はじめに AWS初心者向けハンズオン「AWS Hands-on for Beginners」の中から、AWS DVA（デベロッパー - アソシエイト）取得に役立つハンズオンを紹介します。 DVAは、SAA（ソリューションアーキテクト - アソシエイト）と比較して、①狭く深い知識が問われ、②具体的なコマンドが出てくる問題が多いです。したがって、ハンズオンは有効なDVA試験対策になると思います。 AWS Hands-on for Beginnersとは 初めてAWSサービスを利用する方向け 解説動画を見ながら、実際にAWSサービスを操作する 各ハンズオンは合計1～2時間の動画構成 ハンズオン①　AWS環境のコード管理AWS CloudFormationでWebシステムを構築する DVAでの出題範囲 分野1「展開」に該当 ハンズオンで学べる主要なサービス AWS CloudFormation ハンズオンの内容 AWS環境におけるコード管理の重要性を学び、AWS CloudFormationを利用して以下の環境を構築する。クラウドベースの統合開発環境AWS Cloud9を利用して、CloudFormationテンプレートの編集、更新を行う。AWS CLIを利用してスタックを更新する。VPC、EC2、RDS、ELBを順番にスタックを分けて構築する。構築した環境の動作を確認するため、EC2上のWord Pressにログインする。 ハンズオン②　AWS Codeサービス群を活用して、CI/CDのための構成を構築しよう！ DVAでの出題範囲 分野1「展開」に該当 ハンズオンで学べる主要なサービス AWS CodeCommit AWS CodeBuild AWS CodeDeploy AWS CodePipeline ハンズオンの内容 AWS Codeサービス群を利用して、継続的インテグレーション/継続的デプロイメント(CI/CD)のための簡単な構成を作成する。 上の構成では、AWS Cloud9からAWS CodeCommitにソースコードをgit pushする。AWS CodePipelineは、そのgit pushを検知し、S3 Bucketに成果物をデプロイする。S3 Bucketは、静的ウェブサイトホスティングの設定を行っているので、自動的に公開される。 下の構成では、git pushを検知したAWS CodePipelineは、AWS Codeサービス群を連携させ、EC2 Instanceへのデプロイまで自動で実行する。 ハンズオン③　監視編 サーバーのモニタリングの基本を学ぼう DVAでの出題範囲 分野5「モニタリングとトラブルシューティング」に該当 ハンズオンで学べる主要なサービス AWS CloudWatch CloudWatch Metrics CloudWatch Alarms CloudWatch Logs CloudWatch Logs Insights CloudWatch Events CloudWatch DashBoards ハンズオンの内容 初めにAWS CloudFormationを利用して、モニタリング対象のアーキテクチャを構築する。 Amazon CloudWatchのモニタリングに関する以下の機能を使用する。 機能名 主な用途 使用例 CloudWatch Metrics システムのパフォーマンスを確認する EC2のCPU使用率を確認する CloudWatch Alarms メトリクスに応じたアクションを実行する EC2のCPU使用率が90%を超えたときにメールを送信する CloudWatch Logs システムのログを監視、保存、アクセスする EC2のログを確認する CloudWatch Logs Insights ログをインタラクティブに検索し分析する EC2のエラーコードログを検索しグラフ化する CloudWatch DashBoards 複数のメトリクスやログを1つの画面で確認する EC2のCPU使用率、ディスクの読み書き回数、ネットワークの利用などを1つの画面で確認する CloudWatch Events イベントに応じたターゲットを利用したアクションを実行する EC2が停止したときにメールを送信する おわりに 実際に手を動かして、AWSサービスを触るのは楽しいです（∪＾ω＾）

はじめに GitHub Actions、CircleCiを使ったCIは構築した事があったが、Code BuildでのCIはやった事がなかったのでやってみた その際の備忘録を残す ※前提条件として既にCode Commitにbuild対象のソースコードがある状態からスタートした ※ビルドするものはGoのLambda関数 buildspec.ymlや、GitHub Actionsでのビルドは以下のリポジトリを参照 Code Buildのビルドプロジェクトを作成する Management Consoleからビルドプロジェクトを作成する 以下の画像のように設定できる 1 2 3 4 ※上記の画像では、イメージ（docker image）はaws/codebuild/standard:4.0になっているが、作成後にGoの1.16をruntime versionに指定できるのはaws/codebuild/standard:5.0である事が後かは判明したのでそれに修正した ※「ソース」でブランチ(ビルドするコードを含むブランチを選択します。)を設定しているが、これはstart buildをした時にオプションで何も指定されなかった時にどのソースバージョンでbuildするか？を決められるようにするために設定しているもので、start build時に指定すればこの設定は上書きされる CodeCommit の場合、ビルドするソースコードのバージョンに対応するコミット ID。sourceVersion が指定されなければ、デフォルトブランチの HEAD コミット ID が使用されます。(sourceVersion にタグ名は指定できません。しかし、タグのコミット ID は指定できます。) ・参考：ビルドの実行 (AWS CLI) ビルドプロジェクトを作成するために必要なIAM 上記のビルドプロジェクトを作成する上で必要になる権限はいくつかある ※Code Buildのビルドプロジェクトは、他のAWSサービスとの連携が結構あるのでその分必要な権限も多い Code Build：言わずもがな Code Commit：今回はソースプロバイダをCode Commitにするので必要 IAM：ビルドプロジェクトへサービスロールをアタッチしたり、そのサービスロールを作成するために必要 S3：アーティファクトの保存先のBucket作成、保存されたものへアクセスするために必要 ・参考：AWS CodeBuild のアクセス許可に関するリファレンス Code Build { "Version": "2012-10-17", "Statement": [ { "Sid": "VisualEditor0", "Effect": "Allow", "Action": [ "codebuild:BatchGetProjects", "codebuild:CreateProject" ], "Resource": "arn:aws:codebuild:ap-northeast-1:xxxxxxxxxxxx:project/go-build-console" }, { "Sid": "VisualEditor1", "Effect": "Allow", "Action": [ "codebuild:ListCuratedEnvironmentImages", "codebuild:ListProjects" ], "Resource": "*" } ] } action名 説明 codebuild:BatchGetProjects 1つ以上のビルドプロジェクトに関する情報を取得する権限。単純に自分で作成したビルドプロジェクトの内容を確認するために必要。 codebuild:CreateProject ビルドプロジェクトを作成する権限。 codebuild:ListCuratedEnvironmentImages AWSCodeBuildのコンテナ（Docker）イメージに関する情報を取得する権限。これないと環境イメージの選択とかができない。 codebuild:ListProjects ビルドプロジェクト名の一覧をリストを取得する権限。Code Buildのビルドプロジェクトメニューを選択して表示されるビルドプロジェクト一覧を見れるようにするに必要。 Code Commit ソースの項目を設定する上で必要になる { "Version": "2012-10-17", "Statement": [ { "Sid": "VisualEditor0", "Effect": "Allow", "Action": [ "codecommit:GetCommit", "codecommit:GetCommitHistory", "codecommit:GetReferences" ], "Resource": "arn:aws:codecommit:ap-northeast-1:xxxxxxxxxxxx:go" }, { "Sid": "VisualEditor1", "Effect": "Allow", "Action": "codecommit:ListRepositories", "Resource": "*" } ] } action名 説明 codecommit:GetCommit コミットメッセージやコミッター情報などのコミットに関する情報を取得する権限。ソースのコミット ID - オプショナルの部分を設定できるようにするために必要。 codecommit:GetCommitHistory リポジトリ内のコミットの履歴に関する情報を取得する権限。ソースのコミット ID - オプショナルの部分を設定できるようにするために必要。 codecommit:GetReferences CodeCommitリポジトリ内の参照に関する詳細を取得する権限。ソースのソースバージョンを表示させるために必要。 codecommit:ListRepositories AWSアカウントの現在のリージョンにあるAWSCodeCommitリポジトリに関する情報を一覧表示する権限。ソースのリポジトリの選択リストを表示させるための必要。 ※ソースとは以下の画像の部分で、コミット ID - オプショナルとは以下のリストの部分 IAM ビルドプロジェクトにアタッチしたサービスロールに対し、ビルドプロジェクトが必要になる権限（アーティファクトの保存先であるS3の権限、ビルドのlogを記録するためのCloud Watch Logsの権限、ビルド実行後のレポートを出力するためのCode Buildの権限）などのポリシーを追加したりそのポリシーのバージョンを操作するための権限 { "Version": "2012-10-17", "Statement": [ { "Sid": "VisualEditor0", "Effect": "Allow", "Action": [ "iam:CreatePolicy", "iam:PassRole", "iam:CreateRole", "iam:AttachRolePolicy", "iam:CreatePolicyVersion", "iam:DeletePolicyVersion" ], "Resource": [ "arn:aws:iam::xxxxxxxxxxxx:role/go-build-console", "arn:aws:iam::xxxxxxxxxxxx:policy/*" ] }, { "Sid": "VisualEditor1", "Effect": "Allow", "Action": [ "iam:ListPolicies", "iam:ListRoles" ], "Resource": "*" } ] } action名 説明 iam:CreatePolicy 新しい管理ポリシーを作成する権限。AWS側で自動的にポリシー作成できるようにするために必要。 iam:PassRole サービスに役割を渡す権限。Code Buildのビルドプロジェクトにサービスロールを指定できるようにするのに必要。 iam:CreateRole 新しいロールを作成する権限。新規でロールを作成するのに必要で、サービスロールとしてアタッチするロール作成で必要になった。 iam:AttachRolePolicy 指定されたIAMロールに管理ポリシーをアタッチする権限。AWS側で自動的にロールにポリシーをアタッチできるようにするのに必要。 iam:CreatePolicyVersion 指定された管理ポリシーの新しいバージョンを作成する権限。AWS側で自動的にポリシーを作成できるようにするために必要。 iam:DeletePolicyVersion 指定された管理対象ポリシーからバージョンを削除する権限。AWS側で自動的にポリシーを変更できるようにするために必要。 iam:ListPolicies すべての管理対象ポリシーを一覧表示する権限。AWS側で自動的にポリシーを変更できるようにするために必要。 iam:ListRoles 指定されたパスプレフィックスを持つIAMロールを一覧表示する権限。環境のサービスロールにロールを一覧表示させるのに必要。 ※AWS側で自動的に 　→AWSが勝手にやるが、その権限はログインユーザの権限で動くのでログインユーザにそれを行う権限を付与させる必要がある ※Management Consoleからビルドプロジェクトを作成すると、自動的にサービスロールにポリシーが新規でアタッチされる（go-build-consoleというロールは自分で作成したものだが、CodeBuildBasePolicy-go-build-console-ap-northeast-1というポリシーはAWSによって自動的に作成されたもの） S3 ビルドプロジェクトを作成する際に、ソースプロバイダやアーティファクトなどでS3を設定できるので最低限S3のアクセス権限がないとビルドプロジェクト作成がAccess Deniedになる { "Version": "2012-10-17", "Statement": [ { "Sid": "VisualEditor0", "Effect": "Allow", "Action": "s3:CreateBucket", "Resource": "arn:aws:s3:::go-build-console" }, { "Sid": "VisualEditor1", "Effect": "Allow", "Action": "s3:ListAllMyBuckets", "Resource": "*" } ] } action名 説明 s3:CreateBucket 新しいバケットを作成する権限。アーティファクトで保存先（タイプ）にS3を選択した際に、バケット名を指定するがそのBucketを作成するのに必要。 s3:ListAllMyBuckets リクエストの認証された送信者が所有するすべてのバケットを一覧表示する権限。アーティファクトで保存先（タイプ）にS3を選択した際のバケット名を指定際に表示されるBucket一覧を表示させるために必要。 buildspecを作成しビルドを実行する buildspecを実装する 作業に必要なIAMはbuildspecを実装しビルドを実行するのに必要なIAMの項を参照 SSHでgit cloneできるようにする 以下の参考のサイトにある通り ・参考：Step ステップ 3: Linux、macOS、または Unix で認証情報を設定する ・参考：複数のAWSアカウントを利用する場合のCodeCommit SSHパスの設定方法 Code Buildのyamlの書き方のルール 正直全部は分からないので、ひとまずCodeBuild のビルド仕様に関するリファレンスを見ながら手さぐりで書いてみた GoのLambdaのbuild（zipファイルを作成する）のyaml Goのruntimeの指定は以下のようにできる install: runtime-versions: golang: 1.16 後はLinux環境でのGoのLambdaのbuild手順（.zip ファイルアーカイブを使用して Go Lambda 関数をデプロイする）通りにコマンドを実行すればよく、buildspec.yml全体としては以下のようになる buildspec.yml version: 0.2 phases: install: runtime-versions: golang: 1.16 pre_build: commands: - echo "go version" - go version - echo "go get aws lambda library" - go get github.com/aws/aws-lambda-go/lambda build: commands: - echo "go build" - GOOS=linux go build -o main lambda.go post_build: commands: - echo "create zip" - zip main.zip main config.yaml artifacts: files: - main.zip ・参考：CodeBuild の Amazon ECR サンプル　Go プロジェクトのファイル ・参考：使用可能なランタイム　Linux イメージのランタイム ・参考：ランタイムバージョン ビルドを実行する buildが成功すると以下のようにS3にビルド成果物がs3:::go-build-console/artifact/以下にuploadされる buildspecを実装しビルドを実行するのに必要なIAM 上記のビルドプロジェクトを作成するために必要なIAMで付与した権限以外に以下のactionを実行する権限を追加で付与する （Code Commitについてはbuildspecが見れないと困るので追加で権限付与をしている） Code Build action名 説明 codebuild:ListBuildsForProject 指定されたビルドプロジェクトのビルドIDのリストを取得する権限。ビルド履歴を閲覧できるようにするのに必要。 codebuild:StartBuild ビルドの実行を開始する権限。 codebuild:UpdateProject 既存のビルドプロジェクトの設定を変更する権限。 codebuild:BatchGetBuilds 1つ以上のビルドに関する情報を取得する権限。ビルド履歴のビルド1つ1つの詳細を確認できるようにするのに必要。 ※"Resource"の設定は、ビルドプロジェクトを作成するために必要なIAMのCode Buildの項と同じで、"Resource": "arn:aws:codebuild:ap-northeast-1:xxxxxxxxxxxx:project/go-build-console" Code Commit action名 説明 codecommit:GetRepository AWSCodeCommitリポジトリに関する情報を取得する権限。 codecommit:GetTree AWSCodeCommitコンソールからAWSCodeCommitリポジトリ内の指定されたツリーのコンテンツを表示する権限。リポジトリのフォルダ（階層構造）を表示させるのに必要。 codecommit:GetObjectIdentifier ブロブ、ツリーを解決する権限。 codecommit:GetBlob AWSCodeCommitコンソールからAWSCodeCommitリポジトリ内の個々のファイルのエンコードされたコンテンツを表示する権限。ファイルの中身を見れるようにするのに必要。 codecommit:GitPush ローカルリポジトリからAWSCodeCommitリポジトリに情報をプッシュする権限。 ※"Resource"の設定は、ビルドプロジェクトを作成するために必要なIAMのCode Commitの項と同じで、"Resource": "arn:aws:codecommit:ap-northeast-1:xxxxxxxxxxxx:go" S3 action名 説明 s3:ListBucket Amazon S3バケット内のオブジェクトの一部またはすべてを一覧表示する権限。build成果物を確認するために必要。 ※"Resource"の設定は、ビルドプロジェクトを作成するために必要なIAMのS3のCreateBucketと同じで、"Resource": "arn:aws:s3:::go-build-console" Cloud Watch Logs { "Version": "2012-10-17", "Statement": [ { "Sid": "VisualEditor0", "Effect": "Allow", "Action": "logs:GetLogEvents", "Resource": "arn:aws:logs:ap-northeast-1:xxxxxxxxxxxx:log-group:/aws/codebuild/go-build-console:log-stream:*" } ] } action名 説明 logs:GetLogEvents 指定されたログストリームからログイベントを取得する権限。ビルド結果のlogを見るために必要。 IAM { "Version": "2012-10-17", "Statement": [ { "Sid": "VisualEditor0", "Effect": "Allow", "Action": "iam:UploadSSHPublicKey", "Resource": "arn:aws:iam::xxxxxxxxxxxx:user/codebuild-only" } ] } action名 説明 iam:UploadSSHPublicKey SSH公開鍵をアップロードし、それを指定されたIAMユーザーに関連付ける権限。gitの操作をSSHで行うのに必要。 おまけ S3のIAMで追加した方がいいと思われるもの 以下はBucketを作成した時にブロックパブリックアクセス (バケット設定)のパブリックアクセスをすべて ブロックがオフになっている状態を、オンにする修正するのに必要な権限 { "Version": "2012-10-17", "Statement": [ { "Sid": "VisualEditor0", "Effect": "Allow", "Action": [ "s3:GetBucketPublicAccessBlock", "s3:PutBucketPublicAccessBlock" ], "Resource": "arn:aws:s3:::go-build-console" } ] } ・参考：Amazon S3 ストレージへのパブリックアクセスのブロック Permissions Code Buildのlog [Container] 2021/09/01 13:01:30 Waiting for agent ping [Container] 2021/09/01 13:01:33 Waiting for DOWNLOAD_SOURCE [Container] 2021/09/01 13:01:38 Phase is DOWNLOAD_SOURCE [Container] 2021/09/01 13:01:38 CODEBUILD_SRC_DIR=/codebuild/output/src575922894/src/git-codecommit.ap-northeast-1.amazonaws.com/v1/repos/go [Container] 2021/09/01 13:01:38 YAML location is /codebuild/output/src575922894/src/git-codecommit.ap-northeast-1.amazonaws.com/v1/repos/go/.aws/buildspec.yml [Container] 2021/09/01 13:01:38 No commands found for phase name: install [Container] 2021/09/01 13:01:38 Processing environment variables [Container] 2021/09/01 13:01:38 Selecting 'golang' runtime version '1.16' based on manual selections... [Container] 2021/09/01 13:01:38 Running command echo "Installing Go version 1.16 ..." Installing Go version 1.16 ... [Container] 2021/09/01 13:01:38 Running command goenv global $GOLANG_16_VERSION [Container] 2021/09/01 13:01:38 Moving to directory /codebuild/output/src575922894/src/git-codecommit.ap-northeast-1.amazonaws.com/v1/repos/go [Container] 2021/09/01 13:01:39 Registering with agent [Container] 2021/09/01 13:01:39 Phases found in YAML: 4 [Container] 2021/09/01 13:01:39 INSTALL: 0 commands [Container] 2021/09/01 13:01:39 PRE_BUILD: 4 commands [Container] 2021/09/01 13:01:39 BUILD: 2 commands [Container] 2021/09/01 13:01:39 POST_BUILD: 2 commands [Container] 2021/09/01 13:01:39 Phase complete: DOWNLOAD_SOURCE State: SUCCEEDED [Container] 2021/09/01 13:01:39 Phase context status code: Message: [Container] 2021/09/01 13:01:39 Entering phase INSTALL [Container] 2021/09/01 13:01:39 Phase complete: INSTALL State: SUCCEEDED [Container] 2021/09/01 13:01:39 Phase context status code: Message: [Container] 2021/09/01 13:01:39 Entering phase PRE_BUILD [Container] 2021/09/01 13:01:39 Running command echo "go version" go version [Container] 2021/09/01 13:01:39 Running command go version go version go1.16.4 linux/amd64 [Container] 2021/09/01 13:01:40 Running command echo "go get aws lambda library" go get aws lambda library [Container] 2021/09/01 13:01:40 Running command go get github.com/aws/aws-lambda-go/lambda go: downloading github.com/aws/aws-lambda-go v1.26.0 [Container] 2021/09/01 13:01:50 Phase complete: PRE_BUILD State: SUCCEEDED [Container] 2021/09/01 13:01:50 Phase context status code: Message: [Container] 2021/09/01 13:01:50 Entering phase BUILD [Container] 2021/09/01 13:01:50 Running command echo "go build" go build [Container] 2021/09/01 13:01:50 Running command GOOS=linux go build -o main lambda.go go: downloading github.com/jinzhu/configor v1.2.1 go: downloading github.com/slack-go/slack v0.9.4 go: downloading github.com/BurntSushi/toml v0.3.1 go: downloading gopkg.in/yaml.v2 v2.2.3 go: downloading github.com/pkg/errors v0.8.0 go: downloading github.com/gorilla/websocket v1.4.2 [Container] 2021/09/01 13:01:56 Phase complete: BUILD State: SUCCEEDED [Container] 2021/09/01 13:01:56 Phase context status code: Message: [Container] 2021/09/01 13:01:56 Entering phase POST_BUILD [Container] 2021/09/01 13:01:56 Running command echo "create zip" create zip [Container] 2021/09/01 13:01:56 Running command zip main.zip main config.yaml adding: main (deflated 50%) adding: config.yaml (deflated 71%) [Container] 2021/09/01 13:01:57 Phase complete: POST_BUILD State: SUCCEEDED [Container] 2021/09/01 13:01:57 Phase context status code: Message: [Container] 2021/09/01 13:01:57 Expanding base directory path: . [Container] 2021/09/01 13:01:57 Assembling file list [Container] 2021/09/01 13:01:57 Expanding . [Container] 2021/09/01 13:01:57 Expanding file paths for base directory . [Container] 2021/09/01 13:01:57 Assembling file list [Container] 2021/09/01 13:01:57 Expanding main.zip [Container] 2021/09/01 13:01:57 Found 1 file(s) [Container] 2021/09/01 13:01:57 Phase complete: UPLOAD_ARTIFACTS State: SUCCEEDED [Container] 2021/09/01 13:01:57 Phase context status code: Message:

ユーザーグループにIAMポリシーを割り当てよう 1.今回の目的： 「Administrators」というユーザーグループに、「Billing」というIAMポリシーを割り当てます。 今はカスタマー管理のポリシーが1つだけ割当たってます。 IAMポリシー「Billing」はマネコンでタイプを見ると「ジョブ機能」と書いてあります。 「職務機能のAWS管理ポリシー」というやつのようです。 SCSの教材で見かけたので、SCS受験する方は問題に出現するかもしれません。 ◆(AWS公式docs)職務機能の AWS 管理ポリシー 2.CloudShellの立ち上げ AWSマネジメントコンソールのCloudShellアイコンをクリックしてCloudShellを開いていきます。 ようこそ的な画面は「Close」で閉じます。 CloudShellが立ち上がってきたら、コマンドを打ち込んでいきます。 3.変数の設定 「IAM_GROUP_NAME」という変数に、ユーザーグループ名「Administrators」を設定します。（入力したらEnter） IAM_GROUP_NAME='Administrators' 「IAM_POLICY_NAME」という変数に、今回割り当てたいIAMポリシー「Billing」を設定します。 IAM_POLICY_NAME='Billing' ヒアドキュメントで、変数に値が正しく入っているか確認します。 cat << END #1.IAM_GROUP_NAME:"Administrators" IAM_GROUP_NAME="${IAM_GROUP_NAME}" #2.IAM_POLICY_NAME:"Billing" IAM_POLICY_NAME="${IAM_POLICY_NAME}" END 出力例 #1.IAM_GROUP_NAME:"Administrators" IAM_GROUP_NAME="Administrators" #2.IAM_POLICY_NAME:"Billing" IAM_POLICY_NAME="Billing" (ちょっと脱線)ヒアドキュメントとはなんぞや 例えば上記の変数の中身確認をする場合、ヒアドキュメントを使わないと #1.IAM_GROUP_NAME:"Administrators" echo ${IAM_GROUP_NAME} #2.IAM_POLICY_NAME:"Billing" echo ${IAM_POLICY_NAME} とechoを連発する必要があります。 cat << END ほにゃらら ほにゃらら END といった感じで、cat << xxx ～ xxx　の ～ の部分に表示させたい変数や文字列を記載することで、シンプルに記載できます。 xxxの部分はなんでもよいです。上記は「END」と書きましたが、「EXIT」や「EOF」などでもOKです。 cat << HENSUUKAKUNIN #1.IAM_GROUP_NAME:"Administrators" IAM_GROUP_NAME="${IAM_GROUP_NAME}" #2.IAM_POLICY_NAME:"Billing" IAM_POLICY_NAME="${IAM_POLICY_NAME}" HENSUUKAKUNIN こんなのでもちゃんと表示されます。 続いてIAMポリシーのARNを取得します。 ARNとは「Amazon Resource Name」のことでAWSリソースを一意に識別するための記号のようなものです。 ◆Amazon リソースネーム (ARN) aws iam list-policiesコマンドを利用してARNを取得し、取得したARNを「IAM_POLICY_ARN」という変数に格納していきます。 IAM_POLICY_ARN=$( aws iam list-policies \ --scope AWS \ --max-items 1000 \ --query "Policies[?PolicyName==\`${IAM_POLICY_NAME}\`].Arn" \ --output text \ ) \ && echo "${IAM_POLICY_ARN}" 出力例(5~10秒かかります) arn:aws:iam::aws:policy/job-function/Billing list-policies 「IAM_POLICY_NAME」変数に格納されている「Billing」という名前のポリシーのARNを検索します。 --scope 結果のフィルタリングに使用するスコープです。 今回はAWS管理ポリシー(職務機能のポリシー)から目的の「Billing」を探せばよいので、スコープをAWSに設定しています。 「--scope」を使用しない場合は、自身で作成したポリシーも含めすべてのポリシー名から目的のARNを探すような挙動をするようです。なくても動きます。 --max-items (整数) コマンドの出力で返されるアイテムの総数です。 現在AWS管理ポリシーの数が800くらいなので1000と指定しています。(管理ポリシーの数が1000を超えたらどうなるのでしょう…？) --query 目的のARNをフィルタリングして抽出します。 (詳細はdocsをご参照ください…) https://docs.aws.amazon.com/ja_jp/cli/latest/userguide/cli-usage-filter.html --output text 出力をtext形式に設定しています。--output json、--output yaml、--output yaml-streamなど他の出力形式を指定する場合挙動が少し異なるようですのでリファレンスでご確認ください。https://docs.aws.amazon.com/ja_jp/cli/latest/userguide/cli-usage-filter.html iamコマンドのリファレンスはこちらになります。 ◆iam ヒアドキュメントで、「IAM_POLICY_ARN」という変数に目的のARNが格納できているか確認します。 cat << END #IAM_POLICY_ARN:"arn:aws:iam::aws:policy/job-function/Billing" IAM_POLICY_ARN="${IAM_POLICY_ARN}" END 出力例 #IAM_POLICY_ARN:"arn:aws:iam::aws:policy/job-function/Billing" IAM_POLICY_ARN="arn:aws:iam::aws:policy/job-function/Billing" 4.IAMポリシーのアタッチ では実際にユーザーグループにIAMポリシーをアタッチしていきます。 aws iam attach-group-policy \ --group-name ${IAM_GROUP_NAME} \ --policy-arn ${IAM_POLICY_ARN} ※出力なし IAMグループ"Administrators"にAWS管理ポリシー(職務機能のポリシー)"Billing"がアタッチされていることを確認します。 aws iam list-attached-group-policies \ --group-name ${IAM_GROUP_NAME} \ --query "AttachedPolicies[?PolicyName == \`${IAM_POLICY_NAME}\`].PolicyName" \ --output text 出力例 Billing マネコンから見ると、ユーザーグループ「Administrators」の許可タブからAWS管理ポリシー(職務管理ポリシー)「Billing」が追加されたことがわかります。 IAMポリシーのデタッチはのちほど…(力尽き)

ユーザーグループにIAMポリシーを割り当てよう 1.今回の目的： AWS CLIで、「Administrators」というユーザーグループに、「Billing」というAWS管理のIAMポリシーを割り当てます。 私のアカウントでAWSマネジメントコンソールにログインし、IAMコンソールからユーザーグループ「Administrators」を見ると、今はカスタマー管理のポリシーが1つだけ割当たっている状態です。 IAMコンソールの左ウィンドウ「ポリシー」メニューから、IAMポリシー「Billing」を検索して見てみると、タイプ欄に「ジョブ機能」と書いてあります。 「職務機能のAWS管理ポリシー」というやつのようです。 SCSの教材で見かけたので、SCS受験する方は問題に出現するかもしれません。 ◆(AWS公式docs)職務機能の AWS 管理ポリシー 2.前提条件 IAMに対してフル権限のあるユーザで実施してください。 3.CloudShellの立ち上げ AWSマネジメントコンソールのCloudShellアイコンをクリックしてCloudShellを開いていきます。 ようこそ的な画面は「Close」で閉じます。 CloudShellが立ち上がってきたら、コマンドを打ち込んでいきます。 4.変数の設定 「IAM_GROUP_NAME」という変数に、ユーザーグループ名「Administrators」を設定します。（入力したらEnter） IAM_GROUP_NAME='Administrators' 「IAM_POLICY_NAME」という変数に、今回割り当てたいIAMポリシー名「Billing」を設定します。 IAM_POLICY_NAME='Billing' ヒアドキュメントで、変数に値が正しく入っているか確認します。 cat << END #1.IAM_GROUP_NAME:"Administrators" IAM_GROUP_NAME="${IAM_GROUP_NAME}" #2.IAM_POLICY_NAME:"Billing" IAM_POLICY_NAME="${IAM_POLICY_NAME}" END 出力例 #1.IAM_GROUP_NAME:"Administrators" IAM_GROUP_NAME="Administrators" #2.IAM_POLICY_NAME:"Billing" IAM_POLICY_NAME="Billing" 上下の文字列が同じであれば、変数に正しい値が格納されています。 (ちょっと脱線)ヒアドキュメントとはなんぞや 例えば上記の変数の中身を確認をする場合、ヒアドキュメントを使わないと #1.IAM_GROUP_NAME:"Administrators" echo ${IAM_GROUP_NAME} #2.IAM_POLICY_NAME:"Billing" echo ${IAM_POLICY_NAME} とechoを連発する必要があります。 cat << END ほにゃらら ほにゃらら END といった感じで、cat << xxx ～ xxx　の ～ の部分に表示させたい変数や文字列を記載することで、シンプルに記載できます。 xxxの部分はなんでもよいです。上記はENDと書きましたが、EXITやEOFなどでもOKです。 cat << LOVEAWSCLI #1.IAM_GROUP_NAME:"Administrators" IAM_GROUP_NAME="${IAM_GROUP_NAME}" #2.IAM_POLICY_NAME:"Billing" IAM_POLICY_NAME="${IAM_POLICY_NAME}" LOVEAWSCLI こんなのでもちゃんと表示されます。 続いてIAMポリシーのARNを取得します。 ARNとは「Amazon Resource Name」のことでAWSリソースを一意に識別するための記号のようなものです。ARNの構造は以下docsからご確認ください。 ◆Amazon リソースネーム (ARN) IAMポリシーの割り当てではIAMポリシーのARNが必要になるので、あらかじめ取得しておきます。 aws iam list-policiesコマンドを使用してARNを取得し、取得したARNを「IAM_POLICY_ARN」という変数に格納していきます。 IAM_POLICY_ARN=$( aws iam list-policies \ --scope AWS \ --max-items 1000 \ --query "Policies[?PolicyName==\`${IAM_POLICY_NAME}\`].Arn" \ --output text \ ) \ && echo "${IAM_POLICY_ARN}" 出力例(5~10秒かかります) arn:aws:iam::aws:policy/job-function/Billing list-policies 「IAM_POLICY_NAME」変数に格納されている「Billing」という名前のポリシーのARNを検索(リスト表示)します。 --scope 結果のフィルタリングに使用するスコープです。 今回はAWS管理ポリシー(職務機能のポリシー)から目的の「Billing」を探せばよいので、スコープをAWSに設定しています。 その他設定可能な値 ALL AWS Local --scopeを使用しない場合は、自身で作成したポリシーも含めすべてのポリシー名から目的のARNを探すような挙動をするようです。なくても動きます。 --max-items (整数) コマンドの出力で返されるアイテムの総数です。 現在AWS管理ポリシーの数が800くらいなので1000と指定しています。--max-itemsを指定しないで、かつカスタマー管理のポリシー数がすごくたくさんある場合、一回の検索では表示しきれず「NextToken」となってしまい、目的のARNを取得するのにもうひと手間かかるようです。（詳細はリファレンスをご確認ください…） --query 目的のARNをフィルタリングして抽出します。 (詳細はdocsをご参照ください…) https://docs.aws.amazon.com/ja_jp/cli/latest/userguide/cli-usage-filter.html --output text 出力をtext形式に設定しています。--output json、--output yaml、--output yaml-streamなど他の出力形式を指定する場合挙動が少し異なるようですのでリファレンスでご確認ください。https://docs.aws.amazon.com/ja_jp/cli/latest/userguide/cli-usage-filter.html iamコマンドのリファレンスはこちらになります。その他のオプションもこちらからご確認ください。 ◆iam ヒアドキュメントで、「IAM_POLICY_ARN」という変数に目的のARNが格納できているか確認します。 cat << END #IAM_POLICY_ARN:"arn:aws:iam::aws:policy/job-function/Billing" IAM_POLICY_ARN="${IAM_POLICY_ARN}" END 出力例 #IAM_POLICY_ARN:"arn:aws:iam::aws:policy/job-function/Billing" IAM_POLICY_ARN="arn:aws:iam::aws:policy/job-function/Billing" 5.IAMポリシーのアタッチ では実際にユーザーグループにIAMポリシーをアタッチしていきます。 aws iam attach-group-policy \ --group-name ${IAM_GROUP_NAME} \ --policy-arn ${IAM_POLICY_ARN} ※出力なし attach-group-policy IAMポリシーをユーザーグループに割り当てます。 --group-name IAMポリシーを割り当てる対象のユーザーグループを指定します。 --policy-arn 割り当てる対象のIAMポリシー（今回は「Billing」）を指定します。 IAMグループ"Administrators"にAWS管理ポリシー(職務機能のポリシー)"Billing"がアタッチされていることを確認します。 aws iam list-attached-group-policies \ --group-name ${IAM_GROUP_NAME} \ --query "AttachedPolicies[?PolicyName == \`${IAM_POLICY_NAME}\`].PolicyName" \ --output text 出力例 Billing list-attached-group-policies 指定されたユーザーグループに関連付けられているすべての管理対象ポリシーを一覧表示します。 --group-name IAMポリシー一覧を表示させたい対象のユーザーグループを指定します。 --query "AttachedPolicies[?PolicyName == \`${IAM_POLICY_NAME}\`].PolicyName" AttachedPolicies←アタッチされてるポリシーの中から [?PolicyName == \${IAM_POLICY_NAME}`].PolicyName`←該当のポリシーを抽出 マネコンから見ると、ユーザーグループ「Administrators」の許可タブからAWS管理ポリシー(職務管理ポリシー)「Billing」が追加されたことがわかります。 IAMポリシーのデタッチはのちほど…(力尽き) 参考

前提 WAF のログを Kinesis Data Firehose 経由で S3 に記録していること Athena に WAF ログのテーブルを作成ずみであること まとめると、大体ここらへん HTTP headerの内容を取得したい Stack Overflowの記事の様に、UNNESTとMAP_AGGで、header['name'] = valueで扱える様にする。 例えば、header['user-agent']でUser-Agentが取得できる JWTをデコードし内容を取得したい Amazon Athena は Presto/Trino (Presto SQL is now Trino) ベースなので、 Trino の Issue に SQL で JWT アクセスしたいというのがあがってる。JWT自体をデコードする関数等はないが、とりあえず次の方法で取得できる（暗号化されてないもの) AuthorizationヘッダーからBearerを削除してJWTだけにする ドットをデリミタとして分割してペイロード部分を抜き出し Base64デコードし UTF-8文字列化し JSONとして返す JSONPathで目的の値を取り出し（例: subクレーム=ユーザーの一意識別子) JSONから文字列にキャスト クエリー例 SQL例 LOWER(f.name)なのはクライアント実装によって異なるってのもあるけど、なぜかWAFのログ上同じブラウザーでもUser-Agentだったりuser-agentだったり(原因は追及してない)なので同一で扱うため。 WITH access_log AS ( SELECT timestamp, action, httprequest.clientip, httprequest.country, MAP_AGG(LOWER(f.name), f.value) AS header FROM waf_logs, UNNEST(httprequest.headers) AS t(f) GROUP BY 1, 2, 3, 4 ) SELECT FROM_UNIXTIME(timestamp/1000) AS timestamp, header['user-agent'] AS ua, CAST( JSON_EXTRACT( JSON_PARSE( FROM_UTF8( FROM_BASE64( SPLIT_PART(REPLACE(header['authorization'], 'Bearer '), '.', 2) ) ) ), '$.sub' ) AS VARCHAR ) AS subject FROM access_log; 結果例 timestamp ua subject 2021-09-01 01:23:45.000 Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/92.0.4515.159 Safari/537.36 248289761001

ローカルからAWSのEC2にファイルをデプロイする ローカルのPC上からAWSのEC2にファイル、フォルダーをデプロイする方法についてまとめます。こちらは備忘録のため完璧に整理された記事とは言い難いです。（少しずつ精査していきます） 大まかな手順 *パブリックサブネットにEC2を配置する *「git」をインストールする *Tera Termなどでssh接続を行う *githubのアカウント登録をし、空のリポジトリを作成する *githubのリポジトリにローカルのファイルをpushする （ローカルのファイルをコピーしてネット上に配備する） *EC2にsshで入り、git clone コマンド で対象のリポジトリをダウンロードする 参考 +AWS EC2 AmazonLinux2 Gitをインストールする - Qiita +git clone xxxx　 githubリポジトリの画面右のCodeを押して、https://xxxxが対象のリンク

Djangoで静的ファイルをS3に保存する一番簡単な方法 調べたらカスタムストレージクラスを作る方法がいろいろ出てきたけど意味不明だったので自分用に。 多分これが一番簡単だと思います。 【参考】 - Django mediaファイルとAWS S3 - django-storages pyをいじっていく 1. models.py , forms.py 一般的な方法でPhotoモデル,Photoformモデルを作成する 自分はDjnagoBrosというサイトで紹介されている写真投稿サイトを作って、それを改造する形で実装しました。 2. project_name/urls.py 本番環境想定の設定にしてみる if settings.DEBUG: urlpatterns += static( settings.MEDIA_URL, document_root=settings.MEDIA_ROOT ) settings.py の DEBUG が True の場合だけ Local に保存されるように設定 必要ライブラリをインストールする S3にアップするにはやはりAWSと連携するライブラリを使う必要がある しっかり用意されてるので、それを使ってく ※pyenvを使っている場合、仮想環境に入っておくことを忘れないように $ pip install boto3 $ pip install django-storages S3にバケットを作成する コンソールで作成 バケットポリシー ポリシーはdjango-storageのUsageにあるものをコピーしてくる AWSIDやバケット名は自分のやつに変える { "Version": "2012-10-17", "Statement": [ { "Sid": "VisualEditor0", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::AWS_ACCOUNT_ID:user/bucket_name" }, "Action": [ "s3:PutObject", "s3:GetObjectAcl", "s3:GetObject", "s3:ListBucket", "s3:DeleteObject", "s3:PutObjectAcl" ], "Resource": [ "arn:aws:s3:::bucket_name/*", "arn:aws:s3:::bucket_name" ] } ] } IAM ユーザ作成 S3の操作権限を持つIAMユーザを作る - 名前 : なんでもいいです - プログラムによるアクセス - S3FullAccess (めんどくさいので) (絞る場合、↑のポリシーで指定したものだけ入れたらOK) - 認証情報 : DLしてローカルPCにでも保存しておきます settings.py 編集 DEBUGモード解除 # SECURITY WARNING: don't run with debug turned on in production! DEBUG = False # Falseにする ALLOWED_HOSTS = ["127.0.0.1", "xxx.xxx.xxx.xxx"] # DEBUG = False の時は指定しないと起動できない # この辺はまだよくわかってないので今回はとりあえず127.0.0.1を許可しておく INSTALLED_APPS に 'storages' 追加 pip でインストールしておいたdjango-storageを使うために必要 INSTALLED_APPS = [ 'django.contrib.admin', 'django.contrib.auth', 'django.contrib.contenttypes', 'django.contrib.sessions', 'django.contrib.messages', 'django.contrib.staticfiles', 'django_cleanup', 'app', 'storages', # 追加 ] static設定 # STATIC_URL = '/static/' STATICFILES_DIRS = ( os.path.join(BASE_DIR, "static"), ) # Media files # MEDIA_ROOT = os.path.join(BASE_DIR, 'media') # EDIA_URL = '/media/' # staticファイルの参照先 STATICFILES_STORAGE = 'storages.backends.s3boto3.S3Boto3Storage' # mediaファイル保存先 DEFAULT_FILE_STORAGE = 'storages.backends.s3boto3.S3Boto3Storage' STATICFILES_DIRS : プロジェクトのアプリで使うstaticファイルを格納している、サーバ内の場所を指定する (今回は project_name/static) STATICFILES_STORAGE : CSSなどを参照するstaticファイルの保管先を指定 DEFAULT_FILE_STORAGE : 投稿機能によってアップロードされた写真の保管先を指定 'storages.backends.s3boto3.S3Boto3Storage' を指定することで↓のS3設定を参照するようになる 元のmedia設定は不要なのでコメントアウトか、消しておく S3設定 # アクセスキーID AWS_ACCESS_KEY_ID = 'AKIA**************' # シークレットアクセスキー AWS_SECRET_ACCESS_KEY = '*************************' # バケット名 AWS_STORAGE_BUCKET_NAME = 'bucket_name' # 保存先URL STATIC_URL = 'https://%s.s3.ap-northeast-1.amazonaws.com/' % AWS_STORAGE_BUCKET_NAME AWS_LOCATION = 'static' AWS_ACCESS_KEY_ID , AWS_SECRET_ACCESS_KEY : IAM作成時にDLしてきた認証情報を入力する AWS_STORAGE_BUCKET_NAME : さっき作ったバケット名を入力する STATIC_URL : バケットのURLを入力する 適当にファイルおいて、AWSコンソールでそのファイルの詳細の「オブジェクトURL」を見たらわかる AWS_LOCATION : static関係のファイルをコピーする際、バケット内にディレクトリを作りたい場合指定 今回は bucket_name/static/静的ファイル という構造にしたいので、'static' を入力 必須項目は以上。 他にもいろいろ指定できるけど、とりあえず↑だけでよさそう collectstatic 実行 このままだとdjangoがstaticを認識できないので、collectstaticをいうコマンドを使ってstaticファイルを同期する プロジェクトのディレクトリ上で $ python manage.py collectstatic You have requested to collect static files at the destination location as specified in your settings. This will overwrite existing files! Are you sure you want to do this? Type 'yes' to continue, or 'no' to cancel: yes ← yesを入力 129 static files copied. collectstaticがうまくいって、S3のバケットに static ディレクトリ、その中に admin , css ディレクトリができていればOK！ 画像のS3アップロード確認 runnserver して 実際に画像を投稿してみる →S3の static ディレクトリの中に photos/ が作成されて、その中に実際の画像ファイルが保存されていればOK！ 画像保存先のディレクトリ名はモデルで指定↓ models.py class Photo(models.Model): title = models.CharField(max_length=150) comment = models.TextField(blank=True) image = models.ImageField(upload_to='photos') # ←これ category = models.ForeignKey(Category, on_delete=models.PROTECT) user = models.ForeignKey(User, on_delete=models.CASCADE) created_at = models.DateTimeField(auto_now=True) def __str__(self): return self.title

リモートリポジトリとしてCodeCommitをGitクライアントから利用する場合のアクセス方法について記載させて頂きます。 1．CodeCommitへのアクセス方法の種類 CodeCommitのユーザアカウントは、IAMユーザと紐づいているため、AWSの他の機能を利用しない（マネジメントコンソールへのログインが不要な）場合もIAMユーザの発行が必要となります。 CodeCommitと通信するプロトコルは以下の3種類から選択する必要があります。 HTTPS/SSHはGithubを使用する場合と同じような感じですが、GRC（Git-Remote-Codecommit）はCodeCommit独自の方法です。 プロトコル 説明 HTTPS GitHubと同様の通常のHTTPSによるアクセス。IAMユーザから専用のID/PASSを発行して認証する。 SSH クライアント側で秘密鍵と公開鍵を作成し、IAMユーザ側に公開鍵を登録することで、公開鍵認証を行う。 HTTPS（GRC） CodeCommit用のクライアントツール。AWS CLIのProfileと連携させることができ、複数のAWSアカウントのCodeCommit利用するときやスイッチロールの権限を使いCodeCommitにアクセスしたい場合はこちらを使う必要がある。 2．設定方法：HTTPSの場合 (1) IAMユーザの認証情報からCodeCommit専用のID/Passwordを発行する CodeCommit上でのリポジトリの作成、IAMユーザの作成方法は省略します。 マネジメントコンソールを以下の順序で操作し、CodeCommitのID/Passwordを生成します。 [IAM]→[ユーザー]→[<対象のIAMユーザ>]→[タブ：認証情報]→[AWS CodeCommit の HTTPS Git 認証情報]→[認証情報の生成] (2) ローカル環境からCodeCommitのリモートリポジトリをClone $ git clone https://git-codecommit.ap-northeast-1.amazonaws.com/v1/repos/MY-REMOTE-REPOSITORY Cloning into 'MY-REMOTE-REPOSITORY'... fatal: unable to access 'https://git-codecommit.ap-northeast-1.amazonaws.com/v1/repos/MY-REMOTE-REPOSITORY/': server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none そのままだとSSL証明書のエラーが出てしまうので一旦以下の設定で回避 $ git config --global http.sslverify false 以下も念のため設定 参考：https://dev.classmethod.jp/articles/credential-helper-resolves-codecommit-error/ git config --global --unset credential.helper Git Clone git clone https://git-codecommit.ap-northeast-1.amazonaws.com/v1/repos/MY-REMOTE-REPOSITORY 2．設定方法：SSHの場合 省略します。 3．設定方法：HTTPS(GRC)の場合 Git-Remote-Codecommitの利用シーン 一つのGitクライアント（Cloud9や、EC2 Linux、あるいはPCなど）から、複数のAWSアカウントのCodeCommitを使いたい。 各AWSアカウントへのユーザアカウント登録は、IAMユーザを登録している場合や、IAMロールのみでスイッチロールする場合が混在している。 AWS CLIと同じようにプロファイルを切り替え各CodeCommitのIAM設定に合わせた認証情報でアクセスしたい。 CodeCommitへのアクセスにおいても、マネジメントコンソールへのアクセスと同様アクセスできるようにする。 IAMユーザがあるAWSアカウントのCodeCommitへは、そのIAMユーザ権限で認証 IAMユーザが無く、他のAWSアカウントからスイッチロールしているAWSアカウントのCodeCommitへは、同様にスイッチロールで認証 必要となる設定 上記要件を実現するには、Git-Remote-Codecommit以外にAWS CLIが必要となります。 (1)Git-Remote-CodeCommitのインストール Git-Remote-CodeCommitのインストール（Ubuntuの場合） $ sudo apt install python3-pip $ sudo pip3 install git-remote-codecommit (2)AWSプロファイルの設定 AWS CLIのインストールは省略 プロファイルの設定 account1は、IAMユーザが登録されているアカウント用 account2は、account1からのスイッチロールでアクセスするアカウント用 .aws/config [profile account1] region = ap-northeast-1 output = json [profile account2] region = ap-northeast-1 output = json role_arn = arn:aws:iam::111111111111:role/iam-role-for-codecommit source_profile = account1 クレデンシャルの登録（値はマスクしてます） .aws/credentials [account1] aws_access_key_id = *** aws_secret_access_key = *** (3)動作確認 以下の書式でプロファイルとリポジトリ名を指定しCloneします。 git clone codecommit::ap-northeast-1://<プロファイル名>@<リポジトリ名> account1のプロファイルからclone（masterブランチを指定） $ git clone -b master codecommit::ap-northeast-1://account1@MY-REMOTE-REPOSITORY Cloning into 'MY-REMOTE-REPOSITORY'... remote: Counting objects: 209, done. Receiving objects: 100% (209/209), 42.22 KiB | 192.00 KiB/s, done. Resolving deltas: 100% (125/125), done. 別のプロファイルでclone（ブランチ指定なし） $ git clone codecommit::ap-northeast-1://account2@MY-REMOTE-ACCOUNT2-REPOSITORY

はじめに LambdaとAPIサーバを組み合わせたサービスを開発する際、Lambdaのアクセス制御をしたいケースがあるかと思います。 その際、IPアドレスでアクセス制御を行うことが多いと思うのですが、LambdaのIPアドレスは基本的には固定化されていません。 さらに、Lambdaが使うIPアドレス範囲も結構広く、ちょくちょく変わるため、IPアドレスを固定化しないと制御が難しい。 ⇒ 上記について、LambdaのIPアドレスを固定化させる方法を紹介します。 前提 VPC,Lambdaが作成されていること。 LambdaがVPCに紐づいていること。 手順 インターネットゲートウェイの作成 パブリックサブネットの作成 インターネットゲートウェイの割り当て プライベートサブネットの作成 NATゲートウェイの作成 プライベートサブネットとNATゲートウェイを紐づける 最終的な構成としては、下記のようになります。 順に紹介していきます。 インターネットゲートウェイの作成 インターネットゲートウェイは、VPC とインターネットとの間の通信を可能にする VPC コンポーネントであり、冗長性と高い可用性を備えており、水平スケーリングが可能です。 https://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/VPC_Internet_Gateway.html 作成済みのVPCを選択し、左ペインの「インターネットゲートウェイ」>「インターネットゲートウェイの作成」を押下します。 任意のタグをつけて、作成しましょう。 パブリックサブネットの作成 作成済みのVPCを選択し、左ペインの「サブネット」>「サブネットの作成」を押下します。 既存のVPCを選択すると、下記のように表示されます。 パブリックサブネットだとわかりやすいように、サブネット名に「public-xxxxx」のような名前を付けておきましょう。 IpV4 CIDRブロックは、紐づいているVPCの範囲内に収まるように設定しましょう。 上記入力して、「サブネットを作成」を押下。 インターネットゲートウェイの割り当て 先ほど作成したサブネットは、今の段階ではパブリックとは言えません。 インターネットゲートウェイを割り当てて、パブリックサブネットとしてあげましょう。 作成済みのVPCを選択し、左ペインの「サブネット」>作成したサブネットを選択します。 その後、紐づいているルートテーブルを選択します。 (ルート「0.0.0.0/0」の設定はまだないかと思います。こちらを今から追加していきます。) 「ルートテーブル：xxxxxxxxxx(リンク)」となっているので、リンク部分を押下します。 「ルートを編集」を押下します。 ここで下記を入力し、「変更を保存」を押下します。 送信先：0.0.0.0/0 ターゲット：インターネットゲートウェイ⇒1.で作成したインターネットゲートウェイを選択 これで、パブリックサブネットが作成できました。 プライベートサブネットの作成 次に、プライベートサブネットを作成していきます。 手順はパブリックサブネットを作った時と同様です。 作成済みのVPCを選択し、左ペインの「サブネット」>「サブネットの作成」を押下します。 既存のVPCを選択すると、下記のように表示されます。 プライベートサブネットだとわかりやすいように、サブネット名に「private-xxxxx」のような名前を付けておきましょう。 IpV4 CIDRブロックは、紐づいているVPCの範囲内に収まるように設定しましょう。 上記入力して、「サブネットを作成」を押下。 今の段階で、ここまでできてます。 NATゲートウェイの作成 次に、NATゲートウェイを作成していきます。 NAT ゲートウェイは、ネットワークアドレス変換 (NAT) サービスです。NAT ゲートウェイを使用すると、プライベートサブネット内のインスタンスは VPC 外のサービスに接続できますが、外部サービスはそれらのインスタンスとの接続を開始できません。 https://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/vpc-nat-gateway.html#nat-gateway-creating 作成済みのVPCを選択し、左ペインの「NATゲートウェイ」>「NATゲートウェイを作成」を押下します。 下記のように入力して、「NATゲートウェイを作成」を押下します。 名前：任意 サブネット：public-xxxx 接続タイプ：パブリック Elastic IP：「Elastic IPの割り当て」を押下し、作成 プライベートサブネットとNATゲートウェイを紐づける 今の段階で、ここまでできてます。 プライベートサブネットとNATゲートウェイが紐づいていないため、そこの設定をしていきます。 作成済みのVPCを選択し、左ペインの「サブネット」>プライベートサブネットを選択します。 【インターネットゲートウェイの割り当て】の手順と同様に、ルートテーブルの「ルートを編集」を押下します。 下記のように入力し、「変更を保存」を押下 送信先：0.0.0.0/0 ターゲット：NATゲートウェイ⇒作成したNATゲートウェイ これでLambdaのIPアドレスが、NATゲートウェイのElastic IP Addressに固定化されます。

はじめに CloudWatchにはSyntheticsという、アプリケーションの死活監視(外形監視)を行うサービスがあります。 Canaryを作成し、APIのエンドポイントやWebページのリンクを設定することでそのエンドポイントをスクリプトで定期的に叩きに行き、落ちていた場合はSNSで通知や、CloudWatchAlarmを鳴らしたりできます。 以下公式説明です。 Amazon CloudWatch Synthetics を使用して、スケジュールに沿って実行される設定可能なスクリプトである Canary を作成し、エンドポイントと API をモニタリングできます。Canary は顧客と同じルートをたどり、同じアクションを実行します。これにより、アプリケーションに顧客トラフィックがない場合でも、顧客エクスペリエンスを継続的に検証できます。Canary を使用すると、顧客が問題を検出する前に問題を検出できます。 料金 料金はCanaryの実行回数に依存します。 1ヶ月あたり100回の実行まで無料枠があり、100回を超過すると1回あたり0.0019USDかかります。(東京リージョン) その他、Lambdaの実行料金・CloudWatch Logs・S3の料金などがかかるようです。 試してみる サンプルサイトの準備 ECRにある適当に作ったアプリのコンテナをAppRunnerでデプロイします。 (App Runner非常に楽でよいですよね..) 動作確認程度なので、トップページにリンクがある簡単なサンプルサイトを用意しました。 Syntheticsの設定 CloudWatch Syntheticsの設定を行います。 CloudWatchのメニューから「Synthetics Canaries - Canaryを作成」を選択します。 今回は、リンク切れチェッカー機能を試してみます。 以下デフォルトから変更を加えた部分です。 Canaryビルダー 名前：sample-canary アプリケーションまたはエンドポイントURL：AppRunnerから出力されたURL フォローされているリンクの最大数：10 スケジュール 一回実行(消し忘れ課金予防の為) データストレージ,アクセス許可 任意の適切な設定 設定画面もわかりやすくて良いです。 実行 作製したCanaryを選択し、「開始」を押下します。 終了後、「可用性」タブを見てみるとリンク先までチェックしていることがわかります。 次に、サーバから一つのファイルを削除し、再度起動します。 404を検知して失敗していることがわかります。 まとめ CloudWatch Syntheticsのリンク切れチェッカー機能を試してみました。 CloudWatch Syntheticsには、他にもページのスクリーンショットを取って比較し、差異があればアラームを上げる機能など様々な監視が行える機能があります。料金も高すぎるということはなく、設定も簡単なので積極的に使いたいですね。

Amazon Linux 2 に「nmon」をインストールする記事がなかったので、記載しておきます。 インスタンスの前提 ・OS（AMI）：Amazon Linux 2 AMI (HVM), SSD Volume Type　64 ビット (x86) ・インスタンス：t2.micro 　※arm版以外のインスタンスであれば問題ないと思います。 nmonのダウンロード 以下のURLからダウンロードしてください。この記事では、投稿時点で最新の「nmon16m_helpsystems.tar.gz」をダウンロードしています。 http://nmon.sourceforge.net/pmwiki.php?n=Site.Download nmonのインストール ・まずはTeraterm等SSHでインスタンスに接続してください。 ・インスタンスに接続後、rootでログインしてください。 sudo su - ・ダウンロードしたnmonをWinSCP等で「/tmp」直下にアップロードしてください。 ・「/usr/local/src」直下にファイルをコピーします。 cp nmon16m_helpsystems.tar.gz /usr/local/src/nmon16m_helpsystems.tar.gz ・ファイルを解凍し、「nmon_x86_64_rhel8」のパーミッションを「755」にします。 cd /usr/local/src tar zxf nmon16m_helpsystems.tar.gz chmod 755 nmon_x86_64_rhel8 ・「/usr/local/bin」直下に、「nmon_x86_64_rhel8」をコピーします。 cp nmon_x86_64_rhel8 /usr/local/bin/nmon これでインストールは完了です。 nmonの実行 「nmon」というコマンドを入力すると、nmonの画面が起動します。

awswranglerを使用してS3上の複数JSONファイルを結合し、S3に出力する 概要 AWS Data Wranglerを使用する。 読み込みには以下のJSONLファイルを圧縮した[sample1.json.gz][sample2.json.gz]を使用する。 sample1.jsonl {"id":1,"father":"Mark","mother":"Charlotte","children":["Tom"]} {"id":2,"father":"John","mother":"Ann","children":["Jessika","Antony","Jack"]} sample2.jsonl {"id":3,"father":"Bob","mother":"Monika","children":["Jerry","Karol"]} 事前準備 事前にawswranglerをインストールする $ pip install awswrangler コード import awswrangler as wr import pandas as pd from datetime import datetime,timezone # 入力 file_list = ["s3://testbucket/prefix/sample1.json.gz", "s3://testbucket/prefix/sample2.json.gz"] dfs = wr.s3.read_json(path=file_list, lines=True) # 出力 today = datetime.now(timezone.utc).strftime("%Y%m%dT%H%M%SZ") output_path = 's3://testbucket/output/{}'.format(today) wr.s3.to_json( df=dfs, path=output_path, orient="records", lines=True )

制作背景 友人とバイクでツーリングに行く際に、目的地までの道が重要なのだが道を紹介するサイトが少ない（もしくはバイク乗りなら誰でも知っているような内容しかなかった）という課題から、道やスポットを紹介し、道やスポットについて交流するWEBアプリを作ろうと考えました。 アプリ名 アプリ名: Tamari-Ba 「たまりば」と読みます。バイク乗り達が自分のバイク、好きな道、きつかった道、楽しかった道の駅等を語り合う「たまり場」をイメージして作成。 いつも行くあのカフェ、あの道の駅等の集まってダベれる「たまり場」のように好きなスポットについて語り合えるようなアプリに仕上げました。 ER図 インフラ構成図 ポートフォリオなので大きなアクセス負荷はかからないという見込みからコスト削減のためRDSは使わずに構築しました。 使用技術 フロントエンド HTML / CSS / Sass Bootstrap 4.5 バックエンド Ruby 2.7.2 Ruby on Rails 6.1.3 JavaScript GoogleMapsAPI(Maps JavaScript API / Geocoding API) インフラ MySQL 5.7 Nginx 1.20 Puma 5.3.2 AWS (VPC, EC2, S3) CircleCI Docker 20.10.8 Supervisor 機能一覧 ユーザー関連 機能 1 アカウント登録/削除機能 2 ログイン/ログアウト機能 3 ゲストログイン機能 4 アカウント情報編集機能 5 ユーザー情報 - 都道府県 6 ユーザー一覧 投稿機能 機能 1 投稿機能(CRUD) 2 GoogleMaps表示機能 3 マップ検索機能 4 座標取得/保存機能 5 マーカー設置機能 6 コメント機能 7 いいね機能 8 投稿検索 9 投稿一覧 できること 1. トップページ ログイン状態に応じて、リンクボタンを表示分けさせています。 非ログイン状態：ログイン/ゲストログイン ログイン状態：アプリトップ 最新３件分の投稿を表示 機能の概要を説明 投稿詳細イメージを表示 2. 新規投稿 マップの検索でマップ表示範囲を移動できます。 任意の箇所をクリックすることでマーカーを設置できます。 座標がデータベースに保存されます。 その他にも画像保存、タイトル、説明文を入力することが可能です。 3. 投稿一覧 投稿一覧を見ることができます。 検索機能があるので、投稿を検索することができます。 15投稿でページネーションが適用されます。 4. 投稿詳細 保存された座標を元に地図上にマーカーを表示します。 投稿者本人がログインしている場合には編集/削除ボタンが表示され実行できます。 保存された画像が表示されます。 コメント欄に入力して「コメントする」をクリックすることで、コメント可能です。 まとめ ポートフォリオとしてアウトプットすることで自分の実力がメキメキ付いてくるのを実感しました。 とはいえ、まだつけたい機能やフロント周りは改善の余地があるため転職活動を続けていく中で改善していこうと思います。 投稿記事 ポートフォリオ関連 ポートフォリオ作成に当たり、理解が難しかったもの、知識として足りないと思ったものに関しては記事にまとめています。 - 【GoogleMapsAPI】Rails6アプリにMapsJavaScript APIとGeocoding APIを導入してみた - MySQLが起動失敗による500エラーの解消 - 【Docker】Rails6/MySQLのコンテナを作って開発環境を構築 - 【Amazon Linux2】【Rails】Nginxをpumaのunixドメインソケットでリバースプロキシする設定 - 【CircleCI】AWSにデプロイしたRails6アプリをCircleCIで自動デプロイ - 【Rails6】rails sで起動できなくなった話 その他記事 以下は実案件受注やLT会の記事です。 - Rails6でStripe Checkoutを実装　（開発環境/TESTモード） - 【Ruby】変数と定数のあれこれ - 【SQL書籍勉強会】SQLとは？ - 【SQL書籍勉強会】SQLの集計 - 【SQL書籍勉強会】テーブル設計

AWSのネットワーク構成を学ぶ上で、IPアドレスについて学習しました。 その中で、CIDRという用語が出てきてなんとなく理解はできたものの、 IPアドレスの範囲を定義するって、、、、 CIDRって、、、 と、つまづいたので調べてみたら、良い記事に出会い、"/◯○"について無事理解することができました。 参考：CIDR (サイダー)とは | 「分かりそう」で「分からない」でも「分かった」気になれるIT用語辞典 まだ曖昧な部分も多いのでIPアドレスについて調べていく必要がありそうです。

結論 handlerをasyncにして普通にreturnで99.9%くらいOK async + return 最も普通な方法です. exports.handler = async (event) => { const response = { statusCode: 200, body: JSON.stringify('Hello from Lambda!'), }; return response; }; async + returnでsetTimeoutする exports.handler = async (event) => { const response = { statusCode: 200, body: JSON.stringify('Hello from Lambda!'), }; setTimeout(() => { console.log("1000ms後"); }, 1000); setTimeout(() => { console.log("2000ms後"); }, 2000); return response; }; のような場合, 1回目の実行でreturnするまでが1000ms未満の場合, console.logには出力されず, ウォームスタートした場合に次回以降出力されます. 1回目 START RequestId: 4978d8d6-0550-46d2-ad36-769858d22fa3 Version: $LATEST END RequestId: 4978d8d6-0550-46d2-ad36-769858d22fa3 REPORT RequestId: 4978d8d6-0550-46d2-ad36-769858d22fa3 Duration: 2.50 ms Billed Duration: 3 ms Memory Size: 128 MB Max Memory Used: 85 MB Init Duration: 391.34 ms 2回目 (2秒以上開ける) START RequestId: e4dcdbb1-a150-43b4-9e80-c7a776837c16 Version: $LATEST 2021-09-01T03:17:49.058Z 4978d8d6-0550-46d2-ad36-769858d22fa3 INFO 1000ms後 2021-09-01T03:17:49.059Z 4978d8d6-0550-46d2-ad36-769858d22fa3 INFO 2000ms後 END RequestId: e4dcdbb1-a150-43b4-9e80-c7a776837c16 REPORT RequestId: e4dcdbb1-a150-43b4-9e80-c7a776837c16 Duration: 160.53 ms Billed Duration: 161 ms Memory Size: 128 MB Max Memory Used: 85 MB console.logで出力される際についてくる実行IDが, 前回のものになっていることがわかります. このsetTimeout内のconsole.logは, Lambda実行後かつhandler実行前に実行されます. (setTimeout(() => {console.log(new Date());}, 1000); してみましょう) 3回目実行直後に4回目 START RequestId: a87c55c4-73b6-402b-9b51-924d7ca7e178 Version: $LATEST END RequestId: a87c55c4-73b6-402b-9b51-924d7ca7e178 REPORT RequestId: a87c55c4-73b6-402b-9b51-924d7ca7e178 Duration: 1.14 ms Billed Duration: 2 ms Memory Size: 128 MB Max Memory Used: 86 MB ウォームスタートしていますが, 前回の実行のsetTimeoutが完了していないため, 何も出力されません. 5回目(2秒以上待機) START RequestId: 20217709-e518-48fe-ad60-0fe1c7dd627e Version: $LATEST 2021-09-01T03:19:13.790Z a87c55c4-73b6-402b-9b51-924d7ca7e178 INFO 1000ms後 2021-09-01T03:19:13.790Z a87c55c4-73b6-402b-9b51-924d7ca7e178 INFO 1000ms後 2021-09-01T03:19:13.790Z a87c55c4-73b6-402b-9b51-924d7ca7e178 INFO 2000ms後 2021-09-01T03:19:13.790Z a87c55c4-73b6-402b-9b51-924d7ca7e178 INFO 2000ms後 END RequestId: 20217709-e518-48fe-ad60-0fe1c7dd627e REPORT RequestId: 20217709-e518-48fe-ad60-0fe1c7dd627e Duration: 1.47 ms Billed Duration: 2 ms Memory Size: 128 MB Max Memory Used: 86 MB 溜まっていたsetTimeoutが処理された後にLambdaを実行したため, 一気に表示されました. 詳しくはLambdaのライフサイクルで 非async + Promise asyncで普通にreturnすれば値を返せるので, 当然Promiseを返すとうまくいきます. exports.handler = (event) => { const response = { statusCode: 200, body: JSON.stringify('Hello from Lambda!'), }; return new Promise((resolve) => { resolve(response) }); }; 非asyncな場合, 普通にreturnするだけだとnullになります. callback handlerの第3引数のcallbackで返す方法です. asyncかは問いません. exports.handler = async (event, context, callback) => { const response = { statusCode: 200, body: JSON.stringify('Hello from Lambda!'), }; callback(null, response); // callback後も実行される console.log("callback後"); setTimeout(() => { response.statusCode = 400; // ここの実行後にcallbackに入れた値が返るため, 400が出力される }, 1000); }; この場合, setTimeoutなどの非同期処理が全て終わってからcallbackに入れた値が返されます. 複数回callbackした場合 最も最初のcallbackのみ利用されます. exports.handler = async (event, context, callback) => { const response = { statusCode: 200, body: JSON.stringify('Hello from Lambda!'), }; setTimeout(() => { callback(null, response); }, 1000); callback(null, "hoge"); callback(null, "fuga"); }; hoge エラーの場合は第1引数 callback(new Error("era-")); context context.done, context.succeed, context.failが使えます. exports.handler = async (event, context, callback) => { const response = { statusCode: 200, body: JSON.stringify('Hello from Lambda!'), }; context.succeed(response); setTimeout(() => { console.log("fuga"); // この時点では実行されない (次回実行時にconsole.logされている) }, 1000); console.log("hogehoge"); // 実行される }; つまり, 非同期は後回しになるものの, succeed以降も処理が続く, returnとcallbackの中間の性質を持っています. ぶっちゃけ使いません. async + returnでいいです. callback, context, return全部並べてみる 普通に最初のものが処理されます. exports.handler = async (event, context, callback) => { context.succeed("hoge"); callback(null, "fuga"); setTimeout(() => { console.log("a"); // 次回までお預け }, 1000); return "hige"; }; hoge exports.handler = async (event, context, callback) => { callback(null, "fuga"); context.succeed("hoge"); setTimeout(() => { console.log("a"); // 実行される }, 1000); return "hige"; }; fuga どのみちこんな書き方したらコードレビューで凄まじい数のchange requestがやってくるはずなので, 普通書かないです. さいごに 他にも面白いのあったら教えてください?

前提 redashは公式からamiが提供されており、それをもとにEC2インスタンスを立ち上げることで簡単にredashを体験することができる。 しかし、amiのredashバージョンは、おそらくその時点での安定版が採用されており、最新のベータ版でのみ提供されている機能を使うにはバージョンアップを行う必要がある。 この記事では、redashのEC2インスタンスの立ち上げ方法に加えて、redashのバージョンを上げる方法についても紹介する。 手順 1. amiからredashのEC2インスタンスを立ち上げる EC2でのredashの起動方法を紹介した記事は既に多数あるため、ここでは要点だけ抑えて箇条書きにする。 ・EC2インスタンス起動ウィザードを開き、redash公式から提供されているamiを指定 　※リージョンに注意 ・インスタンスのスペックを指定 　※お試し程度であればt2.smallでも十分らしいが、自分の場合はバージョンアップしたせいかスペック不足で動作が不安定になったため、t2.mediumを使用 ・他項目は状況に合わせて適宜設定 ・EC2インスタンスのターミナルに接続できるか確認 　※redashのamiはubuntuをもとに作られているので、ユーザ名が「ec2-user」ではなく「ubuntu」になることに注意 2. EC2インスタンスに接続してバージョン確認 いちばん手っ取り早いのは、立ち上げたredashのwebページから確認する方法。 EC2インスタンスのターミナルから、直接docker-compose.ymlをみてバージョンを確認する手もある。 初めてredashにアクセスしたときのセットアップが済んでいない場合には、こちらのほうが早いかもしれない。 バージョンの確認 # sudo su # cat /cat/redash/docker-compose.yml version: "2" x-redash-service: &redash-service image: redash/redash:9.0.0-beta.b42121 depends_on: - postgres - redis env_file: /opt/redash/env restart: always … … … バージョンを確認して、試してみたい機能がそのバージョンで提供されていなければ、次の手順に沿ってバージョンアップを行う。 3. redashのdocker-imageの差し替え ひとつまえの手順でdocker-compose.ymlを確認していることからもわかるように、EC2インスタンス内ではdockerコンテナが複数立ち上がりredashとしての機能を提供している。 場合によっては、docker-compose.ymlで参照しているredashのdocker-imageを変更して、docker-composeを立ち上げ直せばバージョンアップできるのだが、大事をとって公式のガイドに従ってバージョンアップを行う。 バージョンアップ手順 # 念の為、バックアップをとってから作業すること # sudo su # cd /opt/redash # viなどで希望するバージョンのdocker-imageに書き換えて保存 # vi /opt/redash/docker-compose.yml # 一部のコンテナを止めて再度立ち上げ直す # docker-compose stop server scheduler scheduled_worker adhoc_worker # docker-compose up -d これでバージョンアップは完了しているはずなので、redashのwebページをからバージョンアップできていることを確認する。

はじめに 今回はAWSのアカウント作成方法についてまとめさせていただきます。 そもそもAWSとは何か？とクリアになっていない方は、 先日まとめさせていただいたこちらの記事をぜひご覧いただければと思います。 アカウント作成前に準備するもの ①メールアドレス メールアドレスはrootアカウントのログイン時に使用したり、請求情報の確認やメールなどが来ます。 ②クレジットカード情報 支払い方法は、基本的にクレジットカード決済を使用します。 私はデビットカードでも行けましたが、三井住友などのデビットは使用不可でした。 理由としてはアカウント登録時に「そのカードが本当に使えるのか？」を確認するために1円ほど引き落とされるようですが、 三井住友は最低引き落とし金額？が決まっており1円を引き落とすことができないみたいです。 ネット銀行のデビットでいけました！ （結構前のお話なので、今は三井住友も問題がない可能性はあります！） ③電話番号 電話番号は本人確認時にSMSまたは、自動音声電話がくるときに使用します アカウント作成手順 ※以下のリンクからアカウント作成が可能です https://portal.aws.amazon.com/billing/signup#/start ①メールアドレス、パスワード、アカウント名を設定します ②連絡先情報を入力 個人で使用する場合はアカウント種類はパーソナルで選択します。 ③クレジットカード情報の入力 ④本人確認 SMSで送られてきた認証コードを入力 ⑤サポートプランの選択 以下のように表示されていれば成功です！ アカウントにサインインする方法 AWSのコンソール画面からサインインが可能です。 こちらはルートユーザーでサインインします。 無事にサインインができた場合はこのようなコンソール画面に遷移されます！ これと同じ画面であればOKです！ 終わりに これでアカウントの作成はOKです！ そこまで難しい工程はないかと思うので、ぜひこちらを見ながら作成していってください！

起きたこと Security Hubで指摘される、Instance Metadata Service Version 2 (IMDSv2) の改善要求 を対策したら、goofysでのS3マウントが失敗するようになった goofysからS3の認証は、インスタンスプロファイルで行っていました /var/log/messages. Aug 30 14:38:08 xxxxxxxxx /usr/local/bin/goofys[1784]: s3.ERROR code=NoCredentialProviders msg=no valid providers in chain. Deprecated.#012#011For verbose messaging see aws.Config.CredentialsChainVerboseErrors, err=<nil> Aug 30 14:38:08 xxxxxxxxx /usr/local/bin/goofys[1784]: fuse.ERROR *fuseops.ReadDirOp error: NoCredentialProviders: no valid providers in chain. Deprecated. Aug 30 14:38:08 xxxxxxxxx /usr/local/bin/goofys[1784]: fuse.ERROR #011For verbose messaging see aws.Config.CredentialsChainVerboseErrors 同じ様にS3マウントしている他のサーバでは起きないので、色々と違いを調べたところ 問題が発生するサーバの方だけ、Security Hub指摘に対応していた所が差異でした Credentialsが通らなくなっているのでかなり怪しいと言うことで IMDSv1を利用できるように戻したところ、問題なくCredentialsも通りマウントできるようになりました どうやら、goofysがまだIMDSv2に対応していない様です EC2 インスタンスでは、Instance Metadata Service Version 2 (IMDSv2) を使用する必要があります [EC2.8] This control checks whether your Amazon Elastic Compute Cloud (Amazon EC2) instance metadata version is configured with Instance Metadata Service Version 2 (IMDSv2). The control passes if HttpTokens is set to required for IMDSv2. The control fails if HttpTokens is set to optional. 修復手順 IMDSv1のSSRF脆弱については、徳丸浩先生の記事が一番わかりやすかったので、ご紹介しておきます。 SSRF対策としてAmazonから発表されたIMDSv2の効果と限界 IMDSv2の使用に移行する 既存インスタンスのインスタンスメタデータオプションの変更 aws ec2 modify-instance-metadata-options \ --instance-id i-1234567898abcdef0 \ --http-tokens required \ --http-endpoint enabled IMDSv1を利用可能にする aws ec2 modify-instance-metadata-options \ --instance-id i-1234567898abcdef0 \ --http-tokens optional \ --http-endpoint enabled

前提 redashでは対応しているデータソースに合わせてクエリを書く必要がある。 CloudWatchをデータソースとした場合、どのようにクエリを書けばよいのか分からなかったため、備忘録として記事を残しておく。 結論 CloudWatchをデータソースとした場合のクエリを書くといっても、実態としてはCloudWatchのメトリクス取得APIを叩いているだけなので、そのAPIへのリクエストパラメータを書くのと同じ。 公式リファレンスからリクエストの例を一部抜粋して改変したものを次に示す。 リクエストの例 { # どれだけの期間のデータを取得するか "StartTime": 1518867432, "EndTime": 1518868032, # 取得したいメトリクス群の記述 # この例では、2つのEC2インスタンスのCPU使用率を取得している "MetricDataQueries": [ # 1つ目のEC2インスタンスの指定 { "Id": "m1", "Label": "CPUUtilization m1", "MetricStat": { # どのAWSリソースのなんのメトリクスを取得するかの指定 "Metric": { "Namespace": "AWS/EC2", "MetricName": "CPUUtilization", "Dimensions": [ { "Name": "InstanceId", "Value": "i-1234567890abcdef0" } ] }, # どれくらいのスパンのどういった値を取得するかの指定 # この例では5分(300秒)ごとの平均を取得している "Period": 300, "Stat": "Average" } }, # 2つ目のEC2インスタンスの指定 { "Id": "m2", "Label": "CPUUtilization, m2", "MetricStat": { "Metric": { "Namespace": "AWS/EC2", "MetricName": "CPUUtilization", "Dimensions": [ { "Name": "InstancdId", "Value": "i-111111111111111111" } ] }, "Period": 300, "Stat": "Average" } } ] } 一番外枠で取得したいメトリクスの期間を指定している。 これは"MetricDataQueries"に記述される全てのメトリクスに適用される。 "MetricDataQueries"には取得したいメトリクスをどんどん繋げて書いていく。 AWSリソースによっては多少"Dimensions"の書き方に違いが出てくるが、そのほかはほとんど同様な形式でリクエストが記述できる。 また、リクエストの書き方によっては、複数のメトリクスの値に四則演算を行い算出した「カスタムメトリクス」を取得することもできる。 そうしたリクエストの書き方も、次の公式リファレンスに記載されている。 redash画面 画面上では、次のように上のリクエストをそのままコピペすることでメトリクスの値が取得できるはず。

はじめに API Gateway + Lambda で画像分類 AI を動かそうとしたところ、API Gateway のタイムアウト制限に引っかかってしまいました。 Step Functions を使うことで回避することができたので、その方法について書いていきます。 実行環境 macOS Big Sur 11.3.1 SAM CLI 1.27.2 Docker 20.10.7 やりたいこと API Gateway と Lambda の間に Step Functions を挟んで、API Gateway から Step Functionsを呼び出します。 Step Functions の StartExecution API を呼び出すと、　Lambda のステートマシンでタスクを実行し、そのタスク名をレスポンスとして API Gateway に返します。 API Gateway にレスポンスが返ってきているためタイムアウトになりません。 また、Step Functions の DescribeExecution API　を呼び出すと、タスクの状況と処理結果を一緒に返してくれます。 構成はこちらの記事を参考にしました。 手順 Lambdaの作成 こちらの記事を参考にLambdaを作成しました。 自身のIAMユーザーに以下のポリシーを付与しておいてください。 AWSLambda_FullAccess AmazonAPIGatewayAdministrator AmazonAPIGatewayPushToCloudWatchLogs AmazonEC2ContainerRegistryFullAccess IAMFullAccess AWSCloudFormationFullAccess AWSStepFunctionsFullAccess Lambda ステートマシンを作成 Lambda の作成ができたら、Step Functions で Lambda ステートマシンを作成します。 Step Functions のコンソールで「ステートマシンの作成」をクリックし、「コードをワークフローで記述」、タイプは「標準」を選択してください。 ステートマシンの定義を下記の内容に変更してください。Resource には、プロジェクト作成時に作られた Lambda 関数の ARN を指定します。 { "StartAt": "CallLambda", "States": { "CallLambda": { "Type": "Task", "Resource": <Lambda関数のARN>, "End": true } } } 詳細を以下のように指定します。ステートマシン名は自由に変更してください。 これで Step Functions の準備は終わりです。 API Gateway 作成 次に API Gateway を作成していきます。 ここからはこちらも参考にしています。 IAM ロールの作成 まず API Gateway 用の IAM ロールを作成します。 IAM コンソールから「ロール」＞「ロールの作成」を選択してください。 「AWS サービス」から API Gateway を選択して「次のステップ：アクセス権限」へ進みます。 「Attached アクセス権限ポリシー」と「タグの追加(オプション)」では何もせずに次のステップへ進んで大丈夫です。 任意のロール名を入力し「ロールの作成」をしてください。今回はAPIGatewayToStepFunctionsとします。 IAM ロールにポリシーをアタッチする 「ロール」ページで先ほど作成したロールを選択します。 下記のような「ロール ARN」が表示されるのでメモをしておいてください。 arn:aws:iam::123456789012:role/APIGatewayToStepFunctions 「アクセス権限」タブの「ポリシーをアタッチします」を選択します。 AWSStepFunctionsFullAccessにチェックをし、「ポリシーのアタッチ」をします。 Step Functions と連携する API を作成 API Gateway を作成します。API タイプは「REST API」で構築してください。 API名を入力してAPIを作成します。 新しいリソースを作成します。「アクション」から「リソースの作成」を選択してください。 任意のリソース名を入力し「API Gateway CORS を有効にする」にチェックを入れて「リソースの作成」をします。 作成したリソースに POST メソッドを作成します。「アクション」から「メソッドの作成」を選択してください。 リストの中から POST を選択し、チェックマークをオンにします。下図を参考に設定してください。実行ロールには先ほどメモしたロール ARN を使用してください。 作成したリソースの下にもう 1 つリソースと POST メソッドを作成します。下図を参考に設定してください。 CORS の有効化を 2 つのリソースそれぞれに対して行います。作成したリソースを選択した状態で「アクション」から「CORS の有効化」を行ってください。 Access-Control-Allow-Headers を'*'に変更し,「CORS を有効にして既存の CORS ヘッダーを置換」します。 API のデプロイを行います。「アクション」から「API のデプロイ」を選択してください。「デプロイされるステージ」を「新しいステージ」、「ステージ名」に任意のステージ名を入力してデプロイをしてください。 これで Step Functions と API Gateway の準備は完了です。 動作確認 では実際に動作を確認してみましょう。 curl を用いて POST リクエストを送ります。URL は自分で作成したリソースの URL に変更してください。 curl -X POST -d '{"input": "{}","stateMachineArn": "<Step Functions の ARN>"}' https://xxx.execute-api.ap-northeast-1.amazonaws.com/prod/execution このような結果が返ってくれば大丈夫です。 { "executionArn":"arn:aws:states:ap-northeast-1:<アカウントID>:execution:test-function:xxxxx", "startDate":1.63046260246E9 }% 状態を返してくれるリソースの方にもリクエストを送ってみましょう。先ほど返ってきたexecutionArnを渡します。 curl -X POST -d '{"executionArn":"arn:aws:states:ap-northeast-1:<アカウントID>:execution:test-function:xxxxx"}' https://xxx.execute-api.ap-northeast-1.amazonaws.com/prod/execution/status 実行途中ならstatusとしてRUNNINGが返ってきます。 { "executionArn":"arn:aws:states:ap-northeast-1:<アカウントID>:execution:test-function:xxxxx", "input":"{}", "inputDetails":{"__type":"com.amazonaws.swf.base.model#CloudWatchEventsExecutionDataDetails","included":true}, "name":"xxxxx", "startDate":1.63046260246E9, "stateMachineArn":"arn:aws:states:ap-northeast-1:<アカウントID>:stateMachine:test-function", "status":"RUNNING", "stopDate":1.630462645972E9, "traceHeader":"Root=1-612ee28a-044d88e25fb4be157a0e5046;Sampled=1" }% 処理が終了するとoutputと、statusとしてSUCCEEDEDが返ってきます。 outputには Lambda の処理結果が入っています。 { "executionArn":"arn:aws:states:ap-northeast-1:<アカウントID>:execution:test-function:xxxxx", "input":"{}", "inputDetails":{"__type":"com.amazonaws.swf.base.model#CloudWatchEventsExecutionDataDetails","included":true}, "name":"xxxxx", "output":"", "outputDetails":{"__type":"com.amazonaws.swf.base.model#CloudWatchEventsExecutionDataDetails","included":true}, "startDate":1.630464429504E9, "stateMachineArn":"arn:aws:states:ap-northeast-1:<アカウントID>:stateMachine:test-function", "status":"SUCCEEDED", "stopDate":1.630464457648E9, "traceHeader":"Root=1-612ee9ad-1a6f0b711a2d53ca6d079d6b;Sampled=1" }%

AWS App Runner インフラストラクチャを管理せずに高速でシンプルかつ安全な方法でコンテナ化されたWebアプリケーションのビルド、デプロイ、実行するためのマネージドなサービスです。 ソースコードまたはコンテナイメージを提供するだけで、App Runnerはアプリケーションを自動的に構築およびデプロイすることができます。 App Runner は裏側で、Fargetが動いているらしい。 ハンズオン 詳細な仕様の話に入る前に、それ程複雑な設定はないので、とりあえず触ってみると良さそうですです。 AmazonのharunobukamedaさんがGithubにhands-onをあげてくれているので、こちらを試してみると良いかと思います。 動作 ハンズオンを実施いただいた通りですが、やることは、 GitHubにアプリケーションコード（現在は、PythonとNode1.jsに対応）をpushするか、 AmazonECRにコンテナイメージをpushする。 これだけで後はいい感じにApp Runnerが動いてくれます。 Auto Scalling リクエスト数に応じてスケールする。 同時リクエストの数が同時実行数の割り当てを超えると、AppRunnerはサービスをスケールアップします。 アプリケーションが捌き切れなく、処理待ちのリクエストがどれぐらい溜まっているかにより、スケールアップします。（例えば、同時実行100にし、100リクエストがきたからといって、スケールアップするわけではない。） ヘルスチェック App runnerは、アプリケーションがリッスンしているポートでTCPヘルスチェックを実行します。 セキュリティ インスタンスロール 例えば、Apprunnerで動かしているアプリケーションが、S3からデータを持ってきたい場合など、IAMロールを作成する。 AWS KMS キー 作成時に、AWSが所有するキーを使用するか、別のAWS KMSキーを選択することが可能。 ログとメトリクス ログ イベントログ デプロイログ アプリケーションログ メトリクス インスタンスレベルのメトリクス サービスレベルのメトリクス カスタムドメイン デフォルトドメインをカスタムドメインと紐付けることが可能。 1日〜2日で反映される。 料金 開発や個人で利用する場合には、一時停止にしてコストを抑えることが可能。 制限事項 既存のVPC上のリソースにアクセスできない。 その他参考URL