25日目！最終日！ 本日は、これまでの1日目～24日目までの内容を振り返っていきます。 1日目～4日目(Amazon S3 Web Hosting) Amazon S3 の静的サイトホスティングの設定をご紹介しました。 S3 に関するコマンドは、オブジェクト操作周りが行える s3 コマンド、API を操作する s3api とユースケースを分けて構成されています。また cp や ls といった馴染み深いコマンドが設定されているので、単にオブジェクトを格納したり、取得したりする際に悩むことが少なくなっています。 5日目～12日目(Amazon CloudFront、AWS WAF など) CDN のサービスである、Amazon CloudFront とWeb Application Firewall のサービスである AWS WAF をご紹介しました。 あわせて、独自ドメインの設定を通じて、Amazon Route53 や 証明書のサービスである AWS Certificate Manager(ACM) もご紹介しました。 今回は、ドメインの取得は別サービスで行いましたが、route53domains register-domain コマンドで行うことができます。 13日目(Amazon CloudWatch メトリクス) Web サイトのアクセス数(リクエスト数)を取得するために、Amazon CloudWatch メトリクスをご紹介しました。ちなみに、 cloudwatch put-metric-data コマンドを使うことでメトリクスを登録することもできます。 14日目～18日目(ネットワーク、EC2、AutoScaling) 後半戦に入ってからは、馴染みのある Amazon EC2 や Amazon Virtual Private Cloud(VPC)、AutoScalingをご紹介しました。 マネージメントコンソールでウィザードに従えばポチポチっと数クリックで数分で EC2 インスタンスを起動させられますが、 AWS CLI であれば、ワンライナーで起動させることができます。 19日目(セッションマネージャー) 運用で必要になるサーバーへの接続を可能にするためにセッションマネージャーをご紹介しました。この環境では、 AutoScaling で起動してくる EC2 インスタンスはプライベートサブネットで稼働するため、VPC エンドポイントを用意しました。 20日目(Amazon CloudWatch Logs) OS のログやアプリのログを CloudWatch Log で確認できるように、CloudWatch エージェントの設定を行いました。ログ監視サーバーや統合ログサーバーなどを CloudWatch Logs に集約できるものです。 ちなみに、 CloudWatch エージェントはログだけでなくメトリクス収集も行ってくれます。 21日目～22日目(AWS CodeCommit, AWS CodePipeline) Web サイトなのでコンテンツのバージョン管理などをするために、リポジトリサービスの CodeCommit のご紹介や環境構築、登録したコンテンツをエンドユーザーに配信できるように自動処理してくれる CodePipeline のパイプラインを作成しました。 23日目～24日目(AWS Lambda, Amazon API Gateway) そしてアドカレ最後として、サーバレス周りのキモになる API Gateway と Lambda 関数のご紹介と設定、構築を実施しました。 おまけに、Lambda の環境情報やストレージ情報など HTML で出力するコードを設定しました。 この期間に実行したコマンド 全 80 種類のコマンドを実行、ご紹介しました。 普段の構築作業では、マネージメントコンソールやCloudFormationなどを使うことが多いですが、個々の API を見ていくことで、例えば、IAM ポリシーにどんなアクション許可が必要なのかが見えてくると思います。ということは、AWS CLIが動かないとか、Lambda関数が動かないといった際、「あ、このアクション許可が足りてないんだね」ってことがすぐにわかり、トラブルシューティングの迅速化にもつなげられると思います。 acm describe-certificate acm request-certificate apigateway create-deployment apigateway create-rest-api apigateway get-resources apigateway put-integration apigateway put-integration-response apigateway put-method apigateway put-method-response apigateway test-invoke-method autoscaling create-auto-scaling-group autoscaling create-launch-configuration autoscaling update-auto-scaling-group cloudfront create-cloud-front-origin-access-identity cloudfront create-distribution cloudfront get-distribution-config cloudfront update-distribution cloudwatch get-metric-statistics codecommit create-repository codepipeline create-pipeline codepipeline get-pipeline-state ec2 associate-route-table ec2 attach-internet-gateway ec2 authorize-security-group ec2 authorize-security-group-egress ec2 authorize-security-group-ingress ec2 create-image ec2 create-internet-gateway ec2 create-route ec2 create-route-table ec2 create-security-group ec2 create-subnet ec2 create-vpc ec2 create-vpc-endpoint ec2 describe-instances ec2 modify-subnet-attribute ec2 revoke-security-group-egress ec2 run-instances ec2 terminate-instances elbv2 create-listener elbv2 create-load-balancer elbv2 create-target-group events put-rule events put-targets iam add-role-to-instance-profile iam attach-role-policy iam create-instance-profile iam create-policy iam create-role lambda add-permission lambda create-function lambda get-function lambda invoke logs describe-log-groups logs describe-log-streams route53 change-resource-record-sets route53 create-hosted-zone s3 cp s3 ls s3 website s3api create-bucket s3api delete-bucket-website s3api get-bucket-lifecycle-configuration s3api get-bucket-logging s3api get-bucket-policy s3api get-bucket-website s3api head-object s3api put-bucket-acl s3api put-bucket-lifecycle-configuration s3api put-bucket-logging s3api put-bucket-policy s3api put-object-acl s3api put-public-access-block ssm get-parameter ssm start-session ssm terminate-session wafv2 create-rule-group wafv2 create-web-acl wafv2 get-web-acl wafv2 update-web-acl 最後に この一連のアドカレのように、一から AWS CLI で構築していくことは少ないかもしれません。 しかし、運用作業などで用いられる「運用手順書」や「作業手順書」といったものを作る際に、AWS CLI を使うことで、マネージメントコンソールのスクリーンショットべたべた手順書から脱却できるということです。 スクリーンショットべたべた手順書を作成したはよいが、ユーザーインターフェースの更新により作り直すといった経験ありませんか？わたしは何度もあります。 ぱっと見敷居は高いかもしれませんが、全体的な運用工数低減にもつなげられるので、AWS CLI と仲良くできるとよいと思いますよ。

はじめ この記事は「AWS Advent Calendar 2021」25日目の記事です。 本日はクリスマスですね。メリークリスマス?? 昨年の本番環境でやらかしちゃった人 Advent Calendar 2020にて、"""S3「 お゛め゛ぇ゛に゛権゛限゛ね゛ぇ゛がら゛！」"""という ネタ 記事を書いてから既に丸1年が経過したという事実が受け入れられません。 インフラエンジニア5年目のtsumitaと申します。 3行まとめ Windows系OSでインスタンスタイプを変更するとネットワークアダプターが変更されることにより、DNS設定がリセットされて名前解決ができなくなることで、通信ができなくなる場合があります DHCP オプションセットやRoute 53のアウトバウンドクエリ転送を使用することで回避できます インスタンスタイプ変更前に互換性を確認しましょう 経緯 Windows Server 2019のインスタンスタイプをt3.mediumからc6i.largeへタイプを変更したところ、名前解決が出来なくなり結果として通信ができなくなりました。 該当のサーバはActive Directory(AD)に参加しており、手動でDNSサーバの設定をしていました。 詳細 状態を把握するためにipconfig /allでネットワークの情報を確認したところ、ネットワークアダプターが付け変わったことによりネットワーク(DNS)の設定がリセットされたようです。 設定がリセットされたことにより、VPCデフォルトのDHCPオプションセットで設定されているRoute 53 ResolverのDNSサーバ(172.31.0.2)が設定されていました。 ※AWS公式ドキュメントのインスタンスタイプの互角性に記載されている以下の仕様のとおり、"ENA"から"high-bandidth ENA"に変更するとネットワークアダプターの設定がリセットされるようです。 Network adapters If you switch from a driver for one network adapter to another, the network adapter settings are reset when the operating system creates the new adapter. To reconfigure the settings, you might need access to a local account with administrator permissions. The following are examples of moving from one network adapter to another: - AWS PV (T2 instances) to Intel 82599 VF (M4 instances) - Intel 82599 VF (most M4 instances) to ENA (M5 instances) - ENA (M5 instances) to high-bandwidth ENA (M5n instances) t3.mediumの情報(インスタンスタイプ変更前) c6i.largeの情報(インスタンスタイプ変更後) また、今回はWindows Server 2019の比較的新しいAMIを利用していたため対象ではないのですが、古いAMIを利用している場合でc6iなど新しいインスタンスタイプを利用する際にドライバ更新が必要な場合があります。 解決策 本事象の一番簡単な解決策はDHCP オプションセットを利用してDNSの設定を自動化することです。 DHCPオプションセットはVPC単位での設定となるため、何らかの理由で設定が出来ない場合はRoute 53のアウトバウンドクエリ転送を利用することで今回の事象は回避できると思います。 力技としてDNS設定スクリプトをユーザデータに仕込んで置いたり、SSM Run Commandなどを実行することで設定も出来るとは思いますが、本当にどうしようもない場合のみ利用した方が良いと思います。 おわり AWSをはじめとするクラウドではマシンスペックを気軽に変更できるため、今回のようなことで障害が発生する場合があると思います。 設定変更する際には必ず影響範囲(互換性)を精査してから行うことが大切だと改めて身をもって体験しました。 AWS Advent Calendar 2021関係者の皆様お疲れ様でした。 記事を読んで下さった皆様にとって来年も素敵な年になることを切に願っています！ 良いお年をお迎えください！

今回は、AWS EC2インスタンスの終了保護設定についてご紹介していきます！ 初めに 本来、インスタンスを停止する際には、下記画像の「インスタンスを停止」から行うのですが、似たような表現で「インスタンスを終了」というボタンも存在します。 万が一、「インスタンスを終了」を押してしまった場合、インスタンスのデータが全て削除されてしまいます！ せっかくデプロイしたアプリが、ちょっとした誤操作により消えてしまわないよう終了保護の設定をしておきましょう！ 終了保護の設定 1.該当インスタンスにチェックを入れ、「アクション」から「終了保護を変更」をクリック。 2.「有効化」にチェックを入れて保存。 デフォルトだと「有効化」にチェックが入っていないので、終了保護が無効化になっている状態です。 3.設定完了確認 画面上部に「終了保護が有効化されました。」とメッセージが表示されれば設定完了です！ これで「インスタンスを終了」をクリックしてもインスタンスの削除に失敗するようになります！

これはなに？ 自分は2020年8月ごろにプロダクトマネージャーからエンジニアに転向し、この1年半でバックエンド、フロントエンド、インフラなど色々やっているうちに気付いたらいちチームのリーダーを任されるまでになりました。なのでこの記事ではその間にどんなことを勉強したのかをまとめておこうと思います。 エンジニアになったばかりの人やこれからなる人の一つの参考になれば幸いです。 担当プロダクトの技術スタック バックエンド：Python, flask フロントエンド：JavaScript, Vue.js DB：MySQL インフラ：AWS 勉強したこと メインとしてバックエンドのapi開発をやっていたため、フロントエンドは薄めになっています。 とりあえず入門 Progate 受講コース：Git/Command Line/SQL/Python/HTML&CSS/JavaScript とりあえず入門するのに手軽でよかったと思います。 キタミ式イラストIT塾 ITパスポート とりあえず基礎中の基礎をさらうために勉強しました。資格自体にめっちゃ意味があるとは思ってないですが、資格勉強をすることで一旦広く知識が得られるのはとても有益だと思っています。 コンピュータの基礎 コンピュータはなぜ動くのか～知っておきたいハードウエア＆ソフトウエアの基礎知識 プログラムはなぜ動くのか 第３版　知っておきたいプログラミングの基礎知識 この２つはプログラミングの勉強をするにあたって、まず最初に読みました。いきなり言語の勉強をし始めるより基礎をちゃんとさらったことは良かったと思っています。 Python 独学プログラマー Python言語の基本から仕事のやり方まで マジでこれから入ってよかった。オライリーから入ったら死んでたと思う Pythonチュートリアル 入門Python3 ガチ初学者には向いてないです。一回プログラミングを通った人がPythonを学ぶのには○ flaskアプリの自作 flaskに関しては恥ずかしながら体系的なインプットをする前に、実務で教えてもらいながら見様見真似で少しずつ理解していきました。(というか１ヶ月くらいで実務に放り込まれたので時間がなかった) 代わりと言ってはなんですが、少し時間が経った頃にこの記事や関連記事を参考に、自分でflaskを使ったslackアプリをつくって遊んでいました。結構勉強になったと思います。 SQL SQL 第2版 ゼロからはじめるデータベース操作 select文は死ぬほど書いたことがあったのですが、それ以外は全くだったので基本をさらうために。 HTML/CSS これからWebを始める人のHTML&CSS,JavaScriptのきほん この辺はある程度はわかっていたのですが、改めてちゃんとエンジニアになるにあたって基本は押さえておこうと思って一応。 JavaScript Udemy 【JS】ガチで学びたい人のためのJavaScriptメカニズム JS学ぶのにいい本ないですか？と聞いたら、これが一番わかりやすくておすすめ、と教えてもらったのがこちら。 結構基礎から非同期処理とかまで一通り扱ってくれて結構助かりました。 Vue.js Vue.js入門 基礎から実践アプリケーション開発まで とりあえず一番基本っぽいものをやりました。 プログラミング基礎 リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック 括りかたわからなかったけど、言わずもがなの必読本。一番お世話になってる気がする。 Linux linux標準教科書 Linuxコマンドポケットリファレンス ポケットリファレンスは、とりあえず通しでパラパラっと読んで、辞書的に使ってます。 最初はMacOSとLinuxの違いが分かってなかったので、オプションの違いとかで結構戸惑いました。 Git GitHub実践入門 ~Pull Requestによる開発の変革 (WEB+DB PRESS plus) 実際にチームで開発する中での細かいルールとかは実務で教えてもらいながらにはなりますが、Gitに関する最低限の知識として絶対読むべきなやつ。 セキュリティ 体系的に学ぶ 安全なWebアプリケーションの作り方 第2版 脆弱性が生まれる原理と対策の実践 めちゃくちゃ分厚くて心折れかけましたが、セキュリティに関する最低限の知識としてがんばりました。 オブジェクト指向/デザインパターン オブジェクト指向でなぜつくるのか 第3版 知っておきたいOOP、設計、アジャイル開発の基礎知識 デザインパターンとともに学ぶオブジェクト指向のこころ オブジェクト指向型の言語を使うにあたって最低限理解しておく必要があるだろうということで。 デザインパターンは正直ある程度実装に慣れた頃に読んで初めて意味があるかな、という感じです。 アルゴリズム プログラマ脳を鍛える数学パズル シンプルで高速なコードが書けるようになる70問 珠玉のプログラミング 本質を見抜いたアルゴリズムとデータ構造 実務でめちゃくちゃアルゴリズムに気を使わないといけないようなことがあるか、と言われたらそんなにないんですが、一通りやっておくことで普段の実装でも計算量とかを意識できるようになると思います。 AWS (模擬問題付き)改訂新版 徹底攻略 AWS認定 ソリューションアーキテクト − アソシエイト教科書[SAA-C02]対応 Udemy これだけでOK！ AWS 認定ソリューションアーキテクト – アソシエイト試験突破講座（SAA-C02試験対応版） Udemy AWS 認定ソリューションアーキテクト アソシエイト模擬試験問題集（6回分390問） 実務でちょいちょいawsに触れる機会があったのですが、一回体系的にインプットしたいな、と思ってとりあえず資格を目標に勉強しました。Udemyの講座が、試験対策だけでなく一通りハンズオン形式で触らせてくれたのでとてもありがたかったです。 一通り最低限の知識を入れたことで、その後の公式ドキュメントとかも読みやすくなった気がします。 ネットワーク ３分間ネットワーキング 全然３分じゃ無理ですが、とりあえずネットワークについて最低限の知識を抑えるのにはおすすめだと思います REST Webを支える技術 -HTTP、URI、HTML、そしてREST (WEB+DB PRESS plus) API設計で必要な考え方の基本が抑えられます。 テスト テスト駆動開発 この本読んでからテストを書かないと気持ち悪くなりました。テスタブルなコードを意識すると、自然とコードがきれいに分割されていく気がするので早いうちに読んでおいて正解だったなと思います。 開発プロセス LeanとDevOpsの科学[Accelerate] テクノロジーの戦略的活用が組織変革を加速する (impress top gear) アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法 SCRUM BOOT CAMP THE BOOK【増補改訂版】 スクラムチームではじめるアジャイル開発 チーム開発をより効率的に進めるために、DevOpsやアジャイル開発に関するインプットもしました。 チーム作り エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで How Google Works(ハウ・グーグル・ワークス) 私たちの働き方とマネジメント Team Geek ―Googleのギークたちはいかにしてチームを作るのか チームリーダーを任されるということで、改めて開発組織をどう作っていくか、というのを考えるために読みました。 プロダクトマネジメント プロダクトマネジメントのすべて PMやデザイナーも含め、チームで一つのプロダクトを作るために目線を揃えよう、ということでチームみんなで読みました。とてもよかった。 おわりに こうやって見てみると、改めてとりあえず広く基本を抑えた感じでやってきたなと思いました。 来年は求められる役回り的にも、もう少しDBの深いところやミドルウェア関連の知識とかもつけていきたいなと思っています。 またここにはわざわざ書いてないですが、各種公式ドキュメントには大変お世話になりました。 ↓の記事にも書きましたが、日々色々とググる中でちゃんと公式に立ち戻ってインプットしていたことがとても良かったなと思います。

AWSは提供しているサービスが多く、それぞれのサービスが何をしてくれるものなのか分からなくなることが多いので、簡単にリスト化してメモしておきたいと思います。 仮想サーバ Amazon EC2：仮想サーバ（OS、CPUスペック、メモリスペックなどを自由に選択できる) Amazon Lightsail：Webサーバを構築する際に利用できる仮想サーバパッケージ データベース、仮想サーバ Amazon RDS：MySQL、　PostgreSQL、OracleDBなどを選択してデータベースサーバを構築できる Amazon Aurola：MySQL、PostgreSQLと互換性がありつつも性能を向上させたデータベース Amazon S3：データストレージ、大容量ファイルなどを置いておくことができる 機械学習 Amazon SageMaker：機械学習用環境を構築するための仮想サーバパッケージ Amazon Comprehend：機械学習の知識がなくても使えるテキスト分析サービス

これは「「はじめに」の Advent Calendar 2021」24日目の記事です。 Github ActionsからAWSのリソースを操作する GitHub ActionsでOpenID Connect経由の各種Cloud Providerの認証取得がGAになったし、年末だしAccessTokenを大掃除したかっただけでした。 検証中に1時間もハマったのでメモ。 OIDC Provier作成 GUIからProviderを作成。 プロバイダのタイプ プロバイダのURL 対象者 OpenID Connect https://token.actions.githubusercontent.com sts.amazonaws.com プロバイダの「ロールの割当」→「新しいロールを作成」 「ウェブID」 → Audienceに「 sts.amazonaws.com 」を選択 ポリシーならなんやらをつけて作成後はこうなります。 1つ目のトラップ GithubActionsに適当なWorkflowを作成して動かしてみます。 name: "sample" on: [ workflow_dispatch ] env: AWS_ROLE_ARN: ${{ secrets.AWS_ROLE_ARN }} jobs: test: runs-on: ubuntu-latest permissions: id-token: write contents: write steps: - uses: actions/checkout@v2 - uses: aws-actions/configure-aws-credentials@master with: role-to-assume: ${{ env.AWS_ROLE_ARN }} role-session-name: sample aws-region: ap-northeast-1 - run: aws s3 ls エラーになります。 Run aws-actions/configure-aws-credentials@master Error: Not authorized to perform sts:AssumeRoleWithWebIdentity 信頼関係のポリシーはこうなっていますが、コレでは動きません。 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Federated": "arn:aws:iam::${aws_account_id}:oidc-provider/token.actions.githubusercontent.com" }, "Action": "sts:AssumeRoleWithWebIdentity", "Condition": { "StringEquals": { "token.actions.githubusercontent.com:aud": "sts.amazonaws.com" } } } ] } この記事を参考に、 "token.actions.githubusercontent.com:aud": "sts.amazonaws.com" を↓に変更します "token.actions.githubusercontent.com:sub": "repo:${github_org}/${github_repo}:*" 再実行してもエラー。しかも内容変わらず。 Run aws-actions/configure-aws-credentials@master Error: Not authorized to perform sts:AssumeRoleWithWebIdentity 2つ目のトラップ 理由がわからず、Cloud Trailまで見に来ました。 { "eventVersion": "1.08", "userIdentity": { "type": "WebIdentityUser", "principalId": "arn:aws:iam::${aws_account_id}:oidc-provider/token.actions.githubusercontent.com:sts.amazonaws.com:repo:${github_org}/${github_repo}:ref:refs/heads/test/oidc-test", "userName": "repo:${github_org}/${github_repo}:ref:refs/heads/test/oidc-test", "identityProvider": "arn:aws:iam::${aws_account_id}:oidc-provider/token.actions.githubusercontent.com" }, "eventTime": "2021-12-24T07:55:02Z", "eventSource": "sts.amazonaws.com", "eventName": "AssumeRoleWithWebIdentity", "awsRegion": "ap-northeast-1", "sourceIPAddress": "xxx.xxx.xxx.xxx", "userAgent": "aws-sdk-nodejs/2.1047.0 linux/v12.13.1 configure-aws-credentials-for-github-actions promise", "errorCode": "AccessDenied", "errorMessage": "An unknown error occurred", "requestParameters": { "durationSeconds": 3600, "roleArn": "arn:aws:iam::${aws_account_id}:role/GithubS3ReadOnlyAccess", "roleSessionName": "sample" }, ・・・(略) 堂々の "An unknown error occurred" GithubActionsの設定やSecretsの方を散々確認しましたが、実は答えはすぐ近くにありました。 間違い "StringEquals": { "token.actions.githubusercontent.com:sub": "repo:${github_org}/${github_repo}:*" } ↓ 正解 "StringLike": { "token.actions.githubusercontent.com:sub": "repo:${github_org}/${github_repo}:*" } * 入っていますからね、 StringEquals じゃなくて StringLike ですよね。 昨日に引き続き文字列違いのネタ。 クリスマスイブだけど(クリスマスイブなので？）軽めにしてます。 (こんなんで1時間ハマるとか・・・)

こんにちは。リンクアンドモチベーションの綿引です。 本記事では、「S3 Storage Lens」と「ライフサイクルルール」を使用して不要なデータを定期的に削除し "S3 のコストを削減" する方法をご紹介します。 この後詳細を記載しますが、当時あるシステムで「S3 の費用が10万円以上」発生していたことがありました。。 その際に上記問題を解決した「コスト削減方法」について書いていければと思います。 S3 は確かに安い！が・・ S3 を使用したことのある方のイメージと言えば「安い！」と思い浮かぶ方も多くいらっしゃるのではないでしょうか？ 幾つか課金項目がある中のストレージ料金だけですが、「1GB あたり 0.025USD」と確かに安いです。 尚、以下が料金形態となります。 私自身ずっと「安い」というイメージを持っており、あまりコストを気にしたことがなかったのですが、ふと AWS Cost Explorer を確認した時に「思ったより S3 のコストが高い」ことがありました。 原因としては数年に渡って徐々に蓄積されたデータが膨大となり、ストレージ料金が高額となっていたためでした。 上記で安いと記載しているものの、これが数TBなどになるとコストにインパクトを与えてきます。 コストがかかっている S3 バケットは開発環境であったり、そもそも不要なデータだったりしたためファイルを削除することで対応したのですが、そこで使用したのが「S3 Storage Lens」と「ライフサイクルルール」だったため、こちらについて私が行った方法を記載できればと思います。 S3 Storage Lens で利用状況を確認 S3 のコストが高かった際、一番最初に確認するのは「どのバケットにコストがかかっているか」です。 そこで便利なのがこの「S3 Storage Lens」で「S3 の利用状況を可視化する」ことができます。 デフォルトでダッシュボードが存在するため、設定なども特になく、そのアカウントにある S3 全体のストレージの合計や、ストレージを使用しているバケットの上位3つなど、色々な情報を得ることができます。 使用方法としては S3 のマネジメントコンソールから上部にある「Storage Lens ダッシュボードを表示」をクリックするだけです。 ダッシュボードを開くと、上記の情報などを見ることができます。 まずはここで「どのバケットがストレージを使用しているか」を調査して、「バケット内のファイルが不要かどうかの判斷」や実際の対応に進んでいきましょう。 尚、S3 Storage Lens のデフォルトのダッシュボードは以下の項目を見ることができるのですが、「有料のメトリクス」を使用することでより詳しい情報を見ることことも可能です。 無料のメトリクス ストレージの合計 オブジェクト数 現行バージョンのバイト数 現行バージョンのオブジェクト数 旧バージョンのバイト数 旧バージョンのオブジェクト数 削除マーカーのオブジェクト数 暗号化されたバイト数 暗号化されたオブジェクト数 レプリケートされたバイト数 レプリケートされたオブジェクト数 オブジェクトロックのバイト数 オブジェクトロックのオブジェクト数 未完了の MPU バイト数 未完了の MPU オブジェクト数 有料のメトリクス すべてのリクエスト GET リクエスト PUT リクエスト HEAD リクエスト POST リクエスト DELETE リクエスト LIST リクエスト リクエストを選択 スキャンされたバイトを選択 返されたバイトを選択 ダウンロード済みバイト数 アップロード済みバイト数 4xx エラー 5xx エラー ライフサイクルの設定 次に不要なファイルが存在することが判明した場合の削除方法です。 S3 オブジェクトの削除方法は「コンソールから手動で削除」や、「aws s3 コマンドを使用する」など幾つかありますが、おすすめはライフサイクルです。 ライフサイクルの機能としては「オブジェクトを一定期間経過後に自動的に削除・移動する」というものであり、単発で削除する際にも使えますが、増え続けるファイルを「一定期間経過後に自動的に削除できる」という点が魅力です。 ライフサイクルを使用するには、まず「ライフサイクルルール」を作成します。 S3 のコンソールから、対象の S3 バケットを選択 → 管理 → ライフサイクルルールを作成する でルールの作成ができます。 設定では「特定のオブジェクトをフィルタリング」したり、「オブジェクトのサイズにで適用する範囲を制限」することなども可能です。 どれほどの期間が経過したら削除されるかは、設定画面下部の「ライフサイクルルールのアクション」で指定します。 例えば「ファイルの作成から30日経過したら削除したい」といった場合は、以下のような設定を行います。 オブジェクトの現行バージョンを有効期限切れにする : チェックをつける オブジェクト作成後の日数 : 30 これで作成から30日以上経過したファイルは削除されます。 今回はバージョニングについては触れませんが、バージョニングを有効にしている場合は設定内容が少しことなるため注意頂ければと思います。 またストレージクラスの移動についても記載していませんが、ライフサイクルを使えば特定のファイルを自動で Glacier に移動できたりもするので、是非見てみてください。 おわりに 「S3 Storage Lens」と「ライフサイクルルール」を使用して不要なデータを定期的に削除し"S3 のコストを削減"する方法をご紹介させて頂きました。 この記事が見て頂いた方の何かの参考になれば幸いです。

この記事について IoTcoreの機能の一つであるフリートインデックスを中心に、少し細かい内容をドキュメントベースや実際に触った内容についてまとめています。 フリートインデックスで検索できる項目の例 モノの名前 属性 シャドウ(名前付き/クラシック) 接続状態 タイプ グループ 以下の画像のように、インデックスが作成される対象を選択することで検索できるようになります。 AWS IoT > 設定 > フリートのインデックス作成の管理 フリートインデックスで可能な検索方式 検索方式 可否 検索例 前方一致 可能 thingName: A*　(Aから始まるモノの名前) 部分一致 不可 - 後方一致 不可 - 完全一致 可能 thingName: test　(名前がtestであるモノ) 正規表現 不可 - クエリ文で利用可能な機能については以下を参考にしています。 https://docs.aws.amazon.com/ja_jp/iot/latest/developerguide/query-syntax.html 前方一致の例として、*だけでなく?を使うことでも検索が可能です。 "thingName:ab?”というクエリ文では「ab」、「abb」、「abc」など、名前に「ab」と 1 つの追加文字を加えたモノを検索します。 https://docs.aws.amazon.com/ja_jp/iot/latest/developerguide/example-queries.html IoTcoreで日本語が使える箇所 IoTcoreでは、各項目について使える文字種が以下のようになっています。 原則、日本語を使うことはできませんが、シャドウでは日本が使えるようになっています。 このため、フリートインデックス(高度な検索)でもシャドウの検索を行う場合のみ日本語が使えます。 英数字(半角) 英数字(全角) - : _ , . @ / # スペース 日本語(カナ文字) 備考(AWSのエラーメッセージを転記) thing名 ○ × ○ ○ ○ × × × × × × × モノの名前に使用できるのは、英数字、ハイフン、コロン、アンダースコアのみです。 タイプ名 ○ × ○ ○ ○ × × × × × × × モノのタイプの名前に使用できるのは、英数字、ハイフン、コロン、アンダースコアのみです 属性名 ○ × ○ ○ ○ ○ ○ ○ ○ ○ × × 属性キーには、英数字および _.,@/:#- のみを使用できます。 属性値 ○ × ○ ○ ○ ○ ○ ○ ○ ○ × × 属性値には、英数字および _.,@/:#- のみを使用できます。 グループ名 ○ × ○ ○ ○ × × × × × × × モノのグループの名前に使用できるのは、英数字、ハイフン、コロン、アンダースコアのみです。 シャドウ名 ○ × ○ ○ ○ × × × × × × × 文字、ハイフン、コロン、またはアンダースコアのみを含む一意の名前を入力してください。シャドウ名にスペースを含めることはできません。 シャドウ値(json形式) ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○(全角/半角) ○ ここからは解釈になります。 何かしらの事情でIoTcoreに日本語を使わざるを得なくなった場合はシャドウで対応することになりそうです。 シャドウ状態データは動的であり、シャドウへのアクセス許可を持つデバイス、アプリ、その他のクラウドサービスによって変更できます。 ドキュメントを見る限り、シャドウに書き込まれる情報は動的なので属性やグループの代わりとしてシャドウを使うのは想定された使い方からは少し外れてしまうように見えます。 シャドウデータオブジェクトに含まれるデータは、他のシャドウや Thing オブジェクトのプロパティ (Thing の属性や MQTT メッセージのコンテンツなど) から独立しています。ただし、デバイスは、必要に応じて、異なる MQTT トピックとシャドウで同じデータを報告できます。 (引用元) https://docs.aws.amazon.com/ja_jp/iot/latest/developerguide/iot-device-shadows.html (補足) シャドウの名前や値に日本語を入れた場合、以下のように表示されます。

はじめに 本番環境でやらかしちゃった人 Advent Calendar 2021 に懺悔の意味も含めて投稿させていただきます。@kyntkです。 思い出すだけで、今でもあの時が鮮明に思い出されて心臓が締め付けられる思いをするので正直書くのも辛かったのですが、二度と惨劇を繰り返さないためにということで書きます。 現在の所属はQiita株式会社ですが、この事故は今の会社ではない時に起きたものですので、Qiitaとは一切関係ありません。 ちなみに、Qiita株式会社もカレンダーを作っているので、よろしければこちらも合わせて見てみてください。 やりたかったのは、ただLambdaの関数名を変えること 事故はLambdaの名前を変えた時に発生しました。Lambda関数の管理はserverless frameworkを使っていました。実際の変更差分としては、たった1行だけだったと思います。 まさか、それがあんな事故につながるなんて想像していませんでした... サービスの概要 サービスの概要としては簡略化すると以下の感じです。 ユーザー登録データが何らかの処理の後にDynamoDBに保存され、そのストリームを受けてLambdaをキックし、後続処理を実行します。その後はユーザーやクライアント、コールセンターへの処理が行われていました。 今回変更を加えたLambdaはイベントの処理を少しする程度で、大したことはしていませんでした。 Lambdaの名前変更 さて、今回はこのLambdaの関数名を変えることになりました。 しかし、実は Lambda関数の名前を変えることはできません!!! serverless (裏側ではCloudFormation) の変更自体は名前を変更したように見えますが、実際はLambdaが削除され、新規関数を作ることになるのです。 (たしかリリース時はdeployコマンド一発でうまく行かず、ごにょごにょした気もします) とはいえ、このオペレーションの時にこのことは知っていました。 実際、staging環境もあるのですが、削除と作成を行い、何も問題が起きないことは検証できました。 削除 → 作成ということで一時的にLambdaが使えなくなる可能性も想定されましたが、リトライされることも検証できたので、ある程度の停止は許容されていました。 Lambdaのリトライについて Lamdbaのリトライの仕組みは呼び出し方によって異なります。 例えば非同期呼び出しでは、2回の再試行をしてくれます。 そして、DynamoDBストリームを使うとストリームの期限切れになるまで再試行を繰り返してくれます。 イベントソースマッピング － ストリームから読み取るイベントソースマッピングは、項目のバッチ全てに対して再試行を実施します。繰り返されるエラーは、そのエラーが解決されるか、項目が期限切れになるまで、影響を受けるシャードの処理を妨げます。 そのため、同時にLambdaが存在する時間さえなければ、問題ないだろうと思っていました。 しかし悲劇は起こった リリースが完了し、ユーザー登録の検証をしている時に、それは気づきました｡ ユーザー登録は問題なくでき、何もエラーは飛んでいませんでした。 検証では、申し込まれたデータを確認するために、後続処理で保存を行う、RDSのデータを確認していました。 しかし、先程登録したデータが見つかりません。だいたいLimit 10でも取れば入ってくるものなので、入ってこないのはおかしいなと思いました。 再度更新しても見つかりません。 ｢ん???｣ ｢というか、さっきと最新のデータ違わない???｣ よくよく見てみると、取得したデータは全てが1秒以内にインサートされたものでした。そうです。1秒以内にとてつもない量のインサートが走っていた ため検証のデータが見つからなかったのです。 このあたりで、なんかやらかしたことに気づきました。 とはいえ、E2Eテストもあるので、たまたまそのタイミングで走っていてそのデータかな?と思ったのですが、テストフラグがたっておらず、データもテストデータではなさそうなものばかりでした。 地獄の時間 他のメンバーへは即座に状況報告をしたのですが、｢名前を変えたらとてつもない量のデータが入ってきた｣ということしか分かっておらず､そうしている間にもデータが各所へ送信されていることが見えていました。 処理を止めるにしても Ctrl-Cボタンのようなものはありません。 また、プログラムのリバートをしても全く治る気がしなかったので、完全に手も足も出ない状況でした。 いわば、rm -rf /を押してしまって、ただ高速に死に近づいているのを見ているような、 終わりの見えない底なし沼にハマっていくような、 富士山の頂上で登山ルートに対して落石ボタンを押してしまって落石が落石を生んでいるような感覚でした。 とにかく出血を止めようと、Lambdaの停止を検討したタイミングで、急にデータのインサートは止まりました。 振り返ってみるとたった1,2分のことでしたが、永遠にも感じる時間でした。 惨劇はなぜおこってしまったのか 各所に報告と収束対応をしながら挿入されたデータを調査したところ、過去1日程度の間で登録されたデータと一致していることが判明しました。 さて、ここで怪しそうなのはDynamoDBストリームです。 ストリームレコードは 24 時間後に自動的に削除されます。 なるほど、DynamoDBストリームは24時間保持されるので、インサートされたデータの期間と一致します。 新規Lambdaが構築されたことで、この残っていた24時間分のストリームの内容が一気に実行されたようです。 さらに振り返って 今回の事故が起きた原因として、 Lambdaの後続処理の冪等性 に問題がありました。後続処理で一度実施済みかどうかを判断するなど、Lambdaがリトライされた時にも問題ないようにしておく必要がありました。 こちらにあるように、 関数にエラーが発生していない場合でも、イベントソースマッピングがキューから同じ項目を 2 回受け取る可能性があります。 と、そもそものイベントソースマッピングの仕様としてエラーが起きなくても同じ処理が2回起きうる状況でした。 それまでは再試行が頻発していなかったので問題になっていませんでしたが、発生していた可能性もあります。 また後から分かったのですが、stagingでのリリース前の検証も行ってはいたのですが、staging環境ではDynamoDBに24時間以内に登録されたデータがなかったため、事前に問題発見をするのは難しかったです。 二度と惨劇を起こさないためにどうしたのか 非同期のイベントベースのシステムは、再実行されても冪等性を保つように設計する もともとの地雷があったとはいえ、その引き金がたった1行の名前変更のリリースということで、ここまで想定するのは当時は難しかったです。 ですが、変更の大小と障害の大小は関係ないということが身にしみて分かったので、いかなる変更でも気を緩めないようにし、惨劇を繰り返さないように対策していきます。

会社からテスト環境であるAWSのEC2に置かれたWordPress環境を本番環境であるさくらレンタルサーバーにデータを移行する際に鬼詰まりしたので共有します。 前提条件 さくらレンタルサーバーに契約して、さくらのURLやコントロールパネルやFTPの情報をもらっている。 DBの移行 旧環境のDBをphpMyAdminなどからエクスポートします。 さくらレンタルサーバーのコントロールパネルからデータベースを新規作成します。 新規作成後はデータベース一覧から対象のDBのphpMyAdminに入って、そこから先ほどエクスポートしたSQLファイルをインポートします。 インポート後はデータを一部変更する必要があります。 wp_optionsテーブルのsiteurlとhomeが旧URLになっていると思うので、こちらを新URLに変更する。 　ファイルの移行 FTPソフトなどを使って、旧環境からローカルPC環境に保存する。 新環境に適応される為に2つのファイルを変更する。 .htaccess AWSでテスト環境を構築した場合、下記のBEGIN/END SAKURA Internet Inc.の記述がない為、こちらを追加する必要がある。 これを追加しなかったため、本ッッ当に詰まりました！！ この記述はコントロールパネルからWordPressをインストールした際に.htaccessの中に生成されたものを流用しました。 # BEGIN SAKURA Internet Inc. <IfModule mod_deflate.c> SetOutputFilter DEFLATE AddOutputFilterByType DEFLATE text/css AddOutputFilterByType DEFLATE application/x-javascript application/javascript application/ecmascript </IfModule> <IfModule mod_expires.c> ExpiresActive On <FilesMatch "\.(css|js)$"> ExpiresDefault "access plus 1 week" </FilesMatch> <FilesMatch "\.(gif|jpe?g|png)$"> ExpiresDefault "access plus 1 month" </FilesMatch> </IfModule> # END SAKURA Internet Inc. # BEGIN WordPress <IfModule mod_rewrite.c> RewriteEngine On RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}] RewriteBase / RewriteRule ^index\.php$ - [L] RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule . /index.php [L] </IfModule> # END WordPress wp-config.php ここはさくらのコンパネで作ったDBの情報を入れるだけです。 他のサイトにもよく解説されているので、難しくないです。 1点だけMySQLのホスト名の部分はデータベースサーバー名を入れます。 この部分はさくらのコンパネのデータベース詳細から確認する事ができます。 // ** MySQL 設定 - この情報はホスティング先から入手してください。 ** // define( 'DB_NAME', '' ); /** MySQL データベースのユーザー名 */ define( 'DB_USER', '' ); /** MySQL データベースのパスワード */ define( 'DB_PASSWORD', '' ); /** MySQL のホスト名 */ define( 'DB_HOST', '' ); /** データベースのテーブルを作成する際のデータベースの文字セット */ define( 'DB_CHARSET', '' ); /** データベースの照合順序 (ほとんどの場合変更する必要はありません) */ define( 'DB_COLLATE', '' ); 構築を進めた後に、新しいURLでサイトが正しく表示されないケースがあります。 その場合はこのファイルの最下部に下記のコードを入れるとうまくいきます。 update_option( 'siteurl', 'http://[サイトURL]' ); update_option( 'home', 'http://[サイトURL]' ); ファイルを変更した後は、新しい環境にFTP接続をして/home/[サイト名]/www/直下に先ほど保存したWPのファイルを置きます。 エラー対応 以上で基本はWordPressの画面が表示されると思いますが、それでもサイトが表示されない場合があります。 その場合は以下の原因も調査してみるといいと思います。 ・パーミッションの変更 ・プラグインの一時無効化

機械学習について学びたいと思い、手始めにAWSの10分チュートリアルを参照しながら機械学習モデルをコーディングしてみました。 <<参考>>Amazon SageMaker を使用して機械学習モデルを構築、トレーニング、デプロイ このチュートリアルに沿ってPythonコードを書くと銀行の顧客データからその顧客が新規商品の契約をしてくれるかどうかを予測する機械学習モデルを簡単に作成できます。 ただ、チュートリアルに沿うだけだと一体何をしているのか分かりづらいので、自分なりにこのコードがしていることをまとめてみましたので参考にしていただければと思います。 具体的にやっていること まず最初にAWS環境にSageMaker環境を構築、その上でjupyter notebookをインストールするという準備が必要になります。 SageMaker：AWSで利用できる機械学習環境 Jupyter notebook：pythonをブラウザ上でコーディングしながらインタラクティブに実行できる環境を提供 ①顧客サンプルデータをpandasデータに変換する 無償で提供されている顧客サンプルデータ(CSV)をS3にダウンロードした上で、pandasライブラリを使って加工しやすいデータに変換します。 pandas：機械学習用にデータを扱いやすくするライブラリ ②③データを学習用データとテスト用データに分離 機械学習のためには学習用データが必要になります。 また、学習完了後、実際に学習できているかを確認するためのテストデータも必要になります。 そのため、①で取り込んだデータをnumpyライブラリを利用して、学習用データとテスト用データに分離します。 numpy：Pythonで利用できる機械学習用のデータ加工ライブラリ ④機械学習モジュールを作成し、学習用データで学習させる XGBoostベースの機械学習モジュールを作成し、学習用データで学習させます。 XGBoost：様々な機械学習アルゴリズムを簡単に利用できるようにしたフレームワーク ⑤学習がうまくいったかどうかテストする 学習が完了したら、学習がうまくいったかどうかをテスト用データによって検証します。 ⑥テスト結果を検証する 実際にどれくらいの精度で学習ができていたかを成功率という形で表示させます。 まとめ こうしたチュートリアルは、手順に沿って作業をしてみるというだけでなく、自分なりに実際を何が行われたのかをまとめてみることで初めてみについたと言えるような気がします。これからもいくつかサンプルコーディングしながら、理解を深めつつ仕事に活かしていきたいと思います。

はじめに 今年のre:Invent2021でECRの新しいスキャン設定が可能になりました。 これまではECR単体としてスキャンの機能がありましたが、このアップデートでAmazon Inspectorに統合されて、EC2のスキャン結果とまとめて確認ができるようになりました。 今回は拡張スキャンを使っていて、脆弱性結果が急に見れなくなったので、その手順と理由を調査した結果を書いていきます。 この記事でわかること ECRスキャンが有効化されている状態でInspectorの無効化有効化を行うと過去の脆弱性結果が見れなくなる Inspectorを有効化している状態で、リポジトリ単位で再度Pushすると過去の脆弱性結果が復活する 長期間Inspectorを無効化した状態でどの程度過去の脆弱性結果が残るかは不明 事前準備 ECRリポジトリは事前に作成しておきます。 今回は拡張スキャンを利用するので、ECR自体のイメージスキャンは無効化したままにします。 ECRのスキャン設定から、拡張スキャンを有効化して、継続スキャンとPush時スキャンが実行されるように設定しておきます。 もしこの時点でAmazon Inspectorが有効化されていなければ、手動でEnableにしておきます。 Dashboard等が見れるようになっていればOKです。 手順 イメージのBuild&Push Pushする用のイメージとして、以下のDockerfileを作成します。 $ cat Dockerfile FROM ubuntu:16.04 あとはECRにPushするだけなので、Dockerfileがあるディレクトリで以下のコマンドを実行します。 $ aws ecr get-login-password --region ap-northeast-1 | docker login --username AWS --password-stdin XXXXXXXXXXXX.dkr.ecr.ap-northeast-1.amazonaws.com $ docker build -t test-repository . $ docker tag test-repository:latest XXXXXXXXXXXX.dkr.ecr.ap-northeast-1.amazonaws.com/test-repository:latest $ docker push XXXXXXXXXXXX.dkr.ecr.ap-northeast-1.amazonaws.com/test-repository:latest 問題なくECR上にイメージがPushされました。 脆弱性スキャン結果確認 今回の設定ではPush時にスキャンが走るようになっているため、脆弱性項目に調査結果を表示というリンクが作成されていることがわかります。 そのリンクをクリックしてみると、脆弱性が21個出ていることが見てわかります。 InspectorのDashboardからも脆弱性を確認できます。 By container imageタブではイメージタグごとにどの程度脆弱性が出ているのかが一覧でわかるようになっています。 ここまではECR拡張スキャンの通常の動作確認になります。 問題の手順 ここからは今回発生した脆弱性結果が消えた際の手順になります。 Inspector無効化 まずInspectorのDashboardからInspectorの無効化を行います。 無効化した後に先ほど確認した脆弱性結果をもう一度ECRから確認してみます。 すると脆弱性結果は見れなくなっており、APIエラーが発生していました。 Inspectorに統合されているので、無効化すると結果が見れなくなっているというのは正しい動作な気がしますが、APIエラーが発生しているのは謎です。 Inspector有効化 今度は無効化したInspectorを再度有効化してみます。 そうすると先ほどまであった脆弱性結果がなくなっており、何もスキャンが実行されていない状態に戻っていました。 また、ECRリポジトリからみると一見脆弱性結果が残っているように見えますが、 リンクをクリックすると先ほどと同じAPIエラーが発生し、スキャン結果が見れなくなっていました。 どうやら、一度Inspectorを無効化してしまうと過去の脆弱性結果は全て消えてしまい、再度有効化したとしても見れなくなってしまうようです。 対応手順 では、どうすれば過去の脆弱性結果を見れるようになるかというと、Inspectorが有効化された状態で同じイメージに対して再度スキャンが実行されれば見れるようになります。 イメージ再Push 先ほど有効化したInspectorをそのままに再度イメージのPushを行うと、 問題なく脆弱性スキャンが実施され、新しくPushされたイメージタグの脆弱性結果が確認できました。 そのあとに先ほど見れなかった過去の脆弱性結果を確認すると、APIエラーは発生せずに最初に確認した結果が見れるようになってました。 Inspectorから見ても2つのイメージタグの脆弱性結果が一覧に表示されているので、過去分が復活していることがわかります。 追加検証 別リポジトリへのイメージPush 試しに先ほどと同じAPIエラーが発生する状況を作った上で、 別のリポジトリにイメージPushした場合でも過去の脆弱性結果が見れるか確認してみます。 まずは別リポジトリのイメージの脆弱性結果を見てみると、APIエラーが出ていますが同時に結果も見えるという不思議な状態になっていました。 最初のリポジトリの脆弱性結果は変わらずAPIエラーが出たままとなっていました。 その状態でInspectorから脆弱性結果を見ると何も表示されていませんでした。 恐らくですが、Inspectorと統合されているECRスキャンを使っている環境で1つ以上APIエラーが発生していた場合、Inspectorのdashboradからの確認もできなくなるようです。 上記のような場合は、APIエラーが発生していると思われるECRリポジトリで新しくイメージのPushをしてあげるとAPIエラーが消えて参照できるようになったので、リポジトリ単位での対応が必要なようです。 おわりに この挙動がバグなのか正常動作なのかはまだ判断が付いていないですが、ECRスキャンが動いている状態でInspectorを無効化すると想定していない挙動になりそうなので、あまりやらないほうが賢明だと思いました。(まぁそんな状況そうそうないとは思いますが)

はじめに Qiitaには多くのAWS資格試験の勉強方法やサービスの紹介はあるので僕は、Notionを使って実際にAWS Solutions Architect - Professional (SAP)の勉強をして資格を取得したのでその際にどのようにNotionを利用したかを共有します。 Notionとは？？ いろいろ出来る情報集約ツールです。 勉強に使ったサービス 今回はこのAWS WEB問題集を中心に利用して勉強しました。 この問題集は7問で1セットになっていて隙間時間に勉強出来るので今回はこれを利用しました。 問題集とか勉強法とかこの記事確認あたりこれらの記事を参考にしてます。 AWS勉強方法 x Notion 僕のSAP勉強用のNotionページです。 勉強に利用している問題集のページを上部に表示して問題の総数をその下に表示して全体の残量を把握できるようにしてます。 利用方法 問題集を解いていき終わったら、Doneにチェック！このページにはDoneにチェックされたものは表示されない様にしています。 （どこまでやったっけ？がなくなります。） DBの最下部にはUncheckの数量を表示して残数を表示。 間違えたところをメモ Notionでは1項目ごとにPageになっていてその問題集を解いたときにわからなかった部分やつまずいたものをメモしておきます。 Pointにはその問題での正答率を入れています。 一覧で表示した際に得点を確認して低いところが苦手なところなので、一通り実施すると苦手が把握できるノートが出来上がります！ 自分で苦手だと思ったところはプロパティにメモを残しておくと一覧で表示した際に確認できます。 復習 これをもとに2回ほど繰り返し。 試験直前 苦手な部分だけを集中的に見直し。 最後に Notionを使うと自由に設定が可能なので、自分に合ったフォーマットを使って勉強を進めることが出来ます。 それだけでも勉強へのモチベーションが上がります。 簡単に列を追加したり、プロパティを追加できるので作っていて楽しいです。 ですが、、若干痒い所に手が届かないことがあるので凝るといろいろ設定を積み重ねていくことになるので自分に合った丁度いい設定を見つけてみてください！

この記事はCloudTech カレンダーの 25 日目です。 概要 2021年5月、元記事クラウドエンジニア(AWS)ロードマップ2021を書籍化するにあたり、「チームで共同執筆する」をテーマに、出版社を巻き込んで出版するまでの工程をまとめた記事です。 もしあなたがコミュニティのオーナーで、 チームを巻き込んでKindle本を出したりするときに役立つかもしれません。 振り返ると、思ったよりも「ウォーターフォール開発」っぽい感じでした。 本ができるまでの流れ フェーズ ウォーターフォールで言うと なにを書くか決める 要件定義 目次を作る 基本設計、詳細設計 担当を決める 担当アサイン 原稿を書く 開発 原稿チェック 単体テスト 仮印刷チェック ステージング環境で結合テスト 最終チェック 総合テスト 印刷所に持ち込み 本番環境デプロイ 体制 担当 役割 人数 オーナー 言い出しっぺで全責任を負う 1名 PMチーム プロジェクトの主体となるサブリーダー集団 8名 執筆者 実際に原稿を書く人 24名 テクニカルレビュワー 技術的なチェックを担当 3名 編集者 マネージャー的にいろいろ 1名 編集者の役割は大切なので、細かい調整が得意そうな人を専任にすべきです。 原稿のどの部分を削るか、目立たせるか、引用チェック、表紙の案、デザイナーとの調整、目次や索引の作成、プロジェクト推進などなどを担当します。 使用ツール（ほぼ無料。Notionのみ月5ドルくらい） Googleドキュメント Googleスプレッドシート Notion Google Meet Slack Adobe Acrobat Reader はじめに コミュニティのSlackで「書籍を出したいからプロジェクトキックオフメンバー募集します！」と発言。 手を上げてくれたのは7名*。1人ずつオンラインミーティングでキャラクターなどを把握。 * 後に8人に 7名は「PMチーム」として各章のマネジメントを担当してもらう。 簡単なスライドを作って概要を説明。 当初はKindle出版（無料配布）の予定でしたが、後に技術評論社から商業出版のお誘いがあったので全力で乗っかります。 なにを書くか決める - 要件定義 ここが一番大変。 PMチーム7名 + 編集者とタスク整理やコンセプトの再確認をする。 ・この本を読むことで得られるメリットは何か？ ・技術レベルはどの程度に設定するか？ ・届けたい読者像はどんなものか？（ペルソナの設定） ・文章はどのような記載ルールとするか？ 決定事項はNotionにまとめること。Slackだと流れてしまうので。 ■実際のNotionのトップ画面 ペルソナ分析を元に、それがどの成果物に影響するのかマッピングをする。 チームで意識を合わせるため、可能な限り具体的にする。 数回会議を行い、「中級者向けのAWS技術書や記事を読めるようになり、自走できるようになるまでを手助けする書籍」にコンセプトを決定。 目次を作る - 基本設計、詳細設計 Googleスプレッドシートに目次構成を作成します。 執筆者 - 原稿を執筆する 担当PM - 執筆者の進捗や記載ルールに沿っているかをチェックする（2名体制） テクニカルレビュアー - 技術的なジャッジを行います 注意* 構成を手直ししたので実際の書籍の目次とは異なります 担当を決める - 担当アサイン 各項目の執筆者を再びSlackで募集します。 募集の際に執筆ルールなどをまとめたドキュメントを執筆者に連携します。 ■実際の執筆にあたっての依頼ドキュメント（一部） 「ですます調」などライターズガイドを用意しましたが、実際にはあまりルールを気にせず筆を進めてもらい、後から手直しする方が進捗が良かったです。 なお、改めて目的意識共有のために「なぜこの本を作るのか？」というスライドを作成し、執筆依頼時に連携しました。 意思疎通のためには何か目に見えるものを作成するのが大切です。 原稿を書く - 開発 執筆はGoogleドキュメントを使い、出来上がった原稿や図表は章ごとのGoogleドライブのフォルダに格納してもらいます。 （なお、図表は出版社側で後工程で全て作り直すので、この段階では仮作成レベルで良いとのことでした。） 各章ごとにSlackチャンネルを作成し、執筆者と担当PMをアサインして各自で進めてもらうようにしました。 方針やトラブルがあればオーナーも議論に参加します。 ■実際のSlack画面 余談ですが、この時に感じたチーム運営の方法論を簡単なスライドにまとめてみました。 原稿チェック - 単体テスト 原稿の指摘はGoogleドキュメントのコメントで行い、議論が発展しそうであればSlackのスレッドでやり取りするルールを設けました。 ■実際の原稿 編集者から「経験上、原稿を事前公開しても売り上げはそれほど変わらなかったよ」の声を受け、SNSで一般レビュワーを募集し、仮完成の原稿公開を決定します。 ある程度チェックの目処がついた段階で募集を開始し、 100名以上の参加者が集まり各原稿に同じ流れでコメントを入れてもらいました。 仮印刷チェック - ステージング環境で結合テスト 編集者がPDFで仮印刷版を作成する。 Googoleドライブにアップし、コメント機能で指摘。 図表なども配置されレイアウトが整っているので、文字だけの段階より格段に誤字脱字等の指摘が目につくようになります。 仮印刷チェックはコミュニティメンバー1000名を巻き込みました。 最終チェック - 総合テスト 表紙や帯、奥付、目次など、印刷してOKの状態まで持っていく。 最終的な指摘があれば取り込み、編集者がPDFで印刷版を作成する。 ここでコードの記号が全角になっているミスに気づきました。電子版をコピペしたら動かなくなるところでした…危ない危ない。最後まで油断なりません。 印刷所に持ち込み - 本番環境デプロイ 無事に納期通りに完了しました。 気づき パレートの法則がほぼ当てはまった 10名集めたら、必ず1〜2名はすごくやる気のある人が出てくる。 逆もまた然り。例外なく、とても不思議でした。 そのため、コミュニティ規模が大きいとやる気のある人も多くなるため、有利に進めるかと思われます。 イラストレーターは偉大 初学者向けの本なのでキャッチーなイラストが欲しい＆技術書典にあるような萌え絵の方が目を引くのではないか？との意見もあり、Twitterで2年くらい相互フォローの「AWSサービス擬人化イラストレーター」zeroさんにお願いすることに。 AWS愛を持ってイラスト制作をしていただきました。いい感じです。 ページ数制限により泣く泣くカット AWSとは別にGitやVScodeなど各種ツールを紹介する項目もありましたが、ページ数の関係で泣く泣くカットが決定しました。 元々書籍と連動する特設Webサイト（確認テスト、動画解説を提供）を用意していたので、そちらのコンテンツとして提供する方針としました。 執筆にご尽力いただいた方には大変申し訳なかった…。 最後に 早く行きたければ、ひとりで行け。遠くまで行きたければ、みんなで行け。 If you want to go fast, go alone. If you want to go far, go together. どれだけ知識を深めてもゴールが無いように、ITインフラ・クラウドの世界も学習に終わりはありません。 特にコンピューター界隈は、少し分野が違うだけで専門家の知識に到底及ばないものです。 私一人では達成できなかったことを「チーム執筆」は実現してくれました。 今回の書籍は、各参加者の得意分野が発揮され、苦手分野をカバーでき、クオリティの高いものになったと振り返ります。 この記事を通じてチーム執筆を目指す方の助けとなり、最終的にはIT業界のレベルアップに貢献できれば幸いです。

AWS CloudFront + S3構成について まず、AWS CloudFront + S3で構成するパターンは下記2パターンあります。 CloudFront のオリジンにS3バケットそのものを指定する構成 CloudFront のオリジンにS3バケットのStatic website hostingのエンドポイントを指定する構成 ですが、現状、2のパターンはS3への直接アクセスを許可してしまうため、セキュリティとして非推奨のようです。 なので1のパターンで構成することを考えます。 「 1. CloudFront のオリジンにS3バケットそのものを指定する構成」ではデフォルトルートオブジェクトのファイル名(index.html)をディストリビューションで指定しているオリジンのルートにしか設定できません。 そのため、サブディレクトリへのパス(例) xxx.com/aaa/へアクセスすると、そのディレクトリにindex.htmlがあったとしても403エラーとなります。 これを解決するには Lambda@Edgeを作成します。 Lambda@Edge作成手順 Lambda@Edge作成の手順として下記のようになります。 Lambda関数作成 コンソールから「関数の作成」をクリックして関数を作成する ※注意：Lambda@Edge 関数の作成は、現時点ではバージニアリージョンでしかできないようですので、us-east-1（米国東部：バージニア北部）を選択します Lambda関数のコードを実装 下記のような実装をします。（参考リンクにあるソースをそのまま使用できます） CloudFrontイベント「オリジンリクエスト」イベントをハンドルし、リクエストパスの末尾が「/」で終わっているものを「/index.html」に置き換える。 Lambda関数を CloudFront ディストリビューションに関連付けるために必要なIAM アクセス許可の設定をする 参考：https://docs.aws.amazon.com/ja_jp/AmazonCloudFront/latest/DeveloperGuide/lambda-edge-permissions.html Lambda関数のトリガーを設定 CloudFrontを選択し、下記を設定する ディストリビューション：任意のディストリビューション CloudFrontイベント：オリジンリクエスト レプリケートの有効化：チェックする これでサブディレクトリのパスにアクセスしてもindex.htmlを返すようになりました！！！ 参考： CloudFront が、サブディレクトリからデフォルトのルートオブジェクトを返さないのはなぜですか? Lambda@Edgeの設定例 S3 オリジンへの直接アクセス制限と、インデックスドキュメント機能を共存させる方法 Lambda@Edgeのログ確認方法 CloudWatch LogsでLambda@Edgeのログの確認ができます。 CloudWatchコンソール https://ap-northeast-1.console.aws.amazon.com/cloudwatch/home?region=ap-northeast-1 ※CloudFrontにアクセスしたとき、Lambda@Edgeを動作させたエッジロケーションによってログ出力されるリージョンが決定されます。（Lambda@Edge作成したときに選択したリージョンに出力されるわけではないことに注意です） 参考： https://dev.classmethod.jp/articles/where-is-the-lambda-edge-log/

AWS CloudFront + S3構成について まず、AWS CloudFront + S3で構成するパターンは下記2パターンあります。 CloudFront のオリジンにS3バケットそのものを指定する構成 CloudFront のオリジンにS3バケットのStatic website hostingのエンドポイントを指定する構成 ですが、現状、2のパターンはS3への直接アクセスを許可してしまうため、セキュリティとして非推奨のようです。 なので1のパターンで構成することを考えます。 「 1. CloudFront のオリジンにS3バケットそのものを指定する構成」ではデフォルトルートオブジェクトのファイル名(index.html)をディストリビューションで指定しているオリジンのルートにしか設定できません。 そのため、サブディレクトリへのパス(例) xxx.com/aaa/へアクセスすると、そのディレクトリにindex.htmlがあったとしても403エラーとなります。 これを解決するには Lambda@Edgeを作成します。 Lambda@Edge作成手順 Lambda@Edge作成の手順として下記のようになります。 Lambda関数作成 コンソールから「関数の作成」をクリックして関数を作成する ※注意：Lambda@Edge 関数の作成は、現時点ではバージニアリージョンでしかできないようですので、us-east-1（米国東部：バージニア北部）を選択します Lambda関数のコードを実装 下記のような実装をします。（参考リンクにあるソースをそのまま使用できます） CloudFrontイベント「オリジンリクエスト」イベントをハンドルし、リクエストパスの末尾が「/」で終わっているものを「/index.html」に置き換える。 Lambda関数を CloudFront ディストリビューションに関連付けるために必要なIAM アクセス許可の設定をする 参考：https://docs.aws.amazon.com/ja_jp/AmazonCloudFront/latest/DeveloperGuide/lambda-edge-permissions.html Lambda関数のトリガーを設定 CloudFrontを選択し、下記を設定する ディストリビューション：任意のディストリビューション CloudFrontイベント：オリジンリクエスト レプリケートの有効化：チェックする これでサブディレクトリのパスにアクセスしてもindex.htmlを返すようになりました！！！ 参考： CloudFront が、サブディレクトリからデフォルトのルートオブジェクトを返さないのはなぜですか? Lambda@Edgeの設定例 S3 オリジンへの直接アクセス制限と、インデックスドキュメント機能を共存させる方法 Lambda@Edgeのログ確認方法 CloudWatch LogsでLambda@Edgeのログの確認ができます。 CloudWatchコンソール https://ap-northeast-1.console.aws.amazon.com/cloudwatch/home?region=ap-northeast-1 ※CloudFrontにアクセスしたとき、Lambda@Edgeを動作させたエッジロケーションによってログ出力されるリージョンが決定されます。（Lambda@Edge作成したときに選択したリージョンに出力されるわけではないことに注意です） 参考： https://dev.classmethod.jp/articles/where-is-the-lambda-edge-log/

AWS Lambda layersを作成/管理できるツールlamblayerを作りました。 現在はPythonにのみ対応しています。 できること pipでinstallできるpakcageのビルド済みlayerを作成する（←これがとっても便利） ローカルのディレクトリからlayerを作成する Lambdaにlayerを設定する jsonの設定ファイルからパラメータを読み取って内部でLambdaのAPIを叩いています。 Quick Start 現在はpipでのみインストール可能です。 pip install git+https://github.com/YU-SUKETAKAHASHI/lamblayer.git@v0.1.0 lamblayer initで既存のLambdaを取り込みます。 $ mkdir quick_start $ cd quick-start $ lamblayer init --function-name quick_start 2021-12-24 10:13:41,225: [INFO]: lamblayer : v0.1.0 2021-12-24 10:13:42,132: [INFO]: starting init quick_start 2021-12-24 10:13:42,318: [INFO]: createing function.json 2021-12-24 10:13:42,319: [INFO]: completed するとfunction.jsonが生成されるので、以降はfunction.jsonを編集してlamblayer setでLambdaにlayerをセットすることができます。 $ lamblayer set 2021-12-24 10:23:34,041: [INFO]: lamblayer : v0.1.0 2021-12-24 10:23:35,312: [INFO]: starting set layers to quick_start 2021-12-24 10:23:35,723: [INFO]: completed Create layer lamblayer createでlayerを作成することもできます。 pipでインストール可能なパッケージのビルド済みlayerの作成と、 ローカルのディレクトリからlayerを作成することの２種類ができます。 1. pipでインストール可能なパッケージのビルド済みlayerの作成 こんな感じにパッケージ名とバージョンをjsonで書けば、 lamblayer creage --packages packages.jsonでLambdaで実行可能なビルド済みのlayerが作成されます。 これがとっても便利で、Dockerを立ち上げてpip installしてzipつくって...という作業から解放されます。最高！ 内部ではこちらの記事のAPIを叩いています。 packages.json { "Arch": "x86_64", "Runtime": "py38", "Packages": [ "numpy==1.20.2", "requests" ] } 作成するlayerの名前や実行環境などは別にjsonで書いてください。--layerオプションでファイルを指定できます。 layer.json { "LayerName": "numpy_requests", "Description": "numpy==1.20.2, requests", "CompatibleRuntimes": [ "python3.7", "python3.8", "python3.9" ], "LicenseInfo": "" } ※まだこちらの記事のAPIが公開されていないため、現在はこの機能は利用できません? Coming soon! 2. ローカルのディレクトリからlayerを作成する ローカルのディレクトリを指定して、自作パッケージのlayerを作成することもできます。 lamblayer create --src my_package layerを作成するときの地味な沼ポイントとして、ファイルたちをpythonディレクトリ以下に配置する必要がありますが、それもlamblayerがやってくれます。 --wrap-dirオプションでディレクトリ名を指定してあげれば、--src以下のファイルをラップしたlayerを作成することができます。 これで自分でpythonフォルダに配置し直す手間はありません。 lamblayer create --src my_package --wrap-dir1 python Set Layer lamblayer setでLambdaにlayerをセットすることができます。こちらは--functionオプションで設定ファイルを指定できます。 function.json { "FunctionName": "quick_start", "Layers": [ "arn:aws:lambda:ap-northeast-1:249908578461:layer:AWSLambda-Python38-SciPy1x:29", "numpy_requests", "my_package" ] } function.jsonでlayer名のみを指定した場合は自動で最新のバージョンのARNに補完してくれます。これもとっても便利で、lamblayer createで作成した最新バージョンのlayerをセットするには、function.jsonにlayer名のみを指定してlamblayer setすればOKです。 その他のcommand 現在は、init, create, set, listコマンドがあります。 最後に GitHub Actionsでも利用できるようにlamblayerをインストールするactionも作りました。 詳細はREADMEに記してあるのでご覧ください。 どうぞご利用ください！

１．今回の記事の内容 この記事ではAWS Fault Injection Simulator(AWS FIS) を使用した『実験』について設定方法などを記述しています。 AWS FISは2021年の3月から利用可能となったサービスで、そのころから触ってみようと思っていたものの、だいぶ時間が経ってしまいました…。 このため、既にFISについてはいろいろな方が試されており、新鮮さはない情報となりますが、使ったこのない方でもすぐに試せるようにできるだけ細かく設定方法を記述していこうと思います。 ２．AWS FISとは AWS Fault Injection Simulator（AWS FIS）とは、稼働中のシステムに対して意図的に障害を発生させることできるAWSのマネージドサービスです。 こういった本番環境に意図的に障害を発生させることで、システムの可用性、信頼性を高めていく取り組みを”カオスエンジニアリング”と呼びます。 ”カオスエンジニアリング”はあの動画配信サービスの「NetFlix」が2010年ぐらいから取り入れたことで世に知られるようになり、現在ではAmazon、Google、Meta Platformsなど多くのテック系企業でも行われているようです。 余談ですが、私が住む東北には「カオス」という名のパチンコ屋があります。 ３．実験環境の構築 AWS FISでは意図的に障害を発生させることを”実験”と称して行います。 その実験をするには環境が必要となりますので、今回は画像のようなシンプルなWordPress環境を構築しました。 この実験環境、当初LightSailで作れば簡単かなとやってみましたが、簡単だけどインスタンスIDとか中身が見えなかったので、ではElasticBeanStalkではどうかなと思いましたが、なんだかんだでややこしそうだったので、結局手作業でポチポチ作りました。 こういったことはすぐに作れるように慣れておかないといけないなと反省。 なお、EC2インスタンス（Amazon Linux2）にはCloudWatchエージェントがインストールされており、メモリ使用量などのリソースの情報が取得可能な状態となっています。 ４．AWS FISの設定 この章では、FISでの実験の設定手順について順を追って説明していきます。 FISでは、以下のようなアクションをサポートしています。 ・Fault injection actions ・Wait action ・CloudWatch actions ・Amazon EC2 actions ・Amazon ECS actions ・Amazon EKS actions ・Amazon RDS actions ・Systems Manager actions FISについて書かれている過去の投稿記事などでは、EC2インスタンス停止などをされている方が多かったので、今回は「Systems Manager actions」での実験、具体的には以下のような実験を実施します。 ・aws:ssm:send-command/AWSFIS-Run-CPU-Stress（CPU負荷を上げる） ４－１．IAM実行ロールの作成 FISの実験を実行するためのIAMロールを事前に作成します。 実験の”アクション”により実行対象となるAWSサービスやActionも異なるため、それに応じて権限設定も変えるのですが、今回は面倒なので公式ドキュメントにある”全部のせ”的なポリシーを使用してロールにアタッチします。 ①ポリシーの作成 IAM ＞　ポリシー　＞　ポリシーを作成 ・「JSON」タブを開きます。 ・以下のポリシーに書き換えてポリシーを作成します。 ・今回ポリシー名は「Test-FIS-Policy」としました。 Test-FIS-Policy { "Version": "2012-10-17", "Statement": [ { "Sid": "AllowFISExperimentRoleReadOnly", "Effect": "Allow", "Action": [ "ec2:DescribeInstances", "ecs:DescribeClusters", "ecs:ListContainerInstances", "eks:DescribeNodegroup", "iam:ListRoles", "rds:DescribeDBInstances", "rds:DescribeDbClusters", "ssm:ListCommands" ], "Resource": "*" }, { "Sid": "AllowFISExperimentRoleEC2Actions", "Effect": "Allow", "Action": [ "ec2:RebootInstances", "ec2:StopInstances", "ec2:StartInstances", "ec2:TerminateInstances" ], "Resource": "arn:aws:ec2:*:*:instance/*" }, { "Sid": "AllowFISExperimentRoleECSActions", "Effect": "Allow", "Action": [ "ecs:UpdateContainerInstancesState", "ecs:ListContainerInstances" ], "Resource": "arn:aws:ecs:*:*:container-instance/*" }, { "Sid": "AllowFISExperimentRoleEKSActions", "Effect": "Allow", "Action": [ "ec2:TerminateInstances" ], "Resource": "arn:aws:ec2:*:*:instance/*" }, { "Sid": "AllowFISExperimentRoleFISActions", "Effect": "Allow", "Action": [ "fis:InjectApiInternalError", "fis:InjectApiThrottleError", "fis:InjectApiUnavailableError" ], "Resource": "arn:*:fis:*:*:experiment/*" }, { "Sid": "AllowFISExperimentRoleRDSReboot", "Effect": "Allow", "Action": [ "rds:RebootDBInstance" ], "Resource": "arn:aws:rds:*:*:db:*" }, { "Sid": "AllowFISExperimentRoleRDSFailOver", "Effect": "Allow", "Action": [ "rds:FailoverDBCluster" ], "Resource": "arn:aws:rds:*:*:cluster:*" }, { "Sid": "AllowFISExperimentRoleSSMSendCommand", "Effect": "Allow", "Action": [ "ssm:SendCommand" ], "Resource": [ "arn:aws:ec2:*:*:instance/*", "arn:aws:ssm:*:*:document/*" ] }, { "Sid": "AllowFISExperimentRoleSSMCancelCommand", "Effect": "Allow", "Action": [ "ssm:CancelCommand" ], "Resource": "*" } ] } ②ロールの作成 IAM ＞　ロール　＞　ロールを作成 ・一般的なユースケースでひとまずEC2を選択 ・Attach アクセス権限ポリシーで、先ほど作成したポリシーをアタッチします。 ・ロール名「Test-FIS-Role」としました。 続けてFISの信頼ポリシーをロールに適用させます。 IAM ＞　ロール　＞　今回作成したロールを開きます。 ・信頼関係タブを開き、信頼関係の編集をクリックします。 ・信頼関係の編集で以下のポリシーに書き換えます。 ・信頼ポリシーの更新を行います。 Test-FIS-Role（信頼ポリシー） { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": [ "fis.amazonaws.com" ] }, "Action": "sts:AssumeRole", "Condition": {} } ] } ４－２．CloudWatchでのアラーム作成 次は実験を行った際にどのような変化が起こるのかを知るために、CloudWatchのアラームを設定します。 今回の実験では「CPUストレス」の実験を行うので、以下のCPUのメトリクスについてアラームを設定します。 アラーム名 監視項目 トリガー閾値 ポーリング間隔 FIS-CPUUtilization AWS/EC2 CPUUtilization 80%以上 1min またこれに加えて、「Synthetics Canaries」でのURL監視(1min)を加えます。 ４－３．FISでの実験テンプレートの設定 実験テンプレート「AWSFIS-Run-CPU-Stress」の作成 テンプレート本体の設定 アクションの設定 ※上記の画像で隠れている部分 アクションタイプ>>　aws:ssm:send-command/AWSFIS-Run-CPU-Stress documentArn>>　arn:aws:ssm:ap-northeast-1::document/AWSFIS-Run-CPU-Stress documentParameters>>　{"DurationSeconds":"180", "InstallDependencies":"True"} ・DurationSeconds– 必須. CPU ストレステストの継続時間 (秒単位)。 ・CPU– オプション. 使用する CPU ストレッサの数。デフォルト値は、すべての CPU ストレッサーを使用する 0 です。 ・InstallDependencies– オプション. 値がtrueでは、必要な依存関係をインストールします (まだインストールされていない場合)。デフォルト: true。依存関係stress-ng。 ターゲットの設定（対象となるEC2インスタンスのIDを指定します。） 停止条件（4-2で作成したアラームを設定します。） ５．実験 長らくお待たせしました。いよいよ実験開始です。 ５－１．EC2インスタンスへのCPUストレステスト実験 実験テンプレートを指定して開始します。 実験が開始されるとすぐにtopコマンド上の「stress-ng-cpu」コマンドが実行されて、CPU使用率が100%で張り付きます。 次にSyntheticsのHARファイルを覗いてみると、 明らかに応答速度が落ちていることがわかります。 ただ、停止条件にしたアラートですが、CPUストレスの継続時間が180secと短かったせいか、閾値まで達しませんでした。 ６．まとめ 今回初めてカオスエンジニアリングの片鱗に触れてみました。 このような単純な構成では、想定通りの動作を確認するだけであまり意味はないかもしれないですが、もっと大規模で複雑な構成の場合こそ、大きな威力を発揮するサービスだと思いました。 あと、それ以外の用途としては「監視アラームやAutoScalingの動作確認」用としての使い道もあるのかなと。 EC2とかだとSSHでログインして手動でstressコマンドを打ってCPU負荷を上げて確認をしたりしていましたが、FISであれば、テンプレートを作っておきあとはターゲットを変えるだけで何度でも同じ実験を行うことができます。 また、色々な監視項目を見ながらの勉強用途として動作を確認するのも良いかもしれないですね。 以上で今回の記事は終わりとなります！

背景・目的 Schema Conversion Tool（以降、SCTという。）を使う機会があるので事前に学ぶ。 結論 SCTでできることは、スキーマ変換以外にも、SQLの書き換えやRedshiftへの最適化などが可能。 内容 SCTとは Schema Conversion Toolの略。 以下に、ドキュメントの内容を転記する。 AWS Schema Conversion Tool (AWS SCT) を使用すると、データベースエンジン間で既存のデータベーススキーマを変換できます。リレーショナル OLTP スキーマやデータウェアハウススキーマを変換できます。変換されたスキーマは、Amazon Relational Database Service (Amazon RDS) MySQL、MariaDB、Oracle、SQL サーバー、PostgreSQL Amazon Aurora スター、または Amazon Redshift クラスターに適しています。変換されたスキーマは、Amazon EC2 インスタンスでデータベースと共に使用するか、Amazon S3 バケットでデータとして保存することもできます。 データベース間のスキーマを変換できる 対象は、OLTPのRDB、DWHなど サポートされている変換 2021/12/24現在の対象を以下にまとめておく。詳細はドキュメントを参照。 OLTP ソース ターゲット Aurora MySQL Aurora PostgreSQL MariaDB SQL Server MySQL PostgreSQL DynamoDB SQL Server ◯ 互換版（※1） ◯ 互換版（※1） ◯ ◯10.2および10.3 ◯ ◯ - MySQL（バージョン5.5以降） ◯ ◯ - - - - - Oracle（バージョン10.2以降） ◯ ◯ ◯10.2および10.3 - ◯ ◯ - IBM Db2 LUW(バージョン 9.1、9.5、) ◯ ◯ ◯10.2および10.3 - ◯ ◯ - Apache Cassandra (バージョン 2.0、3.0、3.1.1、および 3.11.2) - - - - - - ◯ Sybase ASE (12.5、15.0、15.5、15.7、16.0) ◯ ◯ - - ◯ ◯ - ※1 互換版とそれ以外の違いの違いが不明。後ほど調べる。 DWH ソース ターゲット Redshift Greenplum データベース (バージョン 4.3 以降) ◯ Microsoft SQL Server (バージョン 2008 以降) ◯ Netezza (バージョン 7.0.3 以降) ◯ Oracle (バージョン 10 以降) ◯ Teradata (バージョン 13 以降) ◯ Vertica (バージョン 7.2.2 以降) ◯ 概要 以下に、機能についてのドキュメントを転機する。 AWS SCTには、ソースデータベースのデータベーススキーマをターゲット Amazon RDS インスタンスと互換性のある形式に自動変換するための、プロジェクトベースのユーザーインターフェイスが用意されています。ソースデータベースのスキーマを自動変換できない場合、AWS SCTでは、ターゲット Amazon RDS データベースで同等のスキーマを作成する方法についてのガイダンスが表示されます。 UIで操作可能 プロジェクトベースで作成される 変換できない場合、ガイドされる（詳細は別途でまとめる予定） AWS SCT に関するフィードバックを提供できます。バグレポートの提出、機能リクエストの提出、一般情報の提供ができます。 フィードバックを提供できる。（詳細は別途でまとめる予定） その他機能 以下に、スキーマ変換以外の機能を記載する。 データ抽出エージェントを使用し、Redshiftへの以降を準備するため、DWHからデータを抽出できる。 DMSエンドポイント、タスクをを作成できる。またSCTからタスクの状況をモニタリングもできる。 RDSやRedshiftへ変換できない場合、SCT拡張パックウィザードを使用して、変換できない機能をエミュレートできる Lambda、Pythonライブラリをインストールする Redshiftデータベースを最適化する。ソートキーと分散キーをレコメンドする。 RDSインスタンスに、オンプレミスのDBスキーマをコピーできる。 クラウドへの移行や、ライセンスタイプの変更にかかるコスト試算に役立てる。 アプリケーションSQLを変換できる。（詳細は別途まとめる予定） ETL変換できる。（詳細は別途まとめる予定） 考察 RDBだけかと思いきや、KVS（Cassandra）もサポートされている。 DWHはかなりのラインナップがある。 触ってみないと実感がわかない。いくつか不明な仕様があるので、後ほど確認し本ページを更新する予定。 参考

はじめに この記事は、Supershipグループ Advent Calendar 2021の24日目の記事になります。 組織がスケールするにあたり、アジリティを下げずにセキュリティを高めていくためには、正しいクラウド戦略が必要です。 本記事はクラウドインフラ（AWS）でセキュリティを実現するための考え方や、マルチアカウントの運用方法について記載しています。 前半はCloud Center of Excellence（以下、CCoE）の観点から、セキュリティ・ガバナンスを実現するために、フレームワークの考え方や、ガードレールなどクラウドにおけるセキュリティ対策の考え方について記載していきます。 後半はセキュリティ・ガバナンスの実装方法として、AWS Control Towerを軸に、関連するAWSサービスの概要やポイントについて解説しています。 ※CCoEについては以前書いたCloud Center of Excellenceとは何かを参照。 ※本記事の内容は、あくまで考え方の一例であり、必ずしも全ての考え方がシステムに適合したり、ここに書いている内容で満たされている訳ではありません。 クラウドセキュリティの考え方 今後もDX促進によりビジネスでクラウドを活用した動きは、これからも加速してくるでしょう。 背景として、2021年度（令和3年度）税制改正に伴い、DX投資促進税制という制度が新設されました。国として企業のクラウドシステム活用を支援しています。 こうした中、先日、田舎の病院がサイバー攻撃を受けたことが発覚し、ニュースになりました。 病院がサイバー攻撃を受けたとき消えた電子カルテの衝撃 クラウドシステムにおけるセキュリティの考え方は、従来のオンプレミスのシステムにおけるセキュリティの考え方とは異なります。 責任共有モデルを理解し、利用者側の責任範囲を明確にすることで、セキュリティ対策の意味が問われます。 課題解決は、目的と手段を混合しないことが重要です。 今のクラウドはセキュリティをはじめ、色々なサービスが存在しますが、サービスやツールを使用することを目的にしてはいけません。 何故セキュリティ対策をやるのか？ どこまでセキュリティ対策をやるのか？ 誰のためにセキュリティ対策をやるのか？ 何を根拠にセキュリティ対策を保証するのか？ 本質的に考え抜くために、セキュリティ対策について深掘りしていきましょう。 フレームワーク 従来、オンプレミスのシステムでインフラ基盤の新規構築を行う場合、非機能要求グレードを利用して要件定義を行うことが多かったのではないでしょうか。 オンプレミスでミッションクリティカルなシステムを構築する場合、非機能要求グレードを基に、ベースモデルを選定し、以下の各項目を定義していきます。セキュリティについても、機能要求グレードの中で要件を定義し、定義した要件を基にセキュリティ設計を行います。 可用性 性能・拡張性 運用・保守性 移行性 セキュリテイ システム環境・エコロジー 現在は非機能要求グレード2018が最新版となっています。 しかし、クラウドファーストの今、非機能要求グレードを用いてクラウドシステムの要件定義を行うのは、難しいと思います。理由として、非機能要求グレードがオンプレミスの観点で書いてある内容が多いため、クラウドやコンテナを活用している今時のシステムには向いてないからです。 では、クラウドシステムのセキュリティについて考える場合、何を基に手掛けるのが最善でしょうか？ そこで登場するのがNIST Cyber Security Framework（以下、CSF）などのフレームワークになります。 なお、日本では総務省が情報セキュリティ対策の指針として、以下のガイドラインを公開しています。 「クラウドサービス提供における情報セキュリティ対策ガイドライン（第3版）」（案）に対する意見募集の結果及び「クラウドサービス提供における情報セキュリティ対策ガイドライン（第3版）」の公表 NIST Cyber Security Framework（CSF） CSFは米国国立標準技術研究所（NIST）が公開している、サイバーセキュリティフレームワークです。 大統領令を受けて、NISTが政府や民間から意見を集めて作成したベストプラクティスになります。 米国の政府機関に関わるシステムや、重要インフラなどはCSFの採用が義務付けられているため、如何にCSFの正当性が分ります。 なお、CSFは重要インフラでの採用を意図したものではありますが、業界や規模を問わず、あらゆる組織の規範とされています。 AWS クラウドセキュリティはCSFを基に設計されています。 CSFは以下の構成となっています。 コア（セキュリティ対策の分類） 識別 防御 検知 対応 復旧 ティア（セキュリティ対策に対する、組織の成熟度を4段階で数値化） プロファイル（As Is/To Be） コアは重要インフラの分野に共通となるセキュリティ対策、期待されるや効果、参考情報をまとめたものになります。また、5つの機能で構成されています。 ティアはリスク情報を活用したアプローチがどこまで達成されているかなど、組織の成熟度を評価します。 プロファイルは現在のプロファイル（今の状態）と、目標のプロファイル（目指す状態）を比較し、ギャップを見極めます。また、リスクアセスメントを行なって必要なリスクを決定し、優先度付けなどを行います。なお、プロファイルについてはフォーマットは決まっていません。 AWSの米国国立標準技術研究所 (NIST)から、CSFを基にAWS仕様でカスタマイズされたマトリクスのドキュメント（xlsx）がダウンロードできます。 上記、ダウンロード可能なCSFのマトリクスは英語になっています。シンプルにCSFの日本語版が欲しい場合は、以下に示すIPAのIPAのセキュリティ関連NIST文書からダウンロードできます。 [その他のNIST文書] 導入するシステムの要件によっては、全てを満たす必要がなく、適合しない場合があると思います。この様なフレームワークを使用する際は、組織やシステムの規模に合わせて、必要な項目のみ使用するなどフレキシブルに適用する方法が良いでしょう。 CSFを基に本記事で解説するAWSの関連サービスが以下になります。 ガードレールの考え方 ここ数年、セキュリティ業界ではゼロトラストセキュリティという考え方が浸透しつつあります。 従来の保護すべきデータは社内に存在し、社外からはアクセスできないなど境界線で考えるセキュリティ対策ではなく、全ての通信やデバイスを信用せずに検証することで、脅威を防ぐというセキュリティモデルです。 注意すべき点として、ゼロトラストセキュリティはフレームワークではありません。そのため、共通言語が不足しています。現在の状況としては、SP 800-207として文書化されています。日本ではPwCコンサルティング合同会社が翻訳・公開しています。興味ある方は以下をご参照ください。 NIST SP800-207 「ゼロトラスト・アーキテクチャ」の解説と日本語訳 合わせて、AWSが提唱するガードレールの考え方も重要です。 従来のゲート型と、ガードレール型のイメージは以下になります。 ゲート型 境界線を定義し、ルールベースでセキュリティを実現するための考え方 ガードレール型 禁止操作の制限及び、危険な設定を検出してセキュリティ・ガバナンスを実現するための考え方 ガードレールは開発者に自由を与えつつ、絶対に超えてはいけない領域を制限することで、セキュリティ・ガバナンスをコントロールします。 ビジネスモデルに応じたクラウドセキュリティ 現実は理想に対して、複雑です。 ビジネスモデルにより、システム開発やクラウドを使用する状況は異なります。 新規構築/リプレイス/システム移行 一つのサービスやプロダクト 共通基盤 基幹系システムなど大規模なサービス 複数ドメイン 会社の中で複数の事業を展開し、事業毎に別々のクラウドが混在する環境 クラウドを安全に利用するために、ビジネスモデル、組織の規模、カルチャー等を踏まえて、汎用的に補完できるセキュリティの考え方は存在するのでしょうか？ 私は、セキュリティの原理原則に従い、フレームワークの適用及び、ガードレールを整備し維持し続けることが、最善ではないかと考えています。 また、サイバーハイジーンの考え方に従ってエンドポイントの脆弱性を排除、可視化、すなわち日々の運用がセキュリティを作ります。そして、時代に合わせてゼロトラストセキュリティなど新しい考え方を適用し改善し続けていくのが理想だと思います。 マルチアカウント運用 組織が事業活動を行うために、内部統制の仕組みが必要な様に、クラウドを効率かつ効果的に利用するために、マルチアカウント運用は必要不可欠な仕組みです。 マルチアカウント運用のベネフィットは以下になります。 環境の分離 開発/ステージング/本番環境等を分離し、セキュアな運用を実現 請求の分離 サービス/システム単位で分離し、コスト管理の利便性が向上 権限の委譲 コーポレートなど経理の方が、スタンドアロンで請求確認が可能（管理者の運用負荷低減） リスク分散 局所的な影響を減らし、インシデント発生時のリスクを低減 ボリュームディカウントの共有 組織内のメンバーアカウントの使用料を全結合し、ボリュームディカウント（従量制割引）や、リザーブドインスタンスの共有が可能 ソリューション AWS環境でマルチアカウント運用を実現するための手段として、かつてはAWS Organizationsを軸に実施されていたと思いますが、現在脚光を浴びているのがAWS Control Towerです。 AWS Organizationsなど関連するサービスがラップした構成になっているため、初見の場合分かりにくいですが、一つずつサービスを理解することで、AWS Control Towerを使うべき理由が理解できます。 また、組織全体のセキュリティを可視化するための統合ツールがAWS Security Hubです。 AWSではこの二つの補完的なサービスを利用することで、セキュリティ・ガバナンスを実現することができます。 以降、セキュリティ・ガバナンスを実現するために必要となる、関連するAWSサービスについて記載しています。 認証・認可の仕組みとして、AWS Identity and Access Management (IAM)や、SSOを実現するAWS Single Sign-Onも欠かせませんが、本記事では割愛します。 AWS Control Tower AWS Control Towerは、マルチアカウント環境を実装するための手段です。 セットアップを開始すると、マルチアカウント環境の運用を実現するために、AWS Organizationsを自動的に設定し、ガードレールを実装します。 サービス自体は2019年から存在していましたが、リリース当初は東京リージョンが利用できませんでした。 そして、来るべき2021年4月から東京リージョンでも利用出来る様になりました。 AWS Control Tower がムンバイ、ソウル、東京の AWS リージョンで利用可能に AWS Control Towerの特徴は以下になります。 ベストプラクティスを基に、Landing Zoneを設定 ガードレールを適用し、ポリシー違反につながるアクションを禁止、または、ポリシー違反などアカウント内のリソースの非準拠を検出 ガードレールの適用状況をダッシュボードで可視化し、一元的な管理が可能 Account Factoryで新規アカウントのプロビジョニングを標準化 AWS Control Towerが提供するガードレールは、AWSが民間と一緒に作りあげたセキュリティ対策のベストプラクティスになります。セキュリティで重要と思われる項目が選定されています。 ガードレールは予防と、検出の2種類が存在します。 予防のガードレールは強制的に該当操作をできない様に、Organizationsのサービスコントロールポリシーで設定されます。 検出のガードレールは該当操作を検出するために、Config Rulesで設定されます。 ガードレールを使用することにより、ポリシーの意図を表現できます。 また、2021年11月末のアップデートではリージョン毎の制御も出来る様になりました。 AWS Control Tower を使用して任意の AWS リージョンのサービスとオペレーションを拒否 AWS Control Towerを使用することで、以下の様に用途に応じて柔軟なセキュリティ・ガバナンスを実現できます。例えば、ガードレールの予防ルールで海外リュージョンを禁止することで、知らない間に海外にデータが存在しているなど、リスクとなり得る行為を予防することができます。 AWS Control Towerを利用する際のガードレールの見方や、操作方法について以下に記載します。 現在、OUにどのガードレールが適用さているかは、AWS Control Towerの組織単位ペインから、「有効なガードレール」を参照。 OUに対して、ガードレールの設定変更を行いたい場合、AWS Control Towerのガードレールペインから、変更したいガードレールを選択し、有効にする場合は「組織単位が有効」から「OU でガードレールを有効にする」を選択。無効にしたい場合は、「ガードレールを無効にする」を選択。 ガードレールの設定を変更する際に、複数のOUを一括に選択する操作はできない。 新しいガードレールは適宜追加されるため、AWS Control Towerのガードレールペインからリリース日を参照。 AWS Control Towerセットアップ完了後、すべての必須のガードレールがデフォルトで有効になる。なお、必須のガードレールについて個別で変更はできないため、ガードレールを適用したくない場合は、OUから移動する必要がある。 AWS Landing Zone AWS Control Towerを理解するために、最初に理解した方がいいと思うのが、AWS Landing Zoneです。 AWS Landing Zoneについて検索すると、抽象的な説明が多く理解がしにくいと思います。 以下はAWS Landing Zoneについて、ユーザーガイドの説明です。まずはこの様な考え方があることを、抑えておけば良いかと思います。 ランディングゾーン— landing zone は、よく設計されています,複数アカウント環境は、セキュリティとコンプライアンスのベストプラクティスに基づいています。これは、すべての組織単位 (OU)、アカウント、ユーザー、およびコンプライアンス規制の対象とするその他のリソースを保持するエンタープライズ全体のコンテナです。ランディングゾーンは、いずれの規模の企業のニーズに合わせてもスケーリングできます。 なお、AWS Landing Zone ソリューションは現在、長期サポート中で別物になります。 AWS Organizations AWS Organizationsは、複数のAWSアカウントを統合するためのアカウント管理サービスです。 AWS Control Towerセットアップ時に合わせて有効になります。 ガバナンスを目的とし、AWS Organizationsの機能を手段とすることで、マルチアカウントの課題を解決します。 例えば、全AWSアカウントの利用料を管理アカウントへ統合し、一括請求を行なったり、クレジットカードの情報を必要とせずにAWSアカウントの作成を行うことができます。 AWS Control Towerを活用するためには、以下の概念を理解しておくと良いでしょう。 組織単位 (OU) の管理 サービスコントロールポリシー OUについてもっと知りたい場合は、AWS ホワイトペーパーの「Organizing Your AWS Environment Using Multiple Accounts」のRecommended OUsを参照。 AWS Control Towerを利用する際のOU設計で考慮すべき点について以下に記載します。 AWSの推奨するOUは必ずしも全てを満たす必要はない。環境に合わせて独自のOU構造を定義することが望ましい。 2021年11月のControl Towerのアップデートで、ネストされたOUがサポート。いくつか留意事項があるため、詳細はユーザーガイドのNested OUs in AWS Control Towerを参照。（ネストされたOUで、検出は継承されなく、防止は継承されるのが特徴） AWS Control TowerからOUを作成すると、AWS OrganizationsにもOUは反映される。逆にAWS OrganizationsからOUを作成すると、AWS Control Towerにも反映されるが、OU未登録の状態になる。つまり、ガードレールも適用されていない状態になる。 AWS Control TowerからOUを移動することは現状、不可能な操作となっている。そのため、OUを移動させたい場合は、AWS Organizationsから移動する。OU移動後、AWS Control Towerの組織単位ペインを見ると、「管理対象のアカウント」の表示が0/1となるため、OUを再登録する作業が必要。 AWS CloudTrail AWS CloudTrailは、ユーザー、ロール、または AWS のサービスによって実行されたアクションをイベント履歴として記録します。イベント履歴には、AWS Management Console、AWS Command Line Interface、および AWS SDK と API で実行されたアクションが含まれます。 「いつ」、「だれが」、「何を」したのかが記録されるため、不正アクセスなどを確認することを目的に監査ログとして扱うことができます。 AWS CloudTrailの特徴は以下になります。 CloudTrailは、作成時にAWSアカウントで有効になっているが、全てのアクションをサポートしている訳ではない ログはS3に保存され、KMS キーを活用してCloudTrailログをさらに保護することが可能 CloudTrailのイベント履歴 管理イベント（AWSアカウントのリソースで実行される管理操作に関する情報） データイベント（リソース上またはリソース内で実行されるリソース操作に関する情報） Insightsイベント（AWSアカウントの異常なAPIコールレートまたはエラーレートアクティビティ） CloudTrailのイベントログは、過去90日間のイベントの表示、検索、およびダウンロード可能（90日以上、保存したい場合はAmazonGlacierなど手動での設定が必要） AWS Control Towerを使用している場合、Landing Zoneによって、Log archiveアカウントのS3に、アカウント毎のCloudTrailとConfigのログが集約される AWS Security Hub AWS AWS Security Hubは、セキュリティのベストプラクティスのチェックを行い、アラートを集約し、自動修復を可能にするクラウドセキュリティ体制管理サービスです。 セキュリティチェックは、AWS Configが記録した設定項目を利用します。 AWS Security Hubの特徴は以下になります。 CISやPCI DSSなど業界標準となるベストプラクティスを利用し、セキュリティチェックを自動化 複数アカウントのチェックした結果を集約 Amazon CloudWatch Events、AWS System Manager Automation、AWS Step Functions、AWS Lambdaなどと連携し、チェックした対応の一部について自動化（※）を実現 CIS（Center for Internet Security）は米国の独立した非営利団体の略称です。 なお、CISの提供している、CIS Controlsはフレームワークの一つで、AWSのSecurity Hubで利用される、CIS Benchmarkとは異なります。 ※CIS AWS Foundations Benchmarkでは、自動的にチェックできない項目が存在します。 マスターアカウントのAWS Security Hubの画面にて、メンバーアカウントから集約したアラートを可視化できますが、検出結果をAWS CLIのコマンドで使用する際のナレッジを1点紹介します。 検索の詳細の取得 (Security Hub API、AWS CLI) 検出結果の詳細はget-findingsコマンドで取得できます。デフォルトではRecordStateがARCHIVEDのレコードも含まれるため、レコードが蓄積されているアカウントに対して実行すると、凄い時間がかかるため、フィルタリングして取得するのがお勧めです。 AwsAccountIdを軸に、ComplianceStatusがFAILED、RecordStateがACTIVE、SeverityLabelを昇順でソートする例 $ aws securityhub get-findings --filters '{"AwsAccountId": [{"Value": "<account id>", "Comparison": "PREFIX"}], "ComplianceStatus": [{"Value": "FAILED", "Comparison": "EQUALS"}], "RecordState": [{"Value": "ACTIVE", "Comparison": "EQUALS"}]}' --sort-criteria '{"Field": "SeverityLabel", "SortOrder": "asc"}' 例えば、検出結果を分析するために大量のアカウントに対して、1アカウント毎にGUIで分析するのは現実的ではありません。AWS CLIなどを活用すれば、複雑な作業を簡単にこなすことができます。 AWS Config AWS Configは、AWS リソースの設定を評価、監査、審査できるサービスです。 ガバナンスとしてガイドラインに違反していないかを検出するために、AWS Configを使用することで、AWSリソースの設定変更を継続的にモニタリングして記録します。 AWS Configの特徴は以下になります。 AWSリソースを継続的に評価し、コンプライアンス違反やリソースの変化（作成、変更、削除）を検出 検出したイベントに対して、Amazon SNSを用いてEメール通知などが可能 AWSリソースの設定及び、変更履歴を管理し、セキュリティグループの設定変更などトラブル発生時に変更を戻すことで修復可能 記録対象のスナップショットを取得することが可能 Amazon GuardDuty Amazon GuardDutyは、AWSアカウントならびにAWS環境を継続的にモニタリングし、脆弱性となり得るアクティビティを検出するサービスです。 Amazon GuardDutyの特徴は以下になります。 AWSコンソール上で有効化のボタンを押下するだけで、Amazon GuardDutyが開始される 内部的には機械学習 (ML)などの技術を使用し、ログから脅威を検出する仕組み Security Hubと統合して、Amazon GuardDutyの調査結果をSecurity Hubに送信 Security Hubの検出結果の画面から、マルチアカウントの検出結果を集約 おわりに これまではレガシーシステムや、統制がない環境でIaaS系のサービスを使用するなどしてクラウドを利用する立場でしたが、CCoEとして組織の中で推進する立場からクラウドを利用することは、新しい気づきや学びがありました。 日進月歩、テクノロジーの進化には驚きますが、されど利用する先には人間がいるので、本質的に考え抜き、クラウドを活用することが改めて重要だなと思いました。 ポストコロナと言われている今、現在、日本のDX市場で伸びているのは、情報通信業や、amazonなどの小売業です。 従って、まだまだ他の産業でのDXは始まったばかりなので、ブルー・オーシャンはまだあると思います。 クラウドを安全に利用し、ビジネスに活用するためには、まだまだエンジニアとして学び続けられる環境があるということではないでしょうか。 参考 DX 産業界におけるデジタルトランスフォーメーションの推進 DXの実現に向けた取り組み AWS ホワイトペーパー 複数のアカウントを使用してAWS環境を整理する ユーザーガイド AWS Control Tower とは AWS Organizations とは AWS CloudTrail とは AWSSecurity Hub とは AWS Config とは Amazon GuardDuty とは AWS サービス別資料 [AWSBlackBeltOnlineSeminar] AWS Security Hub [AWSBlackBeltOnlineSeminar] AWS CloudTrail 最後に宣伝 Supershipではプロダクト開発やサービス開発に関わる人を絶賛募集しております。 ご興味がある方は以下リンクよりご確認ください。 Supershipグループ 採用サイト 是非ともよろしくお願いします。

はじめに 去年に引き続きクリスマスイブに投稿することになりました。 1年ぶり2度目のQiita投稿です。 まず始めに謝ります。タイトルちょっと盛りました笑 本当はSAP含めた4個すでに取得していたので、2ヵ月で7個追加で取得して11冠になりました。 取得するに至った経緯や、個人的難易度について書いていこうと思います。 自分の経歴 2018年5月、業務でAWSを本格的に触るようになり、2018年10月に試しにSAAを受けたのが最初でした。 その後、あくまで業務の延長としてSAP、DOP、SCSを腕試し的に受けて取得していました。 事前に模試を受け、知らないサービスの概要をAWS サービス別資料で確認し、AWSコンソールで触ってなんとなく理解する。という流れで試験を受けていましたが、これを1回やっておくと業務で課題が見つかったときに検討できるAWSサービスの幅が広がるのを感じました。 副業でもAWSを触ってますが、そちらについてはこちらの過去記事に書いてます。 11冠しようと思ったきっかけ 経歴に書いたように、業務で必要性を感じない限り他の認定については受けるつもりはありませんでした。 ただ、以下の理由から他の認定についても取得することにしました。 登壇時の自己紹介スライドの映え 12月頭に外部で登壇する機会が2件あり、その自己紹介スライドでなんとなくバッジを並べてみたかった。(AWS関連で登壇されてる方の自己紹介スライドによくあるあれをちょっとやってみたかった笑) ちなみに登壇したのは↓の2件です。もし興味がありましたら... SaaS on AWS Day 2022 Visional Security Lounge Vol.2 12月末までお金もらえるキャンペーン 弊社では資格取得奨励制度があり、12月末まで限定でAWS認定については高額の補助を出してもらえたため。(標準受験料の約2倍) 来年から追加される認定試験の影響 今はまだベータ版ですが、専門知識領域に「SAP on AWS」1が追加され、来年第2四半期に公開予定のようです。 さすがにこれは受けないだろうなーもし全冠するなら今年しかないなーと思ったため。 取得履歴 ちょうど10月の頭に登壇の話をもらったので、そこから2ヵ月ぐらいでDVA以降の7個を業務の合間に取得しました。 こう改めてみるとけっこう合格ラインぎりぎりですね...笑 試験名 取得日 スコア AWS Certified Solutions Architect - Associate (SAA) 2018-10-26 767点 AWS Certified Solutions Architect - Professional (SAP) 2019-01-25 不明2 AWS Certified DevOps Engineer - Professional (DOP) 2019-11-28 760点 AWS Certified Security - Specialty (SCS) 2020-12-09 891点 AWS Certified Developer - Associate (DVA) 2021-10-04 814点 AWS Certified SysOps Administrator - Associate (SOA) 2021-10-04 777点 AWS Certified Database - Specialty (DBS) 2021-10-12 792点 AWS Certified Data Analytics - Specialty (DAS) 2021-11-01 800点 AWS Certified Advanced Networking - Specialty (ANS) 2021-11-08 835点 AWS Certified Machine Learning - Specialty (MLS) 2021-11-29 777点 AWS Certified Cloud Practitioner (CLF) 2021-11-30 821点 個人的難易度 やはりどうしても業務で触っていない試験については難しく感じましたね。 MLSとDASについては業務で全く触れていなかったので、本当に勉強して取得した感があります。 ANS、SAPについては業務でやっているはずですが、DirectConnectに関する問題については難しさを感じました。(業務で使わないし、触ろうと思っても簡単には試せないので...) 余談ですが、こちらのハンズオンをAWSさんに弊社向けに個別に開催していただきました。 ANS受験後でしたが、DirectConnectの理解が深まる素晴らしいハンズオンでした。 5位以降はそこまで大差ないかなという感じです。 順位 試験名 1 AWS Certified Machine Learning - Specialty (MLS) 2 AWS Certified Data Analytics - Specialty (DAS) 3 AWS Certified Advanced Networking - Specialty (ANS) 4 AWS Certified Solutions Architect - Professional (SAP) 5 AWS Certified Database - Specialty (DBS) 6 AWS Certified DevOps Engineer - Professional (DOP) 7 AWS Certified Security - Specialty (SCS) 8 AWS Certified SysOps Administrator - Associate (SOA) 9 AWS Certified Developer - Associate (DVA) 10 AWS Certified Solutions Architect - Associate (SAA) 11 AWS Certified Cloud Practitioner (CLF) どのように勉強したか セキュリティとデータベースについては本を買って体系的に勉強しました。 どちらも同じシリーズを購入しましたが、特にセキュリティについてはおすすめです。 要点整理から攻略する『AWS認定-セキュリティ-専門知識』 他の認定については特に本などは購入せず、経歴に書いたような流れで対策してました。 ANSだけは模試がないため、注意が必要です。 人によるかもしれませんが、実際にサービス触ってみるのは大事だと思います。(文字だけで見ててもイメージわかないし、遠回りに感じるかもしれないが理解が早いはず) 取得してみた感想 普段業務では触れないサービスを試しに利用してみたりして、結構楽しかったです。 また、タイミングよく副業先でデータ分析をしてみたい！などの要望が出たりして、早速役に立ちそうです。 あと、今回業務の合間に取得できたのはやはりオンラインで受験できるようになったのが大きいですね。(参考:PearsonVUE) 専門知識やプロフェッショナルは3時間と長丁場になるため、移動時間なく慣れた環境で受験できるのはありがたいです。 おわりに AWS認定はあくまで知らないAWSサービスの概念をつかみ、触るきっかけになるものだと思ってます。 業務で実際に利用してこそ、知識が自分のものになります。 今回試験を受けてみて、AWSコンソール上で実際に設定させるような実技試験もありました。3 今後はこういう試験形態に移行していく流れを感じました。 これSolucation Architect Professionalの略称と被ってるから検索むずかしいですよね... ↩ AWS認定ページからスコアのダウンロードしようと思ったらこいつだけダウンロードリンクなかった... ↩ SysOps試験ラボ ↩

24 日目！ 世の中はクリスマスイブ！ ということで、今日は、API Gateway から、昨日作った AWS Lambda 関数をつなぎます。 もちろん、AWS CLIで。 24日目の要約 API！ AWS CLI の準備 このあたりをみて、好きなバージョンとお使いのOSにあった環境設定をしてくださいね。 なんなら、 AWS CloudShell で実行するのも楽でよいと思います。 この記事シリーズは、AWS CloudShell で実行し、実行例を載せています。 バージョン１ https://docs.aws.amazon.com/ja_jp/cli/latest/userguide/install-cliv1.html バージョン２ https://docs.aws.amazon.com/ja_jp/cli/latest/userguide/install-cliv2.html 概要 API Gateway を作って、リクエストを受けたら Lambda 関数に処理させます。 さあ、やってみよう！ 今回は API Gateway の REST API を作っていきます。 API Gateway の各要素を以下の図で確認します。 API を作成する まずは、APIそのものを作成します。今回は REST API を作成するので、apigateway create-rest-api コマンドを実行します。 aws apigateway create-rest-api --name adventcalendar2021 APIの作成に成功すると、以下のような json が返るので id の値を確認しておきます。 { "id": "u8********", "name": "adventcalendar2021", "createdDate": "2021-12-23T16:08:10+00:00", "apiKeySource": "HEADER", "endpointConfiguration": { "types": [ "EDGE" ] }, "disableExecuteApiEndpoint": false } 今回はリソースを作らない(デフォルトで作られる"/"を使う)ので、"/" の ID を確認しておきます。apigateway get-resources コマンドを実行します。 aws apigateway get-resources --rest-api-id <API の ID> 無事に取得できると、以下のような json が返るので id を確認しておきます。 この id は リソースの ID です。 { "items": [ { "id": "g8********", "path": "/" } ] } GET メソッドリクエストを定義する ここからは、各要素を順々に作っていきます。 一つ目は、クライアントからのリクエストを受け付けるための GET メソッドを apigateway put-method コマンドで作っていきます。 aws apigateway put-method \ --rest-api-id <API の ID> \ --resource-id <リソース のID> \ --http-method GET \ --authorization-type NONE \ --no-api-key-required \ --request-parameters {} 作成に成功すると以下のような json が返ります。 { "httpMethod": "GET", "authorizationType": "NONE", "apiKeyRequired": false, "requestParameters": {} } API Gateway から Lambda への統合リクエストを定義する 2つ目は、API Gateway　から Lambda 関数へのリクエストを定義しますが、まずは、Lambda 関数の ARN を確認します。 Lambda 関数のARN を確認する Lambda 関数の情報を取得する lambda get-function コマンドで ARN を確認することができます。 aws lambda get-function --function-name adventcalendar2021 取得できると、以下のような json が返るので、FunctionArn の値を確認します。 { "Configuration": { "FunctionName": "adventcalendar2021", "FunctionArn": "arn:aws:lambda:ap-northeast-1:************:function:adventcalendar2021", "Runtime": "python3.8", (以下、省略) API Gateway から Lambda へのリクエストを定義する FunctionArn の値が確認できたら、apigateway put-integration コマンドで API Gateway から Lambda 関数へのリクエストを定義します。 uri に指定する形式は、arn:aws:apigateway:<リージョン>:lambda:path/2015-03-31/functions/<Lambdaの関数のARN>/invocations です。 aws apigateway put-integration \ --rest-api-id <API の ID> \ --resource-id <"/" のID> \ --http-method GET \ --integration-http-method POST \ --type AWS \ --uri arn:aws:apigateway:ap-northeast-1:lambda:path/2015-03-31/functions/<Lambdaの関数のARN>/invocations コマンド実行が正常に完了すると、以下のような json が返ります。 uri の後程使用しますので、確認しておきます。 { "type": "AWS", "httpMethod": "POST", "uri": "arn:aws:apigateway:ap-northeast-1:lambda:path/2015-03-31/functions/arn:aws:lambda:ap-northeast-1:************:function:adventcalendar2021/invocations", "passthroughBehavior": "WHEN_NO_MATCH", "timeoutInMillis": 29000, "cacheNamespace": "g8********", "cacheKeyParameters": [] } Lambda から API Gateway への統合レスポンスを定義する Lambda 関数の処理結果(レスポンス)を API Gateway が受け付けるために apigateway put-integration-response コマンドで定義します。 aws apigateway put-integration-response \ --rest-api-id <API の ID> \ --resource-id <リソース の ID> \ --http-method GET \ --status-code 200 \ --response-templates '{"text/html": ""}' 問題がなければ、以下のような json が返ってきます。 { "statusCode": "200", "responseTemplates": { "text/html": null } } API Gateway からクライアントへのメソッドレスポンスを定義する 最後の定義です。API Gateway からクライアントへのレスポンスを apigateway put-method-response コマンドで定義します。 aws apigateway put-method-response \ --rest-api-id <API の ID> \ --resource-id <リソース の ID> \ --http-method GET \ --status-code 200 \ --response-models '{"text/html": "Empty"}' こちらも問題がなければ、以下のような json が返ってきます。 { "statusCode": "200", "responseModels": { "text/html": "Empty" } } これで一連の要素の作成、定義ができました。 Lambda が API Gateway からのリクエストを受けられるように設定する Lambda 関数が API Gateway からのリクエストを受け付けられるようにパーミッションを追加します。 lambda add-permission コマンドを実行します。 aws lambda add-permission --function-name adventcalendar2021 \ --statement-id adventcalendar2021-lambda-permission \ --action "lambda:InvokeFunction" \ --principal apigateway.amazonaws.com \ --source-arn "arn:aws:execute-api:ap-northeast-1:<アカウントID>:<API ID>/*/GET/" 問題がなければ、以下のようなパーミッションが埋め込まれた json が返ります。 { "Statement": "{\"Sid\":\"adventcalendar2021-lambda-permission\",\"Effect\":\"Allow\",\"Principal\":{\"Service\":\"apigateway.amazonaws.com\"},\"Action\":\"lambda:InvokeFunction\",\"Resource\":\"arn:aws:lambda:ap-northeast-1:<アカウントID>:function:adventcalendar2021\",\"Condition\":{\"ArnLike\":{\"AWS:SourceArn\":\"arn:aws:execute-api:ap-northeast-1:<アカウントID>:<API ID>/*/GET/\"}}}" } API をテストする 各要素の作成や定義、Lambda 関数のパーミッション設定が済んだら、テスト実行してみます。 apigateway test-invoke-method コマンドを実行します。 aws apigateway test-invoke-method --rest-api-id <API の ID> \ --resource-id <リソースの ID> \ --http-method GET \ --path-with-query-string '' テストの実行が終わると以下のような json が返ります。 status: 200 が出ていれば特に問題ありません。 また、body の内容が今回であれば、 Lambda 関数が出力する HTML の内容になっていることを確認します。 { "status": 200, "body": .... (以下、省略) API をデプロイする テストも問題がなければ、API を実際に使える状態にするために apigateway create-deployment コマンドで API をデプロイします。 aws apigateway create-deployment \ --rest-api-id <API の ID> \ --stage-name PROD \ --stage-description "Production" \ --description "Advent Calendar2021 API" 正常にデプロイが完了すると、以下のような json が返ってきます。 { "id": "ul****", "description": "Advent Calendar2021 API", "createdDate": "2021-12-23T16:34:18+00:00" } 動作確認 API がデプロイできたので、実際に動作確認をします。 curl コマンドを使い、さらに見やすくするために適宜 sed コマンドで改行を入れていきます。 curl "https://<API の ID>.execute-api.ap-northeast-1.amazonaws.com/PROD/"| sed "s/br>/br>\n/g" | sed "s/<\/h2>/<\/h2>\n/g" API から正常にレスポンスが返ると、以下のような出力されます。 "<HTML><TITLE>AWS Lambda Environment Information</TITLE><BODY><h1>AWS Lambda Environment Information</h1><h2>AWS Lambda Environmental Variables</h2> AWS_LAMBDA_FUNCTION_VERSION=$LATEST<br> (以下省略) まとめ 昨日作成した Lambda 関数が API Gateway 経由で利用可能になりました。 これでいつでも、 Lambda 自体の各種情報が取得できますね！ さて、明日は最終回。 24日分の内容を振り返りつつ、後片付けをしましょう。

自己紹介 プログラムが未だに書けないへっぽこインフラエンジニア。（いい加減何とかしたい） 自分の仕事をIT系以外の人や子供に説明する時は、「WEBのピタゴラスイッチ屋さん」と自称しています。 説明する対象者が年配の方で、「ピタゴラスイッチ」で話が通じない時は「バック・トゥ・ザ・フューチャーの最初のやつ」と説明します。※これでも駄目なら説明あきらめて「インターネット屋さん」としています。 何故記録を残すのか 今回、短期間集中型としての勉強メソッドは、上手く作り込めたと思います。 この成功体験を記憶がフレッシュなウチにQiitaに残すことで、3年後の再取得のときの自分の参考にするためです。 そういう目的なため、ポエミーな部分も多分に含まれると思いますが・・・。どうぞご了承下さい。 ご覧になった皆様の参考として頂けたならば何より幸せでございます。 この記事で得られる事 試験までの残期間を４ブロックに分けて定義付けし、どのように効率的に勉強していくべきかhowtoが記載されています。 勉強に役立つ書籍やWEBページの知見が得られます。 他の方の合格記から私がどんな知見を得て自身の試験に活かしたのか、howtoが記載されています。 前項と内容カブりますが重要なので別項目とします。本試験前の心構えや準備について記載されています。見直しは本当に重要です！ 資格取得遍歴とSAP受験決意まで 2018年冬、NWエンジニア歴7年の冬、クラウドエンジニアとやらにあこがれてソリューションアーキテクトアソシエイト(以下、SAA)を取得。 2019年春、SAAの資格を引っさげ転職し、クラウドエンジニアとしてのスタートを切る事に成功する。 2019年秋、社内勉強会のためにクラウドプラクティショナー(以下、CP)を取得する。 2020年秋、マイクロソフトのウェビナーに参加したところ無料受験チケットを頂いたので、Microsoft Azure Fundamentals(以下、AZ-900）を取得。 2021年秋、SAAの失効を目前にSAA受け直しか、SAPへステップアップするかで悩む。 同上時期、AWS認定準備ワークショップに参加し「あ、やれるかも？」と勘違いしてソリューションアーキテクトプロフェッショナル受験を決意。（ワークショップは不定期開催の模様です） 2021年冬、ソリューションアーキテクトプロフェッショナル(以下、SAP)を取得。 SAP取得して、上位資格取ると下位の資格有効期限も上位資格の有効期限まで伸びる事に気づきました。 てっきり、SAAはSAAで別途再受験が必要なのだとばかり思ってました。 CPもSAAも2024年まで有効期限伸びました。 勉強のロードマップ 決意したのが11/30でしたので、12/1からスタートです。 受験目標日を、SAA有効期限の12/23に受験する計画としました。 何故12/23かというと、理由は大きく3つです。 SAAの合格特典である受験料金半額チケットの有効期限日だったから SAPの受験費用は3万円+税と、ホント馬鹿なんじゃねーかなって金額がかかります。それが半額になります。 会社から一番近いテストセンターの予約申し込み空き日がその日しか無かったから SAAの有効期限日でもあったので、なんか運命かも？とかトキメキを感じてしまったのでその日にしました。 勉強で年越ししたくなかったから SAAの勉強の時にも言ってましたが、年末年始を勉強しなきゃいけない気分で過ごすのが凄くイヤでした。 12/1から23日までの23日間、短期決戦でSAPに挑む計画を以下のように作りました。 ４ブロックに分けて、それぞれのブロックで必要な事をキッチリ行うことで合格にこぎつける作戦です。 準備期間：12/1～5 試験概要、試験範囲を確認 教材となるblackbelt資料やクラメソブログの収集 合格体験記、受験のコツなどのhowto情報収集 教本の選定、WEB問題集の選定 基礎固め期間：12/6～12 試験範囲のサービスをblackbeltやブログ、本から情報を収集し、ノートにまとめる 教本の確認問題 試験慣らし期間：12/13～19 WEB問題集をひたすら解く 夜間時間が3時間取れる日は模擬試験モードを実施する 土日は教本巻末の模試を実施する 追い込み期間：12/20～23 教本を読み直し、WEB問題集を2周3周ひたすら繰り返す 毎晩模試を実施 　準備期間：12/1～5 選定した本は以下２点。 AWS認定ソリューションアーキテクト-プロフェッショナル ~試験特性から導き出した演習問題と詳細解説 以下教本1と呼びます。 演習問題の解説が丁寧で、わかりやすく理解出来る良書でした。模試の難易度も本番相当です。 AWS認定資格試験テキスト&問題集 AWS認定ソリューションアーキテクト - プロフェッショナル 以下教本2と呼びます。 試験の範囲の85%はカバー出来ていて、解説も丁寧で詳細です。誤植が散見されるのは残念ポイントですが、意味が変わってしまうほど致命的なものはありません。しかし、模試の難易度が本番より難しいと感じます。それも問われている内容が難しいのではなく、意地悪引っ掛け問題のようなものもあって少し戸惑いました。（本番試験にもあるのかもしれませんが・・・） 合格体験記を読み漁り、以下のナレッジを得ました。 ３時間に及ぶ試験はとにかく体力と集中力の勝負になる。 体力対策 追い込みで前日徹夜とか絶対駄目、しっかり寝て英気を養って挑む。 試験前日のタイムスケジュールを整備。 集中力対策 人間の集中力など持っても30分だそうなので、意図的に休憩を挟むべし。 試験問題数を３で割った問題数を解くに連れ、１分の休憩を入れることにしました。 ワケワカメな翻訳文の長文から要件を洗い出す能力と、要件に対し適切な回答を見出す能力が必要になる。 長文読解力 問題を繰り返し解き、要件に必要な単語を見逃さず拾い上げて「何が問われているのか」を自分なりの文で構築し直すとわかりやすい。 回答力 選択肢の中で、途中まで同じ文章であったりするものに着目して選択肢間の差異を探す。差異の中で、明らかに要件外であったりベスプラから外れる行為（手作業など）であるものを除外すると正解にたどり着くことがある。 ワケワカメ翻訳読解力 ・・・なんかもう慣れちゃった。よく考えたら、普段の業務の中でトラブってしまい、巷に出回ってる技術文書をgoogle翻訳したものとか読んでるので自然に脳内変換出来るようになってしまっているのかもしれない。 見直しは超重要 時間の許す限り、見直しに時間を掛けること。 わからない問題も階層化し、浅い階層から取り掛かること 1.時間を使って考えれば解けるかもしれない 2.知らないサービスだけどAWS的に考えれば解けるかも 3.知ってるサービスと知らないサービスの組み合わせ 4.まったく知らないサービスのまったく知らない仕様 5.全く知らないサービス同士の組み合わせ 複数選択問題の回答数を確認する（２つ答えよなのか３つ答えよなのか） 回答全体を俯瞰して、ありえない選択肢を選んでいないか 試験日は最初に決めてしまうこと 試験日予約入れると、締め切り効果で勉強やる気スイッチ入りやすくなります。これ重要です。 基礎固め期間：12/6～12 自己ノート作り 教本2を基本軸とし、疑問点をblackbeltやyoutube、クラメソブログの助けを得ながらノートにまとめる。あとから見返したりはほぼしない。考えながら書くことで覚える。 検証 実際のAWS環境を使用し、理解を深めるためにリソースを作成するなど手を動かしてみる。 ただしDirectConnectとか契約が必要なものは構築不可能。（しかし頻出するので理解は必須） 僕は幸いにして構築経験があったので教科書記載の事だけでだいたいの挙動は理解することが出来た。 この辺がSAP取得目安は経験２年以上とされている理由かもしれない？ クラメソブログにまとめられていますが、AWS公式でハンズオンなど開催していることもあります。僕も案件従事前に参加して学んでいます。 試験慣らし期間：12/13～19 問題の数をこなし、長文読解に慣れる。選択肢からの回答力を身につける AWS問題集で学習しよう 超定番ですが上記WEB問題集を購入します。僕がSAA取った時と比べて、サイトが随分洗練されましたね・・・。 土日で模試を実行 まず、13日（期間初日）にいきなり教本1模試を実行します。当然ボロボロな数字が出ますが、この日は採点だけして答え合わせは行いません（重要ポイントです） WEB問題集や教本の模試、確認テストなどを用いてひたすら問題を解く一週間を過ごします。 18日（期間最終日１日前）に、13日と同じ教本1模試を行います。普通は前回よりも点数が良化します！この施策により自身の成長を感じるのがポイントです！短期決戦とはいえ、モチベーション続かんので・・・。 答え合わせを丁寧に行います。正答出来たところも他の回答が何故間違いとなるのかを考えながら読み込みます。 一晩ぐっすり寝て、19日に教本2模試を実施します。 、この本の模試、本番より難しいんじゃないですかね・・・。心がボッキリ折れるレベルで惨敗しました。 追い込み期間：12/20～23 ラストスパート、もうここは根性論 前期間の最終工程でトラウマになるレベルで心折られたので、危機感を持って残り３日間取り組みます。 朝起きて出勤時間ギリギリまでWEB問題集を実施します。昼休みも問題集を実施します。定時ダッシュで職場を去り、WEB問題集模試or教本１模試or教本2模試を毎晩解きます。 試験時間のマネジメントを練習 模試では、タイムマネジメントも練習します。全問回答するまでに何分かかって、見直しの時間は何分取れるのかを模試を繰り返すことで肌感で理解します。私の場合はこの練習により、全問回答したときの残り時間はおおよそ40分～60分ということがわかったので本番の休憩などを考える際に利用します。 息抜きに無料開放されているAWS公式の模試をやります。 クラメソブログ 本番よりちょい簡単くらいかな？丁度いい難易度に思います。インターフェースも洗練されてるし解説もわかりやすい。癒やしの時間です。 本試験 試験前日は０時には模試を切り上げて寝るつもりでした。 が、DirectConnectとDynamoDBとCloudFrontが脳内でワルツ踊っててなかなか寝付くことが出来ませんでした。 試験前日はもうすっぱりある程度のとこで勉強切り上げて寝る！というのも大切なのかもしれません。 試験当日、受付を済ませると、「３時間の長丁場の試験だから一番奥の集中できるスペースがいいですよね」と受付の方が気を利かせてくれて最奥のPCに案内してくれました。これマジありがたかったです・・・。 また、座席にはイヤーマフが置いてあり、自由に使えるようでしたが、僕は顔がデカいので上手くフィットしませんでした。 それを見かねた受付の方が「耳栓ならお出し出来ます」とのことで、耳栓を頂けました。普段の勉強でも耳栓を愛用していたので、マジでありがたや・・・。 試験の内容は当然何も語ることは出来ませんが、CP、SAAで出される問題の難易度と比較にならないレベルです。 画面を埋め尽くす文字の洪水、と言えばイメージが少し伝わりますでしょうか・・・。 わかっていたことですが、CPの時のような１行で問われる問題など１問もなくて、少なくても５行以上の問題文が全てです。スクロールしないと選択肢の全ては読めないような問題も数問あります。 模試をあれほど繰り返して望んでいましたが、本番ではやはり別のことは起こるものです。 タイムマネジメントもほぼ完璧に進めて、意図的な休憩もバッチリ取れていたのですが、2/3ほど問題を進めた辺りから、明らかに集中力が切れて問題文が頭に入らなくなってきました。文字が見えているのに読めない、脳みそがインプットを拒絶してくる感覚といえばわかるでしょうか（わからんか）。 どうにもならないので長めに３分休憩することにして、うつ伏せになり目を閉じて何も考えずただ180秒を数えました。 これを行うことで脳の「TooManyRequestsException」が解消され、残りの1/3の問題に取り組む事ができるようになりました。脳にもエクスポネンシャルバックオフは必要なのだと体で理解した瞬間でした。 時間に余裕があることが前提ですが、オススメです！ 集中力を戻したとはいえ、体力的にはもはやヘトヘトの状態で全問回答を完了しました。 なんとこの段階で、６０分以上の時間が余っていました。 が、前述した「階層化した分からない」問題が28問ありました。この時点で不合格を覚悟しました・・・。 しかし、分からないフラグが立っている問題数をカウントしたからか、一応全問回答した開放感からか試験開始時と同じくらいの集中力が戻って来ていて、浅い階層の分からない問題が15問以上あったのですが全て解く事ができました。 →このおかげで、10問程度は正解出来たと思います。 まだ３０分以上時間が残っていたので、深い階層のわからない問題は後回しにして、１問１０秒程度全問見直しを実行しました。 →この見直しは3問ほど回答を直しました。 何でこんな回答してんだ？と首をかしげるような回答もありました。 集中してるようでしていない時間が存在しているということだと思います。見直しは本当に大切です！ 残り10分で、深い階層のわからない問題をAWSのベスプラ的、商業的、実運用でめんどくさくない的と多方面から考え、選択肢を選びました。5問程度進めたところでタイムアップでした。 結果は合格でした。 脳みそが極限まで疲労していた中で見た「合格」の文字だったので、「不合格」という文字列の「合格」だけ切り出して都合の良い幻覚をみたんじゃなかろーか・・・？と家に帰るまで不安でしたが、帰ってしばらくしたら、メールで認定バッチを送っていただけましたので幻覚じゃないことが証明されました。良かった。 試験感想 スコアレポートでは798点とありました。余裕とは言えないまでも、以外とギリな合格でもないという実感です。 合格記の中で言及されてる方もおられましたが、複数選択問題は部分点が加算されている可能性がありますね。 正直に告白すると僕はこの勉強期間の模試で、一度として75%以上の点数を取得していません。 （良くそれで受験したなとか言わんといて下さい） 本番でそれ以上の点数を取れるのは少し不自然な気がします。 この差異は複数選択問題における部分点加算という仮説で説明出来るのではないかと思いました。 全体感想 これはAWSでインフラ環境を構築したいなら是非学ぶべきよき試験と思いました。 試験を通じて学んだ内容は、実際の現場でも活きてくるであろうと思います。 知っていればこそよりコストを低く、よりセキュアに、より可用性高く、より運用工数低く、 平たく言えば僕らが構築や運用で楽が出来るだけの知識を与えてくれます。 なので勉強頑張って本当に良かったです。試験合格出来たことで一つ強くなれた事も本当に良かったと思っています。 給料あげてくれるともっといい 終わりに 使用教材について簡単にレビューしておきます。 教本1：AWS認定ソリューションアーキテクト-プロフェッショナル ~試験特性から導き出した演習問題と詳細解説 終わってみれば、こいつが一番勉強になったかもしれません。模擬試験の難易度が本番相当でちょうどよいです。 教本2：AWS認定資格試験テキスト&問題集 AWS認定ソリューションアーキテクト - プロフェッショナル 解説部分は教本１よりさらに丁寧で、範囲も申し分ありません。試験合格後も構築時の参考書として読む事ができるほどの内容の充実度があります。個人的に思ったのは、巻末の模擬試験難易度が本番より難しいです。問われている内容そのものの難易度は良い塩梅なのですが、回答の選択肢群が本番より意地が悪い感じです。動作を本当に理解していないと選び抜けないように考えられて作られているのではないでしょうか。それは「模試」なのか？と少し疑問に思っています。 AWS問題集で学習しよう 長い問題文の中から要件を明らかにしていく、という作業は数をこなして出来る事だと思います。その数をこなすツールとして最強レベルに優秀なのがこの教材かと思いました。私にはとても有用でした。 Blackbelt 上記教材で疑問に思ったことや回答間違ってない？などを確認するツールとして大変有用です。WEB問題集は時たま？？？となる問題もありますので、確認するために必須です。 Blackbeltのページでyoutubeが公開されているものは、倍速機能などを用いて視聴すると、より深く理解出来ますのでおすすめです。 クラメソブログ みんな大好きクラメソブログです。ここのやってみたためしてみた記事の質と量は凄まじいです。AWSに絡んだ面白ギミックは大抵のことはすでに実験されているのでhowtoとして最高に有用です。 ただし、クラメソに限ったことではないですがあくまで個人（個社？）ブログなので、情報が古く、現在ではベスプラではない、現在では不可能である、という記事もありますので、記事公開日はチェックが必要です。 ※クラメソさんはこういうとこも追記で対応してくれてたりすることもあるのが本当に凄い。。。 この記録が皆様のお役に立てれば幸いです。願わくば3年後の再試験でも上手く行けばよいなと思います。

この記事はニフティグループ Advent Calendar 2021の23日目の記事です。 はじめに こんにちは。普段はサービス開発運用を担当していますTakumi-Miuraと申します。 普段はAWS+pythonでユーザー管理アプリケーションを作ってます。最近VRデビューしました。 AWS X-Rayとは？ AWSにあるサービスの一つで、「本番環境や分散アプリケーションの分析とデバッグ」と銘打たれています。1 AWSにデプロイされたアプリケーションにSDKを組み込むことによって、アプリケーションのリクエスト・レスポンスの状況や、アプリケーションから発行されたデータベース、APIへのアクセスのレスポンス時間など、アプリケーションの稼働状況に関する様々な情報を取得することができるというものです。 X-Rayを調べる経緯(=使う理由) 私の担当するシステムはさまざまな社内・社外システムと連携して情報取得や申込受付などを実施しているのですが、連携先システムのトラブルでチームのシステムにも影響が及ぶ、ということがしばしば発生します。 もちろんログなどでシステムエラーが発生して検知できるのですが、最近はパフォーマンスの測定と改善にも照準が当たってきており、普段のシステムの健康状態を知りたいという気持ちが出てきました。 担当システムではAWSを利用しているのでAWSのサービスで測定に主眼を置いたサービスはないかと探したところ、X-Rayというサービスを知り、試しに使ってみたら「ええやん！」となったのでここで書いておきます。 ハンズオン AWSでチュートリアルが用意されていますがそれだとつまらないので、自分でSDKを組み込んだアプリケーションを作成してAWS環境に乗せて稼働状況をウォッチしてみたいと思います。 デプロイする環境の用意 AWSの中でも最もシンプルに構築ができるVPC+EC2でWEBアプリケーションを2台起動したいと思います。 VPC+EC2でアプリケーションを手軽に構築する部分については詳しい説明を省きます。(たくさん良記事があるはずなので) 最終的には以下のような構成を作成しておけば、今回の検証が可能になります。 気を付けるポイントは、EC2に対してIAMロールでX-Rayへのアクセス権限を付与しておく必要があることです。EC2に設定するIAMロールにAWSXRayDaemonWriteAccessポリシーを付与しておきましょう。ついでにAmazonEC2RoleforSSMポリシーを付与しておくと、セッションマネージャーを利用してコンソールから直接ログインできて便利です。 アプリケーションの準備 今回はpython+Flaskで簡単なAPIサーバーを2種類作成し、2台のサーバーにそれぞれ載せたいと思います。なぜAPIを2種類建てるかというと、自前で建てたAPIサーバー同士の通信をX-Rayを使って測定したいからです。 X-RayのSDKはpythonのWEBアプリケーションフレームワークのうちDjango、Flask、Bottleに対応しています。フレームワークに対応していなくても組み込みは可能ですが、この3つのフレームワークであればAWSが記述例を掲載してくれているため非常に簡単にX-Rayを導入できます。2 以下が今回用意したソースです。<>で括った箇所は適宜書き替えてください。 API1号機のソース app1.py from aws_xray_sdk.core import xray_recorder, patch from aws_xray_sdk.ext.flask.middleware import XRayMiddleware from flask import Flask, request import os import requests app = Flask(__name__) # APIのIPを設定 api_2_ip = "<API2号機用のEC2に割り振られたグローバルIP>" # X-Ray設定 plugins = ('EC2Plugin',) xray_recorder.configure(plugins=plugins) xray_recorder.configure(service='python_test_API_1') # HTTPリクエストに利用するモジュールを指定 libraries = (['requests']) patch(libraries) # X-Rayサンプリングルールの設定 sampling_rule_path = os.getcwd() + "/" + "sampling_rule.json" xray_recorder.configure(sampling_rules=sampling_rule_path) # FlaskとX-Rayを連携 XRayMiddleware(app, xray_recorder) # API1号機から固定値を返却 @app.route("/api/1/fixed_value", methods=["GET"]) def api_1_fixed_value(): return {"message": "API_1_TEST_RESPONSE"}, 200 # API1号機からAPI2号機へリクエストを送信する @app.route("/api/1/to2", methods=["GET"]) def api_1_value_request_to_2(): path = "http://" + api_2_ip + ":5000/api/2/fixed_value" response = requests.get(path) return response.json(), 200 # API1号機からAPI2号機へリクエストを送信し、その先でさらに別のAPIへリクエストする @app.route("/api/1/to_other_api", methods=["GET"]) def api_1_to_other_api(): path = "http://" + api_2_ip + "/api/2/to_other_api" response = requests.get(path) return response.json(), 200 if __name__=='__main__': app.run(host="0.0.0.0", debug=True, port=5000) API2号機のソース app2.py from aws_xray_sdk.core import xray_recorder, patch from aws_xray_sdk.ext.flask.middleware import XRayMiddleware from flask import Flask, request import os import requests app = Flask(__name__) # X-Ray設定 plugins = ('EC2Plugin',) xray_recorder.configure(plugins=plugins) xray_recorder.configure(service='python_test_API_2') # HTTPリクエストに利用するモジュールを指定 libraries = (['requests']) patch(libraries) # X-Rayサンプリングルールの設定 sampling_rule_path = os.getcwd() + "/" + "sampling_rule.json" xray_recorder.configure(sampling_rules=sampling_rule_path) # FlaskとX-Rayを連携 XRayMiddleware(app, xray_recorder) # API2号機から固定値を返却 @app.route("/api/2/fixed_value", methods=["GET"]) def api_2_fixed_value(): return {"message": "API_2_TEST_RESPONSE"}, 200 # 任意のAPIで情報取得する @app.route("/api/2/to_other_api", methods=["GET"]) def api_2_to_other_api(): path = "<任意のAPIのURL>" response = requests.get(path) return response.json(), response.status_code if __name__=='__main__': app.run(host="0.0.0.0", debug=True, port=5000) API共通のパッケージリスト requirements.txt aws-xray-sdk==2.8.0 botocore==1.23.20 certifi==2021.10.8 charset-normalizer==2.0.9 click==8.0.3 colorama==0.4.4 Flask==2.0.2 future==0.18.2 idna==3.3 itsdangerous==2.0.1 Jinja2==3.0.3 jmespath==0.10.0 MarkupSafe==2.0.1 python-dateutil==2.8.2 requests==2.26.0 six==1.16.0 urllib3==1.26.7 Werkzeug==2.0.2 wrapt==1.13.3 X-Ray設定 sampling_rule.json { "version": 2, "rules": [ { "description": "python_test_API sampling_rule", "host": "*", "http_method": "*", "url_path": "/api/*", "fixed_target": 1, "rate": 1 } ], "default": { "fixed_target": 10, "rate": 0.1 } } X-Rayに関わる箇所を抜粋して確認していきます。 from aws_xray_sdk.core import xray_recorder, patch from aws_xray_sdk.ext.flask.middleware import XRayMiddleware # X-Ray設定 plugins = ('EC2Plugin',) xray_recorder.configure(plugins=plugins) xray_recorder.configure(service='python_test_API_1') パッケージをインポートして、X-Rayへの設定を行っています。pluginsでEC2を指定することでインスタンスIDやアベイラビリティーゾーンの情報を付与することができます。またserviceで名前を付けていますが、X-Rayはserviceごとに情報を集積しており、同じserviceであればダッシュボードでも統一して表示するようになります。 # HTTPリクエストに利用するモジュールを指定 libraries = (['requests']) patch(libraries) API2号機では外部のAPIを呼び出すためにrequestsを利用しています。SDKが対応しているライブラリであれば、ライブラリ名を配列にしてpatchで適用することでX-Rayによしなにデータを送信してくれます。3 # X-Rayサンプリングルールの設定 sampling_rule_path = os.getcwd() + "/" + "sampling_rule.json" xray_recorder.configure(sampling_rules=sampling_rule_path) ここではX-Rayのサンプリングルールを読み込んでいます。 サンプリングルールでは、大量のアクセスの中からどんなパターンのリクエストについて情報を収集するか、記録するデータの量はどのくらいかを指定しています。 sampling_rule.json { "version": 2, "rules": [ { "description": "python_test_API sampling_rule", "host": "*", "http_method": "*", "url_path": "/api/*", "fixed_target": 1, "rate": 1 } ], "default": { "fixed_target": 10, "rate": 0.1 } } ここでは、ホストについては何でもよし、URLは/api/で始まるものを取得するようになっています。また、fixed_valueで秒間の最初のリクエストを必ず取得するように、rateでその後何%のリクエストを受け取るかを指定しています。今回は1秒間の1回目のリクエストと、その後のリクエストの100%を取得するように設定しています。 # FlaskとX-Rayを連携 XRayMiddleware(app, xray_recorder) X-RayとFlaskを連携させています。これにより、Flaskのリクエスト・レスポンスを追うことができるようになりました。 起動 上記のファイルをEC2インスタンス上に搭載します。Gitで落とすでもコピペでEC2インスタンスに直接ファイルを作成するでもよいですが、すべてのファイルが同じディレクトリにあるようにしましょう。 適当なディレクトリ/ 　├ app1.py 　├ requirements.txt 　└ sampling_rule.json X-RayではX-Rayデーモンをサーバー上で起動しリクエストを待ち受けている状態にする必要があります。デーモンをインストールして実行しておきましょう。 設定方法はこちらに掲載されてます。 sudo curl https://s3.us-east-2.amazonaws.com/aws-xray-assets.us-east-2/xray-daemon/aws-xray-daemon-3.x.rpm -o /tmp/xray.rpm sudo yum install -y /tmp/xray.rpm 以下コマンドでAPIを起動していきます。pip3でパッケージをインストールしてpython3 app1.pyで起動していくだけです。 cd <適当なディレクトリ> pip3 install -r requirements.txt python3 app1.py これで準備完了です。APIへ向かってリクエストを投げていきましょう。 X-Rayコンソールでのモニタリング APIへ向かって適当にリクエストを投げた後、AWSコンソールからX-Rayを表示すると、すでにアクセス情報やダッシュボードが入っているはずです。 サービスマップで視覚的にシステムのレスポンスや状態を確認することができます。API1号機からAPI2号機へのリクエスト状況、API2号機からほかのAPIへのリクエストも確認できました。障害時には赤色になるので、どこがトラブルとなっているかがすぐ分かります。 トレースではより詳細なリクエストごとの情報が載っています。自分のアクセス元IPも載っていて最初ちょっとビビりました。 使ってみた感想 API連携,DBアクセスがあるシステムでの効力は凄い X-Rayは稼働直後からサービス間の連携がグラフィカルに表示されるため、非常にとっつきやすく効果を感じられるサービスに思えますし、実際連携システムが複数に渡るときに障害点がどこかを探るのも非常にやりやすいなと感じられました。 マイクロサービスが主流になりつつある中、連携システムのレスポンスを把握しつつシステム自体の品質も手軽に確認できるため、非常に重宝されるサービスではないかなと思います。逆に、システムそれ自体で完結している場合はそこまで威力を発揮しないとも思えました。 SDK導入によるアプリケーションの維持コスト増 導入に際してアプリケーションに対してSDKを組み込まなければいけないことが難点ではあります。バージョン管理や脆弱性対応が発生した際など、様々な場面で考慮すべきミドルウェアが一つ増えるというのは手間になると思います。 ミドルウェアやアプリケーション自体の更新が容易であるようなアーキテクチャやインフラの採用、デプロイが積極的に行われるような運用フローの整備、アプリケーション自体が塩漬けにならないような仕組み作りも同時に必要になるでしょう。 そもそもSDKが用意されていない言語だと組み込めないという弱点もあります。X-Rayに言語選定が引きずられるようなことはしないほうがよいでしょう。 おわりに 以上簡単なX-Rayのハンズオンでした。普段からAPIでの連携をしまくっているシステムを受け持っている私にはとても魅力的なサービスなので、担当システムへの組み込みを含め様々に検討していきたいと思います！ https://aws.amazon.com/jp/xray/?nc2=type_a ↩ https://docs.aws.amazon.com/ja_jp/xray/latest/devguide/xray-sdk-python-middleware.html ↩ https://docs.aws.amazon.com/ja_jp/xray/latest/devguide/xray-sdk-python-httpclients.html ↩

はじめに 平日の朝晩、休日、趣味でIoTの勉強や電子工作してますyoyoと申します。 10月にオンラインで開催されたSORACOM UG 2021を見ていたときに、”初心者でも大丈夫。同じ初心者のためになるからSORACOM試してアウトプットしてみよう！”って言葉がすごく印象深くて私も何か作ってみたい、アウトプットしてみようと思い、今回、AdventCalendarに登録しました。Qiita初投稿です。至らないところもあるかもしれませんが、どうか温かい目で見ていただけるとありがたいです。宜しくお願いいたします。 概要 朝活、デスクワーク、オンライン勉強会、カフェでのプログラミング学習…。 作業に集中してるといつのまにかパソコンの画面に近寄りすぎていて、気づいたら目が疲れていることが多いなと感じます。 この身近な課題を解決を出来ないかと情報を探していたところ、SORACOM IoT DIYレシピで“近づくと音声で自動応答する店番ロボット”の記事を見つけました、本レシピを参考に、画面に近づきすぎたときにアラートメッセージを流してくれるロボットを作りましたので情報を共有いたします。 構成は以下になります。 IoTプロトタイピング IoT DIYレシピをなぞりながら作っていきました。レシピが非常にわかりやすく、 また動画でも説明されてたので、詰まることなく非常にスムーズに作ることが出来ました。 今回、モニタ近接アラートを作るにあたってレシピと変えた点は以下になります。 1.近接判定条件 2.発話させるメッセージ 3.センサ固定部品 1.近接判定条件変更 curlコマンドで取得したstorebot.pyを開き以下のように編集しました。 a) MIN_DISTANCE_CM を 20から40に変更 b) 判定条件をif MIN_DISTANCE_CM >= distanceに変更 コード全体はこちら #!/usr/bin/env python # -*- coding: utf-8 -*- MIN_DISTANCE_CM = 40 MAX_DISTANCE_CM = 200 STAY_COUNT = 5 import time # 距離を読む関数 def read_distance(): # 必要なライブラリのインポート・設定 import RPi.GPIO as GPIO # 使用するピンの設定 GPIO.setmode(GPIO.BOARD) TRIG = 11 # ボード上の11番ピン(GPIO17) ECHO = 13 # ボード上の13番ピン(GPIO27) # ピンのモードをそれぞれ出力用と入力用に設定 GPIO.setup(TRIG,GPIO.OUT) GPIO.setup(ECHO,GPIO.IN) GPIO.output(TRIG, GPIO.LOW) # TRIG に短いパルスを送る GPIO.output(TRIG, GPIO.HIGH) time.sleep(0.00001) GPIO.output(TRIG, GPIO.LOW) # ECHO ピンがHIGHになるのを待つ signaloff = time.time() while GPIO.input(ECHO) == GPIO.LOW: signaloff = time.time() # ECHO ピンがLOWになるのを待つ signalon = signaloff while time.time() < signaloff + 0.1: if GPIO.input(ECHO) == GPIO.LOW: signalon = time.time() break # GPIO を初期化しておく GPIO.cleanup() # 時刻の差から、物体までの往復の時間を求め、距離を計算する timepassed = signalon - signaloff distance = timepassed * 17000 # 500cm 以上の場合はノイズと判断する if distance <= 500: return distance else: return None import urllib2 import json import base64 from subprocess import Popen, PIPE def main(): cnt = 0 while True: distance = read_distance() if distance: print "距離: %.1f cm" % distance if MIN_DISTANCE_CM >= distance: # if MIN_DISTANCE_CM <= distance and distance <= MAX_DISTANCE_CM:　#コメントアウトし条件変更 cnt += 1 else: cnt = 0 if cnt > STAY_COUNT - 1: cnt = 0 headers = {'Content-Type': 'application/json'} payload = json.dumps({}) response = urllib2.urlopen(urllib2.Request('http://uni.soracom.io', payload, headers)) print(response.getcode()) body = json.loads(response.read()) mp3data = base64.b64decode(body['data']) cp = Popen(['mpg123', '-'], stdin=PIPE) cp.communicate(input=mp3data) print(cnt) time.sleep(1) if __name__ == "__main__": main() 2.発話させるメッセージ変更 AWS Lambdaのstorebot (Lambda 関数)のtextを"画面に近づきすぎです。画面から40センチ以上は 目を離しましょう"に変更しました。ちなみに㎝って書くとそのままセンチメートルって読んでしまい 違和感があったので、あえてセンチと入力しました。 コード全体はこちら from boto3 import Session from boto3 import resource from contextlib import closing import base64 def lambda_handler(event, context): text = "画面に近づきすぎです。画面から40センチ以上は目を離しましょう" polly = Session().client("polly") response = polly.synthesize_speech(Text=text, OutputFormat="mp3", VoiceId="Mizuki") with closing(response["AudioStream"]) as stream: r = {'encode': 'base64', 'format': "mp3", 'data': base64.b64encode(stream.read()).decode('utf-8')} return r 3.超音波センサ固定部品製作 3-1.設計 Autodesk社のFusion360を使って設計しました。 設計のポイントとしては ① ノートパソコンの開き具合が変わってもいいようにジョイント構造にしたこと ② できるだけシンプルにPCに取付けたかったのでコの字型にしたこと (カポッて被せられるようにした） ③ 細かい話ですが、干渉防止用の穴や各種固定用の穴を準備したこと です。 3-2.部品製作＆組立、取付 FLASHFORGE社のAdventurer3 3Dプリンタを使って印刷したのち、組み立て、取り付けを行いました。 完成 ※動画だと１秒間隔でドッ、ドッって音が入っていますが、超音波なので実際には人の耳には聴こえないです。 まとめ 実際に作ってみたら色々と新たな課題が見えてきました。 ① お店など人目が気になる環境では音声で警告するのではなく振動センサなど使って 　マナーモードで動作させたい（マナーモード機能が欲しい） ③スクリーンまでの距離をI2CのLCDでセンサ値を表示するなどして視える化したい 作ってみて思ったのは まずはアイデアを大切に手を動かしてみる。形になれば人に見てもらって意見をもらうことも できるし、より具体的に次の方向性が見えてきたりすると感じました。トライ＆エラーを繰り返して より良いものを作り上げていくことが重要なんだろうと...。Advent Calendar投稿とても良い経験に なりました。最後まで見ていただき有難うございます。

AWS TransferFamily + S3 でSFTP構成 　　パスワード認証SFTPを利用してS3の特定のバケットにファイルを置いたり削除したりする構成 　　下記を参考に構築します。（CloudFormationテンプレートを使用してお手軽に構築していますが、今回は勉強のために全て手作業） 　　参考：https://aws.amazon.com/jp/blogs/storage/enable-password-authentication-for-aws-transfer-for-sftp-using-aws-secrets-manager/ 　　所要時間：かなり多くの設定があるため１〜２時間ほど 使用するAWSサービス 　S3：ファイル格納先 　Transfer Family：SFTPサーバ 　Secret Manager：SFTPサーバの接続先、S3のディレクトリを保存 　APIGateway：外からどうこうするために 　Lambda：SecretManagerからキーバリューを取得 　IAM：上記サービス間でやりとりするために各サービスに付与する 　 IAMロールの作成 　目的：API GatewayがLambdaを呼び出したり、LambdaがSecretManagerからキーバリューを取得したり、TransferFamilyがS3へアクセスするために設定します。 　流れ：ポリシーを作成　-> ポリシーを付与した、ロールを作成 -> 信頼関係を編集 ポリシーの作成 ① まずはIAMのコンソール画面に移動し、左のナビゲーションから[ポリシー]を選択します。 ② [ポリシーを作成]を選択し、[サービス]、[アクション]、[リソース]を設定する。 ③ 次へ進み、必要であれば[タグ]をつける ④ [名前]と、[説明]をつけて完了 ■ ①〜④の繰り返しになるため、必要なポリシーは下に列挙します。 　　※リソースは要件によると思いますが、今回は勉強のためなので、[すべて]にしておきます。 　　※名前は自由ですが、ないと説明しにくいので記載します。 　・API_Gatewai_Get_Policy(APIGatewayでGETを呼び出すためのポリシー) 　　サービス：API Gateway 　　アクション：GET 　　リソース：すべて 　・Lambda_Invoke_Policy（APIGatewayがLambda関数を呼び出すためのポリシー） 　　サービス：Lambda 　　アクション： 　　　　　　　　"lambda:InvokeFunction", 　　　　　　　　"lambda:GetFunction", 　　　　　　　　"lambda:ListFunctions", 　　　　　　　　"lambda:ListVersionsByFunction", 　　リソース：すべて 　・SecretManager_Get_Secret_Value_Policy （Lambda関数がSecretManagerからキーバリューを取得するためのポリシー） 　　サービス：Secret Manager 　　アクション： 　　　　　　　　"secretsmanager:GetRandomPassword", 　　　　　　　　"secretsmanager:GetResourcePolicy", 　　　　　　　　"secretsmanager:GetSecretValue", 　　　　　　　　"secretsmanager:DescribeSecret", 　　　　　　　　"secretsmanager:ListSecretVersionIds", 　　　　　　　　"secretsmanager:ListSecrets" 　　リソース：すべて 　　・SFTP_S3_Access_Policy 　　　このポリシーのみ、リソース部にSecretManagerに格納するディレクトリパスを指定するためJSONで記載します。 　　　この設定により、SecretManagerにキー：HomeDirectoryとして設定したパスを読み取り、特定のバケットにのみ接続を制限できます。（バケットのどこにアクセスしても構わないよ、という場合は"アクション"部分のロールをコンソールで選択してください。 　　　サービス：S3 　　　アクション：JSONで記載 { "Version": "2012-10-17", "Statement": [ { "Sid": "AllowListingOfUserFolder", "Action": [ "s3:ListBucket" ], "Effect": "Allow", "Resource": [ "arn:aws:s3:::${transfer:HomeBucket}" ], "Condition": { "StringLike": { "s3:prefix": [ "${transfer:HomeFolder}/*", "${transfer:HomeFolder}" ] } } }, { "Sid": "HomeDirObjectAccess", "Effect": "Allow", "Action": [ "s3:PutObject", "s3:GetObject", "s3:DeleteObject", "s3:GetObjectVersion" ], "Resource": "arn:aws:s3:::${transfer:HomeDirectory}*" } ] } ロールを作成 次にロールを作成します。 流れ：上で作成したポリシーをロールに付与　-> 信頼関係を追加 今度は、上の画像の[ロール]を選択し、[ロールの作成]を選択してください。 ① 信頼されたエンティティの種類を選択：AWS ② ユースケースの選択：連携先のサービス名 　　AssumeRoleというやつですね。いわゆる認証周りです。 ③ Attach アクセス権限ポリシー：作成したポリシーを選択 ④ 必要であれば[タグ]をつけます ⑤ ロールの名前をつけて作成完了 ⑥ 必要であれば、信頼関係を追加 　　ロールを選択後、[信頼関係]タブから、[信頼関係の編集]を選択し、追加 先ほどのポリシーと同様に列挙する形にします。 ・TransferFamily_Role：AWS TransferFamilyのSFTPサーバーに付与するロール 　　信頼されたエンティティの種類：AWS 　　ユースケースの選択：Lambda 　　Attach アクセス権限ポリシー：API_Gatewai_Get_Policy 　　　　　　　　　　　　　　　　　SFTP_S3_Access_Policy 　　信頼関係の追加：２回目以降は省略します。サービス部に必要なサービスを追加してください。 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": [ "s3.amazonaws.com", "transfer.amazonaws.com", "apigateway.amazonaws.com" ] }, "Action": "sts:AssumeRole" } ] } ・Lambda_List_and_Invoke_Role：APIGatewayに付与するロール 　　信頼されたエンティティの種類：AWS 　　ユースケースの選択：Lambda 　　Attach アクセス権限ポリシー：Lambda_Invoke_Policy 　　　　　　　　　　　　　　　　　 　　信頼関係の追加： "Service": [ "apigateway.amazonaws.com", "lambda.amazonaws.com" ] ・Lambda_Get_Secret_Manager_Key_Role：Lambdaに付与するロール 　　信頼されたエンティティの種類：AWS 　　ユースケースの選択：Api Gateway 　　Attach アクセス権限ポリシー：SecretManager_Get_Secret_Value_Policy 　　　　　　　　　　　　　　　　　 　　信頼関係の追加： "Service": [ "apigateway.amazonaws.com", "lambda.amazonaws.com" ] これでロールの作成は完了です。 次にS3バケットを用意します。 S3 バケットの作成とアクセスコントロール S3では格納先のバケットを作成し、AWS SecretManagerに登録してあるディレクトリのパスのみにアクセスできるように、バケットポリシーを設定します。 バケットの作成 ① S3のコンソールへ移動し、左のナビゲーションから[バケット]を選択し、[バケットの作成]を選択します。 バケット名、フォルダ名は自由ですが、説明のためにつけておきます。 バケット名：test_bucket ※バージョニング：バージョニングを設定する場合は、ポリシーに"GetObjectVersion"やらが必要になってくるので注意してください。 あとは特に任意です。何もなければそのまま下までスクロールし、バケットを作成します。 ② 作成したバケットを選択し、フォルダを作成します。 　　フォルダ名：SFTP ③ [アクセス許可]タブより、ブロックパブリックアクセス (バケット設定)の[編集]を選択します。 ④ [パブリックアクセスをすべて ブロック]のチェックを一旦外し[変更の保存]を選択します。 　　これは必ず元に戻してください ⑤ 再び、[アクセス許可]タブに戻り、[バケットポリシー]の[編集]を選択します。 ⑥ 以下のコードを記述し、保存します。"Resource"の部分は作成したバケット名になります。 　　{} はいりません。バージョニングをオンにしている場合には、各ポリシーもバージョニング版を選択しないとクロスリージョンコピーなどでdenyされるので注意 { "Version": "2012-10-17", "Id": "Policy1636522677868", "Statement": [ { "Sid": "Stmt1636522659332", "Effect": "Allow", "Principal": "*", "Action": [ "s3:GetBucketAcl", "s3:GetObject", "s3:GetObjectAcl", "s3:GetObjectVersion", "s3:GetObjectVersionAcl", "s3:ListBucket", "s3:ListBucketVersions", "s3:PutBucketAcl", "s3:PutObject", "s3:PutObjectAcl", "s3:PutObjectVersionAcl", "s3:DeleteObject", "s3:DeleteObjectVersion" ], "Resource": [ "arn:aws:s3:::{ここは作成したバケット名が入る}", "arn:aws:s3:::{ここは作成したバケット名が入る}/*" ] } ] } ⑦ 保存したら先ほどの、[パブリックアクセスをすべて ブロック]のチェックを元に戻します。 以上でS3の設定は完了です。 次は、Lambdaを設定します。 Lambdaの設定 Part1 ① Lambdaのコンソール画面へ移動し、左のナビゲーションから[関数]を選択し、画面右で[関数の作成]を選択します。 ② 下記内容通りに設定 　オプション：一から作成 　関数名：Get_Secrete_Manager(自由ですが説明のために名前をつけます。) 　ランタイム：Python3.9 　アーキテクチャ：x86_64 　デフォルトの実行ロールの変更：既存のロールを使用する。 　作成したロール「Lambda_Get_Secret_Manager_Key」を入力 　詳細設定：なし 　[関数の作成]を選択し、完了 ③ 作成した関数を選択し、コードソースに以下のコードを入力 　　※pythonなのでインデントに注意してください。Quiitaに貼り付けてインデントが崩れているかもしれないので。 import os import json import boto3 import base64 from botocore.exceptions import ClientError def lambda_handler(event, context): resp_data = {} if 'username' not in event or 'serverId' not in event: print("Incoming username or serverId missing - Unexpected") return response_data # It is recommended to verify server ID against some value, this template does not verify server ID input_username = event['username'] print("Username: {}, ServerId: {}".format(input_username, event['serverId'])); if 'password' in event: input_password = event['password'] if input_password == '' and (event['protocol'] == 'FTP' or event['protocol'] == 'FTPS'): print("Empty password not allowed") return response_data else: print("No password, checking for SSH public key") input_password = '' # Lookup user's secret which can contain the password or SSH public keys resp = get_secret("SFTP/" + input_username) if resp != None: resp_dict = json.loads(resp) else: print("Secrets Manager exception thrown") return {} if input_password != '': if 'Password' in resp_dict: resp_password = resp_dict['Password'] else: print("Unable to authenticate user - No field match in Secret for password") return {} if resp_password != input_password: print("Unable to authenticate user - Incoming password does not match stored") return {} else: # SSH Public Key Auth Flow - The incoming password was empty so we are trying ssh auth and need to return the public key data if we have it if 'PublicKey' in resp_dict: resp_data['PublicKeys'] = [resp_dict['PublicKey']] else: print("Unable to authenticate user - No public keys found") return {} # If we've got this far then we've either authenticated the user by password or we're using SSH public key auth and # we've begun constructing the data response. Check for each key value pair. # These are required so set to empty string if missing if 'Role' in resp_dict: resp_data['Role'] = resp_dict['Role'] else: print("No field match for role - Set empty string in response") resp_data['Role'] = '' # These are optional so ignore if not present if 'Policy' in resp_dict: resp_data['Policy'] = resp_dict['Policy'] if 'HomeDirectoryDetails' in resp_dict: print("HomeDirectoryDetails found - Applying setting for virtual folders") resp_data['HomeDirectoryDetails'] = resp_dict['HomeDirectoryDetails'] resp_data['HomeDirectoryType'] = "LOGICAL" elif 'HomeDirectory' in resp_dict: print("HomeDirectory found - Cannot be used with HomeDirectoryDetails") resp_data['HomeDirectory'] = resp_dict['HomeDirectory'] else: print("HomeDirectory not found - Defaulting to /") print("Completed Response Data: "+json.dumps(resp_data)) return resp_data def get_secret(id): region = os.environ['SecretsManagerRegion'] print("Secrets Manager Region: "+region) client = boto3.session.Session().client(service_name='secretsmanager', region_name=region) try: resp = client.get_secret_value(SecretId=id) # Decrypts secret using the associated KMS CMK. # Depending on whether the secret is a string or binary, one of these fields will be populated. if 'SecretString' in resp: print("Found Secret String") return resp['SecretString'] else: print("Found Binary Secret") return base64.b64decode(resp['SecretBinary']) except ClientError as err: print('Error Talking to SecretsManager: ' + err.response['Error']['Code'] + ', Message: ' + str(err)) return None 一旦Lambdaの設定を中断し、次にAPI Gatewayを作成します。　 API Gatewayの設定 API Gatewayでは、外部からGETメソッドを叩いた際に先のLambdaを使用してSecretManagerに設定したS3のディレクトリなどの接続先情報を取得します。 流れ：RESTfulAPIを作成 -> 統合リクエスト、メソッドレスポンスを設定 ① API Gatewayのコンソール画面へ移動し、[APIを作成]を選択します。 ② APIタイプを選択で、[RESTfulAPI]を選択し、[構築]を選択します。 ③ 以下のように設定していきます。 　プロトコルを選択する：REST 　新しい API の作成：新しいAPI 　API名：GET_Connection_Infomation_API（自由ですが説明のために名前をつけます） 　エンドポイントタイプ：リージョン 　[APIの作成]を選択し次へ ④ 左のナビゲーションより、[リソース]を選択し、[アクション]プルダウンより、[リソースの作成]をしていきます。 　 ⑤ [アクション]から[リソースの作成]を選択し、次の画像のように、リソース名を入力していきます。 　　:::note alert 　　{serverId}のように{}を入力すると、画像の[リソースパス]のように 　　なぜか　-serverId- と、-- に変換されるため注意してください。 　　::: 　　これ２年前以上前から治ってないようですね・・・ 　　servers 　　　{serverId} 　　　　users 　　　　　{username} 　　　　　　　　　config ⑥ configまで作成したら最後に[アクション]から[メソッドの作成]を選択し、[GET]を選択します。 ⑦ そしてGETをクリックするといい感じになっていると思うので、以下を作成していきます。　 　　・統合リクエスト 　　・統合レスポンス　　　　　 ⑧ その前に左のナビゲーションから[モデル]を選択し、[作成]を選択 ⑨ モデルのスキーマに以下のコードを入力 { "$schema": "http://json-schema.org/draft-04/schema#", "title": "Error Schema", "type": "object", "properties": { "message": { "type": "string" } } } ⑩ リソースのGETに戻ります。 11 [メソッドリクエスト]を選択し、[統合リクエスト]を選択し、以下のように設定します。 　　 　　統合タイプ：Lambda 　　Lambda プロキシ統合の使用：チェックなし 　　Lambda リージョン：Lambdaを作成したリージョンを選択 　　Lambda 関数：作成したLambda関数を選択 　　実行ロール：上で作成した、Lambda_List_and_Invoke_Roleを選択 　　発信者の認証情報を使用した呼び出し：チェックなし 　　認証情報キャッシュ：発信者の認証情報をキャッシュキーに追加しない 　　デフォルトタイムアウト：そのまま 　　-> 下へスクロールし、[マッピングテンプレート]を選択 　　リクエスト本文のパススルー：テンプレートが定義されていない場合 (推奨) 　　Cotent-Type：マッピングテンプレートの追加を選択し、application/jsonを入力 　　-> application/json をクリックすると、さらに下にスクロールできるようになる 　　以下のコードを入力 { "username": "$util.urlDecode($input.params('username'))", "password": "$util.escapeJavaScript($input.params('Password')).replaceAll("\\'","'")", "protocol": "$input.params('protocol')", "serverId": "$input.params('serverId')", "sourceIp": "$input.params('sourceIp')" } 　保存が完了したら、再びGETに戻ります。 12 [メソッドレスポンス]を選択し、▶︎ を選択し行を展開し、200 のレスポンス本文 の[鉛筆]マークを選択する 13 コンテンツタイプに、application/jsonを入力し、モデルで先ほど作成したモデルを選択。 14 左のナビゲーションより、[リソース] を選択。 15 [リソース] の[アクション]より、[APIのデプロイ] を選択　　 16 以下名前を任意で設定 　　　　　デプロイされるステージ：任意（初回は新しいステージ） 　　　　　ステージ名*：任意 　　　　　ステージの説明：任意 　　　　　デプロイメントの説明 API Gatewayは変更するたびにデプロイしないと反映しないため注意 これでAPI Gatewayの設定は完了です。 次はTransferFamilyを設定します。 TransferFamily ① AWS Transfer Family のコンソール画面へ移動し、 [サーバーを作成] を選択する。 　　以下を設定していく 　　　　　プロトコルを選択：SFTP 　　　　　IDプロパイダ：カスタム 　　　　　カスタムプロパイダ：作成したAPI GateWay のステージに表示されているエンドポイントURL 　　　　　ロール：作成したAWS Transfer Family用ポリシーがアタッチされているロール 　　　　　　-> TransferFamily_Role 　　　　　エンドポイントのタイプ：パブリックアクセス可能 　　　　　カスタムホスト名：なし 　　　　　ドメイン：S3 　　　　　CloudWatch ログ記録：任意 　　　　　暗号化アルゴリズムのオプション：最新のものを選択 　　　　　サーバーホストキー：なし 　　　　　タグ：任意 　　　　　アップロード後の処理：設定不要 　　　　　 　　　　　→ 設定完了後、[サーバーを作成]を選択し、数分待ちSFTPサーバーがオンラインになるのを待つ これでTransfer Familyの設定は完了です。 次は、SecretManagerを設定します。 AWS Secret Manager ① AWS Secret Manager のコンソール画面へ移動し、[新しいシークレットを保存する] を選択し、以下を設定 　　　　　シークレットのタイプ：その他のシークレットのタイプ 　　　　　暗号化キー ：DefaultEncryptionKey（任意） 　　　　　[キー: 値のペア]：（以下） 　　　　　username: 任意　下の重要を参照 　　　　　Password: 任意 　　　　　Role: 作成したS3アクセス用ポリシーとAPIGateway GET用ポリシーが付与されたロールのARN 　　　　　　-> TransferFamily_RoleのARN 　　　　　HomeDirectory: 作成した{S3バケット名/ディレクトリ} 　　　　　　-> /test-bucket/sftp 　　　　　serverId: 作成したAWS Trasnfer Family のサーバー名 　　　　　！重要！ 　　　　　-> シークレットの名前：SFTP/{任意の名前} 　　　　　　※SFTP/ 以降が接続に使用する username となります。 　　　　　リソースのアクセス許可 - オプション：任意 Lambdaの設定に戻ります Lambdaの設定 Part2 ① Part1で作成した関数を選択すると、API Gatewayがトリガーされています。 ② [設定]タブの左のナビゲーションの[アクセス権限]より、[実行ロール]を設定します 　　-> Lambda_Get_Secret_Manager_Key_Role ③ 左のナビゲーションの[環境変数]より、キー：「SecretsManagerRegion」値：「{リージョン}」を設定します。 ④ [テスト]を選択し、以下を入力します。 　　 { "username": "", "password": "{SFTPのパスワード}", "serverId": "{TransferFamilyのSFTPサーバーID}", "protocol": "SFTP" } ⑤ 作成した[テスト]を実行し、成功するとSecretManagerのRoleArnとHomeDirectoryを返却します。 { "Role": "arn:aws:iam::123450123456:role/TransferFamily_Role", "HomeDirectory": "/test_bucket/SFTP" } これでLambdaの設定も完了です 環境の確認 ファイル転送プロトコルクライアントを使用しファイルを転送する 　　・FileZilla 　　　https://filezilla-project.org/download.php?type=client ここではfilezillaを使用する 　　① [ファイル] タブを選択し、[サイトマネージャ]を選択 　　② [新しいサイト]を選択 　　③ [一般]タブで、[プロトコル] より SFTP を選択する 　　④ [ホスト] に、以下を入力 　　　　　sftp://hostname 　　　　　※hostnameは、SFTPサーバーのエンドポイント。AWS Trasfer Familyで作成したサーバーを選択し確認できる。 　　⑤ [ポート] に 22 を設定 　　⑥ [ログオンタイプ] で [パスワードを訪ねる] を選択する 　　⑦ [ユーザー] 名を入力する 　　　　　■AWS Secret Managerのシークレット名の SFTP/以降がユーザー名となる 　　⑧ [接続] を選択して接続の完了を確認する 　　⑨ バケット領域へファイルをドラッグ＆ドロップし、転送されることをS３で確認 お疲れ様でした

書き置き Udemyの「AWSソリューションアーキテクトアソシエイト短期突破講座」をもとに作成。 S3 利用コストはリージョンによって価格が異なる。 ライフサイクル設定 バケット全体やPrefixに設定する。 最大1000ルールが設定できる。 MFA Deleteが有効だと設定不可になる。 アクセス管理 IAMユーザーポリシー IAMユーザーに対して権限を設定する。 バケットポリシー JSONで設定する。 外部ユーザーも含めて管理ができる。 ACL XMLで設定する。 オブジェクトに個別に設定可能。 署名付きURL アカウントAの所有するバケットに対して、アカウントBがアクセスする許可を与えられる。 SDKで生成した権限URLを一定期間付与する。 第三者が閲覧することができる。 クロスアカウントアクセス S3アクセスポイント アクセス先に応じてアクセスポイントを作成して、ポリシーを適用しアクセス設定が可能になる。 静的WEBホスティング メリット サーバーなしにWEBサイトをホスティングできる。 マルチAZの冗長化を勝手にしてくれる。 Route53で独自ドメインを設定できる。 CloudFrontによって配信可能。 デメリット サーバースクリプト言語を実行する動的サイトは利用不可。 単独ではSSLを利用できないので、CloudFrontが必要。 WEBサイトエンドポイント http://bucket-name.s3-website-region.amazonaws.com http://bucket-name.s3-website.region.amazonaws.com クロスオリジンリソースシェアリング（CORS） 1つのWEBサイトを複数ドメインで共有して利用できる。 整合性モデル 新規登録 登録後即時にデータが反映される。 更新 2020/12より強い整合性モデルに変更された。 齟齬は発生しない。 削除 2020/12より強い整合性モデルに変更された。 齟齬は発生しない。 アップロード時のデータ整合性確認 オブジェクトのbase64でエンコードされたMDSチェックサム値を取得する。 アップロード中のオブジェクトの整合性を確認する。 但し、アップロードがAWS署名Ver4でされている場合は、x-amz-content-sha256ヘッダを使用する必要がある。 マルチパートアップロード 大容量オブジェクトをいくつかに分けてアップロードする。 Glacier 構成要素 ボールト アーカイブ（S3のオブジェクトに相当し、各アーカイブには138バイトのランダムなIDが自動で割り当てられる）を保存するための領域。S3のバケットに相当する。 インベントリ 各ボールトに保存されているアーカイブの情報を収集する。およそ1日1回の頻度で更新されるため最新情報の反映にはタイムラグが発生する。 リアタイで確認したい場合は、マネジメントコンソールから確認するか、ListVaults APIを実行する。 ジョブ アーカイブやインベントリに対して検索をかけたり、データをダウンロードするといった要求に対して処理を実行し、処理状況を管理する。 取り出しオプション 高速、標準、バルクの三種類の取り出しオプションがあり、翌日に見られれば十分と言った場合はバルクオプションを利用すると良い。 Glacier Select アーカイブデータに対してSQLを実行し、条件にあったデータを抽出できる。 EC2 利用コストはインスタンスを停止することで課金を抑えられる 開始 / 再起動（Running） 実行時間に応じて料金が発生する 利用中のEBSボリュームの料金が発生する 停止（Stop） EC2の利用料金は停止する 利用中のEBSボリュームの料金が発生する 終了（Terminate） EC2の利用料金は停止する デフォルトではルートボリュームに設定されたEBSボリュームも削除され、料金発生は停止する AMI EC2のバックアップとして構成内容を保存する（EBSボリュームのスナップショットも含まれる） 最適なEC2インスタンスの構成を反映したAMI（＝ゴールデンイメージ）を複数利用できる AMIの共有は、アカウント番号を指定するだけで、ほかアカウントに共有可能 AMIはリージョン内でのみ利用可能。別リージョンにコピーして別AMIとして利用可能。 キーペア ユーザーがPCにダウンロードした秘密鍵を使って、EC2インスタンスの公開鍵とマッチさせる 1つのVPCにおいて最大5000個発行可能 EC2フリート オンデマンドインスタンスとスポットインスタンスで構成されるインスタンスグループとして設定を定義する仕組み スポットフリート インスタンスタイプや入札価格を指定することで、自動で最安値のインスタンスを選択して起動する スポットブロック メリット 最大６時間まで中断することがない 途中で中断する可能性があるスポットインスタンスの利用を安定させる スポットフリートのオプションとして設定可能 デメリット 通常のスポットインスタンスよりも値段が若干高くなるため最安値ではなくなる。 プレイスメントグループ 単一のAZ内のインスタンスのパフォーマンスを向上させるために論理的にグループ化する機能 クラスタープレイスメントグループ 単一AZ内のインスタンスを論理的にグループ化した構成 同じリージョン内の複数ピアVPCにまたがることができる グループ内のインスタンスはTCP/IPトラフィックのフローあたりのスループット上限が高くなり、ネットワークの2分帯域幅の広い同じセグメントに配置されインスタンス間通信が向上する 低いネットワークレイテンシー、高いネットワークスループットを実現するアプリケーション向けの構成 パーティションプレイスメントグループ EC2は各グループをパーティションと呼ばれる論理的なセグメントに分割した構成 プレイスメントグループ内の各パーティションにそれぞれ一連のラックがあり、プレイスメントグループ内のパーティション同士が同じラックを共有しない ラックを分離することで、アプリケーション内でのハードウェア障害による影響を隔離して軽減する スプレッドプレイスメントグループ それぞれ独自にネットワーク及び電源がある異なるラックに別々に配置できるインスタンスのグループ 1つのAZ内のスプレッドプレイスメントグループに配置された7つのインスタンスは、7つの異なるラックに配置される 少数の重要なインスタンスが互いに分離して保持できる。インスタンスが同じラックを共有する時に発生する可能性のある同時障害リスクを軽減する EC2のリカバリー 定期的にバックアップ（IAM/スナップショット）を取得する 定期的にリカバリプロセスを確認する 複数のAZに重要なアプリケーションをデプロイする CWによりインスタンスのステータスをモニタリングする チェック結果が失敗の場合はCWアラームアクションを使用してインスタンスを自動的に復旧 自動復旧後のステータスとIPアドレスは元のインスタンスと同じ インスタンス起動じに動的IPアドレス処理の設定を行う ハイバネーションを利用し、再起動時に停止前の状態を維持する シャットダウン前にメインメモリの内容をハードディスクなどに退避することで、次回起動時にまたメインメモリに読み込み、シャットダウンする前と同じ状態で起動する インスタンスタイプに応じてハイバネーションの実施可否が決まる 現在では、M3~M5, C3~C5, R3~R5に加えて、Amazon Linux2 や WIndowsなども対応している VPC CIDR（Classless Inter-Domain Routing）と呼ばれる、サブネットマスクの値を設定し、同じネットワークとして扱うIPアドレスの個数を調整できるIPアドレスの設定方法で表現する /16を設定した際に設定可能なサブネット数とIPアドレス数の組み合わせ インターネットゲートウェイ パブリックサブネットからインターネットに接続するにはインターネットゲートウェイが必要 ルートテーブルによりインターネットゲートウェイへのルートを確立する NATゲートウェイ プライベートサブネットからインタネットに接続するにはNATゲートウェイがパブリックサブネットに必要 ルートテーブルによりインターネットゲートウェイへのルートを確立する AWSマネージドサービスのため冗長性が高く、管理が楽 NATインスタンス ユーザーが管理するサービス VPCエンドポイント グローバルIPを持つAWSサービスに対し、VPC内から直接アクセスするための出口 ゲートウェイ型エンドポイント AWSサービスをあて先とするトラフィックのルートテーブルのあて先として指定できるゲートウェイ DynamoとS3にのみ適用可能 ゲートウェイ型はサブネットに特殊なルーティングを設定し、VPC内部から直接外のサービスと通信する 無料で利用でき、AWS側で冗長性を確保するマネージドサービス プライベートリンク型エンドポイント（インターフェイス型） AWSサービスをあて先とするトラフィックのエントリポイントとして機能するサブネットのIPアドレス範囲のプライベートIPアドレスを持つElastic Network Interface プライベートIPアドレスを使用してサービスにプライベートアクセスする RDSやEC2などの多くのサービスに適用可能 有料で利用できるマルチAZ設計により冗長性を担保する VPC Peering 2つのVPC間でのトラフィックルーティングが可能 AWSアカウントを跨いで接続することが可能 セキュリティグループ サーバー単位で適用できる ステートフルのため、インバウンドのみ設定すればアウトバウンドも許可される（＝状態を維持する） 全てのルールを適用する デフォルトでは同じSG内通信のみ許可する設定になっている 許可のみをIN/OUTで指定するホワイトリスト形式 ネットワークACL VPC/サブネット単位で適用できる ステートレスのため、インバウンド設定だけではアウトバウンドは許可されない 番号順に適用していく デフォルトでは全ての通信を許可する設定になっている 許可と拒否をIN/OUTで指定するブラックリスト形式 VPCフローログ ネットワークトラフィックを取得し、CWでモニタリングできるようにする機能 VPC内の通信の解析に使用する 追加料金は発生しない VPCにおけるDNSの使用 enableDnsHostname パブリックIPアドレスを持つインスタンスが、対応するパブリックDBSホスト名を取得するかどうかを示す この属性がtrueでenableDnsSupport属性もtrueである場合、VPC内のインスタンスはDNSホスト名を取得できる enableDnsSupport DNS解決がサポートされているかを示す この属性がfalseの場合、パブリックDNSホスト名をIPアドレスに解決するRoute53 Resolverサーバーが機能しない この属性がtrueの場合、DNSサーバー（169.254.169.253）へのクエリ、またはリザーブドIPアドレス（VPCIPv4ネットワークの範囲に+2したアドレス）へのクエリは成功する ENI（Elastic Network Interface） 仮想ネットワークカードを表すVPC内の論理ネットワーキングコンポーネント。 インスタンスへのIPアドレス割り当て時に利用する AutoScaling スケーリングポリシーの設定 ターゲット追跡スケーリングポリシー（簡易スケーリングポリシー） CWのモニタリングメトリクスを利用したスケーリングを実施できる ライフサイクルフック AutoScalingグループによるインスタンスの起動時または削除時にインスタンスを一時停止してカスタムアクションを実行することができる Lambdaと連携した処理も可能 RDS ストレージタイプ 汎用タイプ SSDタイプ GBあたりの容量課金を実施 通常のパフォーマンスに加えてバーストを実施し、100~30,000IOPSを実現可能 プロビジョンドIOPS SSDタイプ GBあたりの容量課金を実施＋プロビジョンド済みIOPS単位の課金 通常のパフォーマンスに加えてバーストを実施し、1,000~30,000IOPSを実現可能 マグネティック（古いタイプ） ハードディスク GBあたりの容量課金を実施＋　IOリクエスト課金 平均100~最大数百のIOPS 冗長化構成 パブリックアクセス構成 パブリックサブネットにRDSを設置し、直接SQLクライアントツールで接続して操作する（MySQLの場合はWorkbenchがよく使われる） 一般的な構成 RDSをプライベートサブネットに設置して、EC2インスタンスを踏み台にしてアクセスする ただし、AZ障害が発生した場合、対応できない マルチAZ構成により、非常に簡単にフェールオーバーが利用可能となる。 ゲールオーバー時にCNAMEレコードがプライマリからセカンダリに移行する リードレプリカ 参照専用のレプリカを最大5台（AUuroraは15台）設置し、DBの読み取り処理をスケールアウトできる RDSのスケーリング インスタンスサイズの変更 インスタンスタイプの変更 ストレージタイプの変更がある。 AutoScallingで容量が増加できるが、減少させることはできない。（RDSのAutoScallingはパフォーマンス性能向上ではなく、容量アップによって実行される） RDSの暗号化 インスタンス作成時のみ暗号化を設定可能（後からする場合はスナップショットを取得してから再構築する際に設定することで暗号化できる） 通信の暗号化 SSL/TLSを使用して、DBインスタンスへの接続を暗号化する 保管データの暗号化 - 保管時のデータリソースを暗号化する EBS EC2インスタンスとともに利用されるブロックストレージ 1つのEBSを複数のインスタンスで共有することはできない 同じAZ内のインスタンスのみ付け替え可能（他のインスタンスに付け替え可能） ELB ALB レイヤー7で実行される 単一ロードバランサで異なるアプリケーションへリクエストをルーティングが可能 1つのインスタンスに複数ポートを登録可能 加重ロードバランシングが利用可能 NLB レイヤー4で実行される 超低遅延で高スループットを維持しながら秒間何百万リクエストを捌くように設計された高性能ロードバランサ 事前申請が不要 ELBの主要機能 ヘルスチェック機能 配下のEC2の負荷に応じて、複数AZにまたがるEC2インスタンスに均等に負荷分散を行うクロスゾーン負荷分散 暗号化通信 セッション中に同じユーザーからきたリクエストを継続して同じEC2インスタンスに送信するスティッキーセッション インスタンスが登録解除されるか、以上が発生した場合に、そのバックエンドインスタンスへの新規リクエスト送信を中止するConnection Draining ログ取得 SQS ポーリング処理（一旦中継に通信内容をためておき受信側のタイミングが良い時に通信を行う）型のキューイングサービスでタスクの並列実施などに利用される 疎結合アーキテクチャを実現可能 主要機能 標準キューでは通信順序は保証されないが、FIFOキューを採用すると順番を保証できる 優先キューは他のキューよりも優先的に処理させることが可能 メッセージ保持期間中はメッセージを保持するが、超過するとメッセージを削除する デフォルトでは４日間（最小60秒〜最大14日で設定可能） アプリケーション上でメッセージを削除する処理を実施しないと期間を超過するまでキューが滞留してしまう 発行したメッセージは取り消し不可 配信ポリシーによるキューの再試行を実施することができる 無制限にメッセージを利用することができるが、メッセージサイズは最大256KBとなっている 可視性タイムアウト 処理担当のインスタンス以外からは一定時間（30秒〜12時間）キューが見えなくなる機能 他のインスタンスが同じメッセージを再処理しないように可視性タイムアウトを設定することで、重複処理を防ぐことができる ポーリング方式 ロングポーリング 問い合わせの結果が空であった場合に、指定したメッセージ受信待機時間の間、SQSが待機してから応答を返す 空のレスポンス数を削減することができる ショートポーリング キューが空の場合に、すぐに空のメッセージが返される キューの詳細設定 遅延キュー キューへの新しいメッセージの配信を数秒遅延させることができる（0秒〜15分） 可視性タイムアウトとの違いは、キューが発行された直後から見えなくなり、キュー全体に効果がある 優先度付きキュー キューの処理順序に優先度をつけ、優先対応があるタスクを最初に処理するようにワークフローを設定できる デッドレターキュー 正常に処理（消化）できないメッセージを別のキューへ移動させ、処理不能なキューの滞留を防げるほか、処理できなかった原因を後で解析できる CloudFront CDN（Content Delivery Network）サービスとして、WEBコンテンツなどを配信する際に主にエッジサーバーとして使われる 210以上のエッジロケーションによる高性能な分散配信 WAFやCertificate Managerとの連携やDDoS対策によるセキュリティ機能を持つ オリジンに対してHeader, Cookie, Query Stringによるフォワード指定で動的なページ配信が可能 Gzip圧縮機能 エッジ側でコンテンツをGZIP圧縮してより高速に配信可能となる DynamoDB キーバリュー型（ワイドカラム型）によりデータを簡易に操作できる できること キーに対するバリューのCRUD操作 簡易なクエリやオーダー できないこと・向いていないこと JOIN, TRANSACTION, COMMIT, ROLLBACKは不可 詳細なクエリやオーダー（データ検索や結合処理など）は向いていない 大量のデータ読み書きにはコストがかかる 整合性モデル 書き（Wriite） 少なくとも2つのAZで書き込み完了が取れた時点で完了 読み（Read） デフォルトでは結果整合性モデルが採用され、最新の読み取り処理が反映されない場合がある オプションで、強い整合性モデルが選択でき、GetItem, Query, Scan では強い整合性のある読み込みオプションが指定可能 キャパシティモード オンデマンドモード プロビジョニングモード プライマリキー ハッシュキー データを特定するためのIDなどのこと 単独での重複を許さない レンジキー ハッシュキーにレンジを加えたもの。複合キーとも呼ぶ。 2つの値の組み合わせによって、1つの項目を特定する 複合キーは単独であれば重複が許される DynamoDBストリーム Dynamoテーブルに保存された項目の追加/変更/削除の発生時の履歴をキャプチャできる機能 データ保存 過去24時間以内のデータ変更履歴を保存し、24時間経過すると消去される データ容量はマネージド型で自動的に管理される データ保存の順番 捜査が実施された順番に応じてデータがシリアライズされる DAX（DynamoDB Accelerator） DynamoDBにインメモリキャッシュ型の機能を付加する Lambda リクエスト数とコードの実行期間で算出されて課金される Lambdaの制限 関数のタイムアウトはデフォルトで3秒、許容最大数は900秒（15分）。タイムアウトに達すると関数が停止される 最大同時実行数はデフォルトで100（最大は1000だが、申請によって数十万まで引き上げ可能） 関数の実行時に使用できるメモリは128MB〜3008MBと制限されている /tmpディレクトリのストレージは512MBまでとされている Lambdaレイヤー（共通処理関数）は最大5妻で設定可能 Lambdaエッジ（Lambda@Edge） CloudFrontの配信コンテンツをLambda関数によってエッジロケーションで処理することが可能 Route53 IPアドレスを人間が読みやすいURLに変換して住所として利用できるようにしてくれるDNSサーバーの役割を提供する https://www.yahoo.co.jp/ → DNS → https://196.10.0.1 というように、IPアドレスに変換するのがDNS ポート53で動作するため、Route53と呼ばれる エイリアスレコードタイプ A ホスト名とIPv4アドレスの関連づけを定義するレコード MX メールの配送先（メールサーバー）のホスト名を定義するレコード CNAME 正規ホスト名に対する別名を定義するレコード 特定のホスト名を別のドメイン名に転送する時などに利用する ルーティングポリシー シンプルルーティング レコードセットで事前に設定された値のみに基づいてDNSクエリに応答する 特殊なルーティングポリシーを使わない標準的な1対1のルーティング 加重ルーティング 複数エンドポイントごとの重み設定によりDNSクエリに応答する 指定した比率で複数リソースにトラフィックをルーティングする際に使用する ABテスト（AパターンとBパターンを比べて修正後のBがどの程度の成果が出るかを検証するテスト）のために新サービスをリリースしたサーバーに一定割合のユーザーを誘導したい場合にも利用できる フェイルオーバールーティング ヘルスチェックの結果に基づいて、利用可能なリソースをDNSクエリに応答する スタンバイ/アクティブ方式でアクティブ側のヘルスチェックが失敗したときにスタンバイ側のシステムへルーティングする 本番システム稼働時にSorryサーバーのIPアドレスをセカンダリレコードに登録しておくと、自動的にSorryコンテンツを表示できる 複数値回答ルーティング ランダムに呼ばれた最大8つの別々のレコードを使用してIPアドレスを設定し複数値を返答する 1つのレコードに異なる複数のIPアドレスを登録しておき、ランダムに返却されたIPアドレスに接続する ヘルスチェックがNGとなったIPアドレスは返却されないため、正常に稼働しているサーバーに対してのみアクセスを分散させることができる レイテンシールーティング リージョンの遅延によりDNSクエリに応答する 基本的にユーザー最寄りのリージョンに返答する 位置情報ルーティング ユーザーのIPアドレスにより位置情報を特定して、地位ごとに異なるレコードを返す ネットワーク構成に依拠しない精度の高いレコードの区分けが可能 地理的近接性ルーティング ユーザーとリソースの場所に基づいて地理的近接性ルールを作成してトラフィックをリーティングする 必要に応じてバイアスを設定し、特定のリソースにルーティングするトラフィック量を変更できる トラフィックフローを利用する必要がある フェイルオーバー リージョンを跨いで設定することができる アクティブ/パッシブ方式 プライマリリソースをアクティブなリソースとしてルーティングする 障害発生時、Route53はセカンダリリソースをルーティングする フェイルオーバーポリシーを使用して設定する アクティブ/アクティブ方式 複数のリソースをアクティブとしてルーティングする 障害発生時、正常なリソースにフェイルバックする フェイルオーバー以外のルーティングポリシーを使用して設定する Aurora RDBの一つだが、マルチクラスタ構成を採用している 従来のRDBは集中管理するものだが、クラウド時代の分散型のRDBとして誕生した 高い並列処理によるクエリを高速処理が実現できる 大量の書き込みや読み込みを同時に扱うことができる DBの集約やスループット向上が見込まれる MySQLとPostgreSQLと互換性があり、同じ操作方法で扱うことができる 耐障害性と自己回復性 3つのAZに2つのコピーを設置可能で合計6つのコピーを保持する 過去のデータがそのままS3に継続的にバックアップされる リストアも差分適用がなく高速に処理できる どのタイミングでも安定したリストアを実現できる 99.99%の高可用性と高耐久性を持つ。 スケーラビリティ 10GBから最大64TBを提供するSSDデータプレーンを利用してシームレスに拡張可能 最大15のリードレプリカを利用した高速読み込みが可能 Elastic Beanstalk vs. OpsWorks Elastic Beanstalk アプリケーションのデプロイ自動化 OpsWorks インフラの設定自動化 AWS Step Functions vs. SWF Step Functions（推奨） ステートマシンをJSONで記述する Lambdaと統合されたサーバレスアプリケーション SWF JavaとRubyでコード記述できるが、複雑になりがちなため利用は推奨されていない プロセスにおいて介入する外部信号が必要な場合、あるいは、結果を親に返す子プロセスを起動する場合はSWFを利用する Snowball - Snowball Edge - Snowmobile 以上