birdpixyさんの助け合いフォーラム投稿一覧
一方、AI Assistantで確認したところでは、S3への接続にPrivateLinkは使用できないので
ゲートウェイ型のVPCエンドポイントの利用が必須であるとの情報が返ってきました。
AI Assistantの情報に疑問があるようでしたら、AWS公式を確認するのが一番だと思います。
https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/userguide/privatelink-interface-endpoints.html
LambdaのVPCアクセスは、インターフェース型VPCエンドポイント（PrivateLink）とは異なる機能という認識です。
VPCアクセス：
https://aws.amazon.com/jp/blogs/news/announcing-improved-vpc-networking-for-aws-lambda-functions/
Lambdaから"アクセス先"のVPCにENIを作成しています。
PrivateLink：
https://docs.aws.amazon.com/ja_jp/whitepapers/latest/aws-vpc-connectivity-options/aws-privatelink.html
"アクセス元"のVPCにENIを作成しています。
ちなみに「VPCアクセス」という用語があるかないかという質問に対しては、ないと思っています。
Lambdaのマネージメントコンソールの設定画面では「VPC」としか書かれていませんし、Lambdaの開発ガイドでは「VPC への関数のアタッチ」や「Lambda 関数に Amazon VPC 内のリソースへのアクセスを許可する」という文章で書かれているので、公式から正式な用語が提示されていません。
https://docs.aws.amazon.com/ja_jp/lambda/latest/dg/configuration-vpc.html
公式ガイドやマネージメントコンソールも頻繁に更新されるので、用語がいつの間にか変わってたり、さらにAWS試験の日本語版は翻訳した文章なので、同じ機能のことをいっているのに別の用語になってたりするので、用語として覚えるのはあまり意味がないです。
AWS OrganizationsのSCPを用いてVPCのインターネットへの接続の拒否設定を行うことはできない認識でいます。
上記選択肢が間違いで解説に「ルートテーブルの設定によりネットワークトラフィックの制御を行うことはできますが、リージョン全体のアクセス制御を行うことはできません。したがって、誤りです。
」とあります。
リージョン全体のアクセス制御はVPCの設定でおこなっているため、解説に納得が出来ません。
VPCのアクセス制御機能には、ネットワークACLとセキュリティグループがありますが、どちらも他のリージョンへのアクセス拒否設定はできません。（基本的にIPアドレスベースの制御です）
マネージメントコンソールでキャッシュクラスターの作成画面を確認したところ、Redisでは詳細設定に「保管中の暗号化」の項目がありましたが、Memcachedにはありませんでした。（「転送中の暗号化」は両方にありました）
AWS DataSync のよくある質問
https://aws.amazon.com/jp/datasync/faqs/
Q: AWS DataSync と AWS Storage Gateway はいつ使用しますか?
A: AWS DataSync を使用して既存のデータを Amazon S3 に移行し、次に AWS Storage Gateway のファイルゲートウェイ構成を使用して、移行したデータへのアクセスを保持し、オンプレミスのファイルベースアプリケーションからの継続的な更新に使用します。
公式のユースケースに、DataSyncで一括移行したあと、Storage Gatewayで継続的な更新に使用することが書かれてあります。
Storage Gateway＝継続的な更新が必要なケースで使用するから、移行後に更新・削除が発生しないケースでは、DataSyncの方が適しているという意味で、Storage Gatewayが誤答である理由になっていると思います。
ちょっとご質問と外れてるかもしれませんが
２．元々プライマリだったDBインスタンスがスタンバイに変更
障害の発生したDBインスタンスがスタンバイに変更されるでしょうか？
障害が発生したら利用不能になるので、スタンバイにはならないのではないのかなと思いました。
元のプライマリDBインスタンスがどのような挙動をしているかの資料が見つからなかったのですが、どこかに載っていましたか？
CloudFormationとElastic BeanstalkはどちらもAWS環境を自動的に構築できるサービスですが、それぞれ下記のような特徴があります。
CloudFormation
・インフラ環境をコード化して各AWSリソースを構築する
・コードの書き換えによって、細かいカスタマイズが可能
・複数の環境をまとめて管理できる
Elastic Beanstalk
・基本的にAWSが用意したインフラ環境の中から選択する
・CloudFormationよりも容易に構築が可能な分、柔軟なカスタマイズはできない
・インフラの専門的知識を持たない人でも、AWS環境の構築が可能
設問の「この環境は企業の部署ごとに個別に用意する必要がある」ことから、WordPress環境を部署ごとにカスタマイズする要件があることが分かります。
Elastic Beanstalkは前述のとおり、AWSが容易したインフラ環境の中から選択するので、部署ごとの細かいカスタマイズしたい要件には適していません。
一方、CloudFormationでは部署全体の共通コードを作成し、部署ごとに異なる部分のみコードを書き換えるだけで対応できます。
各サービスの作成画面だけでも触ってみると理解が深まると思います。
最後のデプロイさえしなければ料金もかからないので。
このサイトの構成図が分かりやすかったです。
https://dev.classmethod.jp/articles/trasfer-for-sftp-endpoint-types-202004/#toc-10
①VPCエンドポイントとは、インターネットに晒されることなく、S3のようなVPC外のサービスとVPC内とを繋ぐサービスではなかったでしたっけ。
(VPC外の)Transfer FamilyとVPC内とを繋ぐなら理解できますが、AWSの外にいるユーザーがVPCエンドポイントに接続する、という構成がピンと来ません。
実際にはインターネットゲートウェイも必要なのでしょうか。
インターネットゲートウェイからパブリックサブネットを通って、VPCエンドポイントへ接続しているようです。
②あわせてもう1点確認させてください。
ACLがサブネットに適用されるのに対し、セキュリティグループはEC2インスタンスのような個々のリソースに適用されるのですよね。
この構成では、セキュリティグループをVPCエンドポイントに適用する、ということでしょうか。
セキュリティグループをVPCエンドポイントに適用する、で合っていると思います。
Auto ScalingヘルスチェックのELBを有効にしたときに、注意書きで
EC2 Auto Scaling は、Elastic Load Balancing によって実行されるヘルスチェックの検出と対応を開始します。予期しない終了を回避するには、まず以下でこれらのヘルスチェックの設定を確認します ロードバランサーコンソール
と出てくるので、インスタンスの終了が想定外に発生するかもしれないから、念のためELBのヘルスチェックの設定を確認させるためなのかもしれません。
障害時にAWSに切り替えるには、通常はDirect Connectでつないでいるのが一般的な構成かと思います。
たしかに、社内システムなどの切り替えはDirect Connectで繋ぐのが一般的な構成だと思います。
設問のシステムは「ある会社はオンプレミスでWebアプリケーションを運用している。」なので、Webアプリケーション＝インターネット（外部）からのアクセスがあるシステムです。
なので、今回切り替え対象となるWebアプリケーションは、社内からプライベートでアクセスされるものではなく、インターネットからパブリックにアクセスされるものなので、Direct Connectを使用しません。
EC2は起動している状態でなければならないと判断しました。
起動しっぱなしが一番切り替えが速いというのも分かるのですが、EC2の状態の選択肢は
・ALB配下のEC2インスタンスを停止状態にしておき、障害発生時に起動する
・障害発生時にAWS CloudFormationテンプレートを実行して、ALBとEC2インスタンスを作成する
しかないので、作成して停止しておく方が速いという考え方になると思います。（障害時しか使用しないのに、ずっと起動し続けるのも結構料金がかかりますし、EC2の起動は数分以内に完了するので）
インターネットからのアクセスに対して、S3がスケーラブルかどうかというとちょっと違うように思います。
この意図がよくわからないですが、S3はリクエスト数に応じて自動的にスケーリングされますよ。
https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/userguide/optimizing-performance.html
Amazon S3 は、高いリクエストレートに自動的にスケールされます。例えば、アプリケーションは、パーティショニングされた Amazon S3 プレフィックスごとに毎秒 3,500 回以上の PUT/COPY/POST/DELETE リクエストまたは 5,500 回以上の GET/HEAD リクエストを達成できます。
DataSyncエージェントはWindowsなどのOSにインストールして利用できるアプリケーションではなく、仮想マシン(VM)アプライアンスなので、エージェントをデプロイできる環境を用意できないというのは珍しくないかもしれません。
https://docs.aws.amazon.com/ja_jp/datasync/latest/userguide/agent-requirements.html
「システムへの影響が最も少ないものはどれか」の前に「可用性の高い構成に変更したいとき」があります。
可用性の高い構成に変更できる方法の中から、システムへの影響が最も少ないものを選択する必要があります。
「フロントエンドとバックエンドのEC2インスタンスをAuto Scalingグループに追加し、ELBの後ろに配置する」は、誤答解説にあるとおりデータベースの可用性についての言及がないので、そもそも「可用性の高い構成にする」という要件を満たしていません。
要件に「テスト環境は同じ構成を複数のチームごとに作成して」と書いてあります。
CloudFormationではAWS環境をコード化（テンプレート化）して各チームの環境にコピーすることが可能ですが、Elastic Beanstalkでは構築を簡略化できるとはいえテスト環境をチームごとに作成しなくてはなりません。
また、Elastic Beanstalkで構築できる環境からテスト環境独自の設定がある場合、各チームの環境にそれぞれ設定を適用していく必要があります。
「同一環境を複数作成する」という点において、CloudFormationの方が適切なアプローチということだと思います。
ユーザがVPC作成時に使用するAZの選択が出来る
あれ、そんな設定したかな？と思ってVPC作成画面を確認したのですが、AZの選択オプションがなかったです。
VPCを作成したあとの設定を見ても分からなかったのですが、どこで選択できましたか？
チームメンバーのAWSアカウントが、監査人用のアカウントのS3バケットへ、認証情報を保存できない。
これを理由に不正解にしてしまうと、例えば
「インターネット上のユーザーがアクセスできるのは、パブリックサブネットのEC2インスタンスか、プライベートサブネットのEC2インスタンスか、どちらか？」
という問題に対して、
「パブリックサブネットのEC2インスタンスのセキュリティグループが設定されていないので、どちらともアクセスできない」
という回答になってしまうと思います。
設問に全てのアクセス権限の設定を盛り込んでいるわけではないので、設定上可能であれば補完して考えなければならないです。
設問に
同社はAWSへWebアプリケーションの移行を計画しており、各WindowsサーバーをEC2 Windowsインスタンスに切り替える予定
オンプレミスのADはWebアプリケーションが動作しているWindowsサーバー群のみ管理している
とあるので、オンプレミスのAD環境すべてAWS上に移行することを要件をしていると思いました。
オンプレミスAD環境の一部を残したい要件が見当たらなかったのですが、何から「オンプレADを辞めて、AWS Directory Serviceに完全移行したら楽だね。という風にはなりませんし、不明確です。」と判断されたのでしょうか？
どのくらいで確実に合格できるかと言われたら、身も蓋もないですが全問題コンボにするのが一番じゃないかなと思います。
合格体験記の上部にその人のコンボ、ヒット、ミスの数が出ているので参考にされてはいかがでしょうか？
「Lambdaをユーザー管理のVPC内で動作させることができる」というのはどこの情報からでしょうか？
Lambda 関数は、常に Lambda サービスが所有する VPC 内で実行されます。
VPCアクセスの設定によってユーザー管理のVPCにアクセスできるのであって、ユーザー管理のVPC内で動作させることはできない認識でした。