2020年6月17日から6月19日に開催しました、Architecting on AWS for APN Partnerにていただきましたご質問と回答の一部を掲載します。
以下は、2020年6月19日現在の情報を元に回答しております。
Q.AWSの特定サービスに障害が発生した際のシミュレーションをする方法はありますか。
例えばデータベースの疑似障害を発生させ、レプリカに切り替わるまでの影響を確認するなど。
AWS側が管理しているマネージドサービスの場合（Lambdaの障害など）は事前確認は難しいでしょうか。
A. RDSがフェイルオーバーした際のアプリケーションの挙動を確認される場合は、フェイルオーバーして再起動を手動で行うことができます。
その他、例えばAuroraには、テストのために障害を投入するクエリもあります。
https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Managing.FaultInjectionQueries.html
Q. 大阪リージョンは、現時点だと利用できないリージョンなのでしょうか。
A. 現時点では大阪リージョンはアベイラビリティゾーン(AZ)が１つだけの特別なリージョンとなり、利用のためには申請が必要です。2021年に3つのAZのリージョンへ拡張される予定です
Q. 東京にいながら例えば海外のリージョンを使用する際のデメリットやリスクはありますか？パフォーマンス劣化等のリスクがあるのでしょうか。
A. 距離が離れると通信のレイテンシーが発生します。また、データを国内にしか置けないなどの制限がある場合も利用はできません。
リージョン、サービスによっては利用コストが東京リージョンより安価になる場合もあります。
Q. 大阪リージョン以外のリージョンで、提供されているサービスの種類に差はあるのでしょうか
A. リージョンにより提供されるサービスが異なることはあります。以下のサイトを御覧ください
https://aws.amazon.com/jp/about-aws/global-infrastructure/regional-product-services/
Q. 「バケットポリシーのサイズは 20 KB に制限されています」ですが、複雑な条件を指定できる限界があるということでしょうか。
多くのオブジェクトを取り扱い、かつ、細かくポリシーを制限する場合はバケットを分ける必要がある？
A. S3アクセスポイントという機能を利用すると、1つのバケットに対し複数のアクセスポイントを設けることができ、アクセスポイントごとにポリシーを設定することができます。長いポリシーを書く場合はアクセスポイント機能を使うと煩雑な管理を避けられます。
Q. 静的コンテンツをS3に配置してWebサーバとして利用すれば、確かに可用性が高く適切な配置であるのは分かるのですが、動的コンテンツを含むページの場合はEC2を使用するとなると、障害分岐点が増えてしまうだけに思うのですが、違いますでしょうか？
静的コンテンツ：www.a123.html S3から配信
動的コンテンツ：www.b123.html EC2から配信
S3配置できるのって、現実的にはメンテンスページやsorryページくらいが一般的ではないのでしょうか。
A. どこか一部で障害が発生しても静的な部分だけでも動くほうが、システムとしては機能的です。静的なコンテンツをS3に分離することで、EC2で提供している動的コンポーネントが故障しても静的コンテンツはサービスとして提供できる、という考え方です。
Q. オブジェクトロックを設定／解除できる権限を持つユーザはルートユーザのみになりますか？
A. いいえ。S3オブジェクトロックにはガバナンスモードとコンプライアンスモードがあります。ガバナンスモードでは、IAMポリシーでオブエジェクトロックの解除を許可されたユーザーが解除でできます。コンプライアンスモードではルートユーザー含め誰も解除できないロックを期限付きで設定することができます。
Q. データレイクとして、S3を使用する場合・その他AWS上のDBを使用する場合の各メリット・デメリットをお聞きしたいです。
A. AWSのマネージドデータベースサービスで集計を行う用途としては、Redshiftが考えられます。Redshiftを常時使用するようなケースでも、S3のデータを直接的にクエリできるRedshift Spectrumがあります。集計するときだけRedshiftを利用することが考えられます。データはS3、集計や分析は他のサービスと連携すればストレージコスト、運用管理の低減などメリットがあります。
Q. S3はストレージ保存量、転送量に応じた課金が発生すると先ほど伺ったように思います。
先ほどご紹介いただいたようなデータレイクとしての使用の場合も、もちろんかかってくると思うのですが、これは料金としてもベストプラクティスということなのでしょうか？
A. EBSやRDSにデータをため続けた場合と比較してもコストメリットがあります。
Q. S3はスケールできるということですが、例えば秒間100通のデータを1通ごとに1ファイル作成し続けると、1時間で36万ファイルできます。ファイルの量に対してベストプラクティスありますか？
A. S3においてはこのようなケースでも別段問題はありません。秒間3,500以上のPUTアクセスが要求される場合はハッシュプレフィックスを利用するとパフォーマンスを向上させることが出来る場合もあります。
https://aws.amazon.com/jp/premiumsupport/knowledge-center/s3-object-prefix-naming/
Q. GlacierからS3に取り出して、用事が終わったらGlacierに戻せるのでしょうか？
(それとも、Glacier上に残存するのでS3に取り出したものは使用後に削除すれば良いのでしょうか。)
A. 後者です。S3にはコピーが取り出されます。
Q. Glacier は簡単にアクセスできないわけですが、例えば、オンプレの資産管理のログデータをアーカイブとして保存、ログの確認のために再取込みする必要がある場合にも向いている認識でしょうか。またインターネット外への取り出しはS3と同じ料金になるのでしょうか。
A. はい、向いています
S3に取り出した後、インターネット経由でダウンロードする場合は、インターネット向けの転送料金が課金されます。
ログアーカイブには向いていますが、あまり小さなデータを大量に保管する用途の場合、Glacierへの移行料金が発生しますので圧縮アーカイブにして保管するという方法もあります。
Q. ライフサイクルポリシーは設定するポリシー数等によって料金が掛かるものでしょうか。
S3の利用料金に含まれるものでしょうか？
A. ポリシー数によっての料金は発生しません。
移行するリクエストによって料金が発生します。
Q. ストレージクラスが4段階ある中で、可用性が異なるのはS3 1ゾーンIAのみ、他より劣る（シングルAZ）という認識で合ってますか？
A. 1ゾーンでない標準 IAでも、可用性は下がります。
https://aws.amazon.com/jp/s3/storage-classes/
Q. 各種AWSに対してAPIを経由することは分かりましたが、コンソール、SDK、CLIで出来ることに違いはありますか？もし差がある場合、どれが一番出来ることが多いでしょうか？
A. CLIのほうが出来ることが多い印象です。例えば、Lambdaで共通ライブラリを保存しているLayersをダウンロードしたい場合は、マネージメントコンソールでは不可能で、CLIを利用することで可能となります。
Q. S3 マネジメントコンソールで、個々のオブジェクトが公開されているか？そうでないか？はどのように知ることができるでしょうか？
A. オブジェクト選択後の[アクセス権限]タブにアクセスコントロールリストがあります。そこで、Everyone の読み取りが「はい」になっていると公開されています。
Q. AWSの機能を利用する上で、APIにかかる負荷がボトルネックになることはあるでしょうか。
（秒間リクエスト数に制限があったり、APIがエラーを返したり、など）
A. S3へのリクエストはプレフィックス単位でPUT 3,500/秒、GET 5,500/秒なら待たずに処理がされます。他のサービスでも制限があるものは、それぞれのサービスで制限の記載があります。
また、後ほどご紹介する、DynamoDBのようにAPIリクエスト数をキャパシティとして設定しておいて、そのキャパシティ(秒間何回のリクエストを行うか)に対して課金が発生するものもあります。
Q. 聞き漏れたかもしれませんが、一度決めたEC2のファミリーは、後から別のファミリーに変更可能でしょうか？
A. できないものもあれば、できるものもあります。調査と検証が必要です。
また、AMIを取得後、変更先のファミリを設定して起動する、としていただくことで、現在の環境を残したまま、新しいインスタンスで検証できます。
Q. スナップショットからの復元は、既存EC2インスタンスのリストアではなく、同じ構成の新規EC2インスタンスを起動する、というイメージでしょうか。
（オンプレサーバのシステムリストアのイメージとは異なる？）
A. 同じ構成の新規EC2インスタンスを起動します。
Q. M4やM5の世代については、大きめのナンバリングの性能が高いとのことですが
後から変更可能でしょうか？またサービス停止はせずに変更可能でしょうか？
A. インスタンスタイプの変更には、EC2インスタンスの一時停止が必要です。
すでに作成済みのAMIがあれば、そのAMIから新規のインスタンスを起動し検証した後に本番サーバーとして差し替えることができればワークロード全体としては無停止でリクエストを受け続けることができます。その場合EBSにデータや情報は持たずに、S3やRDSなどと組み合わせての設計を検討します。
Q. 例えば無料利用枠のt2.microをデプロイした際でも、ボリュームを追加するとその分料金が発生するのでしょうか？
A. アカウント作成後1年間はEBSボリュームは30GiBまでが無料利用枠です。
Q. EFS、FSxのボリュームは、同時に複数のEC2インスタンスでマウントが可能なのでしょうか。
同時アクセスによるファイルの破損などは発生しないでしょうか。
A. はい、可能です。
ファイルの競合など取り扱いはアプリケーションの仕様に依存します。
Q. オンデマンドのインスタンスの自動起動・停止に関する質問です。
指定した日付と時間にインスタンスを自動的に起動、停止できますか？
例えば、日本の仕事日に合わせて、仕事日の9時に起動し、20時に停止したい場合、何か方法がありますでしょうか。
A. 昔はLambdaなどでSDKを使ってコーディングする必要が過去はありましたが、現在はSystemsManagerを使用して、コーディングせずに自動化ができます。
Q. スケジュールRIは、起動そのものも設定したスケジュールになるのでしょうか？
それとも、手動で上げ落としを行い、決めた時間に上がっていた際に割引になるのでしょうか？
A. 手動で上げ落としを行い、決めた時間に上がっていた際に割引になります。
使っていなくても設定した時間分の割引料金が発生します。
Q. スポットインスタンスの終了の2分前に終了通知とありますが、これはEC2インスタンスのアクションの停止が行われるという認識でよろしいでしょうか？
A. デフォルトはアクションの「終了」が行われる2分前に通知があります。停止、休止を選択することもできます。
Q. リレーショナルデータベース、非リレーショナルデータベース、S3について選び方の事例を教えていただけないでしょうか？
A. データを溜め込んでいくだけであればS3が向いています。アプリケーションからリアルタイムにデータにアクセスする場合はデータベースを使います。一例としまして、大量なアクセスは発生せず、複雑なクエリや結合を必要とする業務系アプリケーションなどではリレーショナルデータベース、アクセス量に変動があり、単純なデータモデルを扱える、モバイルアプリケーションやゲームアプリケーションなどでは非リレーショナルデータベースが使用されるケースがあります。
Q. AWSのDBを複数のAZに配置する件について、AuroraDBはAZを意識する必要が無い（裏で自動的に複数のAZにコピーされて一つのAZで障害があれば他に自動で切り替わる）という認識でよろしいでしょうか。（耐障害性という意味ではRDSよりDynamoDBに近いイメージという認識です）
A. データ層はもともと各AZに冗長化して配置されていますが、インターフェース層のレプリカはAZごとに配置されます。フェイルオーバーは自動で起こりますが、ダウンタイムは発生いたします。
Q. sse-cのcは何の略でしょうか？
A. Customerの略です。
Q. EC2のユーザーデータとメタデータの違いが理解しきれませんでした。
いずれもAMI起動時に実行されるコマンドといったイメージなのですが。
A. ユーザーデータは、EC2起動時に実行されるものです。メタデータは、メタ情報、を指します。EC2のOSの階層よりも１階層上にあるAWSの管理する情報のことを指しています。
Q. DBでいう水平スケーリングとはどういうことでしょうか？EC2だとインスタンス数を増やすということだと思いますが、DBだとイメージが湧きませんでした。
A. EC2と同様にサーバが増え、そこにデータを再配置していくイメージです。パーテーションが増加し、データを分散していきます。
Q. DynamoDBの検索で、複数のパーティションキーに同じ値を入れておいて検索を求めたい場合どうするのですか。
A. 同じパーティションキーの項目をレスポンスで受け取ってからフィルタリングするか、ソートキーやローカルセカンダリインデックスとあわせてクエリーします。
Q. DynamoDBは性能はよさそうですが、SQL使えないとBIツールとか連携が難しそう。
現実世界では、DynamoDBだけでなく、同時にAuroraにも書き込んだりしますか？
A. DynamoDBではあまりBIツールと連携させることはしません。またデータベースは１つのシステムの中でも複数種類を選択することもあります。それぞれの要件に応じてデータベースを使い分けしてください。
Q.DMSでの継続的な移行では、移行元DBをオンラインのまま移行できるのでしょうか？「ダウンタイムを減らせる」？
A. はい。オンラインで移行を開始できます。最終的にダウンタイムは発生すると思いますが、その時間を短くすることができます。
Q. DynamoDBへの移行はどうしますか？移行できないのであれば、CSVとかでインポートできますか？
A. DMSでもターゲットデータベースとして指定可能です。また、SDKを使ってプログラムを開発すれば、どのようなケースでもインポートは可能です。
Q. DBに登録時に暗号化した場合、マネジメントコンソールでデータを確認したい際、暗号化されては中身は見れなくなるのでしょうか？
A. 透過的に暗号化されます。AWSのデータセンターで物理的に暗号化されています。
Q.Snowballによるデータ移送とDMSによるデータ移送の場合、どちらの方が優位なのでしょうか。
(価格と相談？)
A. コストと時間のトレードオフです。
利用回線によってはインターネット経由のほうが早いということもあり得ると思います。
SnowballからDMSに連携するオプションもあります。
Q. Parameter Storeに保存されている値はリージョン内で定義されるものでしょうか。
どの範囲で定義されているパラメータになるのか教えていただきたいです。
A. 権限さえ設定すれば、リージョンを越えても取得することができます。オンプレミスからでも取得可能です。
Q. Elastic IPアドレスで切り替えが発生した場合、ユーザーは切り替え前のセッションが維持できるものなのでしょうか？
A. EC2インスタンス以外でセッションを保持していれば可能です。
Q. Elastic Network Interfaceについて、説明をお伺いしてEIPのプライベートIP版だと認識したのですが、正しいでしょうか。
A. プライベートIPアドレスを保持するための使い方もできます。ただしIPアドレスではなくNetwork Interfaceです。EC2にはもともと1つのENIがアタッチされております。
Q. EC2などをElasticIPを使わずに構築した場合、指定したサブネットの中でIPアドレスが割り当てられる認識です。このIPアドレスは、サーバ停止/起動のたびに変化するということでしょうか。
A. ElasticIPを使用しない場合、パブリックIPのみがEC2の起動停止のたびに変更されます。プライベートIPは変更されません。サブネットで設定しているCIDR範囲から割り当てられるのはプライベートIPアドレスです。
Q. EC2にElasticIPを付与しないということはできるんでしょうか。
その場合、ssh接続はできなくなりますか？
A. ラボで実際された内容がまさに、EC2にElasticIPを付与していない状態です。ElasticIPやグローバルIPを割り当てていない場合、インターネットからの接続は全て不可となります。VPNを利用した接続の場合はパブリックIPアドレスの設定は不要です。
Q. SecurityGroupとインスタンス単位のFWルール(WindowsFW等)はどのように役割分担するのがベストプラクティスでしょうか？SecurityGroupが正しく設定されていればインスタンス単位はフルオープンでも構わない？
A. セキュリティグループが適切に設定されていれば、不要なトラフィックはブロックされるため、OSでの設定はなくても構いませんが、要求されるセキュリティレベルによって検討してください。
Q. インターネットゲートウェイに対するアクセス制限の必要はないのでしょうか。
A. インターネットゲートウェイに対するアクセス制限の設定は行なえません。VPC内のリソースは、ルートテーブルで適切にルートを設定し、セキュリティグループやACLでを保護します。
Q. CIDRで誤って重複するIPアドレス範囲を指定した場合はエラーになるだけでしょうか？
A. サブネット同士で重複する場合はサブネット作成時にエラーとなります。
VPC同士で重複する場合は、作成時にはエラーになりませんが、VPCピア接続をリクエストする際にエラーとなります。
Q. VPCピアリング接続なしでVPC間の通信はできないという認識でよろしいですか？
A. 直接プライベートIPアドレスでの通信ができません。
お互いのインターネットゲートウェイを介して、パブリックIPアドレスへの通信などはピア接続なしでも可能です。
Q.先ほどのQAで触れられていたかもしれませんが、複数のEC2インスタンスで別々のアプリ（Webサーバとアプリケーションサーバ等）を起動し、各アプリケーション間で通信を行うような場合、アプリケーションに指定する接続先アドレスとしては、どのようにするのがベストプラクティスでしょうか。(以下の3だと推測しています）
1．Webサーバからアプリケーションサーバには、アプリケーションサーバのプライベートIPアドレスを指定する（EC2インスタンスを障害時に起動しなおした場合、Webサーバの設定変更が必要）
2．Webサーバからアプリケーションサーバには、アプリケーションサーバのDNS名を指定する（上と同じ？）
3．DNSサーバを使用してDNS名を固定にする
A. 結論から申し上げますと、Elastic Load Balancingを間にはさむのがベストプラクティスです。
3ももちろんいいのですが、VPC内で使用できるDNSサーバーを用意する必要があり、その運用が増えます。
アプリケーション・サーバーのプライベートIPアドレスが維持できればいいのであれば、ENIを追加するのも1つの選択肢です。
Q. リージョン、VPC、アベイラビリティーゾーン、サブネットの包含関係が混ざってきてしまいました。包含関係の整理とそれぞれとの通信を可能にする方法の整理をお願いできないでしょうか？
A. VPCはリージョンを選択して作成します。サブネットはAZを選択して作成します。VPCには複数のAZを含むことができます。
VPC内の通信は最初から可能です。ローカル向けのエントリを削除することはできません。
Q. サブネットにアタッチしているルートテーブルにLocalがありますが、それが指しているのはVPCですか、それともサブネットですか。
A. VPC内の全サブネットです。
Q. VPC内のサービス一覧を確認したい場合、どこを見れば分かりますか？
A. VPCユーザーガイドを見ていただくのが確実です。
https://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/what-is-amazon-vpc.html
Q. ELBのロードバランスの手法は何でしょうか？先ほどラウンドロビンと仰っていた気がしましたが、確認したく。
A. ラウンドロビンと最小リクエストインスタンスを優先の2種類から選択できます。
Q. ELBの特徴として、外部にも内部でも接続できる とありますが、どこの内部と外部でしょうか？サブネットでしょうか？
A. VPCの外部と内部です。
Q. S3やEC2 APIなどを使うときに、VPCエンドポイントを使わない理由は何かあるでしょうか？
ご説明だと、セキュリティの観点でもコストの観点でも、VPCエンドポイントの方が優れていると認識しています。
A. S3の場合のゲートウェイエンドポイントは無料です。
EC2 APIはインターフェースエンドポイントで有料ですので、コストとのトレードオフとなります。
Q. Route53自体は、単一障害点とはならないのでしょうか。
A. 世界中のエッジロケーションを利用して展開していますので、単一障害点にはなりません。
Q. S3やEC2へのアクセスは、
・AWSのサービスで完結するならVPCエンドポイント経由
・AWSのサービスで完結しないなら(AWS以外のサービスへのアクセスも必要なら)インターネットゲートウェイが良いと理解しました。
A. はい。ただし、EC2 APIなどインターフェースエンドポイントの場合は、コストとのトレードオフを考慮してください。
Q. IAMできめ細かいアクセス権限設定ができると思いますが、権限設定・実装の妥当性を実際に確認する方法はありますでしょうか？
権限エラーで拒否された際にポリシーのどの設定行で拒否したかを確認できないと、安心して公開させにくいのかなと思いました。
A. IAMポリシーシミュレーターがご利用いただけます。
https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/access_policies_testing-policies.html
Q. Denyをひとしきり書くのは大変そうですが、できること一覧からやってほしくないことを選択していくと、Policyが作られるような、支援機能などあるでしょうか？
A. IAMポリシーを作成するデフォルトの画面はポリシージェネレータです。GUIで操作いただけます。
Q. メタデータはどこからどのように取得するのでしょうか？
httpアクセスで取りに行く？ その場合取得しにいく先のipアドレスはどのように知るのでしょうか？
A. httpアクセスです。すべてのEC2インスタンス共通でhttp://169.254.169.254/latest/meta-data/です。
Q. EC2上に構築した機能でSystemsManagerパラメータストアから情報を取得する場合、EC2はインターネットへのアクセスが必要でしょうか。
A. インターネットへのアクセス、またはVPCエンドポイントが必要です。
Q. Snowballの手配や、S3オブジェクトロックなど、やってほしくないポリシー一覧はどこで入手できますか？
A. 私が使っているポリシーを書き出してみました。参考例としてご参照ください。必要に応じて増減してください。
https://www.yamamanx.com/scp-policy/
Q. Lambdaに対してもIAMロールを設定して開発者がアクセスキーID等を意識せず、他のサービスへアクセスすることは可能ですか？
A. はい。可能です。LambdaではIAMロールが必須です。
Q. アカウントをまたいだVPC間の通信がしたいときは、VPCピアを利用することはできますか？
A. 可能です。VPCピアリングはアカウントもリージョンもまたぐことができます。
Q. AWS外にある外部システムから、AWSのAPIを呼ぶ場合は、どのように権限を与えるべきでしょうか。
ユーザー認証を伴う場合は、IDPで連携すればよいことはわかりましたが、バッチ等ユーザー認証を伴わない場合はどうしたらよいでしょうか。
A. アクセスキーIDとシークレットアクセスキーを使用する方法か、Cognitoを使う方法が考えられます。
Q. 環境自動化の話でユーザーデータの例がでましたが、このユーザーデータは起動時に毎回実行されるものではないのでしょうか？
A. はい、新たにインスタンスを起動（作成）するときだけユーザーデータが実行されます。インスタンス作成時のパッケージのアップデートや仮想記憶の設定などに利用しています。ユーザーデータの実行は、デフォルトでは、インスタンスの停止、開始時には実行されません。
Q. メトリクスの取得間隔(5分)は、変更できるのでしょうか？ 1分など。
A. 詳細メトリクスの有効化をすれば1分にできます。
Q. ログ監視について、フィルタで何件発生したというのはわかりました。
具体的にログの中身は確認できないのでしょうか？
A. ログストリームの内容を確認できます。
Q. CloudWatchでプロセス毎のCPU利用率までは確認できませんか？
A. はい。OSレベル以上の情報になりますので、SDKなどを使って開発していただければカスタムメトリクスとして収集できます。
Q. CloudWatchのカスタムメトリクスを利用し、画像ファイルなどとしてリソースの月次レポートを自動生成できますでしょうか？例えば、前月分のグラフを毎月1日に作成→どこかに保存を自動化できると、資料作成作業が削減でき、便利だと思いました。
A. CloudWatchの情報をS3→Athena→QuickSightに連携すれば定期的にメール送信などもできます。サードパーティ製品でもCloudWatch連携するサービスはあります。
Q. AutoScalingで起動したEC2インスタンスのアクセスログなどは、CloudWatchに連携する形が一般的でしょうか。
A. はい。一般的です。そうすることで「リソースを使い捨てする」ベストプラクティスを実現できます。
Q. Autoスケーリングの機能は無料で、スケールアウトしたインスタンスを起動した分のみ、課金される、という認識は合っていますか？
A. はい、その認識であっております
Q. Aurora DB クラスターのスライドで、プライマリインスタンスが一つのAZにしか配置されていませんが、これは、プライマリインスタンスが配置されているAZが使えなくなると、他のAZでは書き込みはできなくなるが、読み込みはできる という運用になるということでしょうか？
A. リーダーが自動的にマスターに昇格します、複数のリーダーがあるときは優先順位を設定することも可能です
Q. RDSのストレージの拡張時にサービスを停止する必要がありますか。
また、縮小は不可になりますでしょうか。縮小可能な場合、データ消失の可能性はありますか。
A. ストレージ拡張はオンラインで行われますが、縮小は不可能です
Q. 現在設定している環境のフロー図を自動で生成してくれる・・・またはどんなものを作ったかを入力すれば生成・・・なんてサービスはないのでしょうか。
A. サードパーティで、Cacoo、LucidChart、Cloudcraftなどがあります。
https://aws.amazon.com/jp/architecture/icons/
Q. ラボにてEC2インスタンスの可用性テストがシナリオでありましたが、RDSの可用性テストの方法はございますでしょうか。
A. マルチAZでフェイルオーバー付きで再起動を実施することで、アプリケーションの可用性テストを行えます。
Q.JsonとYaml、きっと記述能力は同じなんだと思っていますが、どういう場合はどっちで書いた方が良い、楽など使い分けはあるでしょうか？
A. こちらは好みです。Yamlはコメントが書けるのでコメントを入れたい方はYamlがよいでしょう。
Q. CloudFormationスタック＝テンプレートによって生成されたもの という理解であっているでしょうか？
A. はい、そのとおりです。厳密に言うと、テンプレートをCloudFormationのエンジンが読み込んでスタックを作成します。
Q. AWSの各サービスのアップデートによって、Cloud Formationのテンプレートの内容が使えなくなることはありますか。JsonとYamlの書き換えの必要が出ることはありますか。
A. 基本的に使えなくなることはありませんが、新機能が追加されることはあります。
Q. CloudFormationの中にAuto Scalingの設定も記述することはできますか？
A. はい。可能です。CreationPolicyという属性も使って、必要インスタンス数が起動してから次のリソースを作成するということもできます。
Q. CloudFrontオリジンを修正した際、キャッシュ側に反映されるまでにどのくらいのタイムラグが発生しますか？
A. TTLに設定した時間が経過するまでキャッシュへは反映されません。すぐに反映したい場合はInvalidationを使用します。
Q. エッジロケーションへのアクセスログをCloudWatchに出力することはできますか？
A. CloudFrontのアクセスログはS3バケットに出力することができます、リクエスト数などはCloudWatchメトリクスで確認できます。
Q. ElastiCacheと、DynamoDBの違いが分からないのですが
どちらもセッション管理に使用できますか？使い分けはなんでしょうか。
A. DynamoDBはフルマネージドな上、アプリケーションでデータ構造を自由に構成できるという利点があります。
ElastiCacheはオンプレミスでMemcached、Redisを利用している場合の移行が有利なのと、VPC内で動作するという利点があります。
Q. SQSからコンシューマに対し「プッシュ」はできるでしょうか？
コンシューマはSQSに、取りにくる必要があるのでしょうか？
※アプリのメール送信機能がメールサーバー側の状況を気にすることなく、SMTP失敗してもSQSがリトライをしてくれるといいなと思いました。
A. 取りに行く必要があります。ポーリングと言います。
Q. SQSはmqttやamqtをサポートしますか？
A. SQSではサポートしていません。Amazon MQが、mqtt / amqpのマネージドサービスを提供しています
Q.CloudFrontのBehaviorsで拡張子を書き忘れた場合はキャッシュされないだけでしょうか？ あるいはnot foundになりますか？
A. Behaviorsのdefaultの対象になります。
Q.Lambdaでプログラミングする際、外部ライブラリを追加したい場合、追加可能でしょうか？
A. 可能です。以前はZIPで固めてアップロードしてましたので、Lambda関数ごとに、ライブラリを含める可能性がありましたが、今はLambda Layersがあり、複数のLambda関数から共通で利用できます。
Q. Lambdaのソース管理はどう行うのがいいんでしょうか。
Node.js等でいろいろ作ってた場合、それをまるっとLambdaにあげたりできるんでしょうか。
A. 私は、CodeCommitまたはGithubで管理しています。デプロイはSAM(ServerlessApplicationModel)というCloudFormationの拡張版がありますのでそれを使っています。SAMのチュートリアルをやってみていただくことをオススメします。
Q. Lambdaはリクエストベースの課金とのことでしたが、Lambdaを使用することでかえってコストが高くなるケースというのは考えられるのでしょうか。
A. 今のところは私自身の経験ではありません。Lambdaのアンチパターンとして再帰的な実行があります。これで失敗して無限実行のLambdaを作ってしまって大量課金が発生したという失敗例は聞いたことがあります。
Q. Lambdaを選択すべきでないケースを教えてください。以前見た記事では、Lambdaは呼出都度初期化処理が必要になるのでレイテンシが増加するなどという話を聞きました。また、共通ライブラリの利用はむつかしいのかなと推測しています。
A. レイテンシが許容できない場合は、コンテナやEC2で待ち受けて対応します。
複数の関数で共通でライブラリを使うのであれば、Layersという2018年発表の機能を使って、共有できます。
Q. Lambdaにバージョニングの機能はありますか？
A. はい、あります。バージョンにエイリアス(別名)を設定することもできます。
Q. S3のコストについての質問です。 インターネットへのデータ転送は課金とありますが、静的ウェブサイトに多くのアクセスが来ても支払う料金の変動はないという理解であっていますか。
A. 静的コンテンツへのブラウザからのアクセスは、GETリクエストに対してのレスポンスとして、インターネットへのデータ転送が発生します。ですので、料金の変動はあります。
Q. S3の良いユースケースの所で、データセット数が増加している場合とあるのですが、データセット数は何を示していますか。またなぜ良いユースケースに該当するのでしょうか。
A. 例えば、Json形式やCSV形式のデータや、Logデータが増え続けることを示しています。S3バケットは無制限にデータを保存していただけますので、増え続けてもストレージの増強などの運用が必要なく、向いているといえます。
Q. 「レプリケーションはAurora以外は非同期で行われる」と講義で説明がありましたが、 実際は以下の仕様が正しいでしょうか？
RDSのマスタースタンバイのレプリカは完全同期 、リードレプリカは非同期、 Auroraのリードレプリカは非同期。
https://aws.amazon.com/jp/rds/aurora/faqs/
その場合、Auroraではデータベースへのレプリカへの反映には常にタイムラグが発生するという理解でよいでしょうか？
A. Auroraはご指定のFAQにもありますように、リードレプリカは非同期的でですが、ミリ秒単位です。また、フェイルオーバーの際のデータ損失もありません。
Q. 全体を通して、様々なレイヤーでポリシーがありますが、最終的な権限の評価方法について教えていただきたいです。 同一レイヤーのポリシーでは明示的な拒否が優先される話はあったのですが、別レイヤーでのポリシーで拒否や部分許可条件の不整合があった場合の評価方法が気になりました。 また、ポリシーの数が多く整理して理解ができていないので、主要なポリシー(バケットポリシー、セキュリティポリシー、AWS Organizationsでのポリシー等)を整理して理解できるような方法はありますか？
A. 別のレイヤーであっても拒否が優先されます。また、スコープで考えていきますと、組織で複数アカウントに対して構成するのが、OrganizationのSCP(サービスコントロールポリシー)、アカウント内のIAMユーザーをグループにしてアタッチするのがIAMポリシーです。
S3バケットやKMSのキーポリシーは、リソース側で特定のアカウントやAWSリソースに対しての認可を設定します。
Q. 先日実施したラボの内容を確認したいのですが、可能でしょうか。
A. Bookshelfのラボガイドをご参照ください。
Q. ELBで負荷分散をしている場合には、スティッキーセッションでセッション維持が可能となりますが、 Route53でのルーティングをした場合(ラウンドロビンなど)には、セッション維持する方法はあるでしょうか。 Route53でトラフィックの分散をする場合には、EC2インスタンス外にElastiCacheなどをセッションストアとして持つべきでしょうか。
A. はい。Route 53でDNSクエリ元を識別して同一回答を返す機能はありませんので、セッションは外部に持つ必要があります。
Q. S3への登録をトリガーとして、SQSに連携する際、SNSトピックを仲介するアーキテクチャがテキストで示されています。
ネット検索をしていても、上記のパターンではSQSを介在させる例が示されていることが多いです。
S3のイベントから直接SQSイベントを発生させることができると思いますが、SNSを挟むことによるメリットを教えていただけないでしょうか。
また、このような設計パターンが良く知られたベストプラクティスである場合、代表的なベストプラクティスが掲載されているサイトがあれば教えていただけないでしょうか。
A. S3から直接SQSへ通知する場合は、1つの通知しかできません。オブジェクトに対して一つの処理しかできないということです。SNSはサブスクライバーに複数のSQSを設定できますので、1つのオブジェクトに対しての複数処理を並列化できます。これがメリットです。また、この設計パターンをファンアウトと呼びます。
このような設計パターンは書籍やこちらのサイトにも情報があります。
http://aws.clouddesignpattern.org/index.php
Q. プライベートサブネットのEC2上の処理で、パラメータストアから値を引いてくる場合、パラメータストアへのVPCエンドポイントを作成するのが良いと伺いました。 このVPCエンドポイントに割り当てるセキュリティグループとしては、何番ポートを開けるのが正しいのでしょうか。
A. 443 でEC2インスタンスからのインバウンドトラフィックを許可します。
皆さま、ご受講いただきまして、誠にありがとうございました！
トレノケートのAWS認定トレーニングでは、AWS社の厳格なテクニカルスキル及びティーチングスキルチェックに合格した認定トレーナーがコースを担当します。AWS初心者向けの研修や、AWS認定資格を目指す人向けの研修をご提供し、皆様のAWS知識修得のサポートをいたします。
・トレノケートのAWS研修（AWS認定トレーニング）はこちら
▼AWS初心者の方は、AWS Cloud Practitioner Essentialsから！
座学中心の研修で、AWSを初めて学ぶ方や、営業などで提案に関わる方におすすめです。
「AWS Certified Cloud Practitioner」資格取得を目指す方の基礎知識修得にも最適です。
→ AWS Cloud Practitioner Essentials 詳細・日程はこちらから