birdpixyさんの助け合いフォーラム投稿一覧
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内で動作させることはできない認識でした。
スタックはスタックセットで定義されたAWSリソースのグループなので「複数のリージョン、複数のAWSアカウントで同一のCloudFormationスタックを作成できる」に不自然さを感じないのですが…。
スタックセットでは、1 つの CloudFormation テンプレートを使用して、複数のリージョンの AWS アカウント にスタックを作成できます。
https://dev.classmethod.jp/articles/introducing-cloudformation-stacksets/#toc-1
CloudFormation StackSetsを使うことで、1つのテンプレートから複数のAWSアカウント、リージョンに対しStackを作成することが可能です。
転送時間の計算方法自体が分からないのか、計算しても約81時間にならないのか、どちらか分からないのですが後者だと仮定しまして、
データサイズを1k = 1024byteで計算すると約81時間になりました。
ちなみに1k = 1000byteで計算すると約74時間なので、どちらにしても3，4日で転送完了します。
複数のDirect Connectロケーションを使用する → 複数のAWS Direct Connectエンドポイントに接続している
は成立しますが
複数のAWS Direct Connectエンドポイントに接続する → 複数のDirect Connectロケーションを使用している
は単一のDirect Connectロケーションで複数のDirect Connectエンドポイントに接続していることも考えられるので、成立しません。
なので「複数の回線をAWS Direct Connectエンドポイントに接続する」は単一障害点がない設計にしているとはいえないと思います。
ユーザー（IAM）ポリシーはバケットポリシーと同じくJSON形式でポリシーを記述するので、対象のIAMユーザーのIPアドレスやドメインで制限をかけることができます。
例えば、S3バケットへの書き込み権限を付与するIAMユーザーに対して、社内IPアドレスからのアクセス時のみ許可するといった感じです。
バケット「bucket-pingt」をマネジメントコンソール上で管理するためには、バケット内のオブジェクトを一覧表示させる権限（ListBucket）が必要がある、という説明では納得できないでしょうか？
おそらくポイントは「大量」に「リアルタイム性の高いデータ」を処理するというところだと思います。
Amazon Kinesis Data Streamsはリアルタイムの大量データ処理に特化したサービスであるのに対し、Amazon SNSはメッセージング＆通知機能でリアルタイム性はあるものの大量のデータ処理が得意というわけではないので、その違いかなと思いました。
AWSのサイトに
Q: ボリュームゲートウェイとは何ですか?
（中略）
保管型モードでは、プライマリデータはローカルに保存されてデータセット全体が低レイテンシーのアクセスのために使用可能となり、非同期に AWS にバックアップされます。
https://aws.amazon.com/jp/storagegateway/faqs/
とあるので、オンプレミスのデータがマスターのようです。
該当問題の解説にも
・保管型（ストアドボリューム）
すべてのデータをオンプレミスのボリュームストレージに保存し、S3に非同期でバックアップを保存します。キャッシュ型とは異なり全データへのアクセス先がオンプレミスになるので、S3へのアクセスによる遅延が発生しません。
とあるので、選択肢の書き方がおかしいですね……。
こんばんは。
私がOracle Silverに合格したのは結構前なので自身のことは覚えていないですが、合格体験記に合格した人のコンボ数やレベルいくつで合格したかが見れますよ。
合格体験記は学習方法や出題傾向も書いてあったりするので、一通り見てみることをお勧めします。
起動ボリュームはOSが起動するファイルがあるボリューム（ブートボリューム）のことです。
WindowsだとデフォルトでCドライブです。
EBSのHDDのボリュームタイプ（st1、sc1）は、EC2インスタンスのブートボリューム以外（WindowsでいうDドライブ等）であればアタッチできます。