AWS Cloud Practitiner Essential 殴りがき 責任共有モデル AWS利用者の責任 = クラウド内のセキュリティについて責任を負う AWS利用者のデータ プラットフォーム・アプリケーション・アイデンティティアクセスの管理 OS・ネットワーク・ファイアウォールの設定 クライアント側のデータ暗号化・サーバー側のデータ暗号化・ネットワークトラフィックの保護 AWSの責任 = クラウドのセキュリティについて責任を負う ソフトウェア コンピューティング・ストレージ・データベース・ネットワーク AWSグローバルインフラストラクチャ・リージョン・エッジロケーション・アベイラビリティーゾーン EC2の責任モデルで言うと？ AWS利用者 クラウド内のセキュリティについて責任を負う。クラウド内で作成して配置したすべてのもの データ アプリケーション OS AWSの責任 クラウドのセキュリティについて責任を負う ハイパーバイザー ネットワーク 物理レイヤー ユーザーのアクセス許可とアクセス権 ルートユーザー AWSアカウントの所有者。オーナー。 できることの制限はない。 作成後すぐにMFA認証するように設定すること。 ルートユーザー作成後、IAMユーザーを作成し、そのIAMユーザーに他のユーザーを作成・IAMポリシーを付与できる権限を与える。　そして、ルートユーザーから抜けて、そのIAMユーザーを使う。 AWS IAM (AWS Identity and Access Management) デフォルトのIAMユーザーでは、すべてのアクセス権限がない。 明示的に必要最低限のアクセス権限を付与しなければ何もできない。 本当に必要なアクセス権のみを付与すること。(最小特権の原則) AWSにアクセスするユーザーごとに、個別のIAMユーザーを作成すること。同じ設定をするユーザーが複数いる場合でも、各IAMユーザーを作ることで、セキュリティが強化される。　⇦　一意のセキュリティ認証情報の組み合わせを設定できるため。 IAMポリシーをIAMユーザーに付与することで権限が与えられる。 IAMポリシーとは、各サービスのAPIを実行可能であること・実行不可能であることを記述したJSONドキュメント IAMポリシーの例.json { "Version": "2021-10-17", "Statement": { "Effect": "Allow", "Action": "s3:ListBucket", "Resource": "arn:aws:s3:::coffee_shop_reports" } Effect: 許可するのか、拒否するのか Action: AWSのAPIコール(対象の操作) Resource: APIコールの対象となるAWSリソース IAM グループ IAMユーザーをまとめたもの。 IAMグループに対して、IAMポリシーを付与することにより、そのグループ内のすべてのIAMユーザーにポリシーを付与することができる。 IAM ロール ロールは一時的に付与されるもの。 一時的にできることを許可・拒否する際に付与する。 IAMポリシーより効力が強いため、IAMポリシーで拒否していても、ロールで許可が付与されれば実行可能となる。 ロールは、ユーザーだけではなく、アプリケーションやサービスに付与することができる AWS Organizations 複数のAWSアカウントを一元的に管理するサービス IAMは1つのアカウントの中に作られるものであり、ポリシーはあくまで同一アカウント内での制御。 AWS Organizationはイメージとして、複数のアカウント(複数のルートユーザー間)でリソースを共有したり、制御したりすること。 Organizationsを作ると、一つのルートが一番親として作成される。 複数のAWSアカウントに対して、OU(組織単位)でグルーピングする機能がある。　⇦　一つのアカウント内で言う、IAMグループのようなものを、アカウントをまたいで作る。 AWSアカウント間でリソースを共有できる。 すべてのアカウントの請求を一括請求できる。 一括請求にすることで、割引が発生することもある。 アカウントの階層的なグループ化ができる。 各アカウントがアクセスできる　APIを制御できる。 SCP (サービスコントロールポリシー) を使って、各アカウントのアクセス許可を一元的に制御できる。　⇦　一つのアカウントで言うロールと同じ役割。 コンプライアンス AWS Artifact AWSのセキュリティ・コンプライアンスレポートをオンデマンドで利用できる 特定のオンライン契約を提供 AWS Artifact Agreements AWSとの契約に署名する際に活用する アカウント(個別・Organizations)において契約の確認・受諾・管理を行うことができる。 AWS Artifact Reports AWSを活用する上で保証されている特定の規制基準に準拠する責任に関する詳細情報を確認できる。 AWSのサードパーティー(外部の人)を監査人としてテスト・検証している。 カスタマーコンプライアンスセンター AWSユーザーのコンプライアンスに関するストーリーを読み、様々な課題をどのように解決したかを確認できる。 コンプライアンスに関する質問に対する　AWSの解答 AWS リスクとコンプライアンスの概要 セキュリティ監査チェックリスト 監査人むけのラーニングパス などが確認できる。 サービス妨害攻撃 DoS攻撃・DDoS攻撃などがかけられる。 AWS Shield DoS攻撃・DDos攻撃を防ぐためのサービス AWS Shield Standard すべてのAWS利用者が無料で使える。 ベーシックなDDoS攻撃からAWSリソースを保護する 悪意のあるトラフィックをリアルタイムで検出し、攻撃を緩和する AWS Shield Advanced 詳細な攻撃診断・高度なDDoS攻撃の検出・緩和機能を提供する 有料 複雑なDDoS攻撃に対してカスタムルールを作成して、AWS ShieldをAWS WAFと統合することが可能 その他のセキュリティサービス 暗号化するタイミング データを保存する際 データの送受信の際 AWS KMS (AWS Key management Service) 各サービスのデータ暗号化に使われる。 暗号化キー(暗号化用・復号用)の作成・管理・使用を行う。 AWS WAF CloudFront, Load Balancerと連動するウェブアプリケーションファイアウォール。 ネットワークACLと同じようにトラフィックに対してステートレスで動作するが、Webアクセスを対象とする。 (ネットワークACLはWebに限らず。ネットワークと通るトラフィックすべて。) 指定したIPアドレスを除くすべてのリクエストを許可する感じ つまり、拒否したいIPアドレスをリストに登録しておく。 AWS Inspector AWS利用者がサービスを構築した際のセキュリティ評価を実行する。 ベストプラクティスと比較して、逸脱しているか判定する EC2インスタンスの露出・脆弱性などの確認 サービスを実行する際に、AWS Inspectorを埋め込む。そして、各サービスの脆弱性やその対策など生成する。　 ネットワークの到達性に関する設定 Amazon エージェント EC2インスタンスにインストールできる セキュリティ評価サービス などから構成されている。 ※　ただし、すべてのセキュリティ問題が解決されることを保証はしない。 クラウド内の責任はAWS利用者にあるものだから。 Amazon GuardDuty 脅威検出サービス ネットワークアクティビティの連続ストリームを分析する。(機械学習？？) ネットワークとアカウントのアクティビティを継続的にモニタリングし、脅威を特定する。修復手順なども記載される。 そのセキュリティ調査結果に応じて自動的に修復手順を実行するように　AWS Lambda を設定することもできる サービスに埋め込むなどはせず、独立して実行される。 AWS利用者は、インスタンスに対してセキュリティソフトを入れる必要はなくなる。

目的 AWS外のサービスからURL形式でLambdaを呼び出せるようにAPI Gatewayの発行とLambdaの統合をしました。 前提 AWSアカウントを有しており、コンソール上で操作ができること。 やったこと ①適当なLambdaの作成 ②API Gatewayの発行とLambda統合 ①適当なLambdaの作成 AWSコンソール > Lambda にて関数の作成を押下します。 今回はNode.jsで適当なLambdaを作るだけなので「一から作成」とNode.jsのバージョンを選択します。 関数の作成を押下します。 関数が作成され、コードソース画面に遷移するので「Test」ボタンを押下し、適当なお名前を付けたテストイベントを作成します。 改めて「Test」したときにレスポンスが以下であればOKです。 { "statusCode": 200, "body": "\"Hello from Lambda!\"" } ②API Gatewayの発行とLambda統合 ①で作ったLambdaはいったん寝かせておいて、API Gatewayを仕込みます。 AWSコンソール > API Gateway　よりAPIの作成を行います。 APIタイプはHTTPを選択しました。「構築」ボタンを押下します。 さっき作ったLambdaを選択します。 API名はよしなに付けます。 「次へ」を押して設定できるルートとステージは特に何もしていません。 そのまま作成完了しました。 作成後の画面で表示される「URLを呼び出す」のリンクは罠です。そのまま飛んでもLambdaは呼び出されません。 押下すると新しいブラウザのタブが開いて以下表示されます。悲しみ。 {"message":"Not Found"} API Gateway のルートを開いて、URLの後ろにパスを付け足して再検索してみましょう。 今回の例であれば https:// hogehuga.execute-api.ap-northeast-1.amazonaws.com/testfunc になります。 うまくいけば②で作ったLambdaが覚醒して画面上に以下表示されます。うれしみ。 "Hello from Lambda!" 終わり

こんばんは。natariです。 社内システムの構築プロジェクトが終わったので、日記風にどんなことをやったかを書いていきます。 まず、プロジェクトの概要ですが、社内でExcelで管理している出社状況データ(今日は○○さんはテレワークだよーとか、〇日はお休みだよーとか、部の出社率とかを管理するもの)のweb化でした。 上長からこんな技術使ってとか、こんな風に作ってという指定はありませんでした。 なのでまずは社内の集会などを利用して、どんなシステムを作ったらいいかという皆さんの要望を聞き出すヒアリングから開始しました。 大体20人くらいの方から意見を頂き、すべての意見を反映させることは出来ないので、要望の数が多いものをピックアップして、あとはExcelで管理していたデータをそのままweb上で再現することとしました。 ここで僕にとって幸福だったのは、使用技術の指定がなかったことです。ちょうどプライベートでReactやTypeScript、Node.js、AWSあたりを勉強していたので、SPAでWebアプリを作ってみようと思い、この4つの技術を使うこととしました。 SPAについて簡単に説明すると、従来のよくあるフレームワークでのWebアプリの作り方とは異なり、クライアントとサーバーサイドを独立させて、データのみをやり取りする手法です。 ちなみに現在はGolangで別途APIサーバを作ってこんな感じで機能追加する予定です。 (プライベートで) まず、React(クライアント側)ですが、stateとpropsを使っていきます（当たり前)。 社内には部署が4つあります。そのため部署1～4のstateが必要です。 そしてカレンダーは月ごとに管理しているので、年(2022とか)と月(1～12)のstateも必要です。 次にログイン機能です。ログイン機能の作成についてはこちらの記事で詳しく説明しています。 https://qiita.com/natarisan/items/b43219f03566da8d0a66 ログインしているクライアント情報を保持するstateも必要です。 これらのstateをprops(場合によってはuseContextとか)を用いてうまいことコンポーネント間で共有します。 そして、各stateが変わったとき、そのstate応じたデータをfetchメソッドやaxiosメソッドでNodeサーバと通信して取ってきます。こんな感じで、fetchメソッドの中に現在のstateを当てはめる形でサーバにリクエストを送りました。 データベースもstateに対応するよう作成し、stateに対応するデータを返すようにしました。 同じくサーバ側で対応するデータの出社率計算機能も作成し、ひとまずアプリは完成です。 React-routerなども用いてやっとSPAっぽくなったなあという印象でした。 続いての記事は、作成したアプリをAWSにデプロイするまでを書いていきます。 今回は以上です。

EC2環境にデプロイしていたRailsアプリのデータベースを後からRDSに移行したので自分自身の復習も兼ねて手順をまとめました。 前提 Rails -v 6.0.4 MySQL -v 5.7.36 サーバー： nginx AWS側の設定 AWSのRDSダッシュボードを開く 「データベースの作成」を選択 エンジンのタイプを選択 現在使用しているSQLの種類を選択。 今回はMySQLを選択します。 4.MySQlのバージョンを選択 現在使用しているMySQLのバージョンと同じものを選択します。 MySQLのバージョンの確認方法は下記の通りです。 [ec2-user]$ mysql -u root -p mysql> select version(); 5.テンプレートを選択 今回は無料枠を利用することとします。 下の方に概算コストが表示されるので高性能なテンプレートを選択する場合はそちらを確認してください。 6.基本情報を設定 いずれの項目も自由に設定できますがマスターユーザー名とパスワードは後で使用するので控えるようにしてください。 7.DBインスタンスのクラスを選択 db.t2.microを選択します。1GBのメモリを搭載、実験に適したサイズです。 8.ストレージを設定 今回は初期設定のままとします。 １年間は無料利用枠の対象となります。 9.可用性と耐久性 無料利用枠のテンプレートを選択した場合こちらは設定できないのでスルーします。 10.接続の設定 VPCとサブネットグループに関しては現在使用しているEC2インスタンスと同じ場所に作成します。 パブリックアクセスはこのDBインスタンスにパブリックIPを割り当てるかどうかを設定するものになります。同じVPCに設置したEC2インスタンスから接続できれば十分なので「いいえ」を選択します。「はい」にすると攻撃されるリスクがあります。 VPCセキュリティグループは新規で作成します。あとで中身は設定します。 アベイラビリティゾーンはEC2インスタンスと同じ場所に配置するので自身のEC2インスタンスのアベイラビリティゾーンを確認して選択してください。 11.データベースの作成を選択する 残りの項目については今回はデフォルトのままでいきます。 12.データベースの完成を待つ DBインスタンス一覧から先ほど作成したDBインスタンスのステータスを確認し、「利用可能」となっていれば作成は完了です。 13.セキュリティグループの設定 DBインスタンスをクリックし、「接続とセキュリティ」からセキュリティグループを選択。「インバウンドルールの設定を編集」を選択。 デフォルトの設定を削除し、下記のように設定します。 ソースには使用しているEC2インスタンスに設定したセキュリティグループIDを指定します。 ここまで設定したら「ルールを保存」してください。 14.エンドポイントを確認する 再度、RDSダッシュボードからDBインスタンスを選択し、エンドポイント欄の数値をどこかにコピーしておいてください。 EC2上のMySQLからDBインスタンスにデータを移行する ここからはターミナル操作でデータを移行する手順です。 15.EC2インスタンス上でバックアップを取る [ec2-user]$ mysqldump --databases railsdb -u root -p > /tmp/railsdb.sql 'railsdb' の箇所は現在MySQL上で使用している移行したいデータベース名に置き換えてください。 ここで要求されるパスワードはrootユーザーのパスワードを入力してください。 16.RDSのDBインスタンスにリストアする mysql -h [エンドポイント] -u admin -p < /tmp/railsdb.sql エンドポイントには先ほど確認したエンドポイントを入力し、'admin'のところには先ほど設定したRDSのユーザー名を入力してください。ここで求められるパスワードもRDS用のマスターパスワードを入力します。 Rails側の設定 ここからはRailsのdatabase.ymlの設定を変更します。 17.database.ymlを書き換える #変更前のdatabase.yml production: <<: *default database: <%= Rails.application.credentials.db[:database] %> username: <%= Rails.application.credentials.db[:username] %> password: <%= Rails.application.credentials.db[:password] %> socket: <%= Rails.application.credentials.db[:socket] %> 環境変数としてそれぞれ設定してありますがRDS用のuser名とpasswordに変更していきます。さらにhostの項目を追加します。 #localターミナル $ EDITOR=vim bin/rails credentials:edit credentials.yml db: database: 変更しない username: admin(RDS用のユーザー名) password: RDS用の設定したPW socket: 変更しない host: エンドポイント #変更後のdatabase.yml production: <<: *default database: <%= Rails.application.credentials.db[:database] %> username: <%= Rails.application.credentials.db[:username] %> password: <%= Rails.application.credentials.db[:password] %> socket: <%= Rails.application.credentials.db[:socket] %> host: <%= Rails.application.credentials.db[:host] %> これで移行自体は完了です。 RDSのtime-zone設定 上記の時点でRDSへ移行は完了しましたがRDSはデフォルトでtime-zoneがUTCで設定されています。 [ec2-user]$ mysql -h [エンドポイント] -P 3306 -u [RDSのユーザー名] -p mysql> show variables like '%time_zone%'; +------------------+------------+ | Variable_name | Value | +------------------+------------+ | system_time_zone | UTC | | time_zone | UTC | +------------------+------------+ mysql> SELECT NOW(); UTC時間が表示される system_time_zoneはいじれないようなのでtime_zoneの方を日本時間に設定する手順を紹介します。 1.AWSのRDSページにアクセスする 2.パラメータグループを選択する 3.パラメータグループの作成を選択 4.time_zoneの項目にAsia/Tokyoを選択し、保存する 5.ダッシュボードから変更を選択 6.DBパラメータグループに先ほど作成したグループを選択。 変更を保存する。 7.「アクション」から再起動を選択 再起動後、DBインスタンスの設定項目のパラメータグループが「同期中」となっていることを確認する。 [ec2-user]$ mysql -h [エンドポイント] -P 3306 -u [RDSのユーザー名] -p mysql> show variables like '%time_zone%'; +------------------+------------+ | Variable_name | Value | +------------------+------------+ | system_time_zone | UTC | | time_zone | Asia/Tokyo | +------------------+------------+ mysql> SELECT NOW(); 日本時間が表示される 上記のようになっていればOK.

まずはセットアップするところまで。 せっかく書いたから投稿するけど、Greengrassタグが65個あったのでもっといい記事がありそう.. ラズパイの基本セットアップについて 詳細は下記参照。ラズパイのセットアップ、アップグレード、sshなどを設定。 環境のみ抜粋する。 使用モデル：Raspberry Pi 4 Model B (RAM 4GB) $ cat /etc/os-release PRETTY_NAME="Raspbian GNU/Linux 11 (bullseye)" NAME="Raspbian GNU/Linux" VERSION_ID="11" VERSION="11 (bullseye)" VERSION_CODENAME=bullseye ID=raspbian ID_LIKE=debian HOME_URL="http://www.raspbian.org/" SUPPORT_URL="http://www.raspbian.org/RaspbianForums" BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs" 前準備（AWS側） IAMロールを作成 インストーラーがリソースをプロビジョニングするための最小限の IAM ポリシーを参考にして、下記ポリシーを持ったロールを作成する。 以下、GreengrassRoleとする。 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "iot:AddThingToThingGroup", "iot:AttachPolicy", "iot:AttachThingPrincipal", "iot:CreateKeysAndCertificate", "iot:CreatePolicy", "iot:CreateRoleAlias", "iot:CreateThing", "iot:CreateThingGroup", "iot:DescribeEndpoint", "iot:DescribeRoleAlias", "iot:DescribeThingGroup", "iot:GetPolicy", "iam:GetRole", "iam:CreateRole", "iam:PassRole", "iam:CreatePolicy", "iam:AttachRolePolicy", "iam:GetPolicy", "sts:GetCallerIdentity" ], "Resource": "*" }, { "Sid": "DeployDevTools", "Effect": "Allow", "Action": [ "greengrass:CreateDeployment", "iot:CancelJob", "iot:CreateJob", "iot:DeleteThingShadow", "iot:DescribeJob", "iot:DescribeThing", "iot:DescribeThingGroup", "iot:GetThingShadow", "iot:UpdateJob", "iot:UpdateThingShadow" ], "Resource": "*" } ] } ロール作成後、GreengrassRoleのページの「認証関係」タブを選択し、「認証関係の編集」ボタンを押下。 jsonで下記を設定する。アカウントIDは12桁の数値、ユーザ名は次手順で作成するユーザ名（本資料ではGreengrassUser）に置き換えること。 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::<アカウントID>:user/<ユーザ名>" }, "Action": "sts:AssumeRole" } ] } IAMユーザを作成 IAM > ユーザー から「ユーザーを追加」ボタンを押下。 ユーザー名： 適当な名称（以下、GreengrassUser とする）。 AWS認証情報タイプを選択： アクセスキーのみチェック。 ユーザーにつけるポリシー： アカウントID、ロール名（本資料ではGreengrasRole）は置き換えること。 { "Version": "2012-10-17", "Statement": [ { "Action": [ "sts:AssumeRole" ], "Effect": "Allow", "Resource": [ "arn:aws:iam::<アカウントID>:role/<ロール名>" ] } ] } 作成後、アクセスキー＆シークレットアクセスキーを書き留めておく。 前準備（ラズパイ側） AWS IoT greengrass（AWSマネジメントコンソール）にも手順が記載されているが、前準備も含めて具体的に記載する。 ラズパイにJDK（JAVA）をインストール $ sudo apt install default-jdk インストール後のバージョン $ java --version openjdk 11.0.13 2021-10-19 OpenJDK Runtime Environment (build 11.0.13+8-post-Raspbian-1deb11u1) OpenJDK Server VM (build 11.0.13+8-post-Raspbian-1deb11u1, mixed mode) AWS CLIをインストール。ラズパイへのインストール方法が以下に詳しく記載されている。 JSON成型用にjqコマンドをインストール $ sudo apt install jq AWS CLIをセッティング。 $ aws configure AWS Access Key ID [None]:　　　　※前手順で書き留めたIAMユーザのアクセスキー AWS Secret Access Key [None]:　　※　　　　　　〃　　　　　　　 シークレットアクセスキー Default region name [None]:　　　※ap-northeast-1　を入力（東京リージョン以外は適宜変更） Default output format [None]:　　※そのままReturnキー押下（jsonとなる） セッショントークンを取得＆環境変数に設定。 AWS_ACCESS_KEY_ID、AWS_SECRET_ACCESS_KEYはconfigureの設定値を見て欲しいのに、環境変数に入れないとダメっぽい... $ export STSRES=$(aws sts assume-role --role-arn arn:aws:iam::<アカウントID>:role/GreengrasRole --role-session-name sts-session --duration-second 3600 --profile default) #echo $STSRES | jq . $ export AWS_ACCESS_KEY_ID=$(echo $STSRES | jq -r '.Credentials.AccessKeyId') $ export AWS_SECRET_ACCESS_KEY=$(echo $STSRES | jq -r '.Credentials.SecretAccessKey') $ export AWS_SESSION_TOKEN=$(echo $STSRES | jq -r '.Credentials.SessionToken') $ unset STSRES Greengrassをラズパイにインストール マネジメントコンソールからGreengrassのセットアップページへ移動し、「1 つの Core デバイスをセットアップ」ボタンを押下。 以下、入力する。 ステップ 1: Greengrass コアデバイスを登録する コアデバイス名：適当な名称を入力。（本資料ではGreengrass-rsp001とした） ステップ 2: モノのグループに追加して継続的なデプロイを適用する モノのグループ： 「新しいグループ名を入力」を選択し、適当な名称を入力。（本資料ではGreengrassQuickStartGroupとした） ステップ 3: Greengrass コアソフトウェアをインストール オペレーティングシステム： 「Linux」を選択 上記まで入力すると、ページの下半分に記載されているコマンド内容が動的に変わる。 以下はマネジメントコンソールにも記載されているが念のため記載しておく。 ※設定値によってコマンド引数が変わるため、コピペした方がよい Greengrassインストーラのダウンロード　　※ラズパイで実行 $ cd /tmp $ curl -s https://d2s8p88vqu9w66.cloudfront.net/releases/greengrass-nucleus-latest.zip > greengrass-nucleus-latest.zip && unzip greengrass-nucleus-latest.zip -d GreengrassCore Greengrassインストーラの実行　　※ラズパイで実行 $ sudo -E java -Droot="/greengrass/v2" -Dlog.store=FILE -jar ./GreengrassCore/lib/Greengrass.jar --aws-region ap-northeast-1 --thing-name Greengrass-rsp001 --thing-group-name GreengrassQuickStartGroup --component-default-user ggc_user:ggc_group --provision true --setup-system-service true --deploy-dev-tools true 失敗する場合は、一時権限を1hで取得しているため、aws sts コマンドでセッショントークンを再取得＆再設定するとよい。 コマンド実行後（コマンドはすぐ返ってくるが）AWS側で登録されるまで10～20分かかる。 インストール後の確認 AWS IoT > Greengrass > コアデバイスのページにコアデバイスが追加されていることを確認する。 AWS IoT > 管理 > モノのページにもデバイスが追加されていることを確認する。 AWS IoT > 証明書に証明書が追加されていることを確認する。　※念のため詳細割愛 どうやら後は証明書による認証でAWSと通信するっぽい。 AWS IoT > ポリシーが2つ追加される コアデバイスのポリシーは以下ポリシーの権限に加え、STSでロールエイリアス（GreengrassV2TokenExchangeRoleAlias）が追加されて使われる様子。 GreengrassV2IoTThingPolicy GreengrassTESCertificatePolicyGreengrassV2TokenExchangeRoleAlias [AWS IoT > ロールエイリアス]が1つ追加される GreengrassV2TokenExchangeRoleAlias 使いたいサービスがあれば、このロールこに追加すればよさそう。 ポリシー：GreengrassV2TokenExchangeRoleAccessが初期権限として付いている。 後片付け 不要なものを削除しておく。 $ rm -rf ~/.aws # AWS CLI $ rm -f ~/.bash_history # コマンド履歴 $ rm -f /tmp/greengrass-nucleus-latest.zip # greengrass一時ファイル $ rm -rf /tmp/GreengrassCore # 同上 セットアップ時に使用したユーザは不要なので停止しておく。 [IAM > ユーザー > ＜該当ユーザ＞]のページの「認証情報」タブを開き、「アクセスキー」のステータスから「無効」を選択。

巷で話題のAWSコンテナ設計・構築本格入門を読んだので自分用にメモ Chapter02 コンテナ設計に必要なAWS基礎知識 次に挙げるような一部の例を除きFargate一択 従来のオンプレミスの経験やナレッジを活用したい デプロイとスケール速度を極限まで早くしたい イメージのキャッシュをEC2に保持できるため ２００GB以上のストレージを使う必要がある KubernetesのDaemonSetを使いたい GPUを使いたい ECSとKubernetesどっちを採用するか問題 Kubernetes 運用フェーズを含めてインフラもしっかり見られる体制がある場合 AWS以外のクラウドやオンプレを視野に入れている場合 ECS それ以外 Chapter03 コンテナを利用したAWSアーキテクチャ Well-Architectedフレームワークの活用 運用上の優秀性 どのようにシステムの状態を把握するか どのように不具合の修正を容易にするか どのようにデプロイのリスクを低減するか モニタリングの主な目的はシステムの可用性を維持するために問題発生に気がつくこと オブザーバビリティ（可観測性）→システム全体を俯瞰しつつ、内部状態まで深掘りできるような状態 ロギング設計 CloudWatch Logsサブスクリプションフィルター ログ内に特定文字列が含まれているログの抽出 CloudWatch Logs Insightsを使いたい FireLens CloudWatch Logs以外のAWSサービスやAWS外のSaaSへのログ転送（もちろんCloudWatch Logsにも転送できる） ログ出力先を複数指定したい場合（コンテナごとにログの出力先は１つしか指定できない） 大量のログが出力される場合（料金面） メトリクス設計 CloudWatchメトリクス ECSサービス単位（ECSタスクではない） CPUUtilization MemoryUtilization CloudWatch Container Insights ECSタスク単位 CPUとメモリの他にネットワーク、ストレージ、ECSタスク、ECSサービスのメトリクスが取得できる ダッシュボードが用意される 別途料金がかかるので注意 ☆クラウドを利用することで、安定稼働やハードウェアの追加調達の判断ではなく、リソース効率性やコンピューティングリソースの妥当性、オートスケールの発動条件にモニタリングの用途を変えることができる。そのためサーバに関する監視設計への関心よりも、サービス側に対して関心を寄せることができる トレース設計 X-Ray アプリケーションの内部処理の呼び出しやサービス間のトランザクション情報 サービスマップのダッシュボードでシステム全体の可視化 ECSタスク定義の中にアプリケーションコンテナとX-Rayコンテナを同梱＋アプリケーションにX-RayのSDKでコーディングすることで使える IAM権限(AWSXRayDaemonWriteAccess)が必要(タスク実行ロールではなく、ECSタスクロールへの権限付与) エンドポイントがAWSパブリックネットワークに存在するので、VPC EndpointやNATゲートウェイなど考慮が必要 CI/CD設計 常にテストして自動でプロダクション環境にリリース可能な状態としておくことでアジリティを高める ソフトウェア開発サイクルを自動化・高速化するために用いられる手法 変更を自動でリリースできるようになり開発に集中できる 迅速に不具合を発見でき品質改善の効率化が図れる コンテナのポータビリティ、再現性、軽量さと相性がいい 構成について 環境ごとにアカウントを用意 CodeCommitは環境間で共有リソースにする（資産管理、運用の複雑性を回避） CodeBuildは環境ごとに配置（環境ごとに動作が違う。本番はステージングでテスト・ビルドしたイメージをそのまま使う） CodeDeployも環境ごとに配置（アカウントを跨いだ設計が発生して複雑になってしまう） ECRは開発とステージング兼本番の２つを共有リソースに保持（開発は開発者が手動でイメージの操作をできるように、本番はできないようにすることで開発者の自由度が高まる） 全てのECRを共有リソース用アカウントに集約することで情報源を一元化できる CI/CD及びコンテナのAWSリソース定義が各環境のアカウント間で同一になる アプリケーション開発が本格化する前にCI/CDパイプラインを用意する イメージのメンテナンス運用 ライフサイクルポリシーを使って一定期間の身、もしくは指定した世代分のみ保持（コスト） 複数環境で使う場合はライフサイクルポリシーによって意図せず消されてしまう可能性がある 環境ごとに固有のタグ識別文字をつけて、タグごとのライフサイクルポリシーを指定する この時コードリポジトリのコミットIDも付与するとECSで展開されているコンテナがどのソースコードバージョンで稼働しているのかが明確になる ガバナンス・コンプライアンスの考慮 ECS: IAMポリシーによる書き込み・実行制御 ECR: リポジトリポリシーによるアクセス制御 S3: バケットポリシーによるアクセス制御 CodePipeline上に承認アクションを設定 Bastion設計 セッションマネージャーを活用することでアタックサーフェスを減らせるし、OSに関する責任をAWS側に移譲できる セキュリティ コンテナ開発のセキュリティベストプラクティス NIST SP８００-１９０ ※ECS/Fargate利用時に考慮が必要な項目は☆ イメージ ☆イメージの脆弱性 →ECRによる脆弱性スキャン 有効化するだけで追加コストなしにプッシュ時にスキャンしてくれる →Trivyによる脆弱性スキャン ベースイメージに含まれるOSパッケージだけでなく、アプリケーションの依存関係(pip, gem, npmなど)もスキャンできる 実行方法がシンプルでCI/CDパイプラインに組み込みやすい 継続的なスキャン イメージは時間が経てば内部コンポーネントのバージョンが古くなり脆弱性が発見される恐れがある 頻繁にデプロイされない（スキャンされない）プロダクトについては、CloudWatch Eventsから定期的にLambdaを実行してECRの手動スキャン実行などが必要 ☆イメージ設定の不具合 Dockle コンテナベストプラクティスチェックツール The Center for Internet Security(CIS)やDocker社でベストプラクティスが公開されているが、こちらのチェックを実行できる 簡単に実行が可能なのでこちらもCI/CDプロセスに導入し継続的なイメージ設定のチェックを行う ☆埋め込まれたマルウェア 提供元が不明なベースイメージの利用は避ける GuardDutyを使って外部との不正な通信をチェックする VPCフローログ、CLoudTrailイベントログ、DNSログなどから悪意のある通信を検知してくれる ☆埋め込まれた平文の秘密情報 Secrets ManagerやSSMパラメータストアのARNと環境変数名をタスク定義内でマッピング コンテナ内でOSの環境変数として認識される ☆信頼できないイメージの使用 イメージとレジストリを一元管理 検証が不十分な外部コンテナイメージを利用しない 自分達がビルドし十分にテストされたイメージを利用する ECRは対応していないが、Docker HubであればDocker Content Trust(DCT)を使ってイメージの整合性と公開社情報を検証できる レジストリ レジストリへのセキュアでない接続 ☆レジストリ内の古いイメージ 使用しない古いイメージは脆弱性が含まれていつ可能性があるので適切に削除する ECRではイメージタグの上書きを禁止するIMMUTABLE設定を行う イメージを上書きすることができるが、タグが上書きされると既に存在しているイメージのタグも外れてしまう コンテナイメージの一貫性を維持、不正なイメージの混入を防ぐためこの設定を有効化 ☆不十分な認証・認可制限 ECRはプライベートリポジトリとして作成 パブリックリポジトリを作成できないよう(ecr-public:*をDeny)、IAMポリシーを作成しSCPに適用(予防的ガードレール戦略） リポジトリポリシーを設定 イメージのプッシュ: CICodeBuild(からのみ許可） イメージのプル: IAMユーザ及びECSからのみ許可 オーケストレータ ☆無制限の管理アクセス 最小権限のみを割り当てる 業務フローによってはIAMグループごとにアクセスできるECSクラスターを限定してもいいが、要件次第 権限を縛りすぎると開発アジリティを損ねるので考慮する ☆コンテナ間ネットワークトラフィックの不十分な分離 Fargateが起動するとタスクごとにENIが割り当てられる VPC全体を俯瞰して考える ワークロードの機微性レベルの混合 オーケストレー他のノードの信頼性 コンテナ ランタイムソフトウェア内の脆弱性 ☆コンテナからの無制限ネットワークアクセス パブリックネットワーク→VPC WAFを利用してIP、ポート番号、HTTPヘッダの付与、メソッド限定、SQLインジェクションなどの防御をする CloudFront, ALB, API Gatewayに対応 ECSタスクは通信はALBに紐づくセキュリティグループIDからのみ許可 ECSタスク間 ALB, ECSタスクの各セキュリティーグループ間でそれぞれセキュリティーグループID指定で通信を最小限に限定する VPC→パブリックネットワーク ECSタスクはPrivate Subnetに置く NATゲートウェイを利用する さらに絞りたい時はVPC Endpointを各サービス（S3, ECR, CloudWatch Logsなど）ごとに用意する ただしインターフェース型のVPC Endpointは時間と処理量によって課金されるので注意 セキュアでないコンテナランタイムの設定 ☆アプリケーションの脆弱性 ECSタスク定義でコンテナのルートファイルシステムアクセスを読み取り専用に変更 ☆未承認のコンテナ 稼働するコンテナが適切な承認プロセスを経た状態でデプロイされていることを徹底 ECRのリポジトリポリシーでCI/CD以外のイメージプッシュを拒否 IAMユーザに対してECSタスク定義の更新を拒否 ホスト 大きなアタックサーフェス 共有カーネル ホストOSコンポーネントの脆弱性 不適切なユーザーアクセス権 ホストファイルシステムへの改ざん 信頼性 Well-Architectedフレームワークの設計原則 障害から自動的に復旧する 復旧手順をテストする 水平方向にスケールしてワークロード全体の可用性を高める キャパシティを推測することをやめる オートメーションで変更を管理する マルチAZ構成 FargateでECSを動かすとECSサービス内部のスケジューラがベストエフォートでAZタスクをAZ間でバランスしてくれる 障害時切り離しと復旧 RunningTaskCount（ECSサービスの稼働タスク数）かTaskCount（ECSクラスターの稼働タスク数）とCloudWatchアラームを組み合わせてECSタスク障害を検知する ECSは常にタスク数を設定値に保つのでわざわざアラーム通知しなくてもいい場合がある ECSの場合、リタイアイベントなどでSIGTERMシグナルが送られる場合があり処理の生合成が必要な場合、アプリケーションを適切にハンドリングする必要がある SIGTERMの応答が３０秒ない場合はSIGKILLが発行される システムメンテナンス時におけるサービス停止 ECSタスクが登録されているターゲットグループへの転送ルールとメンテナンス用の固定レスポンスを返却するルールを用意 メンテナンス時にコンソールやLambdaを使用してリスナールールの優先度を変更 パフォーマンス効率 ビジネスで求められるシステムへの需要を満たしつつ、技術領域の進歩や環境の変化に対応可能なアーキテクチャを目指すこと パフォーマンス設計の目的はビジネスで求められるシステムへの需要を満たすことなため、ビジネス上の要件が前提 とはいえクラウドでリソースを容易にスケールできるため厳密な見積は不要 既存のワークロードを模倣したベンチマークや負荷テストでパフォーマンス要件を満たすかどうかの確認は必要 流れ ビジネス上のパフォーマンス要件の確認 最低要件を確認 リソースの割り当て ある程度余裕を考えながらリソースの割り当て スケール戦略の検討 スケールアウトかスケールアップか アプリケーションの特性に依存するが一般的にはスケールアウト構成 リソース上限に到達しにくい タスクの停止が不要 スケール判断の自動化がやりやすい 可用性と耐障害性が向上する リージョンあたりの起動可能なFargateのECSタスク数は１０００なので注意 またECSタスクごとにENIが割り当てられるのでIPアドレスの枯渇に注意 ステップスケーリングポリシー メトリクスの値に応じてステップを刻みスケーリング ターゲット追跡スケーリングポリシー (おすすめ) メトリクスの値を維持するようにスケーリング 注意事項 メトリクスがターゲット値を超えている場合のみスケールアウトできる スケールインはスケールアウトに比べて緩やかに実行される 複数のメトリクスのターゲット値を定義できる スケールアウトはいずれかのターゲット値が超過すれば行われる スケールインは全てのターゲット値が下回らなければ行われない テストの実施 負荷試験前に事前に少量のリクエストを実行して以下の確認もしておく 期待する一連のメトリクスが取得できているか アプリケーションからエラーが出力されていないか ログに欠損はないか、ログレベルは妥当か メトリクスの確認 パフォーマンス要件で定義したリクエスト量が満たせているか リソースの余剰や逼迫が発生していないか スケールイン・スケールアウトは正しく発動するか スケールアウト、スケールイン時にアプリケーションからエラーが出力されていないか リソース割り当てやスケール戦略の見直し リソース割り当てやスケールの閾値を見直す Well-Architectedフレームワークにの書いてあるがより頻繁に実験し試行錯誤しながら最適な比較検証を行うべき マインドセットについて 運用コストとのバランス 最適なリソースを判断するために必要なメトリクスを収集し、適切なサイジングを行う コスト最適化 コストの利用状況を把握し無駄を削減 クラウド利用の方が高くつく可能性もある ECSタスク数とリソースのサイジング アプリケーションの稼働に必要十分なリソース量を定めることがコスト最適化の基本 Compute Savings Plans (Fargate) 1年または３年の期間で指定リソースの利用事前コミットによる割引 ECRコンテナイメージ イメージを適切に削除することはコスト削減に加え運用管理やセキュリティにおいても有効 ライフサイクルポリシーの設定で実現可能 開発・ステージング環境のECSタスク稼働時間 夜間不要なことが多いのでCloudWatch EventsからLambdaを発火させECSサービスのタスク数を更新 開発環境は可用性を犠牲にして最小限のタスク数にする Fargate Spot 停止をある程度許容する代わりに約７割引で使える 使用する場合はECSサービスにキャパシティプロバイダ戦略の設定が必須 FARGATEとFARGATE_SPOTそれぞれのベース起動数とウェイト起動数を指定してオンデマンドとスポットの起動割合を指定する タスクが終了するまで２分間の猶予がある CloudWatch EventsにECSタスクの状態変更がイベント通知される 実行中のタスクに対してSIGTERMシグナルも送信される コンテナイメージサイズの削減 Fargateはイメージをキャッシュしないため、タスクが増えるたびに転送量がかかる コンテナ構成を最小限にすることでコストメリットがある またダウンロード時間が短くなり起動が速くなる 不要なライブラリなどを取り除くことで堅牢になる Chapter04 コンテナを構築する ネットワーク設計 用途(ingress, application, db, management)、NW区分(public/private)、AZ(1a, 1c)、CIDR、サブネット名（sbctr-subnet-NW区分-用途-AZ） サブネットのネットワーク部分は間隔をあけておく これらを表にまとめておく 単一のAZしか使わない想定でもAZ障害に備えてAZを２つ確保しておく ルーティングテーブルは共通のものを一つ作成 通信の特性を示すネーミング ECRは手動で作成 Cloud9からECRにアクセスするためには別途IAMポリシーの割り当てが必要 エンドポイント com.amazonaws.(region).ecr.api: ECR API読み出しに利用 (インターフェース型エンドポイント) com.amazonaws.(region).ecr.dkr: dockerクライアントコマンドの呼び出しに利用（インターフェース型エンドポイント） com.amazonaws.(region).s3: dockerイメージ取得に利用 (ゲートウェイ型VPCエンドポイント) Fargateの仕組み タスクは複数のコンテナからなる タスクはマイクロVM上で稼働する マイクロVMはFirecrackerと呼ばれるシステムで稼働する ECSサービス設定のロードバランサーの設定で、本番用リスナーとテスト用リスナーの二つ紐づけられるので、リスナーを二つ作っておく ECSサービス設定でBlue/Greenデプロイメントの設定を行うが、デフォルトではアプリケーションリリース後即座に切り替わる設定となっている 変更するためにはCodeDeployのDeployment settings内のTraffic reroutingの設定を行う Fargate1.4.0以降はSecrets ManagetおよびSystems Managerにアクセスするためにはインターフェース型VPCエンドポイントが必要（以前はFargate ENIというAWS管理のENIが利用されていて通信が利用者で管理できなかった） サブネットはサービスごとに分ける ALB ECS(Front, Backend), FrontBackend間のALBも Cloud9 Aurora VPC Endpoint CodeBuildでdocker hubからイメージをプルすると、IPガチャの結果によってはTo many Requestで失敗する可能性がある 対処法は次の３つ CodeBuildでdocker loginする ECRにあらかじめベースイメージを登録する VPC内でCodeBuildを起動する CodePipelineのappspec.yml内のTaskDefinitionの値はと指定すれば自動的に置き換えられる CodePipelineのtaskdef.jsonのContainerDefinitionのimageの値はと指定すれば自動的に置き換えられる 攻撃の防御はなるべく攻撃者の近くでブロックした方がいいため、WAFはCloudFrontで行うことが推奨される AWS WAF ルール リクエストの検査方法の定義 特定のIPアドレスだけ許可 特定のヘッダのみ許可など ルールグループ ルールの集約 ルールの優先順位を設定できる ルールにはWCU (WAF Capacity Unit)が定められており、合計が上限値を超えないようにしないといけない なおWCUはルールグループ作成時のみ設定が可能 ウェブACL ルールグループと適用するAWSリソースを紐づける 複数のルールグループを紐付け可能 ただしWCU上限は１５００ ルールグループとウェブACLはそれぞれGlobalか各Regionを指定する必要があり、ウェブACLに設定するルールグループはそれぞれ同一である必要がある またCloudFrontの場合はGlobal、ALBの場合はRegionである必要がある ECRの単一リポジトリにタグ違いで複数のシステムのイメージを格納するのもあり firelensの設定方法 (カスタムしたfluentbitを使う場合) 1. オリジナルのfluentbitをECRにプッシュしておく 2. タスク定義で「FireLens の統合を有効にする」にチェックを入れ、タイプとイメージを指定する 3. log_routerというコンテナ定義が追加されるのでCPUなどを設定 ４。 firelensに流したいログを出力するコンテナのログ設定をawsfirelensに変更 5. fluentbitのカスタム設定ファイルをタスク定義にJSONで指定 (firelensConfiguration) bastionサーバをFargateで構築するときのポイント ssmエージェントを実行するイメージを作成（create-activationが必要） タスクロールとしてSystems Managerへ権限を渡すためのiam:PassRoleとアクティベーション用の権限が必要 Systems Managerに渡すIAMロールとしてAmazonSSMManagedInstanceCore管理ポリシーがアタッチされたIAMロールが必要 ssmmessagesとssmのVPCエンドポイントが必要 Systems Managerのインスタンスティアをアドバンスドインスタンスティアに設定変更する必要がある

1. はじめに 最近はインフラ構築もコードで行われるようになりました。 その一例がAWSの提供するリソースプロビジョニングサービス「CloudFormation(以下、CFnと表す)」です。 今回はCFnを使用して、一般的な2階層Webサーバを構築しようと思います。 また、CFnに関する記事では、マネコン上でビルドする記事が多いですが、CFnの本質はIaC、つまりはコードでのインフラ構築ですので、本記事ではテンプレートのビルドはIDE上(Cloud9)でAWS CLIを使用して行うものとします。 記事は以下3編に分けて公開します。 ①【AWS】CloudFormationでWebサーバを構築①（NW編）←本記事 ②【AWS】CloudFormationでWebサーバを構築②（EC2編） ③【AWS】CloudFormationでWebサーバを構築③（ビルド編） 2. 概要 本記事の概要を以下に記載します。 2.1 本記事の目的 CFnを利用し、IDE上(Cloud9)からWebサーバ環境を構築する。 2.2 本記事の流れ ① NW環境、及びセキュリティテンプレートの作成 ② サーバテンプレートの作成 ③ AWS CLIでビルド ④ 動作確認(Apacheページの閲覧) 2.3 機能要件 ・テンプレートの形式は『yaml』を採用する ・テンプレートファイルは各ロール毎に分割し、クロススタック方式を採用する ・作成するテンプレートを以下の通りとする 　・「network.yaml」←本記事で作成する部分 　・「security.yaml」←本記事で作成する部分 　・「server.yaml」 ・リソース作成からビルドまでを全てコマンドライン上で行う ・IDEはCloud9を使用する ※皆さんはVSCode等のお好きなIDEを使用して下さい ・完了要件は「テストページ」の閲覧とする 2.4 構成図 ※準備中です。。 3. 事前準備 事前準備として、以下の用意をお願いします。 ・IDE（本記事ではCloud9を使用します） ・AWS CLIが使用可能であること また、テンプレートファイルの保管、及びビルド用のディレクトリ(以下、「作業用ディレクトリ」を表す)を任意の場所に作成してください。 ディレクトリの作成コマンドは以下の通りとなります。 作業ディレクトリの作成 $ mkdir cfn-dev-dir $ cd cfn-dev-dir 以降、作成するテンプレートは全てこの作業用ディレクトリの直下に保存して下さい。 4. NW編の概要 今回の『【AWS】CloudFormationでWebサーバを構築①（NW編）』では、Web環境周りのNW部分のテンプレートを作成します。 具体的なサービスとしては以下の通りとなります。 ・VPC ・IGW ・Subnet ・RouteTable ・SecurityGroup 4.1 NW編構成図 NW編で作成するテンプレート環境の構成図を下図の通りとします。 5. NWテンプレートの作成 早速ですが、以下がNW部分のテンプレートになります。 命名規則等、必要であればご自身の環境に合わせて修正してください。 修正が完了したら、作業用ディレクトリに「network.yml」というファイル名で保存してください。 network.yml AWSTemplateFormatVersion: "2010-09-09" Description: chibiharu's Qiita [【AWS】CloudFormationでWebサーバを構築①（NW編）] - NetworkTemplate # ------------------------------------------------------------ # Input Parameters # ------------------------------------------------------------ Parameters: VPCCIDR: Type: String Default: "192.168.0.0/20" PublicSubnetCIDR: Type: String Default: "192.168.1.0/24" PrivateSubnetCIDR: Type: String Default: "192.168.3.0/24" ### Resources ### Resources: # ------------------------------------------------------------ # VPC # ------------------------------------------------------------ chibiVPC: Type: "AWS::EC2::VPC" Properties: CidrBlock: !Ref VPCCIDR EnableDnsSupport: "true" EnableDnsHostnames: "true" InstanceTenancy: default Tags: - Key: Name Value: "chibi-cfn-vpc" # ------------------------------------------------------------ # InternetGateway: # ------------------------------------------------------------ chibiIGW: Type: "AWS::EC2::InternetGateway" Properties: Tags: - Key: Name Value: "chibi-cfn-igw" chibiIGWAttachment: Type: "AWS::EC2::VPCGatewayAttachment" Properties: InternetGatewayId: !Ref chibiIGW VpcId: !Ref chibiVPC # ------------------------------------------------------------ # Subnet # ------------------------------------------------------------ chibiPublicSubnetA: Type: "AWS::EC2::Subnet" Properties: AvailabilityZone: "ap-northeast-1a" CidrBlock: !Ref PublicSubnetCIDR VpcId: !Ref chibiVPC Tags: - Key: Name Value: "chibi-cfn-public-subnet-a" chibiPrivateSubnetA: Type: "AWS::EC2::Subnet" Properties: AvailabilityZone: "ap-northeast-1a" CidrBlock: !Ref PrivateSubnetCIDR VpcId: !Ref chibiVPC Tags: - Key: Name Value: "chibi-cfn-private-subnet-a" # ------------------------------------------------------------ # RouteTable # ------------------------------------------------------------ chibiPublicRTB: Type: "AWS::EC2::RouteTable" Properties: VpcId: !Ref chibiVPC Tags: - Key: Name Value: "chibi-cfn-public-route-a" chibiPublicSubnetRTBAssociation: Type: "AWS::EC2::SubnetRouteTableAssociation" Properties: SubnetId: !Ref chibiPublicSubnetA RouteTableId: !Ref chibiPublicRTB chibiPublicRoute: Type: "AWS::EC2::Route" Properties: RouteTableId: !Ref chibiPublicRTB DestinationCidrBlock: "0.0.0.0/0" GatewayId: !Ref chibiIGW chibiPrivateRTB: Type: "AWS::EC2::RouteTable" Properties: VpcId: !Ref chibiVPC Tags: - Key: Name Value: "chibi-cfn-private-route-a" chibiPrivateSubnetRTBAssociation: Type: "AWS::EC2::SubnetRouteTableAssociation" Properties: SubnetId: !Ref chibiPrivateSubnetA RouteTableId: !Ref chibiPrivateRTB # ------------------------------------------------------------ # Output Parameter # ------------------------------------------------------------ Outputs: ### VPC ### chibiVPC: Value: !Ref chibiVPC Export: Name: "chibi-cfn-vpc" VPCCIDR: Value: !Ref VPCCIDR Export: Name: "chibi-cfn-vpc-cidr" ### Subnet ### chibiPublicSubnetA: Value: !Ref chibiPublicSubnetA Export: Name: "chibi-cfn-public-subnet-a" PublicSubnetCIDR: Value: !Ref PublicSubnetCIDR Export: Name: "chibi-cfn-public-subnet-a-cidr" chibiPrivateSubnetA: Value: !Ref chibiPrivateSubnetA Export: Name: "chibi-cfn-private-subnet-a" PrivateSubnetCIDR: Value: !Ref PrivateSubnetCIDR Export: Name: "chibi-cfn-private-subnet-a-cidr" ### RouteTable ### chibiPublicRTB: Value: !Ref chibiPublicRTB Export: Name: "chibi-cfn-public-route-a" chibiPrivateRTB: Value: !Ref chibiPrivateRTB Export: Name: "chibi-cfn-private-route-a" 6. セキュリティテンプレートの作成 以下はSecurity部分のテンプレートになります。 こちらも命名規則等、必要であればご自身の環境に合わせて修正してください。 修正が完了したら、作業用ディレクトリに「security.yml」というファイル名で保存してください。 security.yml AWSTemplateFormatVersion: "2010-09-09" Description: chibiharu's Qiita [【AWS】CloudFormationでWebサーバを構築①（NW編）] - SecurityTemplate ### Resources ### Resources: # ------------------------------------------------------------ # SecurityGroup # ------------------------------------------------------------ chibiWebSG: Type: "AWS::EC2::SecurityGroup" Properties: GroupDescription: "http,https public" GroupName: cfn-dev-web-sg VpcId: !ImportValue "chibi-cfn-vpc" SecurityGroupIngress: IpProtocol: tcp FromPort : 80 ToPort : 80 CidrIp: 0.0.0.0/0 IpProtocol: tcp FromPort : 443 ToPort : 443 CidrIp: 0.0.0.0/0 SecurityGroupEgress: IpProtocol: tcp FromPort : 3306 ToPort : 3306 CidrIp: 0.0.0.0/0 chibidbSG: Type: "AWS::EC2::SecurityGroup" Properties: GroupDescription: "db private" GroupName: cfn-dev-db-sg VpcId: !ImportValue "chibi-cfn-vpc" SecurityGroupIngress: IpProtocol: tcp FromPort : 3306 ToPort : 3306 SourceSecurityGroupId: !Ref chibiWebSG # ------------------------------------------------------------ # Output Parameter # ------------------------------------------------------------ Outputs: ### SecurityGroup ### chibiWebSG: Value: !Ref chibiWebSG Export: Name: "chibi-cfn-web-sg" chibidbSG: Value: !Ref chibidbSG Export: Name: "chibi-cfn-db-sg" 7. まとめ 本記事は以上になります。 次回はサーバー部分のテンプレート作成「【AWS】CloudFormationでWebサーバを構築②（EC2編）」になります。 やはりCUIよりGUIの方が直感的に分かりやすく、ミスオペも無く簡単ですが、慣れればCUIのが簡易にインフラ構築が可能になります。 また、コード化することによって、GitHub等のバージョン管理システム上でコード管理を行えるようになり、大規模なインフラ構築における可視性の向上、及び迅速なプロビジョニングが可能になります。 本記事を足がかりに、是非この際にIaCに挑戦して貰えればと思います。

前提条件 OS MacOS Monterey 12.0.1 CPU Apple M1(arm64) AMI(アマゾンマシンイメージ) Amazon Linux 2 AMI (HVM) - Kernel 5.10, SSD Volume Type - ami-02d03ce209db75523 (64 ビット x86) / ami-00ad846222db698f3 (64 ビット Arm) インスタンスタイプ t2.micro ※練習用の低スペックなインスタンスです はじめに 今回はハマった内容を解決した備忘録的に書いているので、内容はエラー箇所とその解決過程にフォーカスし、各リソースの設計手順等はほとんど割愛しています。 ご容赦ください。 アーキテクチャ ・１つのVPCに２つのAZ(１b、１cとします)を配置 ・それぞれのAZにパブリックサブネットを１つずつ設置（１b、１c） ・それぞれのパブリックサブネットにEC2インスタンスをWEBサーバとして起動 　　※ほぼ同じ内容でインスタンスを起動しています 　　※サブネット１bに作ったEC2インスタンスをAMIとしてイメージ保存し、そこからもう１台を立ち上げるとスムーズです。 ・起動したインスタンス計２台にELBを紐づける ※EC2インスタンスにアパッチサーバをインストールし、WEBサーバとして起動する手順を記しています。ご参考までに。 ↓ やりたいこと ELBで２台のWEBサーバ（EC2インスタンス）に負荷分散する （ELBのDNSにアクセスした際、２台のWEBサーバの内容が均等に表示されることを確認する） つまづいた話 ELBのDNSにアクセスすると、「HTTP 504: Gateway Timeout」のエラーが発生する 切り分け ・各EC2インスタンスのグローバルIPには正常にアクセスできる 　　　→インスタンスの異常ではない ※どちらのインスタンスにアクセスできているかがすぐ分かるよう、それぞれに置くhtmlファイルの内容はAZ名で書き分けています。 ・サブネットのネットワークACLはデフォのまま、IN,OUT共に全トラフィックを許可することになっている ・ELBのターゲットグループやELB自体は正常に動作している 原因 EC2に設定したセキュリティグループのインバウンドルールで、ELBからのトラフィックを許可していなかった。 ELBは配下のEC2に負荷分散を行うに当たってEC2にリクエストを送りますが、そのトラフィックがインスタンスに届かなかったことが原因でした。 解決策 セキュリティグループの見直し 修正前）EC２、ELBとも同じセキュリティグループを設定 ↓ 修正後） ①ELBのセキュリティグループを設定 　　IN)クライアントからのトラフィックを許可 　　OUT)全て許可 ②各EC2のセキュリティグループのインバウンドで、①のセキュリティグループを許可 セキュリティグループは、許可するソースとして別のセキュリティグループも設定できる という点がポイントだったんですね。 ここがネットワークACLと異なる点であり、見落としがちな点なんだとか。 ※自分も勉強したばかりの内容でしたが、気づくまでずいぶん時間がかかりました。。。 手順 1　ELBにセキュリティグループを設定 分かりやすいよう、「ELB-SG」という名前にしました。 ※セキュアな状態となるよう、インバウンドはクライアントPC（自分）からのアクセスのみ許可するようソースを設定しました。 （セキュリティグループ編集の「ソース」から「カスタム」→「マイIP」で設定可能） ※アウトバウンドはデフォのまま、全て許可としています。 2　EC２にセキュリティグループを設定 「Webserver-SG」という名前にしました。 ※ELBからのトラフィックが届くようにします。 ※上記１で設定したELBのセキュリティグループを、インバウンドで許可するソースとして設定します。 ※タイプ「HTTP」　ソース「カスタム」とすると、選択肢から他のセキュリティグループを指定できます。 3　ELBのDNSをブラウザURL欄に貼り付け、アクセスしてみる 無事にページが表示されました。 繰り返しアクセスすると、アクセスのたびに各インスタンスにトラフィックが分散されていることがわかります。 （各インスタンスに置いた別々のhtmlファイルの内容が、交互に表示されているため。） 正常に動作しているようです。 参考サイト ↓Udemy ↓公式ドキュメント

はじめ Lambdaで、当日の日付を20220116の形にし、5日後の日付20220121を引くと、5という数字が出せるようにすることを目的として、Lambdaを作成したため、まとめます。 Lambdaコードの流れ 当日の日付 2022-01-16 11:41:21.282791（タイムゾーンはUTC） ↓UTCをJSTに変換する 2022-01-16 11:41:21.282791（タイムゾーンはUTC） ↓タイムスタンプに変更 1642765665851 ↓年、月、日のみに変換。（時間、分、秒は、切り捨て） 20210116 5日後の日付 2022-01-16 11:41:21.282791（タイムゾーンはUTC） ↓日付を5日進める 2022-01-21 11:41:21.282791（タイムゾーンはUTC） ↓UTCをJSTに変換する 2022-01-21 11:41:21.282791（タイムゾーンはUTC） ↓タイムスタンプに変更 1642765665851 ↓年、月、日のみに変換。（時間、分、秒は、切り捨て） 20210121 Lambdaの設定 Node.jsとPythonそれぞれ作成します。 Node.js Node.js exports.handler = async (event) => { // UTCの日付 "2022-01-16T11:31:09.498Z" const dateUTC = new Date(); const fivedateUTC = new Date().setDate(dateUTC.getDate() + 5); // JSTに変更後、タイムスタンプに変える const dateJST = new Date(dateUTC.getTime() + 32400000); // 5日進める const FivedateJST = new Date(fivedateUTC + 32400000); // タイムスタンプを日付の年月日に変える。時間は切り捨て let year = dateJST.getFullYear(); let month = dateJST.getMonth()+1; let day = dateJST.getDate(); let FiveLateryear = FivedateJST.getFullYear(); let FiveLatermonth = FivedateJST.getMonth()+1; let FiveLaterday = FivedateJST.getDate(); // 値が1桁であれば '0'を追加 if (month < 10) month = '0' + month; if (day < 10) day = '0' + day; if (FiveLatermonth < 10) FiveLatermonth = '0' + FiveLatermonth; if (FiveLaterday < 10) FiveLaterday = '0' + FiveLaterday; //"20220116" const dateTimeString = year + month + day; //"20220121" const FiveDaysLaterTimeString = FiveLateryear + FiveLatermonth + FiveLaterday; //20220116 const today = Number(dateTimeString); //20220121 const FiveDaysLater = Number(FiveDaysLaterTimeString); return FiveDaysLater - today; }; Python Python from datetime import datetime, timedelta def lambda_handler(event, context): # 2022-01-16 20:54:05.134159 dateJST = datetime.today() + timedelta(hours=9) dateJSTFiveDaysLater = dateJST + timedelta(days=5) #現在の日本の日付 20220116 today = int(dateJST.strftime("%Y%m%d")) # 5日後 20220121 fiveDaysLater = int(dateJSTFiveDaysLater.strftime("%Y%m%d")) return fiveDaysLater - today Pythonの方がすでにLambdaでインストール済みのライブラリが豊富なため、コードが少なくていいですね。 どちらも20220121 - 20220116 = 5という結果になりました。 参考 Node.js Python

はじめ Lambdaで、当日の日付を20220116の形にし、5日後の日付20220121を引くと、5という数字が出せるようにすることを目的として、Lambdaを作成したため、まとめます。 Lambdaコードの流れ 当日の日付 2022-01-16 11:41:21.282791（タイムゾーンはUTC） ↓UTCをJSTに変換する 2022-01-16 11:41:21.282791（タイムゾーンはUTC） ↓タイムスタンプに変更 1642765665851 ↓年、月、日のみに変換。（時間、分、秒は、切り捨て） 20210116 5日後の日付 2022-01-16 11:41:21.282791（タイムゾーンはUTC） ↓日付を5日進める 2022-01-21 11:41:21.282791（タイムゾーンはUTC） ↓UTCをJSTに変換する 2022-01-21 11:41:21.282791（タイムゾーンはUTC） ↓タイムスタンプに変更 1642765665851 ↓年、月、日のみに変換。（時間、分、秒は、切り捨て） 20210121 Lambdaの設定 Node.jsとPythonそれぞれ作成します。 Node.js Node.js exports.handler = async (event) => { // UTCの日付 "2022-01-16T11:31:09.498Z" const dateUTC = new Date(); const fivedateUTC = new Date().setDate(dateUTC.getDate() + 5); // JSTに変更後、タイムスタンプに変える const dateJST = new Date(dateUTC.getTime() + 32400000); // 5日進める const FivedateJST = new Date(fivedateUTC + 32400000); // タイムスタンプを日付の年月日に変える。時間は切り捨て let year = dateJST.getFullYear(); let month = dateJST.getMonth()+1; let day = dateJST.getDate(); let FiveLateryear = FivedateJST.getFullYear(); let FiveLatermonth = FivedateJST.getMonth()+1; let FiveLaterday = FivedateJST.getDate(); // 値が1桁であれば '0'を追加 if (month < 10) month = '0' + month; if (day < 10) day = '0' + day; if (FiveLatermonth < 10) FiveLatermonth = '0' + FiveLatermonth; if (FiveLaterday < 10) FiveLaterday = '0' + FiveLaterday; //"20220116" const dateTimeString = year + month + day; //"20220121" const FiveDaysLaterTimeString = FiveLateryear + FiveLatermonth + FiveLaterday; //20220116 const today = Number(dateTimeString); //20220121 const FiveDaysLater = Number(FiveDaysLaterTimeString); return FiveDaysLater - today; }; Python Python from datetime import datetime, timedelta def lambda_handler(event, context): # 2022-01-16 20:54:05.134159 dateJST = datetime.today() + timedelta(hours=9) dateJSTFiveDaysLater = dateJST + timedelta(days=5) #現在の日本の日付 20220116 today = int(dateJST.strftime("%Y%m%d")) # 5日後 20220121 fiveDaysLater = int(dateJSTFiveDaysLater.strftime("%Y%m%d")) return fiveDaysLater - today Pythonの方がすでにLambdaでインストール済みのライブラリが豊富なため、コードが少なくていいですね。 どちらも20220121 - 20220116 = 5という結果になりました。 参考 Node.js Python

はじめに AWS LambdaからBigQueryに接続し、その結果を使って後続の処理を行いたい場合、Lambda上にGCPのサービスアカウントの認証キーを配置することで可能になりますが、認証キーの発行やLambda上への配置はできればしたくありません。 そういった時に便利なのが、GCPのWorkload Identityです。 この方法では、GCPのサービスアカウントとAWS等のロールを紐付け、サービスアカウントの権限を借用して認証することができます。 今回はこの方法でLambdaからBigQueryに接続する方法を確認して行きます。 実行準備 以下は作成済みである前提で進めて行きます。 GCP側 プロジェクト BigQueryにについて操作可能なGCPのサービスアカウント BigQueryのテーブル AWS側 Lambda関数 Lambda関数の実行ロール また、GCPのリソースについてCLIで操作を行なっていくので、gcloudが実行できる状態にしておいてください。 $ gcloud version Google Cloud SDK 367.0.0 bq 2.0.72 core 2021.12.10 gsutil 5.5 BigQueryテーブル テーブルについては以下の通り、usersというテーブル名でuser_id、nameというカラムを持つシンプルなテーブルを用意しました。 Lambda関数 Lambda関数は以下のように作成し、デプロイしておきます。 usersのテーブルにクエリを投げて結果を取得するシンプルなものになっています。 import os from google.cloud import bigquery def lambda_handler(event, context): client = bigquery.Client(project="<プロジェクト名>") query = """ SELECT user_id, name FROM `<プロジェクトID>.<dataset名>.users` """ query_job = client.query(query) print("The query data:") for row in query_job: print("user_id={}, name={}".format(row["user_id"], row["name"])) return event ※ <プロジェクトID>、<dataset名>は適宜書き換えてください ※ from google.cloud import bigqueryするためにgoogle-cloud-bigqueryをパッケージに含めてbuildする必要があることに注意してください やってみる 今回は、以下の手順で進めて行きます。 Workload Identity構築・アカウント紐付け Lambda側で認証情報ファイルを配置・実行確認 Workload Identity構築・アカウント紐付け 早速、構築して行きます。 ※ コード中の<hoge>は適宜書き換えてください 1.GCP で以下 API が有効になっていることを確認します。 Identity and Access Management (IAM) API Cloud Resource Manager API IAM Service Account Credentials API Security Token Service API 2.事前に作成しておいたlambda関数に紐付けた実行ロール名を確認しておきます 3.Workload Identityプールを作成する プール名は新規でセット $ gcloud iam workload-identity-pools create "<Workload Identity プール名>" --location="global" 4.Workload IdentityプールにAWSアカウントIDをプロバイダとして追加する プロパイダー名は新規でセット $ gcloud iam workload-identity-pools providers create-aws "<プロバイダー名>" --location="global" --workload-identity-pool="<Workload Identity プール名>" --account-id="<AWSアカウントID>" 5.権限を借用するGCPサービスアカウントに、Lambda関数のロールを紐付け まず、さきほど作成したプールのnameを確認しておきます。 $ gcloud iam workload-identity-pools list --location="global" --- name: <POOL_NAME> state: ACTIVE Updates are available for some Cloud SDK components. To install them, please run: $ gcloud components update 確認した<POOL_NAME>とAWS Lambdaのロール名を使用して、両者を紐づけていきます。 $ gcloud iam service-accounts add-iam-policy-binding "<プロジェクト名>@<サービスアカウント名>.iam.gserviceaccount.com" \ --role="roles/iam.workloadIdentityUser" \ --member="principalSet://iam.googleapis.com/<POOL_NAME>/attribute.aws_role/arn:aws:sts::<AWSアカウントID>:assumed-role/<Lambdaのロール名>" 6.サービスアカウントの認証情報ファイルをダウンロードする ここまでで紐付けが完了したので、認証情報ファイルをダウンロードします。 $ gcloud iam workload-identity-pools create-cred-config \ "<POOL_NAME>/providers/<プロバイダー名>" \ --service-account="<プロジェクト名>@<サービスアカウント名>.iam.gserviceaccount.com" \ --output-file="<path/to/file.json>" \ --aws ダウンロードしたファイルの中身を確認してみると分かりますが、キー情報が含まれていないファイルになっています。 これでこの認証情報ファイルとAWS側のロールを使って、BigQueryにアクセスする準備が整いました！ Lambda側で認証情報ファイルを配置・実行確認 ここまでの手順で作成した認証情報ファイルをLambdaの実行環境に配置し、Lambda関数の環境変数に以下をセットしてください。 GOOGLE_APPLICATION_CREDENTIALS = "<path/to/file.json>" Lambda側の設定はこれだけです。これでWorkload Identityによる連携が完了しました！ それでは実際に実行確認をしてみましょう。 Lambdaをテスト実行すると成功し、BigQueryのデータにアクセスできていることがわかります。 ちなみに、Lambdaにアタッチされているロールを剥がすとアクセスできなくなり、IAMロールでの連携がされていることが確認できます。 最後に Workload IdentityによってAWS側のIAMロールをGCPのサービスアカウントに紐づけてLambda->BigQueryのアクセスを確認できました。 キーレスで認証できるので、認証キーを作成・コピーする必要がなくなるのは嬉しいですね！ 今回はCLIによって順番に操作を行なって行きましたが、次回はTerraformで構築も記事にしていこうかなと思います。 それでは今回はこれにて！

AWSのGPUインスタンスで【vCPU】の上限を解除してもらう為にやった事をメモに残します。 経緯 『つくりながら学ぶ! PyTorchによる発展ディープラーニング』の教材が私のBTOPCのGPU（GeForce GTX1060 super：6GB）では、モデルとデータがGPUメモリ上に乗らなくなり、学習が進まなくなってきました。 新しいGPUの購入を検討しましたが、半導体不足の昨今、GPUメモリが10G以上のNvidiaのGPUに買い替えて、PC本体の電源ユニットの強化まで含めると、15万円以上の出費になってしまいます。 それなら、『AWS：g4dn.xlarge（0.526USD/時間：オレゴン）』の方が安い？と考え、下記のリンク先を参考にトライしてみました AWSによるEC2インスタンスの作成 AWS EC2インスタンスを作成する（AMI:Amazon Linux / Amazon EBSの設定など） トライの結果、オレゴンで2回、北部バージニアで1回、【vCPUの上限依頼】をリジェクトされてしまいました。（この頃、制限解除の条件が厳しくなっている様です） 途方にくれておりましたが、やり取りの中で気付きがあったので、それに従ってトライしたところ、北部バージニアでオンデマンドインスタンスで【vCPUの上限依頼】が通り、無事に『GPUインスタンス：g4dn.xlarge』を作成する事ができました。 気付き AWSサポートとのやり取りの中で、AWSは、以下の3点をチェックしていると感じました ・GPUインスタンス申請者はお試しでは無く、ちゃんと使い続けるつもりなのか？（基本設定はできているか？） ・申請者がちゃんとAWSを管理できるだけのスキルを持っているか？ ・”Amazon SageMaker Studio Lab”ではなく、あえてEC2のGPUインスタンスを申請する理由が妥当か？ 行った事 AWS初心者の私は（こんなこともあろうかと、セールで買っておいた）Udemy講座を参考に設定を見直しました。 【AWS初心者向け】手を動かして身につける！ 実戦で役立つAWSサービスの基礎とアーキテクチャ(SAAレベル) 設定の詳細を書くとUdemy講座に対して失礼に当たるので、詳細は上記の講座や他のページでご確認ください 下記の記事に私が追加して行った事だけを記載します。 AWSによるEC2インスタンスの作成 注）以下は4度目のトライ時に私が行った全てであり、AWSがどの設定を気にして承認してくれたかは、不明です。 １．AWSアカウント（rootユーザ）の追加設定：MFAによるSecurity設定 MFAデバイスを設定してアカウントを安全に保護する（2段階認証です） 仮想MFAデバイスを設定しました ”Google Authenticator”を使用します AWSアカウントは6ケタ数字を2個入力する必要があります。 上の枠に、”Google Authenticator”に表示されている6桁の数字を記載します 下の枠に、1分経過して、切り替わった”Google Authenticator”の6桁の数字を記載します MFAを設定したら、一度サインアウトして、再度サインインします 2．IAMユーザーの新規作成：MFAによるSecurity設定 ”rootユーザー”の使用を避け、安全にAWSを使う為、”IMAユーザー”を作成します 管理用IAMグループを作成 ”ポリシー”を設定した グループに所属する形で”IAMユーザー”を作成 ”AWSへのアクセスの種類”を設定した ”ユーザー追加完了”時のCSVのダウンロードは必ず行っておくこと 一度サインアウトして、上記CSVファイルにサインインリンク先が記載されているので、ブラウザにコピペしてサインインする 情報はCSVファイルからコピペして、”新しいパスワード”を設定する 右上のユーザー名が”IAMユーザー”のアカウント名になっていればOKです ”IAMユーザー”にもMFAを設定する 手順は”AWSアカウント（rootユーザ）”と同じです。 ”IAMユーザー”は6ケタ数字を1個入力でOKです MFAを設定したら、一度サインアウトして、再度”IAMユーザー”でサインインします 3．EC2インスタンスの設定準備：（この項目がどの程度効果があったか？は不明） 予算の設定 ”ルートユーザ”でサインインします "IAMユーザ/ロールによる請求情報へのアクセス"を有効にする サインアウトする ”IAMユーザ”でサインインします AWS Bugetsで”予算の設定”を行う 以下は全て、 ”IAMユーザ”で設定します VPCの作成 Amazon VPCを作成 ”VPC”サービスウィンドウから（1クリックで作成も可能（らしい）） ”VPC”を作成 ”サブネット”を作成（Publicを１つで十分） ”インターネットゲートウェイ”を作成 同時に”VPCへのアタッチ”を実施する ”パブリックサブネット用ルートテーブル”の作成 ”VPC”を設定する ”ルートテーブル”の”ルートの編集”を行う ”サブネットの関連付け”を行う キーペアの作成 EC2ダッシュボードから ”キーペア”を選択して、【キーペアを作成】され、秘密鍵がダウンロードされます ダウンロードされる秘密鍵は再ダウンロードできないので、しっかり保存しておくこと Elastic IPの取得 EC2ダッシュボードから ”Elastic IP”を選択して、【Elastic IPアドレスの割り当て】をクリック タグに”Name”を記載しておくと、あとでわかりやすい 4．EC2インスタンスの設定：失敗すること前提 AMI（Amazonマシンイメージ）の選択 私は、Docker主体で構築するので『Deep Learning Base AMI (Ubuntu 18.04)』を選択 インスタンスタイプの選択 ”g4dn.xlarge”を選択 -インスタンスの詳細の設定 ネットワーク：”VPC”で設定した”VPC”の名前 サブネット：”VPC”で設定したPublicの名前 ストレージの追加 お望みのサイズで タグの設定 ”Name”は記載しておくとあとでわかりやすい その他はお好みで セキュリティグループの設定 下記のリンク先を参照しました AWS EC2インスタンスを作成する（AMI:Amazon Linux / Amazon EBSの設定など） インスタンス作成の確認 "キーペア"は『既存のキーペア』を選び、先程作成したキーペアを選択する 『インスタンスの作成』をクリックする インスタンス作成が開始されるが、 インスタンスの作成に失敗し、 『You have requested more vCPU capacity than your current vCPU limit of 0 allows for the instance bucket that the specified instance type belongs to』と表示される(涙) 5．AWSへの【vCPUの上限】の解除依頼 ”EC2ダッシュボード”→”制限”→【vCPU制限を計算】をクリック 『制限計算ツール』が開くので、必要なインスタンス等を設定し、必要な『vCPU数』を再確認 ”オンデマンド制限の引き上げをリクエスト” ”スポット制限の引き上げをリクエスト” の何れかをクリック ”Create case”が開くので、 リージョン インスタンス名 New limit value : 必要なvCPU数 を記入する Use case description”に記載する情報も大事らしい 以下の内容をDeepL翻訳などで英語にする（私のように英語が不得意な方） 読んでいる最終判断するのは各Regionの担当者の様なので、英語での記載が安全 和文は”主語を抜かない”等の正しく英訳してくれる和文を意識して書く 【和文→英文→和文】にしても和文の意味が崩れない事を確認する 内容 要求する内容（”vCPU上限”を【x個】にしてくれ!!） GPUが必要な理由はなにか？ どの程度使用する予定なのか？ EC2では無いとダメな理由はなにか？ なぜ、オンデマンドインスタンスなのか？ 私は以下の英文を添付しました Dear AWS support staff I've just started using AWS. I need a GPU for deep learning. I'm trying to launch an AWS "g4ad.xlarge" instance because my PC's GPU is not powerful enough. However, at the end of launching the instance, an error message "You have requested more vCPU capacity than your current vCPU limit of 0 allows for the instance bucket that the specified instance type belongs to" is displayed and the instance will not launch. Please adjust the vCPU limit of the "g4ad.xlarge" instance and change it to "4". I plan to use it for about 2 hours on weekdays and about 6 hours on weekends. I am going to use AWS EC2 with ROS (Robot Operating System) and web apps as well, so I need an EC2 GPU instance instead of "Amazon SageMaker Studio Lab". I chose the "On-demand Instance" because I have limited time to work on it. My company also uses AWS EC2 instances, and since this study is related to that work, I chose the same AWS EC2. Please let me know if there are any conditions necessary to remove the restriction. Thank you very much for your help. （改めて見直すと、日本語英語ですね〜。”Please adjust the vCPU limit of the "g4ad.xlarge" instance and change it to "4".”と要求から書き始めても良かったかも。） 6．EC2インスタンスの作成：【vCPUの上限解除】後 無事にAWSから”vCPUの制限解除”の連絡が届いたら、『4．EC2インスタンスの設定準備』を再トライです、 インスタンスが『実行中』になり『ステータス：2/2のチェックに合格しました』と表示されたら成功です Elastic IPの取得 EC2ダッシュボードから ”Elastic IP”を選択して、【アクション】から【Elastic IPの関連付け】を選択 ”インスタンス名”と”プライベートIPアドレス”を選択して、【関連付け】をクリック これで無事にssh接続ができます ＜参照先＞ AWSによるEC2インスタンスの作成 AWS EC2インスタンスを作成する（AMI:Amazon Linux / Amazon EBSの設定など） 【AWS初心者向け】手を動かして身につける！ 実戦で役立つAWSサービスの基礎とアーキテクチャ(SAAレベル) 0版：2022年1月16日

目的 Dockerの理解を深めたいと考え、Docker-Composeを用いてWordpressの構築を行いました。 条件設定 ・AmazonLinux2のイメージを用いて構築する ・WEB用とDB用のコンテナそれそれ2台を用いる ・データの永続化 　ログ記事を書いた後に、コンテナの再起動をしても書いたブログ記事がちゃんと 　残ってるかどうか 環境設定 ・docker ver3.8 ・php ver7.3 ・Apache ・MySQL ・mariadb 構成 /opt/project 　 l 　L docker-compose.yml 　 l---web 　 l 　 l-Dockerfile 　 l---db 　　　l-Dockerfile 　　　l-wordpress 　　　　　　l-db.opt 手順 1.ルート権限になる # sudo su - 2.Dockerのインストール # yum install docker 3.dockerの起動 # systemctl start docker 4.dockerのプロセスが通っているかの確認 # ps -ef | grep docker 5.dockerのシステム起動の確認 # systemctl status docker 6.作業ディレクトリの作成・移動 # mkdir /opt/project && cd /opt/project 7.web/dbのディレクトリを作成 # mkdir web # mkdir db 8.ymlファイルを作成 # vi docker-compose.yml docker-compose.yml ----------------------------------------- version: "3.8" services: #./webに作成したwordpressのDockerfileを使用して"docker-compose build"でwebという名前のイメージを作成 web: container_name: web build: ./web #ポート番号の指定 ports: - "80:80" tty: true #./dbに作成したMySQLのDockerfileを使用して"docker-compose build"でdbという名前のイメージを作成 db: container_name: db build: ./db #ポート番号の指定 ports: - "3306:3306" tty: true ----------------------------------------- 9.wordpressのDockerfileを作成 # cd /opt/project/web && vi Dockerfile /opt/project/web ----------------------------------------- #AmazonLinux2の環境を使用 FROM amazonlinux:2 #初期装備をインストール RUN yum -y install yum-utils tar wget procps epel-release RUN yum clean all #Apacheインストール RUN yum -y install httpd #PHPのインストール RUN amazon-linux-extras enable php7.3 RUN yum install -y php php-gd php-mysqlnd php-xmlrpc #wordpressインストール #ENV wpdl https://wordpress.org/latest-ja.tar.gz # wp download #RUN cd /var/www/html && wget -O - $wpdl | tar xzfv - #RUN mv /var/www/html/wordpress/* /var/www/html RUN wget https://wordpress.org/latest.tar.gz RUN tar -xzvf latest.tar.gz RUN mv /wordpress/* /var/www/html RUN chown -R apache:apache /var/www/html RUN chmod 2775 /var/www/html CMD [ "/usr/sbin/httpd", "-D", "FOREGROUND" ] ----------------------------------------- 10.データベースのDockerfileを作成 # cd /opt/project/db && vi Dockerfile /opt/project/db ----------------------------------------- FROM amazonlinux:2 #初期装備をインストール RUN yum install -y yum-utils tar wget procps epel-release #インストール RUN yum -y install mariadb mariadb-server #pingコマンド使用 RUN yum install -y iputils #port確認 EXPOSE 3306 # DB作成 RUN mkdir /var/lib/mysql/wordpress/ COPY ./wordpress /var/lib/mysql/wordpress/ RUN chown -R mysql:mysql /var/lib/mysql/wordpress #mariadbの起動 CMD ["/usr/bin/mysqld_safe" ,"--skip-grant-tables"] ----------------------------------------- 11.dbのイメージを作成する際に必要なファイルを作成 # mkdir /opt/project/db/wordpress && vi /opt/project/db/wordpress/db.opt /opt/project/db/wordpress/db.opt ----------------------------------------- default-character-set=latin1 default-collation=latin1_swedish_ci ----------------------------------------- 12.docker-composeでイメージをビルド # cd /opt/prject # docker-compose build 13.作成したイメージの確認 #docker images 14.docker-composeでコンテナを作成 # docker-compose up -d 15.作成したコンテナの確認 # docker ps # docker-compose ps 16.WEBでログインしてwordpressをインストール http://グローバルIP ～データベースの選択画面～ データベース名： wordpress ユーザ名：　　空白　　 パスワード： 　　空白　　 データベースのホスト名：db ※データベースのコンテナ名 テーブルの接頭辞：wp_　　　　（そのまま） でインストール！！ 次の課題の確認のため、何か一つ思いのたけを投稿しておく。。。 参考 滅びの呪文 初心者はdocker-composeから始めた方がいいかもしれない説 Docker Compose を使う データの永続化 1.dockerボリュームを作成 # docker volume create mariadb 2.docker-compose.ymlにvolumesを追加 # cd /var/project/ && vi docker-compose.yml docker-compose.yml --------------------------------------------- version: "3.8" services: web: ～要約～ #ボリュームを使いWEBデータを永続化 volumes: - wordpress/:/var/www/html ～～～～～～～～～～～～～～～～～～～～～～～ db: ～要約～ #ボリュームを使いDBデータを永続化 volumes: - mariadb:/var/lib/mysql ～～～～～～～～～～～～～～～～～～～～～～～ # databaseのように永続的なストレージが欲しい場合に必要な設定 volumes: mariadb: wordpress: --------------------------------------------- 3.dockerコンテナを一度削除 # docker-compose down -v 4.docker-composeでコンテナを再作成 # docker-compose up -d 5.WEBでログインして確認 http://グローバルIP 参考② Docker-Compose persistent data MySQL Dockerのデータを永続化！Data Volume（データボリューム）の理解から始める環境構築入門 docker-compose を使って WordPress テーマ開発環境を構築しよう

AWS Cloud Practitiner Essential 殴りがき インスタンスストア EC2を作成すると、「インスタンスストアボリューム」というローカルストレージ(ハードディスクみたいな。)が提供される。 インスタンスストアボリュームは、インスタンスが実行されるホストのストレージを仮想的に取得したもの そのため、インスタンスを終了させると、そのインスタンスが保存していたデータは失われる。 再度同じインスタンスを実行しても、同じ物理ホスト上で実行されるとは限らないため。 一時的なデータなどを保管する際に使う。 Amazon EBS(Elastic Block Store) ブロックストレージ - 「EBSボリューム」という仮想ストレージが、インスタンスとひもづく。 物理ホストとの紐付きではないため、インスタンスが終了され、再び実行してもデータは残ったまま。 設定を考える サイズ タイプ EBSのバックアップは、増分バックアップ(スナップショットを作成する) 1回目: 全てのデータがバックアップされる 2回目: 1回目から増えた分だけバックアップする 3回目: 2回目から増えた分だけバックアップする EC2インスタンスと1セットとなる。 AZレベルでEBSが作られるため、違うAZのインスタンスに対してEBS上のデータを共有することはできない。 ※　増分バックアップと差分バックアップの違い - 増分は、前回からその都度増えた分だけバックアップをとる。 - 差分は、フルバックアップ(初回)から増えた分その都度バックアップをとる。　⇦　3回目の内容には、2回目の内容も含まれる。 S3(Amazon Simple Storage Service) オブジェクトストレージ データの保存・取得に制限がない。 アップロードの最大容量(= 一回にアップできるファイルの最大サイズ)は5TB データ: オブジェクトとして保存される。 ディレクトリ: バケットと呼ばれる。 バケットにオブジェクトを保存するイメージ。 オブジェクトをバージョン管理する機能がある。 誤って削除されても、指定のバージョンにすぐに戻すことができる。 オブジェクトは、データ・メタデータ・キーで構成される データ: 保存する内容 メタデータ: データの種類・使用方法・サイズ キー: 一意の識別子 - アップする際に、アクセス制御を設定する。 S3ライフサイクルポリシー ストレージクラス間でデータを自動的に移動する - 例: 90日はS3標準で保存し、その後30日はS3低頻度アクセスで保存する。そしてその後はS3 Glacierで保存する。 - このような、どの期間をどのシステムで保存するかを設定できる。 ストレージクラス S3標準 9 * 11 (イレブン9)の耐久性。 99.999999999%データを失うことはない。 静的Webサイトのホスティングができる　⇦　オブジェクトとしてWebサイトを保存すれば、それにアクセスするだけでWebサイトが使える 頻繁にアクセスされるデータ用 最低3つのアベイラビリティゾーンにデータが保存される。 S3標準 - 低頻度アクセス(S3標準-IA) バックアップなど、長期間でのデータ保存が必要だか、頻繁にアクセスすることはないデータを保存する。 頻繁にアクセスされることはないが、必要な際にはすぐアクセスできる設計 保存にかかる料金は低い。取り出しにかかる料金が高い。 最低3つのアベイラビリティゾーンにデータが保存される。 S3 1ゾーン - 低頻度アクセス(S3 1ゾーン - IA) 1つのアベイラビリティーゾーンにデータが保存される ストレージコストを節約する場合に適する AZが一つであるため、三つ使うストレージクラスより安い AZに障害が発生した場合にデータを簡単に復元できる。 S3 Intelligent-Tiering アクセスする頻度が不明な際、このストレージクラスを選択することにより、アクセス状況に応じて適切なストレージクラスに移動される。 30日間連続アクセスなし: S3標準-低頻度アクセスに移動。 低頻度アクセスに移動後にアクセスが増えた: S3標準に移動。 S3 Glacier データをアーカイブする必要がある場合。 データの取得には数分から数時間かかる。(S3標準やS3標準-低頻度アクセスより取得に時間がかかる) S3 Glacier Deep Archive 最も低コスト データ取得には12時間(以内)かかる。(S3 Glacierよりさらに取得に時間がかかる) EBS と　S3　の比較 EBS -　一つのファイルに対して、小さな変更を頻繁にするケースに適する -　ファイルを小さなパケットに分割して保存する(ブロックストレージ)ため、ファイルの極1箇所を変更した際は、その小さな変更分だけを更新されることになる。 S3 たくさんの場所から参照される場合(Webなど)に適する。 一つのファイルに対して、頻繁に変更しないケース(Write Once Read Many)に適する ファイルをオブジェクトとして保存する(オブジェクトストレージ)ため、ファイルの極1箇所に小さな変更を加えた場合でも、ファイル丸ごとアップロードし直さないといけない。 ファイルが80GBで、そのうちの1GB分のデータに変更を加えた場合でも、80GB分を再アップロードする必要がある ウェブが有効(オブジェクトにはurlが付与されており、アクセス権によって操作する) 耐久性が強い -> 9 * 11の耐久性 コスト削減 -> EBSを使うよりやすい。 サーバーレスである。 Amazon Elastic File System(Amazon EFS) ファイルストレージ 複数のインスタンスがEFSのデータに同時に読み込み・書き込みができる スケーリング・複製などをAWSに任せることができる リージョン単位でEFSが作成されるため、同じリージョン内のインスタンスであればEFSのデータにアクセスすることができる。　⇦　複数リージョンに作成され、スケーリングなどがされる。 Linuxファイルサーバーとなるため、アクセスする際には、ファイルパスを操作する RDS (Amazon Relational Database Service) 以下の管理をAWSがしてくれる。 自動パッチ適用 バックアップ 冗長性 フェイルオーバー 災害対策 セットアップ バックアップ 以下のRDBMSがサポートされている PostgreSQL MySQL MariaDB Oracle DB Microsoft SQL Server Amazon Aurora MySQLとPostgreSQLの二つと互換性がある。 MySQLの5倍, PostgreSQLの3倍高速 高可用性が求められるケースに適する コストは商用DBの1/10 データレプリケーション 常に6つのコピーが複製されている　⇦　3つのAZに2つずつ。 最大15個まで複製を増やせる　⇦　増やすことで読み取り負荷を分散してパフォーマンスを拡張させることができる S3への継続バックアップされている 特定の期間のデータを復旧できる(ポイントインタイムリカバリ) エンタープライズ規模のリレーショナルデータベース AmazonDynamoDB サーバーレスデータベース。 -　パッチ適用・管理・外ウェアのインストールなどを自動で実行してくれる 高いスケーラビリティ 自動的にスケーリングされる 非リレーショナルDB NoSQL(SQLは使わない。) 応答時間がめっちゃ短い。(数ミリ秒) 非リレーショナルDBの特徴 キーバリューペアがある。 キー: 一つのデータを示す バリュー: 一つのデータが持つ情報。それぞれのデータが同じバリュー属性を持たくて良い。 バリューをいつでも追加・削除できる キー バリュー 1 名前: Kohei, 住所 123, 性別: 男 2 名前: Takeshi, 誕生日: 1180年7月7日, 年齢: 17 Amazon RDS と Amazon DynamoDBの比較 Amazon RDS -　各データの複雑な結びつきがある場合に適する Amazon DynamoDB 各データで複雑な結びつきがなく、大量なデータを高速に処理する場合に適する Amazon Redshift 現在のデータではなく、過去のデータをさかのぼって処理するのに適する。 データウェアハウシングを提供するサービス - ビックデータ分析 - データの傾向を理解するのに役立つ。 Amazon DMS(Amazon Database Migration Service) オンプレミス環境や移行元EC2・RDSなどからクラウドへデータ移行をする際に役立つサービス。 RDS,非RDS(NoSQL)でも移行は可能。 開発環境・テスト環境でのデータベース移行にも使える。 開発環境 or テスト環境に本番環境のデータをコピーするなど。 データベースの統合にも使える。 複数のDBを一つのDBにまとめる 継続的なデータベースレプリケーションにも使える。 地理的に離れている場所に複製ができるため、優れたバックアップとして使える。 移行中も、移行元のDBを通常通り運用しながらできる アプリケーションのダウンタイムが最小限となる。 移行元と移行先のDBの種類が異なっていても問題なく移行できる ex: 移行元のMySQL を 移行先のPostgreSQLにデータを移せる 1. スキーマ構造・データ型・データベースコード を 移行先へ変換 1.　　実際にデータを移行する その他のデータベースサービス Amazon DocumentDB MongoDBをサポートするドキュメントDBサービス。 Amazon Neptune グラフDBサービス -> 高度に接続されたデータセットを使うアプリケーション構築に適する レコメンデーションエンジン・不正検出・ナレッジグラフなど Amazon QLDB(Amazon Quantum Ledger Database) 台帳DBサービス データに対して行われた全ての変更履歴を確認できる Amazon Managed Blockchain ブロックチェーンネットワークを作成・管理するために使用できる ブロックチェーンは複数の当事者がトランザクションを実行し、データを共有できるようにする分散台帳システム Amazon ElastiCache DB上にキャッシュレイヤーを追加することで、リクエスト読み込みを短縮できるサービス Amazon DynamoDB Accelerator DynamoDBのインメモリキャッシュ。応答時間をマイクロ秒に向上する。(DynamoDBはミリ秒)

目的 ・スマホの育成ゲームの結果をデータベースにまとめたい。 ・1つずつ手入力するのは手間である。 ・AWSに画像上の文字を認識して出力するサービスがあるので利用してみる。 （日本語は無理そうだが、アルファベットや数字は問題なさそう。） 実行内容 ①画像の準備（スマホでスクリーンショットで収集） ②画像の加工（OpenCVで大きさや不要な箇所を隠すなど実施） →文字認識結果をまとめやすくするため ③AWSのRekognitionを使ってテキスト検出を行う。 ④結果をデータベースにまとめる 記載内容 今回は③のRekognitionのテキスト検出について記述する。 参考 ①Qiita記事（コードの内容） https://qiita.com/banquet_kuma/items/560787299b83fb924ff7 ②AWS_Rekognition公式入門ガイド https://aws.amazon.com/jp/rekognition/resources/ テキスト検出結果 加工した画像 出力結果 ※一番最初には読み込んだ画像名を出力してます。（テキスト検出の範囲外） 　「NN」という文字はどこから検出したか不明ですが、収集後削除すれば良し。 コード code import boto3 import configparser region = "画像を保存しているS3のRegion" bucket = "画像を保存しているS3のバケット名" #アクセスキーが記述されているiniデータから必要な情報を抽出 ini = configparser.ConfigParser() ini.read("読み込む.iniデータ","utf-8") access_key = ini["AWS_KEY"]["aws_access_key_id"] secret_key = ini["AWS_KEY"]["aws_secret_key"] session = boto3.Session(aws_access_key_id=access_key,aws_secret_access_key=secret_key,region_name=region) #S3に保存している画像一覧の取得 s3 = session.client("s3") objects = s3.list_objects_v2(Bucket=bucket) for filename in objects["Contents"]: filename = filename["Key"] idname = filename.split(".")[0].split("/")[1] #idnameは読み込んだデータ名 data = [idname] rekognition = session.client("rekognition") #テキストの検出 response = rekognition.detect_text(Image={"S3Object":{"Bucket":bucket,"Name":filename}}) textDetections = response["TextDetections"] for text in textDetections: data.append(text["DetectedText"]) #収集した結果を出力 print(data) 所感 ・精度がよくて、満足。 ・育成データの手入力が不要って、すごく便利！！ ・知らないうちに世の中がさらに便利になっていく、、、驚きです。 ※本記事には記載していないが、収集結果をデータベースにまとめて、欲しいデータをSELECT文で抽出してグラフで表示することまで行った。 以上。

SAM CLIとDynamo DB Localを使用してローカル環境でサーバーレスアプリを構築する手順についてメモする。 前提条件 Docker、docker-composeインストール済みであること。 dynamodb-admin(DynamoDB GUIツール)インストール済みであること。インストール手順 SAM CLIインストール済みであること。 ディレクトリ構成 local_app - dynamodb -- docker-compose.yml | |_ docker - dynamodb |_ sam-app 構築手順 DynamoDB Local準備 docker-compose.yml準備 version: '3.8' services: dynamodb-local: command: "-jar DynamoDBLocal.jar -sharedDb -dbPath ./data" image: "amazon/dynamodb-local:latest" container_name: dynamodb-local ports: - "8000:8000" volumes: - "./docker/dynamodb:/home/dynamodblocal/data" working_dir: /home/dynamodblocal networks: - lambda-local networks: lambda-local: external: true 2.Docker network 作成＋コンテナ起動 docker network create lambda-local docker-compose up ※localhost:8000でコンテナが起動する。 3.dynamodb-admin(http://localhost:8001)にアクセス 4.テスト用テーブルtest-table作成 ※テーブル設定は下記の通り。 { "AttributeDefinitions": [ { "AttributeName": "name", "AttributeType": "S" }, { "AttributeName": "date", "AttributeType": "S" } ], "TableName": "test-table", "KeySchema": [ { "AttributeName": "name", "KeyType": "HASH" }, { "AttributeName": "date", "KeyType": "RANGE" } ], "TableStatus": "ACTIVE", "CreationDateTime": "2022-01-16T05:43:16.767Z", "ProvisionedThroughput": { "LastIncreaseDateTime": "1970-01-01T00:00:00.000Z", "LastDecreaseDateTime": "1970-01-01T00:00:00.000Z", "NumberOfDecreasesToday": 0, "ReadCapacityUnits": 3, "WriteCapacityUnits": 3 }, "TableSizeBytes": 116, "ItemCount": 3, "TableArn": "arn:aws:dynamodb:ddblocal:000000000000:table/test-table" } SAMプロジェクト準備 1.SAMプロジェクト作成 local_appディレクトリ内で次のコマンドを実行。 sam init --runtime python3.8 ※HelloworldFunction利用。その他もデフォルト設定で作成。 2.各種設定、コード変更 app.py DynamoDBテーブルtest-tableにname、dateを登録する。 import json import boto3 import string import random from datetime import datetime def lambda_handler(event, context): # DynamoDB接続設定 session = boto3.session.Session() region = session.region_name dynamodb = boto3.resource('dynamodb', region_name = region, endpoint_url = "http://dynamodb-local:8000") # テーブルを取得 table = dynamodb.Table('test-table') # name(文字数5の英数字文字列) dat = string.digits + string.ascii_lowercase + string.ascii_uppercase name = ''.join([random.choice(dat) for i in range(5)]) # 日時 date = datetime.utcnow().isoformat() # 登録アイテム item = {'name': name, 'date': date} # テーブル登録 table.put_item( Item=item ) return { "statusCode": 200, "body": json.dumps(item), } requirements.txt ※boto3追加 requests boto3 template.yml ※Pathを/item、Methodをpostに変更 ~省略~ Events: HelloWorld: Type: Api Properties: Path: /item Method: post 3.API起動 sam local start-api --docker-network lambda-local 動作確認 APIリクエスト POST /item HTTP/1.1 Host: localhost:3000 Content-Type: application/json Content-Length: 2 {} APIレスポンス { "name": "d4jlG", "date": "2022-01-16T06:00:45.853215" } dynamodb-adminからテーブル内容確認

DynamoDB Localの環境構築手順についてメモする。 DynamoDB Localとは AWS製のローカル環境向けDynamoDB Dockerイメージとして提供 前提条件 Docker,docker-compose環境構築済みであること。 nodejsインストール済みであること。 ディレクトリ構成 dynamo_test -- docker-compose.yml |_ docker/dynamodb 環境構築手順 1.docker-compose.yml準備 version: '3.8' services: dynamodb-local: command: "-jar DynamoDBLocal.jar -sharedDb -dbPath ./data" image: "amazon/dynamodb-local:latest" container_name: dynamodb-local ports: - "8000:8000" volumes: - "./docker/dynamodb:/home/dynamodblocal/data" working_dir: /home/dynamodblocal 2.マウントディレクトリ作成+権限設定 ※コンテナ内部でdynamodblocalユーザーとして処理するために必要 mkdir -p ./docker/dynamodb sudo chmod 777 ./docker/dynamodb 3.コンテナ起動 docker-compose up Starting dynamodb-local ... done Attaching to dynamodb-local dynamodb-local | Initializing DynamoDB Local with the following configuration: dynamodb-local | Port: 8000 dynamodb-local | InMemory: false dynamodb-local | DbPath: ./data dynamodb-local | SharedDb: true dynamodb-local | shouldDelayTransientStatuses: false dynamodb-local | CorsParams: * dynamodb-local | ※localhost:8000でコンテナが起動する。 動作確認 0.dynamodb-admin(DynamoDB用GUIツール) . 次のコマンドを実行する。 npm install -g dynamodb-admin set DYNAMO_ENDPOINT=http://localhost:8000 ※筆者環境はWindowsのため、上記接続先設定を行っている。 1.dynamodb-admin起動 dynamodb-admin 2.http://localhost:8001にアクセス 3.テーブル作成 Create Tableボタンを押下し、テーブル情報を入力してテーブルを作成する。 参考情報 DynamoDB ローカル (ダウンロード可能バージョン) のセットアップ aaronshaf/dynamodb-admin DynamoDBの初心者に伝えたい初めて触るときの勘所

はじめに この度AWS認定のSAPを受験してきましたので、勉強した内容と受験した感想を書いておきます。 これから受験される方の参考になれば幸いです。 今回でAWS認定は10冠を達成しました。 2019-07-04 AWS Certified Cloud Practitioner 2019-07-24 AWS Certified Solutions Architect - Associate 2021-02-25 AWS Certified Data Analytics - Specialty (DAS) 2021-07-23 AWS Certified Developer - Associate (DVA) 2021-10-26 AWS Certified SysOps Administrator - Associate (SOA) 2021-11-13 AWS Certified Security - Specialty (SCS) 2021-12-01 AWS Certified DevOps Engineer - Professional (DOP) 2021-12-28 AWS Certified Database - Specialty (DBS) 2022-01-06 AWS Certified Advanced Networking - Specialty (ANS) 2022-01-15 AWS Certified Solutions Architect - Professional (SAP) ← 今回 前提 AWS経験は２年と半年程度 普段はデータ分析系のサービスを使うことが多い 最近は業務でセキュリティ周りのこともやる機会が増えてきた DB系はほとんど使わない。Redshiftだけ触る コンテナ周りは少々触る ネットワークはVPCとエンドポイントぐらいしか触らない 学習内容 今回は以下の順番で勉強を進めました。 ①試験対策本（AWS認定資格試験テキスト&問題集 AWS認定ソリューションアーキテクト - プロフェッショナル） ②練習問題 ③Web問題集 試験対策本 最初に昨年発売されたSAP本を使って勉強しました。 必要なサービスが網羅的に説明されていて、出題範囲を理解するのに役に立ちました。 実際に試験を受けてみて思ったのは、いくつか足りないサービスや説明があるので、追加で公式ドキュメントや動画で深堀りできると良いと思います。 尚、巻末の模擬問題は解いてません。 練習問題 今回も公式から出ている無料の練習問題を利用しました。 問題数は20問と少ないですが、問題の正答と解説を読んで調べるだけでも学べることは多いので、受験するなら一回は受けてたほうが良いと思います。 正答率９０%を超えるまで繰り返し解きました。 Web問題集 あとはいつもどおりkoiwaclubの問題集を利用しました。 サイトの合格記を見ると#30以降が精度高いらしいので、#30〜#62を正答率100%になるまで繰り返し解きました。 実際に受験してみて、精度高いという評判は確かだなと思いました。 ただ、当然全範囲をカバーしているわけじゃないので、これだけ解いて合格できるかと言われるとそういうわけではないと思います。 足りない部分は、公式ドキュメントや動画で補足しておいたほうが良いです。 受験した感想 これまでの試験と同じく3時間使い切りましたが、見直しの時間はほとんど取れなかったので、そういう意味だとこれまでの試験の中でも一番難しかったです。 前述したWeb問題集や対策試験本で勉強した内容はもちろん役に立ちましたが、過去に取得したAWS試験で学んだ知識も結構必要になりました。 ただ、それでも知らないサービスが出題されたりしたので、出題範囲はかなり広いと感じました。 特に移行関連のサービスは勉強しておいたほうが良いかもしれません。 受験結果 スコアは808でした。 おわりに 残すはMLSだけなので、まずは機械学習について勉強を開始しようかと思います。

前回はServerless Frameworkをローカル実行する方法を記事にしました。今回はその続きで、DynamoDBをローカルで立てるプラグインServerless DynamoDB Localについて述べます。 Serverless DynamoDB Local のインストール 前回と同様にaws-nodejs-templateを使って環境を作成します。template.yamlファイルを使って書く記事が沢山上がっているのですが、TypeScriptで書いた方が変数の取り込みなど便利すぎるのでtsで書く方法を述べます。（といってもyamlをJSONに直すだけですが笑）あとでリソース用のバケットも準備するのでディレクトリ名はresourcesとしています。 $ serverless create --template aws-nodejs-typescript --path resources $ cd resources $ npm install こんな感じのディレクトリ構成で進めます。api側は前回作ったAPIで、今回は新たにresourcesを足しました。 backends ├── api │   ├── README.md │   ├── node_modules │   ├── package-lock.json │   ├── package.json │   ├── serverless.ts │   ├── src │   ├── tsconfig.json │   └── tsconfig.paths.json └── resources │   ├── README.md │   ├── node_modules │   ├── package-lock.json │   ├── package.json │   ├── serverless.ts │   ├── src │   ├── tsconfig.json │   └── tsconfig.paths.json ここからは、公式に従ってインストールしていきましょう。まず、npmでserverless-dynamodb-localをインストールします。 $ npm install -D serverless-dynamodb-local 次に、serverless.tsの不要な部分を削除しつつ、次のように書き換えます。なお、stageは"local"としました。 serverless.ts import type { AWS } from "@serverless/typescript"; const serverlessConfiguration: AWS = { service: "resources", frameworkVersion: "2", plugins: ["serverless-esbuild", "serverless-dynamodb-local"], provider: { name: "aws", runtime: "nodejs14.x", stage: "local", }, package: { individually: true }, custom: { esbuild: { bundle: true, minify: false, sourcemap: true, exclude: ["aws-sdk"], target: "node14", define: { "require.resolve": undefined }, platform: "node", concurrency: 10, }, }, }; module.exports = serverlessConfiguration; 重要なのは、pluginsの最後に"serverless-dynamodb-local"を足したことです。（必ずビルド用プラグインの後に書いてください）さらに、この環境に次のコマンドでDynamoDB Localをインストールします。 $ npx sls dynamodb install 以上でインストールは完了です！ DynamoDB Localの起動 前項でServerless DynamoDB Localのインストールは完了しました。次は、serverless.tsのresourcesを足していきます。serverless.tsのserverlessConfigurationに次のキーとオブジェクトを足してください。 serverless.ts const serverlessConfiguration: AWS = { ... resources: { Resources: { DynamoDBTable: { Type: "AWS::DynamoDB::Table", Properties: { TableName: "test", AttributeDefinitions: [ { AttributeName: "DataType", AttributeType: "S", }, { AttributeName: "ID", AttributeType: "S", }, ], KeySchema: [ { AttributeName: "DataType", KeyType: "HASH", }, { AttributeName: "ID", KeyType: "RANGE", }, ], ProvisionedThroughput: { ReadCapacityUnits: 1, WriteCapacityUnits: 1, }, }, }, }, }, ... } このresorcesはAWSの公式に従って書いていけば良いです。たくさんのオプションがあるので戸惑うかもしれませんが、基本はPK, SK, GSIなどのテーブル設定と1秒当たりのスループットの最大値を設定するだけです。 次に、DynamoDB LocalのConfigを書いていきます。serverlessConfiguration.customに次を足します。 serverless.ts const serverlessConfiguration: AWS = { ... custom: { ... dynamodb: { stages: ["local"], start: { port: 8000, inMemory:true, migrate:true, seed: true, }, seed: { local: { sources: [ { table: "test", sources: ["./seed/test.json"], }, ], }, }, }, }, } ここで、stagesにはローカル実行したいステージを記載します。また、startにはローカル実行する場合の設定を書き、start.seed=trueの場合はDB起動時のシード値としてseedに書いたソースがインポートされます。なお、seed/test.jsonには以下のようなデータを入れました。 seed/test.json [ { "DataType": "Hoge", "ID": "HOGE_1" }, { "DataType": "HUGA", "ID": "HUGA_2" } ] 　ここまでできると、次のコマンドで起動できます。(注意：Javaがインストールされていないとエラーが出ることがあるようです) $ npx sls dynamodb start 次が表示されると、localhost:8000にDynamoDBが立っていることになります。 Dynamodb Local Started, Visit: http://localhost:8000/shell Serverless: DynamoDB - created table test Seed running complete for table: test 接続確認 ここではAPIも同時に立てて、DynamoDB Localにアクセスできるか確認しましょう。前回のようにLambda関数をローカルで実行します。 まず、sdkをインストールします。 $ npm install @aws-sdk/client-dynamodb 次に、Lambda関数を書いていきます。api/src/functions/hello/handler.tsに次を足します。 api/src/functions/hello/handler.ts import { DynamoDBClient, DynamoDBClientConfig, ScanCommand, } from "@aws-sdk/client-dynamodb"; const ClientConfig: DynamoDBClientConfig = { endpoint: "http://localhost:8000", }; const dynamodb = new DynamoDBClient(ClientConfig); さらにハンドラ関数内で次のようにDynamoDBアクセスを行います。ここではそのままレスポンスにDBのデータを入れました。 api/src/functions/hello/handler.ts const hello: ValidatedEventAPIGatewayProxyEvent<typeof schema> = async ( event ) => { ... const result = await dynamodb.scan({ TableName:"test" }).promise(); const data = result.Items; ... return formatJSONResponse({ data, event, }); }; ここまでやれば、あとはローカルで実行してみるだけ！ $ npx sls invoke local -f hello 次のようなレスポンスが帰ってきたらOKです。 { "statusCode": 200, "body": "{\"data\":[{\"DataType\":{\"S\":\"HUGA\"},\"ID\":{\"S\":\"HUGA_2\"}},{\"DataType\":{\"S\":\"Hoge\"},\"ID\":{\"S\":\"HOGE_1\"}}],\"event\":\"\"}" } まとめ 今回はServerless DynamoDB Localを使ってDynamoDBのローカル開発環境を整えてみました。まとめると次のような感じでした。 serverless createでServerless Frameworkの環境構築 npm install -D serverless-dynamodb-localでnpmモジュールをインストール serverless.tsにプラグインを記載してnpx sls dynamodb installでServerless環境にインストール serverless.tsにresourcesを追加し、custumにDynamoDB Localの設定を記載 npx sls dynamodb startで起動 接続確認 少し手間がかかりますが、実際に立てられさえすればローカル開発がめちゃめちゃ捗ります！ぜひ使ってみてください。 次回はさらにS3 Bucketをローカル環境に追加してみます。ぜひこれからも最高のエンジニアライフを！！

はじめに AWSのIAMユーザに対して、時々、一時的に強い権限を与える必要があり、CloudFormationを用いてその操作を簡単にできるようにした内容を記事にしました。 概要 期間限定で(管理者ユーザにアタッチしている)IAMポリシーに権限を与えます。 その操作を、CloudFormationのスタックの更新で行います。 パラメータの変更だけで実現でき、操作ミス等が生じにくい運用にできます。 利用シーン AWSのBIサービスであるQuickSightは、S3やRedshiftなど、外部のデータを取得して可視化できます。 QuickSightから外部のサービスにアクセスする際は、専用のIAMロールがQuickSightにアタッチされます。 一方QuickSightの管理者は、QuickSightの操作を行うだけであれば、外部のリソースに対する許可は不要です。 ですが、別サービスとの連携を追加するなどQuickSightの設定変更を行う際、変更するユーザ（ここでは管理者）に「対象のサービスを閲覧できる権限」や「QuickSightのIAMロールを変更できる権限」などの権限が必要な模様でした。 そのため、「普段はQuickSightの権限だけもつユーザ。設定変更の際に一時的に強い権限を有効にする、なるべく簡単な操作で」という運用の際に使います。 CloudFormation 以下が作ったCloudFormationのコードです。英語の拙さはご容赦ください。 AWSTemplateFormatVersion: 2010-09-09 Description: Create QuickSight Admin Parameters: userId: Description: QuickSight administrator user ID. Type: String Default: quicksightadmin password: Description: QuickSight administrator default password. Type: String NoEcho: true datelessthan: Description: the expiration date of the IMPORTANT ACTION. Type: String Default: 2020-08-31T19:00:00+09:00 Metadata: AWS::CloudFormation::Interface: ParameterGroups: - Label: default: User Login Information. Parameters: - userId - password - datelessthan Resources: # QuickSight用の管理者IAMユーザー QuickSightIAMUser: Type: "AWS::IAM::User" Properties: Path: "/" UserName: !Ref userId LoginProfile: Password: !Ref password PasswordResetRequired: true ManagedPolicyArns: - !Ref QuickSightIAMManagedPolicy Tags: - Key: "phase" Value: "operation" QuickSightIAMManagedPolicy: Type: "AWS::IAM::ManagedPolicy" Properties: ManagedPolicyName: "quicksight-admin" Path: "/" PolicyDocument: Version: "2012-10-17" Statement: - Effect: "Allow" Action: - "ds:AuthorizeApplication" - "ds:UnauthorizeApplication" - "ds:CheckAlias" - "ds:CreateAlias" - "ds:DescribeDirectories" - "ds:DescribeTrusts" - "ds:DeleteDirectory" - "ds:CreateIdentityPoolDirectory" - "iam:ListAccountAliases" - "quicksight:CreateAdmin" - "quicksight:Subscribe" - "quicksight:Unsubscribe" - "quicksight:GetGroupMapping" - "quicksight:SearchDirectoryGroups" - "quicksight:SetGroupMapping" Resource: "*" # 以下、初期設定のために一時的に強い権限を与える - Effect: "Allow" Action: - "s3:*" - "glue:*" - "athena:*" - "iam:*" Resource: "*" Condition: DateLessThan: aws:CurrentTime: !Ref datelessthan ポリシー"quicksight-admin"の1つ目は、QuickSightの管理者に必要な権限になります。 必要十分な設定のつもりです。わかる方いらっしゃいましたらご指摘ください。 ポリシー"quicksight-admin"の2つ目が一時的に付与する強い権限です。 どれくらい強い権限を与えればいいかわからなかったので、かなり大雑把です、スミマセン。 ここではS3とGlueとAthenaですが、他に必要な権限ありましたら適宜追加します。 Conditionにて、現在時刻よりもパラメータの入力時刻が未来であれば有効、という内容になります。 使い方 作成時 このCloudFormationで、管理者を作成。 その際、パラメータdatelessthanには、QuickSightの設定を終わらせられそうな時刻を入力。 QuickSightを、作ったユーザで有効化。 リソース参照など、各種設定を行う。 パラメータdatelessthanの時刻が過ぎると、自動的に強い権限が無効化されます。 設定ON時 管理者を作成したCloudFormationのスタックを更新。 現在のテンプレートを使用　を選ぶ。 パラメータdatelessthanに、変更したい設定を終わらせられそうな時刻を入力し更新。 作成時と同様にパラメータdatelessthanの時刻が過ぎると、自動的に強い権限が無効化されます。 これで直接IAMポリシーを修正することなく、入力するだけで一時的に強い権限を付与することができました。 おわりに 一時的に強い権限を付与する方法を、CloudFormationを使うことで簡単に出来ることを紹介しました。 今回はQuickSightでしたが、他にも使う機会ありましたら参考にしてください。

AWS Cloud Practitiner Essential 殴りがき VPC(Virtual Private Cloud) AWSユーザー専用のプライベートネットワーク VPC内に、EC2やELBなどを配置できる ゲートウェイがないと、VPC内のリソースには誰もアクセス出来ない。 サブネット VPC内のIPアドレスの集合 インターネットに公開するか、プライベートにするか。 ※　サブネットによって複数のネットワーク空間に分けているため、ゲートウェイはVPCに複数設置される可能性がある。 パブリックサブネット インターネットゲートウェイからのアクセス権がある。 プライベートサブネット インターネットゲートウェイからのアクセス権がない。 インターネットゲートウェイ インターネットからVPCにアクセスを可能にするには、インターネットゲートウェイを設置する必要がある。 インターネットからインターネットゲートウェイを通してELBに対してのリクエストを可能とする。 仮想プライベートゲートウェイ プライベートネットワーク(指定された社内ネットワークなどVPN接続)からのアクセスだけ許可する インターネットからのアクセスは拒否する プライベートネットワークから仮想プライベートゲートウェイを通してELBに対してのリクエストを可能とする。 配置位置はインターネットゲートウェイと同じ感じ。 イメージは、インターネットを使ってリクエストを送るが、VPNのようにリクエストは暗号化され、周りからは守られる。ただし、インターネットと同じ経路を使うため、リクエストの渋滞などに巻き込まれる可能性はある。 AWS Direct Connect データセンターから直接VPCに繋げ、Direct Connectを通してELBに対してのリクエストを可能とする。 配置位置はインターネットゲートウェイと同じ感じ。 イメージは、インターネットを使わないため、他のリクエストの渋滞に巻き込まれる可能性はない。接続元からの直通通路を使うイメージ ネットワーク ACL パケットの送信者、通信方法によりサブネットに通すか判断する。 入国、出国を検査するファイヤウォール。 ゲートウェイは、どこからのリクエストを許可するのかを判別するイメージ。 ネットワーク ACLは、リクエストの内容に応じて許可するかを判別するイメージ。 ブラックリストやホワイトリストなどを設定して、特定のリクエストをはじく。 リクエストを迎える、レスポンスを送る。それぞれに対して許可するかを判断する。 ステートレス: 通過するパケットの一つ一つをチェックする 出国したからといって、帰国する際にも必ずチェックする。　⇦　ステートレスで覚えてないから。 ACLは、AWSが提供するデフォルトACLと、自分でカスタマイズするカスタムネットワークACLがある。 デフォルトACLでは、全てのトラフィックの入国・出国を許可する ルールを加えることで変更はできる カスタムネットワークACLでは、全てのトラフィックの入国・出国を拒否する ルールを加えることで許可するものを登録できる。 セキュリティグループ インスタンス単位のセキュリティ。パケット情報に対して？ デフォルトでは、全ての入国を拒否、全ての出国を許可。 同じサブネット内の特定のインスタンスには許可する。セキュリティグループという設定をインスタンスに付与する。 デフォルトでは全てのポートが閉じられ、全てのリクエストを許可しない設定となっている。 リクエストを迎え際は許可するか判断するが、レスポンスを送る際は判断しない。 ステートフル: 許可するかどうかを記憶によって判断する = 以前通過したものはチェックしない リクエストに対してチェックを入れ、そのリクエストを覚えておく。レスポンスを通す際はチェックしない。　⇦　ステートレスでチェックしたこと覚えてるし。 Route53 DNS。 レイテンシーベースのルーティング 位置情報DNS リクエスト先に近いリージョンにルーティングする 地理的近接性ルーティング 加重ラウンドロビン Amazon CloudFront エッジロケーション。コピーデータをキャッシュして、遠いリージョンにアクセスしなくても高速でリクエストを処理して返すことができる。 -> CDNと呼ばれる技術。

はじめに DynamoDBをCloudFormatinで使うときの留意点をまとめてみました DynamoDBでのBillingMode BillingモードはPROVISIONEDとPAY_PER_REQUESTのふた通りあります。 PAY_PER_REQUESTは従量課金になります。 Billingモードを指定しない場合はデフォルトのPROVISIONEDが選択されます。 PROVISIONEDが指定された場合はProvisionedThroughputの項目が必須になります。 DynamoDBUserTable: Type: AWS::DynamoDB::Table Properties: AttributeDefinitions: - AttributeName: id AttributeType: S KeySchema: - AttributeName: id KeyType: HASH ProvisionedThroughput: ReadCapacityUnits: 5 WriteCapacityUnits: 5 TableName: Fn::Sub: "User" BillingModeの項目がないためPROVISIONEDが指定され、ProvisionedThroughputのReadCapacityUnitsとWriteCapacityUnitsを５にしています。 最後に 従量課金はアクセス数が予測できない時に使うと良さそうですが、開発段階では必要なさそうです。 参考文献

１．はじめに 少し前にControl Towerでマルチアカウント環境を構築する機会がありました。非常に便利で使い勝手がよかったので、今回は構築方法を含てめこの記事の中で紹介していきたいと思います。 ２．そもそもControl Towerとは AWSのマルチアカウント環境を一括でまるっと提供してくれるサービスです。通常であれば非常に手間のかかる構築作業の大半をサービスがほぼ自動で対応してくれます。Control TowerはLanding Zoneという考え方に基づいているので、まずこちらについて簡単に解説します。 ２－１．Landing Zone Landing Zoneは、Well-Architected Framework などAWS のベストプラクティスに基づいて構成されたマルチアカウント環境をいい感じに展開するための仕組みの総称です。Landing Zone自体はあくまで考え方なので、これに準拠したマルチアカウント環境を構築する場合、基本的には仕組みを理解して自分でAWSの各種サービスを組み上げていく必要があります。 Landing Zoneについては以下のブログに詳しく書かれていますので、興味のある方はご覧ください。きれいに整理されているので、これからマルチアカウントを実装しようとしている人は読んでおいた方がよいかと思います。 ちなみにマルチアカウントそのものの考え方についてもこちらに詳細に書かれてます。（上の記事は第二回、こちらは第一回なので、こちらから先に読んだ方が分かりやすいかもしれません） ２－２．Landing Zone（実装） 先ほどLanding Zoneは考え方だと書きましたが、この概念をAWSが形にして一般公開したものをLanding Zone（実装）と言うそうです。名前が同じなので若干混乱してしまいそうですが。。 私も使用したことはないですがNode.jsやCloudFormationで実装されているようで、このスクリプトを各自のAWSアカウント上で実行することでLanding Zoneに則ったマルチアカウント環境を構築することができるとのことです。こちらは現在長期サポート中の扱いで機能追加はストップされているようなので、これからマルチアカウントを構築したいと考えている人は使わない方がよさそうです。もし興味のある方は以下AWSのページを参照ください。 ２－３．Contorol Tower 上記Landing Zone（実装）の後継となるサービスです。どこかでそういう記述を見たわけではないですが、そんな雰囲気で恐らく合ってると思います。こちらはNode.jsスクリプトではなく純粋なAWSサービスとして提供されており、当然のごとくLanding Zoneに準拠しています。 対象のAWSアカウントでマウスをポチポチするだけで即利用できます。非常に便利なので今後のマルチアカウント管理のド本命と思いますが、利用できるリージョンに縛りがあるなど現時点ではまだ若干の癖があるため、この辺を受け入れられるかが採用のポイントかと思います。 制約や注意事項についてはこちらに纏めていますので、興味のある方はご覧ください。 ２－４．Control Towerを構成するサービス Control Towerは複数のAWSサービスを組み合わせて構成されています。使用しているサービスのうち、代表的なものを以下に記載します。 AWS Organizations AWSでマルチアカウントを実現する際に必須となるサービスです。 親となるアカウントを管理アカウントとし、その配下にメンバーアカウントがぶら下がるようなイメージでマルチアカウント環境を構成できます。管理アカウントは絶大な権力を持ち、メンバーの追加／変更／削除だけでなく、SCP（サービスコントロールポリシー）を使用してメンバーアカウントに対して制限を掛けたりできます。いわゆるガードレールです。 また管理アカウント上に組織単位（OU）を作成することができ、作った組織の中にメンバーアカウントを入れて管理し、さらに組織に対してSCPを割り当てたりできます。 例えば、営業部・人事部など部署毎にOUを切ってメンバーアカウントを格納し、SCPにより各部単位に制限をかけたりできます。 AWS Config AWSサービスの構成情報を記録できます。サービスに対する変更来歴を長期間保存し、いつどのような変更が行われたかを遡って確認することができます。例えば、誤ってS3がパブリック公開された際に、後からバケットポリシーの変更来歴を追いかけたりできます。 このサービスは全リージョン全アカウントで有効化することが推奨されているようです。 AWS Config Rule（適合パック） AWS Configの派生サービスです。サービスに対して加えられた変更を自動的に検知し、予め定めておいたルールに違反した場合にアラートを上げたり、自動で修復（変更内容を取り消し）したりできます。 AWS Config Rule単体ではルール違反の検知しかできないため、以前は自動修復を実現するために色々なサービスと組み合わせる必要がありましたが、適合パックの登場によりAWS Configの１サービスだけでこういったことが対応ができるようになりました。 Cloud Trail AWSに対するAPIコールのログを記録することができます。AWS Configと異なり、こちらのサービスではIAMなどのユーザによる操作（APIアクション）を記録、可視化することができます。 AWS Organizations環境下においては、管理アカウントから配下の全メンバーアカウントに対し、Cloud Trailを一括で有効化することも可能です。 AWS SSO AWS上でシングルサインオン（SSO）を実現することができるサービスです。主に前述のOrganizationsと組み合わせて使うことが多いと思います。マルチアカウント環境下で、IAMユーザを使わずにAWSコンソールへログインしたり、複数アカウントの権限を一括でコントロールしたり、あるアカウントから別のアカウントへシームレスに切り替えたりと色々できるので非常に便利です。 Service Catalog CloudFormationのテンプレートを製品として管理し、配布できるようになるサービスです。なんのこっちゃ分かりづらいと思いますが、とりあえずControl Towerの内部では、後述のAccount Factoryでこのサービスを使用しています。まあそんなものか、くらいの感覚で捉えておいてもらえればよいかと思います。 ２－５．Control Towerが提供する機能 前述した通りControl Towerは様々なサービスの組み合わせで構成されているわけですが、これらを使って最終的に提供される具体的な機能のうち、代表的なものを以下に記載していきます。 ダッシュボード Control Tower専用のダッシュボードが提供されます。これにより、中央管理者がControl Tower内のAWSアカウントの状況を継続的に監視することができます。配下のメンバーアカウントがガードレールに違反した場合には中央管理者へアラート（メール）が送信されるため、詳細をダッシュボードで確認し、各利用者に改善を促すといった運用ができるようになります。 ガードレール ガードレールはAWSのガバナンスやセキュリティの実現における重要な考え方です。道路の脇にあるガードレールと同じで「事前にはみ出してはいけない範囲を決めておいてあげて、その中では何をしてもOK」というもので、OrganizationsのSCPやAWS Configルールなどで実現します。ガードレールの一例ですが、たとえば特定のAWSアカウントに対してインターネットへのアクセスを禁止＆それ以外は制約なく好きに使わせる、といったことが実現できます。 ガードレールには、大きく分けて発見的統制と予防的統制の２種類があります。 発見的統制：やってはいけないことのルールを定義し、これに違反した場合、アラートを上げたり変更内容を自動修復したりします。操作自体に制限を加えることはないので、各アカウントではルール違反の操作を実行すること自体は可能です。起きてしまった後にどう対応するか？といった考え方となります。AWS Config Rule（と適合パック）で実現します。 予防的統制：ルール違反の操作自体を禁止します。操作ができないのでより厳しいガードレールとなります。OranizationsのSCPで実現します。 現在Control Towerで提供されているガードレールの詳細については以下のリンクを参照ください。 必須のガードレール：https://docs.aws.amazon.com/ja_jp/controltower/latest/userguide/mandatory-guardrails.html 強く推奨されるガードレール：https://docs.aws.amazon.com/ja_jp/controltower/latest/userguide/strongly-recommended-guardrails.html 選択的ガードレール：https://docs.aws.amazon.com/ja_jp/controltower/latest/userguide/elective-guardrails.html 監査ログの集約 後述のログアーカイブアカウントに、CloudTrailやAWS Configなど監査系のログが集約して保存されます。自分でログの転送設定などを行わなくても、Control Towerが全て自動で対応してくれるので非常に便利です。 Account Factory Control Tower内に新規アカウントを追加するための機能です。これを使用することで、Landing Zoneに準拠した設定がAWSアカウントに対して自動的に適用されます。ワークロードで使用する運用アカウントの作成や配布は、基本的にこのAccount Factory機能から行うことになります。 ３．構築手順 それではControl Towerの環境構築方法を記載していきます。 ３－１．事前準備 Contorol Towerではメインとなるマスターアカウントの他に、ログアーカイブアカウントと監査アカウントの２つが必要になります。それぞれの役割は以下の通りです。 アカウント種別 役割 ログアーカイブアカウント マルチアカウント環境内の全アカウントで生成された監査系のログ（AWS Config、CloudTrail）を集約して管理してくれます。 監査アカウント マルチアカウント内の監査系サービス（AWS Configなど）を集中管理するアカウントです。Control Towerから発信されるアラートメール等はこのアカウントに対して送付されます。 このため、マスターアカウント以外の新規メールアドレスをを２つ取得しておいてください。 ３－２．AWSコンソールでのセットアップ まずはマスターアカウント上でAWSコンソールを開き、メニューからControl Towerを選択します。以下の画面が表示されるので「ランディングゾーンの設定」ボタンをクリックします。 続く画面でリージョンの設定を行います。ホームリージョンはメインで使用するリージョンです。基本は東京になるかと思います。また、ホームリージョン以外にControl Towerを適用するリージョンの選択も行えます。ここでは対応している全リージョンを指定しました。 続く画面でOUの設定を行います。「基礎となるOU」は、特に理由がなければデフォルトのまま「Security」でよいかと思います。「追加のOU」にはワークロードで使用するアカウントを追加していくことになるので、運用を考慮して任意の名前を指定してください。 続いてログアーカイブアカウント、監査アカウントの設定を行います。事前準備で取得したメールアドレスを指定しましょう。またKMS暗号化は任意項目なので、必要に応じチェックをONにしてください。 最後に確認画面が表示されます。画面最下部に同意文が記載されているので、内容を確認の上チェックを入れ、「ランディングゾーンの設定」ボタンをクリックします。 そうするとセットアップ画面が表示されます。推定残り時間は60分となっているので気長に待ちましょう。ちなみに私の場合は30分程度で完了しました。 ３－３．各アカウントの設定（マスタアカウントなど） セットアップ中にAWSからメールがいくつか飛んでくるので対応していきます。まずはマスターアカウント宛にアドレス検証のメールが来ます。「Verify your email address」ボタンに設定されているリンクを、マスターアカウントにログイン済みのブラウザで開きましょう。 ブラウザ上に以下の内容が表示されれば設定は完了です。 続いてマスターアカウント宛にAWS SSO（Single Sign-On）のメールが飛んできます。Control Towerでは自動でAWS SSOが有効になるので、このタイミングでアカウントの設定を行います。メール内の「Accept invitation」リンクに設定されているURLをブラウザで開きましょう。ちなみに、こちらはまだAWSコンソールにログインしていないブラウザを使用してください。 以下のサインアップ画面が開くので、SSOユーザのパスワードを設定します。 続いて監査アカウントとログアーカイブアカウントのアドレスに以下のメールが届きます。こちらはAWSアカウントが無事作成された旨のメールなので、特に何もする必要はありません。 最後に監査アカウントへSNSの案内が来ます。Control Towerでは、ガードレール違反等のセキュリティに関するアラートはこのSNS経由で配信されます。メール内の「Confirm subscription」をクリックすると以下の画面が表示され、SNSのサブスクリプションが有効になります。 AWSコンソールでControl Towerを見てみましょう。以下の画面が出れば設定は全て完了です。お疲れ様でした。 さいごに 今回はContorol Towerの環境構築方法を紹介しました。次回はAccount Factoryによるメンバーアカウントの追加方法などについても記載してみたいと思います。 この記事が誰かのお役に立てると幸いです。

柔軟性のある認証フローを作成できる Cognitoを触ってみて、最初は色々不便だなあと思っていました。 しかし、ちゃんとドキュメントを読んでいくうちに、拡張性が高く、結構柔軟な実装が可能だと気づきます。 その柔軟性を担保してくれいている仕組みの一つが「カスタム認証チャレンジ」です。 https://docs.aws.amazon.com/ja_jp/cognito/latest/developerguide/user-pool-lambda-challenge.html より引用 何が便利なのか ログイン方法を複数指定することができます。 一般的な認証方法の１つにユーザ名とパスワードを入力するパスワード認証があります。 例えば、カスタム認証フローを使えば、あるロールのユーザにはパスワード認証を、あるロールのユーザにはトークン認証を使うなど、相手によって認証方法を変えることができます。 また、パスワード認証の前後にMFAを設定したり、合言葉認証を複数設定することも実装できます。 どうやって実装するのか Lambdaを使って認証を定義していきます。 上記の図のように３つのトリガーがあり、そのトリガーごとにLambdaを設置します。 各Lambdaの役割 Define Auth Challenge ここでは、次にユーザに要求するチャレンジを選択し、認証するかどうかを決めます。 レスポンスを return する際、レスポンスの中に challengeName の値を以下の CUSTOM_CHALLENGE、SRP_A、PASSWORD_VERIFIER、SMS_MFA, DEVICE_SRP_AUTH、DEVICE_PASSWORD_VERIFIER、ADMIN_NO_SRP_AUTH のうち、いずれかを指定します。 return されたchallengeName に指定されたチャレンジをユーザに要求します。 ユーザは respond-to-auth-challenge APIなどを使って、そのチャレンジに答えます。 CUSTOM_CHALLENGE以外のチャレンジは、ユーザからの答えをCognitoが内部的に処理をし、 Define Auth Challenge を再度呼び出します。 returnされたchallengeNameにCUSTOM_CHALLENGEが返されると次のラムダ関数である Create Auth Challenge を呼び出します。 ユーザがこの Create Auth Challenge からのチャレンジに応え Verify Auth Challenge が呼び出された後、再度この Define Auth Challenge が呼び出されます。 Create Auth Challenge ここでは、ユーザに独自のチャレンジを返します。 例えば、ユーザに特定の数字「100」を返し、ユーザからその2倍の数が送られてきたらチャレンジをクリアしたと判定させることもできます。 それを実装する場合、この関数ですることは、 ユーザに「100」を返し、答えとする値「200」を保存することだけです。 ユーザから返ってきた値が望む値かどうかを判定するのは次のラムダ関数の役割です。 Verify Auth Challenge ここではユーザから返されたチャレンジに対する答えを処理し、チャレンジが通過したかどうかを判定します。 レスポンス中の answerCorrect を true にして return することで、このCUSTOM_CHALLENGEが通過したかどうかを Define Auth Challenge に返します。 よくわかんない！ と思う方は多いと思います。 私も複雑怪奇な公式の日本語ドキュメントを読んで、最初はそういう感想がでました。 とりあえずコードを見た方がイメージがつきやすいと思うので、ひとまずコードをば。 コード 「アプリでJWTを発行し、それをCognitoに投げたユーザを認証する」という場合を考えてみます。 注意： ここではJWTシークレットをパラメーターストアに保存してそれを取得するようにしています。 JWTについてよくわからない方は別途調べてください。 jsonwebtokenが必要なので、レイヤーを作る必要があります。 https://zenn.dev/nekoniki/articles/6a30b75da0fac5 がわかりやすいです。 簡易的な実装なので、実際に実装をする場合にはJWTの検証をより適切に行う必要があります。 AWS CLI, SAM CLI が必要です。 define_auth_challenge.js exports.handler = async (event, context, callback) => { console.log(context); console.log(event); if (event.request.session.length > 0 && event.request.session[event.request.session.length - 1].challengeResult){ event.response.issueTokens = true; event.response.failAuthentication = false; } else { event.response.issueTokens = false; event.response.failAuthentication = false; event.response.challengeName = 'CUSTOM_CHALLENGE'; } callback(null, event); }; create_auth_challenge.js exports.handler = (event, context, callback) => { console.log(event); event.response.publicChallengeParameters = {}; event.response.publicChallengeParameters.NEXT_ACTION = 'respond-to-auth-challenge'; callback(null, event); } verify_auth_challenge.js const jwt = require('jsonwebtoken'); const ssm = new (require('aws-sdk/clients/ssm'))(); const env = process.env['ENV']; exports.handler = async (event, context, callback) => { console.log(event); const token = event.request?.challengeAnswer if (verifyJwt(token)) { event.response.answerCorrect = true; } else { event.response.answerCorrect = false; } callback(null, event); }; const verifyJwt = async function(token){ const ssmData = await ssm.getParameter({ Name: `/${env}/secure/JWT_SECRET`, WithDecryption: true }).promise(); const jwtSecret = ssmData.Parameter.Value; return jwt.verify(token, jwtSecret, (err, decoded) => { if (err) { throw new Error("This JWT token was invalid."); } else { console.log("verifyJwt() was successful."); return true; } }); }; template.yml AWSTemplateFormatVersion: '2010-09-09' Transform: 'AWS::Serverless-2016-10-31' Description: Custom auth sample Parameters: Env: Type: String AllowedValues: - prod - stg - dev Layer: Description: ARN of Lambda Layer which has jwt package Type: String Resources: DefineAuthCallengeLambda: Type: 'AWS::Serverless::Function' Properties: Handler: define_auth_challenge.handler Runtime: nodejs14.x FunctionName: define-auth-challenge CodeUri: ./define_auth_challenge.js Description: '' MemorySize: 128 Timeout: 10 Role: !GetAtt DefineAuthChallengeRole.Arn Environment: Variables: ENV: !Ref Env CreateAuthChallengeLambda: Type: 'AWS::Serverless::Function' Properties: Handler: create_auth_challenge.handler Runtime: nodejs14.x FunctionName: create-auth-challenge CodeUri: ./create_auth_challenge.js Description: '' MemorySize: 128 Timeout: 10 Role: !GetAtt CreateAuthChallengeRole.Arn Environment: Variables: ENV: !Ref Env VerifyAuthChallengeLambda: Type: 'AWS::Serverless::Function' Properties: Handler: verify_auth_challenge.handler Runtime: nodejs14.x FunctionName: verify-auth-challenge CodeUri: ./verify_auth_challenge.js Description: '' MemorySize: 128 Timeout: 30 Role: !GetAtt VerifyAuthChallengeRole.Arn Layers: - !Sub ${Layer} Environment: Variables: ENV: !Ref Env DefineAuthChallengeRole: Type: AWS::IAM::Role Properties: RoleName: define-auth-challenge-role AssumeRolePolicyDocument: Version: "2012-10-17" Statement: - Effect: "Allow" Action: "sts:AssumeRole" Principal: Service: lambda.amazonaws.com Policies: - PolicyName: define-auth-challenge-policy PolicyDocument: Version: "2012-10-17" Statement: - Effect: "Allow" Action: - "logs:CreateLogGroup" Resource: !Sub "arn:aws:logs:${AWS::Region}:${AWS::AccountId}:*" - Effect: "Allow" Action: - "logs:CreateLogStream" - "logs:PutLogEvents" Resource: !Sub "arn:aws:logs:${AWS::Region}:${AWS::AccountId}:log-group:/aws/lambda/define-auth-challenge:*" CreateAuthChallengeRole: Type: AWS::IAM::Role Properties: RoleName: create-auth-challenge-role AssumeRolePolicyDocument: Version: "2012-10-17" Statement: - Effect: "Allow" Action: "sts:AssumeRole" Principal: Service: lambda.amazonaws.com Policies: - PolicyName: create-auth-challenge-policy PolicyDocument: Version: "2012-10-17" Statement: - Effect: "Allow" Action: - "logs:CreateLogGroup" Resource: !Sub "arn:aws:logs:${AWS::Region}:${AWS::AccountId}:*" - Effect: "Allow" Action: - "logs:CreateLogStream" - "logs:PutLogEvents" Resource: !Sub "arn:aws:logs:${AWS::Region}:${AWS::AccountId}:log-group:/aws/lambda/create-auth-challenge:*" VerifyAuthChallengeRole: Type: AWS::IAM::Role Properties: RoleName: verify-auth-challenge-role AssumeRolePolicyDocument: Version: "2012-10-17" Statement: - Effect: "Allow" Action: "sts:AssumeRole" Principal: Service: lambda.amazonaws.com Policies: - PolicyName: verify-auth-challenge-policy PolicyDocument: Version: "2012-10-17" Statement: - Effect: "Allow" Action: - "logs:CreateLogGroup" Resource: !Sub "arn:aws:logs:${AWS::Region}:${AWS::AccountId}:*" - Effect: "Allow" Action: - "logs:CreateLogStream" - "logs:PutLogEvents" Resource: !Sub "arn:aws:logs:${AWS::Region}:${AWS::AccountId}:log-group:/aws/lambda/verify-auth-challenge:*" - Effect: "Allow" Action: - "ssm:GetParameter" Resource: !Sub "arn:aws:ssm:${AWS::Region}:${AWS::AccountId}:parameter/${Env}/secure/JWT_SECRET" デプロイしてみよう 上記のファイルを全て同じディレクトリに置いた状態でデプロイします。 SAMのデプロイコマンド例(SAM CLIのインストールが必要) sam deploy --region ap-northeast-1 --capabilities CAPABILITY_NAMED_IAM \ --stack-name lambda-custom-auth --s3-bucket templateを保存するS3バケット名 \ --parameter-overrides Env=dev Layer=レイヤーのARN --s3-prefix custom-auth 動作確認をしよう initiate-auth がログインのためのAPIとなります。 ここの --auth-flow を CUSTOM_AUTH とすることで カスタム認証チャレンジ を開始できます。 (--auth-flow を USER_PASSWORD_AUTH とすると、一般的なパスワード認証で認証させることができます) このコマンドを打つと aws cognito-idp initiate-auth --auth-flow CUSTOM_AUTH \ --auth-parameters "USERNAME=+81000000000" --client-id クライアントID 以下のように { "ChallengeName": "CUSTOM_CHALLENGE", "Session": "session情報", "ChallengeParameters": { "NEXT_ACTION": "respond-to-auth-challenge", "USERNAME": "uuid" } } こんな値が返ってくるので、Sessionの値を用いて、 aws cognito-idp respond-to-auth-challenge --client-id クライアントID --challenge-name CUSTOM_CHALLENGE \ --challenge-responses USERNAME=+81000000000,ANSWER=ここにJWTを入力 --session "session情報" 上記のようにJWTを送ってあげます。 { "ChallengeParameters": {}, "AuthenticationResult": { "AccessToken": "アクセストークン", "ExpiresIn": 86400, "TokenType": "Bearer",, こんな感じでアクセストークンが返ってきたら成功です！！ 当然ですが、JWT生成時と、Lambdaで同じJWT_SECRETを利用していなかったり、JWTの期限が切れていると認証は失敗します。 参考

キャッシュ期間がわかりにくい なので、ただ図にしただけの味のしない記事です。 （間違えがあればご指摘いただけると嬉しいです!） CloudFront キャッシュ期間 参考

buildspec.yaml シーケンス 説明 version: buildspec のバージョン（必須） run-as: コマンドを実行するLinuxユーザ env: 環境変数 proxy: プロキシサーバ設定 batch: バッチビルド設定 phases: 実行するコマンド（必須） reports: テストレポート出力 artifacts: AWS CodeBuildの出力 cache: キャッシュ設定 version: 0.2 run-as: Linux-user-name env: shell: shell-tag variables: key: "value" key: "value" parameter-store: key: "value" key: "value" exported-variables: - variable - variable secrets-manager: key: secret-id:json-key:version-stage:version-id git-credential-helper: no | yes proxy: upload-artifacts: no | yes logs: no | yes batch: fast-fail: false | true # build-list: # build-matrix: # build-graph: phases: install: run-as: Linux-user-name on-failure: ABORT | CONTINUE runtime-versions: runtime: version runtime: version commands: - command - command finally: - command - command pre_build: run-as: Linux-user-name on-failure: ABORT | CONTINUE commands: - command - command finally: - command - command build: run-as: Linux-user-name on-failure: ABORT | CONTINUE commands: - command - command finally: - command - command post_build: run-as: Linux-user-name on-failure: ABORT | CONTINUE commands: - command - command finally: - command - command reports: report-group-name-or-arn: files: - location - location base-directory: location discard-paths: no | yes file-format: report-format artifacts: files: - location - location name: artifact-name discard-paths: no | yes base-directory: location exclude-paths: excluded paths enable-symlinks: no | yes s3-prefix: prefix secondary-artifacts: artifactIdentifier: files: - location - location name: secondary-artifact-name discard-paths: no | yes base-directory: location artifactIdentifier: files: - location - location discard-paths: no | yes base-directory: location cache: paths: - path - path version 0.2 を使う。 run-as Linux環境のみ指定可能。 指定しない場合、全てのコマンドがrootユーザーで実行される。 Phasesブロックでオーバーライド可能。 env 環境変数 プレーンテキスト parameter-store secrets-manager 環境シェル Linux：bash、/bin/sh Windows：powershell.exe、cmd.exe proxy 明示的なプロキシサーバーでビルドし、アーティファクトのアップロード時、CloudWatch logsを作成する時にプロキシサーバーを利用するか指定可能。 upload-artifacts logs batch プロジェクトの同時実行と協調実行の定義実行を行う。 fast-fail build-graph バッチ内の他のタスクに依存する一連のタスクを定義する。 batch: fast-fail: false build-graph: - identifier: build1 env: variables: BUILD_ID: build1 ignore-failure: false - identifier: build2 buildspec: build2.yml env: variables: BUILD_ID: build2 depend-on: - build1 - identifier: build3 env: variables: BUILD_ID: build3 depend-on: - build2 build1 は依存関係がないため、最初に実行されます。 build2 に依存しているbuild1、build2 実行後 build1 を完了します。 build3 に依存しているbuild2、build3 実行後 build2 を完了します。 build-list 並行して実行されるタスクの数を定義するために使用される。 batch: fast-fail: false build-list: - identifier: build1 env: variables: BUILD_ID: build1 ignore-failure: false - identifier: build2 buildspec: build2.yml env: variables: BUILD_ID: build2 ignore-failure: true build1 と build1 が並行して実行される。 build-matrix 並行して実行される異なる構成のタスクを定義する。 batch: build-matrix: static: ignore-failure: false env: type: LINUX_CONTAINER image: aws/codebuild/amazonlinux2-x86_64-standard:3.0 privileged-mode: true dynamic: buildspec: - matrix1.yml - matrix2.yml env: variables: MY_VAR: - VALUE1 - VALUE2 - VALUE3 上記の例では、matrix1/matrix2 * VALUE1/VALUE2/VALUE3 の計6つのビルドが並行して実行される。 phase ビルドの各段階で実行するコマンドを記述する。 inastall:パッケージにインストールのみに利用することを推奨。runtime_versionsでランタイムを指定可能。 pre_build：ビルド前に実行されるコマンドを記述。(例：ECRへのサインイン) build:ビルドで実行するコマンドを記述。 post_build:ビルド後に実行するコマンドを記述。（ECRへのpush） reports CodeBuildのジョブから出力されたレポートファイルを解析し、テスト実行結果を確認するためのビューを提供する機能。 artifacts アーティファクトの名、アーティファクトに含めるサブディレクトリとファイルを指定。 secondary-artifactsを利用して、複数のビルド出力アーティファクトを指定することも可能。 cache CodeBuildがビルドを使うときのキャッシュを定義する。 キャッシュタイプはビルドプロジェクトに対して設定。※S3とローカルのカスタムキャッシュはbuildspec.yamlで指定する。 キャッシュなし。 S3 ローカル（ソースキャッシュ、Dockerレイヤーキャッシュ、カスタムキャッシュ） 機能 AWS CodeBuild エージェントを使用して、ローカルマシンで CodeBuild ビルドを実行してテストすることが可能。 セッションマネージャーで実行中のビルドを表示することが可能。