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