Architecting on AWS for APN Partner 2020/11/18~20 QA
2020年11月18日から11月20日に開催しました、Architecting on AWS for APN Partnerにていただきましたご質問と回答の一部を掲載します。
以下は、2020年11月18日現在の情報を元に回答しております。
Q.データ転送時の方法として、SnowballとDataSyncの違いは何でしょうか？
A. DataSync はオンライン転送を行なうサービスです。Snowball は、物理的なデバイスが手元に届くので、移行元のLANに接続してデータコピーを行ないます。
Q. Lambda側でトリガーとして設定するのはDBとテーブルのみであり、CRUDのどのアクションがトリガーとなるかまではPythonなどで書く必要があるのでしょうか？（設定みてもなさそうだったので…）
A. ストリームに情報が入ればトリガーになります。ストリーム内には旧データと新データがあります。挿入すると新データに入ります。更新すると、旧データに更新前情報、新データに更新後情報が入ります。削除すると、旧データに削除前データが入ります。これをアプリケーション側で受けて処理をします。
今回は、新イメージだけが必要ですので、コード内で、record['dynamodb']['NewImage'] というコードになっています。
Q. 今更の質問となってしまい申し訳ございませんが、サーバレスシステムについてお伺いしたいです。サーバレスシステムとはEC2やRDSなどのインスタンスを利用せず、「サーバーのプロビジョニングや管理を行わないシステム」のことと認識しておりますが、合っていますでしょうか？
例）Lamdaなどのコンピューティングシステム、APIGatewayなどのアプリケーション結合システム、S3などのデータストアを利用する。
A. はい、合っています！サーバーレスアーキテクチャは、サーバー（管理）レスという意味になるので、管理・運用するサーバーがない状態です。
Q. Lambdaがサポートするプログラム言語において、例えば、Pythonの2を実行したいなど、特定のバージョンを選択することは可能でしょうか？
A. Lambda でサポートしている言語ランタイムとバージョン情報は以下のページで公開されています。
Q. Lambdaでアクセスできる情報はどこまでアクセスできるのでしょうか？
（EFSにアクセスできる、ということはRDSにもアクセス可能…？）RDSにもアクセス可能であればLambdaからアクセスできない物はあるのでしょうか？
A. RDS も利用可能です。VPCに配置して、EC2上のアプリケーション同様にコードを書きます。
Q. ラムダにおいて、環境変数や設定ファイルなど、コード実行で必要なパラメータ周りの扱いはどうなるのでしょうか。
A. Lambda の関数において環境変数が指定できます。複数の Lambda 関数で共通利用するような場合は、Systems Manager の パラメータストアや、Secrets Manager などを利用します。
Q. LambdaはElasticBeanstalkとはどのように違うのでしょうか。コードに集中という意味では、同じように感じてしまったのですが・・・。
A. Lambdaはコードを用意してイベントによって実行されます。Elastic Beanstalk はアプリケーション一式が構築されて、その実行プログラムをユーザーが用意します。
Q. ECSにおいても、EFSなどの共有サーバのような、コンテナが変わっても同一の情報にアクセスできる概念はあるのでしょうか。
A. 以前はサポートしていませんでしたが、現在は EFS をサポートしています。
Q. ECS（Fargate）を使う場合にターミナル接続（docker exec)は可能でしょうか？
見えなくなる、とはどこまで自由度がなくなるのかが気になりました。
A. こちら現状サポートしておりませんが、コンテナワークロードでは「同一の環境でしっかりテストを行う」ことや「ログを外部に全て出す」ことがベストプラクティスとされていて、コンテナに入る必要性を出来る限り減らす方が将来的にも好ましいです。Systems Manager のセッションマネージャを利用することで中に入ることは出来るようです。
Q. EC2タイプとFargateの違いですが、Fargateの場合GPUが使えないとか制限があったように思います。EC2タイプを選択するべき状況がもう少しあれば教えていただけますでしょうか？
A. ご指摘のように GPU は EC2 タイプでのみ利用可能です。それ以外にも Fargate では指定できないオプションがいくつかありますので、それらを指定したいときは EC2 タイプを利用することになります。
Q. SQSはキューにたまったリクエストを削除することはできますか？
A. マネージメントコンソール、CLIなどから個別あるいはすべて削除することができます。すべて削除するアクションはPurgeQueueです。
Q. Dead leteer queueを設定する場合は、DBのフェイルオーバー時間を想定して設定しておかないと、DBのフェイルオーバーが完了する前にDead leteer queueへ隔離されてメッセージの処理が未実行のままになるという認識でしょうか。
A. はい。合っています！
Q. 注文データのように非同期でよいものはSQSが適するのは理解できましたが、注文まで至るまでの商品検索、商品照会、などの同期処理はRDSのフェイルオーバーによるダウンタイムを避けることはできない、ということでしょうか？
A. RDS であればリードレプリカを利用することで、読み込みに対する対障害性を考慮するなどアーキテクチャとして実現できる方法はいくつか考えられます。
Q. スティッキーセッションを使わないようにして、ALBで複数のE2(Webアプリケーション)にリクエストを振り分けるようにしています。
ログは、各EC2のアプリケーションから出すようにしている場合、同じユーザーの操作ログを追うためには全てのEC2から出力されるアプリケーションログをかき集めてマージする処理が必要となりますか？
何かいい解決策等ありますか？
A. EC2 からのログを CloudWatch Logs に転送するようにして CloudWatch Logs 側で確認するようにすれば一元的に確認できます。あるいは、S3 にログを保存しておき、Amazon Athena を利用するという解決策もあります。
Q. エッジロケーションはキャッシュを配信する以外、どのような役割があるのでしょうか？
A. Amazon S3 Transfer Acceleration 機能において、ユーザーからのアップロード先として利用されます。また、Route 53 のサーバーが配置されています。エッジロケーションについての資料も御覧ください。
Q. 新しいコンテンツがS3からエッジロケーションに新しくキャッシュされたとして、別のエッジにもキャッシュが同期されていくのでしょうか？
A. エッジロケーションにリクエストが到達した段階でキャッシュがなければオリジンから取得する動作になるので、エッジキャッシュ間で同期などは行われていません。
Q. 2点確認させてください。
・エッジロケーションに保持されているキャッシュは、それぞれの個所でバラバラの内容でしょうか？
（例えば、クライアントからアクセスした際に以下のような取得になる場合がありますか）
クライアント→Aエッジ→Bエッジ→Cエッジ→オリジン
・エッジロケーションに探している情報がない場合（初回アクセス）、エッジロケーション→オリジン、オリジン→エッジロケーションと情報が流れていきますが、その場合、レイテンシーが高くなると考えてよいでしょうか？
A. クライアントからのアクセスが有った場合、ネットワーク的に近いエッジロケーションからキャッシュの取得を試みます。したがって、オリジンへのアクセスが必要になった場合はコンテンツが表示されるまでにレイテンシーが追加されます。CloudFront がエッジキャッシュを利用する動作についてのドキュメントです。（ドキュメントの中で触れられているリージョン別エッジキャッシュは、リージョンごとに用意されるキャッシュです。ここにキャッシュがあれば、オリジンまで取りに行かないです。）
Q. デフォルトで全てキャッシュを持たれて、キャッシュを持たないようにする設定が必要なのでしょうか。
A. CloudFront の設定として、TTL（生存期間）を指定してきます。デフォルト値はなく、設定が必要です。TTL を 0 にすれば、CloudFront 経由でのアクセスであってもキャッシュは残りません。
Q. CloudFrontのキャッシュはどのような判断でキャッシュから返しているのでしょうか？
同じURLでもユーザの権限により表示が異なる場合は利用できないのでしょうか？
画像だけをCloudFrontに、とも思ったのですが、画像についてもユーザの権限で表示可否を制御している場合はCloudFrontは利用できないのでしょうか？
A. CloudFront にキャッシュされたコンテンツの TTL（生存期間）が有効な場合にキャッシュが返されます。同じ URL でもユーザーによってコンテンツが変わる場合は、キャッシュされてしまうと全員が同じページを見ることになるので利用しません。ただ、ページ内でユーザーに共通の表示内容や CSS/JS など個別にキャッシュすることはあります。画像についてもユーザー毎に表示有無を変えるということであればキャッシュには向いていません。
Q. CloudFormationのテンプレート内で、SystemsManagerのRunCommandを実行するなど可能でしょうか？
A. 可能です。こちらユーザーガイドです。
Q. スタックはテンプレートみたいなもので、スタックを利用してデプロイとかをするのだと解釈していたのですが、ラボをする限り、スタック作成がデプロイや設定を実施するという認識に変わったのですが、合ってますか？
A. そのとおりです！テンプレートはYAMLで書かれたドキュメントがテンプレートで、スタックは実際に起動しているリソースの集合体です。ですので、スタックを作成する=デプロイする、であってます。
Q. CloudFormationで作成されたリソースの手動変更(ドリフト?)を、CloudWatchで拾うこともできるのでしょうか。(検知してSNS経由で通知などを想定)
A. ご参考の試してみた記事です。
Q. 逆にCloudFormationで作れないインフラストラクチャ（サービス？）はありますか？
A. CloudFormation が対応しているリソースの一覧が公開されています。
Q. RDS for MySQLなどサブネットを二つ以上指定が必要だと思います。スタンバイを作らない場合、DBは一つと思いますが、サブネットに二つ以上またがる状況というのはどのような状況かイメージがわかないので教えてください。
A. RDS では、スタンバイを利用するかによらず、2つ以上のサブネットを組み合わせたサブネットグループを指定する仕様です。スタンバイを有効にした場合は、指定されたいずれかのサブネットにMaster インスタンスが作成され、もう片方にスタンバイインスタンスが作成されます。
Q. ELBはVPCを選択して作成するので、サブネット（AZ）に存在しないという理解で正しいでしょうか？ELBにサブネット設定がありますが、これはどのサブネットに向けて通信をするか、という意味と理解しています。
A. ELB の作成時に指定しているサブネットは ELB の実体が配置されるサブネットを指定しています。ターゲットグループによって、送信を指定しています。これにより、パブリックサブネットにELBを配置し、プライベートサブネットにアプリケーションサーバを配置することが実現できています。
Q. RDSに接続するために、エンドポイント、データベース名、ID、パスワードが必要になりますが、パスワードはいずれかの管理画面から確認できるのでしょうか。確認できないのであれば、DBインスタンスの再生成が必要になるということでしょうか。
A. マスターユーザーのパスワードは確認はできませんが、変更メニューから変更可能です。
Q. ラボでAuto ScalingグループにInventory-Appをタグ付けする箇所がありますが、Cost Centerをタグ付けする場合、キーはの設定はNameではキー重複となってしまいます。何を設定すればよいのでしょうか。
A. コスト配分タグで確認するということであれば、Name ではなく別の任意の名称のタグと値を利用できます。
Q. AutoScalingは、起動テンプレートから作成されたものしか対象にできないのでしょうか？
たとえば上記のようだと、業務アプリケーションを複製して作成、スケーリングすることはできないということでしょうか？
A. 起動テンプレート、または起動設定ですが、似たような仕組みです。
業務アプリケーションをインストール、設定済のAMIを作られて、それを指定するAMIではいかがでしょうか。
Q. NATゲートウェイの課題でAZ1に障害が発生したときに通信が不可能となる、とありますがテストする方法はありますでしょうか？
A. AZに何らかの障害が発生したという想定シナリオで、NATゲートウェイを削除するぐらいかと思います。
Q. データベースのプライマリに障害が発生したときに処理を引き継げる、とありますが、それをテストする方法はありますでしょうか？
（ロードバランサーはEC2を削除してテストできましたが、こちらはなかったため）
A. Auroraには障害を挿入するクエリがありますが、ほかのRDSにはありません。
フェイルオーバーのみのテストであれば、手動再起動で可能です。
Q. EC2のナビゲーションペインが選択しているものによって英語になったり日本語になったりするのですが、こういう仕様なのでしょうか？
A. 開発しているチームはマイクロサービス化されたチームでリリースタイミングもバラバラなので統一性はありません。
Q. LAB47.[IAMインスタンスプロフィール]で[Inventory-App-Role]を選択します。
とありますが、これはどこかで作成したものでしたっけ？既存で作成されていたものですか？
そもそもインスタンスプロフィールとはなんですか？
A. ラボ開始時にCloudFormationによって作成されていたIAMロールです。
EC2インスタンスにはIAMロールを使うために、インスタンスプロフィールという要素を使っています。
ですが、これは使うときに意識していただく必要はなく、EC2用のIAMロールを作れば自動的にインスタンスプロフィールもできます。
Q. ロードバランサーの設定でアベイラビリティーゾーンを2つ選択していますが、3つ目のアベイラビリティーゾーンがないのは、当アカウント内の何かに紐づいているからでしょうか？
A. ラボ開始時にCloudFormationによって作成されているVPCで2つのAZにしかサブネットを作っていないためです。
Q. IAMロール・ポリシーを見てみたのですが、たくさんあるんですね。
これはデフォルトで提供されているものを選択する形なのでしょうか。
独自に作成されたのですか？ユーザに割り当てるのはポリシーでしたっけ？ロールとポリシーの違いと設定のポイントやコツなどがあれば教えていただけると嬉しいです。
A. IAMロールで「AWS」からはじまっているものはデフォルトで用意されているものです。
IAMポリシーは、名前の前にオレンジ色のアイコンがあるものが、AWS管理ポリシーといってAWSが管理しているポリシーです。ユーザーにアタッチするのはポリシーです。IAMロールもポリシーをアタッチします。管理者グループにはAdministratorAccessなどでもいいと思いますが、ほかの権限設定しないといけないグループには、AWS管理ポリシーを元にして、リソースやアクションを絞り込んだポリシーを作ったり、テキストにあったNotResourceでDeny拒否ポリシーを作っておくと管理しやすくなります。
Q. RDS for Oracleなどサブネットはデフォルトで二つ指定が必須と思いますが、レプリケーションのチェックを入れない場合も冗長化される(アベイラビリティゾーンをまたいで二つ作成される)という理解でよろしいですか？チェックを入れる場合との違いを教えてください。
A. Multi-AZ 配置を有効にした場合は、2つのAZに Master - StandBy で構成されます。
Single-AZ の場合には、サブネットグループに2つのAZを指定している場合でも冗長化は行われません。
Q. CloudTrailはすべてのAPIログを記録できるとのことですが、記録される内容はどの程度まで確認できますでしょうか。
（例えば、CLI等でEC2上のファイルをS3にアップロードした際に、対象のファイル名が分かるかなど）
A. S3、Lambda では、データイベントを有効にすることで細かいログを取得できます。
Q. 前にCloudTrailを設定していたら、S3の無料枠から超えそうになりました。
個人で利用するときは、特に設定しなくていいものなのでしょうか。
A. 個人のサイト運営や検証用などでは特になくても大丈夫であろうと思いますが、クリティカルなデータを扱っている場合は、個人法人の区別ではなく有効にされたほうが良いと思います。
Q. サービスにも依るかと存じますが、例えば、トラブルシューティングや問題解決に向けたフローのような自己解決に向けた手段といったものは、AWSから提供されているのでしょうか。
A. どのようなトラブルかによりますが、各種ログを確認できる仕組みが提供されています。CloudWatch Logs によるログの確認、CloudTrail による API の実行ログの確認、VPC フローログによるネットワークトラフィックのモニタリングなどです。私個人の例としては、作成した アプリケーションが AWS API を呼び出していたのですが、挙動が怪しいときがあったので CloudTrail のログを確認して実行を確認して不具合の発生を確認したことがあります。AWS の障害については、AWS Personal Health Dashboard から確認ができます。
Q. IAMロールユースケース「AWSリソースにAWSのサービスへのアクセスを提供」についてご質問です。
上記ユースケースでは、STSのAssumeRoleの操作で内部的にアクセスキーは発行されユーザはアクセスキーを意識することなく使用できるため、通常のアクセスキーを手動で発行して行う認証より安全という認識で合ってますでしょうか。
（手動では、アクセスキーの受け渡しやメモ等による流出の危険があるため？）
A. 合っています！ご指摘のように手動によるアクセスキーの受け渡しによる漏洩の可能性が高くなることがあります。AssumeRole であれば、必要なタイミングで有効期限の短いキーが発行されるためよりセキュリティ面で優れていると言えます。
Q. ちょっと講義とは離れてしまうのですが、、、
アクセスキー・シークレットアクセスキーは、流出すると誰でもアクセスできてしまうのでできるだけ発行したくないです。AWS CLIでCognito等の操作をする場合、必ずアクセスキーが必要なのでしょうか？
「認証のためにアクセスキーが必要」というエラーになるのですが、アクセスキー以外で認証する方法はないのでしょうか・・・？
(色々と調べても見つからず・・・。CLI操作するEC2にアタッチしているIAMロールにCognito操作の権限を与えていてもダメでした)
A. AWS の API を実行する際にアクセスキーとシークレットキーが必要になります。AWS CLI での操作も内部的には AWS API が呼び出されるため必要となります。
Q. Route53 で、ヘルスチェックによって画面閉塞(オンライン時間以外はメンテナンス中画面を返す)の実現はできないかと考えています。ヘルスチェックで、EC2(Webアプリが乗っているもの)が停止していたらS3上に置いている静的コンテンツ(メンテナンス中ですと表示するhtml)に誘導するやり方です。
① CloudFront → ALB → EC2 の形で経由する場合、Route53 のヘルスチェックではEC2の停止は検知できませんか？
② ヘルスチェックだとタイムラグがあるとおっしゃっていましたが、実際はどのくらいの時間タイムラグはありますか？
A. ヘルスチェックによるメンテナンスページの表示は実現可能です。あるいは、CloudFront でカスタムエラーの設定を行うことでも実現可能です。Route53 のヘルスチェックのラグについては、TTL 設定によります。
Q. ALBはリバースプロキシと捉えても間違いないでしょうか？
A. ALB はリクエストをターゲット登録されたインスタンスに振り分けるロードバランサーです。
Q. EC2の設定を誤って作ったため、終了して新しく作成しようとしました。
しかしインスタンスの状態を終了にしようとしたらYou are not authorized to perform this operation.と表示され、終了できませんでした。
今回のラボのアカウントに割り当てられているIAMグループで制限をかけているということでしょうか？
A. はい。インスタンスの停止はできますが、終了が許可されていません。モジュール7の中で権限周りの話がありますが、実際に体験できていますね。
Q. インスタンス起動後、パブリックIPが割りあたりません。どこを調べるとよいでしょうか？
A. EC2インスタンス起動時のVPCとサブネット選択画面で、パブリックIPアドレス設定が有効になっていなかったと考えられます。この設定は、17の手順によって、PublicSubnetのオプションを選択すればデフォルトで有効になるようになっています。
Q. ルートテーブルの設定方法について、「接続先」の欄と「ターゲット」の欄は何を指しているんでしょうか。例を挙げながらご説明いただけると大変助かります。
A. 接続先は、接続先のIPアドレス範囲です。
ターゲットはそのIPアドレスとの通信で使うゲートウェイです。例えばユーザーデータの「wget https://github.com/~~」でEC2からダウンロードリクエストを実行しているgithub.comのIPアドレスは、13.114.40.48 です。これは、10.0.0.0/16ではなく、0.0.0.0/0の範囲に該当します。
ルートテーブルでは、そのリクエスト通信はインターネットゲートウェイへ行け、と書いてあるので、インターネットへリクエストが送信されるとなっています。
Q. VPCピアリング接続を使う場面というのは、他で既に構築済みのVPC内にあるDBにアクセスしたい場合などでしょうか？新規構築の場合は、パブリック・プライベートサブネットで分割するのでピアリング接続をする必要はないですよね？(それとも、新規構築時のこういう場合はピアリング接続すべき というものがあれば教えていただきたいです。)
A. 例えば今回のDBが複数の異なるアプリケーションから共通で使用するDBの場合、DB用のVPCに分けて、各アプリケーションからピア接続をします。そうすれば各アプリケーションとDBは接続できて、各アプリケーション同士は接続させない、という構成を作ることができます。
Q. VPCピアリング接続は、属しているサブネットがパブリック・プライベートに関わらずできてしまうという認識で合っていますか？別AWSアカウントのVPCにも接続できるとのことで、何か攻撃されそうに見えるのですが、そういうことはないのでしょうか？(承認しなければ大丈夫なので問題ないのかもしれませんが・・・)
A. VPCピアリングはVPCとVPCを接続してプライベートネットワークでの通信ができるようにします。ですので、インターネットゲートウェイは通っていません。
よって、仰っておられるとおり、プライベートサブネットとの通信も可能になります。他アカウントも可能ですが、承諾しない限りは通信できないので安全です。
Q. 今回の演習で利用するEC2のインスタンスはt2.microではなく、t3.microを利用する手順になっておりますが、t2.microではいけない理由はあるのでしょうか？
A. ありませんが、無料利用枠を使いたいなど特別な理由がない限りは最新世代のインスタンスを使用したほうがパフォーマンス、コストに優れていますのでおすすめです。
Q. セキュリティグループについてです。(パブリックサブネットでIGW等の設定済の想定)
VPCのデフォルトセキュリティグループ：インターネットからのインバウンド通信を許可していない。
VPC内のインスタンスにアタッチしたセキュリティグループ：インターネットからのインバウンド通信XXを許可
の状態でも、上記インスタンスはインターネットからのインバウンド通信は可能でしょうか？
A. 可能です。まずアタッチしているセキュリティグループのみが有効です。
デフォルトのセキュリティグループは、あるだけで、自動アタッチはされません。
そして、デフォルトも仮にアタッチされていたとしても、セキュリティグループは許可の合計(or)になります。
Q. デフォルトで作成されているインターネットゲートウェイは何者ですか？
A. デフォルトVPCにアタッチされているインターネットゲートウェイです。
デフォルトVPCは、検証目的のVPCです。
Q. セキュリティグループで許可・ネットワークACLで不許可とした経路があった場合、ENIを通り、サブネットでブロックされる認識で合ってますでしょうか。
A. 合っています！ネットワークACL はサブネットの境界で評価されます。
Q. ENI に紐付けられている、IPアドレスの情報込で複数の EC2 インスタンス間で付け替えることができます。
付け替えられるのはENIの機能のことかと思いますが、移動とは具体的に何を指すのでしょうか？
例を交えて説明していただけると大変助かります。
A. 付け替える。ということを移動できると説明しています。A という EC2 インスタンスの ENI を B という EC2 インスタンスに付け替えをした場合、ENI に設定されている IP アドレスが A から B に移動します。
Q. ①インスタンスが障害→②別インスタンスを起動→③ElaticIPを関連付ける流れは今のデモで理解できましたが、すでに動作しているインスタンスで③を行うとどうなるのでしょうか。関連付けに失敗すると思ってますが、、、(IPが重複するので)
A. Elastic IP を複数のインスタンスに関連付けることはできませんのでエラーになります。再関連付け を許可している場合は、別のインスタンスに関連付けを変更することができます（以前に関連付けられていたインスタンスからは自動でEIPが外れます）
Q. RDSにオブジェクトブラウザなどのツールでアクセスしたい場合、以下のどちらかの設定になるのでしょうか？
・パブリックネットワークに所属させる
・プライベートネットワークに所属させ、踏み台サーバ等を用意し、そこからの接続のみ可能とするようなセキュリティ設定を行う
A. セキュリティの優秀性で考えた場合、プライベートサブネットに配置することが望ましいです。
Q. Elastic Network Interfaceが理解できません。「EC2インスタンスを間で移動」とありますが、移動とは何を示すのでしょうか？
A. ENI に紐付けられている、IPアドレスの情報込で複数の EC2 インスタンス間で付け替えることができます。
Q. 現状NATインスタンスを選択する利点はありますか？
（利用料金もNATゲートウェイとそこまで変わらないのであれば、NATインスタンスは全く選択肢に入らないと感じました。）
A. 特殊な理由がない場合は、NATゲートウェイの利用が良いですが、NATゲートウェイとNATインスタンスの比較表がありますので、要件的に NATインスタンスが必要になるのかを確認できます。
Q. パブリックサブネットなのに、VPCの中にある、という概念図が腑に落ちませんでした。
VPCの中でプライベートサブネットはわかるのですが...
昨日のラボで選択したパブリックサブネットもVPCの中なのでしょうか？
A. はい。全てのサブネットは VPC 内に作成されます。プライベート、パブリックは機能的な違いがあるわけではなく、どちらも同じく VPC の CIDR を小さく分割したネットワークセグメントです。インターネットゲートウェイへのルートが存在するルートテーブルが割り当てられているサブネットをパブリックサブネットと呼称します。
Q. VPCとインターネットゲートウェイは1：1
パブリックサブネットとインターネットゲートウェイは多：1
という認識で合っていますか？
A. 合っています！インターネットゲートウェイへのルートが存在するサブネットをパブリックサブネットと呼称します。したがって、必要なサブネットのルートテーブルに IGW へのルートを設定できます。
Q. ルートテーブルは物理世界のルーターと同じ意味と理解しておりますが、その場合ルートテーブルの機能にファイアウォールを見立てることができると思います。そうするとセキュリティグループ（ファイアウォール）との役割の違いなどが混乱してくるのでこのあとの説明で補っていただけますと助かります。（おそらくセキュリティグループはリソース単位の小さい世界でのファイアウォールであり、ルートテーブルは主にサブネット単位でのファイアウォールを実装可能と理解しています。）
A. このあと解説がありますが、ルートテーブルは、ご質問にあるように物理的なルーターに近い機能を提供しますが、あくまでもルーティングに特化しています。セキュリティグループは、EC2 インスタンスの手前に配置するファイアーウォールです。サブネット間のファイアーウォールとしては、ネットワークACLがあります。
Q. VPCの設定(CIDR等）は構築後、不足したとなってから修正不可能なものなのでしょうか。
A. 構築済みの VPC の CIDR は変更できません。既存の VPC に新しい CIDR を追加することはできますが、CIDR を重複させる事はできません。
Q. セキュリティグループを複数選択する場合は、ルールに関してはANDでしょうか？ORでしょうか？（たぶんORだと予想しますが…。）
A. ORです。どれかで許可されていれば通過します。
Q. 確認ですが、ラボで使っていたSystems Managerは、アプリケーションの設定値を管理する用途で使っていたのでしょうか？
A. はい。あっております。EC2インスタンスローカルに情報や状態もたさないことが使い捨てをしやすくするベストプラクティスです。
Q. DMSを利用する場合、費用は何に対してかかるのでしょうか？
データ量でしょうか？
A. DMS の料金は起動するインスタンスとストレージサイズによります。
Q. ソリューションアーキテクトの出題傾向の中には、『顧客でこういったサービスを提供したい。AWSのどんなDBサービスを使うのが良いか？』というようなものもあるのでしょうか？
A. あります。SAA(ソリューションアーキテクトアソシエイトの略です)では、お客様要件に対して最も適切な選択肢を選んでいただくことができるかが判定されますので、DBサービスを選択することももちろんあります。
Q. EFSはNFSのAWS版という理解で合っていますでしょうか？
A. はい。NFSファイルシステムを利用者が管理することなく利用できるようにAWSが提供しているサービスです。
Q. EC2インスタンスは、自動起動/自動停止の設定ができるのでしょうか。一日のある時間だけ起動しておきたい場合などを想定しています。
A. 明日ご紹介するSystems Managerと組み合わせると、コードを書かなくても実現できるケースもあります。
Q. Dedicatedで専有するメリットはなんでしょう？企業のルールの為ですか？
A. はい。ご指摘のように企業内のルールや要件によってシングルテナント（他のAWSアカウントと共存NG）が指定されている場合や、ソフトウェアライセンスの都合でホストを固定したい場合に利用します。
Q. リザーブドインスタンスで1年買った場合、3か月ごとにサーバーを削除→新規構築して、1年で計4台（同時稼働はなしで直列）みたいな使い方は可能なのでしょうか？
A. はい。特定のインスタンスについての購入方法ではないので、3ヶ月毎に作成されるインスタンスが購入済みのリザーブドインスタンスの条件にマッチすれば自動で割引されます。
インスタンスタイプの互換性ですが、P3 (GUI)以外は互換性があると思っていいでしょうか？A. インスタンスタイプの互換性については、こちらのドキュメントで確認できます。
Q. S3バケットのタブにアクセスポイントとありますが、AmazonS3アクセスポイントとは何か教えていただけませんか。
A. バケットポリシーをシンプルにするために、バケットに別のエンドポイントを作って、そのエンドポイント用のバケットポリシーを設定できます。
Q. S3暗号化のCSE-KMSとCSE-Cの使い分けですが、AWSに鍵管理を委ねて運用を楽にしたいかどうかの視点だけでしょうか？（または鍵は自社でセキュアに管理したくないからCSE-KMSが不可などの理由もあると思いますが。）CSE-KMSの方が運用面でもっとメリットあったりする場合は教えてください。（SSE-KMSとの組み合わせでメリット出るなど）
A. おっしゃるっとおり鍵管理の運用が楽になります。キーサーバーなどのハードウェアをもたなくてすみます。お客様が守る対象を減らせるというメリットがあります。
KMSのマスターキーはキーポリシーで制御できますので、AWS上で構築しているアプリケーションとの統合も簡単です。
Q. S3作成時に『パブリックアクセスをすべてブロック』をチェックオフしたが、アクションから公開を選択しないと公開されない、という動きだが、これはACLを設定しなくてもパブリックアクセスならOKとする場合の設定でしょうか？
A. パブリックアクセスブロックは「パブリック設定にすることをブロックする」です。
アクション-公開 = ACLでパブリックを設定した、です。
ですので、ACLでパブリック設定を可能にするために、最初にブロックを外しています。
Q. オブジェクトアクションに、[非公開にする] が見当たらないのですが、非公開にしたい場合はどのように操作すればよいのでしょうか？
A. オブジェクトごとのアクセス権限の設定で、パブリック設定を外せば非公開にできます。
Q. S3内のオブジェクトが公開されているかどうか、コンソール上で一覧などで確認することは可能ですか？
A. 現在は、オブジェクトの一覧で公開状態は確認できません。オブジェクトの詳細画面上では公開状態を「アクセスコントロールリスト (ACL)」で確認できます。
Q. オブジェクトの上書きアップロードをした際に既存のACLを引き継ぐことは可能でしょうか？
A. アップロード画面の「追加のアップロードオプション」で、パブリックを選択すると、引き継ぐというより、公開設定をアップロード時に行うことが可能です。
Q. Transfer Accelerationはデフォルト無効ですが、有効にしたほうがメリットがありますが、デメリットはありますでしょうか（料金がかかる？）
A. ご指摘の通り、追加コストが掛かる点がトレードオフです。
Q. S3はオブジェクトレベルのストレージであるのに、データ分析のためのストアとして利用できるというイメージが良くわかりませんでした。
APIなどを利用し、保存したファイル・データの内容を読み取り、分析可能ということでしょうか？
A. S3 は容量無制限で保存できるため、分析用のデータを大量に保存しておく用途に向いています。
分析自体は AWS の他のサービスや独自に構築したシステムで行ないますが、ご質問にあるように分析システム側でデータ取得元として利用します。
Q. クライアントサイドで暗号化が必要になる場合の、要件（例）を示してほしいです。サーバサイドではなく、クライアントサイドを使用する場合がどのような場合かわかりませんでした。
A. コンプライアンスやガバナンス要件で指定されている場合です。
Q. S3バージョニング機能を使った場合、過去〇世代まで残す という使い方をしたい場合は、ライフサイクルポリシーを設定して自動削除するという運用でしょうか？また、自動削除したものを復旧するAPIは用意されていますか？
A. 削除済みの復元に関しては、バージョニング有効で削除されたものは解説のあったように削除マーカーオブジェクトを削除することで復元できますが、完全に削除されたものは復元できません。
Q. S3のバージョニングで管理されているファイルは使用容量（コスト）としてカウントされますでしょうか？
A. 全てのバージョンのオブジェクトが課金対象となります。
Q. バージョニングを有効にしておくデメリットなどはありますか？
A. 古いバージョンを含め、保存されたオブジェクト全て含めてコストが発生します。完全性とコストのトレードオフで必要な場合に有効にします。
Q. リージョン毎にS3エンドポイントが異なると聞いたことがありますが、間違いですか？
A. はい。リージョン名が含まれるリージョン毎のエンドポイントもありますが、含まれないエンドポイントも存在します。
Q. 構築図などでサービスのアイコンなどをよく見かけますが、ダウンロードで取得可能でしょうか？
A. こちらから可能です。
Q. エッジロケーションはどこにあるか公開されていますか？
A. 具体的な地理的な位置は公開されていませんが、どの地域にいくつ存在するかについては公開されています。
ご受講、たくさんのご質問ありがとうございました！
トレノケートのAWS研修（AWS認定トレーニング）
トレノケートのAWS認定トレーニングでは、AWS社の厳格なテクニカルスキル及びティーチングスキルチェックに合格した認定トレーナーがコースを担当します。AWS初心者向けの研修や、AWS認定資格を目指す人向けの研修をご提供し、皆様のAWS知識修得のサポートをいたします。
・トレノケートのAWS研修（AWS認定トレーニング）はこちら
▼AWS初心者の方は、
AWS Cloud Practitioner Essentials から！
座学中心の研修で、AWSを初めて学ぶ方や、営業などで提案に関わる方におすすめです。
「AWS Certified Cloud Practitioner」資格取得を目指す方の基礎知識修得にも最適です。
→ 詳細・日程はこちらから
▼実践スキルを磨くなら、AWS Technical Essentials で ！
実機演習が中心の研修です。仕事で構築作業を行う方や、シナリオベースの演習を通じて、実際に手を動かしながら各サービスの特徴を学びたい方におすすめのAWS研修です。
→ 詳細・日程はこちらから
いきなりの有償コースに抵抗がある方やまずはお試しをしてみたい方は、トレノケートが実施している無料セミナーがおすすめです。詳細はセミナーページよりご確認ください。
▼無料セミナーの詳細はこちらから
合わせて読みたいAWS関連記事
