複数のIAMロールを１つのインスタンスにアタッチすることはできないが、１つのIAMロールを複数のインスタンスにアタッチすることはできる。 IAMロールはユーザに対してもアタッチできるがインスタンスに対してもアタッチできる。 IAMロールにポリシーを追加したら即時反映される（サーバ再起動は不要）

はじめに 今回は AWS Amplify Studio を試します。 Amplify Studioで UIやデータを作成し、ReactのWebアプリケーションをホスティングします。 準備 Amplify CLI 等、ローカル環境で Amplifyを使う準備をします。 参考:Amplify Figmaのアカウントを取得します。 プロジェクト作成 プロジェクトの名前を入力します 「Studioを起動する」 をクリックします。 Figmaと連携 UI Library画面の「Get started」をクリックします。 「Use our Figma template」をクリックします。 「Duplicate」をクリックします。 「Accept all」をクリックします。 データ作成 Data画面でデータモデルを追加します。 Content画面でデータを追加します。 データを入力し保存します。 コンポーネントとデータモデルの紐付け UI Library画面の My Components から、今回は「CardA」をクリックします。 「Configure」 をクリックし、以下の設定をします。 画像のURL タイトル 日付 ローカル環境での作業 Reactアプリケーションの初期化 mkdir amplify-studio-react cd amplify-studio-react npx create-react-app . npm install aws-amplify @aws-amplify/ui-react Amplify アプリケーションの Pull AWSコンソールから pullコマンドを確認します。 amplify pull --appId {app_id} --envName {env_name} GraphQL の追加 amplify update api GraphQLのクエリーファイルの生成 amplify codegen add src/App.jsの編集 import React, { useState, useEffect } from 'react'; import './App.css'; import { Amplify, API } from 'aws-amplify'; import awsconfig from './aws-exports'; import Card from "./ui-components/CardA"; import { listSampleModels } from './graphql/queries'; Amplify.configure(awsconfig); function App() { const [icons, setIcons] = useState([]); useEffect(() => { fetchIcons(); }, []); async function fetchIcons() { const apiData = await API.graphql({ query: listSampleModels }); setIcons(apiData.data.listSampleModels.items); }; return ( <div className="App"> { icons.map(item => ( <div key={item.id}> <Card Sample={item}></Card> </div> )) } </div> ); } export default App; Webアプリケーションのホスティング・公開 ホスティング amplify add hosting 公開 amplify publish 動作確認 終わりに AWS Amplify Studio を試しました。 UIやデータ作成はブラウザ上で行えましたが、 App.jsの編集や公開作業はローカル環境で行う必要がありました。 アプリケーションを複数人で開発するためのツールとして、とても便利だと感じました。 以下の記事を参考にしました。 Amplify Studioってホントにすごいの？ 【多分初心者向け】AWS Amplify Studio に触ってみて、とりあえず1からwebページを作ってみた Amplify新機能(Studio)を触ってみた(プレビュー版)

概要 急にサイトが500エラーを発生してつながらなくなったので調査して見ると RDSのステータスが「Storage-full」、つまりデータ容量がいっぱいになったことが原因でつながらなくなっていた。 対処方法 前提として、「Storage-full」になるとインスタンスが停止するので、DBに繋げてデータを削除することができない。 そのためRDSのストレージ容量を拡張するをする必要がある。 以下、手順です。 １．RDSの画面から拡張したいDBを選択した状態で「変更」ボタンを押す ２．ストレージを増やす（例だと20GBから30GBに増やしている） ↓↓↓ 拡張する時の注意 RDSのストレージ容量を増やすと後から減らすことはできない。 どうしても減らしたい場合は、一度拡張した後にデータを削除した後にdumpを取ってから別のRDSインスタンスを作る必要がある。 ちなみに10GB増やすだけならそんなに金額は掛からない。 例： リージョン：東京リージョン ストレージタイプ：汎用 (SSD) ストレージ ＄0.138/GB × 10GBとなるので、＄1.38/月となる。 1ドル=115円と計算すると約160円くらい。 参考：RDS料金 今後の対策 取れる方法は２つ １．CloudWatchでストレージ容量を監視し、容量がいっぱいになったら消す 不要なデータを消すことができるならこれが一番お金がかからない。 ２．RDSのオプションで容量をスケーリングさせる RDSのオプションで容量を自動拡張させることができる そもそもデータ消すことができないのであれば、こっちで対応した方がいい。 私の場合は、コストの関係上「１」で対応することになったが、CloudWatchなどの設定はそんなに難しくなく数分で対応できた。 以上となります。

プロフィール 現在新卒2年目で、当時は新卒1年目 開発部に所属しており、業務ではAWSはあまり触っていない サービスの名前と役割が紐づいていないぐらい知識はなかった 勉強期間 期間: 2020/10～2021/02の約半年間 内容: 主に以下の3つ 社内の研修 Udemy AWS WEB問題集で学習しよう 社内の研修 隔週で約2時間の講義が全10回程 問題演習が多めでその場で解説を受けていた 合計20時間 Udemy 以下の講座を受講 【2022年版】これだけでOK！ AWS 認定ソリューションアーキテクト – アソシエイト試験突破講座 この講義では20サービス以上のハンズオンと3回分の模擬テストを受けることが可能 ハンズオンの前にサービスについての説明があるためそこまでハードルは高くなくおすすめ！ 勉強期間は3週間で模擬テストは3周程 1日の勉強時間は平日は業後に2時間程度、休日は6～8時間程度 合計約50時間 AWS WEB問題集で学習しよう 効率的な2つのポイント 効率的にAWSをマスターできること 全11科目、3000問以上の実践的な問題集を使用して学習可能 問題は順次更新されていくため最新の問題を解くことも可能 隙間時間の有効活用 スマートフォンにも対応しており通勤時間を有効活用ができる 7問1セットとなっており、ワンクリックで回答がすぐに表示されることが特徴 注意事項 1度解いた問題の正解/不正解を記憶する機能がない ポイント 数字が大きいものが最新の問題のため、後ろの問題から絶対に解くこと 期間は1ヶ月程度で全問題を1周し、その後は#91以降を2、3周程 1日の勉強時間は平日は業後前・昼休憩・業務後含めて2～3時間、休日は6時間程度 1日49問7セットを目標に取り組んでいました。 何時間勉強したか覚えていない 勉強テクニックと解答のコツ 1. 学習計画を立てる 受験日を最終日として逆算して学習計画を作成する受験日から逆算して学習計画を立てる必要があります。受験日を決めることで目標が明確になり、限られた時間内で集中することができます。受験日を決めないと目標が明確にならずだらだらしてしまうため、まずは受験日を決めると良いです。 また、毎日の勉強計画はおおまかに立て、て挫折しないために余裕を持った計画を立てることがコツです。学習記録をして進捗の管理や調整・修正を行ってもいいと思います。 2. 記憶に定着させるために問題を解く 覚えるよりも思い出すことで記憶に定着する暗記という目的においては、思い出すことが重要です。覚えることよりも思い出すことで記憶に定着するからです。ただテキストを読み返すより問題に答える方が圧倒的に復習効率は良いです。そのため問題演習でアウトプットしていくことがおすすめです。間違った問題は正解できるまで解き直すことが大切です。 3. 継続して勉強する はじめの勉強の敷居を低くする勉強する習慣をつけることがとても大事です。継続するためにはじめの勉強の敷居を低くすることです。 例えば先程紹介したUdemyの動画を聞き流すことです。聞き流すことであれば他のことをしながらできますし負担は少ないと思います。 とにかく実績を作り達成感を得ることが重要です。最初は分からないところは飛ばしていき、最後まで終えた後分からなかったところを重点的に勉強していきます。この繰り返しによって分からなかったところが次第にわかるようになります。知的な欲求が満たされると勉強に楽しみを覚え、ますます継続できるようになり一気に知識の定着が上がります。 4. 問題文から要件を抽出する 文中から問題を解くために必要な情報だけを理解するように努める問題文が長いため文中の情報を全て理解しようとせず、文中から問題を解くために必要な情報だけを理解するように努めるのがよいです。文末から現状のシステムと要件を切り分けることが可能です。また解ける問題を多くするためによく出るキーワードは覚えるようにした方が良いです。 さいごに 1年前のことだが振り返ってまとめてみた SAAを取得したことによって業務の幅が広がったことは実感している クラウドに注目されている今、AWSの資格はキャリアアップに有利とされている 別の資格も取得したいと思っているため、お互い勉強頑張りましょう！

はじめに Microsoft Defender for Cloud は Ignite 2021 で発表された 旧 Azure Security Center と Azure Defender が統合されたサービスです。Microsoft Defender for Cloud はマルチクラウドの CSPM (Cloud Security Posture Management) に対応しており、2022/2/28 現在で AWS と GCP をサポートしています。(ともに Preview 中) AWS 環境のセキュリティチェックと言えば AWS Security Hub ですが、 Microsoft Defender for Cloud は Security Hub に依存せずに独自のチェックを行っています。基本的にはドキュメント通りに簡単に設定できるのですが、どのような仕組みでチェックが行われているのかも見ていきたいと思います。 やってみる 環境設定から AWS アカウントを追加します。 リソースグループやリージョン、AWS アカウント ID などを入力します。AWS Organizations の管理アカウントを指定することで組織内の全アカウントをオンボーディングできるようですが、ここでは単一のアカウントを接続します。 プランの選択ではアカウント内の EC2 や EKS を Microsoft Defender for Cloud に接続することもできますが、ここではセキュリティ体制の管理のみを有効化しました。 アクセスの構成で CloudFormation テンプレートをダウンロードできるため、対象のアカウントにデプロイします。 このテンプレートでは以下のリソースがデプロイされます。 Azure から接続をおこなうための IAM OIDC ID Provider IAM OIDC ID Provider プロバイダを介して Assume Role を行うための IAM Role 先ほどのプランの選択ではアクセス許可は SecurityAudit と記載がありましたが、実際の IAM ロールには ReadOnlyAccess がアタッチされていました。 ちなみにオンボードで管理アカウントを指定した場合は、StackSets を使用して上記のテンプレートをデプロイするような指示があります。 レビューと生成で設定内容を確認して作成を完了すると、対象の AWS アカウントが追加されます。さらに設定の編集からチェック対象の標準を有効化および無効化することができます。 AWS Security Hub と同様に以下の標準に対応しています。 CIS AWS Foundations Benchmark v1.2.0 AWS 基礎セキュリティのベストプラクティス PCI DSS 3.2.1 アカウント追加直後は AWS 基礎セキュリティのベストプラクティスのみが有効になっていたため、追加から標準を選択し、CIS AWS Foundations Benchmark v1.2.0 を追加しました。 設定が完了すると推奨事項ページに順次 AWS リソースが表示されます。環境フィルターで AWS リソースに関する推奨事項のみを表示することができます。 アカウント単位やリソース単位でフィルターしたい場合はインベントリページから確認します。以下は AWS コネクター用に作成したリソースグループでフィルタリングした例です。リソースごとに推奨事項への準拠状況を確認できます。アカウント単位で確認したい場合は、アカウント ID のリソース名 (リソースの種類: microsoft.security/securityconnectors/stsaccount) をクリックします。 以下のように対象アカウント内のリソースの正常性を確認することができます。 AWS Security Hub によるチェックと比較した際の違い いくつか気づいた点を記載します。 推奨事項の除外ができない 2022/2/28 時点では各推奨事項に除外ボタンが表示されていないため、未サポートであるようです。AWS Security Hub はリージョナルサービスであるため、リージョンごとに独立してチェックが行われており、特定のリージョンだけチェックを除外したいというような運用が可能です。 例えば以下は CIS AWS Foundations Benchmark v1.2.0 の準拠状況ですが、3. Monitoring に関連するチェックがすべて NG になっています。CloudTrail や Monitoring の設定は全リージョンには設定しないので、特定のリージョンのみ監視するよう設定したいのですが、現状そういった設定はできません。 カスタム標準を作成することができる Microsoft Defender for Cloud ではカスタム標準を作成して、任意のルールのみを対象にチェックを行うことができます。これにより組織内で必要なチェックに絞って準拠状況のモニタリングを行うことができます。このような機能は AWS Security Hub にはありません。 API 経由でチェックが行われている 冒頭にも記載したとおり、Microsoft Defender for Cloud は AWS Security Hub や AWS Config Rule に依存しない作りになっており、チェックはすべて API 経由で行われます。どのような API アクセスが行われているかは CloudTrail の証跡から確認ができます。Assume Role 時のロールセッション名が MicrosoftDefenderForClouds_xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx のような固定値になっているため、コンソールからであればユーザー名を指定して検索することができます。 今回の検証では AWS 基礎セキュリティのベストプラクティスは無効化していたのですが、上記の履歴を見る限り API による情報収集は裏側では継続して行われているようです。 ドキュメント 以上です。 参考になれば幸いです。

目的 DynamoDBはデータベース的な役割をもつAWSのサービスの一つ、ということしか知らなかったため調査した。 DynamoDBの基本情報 完全マネージド型のSQLサービス 管理を２４時間体制で自動でおこなってくれるサービスのこと NoSQL型のデータベース RDBMS以外である（よくわからないので後述） 低レイテンシー（応答速度が速い） パーティショニングを実施（テーブルを内部で分割している、外からは一つのテーブルに見える） 容量制限がない 高可用性 複数のAZ（アベイラビリティゾーン）にデータを保存しているため、ある地域のDBで障害が発生しても稼働が継続できる NoSQL型とリレーショナルデータベースの違いとは リレーショナルデータベース テーブルと呼ばれるExcelのような列と行で成り立つ二次元の表で表され、 複数のテーブルを用いてデータを抽出することが可能。 あらかじめテーブル名や列名、型を定義しておく必要がある。 仕様変更が柔軟にしにくい。 複雑なデータを保存するには適している。 メインテーブル ID 社員名 所属部署ID 1 山田太郎 01 2 佐藤花子 02 部署テーブル ID 　所属部署　 01 営業部 02 総務部 ちなみにRDBMSとはRelational DataBase Management Systemの略で リレーショナルデータベース型データベースを管理するシステムのことを指す。 NoSQL NoSQLには以下の３つのパターンが存在する key-value型 カラム指向型 ドキュメント型 今回key-value型についてのみ言及する NoSQLの一つであるkey-value型とは 一つのkeyに対して複数のデータ(value)を保持する 大量のデータの蓄積に向いている 他のテーブルと拡張しやすい 大量の読み書きは向いてない データの検索や結合処理には向いてない トランザクションができない？ key Value 1 山田太郎, 営業部 2 佐藤花子, 総務部

はじめに AWSの利用料を節約するために、みなさんは何をしてますでしょうか？ 不要なインスタンスを停止する、使ってないEBSボリュームを削除するなど、定期的にゴミ掃除をするのは効果的です。 それ以外に、割引を適用するという方法もあります。 具体的には、リザーブドインスタンス の使用や、 Savings Plans の適用などです。 今回は後者のSavings Plansについて説明した後に、具体的に適用する手順を紹介したいと思います。 Savings Plansとは？ 公式サイトに載っている説明は以下のとおりです。 Savings Plans は、1 年または 3 年の期間で特定の使用量 (USD/時間で測定) を契約するかわりに、オンデマンド料金と比較して低料金を実現する柔軟な料金モデルです。AWS は、Compute Savings Plans、EC2 Instance Savings Plans、Amazon SageMaker Savings Plans の 3 種類の Savings Plans を提供しています。Compute Savings Plans は、Amazon EC2、AWS Lambda、および AWS Fargate 全体の使用量に適用されます。EC2 Instance Savings Plans は EC2 の使用量に適用され、Amazon SageMaker Savings Plans は Amazon SageMaker の使用量に適用されます。AWS Cost Explorer で 1 年または 3 年の期間の Savings Plans に簡単にサインアップし、推奨事項、パフォーマンスレポート、および予算アラートを利用してプランを管理できます。 要は、長期間（1年 or 3年）の使用をあらかじめコミットしておくことで割引（最大72%）が受けられますよ という制度です。 割引イメージは以下のような形です。 なお、Savings Plansはキャンセル不可なので、1度コミット（＝購入）した後、やっぱりそんなに使わないとなった場合は損してしまいます。 3種類のプランがあるのですがSageMakerは種類が違うので除外して、「Compute Savings Plans」 と 「EC2 Instance Savings Plans」 の2つをざっくり比較してみます。 プラン Compute Savings Plans EC2 Instance Savings Plans 対象 EC2,Fargate,Lambda EC2のみ リージョン指定 不要 必要 インスタンスタイプ指定 不要 必要(m5、t3などファミリー単位) 割引率 低い(最大66%) 高い(最大72%) 要は、「Compute Savings Plans」は後からでも柔軟に変更できるけど割引率低め 、「EC2 Instance Savings Plans」は後から変更はしづらいけど割引率高め となっています。 一長一短なのでどちらがいいかは、システム特性に応じて決めましょう。 購入方法と割引率の確認 Cost Explorerの 「推奨事項」 をチェックするのが一番わかりやすいと思います。 まずはさきほど説明したプランを「Compute Savings Plans」、「EC2 Instance Savings Plans」のどちらか選択します。 そして以下の3つを選択します。 期間 （1年間 or 3年間） 長い方（3年）が割引率が高い 支払いオプション （全額前払い or 一部前払い or 前払いなし） 「全額前払い」が最も割引率が高い。 「前払いなし」は割引率が低い 基準とする直近の期間（7日 or 30日 or 60日） これはSavings Plansのコミット金額を決める上での推奨値に影響する これで割引率を見ていきます。 以下の例はあくまで当方の環境の場合なので、実際の割引率は各自の環境で異なってくると思います。 例①-1 Compute Savings Plans、1年間、前払いなし（割引率14%） 例①-2 Compute Savings Plans、3年間、全額前払い（割引率33%） 例②-1 EC2 Instance Savings Plans、1年間、前払いなし（割引率23～30%） 例②-2 Compute Savings Plans、3年間、全額前払い（割引率41～56%） 購入手続き プランが決まったらカートに入れて購入手続きをします。 以下は例①-1をカートに入れたときの画面です。 ここで 「1時間あたり支払う金額」 にあたる 「コミットメント」 が重要です。 この金額は、リソースを使わなかろうが1年間はずっと支払い続けることになります。 そして、 「合計コスト」 は1年間に支払う総額になります。 あとはオプションで開始期間も選択できます。 この内容で納得いけば 「注文書の送信」 を押しましょう。 以下の画面がでれば完了です。 コミットメント金額を調整したい場合 今回は推奨プランから出された金額をそのまま購入しますが、調整したい場合もあると思います。 その場合は、 「Savings Plansの購入」 からコミットメントを個別に指定してカートに入れて手続きしましょう。 さいごに ということで、Savings Plansの適用についての記事でした。 AWS利用料はほっとくと高くなりがちなので、こういったプランを使ってうまくコストを低減していきましょう。 参考

SVGを出力したい 特に何も考えずに Content-Type だけしっかり指定してあげればOK。 return { 'statusCode': 200, 'headers': { 'Content-Type': 'image/svg+xml', }, 'isBase64Encoded': False, 'body': '<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">svg version="1.1" xmlns="http://www.w3.org/2000/svg">...', } PNGを出力したい こっちが主題になります。 Pythonで画像を取り扱う場合、何らかのライブラリを使用することになると思いますが、今回はおそらく一番使われてるであろうPillowを使っていることにします。 他のライブラリでも応用できると思います。 import io import base64 from PIL import Image # : # ここら辺で画像を色々なんとかして最終的に`image`に何か入ってると思いねぇ # : bytes_io = io.BytesIO() image.save(bytes_io, format='PNG') return { 'statusCode': 200, 'headers': { 'Content-Type': 'image/png', }, 'isBase64Encoded': True, 'body': base64.b64encode(bytes_io.getvalue()).decode('UTF-8'), } ポイントはPillow.Image.save()でio.BytesIOに書き込み、getvalue()で取得したbytes型をBase64でエンコードしてやる、ってところです。 出力がバイナリの場合はisBase64EncodedをTrueにした上でBase64でエンコードしたデータをbodyに入れる必要があります。 書き込み時のformatをJPEG等に変更すればその形式で出力することができます。 あとはSVGと同様にContent-Typeを指定してあげればOKです。 最後に この記事書いてる人は実はあんまりPython得意じゃありません。 なのでもっと良い方法あるよ！って方はコメントとかで教えてください。 ついで（？）に弊社ではサーバーサイドエンジニアを募集していますので、まずはざっくばらんにお話ししてみませんか？ 下記からご応募お待ちしております。 ▼ https://herp.careers/v1/lanchester/Bucw0mXRKogc ▼ https://www.wantedly.com/companies/lanchester ▼採用動画について：https://moovy.jp/job/651

はじめに Lex 組み込みスロットタイプのAMAZON.TIMEを使用した際、 21時と伝えると、聞き取ってくれますが、9時だと、9:00　もしくは　21:00の2通りあるため、Lexがどっちか分からず、エラーになります。 下記のドキュメントに記載されていました。 ただし、時間の発話の範囲が、9:00〜19:00の場合、9時と答えると、21時ではないため、9時と認識してほしいものです。 その方法をまとめます。 事前構築 下記の記事を参考にしました。 Lexは、下記の通りにしました。 実際の発話 21時と答えた場合 LambdaのCloudWatchLogsからログを確認してみると、 interpretedValue（解釈した値）は、21:00となっていました。 { "what_time": { "shape": "Scalar", "value": { "originalValue": "21", "resolvedValues": [ "21:00" ], "interpretedValue": "21:00" } } } 9時と答えた場合 9時と答えるとエラーになりました。 LambdaのCloudWatchLogsからログを確認してみると、 resolvedValues内に、"09:00","21:00"の2つがあることがわかります。 { "what_time": { "shape": "Scalar", "value": { "originalValue": "9", "resolvedValues": [ "09:00", "21:00" ] } } } interpretedValue（解釈した値）は、ないことも分かりました。 対処方法 LexのLambdaは、以下のようにしました Lambda import json from decimal import Decimal # json形式でログを出力するため、Decimalがある場合取り除く def decimal_to_int(obj): if isinstance(obj, Decimal): return int(obj) def elicit_slot(slot_to_elicit, intent_name, slots): return { 'sessionState':{ 'dialogAction': { 'type': 'ElicitSlot', 'slotToElicit': slot_to_elicit, }, 'intent':{ 'name': intent_name, 'slots': slots, 'state': 'InProgress' } } } def validation_slot(slot_to_elicit, message_content, intent_name, slots): return { 'messages': [{'contentType': 'PlainText', 'content': message_content}], 'sessionState':{ 'dialogAction': { 'type': 'ElicitSlot', 'slotToElicit': slot_to_elicit, }, 'intent':{ 'name': intent_name, 'slots': slots, } } } def confirm_intent(intent_name, slots): return { 'sessionState':{ 'dialogAction': { 'type': 'ConfirmIntent', }, 'intent':{ 'name': intent_name, 'slots': slots, 'state': 'Fulfilled' } } } def input_slots_value(value): return { "shape": "Scalar", "value": { "originalValue": value, "resolvedValues": [value], "interpretedValue": value } } def close(fulfillment_state, message_content, intent_name, slots): return { 'messages': [{'contentType': 'PlainText', 'content': message_content}], "sessionState": { 'dialogAction': { 'type': 'Close', }, 'intent':{ 'name': intent_name, 'slots': slots, 'state': fulfillment_state } } } # "time"インテント def time_reserve(intent_request): print("Received event:" + json.dumps(intent_request, default=decimal_to_int, ensure_ascii=False)) intent_name = intent_request['sessionState']['intent']['name'] slots = intent_request['sessionState']['intent']['slots'] print('Received intent_name:' + json.dumps(intent_name, default=decimal_to_int, ensure_ascii=False)) print('Received slots:' + json.dumps(slots, default=decimal_to_int, ensure_ascii=False)) if slots['what_time'] is None: return elicit_slot('what_time',intent_name,slots) what_time_resolved = slots['what_time']['value']['resolvedValues'] counts = len(what_time_resolved) # あいまいな時間を言った場合 for i in range(counts): if what_time_resolved[i] >= "09:00" and what_time_resolved[i] <= "19:00": what_time = what_time_resolved[i] slots['what_time']['value']['interpretedValue'] = what_time break what_time = slots['what_time']['value']['interpretedValue'] # 09:00〜19:00範囲内 if what_time < "09:00" or what_time > "17:00": return validation_slot('what_time','時間は、9:00から19:00時の間でお伝え下さい。',intent_name,slots) print('what_time:' + json.dumps(what_time, default=decimal_to_int, ensure_ascii=False)) confirmation_status = intent_request['sessionState']['intent']['confirmationState'] print(confirmation_status) if confirmation_status == "Confirmed": return close( "Fulfilled", '承知しました。', intent_name, slots) elif confirmation_status == "Denied": return close( "Failed", 'キャンセルしました。', intent_name, slots) elif confirmation_status == "None": return confirm_intent( intent_name, slots) # インテントのルーティング def dispatch(intent_request): # 他にインテントを使用する場合 intent_name = intent_request['sessionState']['intent']['name'] # "book"インテント if intent_name == 'book': return book_reserve(intent_request) # "time"インテント if intent_name == 'time': return time_reserve(intent_request) def lambda_handler(event, context): return dispatch(event) 注意点ですが、時間を判定する際、時間は、"9:00"ではなく、"09:00"と0が必要です。 if what_time < "9:00" : # ✕ if what_time < "09:00" : # ◯ テスト 9時と答えた場合 9時と答えた場合、21:00ではなく、9:00と判断されました。 8時と答えた場合 9:00〜19:00を答えた場合、拒否されます。 別の方法 今回時間範囲が9:00〜19:00でしたが、時間範囲がない場合の対処法は、時間の前に午前・午後をつけると聞き取ってくれます。 AMAZON.TIMEの発話リスト 他にも以下の伝え方だと、聞き取ってくれます。 発話 判定 3時 ✕（聞き取れない） 15時 15:00 15時半 15:30 午後3時 15:00 午前12時 00:00 午後0時 15:00 午後12時 12:00 午後0時 12:00 今 現在の時刻

私がテストでミスった部分の知識を共有します。 EC2 キーペアは1つのVPCに5000個まで。 停止中にもEBSの料金が発生する。 ストレージはEC2インスタンスストア(停止すると消える)かEBS -　スポットインスタンス：余ってるEC2使う。同じ性能で、最大90%off。 -　EC2ImageBuilderはAMIの設定更新の自動化 EC2フリートはオンデマンドインスタンスとスポットインスタンスで構成される インスタンス間のネットワークのレイテンシを最小限に抑える必要がある場合、クラスタープレイスメントグループにて、単一のAZ内のインスタンスを論理的にグループ化 GPU持ってるやつは高速コンピューティング AMI AMIの共有はアカウント番号を指定するだけで他のアカウントに共有可能 リージョン内のみで利用可能。別リージョンにコピーして別AMIとしても利用可 1つのリージョンで利用できるElasticIPの上限は5 Directed Hostは別IAMグループとは物理サーバは共有せず、物理的にサーバを占有可 スティッキーセッションは同一ユーザーの同じセッションのアクセスを全て同じEC2インスタンスに送信する Connection Drainingは登録解除されるが、異常が発生したインスタンスへの新規リクエスト送信を中止する機能 route53 レイテンシベースルーティングはレイテンシの低いリソースへルーティング 位置情報ルーティングは、地理的に近いリソースへルーティング VPC 1リージョン、最大5VPC VPCエンドポイントはグローバルIPをもつAWSサービスに対し、VPC内から直接アクセスする為の出口 ゲートウェイ型エンドポイント サービスの宛先とするトラフィックのルートテーブルの宛先として指定できるゲートウェイ DynamoとS3に適応可 VPCフローログはVPC内の通信の解析 ネットワークACLはVPC/サブネット単位で適応。+ステートレスで、インバウンドだけではアウトバウンドは許可されない SG→インスタンス単位 ACL→VPC単位 AutoScaling クールダウンのデフォルトは300sec ウォームアップ条件ステップスケーリングポリシー`によって設定 Aurora 3つのAZに配置、6個レプリケート可能 自動で10GBのセグメントに分割 最大15のリードレプリカ RDS フェイルオーバーするとDBインスタンスのCNAMEを自動で切り替えられる Lambdaを連携させたい時、RDS Proxyを使用 シャーディング可能(DB負荷分散) AutoScalingはストレージ増加させる lambda cloud watch logsのログをLambdaへ連携する場合、cloudwatchLogsのサブスク機能 最大一時実行ボリューム512MB デフォルトタイムアウト3sec、max実行時間は15min SQS メッセージサイズ最大 256kb(拡張clientライブラリ利用で、最大2GBまで) AutoScalingトリガーを構成する場合はSQSのキューサイズを確認 ロングポーリングですぐにメッセージが受信可能 S3 特定のIPアドレスからのアクセスはIAMロールで設定 AccessAnalyzerで不正アクセス確認 ストレージ分析でいつ適切なデータをストレージクラスに移行するか判断 S3 Intelligent-Tieringで低頻度アクセスのオブジェクトを自動的に低頻度アクセスに移動 Glacier Deep ArcheveはS3のアーカイブ、長期バックアップ Glacierより優位な点は 3つ以上のAZにまたがって保存 12時間以内に取り出せる S3 selectはオブジェクトからデータの一部のみを取り出し可 クロスリージョンレプリケーションは異なるAWSリージョン内のS3バケット間でオブジェクトをコピーする機能 暗号方式 SSE-S3 SSE-KMS SSE-C ボールドロック：ボールドロックポリシーでファイル削除とか禁止 cloudfront Gzip圧縮機能でエッジ側でコンテンツを圧縮して高速配信 コスト算出法 エッジロケーションの場所 データ転送量 リクエスト数 ALB メリット L7、パスルーティング 1インスタンスに複数ポートを登録可 ターゲットグループでのヘルスチェック可 デメリット リージョン間無理。 ログファイル分析するには、S3でELBファイル収集、EMRで解析 cloudwatch 3つのステータス OK(正常) ALARM(警告) INSUFFICIENT_DATA(データ足りていない) 拡張：Ec2にcloudwatchAgentをインストール EBS DLM(Data Lifecycle manager)定時バックアップが可 最初、フルバックアップその後増分 プロビジョンドIOPS I/O負荷の高いワークロード、特にデータベースワークロードのニーズを満たすように設計 複数のEC2アタッチ可能 アクセス頻度低いけど、大事なデータの保存のストレージにはEBSのコールドHDDを選択 同一AZ内にアタッチ可 暗号化 ボリューム内の保存データ ボリューム内のインスタンス間で移動されるデータ ボリュームから作成されたスナップショット スナップショットから作成された全てのボリューム DynamoDB 1ミリ単位のレイテンシを要求する時 1アイテム400kBまで リードレプリカ無い Elastic Cache ノード：最小単位 シャード：1~6個のノードで構成 プライマリノード：データの更新と紹介 レプリカノード：プライマリをコピー、障害時に使う クラスター：複数のシャードで構成。マルチAZ複数AZに分散可 EFS NFSv4プロトコル Elastic BeanStalk デプロイ、プロビジョニング、ロードバランシングなどできる Dockerの仕組みを利用 Trusted Adviser コスト最適化、パフォーマンス、セキュリティ、耐障害性、サービスの制限 EMR EC2とS3で構成されたHadoopフレームワーク appSync GraphQLの開発を容易にする完全マネージド型SB 単発 Storage Gateway、S3 Glacierは標準で暗号化 AD Connector:IAMとオンプレのADを連携 Amazonマルチアップロード：大量のobjectをいくつかに分けて並列でアップロード、基本100MB以上の場所 インスタンスのトラフィック分散はRoute53じゃなくてELB API Gatewayの処理性能向上は、スロットリング制限設定とキャッシュを有効化 AWSでは/28が最小のCIDR単位 IPフローティング：ELBやRoute53によるDNS情報の伝搬の際の一定のダウンタイムを防止するため、仮想IPアドレスを使って可用性を高めるサービス コストの可視化はCost Explorer PCIまたは HIPAA準拠(クレカ処理)の処理を実行している場合、監査のためには過去365日間のCloud Frontの使用状況を記憶すること Well-Architectedの5つの柱 運用の優勢性 セキュリティ 信頼性 パフォーマンス効率 コスト最適化 VPN関連 AWS間のVPN接続の監視：CloudWatch TunnelStateを利用 オフィスと社内ネットワークとAWSのVPN接続を必要:AWS managed VPN その他 VMImport/Export：仮想マシン、イメージをEc2に移行したり AmazonLex；音声、テキストを使用して対話できる AmazonPolly：文章をリアルな音声に変換 AmazonSageMaker：機械学習モデルを迅速に構築 AmazonRekognition：画像分析、動画分析 Aws Lake Formation：S3を利用したデータレイク構成 AWS SAM(serverless application model)：サーバーレスアプリケーション。cloud formationと連携 Amazon Simple Workflow：分散アプリケーションコンポーネント間での作業調整を用意するサービス AWS Global Accelerator：アプリケーションの障害による停止時間と割合と応答性能を改善するネットワークサービス フェイルオーバー：使用不可能になった時に、自動的に切り替わる Pop3:ローカルに落とす。IMAP4：リモートの内容を見る パイロットライト：停止した状態の最小限の構成を別リージョンに用意。

はじめに 2022年2月にAWSクラウドプラクティショナーを受験し、無事に合格しました。 40代の非エンジニア、家族は妻と子供2人の私でも合格できましたので、今後取得されようとされている40代の非エンジニア、家族持ちの方々にも参考になれば幸いです。 勉強教材 Udemy【2022年版】これだけでOK! AWS認定クラウドプラクティショナー試験突破講座（豊富な試験問題290問付き） ななななんと！AWS認定の模擬試験が無料になりました！！ 学習内容 非エンジニアの家族持ちのため、お風呂や移動の時間などもフル活用して、動画学習できる時間と場所でまずは理解に努めて、 そのあとは、UdemyとAWS公式の模擬試験を実施して、100点を取れるまで何度も何度も繰り返す、 これをひたすらやっていました。 通常業務はもちろんのこと、家事や育児もやりながらの学習でしたので、1日の学習時間があまり取れず、模擬試験で100点を継続して取れるようになるまでには、1ヶ月半ぐらいかかりました。 試験結果 なんとか717点で、一発合格できました。 試験内容は、UdemyとAWSの模擬試験とは異なる問題が多くあったと感じましたが、 複数の模擬試験で100点を継続的に取れるようになっていれば、合格できるレベルにまでもってこれるのかなと思いました。 まとめ 40代の非エンジニアでも合格可能な資格です。 これまでは、各案件における協議を狭い世界でしていたのだと気付きがあり、 AWSというシェア1位のクラウドサービスの体系を学んでおくことは、 今後のクラウドサービスを作っていく上では必須の資格だと思いました。 皆様のご参考になれば幸いです。

はじめに みなさんはOpenShift上のコンテナからAWSを操作する時、どのような形で権限を付与していますか？よくあるパターンとしてIAMユーザーのアクセスキーとシークレットキーをSecretで環境変数としてアタッチすることが多いかと思います。 しかしAWSでのベストプラクティスでは、システム上での認証はIAMユーザーでなくIAMロールやAWS STS(Security Token Service)による一時的な形での付与を推奨されています。また企業のセキュリティ規約上、システムリソースにIAMユーザーを使うことを明示的にNGにしていることもあるかと思います。 そこで、OpenShift上のコンテナに対して、IAMユーザーの認証情報ではなく、STSを使った一時的な認証情報を渡す方法についてご紹介します。 ここでは、Red Hat OpenShift Service on AWS(ROSA)環境にてSTSによる認証を付与されたPodからAWSリソースにアクセスできるまでの手順をまとめます。 前提条件としてすでにSTSを使ったROSA環境をデプロイできていることを想定しているため、もしこれからSTSを使ったROSAのインストールを実施する場合は以下の赤帽エンジニアブログを参照ください。 AWS STSを使ったROSAのデプロイ また、AWS IPIインストール時の手順は、OpenShiftの構築手順と含めて以下の赤帽エンジニアブログに上げています。 AWS STSを使って一時的な認証情報を扱うOpenShift on AWS環境を構築する それでは、まずはキーコンポーネントとなるCloud Credential Operatorの説明から。 Cloud Credential Operator（CCO） Cloud Credential Operator（CCO）はOpenShiftの管理Operatorで、デフォルトでクラスターにインストールされています。 CCOはクラウドの認証情報をCredentialsRequestというカスタムリソースで管理しており、このリソース内に記述したIAMポリシー情報や利用先のNamespace情報を元に、自動的に該当のIAMユーザーの作成とSecretの作成を実施してくれる便利なツールです。 IAMユーザーの利用で問題なければ、上記を活用して簡単にAWSアクセス用のリソースが準備できるのでぜひご利用してみてください。 今回はSTSを使うということなのでOpenShift上のこちらの機能は活用できませんが、CCOはccoctlというバイナリツールを提供しており、それを使うことでCredentialsRequestからSTSを使う場合のSecret yamlファイルを作成することができます。 ちなみにOpenShiftのSTSによるインストールはバージョン4.8からGAになりました。 以下はCCOのgithubにある、STSを使った一時的なCredential付与の概要です。 OpenShiftは、AWS Security Token Service(STS)で様々なコンポーネントの一時的なクレデンシャルを使用するように設定できます。これにより、認証フローが有効になり、コンポーネントがIAMロールを引き受けることができるため、資格情報が短命になります。また、AWS IAM OpenID Connect（OIDC）IDプロバイダーを使用して、Credentialsのリクエストと更新を自動化します。OpenShiftは、AWS IAMによって信頼されているServiceAccountトークンに署名できます。このトークンは、Podにプロジェクションして認証に使用できます。以下は、それがどのように機能するかを示す図です。 https://github.com/openshift/cloud-credential-operator/blob/master/docs/sts.md ROSA環境におけるSTS利用手順 前提条件 Linux環境 ROSAをAWS STSを使った方法でインストール済 ocコマンド AdministratorAccessのIAMユーザー pull-secretのダウンロード まずはこちらからpull-secretをダウンロードして実行フォルダに格納してください。 ccoctlバイナリのダウンロード まずccoctlコマンド実行のための準備を行います。 ROSA環境にcluster-adminでログインしている状態で以下のコマンドを実行します。 今のROSA環境にインストールされているCCOのイメージを取得し、バイナリとしてダウンロードします。 $ CCO_IMAGE=$(oc adm release info --image-for='cloud-credential-operator') $ oc image extract $CCO_IMAGE --file="/usr/bin/ccoctl" -a ./pull-secret.txt $ chmod 775 ccoctl 以下コマンドを実行すると正常にダウンロードできているか確認できます。 $ ccoctl aws --help Creating/updating/deleting cloud credentials objects for AWS cloud Usage: ccoctl aws [command] Available Commands: create-all Create all the required credentials objects create-iam-roles Create IAM roles create-identity-provider Create IAM identity provider create-key-pair Create a key pair delete Delete credentials objects Flags: -h, --help help for aws Use "ccoctl aws [command] --help" for more information about a command. IDプロバイダーのARNを確認 AWSコンソールにログインして、IAM→IDプロバイダからROSA構築時に作成されたIDプロバイダを選択し、表示されたARNをメモしておきます。 CredentialsRequestリソースのyamlファイルを作成 次に、デプロイしたいIAMロールの権限情報を記載したCredentialsRequestリソースのyamlファイルを作成します。 今回はPodからS3バケットの一覧を取得するコマンドを実施したいので、その操作に必要な権限を定義します。 以下は、Secretのデプロイ先Projectを「sts-test」に、またPodに付与するService Accountを「default」にすることを前提として記述しています。 $ mkdir -p sts-test-resource/cred-reqs $ cd sts-test-resource $ vi cred-reqs/s3-access-secret.yaml cred-reqs/s3-access-secret.yaml apiVersion: cloudcredential.openshift.io/v1 kind: CredentialsRequest metadata: name: sts-test-cr namespace: openshift-cloud-credential-operator spec: secretRef: name: s3-access-secret namespace: sts-test providerSpec: apiVersion: cloudcredential.openshift.io/v1 kind: AWSProviderSpec statementEntries: - effect: Allow action: - s3:ListAllMyBuckets resource: "*" serviceAccountNames: - default ccoctlコマンドの実行 取得・作成した内容をもとに、ccoctlコマンドを実行してIAMロールの作成とsecretマニフェストの作成を行います。 --identity-provider-arnには先述の手順で取得したIDプロバイダーのARNを入力します。 $ ccoctl aws create-iam-roles \ --identity-provider-arn arn:aws:iam::XXXXXXXXXXXX:oidc-provider/rh-oidc.s3.us-east-1.amazonaws.com/1ql0oja8ndd2h0s03c9lhmdrtfqev56q \ --output-dir ./outputs \ --name sts-test-rosa \ --region ap-northeast-1 \ --credentials-requests-dir ./cred-reqs/ 実施すると、IAMロールが新規に作成されます。 ポリシーを確認するとCredentialsRequestで指定したポリシーがアタッチされています。 信頼関係を見てみると、ROSAインストール前に構築したIDプロバイダーをプリンシパルとして、sts-testNamespaceのdefaultサービスアカウントに権限を付与することが読み取れます。 またoutputsディレクトリに、デプロイするためのマニフェストが出力されています。 $ cat outputs/manifests/sts-test-s3-access-secret-credentials.yaml apiVersion: v1 stringData: credentials: |- [default] role_arn = arn:aws:iam::XXXXXXXXXXXX:role/sts-test-rosa-sts-test-s3-access-secret web_identity_token_file = /var/run/secrets/openshift/serviceaccount/token kind: Secret metadata: name: s3-access-secret namespace: sts-test Secretのデプロイ outputsディレクトリに出力されたyamlをデプロイします。 $ oc new-project sts-test $ oc create -f outputs/manifests/sts-test-s3-access-secret-credentials.yaml これでPodからSTSの認証情報を取得する準備が整いました。 Podのデプロイ 最後にデプロイするPodのyamlファイルを作成していきます。 デプロイしたSecretを/var/run/secrets/awsにVolumeMount awscli実行時の認証ファイルに/var/run/secrets/aws/credentialsを使うようAWS_CONFIG_FILE環境変数を設定 サービスアカウントのトークンを/var/run/secrets/openshift/serviceaccountに格納するようbound-sa-tokenvolumesを設定（詳細はこちらを参照） $ vi pod.yaml pod.yaml apiVersion: v1 kind: Pod metadata: annotations: labels: run: running-aws name: running-aws spec: containers: - command: - tail - -f - /dev/null image: amazon/aws-cli name: running-aws resources: {} env: - name: AWS_CONFIG_FILE value: /var/run/secrets/aws/credentials volumeMounts: - name: aws-credentials mountPath: /var/run/secrets/aws readOnly: true - name: bound-sa-token mountPath: /var/run/secrets/openshift/serviceaccount readOnly: true volumes: - name: aws-credentials secret: defaultMode: 420 secretName: s3-access-secret - name: bound-sa-token projected: defaultMode: 420 sources: - serviceAccountToken: audience: openshift expirationSeconds: 3600 path: token 上記のPodをデプロイします。 $ oc create -f pod.yaml 実際にPodにログインしてawsコマンドを叩いてみます。 $ oc rsh running-aws sh-4.2# aws s3 ls 2022-02-28 05:46:27 sts-test-rosa-vlwl8-image-registry-ap-northeast-1-tcfkpstrpeww 無事にS3バケットの情報が取得できました。 最後に ということで、ROSA環境におけるSTSでの一時的な認証付与を行なったPodの作成方法についてご紹介しました。 CCOの機能を最大限活用するにはIAMユーザーでの運用が望ましいですが、セキュリティ的な側面からIAMユーザー認証が使えない際は、この手法を検討してみてはいかがでしょうか？

はじめに 以前にDynatraceによるAWSの監視の始め方という記事を書きました。このときは、ActiveGateは利用せずDynatraceから直接AWSを監視する方法について、記載しました。 本記事では、ActiveGateを利用して、AWSを監視する方法について紹介していきます。 ActiveGateの導入方法については以下の記事で紹介していますので、ご参考ください！ ActiveGateを利用してAWSを監視する場合、ActiveGateにIAM Roleを割り当てる必要があるためActiveGateはEC2インスタンスに立てる必要があります。 ActiveGateを利用する必要があるケース 以前の記事の通り、ActiveGateを利用しなくともAWSを監視することは可能です。ただし、ActiveGateを利用しない場合は、EC2やEBS、ELB、RDSなどに限定されます。それ以外の様々なサービスの監視を行うためにはActiveGateを利用する必要があります。 設定の流れ ActiveGate の構築 AWS監視用ポリシーの作成 AWSロールの作成 AWS監視用ロールの作成 ActiveGate用ロールの作成 AWSアカウントとDynatraceの接続 オプションで以下を設定していきます。 AWSのリソースタギング サポートサービスの追加 アラートのためのメトリックイベントの設定 詳細な設定はDynatraceのマニュアルサイトをご参照ください。 ActiveGateの構築 別記事に掲載していますので、そちらを参考にEC2インスタンス上にActiveGateを構築します。 AWS監視用ポリシーの作成 AWSマネジメントコンソールからIAMのページを開きます。 ポリシーのページに行き、ポリシーの作成をクリックします。 JSONタブを選び、以下のjsonポリシーを貼り付けます。 JSONポリシー { "Version": "2012-10-17", "Statement": [ { "Sid": "VisualEditor0", "Effect": "Allow", "Action": [ "acm-pca:ListCertificateAuthorities", "apigateway:GET", "apprunner:ListServices", "appstream:DescribeFleets", "appsync:ListGraphqlApis", "athena:ListWorkGroups", "autoscaling:DescribeAutoScalingGroups", "cloudformation:ListStackResources", "cloudfront:ListDistributions", "cloudhsm:DescribeClusters", "cloudsearch:DescribeDomains", "cloudwatch:GetMetricData", "cloudwatch:GetMetricStatistics", "cloudwatch:ListMetrics", "codebuild:ListProjects", "datasync:ListTasks", "dax:DescribeClusters", "directconnect:DescribeConnections", "dms:DescribeReplicationInstances", "dynamodb:ListTables", "dynamodb:ListTagsOfResource", "ec2:DescribeAvailabilityZones", "ec2:DescribeInstances", "ec2:DescribeNatGateways", "ec2:DescribeSpotFleetRequests", "ec2:DescribeTransitGateways", "ec2:DescribeVolumes", "ec2:DescribeVpnConnections", "ecs:ListClusters", "eks:ListClusters", "elasticache:DescribeCacheClusters", "elasticbeanstalk:DescribeEnvironmentResources", "elasticbeanstalk:DescribeEnvironments", "elasticfilesystem:DescribeFileSystems", "elasticloadbalancing:DescribeInstanceHealth", "elasticloadbalancing:DescribeListeners", "elasticloadbalancing:DescribeLoadBalancers", "elasticloadbalancing:DescribeRules", "elasticloadbalancing:DescribeTags", "elasticloadbalancing:DescribeTargetHealth", "elasticmapreduce:ListClusters", "elastictranscoder:ListPipelines", "es:ListDomainNames", "events:ListEventBuses", "firehose:ListDeliveryStreams", "fsx:DescribeFileSystems", "gamelift:ListFleets", "glue:GetJobs", "inspector:ListAssessmentTemplates", "kafka:ListClusters", "kinesis:ListStreams", "kinesisanalytics:ListApplications", "kinesisvideo:ListStreams", "lambda:ListFunctions", "lambda:ListTags", "lex:GetBots", "logs:DescribeLogGroups", "mediaconnect:ListFlows", "mediaconvert:DescribeEndpoints", "mediapackage-vod:ListPackagingConfigurations", "mediapackage:ListChannels", "mediatailor:ListPlaybackConfigurations", "opsworks:DescribeStacks", "qldb:ListLedgers", "rds:DescribeDBClusters", "rds:DescribeDBInstances", "rds:DescribeEvents", "rds:ListTagsForResource", "redshift:DescribeClusters", "robomaker:ListSimulationJobs", "route53:ListHostedZones", "route53resolver:ListResolverEndpoints", "s3:ListAllMyBuckets", "sagemaker:ListEndpoints", "sns:ListTopics", "sqs:ListQueues", "storagegateway:ListGateways", "sts:GetCallerIdentity", "swf:ListDomains", "tag:GetResources", "tag:GetTagKeys", "transfer:ListServers", "workmail:ListOrganizations", "workspaces:DescribeWorkspaces" ], "Resource": "*" } ] } ポリシーの名前にはわかりやすい名称（Dynatrace_monitoring_policyなど）を設定します。 ポリシーの作成をクリックし、ポリシーを作成します。 AWSロールの作成 AWSロールを作成するには以下が必要になります。 DynatraceのAWSアカウントID: 509560245411 ActiveGate をホストしているAWSアカウントID 監視対象となるAWSアカウントID 外部ID Step 1. 外部IDの取得 AWSロールを付与するための外部IDを取得します。 DynatraceのGUIにログインをし、左のメニューからの一番下にある管理 > 設定を開きます。 Cloud and virtualization > AWSを開きます。 Connect new instanceをクリックします。 Authentication methodをRole-based authenticationに変更し、Copyボタンをクリックします。 この画面は後ほど戻ってきますので、このままにしておきます。 Step 2. 監視用ロールの作成 監視対象のAWSアカウントに監視用ロールを作成します。もし、複数のAWSアカウントを監視する場合はこの手順を監視対象のAWSアカウント全てで行います。 AWSコンソールからロールのページに行き、ロールを作成をクリックします。 信頼されたエンティティタイプにはAWSアカウント > このアカウント(***)を選びます。外部IDを要求するにチェックを入れ、外部ID欄にStep 1.で取得した外部IDをペーストし、次へをクリックします。 許可ポリシーでは先ほど作成したポリシー（Dynatrace_monitoring_policy）を選択し、次へをクリックします。 ロール名にはわかりやすい名称（Dynatrace_monitoring_roleなど）を入力し、ロールを作成をクリックします。 Step 3. ActiveGate用ロールの作成 監視用ロールを作成したら、ActiveGateに割り当てる用のロールを作成します。 AWSコンソールからロールのページに行き、ロールを作成をクリックします。 AWSのサービス > EC2を選び、次へをクリックします。 許可ポリシーは何も設定せずに次へをクリックします。 ロール名にはわかりやすい名称（Dynatrace_ActiveGate_roleなど）を入力し、ロールを作成をクリックします。 作成した ActiveGate用ロール（Dynatrace_ActiveGate_role）を開き、インラインポリシーを作成をクリックします。 JSONタブを選び、以下のjsonポリシーを貼り付け、自身の環境に合うように編集します。 複数のAWSアカウントを監視する場合はStatement.Resourceに全て記載をします。 編集が完了したら、ポリシーの確認をクリックします。 JSONポリシー { "Statement": [ { "Resource": [ "arn:aws:iam::<12桁の監視対象のAWSアカウントID>:role/<Step 2で作成した監視用ロール名 (Dynatrace_monitoring_role)>" ], "Action": [ "sts:AssumeRole" ], "Effect": "Allow" } ], "Version": "2012-10-17" } インラインポリシーにわかりやすい名称（Dynatrace_assume_policyなど）を入力し、ポリシーの作成をクリックします。 Step 4. 監視用ロールへの信頼ポリシーの編集 Step 2で作成した監視用ロール（Dynatrace_monitoring_role）を開き、信頼関係タブから信頼ポリシーを編集をクリックします。 信頼ポリシーを編集画面で以下のjsonポリシーを貼り付け、自身の環境に合うように編集します。 JSONポリシー { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "sts:AssumeRole", "Principal": { "AWS": [ "arn:aws:iam::<12桁の監視対象のAWSアカウントID>:role/<Step 3で作成したActiveGate用のロール (Dynatrace_ActiveGate_role)>", "arn:aws:iam::509560245411:root" ] }, "Condition": { "StringEquals": { "sts:ExternalId": "<Step 1で取得した外部ID>" } } } ] } 更新が完了したら、ポリシーを更新をクリックします。 Step 5. ActiveGateへロールの適用 AWSコンソールからEC2を開き、ActiveGateのインスタンスを選択します。 アクション > セキュリティ > IAMロールを変更をクリックします。 Step 3で作成したActiveGate用ロールを選択して、保存をクリックします。 Dynatraceとの接続 Connection nameにどのような任意の名前（どのようなアカウントなのかわかりやすいもの）を入力し、IAM role that Dynatrace should use to get monitoring dataに作成した監視用ロール名を、Your Amazon account IDに監視対象のAWSアカウントIDを入力します。最後に接続ボタンをクリックすることでAWSに接続し、監視が始まります。 以上の操作で、AWSの主要な機能に関する監視が行われます。 オプション設定 リソースタギング 以前の記事でも記載したように、AWSのタグを利用することで、監視する対象を制限でき、AWSに対するAPIコール数を制限することが可能です。 AWSコンソールから対象となるリソースに対して、タグを指定します。ここではキーにmonitor_dynatrace、値にtrueを設定しています。 設定 > Cloud and virtuallzation > AWSと進んで、先ほど作成した設定の右側にあるペンシルアイコンをクリックします。 Resource to be monitored欄をMonitor resources selected by tagsに変更し、主要と値にAWSの監視対象と同一のものを入力し、保存ボタンをクリックします。 ここで設定したキーと値が一致したリソースのみを監視するようになります。 サポートサービスの追加 ActiveGateを用いたAWSの監視のメリットはEC2やEBS、ELB、RDSなどの主要なサービス以外の様々なAWSサービスのメトリックを取得可能な点です。DynatraceがサポートしているAWSサービスについては以下から確認ができます。 AWS supporting service metrics Dynatraceでは選択したサービスに対してAWS CloudWatchのメトリクスを選択して取得することができるため効率よくデータを取得できコスト削減につなげることができます。 リソースタギングと同様に設定したAWSの画面を開き、サポートサービスからAdd serviceボタンもしくはManage servicesボタン（一度、serviceを追加したらManage servicesに変わります）をクリックします。 Select service to be monitored...フィールドから監視したいサービスを選択し、Add serviceボタンをクリックします。 Add serviceボタンをクリックし、監視したいサービスを全て登録したら変更の保存ボタンをクリックします。 インフラストラクチャ > AWSを開き、作成したAWS名をクリックすることでAWSの監視画面を開きます。サポートサービスをクリックすることで先ほど設定したサービスを監視していることが確認できます。 これらのサービスをクリックすることで、詳細を確認することが可能です。 取得するメトリックの編集 再度、設定 > Cloud and virtuallzation > AWSと進み、AWSの設定画面を開きます。サポートサービスの下のManage servicesをクリックします。 監視しているサービスの一覧が表示されるので、メトリックを編集したいAWSサービスの名前をクリックします。 メトリックを追加する場合は、メトリックの追加ボタンを削除する場合は、該当メトリックの×アイコンをディメンションなどの変更を行う場合は、下矢印アイコンクリックします。 追加したいメトリックを選び、Choose dimension(s)からディメンションを選択し、メトリックの追加ボタンをクリックします。 最後に忘れずに変更の保存ボタンをクリックします。 アラートのためのメトリックイベントの設定 サポートサービスで追加取得したメトリックについても、アラートの設定をすることが可能です。Dynatraceではあらかじめ推奨のアラートルールが定義されておりそれを有効にするだけで、細かい閾値の設定などは必要ありません（もちろん閾値を変更することも可能です）。 設定 > Cloud and virtuallzation > AWSと進み、AWSの設定画面を開き、Manage alerting rulesボタンをクリックします。 監視しているサポートサービスの内容に応じた推奨のアラートルールが表示されます。全てのルールを作成する場合はCreate all recommended alerting rulesボタンをクリックします。 特に保存ボタンなどはなく有効になります。個別に設定を変更したい場合はアラートルール名をクリックすることで閾値などを変更可能です。 まとめ 今回はActiveGateを利用したDynatraceによるAWSの監視の設定方法について紹介しました。ActiveGateを利用することで監視の幅が広がりますので、ぜひご活用いただければ幸いです。 また、AWSの監視についてはEC2インスタンスにOneAgentをインストールすることで、自動でAWSのタグをホスト情報に紐付けてくれたりするので、AWS上でアプリケーションを展開しているのであればぜひ導入を検討してみてください。

はじめに AWSはクラウドなので、使いたいときに使いたいだけのリソースを使用できます。 とはいえ、AWSも物理リソースには限界があります。いざEC2を起動したいと思ったときに、キャパシティ不足で起動できないという可能性があるわけです。 そんなリスクに備える手段が 「オンデマンドキャパシティ予約」 になります。 これをあらかじめ行っておけば、リソース不足でEC2が起動できないといったリスクを回避することができます。 ただ、キャパシティを予約しておくということは、その分のリソースを確保しておくことなので、当然ながらお金がかかります。費用はEC2をオンデマンドで起動しておくのと同等の金額です。 EC2を起動していなくても料金はかかってしまうので、その点がデメリットです。 今回はスクリーンショットとともに、オンデマンドキャパシティ予約に実施方法を記します。 なお、AWS公式ページはこちらにあります キャパシティ予約の実施手順 まずはマネージメントコンソールにログインし、該当リージョンのEC2のページを開きます。 ここで 「キャパシティの予約」＞「キャパシティ予約の作成」 をクリックします。 インスタンスの詳細 以下を選択します インスタンスタイプ プラットフォーム(OS) アベイラビリティーゾーン(AZ) テナンシー プレイスメントグループ 数量 インスタンスタイプ、OS、AZなどが多様だと、それごとに設定しなくちゃいけないので結構面倒です。 テナンシーやプレイスメントグループを利用していなければそのままでOKです。 今回は、試しに「t3.nano」「Linux/UNIX」「ap-northeast-3a(大阪リージョン)」で「1台」としてみます。 予約の詳細 「手動」 にすると、キャパシティ予約をキャンセルしない限りはずっと予約が維持されます。 「特定の時間」 にすると、未来の日時を設定しておけば、そのタイミングで自動で予約がキャンセルされます。 また、インスタンスの利用資格に関して、「一致する詳細を持つ任意のインスタンス」 を選択すると、「インスタンスの詳細」で設定したインスタイプ・OS・AZのEC2を起動した場合、自動的にキャパシティ予約の内数としてカウントされます。 「この予約を指定するインスタンスのみを受け入れます。」 を選択すると、EC2を起動する際に、明示的に予約リソースグループのARNを指定する必要があります。 今回は「手動」、「一致する詳細を持つ任意のインスタンス」としてみます。 このまま 「作成」 を押すと確認画面が出てきますので、「確認」 を押すとキャパシティ予約完了です。 キャパシティ予約の確認 上記のように予約ができました。 利用可能が1インスタンスとなっています。 EC2の起動 ここで該当するインスタンスタイプ・OS・AZでEC2を起動してみます。 キャパシティ予約の画面から 「インスタンスの起動」 をクリックしてウィザードを進めます。 そして起動しようとしたらエラー画面が出ました。 どうやら、t3.nanoを予約したのに、t2.microを起動しようとしてしまったみたいです。 このように、パラメータを間違えると起動できないようにしてくれます。 インスタンスタイプを修正したところ無事起動しました。 起動後のキャパシティ予約の画面は以下のとおりです。 ちゃんと起動が1インスタンスとなり、利用可能は0インスタンスに減っています。 予約のキャンセル キャパシティ予約をしたままだと料金がかかってしまうので不要であればキャンセルしましょう。 「予約をキャンセル」 をクリックします。 確認画面が出ますので 「予約をキャンセル」 をクリックします。 これでキャパシティ予約が解放され、料金がかからない状態にできます。 さいごに 今回はマネージメントコンソールからEC2のオンデマンドキャパシティ予約をする手順を紹介しました。 AWS CLIから実施する手順はこちらに載ってますのでチェックしてみてください。

はじめに AWSはクラウドなので、使いたいときに使いたいだけのリソースを使用できます。 とはいえ、AWSも物理リソースには限界があります。いざEC2を起動したいと思ったときに、キャパシティ不足で起動できないという可能性があるわけです。 そんなリスクに備える手段が 「オンデマンドキャパシティ予約」 になります。 これをあらかじめ行っておけば、リソース不足でEC2が起動できないといったリスクを回避することができます。 ただ、キャパシティを予約しておくということは、その分のリソースを確保しておくことなので、当然ながらお金がかかります。費用はEC2をオンデマンドで起動しておくのと同等の金額です。 EC2を起動していなくても料金はかかってしまうので、その点がデメリットです。 今回はスクリーンショットとともに、オンデマンドキャパシティ予約に実施方法を記します。 なお、AWS公式ページはこちらにあります キャパシティ予約の実施手順 まずはマネージメントコンソールにログインし、該当リージョンのEC2のページを開きます。 ここで 「キャパシティの予約」＞「キャパシティ予約の作成」 をクリックします。 インスタンスの詳細 以下を選択します インスタンスタイプ プラットフォーム(OS) アベイラビリティーゾーン(AZ) テナンシー プレイスメントグループ 数量 インスタンスタイプ、OS、AZなどが多様だと、それごとに設定しなくちゃいけないので結構面倒です。 テナンシーやプレイスメントグループを利用していなければそのままでOKです。 今回は、試しに「t3.nano」「Linux/UNIX」「ap-northeast-3a(大阪リージョン)」で「1台」としてみます。 予約の詳細 「手動」 にすると、キャパシティ予約をキャンセルしない限りはずっと予約が維持されます。 「特定の時間」 にすると、未来の日時を設定しておけば、そのタイミングで自動で予約がキャンセルされます。 また、インスタンスの利用資格に関して、「一致する詳細を持つ任意のインスタンス」 を選択すると、「インスタンスの詳細」で設定したインスタイプ・OS・AZのEC2を起動した場合、自動的にキャパシティ予約の内数としてカウントされます。 「この予約を指定するインスタンスのみを受け入れます。」 を選択すると、EC2を起動する際に、明示的に予約リソースグループのARNを指定する必要があります。 今回は「手動」、「一致する詳細を持つ任意のインスタンス」としてみます。 このまま 「作成」 を押すと確認画面が出てきますので、「確認」 を押すとキャパシティ予約完了です。 キャパシティ予約の確認 上記のように予約ができました。 利用可能が1インスタンスとなっています。 EC2の起動 ここで該当するインスタンスタイプ・OS・AZでEC2を起動してみます。 キャパシティ予約の画面から 「インスタンスの起動」 をクリックしてウィザードを進めます。 そして起動しようとしたらエラー画面が出ました。 どうやら、t3.nanoを予約したのに、t2.microを起動しようとしてしまったみたいです。 このように、パラメータを間違えると起動できないようにしてくれます。 インスタンスタイプを修正したところ無事起動しました。 起動後のキャパシティ予約の画面は以下のとおりです。 ちゃんと起動が1インスタンスとなり、利用可能は0インスタンスに減っています。 予約のキャンセル キャパシティ予約をしたままだと料金がかかってしまうので不要であればキャンセルしましょう。 「予約をキャンセル」 をクリックします。 確認画面が出ますので 「予約をキャンセル」 をクリックします。 これでキャパシティ予約が解放され、料金がかからない状態にできます。 さいごに 今回はマネージメントコンソールからEC2のオンデマンドキャパシティ予約をする手順を紹介しました。 AWS CLIから実施する手順はこちらに載ってますのでチェックしてみてください。

背景 Lambdaを使って日付ごとにデータをスクレイピングすることがあった。 大量のデータであったが、繰り返し文で日付を変えながら行うプログラムとしていたため、非常に時間がかかった。 そこで、①実行指示Lambdaと②スクレイピングLambdaに分けてプログラムを作成し、①にて変数を入れ替えながら②に指示するような構成にすることで、Lambdaの同時実行が可能になったので、備忘録として記載する。 参考記事については複数層に分けて大量のLambda実行を可能としているが、今回はわかりやすさ優先で、（親）と（子）の2層構造でLambdaを同時実行してみる。 イメージ 親Lambda parent import json import io client = boto3.client('lambda') date_list = ['2022/01','2022/02','2022/03','2022/04'] category_list = ['setosa','versicolor','virginica','other'] def lambda_handler(event, context): # 子Lambda の呼び出し for i in range(len(date_list)): response = client.invoke( FunctionName='children',#Lambdaで記載している関数名を記載 InvocationType='Event', Payload=json.dumps({'DATE': date_list[i] ,'CATEGORY': category_list[i] }) ) 上記のように、親Lambda内で子Lambdaを呼び出している。for文でdate_listの数（4回）だけ呼び出しをするように指示している。 子Lambda children import json from selenium import webdriver from selenium.webdriver.support.ui import WebDriverWait def lambda_handler(event, context): date = str(event.get('DATE')) category = str(event.get('CATEGORY')) driver = headless_chrome() wait = WebDriverWait(driver, 30) driver.get("http://〇〇…") ・・・ 親Lambdaで呼び出された子Lambdaは、event.getで親Lambdaから渡された変数を読み込むことができる。 終わりに 上記は基本形の形であるが、参考記事のように複数層で呼び出しー呼び出され構成にすることで、並列処理チックな構成を組むことが可能。 大量データのスクレイピングだけではなく、大量データの集計・解析作業の高速化につながることを期待。 参考記事

課題 Amplify CLIではAuthなどのCFnテンプレートを上書きするためのファイルとして、override.tsが提供されています。このoverride.tsはaws-cdk内の一部のメソッドのみを利用できるようになっています。 本来、getProjectInfo()でAmplifyのプロジェクトの詳細を取得することができるのですが、2022/2/28現在このメソッドはアクセス権限に関する以下のエラーが発生するため利用できません。 ⠇ Building resource storage/MyStorage? Error: Skipping override due to VMError: Access denied to require 'os' override.ts内で環境名を取得する必要がある場合、上記メソッドを使わずに取得する方法をご紹介します。 解決策 ※注意 本記事で紹介する解決策は邪道です。issue(https://github.com/aws-amplify/amplify-cli/issues/9063 )が対応され次第修正した方が良いです。 Amplify CLIではプロジェクトの環境等のメタ情報をamplify/backend/amplify-meta.jsonにて保持しています。このファイルはamplify env checkout ...などのコマンドで環境が変更された際、amplify/team-provider-info.jsonの情報を元に構築されるものです。今回はここから環境名を取得します。 手順１:amplify-meta.jsonのモジュール化 amplify-meta.jsonをモジュールとしてシンボリックリンクを貼ります。ファイルを直接読みにいくことも可能のようですが、私の環境ではエラーが発生し読み込めなかったためこの手順を踏んでいます cd amplify/backend yarn add link:./amplify-meta.json 手順2:override内でStackNameの取得 amplify-meta.jsonのStackNameを取得します。StackNameはamplify-[プロジェクト名]-[環境名]-[プロジェクト番号]で構成されているため、文字列を分解すれば環境名を取得することができます。 override.ts export function override(resources: AmplifyAuthCognitoStackTemplate) { const amplify_meta_json = require('amplify-meta.json') const env_name = amplify_meta_json.providers.awscloudformation.StackName.split("-").slice(-2, -1).pop() //省略 } まとめ override.ts内で環境名を取得する機会は多いと思われるので、誰かの参考になれば幸いです。 また、この対応はissue内のcespin氏を参考にしております。この場を借りてお礼申し上げます。 参考 不具合のissue Override Amplify-generated Cognito resources(公式Doc)

terraform入門 terraformチュートリアル（AWS） tfenvインストール brew install tfenv tfenv --version > tfenv 2.2.2 # 使用可能なバージョン一覧 tfenv list-remote # 指定バージョンインストール tfenv install 1.1.5 # 使用バージョン指定 tfenv use 1.1.5 # 現在インストールされているバージョン tfenv list > * 1.1.5 (set by /usr/local/Cellar/tfenv/2.2.2/version) terraform -v > Terraform v1.1.5 > on darwin_amd64 required_providersについて required_providersのバージョンは公式のレジストリから確認すると良い https://registry.terraform.io/providers/hashicorp/aws version = ">= 1.0"は最小バージョン指定。1.0以上 version = "~> 3.27"はパッチバージョンのみ許可。3.27.0以上、3.28.0未満 terraform { required_version = ">= 1.1.5" required_providers { aws = { source = "hashicorp/aws" version = "~> 3.27" } } } provider "aws" { profile = "dev-user" region = "ap-northeast-1" } tfstateファイルをS3で共有管理するためバケット作成 参考 https://qiita.com/mintak21/items/ecc8d568c2859210c0c4 ECRにイメージプッシュ 参考 https://docs.aws.amazon.com/ja_jp/AmazonECR/latest/userguide/getting-started-cli.html # ecrログイン aws ecr get-login-password --region ap-northeast-1 | docker login --username AWS --password-stdin xxxxxxxxxx.dkr.ecr.ap-northeast-1.amazonaws.com # リポジトリ作成 aws ecr create-repository \ --repository-name y-oka/nginx \ --image-scanning-configuration scanOnPush=true \ --region ap-northeast-1 # タグ作成＆push docker pull nginx:latest docker tag nginx:latest xxxxxxxxxx.dkr.ecr.ap-northeast-1.amazonaws.com/y-oka/nginx:latest docker push xxxxxxxxxx.dkr.ecr.ap-northeast-1.amazonaws.com/y-oka/nginx:latest terraformを触ってみてのQ&A Q1. 違うユーザーでソース（tfファイル）を更新、applyしたらインフラはどうなる？ A1. 追加で同じインフラが作成される。複数のユーザーでインフラを管理したい場合はtfstateファイルを共有する必要がある Q2. destroyを使わず特定のインフラを削除したい場合、たとえばドメインをtfファイルから削除したら、そのドメインも消える？ A2. tfstateファイルとtfファイルとの差分で削除される。tfstateファイルで管理されていない場合は削除されない。 Q3. tfファイルのリソース名を変更しても、インフラに影響ない？ A3. 影響ある。リソース名を変更してしまうと、削除→新規作成されてしまう。planで確認する Q4. tfファイルのリソース内のパラメータを変更しても、インフラへの影響は最小限で済む？ A4. 分からない。planで確認する Q5. tfファイルとtfstateファイルに差分がある状態でdestroyした場合どうなる？ A5. tfstateに存在するインフラが削除される。 Q6. 既存のインフラをterraformで管理したい場合はどうする？ A6. importコマンドで1つ1つ、tfファイルとtfstateファイルに取り込んでいく必要がある。はじめて管理する場合は「Terraformer」というツールでまとめてインポートしてから修正していくと良さそう。

[前回] AWS公式資料で挑むSCS認定(8)-VPC(続き) はじめに IAMとVPCについて、なんとか攻略できました(復習・実習はTODO)。 今回のKMS(AWS Key Management Service)は、 AWSサービス全般の認証・認可・データ暗号化などで使用される暗号キーを、 作成のみならず、一元管理・表示および監査機能まで備わっているようです(すごい)。 勉強に使用する教材 恒例となりますが、公式資料から3点選びました。 AWS KMS の暗号化の詳細 [AWS Black Belt Online Seminar] AWS Key Management Service AWS Key Management Service デベロッパーガイド KMSのアーキテクチャ KMS は、ウェブとの接点である「KMS host」と、階層化された「HSM」で構成された階層型サービスとなっているとのこと。 まず、アーキテクチャの登場人物を見てみましょう。 KMS interface 暗号化キーを生成および管理するためのウェブインターフェース データを保護するための暗号化サービスプロバイダーとして機能 KMS host KMS interfaceからの暗号化リクエストを受け取って処理する HSM HSMはハードウェアセキュリティモジュール HSM 分散フリート(フリートってなんだ?)に対する暗号化操作は FIPS 140-2 規格検証済み(規格要件満たせるので安心して使える) AWS KMS HSMは、KMS のセキュリティおよびスケーラビリティ要件を満たす専用の暗号化機能を提供するように設計されたマルチチップのスタンドアロンハードウェア暗号化アプライアンス KMS キー HSM 上でのみ使用でき、暗号化リクエストの処理に必要な時間だけメモリ内に存在(ずっとメモリに存在したら窃取されるリスク) 複数の KMS キーを作成でき、各キーはキー ID で表される ユーザーのAWS IAM ロールとアカウントからのみ、ユーザーのKMS キーを作成、削除でき、データの暗号化、復号化、署名、検証に使用できる ポリシーを作成し KMS キーにアタッチすることで、KMS キーの管理・使用に関するアクセス制御を行う KMSの用語と概念 KMSの理解に役立つ、基本的な用語と概念。 KMS キー キー階層の最上位を表す論理キー KMS キーには、一意のキー ID を含む Amazon リソースネーム (ARN) が与えられる KMS キーの3 つのタイプ カスタマーマネージド型キー ユーザーが、作成、ライフサイクルとキーポリシーの管理を行う(キーへのリクエストは CloudTrail イベントとして記録される) AWS マネージドキー AWS が、作成、ライフサイクルとキーポリシーの管理を行う(ユーザーの AWS アカウント のリソースなので、ユーザーはそのアクセスポリシーと CloudTrail イベントを確認できるが、管理はできない) AWS 所有のキー AWS が、作成、さまざまな AWS サービスで内部の暗号化オペレーションに使用(ユーザーは、キーポリシーや CloudTrail からその使用状況を確認できない) エイリアス KMS キーに関連付けられている別名 多くの KMS API 操作でキー ID と同じように使用できる アクセス許可(Permission) キーに対するアクセス許可を定義するポリシー KMS キーにアタッチされる デフォルトのポリシー ユーザーが定義するすべてのプリンシパルが許可される AWS アカウントのルートユーザーにより、キーを参照する IAM ポリシーの追加も許可される 許可(Grant) KMS キーを使用するため委任されるアクセス許可 初期段階でIAM プリンシパル(KMSキーの使用者)またはキーの使用期間が決まっておらず、IAM ポリシーにアクセス許可を追加できない場合に使用 許可の使用方法 AWS サービスにKMS キーを使用する限定されたアクセス許可を与えたい場合(署名されたダイレクト API コールを経由せず、AWS サービスがユーザーに代わり暗号化されたデータに対して非同期作業を行う際) データキー HSM で生成され、KMS キーによって保護される暗号化キー 許可されたエンティティは、プレーンテキスト(暗号化されていない)のデータキーと暗号化されたデータキーを取得できる データキーは、対称キーまたは非対称キー 暗号文 KMS の暗号化された出力、ユーザーの暗号文と呼ばれることもある 暗号文には、復号化プロセスで使用するための KMS キーを識別する追加情報を含む データキーは暗号文の例の1つ サイズが4 KB未満のデータは、KMSキーにより暗号化され暗号文を生成可能 暗号化コンテキスト KMS で保護されている情報に関連付けられた、追加情報のキーと値のペアマップ KMS では、データキーの保護に認証済みの暗号化が使用される 暗号化コンテキストは、KMS で暗号化された暗号文で、認証済みの暗号化の AAD に組み込まれる KMSで保護された情報に関連付けられている追加情報で、キーと値のペアマップ KMSは、認証済み暗号を使用してデータキーを保護するが、暗号化コンテキストは、暗号文の認証済み暗号のAAD(認証済み追加データ)に組み込まれている 認証済み追加データ(AAD)は、復号プロセス中に機密性と信頼性が保証される追加データ 暗号化コンテキスト情報はオプショナルで、キー(または暗号化操作)のリクエスト時は返されない。 公開キー 非対称暗号 (RSA または楕円曲線) を使用する場合、公開/秘密キーペアにおける公開キー 公開/秘密キーペアの所有者のデータを暗号化する必要のあるエンティティに、公開キーが共有される デジタル署名では、公開キーを使用して署名を検証する 秘密キー 非対称暗号 (RSA または楕円曲線) を使用する場合、公開/秘密キーペアにおける秘密キー 秘密キーは、データの復号またはデジタル署名の作成に使用される 秘密キーは HSM で暗号化される(対称 KMS キー同様) KMSの設計目標 KMS は下記要件を満たすように設計されているようです。 耐久性 暗号化キーの耐久性は、AWS で最高の耐久性を持つサービスと同等に設計されている 1 つの暗号化キーで、長期間にわたって蓄積された大量のデータを暗号化できる 信頼性 キーの使用は、ユーザーが定義および管理するアクセス制御ポリシーによって保護される プレーンテキストの KMS キーをエクスポートするメカニズムは存在しない(あったら逆に怖い) 低レイテンシーと高スループット KMS には、他のAWSサービスからの使用に適した、レイテンシーとスループットを兼ね備えた暗号化オペレーションが用意されている リージョンの独立性 異なるリージョンでデータアクセスを制限する必要があるお客様向けに、リージョンの独立性を確保している キーの使用は AWS リージョン 内に限定できる 元になる乱数の安全性 強力な暗号は予測不可能な乱数生成に依存する KMS には高品質で検証済みの乱数のソースが用意されている 監査 暗号化キーの使用と管理は CloudTrail ログに記録される CloudTrail ログを使用して、AWS のサービスによる暗号化キーの使用状況を調べることができる これらの目標を達成するため、KMS システムには、「ドメイン」を管理する一連の KMS オペレーターとサービスホストオペレーター (総称して「オペレーター」) が含まれている。 ドメインとは、リージョンに定義された KMS サーバー、HSM、およびオペレーターのセット 各 KMS オペレーターは、アクションの認証に使用される公開キー秘密キーペアを含むハードウェアトークンを持っている HSMには、HSM状態の同期を保護する暗号化キーを確立するための、追加の公開/秘密キーペアがある 暗号化の基本 KMS の暗号化アルゴリズムのデフォルトセットは、安全性とパフォーマンスのため、連邦情報処理標準(FIPS)のアルゴリズムから選択されている。 なお、暗号化アルゴリズムは設定可能とのこと。 エンベロープ(Envelope)と乱数生成 KMS キー生成は、HSM で実行される HSM では、AES-256 を使った NIST SP800-90A 決定論的ランダムビットジェネレーター (DRBG) CTR_DRBG を使用したハイブリッド乱数生成機能を実装 非決定論的ランダムビットジェネレーターは 384 ビットのエントロピーでシードされ、追加のエントロピーで更新される 対称キーのオペレーション(暗号化のみ) HSM 内で使用されるすべての対称キーの暗号化コマンドに、高度暗号化規格 (AES) で 256 ビットキーの Galois Counter Mode (GCM) を使用 復号の際は逆関数を使用 AES-GCM は認証済み暗号化スキームで、プレーンテキストの暗号化による暗号文の生成に加え、暗号文と認証が必要な追加データ(AAD)に対する認証タグを計算 非対称キーのオペレーション(暗号化、デジタル署名、署名の検証) 暗号化およびデジタル署名のオペレーションの両方で非対称キーオペレーションの使用をサポート 非対称キーのオペレーションは、数学的に関連する公開/秘密キーペアに依存 キーペアは、「暗号化および復号化」または「署名およびその検証」に使用できるが、両方には使用できない KMS で秘密キーは必ず暗号化された状態で存在する KMS API を用いて、KMS 内で公開キーを使用することも、公開キーをダウンロードし KMS の外部で使用することもできる KMS では、2 種類の非対称暗号がサポートされる RSA-OAEP(暗号化用) および RSA-PSS/RSA-PKCS-#1-v1_5(署名および検証用) 楕円曲線(ECC): 署名と検証にのみ使用できる キー導出関数 最初のシークレットまたはキーから追加のキーを取得するために使用される KMS では、キー導出関数 (KDF) を使用して、KMS キーを使った暗号化コールごとにキーを取得 すべての KDF オペレーションでは、SHA256 [FIPS180] で HMAC [FIPS197]を用いたカウンタモードの KDF を使用 256 ビットの導出キーは AES-GCM とともに、暗号化または復号に使用される KMS 内部でデジタル署名の使用 デジタル署名は、KMS エンティティ間のコマンドや通信を認証するためにも使用される すべてのサービスエンティティには、楕円曲線デジタル署名アルゴリズム (ECDSA) のキーペアがある エンベロープ暗号化(Envelope Encryption) 多くの暗号化システムで使用されている基本的な構造 2つ以上の暗号化キーを使用してメッセージを保護 長期的な静的キー メッセージの暗号化のために生成されるメッセージごとのキー エンベロープは、メッセージの暗号化により生成される KMS では、長期的な静的キーを管理し、データをエンベロープ暗号化するプロセスを自動化する機能を提供 AWS Encryption SDK では、KMS サービス内で提供される暗号化機能に加え、クライアント側のエンベロープ暗号化ライブラリを提供することで、データとその暗号化に使用している暗号化キーを保護 KMSのユースケース KMSを最大限に活用するために役立つユースケースです。 実際の運用に必要な内容ですので、しっかりマスターしたいです。 Amazon EBS ボリュームの暗号化 各ボリュームは AES-256-XTS を使用して暗号化され、2つの 256 ビットボリュームキーが必要(1 つの 512 ビットボリュームキーと考えられる) ボリュームキーは、アカウントの KMS キーで暗号化される Amazon EBS でボリュームを暗号化するには、アカウントの KMS キーの下にボリュームキー (VK) を生成するためのアクセス権が必要 データキーを作成しボリュームキーを暗号化および復号化するため、Amazon EBS に KMS キーへのアクセス権を付与 Amazon EBS は、KMS キーを用いて暗号化されたボリュームキーを生成 クライアント側の暗号化 AWS Encryption SDK の API 操作により、KMS キーを使ったエンベロープ暗号化を実行 クライアントアプリケーションは、AWS Encryption SDK を使って、KMS を用いたエンベロープ暗号化を実行 おわりに 今回はKMSのアーキテクチャ、用語、概念を勉強しました。 暗号化の基本やKMSのユースケースも少しかじりました。 次回はKMSのユースケースを軸に、重要事項を深掘りします。 お楽しみに。

目次 Basic認証 DNS連携freenom SSL化 Basic認証 Basic認証とは、サイト閲覧の際にパスワードなどでアクセス制限をかけること。 主に開発段階のサイトや開発用に使用するサイトにて、関係者以外閲覧させないようにする際に使用されることが多い。 触るファイルは3つ .htaccess →サイトにアクセスしてきた来訪者を別ページに誘導したり、認証をかけたりできるファイル。 .htpasswd →認証におけるユーザー名とパスワードを設定するファイル。 wordpress-https-vhosts.conf →apache(webサーバー)の設定ファイル。vhostsはヴァーチャルホストの意味らしい。 /opt/bitnami/wordpress/.htaccess <Files ~ "^\.(htaccess|htpasswd)$"> deny from all </Files> Options -Indexes AuthUserFile /opt/bitnami/wordpress/.htpasswd AuthGroupFile /dev/null AuthName "Please enter your ID and password" AuthType Basic require valid-user order deny,allow すでにファイルがある場合、以上のものを追記する。 /opt/bitnami/wordpress/.htpasswd # あくまでサンプルです。「ユーザー名:暗号化されたパスワード」の並びです。 test:$apr1$Ef4D6g1suPHnnnoiCt. .htpasswdはhtpasswdコマンドを打ち込んで、作成する。 htpasswd -c /opt/bitnami/wordpress/.htpasswd ユーザー名 -cはユーザーとパスワードが書かれたファイルを新規作成/上書きするという意味。上書きされたくなければ -c を取って、ファイル名を指定することが必要。 /opt/bitnami/apache2/conf/vhosts/wordpress-https-vhost.conf #省略 <Directory "/opt/bitnami/wordpress"> Options -Indexes +FollowSymLinks -MultiViews AllowOverride None Require all granted # BEGIN WordPress fix for plugins and themes # Certain WordPress plugins and themes do not properly link to PHP files because of sy mbolic links # https://github.com/bitnami/bitnami-docker-wordpress-nginx/issues/43 RewriteEngine On #省略 AllowOverrideの項目にNoneが設定されています。 NoneをAllに書き換え、AllowOverrideディレクティブ(指示文)の設定を許可するようにします。 これは<Directory "/opt/bitnami/wordpress">が示すように、指定されたディレクトリの設定を許可するか否かを決める役割を担っています。 /opt/bitnami/wordpressの設定を許可するということは、その中に存在する.heaccessファイルを読み込むことになるため、Basic認証が許可されることとなります。 以上の3つのファイルを設定すればBasic認証の設定は以上です。 その後、webサーバーであるapacheを再起動しサイトに認証がかかっているか確認してみましょう。 # apacheの再起動 sudo /opt/bitnami/ctlscript.sh restart apache dns連携freenom DNS、いわゆるドメインですね。http://example.com みたいなやつ。 元々、サーバーはIPアドレスと言う固有の数字が与えられています。例)http://123.45.22 人間がわかりやすいようにIPアドレスにドメインを紐付けることにより、123.45.22にアクセスした時と、example.comにアクセスしたときどちらも同じ挙動をするようになります。 そのドメインの紐付けを行います。 freenomの場合： freenomは無料でドメインを取得できるサービスです。.comや.jpではなく、.tkや.mlなどが利用できます。 ドメインは好きな名前にしてもらえれば大丈夫ですが、 .tkや.mlなど最後まで指定を行うと取得することができます。 ドメイン取得後はメニューのServisesからMyDomainsを選択し、取得したドメインを確認していきます。 取得した、ドメインをlightsailに紐づけていきます。 Network欄のDNSゾーンの作成から、登録済みドメインの入力をしていきます。 この時、http://は不要です。 作成できたらレコードの追加をしていきます(ここが本番) record名 subdomain入力 A record @ CNAME record www resolves toには、staticIPを入力します。 これによりstaticIPで固定された、IPアドレスとの連携ができます。 その下のName serversと書いてある場所に、4つほど情報が書いてあります。 その情報をfreenomのManagementTools->NameServerの欄に入力しDNSサーバーと連携します。 これにより、取得したドメインでのアクセスが可能になります。 もちろんstaticIP　アドレスもしくはドメイン、どちらでもアクセスすることは可能です。 ※若干反映に時間がかかるかもしれません。 自分は10分待てば、アクセスできました。 こういったドメインの紐付けには、最大48時間かかることもあるようです。 SSL化 Amazonが公式に「Amazon LightSailのBitnamiスタックにSSL証明書をインストールする」という記事を出しています。 こちらを参考にしました。 やったこととしては、 sudo /opt/bitnami/bncert-tool を実行 domain list [] が出ると、ドメインとwwwつきドメインを入力 例)test.tk www.test.tk #それぞれ出てきた項目には以下のように答える Enable HTTP to HTTPS redirection y Enable non-www to www refirectin n Enable www to non-www redirection n Do you agree to these changes y e-mail address #自分のメールアドレスを入力してね Do you agree to the let's Encrypt Subscriber Agreement y press [enter] to continue エラーが出たら、もう一度sudo /opt/bitnami/bncert-toolを実行してみるといいかもしれません。 うまく設定できていればSSL化の90日間期限も自動的に更新してくれるみたいです。 またこれはあくまで一例であり、WordPressのSSL化は他にも方法があるそうです。今回は、LightSailにおいての方法を公式に乗っ取ってやってみました。

AWS CloudFormationで独自ドメインホスティング環境構築を自動化してみました 以前の記事内容をAWS CloudFormationで実現する方法をためしてみました！ 今回の作成したテンプレートをGitHubで公開したのでぜひご利用ください！ certificate-create.yml AWSTemplateFormatVersion: 2010-09-09 # テンプレート概要 Description: Certificate creation # パラメータ Parameters: # ドメイン名入力 DomainName: Description: Domain Name Type: String # ホストゾーンID入力 HostedZoneId: Description: Host Zone ID Type: String # リソース Resources: # Certificate Manager設定 CertificateManagerCertificate: # リソースタイプ Type: AWS::CertificateManager::Certificate # プロパティ Properties: # ドメイン指定 DomainName: !Sub ${DomainName} # 検証ドメイン設定 DomainValidationOptions: - # ドメイン指定 DomainName: !Sub ${DomainName} # ホストゾーンID指定 HostedZoneId: !Sub ${HostedZoneId} # 検証方法指定 ValidationMethod: DNS hosting.yml AWSTemplateFormatVersion: 2010-09-09 # テンプレート概要 Description: Build a Unique Domain Hosting Environment with Amazon Route 53, Amazon CloudFront, and Amazon S3 # パラメータ Parameters: # ドメイン名入力 DomainName: Description: Domain Name Type: String # ホストゾーンID入力 HostedZoneId: Description: Host Zone ID Type: String # 証明書ID入力 CertificateId: Description: Certificate ID Type: String # リソース Resources: # S3バケット設定 S3Bucket: # リソースタイプ Type: AWS::S3::Bucket # プロパティ Properties: # バケット名指定 BucketName: !Sub ${AWS::StackName}-${AWS::Region}-${AWS::AccountId} # S3バケットポリシー設定 S3BucketPolicy: # リソースタイプ Type: AWS::S3::BucketPolicy # 処理順設定 DependsOn: - CloudFrontOriginAccessIdentity # プロパティ Properties: # S3バケット指定 Bucket: !Sub ${S3Bucket} # CloudFront用バケットポリシー指定 PolicyDocument: Statement: - Sid: PolicyForCloudFrontPrivateContent Effect: Allow Principal: AWS: !Sub arn:aws:iam::cloudfront:user/CloudFront Origin Access Identity ${CloudFrontOriginAccessIdentity} Action: s3:GetObject Resource: !Sub arn:aws:s3:::${S3Bucket}/* # CloudFrontOAI設定 CloudFrontOriginAccessIdentity: # リソースタイプ Type: AWS::CloudFront::CloudFrontOriginAccessIdentity # プロパティ Properties: CloudFrontOriginAccessIdentityConfig: Comment: Unique Domain Hosting Environment # CloudFront設定 CloudFrontDistribution: # リソースタイプ Type: AWS::CloudFront::Distribution # 処理順設定 DependsOn: - S3Bucket - CloudFrontOriginAccessIdentity # プロパティ Properties: DistributionConfig: # ドメイン指定 Aliases: - !Sub ${DomainName} Origins: - # S3ドメイン名指定 DomainName: !Sub ${S3Bucket}.s3.${AWS::Region}.amazonaws.com # オリジン名指定 Id: !Sub ${S3Bucket}.s3.${AWS::Region}.amazonaws.com # オリジンアクセスアイデンティティ指定 S3OriginConfig: OriginAccessIdentity: !Sub origin-access-identity/cloudfront/${CloudFrontOriginAccessIdentity} # キャッシュビヘイビア設定 DefaultCacheBehavior: # オリジンID指定 TargetOriginId: !Sub ${S3Bucket}.s3.${AWS::Region}.amazonaws.com # 自動圧縮有無指定 Compress: true # HTTPメソッド指定 AllowedMethods: - HEAD - GET CachedMethods: - HEAD - GET # ビューアプロトコルポリシー指定 ViewerProtocolPolicy: redirect-to-https # キャッシュポリシー指定 (CachingOptimized) CachePolicyId: 658327ea-f89d-4fab-a63d-7e88639e58f6 # SPA対応設定 CustomErrorResponses: - ErrorCode: 403 ResponsePagePath: /index.html ResponseCode: 200 ErrorCachingMinTTL: 0 - ErrorCode: 404 ResponsePagePath: /index.html ResponseCode: 200 ErrorCachingMinTTL: 0 # 料金クラス指定 PriceClass: PriceClass_All # ディストリビューション有効無効指定 Enabled: true # SSL証明書設定 ViewerCertificate: # 証明書ID指定 AcmCertificateArn: !Sub arn:aws:acm:us-east-1:${AWS::AccountId}:certificate/${CertificateId} # セキュリティポリシー指定 MinimumProtocolVersion: TLSv1.2_2021 SslSupportMethod: sni-only # 配信制限設定 Restrictions: GeoRestriction: # 地理的制限指定 RestrictionType: none # HTTPバージョン指定 HttpVersion: http2 # ルートURL指定 DefaultRootObject: index.html # IPv6有無指定 IPV6Enabled: true # Route53レコード設定 Route53RecordSet: # リソースタイプ Type: AWS::Route53::RecordSet # 処理順設定 DependsOn: - CloudFrontDistribution # プロパティ Properties: # ドメイン指定 Name: !Sub ${DomainName} # ホストゾーンID指定 HostedZoneId: !Sub ${HostedZoneId} # レコードタイプ指定 Type: A # エイリアスターゲット設定 AliasTarget: # CloudFrontドメイン指定 DNSName: !GetAtt CloudFrontDistribution.DomainName # ホストゾーンID指定 (固定) HostedZoneId: Z2FDTNDATAQYW2 事前準備 Amazon Route 53による独自ドメインの取得 対象の「ドメイン名」と「ホストゾーンID」をメモしておく 構築の流れ 指定リージョンでSSL証明書を自動デプロイ 任意リージョンで独自ドメインホスティング環境を自動デプロイ 指定リージョンでSSL証明書を自動デプロイ はじめに、指定リージョンでSSL証明書を自動デプロイします。SSL証明書をCloudFrontで利用するためには、リージョンを「us-east-1」で作成する必要があります。 リージョン「us-east-1」でCloudFormationにアクセス。スタック → スタックの作成 → 「新しいリソースを使用」をクリック。 前提条件は「テンプレートの準備完了」を選択。テンプレートの指定は「テンプレートファイルのアップロード」を選択しファイルをアップロード → 「次へ」をクリック。 CloudFormationテンプレートは「certificate-create.yml」を利用。 任意のスタック名・ドメイン名・ホストゾーンIDを設定 → 「次へ」をクリック。 スタックオプションは今回デフォルトで設定 → 「次へ」をクリック。 設定を確認 → 「スタックの作成」をクリック。 スタックが作成されたのを確認。 「us-east-1」リージョンのAWS Certificate Managerを確認すると、SSL証明書が自動作成されているのを確認できる。次のテンプレートで利用するため対象の「証明書ID」をメモ。 任意リージョンで独自ドメインホスティング環境を自動デプロイ 最後に、任意リージョンで独自ドメインホスティング環境を自動デプロイします。 デプロイしたいリージョンでCloudFormationにアクセス。 スタック → スタックの作成 → 「新しいリソースを使用」をクリック。 前提条件は「テンプレートの準備完了」を選択。テンプレートの指定は「テンプレートファイルのアップロード」を選択しファイルをアップロード → 「次へ」をクリック。 CloudFormationテンプレートは「hosting.yml」を利用。 任意のスタック名・証明書ID・ドメイン名・ホストゾーンIDを設定 → 「次へ」をクリック。 スタックオプションは今回デフォルトで設定 → 「次へ」をクリック。 設定を確認 → 「スタックの作成」をクリック。 スタックが作成されたのを確認。 Amazon CloudFrontに自動でデプロイされているのを確認します。 Amazon S3に自動でデプロイされているのを確認します。 デプロイされたS3バケットに公開したいファイル一式をアップロードします。 独自ドメインにアクセスするとアップロードしたWebSiteが表示されます。 AWS CloudFormationを利用することで、独自ドメインホスティング等のさまざまなリソース構築を自動化することが可能です 今後は、AWS CDK等で各サービス構成をどの範囲まで定義できるかも試していければと思います。 AWS CloudFormationについて、他にも記事を書いています。よろしければぜひ tags - AWS CloudFormation やってみたシリーズ tags - Try

はじめに AWSサービスクォータの管理、自動化してますか？ 前回の記事では、AWSサービスクォータの重要性と全サービスクォータを一覧化する方法を紹介しました。 今回は、AWSのサービスクォータの管理を自動化する意味とその方法を解説します。 合わせて、クォータ管理を自動化するCloudFormationテンプレートのサンプルも紹介します。 前回のおさらい 前回の記事では、 サービスクォータを意識しないと信頼性が低下してしまう可能性がある サービスクォータを意識しよう、という話は AWS Well-Architected Framework にも書かれている サービスクォータは信頼性に影響するので 「信頼性の柱」 として定義されている という話を書きました。 今回は、この中の クォータをモニタリングおよび管理する クォータ管理を自動化する の話です。 なぜ、クォータ管理の自動化が必要なのか？ 自動化したほうが楽だからです。（キリッ） これ以上の説明は不要な気もしますが、説明していきましょう。 以下は前回の記事の引用です。 例えば、Aさんが API Gateway - Lambda - DynamoDB を用いてサーバーレスなAPIサービスを作ったとしましょう。 Aさんは「Lambdaは自動でスケーリングしてくれるから利用者が増えても大丈夫」と考えています。 このAPIサービスは好評を博し、順調に利用者が増えていきました。 すると、ある日突然、このAPIでエラーが頻発するようになりました。 なぜでしょう？ 原因は、利用者増加に伴い、Lambdaの同時実行数が増え、同時実行数が「1,000」を超えた＝Lambdaのサービスクォータに引っ掛かってしまったためでした。 問題 Q. Aさんはどうするべきだったのでしょうか？ 毎日、Lambdaの同時実行数を確認し、「800」を超過していたら、手動でクォータの引き上げをリクエストする。 Lambdaの同時実行数が「800」を超過したタイミングで CloudWatch Alarm と SNS (Simple Notification Service) を用いて、メールで通知する。メールを受信した後、手動でクォータの引き上げをリクエストする。 Lambdaの同時実行数が「800」を超過したタイミングで CloudWatch Alarm と SNS (Simple Notification Service) を用いて、別のLambdaを実行する。別のLambdaはAWS SDKを用いて自動的にクォータの引き上げをリクエストする。 ※ 選択肢中の「800」は、クォータ上限に到達するまでに十分な余裕のある数値を意図しており、状況に応じて変動する値（パラメータ）と捉えてください。 解説 選択肢をひとつずつ見ていきましょう。 選択肢1 毎日、Lambdaの同時実行数を確認し、「800」を超過していたら、手動でクォータの引き上げをリクエストする。 これは明らかに間違いです。毎日、人が確認するのはつらいですね。。 また、確認するタイミングによっては既に「1,000」を超えてしまっている可能性もあります。 選択肢2 Lambdaの同時実行数が「800」を超過したタイミングで CloudWatch Alarm と SNS (Simple Notification Service) を用いて、メールで通知する。メールを受信した後、手動でクォータの引き上げをリクエストする。 この選択肢は、クォータ上限である「1,000」に近づいてきたらメールで通知して対応しよう、という案です。 クォータ上限に達する前に対応することができるので悪くなさそうです。 ただし、クォータの引き上げリクエストは手動です。 選択肢3 Lambdaの同時実行数が「800」を超過したタイミングで CloudWatch Alarm と SNS (Simple Notification Service) を用いて、別のLambdaを実行する。別のLambdaはAWS SDKを用いて自動的にクォータの引き上げをリクエストする。 この選択肢は、クォータ上限である「1,000」に近づいてきたらLambdaを使って自動的にクォータを引き上げよう、という案です。 クォータ上限に達する前に対応することができるうえに、クォータ引き上げリクエストまで自動化されています。 というわけで正解は選択肢3です！ 本当にそうでしょうか！？ 落ち着いてもう一度考えてみましょう。 本当に選択肢3が唯一無二の正解なのでしょうか？ 選択肢3は人の手を介さずにクォータ引き上げリクエストまで自動化されています。 しかし、これは裏を返せば、事前に設定した条件さえ満たせば、人の判断を介さずに実行されるということを意味します。 ※ ここでは、事前に設定した条件＝Lambdaの同時実行数が「800」を超過、です。 このAPIサービスの利用者が順調に増えていった結果として、Lambdaの同時実行数が「800」を超過したのであれば、問題はないでしょう。 しかし、例えば、このAPIサービスがDDoS攻撃を受けていたとしたらどうでしょう？1 または、このサービスの開発者が誤って負荷テスト用のテストツールを動かし続けていたとしたらどうでしょう？ そう考えると、必ずしも、選択肢3が正解とは言えないのではないでしょうか。 通知を受けた人が状況に応じてクォータの引き上げを判断できる選択肢2の方が好ましい場合もあります。 結局、どれが正解なの？ ケースバイケースです。 何を優先するかは、所属する組織やプロジェクトによって異なるはずなので、画一的に決めつけず、状況に応じて判断することをおすすめします。 また、今回は、Lambdaの同時実行数のクォータを例にしましたが、対象とするクォータによってもどちらを採用すべきかは異なってきます。 あえて言うなら 自動で上限を引き上げることによるリスクがあるクォータであれば、選択肢2 自動で上限を引き上げることによるリスクがないクォータであれば、選択肢3 が正解です。 必ずしもクォータの引き上げまで自動化するのが正解とは限らない。 通知までを自動化し、クォータの引き上げは人が判断すべき場合もある。 どのようにクォータ管理を自動化するか？ ここからは実装方法を解説していきます。 なお、モニタリング対象のクォータは引き続き「Lambdaの同時実行数」としています。 別のクォータを対象としたい場合は適宜読み替えてください。 パターン1：クォータのモニタリングと通知 アラーム通知を受けて、人が判断して手動でクォータ引き上げをリクエストするパターンです。 パターン2：クォータ引き上げの自動化 アラーム通知を受けて、Lambdaが自動的にクォータ引き上げをリクエストするパターンです。 LambdaがAWS SDK (request_service_quota_increase) を用いてクォータ引き上げをリクエストします。 パターン3：パターン1＋パターン2 パターン1とパターン2の合わせ技です。 自動的にクォータ引き上げをリクエスト、かつ、メール通知もするパターンです。 CloudFormationテンプレート パターン1とパターン2を包括するパターン3のテンプレートを載せておきます。 CloudFormationパラメータ ThresholdConcurrentExecutions Lambdaの同時実行数がこの値を超えるとクォータ引き上げをリクエストする閾値 NotificationEmail 通知先メールアドレス quota_automation.yaml #=============================================================================== # CloudFormation Template #=============================================================================== AWSTemplateFormatVersion: "2010-09-09" Description: CloudFormation Template #=============================================================================== # Metadata #=============================================================================== Metadata: AWS::CloudFormation::Interface: ParameterGroups: - Label: default: Parameters Parameters: - ThresholdConcurrentExecutions - NotificationEmail #=============================================================================== # Parameters #=============================================================================== Parameters: ThresholdConcurrentExecutions: Type: Number NotificationEmail: Type: String #=============================================================================== # Resources #=============================================================================== Resources: #----------------------------------------------------------- # IAM #----------------------------------------------------------- AlarmActionFunctionRole: Type: AWS::IAM::Role Properties: AssumeRolePolicyDocument: Version: "2012-10-17" Statement: - Effect: Allow Principal: Service: - lambda.amazonaws.com Action: - sts:AssumeRole ManagedPolicyArns: - arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole Policies: - PolicyName: AllowRequestServiceQuotaIncrease PolicyDocument: Version: "2012-10-17" Statement: - Effect: Allow Action: - servicequotas:RequestServiceQuotaIncrease Resource: "*" #----------------------------------------------------------- # Lambda #----------------------------------------------------------- AlarmActionFunction: Type: AWS::Lambda::Function Properties: FunctionName: !Sub ${AWS::StackName}-alarm-action Role: !GetAtt AlarmActionFunctionRole.Arn Architectures: - arm64 MemorySize: 256 Timeout: 30 Runtime: python3.8 Handler: index.handler Code: ZipFile: | import boto3 import logging logger = logging.getLogger() logger.setLevel(logging.INFO) def handler(event, context): logger.info('event: %s', event) client = boto3.client('service-quotas') response = client.request_service_quota_increase( ServiceCode='lambda', QuotaCode='L-B99A9384', DesiredValue=1100 ) return AlarmActionFunctionPermission: Type: AWS::Lambda::Permission Properties: Action: lambda:InvokeFunction FunctionName: !GetAtt AlarmActionFunction.Arn Principal: sns.amazonaws.com #----------------------------------------------------------- # SNS #----------------------------------------------------------- AlarmTopic: Type: AWS::SNS::Topic Properties: TopicName: !Sub ${AWS::StackName}-alarm-topic AlarmSubscriptionForEmail: Type: AWS::SNS::Subscription Properties: TopicArn: !Ref AlarmTopic Protocol: email Endpoint: !Ref NotificationEmail AlarmSubscriptionForLambda: Type: AWS::SNS::Subscription Properties: TopicArn: !Ref AlarmTopic Protocol: lambda Endpoint: !GetAtt AlarmActionFunction.Arn #----------------------------------------------------------- # CloudWatch Alarm #----------------------------------------------------------- LambdaConcurrentExecutionsAlarm: Type: AWS::CloudWatch::Alarm Properties: AlarmName: !Sub ${AWS::StackName}-concurrent-executions ActionsEnabled: true AlarmActions: - !Ref AlarmTopic Namespace: AWS/Lambda MetricName: ConcurrentExecutions Period: 60 EvaluationPeriods: 1 Threshold: !Ref ThresholdConcurrentExecutions Statistic: Maximum ComparisonOperator: GreaterThanThreshold TreatMissingData: notBreaching わかりやすさ重視のため、テンプレート内に直接Lambdaコードを書いていますが、実際に使う際は別ファイルで管理することをおすすめします。 DesiredValueなどの値も固定値にしていますが、パラメータ化することをおすすします。 特定のLambda関数の同時実行数をモニタリング対象とする場合は Alarm にDimensionsプロパティを追加し、対象のLambda関数を指定します。 このCloudFormationテンプレートに含まれるLambda関数を実行すると、Lambdaの同時実行数クォータの引き上げがリクエストされますので、実際に実行する際はご留意ください。 クォータ引き上げに関する注意事項 クォータの引き上げは、リクエストすると、すぐに引き上げられるわけではないことにご注意ください。 クォータの引き上げをリクエストすると、サポートケースが作成されます。 このサポートケースが処理される時間は対象のクォータによっても異なるようです。 また、クォータによってはAWSサポートから質問が来ることもあります。 私が実際に経験したものとしては、WAF の WCU (Web ACL Capacity Unit) のクォータ引き上げをリクエストした際に、AWSサポートから「どのようなユースケースなのか？」「対象のWeb ACLのARNを教えてほしい」といった質問が来たことがあります。（そのやりとりも含め、3日程度かかりました） 数分程度で引き上げられるクォータもありますが、クォータによってはこのような対応が必要になる可能性があることは念頭に置いておきましょう。 まとめ CloudWatch Metrics/Alarm と SNS を組み合わせて、クォータのモニタリング・通知ができる Lambda (AWS SDK) を用いてクォータの引き上げリクエストを自動化できる クォータの引き上げリクエストまで自動化すべきかは状況に応じて判断すべき クォータの引き上げリクエストはすぐに対応されるとは限らない 最後まで読んでいただき、ありがとうございます。 この記事が少しでも役に立てば幸いです。 いいね（LGTM）いただけると励みになりますm(_ _)m もちろん、WAFやShieldなどを用いて対策すべきですが、本記事はクォータにフォーカスした内容なので、DDoS攻撃対策には言及しません。 ↩

はじめに AWS ECSを使ったアプリケーションを簡単にデプロイできるツールであるAWS Copilot CLIでSQSを使ってみます。 Copilotにはインターネットからアクセスされるウェブアプリケーションをデプロイできる Load Balanced Web Service や定期的に起動するバッジである Scheduled Job と並んで Worker Service というメッセージを受信して処理するタイプのサービスがあります。が、この Worker Service で具体的にどのようなアプリケーションがデプロイされるのかいま一つイメージがつかなかったため、実際にWorker Serviceをデプロイして、非同期サービス間通信を体験してみました。 参考 公式ドキュメント 前提 $ copilot version version: v1.14.0, built for linux CopilotにおけるApplication、Serviceとはなにか、などCopilotに関する基礎知識に関する説明は省略します。また、Application、Environmentは作成済みとしてそこへServiceをデプロイする部分の手順だけ記載します。 目標 次の図のような一連の流れを実現させようと思います。（ALBなどを省略した簡略図です） Load Balanced Web Service をECSにデプロイし、これをメッセージを送信するパブリッシャーとします。 具体的には、今回の試行ではAPIをデプロイし、インターネットからPOSTアクセスがあればそのアクセスに含まれるデータをSNSに送信します。 さらにもう一つ、 Worker Service をECSにデプロイし、メッセージを処理するサブスクライバーとします。 このサービスがSQSからメッセージを取得し、処理します。 Copilotのドキュメントによると Worker Service はpub/sub アーキテクチャを実装するものらしいです。 私はpub/sub アーキテクチャについての知見が無いため、これについて解説することはできないのですが、ともかくまずは最小の構成で試してみます。 パブリッシャーをデプロイ まず、SNS経由でSQSにメッセージを送信する側であるパブリッシャーをデプロイします。 Load Balanced Web Service で試してみましたが、パブリッシャー側は Scheduled Job などどのタイプのサービスでも良さそうです。 今回デプロイしてみたアプリケーションはGitLabに置いてあります。send-message-apiで確認できます。 Spring Boot + JavaによるWebアプリケーションになっており、POSTリクエストがあるとそのBodyをSNSへ送信します。Controllerで全ての処理を実施している簡易的な実装です。 Service作成 copilot svc init -a demo-app -n send-message-api -t "Load Balanced Web Service" demo-appというApplicationは事前にできているものとします。send-message-apiというServiceをLoad Balanced Web Serviceタイプでinitします。 次にcopilotがプロジェクト内に作成したmanifestに次のようなpublishセクションを追加します。 publish: topics: - name: order-events 参考のためにmanifest全体を折りたたみ中に記載しておきます。 manifest.yml name: send-message-api type: Load Balanced Web Service http: path: 'send-message-api' healthcheck: '/send-message-api/actuator/health' image: build: Dockerfile port: 8080 cpu: 256 memory: 512 count: 1 exec: true publish: topics: - name: sample-sns デプロイ copilot svc deploy -a demo-app -e environment -n send-message-api でデプロイします。developEnvironmentは作成済みとします。 demo-appApplicationのdevelopEnvironmentにsend-message-apiというServiceがデプロイされます。 publishセクションの内容に沿って、SNSが作成されます。 自分が試したときにはdemo-app-develop-send-message-api-sample-snsという名前のSNSになりました。 SNSの名称は ${Application}-${Environment}-${Service}-${manifestファイル中のpublish.topics.name} のように命名され、一意になるということのようです。 なお、実際はSNSのARNは環境変数経由で取得できるため、SNSが具体的にどのような名前で作られたかは基本的に意識する必要はありません。 環境変数に格納されるSNSのARN 作成されたSNSのARNは環境変数としてコンテナに設定されます。 具体的には今回の動作確認ではCOPILOT_SNS_TOPIC_ARNSという環境変数に{"sample-sns":"arn:aws:sns:ap-northeast-1:xxxxxxxx:demo-app-develop-send-message-api-sample-sns"}のようなJSON文字列が設定されました。 単純にARNが設定されるのではなく、JSON文字列であることに注意が必要です。パースしてARNを取り出さなければなりません。 サブスクライバーをデプロイ 次にSQSからメッセージを取り出して処理するサブスクライバーをデプロイします。 今回デプロイしてみたアプリケーションはパブリッシャー同様GitLabに置いてあります。receive-message-batchで確認できます。 ほぼメインメソッドしかない超簡易的な実装です。 Service作成 copilot svc init -a demo-app -n receive-message-batch -t "Worker Service" receive-message-batchというServiceをWorker Serviceタイプでinitします。 次にcopilotがプロジェクト内に作成したmanifestのsubscribeセクションを次のように記載します。 subscribe: topics: - name: sample-sns service: send-message-api Worker Serviceのmanifestについてのドキュメント 上記のような書き方をすることでsend-message-apiServiceのsample-snsトピックをサブスクライブします。つまり、先程デプロイしたServiceが送信するメッセージを受け取れるようになります。 参考のためにmanifest全体を折りたたみ中に記載しておきます。 manifest.yml name: receive-message-batch type: Worker Service image: build: Dockerfile cpu: 256 memory: 512 count: 1 exec: true subscribe: topics: - name: sample-sns service: send-message-api command: java -jar receive-message-batch-all.jar デプロイ copilot svc deploy -a demo-app -e environment -n receive-message-batch でデプロイします。demo-appApplicationのdevelopEnvironmentにreceive-message-batchというServiceがデプロイされます。 demo-app-develop-receive-message-batch-EventsQueue-yyyyyyのような名称のSQSが追加されます。さらに、SNSのへのサブスクリプション、必要なポリシーなども自動で作成されます。 SNSと似たように、SQSの名称は ${Application}-${Environment}-${Service}-EventsQueue-${ランダム文字列} のように命名され、一意になるということのようです。 パブリッシャーにおけるSNS同様にSQSのURIは環境変数経由で取得できるため、具体的にどのような名前のSQSが作成されたかなどは基本的に意識する必要はありません。 環境変数に格納されるSNSのARN 作成されたSQSのARNは環境変数としてコンテナに設定されます。 具体的には今回の動作確認ではCOPILOT_QUEUE_URIという環境変数にhttps://sqs.ap-northeast-1.amazonaws.com/xxxxxx/demo-app-develop-receive-message-batch-EventsQueue-yyyyyyのような文字列が設定されました。今回はJSONではありません。 Worker Serviceの挙動 勝手な思い込みでしかないのですが、当初私は Worker Service はSQSにメッセージが送信されるたびに起動されてメッセージを処理し、それ以外のタイミングでは起動しないものだと思っていました。 例えばlambdaだとそのような起動の仕方が可能だったはずです。 しかし、実際の Worker Service はそのようなものではなく、基本的にコンテナは常駐し、SQSをポーリングしメッセージがあるか確認する処理などは自前で実装する必要があります。 どのような実装が良いのかはよくわかりませんでしたが、一旦while文で無限ループさせ、SQSをポーリングするようにしました。（この部分です） 動作確認 ここまでの手順でパブリッシャーとサブスクライバーがデプロイされ、SNS・SQSを介して連携するようになりました。 今回私はサンプルとしてsend-message-api（パブリッシャー）、receive-message-batch（サブスクライバー）をデプロイしています。 今回の場合、次のように動作確認しました。 パブリッシャーへPOSTリクエスト パブリッシャーは Load Balanced Web Service としてSNSへメッセージを送信するWebアプリケーションをデプロイしているので、 curl -X POST -H "Content-Type: application/json" -d '{"message":"java"}' http://${デプロイしたLoad Balanced Web Serviceに紐づくALBのDNS名}/send-message-api/send のようにPOSTリクエストします。 SNSからSQSへとメッセージの伝達 先述のPOSTリクエストでパブリッシャーはリクエストボディ取得してSNSへ送信します。（この部分です） Worker Serviceデプロイ時に作成されたSQSはSNSをサブスクリプションしているので、SQSへメッセージが渡ります。 Worker ServiceはSQSをポーリングしているため、メッセージがSQSに入ると、それを取得し、処理します。今回のreceive-message-batchは処理といってもログ出力（この部分です）するだけですが、メッセージがあると、そのメッセージをログ出力します。 これで2つのサービスがSNS・SQSを介して非同期的にコミュニケーションできていることが確認できました。 その他追加で試したこと キューの細かい設定 Worker Service で最小の設定として subscribe: topics: - name: sample-sns service: send-message-api のような記載をmanifestに書きました。この場合SQSはデフォルト設定で作成されます。 しかし、Worker Serviceに関するドキュメントにはキューのカスタマイズ設定も紹介されています。 目一杯設定すると次のようになります。 subscribe: topics: - name: sample-sns service: send-message-api queue: # 可視性タイムアウト timeout: 45s # メッセージ保持期間 retention: 71h # 配信遅延 delay: 30s dead_letter: # デッドレターキュー 最大受信数 tries: 5 コメントに書いている項目を設定できるようです。 「可視性タイムアウト」とはなにか、などは前述のCopilotのドキュメントおよびSQSのドキュメント（キューパラメータの設定(コンソール)など）が参考になります。 サブスクライバーが複数いる場合 1つのパブリッシャーに対して複数のサブスクライバーがいるパターンも試しました。 別の Worker Service をcopilot svc init -t "Worker Service"で作成し、manifestに全く同じように、 subscribe: topics: - name: sample-sns service: send-message-api と記載してデプロイするだけです。 すると、このサービス用にもう一つSQSが作成され、SNSへのサブスクリプションが設定されます。 パブリッシャーがSNSへメッセージを送信すると両方のSQSにメッセージが送られ、ほぼ同時に2つの Worker Service が同じメッセージを受信して処理を実施します。 FIFOキューについて 現在SQSのFIFOキューには対応していなさそうです。 しかし、下記のIssueを見ると近いうちに対応されるのかもしれません。

はじめに AWS Certified SysOps Administrator - Associateの試験ラボを乗り切るために、勉強していることをなんとなくメモっていきます。 基本的にハンズオンの内容は説明せずに出てきた単語を少し深掘りしていきます。 行うこと https://aws.amazon.com/jp/aws-jp-introduction/aws-jp-webinar-hands-on/ Network編#2 Amazon VPC間およびAmazon VPCとオンプレミスのプライベートネットワーク接続 本人情報 IT現場雑用員（SEで採用されながら一生Excel触ってる人） 半年前にAWS SAA取得済み Amazon VPC間の接続 一つのアカウントでリージョン内に作成できるVPCの数は5つであり、環境毎やシステム毎に作成します。開発の過程でVPC間の通信が必要になった場合、主に２つの方法で接続が行われます。 VPCピアリング接続 2つのVPC間をプライベートに接続することができます。異なるリージョン、異なるアカウント間での接続も可能です。 条件 ・　VPCのローカルアドレスについて、接続するVPCはそれぞれ異なるネットワーク部を持つアドレスである必要があります。 ・　VPCを踏み台にして１つ先のVPCと接続することはできません、接続するVPC同士は全てVPCピアリンングを設定する必要があります。 Transit Gateway接続 VPCピアリングを用いて多くのVPC同士を接続しようとした場合、構成が複雑になってしまいます。Transit GatewayはVPC同士を接続するためのハブのような役割を果たしてくれるため、構成を簡素化することができます。 https://aws.amazon.com/jp/summits/tokyo-osaka-2019-report/ ##VPCピアリングの作成 VPCピアリングの作成はVPC Management Console内のピアリング接続から行うことができます。 接続を行なうVPCを2つ選択する他、アカウントやリージョンを跨いで接続を行う場合はそれらを選択して作成を行います。 また、自分のアカウント内であっても作成を行なった後にピアリング接続の承認を行う必要があります。 作成が終わった後はそれぞれのVPC内に作成されたサブネットのルートテーブルに接続先を追加する必要があります。追加する際にターゲットはピアリング接続を選択します。 疎通確認 片方のVPCにピアリング用のEC2、もう片方にCloud9を作って疎通確認を行います。 Cloud9とは AWS上で動作する統合開発環境です。コードの作成、ビルド、実行、テスト、デバックやショートカットの割り当てや構文の色などコードエディタとしての細かな設定を行うことができます。Cloud9で環境を作成、保存しAWS CodeCommitリポジトリなどを使用して作業内容を保存することによって全ての開発作業をAWS上で完結させることができます。その結果どの端末からでも作業を行うことが可能となり、コンピュータの切り替えや人員の増加などが容易になります。 https://docs.aws.amazon.com/ja_jp/cloud9/latest/user-guide/welcome.html 疎通 Cloud９のipアドレスを確認し ip addr 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc pfifo_fast state UP group default qlen 1000 link/ether 06:c8:f7:d8:42:11 brd ff:ff:ff:ff:ff:ff inet 10.0.0.176/24 brd 10.0.0.255 scope global dynamic eth0 valid_lft 2673sec preferred_lft 2673sec inet6 fe80::4c8:f7ff:fed8:4211/64 scope link valid_lft forever preferred_lft forever もう一方で作成したVPC内のEC2（10.1.0.100）に向けてpingを送ります。 PING 10.1.0.100 (10.1.0.100) 56(84) bytes of data. 64 bytes from 10.1.0.100: icmp_seq=1 ttl=64 time=0.432 ms 64 bytes from 10.1.0.100: icmp_seq=2 ttl=64 time=0.461 ms 64 bytes from 10.1.0.100: icmp_seq=3 ttl=64 time=0.481 ms 無事疎通が取れていることが確認できました。 まとめ VPCピアリンングを作成する場合は、作成、承諾、ルートテーブルの追加を行う。 Amazon VPCとオンプレミスを接続する AWS SIte-to-Site VPN IPsec VPNを介してVPCにプライベート接続するサービスです。実際はVGWは冗長化のために２つ設定されます。VPN Connectionの接続先としてTransit Gatewayを選択すると、1つのAWS SIte-to-Site VPNでより多くのVPCと接続することができます。IPsecによって通信自体の暗号化はされますが、インターネットを経由するため後述するDirect Connectと比べて通信が安定しません。 https://docs.aws.amazon.com/ja_jp/vpn/latest/s2svpn/how_it_works.html AWS Direct Connect お客様のデータセンターやオフィスを専用線を介してAWSへプライベート接続するサービスです。Direct Connect locationでお客様のネットワーク機器とDirect Connectデバイスが物理的に接続されます。先述のAWS SIte-to-Site VPNと比べてインターネットを経由せずに物理線を通って通信が行われるため、高い品質の通信を行うことができます。 https://docs.aws.amazon.com/ja_jp/directconnect/latest/UserGuide/Welcome.html 疎通確認 Vyosとは ハンズオン内で使用したVyosとは、インストールすることで物理マシン、仮想マシンをソフトウェアルーターとして利用することができるソフトウェアです。ハードウェアルーターと同様にIPsecやSSL、パケットフィルタリング、URLフィルタリング、WAN負荷分散アドに使用することができます。今回はEC2上にインストールし、仮のカスタマーゲートウェイとして使用していました。 またVyOS1.1系から1.2に変更されるにあたって構文が変更されたため、ダウンロードしたconfigファイルはそのままでは使えないようです。下記サイトにも記載がありますが、AWSでのテスト済みカスタマーゲートウェイデバイスの一覧にVyosは存在しないため、テスト以外での用途では使用しない方がよさそうです。 https://dev.classmethod.jp/articles/vyos1-2_aws/ 疎通 オンプレミスとして作成したVPN内に作成したEC2インスタンス（192.168.0.100）に対してpingが通ることを確認することができました。 まとめ ・VGWの作成、VPCへのアタッチ ・CGWの作成 ・サイト間VPNの作成 ・Customer Gatewayの作成 ・ルートテーブルの伝搬 を行うことによってオンプレミスとVPCをプライベートネットワークとして接続することができます。

はじめに 今回のお話はAWSにアプリをデプロイ出来なかった話です。 あんまり技術的な学びはないので、真面目な気持ちでクリックしてしまったあなたはブラウザバックしてください。 逆に仕事が捗らなくて技術記事読むフリして休憩したいそんなあなたにはピッタリの内容になっております。 どんなアプリを作ったか 今回の本筋ではないのですが、デプロイ出来なかったのでここでアプリを供養しておきます。 簡単なTodoアプリで、以前Nuxt.jsとFirebaseで作ったものをNext.jsとLaravelで作り直したという感じです。 未経験からエンジニア転職する際に作ったポートフォリオだったので、思い入れのあるアプリです。 CSSフレームワークとしてChakraUIを使いました。 class名でスタイリングしていくわけではなく、スタイリングされたcomponentを使う形式です。 型定義バッチリされてるし、propsで値渡せばそこそこ柔軟にスタイル変えられるし最高でした。 リポジトリはこちら ローカルでの立ち上げ方もREADME付けているので、是非触ってもらえたら嬉しいです。 やろうとしたこと Next.jsをVercelにデプロイ。 LaravelとMySQLをAWSのEC2にデプロイ。 初めてAWSを触るので、学習コストを少しでも下げるためにRDSは使わない。 出来たことと挫折したこと Next.jsをVercelにデプロイ。 簡単とは聞いていたが、ビックリするくらい簡単だった。何回かクリックしたらデプロイが終わった。 masterブランチにpushする度に自動デプロイされて、便利なことこの上なかった。 LaravelとMySQLをAWSのEC2にデプロイ。 タイトル詐欺と言われそうだが、実はEC2にLaravelとMySQLをデプロイ自体は出来た。 もう少し言うとローカルのフロントからEC2上のLaravelのAPIを叩くところまでは出来た。 CORSエラーに苦しんだが、nginxでリクエストにheaderを付けることで解消出来た。 ELBを使っていなかったので、EC2はhttpのままで、Vercelはhttpsだったので、プロトコルが違って通信出来なかった。今回ここで挫折。 そもそもやらなかった（が今後やりたい）こと Next.js getStaticPropsとgetServerPropsは使わずじまいだった。useEffectで誤魔化してました。 初めてのNext.jsだったので、Recoilは使わず。useContextで行きました。 パフォーマンスの意識。とにかく動けばOKの精神で作ってしまった。 Laravel ステートフルにしたかったが、Laravelのsessionの使い方がよく分からず見送り。 以前の記事でも書きましたが、モダンフロントとLaravelの組み合わせの記事が本当に少なくて、Blade前提のものばかりで参考にならない・・・。 CORSとCSRFはどちらもちゃんと対策できず、セキュリティガバガバアプリになった。 今後勉強しないといけないなと思ったこと Linux 参考文献のコマンドをコピペで打ってデプロイしただけなので、あんまりコマンドの意味も分からずやっていた。 普段意識しないようなパーミッションの概念が全然分かっていなかった。 nginx(別にapacheでも良いけど） 前述の通りCORSエラーにめっちゃ苦しめられた。サーバーアプリはちゃんと勉強しておかないとインフラの理解なんて出来る訳がないなと痛感した。 AWS 当たり前だけど、AWS自体も全然分かっていなかった。一度に色んなことをやろうとしたのが敗因。 基本的なVPC、EC2、Route53、ELBあたりを一つずつちゃんと学習するべきだった。 さいごに 暗い記事になってしまいましたが、初めてNext.js、AWSを触れたので学びは多かったです。 休憩ということで、次はバックエンドとインフラをAmplifyとかFirebase使って、フロントに集中したアプリを作りたい。 参考文献 【AWS入門】EC2+NGINX+MySQL環境へLaravelをデプロイする手順 nginxのadd_headerでレスポンスヘッダが付かない時の対処法 【初心者向け】AWSのサービスを使ってWebサーバーをHTTPS化する

はじめに 掲題通り。 よく忘れて、都度検索してしまうのでメモ。 Amazon Linux 2 での動作させることを想定。 準備 (EFS以外のリソース) EFS を作成する VPC で「DNS解決の有効化」および「DNSホスト名を有効化」しておく ウィザードなどに頼らずにVPCを作成した場合、デフォルトでDNSホスト名が無効になっているため注意 単にDNSホスト名を有効化しただけだと、なぜか反映されない時があったが、その時は改めて「DNS解決」および「DNSホスト名」を無効化⇒有効化したら反映された EFS へのアクセス元からの TCP: 2049 インバウンドアクセスを許可するセキュリティグループを作成しておく ここでは名前を efs とする。 EFS の作成 Management Console から利用するVPCを選んで作成していく。 この時、EFSのマウントターゲットを指定する際、先の手順で作成したセキュリティグループ efs を指定してアクセスを許可する。 EFSのマウントターゲットのsubnetを指定するが、Q. 作成時のsubnet指定は、EFSをマウントするEC2インスタンスが所属しているsubnetを選択すればよいですか？ の回答によれば、基本はメインで利用するインスタンスから近いサブネットを指定する のが良いようだ。 ただし、もちろん別のサブネットであっても、アクセスの条件を満たしていればアクセスは可能。 準備 amazon-efs-utils をインストール。 $ sudo yum -y install amazon-efs-utils 起動時にEFSをマウントするようにする サーバー上のマウントポイントに sudo mkdir -p /mnt/efs で空ディレクトリを作成。 その後 /etc/fstab に以下を追加。 # フォーマット <EFSのファイルシステムID>.efs.<リージョン>.amazonaws.com:<EFSのマウントポイント> <ローカルのマウントポイント> efs defaults,_netdev 0 0 # 具体例: EFSの / をローカルの /mnt/efs にマウントする # fs-0123456789abcdef.efs.ap-northeast-1.amazonaws.com:/ /mnt/efs efs defaults,_netdev 0 0 なお、defaults 部分を tls に書きかえることでインスタンス/EFS間の通信を暗号化する。 AWSマウントヘルパに記載のある -o tls に対応する部分がここ。 実際には IAM 認証の場合は暗号化設定が必要なので、この場合に利用する方法が紹介されている。 参考

IaC（Infrastructure as Code）としてAWSではCloudFormationを利用して インフラのプロビジョニングを行うことがある。 Githubなどで公開されたyamlを利用することで簡単に AWSのインフラサービスが使用可能な状態（セキュリティグループ設定、IAM設定、バッチ処理（Lambda））になっていたりする。 今回Githubなどで公開されたyamlをベースに追加のリソースや設定の追加を行う際に 特に考えずともインフラが払い出せてしまい、カスタマイズやチューニングする際に CloudFormationに書かれていることを解読する羽目になり、 シーケンス図を記載したりしながら依存関係を洗うこととなった。 こんな大変なら 全部手書きできるほうが早いじゃんと思ったので まずIaC化に対する目的から整理し、道具に使われてしまうSEが減ることを願って 足跡を残していこうと思う。 IaC（CloudFormation）の目的を整理してみた ①自動化することで、人件費を削減したい ②自動化することで、人為的なミスを減らし、担当者の負荷を下げたい ③インフラの管理コストを削減したい 環境の再構築時を自動化でき、 コード自体が環境のバックアップとなる。 また、Gitなどを用いたバージョン管理により、Excelなどに比べ管理しやすい GUIで作っちゃった環境も Former2を利用すれば、既存環境のリソースに合わせた設定値のテンプレートを作成することができる https://former2.com/ CloudFormationだけでなく、TerraformをはじめとしたOutputsを無料で提供しているため、 IaCを何時からでも始めることはできる。 ここで一つ問題が発生する。 Former2で作成するテンプレートには環境固有値（IamgeID）が入ってしまうため、 バックアップには使用できる＆10分以内に作成できるが、 テンプレートとしてプロビジョニング用途には使用ができない。 そこでCloudFormationの書き方を勉強することになった。 CloudFormationの書き方は以下を参照 https://dev.classmethod.jp/articles/cloudformation-beginner01/ 結論 書きなれていなければ、GUIで考えながら作ったほうが圧倒的にデプロイは早い（と思う） ただ、品質や再現性、管理工数を鑑みるにIaCテンプレートを作成したほうが良い場合もある。 どれだけテンプレートを作成したとしても、使う人間が考えずに使用すればまた道具に使われてしまうだけなので 目的と運用の立て付けが必要だと感じた。