2020年9月16日から9月18日に開催しました、Architecting on AWS for APN Partnerにていただきましたご質問と回答の一部を掲載します。
以下は、2020年9月18日現在の情報を元に回答しております。
Q. (デモや事例で)ダイナモDBをよく使っているイメージですが、特に気に入っているポイントは何ですか？
A. 弊社のコースのマスタや最新状態、みなさんのご質問など、データに制約があまりない、シンプルなデータモデルが扱える要件で利用しています。
Q. 自身の知らないAWSサービスを使うときはまずAWSのサービス設定を全部みて、理解しますか？
使いながらだと結局非効率な使い方になってしまうのかなぁと思ってます
A. AWSが用意しているチュートリアルがある場合は、それをやっています。あわせてユーザーガイドを読みます。BlackBeltの動画を見ることもあります。
Q. SNSから直接Lambdaを呼ばずにSQSを挟むメリットは何でしょうか？
A. リトライがやりやすくなります。今回のように処理先のAPIがリクエスト拒否となっている間もメッセージはSQSに残りますので、API復旧後に処理することが可能です。
Q. GlobalAccelaratorは、「複数のエンドポイントグループを作成し、送信元のユーザから最もレイテンシーの低いエンドポイントへルーティングする」という理解で合っていますでしょうか。
A. あっております。そのうちのヘルシーなエンドポイントにルーティングします。
Q. Lambdaのログはどこで確認ができるのでしょうか？
A. CloudWatch Logsで確認できます。
Q. Cloudwatchを設定しませんでしたが、S3のイベント・Lambdaのイベントを設定すると裏でcloudwatchが動くという理解でいいでしょうか。
A. S3 のイベントによりLambdaを実行しています。Lambda の実行ログは、設定をしなくても CloudWatch Logs に書き込まれます。
Q. Pythonでlambdaを書いて様々なサービスと連携したい場合、覚えておいたほうがいいAWS固有のパッケージとかありますか？
A. AWS の Python SDK Boto 3 を利用します。
Q. Lambda内でローカルファイル /tmp/inventory.txt を作成していますが、複数のlambdaが同時に動いた場合でも問題ないのでしょうか
A. 起動された Lambda のインスタンスそれぞれに実行環境が用意されるため、同じファイルへ複数のLambda実行環境からの同時アクセスは発生しません。
Q. AWSの場合はロールフォワードの考え方はないのでしょうか?
A. 特定の時点に戻したい、という要件でしたら、RDS、DynamoDBにポイントタイムリカバリ機能があります。
Q. LambdaとECSの特徴が、つかめていないです。あるCloudWatchのイベントで起動されるバッチ処理を構築する場合、判断に必要な要件があれば教えてください。
A. Lambdaで実現可能な場合はLambdaを使うことで運用がシンプルになります。
15分以上必要、モジュール総容量が大きいなどLambdaの制限にかかる場合はコンテナを検討します。
Q. レイヤーとLambdaの関係がいまいちわかりませんでした。
A. 各 Lambda 関数で利用したい共通の処理がある場合、Lambbda レイヤーに置いておくことで各 Lambda にモジュールとして組み込む必要がなくなるので、管理の煩雑さから開放されます。
一般的なプログラムにおいて共有ライブラリ、共通モジュールとして開発されるのと同じイメージです。
Q. SQSとLamdaの連携の仕方を教えてください
LamdaのAPIが何らかのメッセージをSQSに流すのですか？
A. Lambda のトリガーとして、SQSのキューを指定するだけで、内部的にポーリングして必要に応じてLambda関数が実行されます。処理成功時のメッセージ削除も自動化されます。
Q. かなり以前のことですが、Lambdaがアンロードされてしまうと次の実行の際に時間がかかるという事象があり、対策として定期的に実行させていました。現在は解消されているのでしょうか
A. 同時実行数のプロビジョニングができるようになりました。
Q. Lambdaは実行すると料金発生とのことですが、開発はローカルで実施したほうがコスト削減に感じますが実際はどうなのでしょうか？
A. ローカルで開発をおこない、実機試験のときにLambdaで実行する。という運用をおこないます。ですので、ハンドラ関数以外から実行された際にテストイベントを渡すようにコーディングすることがあります。
Q. Lambdaが関数でA・B・Cのリソースに何か処理を実行する場合、LambdaにA・B・Cリソースへの処理に応じた操作権限（IAMロール）を与える必要があるという認識で正しいでしょうか？
A. はい。あっております。
Q. AWSの場合は、設計書、環境定義書などはどのような形になるのでしょうか?
A. 決まったものはありませんが、AWSアイコンを使ったイメージでコミュニケーションすることが多くあります。
CloudFormationスタックとして作成された環境の正確な情報として、CloudFormationテンプレートが使われることもあります。
Q. Lambdaレイヤーのイメージがわかりません。もう少しかみ砕いて教えていただけますか。
A. 一般的なプログラムにおいて共有ライブラリ、共通モジュールとして開発されるのと同じイメージです。
Q. AWS Fargateがイメージできませんでした。
A. AWS Fargate は、コンテナを実行する EC2 インスタンスの運用管理をAWSに任せるマネージドサービスです。
Q. 基本的で申し訳ないですが、コンテナの概念が理解しきれていません。
AMIイメージの小規模版（サービスやMWやその設定、パラメータレベル？）といったイメージでしょうか？
インスタンスを上げて、コンテナを置くだけで同設計のサービスが作れるイメージでしょうか。
A. 一つの例で言うと、仮想サーバーはOSを含むサーバー。コンテナは、OSを含まないプロセス。です。
仮想サーバーでは、Webサーバ＋アプリケーション・サーバー＋データベース・サーバーなど必要なサーバーを必要なだけ組み込めますが、コンテナでは、それぞれのサーバーをコンテナという単位で用意します。参考情報です。
Q. EC2上に展開したコンテナに対してセキュリティグループなどAWSのサービスを適用できますか?
A. セキュリティグループ、IAMロールなど適用できます。
Q. コンシューマーの処理時間によって、メッセージの処理完了の順番が守られないことになりますか？
A. ありえます。
Q. ポーリングで30秒待つ時、29秒あたりで新規メッセージが発生したら、その時に処理されるのでしょうか？それとも次回の処理になりますか？
A. ロングポーリングの最大は20秒ですが、ロングポーリングで待機中にメッセージが到着すればそのメッセージを取得します。
Q. ECSが使っているEC2もマネージメントコンソールから見えるのでしょうか？
A. はい。EC2タイプの場合は確認できます。Fargateタイプの場合は確認できません。
Q. Docker=ECSというわけではないのでしょうか？いまいちECSのイメージがつかめませんでした。
A. Docker は、コンテナを実行するソフトウェアです。AWS 特有のものではありません。
ECSは、Docker のサーバーを実行する EC2 インスタンスのクラスタ管理や、ELBターゲットやIAMロールの設定などを行なうサービスです。
Q. SNSでの疎結合化とSQSでの疎結合化での差はあるのでしょうか？
A. SQS は、メッセージとコンシューマーが1対1の関係です。非同期な疎結合を実現します。
SNS は、メッセージとサブスクライバーが1対多の関係です。並列的な疎結合を実現します。
Q. メッセージをキューに戻す、というのはどこで判断するんですか？Comsumerから完了した通知を受け取れなかったら等を作りこむのでしょうか？
A. 可視性タイムアウトでは、メッセージ自体は削除されず見えなくなります。従って、可視性タイムアウトを超えたメッセージは、コンシューマーから見える状態になります
Q. FIFOキューで障害となるメッセージがある場合、デッドレターキューに移動するまで次のキューは処理されないのでしょうか?
A. メッセージを受信する順番が守られるというだけで、処理順番が守られるというわけではありません。
Q. 「ロングポーリングによって、低コストで取り出せる」がなぜ低コストになるのかが分からないため、教えていただきたいです。
A. SQSの料金はリクエスト数に応じます。受信メッセージ数がゼロでも1回のリクエストです。ショートポーリングで受信メッセージがゼロのリクエストを何度も発生させるとそれだけ無駄なコストが発生します。
Q. AWS Direct Connectは物理的な専用線、仮想的な専用線の2つのパターンがあるという理解であっていますか？
A. 物理的な専用線の中にVIF(仮想インターフェース)を作成して利用します。
Q. Elasticache を使うのがよいのか、DBのキャッシュを使うのがよいのか? どのように判断しますか?
A. DBのキャッシュは、DBサーバーへのリクエストが発生しDBサーバーのリソースを結果的に利用しています。DBサーバーの手前に ElastiCache を配置することで、DBサーバーへのリクエスト自体を行わないようにできます。
Q. ElasticCacheを使えば、スティッキーセッションを使う必要がないというところをもう少し詳しく聞きたいです。
A. スティッキーセッション機能は、ELB の背後にある EC2 サーバーの接続先を固定する機能です。
EC2 サーバー内にセッション情報を保持している場合、2回目以降のリクエストが別のEC2サーバーに接続されるとセッション情報を取得できずに再度ログインを求められたりします。これを防ぐために、前回の接続先と同じEC2サーバーへの接続を行なうために利用します。
ElastiCache や DynamoDB にセッション情報を保持している場合、どのEC2のアプリケーション・サーバーからもセッション情報を ElastiCache や DynamoDB から取得することができるため、任意のEC2インスタンスに接続しても問題が起きないようにできます。
Q. CloudFrontに登録するドメイン名は、Route53で購入して登録する必要がありますか。
A. いいえ、外部で購入、ドメイン管理している場合でも利用可能です。
Q. DBをElasticCacheのみにするのはナンセンスですか？
A. Redis であれば、そのような構成もありえます。
Q. キャッシュのサイズはいくつになるのでしょうか? ソース(S3/DB)と同じサイズですか?
A. キャッシュされるオブジェクトのサイズということで回答いたします。
オリジナルのコンテンツと同じサイズです。
Q. CloudFrontを利用するとEC2を小さくできるというのは、アクセス数を減らせるからスペックを下げられるという理解でよろしいでしょうか。
A. はい。オリジンサーバーへのリクエストが減るのでスペックを下げられる可能性があります。
Q. グローバルではないコンテンツ配信の場合、CloudFront以外の選択肢があるのでしょうか？
A. 国内での利用という場合でも、キャッシュの配信にはCloudFront を利用するメリットは考えられます。
Q. オンプレでCloudFrontを使うメリットがわかりませんでした。
通常の通信でも同じようなキャッシュの仕組みがあると思うのですが、切り替える理由は何でしょうか？
A. オンプレミスでも、よりユーザーに近い場所でキャッシュ配信し、レイテンシーを抑えられるメリットがあります。
Q. CloudFroutを使用した方が金額が安くなるというのは、何度もリクエストされるコンテンツをキャッシュしておくことで、インスタンスがデータ転送する量が減るからでしょうか。
A. オリジンサーバーへのリクエストが減ることで、サーバーの負荷を軽減できる可能性がある。ということです。
Q. Webアプリケーションの場合、通常のリクエストはELBに向け、画像など静的コンテンツだけはCDNにする等を行うことはないのでしょうか？
キャッシュしたいコンテンツが少しでもあればアプリへのアクセス前段にCloudFrontを立てるのがベストプラクティスになるのでしょうか？
A. ウェブアプリケーションの手前にCloudFrontをTTL0で配置する場合のメリットとして、エッジロケーションを経由で通信が行われるために遅延が少なくなる。ことが考えられます。ドメインを統一でき管理をシンプルにするメリットもあります。
Q. 静的なコンテンツを更新するときは毎回手動でS3にアップロードしているのでしょうか？
A. 山下の例では、WordPress のプラグインとして、画像のアップロードをS3 に行なうプラグインを利用して自動化しています。
Q. CloudFrontでAWS WAFが設定できるとのことですが、AWS WAFのサービスに移動すれば細かいWAFの設定ができるのでしょうか？
A. はい。AWS WAF 側で設定した構成を CloudFront で利用しています。
Q. ELBを使っていない場合はoriginにEC2を指定するという理解であっていますか？
A. EC2 の公開DNS名を利用してオリジン指定できます。
Q. CloudFrontのキャッシュヒット率やアクセス数などを確認する方法はありますか。
A. リクエスト数は、CloudWatch のメトリクスとして取得できます。
ヒット率は、CloudFront のダッシュボードから確認できます。
ELB へのリクエスト数とCloudFront のリクエストを比較表示しておくとヒット状況を確認することもできます。
Q. TTLの単位は何ですか？日？時？秒？
A. TTL は秒数で指定します。
Q. OriginをS3とELBに設定するのはなぜですか
A. 画像は、S3 から配信することがベストプラクティスになるので利用しています。
静的コンテンツ以外は、ELB 以下の構成で対応しています。
Q. タグの最大数は50個だったかと思いますが、1契約あたりになるのでしょうか。
A. リソース単位です。
Q. キーと値のタグの有用性についてピンと来てません。簡単にご教示願います
A. タグを利用することで、人とシステムが識別するための目印として利用できます。具体的な利用方法としては、EC2 インスタンスの一覧の Name を利用して EC2 インスタンスがなんのサーバーかを判断することや、Systems Manager など EC2 インスタンスを指定するサービスなどでタグをもとに抽出することがあります。
Q. CloudFormationの出力は内部的にDynamoDBなどに管理されているのでしょうか。他のAWSリソースから活用したり参照したりできるのでしょうか。
A. CloudFormation の Outputs セクションを利用して、別のスタックで利用することができます。
Q. labにはありませんでしたが、conditionsを使用した設定はどのように行うのでしょうか？
A. AWS のドキュメントにサンプルがありますのでご確認ください
Q. CloudFormationとは手動で各リソースを設定していたものをテキストファイルに記載し、それを読み込ませることで自動で生成することが出来るようになるツールである、という認識で正しいでしょうか？
A. はい。バッチリあっております！
Q. ElasticBeanstalkでアプリをデプロイするとマネージメントコンソール上から実際に使われているEC2やELB等を確認、変更することは出来るのでしょうか？
A. ElasticBeanstalk で起動されたリソースは、マネージメントコンソール上で確認できます。
Q. スタックの更新は、更新先が起動中でも強制的に更新できてしまうのですか？
A. はい。状況によらず更新されますので、変更セットで事前確認しましょう。
Q. NATゲートウェイにElasticIPアドレスは必須ですか？
また、ElasticIPはグローバルIPアドレスという認識で正しいでしょうか？
A. はい。あっております！
Q. AutoScalingの機能はAWSを使用する上で一般的に使われる機能なのでしょうか？
A. ベストプラクティスを実現するために一般的に利用されます。
Q. プライベートサブネットにあるサービスは、NATゲートウェイを通って外部へアクセスする認識でよいでしょうか。
パブリックサブネットが無い環境の場合、インターネットゲートウェイは不要という認識でよろしいでしょうか。
A. プライベートサブネットに配置された EC2 インスタンスは、パブリックサブネットに配置された NAT ゲートウェイを経由して、インターネットゲートウェイからインターネットに出ていきます。従って、EC2 インスタンスがインターネットに出る必要がある場合は、NAT ゲートウェイを配置するパブリックサブネットと、インターネットゲートウェイは必要です。
Q. DynamoDBで複数のTBLを持たしていて、1つの（本日更新用など）TBLのみオンデマンドにして、他のTBLはプロビジョンドでWCU/RCUを設定するという自動運用を取ることができますか
A. テーブルごとに設定することはできます。自動運用される場合であれば、SDK などで仕組みを用意して実現できます。
Q. DBをマルチAZのMaster（主）/Standby（従）の構成で、何かしらが原因でフェイルオーバーが発生したとします。
Masterが障害から復旧した場合、Masterは自動的に主系になりますか。手動で主系に戻すことになりますか。
A. 自動的に主系にはなりません。マスターが復旧したから戻す。という要件は稀な要件と考えられますが、データベースの再起動時にフェイルオーバーをさせることができます。
Q. データによってはシャーディングできないデータもあると思います。(品目マスタなど)
そのようなデータはどうすれば良いのでしょうか。
A. ひとつの例ですが、マスター情報は専用の共通データベースにしておき、他のデータについてシャーディングするような考え方があります。
Q. Aurora ServerレスはAuroraRDSを作成するときのオプションですか？
A. はい。Aurora をデータベースエンジンとして選択したときに選択できます。
Q. アプリケーションからRDSアクセスする際、マスターかリードレプリカを意識する必要がありますでしょうか。
A. マスターとリードレプリカで接続先エンドポイントが別になるのでアプリケーション側で意識する必要があります。
複数のリードレプリカを利用する場合は、それぞれのリードレプリカでエンドポイントが違います。
Q. ALBにグローバルIPが付与されず、エンドポイント名でアクセスできるのはどういった仕組みでしょうか？
A. ALB にも グローバルIPアドレスは付与されていますが、IPアドレスが固定ではないため、実際に利用する場合は、DNS名にアクセスする必要があります。
グローバルIPを固定したい要件がある場合には、NLB を利用します。
Q. 構成図でELBはVPC上にありますが、パブリックゲートウェイに跨っているイメージであっていますでしょうか。
A. ご指摘の通り、ELB は VPC 内のサービスです。ELB を作成する際に選択した複数のAZに内に実態が配置されます。
Q. AZ同志は物理的にある程度距離が離れているのでしょうか。
単一障害点を避けるためにリージョンを分けたシステム構成にするのは過剰でしょうか。
A. 物理的に距離が離れたエリアに構築されています。公式ドキュメントでは、「各 AZ はそれぞれ他の AZ から物理的に意味のある距離、つまり数キロメートル離れていますが、すべて 100 km 以内 (互いに 60 マイル) に配置されています。」
Q. インターネットGWはインターネットへの口を作る、VPCエンドポイントは特定のサービスへのみ口を作る、という差別化の考えで良いですか？
A. はい。バッチリです！
Q. ELBとアプリケーションロードバランサの違いを簡単に教えて頂けますでしょうか。
A. ELB は Elastic Load Balancing というサービス名です。ELB のサービスの一つのタイプとして、ALB Application Load Balancer があります。
Q. IAMユーザは「一つのAWSアカウントに複数設定できる」という理解で合っていますでしょうか。
A. はい。5000ユーザー作成できます。
Q. VPCピア接続の場合はサブネットに関連付けたルートテーブルに、Transit Gatewayの場合はVPCに関連付けたルートテーブルに設定するという理解であっていますか。
A. はい。厳密にはVPCのサブネットに作成したTransitGateway アタッチメントに関連付けたルートテーブルで設定をします。
Q. AutoScalingで増加したEC2に対して、CloudWatchLogsの設定を自動的に行えるのでしょうか
A. オートスケーリングで起動するインスタンスの AMI として、事前に CloudWatchAgent の設定などをすませんた AMI を利用します。
Q. Auto Scalingで、例えば最低4台数指定した場合、2つのAZがある場合、均等に2台ずつEC2が立ち上がるのでしょうか？
A. スケールアウト、スケールインともに 複数AZに均等配置を行います
Q. シンプルスケーリングは縮小きっかけは何ですか？手動ですか？拡張はアラームきっかけですが戻りのトリガーが知りたいです。
A. 同じく、時間ベースまたはCloudWatch アラームがきっかけです。オートスケーリングアクションとして追加するか削除するかを設定します。
Q. AWSで複数アカウントを作成する際は、AWS Organizationsを使用して作成するのがよろしいのでしょうか。
A. はい。組織メンバーとしてアカウントを作成する場合は、Organizationsから作成したほうが簡単です。
Q. カスタムメトリクスはクラウドウォッチエージェントをインストールしなければ取得できないのでしょうか？
A. PutMetricData API を利用するアプリケーションを作ることで CloudWatch Agent を利用しなくてもカスタムメトリクスを送信できます。
Q. CostExplorerなどで、事前に一定額以上の課金が起こりそうなときに教えてくれる機能はありますか？
A. 請求アラームをCloudWatch設定できます。設定するときは、リージョンをバージニア北部を選択します。
Q. CloudTrail、CloudWatchLogsを構成図に表示する場合、リージョン内に表示するのでしょうか。
リージョン外でしょうか。
A. リージョン内に配置します。
Q. CloudTrailはS3以外の出力先は指定できないのでしょうか？
A. はい。CloudTrail のログ出力先はS3のみです
Q. EC2がS3に接続する要件が無かったシステムでも、CloudWatchLogsを使用することになった場合は、EC2がS3に接続できるようにルートテーブルやゲートウェイエンドポイントの設定が必要になるという認識でよろしいでしょうか。
A. CloudWatch Logs を利用するにあたっては S3 の権限やゲートウェイは不要です。CloudWatch Logs のエクスポート先としてS3 が利用可能です。
EC2 インスタンス側には、CloudWatch Logs への書き込み権限を IAM ポリシーで与えることや、必要に応じてVPCエンドポイントを用意します。
Q. 昨日の研修の確認になりますが、AWSのCPUの「バースト」という概念はT2やT3等のTファミリーのみの概念でしょうか？
A. はい。あっております！
Q. Access Key IDのみ漏えいする場合はどういったリスクがあるでしょうか。（Secret Access Keyとセットで漏れなければ大丈夫とかでしょうか。）
A. Secret Access Keyをゼロからアタックするのは難しいので、Access Key だけの漏洩であればリスクは低いと考えます。
Q. Organizationsを使用して子アカウントを作った場合それぞれのアカウントに紐づくリソースはVPCピア接続とかを利用しない限りは干渉しないのでしょうか
A. AWS Organizations で管理しているアカウント同士であっても、透過的に他のアカウントのリソースを使えたり通信できることはありません
Q. AWSを導入する際に、導入時の管理者が退職をすることを考慮してrootユーザーの運用を設計する必要があると思います。
退職を考慮したベストプラクティスはありますか？
A. root ユーザーの登録メールアドレスを個人アドレスにしないことや、認証情報の引き継ぎなどが考えられます。個人とアカウントを紐付けない運用を推奨します。
Q. 中小企業ですとアカウントは1つのイメージがありますが、大企業ではアカウントはいくつぐらい保有しているのでしょうか？目安でよいので知りたいです
A. 中小企業に置いても複数の AWS アカウントを利用している事例はあります。100以上保有していることもあります。
Q. ルートアカウントとして既に存在しているアカウントをOrganizationに追加したりすることは出来るのでしょうか？
A. 可能です。どこにも所属していない AWS アカウントを AWS Organizations のメンバーに加えることができます。
Q. IDプールにIAMロールを紐付けなくても、アプリケーションをホストするEC2にIAMロールを紐付ければアクセス制限ができるのではないでしょうか。IDプールの意味は、認証されたユーザーごとにアクセス権を帰る場合でしょうか？
A. EC2 インスタンスに割り当てた IAM ロールはサーバーサイドのプログラムでは利用できますが、クライアント側では利用できません。
クライアント側から直接S3やDynamoDBにアクセスする場合などは、Cognito を利用してIAMロールを引き受けさせます。
Q. ARNとは何でしょうか？
A. ARN は Amazon Resource Name の略です。AWS のリソース参照する場合に利用される名前です
Q. STSとAssumeRoleがうまく理解できず、もう一度教えていただけないでしょうか。
A. Security Token Service は、一時的な認証情報を提供するサービスです。AssumeRoleは、STSが提供する API です。ロールの引き受けを要求します。
Q. 信頼関係とロールに設定するポリシーの関係性がいまいちわからないです。
A. 信頼関係は、ロールを利用可能な人やサービスを指定します。
ポリシーは、ロールを引き受けた人やサービスができる権限を設定します。
Q. IAMのポリシーで拒否も許可もされていないリソースについてはどのように扱われるのでしょうか(拒否されるのでしょうか？)
A. 明示的に許可されていないものは、拒否されます。暗黙的拒否と呼ばれます。
Q. KMSとIAMの違いを教えてください。
A. KMS は Key Management Service の略で暗号化・復号化の鍵を管理するサービスです。
IAM は Identity and Access Management service の略で認証と認可を管理するサービスです。
Q. ユーザーとグループのポリシーはどっちが優先ですか？
A. すべてのポリシーが合算されて適用されます。その中で拒否が最優先されます。例えばユーザーにアタッチしているポリシーで許可していても、グループにアタッチしているポリシーで拒否していれば拒否が優先されます。
Q. IAMユーザが自分に付与されたポリシーを書き換えてしまったらアクセス拒否していたものでも許可になってしまうのでしょうか？ポリシーの書き換えの制限もあるのでしょうか？
A. ポリシーの変更が許可されている場合は変更できます。ポリシーの書き換えを許可したくない場合は、Denyに記述するか、Allow から外します。
Q. IAMの権限設定を行う場合は、必ずコードを記載するという事になるのでしょうか。
画面から操作はできないという認識でよろしいでしょうか。
A. 管理コンソールからGUIで作成することもできます。結果的に作成されるものはJSONです。
Q. アカウント間でIAMユーザを共有することはできるのでしょうか？
A. アカウント間でIAMユーザーは共有できません。IAMロールを使ってクロスアカウントアクセスを設定することはできます。
Q. アクセスキーの使用は非推奨と説明されていましたが、CLIを使うときは必ずアクセスキーを使うと思います。
毎日のバッチ処理を行う場合はアクセスキーを発行せざるえないとですが、ベストプラクティスはあるのでしょうか。
A. バッチ処理をするサーバーをEC2インスタンスで構築し、IAMロールを割り当てることで、ユーザーから発行したアクセスキー情報を使わなくてもよくなります。
Q. 同一VPC内のサブネットに別のルートテーブルを付与した場合には、設定にかかわらずそのサブネット間は通信出来なくなるんでしょうか？
A. いいえ。同一VPC内ではローカルターゲットのルートがありますので通信可能です。
Q. 1つのVPC内でパブリック、プライベートのサブネットを作成するとき2つのサブネットでCIDRが重複するとどのような問題があるのでしょうか。
A. CIDRは重複できません。作成時にエラーになります。
Q. インターネットゲートウェイのアタッチ先のVPCはインターネットゲートウェイの画面で確認できますが、VPCにアタッチされているインターネットゲートウェイをVPCの画面では確認できないのでしょうか？
A. はい。マネジメントコンソールでは現在その機能はありません。左下のフィードバックから機能リクエストしていただけると追加されるかもしれません。
Q. 初歩的な質問になりますが、AレコードとCNAMEがよくわかりませんでした。お時間あれば補足説明お願いできないでしょうか。
A. Aレコードは、ドメイン名に対するIPアドレスを指定します。
CNAMEは、ドメイン名に対して別のドメイン名を指定します。
Q. Route53とはAWSから提供されるDNSサーバ、という理解でよいでしょうか？
A. はい。あっております！厳密にはサーバーではなくサービスです。
Q. Route53をユーザが使用するケースのイメージが湧かないです。どのようなシステムを作る際に使用することがあるのでしょうか？
A. Route53 は DNSサービスです。例えば、弊社コーポレートサイト(www.trainocate.co.jp)をインターネットに公開する場合に使用します。
Q. Route53 の53の意味がありましたら、教えてください。
A. DNSが利用するデフォルトポート番号が53番であることが由来です。
Q. ウェブ層からアプリケーション層へのELBの役割がわかりませんでした。
A. パブリックサブネットに配置されたサーバー（ウェブサーバーなど）とプライベートサブネットに配置されたサーバー（アプリケーション・サーバーなど）の関係を蜜にしないためにELBを経由するように配置します。蜜にしない疎結合化により、高可用性を確保します。
具体例としては、ELB経由にすることで、ウェブサーバー、アプリケーション・サーバーそれぞれ独自にスケールアウトさせることができます。
Q. パブリックIPをもたないELBはサブネットに所属しないのでしょうか。所属しない場合、プライベート通信ではなく内部的にパブリック通信をするのでしょうか。
A. 内部向けのELBについても、プライベートサブネットに関連付けます。
Q. Connection Draining でコネクションが残っていたとしても5分経過したらインスタンスがシャットダウンされるのでしょうか?
A. はい。タイムアウトに到達した時点でELBから切り離されます。
Connection Draining では、ELB からインスタンスを切り離すだけなのでシャットダウンは行いません。Auto Scaling を利用することで自動でシャットダウンするようにできます。
Q. VPCエンドポイントはセキュリティ要件がなければ無理に使わなくてもよいでしょうか？
A. はい。要件に合わせて利用を検討します。
Q. 1対1の接続であればピア接続、複数のVPC間を接続する場合はTransitGWを利用することが推奨（ピア接続でもできるが設定や管理が煩雑）という意味合いなのでしょうか。
A. そのご理解で問題ありません。
もちろん、複数の接続でもピア接続は利用できますが、数が多くなってきたときに管理が煩雑になるため、Transit Gateway を利用することで管理をシンプルにしていけます。
Q. ルートテーブルはVPCへの適用ですか？サブネットへの適用ですか？
A. ルートテーブルはサブネットに対して関連付けます。
Q. 異なるアカウントのVPC間の場合、どちらに料金が発生しますか
A. VPCピア接続自体には料金は発生しませんがデータ転送に関して、転送元のコストが発生する通信ケースがあります。
Q. ピア接続、というのは特別な言葉ですか？VPC同士の接続＝ピア接続ですか？
A. 英語では、Peering と表現されているものを日本語でピア接続と約しています。ネットワーク同士を繋ぐことを総じて Peering / ピア接続と呼んでいます。
Q. メタデータアクセスの件、追加質問です。メタデータへのアクセスはVPC内接続なので可能とのことですが、アクセスは基本APIだからインターネット接続という機能の話ではなかったでしょうか。
A. メタデータはAWSのAPIアクセスではありませんので、インターネットへのアクセスは必要ありません。リンクローカルアドレスへのEC2からのみのアクセスです。
Q. IAMロールは設定しなくてもインスタンスを作成できると思いますが、どのような場合に設定が必要でしょうか？
必要性はなく、オプション的な認識で問題ないでしょうか。
A. はい。オプションです。EC2上のアプリケーションに、AWSサービスへの認証を適用したいときに利用します。
Q. RDS作成時に選択するテンプレートの違いが知りたいです
A. 本番稼働用はマルチAZになりスタンバイデータベースが作成されます。
開発/テストはシングルインスタンスになります。
開発/テストではダウンタイムが発生してもいいのでコストを下げたいためです。
無料利用枠はアカウントを作成して最初の1年無料で利用できる設定がデフォルト設定になります。
Q. プライベートサブネットのインスタンスにもEIPをつけられますか？
A. プライベートサブネット内のインスタンスに対しても EIP をアタッチできますが、インターネットからアクセスができないので設定する意味がありません。
Q. 起動時にパブリックIPはどういったルールで割当られるのでしょうか？
A. AWS が保有する IPアドレスの中から利用可能なものが割り当てられます。割当のルールを設定することはできません。
Q. ACLの設定ですがL3のみでしょうか？L2の設定(主にICMP)は可能でしょうか？
A. ICMPなどについても設定可能です
Q. ネットワークACLのユースケースを教えて下さい。(セキュリティグループで十分な気がしました。)
A. 多くの場合セキュリティグループで要件を満たせる場合が多いですが、より厳密な要件がある場合やセキュリティ上厳密な制御を必要とする場合にネットワークACLを利用します。
Q. 初期設定ではセキュリティグループ、NACLどちらが適用されている状態になるのでしょうか。
A. 初期状態では、ネットワークACL ですべての通信が許可されていますが、セキュリティグループによりすべての通信が拒否されています。
Q. セキュリティグループはElastic Network Interface関連付けられると伺いましたが、VPC外にあるS3には関連付けられないということでしょうか？
A. はい。S3 には付けられません。
Q. ルートテーブルはサブネットに対して、セキュリティグループはEC2とかに対してのインバウンド、アウトバンドルール設定する認識で合ってますか？
A. はい。厳密には、ルートテーブルは通信経路を定義しています。セキュリティグループは、ファイアーウォールとして通信の制御を行います。
Q. IDを指定するメリット「EC2が増えたときRDS側の設定変更不要」というのは「既存のEC2と同じセキュリティーグループ内にEC2が増えたとき」ということであっていますでしょうか？
A. はい。厳密に解説をすると、セキュリティグループという枠の中にEC2インスタンスを所属させるわけではなく、複数のEC2インスタンスに対して同じセキュリティグループを割り当てます。
Q. セキュリティグループは何に対して設定を行うものなのでしょうか？
A. EC２ インスタンスや RDS インスタンスへの通信に対するファイアーウォールとして設定します。
Q. Elastic IP アドレスの説明で「AWSリージョンあたり5つ利用可能」とありますが、
5個以上使用したい場合、EIPも上限緩和申請を行うのでしょうか
A. はい。上限緩和申請が必要です。
Q. S3はVPCの外側という認識でよろしかったでしょうか。
Private VPCからS3の内容を参照する場合、NAT GWにルートテーブルを作ってS3へのルーティングを設定するイメージでしょうか。
A. はい。プライベートサブネットから S3 をはじめとする AWS の API を呼び出すためには NAT ゲートウェイを必要とします。後に説明するVPCエンドポイントを利用することもできます。
Q. VPCを分ける理由は何になるんでしょうか？(広いレンジのIPをVPCで取ってサブネットを何個も作ることとの違い)
A. プロジェクト単位やサービス単位など分離させたほうが良いものを分けて利用します。
VPCのIPレンジは、なるべく広く取っておっことを推奨します。理由としては、レンジをあとから変更することができないためです。
別のレンジを追加することはできます。
Q. 署名付きURLは、そのURLを知っている人であれば、有効期間中はだれでもダウンロードできるのでしょうか？
A. はい。そうです。ですので、URLを他の人に漏らさないようにお伝えいただく必要があります。
Q. Webサーバーの代わりにS3を使用して静的コンテンツを公開する場合、アクセスログはどのようにして取得するのでしょうか。
A. オブジェクトのアクセスログが取得できます。バケットのプロパティで設定できます。
Q. セキュリティグループのインバウンドルール、アウトバウンドプールの設定をテキスト等に一括ダウンロードする事は可能でしょうか?
A. CLIのdescribe-security-groupsで出力するなどの方法が考えられます。
Q. AWSとオンプレとサーバ間で通信する場合、セキュリティグループ等の設定で考慮する事はありますか?
A. オンプレミスかどうかは関係なく、必要最小限のポートと送信元(アウトバウンドの場合は送信先)だけを許可するようにします。
Q. S3の「パブリックアクセスブロック」と「公開設定オフ」の違いを再確認したいです。。
どちらも「外部からの見えないようにする設定」ですが、「外部から見えないようにしている方法が異なる」という理解で問題ないでしょうか。
「パブリックアクセスブロック」→公開したものに対してきたアクセスを拒否する、「公開設定オフ」→そもそも公開していない
A. 「公開設定にする」ことをブロックするのがパブリックアクセスブロックです。誤って公開設定されることを二重で防いでいます。
Q. リザーブドインスタンスとSavings Plansの違いは何でしょうか。
A. 割引率の違いはありますが、SavingsPlansは柔軟に扱えます。
EC2 SavingsPlansでは、ファミリーとコミット金額を決めます。
インスタンスサイズは決めません。
Compute SavingsPlansはコミット金額を決めてEC2A. FargateA. Lambdaと3つのサービスをまたがって適用できます。
Q. Auroraではなく、MySQL・Postgreを選択するユースケースはありますか？
A. 利用したいバージョンが Aurora では提供されていない場合や、小規模なデータベースの場合は、Aurora ではなく RDS MySQL や PostgreSQL を選択することがあります。
Q. RDSの場合の、OracleやSQL Serverのライセンス料金はRDSの課金に含まれますか? また、RDSで、MySQLや Oracleのエラーが発生した場合問い合わせはAWS経由で、Oracle社、MS社へ問い合わせとなりますか?
A. RDSの利用料金にOracleA. SQLServer のライセンス料を含みます。
Oracle、SQLServer の問い合わせはAWS経由です。MySQLは、Community Edition なので、問い合わせはサポートされていません。
Q. AmazonEBSはEC2とは別のサービスとして用意されているものなのでしょうか？
容量に応じて課金がある別のサービスと捉えるのが正しいのでしょうか？それともEC2サービスの一部として付帯されるものですか？
A. ご理解のとおりEC2とは別のサービスです。課金も確保したストレージサイズに応じて課金されます。
EC2インスタンスを削除してもEBSボリュームを残しておくことができます。
Q. FSx for LustreとFSxの違いは何なのでしょうか？
A. 電子テキスト内で FSx と表記されているものは、FSx for Windows サービスを表しています。これは、Windows で利用する共有ストレージサービスです。
FSx for Lustre は HPC 向け共有ストレージサービスです。
Q. ハードウェア専有インスタントと専有ホストの違いは前者は利用するハードウェアが選択できないが、後者は選択できるというくらいで、どちらもハードウェアは自分のアカウントで専有していると理解しましたが、あっていますでしょうか？
A. 大きな違いはそれで正しいです。細かい違いについては以下の URL を御覧ください。
Q. オンデマンドと比較し、専有オプションを使用するメリットはなんですか？
※物理的に分離されている安心感がメリットでしょうか？
A. 「他社とホストを共有しない」といったコンプライアンス、ガバナンス要件、ライセンス要件がある場合に利用します
Q. リザーブドインスタンスは複数アカウントで共有できるということですが、単一アカウントで複数のEC2インスタンスを使用した場合は、EC2インスタンスの起動時間の合計が適用されるといううことでいいでしょうか？
A. 単一アカウントでも複数のEC2インスタンスの合算で計算できます
Q. リザーブドインスタンスで毎月支払うというのは、一部前払いのことでしょうか。
A. 一部前払い、または前払いしない場合です。
Q. リザーブドインスタンスは同一リージョンの複数インスタンスに対して使える権利、という認識であっていますか？
A. 同一リージョンの同じインスタンスファミリー、OSに適用できます。
Q. リザーブドインスタンスの開始と終了での単価が異なる場合は開始の単価で金額計算される認識でよいでしょうか。段階的な支払の場合も開始の単価になる？
A. はい。購入時の料金が適用されます。
Q. リザーブドインスタンスを1年や3年購入し予想より短い期間しか使わなくなってしまった場合で、月払いにしていても1年や3年分の料金を払わないといけないのでしょうか？
A. 利用したかどうかによらず支払いが必要です。基準を満たせばリザーブドインスタンスマーケットプレイスで販売することも可能です
Q. リザーブドインスタンスで「1年間/前払い」を行ったとします。
2年目も「1年間/前払い」を行うことは可能でしょうか。
A. 2年目以降についても改めて1年/前払いを新たに購入します。
Q. t2、t3は何で差別化して使いますか？
A. AWS アカウント作成後1年間は t2.micro インスタンスが無料利用枠で使えるので敢えて使うことがあります。それ以外はAZにもよりますがT3を使います。
Q. CPUクレジットには上限があるという認識でいいですか？
A. はい。インスタンスタイプ別の上限はドキュメントをご確認ください。
Q. ベースラインはどこで確認できますか。
A. インスタンスタイプごとのベースラインは、ドキュメントをご確認ください。
Q. クライアントサイド暗号化というのは、S3に送付する前に暗号化することを指しているという理解で正しいでしょうか？
A. はい。送信時に暗号化しておかないといけない要件で使用します。
Q. アーティファクトサービスとは、技術ナレッジがあるイメージですか？
A. 認証レポートを確認できるサービスです。
技術ナレッジとしては、Builder's Library や builders.flash があります。
Q. 金融機関や政府機関が使用する際のセキュリティガイドライン対応状況はどこかで確認できますでしょうか。
A. 資料によっては、AWS 管理コンソールにログイン後に AWS Artifact から入手できるものがあります。
Q. 次ごとのアクセス量などで変動はあると思いますが、山下さんの個人ブログのサイトでAWS月額利用料金はいくらくらいになるのでしょうか？
A. 8月で$60ぐらいでした。
最近のアーキテクチャはこちらです。
Q. S3で静的ページを表示する構成で、AWS WAFを使用たい場合、S3の前段は必ず
CloudFrontになるという認識でよろしいでしょうか。
A. はい。ご認識のとおりです。
Q. 静的コンテンツ(S3関連)について理解が深まりました。
AWS設計を進めていくときに、アーキテクチャや非機能要件、料金などをまとめて構成案を作成していく必要があると思うのですが、設計・見積もりサポートツールやフォームなどあったりしますか?
A. AWS料金計算ツールがあります。
Q. 特定のファイル/フォルダのみバージョン管理したい場合でもバケット単位でしかバージョニングの有効/無効を切り替えられない、で合っていますでしょうか。ファイル/フォルダ単位での切替は他に手段はないのでしょうか。
A. はい。バージョニングの有効化はバケット単位です。ライフサイクルポリシーで、特定のパスのオブジェクトは過去のバージョンを1日で削除、というコントロールは可能です。
Q. バケットを作る際に「パブリックアクセスをすべてブロック」をオフにしても、
オブジェクトをアップするごとに「公開」をしなければならないのですか？
「パブリックアクセスをすべてブロック」をオフにした意味がよくわかりませんでした。
A. 「パブリックアクセスブロック」は公開設定にする操作そのものをブロックします。
今回のケースではオフにしておかないと、公開設定がブロックされてしまいます。
Q. S3はアーカイブデータには向いていない理由としては、ストレージクラスとしてGlacierのようなアーカイブ機能が存在するから、ということですか？
A. はい。長期保存が目的で取り出す頻度はさほど多くない。といったアーカイブ目的には S3 Glacier が適しています。
Q. Transfer AccelerationはS3の設定項目の1つなのでしょうか？
A. S3のバケット単位で設定します。
Q. S3 Transfer Accelerationは、例えば世界中のクライアントからのアップロードを日本のS3に集めいたい場合、クライアントとしてはエッジロケーションまでアップロードすれば良い機能という理解で正しいでしょうか。無償でしょうか。
A. はい。ばっちりです。
Q. 静的ページの保存とバックアップの保存を同一のS3で保存する場合、静的ページのみアクセス可能とすることは可能でしょうか。
A. オブジェクト単位でアクセス制御できます
Q. バケットのバージョンですが、復元できるのはv何まででしょうか？（もしくは全世代分でしょうか？）
A. 保存されているいずれのバージョンでも復元可能です。
Q. バージョニングで最新、1世代前、2世代前の3つのデータ（全て同じデータ容量と仮定）があると、最新×3のデータ量が課金対象という理解で正しいでしょうか。
A. はい。あっております。
Q. S3でバージョニングされており、削除する場合は削除ポイントができるのは理解しました。バージョニングされた状態で物理的に削除されるタイミングはあるのでしょうか。
A. あります。バージョンIDを指定して削除する場合は、削除マーカーを作らず削除されます。
Q. AWS認定試験を受けるにあたってできるだけ多くの問題を解いてから本試験に臨みたいです。どのような方法がありますか?
A. 正確性は保障できませんが、より多くの参考書の問題を見られてみるのでいかがでしょうか。
Q. 質問フォームがS3とCloudFrontの組み合わせと伺ったのですが、リアルタイムに反映されているのはなぜでしょうか
A. 送信ボタンを押下するまでの処理はクライアントサイドJavaScriptです。これはブラウザにダウンロードされて実行されています。
送信ボタンを押した後の処理は、APIにリクエストされて、サーバーレスアーキテクチャで実装しています。
3日目に詳しく解説します。
こちらのブログでも解説しています。
Q. リージョンとアベイラビリティゾーンの関係は何でしょうか？
A. アベイラビリティゾーンは、複数のデータセンターで構成されるデータセンターのクラスターです。リージョンは、2つ以上のアベイラビリティーゾーンで構成されます。
Q. 何故「アンマネージドサービス」を使うとコストが上がるのでしょうか？コストが上がるから「アンマネージドサービス」と呼んでいるのでしょうか？
A. 例えば、EC2 で自前で Web API を提供すると考えた場合、リクエストがいつ来るかわからないために EC2 サーバーを常時起動しておく必要があります。EC2 は、起動している時間単位で課金されるため、待受状態のみでも課金対象です。マネージドサービスを利用することで、最適化されたサービス利用料金が請求されるのでコストの最適化につながります。
Q. オンプレでは「リプレースまでの5年間でこれ位リソースを使用する見込みだから、これ位のスペック、ディスク容量が必要」といった提案をしてます。
AWSでは、現況で必要なスペック・容量で構成し、運用フェーズで定期的なリソース見直しをしていくのがベターという考え方で良いのでしょうか。
A. ご認識のとおりです。オンプレミスのように計画にそってすべてを決めてしまうのではなく、定期的な見直しと、見直しのもととなるモニタリングを行っていきます。
Q. オンデマンドのキャパシティ課金もありますが、固定キャパシティの課金の方がリーズナブルだったと思います。そういった意味で、予測は必要かと思っています。
A. ありがとうございます。言葉の定義の話になってしまうかもしれませんが、メリットの話での「予測」は「(人の)予測」です。
例えばリザーブドインスタンスで1年分購入、SavingsPlansで1年分のコミットなどをされる場合は、観測(モニタリング)した実測値に基づく、もしくは機械学習モデルを利用した推論結果に対して購入されます。
不確実な人の予測が必要なくなることをメリットととらえてください。
ご受講、たくさんのご質問ありがとうございました！
トレノケートのAWS認定トレーニングでは、AWS社の厳格なテクニカルスキル及びティーチングスキルチェックに合格した認定トレーナーがコースを担当します。AWS初心者向けの研修や、AWS認定資格を目指す人向けの研修をご提供し、皆様のAWS知識修得のサポートをいたします。
・トレノケートのAWS研修（AWS認定トレーニング）はこちら
▼AWS初心者の方は、 AWS Cloud Practitioner Essentials から！
座学中心の研修で、AWSを初めて学ぶ方や、営業などで提案に関わる方におすすめです。
「AWS Certified Cloud Practitioner」資格取得を目指す方の基礎知識修得にも最適です。
→ 詳細・日程はこちらから
▼実践スキルを磨くなら、AWS Technical Essentials で ！
実機演習が中心の研修です。仕事で構築作業を行う方や、シナリオベースの演習を通じて、実際に手を動かしながら各サービスの特徴を学びたい方におすすめのAWS研修です。
→ 詳細・日程はこちらから
いきなりの有償コースに抵抗がある方やまずはお試しをしてみたい方は、トレノケートが実施している無料セミナーがおすすめです。詳細はセミナーページよりご確認ください。
▼無料セミナーの詳細はこちらから