AWS DeepRacerにカジュアル参加してみましたので、備忘録です。 （なぜかQiitaに画像をアップロードできず、テキストのみ記載します。） AWS DeepRacerについて 以下を参照してください AWS DeepRacer The fastest way to get rolling with machine learning Welcome to the world’s first global autonomous racing league, open to anyone. It’s time to race for prizes, glory, and a chance to advance to the AWS DeepRacer Championship at re:Invent 2020. 2021 Virtual Circuit関連のURLは以下です。 Welcome to the 2021 Virtual Circuit AWS-DeepRacer-Innovate-Challenge Train&Evaluate AWS DeepRacer Page AWS Summit Online, AWS DeepRacer リーグ カジュアル参加のやりかた 上記ページのgetStartedを押すだけです。 getStarted 以下３ステップで進めていきます。 Step 1: Learn the basics of reinforcement learning (Optional / ~10 mins) Step 2: Create a model and race (Required / ~1 hour) Step 3: Learn about sensors and new types of racing 上記のStep 1とStep 3はチュートリアルとその他の案内のようで、レースはStep 2を選択すると準備を始められます。 Step 2: Create a model and race (Required / ~1 hour)では、以下の３ステップがあります。 Step 1 Specify the model name and environment Step 2 Choose training type, training algorithm and agent Step 3 Customize reward function まずモデルの名前と環境を決めます。 モデルの名前はseigotなど何でもOKのようです。 コースは、2021,Mayの時点で競技コースになっているKuei Racewayを選択しました。 また、1hour 3.5ドル掛かるようでした。（初心者は10hoursのfree枠を使えるらしい。詳しくは元URLを参照） 色々とGUIからカジュアルに設定してきます。今回は以下を設定しました。（ほぼデフォルト） - Value 範囲 Race Type Time Trial Time Trial or Object avoidance or Head-to-head racing Training algorithm PPO PPO or SAC Speed(速度の種類　) { 0.33, 0.67, 1 } m/s 固定？ Steering angle (ステアリング角の種類) { -30, 0, 30 } ° 固定？ 機械学習フレームワーク Tensor-flow 固定？ PPOとSACについては以下 PPO A state-of-the-art policy gradient algorithm which uses two neural networks during training – a policy network and a value network. SAC Not limiting itself to seeking only the maximum of lifetime rewards, this algorithm embraces exploration, incentivizing entropy in its pursuit of optimal policy. ハイパーパラメータは以下を設定します。（ほぼデフォルト） - Value 範囲 Gradient descent batch size 64 32,64,128,256,512 Entropy 0.01 Real number between 0 and 1. Discount factor 0.999 Real number between 0 and 1. Loss type Huber Mean squared error or Huber Learning rate 0.0003 Real number between 0.00000001 (1e-8) and 0.001 (1e-3). Number of experience episodes between each policy-updating iteration 20 Integer between 5 and 100. Number of epochs 10 Integer between 3 and 10. 報酬関数も設定します。 報酬関数は、関数内をpythonで記述します。 設定後は処理が開始します。 initializeに6minほど掛かるようです。 InProgress状態になり学習が始まります。 その後、設定した学習時間（今回は60min）後にトレーニングが終わるようなので、しばらく待ちます。 60min後、学習が終わり停止処理が働きました。停止処理は4min程掛かるようです。 自動submitもしっかり発動していそうです。 無事に自動submitされました。 evaluationをして正しく動いたらモデル作成は一旦成功と思われます。 Open Divisionが、evaluatingになっています。 しばらくすると、evaluateが終わり、無事に105位/161人中の順位になりました、、、！ Open Division --> Pro Division --> Pro Division Finale の順にレベルアップするようです。 機会があれば上位レベルに挑戦したいと思います。 参考 AWS DeepRacer The fastest way to get rolling with machine learning Welcome to the 2021 Virtual Circuit, seigot! AWS-DeepRacer-Innovate-Challenge Train&Evaluate AWS DeepRacer Page AWS Summit Online, AWS DeepRacer リーグ

Macでも・・・Windowsでも・・・開発環境を構築できない場合、Cloud9しかないかなあ〜と思ったのでやってみました。 ミドルウェア達は手動で入れます。 マシンスペック Mac mini 2018 macOS Catalina（10.15.x） Intel Core-i7 3.2GHz 6コア メモリ 32GB SSD 512GB Laravel環境 Nginx 最新版 PHP（PHP-FPM） 7.2.x MySQL 5.7 Composer 最新版 Laravel 5.6 やること Cloud9でLaravel環境構築 ミドルウェア達は手動構築 AWS Cloud9の準備 下記を参考に準備する。 【コピペ】AWS Cloud9+Docker ComposeでLaravel環境を構築その壱#AWS Cloud9の準備 ミドルウェアなどの準備 PHPインストール PHPはインストール済み。 $ php -v PHP 7.2.24 (cli) (built: Oct 31 2019 18:27:08) ( NTS ) Copyright (c) 1997-2018 The PHP Group Zend Engine v3.2.0, Copyright (c) 1998-2018 Zend Technologies でも、Laravelを動かすライブラリが不足してるので、インストールし直す。 $ sudo yum -y install http://rpms.famillecollet.com/enterprise/remi-release-7.rpm $ sudo yum -y install --enablerepo=remi,remi-php72 php php-devel php-mbstring php-pdo php-gd php-xml php-pecl-mcrypt php-mysqlnd php-fpm php-pecl-zip php-bcmath ・・・ Complete! Nginxインストール $ sudo vi /etc/yum.repos.d/nginx.repo ★点線内をコピペ --- [nginx] name=nginx repo baseurl=http://nginx.org/packages/mainline/centos/7/$basearch/ enabled=0 gpgcheck=0 --- :wq $ sudo yum -y --enablerepo=nginx install nginx 設定ファイルの編集 PHP-FPM /etc/php-fpm.d/www.conf $ sudo vi /etc/php-fpm.d/www.conf ★下記を点線内に編集 user = apache group = apache listen = /run/php-fpm/www.sock ;listen.owner = nobody ;listen.group = nobody ;listen.mode = 0660 ↓ --- user = nginx group = nginx listen = /var/run/php-fpm/php-fpm.sock listen.owner = nginx listen.group = nginx listen.mode = 0660 --- :wq Nginx /etc/nginx/conf.d/default.conf $ sudo vi /etc/nginx/conf.d/default.conf ★全行を削除 :%d ★点線内をコピペ --- server { listen 8080; server_name laravel.cloud9; charset UTF-8; access_log /var/log/nginx/access.log; location / { root /home/ec2-user/environment/laravel/public; try_files $uri /index.php?$query_string; } #error_page 404 /404.html; # redirect server error pages to the static page /50x.html # error_page 500 502 503 504 /50x.html; location = /50x.html { root /usr/share/nginx/html; } location ~ \.php$ { root /home/ec2-user/environment/laravel/public; fastcgi_pass unix:/var/run/php-fpm/php-fpm.sock; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; include fastcgi_params; } } --- :wq 起動および自動起動設定 $ sudo systemctl start php-fpm $ sudo systemctl enable php-fpm Created symlink from /etc/systemd/system/multi-user.target.wants/php-fpm.service to /usr/lib/systemd/system/php-fpm.service. $ sudo systemctl start nginx $ sudo systemctl enable nginx Created symlink from /etc/systemd/system/multi-user.target.wants/nginx.service to /usr/lib/systemd/system/nginx.service. Nginxが/home/ec2-user配下を実行できるようにする $ chmod 701 /home/ec2-user MySQLインストール MariaDBのアンインストール $ rpm -qa | grep aria mariadb-common-10.2.36-1.amzn2.0.1.x86_64 mariadb-config-10.2.36-1.amzn2.0.1.x86_64 mariadb-libs-10.2.36-1.amzn2.0.1.x86_64 mariadb-10.2.36-1.amzn2.0.1.x86_64 $ sudo yum -y remove mariadb* $ sudo rm -rf /var/lib/mysql MySQLインストール $ sudo rpm -Uvh https://repo.mysql.com/yum/mysql-5.7-community/el/7/x86_64/mysql57-community-release-el7-10.noarch.rpm $ sudo yum -y install --enablerepo=mysql57-community mysql-community-server $ mysqld --version mysqld Ver 5.7.30 for Linux on x86_64 (MySQL Community Server (GPL)) $ sudo systemctl enable mysqld.service $ sudo systemctl start mysqld.service $ sudo grep 'temporary password' /var/log/mysqld.log 2020-06-14T11:56:34.296676Z 1 [Note] A temporary password is generated for root@localhost: XXXXXX $ sudo mysql_secure_installation Enter password for user root: XXXXXX ★パスワードは「英字小文字、英字大文字、数字、記号」の組み合わせにしたら通る 例）cloud9#CLOUD9 New password: cloud9#CLOUD9 Re-enter new password: cloud9#CLOUD9 〜 以降の質問は全て y で回答し、パスワード聞かれたら上記パスワードを入力する 〜 All done! データベース作成など $ mysql -u root -p Enter password: cloud9#CLOUD9 ★DB：hoge、USER：fuga、PASSWORD：cloud9#CLOUD9（※好きなのに変える） mysql> create database hoge default character set utf8 collate utf8_general_ci; mysql> CREATE USER fuga@'%' IDENTIFIED BY 'cloud9#CLOUD9'; mysql> GRANT ALL ON hoge.* TO fuga@'%'; mysql> CREATE USER fuga@'localhost' IDENTIFIED BY 'cloud9#CLOUD9'; mysql> GRANT ALL ON hoge.* TO fuga@'localhost'; mysql> FLUSH PRIVILEGES; mysql> quit Composerインストール $ curl https://getcomposer.org/installer | php $ sudo mv -i composer.phar /usr/local/bin/composer $ composer -v ______ / ____/___ ____ ___ ____ ____ ________ _____ / / / __ \/ __ `__ \/ __ \/ __ \/ ___/ _ \/ ___/ / /___/ /_/ / / / / / / /_/ / /_/ (__ ) __/ / \____/\____/_/ /_/ /_/ .___/\____/____/\___/_/ /_/ Composer version 2.0.13 2021-04-27 13:11:08 ・・・ Laravelインストール プロジェクト作成 $ composer create-project --prefer-dist laravel/laravel laravel "5.6.*" パッケージ追加とパーミッション変更 $ cd laravel $ composer require --dev barryvdh/laravel-ide-helper $ composer require --dev squizlabs/php_codesniffer $ chmod -R 777 storage $ chmod -R 777 bootstrap/cache データベース接続設定 .env $ vi .env ★下記を点線内に編集 DB_DATABASE=homestead DB_USERNAME=homestead DB_PASSWORD=secret ↓ --- DB_DATABASE=hoge DB_USERNAME=fuga DB_PASSWORD=cloud9#CLOUD9 --- :wq マイグレーション＆シーダー実行 $ php artisan migrate:fresh --seed キャッシュとか色々クリアするシェル作成＆実行 bin/clear-laravel.sh $ mkdir bin $ vi bin/clear-laravel.sh ★下記を点線内をコピペ --- #!/bin/bash php artisan view:clear php artisan cache:clear php artisan config:clear php artisan route:clear php artisan clear-compiled php artisan config:cache composer dump-autoload php artisan ide-helper:generate php artisan ide-helper:models -N php artisan ide-helper:meta --- :wq $ chmod 755 bin/clear-laravel.sh $ bin/clear-laravel.sh ブラウザで動作確認 「Preview」 → 「Preview Running Application」を選択する。 ブラウザを別タブで開く。 下記ページが表示されればOK。

目的 APIを叩いてきたユーザー名によって変えたいということがありました。 そこで、Cognitoでオーソライズを行っているLambda関数にて、API Gatewayの認証情報をLambda(Golang)の中で取得する方法を調べました。 結論 以下のコードでユーザー名を取得できます。 func handler(ctx context.Context, apiGWEvent events.APIGatewayProxyRequest) (events.APIGatewayProxyResponse, error) { ユーザー名取得 diaryGetter := apiGWEvent.RequestContext.Authorizer["claims"].(map[string]interface{})["cognito:username"].(string) /// ...略 } 割と途中のコードとかが謎ですので、以下に解説を載せておきます。(これより単純に取得できる方法がありましたらご教授いただけると幸いです。) 解説 (前提として、LambdaのオーソライザーにCognitoのユーザープールが設定されていることを確認) まず、events.APIGatewayProxyRequestにはどのようなhttpリクエストを受け取ったのかが格納されます。 ドキュメントを参照すると、 type APIGatewayProxyRequest struct { Resource string `json:"resource"` // The resource path defined in API Gateway Path string `json:"path"` // The url path for the caller HTTPMethod string `json:"httpMethod"` Headers map[string]string `json:"headers"` MultiValueHeaders map[string][]string `json:"multiValueHeaders"` QueryStringParameters map[string]string `json:"queryStringParameters"` MultiValueQueryStringParameters map[string][]string `json:"multiValueQueryStringParameters"` PathParameters map[string]string `json:"pathParameters"` StageVariables map[string]string `json:"stageVariables"` RequestContext APIGatewayProxyRequestContext `json:"requestContext"` Body string `json:"body"` IsBase64Encoded bool `json:"isBase64Encoded,omitempty"` } となっております。 参考:GoDoc package aws/aws-lambda-go/events 参考:AWS Lambda+API Gateway+DynamoDBでCRUD APIを作るのをGolangでやってみた こちらの、RequestContext構造体には、Authorizer情報がmap[string]interface{}型で入っています。 僕が作成したアプリのdev環境用のCognitoの情報を取得してみると、以下の様になっています。 map[claims:map[aud:tekitoutekitou auth_time:12345678 cognito:username:テスト太郎 event_id:tekitou-d37c-41c9-be67-tekitou exp:Tue May 11 14:18:46 UTC 2021 iat:Tue May 11 13:18:46 UTC 2021 iss:https://cognito-idp.ap-northeast-1.amazonaws.com/ap-northeast-tekitou sub:tekitou-c7e9-4649-ab16-tekitou token_use:id]] こちらから、claimsキーの中の、cognito:usernameキーがユーザーネームであることがわかります。 最初この構造を見たとき、 diaryGetter := apiGWEvent.RequestContext.Authorizer["claims"]["cognito:username"] みたいな感じでとれるんじゃないの？ と思ったのですが、これをやろうとすると、 invalid operation: cannot index apiGWEvent.RequestContext.Authorizer["claims"] (map index expression of type interface{}) となってしまいます。 interface型の知識が欠如しておりました。 どんな型の値でも受け取れるinterface{}ですが、interface{}型の引数で受け渡された値は、元の型の情報が欠落しています。 （元の型の値を操作するための関数等を実行できません） 引用:https://blog.y-yuki.net/entry/2017/05/08/000000 元の型の値を操作できないため、辞書型のキーを取り出すという動作ができないっぽいです。 なので、型アサーションをして、取り出す必要がありました。さらにこのdiaryGetterはstring型として扱いたいので、最後も型アサーションをする必要があったということです。 まず、 apiGWEvent.RequestContext.Authorizer["claims"] を型アサーションでmap[string]interface{}型にして、mapのキーを取り出すという感じです。

Chapters ?introduction: Web アプリ開発初心者、Django 触る ?Error 　? #01: AWS Cloud9のプレビューが上手く表示されない Windows プロジェクトを行った後に Mac でも動かしてみようと考えた。 エラー内容 $ python manage.py startapp hoge と入力してアプリケーションを作成した後に $ python manage.py runserver $IP:$PORT を入力してプレビューを見ようとしたらこんなエラーが。 VFS connection does not exist (直訳: VFSの接続が存在しない) ドユコト？ VFS とは仮想ファイルシステム（英: Virtual File System) わからんから調べてみると、治し方を記事にしてくださってる方がいたので参考にさせていただきました! 答えはブラウザにあった...!! 記事を見ていると AWS Cloud9 は複数のブラウザでの動作をサポートしているのですが、SafariやFirefoxを用いると正常に動作しないことがユーザーによって報告されています。予期せぬエラーの原因となるので、もし他のブラウザをお使いの方は、Google Chromeに切り替えて開発を進めてください。 いやいやいやいや、そんなことで治るはずは... そう思いつつ Safari から Google Chrome に切り替えてみると...... うん、できちゃった いやこれで治るとは思わんやん。次からは Google Chrome で開発します。はい...以上です...... 参考記事 ?AWS Cloud9のプレビューが上手く表示されない時の対処法 - プログラミング入門ナビ

※本稿は記事：【初心者】AWSのlightsailでWordPressを導入するまでの続きとなるものです。 ※本稿では、LightsailのSSL証明書、Let’s Encryptの証明書有効期限が切れた場合の更新手順を示します。 ※ぜひ、こちらもご覧ください⇒【初心者】AWSのLightsailでIP固定化と独自ドメインの紐付けとSSL化 有効期限が切れた うん。知ってた。SSL証明書の有効期限が切れるって。だってメールが来てたから。 有効期限が切れそうなときに、届くメール タイトルがLet's Encrypt certificate expiration notice for domain "XXXXXX.info" というメールが、期限の切れる約20日前と約10日前の２通、From Let's Encrypt Expiry Bot <expiry@letsencrypt.org> で届いておりました。 （メールの文頭） Your certificate (or certificates) for the names listed below will expire in 10 days (on 11 May 21 09:39 +0000). Please make sure to renew your certificate before then, or visitors to your web site will encounter errors. （訳 by DeepL） 以下の名前に対するあなたの証明書（または複数の証明書）は、10日後（11 May 21 09:39 +0000）に期限切れとなります。それまでに証明書を更新しないと、あなたのウェブサイトにアクセスした際にエラーが発生します。 有効期限が切れる前後の比較 ちなみに... ↑ 有効期限が切れても、鍵マークは健全表示でした（これは知らなかった...切れたまま時間が経てばNGになるのだろうか...？） Let’s Encryptの有効期限を更新しよう ココから本題です。 手順はとても単純。 Lightsailのターミナルにアクセスし、下記のコマンドを実行するだけ terminal $ sudo /opt/bitnami/bncert-tool ちなみに、このコマンドは初めてLightsailでSSL化するときと同じコマンドです。 ですので、詳細はコチラを参照ください 以下、更新中のスクショと、初回SSL化の際とは異なる点を記します。 黄色★マークは、何かしらの入力を求められる部分です。 私の場合は、サブドメインも使っているので、Domain listには２つ入っています。 注目すべきは赤色★マークのWarningのところ。 Warning: A certificate for the list of domains you entered already exists. It will be used instead of generating a new one. （訳 by DeepL） 警告です。入力されたドメインのリストに対する証明書は、すでに存在しています。この証明書は新しい証明書を生成する代わりに使用されます。 要は、更新のことを言っているのでしょう。Enterを入力して進めてください。 テキスト入力するところは、最初の方のDomain listと、中盤のE-mail addressぐらいで、あとはEnterかYの入力です。 ちょっと寄り道：自動更新されない場合 気になるところは緑色★マークのところ Some errors occurred The configuration was applied, but some of the changes could not be applied. Find the details below. Creating Let's Encrypt certificate: Automatic renewal not working （訳 by DeepL） いくつかのエラーが発生しました。 設定を適用しましたが、一部の変更を適用できませんでした。 詳細は以下のとおりです。 Let's Encrypt証明書の作成。自動更新が機能しません 自動更新が上手く設定できなかったようです。 解決方法がココに載っていました。 Step １） 自身がApproach AかApproach Bかを調べる 以下のコマンドを実行しApproach Bだった場合は、次のステップへ（Approach Aならココを熟読ください） test ! -f "/opt/bitnami/common/bin/openssl" && echo "Approach A: Using system packages." || echo "Approach B: Self-contained installation." Step 2） ​httpd-vhosts.confに追記する （訳 by DeepL） アプローチ B: 自己完結型の Bitnami インストール。アプリケーションの httpd-vhosts.conf ファイルの VirtualHost ブロック内に、以下の設定を追加します。 ​Alias /.well-known/ "/opt/bitnami/apps/letsencrypt/.well-known/" ​<Directory "/opt/bitnami/apps/letsencrypt/.well-known"> ​Options +MultiViews ​AllowOverride None ​Require all granted ​</Directory> 対応後、もう一度$ sudo /opt/bitnami/bncert-toolを実行 無事にSuccessになりました。今後は自動更新されるはずなので、この記事（備忘録）を見直すこともないかな？ 更新の結果 ブラウザをリフレッシュしたら、ちゃんと有効期限が更新されていました。 参考サイト Learn About The Bitnami HTTPS Configuration Tool Connect To The Server Using SSH

まえがき 仕事でCloudwatch Logs上に出力したVPCフローログから必要な情報を抽出したい、という要望がありました。 S3のフローログを整理したことはありましたが、CWLではやったことなかったので個人的なメモ。 Cloudwatch logs insightsを使用します。 手順 まずquery-idを変数に格納。 開始時間、終了時間はそれぞれUNIXTIMEで指定します。 --query-stringでフィルタパターンを使用します。 詳しくはドキュメント参照。 ID取得 $ query_id=`aws logs start-query \ --log-group-name {Log_Group_Name} \ --start-time 1234567890 \ --end-time 1234567890 \ --query-string "fields @message | filter @message like /NODATA/" \ --output text` 取得したquery-idを使用して、出力結果を確認します。 jqで不要な情報（@ptrとか）は無くしました。 ID取得 $ aws logs get-query-results --query-id $query_id | jq -r '.results[] | .[] | select(.field == "@message") | .value' 実行結果 2 123456789123 eni-123456789abcdef - - - - - - - 1234567890 1234567890 - NODATA 2 unknown eni-123456789abcdef - - - - - - - 1234567890 1234567890 - NODATA 2 123456789123 eni-123456789abcdef - - - - - - - 1234567890 1234567890 - NODATA jqについて .results[] | .[] は不要じゃね？って感じですが、入れないとエラーになります。 もう少しキレイに書ける方法あれば教えてください。 エラー $ aws logs get-query-results --query-id $query_id | jq -r '.results[] | select(.field == "@message")' jq: error (at <stdin>:820): Cannot index array with string "field"

LambdaやDynamoDBを使ったサーバレスアーキテクチャを構築するうえでとても便利なIaaC（Infrastructure as a Code）ツールであるSAM（Serverless Application Model）を使って、Lambda Authorizerを使った認証付きAPIを作成したいと思います。 今回はトークンベースの認証とします。 SAMには、いくつかのテンプレートが用意されています。その中でも最もシンプルなhello-worldテンプレートからスタートしてみます。 sam init 上記のコマンドでプロジェクトの作成を開始します。 今回は、AWS Quick Start Templatesを選び、Zipでデプロイする方式で、ランタイムはnodejs14.x、使用するテンプレートはHello World Exampleとしました。 ちなみに、ここでとってくるSAMのtemplateは、以下のリポジトリからクローンされます。 https://github.com/aws/aws-sam-cli-app-templates 結果として、次のように表示されました。 ----------------------- Generating application: ----------------------- Name: authorizerDemo Runtime: nodejs14.x Dependency Manager: npm Application Template: hello-world Output Directory: . Next steps can be found in the README file at ./authorizerDemo/README.md これでアプリケーションを開発していくためのベースのテンプレートからスタートできます。 ちょっとディレクトリ構成をいじります。 src <- 新規追加 hello-world <- もともとあったソースをsrcディレクトリ以下に移動 auth <- 新規追加 authディレクトリに移動して、npm initします。 auth.jsを作成します。これがユーザの資格情報をチェックするコードになりますが、ここでは、簡単な例として、tokenに、mySecretという文字列が入っているとき、Allowとし、それ以外はDenyとするコードにします。 exports.lambdaHandler = async(event, context) => { const token = event.authorizationToken; // このAPIについて拒否したり許可したりしたいので、このAPIを指定するためのリソースARNを取得 const resource = event.methodArn; // tokenがmySecretであるならば、許可、そうでないなら拒否 if (token == 'mySecret') { console.log('allow'); return { principalId: token, policyDocument: { Version: "2012-10-17", Statement: [{ Action: "execute-api:Invoke", Effect: "Allow", Resource: resource, }, ], }, }; } else { console.log('deny') return { principalId: token, policyDocument: { Version: "2012-10-17", Statement: [{ Action: "execute-api:Invoke", Effect: "Deny", Resource: resource, }, ], }, }; } }; template.yamlを、次のように変更します。 myApiは、API Gatewayを定義します。ここで、Authorizerとして、authFunctionを指定しています。 authFunctionとして、前述のauth.jsが呼ばれます。 また、必須ではないのですが、StageNameをパラメタとして定義して、ほかで使いまわせるようにします。 Parameters: StageName: Type: "String" Default: "dev" Resources: myApi: Type: AWS::Serverless::Api Properties: StageName: !Ref StageName # 上で決めたStageNameを参照します Auth: DefaultAuthorizer: authFunction Authorizers: authFunction: FunctionArn: !GetAtt authFunction.Arn authFunction: Type: AWS::Serverless::Function Properties: CodeUri: src/auth/ Handler: auth.lambdaHandler Runtime: nodejs14.x 既存のHello-world関数に認証をつけたいと思いますので、以下のようにHello-world関数の定義で、LambdaAuthorizerを呼び出すように変更します。 HelloWorldFunction: Type: AWS::Serverless::Function Properties: CodeUri: src/hello-world/ Handler: app.lambdaHandler Runtime: nodejs14.x Events: HelloWorld: Type: Api Properties: RestApiId: !Ref myApi # <- ここで、Authorizerを呼ぶように設定しています Path: /hello Method: get Outputも設定しておきます。 HelloWorldApiのエンドポイントで、上記のmyApiのStageNameを参照するように書き換えています。 Outputs: ApiWithLambdaAuth: Description: "API Gateway endpoint URL" Value: !Sub "https://${ServerlessRestApi}.execute-api.${AWS::Region}.amazonaws.com/${StageName}/hello/" ここまでできたら、あとは、デプロイするだけです。 template.yamlが見えるパスで、以下のコマンドで、ビルドしてデプロイします。 sam build sam deploy --guided guidedの対話シェルでは、以下のように入力をしました。ここでsamconfig.tomlファイルを作成しているのですが、このファイルとtemplate.yamlファイルが見えているパスで、--guidedをつけずに、sam deployすると、自動的にtomlファイルを読み込んでデプロイしてくれるようになります。便利ですので、せっかくなので作成するようにしましょう。 　　　　Setting default arguments for 'sam deploy' ========================================= Stack Name [sam-app]: lambda-auth-demo AWS Region [ap-northeast-1]: #Shows you resources changes to be deployed and require a 'Y' to initiate deploy Confirm changes before deploy [y/N]: y #SAM needs permission to be able to create roles to connect to the resources in your template Allow SAM CLI IAM role creation [Y/n]: Y Save arguments to configuration file [Y/n]: Y SAM configuration file [samconfig.toml]: SAM configuration environment [default]: ところが、デプロイは途中でこけてしまいます。以下のエラーが出力されるのですが、何が起きているのでしょうか。 Error: Failed to create changeset for the stack: lambda-auth-demo, ex: Waiter ChangeSetCreateComplete failed: Waiter encountered a terminal failure state: For expression "Status" we matched expected path: "FAILED" Status: FAILED. Reason: Unresolved resource dependencies [ServerlessRestApi] in the Outputs block of the template Unresolved resource dependencies [ServerlessRestApi] in the Outputs block of the templateは、ServerlessRestApiというリソースが解決されません、ということなのですが、この、ServerlessRestApiというのは、API Gatewayをテンプレートのなかで明示的に指定しなかったときに、SAMによって暗黙的に生成されるAPI Gatewayのリソース名です。 もともとのテンプレートでは、API Gatewayのリソースを明示的に定義していないので、これが使えるのですが、いま、Authorizerを設定するために、API Gatewayのリソースを明示的に定義したので、使えなくなっています。 そこで、自分で定義したmyApiに変えてあげる必要があります。初めてデプロイしたときにはまったので、共有しておきます。 ただ、Outputsは、SAMが作成したエンドポイントを単に出力するだけなので、最悪なくても、動作に問題はないと思います。その場合は、自分でコンソール上でAPIゲートウェイを見に行くか、aws cloudformation --describe-stacksなどを用いてエンドポイントを確認します。 Outputs: ApiWithLambdaAuth: Description: "API Gateway endpoint URL" Value: !Sub "https://${myApi}.execute-api.${AWS::Region}.amazonaws.com/${StageName}/hello/" さて、これでデプロイできるはずです。やってみましょう。 -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Outputs -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Key ApiWithLambdaAuth Description API Gateway endpoint URL Value https://xxxxxxxxx.execute-api.ap-northeast-1.amazonaws.com/dev/hello/ -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Successfully created/updated stack - lambda-auth-demo in ap-northeast-1 成功したみたいです！ 動作確認をしてみましょう。 1.headerなし $ curl https://xxxxxxxxx.execute-api.ap-northeast-1.amazonaws.com/dev/hello/ {"message":"Unauthorized"} 2.不正なトークン $ curl https://xxxxxxxxx.execute-api.ap-northeast-1.amazonaws.com/dev/hello/ -H "Authorization: mySecrets" {"Message":"User is not authorized to access this resource with an explicit deny"} 3.正当なトークン $ curl https://xxxxxxxxx.execute-api.ap-northeast-1.amazonaws.com/dev/hello/ -H "Authorization: mySecret" {"message":"hello world"} 1では401(Unauthorized)、2では403(Forbidden)が返り、3で200(OK)が返ります。 これで期待通りに動作していることが確認できました。

ご挨拶 AWS SAAを取得してから約5カ月経過しました。 また実務でもAWSの運用的な知識が必要になってきたので真面目にAWS SOAの学習を開始しました。 今回はSOAの学習の中で身になったCloudWatchについて記事にします。 CloudWatchとは AWSリソースの状態を監視したりログを収集したりするモニタリングサービスです。 リソースの状態は視覚的に分かりやすくグラフで表示してくれます。 また、リソースに異常が発生した際にアラーム状態にすることができます。 Amazon SNSと組み合わせることでアラーム状態になったときにメール通知を行うことが可能になります。 私のプライベートアカウントでは月の料金が約5000円を超えた際にメール通知をしてくれる設定を行っています。 『AWS初学者向けハンズオン』 請求アラームの設定編 実際に使ってみる 今回はログの収集を行ってみようと思います。 収集するログはApacheのアクセスログにします。 環境 Ubuntu20.04 Apache2.4 設定の流れ 統合CloudWatchエージェントのインストール 収集するログの設定 IAMロールの作成&EC2へアタッチ 確認 1. 統合CloudWatchエージェントのインストール ※今回はCloudWatchがメインなのでEC2インスタンスの起動や設定は省かせてもらいます。 CloudWatchエージェントは以下のOSでサポートされています。 参考ドキュメント OSやバージョン、アーキテクチャを確認したら以下のコマンドを実行してください。 Ubuntu20.04 wget https://s3.ap-northeast-1.amazonaws.com/amazoncloudwatch-agent-ap-northeast-1/ubuntu/amd64/latest/amazon-cloudwatch-agent.deb sudo dpkg -i -E ./amazon-cloudwatch-agent.deb 2. 収集するログの設定 今回はウィザードをしようしてログ出力設定を行います。 以下のコマンドを実行してください。 Ubuntu20.04 sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-config-wizard 実行後、何を収集するか聞かれるウィザードが起動します。 質問の内容に回答していきます。 Ubuntu20.04 On which OS are you planning to use the agent? 1. linux 2. windows 3. darwin default choice: [1]: 1 Trying to fetch the default region based on ec2 metadata... Are you using EC2 or On-Premises hosts? 1. EC2 2. On-Premises default choice: [1]: 1 Which user are you planning to run the agent? 1. root 2. cwagent 3. others default choice: [1]: 1 Do you want to turn on StatsD daemon? 1. yes 2. no default choice: [1]: 2 Do you want to monitor metrics from CollectD? 1. yes 2. no default choice: [1]: 2 Do you want to monitor any host metrics? e.g. CPU, memory, etc. 1. yes 2. no default choice: [1]: 2 Do you have any existing CloudWatch Log Agent (http://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AgentReference.html) configuration file to import for migration? 1. yes 2. no default choice: [2]: 2 Do you want to monitor any log files? 1. yes 2. no default choice: [1]: 1 Log file path: /var/log/apache2/access.log Log group name: default choice: [access.log] Log stream name: default choice: [{instance_id}] Do you want to specify any additional log files to monitor? 1. yes 2. no default choice: [1]: 2 Saved config file to /opt/aws/amazon-cloudwatch-agent/bin/config.json successfully. Current config as follows: { "agent": { "run_as_user": "root" }, "logs": { "logs_collected": { "files": { "collect_list": [ { "file_path": "/var/log/apache2/access.log", "log_group_name": "access.log", "log_stream_name": "{instance_id}" } ] } } } } Please check the above content of the config. The config file is also located at /opt/aws/amazon-cloudwatch-agent/bin/config.json. Edit it manually if needed. Do you want to store the config in the SSM parameter store? 1. yes 2. no default choice: [1]: 1 What parameter store name do you want to use to store your config? (Use 'AmazonCloudWatch-' prefix if you use our managed AWS policy) default choice: [AmazonCloudWatch-linux] Trying to fetch the default region based on ec2 metadata... Which region do you want to store the config in the parameter store? default choice: [ap-northeast-1] Please provide credentials to upload the json config file to parameter store. AWS Access Key: アクセスキーを入力してください AWS Secret Key: シークレットアクセスキーを入力してください Successfully put config to parameter store AmazonCloudWatch-linux. Program exits now. 上から解説していきます。 On which OS are you planning to use the agent? こちらは使用しているOSについて聞いています。 今回はUbuntuですので1を選択します。 Trying to fetch the default region based on ec2 metadata... Are you using EC2 or On-Premises hosts? こちらはどこでホストしているか聞いています。 今回はEC2なので1を選択します。 Which user are you planning to run the agent? エージェントを実行するユーザについて聞かれています。 私はrootで実行するように1を選択しました。 Do you want to turn on StatsD daemon? カスタムアプリケーションからカスタムメトリクスを取得する際に使用するツールのようです。 今回は必要ないので2を選択しました。 参考ドキュメント Do you want to monitor metrics from CollectD? こちらも同じようにカスタムメトリクスを取得する際に使用するツールのようです。 今回は必要ないので2を選択しました。 参考ドキュメント Do you want to monitor any host metrics? e.g. CPU, memory, etc. こちらはメモリやCPUのメトリクスを取得するか聞かれています。 今回は必要ないので2を選択しました。 Do you have any existing CloudWatch Log Agent (http://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AgentReference.html) configuration file to import for migration? 既存のCloudWatch Log Agentの設定ファイルがあるか聞かれています。 無いので2を選択しました。 Do you want to monitor any log files? ここでようやくログに関する質問が来ました。 これはログを収集するか聞かれています。 収集するので1を選択しました。 Log file path: ログのパスを聞かれています。 Apacheのデフォルトのアクセスログは/etc/apache2/envvarsを確認するとexport APACHE_LOG_DIR=/var/log/apache2$SUFFIXのように記載されています。 なので/var/log/apache2/access.logと入力します。 Log group name: ログのグループネームについて聞かれています。 デフォルトのaccess.logでいいのでそのままエンターを押下します。 Log stream name: こちらはログストリームネームについて聞かれています。 デフォルトのinstance_idでいいのでそのままエンターを押下します。 Do you want to specify any additional log files to monitor? 他にも出力したいログはあるか聞かれています。 無いので2を選択しました。 Saved config file to /opt/aws/amazon-cloudwatch-agent/bin/config.json successfully. Current config as follows: ここでは出来上がった設定ファイルの確認が行われます。 Do you want to store the config in the SSM parameter store? ここではSSMパラメータストアに保存するか聞かれています。 保存するので1を選択します。 What parameter store name do you want to use to store your config? (Use 'AmazonCloudWatch-' prefix if you use our managed AWS policy) ここではパラメータストアの名前を聞かれています。 指定はないのでデフォルトのままエンターを押下します。 Which region do you want to store the config in the parameter store? パラメータストアのリージョンについて聞かれています。 東京リージョンを使用するのでap-northeast-1のままエンターを押下します。 Please provide credentials to upload the json config file to parameter store. パラメータストアにjsonをアップロードするための認証情報を聞かれています。 アクセスキーとシークレットアクセスキーを入力してください。 Successfully put config to parameter store AmazonCloudWatch-linux. Program exits now. こちらが出力されたら終了です。 AWS Systems Managerのパラメータストアで設定した内容で保存されていることが確認できます。 3. IAMロールの作成&EC2へアタッチ 参考ドキュメント IAMダッシュボードからIAMロールを作成します。 以下の画面の「ロールの作成」をクリックします。 「信頼されたエンティティの種類を選択」で「AWSサービス」を選択 「一般的なユースケース」でEC2を選択 選択したら「次のステップ:アクセス権限」をクリックします。 CloudWatchAgentServerPolicyとAmazonSSMManagedInstanceCoreをチェックします。 チェックしたら「次のステップ:タグ」をクリックします。 タグが必要な場合は設定してください。 設定ができたら、「次のステップ:確認」をクリックします。 ロール名は任意のものを入力してください。 分かりやすいものをお勧めします。 設定に問題が無いか確認出来たら「ロールの作成」をクリックします。 次はEC2ダッシュボードへ移動してIAMロールを設定するEC2インスタンスを選択してください。 選択したら「アクション」→「セキュリティ」→「IAMロールを変更」をクリックします。 クリックしたらIAMロールの部分で上記で作成したIAMロールを選択して「保存」をクリックします。 Systems Manager Run Commandを使用してCloudWatch エージェントを開始する 参考ドキュメント Systems Manager Run Commandへ移動します。 「コマンドを実行する」をクリックします。 「コマンドドキュメント」で「AmazonCloudWatch-ManageAgent」を選択します。 「ターゲット」でエージェントを起動するEC2インスタンスを選択します。 「コマンドのパラメータ」→「Action」で「configure」を選択します。 「Optional Configuration Source」で「ssm」を選択します。 「Optional Configuration Location」でパラメータストアに保存されたパラメータ名を入力します。 「Optional Restart」で「yes」を選択します。 最終的な画面は以下のようになると思います。 確認が完了したら「実行」をクリックします。 次の画面で以下の結果がでたら成功です。 4. 確認 CloudWatchのロググループにaccess.logが出力されていることが確認できました。 締めのご挨拶 今回はログの収集に関する設定を行ってみました。 AWSの公式ドキュメントを参照しながら簡単に設定することができました。 またAWS Systems Managerでパラメータの管理やエージェントの起動、インストールができることを知れたのは大きい収穫だと思います。

はじめに フロントエンド React + バックエンド Django REST Framework でアプリを作成したが、ローカル環境でしか動かすことができないので、AWS EC2 インスタンス上にデプロイして外部からもアクセスができるようにする。今回はフロントエンドである React アプリをデプロイすることとし、Web サーバーソフトウェアには、nginx を用いる。なお React アプリはすでに作成されており、コードは GitHub に push してあることを前提とする。React/Next.jsアプリケーションを作成し、AWS EC2を使って本番環境にデプロイするまでを参考にした。 EC2 インスタンスの作成 Amazon Linux 2 AMI (HVM), SSD Volume Type という無料利用枠対象のものを使用して作成した。OS は RHEL7 / CentOS7 をベースとしているらしい。セキュリティグループ設定で HTTP 設定の追加を忘れないこと。設定されていると、以下のようになっているはず。 その他インスタンス作成に関することはここでは割愛する。以下の作業はすべて作成した EC2 インスタンスに SSH 接続を行った状態での作業であるので注意。接続方法は SSH を使用した Linux インスタンスへの接続を参照。 nginx のインストールおよびセットアップ 以下コマンドで nginx をインストールする。 $ yum update -y $ sudo amazon-linux-extras install nginx1 以下コマンドで、nginx の自動起動設定を行い、起動する。 $ sudo systemctl enable nginx # 自動起動設定 $ sudo systemctl start nginx.service # 起動 この状態で、EC2 インスタンスの「パブリック IPv4 アドレス」または「パブリック IPv4 DNS」にアクセスして、問題なく接続できることを確認する。 次に、/etc/nginx/nginx.conf（一部抜粋）に以下を追記する。 /etc/nginx/nginx.conf http { ... server { ... location / { proxy_pass http://localhost:3000; } ... } } 上記でリバースプロキシの設定ができたので、このインスタンスに対するリクエストは localhost:3000 へ転送される。 設定を反映させるために、一度 ngnx を再起動しておく。 $ sudo systemctl restart nginx React アプリの起動 GitHub に push されているアプリをクローンして起動する。まず git をインストールして、レポジトリをクローンする。 $ sudo yum -y install git $ git clone https://github.com/<your repository> React アプリが動作する環境を作成するため、パッケージ管理ツールである npm をインストールする。（以下コマンドは Node.js をインストールしているが、合わせて npm もインストールされる。）インストール方法の詳細はNode.js Binary Distributions を参照。 $ sudo su - root # curl -fsSL https://rpm.nodesource.com/setup_16.x | bash - # yum install -y nodejs アプリをビルドして、起動する。 $ cd <your repository> $ npm install # package.json に記載されたパッケージを一括インストール $ npm run build # ビルド実行 $ npm run start 再度　EC2 インスタンスに接続すると、アプリが表示されていることが確認できる。 おわりに フロントエンドのアプリを EC2 上にデプロイした。バックエンド側も合わせてデプロイしたい。

ググってもすぐ見つからなくて難儀したのでここに残します。 remove_attribute.py import boto3 dynamodb = boto3.resource('dynamodb') my_table = dynamodb.Table('MyTable') partition_key = 'hoge' sort_key = 123 # 項目の取得 result = my_table.get_item( Key= { 'pk': partition_key, 'sk': sort_key } ) print(result['Item']) # 項目から属性の削除 my_table.update_item( Key= { 'pk': partition_key, 'sk': sort_key }, UpdateExpression='remove foo' ) # 項目の再取得 result = my_table.get_item( Key= { 'pk': partition_key, 'sk': sort_key } ) print(result['Item']) $ python remove_attribute.py {'pk': 'hoge', 'sk': Decimal('123'), 'foo': 'bar'} {'pk': 'hoge', 'sk': Decimal('123')}

お疲れ様です。 先日、EC2インスタンスのパスワードがわからなくなってしまったので、その対処法です。 いつもはキーペアを作成して保存していたり、パスワードログインできるようにしていたりするんですが、 いつも、これをなくしたらどうしよう、と不安でした。 そんな時は、次の方法で解決できます。 インスタンスを作り直す 身も蓋もない解決策ですが、これが一番手っ取り早いです。 セッションマネージャーで接続する セッションマネージャーを使用すれば、SSHキー、踏み台ホストなしで、ブラウザ上でインスタンスに接続できます。 セッションマネージャーを使用するには、インスタンスにAmazonSSMManagedInstanceCoreの権限を持ったロールを割り当てる必要があるようです。 それが設定されていれば、以下の画面（EC2>インスタンス>接続）に接続ボタンが表示されます。 接続ボタンを押すと、以下の画面が立ち上がります。 コンソールと同じような操作感なので、違和感なく使えます。

最近AWSのリソースをterraformerで取り込むことが多く、その中でいくつかハマりどころがあったので手順をまとめる。 1. terraformerで取り込み 必要なリソースをterraformerで取り込む。 $ terraformer import aws --resources=hoge --profile=fuga --path-pattern ./ 2. state mvでresource名を管理しやすい名前に変更 terraformerが生成するresoure名は、既存のリソースのIDから生成したりしてわかりにくかったりするので、state mvで変更する。 全resourceにたいして行う（つらい） $ terraform state mv aws_s3_bucket.tfer--abcdefghijklmn aws_s3_bucket.fuga 3. 必要に応じてmodule化 既存のresoureをmoduleにして管理しやすくする。 もしくは既にmoduleがあれば、それを利用してresourceを書き直すのでも良い。 4. providerをreplaceする 自分は、手順3でにmoduleに書き直した直後にplanを実行すると、下記のようなエラーが出た。 $ terraform plan Refreshing Terraform state in-memory prior to plan... The refreshed state will be used to calculate this plan, but will not be persisted to local or remote state storage. Error: Provider configuration not present To work with aws_s3_bucket.hoge its original provider configuration at provider["registry.terraform.io/-/aws"] is required, but it has been removed. This occurs when a provider configuration is removed while objects created by that provider still exist in the state. Re-add the provider configuration to destroy aws_s3_bucket.hoge, after which you can remove the provider configuration again. どうもterraformerがimportする際に、providerとして昔の形式 registry.terraform.io/-/aws で取り込んでしまうっぽい？ なので、terraform v0.13以降で使用される新しいproviderの形式 registry.terraform.io/hashicorp/aws に変更する必要がある。 $ terraform state replace-provider 'registry.terraform.io/-/aws' 'registry.terraform.io/hashicorp/aws' 5. state mvでresourceからmoduleに変更 ただresourceからmoduleに書き換えただけだとterraformは差分を検知できず、destroy & addしようとするので、state mvでresourceとmoduleを紐つけてやる。 $ terraform state mv aws_acm_certificate.hoge module.acm_hoge.aws_acm_certificate.acm 6. terraform planで差分が出ないことを確認 $ terraform plan ... ... Plan: 0 to add, 0 to change, 0 to destroy. ------------------------------------------------------------------------ Note: You didn't specify an "-out" parameter to save this plan, so Terraform can't guarantee that exactly these actions will be performed if "terraform apply" is subsequently run. 7. backendをs3等に変更 terraformerはデフォルトだとbackendをlocalにしてしまうので、s3等に変更して誰でもいじれるようにする。 backend.tf terraform { backend "s3" { bucket = "hoge-backend" key = "tfstate.json" region = "ap-northeast-1" } } $ terraform init --reconfigure 余談 最初、手順4のエラーがわからず悩まされた。 最終的に下記のstackoverflowを参考にして解決。 https://stackoverflow.com/questions/63590836/switch-terraform-0-12-6-to-0-13-0-gives-me-providerregistry-terraform-io-nul あとterraformerで取り込むと、毎回resourceをmvしなきゃいけないのはつらい。 prefixを事前に与えるとかしていい感じの名前をつけてほしいんだけど、厳密には難しいんだろうなーって思ったり。 terraformerでの取り込みは腕力が必要ですね。はい。

AWS Summit online こちらに参加したので気になった部分を走り書きしていきます(全てをメモするわけじゃないのでご容赦を) 基調講演 テクノロジーが買えるこれからの日本社会 リージョンの考え方が他の企業と違う AWS: 複数のAZを保有することでより高い可用性を実現 大阪リージョンの公開 国内で複数のリージョンによる構成が可能に 1国で複数リージョンを持っている国は少ない AWS Wavelength Zone 5Gネットワークに対応したエッジサービス(KDDI) キャリアのネットワーク内で解決することで低レイテンシーを実現 AWSのイノベーションを起こす方法 お客様最優先でそこから逆算して考える 開発を続けるためのリーダーシップ8箇条 発明し続けるリーダーの意思 時代の流れには逆らえないという認識 発明に対する強い意欲を持った人材 お客様の真の課題を解決するという観点 まずは初めてみること 関係者を少なくシンプルに 多くの機能と豊富なツールセットを兼ね備えたプラットフォームの活用 トップダウンによるアグレッシブな目標設定と推進 クラウド利用とオンプレ利用(DeNA南波さん) issue: コスト: 通常オンプレコストの2倍だったものを圧縮できるか 移行時間: 3y QCD Q: オンプレでできたものはクラウドでもできるはず D: クラウドに部がある C: オンプレの方がいい 仮説: クラウドとほぼ同等なのでは？ 人材 AWSコストの50%でオンプレと同等 DeNAの対応内容 ステートレスサーバーはスポットインスタンスを活用 オートスケーリングとDeNA独自のScaling対応 Shardingの調整 結果 達成(すごい。。。) 移行期間の長さ エンジニアとしてダイナミックな流動性・シナジーを維持 標準化を最初に徹底することにより以降は素早く行えるようにした 標準化: 1年3ヶ月 移行: 単一プロダクトでは3ヶ月いない 移行期間を短くすることでダイナミックな人材流動性を確保 AWS ITトランスフォーメーションパッケージ https://aws.amazon.com/jp/blogs/news/itx-package-support-customers-migration/ クラウドにマイグレーションを支援するパッケージ 評価->計画立案->移行 スモールスタートアップのビジネスをAWSで実現するRABO 伊豫さん catlog 猫様専用IoT IoT機器のログををAWS Fargateと機械学習でアプリに反映 7億件のログが既にある クラウドの人材について クラウドを活用する上で人材が大切 必要人材数 年間+40％ イノベーションを繰り返す土壌を作る 今まで: ローンチが目標であり、そのあとは塩漬けするケースが多い これから: 小さく作ってサービスを進化させスケールアップダウンをさせる

AWS Summit online こちらに参加したので気になった部分を走り書きしていきます(全てをメモするわけじゃないのでご容赦を) 基調講演 テクノロジーが変えるこれからの日本社会 リージョンの考え方が他の企業と違う AWS: 複数のAZを保有することでより高い可用性を実現 大阪リージョンの公開 国内で複数のリージョンによる構成が可能に 1国で複数リージョンを持っている国は少ない AWS Wavelength Zone 5Gネットワークに対応したエッジサービス(KDDI) キャリアのネットワーク内で解決することで低レイテンシーを実現 AWSのイノベーションを起こす方法 お客様最優先でそこから逆算して考える 開発を続けるためのリーダーシップ8箇条 発明し続けるリーダーの意思 時代の流れには逆らえないという認識 発明に対する強い意欲を持った人材 お客様の真の課題を解決するという観点 まずは初めてみること 関係者を少なくシンプルに 多くの機能と豊富なツールセットを兼ね備えたプラットフォームの活用 トップダウンによるアグレッシブな目標設定と推進 クラウド利用とオンプレ利用(DeNA南波さん) issue: コスト: 通常オンプレコストの2倍だったものを圧縮できるか 移行時間: 3y QCD Q: オンプレでできたものはクラウドでもできるはず D: クラウドに部がある C: オンプレの方がいい 仮説: クラウドとほぼ同等なのでは？ 人材 AWSコストの50%でオンプレと同等 DeNAの対応内容 ステートレスサーバーはスポットインスタンスを活用 オートスケーリングとDeNA独自のScaling対応 Shardingの調整 結果 達成(すごい。。。) 移行期間の長さ エンジニアとしてダイナミックな流動性・シナジーを維持 標準化を最初に徹底することにより以降は素早く行えるようにした 標準化: 1年3ヶ月 移行: 単一プロダクトでは3ヶ月いない 移行期間を短くすることでダイナミックな人材流動性を確保 AWS ITトランスフォーメーションパッケージ https://aws.amazon.com/jp/blogs/news/itx-package-support-customers-migration/ クラウドにマイグレーションを支援するパッケージ 評価->計画立案->移行 スモールスタートアップのビジネスをAWSで実現するRABO 伊豫さん catlog 猫様専用IoT IoT機器のログををAWS Fargateと機械学習でアプリに反映 7億件のログが既にある クラウドの人材について クラウドを活用する上で人材が大切 必要人材数 年間+40％ イノベーションを繰り返す土壌を作る 今まで: ローンチが目標であり、そのあとは塩漬けするケースが多い これから: 小さく作ってサービスを進化させスケールアップダウンをさせる

プログラミング勉強日記 2021年5月11日 VPCとの接続方法 　VPCとのオンプレミス側との接続方法は大きく分けて2つある。1つはVPN接続をすること。もう1つは専用線接続(Direct Connect)をすること。 Direct Connect 　Direct Connectはユーザのデータセンターやオフィスを専用線を介してAWSにプライベートに接続するサービスのこと。メリットとしては、値段が安い・ネットワークの信頼性の向上・ネットワーク帯域幅の向上がある。 　Direct Connectの仕組みとしては、以下の図のようになっている。Direct ConnectロケーションがAWSのAZ以外にもリージョンの近くに設計されていて、そこに自社の機器を設置してその中にあるDirect Connectデバイスと接続する。自社の機器側に自社のオンプレ環境とGatewayで接続する設定を行う。この自社機器を介してDirect Connectデバイスに物理的に接続する。Direct Connectデバイスの方はAWSのAZに接続しているので、これを介して専用線の接続ができる。このように物理的に直接つなぐことでかなりの帯域幅と信頼性が高くなっている。 Direct Connect Gateway 　Direct Connect Gatewayによって、同一アカウントに所属する複数リージョンの複数AZから別の複数リージョンの複数VPCに接続できる。これを介してリージョン間のネットワーク接続が可能になる。東京リージョンから中国香港リージョン、東京リージョンから米国東部リージョンといった接続ができる。 VPNとDirect Connect 　Direct Connectの特徴をVPNと比較してみる。VPNの方が安く早く利用できるが、信頼性や品質は専用線のほうが良い。 VPN 専用線 コスト 安価なベストエフォート回線が利用できる キャリアの専用線サービス契約が必要でVPNより高価 リードタイム クラウド上で接続可能などですぐに利用できる 物理対応が必要なので数週間かかる 帯域幅 暗号化のオーバーヘッドによって制限がある ポート当たり1G/10Gps 品質 インターネット経由のためネットワークの影響を受ける キャリアによって高い品質が保証される 障害切り分け インターネットベースなので自社で保持している範囲以外の確認・障害対応は難しい 　物理的に経路が確保されているので簡単

プログラミング勉強日記 2021年5月11日 VPCとのオンプレミス接続方法 　VPCとのオンプレミス側との接続方法は大きく分けて2つある。1つはVPN接続をすること。もう1つは専用線接続(Direct Connect)をすること。 Direct Connect 　Direct Connectはユーザのデータセンターやオフィスを専用線を介してAWSにプライベートに接続するサービスのこと。メリットとしては、値段が安い・ネットワークの信頼性の向上・ネットワーク帯域幅の向上がある。 　Direct Connectの仕組みとしては、以下の図のようになっている。Direct ConnectロケーションがAWSのAZ以外にもリージョンの近くに設計されていて、そこに自社の機器を設置してその中にあるDirect Connectデバイスと接続する。自社の機器側に自社のオンプレ環境とGatewayで接続する設定を行う。この自社機器を介してDirect Connectデバイスに物理的に接続する。Direct Connectデバイスの方はAWSのAZに接続しているので、これを介して専用線の接続ができる。このように物理的に直接つなぐことでかなりの帯域幅と信頼性が高くなっている。 Direct Connect Gateway 　Direct Connect Gatewayによって、同一アカウントに所属する複数リージョンの複数AZから別の複数リージョンの複数VPCに接続できる。これを介してリージョン間のネットワーク接続が可能になる。東京リージョンから中国香港リージョン、東京リージョンから米国東部リージョンといった接続ができる。 VPNとDirect Connect 　Direct Connectの特徴をVPNと比較してみる。VPNの方が安く早く利用できるが、信頼性や品質は専用線のほうが良い。 VPN 専用線 コスト 安価なベストエフォート回線が利用できる キャリアの専用線サービス契約が必要でVPNより高価 リードタイム クラウド上で接続可能などですぐに利用できる 物理対応が必要なので数週間かかる 帯域幅 暗号化のオーバーヘッドによって制限がある ポート当たり1G/10Gps 品質 インターネット経由のためネットワークの影響を受ける キャリアによって高い品質が保証される 障害切り分け インターネットベースなので自社で保持している範囲以外の確認・障害対応は難しい 　物理的に経路が確保されているので簡単

AWSで作成したインスタンスのリージョンを変更したい時、非常に参考になる記事があったので備忘録も兼ねて紹介。 https://www.souichi.club/aws/changeregion/ ステップごとに画像と詳細のやり方が書かれていてとても参考になりました、ありがとうございます。

EC2接続時のエラーとその解決方法をメモ Permissions 0644 for '〜.pem' are too open. It is required that your private key files are NOT accessible by others. This private key will be ignored. Load key "〜.pem": bad permissions ec2-user@iPアドレス.リージョン.compute.amazonaws.com: Permission denied (〜). .pemファイルの権限がゆるいとエラーがでるらしいので、以下のコマンドで解決。 chmod 400 ~.pem やっていること 一桁目　所有者 二桁目　グループ 三桁目　その他 数字の意味 4 読み取りのみ 2 書き込みのみ 1 実行のみ 0 全て禁止 つまり、400は所有者のみに、読み取り権限を与えている。

目次 勉強方法だけ参考にしたい方は「振り返り」をご覧ください。 はじめに SAA受験きっかけ 勉強過程 振り返り さいごに はじめに 本記事はAWS認定ソリューションアーキテクト アソシエイト（以下、SAA）の受験体験記です。 2021年5月8日に受験し、ギリギリですが合格することができました。 様々な方がSAAの体験談を書かれていますが、著者によってバックグラウンドが様々で、自分のバックグラウンドとあまりにも異なる方の体験談を参考にすると、思わぬ落とし穴にハマってしまう可能性が高くなります。そこで、私のバックグラウンドを以下に記述します。 2021年5月時点で新卒2年目のデータアナリストです。 普段の業務では、 既存の分析環境（AWS使用）の運用 ちょっとしたプロジェクトの分析・ドキュメント整理 を行なっています。 1について、AWS使用といってもがっつり使用しているわけではなく、AWSを基盤とした既存のシステムに少し変更を加えることが主な業務です。具体的には、IAMユーザー・グループを整備したり、Redshiftの権限をいじったり、LambdaとSNSで簡単な通知システムを付け加えたり、DataPipelineで動くシステムを修正したり、S3バケットをライフサイクル等で整理したり…そういったことです。その中でTrusted AdvisorやCloudWatch等の便利サービスはちょくちょく使用しています。 2について、これまでの分析では、時系列モデル、傾向スコア、LightGBMを使用しました。これらはローカルで分析しておりましたのでAWS等のクラウドサービスは使用していません。ドキュメント整理としては他のアナリストが使用していた分析環境（AWSのEC2、S3、Redshift）を1から再現できるようなドキュメントを作成した経験があります。 1、2についてAWS経験の観点からまとめると、がっつりwebサービス等のプロダクトをAWSで作成した経験はないが、データ分析業務で使用されることが多い主要サービス（EC2、S3、Redshift、DataPipeline）やその他主要サービス（IAM、CloudWatch等）は触ったことがある程度の知識レベルでした。よって、特定のサービスの特定の機能についてのみ詳しいといったレベルです。 大学・大学院はいわゆる文系でしたが、計量経済学や社会学等で使用されるような統計モデル（マルチレベル分析、ハードルモデル、潜在クラス分析等）や因果推論（傾向スコア等）を用いて調査データの分析をしていました。その流れで、機械学習を含むデータ分析自体に興味を持ちデータアナリストとして新卒入社しました。これは余談ですが、DC1にも面接免除で採用されるなど本気で研究者を目指しておりましたが、データ分析そのものの魅力に取り憑かれ今の会社に就職した次第です。今でも大学・大学院時代に専攻していた分野界隈の論文を読むことが好きです。最近では計算社会科学と呼ばれる分野の論文を読むことが好きです。 大学・大学院時代はAWSの存在すら知らない状態でした。したがって、新卒研修時にEC2やRedshiftを使うことがあり戸惑った覚えがあります。実際の業務においても、今でこそだいぶ慣れましたが、当初はAWSの各サービスの概念が分からず、調べながらキャッチアップしていきました。 SAA受験きっかけ データ分析業務にアナリストとして関わる方なら共感してもらえるかもしれませんが、データ分析に関するアナリスト業務においては、AWSの中でもEC2、Redshift、S3といったサービスだけを使用することが多いかと思います。私もそのような状態にあり特定のサービスの特定の機能については詳しくなる一方で、AWS全体のサービスを俯瞰してみたいなと思うようになりました。 実際に、SAA合格のための勉強をすることで、これまで使ったことがないが重要なサービス（Route53、ELB、CloudFormation等）について知ることができました。さらに、これまで使用していたサービスについても知らなかった機能を知ることができ、勉強して良かったなと思っています。 一方で、SAAはwebアプリケーションを作るインフラエンジニア？向けのテストのようにも思います。データアナリストとして業務をしている私からは、今後も使用することが少ないであろうサービスについても勉強する必要がありました。 AWS認定試験の中にはAWS Certified Data Analytics - Specialtyというデータ分析に関わるサービスに特化した試験もありますので、そちらの取得を目指しても良いのかなとも思っています。また、私の1の業務（既存の分析環境（AWS使用）の運用）と関わりが深そうなAWS Certified SysOps Administrator – Associateの取得を最初に目指した方が良かったのかなとも思っています。 勉強過程 実際にどれくらいの期間試験勉強したのかと言われると正直わかりませんが、以下で私のAWS歴を記します。 2020年7月-9月 業務にキャッチアップするために基本的な概念をざっと確認しました。この段階でAWSの知識はほぼ0でした。 まず、IAMとは何なのか、CloudWatchとは何なのかという本当に基礎的なところから確認しないといけないなと考えていました。 参考にしたのは下記の本です。 図解即戦力 Amazon Web Servicesのしくみと技術がこれ1冊でしっかりわかる教科書 上記の本でとりあえず、主要サービスの基本的な概念は抑えられたのかなと思います。この本は知識レベル0の人が「キソのキ」から始める際にはとても良い教材だと感じました。少しでもAWSに対する知識がある方にとっては、簡単すぎる内容だと思います。 この頃にSAAの存在を知りました。AWS側はSAAの受験者としては業務経験1年くらいの方を想定しているとのことだったので、1年後くらいに受けることができたらなと考える程度で、特に試験について調べるわけでもなかったです。 その後も、特に試験勉強をするわけでもなく、業務に必要な知識をその都度キャッチアップするかたちでAWSについて勉強していました。 2020年10月-2021年2月 2020年10月にそろそろ試験について勉強しようかなと思い始めました。というのも、業務にも少しずつ慣れてきてAWSの知識が溜まっていく感覚がなくなってきたためです。 業務では使用することのない主要サービスについても知りたいなと考えるようにもなってきました。 そこで、以下の教材を購入しました AWS認定資格試験テキスト AWS認定ソリューションアーキテクト - アソシエイト 改訂第2版（正確には第1版を購入） この本は各種サービスについて比較的詳しい解説がなされており、日本語も大変読みやすいものでした。ただ、これだけでSAAに合格するのは、前提知識がない限り無理だと感じました。 この期間に、この本をだらだら何周か読むことを行いました。本当にだらだら読みました。というのも、この期間に他のことを勉強してたり業務が忙しくなったりと、AWSの勉強に多くの時間を割いたわけではなかったためです。平均すると1週間に1-2時間程度レベルの勉強時間だったと思います。 ただ、この本を読むことでよりSAAを受けようという気持ちが高まってきました。 2021年3月-4月 本格的にSAAを受験しようと考えました。新卒1年目が終わるということもあり、何か目に見えるかたちで1年を締め括りたいと考えていました。 この時点で3月初旬〜中旬でした。そこでまずは、1ヶ月後の4月中旬に試験を予約してしまうことから始めました。 先に言っておくと、この試験は2回リスケし5月に受験するかたちとなってしまいました…。AWS認定試験は簡単にリスケができるので、とりあえず試験を予約してしまいそれに向かって勉強する、直前で無理そうだったらリスケするという戦略をとることができます。 AWSが公開しているサンプル問題を確認すると、今の知識だけでは絶対に合格できないと確信したので下記の教材を購入しました。 これだけでOK！ AWS 認定ソリューションアーキテクト – アソシエイト試験突破講座（SAA-C02試験対応版） この教材はUdemyの教材ですが、試験頻出サービスの機能の紹介、ハンズオン、模擬試験が詰まっており大変良い教材でした。ただ、大変ボリューミーな内容で集中力を保ちながら最後まで視聴するのはとても大変だった記憶があります。また、SAA合格だけを目標とする場合は、若干オーバーワークな気がします。 私はまず模擬試験以外の全ての動画を視聴し、ハンズオンも行いました。最後まで視聴し終えた後、再度ハンズオン以外の動画を倍速で見直しました。 その後、模擬試験を受けました。結果は下記の通りです（小テスト13は行いませんでした）。 模擬試験①: 67%（不合格） 模擬試験②: 55%（不合格） レベルが本番よりも難しく設定されてるとのことだったので、まあこんなもんだろうと思っていました（今ではこれらの模擬試験レベルは本番レベルと同等くらいだと考えています）。間違えた問題については解説を読み、ふむふむと納得しながら、またよくわからない事は調べながら見直しました。 ただ、もう少し問題を解きたいなと考えたので、下記の教材を購入しました。 【SAA-C02版】AWS 認定ソリューションアーキテクト アソシエイト模擬試験問題集（6回分390問） 結果は下記の通りでした。 演習テスト1: 72%（合格） 演習テスト2: 69%(不合格) 演習テスト3: 55%(不合格) 演習テスト4: 61%(不合格) 演習テスト5: 56%(不合格) 演習テスト6: 60%(不合格) こちらも難く設定されてるとのことだったので、まあこんなもんだろうと思っていました（今ではこれらの模擬試験レベルは本番レベルと同等くらいだと考えています）。こちらも間違えた問題については解説を読み、ふむふむと納得しながら、またよくわからない事は調べながら見直しました。 この時点で、まあまあ知識がついただろうと思い、AWS公式の模擬試験を受験しました。AWS公式の模擬試験は自分の実力を判断する上でとても役に立つと思います。 その結果は下記の通りでした。 総合スコア: 45%（不合格） これにはとても焦りました。まずは急いで試験を4月後半にリスケしました。 良い点数が取れなかった原因としては、たくさんのテストをこなしたので、かえって頭の中が混乱していたことがあると自己分析しました。というのも、上記のテストで初めて出てきたサービスが数多くあり、頭がごちゃごちゃしてる状態でした。 そこで、上記の合計8つの模擬試験および演習テストを繰り返し解くことを決めました。今から思うと、このやり方が最も効率の良い勉強方法だと思います。 2回目以降の得点は80%~90%でした。ここでは問題の解答を丸暗記するような過学習をしないように意識しました。具体的には、なぜ各選択肢が正解・不正解なのかを思いだしながら解答していきました。 4月後半にリスケしたSAAですが、最終的には5月8日に再リスケして、ゴールデンウィークに勉強できる時間を確保し、上記8つのテストを繰り返し解いていきました。 2021年5月 5月8日、試験当日です。自宅近くのテストセンターでテストを受けました。 身分証明証が2つ必要なのですが、パスポートと運転免許証を持参しました。10:30試験開始だったのですが、10:05くらいに試験会場に到着しました。 特に待たされるわけでもなく、諸々説明を受けたのち、試験部屋（部屋に複数のPCがあり、パーティションで区切られているような部屋でした）に案内され、試験開始となりました。 メモができるものとして、ペンとホワイトボードみたいなものを渡されました。メモは消せないようになっており、最後に回収されました。 試験はAWS公式の模擬試験のようなUIでしたが、完全に同じわけではありませんでした。 個人的な感覚ですが、難易度としては上記8つの模擬試験・演習テストやAWS公式の模擬試験と同じくらいでした。 時間は十分過ぎるくらいで、一通り問題を解いた後、もう一度全ての問題を見直し、さらに気になるところを再度見直すくらいの時間はありました。 それでも10分程度余るくらいで、もうこれでいいだろうと思って試験を終了しました。 試験終了後は簡単なアンケートに答えさせられました。その後、すぐに合格か不合格かの画面に推移します。公式的には、数日以内に通知が来ました。 合格という文字を見たときは、大変安心しました。正直、受けた直後は落ちたかもしれないと思っていました（実際、合格点ギリギリでした）。 振り返り 振り返ると、3月からの約2ヶ月間が集中してSAA対策に取り組んだ時期になりました。集中してといっても平日の2-3時間程を度勉強に当て、休日はゴールデンウィークを除いて勉強をしないことがほとんどでした。 より集中的に取り組めば1ヶ月程度で十分合格には辿り着くのかなとも思います。 また、試験合格という意味では下記のやり方が最強なのではないかと思っています。 AWS主要サービスの基本的な概念・機能を知る（AWS認定資格試験テキスト AWS認定ソリューションアーキテクト - アソシエイト 改訂第2版） 問題を解く（【SAA-C02版】AWS 認定ソリューションアーキテクト アソシエイト模擬試験問題集（6回分390問）） 再度AWS機能について学習（AWS認定資格試験テキスト AWS認定ソリューションアーキテクト - アソシエイト 改訂第2版） 問題をひたすら繰り返し解く（【SAA-C02版】AWS 認定ソリューションアーキテクト アソシエイト模擬試験問題集（6回分390問）） 試験勉強において、最も重要なのは問題を解くことだと思います。 SAAの問題の感覚というか癖というか、そういうことを知るためには「それなりの業務経験を積む」もしくは「問題を解いて慣れる」しかないと思います。 私の場合前者については、業務内容が若干SAAの内容とは異なっていたので不可能でした。 よって、「問題を解いて慣れる」ことが必要でした。私は「問題を解いて慣れる」ことをだいぶ後回しにしてしまったので後悔しています。 より早い段階で問題を解いて慣れ、その上で改めてAWSの各サービスについて勉強することが試験に合格するという意味では重要だと考えております。 ただ、試験に合格することはできても、業務等で実際にうまく活用できないともったいないようにも思います。 そういう意味では、単に問題を解くだけではなく、下記の教材を使用してハンズオンを行なったり、時間をかけて勉強することで長期記憶することも大事かと思います。 これだけでOK！ AWS 認定ソリューションアーキテクト – アソシエイト試験突破講座（SAA-C02試験対応版） さいごに 今後は、AWS Certified Data Analytics - SpecialtyあるいはAWS Certified SysOps Administrator – Associateを受験しようかなと、うっすらですが考えています。 また、今回の勉強を通してIT用語の基本的なところ（例えば、RAIDとかミラーリング）の知識もちゃんとおさらいしたいなと感じたので、基本情報技術者試験を受けようかなとか考えたりしています。 その一方で、少し自由に興味があることを勉強する時間を確保したいなとも思っています。 以上、SAA受験体験記でしたが、私も勉強しながら様々な方の記事を参考にしました。 この記事が、他の方の役に立つことを願っております。 （合格するともらえるバッジです）

KMSはAWSの他のサービスを使うときになんとなく設定する程度で、KMSそのものの動きはいままで理解できていませんでした。そこで、awscliで手動で暗号化・復号化の処理をしてみることで、理解を進めました。 キー作成 aws kms create-key コマンドでキーを作成します。 $ aws kms create-key { "KeyMetadata": { "AWSAccountId": "123456789012", "KeyId": "2f94xxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx", "Arn": "arn:aws:kms:ap-northeast-1:123456789012:key/2f94xxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx", "CreationDate": 1620370256.542, "Enabled": true, "Description": "", "KeyUsage": "ENCRYPT_DECRYPT", "KeyState": "Enabled", "Origin": "AWS_KMS", "KeyManager": "CUSTOMER", "CustomerMasterKeySpec": "SYMMETRIC_DEFAULT", "EncryptionAlgorithms": [ "SYMMETRIC_DEFAULT" ] } } ここで作成したキーは、存在は見えるものの、キーそのもの(CMK、Customer Master Key)を見ることはできません。 AWSアカウントにあるキー一覧を確認 aws kms list-keys コマンドでキーの一覧を確認できます。さきほど作成したキーはこの中に含まれています。 $ aws kms list-keys { "Keys": [ { "KeyId": "2f94xxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx", "KeyArn": "arn:aws:kms:ap-northeast-1:123456789012:key/2f94xxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" }, { "KeyId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx", "KeyArn": "arn:aws:kms:ap-northeast-1:123456789012:key/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" }, { "KeyId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx", "KeyArn": "arn:aws:kms:ap-northeast-1:123456789012:key/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" }, ... ] } マネジメントコンソールで見ると、作成したキーはCustomer managed keysに入っていました。 さきほど作成した以外のキーはAWS managed keysに入っていました。 エイリアスは aws kms list-aliases コマンドなどで確認できます。 $ aws kms list-aliases { "Aliases": [ { "AliasName": "alias/aws/backup", "AliasArn": "arn:aws:kms:ap-northeast-1:123456789012:alias/aws/backup", "TargetKeyId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx", "CreationDate": 1594564129.245, "LastUpdatedDate": 1594564129.245 }, { "AliasName": "alias/aws/dms", "AliasArn": "arn:aws:kms:ap-northeast-1:123456789012:alias/aws/dms", "TargetKeyId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx", "CreationDate": 1598578567.162, "LastUpdatedDate": 1598578567.162 }, { "AliasName": "alias/aws/dynamodb", "AliasArn": "arn:aws:kms:ap-northeast-1:123456789012:alias/aws/dynamodb", "TargetKeyId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx", "CreationDate": 1604415194.916, "LastUpdatedDate": 1604415194.916 }, { "AliasName": "alias/aws/ebs", "AliasArn": "arn:aws:kms:ap-northeast-1:123456789012:alias/aws/ebs" }, ... CDK作成 aws kms generate-data-key コマンドによりCDKを作成します。CDKはデータを暗号化・復号化するためのキーです。 $ aws kms generate-data-key --key-id 2f94xxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx --key-spec AES_256 { "CiphertextBlob": "AQID...", "Plaintext": "zNn6...", "KeyId": "arn:aws:kms:ap-northeast-1:123456789012:key/2f94xxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" } レスポンスにある、Plaintextはキーそのもので、CiphertextBlobはそのキーを最初に作成したキー(CMK、Customer Master Key)で暗号化したものです。どちらもBASE64でエンコードされた長い文字列です。このあとで試しますが、aws kms decryptコマンドで、CiphertextBlobからPlaintextを復元できます。 CDKは aws kms generate-data-key コマンドを実行するごとに異なるキーが返されます。 データを暗号化 Hello, World! というテキストを暗号化してみます。データの暗号化・復号化は、awscliではなく、適当なツールを使えばよいようです。opensslを使いました。パスフレーズにさきほど作成したCDKのPlaintextを指定します。BASE64でデコードが必要です。 $ echo 'Hello, World!' | openssl enc -e -aes256 -pbkdf2 -pass file:<(echo 'zNn6...' | base64 -d) | base64 U2FsdGVkX19Qvh8L0t+zpptfNhgHX4a/RzpNB2nql9g= openssl enc -eコマンドの -pass には、パスフレーズの書かれたファイルを file:FILEPATH のようにファイル名で指定します。ここではファイル作成の手間を惜しんで、コマンドの中に <(...) で埋め込んでいます。<(...) の中身はPlaintextをBASE64でデコードした結果です。 openssl encコマンドの出力は暗号化された結果です。バイナリなので、コンソール上に表示できるようにBASE64でエンコードしています。 暗号化したデータを保存 データベースなどにデータを暗号化して保存する際は U2FsdGVkX19Qvh8L0t+zpptfNhgHX4a/RzpNB2nql9g= という暗号化したデータとともに、CDKのCiphertextBlobの AQID.... という文字列（またはそれをBASE64でデコードしたバイナリ）を保存しておきます。CiphertextBlobのから直接データを復号化することはできません。CDKのPlaintextが必要です。Plaintextを得るには、KMSにCiphertextBlobからの復元をリクエストする必要があります。 このあとは、暗号化したデータとCiphertextBlobが保存されていることを想定して、そこからKMSを使って復号化する手順を踏みます。 CDKのPlaintextを復元 aws kms decrypt コマンドによりCDKのCiphertextBlobからPlaintextを復元します。 $ aws kms decrypt --ciphertext-blob fileb://<(echo 'AQID...' | base64 -d) { "KeyId": "arn:aws:kms:ap-northeast-1:123456789012:key/2f94xxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx", "Plaintext": "zNn6...", "EncryptionAlgorithm": "SYMMETRIC_DEFAULT" } --ciphertext-blob オプションには fileb://FILEPATH のように、CiphertextBlobの AQID.... という文字列をBASE64でデコードしたバイナリを保存したファイル名を指定します。ここではファイル作成の手間を惜しんで、コマンドの中に <(...) で埋め込んでいます。<(...) の中身はCiphertextBlobをBASE64でデコードした結果です。 レスポンスされたPlaintextが、暗号化したときのPlaintextと一致しています。暗号化したときのパスフレーズを保存しておかなくても、KMSとCiphertextBlobから復元できることがわかります。 KMSはPlaintextを復元する際にはCMKを識別するためのKeyIdが必要なはずですが、 aws kms decrypt コマンドではKeyIdの指定が不要です。CiphertextBlobにCMKを識別するための情報が埋め込まれているらしいです。 データを復号化 openssl enc -d で復号化します。無事 Hello, World! が復元できました。 $ echo 'U2FsdGVkX19Qvh8L0t+zpptfNhgHX4a/RzpNB2nql9g=' | base64 -d | openssl enc -d -aes256 -pbkdf2 -pass file:<(echo 'zNn6...' | base64 -d) Hello, World! 暗号化したデータは openssl enc -dコマンドの標準入力に渡しています。 U2FsdGVk... はBASE64でエンコードされた文字列ですので、標準入力前にBASE64でデコードしています。 openssl enc -dコマンドの -pass には、暗号化したときと同様にコマンドの中に <(...) で埋め込んでいます。