2020年7月15日から7月17日に開催しました、Architecting on AWS for APN Partnerにていただきましたご質問と回答の一部を掲載します。
以下は、2020年7月17日現在の情報を元に回答しております。
Q. AZは複数のデータセンターで構築されているので、単一のAZでも冗長されているという認識であってますか？
A. 単一のAZでも冗長化されている要素もありますが、停電、落雷、竜巻、地震などの問題からより安全に隔離、保護するために複数のAZで高可用性を実現してください。AZに含まれるデータセンターは距離的に近い場合がありますので障害発生時に単一AZ全体に障害が発生することは起こりえます。
Q. 2つ以上のアベイラビリティゾーンで構成されるとありますが、S3はデフォルトで3か所のAZに複製されるはずです。
2か所しかAZがないリージョンはあるのですか？
A. 2箇所のAZで構成されているリージョンは存在します。2箇所のAZしかない場合は、2つのAZ内の3箇所のデータセンターで分散コピーすることで可用性を高める設計をしています。1ゾーンIAストレージクラスという例外はありますが、S3は基本的に利用するAZを利用者が気にしなくても良いサービスです。
Q. 複数のAZで構成されてAZ障害に対応していれば可用性に関しては十分であり、例えば別リージョンにBCP環境を用意するといった考慮は基本的には不要という認識で良いでしょうか？
A. リージョン全体が止まるという障害はこれまで発生していませんが、巨大な災害により発生しないとは言い切れません。要件によって、例えば東京リージョンが利用できない事態になってもビジネスは継続しなければならないといったケースでは複数リージョンによるBCP環境を検討してください。
Q. 3つのAZがあるリージョンでサービスによっては2つのAZしか利用できない場合がありますが、サービス毎に利用可能なAZ情報が公開されていましたら、公開場所を教えて頂けますでしょうか。
A. 例えばEC2インスタンスのファミリーなど、サービスごとに利用可能なAZの情報のまとまったものは公式では見たことはありません。
Q. Cloud FrontにキャッシュされるデータはGDPRなどの法規を加味した設計でないといけないでしょうか
A. 加味した設計である必要があります。CloufFront の機能で特定の地域からのアクセスを制限することことも可能です。
Q. リージョン、AZを選択するとき、判断基準についてご教示いただけますか。
リージョンについてはレイテンシの話がありましたので、サービスのエンドユーザーが近いところを選ぶのが基本かと思うのですが、例えば日本は自然災害が多いということも判断材料になりえるのでしょうか。
また、AZについては、どのリージョン/AZでどのサービスがどの程度使えるということは判断材料になりえるかと思いますが、それが同一の場合(インスタンスタイプが同価格で同様のサービスと使えるはず、ということをイメージしています)選択する上での基準は何になるのでしょうか。
A. リージョンの選択基準はレイテンシーの他にもコンプライアンスやガバナンス要件（国外へのデータ持ち出し禁止有無）や、サービス提供の可否（リージョンによっては提供されていないサービスもあります）、サービス料金が考えられます。AZについては、複数のAZを利用することで可用性を高くすることができます。
Q. S3のエンドポイントURLはRoute53等のDNSサービスで別のURLに変更は可能なのでしょうか？
その方法が記載されているマニュアルがあればURLを教えていただきたいです。
A. 独自ドメインでアクセスするように DNS を設定することが可能です。ただし、HTTPS で利用できません。独自ドメインで HTTPS を利用したい場合は、CloudFront との併用で実現できます。モジュール10で詳しくお話します。
こちらにチュートリアルがあります。
Route 53 に登録されたカスタムドメインを使用した静的ウェブサイトの設定
Q. Route 53の53ってなんでしょうか？
A. 53 は DNS のサービスポート番号です。
Q. EC2を使うかS3を使うか何を基準に選ぶのか詳しく教えていただけますか。
A. 静的かどうか（ファイルとしてすでに存在しているものを配信するかどうか）が判断基準になります。PHP などサーバーサイドのプログラムの実行結果を返したい場合（動的）であれば、EC2 などを利用します。
Q. S3のバージョニングは、過去1世代のみ、といった指定はできるのでしょうか。
A. 世代数を指定することはできません。
Q. S3のバージョニングの復旧について教えてください。
現行バージョン（V3）からV1に復旧したあと、V2やV3のバージョンに再び復旧することは可能なのでしょうか？
A. 可能です。削除されていない過去のバージョンに復元することができます。この場合、V2は復元後にV4と新しいバージョンとなります。
Q. バージョニングはスナップショットなどの差分、増分ではなくファイルそのものを置くので単純にファイル容量分のコストがかかるという理解でよろしいでしょうか。
A. はい。各バージョンのサイズ分の請求が発生します。
Q. S3バケットのロールバック復元は、タグ付けして一括して特定のタイミングに戻すことは可能なのでしょうか？
A. 機能としてはありませんが、例えばSDKでコーディングしていただくことで自動化が実現できます。
Q. S3バージョニングを有効にした場合、何回以上の変更分は削除するということはできますか？
(5回変更をしたデータに対して6回目の変更をしたときに、最古の変更データは削除して、5回分のデータを確保し続ける設計など)
A. ライフサイクルポリシーを使用して、回数ではなくアップロードからの日数を指定して古いバージョンを削除できます。
Q. マネジメントコンソールを見た限りでは、山下さんが構築されたS3は米国リージョンかと見受けられましたが、東京リージョン上に構築しなかったのは何か理由があるのでしょうか？
A. モジュール10で CloudFront のお話をするときの例として利用するためにオハイオリージョンを使用しています。東京以外のリージョンを選択する理由としては、コストが低くなる場合がある。というケースも考えられます。
Q. S3で静的コンテンツ配信（静的Webホスティング）で利用する場合、ホームページの改竄などを考慮し、セキュリティ機器（IPS,WAF）を経由させることはできないのでしょうか？
A. CloudFrontと組み合わせて、AWS WAF を利用できます。
Q. バージョニングの過去バージョンファイルをCLIなどで一括ダウンロードした場合、過去バージョンはダウンロードの対象になりますか、なる場合はファイル名はどうなりますか？
A. ダウンロード時にローカルファイル名を指定します。各バージョンごとに違うファイル名でダウンロードさせることができます。
Q. データのバックアップの保管先にS3を使っていたりしますが、AWSの設計思想からすると正しくないのでしょうか。
A. 正しいです。S3はバックアップ先としてのユースケースがあります。
Q. S3のデータレイクからデータを取り出して分析するようなサービスはAWSから提供されているのでしょうか。
A. 連携するサービスとして SageMaker 、RedShift などがあります。各サービスのデータソースとして S3 を利用して必要なときにデータを S3 から取得してサービス内で利用するといったやり方であれば、各サービスにデータを保持する必要がなくなるので、解析が終わればサービスのリソースを削除することでコストを抑える。といった利用ができます。
Q. ユースケースには出てきませんでしたが、S3をクラウドストレージのように活用したユースケースはありますでしょうか。
また、そのようなユースケースで活用する場合に考えられる懸念点があれば教えてください。
A. DropBox などのような利用目的の場合、共有機能などは有していないので向いていません。そういった利用には、WorkDocsが向いています。
Q. 講師紹介の写真で持っていた箱はSnowballですか？
A. Snowball Edge です
Q. S3 Transfer Accelerationのエッジロケーションは自動で選択されるのでしょうか。
A. 送信元からレイテンシーの低いエッジロケーションが自動で決定されます。
Q. （ログ収集用途として想定)S3だけでのデータ検索、フィルタリングはできますか。あるいは、他のAWSサービスとの連携が必要でしょうか。
A. S3 Select を利用すると S3オブジェクトから直接データをクエリーすることができます。
Q. S3 Intelligent Tiering を有効にするとコストが発生するのでしょうか？
A. はい。有効後にストレージクラスの移行するコストが発生します。
Q. Inteligent Tieringを利用するデメリットは考えられますでしょうか。
A. ストレージクラスの変更をコントロールできない点です。
Q. S3のストレージクラスの一つとしてGlacierがあるように書かれている資料が多いですが、S3とGlacierは別物と考えた方が良いのでしょうか？
A. ストレージクラスオプションの一つとして捉えてください。GlacierでVaultという機能を利用するケースもありますが今の段階では、アーカイブデータを保存するストレージクラスと考えてください。
Q. S3 1ゾーン IAが適しているデータはどのようなデータでしょうか。
A. 例えば、東京で保存しているバックアップの災害対策用としてシンガポールに保持していきたいといった場合が考えられます。
Q. ライフサイクルポリシーとは、バージョニングの日数保管とは別にありますか？
別の場合、削除機能はライフサイクルポリシーを迎えたオブジェクトは全バージョン含めて削除しますか？
また、ライフサイクルポリシーの開始時点は最新バージョンが保存された時ですか？
A. ライフサイクルポリシーとバージョニングの日数は同じです。ライフサイクルは、オブジェクトがアップロードされたタイミングから始まります。
Q. IntelligentTieringはAWSが独自の計算で自動的にストレージクラスを移動してくれる機能、
ライフサイクルポリシーは自分でストレージクラスの移動を計画して実施できる機能ということでよろしいでしょうか？
A. はい。
Q. IntelligentTieringを有効にしていた場合、知らずのうちにクラスが下のTireに移動していて思わぬところでアクセス速度に影響が出てしまうといった懸念はありますでしょうか？
A. IA(低頻度アクセスストレージクラス)は速度への影響はありません。
Q. S3 1 ゾーン - 低頻度アクセスの1ゾーンとは何を意味するのでしょうか？
A. 1つの AZ のみを利用することを意味しています。
Q. S3でStatic Website hostingを有効にして公開した場合と、有効にせずファイルを直接公開した場合とで、どのような点が違ってきますか？
A. Static Website hostingを有効にした場合は、index.htmlをつけずにアクセスできる、error.htmlを指定できる、Route 53のエイリアスで指定できる、という点が異なります。
Q. AMIに含まれているものについて詳しくお聞きしたいです。
例えばEC2インスタンスに100GBのルートと200GBの別ディスクがアタッチされているものをAMIでコピーしていた時、ルートボリュームはコピーされているが、200GBのディスクについては、アタッチされていることはコピーされる(アタッチは自動でされる)が、中身のコピーはされないということでしょうか。
A. AMI 作成時にアタッチされていたボリュームのスナップショットが AMI には含まれます。すなわち、AMI から起動した場合はそれぞれのボリュームの中身は保持されてインスタンスが作成されます。
Q. T2,T3のCPUクレジットはインスタンスを停止したら貯めてあった分がなくなってまた1から貯まり続けるのでしょうか？
A. インスタンスの停止時には貯めていたクレジットは初期化されます。T2 では、初期値がサイズによって予め設定されています。T3 では、0 に戻ります。
Q. 本番環境にてCPUの使用率が設計時点で見えない場合はT2, T3ではなくM系を採用する方が無難という認識で宜しいでしょうか？
A. はい。
Q. 古い世代のインスタンスタイプも選択できますが、既存のインスタンスと同じ世代を作成したいといった特別な理由がない限り、古い世代を選択するメリットはない認識で合っていますでしょうか。
A. はい。パフォーマンス、コストの最適化が図られています。
Q. ストレージ最適化インスタンスファミリーを使用する状況は「ディスク量が必要であり、【ディスクスループットが必要なとき】」でしょうか。容量だけ必要な場合はS3などにファイルを配置し読み込めばいいのでは？と思い質問です。
A. ストレージ最適化は、ご質問のようにディスクのスループットが必要な場合という認識であっています。あるいは、大容量なディスクを利用したいがアプリケーションのカスタマイズを行いたくなく、 S3 が利用できない場合に検討できます。
Q. EC2のAMIと、EBSのスナップショットという両機能があるように思われますが、どのような違い、ユースケース、メリット・デメリットがあるのでしょうか。
A. EC2全体のバックアップは、AMI の作成になります。AMI の作成とスナップショットの比較という場合、例えばボリュームが1つしかない場合は AMI の作成をすることで、ルートボリュームのスナップショットが作成されます。
2つ目以降の EBS ボリュームをアタッチして追加ボリュームにデータ更新が発生するような場合であれば、追加した EBS ボリュームのスナップショットを取るようにしておくと、毎回AMIを作成するよりも管理をシンプルにすることができ、コスト最適化に繋がります。
Q. EBSボリュームを暗号化することでなにか利点はありますでしょうか？
A. 物理ディスクの暗号化が必須。というコンプライアンス要件をクリアすることができます。
Q. AMI作成時に作成されたEBSスナップショットを削除するには、AMIを削除→EBSスナップショットを削除の順にすればよいのでしょうか？
A. はい。AMI の削除後には、関連していたスナップショットは自動で削除されないので削除を行う必要があります。
Q. AMIを定期的に取得することでEC2インスタンスのバックアップとして運用することは可能でしょうか？また、その場合AWS Backupとの違いについて教えて頂きたいです。
EC2インスタンスの定期バックアップとしてはどちらがベストプラクティスに近いのでしょうか。
A. AMI を定期的に取得することでバックアップとなります。AWS Backup を利用することで、定期的に AMI を作成するタスクを実行できます、また、同時に EFS など他のサービスについてもバックアップを取得することを実行できます。手動で作成いただくよりも、AWS Backup を利用して自動的にAMIを作成いただくことがベストプラクティスになります。
Q. 共有ファイルシステムとしてS3を使うのが理想的でない理由をもう一度教えてください。
A. S3 を共有ディスクとしてプログラムの中から利用する場合は、S3 の API を利用する必要があるため、プログラムのカスタマイズが必要になります。
ファイルシステムを共有する要件であれば、EFS、FSxが選択肢です。
Q. スポットインスタンスを使用したとき、AWSがインスタンスを中断する際に事前アナウンスのようなものはあるのでしょうか？
A. 終了される2分前にメタデータ内及び CloudWatch イベントとして通知されます。
Q. リザーブドインスタンスを契約したとき、4つのアカウントで利用する場合、同時に4つインスタンス起動しても、合計の起動時間が範囲内に収まっていれば問題ないか？
A. はい。4つのアカウントで一括請求にしていれば共有してリザーブドインスタンスを使えます。
Q. リザーブドインスタンスといった考えはEC2インスタンスだけでなくEBSに対しても適用可能でしょうか？
A. EBS には存在しませんが、RDS, ElastiCache などリザーブドインスタンスを利用できるサービスがあります。
Q. スポットインスタンス利用時にインスタンス停止される時は、OSシャットダウン相当の停止処理でしょうか。それとも強制停止（物理サーバの長押し相当）でしょうか。
A. スポットインスタンスが中断される動作では、終了・停止・休止を選択できます。
Q. スポットインタンスで価格設定して、落札？した後のイメージを教えてください。（落札通知がどう来るのか、起動時に使用するAMIを事前設定しておくのか、自動でインスタンス起動されるのか？など）
A. 起動時のインスタンスの構成は事前設定しておきます。自動でインスタンスが起動されます。
Q. ハードウェア専有インスタンスがよく理解できなかったのですが、あるホスト上のHDDやメモリを専有するという意味でしょうか？
A. ハードウェア専有インスタンスでは、EC2 インスタンスが起動する物理ホストを専有します。他の AWS アカウントの EC2 インスタンスは混在しません。リソースの専有目的ではなく、セキュリティ、コンプライアンス、ライセンス要件を満たすために選択します。
Q. EC2にアタッチしたEBSをデタッチした後、別のEC2にアタッチすることはできるでしょうか？
A. はい。デタッチ、アタッチできます。
Q. スポットインスタンスを使用するとき、2分前に通知が来るとのことですが。通知を受けて、自動で終了処理などを組み込むことは可能でしょうか。
A. プログラムを組む必要がありますが、例えば1分ごとにインスタンスメタデータを取得して通知が来た際に1分以内にデータの退避をするなどの処理をおこなうことや、EC2 インスタンスにAPIレベルで処理をするのであれば、CloudWatch イベントを受けて処理を起動するプログラムを実行できます。
Q. EC2インスタンスを作成する場合、必ず一つのEBSボリューム（OS用？）が付属するのでしょうか？その場合、そのEBSボリュームもスナップショットを取得できるのでしょうか？
A. 1つのルートボリュームが用意されます。EBSボリュームであればスナップショットを取得できます。厳密に言えば、EBSボリュームを利用せずインスタントストアを利用する。という選択肢もあります。
Q. EFSにはEBSのようにボリュームタイプの指定は無いで理解はあってますでしょうか。料金がどのように決まりますでしょうか。またEFSはEBSと同じようなスループットでアクセスできるものなのでしょうか。
A. EFS では、ストレージクラスを選択できます。スループットでアクセスでき、プロビジョニングしておくこともできます。
Q. RDSでマルチAZの高可用性の設定でデプロイした場合、データベースの冗長化の仕組み（Oracleの場合はRAC等）も意識せずRDS側でよしなに冗長化してくれるのでしょうか？
A. マルチAZ構成を有効にすればRDS側で冗長化してくれるのでお客様側で構成していただく必要はありません。
Q. すでに使用されているEC2にDBを持っていおり使用している状態のものを途中からRDSを使用する形にすることはできるのでしょうか？その時はDBを使用する他のアプリケーションが使えなかったりするのでしょうか？
A. オンプレミスと同様にデータ移行が必要です。データ移行中は、不要なデータ更新を防ぐためにダウンタイムが発生します。Database Migration Serviceを使い継続的な移行を計画することで、停止時間を短くすることが可能です。
Q. Auroraは自動的に10GBずつ増加するということですが、減った場合は自動的に下がるのでしょうか？それとも増えたままでしょうか？
A. 増えたままです。RDSのストレージを減らすことはできません。
Q. Amzon AuroraはAmazon RDSの上位互換という認識であっていますか？
A. MySQL，PostgreSQLの互換性を持つデータベースエンジンです。
Q. オンプレミスで運用しているデータベースをRDSへ移行するツール等、何か手段はありますでしょうか？
A. Database Migration Serviceがあります。このモジュール後半で解説いたします。
Q. RDSはMySQLやPostgreSQLを利用するといったどのデータベースを使うかを選択ができるという認識であっておりますでしょうか？
A. 正しいです。RDS では、データベースを作成する際に利用するデータベースエンジンを選択します。
Q. RDS容量の拡張は閾値容量を設定、監視して手動での拡張が必要という理解でよろしいでしょうか？
また、RDSにおいて、DB削除後に容量が少なくなり縮小したい場合は、どのように対応したらよいのでしょうか？
A. CloudWatch のメトリクスを監視して必要に応じて拡張をします。容量を減らす場合は、新しいデータベースを作成してデータ移行をすることで不要な領域を減らすことができます。この場合も、データ移行に伴うダウンタイムが発生します。
Q. オンプレミスのアプリケーションでPostgreSQLのJDBCドライバを使ってDBアクセスしていた場合、AWS上にデプロイしてPostgreSQL互換のAuroraを利用する場合はドライバの変更の必要はありますか。
A. データベースが同一バージョンであれば動作することが想定されますが、検証を行うことが望ましいです。
Q. RedshiftにはSQL発行履歴などDB上の稼働状況を取得する機能は備わっているのでしょうか？
A. あります。STL_QUERY
Q. RDS上のデータから年次レポート作成する時にだけRedshiftを使用したい場合、都度、RDSからRedshiftにコンバートする運用になるのでしょうか？
A. 必要に応じてRDS -> RedShift にデータを移動して集計をするという運用が考えられます。また、アプリケーションからは利用されない過去のデータであるという場合は、S3 に RDS からエクスポートすることで、RedShift から S3 のデータを利用できます。
Q. DBはバージョンによって機能に差があったりしますが、RDB経由の場合、各DBのバージョンを選択できたりしますでしょうか。プロダクト固有機能(OracleのDataPump等)の利用に制限は無いと考えてよろしいでしょうか。
A. RDSでは、データベースエンジンのバージョンを選択できます。新しいバージョンのサポートも随時追加されています。個別の機能については、使えるものと使えないものがあるので検証してください。
Q. 可用性を担保するためにマルチAZ構成を利用する場合、AZをまたいでEFS/FSxによるストレージの共有はできますか？
それとも、ストレージの管理はそれぞれのAZ内に閉じているべきでしょうか。
A. EFS/FSxはAZもリージョンもまたいで使うことができます。AZに閉じる必要はありません。各ネットワーク上にマウントターゲットを作成しますが、ファイルシステムは共通です。
Q. EC2の休止状態の場合は、時間当たりのインスタンス料金はかからないという理解で大丈夫でしょうか。
A. はい。EC2 の料金は起動、再起動のときに発生します。注意点として、EC2 が停止中の場合でも、EBS の請求は確保している容量分発生します。
Q. DynamoDBではパーティションキーとソートキーの組み合わせがユニークでなければいけないという認識で合っていますでしょうか。
A. あってます。正確には、パーティションキーのみ。あるいは、パーティションキーとソートキーの組み合わせでユニークにする必要があります。
Q. パーティションキー、ソートキーは2つのキーで一意性制約を持たせられるという理解でよろしいでしょうか？ それとも絞り込みだけなのでDBでは重複が許されるのでしょうか？
A.プライマリキーとして一意にします。ソートキーを使用する場合は、パーティションキーとソートキーを組み合わせてユニークにする必要があります。
Q. データ分析をする場合、データを配置する場所としてDynamoDBとS3も選択肢に入ると思いますが、選択基準はどのような点になりますか？
※データ分析処理自体はGlueやAthenaなどやEMRなどを利用する場合など。
A. データ分析のデータストアとして利用する用途であれば、S3 のほうが向いています。データ分析サービスの連携もS3を対象とするものが大半です。DynamoDB に保存されたデータを分析に使う要件であれば、Data Pipeline を使用して S3 にデータを流し込んでから Athena などのサービスと連携できます。
Q. DynamoDBのセカンダリーインデックスは作成数に制限があったりしますでしょうか。
A. 本日時点での制限としては、ローカルセカンダリインデックスが5まで。グローバルセカンダリインデックスが20までとなっています。この制限は、緩和申請をすることで上限を上げられます。
セカンダリーインデックスの使い分けについては DynamoDB のセカンダリインデックスのガイドライン をご覧ください。
Q. DynamoDBがなぜイベント駆動型のDBなのか教えていただけないでしょうか。
A. イベント駆動型は、リアルタイムの処理に向いている特徴があります。リアルタイムな処理をすることにより、エンドユーザーのニーズにいち早く対応することが可能になります。DynamoDBではDynamoDBストリームを使用します。
Q. 継続的な差分移行といわれているのは、オンラインでDBを利用しながら移行できるという認識でよいのでしょうか。
A. はい。
Q. DBインスタンスクラスで、標準クラスとメモリ最適化クラス、バースト可能クラスの違いを教えてほしいです。
A. RDSにもEC2のように性能を決めるためのインスタンスクラスがあります。
メモリ最適化はファミリーがRとなっているメモリ最適化に設計されたホスト上で起動します。
バースト可能は、Tファミリーで、CPUベースラインがあり、CPUクレジットを使ってCPUバーストします。
標準はそれ以外のファミリー(M)です。
インスタンスクラスのファミリーの選択肢です。
Q. EC2作成時のオプションで下記が選択できるようですが
[シャットダウン操作]：停止｜終了
OSからのシャットダウン操作を行ったときにEC2サービスとしての状態を設定できるということでしょうか。またこれが何に影響しますか？
A. OSシャットダウン時にEC2インスタンスを停止するか、終了させるかです。
OS側からの操作によって、EC2を終了(terminated)させたい場合に設定します。
Q. 今回のラボ2ではEC2インスタンスとRDSの接続をブラウザ上で実施しましたが、AWSのマネージメントコンソールからEC2とRDSの接続を実施することも可能という認識であっておりますでしょうか？
A. マネジメントコンソールの機能としてデータベースインスタンスへの接続を確認する機能はありません。例えば、MySQL Workbenchなどの管理クライアントを使って接続することは可能です。
Q. （マネージメントサービスを利用した）DBの場合、利用バージョンは永続的に利用可能ですか？それとも、どこかのタイミングで自動的にVUPされるのでしょうか。
A. RDSなど他のデータベースに依存している場合は、サポート終了が訪れます。その際はバージョンアップが必要です。停止も必要です。
Q. AWS MarketplaceにもコミュニティAMIにもWindowsサーバやLinuxサーバがあると思うのですが、どちらから選ぶのが良いのでしょうか。「AWS Marketplace」と「コミュニティAMI」それぞれのメリットデメリットを教えてください。
A. OS の古いバージョンなど Marketplace で提供されている場合があります。コミュニティ AMI は、提供元が信頼できる場合に自己責任で利用します。
Q. yum install -y httpd mysqlでmysqlもinstallしているように思うのですが、これはアプリからの接続のためにいれているという理解であっていますでしょうか。
A. 正しいです。MySQLクライアントをインストールしています。
Q. あえて今回AmazonLinux 2を使用していますが、他のディストリビューションにはないメリットが今回の研修において有るのですか？
A. 研修においてのメリットは特に有りませんが、Amazon Linux 2のメリットとしては、課金が秒単位で発生する点が考えられます。
Q. RDS作成の際、スタンバイインスタンスを作成しないでください -> アベイラビリティーゾーン：指定なし、とした結果、自動で1cに作成されました。
EC2は1aを指定しましたので、本来はRDSも1cを指定したほうがよかったでしょうか？
A. 要件として数ミリ秒のレイテンシーも許容できない。といった場合には、同じAZを指定することによるメリットはありますが、要件的に問題がなければ自動でも問題ありません。
Q. 2台目のAPP Serverを作りました。
特に設定をしなくてもWebサイトのSettingにDBエンドポイントが入力されていてDBが参照できるようになっているのはなぜでしょうか。
A. 1台目で設定した内容が、System Manager パラメータストアに保存されているため、2台目以降はGetParameterして利用しているためです。サーバー内にデータを残していないので、サーバーを増やすことが簡単にできることをご体験いただけたかと思います。
Q. VPCを分けるか分けないかの判断について聞きたいです。
本番環境、検証環境等の環境分離のためにVPCを分けることは理解できるのですが、
環境や管理を分ける以外にVPCを分けるメリットはありますでしょうか？
また、VPCを分離することでNATゲートウェイやDirect Connect等のコンポーネントを置く場合は
複数必要となり、コスト面でのデメリットとなりうるでしょうか？
A. 分離する判断基準として、セキュリティや管理面を考慮することができます。
NATゲートウェイが増えることでコストも増えます。Direct Connectは複数のVPCに対して共有して使うこともできます。
必要に応じての分離を検討してください。
Q. 1つの会社（顧客）で複数のシステムを本番利用する場合、1つのアカウントでVPCを分けて構築するのか、複数のアカウントをシステム毎に分けていくのか、
運用面も考慮し判断するポイントはどのような点がありますでしょうか？
システムによって保守ベンダも異なる場合、アカウントを分けた方がやりやすいものの、顧客側の運用を考慮すると1つのAWSアカウントで運用すべきでしょうか。
A. VPCでは分離できないサービスなどがあるので、基本的にはマルチアカウント構成が多くなります。
複数のアカウントの管理方法については、モジュール7のAWS Organizationで解説します。
Q. IPは大きく取るということですが、セキュリティグループで絞るから問題ないということでしょうか。どちらで絞るか判断はどのようにするのですか。
A. IPアドレスをあとから増やすことはできないので、予め大きく作成することが推奨されています。セキュリティグループの許可ルールを最小化することによって制御してください。
IPアドレスが不足することでリソースが起動できない状態になるのは、アンチパターンです。
AWSのスケールキャパシティメリットを活かさない使い方です。
Q. EC2, RDS などのアベイラビリティゾーンの決定は VPC (Subnet) によって決定されると考えてよいでしょうか。
A. はい。サブネットを選択することでAZが決まっています。
Q. VPC範囲は変更できないとのことですが、サブネットの範囲は変更可能ですか？
ブロードキャスの観点からはサブネットは小さめの方が好ましいと思いますが、広げたくなったら広げられるのであれば小さめに作ってもよいのではないでしょうか。
A. サブネットの範囲を変更することはできませんので予め大きめに設定してください。VPCもIPアドレス範囲を変更することはできませんが、追加することは可能です。
Q. 障害時にENIを付け替える運用ですが、これは1つ目のENIでは不可で必ず2つ目のENIを付けないといけないのでしょうか？
また、上記の動作はどのように自動化できますか？
A. EC2の1つ目のENIは操作できないので、2つ目のENIをアタッチしています。ご理解されているとおりです。
自動化については、APIで操作するスクリプトを作成することで自動化に対応できます。
Q. ElasticIPを使えば、EC2の前にELB等を配置しなくても接続向き先変更ができるように捉えました。改めてELB使う場合とEIPの使い時を確認させてください。
A. ELBを利用することで、複数のEC2インスタンスを配置できます。負荷分散の用途以外にも、片方のEC2インスタンスがダウンした場合でもサービス継続性を高めることができます。EIPで公開している場合、EIP の付替えをしている間はサービスのダウンタイムが発生するため、そのダウンタイムを許容できるかどうかになります。ベストプラクティスは単一障害点を避けることですので、ELBを使い、2つ以上のEC2インスタンスを使用します。
アプリケーションのカスタマイズができず、ロードバランシングに対応していないソフトウェアを使用するケースではEIPを使うケースがあります。
Q. セキュリティグループはENIごとということは、EIPをEC2に付与した場合はセキュリティグループを2つ設定する必要があるということでしょうか。
A. EIP は既存のENIに関連付けられますのでENIは増えません。セキュリティグループは1つで大丈夫です。ENI を追加で付与した場合は、ENI ごとのセキュリティグループを用意します。
Q. IPアドレスはAWSで5つ予約されているとのことですが、/31、/30は5個以下のアドレス数です。この範囲のサブネットは作れないということでしょうか。
A. VPCもサブネットもCIDRブロックサイズは、16~28です。
Q. サブネットやVPCに対するトポロジマップのようなものは、AWSで自動作成されるのでしょうか。自分で作成して管理するものですか。
A. 今ご紹介している範囲のサービスではご自身で作成して頂く必要があります。
モジュール6で出てくるTransitGatewayというサービスのNetwork Managerを使うとリンク先にあるようなマップを作ることができます。
https://aws.amazon.com/jp/blogs/news/new-for-aws-transit-gateway-build-global-networks-and-centralize-monitoring-using-network-manager/
Q. EC2インスタンス作成完了確認ですが、インスタンスの状態がrunningになれば良いのでしょうか、それともステータスチェックが2/2合格しましたを確認出来れば良いでしょうか。
A. runningになればOKです。
ステータスチェックはHWレベル、SWレベルでのモニタリング結果を確認しています。初回確認時に時間がかかりますが、runningになればインスタンは起動しています。
Q. VPCピアリングのリクエスタ/アクセプタの設定先の指定について、以下のイメージを持ちましたが合っていますか？
リクエスタ:自身がオーナーのVPC
アクセプタ：自身もしくは他者がオーナーのVPC
この場合、アクセプタのVPCが自分であれば自分で即時許可が出せ、他者であれば許可待ち時間が入ると考えています。
A. そのご理解であっています。他のVPC管理者から勝手にピアリングができないようになっています。
Q. VPCのデフォルトルートテーブルでサブネット同士のルーティングが許可されていますが、特定のサブネット同士のみ通信許可したい場合はデフォルトのルートテーブルを削除することはできますでしょうか。
それともNACLで拒否する方法が良いのでしょうか。
A. NACLで拒否してください。デフォルトのルートエントリは削除できません。
Q. ルートテーブルに設定を追加しなければいけないのは、どのような場合でしょうか。
サブネットを跨いで通信するようなとき(Internet GW、ピアリング等)であり、同じサブネット内の通信の場合にはルートテーブルに設定する必要がない、のような認識であっていますか？
A. 同じVPC内のルートエントリは設定済ですので、設定する必要はありません。
Q. ルートテーブルはGWとサブネットの設定だと思いますが、セキュリティグループを設定しなくともルートテーブルでHTTPだけ許容したことになりますか。
A. ルートテーブルは、サブネットのネットワーク経路を指定しているだけであるため、HTTPだけ許容したことにはなりません。セキュリティグループ、ネットワークACLの設定が必要です。
Q. VPCのデフォルトのルーティングテーブルではなく、あえて新しくPublic用のテーブルを作る理由は何でしょうか。
A. デフォルト(メイン)ルートテーブルは、新しく作成されるサブネットに初期設定されるルートテーブルであるため、インターネットゲートウェイへのルートを追加した新しいルートテーブルを用意しています。もし、デフォルトルートテーブルにインターネットゲートウェイへのルートを設定した場合は、新しく作成されるサブネットのデフォルトがパブリックサブネットとなりますので意図しない状態が生まれます。メインルートテーブルは特定のサブネットで使用しないこと検討してください。
Q. ルートテーブルはサブネットの数だけ作成する認識でよろしいでしょうか。
また、ルートテーブルに明記するサブネットはスタティックルートやデフォルトルートのみで、
その他のルーティングは暗黙的に記載されているイメージでしょうか。
A. 同じルートを利用する場合であれば、サブネット毎にルートテーブルを用意する必要はありません。1つのルートテーブルに複数のサブネットを関連付けることができます。
ルートテーブルに設定されていないルーティングは処理されません。VPC 内の通信は、VPC の CIDR が local で指定されているため他のサブネットへのルートがあります。
Q. システムを新規で構築する場合、デフォルトVPC、デフォルトルートテーブルは削除すべきでしょうか？
A. デフォルトVPCは、必要がなければ削除してもいいです。デフォルトルートテーブルは、新規サブネットの初期ルートテーブルになるので削除しません。
Q. VPC作成の上限がデフォルトで5つだったと思いますが、デフォルトVPCはその上限に入る認識で合っていますでしょうか？
A. はい。デフォルトVPC を利用せずに残していると実質的に4つのVPCまでしか作成できません。
Q. VPC：VGWは1：1でしょうか
A. はい
Q. EC2作成時にIPv4 パブリック IPが自動割り当てされていなかった場合、Publicサブネットの設定を変更後、EC2再起動ではなく、再度EC2の作成からし直す必要があるのでしょうか。
A. EC2 のパブリックIP付与の設定は、新規インスタンス作成時にのみ指定できます。あとからパブリックIPが必要になった場合は、AMIを作成してインスタンスを起動する方法以外にも、ElasticIPをアタッチすることで対応できます。
Q. VPNのみとDirect Connectを比較した場合に、専用線であるDirect Connectの方がメリットが大きく見えました。
VPNを選択するケースとしてはどんなものがありますでしょうか？
通信量での従量課金以外の部分で、Direct Connectは劣るのでしょうか？
A. 常に一定の通信量（1Gpbsや10Gbpsといった）が必要ない場合、Direct Connectのほうがコストが大きくなる可能性があります。
Q. VPCピア接続はIP空間は重複できないとありましたが、後から被っていることが判明した場合どうすればいいでしょうか。（他アカウントとの接続などの場合）
A. VPCを新たに作成して、新しいVPC へのリソースやデータの移行作業を行います。
Q. TransitGatewayで、サブネットAからサブネットCは許可しない設定はできますか？送信元で判断するような感じですか？
A. 可能です。サブネット間の通信経路設定はルートテーブルで行います。ルートテーブルで許可した上で制御する必要がある場合は、ネットワークACLで制御できます。
Q. 現在は小規模でも今後の展開（展開されてるかは不明だが、していきたいという要望はある状態）を見据えて、TransitGatewayを使用しておくことは有効かと思いますが、ベストプラクティス的には適切な選択ではないのでしょうか？
A. TransitGatewayでは、時間単位の接続数とトラフィックの課金が発生します。そのコストが許容できるのであれば適切であると捉えることができます。
Q. 静的コンテンツをS3に配置しELBのルーティングで静的コンテツはS3につなげる、というやり方は通常のやり方でしょうか？もしくはそもそもELB配下にS3は配置できないでしょうか？
A. ELB のターゲットとして S3 を指定することはできません。S3 をターゲットとする場合、CloudFront を利用できます。CloudFront については明日解説いたします。
Q. ELBで特定のパスを特定のインスタンスに流す場合、そのインスタンスがダウンした場合、新たなインスタンスが立ち上がった後、そのインスタンスに自動で流されるであっていますでしょうか。
A. ELBからのリクエストがターゲットインスタンスに流されてターゲットインスタンスがダウンした場合にリトライされることはありませんが、ヘルスチェックによりアンヘルシーとしたインスアタンスにはリクエストは送信しません。リクエスト済で処理中に異常が発生し、他のインスタンスでリトライしたい場合は、SQSなどを使いリトライできる設計を構築します。
Q. ELBの分散方式は何がありますか？
A. ELB の分散方式として登録されているターゲットに均等に振り分けるラウンドロビン方式とリクエスト処理数に応じた振り分け方式があります。
Q. Route53は外部の名前解決を行うリゾルバとしても機能しますか？
A. はい。構築できます。
Q. AWS Transit Gateway以外にリージョン間のピアリングがサポートされているサービスはございますでしょうか？
A. VPC ピア接続でもリージョンをまたがった接続が利用できます。
Q. AWSユーザーとして、ActiveDirectoryのアカウントを利用する、もしくは、連携することはできますか？
A. Active Directory と連携することができます。
Q. IAMプリンシパルではIAMグループの設定はできないのでしょうか？
A. グループは現在プリンシパルとして指定できません。
Q. 1つのユーザーやグループに複数のロールやポリシーを割り当てられますか？その場合、どれが優先されますか？
A. 複数のポリシーを割り当てることができます。許可ポリシーは合計で適用されます。拒否ポリシーは、許可よりも優先されて適用されます。
1人のユーザーが複数のグループに所属することは可能です。
ロールは割り当てるのではなく、一時的に受け入れる機能になりますので、同時に複数のロールを使用することはありません。
Q. Cognitoの料金体系について教えてください。単一のウェブ（モバイル）アプリに対して利用する場合と複数のウェブアプリケーションに対する認証基盤（SSO)として利用する場合で料金は異なりますか？
A. Cognito の課金は、月間アクティブユーザー数に応じて課金されます。アプリケーションが増えるだけでは計算は変わりませんが、多くの場合アプリケーションが増えればその分のアカウント数が増えることが想定できます。
Q. EC2のリザーブドインスタンスの利用時間計算はOrganizations単位でしょうか。
A. リザーブドインスタンスの適用範囲は、Organizations で管理されているアカウント内、ビリングファミリーで共有されます。
Q. EffectのDenyを記載していましたが、Denyで明示的に拒否しなければすべてAllowなのでしょうか？
A. 明示的に Allow としなければ、すべて Deny です。あえて、Deny を記述する理由としては、間違えて Allow された場合でも、Deny が優先されるため不慮の事故を起こさないようにできます。
Q. AWS Organizationsもグループもどちらも権限管理の運用が向上すると理解しました。
ただ、AWS Organizationsでの権限管理と各グループでの権限管理とでのメリットデメリットがいまいち理解できなかったのですが、改めて説明して頂きたいです。
A. Organizations とグループでは、権限管理のスコープ（範囲）が違います。AWSアカウント内の複数のIAMユーザーへの権限管理を行う場合はグループによる権限設定を行います。複数のAWSアカウントに対して権限管理を行う場合はOrganizationsのSCP(サービスコントトールポリシー)を使用します。
Q. IAMロールの信頼関係についてよくわかりませんでした。もう一度説明いただけると幸いです。
A. IAM ロールの信頼関係は、「どのプリンシパルが IAM ロールを利用できるか。」を設定します。スイッチロールで利用する場合であれば、そのロールに切替られるAWSアカウントを指定しています。EC2 にアタッチする IAM ロールでは、どのサービスが利用できるかとして EC2 を指定しています。
Q. CloudWatch では特定の文字列（例：RDSのエラーやアラーム情報）を指定することはできるのでしょうか？
A. RDSはイベント別に通知を受けることができます。アラームイベントにはそのアラームについての情報がすべて含まれます。
CloudWatch Logsでメトリクスフィルターを使えば文字列の抽出とメトリクス化ができます。
Q. CloudWatch はほかのマネージメントサービス同様、冗長性などは考慮せずに、ただ単に使うだけという理解でよろしいでしょうか。
A. はい。そのご理解で大丈夫です。
Q. どのプロセスがCPU使ったのかは分かりますか？
A. 標準メトリクスでは取得していません。EC2のOSはお客様の管理範囲なので、AWSが勝手にデータを収集することはありません。独自のカスタムメトリクスとしてコーディングしていただければ収集できます。
Q. セキュリティグループとネットワークACLへ許可・禁止する条件が多くなると通信パフォーマンスは悪くなるでしょうか？
A. はい。特にセキュリティグループルールが多い場合は、パフォーマンスに影響を及ぼすアンチパターンです。
Q. CloudWatchのメトリクス監視対象にCloudWatchLogsのメトリクスフィルタでカウントアップされたものを追加した場合、課金されますか？
A. はい。カスタムメトリクスとなり、追加料金が発生します。
Q. CloudWatchはEC2内のアプリケーションログ（IISログなど）を定期的にクローリングしてS3などに溜め込むことは可能ですか？
A.CloudWatch Logsで取得し、S3エクスポートリクエストを定期的に実行することで可能です。
Q. ログの収集はアプリ側から特定のAWSサービスのエンドポイントに投げるイメージではなくSysmteManager側がアプリログを見に行って CloudWatchに収集されるという感じであっていますか？（アプリ側からはログ収集されていることを意識しない。あと付けて収集が可能、となる）
A. CloudWatch AgentがEC2上で動きます。Agent起動時にSystems Managerパラメータストアの設定を見にいってます。ただし、収集しているのはAgentですので、アプリ側での意識は必要ありません。あとからも収集します。
Q. EFSやS3ではメンテナンス（計画停止）はAWS側で発生しないでしょうか。
また、サポートライフサイクルはあるのでしょうか。
A. メンテナンスがあったとしてもその影響での計画サービス停止はありません。
AWSはこれまでにレガシーとなったサービスや機能の提供終了は今のところ発生していません。
Q. AZ障害を考慮する必要がある場合についての質問なのですが、AZ自体が自身のコントロール下ではないので障害試験の具体的なシナリオがイメージできません。
常套手段等ありましたらご教示いただけないでしょうか？
A. サービスによって異なります。例えばRDSであればマルチAZ環境で手動再起動時にフェイルオーバーさせることができますので、アプリケーションへの影響を確認することができます。
EC2などの場合は手動で削除や停止を行って、またはプログラムを作って自動で壊しながら自動復旧させるという検査を行っているお客様もいます。(例: NetFlixさんのChaosエンジニアリングなど)
Q.AWSサービスでデータ変換（CSV、DB、xml、固定長など←→CSV、DB、xml、固定長など）するサービスはありますか
A. AWS Glueがあります。
Q. 社内から仮想マシンに接続する方法は色々あると思いますが、おすすめの方法を教えてほしいです。踏み台を設けたほうが良いのでしょうか。
A. インターネット経由でもVPN 経由でも接続することができます。
オフィスネットワークとAWSをVPNでつないで、社外の方はオフィスへVPNで接続したうえで利用することや、社外の方は AWS Client VPN を利用して直接接続することができます。
Q. クライアントVPNの機能について、例えば社員数百人が自宅からリモート接続する際に、
それぞれの通信を全てVPNにて行えるようになる機能ということで良いですか？
A. はい。
Q. 本日のおさらいで表示戴いたスライド4では、EFSはAZの外に配置されています。
FSxやEFSは、（S3のように）サブネットやAZの外にあり、AZ冗長化は考慮しなくて良い仕組み、という理解で良いでしょうか。
A. はい。ただしマウントターゲットはサブネットを指定しますので、複数AZに構成いただくことがベストプラクティスです。
Q. AmazonRDSをマルチAZ配置できることを教えていただきましたが、リージョンまたぎで冗長化することは可能でしょうか。
A. クロスリージョンリードレプリカが使えます。また、Auroraにはグローバルデータベースというオプションもあります。
Q. NAT Gatewayの役割をもう一度教えてください。
A. プライベートサブネットからインターネットゲートウェイを経由したインターネットへのアウトバウンド通信が必要になったときに、プライベートサブネットからのリクエストをプロキシするサービスです。インバウンド通信は受け付けません。
プライベートサブネットからインターネットゲートウェイを経由したインターネットへのアウトバウンド通信が発生しなければ配置する必要はありません。（例えば、プライベートサブネットからのアウトバウンド通信がVPN経由でオフィスネットワークから出ていく場合など）
また、S3などVPCの外のサービスに接続する場合でも、VPCエンドポイント経由で接続すれば NATゲートウェイは設置する必要がなくなります。
Q. 過去AZが使えなくなった事例はあるのでしょうか？もしご存じであればご教示いただければ幸いです。
A. AZ全体の障害ではないですが、2019年の夏に東京リージョンで発生した障害についてAWSがまとめた資料がありますのでご参照ください。
東京リージョン (AP-NORTHEAST-1) で発生した Amazon EC2 と Amazon EBS の事象概要
Q. NATゲートウェイの利用シーンについて、パッチの取得などを挙げていました。
直接インターネットに出ないのが一番好ましいと思いますがAWSでプロキシのようなサービスは用意されていませんか？
A. AWS でパッチファイルなどをプロキシするサービスはありませんが、Amazon Linux などでは、RPMファイルを S3 から取得するようになっています。同様にS3にパッチファイルをアップロードして、VPCエンドポイント経由でS3にアクセスする構成であればNATゲートウェイは不要にできます。
Q. NATゲートウェイを導入していればVPCエンドポイントを設置する必要はないでしょうか？
それぞれ個別に設置したほうがいいのでしょうか？それぞれメリット等あればお聞かせください
A. VPCエンドポイントへアクセスできるサービスであればNATゲートウェイは不要です。また、NATゲートウェイ、インターフェイス型のVPCエンドポイントは費用が掛かります。コストバランスに応じて検討します。
Q. NAT-GWの2台とEC2の2台は、片側のNAT-GWダウンに備えてクロス接続すべきなのでしょうか？（構成図ではクロスしていないので・・・）
A. クロス接続はおこなわないです。
NATゲートウェイが利用できない状況では、AZ自体が利用できない状況が考えられます。すなわち、同一AZ内のEC2インスタンスが利用できない状態である可能性があります。
NATゲートウェイは接続元となるプライベートサブネットが存在するすべてのAZに配置をし、同一AZ内のプライベートサブネットからのアウトバウンド通信をプロキシさせるように経路設計をします。
Q. CloudTrail を使用する際にS3バケットでの設定はどのようなものが必要なのでしょうか？
それとも自動的にS3が立ち上がるのでしょうか
A. 新しいS3バケットを利用するように構成した場合は、自動的に作成されてバケットポリシーも設定されます。既存のバケットを利用する場合は、自身でバケットポリシーを設定する必要があります。
Q. CloudWatchの請求アラームで一定期間稼働していないものを通知するようなことも可能でしょうか？
あるいは一定期間稼働していない環境を自動削除するような設定は可能でしょうか？
検証環境などで不要になった環境を利用者が意識せずともコストの無駄なく利用する方法があればご教示いただければ幸いです。
A. はい。可能です。アラームをもとに自動削除なども必要に応じてプログラムを作れます。
あるいは、Trusted Advisor の「コスト最適化」で利用されていないリソースを検出することもできます。
Q. EC2 Auto Scaling は、リージョンをまたいで作成はできないでしょうか。
A. リージョンをまたいだ構成は作成できません。
Q. サーバ障害時に自動的に新しいインスタンスが起動するという動作のみを目的とした
1台構成のオートスケーリンググループを作成することはサポートされますでしょうか？
また、その場合1台なので負荷分散は不要となりますが、ELBは構成不要でしょうか？
A. 要件として受け入れられる場合ご提示の利用方法も可能です。負荷分散としてのELBは不要ですが、リクエスト先のパブリックIPをElasticIPなどで付け替えることをしないのであれば、ELBを利用します。
Q. 話を聞いているとEC2の複製に聞こえるので、今あるEC2にDBとかそれを使用するアプリケーションがインストールした状態のEC2であれば、DBを別のAWSサービスに別出ししたあとでEC2をオートスケールにしないといけないという認識であっていますか？
A. あってます。オートスケーリングで起動するEC2インスタンスには情報を残さないことがベストプラクティスです。
Q. 起動テンプレートとAMIの違いは何でしょうか。
使える先が違う(起動テンプレートはAutoScaling用で、AMIはEC2インスタンス新規作成用他)というの理解しましたが、差分はそれだけでしょうか？
A. AMI は 起動されるインスタンスのテンプレートそのものです。インスタンスタイプやユーザーデータなど起動時に設定される内容は保有していません。
起動テンプレートは、新しいインスタンスを起動するときの条件を指定しておくテンプレート情報です。AMI やユーザーデータなどを指定します。（マネージメントコンソールでインスタンスの作成時に操作している内容を事前に設定します）また、起動テンプレートはオートスケーリング専用ではないので新規インスタンスの作成時にも利用できます。
Q. AutoScallingされたEC2インスタンスもCloudWatchでメトリクスやログを見れますか
A. オートスケーリングで作成されたEC2インスタンスはマネージメントコンソールで作成されたインスタンス同様に CloudWatch でメトリクスを確認できます。また、ログのエージェント設定が行われていれば、CloudWatch Logs へログの転送も行なわれます。
Q. 「スケールインはゆっくり」は具体的にはどのような設定をするのでしょうか？
A. オートスケーリングのトリガーとなるCloudWatchのデータポイントを増やし間隔を長くします。そうして、一時的なピークが過ぎたあとに再発生するリクエストに備えます。
Q. Windows AMI作成時にSysrep等なにか事前処理は必要でしょうか？
A. Windows 用 AMI の作成には Sysrep の利用が推奨されています。詳しくはドキュメントをご参照ください。
Sysprep を使って標準の Amazon マシンイメージを作成する
Q. リージョンまたぎでオートスケーリンググループを作成できないということでしたが、東京リージョン、USリージョンをそれぞれ利用し、通常、東京リージョンを使っていて、東京リージョンが何かの理由で使えなくなった場合に、USリージョンでEC2インスタンスを起動するような構成はできないでしょうか。
A. Route53 を利用することでマルチリージョンに対応するフォールトトレラントの仕組みを構築できます。
Q. オーロラサーバーレスはリードのみで自動スケールという捉え方であっていますか？
A. リードだけではありません。DBインスタンスそのものの性能がスケールします。
Q. DBスケーリングのリードレプリカ～シャーディングの部分がいまいちよくわからなかったのですが、要するに2つ以上のDBを作成してそれぞれの機能でそれぞれのDBに分配させるのでしょうか？
A. リードレプリカは、書き込み用のデータベースとは別に読み込み専用のデータベースを用意してデータの読み込みトラフィックを分離させる仕組みです。書き込み用と読み込み用のデータベースは非同期レプリケーションされます。
シャーディングは、データの格納先を分離する仕組みです。たとえば、IDの先頭がAからHで始まるデータはデータベースA、IからZまではデータベースBという構成です。
Q. Auto Scalingによって停止したインスタンスを検知した場合、新たなインスタンスが自動作成されました。
停止したインスタンスは明示的に手動で削除する必要がありますか？
ElasticIPをアタッチしている場合は停止しているインスタンスが増えれば課金額も増えますよね？
A. 削除する必要はありません。自動的にterminated(削除)になります。
EIP分が課金対象になります。その場合はEIPが不要であれば開放します。
ただし、今回のラボのようにELBでユーザーリクエストを受け付ける場合はEIPは必要ありません。
Q. 今回の演習ではオートスケーリングのインスタンスは2つなので、2つのAZにそれぞれ1つづつEC2が起動し、もし、3つにした場合、1個は2つのAZいずれかに立つという理解でよいでしょうか。
A. はい。あってます。
Q. 1つのELBに対して1ターゲットグループしか設定できない、という認識であっていますか？
A. 複数のターゲットグループを設定可能です。
Q. ルートテーブルの初期値で設定されているlocalとは何でしょうか。
A. VPC内の送信先です。
Q. ELBで証明書を持たせる場合、証明書の更新などはどのような操作をするのでしょうか
A. ACM(AWS Certificate Manager)でメール認証している場合は、メールが送信されるのでリンクをクリックします。CNAME認証している場合は自動更新です。いずれもELB側での設定変更は必要ありません。
Q. Amazon RDSで、リージョンをまたいだリードレプリカは可能でしょうか。
A. 可能です。クロスリージョンリードレプリカと言います。
Q. 運用上、DBを参照するケースと、Appサーバーへのアプリのデプロイをする場合、どのように構成しておくのがベストなのでしょうか。
A. まず、構成としては今回のラボの構成がベストプラクティスではあります。運用上という意味で、モニタリング、自動化と捉えますが、モニタリングはCloudWatchで行い、必要なメトリクスをダッシュボードで可視化し、必要に応じてアラームを設定します。必要なログはCloudWatch Logsに出力します。必要に応じてメトリクスフィルタでメトリクス化、アラームをします。
自動化の側面においては、これらのアラームにより発生するアクションを可能な限り自動化します。
Q. ベストプラクティスとしては、Webサーバなどもパブリックサブネットには立てずに、今回ようにプライベートサブネットに配置をして構成するほうが好ましいのでしょうか？
A. はい。そうして、仮にセキュリティグループを間違えてしまったとしてもリソースを守ることができます。
Q. 書籍を見ていても、プロビジョニングとデプロイが混同してしまいます。
CloudFormation ・・・ プロビジョニングのみ
Beanstalk、DevOps ・・・ プロビジョニング及びデプロイ
よい覚え方はないでしょうか
A. 何をプロビジョニング、デプロイすると記述されるのかによって捉えられれば言葉の違いは深く考えなくてもよいと思います。参考としましてですが、
プロビジョニング: 調達してくる
デプロイ: 展開する
という意味で使われることが多いです。
Q. テンプレートはどこにどういう記述をすればよいのか説明している資料などはあるのでしょうか。
A. CloudFormation テンプレートリファレンス をご参照ください
Q. CloudFormationは、Lambda（LayersやVPCの設定も含めて）もテンプレート化して環境を再現できるのでしょうか？
A. Lambda の構成も自動化できます。サーバーレスアプリケーション専用の AWS サーバーレスアプリケーションモデル (SAM)というCloudFormationの拡張機能もあります。
Q. テンプレートの更新を反映させるときに、差分更新で反映されるのでしょうか？
A. 差分更新できる場合は差分更新されます。VPCのCIDR変更など差分更新ができない場合は、新たに作り直されます。
Q. CloudFormation で追加したリソースを逆に(追加したリソースだけ)削除することなどはできるのでしょうか。
A. 削除できます。CloudFormation のスタック単位で削除できます
Q. CloudFormationのyamlの記載内容が正しいかをチェックするような機能はありますか。test Runさせて実際に環境は作成されない状態できちんと有効な内容であることを事前に確認をしたいです。
A. CloudFormation のテンプレートは AWS CLI のvalidate-templateコマンドで検証できます。テンプレートの検証
CloudFormation により作成されるスタックが予期した通りかを確認する場合は、変更セットを作成して確認できます。
Q. テンプレートの自動生成機能またはサポートサービスはありますか？JSON/YAMLでゴリゴリ書くしかないですか？
例えば、Trailで記録されたAPI操作からYAMLが書き出されるなど、できるのでしょうか？
A. AWS の標準機能ではなく、サードパーティからいくつかのサービスが提供されています。 Former2 などが有名です。
Q. スタックが理解できていないです。教えていただけますか。
A. スタックは、CloudFormation が作成するAWSのリソースの集合体を意味します。
Q. テンプレートでインスタンスを複数作成した場合、各インスタンスの区別がしやすいようなタグや名前はJson等で設定することはできるのでしょうか。
A. はい。可能です。JsonでもYamlでも可能です。また、スタック作成時にも指定可能です。
Q. Elastic BeanstalkとLambdaの違いを確認させてください。
A. Lambda は用意したコードを実行するリソースを管理しなくてもいいサービスです。（サーバーレス）Elastic Beanstalk は、用意したコードを実行する環境を構築してくれるので、出来上がったリソースなどの運用は必要です。
Q. CloudFormationnoの設定の記述で、インスタンスの記載順番を気をつけなければいけない場合はありますか？例えば演習のようにネットワークとアプリは別で作り、ネットワーク→アプリの順番で実行しなければだったり、アプリの構成においても、ELB関連でELB自体、EC2等構築順など？があるのではないかと想像します。
また、その順序性が妥当化はファイルインポート時に警告される、もしくはCloudFormation側でよしなにやってくれるでしょうか。
A. 作成されるリソースの前提リソースを指定する DependsOn 属性を使います。
Q. スタックの削除が完了したイベントを見ることは出来ますか。
A. はい。確認することができます。
Q. 実際の作業として、初回にAWS環境を構成するときにCloudFormationから始めることは現実的なのでしょうか。
開発環境を手動で構築し妥当性を確認してから、Yamlにツールで自動もしくは手動で出力し、
開発環境の再構築を含む検証・本番環境をCloudFormationから再度作るような感じにならないでしょうか？
A. 検証した環境をもとにFormer2 などのサービスでテンプレートを作成したり、CLIコマンドの出力結果とリファレンスのサンプルをあわせたり、という手順もあります。また、同じような構成を増やしたいという場合に、既存のテンプレートを複製して利用することで検証済みのコードを再利用できます。
Q. 削除ポリシーで作成したスナップショットを指定してスタックを再作成することはできますか？
A. はい、できます。
Q. すいません、キャッシュの概念がよくわからなかったです。
DB側もDBの種類によっては内部でキャッシュを持つような構造になっていると思います。
ここでいうキャッシュというのは、DB外にさらにクエリの結果を持つようなメモリを作成するということでしょうか？
→どこかでキャッシュに乗せる必要があるが、キャッシュ乗せが完了すればDBにはアクセスしないのでその分のIOなどがなくなる
A. データベースについて考えると、そのご理解であっています。
CloudFront のようなウェブコンテンツの場合もデータベースの考えと同じようにウェブサーバーやウェブアプリケーションサーバーに処理をさせずに計算済の結果を、リクエストユーザーに対して低レイテンシーのエッジロケーションからレスポンスを返します。
Q. エッジロケーションのイメージがつかないのですが、クライアントがどこのエッジロケーションを参照するかどのように決定されるのでしょうか。
またCloudFrontを配置するエッジロケーションは指定可能ですか？
A. クライアントが利用するエッジロケーションは、ユーザーに対してレイテンシーの低い場所が選択されます。
CloudFront を使用する地域を設定で限定することができます。
Q. Invalidationにもコストもかかるとはどういうことでしょうか？
A. エッジロケーションにキャッシュされているコンテンツを削除する処理に対して請求が発生することを意味します。
Q. CloudFrontは、ターゲットが日本国内だけの場合でも使用メリットありますか？
A. はい。メリットがあります。
オリジンにEC2を指定している場合などでは、CloudFrontにあるキャッシュを返すことができるので EC2 インスタンスのサイズを小さくしても対応できるようになります。結果、コストの最適化を図ることができ、計算処理が発生しない分ユーザーには素早くコンテンツを返すことができます。
Q. CloudFrontの概要がいまいち分かりませんでした。
ユーザーの近いエッジロケーションを設定して、データ送信の中継機関のような役割を果たしてくれるような認識でよろしいでしょうか。
A. 最終的にユーザーに返されるコンテンツをキャッシュとしてエッジロケーションから返せるサービスです。
参考情報：たとえば大阪に商品を配送すると考えた場合、毎回東京の倉庫から送るのではなく、大阪の近い場所にある倉庫から発送すれば早いと思います。すなわち、中継機関というよりも中間貯蔵庫というイメージです。
Q. コストがかかる機能かからない機能、基準がわかりません。削除するのだからむしろコストが掛からないのではないのですか？
A. CloudFrontに削除処理をリクエストしています。とはいえ、仰っておられるようにS3のDeleteリクエストは無料などサービスによって異なります。AWS全体でルールがあるわけではなく各サービスごとに料金は最新の情報を確認してください。
Q. CloudFrontを使用した場合の実際のアクセス数は分かりますか？
A. CloudWatch のメトリクスで確認できます。
Q. CloudFrontの料金体系はどのようになっておりますでしょうか？
A. 転送量とリクエスト数による課金があります。
Q. ElasticacheとDBアクセスを アプリケーションから意識せず透過的に利用できるものでしょうか？
A. アプリケーション側でコントロールする必要があります。アプリケーション側でキャッシュ確認して無効であればDBから取得する処理を行うのが遅延リクエストです。
参考情報：データベース接続用のライブラリによっては、接続時にMemcached の情報を渡すことで、透過的に処理をしてくれるライブラリもあります。この場合でも、ライブラリに対してMemcached の接続先情報を渡す方法はアプリケーション側で考えます。
Q. セッション情報の保持にスライドの例にあったDynamoDBではなくElatieCacheやRedisを利用することはできますか？
A. はい。セッション情報の格納先としてElastiCacheを利用できます。
Q. Auroraであれば15個以内のサブネットに一個づつリードレプリカを置いておけば耐障害性の面でもメリットありそうですが、ElastiCacheのほうがコスト的にも安くなるのでしょうか
A. ElastiCache を利用することで、データベースサーバーへ処理を流さずに結果を取得できる。というメリットがあります。また、データベースの処理よりもインメモリキャッシュのほうが多くの場合で結果を早く取得できます。ただし、全体的なノード数にも依存するので想定される環境を検証してください。
Q. SSL終端を考慮すると、CloudFrontとELBどちらにも証明書を持たせることが必要でしょうか。
構成：クライアント→CloudFront→ELB→EC2
A. 要件次第です。ELB、EC2 に対する通信についても SSL通信が必要であるという要件であればそれぞれに証明書を持たせる必要があります。
CloudFront でSSL終端することで、証明書の管理を1か所にするというメリットもあります。
Q. キューの処理を受け取った後スポットインスタンスが中断した場合、他のサーバーに処理を行ってほしいところですが、処理中に中断してしまったという連携はどこでやるのでしょうか。
たとえば現在たまっているキューが処理中なのかどうかコンシューマーはどうやって判断するのでしょうか。
A. 処理されなかったメッセージは可視性タイムアウトで設定した時間が経過すれば、受信可能になります。受信できるメッセージは未処理という判断ができ、可視性が失われているメッセージは処理中という判断ができます。ただしあくまでもメッセージが未処理か処理中かという判断ですので、実際の処理についてはステータスなどを判定して冪等性を実装します。
Q. ロケットチャットのようなチャットツールではFIFOキューのほうが適しているということでしょうか。
A. メッセージの重複を許容できない、先入れ先出しを実装したいケースではFIFOキューを使用します。今回の構成でRocketChatに投稿している処理については、厳密な順序指定も必要ありませんし、メッセージが重複しても大きな影響はありませんので、標準キューを使用しています。
Q. FIFOキューはコンシューマとの連携に失敗した場合は（処理されたかわからない）、二度と処理されないということでしょうか。であれば、標準キューで冪等制御したほうがいいかなと思ったのですが。
A. メッセージを削除しない限り、リトライができます。デッドレターキューを用意しておくことで指定回数リトライして失敗したキューデータを保持することもできます。
どちらのキュータイプを使用している場合でも、冪等性は実装するほうがいいです。
Q. 標準キューとFIFOキューのイメージが付きませんでした。何か具体例とかございますか。
A. FIFOキューは、First in First Out の名前の通り、メッセージが登録された順番通りに取得できること、重複してメッセージを受け取りたくないケースで利用します。例えば先着順に予約可能な場合は先入れ先出しを守らなければなりません。そのような要件がなければ標準キューを使用します。
Q. 可視性タイムアウトで60秒のタイムアウトを越えたので別のサーバーがキューを処理し始めた時、遅ればせながら先に処理していたサーバーが結果を返してしまった場合はどうなるのでしょうか。
A. 重複処理となります。可視性タイムアウトは短かくなりすぎないように調整が必要です。
Q. 可視性タイムアウトはメッセージの重複処理を極力なくすための処理でしょうか。
処理としては、キュー取得→可視性タイムアウトで見えなくなる→処理が終わる→キューを消す の流れであっていますか？
A. はい。あっています。重複して複数のコンシューマでキューメッセージを同時に受信しないための仕組みです。
Q. キューが正常に処理されたという状態はどう決定されるのでしょうか。例えば、可視性タイムアウトでいうと、処理中コンシューマがタイムアウト時間内に処理された状態にならなかった場合、別のコンシューマが処理するという形になるかと思うのですが、実は処理中コンシューマがなんらかの理由で処理が遅延していただけで、二重で処理してしまうようなことにはならないでしょうか。
A. 正常に処理が完了すればキューから削除します。
可視性タイムアウトでも重複して処理される可能性はありえます。したがって、アプリケーション側でもタイムアウトの考慮などを検討します。
Q. プロデューサーは投げたキューメッセージの処理結果については特に確認しないという作りがベストなのでしょうか。結果を待つようであればあまり疎結合感がないので。。。
A. はい。プロデューサー側（送信元）はキューに登録した時点でプロセスは成功して終了とします。
Q. ロングポーリング方式ではなく、キューにエンキューされたイベントで処理を開始する処理方式は考えられないのでしょうか。
A. Lambda を利用する場合、ポーリング処理は書かなくてもSQSをトリガーにできます。ですが、内部でロングポーリングが行われていますので同じです。キューにメッセージが送信されたことをイベントとして、受信リクエストを実行する、という仕組みも考えら得ますが、その分の遅延は発生します。
Q. SQSとSNSの使い分けはどのようになりますでしょうか？
A. SQSは非同期化、SNSは並列化とお考えください。
SQSはメッセージとコンシューマが1対1です。リトライできることで耐障害性が向上します。
SNSはメッセージとコンシュマーが1対多です。1つのメッセージに対しての複数のアクションが可能です。
Q. モジュール11の猫の画像をS3に格納したらイベント通知をSNSが受け取ってSQSキューに並列化させてメッセージを送るところですが、「サムネイル作成」「モバイル向けのサイズ調整」「ウェブ向けの画像サイズ調整」と同じメッセージを並列化ではなく、異なるメッセージを並列化して送っているのでしょうか。
A. それぞれ同じメッセージが送られています。
Q. FargateもDockerコンテナですか？
A. 2020年4月のアップデートで、Docker Engine から Docker コンテナをサポートする containerd というエンジンに変更されました。
https://aws.amazon.com/jp/blogs/news/under-the-hood-fargate-data-plane/
Q. ContainerはAWS独自技術ではないので、利用に関しては無料という認識で会っていますか？
ECSなどを利用するときだけ課金対象でしょうか。
A. はい。コンテナの利用についてソフトウェア料金はかかりませんが、FargateやECSで起動されるEC2インスタンスの料金が発生します。
Q. LambdaはAZサービスですか？VPCサービスですか。
A. 選択できます。Lambdaはリージョンを選択して使うこともできますし、VPC内で起動して使うこともできます。また、エッジロケーションで起動することもできます。
Q. サーバレスアーキテクチャでログインセッションを有するアプリを構築するにはどのようにすればよいですか？
A. Cognito のユーザープールを使用します。
Q. 様々なサービスが登場してくる（Lamdaを制御するであればStepFunctions）といった具合にどんどん使用するサービスが増え管理が難しく、いろいろ望むことをやったら自分がなんのサービスで何をやっているのかわからなくなりそうです。全体整理するようなサービスはありますか？
A. AWS のサービスを全体管理する仕組みは順次提供されてきています。
サーバーレスアーキテクチャでは、個々のサービスを管理する仕組みとしてX-RayやCloud Map、App Meshといったサービスが登場してきています。
Q. StepFunctionsは、分岐や並列処理、エラー時のフロー制御は行えますでしょうか。あと、ステップの実行結果を別のステップに渡すことはできますでしょうか。
A. Step Functions で作成するステートマシンでは、ご質問にある分岐や並列処理、エラーフローなどできます。
ステップの出力を次のステップの入力データにすることができます。
Q. StepFunctionsで、なんらかのイベント(SQSにキューイングされた等)が発生するまで処理を待機するといったことはできますでしょうか。
A. 可能です。変動的な条件に基づく場合はアクティビティを使用し、時間に基づく場合はWaitタイプを使って待つ時間を指定します。
Q. Lambdaのコールドスタート対策はなにかありますか？
A. Provisioned Concurrencyという新機能があります。
Q. Lambdaにてnpmでモジュール追加はどのようにできますか？
またレイヤの機能についても簡単に説明いただけないでしょうか。
A. 可能です。方法は2つです。コードとモジュールをzipでまとめてUploadします。もう一つはモジュールだけをzipにしてLayersにアップロードします。そしてLambda関数からLayersを設定します。Layersは複数のLambda関数で共通のモジュールを利用できる仕組みです。
Q. Lambdaは処理完了後実行環境は破棄されるものかと思いました。
実行環境が残っているという場合でも、起動されるLambdaの実行環境は選べるものなのでしょうか？
A. 指定はできませんが、次に発生するリクエストのために一定時間残っています。
Q. S3, DynamoDB からのトリガーは Lambda からでも、各サービスからでも設定できるととらえても良いのでしょうか。
A. はい。両方とも可能です。
Q. サービスを表すアイコンはどこで入手できますか？
また、構成図の自動作成ツールはありますか？CloudFormationのデザイナーが近かったような気がしていますが？
A. こちらにあります。
https://aws.amazon.com/jp/architecture/icons/
下の方にサードパーティの描画製品がいくつかありますが、アカウントから構成情報をエクスポートする機能がある製品もあります。
Q. StepFunctionsにて並列処理で動的並列数での実行と、その取りまとめ（すべての処理が完了したことのハンドリング）は可能なのでしょうか？
A. 可能です。2019年にリリースされた、MAPというタイプを使います。利用例です。
https://www.yamamanx.com/aws-multi-account-resource/
Q. 「StepFunctionsで、なんらかのイベント(SQSにキューイングされた等)が発生するまで…」で質問したものですが、StepFunctionの実行ではなく、フロー実行中のStepで待ち合わせを想定していました。
A->B->Cとあって、BはSQSにキューイングされたことをもって、動作する（それまでこのStepFunctionはA実行後に待機）ような形ができるかどうかなのですが。
A. 可能です。Step FunctionsのActivityという機能を使うことで、特定のアクションが発生するまで待たせることができます。
Q. セキュリティが担保され、官公庁も金融も使い始めている現在において、AWSに向いていないシステム、AWSでは要件を満たせないシステムは、どのようなものがあるのでしょうか？
A. 物理的な要件が強い場合（特定の物理回線やハードウェア要件など）には向いていないものがあると考えられます。
Q. Lambdaの処理上の制約（15分以外）はありますでしょうか。あと向き不向きなどあれば教えていただけないでしょうか。
A. Lambda がイベントトリガーから呼び出されて起動するまでに多少の時間が掛かります。この時間が許容できない要件であれば、EC2 やコンテナを利用することを検討します。Lambda の制限はこちらをご参照ください。 AWS Lambda の制限
Q. S3のライフサイクルポリシーを利用すれば最新のバックアップのみ標準に、最新以外のバックアップをGlacierに配置することは可能でしょうか？
A. オブジェクトのバージョニング機能と組み合わせることで実現可能です。
Q. Rounte53で向き先を変えるのか、ELBで向き先を変えるのか、どちらを使うのか改めて整理させてください。
A. リージョンレベルの障害に対応する場合は、Route 53 を利用します。AZ 単位の障害に備える場合は、ELBとマルチAZ構成を利用します。
Q. バックアップリストアとパイロットライトのコスト差は大きいでしょうか？あまり大きくないのであればやはりパイロットライトがおすすめでしょうか？
A. 常時稼働リソースがある分、パイロットライトの方がコストは発生しますが、現実的な復旧時間と復旧のシンプルさとしてパイロットライトが多くのケースに適用しやすいと考えます。
Q. リードレプリカとスナップショットの言葉の違いが理解できておりません。
A. リードレプリカはデータベースの読み込み専用の複製ですので、オンラインでデータの同期をしています。スナップショットはバックアップですので、あるタイミングのデータベースの状態を切り取って保存します。
Q. 山下さんのブログで利用している RDS はスポットインスタンスを利用しているのでしょうか。それともオンデマンドやリザーブドインスタンスとして利用しているのでしょうか。コストをどう削減しているのかが気になりました。
A. RDSのリザーブドインスタンスです。RDSにはスポットインスタンスはありません。
Q. 個人で勉強するために、とりあえずEC2など基本的に扱ったほうがいいサービスを起動したいのですが、一番安く済ませるおすすめを教えて頂けないでしょうか。
A. AWS無料利用枠(https://aws.amazon.com/jp/free/)の情報を確認していただいて、該当する条件でサービスをご利用ください。
Q. AWSのアカウントで課金が発生しているものを全て削除することとか可能ですか？
A. アカウントの解約をすればリソースは削除されますが、リソースは削除してから解約することを推奨します。
皆さま、ご受講いただきまして、誠にありがとうございました！
トレノケートのAWS認定トレーニングでは、AWS社の厳格なテクニカルスキル及びティーチングスキルチェックに合格した認定トレーナーがコースを担当します。AWS初心者向けの研修や、AWS認定資格を目指す人向けの研修をご提供し、皆様のAWS知識修得のサポートをいたします。
・トレノケートのAWS研修（AWS認定トレーニング）はこちら
▼AWS初心者の方は、AWS Cloud Practitioner Essentialsから！
座学中心の研修で、AWSを初めて学ぶ方や、営業などで提案に関わる方におすすめです。
「AWS Certified Cloud Practitioner」資格取得を目指す方の基礎知識修得にも最適です。
→ AWS Cloud Practitioner Essentials 詳細・日程はこちらから