理解確認：Migration後のRe-architecture判断

リホスト済みの業務アプリケーションについて新しいアーキテクチャを検討しています。チームは移行前の設計書だけを使い、AWS上で実際に使われている依存関係や運用上の制約を確認せずにサービス選定を始めようとしています。

最も適切な最初の対応はどれですか。

リホスト後のアプリケーションは正常稼働していますが、ローカルディスクへの状態保持、手動のOS更新、単一サーバー保守時の停止が残っています。

新しいアーキテクチャを検討するとき、この情報を最も適切に扱う方法はどれですか。

移行後のシステムでは、OSパッチ、バックアップ確認、フェイルオーバー手順、容量変更に多くの定常作業が残っています。

新しいプラットフォームを選ぶ前に行うべきことはどれですか。

既存ワークロードをAWS上で再設計します。ピーク時には手動増設が間に合わず、単一ノード障害でサービスが停止します。また、必須の商用ライブラリはx86_64のみサポートされています。

具体的なAWSプラットフォームを選ぶ前に、ターゲットアーキテクチャの条件として直接記録すべきものを3つ選択してください。

移行前の設計書では旧APIサーバーへの依存は廃止済みとされています。しかしAWS上の通信記録では、現在もそのAPIサーバーへの接続が確認されています。新しいアーキテクチャでは旧APIサーバーを廃止する予定です。

最も適切な対応はどれですか。

リホスト後のワークロードには改善したい運用・可用性上の課題があります。一方、必須の商用ライブラリが現在の実行環境に依存しており、対応版は6か月後に提供予定です。ライブラリと無関係な部分は先に変更できます。

最も適切なターゲット設計はどれですか。