EBS ボリュームタイプの選択 EBS ボリュームの種類 Amazon EBS では複数のボリュームタイプが提供されており、パフォーマンス特性と料金が異なります。 汎用 SSD (gp2, gp3): その名の通りほとんどのワークロードに適しています Provisioned IOPS SSD (io1, io2, io2Block Express): ミッションクリティカルで高い I/O 性能が求められるワークロードに適しています それぞれのボリュームタイプの最大性能が決まっており、このカタログ値も判断基準の一つです。 詳細は後述しますが、すべてのボリュームで常に最大パフォーマンスが得られるわけではないことに注意ください。 ボリュームタイプ gp2 gp3 io1 io2 io2 Block Express ボリュームサイズ 1 GiB - 16TiB 1GiB - 16TiB 4 GiB～16 TiB 4 GiB～16 TiB 4 GiB～64 TiB ボリュームあたりの最大IOPS 16,000 16,000 64,000 64,000 256,000 ボリュームあたりの最大スループット 250 MiB/秒 1,000 MiB/秒 1,000 MiB/秒 1,000 MiB/秒 4,000 MiB/秒 ※ io2 Block Express は R5b インスタンスで io2 ボリュームを使用した場合のみ、自動で有効化されます。 汎用 SSD (gp2, gp3) 選択時の考慮点 gp2 の I/O クレジットおよびバーストパフォーマンスの考え方 gp2 の I/O 性能はボリュームの割当サイズにより変動します。ベースラインパフォーマンスは 1 GiB あたり 3 IOPS で、最小値は 100 IOPS、最大値は 16000 IOPS です。例えば 100 GiB のボリュームでは 300 IOPS がベースライン (最低保障) 性能となります。 1000 GiB 未満の汎用 (SSD) ボリュームでは、最大で 3000 IOPS までバースト可能です。gp2 ボリュームには I/O クレジットという概念があり、これを消費することで少ない割当のボリュームであっても、最大 30分間は 3000 IOPS のパフォーマンスを発揮することができます。I/O クレジットを消費した場合は時間とともに回復します。 バーストパフォーマンスに依存しているアプリケーションで I/O クレジットが枯渇した場合、稼働するアプリケーションに影響が発生する可能性がある点についてご注意ください。1000 GiB 未満のボリュームを使用している環境では I/O クレジットの残量を CloudWatch のメトリクス (BurstBalance) でモニタリングしておくことが重要です。 最大スループット性能もボリュームサイズに応じて変動します。 170 GiB 以下のボリューム: 128 MiB/秒 170 GiB 以上 334 GiB 以下のボリューム: I/Oクレジットを消費している間は 250 MiB/秒 334 GiB 以上のボリューム: 250 MIB/秒 gp3 ボリュームの概要 gp3 は最新世代の汎用 SSD ボリュームです。gp3 には I/O クレジットおよびバーストパフォーマンスの概念はありません。割当サイズによらず、ベースライン性能は 3,000 IOPS と 125 MiB/秒のスループットです。以下の追加料金を支払うことで IOPS とスループットをボリュームあたりの最大値までプロビジョニングできます。 東京リージョン 2021年10月 時点 3,000 IOPS までは無料、3,000 を超えた分について 1 か月におけるプロビジョンド IOPS あたり 0.006USD 125 MB/秒 までは無料、125 を超えた分について 1 か月におけるプロビジョンド MB/秒あたり 0.048USD gp3 はチューニングの自由度が高く、I/O クレジットのような複雑な概念がありません。1 GB あたりの利用料金も gp3 のほうが 20% 安価です。また割当容量が少ないボリュームの場合は、gp2 と比較して高いベースライン性能の恩恵を受けることができます。 Provisioned IOPS SSD (io1, io2, io2 Block Express) 選択時の考慮点 主にデータベースサーバーのようなミッションクリティカルで高い I/O 性能が求められるワークロードに向けに用意されているボリュームタイプです。ボリューム毎に 100～64,000 (io1/io2) または 256,000 (io2 Block Express) まで任意の IOPS 値を指定することができます。 1GB あたりのストレージ料金のほか、割り当てる IOPS 値によって追加料金が発生します。IOPS 値はむやみに高い値を設定すると高額な請求になりますのでご注意ください。 東京リージョン 2021年10月時点 io1 1 か月におけるプロビジョンド IOPS あたり 0.074USD io2, io2 Block Express 1 か月におけるプロビジョンド IOPS (最大 32,000 IOPS まで) あたり 0.074USD 1 か月におけるプロビジョンド IOPS (最大 32,001～64,000 IOPS) あたり 0.052USD 1 か月におけるプロビジョンド IOPS (64,000 IOPS 超) あたり 0.036USD io2 ボリュームの概要 io2 は最新世代の Provisioned IOPS SSD ボリュームです。GB あたりの料金は io1 ボリュームと同じですが、以下の3点が異なります。 プロビジョンド IOPS 料金 32,001～64,000 IOPS の割当料金は io1 より io2 のほうが割安に設定されている データの耐久性が約100倍 io1 の 年間故障率 0.1%～0.2% io2 の 年間故障率 0.001% 容量あたりに割当可能な IOPS 値が10倍 io1 の 1GiB あたりの最大割当 IOPS: 50 io2 の 1GiB あたりの最大割当 IOPOS:500 io2 Block Express の概要 io2 Block Express は io2 ボリュームより低レイテンシー、高い IOPS、スループット、大容量を得ることができるボリュームタイプです。io2 ボリュームはすべての EC2 インスタンスタイプで使用できますが、io2 Block Express は R5b インスタンスでのみ利用できます。 R5b インスタンスに接続された io2 ボリュームが自動的に io2 Block Express ボリュームとして認識、実行されます。 EC2 インスタンスタイプによる上限 EC2 のインスタンスタイプごとに Amazon EBS 専用の帯域幅が定められており、これにより IOPS、スループットの上限が決まります。つまり gp3 や io2 ボリュームで高い性能を確保していたとしても、インスタンスタイプごとの上限がボトルネックとなり、意図した性能を確保できないケースがあります。 また Nitro ハイパーバイザーかつ、2xlarge までのインスタンスタイプは EBS 専用帯域幅がバースト特性を持ちます。例えば m5.large というインスタンスタイプの場合は以下のような制限となります。 最大 IOPS: 18,750 ベースライン IOPS: 3600 最大スループット: 593.75 MB/s ベースラインスループット: 81.25 MB/s 最大 IOPS/ベースライン は 「24 時間につき少なくとも 30 分間維持することができる」性能です。30分以上パフォーマンスを維持する必要があるワークロードではベースラインの IOPS/スループットに基づいてインスタンスタイプを選択する必要があります。インスタンスタイプごとの上限値については以下のドキュメントを参照してください。 CloudWatch によるパフォーマンスモニタリング 各ボリュームのパフォーマンスは CloudWatch ボリュームメトリクスを使用してモニタリングできます。観測の結果、ストレージ性能がボトルネックになっていることがわかれば、IOPS の追加などの対応方針を検討できます。 IOPS の確認方法 VolumeReadOps と VolumeWriteOps の合計値から計算します。EBS は 1 分間ごとに CloudWatch へメトリクスを送るため、データの期間 1 分に変更し、その値を 60(秒) で割ることで IOPS を算出できます。 CloudWatch は数式を扱うことができる機能があるため、算出した IOPS の値をグラフにプロットできます。以下の例の場合、IOPS が 450 前後を記録していることがわかります。 スループットの確認方法 VolumeReadBytes と VolumeWriteBytes の合計値から計算します。データの期間を 1 分とし、60 で割るところは IOPS と同じですが、スループットは転送されたバイト総量から求める必要があるため、統計を合計に変更する必要があります。 CloudWatch の数式でプロットすると以下のようになります。この例の場合、15 MB/s 前後のスループットを記録していることがわかります。 Compute Optimizer CloudWatch 以外の確認方法としては AWS Compute Optimizer を使用できます。Compute Optimzer は EC2 や Auto Scaling Group のメトリクスと設定データを機械学習で分析して、推奨されるインスタンスタイプをレコメンドするサービスです。EBS ボリューム性能のレコメンデーションもサポートしています。I/O やスループットの過不足や、ボリュームタイプを変更した際のコスト、パフォーマンスへの影響を等を確認できます。 ストライピング (RAID 0) による性能向上 ストライピング とは ストライピング (RAID 0) とは複数のボリュームをまとめて1つのボリュームのように管理する RAID の技術です。複数ボリュームに並行してデータを記録することで読み書きを高速化します。EBS でも複数のボリュームをまとめてストライピングすることで、より高いパフォーマンスのファイルシステムを実現できます。 ストライピングを使用した場合、IOPS と スループットの性能は単純に加算されていきます。例えば容量 100GB で 4000 の IOPS を割り当てた 2 つの gp3 ボリュームでストライピングを組んだ場合、8000 の IOPS を備えた 200 GB のボリュームとして扱うことができます。 AWS の機能として提供されているものではないため、各 OS レベルで ソフトウェア RAID を構成する必要があります。詳細な手順は AWS のドキュメントを参考にしてください。 ストライピング利用時の注意点 既存のボリュームは変更できない 新規のボリュームを使用してフォーマットする必要があります。運用環境の場合はデータを移行するなどの考慮が必要です。 RAID 5/6 は使用しない Amazon EBS のデータは AZ 内の複数のサーバーに複製されるため、データの耐久性を目的に RAID 5 または 6 を採用する必要はありません。パフォーマンスへの影響があるため、むしろ非推奨とされています。 バックアップ取得のタイミング ストライピングは複数ボリュームに並行してデータを記録するため、データ整合性の観点からバックアップは同時に取得する必要があります。具体的には Data Lifecycle Manager でマルチボリュームスナップショットを取得するか、AWS Backup を使用してください。 インスタンスストアの活用 インスタンスストアは、EC2 インスタンスが稼働するホストに直接アタッチされた揮発性のストレージです。インスタンスの停止や終了でインスタンスストア上のデータは失われますが、NW 腰EBS よりも高い IOPS/スループットを発揮できます。バッチ処理などで一時データ書き込み場所が必要なケースではインスタンスストアを利用することで追加コストなしで処理時間が改善される可能性があります。 インスタンスストアは特定の M5ad, R6gd のように追加機能として d がつくインスタンスタイプまたは、ストレージ最適化インスタンス の I3 など特定のインスタンスタイプでのみ利用できます。

前回のお話 はじめに 本記事は、将来再認定を受けるときの備忘録でもあります 本記事を見る時点で大体AWS認定試験のことや、Solutions Architect - Professional のことは大体理解されている前提で記事をまとめたいと思います 試験を受ける前の私のスペック AWS を使った業務経験は最低限はある EC2 関連がメインであり、その他機能についてはほぼ知らないに等しい状態 AWS認定試験は以下を取得 アソシエイト資格3種 スペシャリティ 試験3種 データアナリティクス セキュリティ ネットワーク データベース 学習教材 AWS 認定ソリューションアーキテクト - プロフェッショナル 試験特性から導き出した演習問題と詳細解説 AWS WEB 問題集で学習しよう ※ 今回、模擬試験はやってません 学習期間 10/1 - 10/29 （前回取得してからしばらく資格取得に満足したのでお休みしてました） 学習方法 書籍学習(10/1-10/5) 「AWS 認定ソリューションアーキテクト - プロフェッショナル 試験特性から導き出した演習問題と詳細解説」を一通り流し読みしてました 模擬試験は紙ベースだと結構手間に感じて最終的には手付かず AWS WEB 問題集で学習しよう(10/5 - 10/29) 合格記を見ていると #30-58 を何度も解けば合格圏内に入るということだったので3週ほど実施した 最終的には8～9割はなぜダメなのか、なぜこの選択肢なのかを考えた上で解けるぐらいになっていた（たまに抜けて間違えることもあったので詰めは甘い） 試験当日 電車で試験会場に移動中 #30 - のタイムトライアルをしていた 試験結果 過去受験した人の記事から3時間の時間が足りなくなるという話を聞いていたのでビクビクしていたが、1周が終わったタイミングで残り60分、見直し2周で残り時間15分を残す形で終了した 全75問に対しての感覚値 2択まで絞り込めた＋全く分からない問題：36問 自身がそれなりにある問題：39問 2択絞り込みについても、そこそこ自信があるものが半分ぐらいあり、全く分からなかった問題は8問ぐらいあった 75問の75%合格ラインとした場合、18問以下の誤答まで許される計算になるので勝率は半分よりは高いと思っていた 結果の点数から見ると、試験を受けた時に感じた感覚通りの点数でした 珍しいのは800～900点を超えていないけど、コンピテンシーをすべて満たしていたこと 試験を受けて思ったこと スペシャリティ関連の試験を受けていたこともあり試験の進め方に若干の慣れがあった アソシエイトを受けた後、プロフェッショナルを受けると問題の長さに面を食らうと思う 範囲的に狭く深いスペシャリティの問題を解いて試験感覚を得るのは良い手段かもしれない 試験パターンに慣れたとして SAP の難しいと感じさせる要因の一つは試験範囲の広さ、浅く広い長文の問題が多いので、難しく感じやすく、試験が進むにつれて気持ちがダレやすいと感じた 最後に AWS の認定試験残すところ DOP と MLS の二つとなった 機械学習は全くの未知の分野なので躊躇している部分がある となると DOP を攻めるのが無難なのかな？

今回は、AWSの統合開発環境(IDE)Cloud9上でデータサイエンスをする上で開発効率が一気に上がるIDEのJupyter Labを立ち上げる方法を紹介します。 この記事の流れ ① Cloud9にJupyterをインストール ② Jupyter labを立ち上げる ③ Jupyter labに入る ①Cloud9にJupyterをインストール 今回使うCloud9はAmazon Linux2、Pythonはdefaultのversion 3.7.10をを使っています。 それでは、Cloud9上のTerminalでJupyter labをインストールしましょう。 pip install jupyterlab ②Jupyter labを立ち上げる 次にJupyter Labを立ち上げます。ここで、ローカル環境でよくやる jupyter lab というコマンドを書けばすぐに立ち上がってWebブラウザを開いてくれましたが、Cloud9ではそうなりません。 その理由は、Cloud9上で実行しているアプリケーションをプレビューするには、ポートの設定を8080、8081、8082を指定している必要があるからです。 AWS Cloud9統合開発環境 (IDE)で実行中のアプリケーションをプレビュー コマンドを以下に変更して実行しましょう。 jupyter lab --port 8080 --ip 0.0.0.0 すると以下のようにサーバーが立ち上がります。 この下から２番目の token=8e{モザイク} のtoken=よりも後の部分をコピーしておきましょう。Jupyter Labに入るためのトークンです。 ③Jupyter labに入る 実行後、optionタブの[Preview] → [Preview Running Application]をクリックすると以下の?の画面に遷移します。 赤丸をしてる部分をクリックすると、Jupyter Labのログインページに遷移します。 ここに先程のトークンを入力して、アクセス成功です！

今回は、AWSの統合開発環境(IDE)Cloud9上でデータサイエンスをする上で開発効率が一気に上がるIDEのJupyter Labを立ち上げる方法を紹介します。 この記事の流れ ① Cloud9にJupyterをインストール ② Jupyter labを立ち上げる ③ Jupyter labに入る ①Cloud9にJupyterをインストール 今回使うCloud9はAmazon Linux2、Pythonはdefaultのversion 3.7.10をを使っています。 それでは、Cloud9上のTerminalでJupyter labをインストールしましょう。 pip install jupyterlab ②Jupyter labを立ち上げる 次にJupyter Labを立ち上げます。ここで、ローカル環境でよくやる jupyter lab というコマンドを書けばすぐに立ち上がってWebブラウザを開いてくれましたが、Cloud9ではそうなりません。 またJupyter Labのデフォルトポート番号は8888ですが、Cloud9上で実行しているアプリケーションをプレビューするには、ポートの設定を8080、8081、8082を指定している必要があります。 AWS Cloud9統合開発環境 (IDE)で実行中のアプリケーションをプレビュー コマンドを以下に変更して実行しましょう。 jupyter lab --port 8080 --ip 0.0.0.0 すると以下のようにサーバーが立ち上がります。 この下から２番目の token=8e{モザイク} のtoken=よりも後の部分をコピーしておきましょう。Jupyter Labに入るためのトークンです。 ③Jupyter labに入る 実行後、optionタブの[Preview] → [Preview Running Application]をクリックすると以下の?の画面に遷移します。 赤丸をしてる部分をクリックすると、Jupyter Labのログインページに遷移します。 ここに先程のトークンを入力して、アクセス成功です！

AWS S3の静的ホスティングの設定〜Github Actionでデプロイが走るとS3にアップロードしてくれるパイプライン構築までの手順を自分用にまとめました。 IP制限もかけられるようにしました。 AWS側の設定 S3の設定 https://s3.console.aws.amazon.com/s3/home?region=ap-northeast-1へアクセスし、バケットを作成をクリックする。 任意のバケット名を入力し、リージョンを選択（ap-northeast-1）し、パブリックアクセスを全てブロックのチェックを外す。 最下部の「バケットを作成」ボタンをクリックする。 作成したバケットをクリックして、詳細画面にいく。 最下部にある「静的webホスティング」の編集をクリックする。 画像のように、静的ウェブホスティングを有効にする。（インデックスドキュメントはindex.htmlで良い） 詳細画面に戻り、「アクセス許可」タブのバケットポリシーを編集する。 JSONの記述が難しい場合は、「Generate Policy」で作成すると良い。 以下では特定のIPアドレスからのアクセスのみ許可するポリシーを設定。 CIDR表記がわからない場合は、ネットワーク計算ツールで確認すると良い。 { "Version": "2012-10-17", "Id": "{任意のIDを記述する}", "Statement": [ { "Sid": "{任意のIDを記述する}", "Effect": "Allow", "Principal": "*", "Action": "s3:GetObject", "Resource": "arn:aws:s3:::{先ほど作成したバケット名を記述する}/*", "Condition": { "IpAddress": { "aws:SourceIp": "{自分のIPアドレスをCIDR形式で記述する}" } } } ] } これでS3の設定は全て完了です。 IAMの設定 https://console.aws.amazon.com/iamv2/home#/usersにアクセスし、Githubと連携するためのCLIのIAMユーザーアカウントを作成する 「アクセスキー - プログラムによるアクセス」にのみチェックを入れる ポリシーは「AmazonS3FullAccess」を選択する。 認証情報をcsvダウンロードする。（Github Actionで使用するのでちゃんとメモっておく） これでIAMの設定は全て完了です。 Github Actionの設定 Github上でリポジトリを作成する。 SettingタブのSecretsをクリックから、「New Repository Secret」をクリックし以下の3つを登録する。 Name 値 AWS_ACCESS_KEY_ID 先ほど控えておいたAccess key IDを入力する AWS_SECRET_ACCESS_KEY 先ほど控えておいたSecret access keyを入力する S3_BUCKET 先ほどの手順で作成したバケット名を入力する Actionsタブへ行き、「set up a workflow yourself」をクリックし、「Edit new file」をクリックする。 yamlは以下を入力し、「Start commit」をクリックしてから、「Commit new file」をクリックする。 name: Amazon S3 Upload on: push: branches: - master jobs: build: runs-on: ubuntu-latest steps: - name: Checkout uses: actions/checkout@v2 - name: Configure AWS credentials uses: aws-actions/configure-aws-credentials@v1 with: aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }} aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }} aws-region: ap-northeast-1 - name: Upload to S3 env: S3_UPLOAD_BUCKET: ${{ secrets.S3_BUCKET }} run: | aws s3 sync . s3://$S3_UPLOAD_BUCKET/ --delete --exclude "README.md" --exclude ".git/*" --exclude ".github/*" --exclude ".gitignore" これでGithub Actionの設定は完了です。 パイプラインが走る エディタ（vscode）からGithubへプッシュすると、Github Actionがキックされ、パイプラインが回ります。 最後に こんなに簡単にできるとは思っていなかったです。（Github Actionすごい） ご不明点あれば、コメントまで〜！ @lmatsulさんのGithub Actions を使って AWS の S3 へデプロイするを参考にさせていただきました?‍♂️

AWS Cloud9で環境を作成しようとした際のエラーです ある日、Cloud9で新規環境を作成しようとすると、下記のエラーが出ました 素直に、CloudFormationが原因と考えて、色々調べたところ下記の検索結果がヒントになりました https://aws.amazon.com/jp/premiumsupport/knowledge-center/cloudformation-stack-delete-failed/ URLにある記事のとおり、下記の画面で「削除」を実行します。 で、再度Cloud9で環境を新規作成していきます。 これで解決かと思いきや、もう１つエラーが出ました。下記は「AWS Cloud9 > Environments」の詳細画面で見たエラー詳細です。 これも検索していくと、下記の説明が目にとまりました。 https://ja.confluence.atlassian.com/jirakb/aws-quickstart-template-leads-to-the-following-resource-s-failed-to-create-vpcstack-rollback-requested-by-user-error-966662213.html 地域選択を大阪にしていたことを即思い出し、「アジアパシフィック（東京）」に再度選択し直します。 すると、今度は、無事Cloud9環境を作成。Welcome画面に辿り着きました。 結果、どんだけ大阪が好きやねんという結末ですが、AWSはリージョン設定によっては使えなくなる機能があるというのはいい教訓ですね。

aws Amplify チュートリアルをやる前の準備 準備 ローカル環境確認 node -v npm -v create-react-app --version amplify --version アカウント取得 Githubアカウント取得 awsのアカウントを取得 Reactのローカル環境を構築 ローカル環境構築 参考 M1macでReactの環境構築をやってみた https://www.mitsurog.com/opinion/m1macbook-react/ Reactの環境構築に必要なファイルをインストールする homebrewのインストール nodebrewのインストール nodeのインストール npmのインストール yarnのインストール crea-react-appのインストール amplifyのインストール npm install -g @aws-amplify/cli アカウント取得 ・Githubアカウント取得 ・awsのアカウントを取得 Githubアカウント取得 GitHubアカウント作成とリポジトリの作成手順 https://qiita.com/kooohei/items/361da3c9dbb6e0c7946b awsのアカウントを取得 プロが教えるAWSアカウント作成方法 ～ルートユーザアカウント作成編～ https://www.cloudsolution.tokai-com.co.jp/white-paper/2021/0604-238.html 住所を英語表記に変換 https://kimini.jp/ Reactのローカル環境を構築 M1macでReactの環境構築をやってみた https://www.mitsurog.com/opinion/m1macbook-react/ ▼Reactの環境構築に必要 homebrew(ホームブリュー) nodebrew(ノードブリュー node(ノード) npm(エヌピーエム) yarn(ヤーン) crea-react-app(クリエイト-リアクト-アップ)

はじめに 今回は Amazon SageMaker Studio を試します。 機械学習のための統合開発環境を起動し、サンプルコードを実行します。 初回設定 AWSマネジメントコーンソールから Amazon SageMaker > SageMaker Domain を開きます。 クイックスタート欄のIAMロールを設定します。 次の画面でVPCを設定します。 起動 初回設定の後しばらく待ちます。 ユーザーが表示された後、「Studioを開く」をクリックします。 サンプルコード実行 Studioを開いた直後はLauncherタブが表示されます。 Launcherタブの最下部にある「System terminal」をクリックし、ターミナルタブを開きます。 サンプルコードを取得します。今回は amazon-sagemaker-examples を取得しました。 ipynbファイルを開き、コードにフォーカスをあわせて画面上部の▶ボタンをクリックすると、コードを実行できます。 終了 File > Shut Down をクリックします。 「Server stopped」の表示が出るので、ページを閉じます。 終わりに SageMaker Studio を試しました。 自動シャットダウン拡張機能を利用した Amazon SageMaker Studio のコスト削減方法が紹介されているので、今後試して行こうと思います。 参考資料 SageMaker Studioが東京リージョンで使えるようになりました。 #SageMaker Amazon SageMaker Studioを使って機械学習をやってみる Amazon SageMaker とは Amazon SageMaker のよくある質問 Amazon SageMaker Examples

概要 Dockerを使用した開発にあたり手持ちのWindows端末ではいろいろと不便になってきたのでCloud9で開発をできるようにしてみようかと思います。 作成の部分はこちらAWS CLI 専門支部のイベント を参考に作っています。 Cloud9用VPC作成 VPCの設定 Cloud9用のVPCを作成します。 CloudShell で以下のコマンドを実行していきます #以下のコマンドをコピペして実施すればできます # 各変数の設定 ターミナルを切り替えたりした場合は再度設定が必要になります AWS_REGION="ap-northeast-1" EC2_VPC_TAG_NAME='docker-vpc' EC2_VPC_CIDR='10.0.0.0/16' EC2_INTERNET_GATEWAY_TAG_NAME='docker-internet-gateway' EC2_ROUTE_TABLE_TAG_NAME='docker-route-table' EC2_ROUTE_DESTINATION_CIDR='0.0.0.0/0' EC2_SUBNET_TAG_NAME='public-subnet' EC2_SUBNET_CIDR='10.0.0.0/24' EC2_AZ_NAME="ap-northeast-1a" # 設定値の確認 設定値が設定されていない場合はコマンドを見直してください cat << END # 0. AWS_REGION:"ap-northeast-1" AWS_REGION="${AWS_REGION}" # 1. EC2_VPC_TAG_NAME:"docker-vpc" EC2_VPC_TAG_NAME="${EC2_VPC_TAG_NAME}" # 2. EC2_VPC_CIDR:"10.0.0.0/16" EC2_VPC_CIDR="${EC2_VPC_CIDR}" END # 変数の設定 STRING_EC2_VPC_TAG="ResourceType=vpc,Tags=[{Key=Name,Value=${EC2_VPC_TAG_NAME}}]" \ && echo ${STRING_EC2_VPC_TAG} # 設定値の確認 設定値が設定されていない場合はコマンドを見直してください cat << END # EC2_VPC_CIDR:"10.0.0.0/16" EC2_VPC_CIDR="${EC2_VPC_CIDR}" # STRING_EC2_VPC_TAG:"ResourceType=vpc,Tags=[{Key=Name,Value=docker-vpc}]" STRING_EC2_VPC_TAG="${STRING_EC2_VPC_TAG}" END # VPC作成 aws ec2 create-vpc \ --cidr-block ${EC2_VPC_CIDR} \ --tag-specifications ${STRING_EC2_VPC_TAG} 作成結果確認 # VPC作成確認 aws ec2 describe-vpcs \ --filters Name=tag:Name,Values=${EC2_VPC_TAG_NAME} \ --query 'Vpcs[].Tags[?Key == `Name`].Value' \ --output text # CIDRの確認 aws ec2 describe-vpcs \ --filters Name=tag:Name,Values=${EC2_VPC_TAG_NAME} \ --query "Vpcs[].CidrBlock" \ --output text インターネットゲートウェイの設定 前述の手順作成したVPCのインターネットゲートウェイを作成します。 CloudShell で以下のコマンドを実行していきます #以下のコマンドをコピペして実施すればできます # VPCのタグ名、CIDRの設定 cat << END # 0. AWS_REGION:"ap-northeast-1" AWS_REGION="${AWS_REGION}" # 1. EC2_INTERNET_GATEWAY_TAG_NAME:"docker-internet-gateway" EC2_INTERNET_GATEWAY_TAG_NAME="${EC2_INTERNET_GATEWAY_TAG_NAME}" END # 変数設定 STRING_EC2_INTERNET_GATEWAY_TAG="ResourceType=internet-gateway,Tags=[{Key=Name,Value=${EC2_INTERNET_GATEWAY_TAG_NAME}}]" \ && echo ${STRING_EC2_INTERNET_GATEWAY_TAG} cat << END # STRING_EC2_INTERNET_GATEWAY_TAG:"ResourceType=internet-gateway,Tags=[{Key=Name,Value=docker-internet-gateway}]" STRING_EC2_INTERNET_GATEWAY_TAG="${STRING_EC2_INTERNET_GATEWAY_TAG}" END # インターネットゲートウェイの作成 aws ec2 create-internet-gateway \ --tag-specifications ${STRING_EC2_INTERNET_GATEWAY_TAG} # 作成の確認 aws ec2 describe-internet-gateways \ --filters Name=tag:Name,Values=${EC2_INTERNET_GATEWAY_TAG_NAME} \ --query "InternetGateways[].Tags[].Value" \ --output text インターネットゲートウェイのアタッチ 前述の手順作成したVPCのインターネットゲートウェイのアタッチを行います。 CloudShell で以下のコマンドを実行していきます #以下のコマンドをコピペして実施すればできます # 変数確認 cat << END # 0. AWS_REGION:"ap-northeast-1" AWS_REGION="${AWS_REGION}" # 1. EC2_VPC_TAG_NAME:"docker-vpc" EC2_VPC_TAG_NAME="${EC2_VPC_TAG_NAME}" # 2. EC2_INTERNET_GATEWAY_TAG_NAME:"docker-internet-gateway" EC2_INTERNET_GATEWAY_TAG_NAME="${EC2_INTERNET_GATEWAY_TAG_NAME}" END # VPCIDの取得 EC2_VPC_ID=$( \ aws ec2 describe-vpcs \ --filters Name=tag:Name,Values=${EC2_VPC_TAG_NAME} \ --query 'Vpcs[].VpcId' \ --output text \ ) \ && echo ${EC2_VPC_ID} # インターネットゲートウェイIDの取得 EC2_INTERNET_GATEWAY_ID=$( \ aws ec2 describe-internet-gateways \ --filters Name=tag:Name,Values=${EC2_INTERNET_GATEWAY_TAG_NAME} \ --query "InternetGateways[].InternetGatewayId" \ --output text \ ) \ && echo ${EC2_INTERNET_GATEWAY_ID} # 変数の確認 cat << END # EC2_VPC_ID:"vpc-xxxxxxxxxxxxxxxxx" EC2_VPC_ID="${EC2_VPC_ID}" # EC2_INTERNET_GATEWAY_ID:"igw-xxxxxxxxxxxxxxxxx" EC2_INTERNET_GATEWAY_ID="${EC2_INTERNET_GATEWAY_ID}" END # インターネットゲートウェイのアタッチ aws ec2 attach-internet-gateway \ --vpc-id ${EC2_VPC_ID} \ --internet-gateway-id ${EC2_INTERNET_GATEWAY_ID} # アタッチの確認 aws ec2 describe-internet-gateways \ --filters Name=tag:Name,Values=${EC2_INTERNET_GATEWAY_TAG_NAME} \ --query "InternetGateways[].Attachments[?VpcId == \`${EC2_VPC_ID}\`].VpcId" \ --output text ルートテーブルの作成 前述の手順作成したVPCのルートテーブルを作成します。 CloudShell で以下のコマンドを実行していきます #以下のコマンドをコピペして実施すればできます # 変数の確認 cat << END # 0. AWS_REGION:"ap-northeast-1" AWS_REGION="${AWS_REGION}" # 1. EC2_VPC_TAG_NAME:"docker-vpc" EC2_VPC_TAG_NAME="${EC2_VPC_TAG_NAME}" # 2. EC2_ROUTE_TABLE_TAG_NAME:"docker-route-table" EC2_ROUTE_TABLE_TAG_NAME="${EC2_ROUTE_TABLE_TAG_NAME}" END # 変数設定 STRING_EC2_ROUTE_TABLE_TAG="ResourceType=route-table,Tags=[{Key=Name,Value=${EC2_ROUTE_TABLE_TAG_NAME}}]" \ && echo ${STRING_EC2_ROUTE_TABLE_TAG} # 変数の確認 cat << END # EC2_VPC_ID:"vpc-xxxxxxxxxxxxxxxxx" EC2_VPC_ID="${EC2_VPC_ID}" # STRING_EC2_ROUTE_TABLE_TAG:"ResourceType=route-table,Tags=[{Key=Name,Value=docker-route-table}]" STRING_EC2_ROUTE_TABLE_TAG="${STRING_EC2_ROUTE_TABLE_TAG}" END # ルートテーブルの作成 aws ec2 create-route-table \ --vpc-id ${EC2_VPC_ID} \ --tag-specifications ${STRING_EC2_ROUTE_TABLE_TAG} # 完了確認 aws ec2 describe-route-tables \ --filters Name=vpc-id,Values=${EC2_VPC_ID} \ Name=tag:Name,Values=${EC2_ROUTE_TABLE_TAG_NAME} \ --query "RouteTables[].Tags[?Key == \`Name\`].Value" \ --output text ルートの作成 前述の手順作成したルートを作成します。 CloudShell で以下のコマンドを実行していきます #以下のコマンドをコピペして実施すればできます # 変数確認 cat << END # 0. AWS_REGION:"ap-northeast-1" AWS_REGION="${AWS_REGION}" # 1. EC2_VPC_TAG_NAME:"docker-vpc" EC2_VPC_TAG_NAME="${EC2_VPC_TAG_NAME}" # 2. EC2_ROUTE_TABLE_TAG_NAME:"docker-route-table" EC2_ROUTE_TABLE_TAG_NAME="${EC2_ROUTE_TABLE_TAG_NAME}" # 3. EC2_ROUTE_DESTINATION_CIDR:"0.0.0.0/0" EC2_ROUTE_DESTINATION_CIDR="${EC2_ROUTE_DESTINATION_CIDR}" # 4. EC2_INTERNET_GATEWAY_TAG_NAME:"docker-internet-gateway" EC2_INTERNET_GATEWAY_TAG_NAME="${EC2_INTERNET_GATEWAY_TAG_NAME}" END # ルートテーブルのID設定 EC2_ROUTE_TABLE_ID=$( \ aws ec2 describe-route-tables \ --filters Name=vpc-id,Values=${EC2_VPC_ID} \ Name=tag:Name,Values=${EC2_ROUTE_TABLE_TAG_NAME} \ --query "RouteTables[].RouteTableId" \ --output text \ ) \ && echo ${EC2_ROUTE_TABLE_ID} # 変数確認 cat << END # EC2_ROUTE_TABLE_ID:"rtb-xxxxxxxxxxxxxxxxx" EC2_ROUTE_TABLE_ID="${EC2_ROUTE_TABLE_ID}" # EC2_ROUTE_DESTINATION_CIDR:"0.0.0.0/0" EC2_ROUTE_DESTINATION_CIDR="${EC2_ROUTE_DESTINATION_CIDR}" # EC2_INTERNET_GATEWAY_ID:"igw-xxxxxxxxxxxxxxxxx" EC2_INTERNET_GATEWAY_ID="${EC2_INTERNET_GATEWAY_ID}" END # ルートテーブル作成 aws ec2 create-route \ --route-table-id ${EC2_ROUTE_TABLE_ID} \ --destination-cidr-block ${EC2_ROUTE_DESTINATION_CIDR} \ --gateway-id ${EC2_INTERNET_GATEWAY_ID} # 完了確認 aws ec2 describe-route-tables \ --filters Name=vpc-id,Values=${EC2_VPC_ID} \ Name=tag:Name,Values=${EC2_ROUTE_TABLE_TAG_NAME} \ --query "RouteTables[].Routes[?DestinationCidrBlock == \`${EC2_ROUTE_DESTINATION_CIDR}\`].DestinationCidrBlock" \ --output text aws ec2 describe-route-tables \ --filters Name=vpc-id,Values=${EC2_VPC_ID} \ Name=tag:Name,Values=${EC2_ROUTE_TABLE_TAG_NAME} \ --query "RouteTables[].Routes[?DestinationCidrBlock == \`${EC2_ROUTE_DESTINATION_CIDR}\`].GatewayId" \ --output text サブネット作成 前述の手順作成したサブネットを作成します。 CloudShell で以下のコマンドを実行していきます #以下のコマンドをコピペして実施すればできます # 変数確認 cat << END # 0. AWS_REGION:"ap-northeast-1" AWS_REGION="${AWS_REGION}" # 1. EC2_VPC_TAG_NAME:"docker-vpc" EC2_VPC_TAG_NAME="${EC2_VPC_TAG_NAME}" # 2. EC2_SUBNET_TAG_NAME:"public-subnet" EC2_SUBNET_TAG_NAME="${EC2_SUBNET_TAG_NAME}" # 3. EC2_SUBNET_CIDR:"10.0.0.0/24" EC2_SUBNET_CIDR="${EC2_SUBNET_CIDR}" # 4. EC2_AZ_NAME:"ap-northeast-1a" EC2_AZ_NAME="${EC2_AZ_NAME}" END # サブネット STRING_EC2_SUBNET_TAG="ResourceType=subnet,Tags=[{Key=Name,Value=${EC2_SUBNET_TAG_NAME}}]" \ && echo ${STRING_EC2_SUBNET_TAG} # 変数確認 cat << END # EC2_VPC_ID:"vpc-xxxxxxxxxxxxxxxxx" EC2_VPC_ID="${EC2_VPC_ID}" # EC2_SUBNET_CIDR:"10.0.0.0/24" EC2_SUBNET_CIDR="${EC2_SUBNET_CIDR}" # EC2_AZ_NAME:"ap-northeast-1a" EC2_AZ_NAME="${EC2_AZ_NAME}" # STRING_EC2_SUBNET_TAG:"ResourceType=subnet,Tags=[{Key=Name,Value=public-subnet}]" STRING_EC2_SUBNET_TAG="${STRING_EC2_SUBNET_TAG}" END # サブネット作成 aws ec2 create-subnet \ --vpc-id ${EC2_VPC_ID} \ --cidr-block ${EC2_SUBNET_CIDR} \ --availability-zone ${EC2_AZ_NAME} \ --tag-specifications ${STRING_EC2_SUBNET_TAG} # 完了確認 aws ec2 describe-subnets \ --filters Name=vpc-id,Values=${EC2_VPC_ID} \ Name=tag:Name,Values=${EC2_SUBNET_TAG_NAME} \ --query 'Subnets[].Tags[?Key == `Name`].Value' \ --output text aws ec2 describe-subnets \ --filters Name=vpc-id,Values=${EC2_VPC_ID} \ Name=tag:Name,Values=${EC2_SUBNET_TAG_NAME} \ --query "Subnets[].CidrBlock" \ --output text aws ec2 describe-subnets \ --filters Name=vpc-id,Values=${EC2_VPC_ID} \ Name=tag:Name,Values=${EC2_SUBNET_TAG_NAME} \ --query "Subnets[].AvailabilityZone" \ --output text ルートテーブル更新 前述の手順作成したルートテーブルの更新をします。 CloudShell で以下のコマンドを実行していきます #以下のコマンドをコピペして実施すればできます # 変数確認 cat << END # 0. AWS_REGION:"ap-northeast-1" AWS_REGION="${AWS_REGION}" # 1. EC2_VPC_TAG_NAME:"docker-vpc" EC2_VPC_TAG_NAME="${EC2_VPC_TAG_NAME}" # 2. EC2_ROUTE_TABLE_TAG_NAME:"docker-route-table" EC2_ROUTE_TABLE_TAG_NAME="${EC2_ROUTE_TABLE_TAG_NAME}" # 3. EC2_SUBNET_TAG_NAME:"public-subnet" EC2_SUBNET_TAG_NAME="${EC2_SUBNET_TAG_NAME}" END # サブネットID EC2_SUBNET_ID=$( \ aws ec2 describe-subnets \ --filters Name=vpc-id,Values=${EC2_VPC_ID} \ Name=tag:Name,Values=${EC2_SUBNET_TAG_NAME} \ --query "Subnets[].SubnetId" \ --output text \ ) \ && echo ${EC2_SUBNET_ID} # 変数確認 cat << END # EC2_SUBNET_ID:"subnet-xxxxxxxxxxxxxxxxx" EC2_SUBNET_ID="${EC2_SUBNET_ID}" # EC2_ROUTE_TABLE_ID:"rtb-xxxxxxxxxxxxxxxxx" EC2_ROUTE_TABLE_ID="${EC2_ROUTE_TABLE_ID}" END # ルートテーブルの更新 aws ec2 associate-route-table \ --subnet-id ${EC2_SUBNET_ID} \ --route-table-id ${EC2_ROUTE_TABLE_ID} # 完了確認 aws ec2 describe-route-tables \ --route-table-ids ${EC2_ROUTE_TABLE_ID} \ --query "RouteTables[].Associations[?SubnetId == \`${EC2_SUBNET_ID}\`].RouteTableAssociationId" \ --output text Cloud9の構築 Cloud9の環境を作成行います Cloud9ダッシュボードにアクセスします。 リージョンが東京になっていることを確認します。 Create enviromentボタンを押下します。 Name に環境名を入れます ここでは docker-cloud9-env とします Description は説明なのでお好みで 設定値は以下を参照 基本はデフォルトのままで Instance type は無料枠があれば無料枠の t2.microがいいかも Network(VPC),Subnetについては作成したVPCを選択してください。 メニューから隠れているので + となっている部分を押下することで設定できます。 Next Stepボタンを押下すると確認画面に遷移します。 Create enviroment ボタンを押下するとCloud9環境が起動します。軌道には時間がかかります。 AWSCLIの設定 Dockerを使うだけなら不要ですがAWS CLIを使えるように更新をします sudo yum erase aws-cli -y aliasの追加 ~/.bashrc に対して以下を追加します。 alias sudo='sudo ' 追加後以下のコマンドで設定を反映させます。 source ~/.bashrc AWSCLIのインストール 以下のコマンドでインストールします sudo pip install awscli タブ補完の有効化 以下の内容を ~/.bashrc に対して追加を行います。 そのまま貼り付けるとインデントがずれるかもしれません。 この設定を行うことで正常にコマンドを実行したときに 緑色に 失敗すると赤になるようになります。 complete -C aws_completer aws PS1="\` if [ \$? = 0 ]; then echo \[\e[36m\] else echo \[\e[31m\] fi \`[\u@\h%]\[\e[0m\]\$ " 追加後以下のコマンドで設定を反映させます。 source ~/.bashrc AWS CLI完了確認 以下のコマンドでバージョンを確認する。 aws --version 今回はここまで Cloud9の環境はブラウザを閉じれば30分後に停止しますが、気になる方は手動で停止をしましょう。

AWS ECS でコンテナ毎のメトリクス（CPU使用率やメモリ使用率など）を取得する方法です。 ECSの起動タイプはEC2、Fargateにて確認しています。 取得できるメトリクスは以下サイトの「Type: Container」に記載のある項目です。 Amazon ECS の Container Insights パフォーマンスログイベント 概要 CloudWatch Container Insightsを有効にしたECSクラスターは、コンテナのメトリクス情報 （パフォーマンスログ）がCloudWatch Logsに出力されます。 そのログに対してCloudWatch Logs Insightsでクエリを実行することでメトリクスを取得できます。 本記事ではCPU使用率とメモリ使用率を取得します。 CloudWatch Logs Insightsを使う理由 ECSのメトリクスを取得する方法は他にもあると思いますが、以下に挙げる方法は使いづらい点があります。 CloudWatch Container Insightsのダッシュボード コンテナ毎の詳細なメトリクスがない。Container Insightsはクラスター毎、サービス毎、タスク毎のメトリクスをグラフ表示しますが、コンテナ毎のメトリクスは以下のように平均値しかありません。タスク内にコンテナを1つしか定義していない場合はタスク毎のメトリクスで十分な場合もありますが、複数定義している場合に困ることがあります。 Container Insightsのタスク毎のグラフは複数のタスクが同時に起動している場合、合算集計されたグラフになります。特定のタスクのみの結果が欲しい場合、CloudWatch Logs InsightsでタスクIDを絞る必要があります。 コンテナのホストであるEC2上でdocker stats等のコマンドを実行 FargateではホストのEC2が不可視のためこの方法は実行不可。 EC2にSSH接続やRDP接続で乗り込まないといけないので手間。 事前準備 ECSクラスターのContainer Insightsを有効にしておく ECSクラスターのContainer Insightsを有効にしておくことで、CloudWatch Logsにパフォーマンスログが出力されます。 Container Insightsを有効にする方法はこちらをご確認ください。 クラスターおよびサービスレベルの Amazon ECS でメトリクスの Container Insights の設定 集計実施 CloudWatch Logs Insightsでクエリを実行する 以下項目を入力し、クエリの実行をします。 　① ロググループ 　　　ECSコンテナのパフォーマンスログは以下名称で作成されています。 　　　/aws/ecs/containerinsights/{クラスター名}/performance 　②集計対象の期間 　③クエリ文 　　　クエリ文 参照 クエリ文 fields @timestamp, CpuUtilized, CpuReserved, CpuUtilized * 100 / CpuReserved as CpuUtilization, MemoryUtilized, MemoryReserved, MemoryUtilized * 100 / MemoryReserved as MemoryUtilization | filter ContainerName = "XXXXXXXXXXXXXXXXXX" and Type = "Container" and TaskId = "XXXXXXXXXXXXXXXXXX" | sort @timestamp asc | limit 10000 fields : 取得するメトリクス。上記クエリの内容は下表参照。 filter : コンテナ名、パフォーマンスログの種類、タスクIDで集計対象のログをフィルタ。 ※コンテナ名、タスクIDは環境に合わせて設定。 sort : タイムスタンプの昇順に表示。（デフォルトは降順） limit : 取得するログ件数。最大10,000。（デフォルトは1,000） fields 内容 @￰timestamp パフォーマンスログのタイムスタンプ CpuUtilized CPUユニット数の使用量 CpuReserved コンテナに対するCPUユニット数の割り当て CpuUtilization CPU使用率（CpuUtilized * 100 / CpuReserved で計算1） MemoryUtilized メモリ使用量（MiB） MemoryReserved コンテナに対するメモリの割り当て（MiB） MemoryUtilization メモリ使用率（MemoryUtilized* 100 / MemoryReservedで計算1） CloudWatch Logs Insightsのクエリ文の書き方詳細は以下参照。 CloudWatch Logs Insights のクエリ構文 実行結果 「結果をエクスポート」からCSV形式およびMarkdown形式で上記を出力できます。 CSVから簡単にグラフにできますね。 なお、ECSコンテナのパフォーマンスログは1分おきに出力されるため、それ以上細かい時間でのメトリクスは取得できません。 分母はコンテナに割り当てられたリソースであることに注意。EC2のリソースやタスクに割り当てたリソースではない。 ↩

CloudWatch Logs エージェントをインストールすると CloudWatch Logs の画面でEC2インスタンスで実行されているアプリケーションのログがリアルタイムに閲覧できます。 IAMロール設定 まずは適切なロールが必要です。 下記のポリシーで新規ロールを作って、そのロールをEC2インスタンスに割り当てます。 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "logs:CreateLogGroup", "logs:CreateLogStream", "logs:PutLogEvents", "logs:DescribeLogStreams" ], "Resource": [ "*" ] } ] } ロールが作成できたらEC2インスタンス一覧画面で、インスタンスを右クリックして、セキュリティーの中に IAMロール変更を選択すると簡単にロールを割り当てることができます。 CloudWatch Logs エージェント設定 まずはEC2にアクセスして、sudo apt-get updateを実行 インストールするコマンド： curl https://s3.amazonaws.com/aws-cloudwatch/downloads/latest/awslogs-agent-setup.py -O sudo python ./awslogs-agent-setup.py --region ap-northeast-1 pythonコマンドで実行失敗だったらpython2もしくはpython3で試してください。 インストールに５つのステップがあります。 ステップ３では何も入力せずエンターを押して進めていいです。 ステップ４では閲覧したいログファイルのパスを入力してから CloudWatch Logs のロググループ名を指定できます。 それから Stream名やタイムスタンプなど設定します。 それでは CloudWatch Logs エージェントのインストールと設定が完了です。問題なければ CloudWatch Logsのロググループメニューからログを閲覧できるようになります。 CloudWatch Logsエージェント自体のログを確認したい場合 tail -f /var/log/awslogs.log Regionなど変更したい場合 /var/awslogs/etc/aws.conf [plugins] cwlogs = cwlogs [default] region = ap-northeast-1 ログファイルやロググループ名なの変更したい場合 /var/awslogs/etc/awslogs.conf [production.log] file = /deploy/apps/ityogo/shared/log/production.log buffer_duration = 5000 log_stream_name = production initial_position = start_of_file log_group_name = ityogo-prd [puma_access.log] file = /deploy/apps/ityogo/shared/log/puma_access.log buffer_duration = 5000 log_stream_name = puma_access initial_position = start_of_file log_group_name = ityogo-prd [puma_error.log] file = /deploy/apps/ityogo/shared/log/puma_error.log buffer_duration = 5000 log_stream_name = puma_error initial_position = start_of_file log_group_name = ityogo-prd 変更してから awslogs を再起動すると反映されます。 sudo service awslogs restart インストールして設定しても CloudWatch Logs に反映しない場合の調査 まずは tail -f /var/log/awslogs.log コマンドでエージェント自体のログを確認してください。もしかしたら /var/awslogs/etc/awslogs.confで設定したタイムスタンプのフォーマットはログファイルのと違う可能性があります。 実は datetime_format という設定が不要みたいなので、/var/awslogs/etc/awslogs.conf で datetime_formatの設定を削除して、 awslogs を再起動すれば動くかもしれません。

背景 EC2　>　ロードバランシング　>　ロードバランサー 削除したいロードバランサーを選択してアクションで削除をクリック後、赤字でタイトルのエラーが表示され削除ができない 結論 統合サービスと連携している場合はまずそちらを削除する 今回は緑のチェックが入ったVPC エンドポイントサービス (AWS PrivateLink)を使用していたため、サービスIDをクリックし、サービスID先を削除することでELBの削除が可能になった 　メモ 上記の前に以下を行ったため、上記で削除できない場合は以下の作業も必要 EC2 > ロードバランサー > リスナー > 削除 EC2 > ターゲットグループ > 削除

ご挨拶 タイトルの通りLambdaからRDSへ接続してみたので記事を書いていきます。 最近業務でLambdaを使用することが増えてきたので勉強になればと思いやってみました。 やること LambdaでプライベートサブネットにあるRDS MySQLに向けてSQLを実行して実行結果を確認します。 今回RDSの作成はCloudFormationを使用しています。 事前にプライベートサブネットを二つ作成しています。 以下の手順で進んでいきます。 Lambda関数の作成 IAMロールの編集 RDSの作成 LambdaをRDSに接続できるように設定 テスト実行 構成図 参考にしたサイト チュートリアル: Amazon VPC の Amazon RDS にアクセスする Lambda 関数の設定 pymysqlのドキュメント やってみる 1. Lambda関数の作成 マネジメントコンソールからLambdaへ移動 移動後、関数→関数の作成をクリック クリック後上から順に以下の画像のように選択と入力を行います 関数名はお好みで大丈夫です。 今回はPythonを使用して関数を作成するのでランタイムはPython3.9を選択しました。 IAMロールは新しく作成してくれるものを選択することでCloudWatch logsへのアクセス権をいい感じに絞ったものが作成されます。 作成が完了したら一旦マネジメントコンソールでの作業は終わりでコードを作成します。 コード作成 pythonでMySQLの操作をするのにpymysqlというモジュールを使用します。 pymysqlはLambdaのデフォルトでは使用できないのでモジュールをzipにしてアップロードします。 lambda_function.py import os import pymysql host = os.environ['RDS_HOST_NAME'] user = os.environ['USER'] password = os.environ['PASS'] db = os.environ['DB'] connection = pymysql.connect(host=host, user=user, password=password, database=db) def lambda_handler(event, context): with connection.cursor() as cursors: cursors.execute('show databases') print(cursors.fetchall()) 作成されているスキーマを取得するものを作成しました。 execute()でSQLを実行して結果をfetchall()で取ってきています。 ここまで出来たらファイルを保存します。 保存したディレクトリ(フォルダ)と同じ階層にpymysqlを入れます。 以下のコマンドを実行します。 powershell pip install PyMySQL -t /ファイルがあるディレクトリ もしくはファイルがあるディレクトリに移動して以下のコマンド実行 pip install PyMySQL -t ./ インストールができたらファイルとモジュールを一つのzipにします。 zipができたらマネジメントコンソールに戻ってアップロードします。 以下の画面からアップロード元→.zipファイル→アップロードの順でクリックして上記手順で作成したzipファイルをアップロードします。 2. IAMロールの編集 上記1まで出来たらIAMロールを編集します。 RDSにアクセスできるようにするにはENIが必要なためIAMでアクセス権を与えます。 以下の画面の設定→アクセス権限→実行ロールのところでLambdaにアタッチされているIAMロールが確認できます。 そこからIAMロールをクリックすると編集ができます。 クリックするとIAMの画面に移動します。 移動したら「ポリシーをアタッチします」をクリックしてIAMポリシーを選択します。 選択するポリシーはAWSLambdaVPCAccessExecutionRoleです。 アタッチできたらIAMの設定は終了です。 3. RDSの作成 RDSの作成は以下のyamlで作成しました。 CloudFormationの使用方法は以下の記事の「CloudFormationでスタック作成」をご覧ください。 【AWS】 CloudFormationで基本的な構成のEC2とRDSを作る create_rds.yml AWSTemplateFormatVersion: "2010-09-09" Description: create rds #パラメータ Parameters: vpcid: Type: AWS::EC2::VPC::Id Description: Enter vpcid subnetid1: Type: AWS::EC2::Subnet::Id Description: Enter RDS subnetid subnetid2: Type: AWS::EC2::Subnet::Id Description: Enter RDS subnetid rdssubnetgroupname: Type: String Description: Enter RDS subnet groupname rdsdbname: Type: String Description: Enter RDS DBname rdsusername: Type: String Description: Enter RDS username AllowedPattern: '[a-zA-Z0-9]*' rdspassword: Type: String Description: Enter RDS password MinLength: '8' MaxLength: '41' AllowedPattern: '[a-zA-Z0-9]*' #リソース Resources: lambdasecuritygroup: Type: AWS::EC2::SecurityGroup Properties: GroupDescription: lambda-securitygroup SecurityGroupEgress: - IpProtocol: -1 FromPort: -1 ToPort: -1 CidrIp: 0.0.0.0/0 VpcId: !Ref vpcid rdssecuritygroup: Type: AWS::EC2::SecurityGroup Properties: GroupDescription: rds-securitygroup SecurityGroupEgress: - IpProtocol: -1 FromPort: -1 ToPort: -1 CidrIp: 0.0.0.0/0 SecurityGroupIngress: - IpProtocol: tcp FromPort: 3306 ToPort: 3306 SourceSecurityGroupId: !Ref lambdasecuritygroup VpcId: !Ref vpcid rdssubnetgroup: Type: AWS::RDS::DBSubnetGroup Properties: DBSubnetGroupDescription: rdssubnetgroup SubnetIds: - !Ref subnetid1 - !Ref subnetid2 DBSubnetGroupName: !Ref rdssubnetgroupname Tags: - Key: Name Value: rdssubnetgroup rdsinstance: Type: AWS::RDS::DBInstance Properties: AllocatedStorage: 20 DBInstanceClass: db.t2.micro DBSubnetGroupName: !Ref rdssubnetgroup DBName: !Ref rdsdbname Engine: mysql EngineVersion: "5.7.34" MasterUsername: !Ref rdsusername MasterUserPassword: !Ref rdspassword StorageType: gp2 Tags: - Key: Name Value: rdsinstance VPCSecurityGroups: - !Ref rdssecuritygroup 上記のテンプレートを使用してプライベートサブネットにRDSを作成します。 4. LambdaをRDSに接続できるように設定 RDSの作成ができたら環境変数を登録していきます。 Lambda関数の設定画面から環境変数→編集をクリック キーと値には以下の4つを設定します。 キー 値 RDS_HOST_NAME RDSのエンドポイント USER MySQLのユーザ (CloudFormationで作成時に入力したユーザ) PASS MySQLのパスワード (CloudFormationで作成時に入力したパスワード) DB DB名 (CloudFormationで作成時に入力したDB名) 次にVPCの設定を行います。 Lambdaの設定→VPC→編集をクリック クリックしたら上からVPC、サブネット、セキュリティグループを選択します。 VPCはRDSと同じVPCを選択します。 サブネットはプライベートサブネットを選択します。 セキュリティグループはCloudFormationで作成したlambda-securitygroupを選択します。 5. テスト実行 上記まで完了したらテスト実行してみます。 コード→Testをクリックします。 テストを実行してFunction Logsに以下のデータベースが出力されれば成功です。 データベース (('information_schema',), ('innodb',), ('lambda_to_rds',), ('mysql',), ('performance_schema',), ('sys',)) 感想 information_schemaが見れるので各テーブルのレコード数やAutoIncrementの数値を取ってきてCloudWatchメトリクスに登録するなどの活用ができそうだと思いました。(小並感) 使用方法によってはRDS Proxyというものを使用してLambdaからの大量の接続を維持することも検討する必要があるようです。 AWS LambdaでAmazon RDS Proxyを使用する

目次 1.はじめに 2.検証結果_gpoの優先順位 3.検証準備_ec2の作成および日本語化 4.検証準備_adインストールおよびdc昇格 5.検証_gpoの優先順位 6.まとめ はじめに Windows Serverの機能で、ユーザや機器の集中管理に利用できるActive Directoryですが、GPO(グループポリシーオブジェクト)の優先順位で時々混乱してしまうため、記事として整理しました。 GPOの優先順位で混乱することを減らすためには実際に手を動かすことが有効であると考え、実機を通した検証を行いました。尚、Active Directoryを使用するためにはWindows Serverが必要になってきますが、今回はAWSのEC2にてWindows Server2019を用意し、検証を実施しています。 検証結果_gpoの優先順位 今回2つの検証を実施しますが先に結果をまとめておきます。 検証内容 ①「競合するGPO」 →競合するGPOが存在するときの優先順位はどうなるか？ ②「強制」 VS 「継承のブロック」 →GPOの「強制」設定と「継承のブロック」設定はどちらが優先されるか？ 検証における構成 ・「test」OUを作成する。また、「test」OUの配下に「test-admin」OUを作成する。 ・「test-admin」OUにドメインユーザ「Administrator」を所属させる。 ・コントロールパネルへのアクセスを拒否するGPO「Deny-Control」を作成し、「test」OUにリンクさせる。 ・コントロールパネルへのアクセスを許可するGPO「Allow-Control」を作成し、「test-admin」OUにリンクさせる。 検証の結果 ①「競合するGPO」 →上記のような構成の場合、ユーザ「Administrator」はコントロールパネルへのアクセスが許可される。 →より近い階層のGPO(Allow-Control)が優先される！ ②「強制」 VS 「継承のブロック」 →「Deny-Control」に「強制」の設定をし、「test-admin」OUに「継承のブロック」設定をした場合。 →ユーザ「Administrator」はコントロールパネルへのアクセスが拒否される。 「強制」の設定が優先される。 結果としては上記のようになりますが、実際に実機にて確認されたい場合は次章以降を参考として頂ければと思います。 検証準備_ec2の作成および日本語化 まずはAWSにてEC2を作成していきます。また、今回利用するAMIが英語版のWindowsServerのため、利用言語設定にて日本語が使用できるようにします。 ・AWSマネジメントコンソールにログイン後、EC2の画面より、「インスタンスを起動」を押下する。 ・AMIの選択画面で「Microsoft Windows Server 2019 Base」の「選択」を押下する。 ・インスタンスタイプの選択画面で、デフォルトの「t2.micro」のまま「次のステップ：インスタンスの詳細の設定」を押下する。 ・インスタンスの詳細の設定画面で、「ネットワーク」、「サブネット」を今回はデフォルトのものを選択、「自動割り当てパブリックIP」を「有効」にして、「次のステップ：ストレージの追加」を押下する。 ・デフォルトのストレージのまま、「次のステップ：タグの追加」を押下する。 ・今回は「キー」に「Name」、「値」に「AD」と入力し、「次のステップ：セキュリティグループの設定」を押下する。 ・「新しいセキュリティグループを作成する」を選択し、今回は「セキュリティグループ名」、「説明」を「Windows-SG」とする。「RDP」が許可されていることを確認し、「確認と作成」を押下する。 ※一時的な検証用のため、ソースは「0.0.0.0/0」としておく。 ※今回の検証自体には支障が起きないが、ADサーバとして本格運用する際はDNS等、いくつかのプロトコルを許可する必要がある。 ・インスタンス作成の確認画面にて「起動」を押下する。 ・新しいキーペアを作成しダウンロードするか、既存のキーペアがあれば選択し、「インスタンスの作成」を押下する。 ・インスタンスが作成されたことを確認し、チェックを入れた上で、「接続」を押下する。 ・「RDPクライアント」にて、「パスワードを取得」を押下する。 ・「Browse」にてキーペアを選択し、内容がテキストボックスに表示されることを確認してから、「パスワードを復号化」を押下する。 ・Administratorのパスワードが表示されたらコピーをしておく。 ・リモートデスクトップ接続にて、今回作成したEC2インスタンスのパブリックIPアドレスを入力し、「接続」を押下する。 ・ユーザ名：Administrator、パスワード：先ほどコピーしたパスワードを貼り付け、「OK」を押下する。 ・EC2インスタンスにログイン後、スタートメニューから「Settings」を押下する。 ・「Time & Language」を押下する。 ・「Language」を押下する。 ・「Add a language」を押下する。 ・「日本語」を選択し、「Next」を押下する。 ・「Install」を押下する。 ・インストールが開始されるので、完了まで数分待つ。 ・「Will be display language after next sign-in」と表示されてから、「Sign out」をする。 ・再度EC2インスタンスにAdministratorでリモート接続し、スタートメニューの表示が日本語となっていることを確認。「コンピュータの管理」を押下する。 ・「ローカルユーザーとグループ」→「ユーザー」内、現在サインインしているローカルアカウント「Administrator」が存在することを確認する。 検証準備_adインストールおよびdc昇格 次に、作成および日本語化したEC2インスタンスに対し、Active Directoryのインストール、ドメインコントローラーへの昇格を実施します。 ・スタートメニューから「サーバーマネージャー」を押下する。 ・「役割と機能の追加」を押下する。 ・「次へ」を押下する。 ・「役割ベースまたは機能ベースのインストール」が選択されていることを確認し、「次へ」を押下する。 ・今回作成したサーバーが表示されるので、「次へ」を押下する。 ・「Active Directory Domain Service」にチェックを入れる。 ・ポップアップが表示されるので、「機能の追加」を押下する。 ・「Active Directory Domain Service」にチェックが入ったことを確認し、「次へ」を押下する。 ・機能の選択でデフォルトのまま、「次へ」を押下する。 ・「次へ」を押下する。 ・「インストール」を押下する。 ・インストールが開始されるので数分待つ。 ・サーバーマネージャーのフラグより、機能のインストール完了が確認できたら、「このサーバーをドメインコントローラーに昇格する」を押下する。 ・「新しいフォレストを追加する」を選択し、ドメイン名を入力後(今回はtest.localとした)、「次へ」を押下する。 ・ディレクトリサービス復元モードのパスワードを設定し、「次へ」を押下する。 ・デフォルトのまま、「次へ」を押下する。 ・「NetBIOSドメイン名」が自動入力されることを確認し、「次へ」を押下する。 ・デフォルトのパス指定のまま、「次へ」を押下する。 ・「次へ」を押下する。 ・「インストール」を押下する。 ・インストールが開始され、しばらくすると自動的にOS再起動が実施され、リモートデスクトップ接続のセッションが切断される。 ・「ドメイン名￥Administrator」にて再度、リモートデスクトップ接続を実施する。 パスワードはローカルのAdministratorで使用していたものと同一 ・ドメインのAdministratorでログイン後、「コンピュータの管理」を開き、「ローカルユーザーとグループ」の項目が存在しなくなったことを確認する。 ※ドメインコントローラーに昇格後、ローカルユーザーはドメインユーザーに移行される。 ・「サーバーマネージャー」から「Active Directory ユーザーとコンピューター」を押下する。 ・「Users」コンテナー内、現在ログインしているドメインのAdministratorが存在することを確認する。 ・「ドメイン名を右クリック」→「新規作成」→「組織単位(OU)」を押下する。 ・OU名を入力し(今回はtest)、「OK」を押下する。 ・「作成されたOUを右クリック」→「新規作成」→「組織単位(OU)」を押下する。 ※「test」OU配下に別のOUを作成する。 ・OU名を入力し(今回はtest-admin)、「OK」を押下する。 ・「test」OU、「test-admin」OUが作成されたことを確認し、「Users」コンテナー内、「Administratorを右クリック」→「移動」を押下する。 ・移動先として、「test-admin」OUを選択し、「OK」を押下する。 ・「test-admin」OU内にAdministratorが移動されたことを確認する。 検証_gpoの優先順位 ここから先はGPOを作成し、2つの検証を実施していきます。まずはGPOの作成からです。 ・「サーバーマネージャー」から「グループポリシーの管理」を押下する。 ・「グループポリシーオブジェクト」を右クリックし、「新規」を押下する。 ・GPOの名前(今回はDeny-Control)を入力し、「OK」」を押下する。 ・「Deny-Control」GPOが作成されることを確認する。 ・「test」OUを右クリック→「既存のGPOのリンク」を押下する。 ・「Deny-Control」を選択し、「OK」を押下する。 ・「test」OUに「Deny-Control」がリンクされること、また「test-admin」OUにもグループポリシーの継承より、「Deny-Control」が適用されることを確認する。 ・「Deny-Control」→「編集」を押下する。 ・「ユーザーの構成」→「ポリシー」→「管理用テンプレート」→コントロールパネル」→「コントロールパネルとPC設定へのアクセスを禁止する」を右クリック→「編集」を押下する。 ・「有効」を選択し、「OK」を押下する。 ・「Deny-Control」の設定を適用させるため、一度、サインアウトした後、再度ドメインのAdministratorでサインインする。 ・「Windows＋R」キー→「control」と入力→「OK」を押下する。 ・「Deny-Control」の設定により、コントロールパネルが開けないことを確認する。 ここで1つ目の検証を実施します。 ①競合するGPOの優先度 「test-admin」OUに対し、「Allow-Control」GPO(コントロールパネルへのアクセスを許可する)をリンクさせた場合、Administratorによるコントロールパネルへのアクセスがどうなるか。 ・「Allow-Control」のGPOを作成する。 ・「Allow-Control」を右クリック→「編集」を押下する。 ・「ユーザーの構成」→「ポリシー」→「管理用テンプレート」→コントロールパネル」→「コントロールパネルとPC設定へのアクセスを禁止する」を「無効」に設定する。 ・「test-admin」OUに「Allow-Control」をリンクさせ、「グループポリシーの継承」にて、優先順位が最も高くなっていることを確認する。 ・GPOの設定を適用させるため、一度、サインアウトした後、再度ドメインのAdministratorでサインインする。 ・「Windows＋R」キー→「control」と入力→「OK」を押下し、コントロールパネルが開けることを確認する。 検証「競合するGPO」の結果 →オブジェクト(今回の場合、ユーザ「Administrator」)に近い階層のGPOが優先される！ ②「強制」 VS　「継承のブロック」 検証①ではAdministratorが「Deny-Control」よりも、「Allow-Control」に近い階層であるため、コントロールパネルを開けることを確認しました。 そこで、「Deny-Control」に対し、「強制」の設定を適用してみます。 ・「Deny-Control」を右クリック→「強制」を押下 ・Administratorが所属する「test-admin」OUの「グループポリシーの継承」から、「Deny-Control」が強制となり、最も優先度が高くなっていることを確認します。 ・この状態で、サインアウトし、再度Administratorでログインした際、コントロールパネルは開けなくなっています。そこで、次に「継承のブロック」を設定してみます。 ・「test-admin」OUを右クリック→「継承のブロック」を押下する。 ・「Default Domain Policy」は継承のブロックにより、適用されなくなったが、「Deny-Control」は依然として強制となり、優先順位が最も高いことを確認する。 ・この状態で、サインアウトし、再度Administratorでログインしても、コントロールパネルは開けなくなっていることを確認する。 検証「「強制」 VS　「継承のブロック」」の結果 →「強制」が優先して適用される。 まとめ 今回、Active DirectoryにおけるGPOの優先順位を検証してみました。実際に手を動かすことで理解度も上がり、より知識の定着ができたと感じます。また、このようにチョコっと検証を行う上で、クラウドサービス(今回はAWS)は非常に便利だと実感しました。 以上、最後まで読んで頂きありがとうございました！

概要 https://qiita.com/okadarhi/items/5ff734c6472b83d51597 の続き。 AWS側で転送元のデータを作成するが、作成処理が完全に完了してから転送ジョブを実行して欲しいという要望があり、スケジュール実行ではなく、AWS側から手動で転送ジョブを実行する方法を検討した。 転送ジョブを実行するAPIがあるのだが、それは実行しかしてくれず、転送ジョブの成否は別のAPIで確認する必要があった。 実行するAPI: https://cloud.google.com/storage-transfer/docs/reference/rest/v1/transferJobs/run 確認するAPI: https://cloud.google.com/storage-transfer/docs/reference/rest/v1/transferOperations/get なので、転送ジョブの実行と確認を管理するジョブを作成しようと思い、Step Functionsを採用することにした。 その時行った検証作業を備忘録としてまとめる。 手順 Lambda関数の作成 レイヤーの作成 Google APIを実行するためのpythonクライアントライブラリーをLambdaで実行するためのレイヤーを作成する。 まずは、Cloud9上でLambdaレイヤーに使用するライブラリーファイルを作成する。 admin:~/environment $ mkdir python admin:~/environment $ pip install -t ./python google-api-python-client boto3 admin:~/environment $ zip -r google-api-python-client.zip python 次に、作成したライブラリーファイルをLambdaレイヤーのアップロードする。 Workload Identityの認証情報ファイルの配置 Workload Identityを使用してLambda関数でGoogle APIを実行するため、参照用の認証情報ファイルをS3バケットに格納する。 まずは、バケットを作成する。 次に、認証情報ファイルをアップロードする。 Storage Transfer Serviceの転送ジョブを実行するLambda関数の作成 Storage Transfer Serviceの転送ジョブを実行するLambda関数を作成する。 import os import boto3 from pprint import pprint from googleapiclient import discovery import google.auth s3 = boto3.resource('s3') def lambda_handler(event, context): bucket = s3.Bucket(os.environ['config_bucket_name']) bucket.download_file(os.environ['client_library_config'], '/tmp/' + os.environ['client_library_config']) os.environ['GOOGLE_APPLICATION_CREDENTIALS'] = '/tmp/' + os.environ['client_library_config'] scopes=['https://www.googleapis.com/auth/cloud-platform'] credentials, project = google.auth.default(scopes=scopes) service = discovery.build('storagetransfer', 'v1', credentials=credentials) job_name = os.environ['job_name'] job_body = { "projectId": os.environ['project_id'] } request = service.transferJobs().run(jobName=job_name, body=job_body) response = request.execute() pprint(response) return response ランタイムはpython3.9（x86_64）を指定する。 作成したレイヤーを指定する。 デフォルトのタイムアウト（３秒）は短いので、1分に変更する。 コードで指定した環境変数を設定する。 ※ここでは https://qiita.com/okadarhi/items/5ff734c6472b83d51597 で作成した転送ジョブを指定している。 Storage Transfer Serviceの転送ジョブのステータスを確認するLambda関数の作成 Storage Transfer Serviceの転送ジョブのステータスを確認するLambda関数を作成する。 import os import boto3 from pprint import pprint from googleapiclient import discovery import google.auth s3 = boto3.resource('s3') def lambda_handler(event, context): bucket = s3.Bucket(os.environ['config_bucket_name']) bucket.download_file(os.environ['client_library_config'], '/tmp/' + os.environ['client_library_config']) os.environ['GOOGLE_APPLICATION_CREDENTIALS'] = '/tmp/' + os.environ['client_library_config'] scopes=['https://www.googleapis.com/auth/cloud-platform'] credentials, project = google.auth.default(scopes=scopes) service = discovery.build('storagetransfer', 'v1', credentials=credentials) name = event['Payload']['name'] request = service.transferOperations().get(name=name) response = request.execute() pprint(response) return response ランタイムはpython3.9（x86_64）を指定する。 作成したレイヤーを指定する。 デフォルトのタイムアウト（３秒）は短いので、1分に変更する。 コードで指定した環境変数を設定する。 Step Functionsの作成 Storage Transfer Serviceの転送ジョブを実行して、ステータスを確認するStep Functionsを作成する Run: Storage Transfer Serviceの転送ジョブを実行するLambda関数を呼び出している。 Get: Storage Transfer Serviceの転送ジョブのステータスを確認するLambda関数を呼び出している。 　　　　　　　　　　Runで実行した転送ジョブを確認する。 Check: Getで取得した転送ジョブのステータスを確認する。 　　　　　　　　　　　　　　・ステータスがIN_PROGRESS→Waitステートに遷移し、一定時間経過後に再度Getを実行する。 　　　　　　　　　　　　　　・ステータスがSUCCESS→Successステートに遷移する。 　　　　　　　　　　　　　　・ステータスが上記以外→Failステートに遷移する。 実際の定義内容は以下の通り。 { "Comment": "This is your state machine", "StartAt": "Run", "States": { "Run": { "Type": "Task", "Resource": "arn:aws:states:::lambda:invoke", "Parameters": { "FunctionName": "<Storage Transfer Serviceの転送ジョブを実行するLambda関数>" }, "Retry": [<デフォルト設定>], "Next": "Get" }, "Get": { "Type": "Task", "Resource": "arn:aws:states:::lambda:invoke", "Parameters": { "Payload.$": "$", "FunctionName": "<Storage Transfer Serviceの転送ジョブのステータスを確認するLambda関数>" }, "Retry": [<デフォルト設定>], "Next": "Check" }, "Check": { "Type": "Choice", "Choices": [ { "Variable": "$.Payload.metadata.status", "StringMatches": "IN_PROGRESS", "Next": "Wait" }, { "Variable": "$.Payload.metadata.status", "StringMatches": "SUCCESS", "Next": "Success" } ], "Default": "Fail" }, "Wait": { "Type": "Wait", "Seconds": 10, "Next": "Get" }, "Fail": { "Type": "Fail" }, "Success": { "Type": "Succeed" } } } Step Functionsの実行 作成したStep Functionsを実行する。 →正常終了したことが確認できる。 →Google Cloud側でもStorage Transfer Serviceの転送ジョブが成功していることが確認できる。

概要 AWS環境に構築したシステムのデータを、Google Cloud環境にあるデータレイク（GCS）に格納して欲しいという依頼があり、Storage Transfer Serviceを使って、S3バケットからGCSバケットにデータ転送することにした。 また、なるべく永続的なキー情報を使用せずに対応して欲しいとの要望があり、 Storage Transfer Serviceの環境構築するために、Workload Identityを使用すること Storage Transfer ServiceがS3バケットのアクセス設定でフェデレーションIDを使用すること を提案しようと思ったが、まずはちゃんと実装できることを確認するために検証作業を行った。 その時に実施した作業内容を備忘録としてまとめる。 手順 Workload Identityの設定 Workload Identityを設定して、JSONの認証情報ファイルを取得する。 手順はNRIネットコムの記事が綺麗に纏まっているので割愛。 https://tech.nri-net.com/entry/2021/07/01/111020 サービスアカウントの権限付与 Workload Identityに関連付けたサービスアカウントに対して、Google Cloud側で許可する操作権限を付与する。 今回は、Storage Transfer Serviceの転送ジョブを作成するので、Storage Transfer 管理者をアタッチする。 転送元のS3バケットの作成 転送元のS3バケットを作成する。 転送先のGCSバケットの作成 転送先のGCSバケットを作成する。 転送元のS3バケットへのアクセス設定 データソースのS3バケットに対して、Storage Transfer Serviceがアクセスするための設定を行う。 今回は、Google Cloud側でAWSのアクセスキーとシークレットを管理したくないという要件があったので、フェデレーション IDで設定する。 手順はKSKSKSKS2さんの記事が綺麗に纏まっているので割愛。 https://ksksksks2.hatenadiary.jp/entry/20211005/1633391108 AWS環境から転送ジョブの作成 AWSアカウント上のCloud9から、Storage Transfer Serviceの転送ジョブを作成する。 認証情報ファイルの配置 事前作業として、Cloud9上にWorkload Identity設定で取得した認証情報ファイルを配置する。 →「clientLibraryConfig-awstogcp.json」が認証情報ファイル。 転送ジョブ作成スクリプトの作成 次に、転送ジョブを作成するためのpythonファイルを作成する。 基本的に以下ドキュメントに記載されているpythonスクリプトを踏襲する。 https://cloud.google.com/storage-transfer/docs/reference/rest/v1/transferJobs/create Workload Identityを使用して、Google Cloud環境にアクセスするため、一時変更する。 変更内容としては、以下の通り。 from pprint import pprint from googleapiclient import discovery # Workload Identityを使用するため不要。 """ from oauth2client.client import GoogleCredentials credentials = GoogleCredentials.get_application_default() """ # Workload Identityを使用するため追加。 ### ここから ### import google.auth scopes=['https://www.googleapis.com/auth/cloud-platform'] credentials, project = google.auth.default(scopes=scopes) ### ここまで ### service = discovery.build('storagetransfer', 'v1', credentials=credentials) transfer_job_body = { # TODO: Add desired entries to the request body. } request = service.transferJobs().create(body=transfer_job_body) response = request.execute() # TODO: Change code below to process the `response` dict: pprint(response) 転送ジョブ作成スクリプトの実行 まず、配置した認証情報ファイルを環境変数GOOGLE_APPLICATION_CREDENTIALSに設定する。 admin:~/environment $ export GOOGLE_APPLICATION_CREDENTIALS=~/environment/clientLibraryConfig-awstogcp.json 次に、Google APIを実行するためのpythonクライアントライブラリーをインストールする。 admin:~/environment $ pip install --upgrade google-api-python-client 最後に、作成したスクリプトを実行する。 admin:~/environment $ python create-tranferjob.py {'creationTime': '2021-10-29T18:34:20.709570416Z', 'lastModificationTime': '2021-10-29T18:34:20.709570416Z', 'name': 'transferJobs/okada-transferjob', 'projectId': '<転送先のGoogle CloudプロジェクトID>', 'schedule': {}, 'status': 'ENABLED', 'transferSpec': {'awsS3DataSource': {'bucketName': 'okada-source-bucket-202110', 'roleArn': '<転送元のS3バケットへのアクセス設定で作成したIAMロール>'}, 'gcsDataSink': {'bucketName': 'okada-destination-bucket-202110'}}} admin:~/environment $ 実行結果から問題なく作成されたことが確認できる。