AWS SOAレベル無料練習問題②

第1問: オンプレミスのバックアップをブロックストレージ対応でAWSに拡張する方法

あるAI研究企業は、オンプレミスのサーバーでアプリケーションを動かしており、これらのデータをAWS上にバックアップしたいと考えています。しかしアプリケーションのバックアップソフトウェアはPOSIX互換のブロックストレージにしか書き込みができません。バックアップ先としてのストレージは、オンプレミス側からブロックデバイスのように認識され、かつオフサイトとしてAWSへ安全に保存される必要があります。どのソリューションが最も適しているでしょうか？

正解: 2. AWS Storage Gatewayを使用し、ゲートウェイ保存ボリュームを活用してオンプレミスのローカルにデータを置きつつクラウドへバックアップする

ゲートウェイ保存ボリューム（Stored Volumes）は、オンプレミス側にフルデータを保持しながら、バックアップを自動的にAWS側へ転送する仕組みです。ブロックデバイスとして認識されるため、POSIX互換のバックアップソフトウェアがローカルディスクと同様に扱うことができます。データはオンプレミスに常にフルコピーが保管されるので、アプリケーションの要件（ローカルでデータ利用可能）にも合致します。

他の選択肢

Amazon S3を直接ターゲットにする場合、ブロックストレージとしては認識されないためPOSIX互換要件を満たしません。
Amazon S3 Glacierも同様にオブジェクトストレージであり、ブロックデバイスとして扱えないため要件を満たせません。
ゲートウェイキャッシュボリュームはオンプレミスには一部のキャッシュが保持されるだけで、フルコピーはクラウド上にあり、常時ローカルデータを利用できる要件を満たしません。

第2問: IAMポリシーの使用状況とサービス上限を把握する方法

ある医療系スタートアップは、さまざまなワークロードや実験用に多くのIAMポリシーを作成しており、セキュリティチームがポリシー数の増加を懸念しています。セキュリティチームは、現在利用中のIAMポリシー数と、AWSで許可される最大ポリシー数との比較を報告するようSysOps管理者に依頼しました。どのAWSサービスを利用すれば、このような情報を可視化し報告できるでしょうか？

正解: 3. AWS Trusted Advisorを使用し、IAMポリシーの使用状況と上限に関するレポートを参照する

AWS Trusted Advisorは、セキュリティ・コスト最適化・パフォーマンスなどの観点からAWSアカウントのベストプラクティスをチェックします。その中にService Limitsチェックが含まれ、IAMポリシーを含むさまざまなAWSサービスの使用量と現在の上限を把握できます。これにより、IAMポリシー数が限界に近づいていないかを簡単に確認して報告できます。

他の選択肢

Amazon InspectorはEC2インスタンスの脆弱性やネットワークセキュリティに関する評価に焦点を当てており、IAMポリシーの数や上限は直接確認できません。
AWS ConfigではIAMポリシーの変更履歴などを記録できますが、サービス上限の可視化やレポートを行う機能はありません。
AWS Organizationsは複数アカウントの一元管理やSCPを扱うためのサービスであり、IAMポリシーの数や上限をリソースレベルで直接可視化する用途には向きません。

第3問: Lambda関数のCPU集約型タスクによるパフォーマンス低下を解決する

あるオンラインゲーム分析企業では、Amazon S3上のログを処理するためにAWS Lambda関数を使用しています。ログ解析の一部で複雑なCPU集約型演算を実行しているため、Lambda関数の処理が遅く、全体のシステムスループットを低下させています。Lambdaの実行速度を向上させたい場合、SysOps管理者はどのような措置を取るべきでしょうか？

正解: 4. Lambda関数のメモリ割り当てを増やし、結果的にCPUリソースを拡大させる

AWS Lambdaはメモリ割り当て量を増やすと比例してCPUリソースも増加する仕組みを持っています。CPU集約型の処理を行っている場合、メモリサイズを拡大することでCPUリソースも増え、処理時間の短縮に有効です。これはLambdaの特性として、設定したメモリ容量に応じてCPUやネットワーク帯域がスケーリングされるためです。

他の選択肢

暗号化をオフにする：Lambdaのデフォルト暗号化はフローに大きなCPU負荷をかけるわけではなく、主なボトルネック解消にはならない可能性が高いです。
ハイパースレッディングを有効にする：Lambdaはハイパースレッディングを個別に設定できません。メモリ割り当て増加によるCPU拡大が正しいアプローチです。
カスタムレイヤーにコードを格納する：コード配置だけではCPUリソース不足を解決できず、根本的な高速化にはならないケースが多いです。

第4問: マルチスケジュールのバックアップ保持要件を満たす最適な方法

ある動画制作会社のSysOps管理者は、Amazon EC2インスタンスとAmazon RDSデータベースのバックアップを一元管理したいと考えています。バックアップには次の保存要件があります。『日時バックアップは保存期間7日、週次バックアップは保存期間5週間、月次バックアップは保存期間12か月、年次バックアップは保存期間6年間。』管理工数を最小限に抑えて、これらのさまざまな期間のバックアップを自動で取得・保存するには、どの方法が最適でしょうか？

正解: 4. AWS Backupを使用して、EC2とRDSの両方に対して必要なスケジュールと保存期間を設定するバックアッププランを作成する

AWS Backupでは、EC2インスタンス（EBSスナップショット）やRDSインスタンスなど複数のリソースタイプのバックアップを一元管理できます。一つのバックアッププランの中で複数のスケジュール（毎日、毎週、毎月、毎年など）と保持期間を指定し、必要なリソースをタグまたはARNで紐付ければ、自動取得と保存が行われるため管理工数が最小化されます。

他の選択肢

Lambda関数とEventBridgeルールを用いてスクリプトでバックアップを取得する方法は細かい制御ができますが、バックアップの状態管理・保管期間の制御などをすべてカスタム実装する必要があり、保守が複雑です。
Amazon S3への直接バックアップ（EC2インスタンスのデータなど）は一般的でなく、RDSデータをS3へバックアップするにはDMSなどが必要で、要件のスケジュール管理が追加で必要です。
Data Lifecycle ManagerはEBSボリュームスナップショットには最適ですが、RDSには対応していないため、本要件を一括で管理できません。

第5問: SQS StandardキューからFIFOキューへ移行する際に必要な手順

ある決済処理企業は、Amazon SQSのStandardキューを使ってメッセージをやり取りしていましたが、メッセージ順序と重複排除をより厳密に管理するため、FIFOキューへの移行を検討しています。現在のアプリケーションは、メッセージ本文が一意であることを前提に標準キューへ送信しています。FIFOキューを導入するにあたり、移行時に必要となる作業として最も適切な手順はどれでしょうか？

正解: 3. 新たにFIFOキューを作成し、コンテンツベース重複排除を有効化してメッセージグループIDをアプリケーションで設定する

SQS StandardキューからFIFOキューへは直接タイプを変換できないため、新たにFIFOキューを作成する必要があります。FIFOキューで順序と重複排除を保証するためには、最低限メッセージグループIDを指定し、かつコンテンツベース重複排除を有効化するか、もしくは重複排除IDを付与する必要があります。コンテンツベース重複排除を有効化すると、同一のメッセージ本文を一定期間内に送信しても重複扱いとして排除できます。アプリケーション側でメッセージグループIDを適切に設定し、FIFOの特性を利用します。

他の選択肢

既存のStandardキューをFIFOに変更する仕組みは提供されておらず、新しくFIFOキューを作り直す必要があります。
DelaySecondsを設定する方法はFIFOキュー固有の要件ではなく、順序や重複排除には関与しません。
重複排除をオフにするとFIFOキューの重複排除機能は利用できず、要件を満たさない可能性があります。

第6問: タグなしEC2インスタンスをリアルタイムで終了する

ある旅行会社のSysOps管理者は、Amazon EC2インスタンスが必須の「department」タグを付与されていることをコンプライアンス要件として定めています。誤ってタグが付与されなかったインスタンスは、ほぼリアルタイムで検知され次第、自動的に終了させたいと考えています。どのソリューションがこの要件を最も効率的に満たすでしょうか？

正解: 2. AWS Configルールを活用してタグの無いEC2インスタンスを検出し、自動修復でEC2インスタンスを終了させる

AWS Configを利用すると、リソースのタグの有無を継続的に監視できます。必須タグが存在しないEC2インスタンスを検出した際に、自動修復の設定を行っておけば、AWS Systems Manager Automation RunbookのAWS-TerminateEC2Instanceを呼び出し、即座にインスタンスを終了できます。これにより、ほぼリアルタイムにコンプライアンスを適用でき、運用負荷を大幅に軽減できます。

他の選択肢

EventBridgeとSNSを組み合わせる方法では、インスタンスがタグなしで作成された場合に通知は可能ですが、自動終了の仕組みが含まれていません。
IAMポリシーでタグ付与を強制することは一部可能ですが、徹底できないケースもあり、すでに起動してしまったインスタンスをリアルタイムに終了する機能はありません。
Systems Manager Complianceで非準拠リソースを停止するだけでは、本番要件の「終了」には達さず、停止のまま残るため運用面でギャップがあります。

第7問: VPCとオンプレミス間でSite-to-Site VPNを設定する際のカスタマーゲートウェイIPアドレスの選択

ある物流企業は、オンプレミスのデータセンターとAWS VPCを接続するため、AWSマネージドVPNを利用してSite-to-Site VPNを構築しています。オンプレミス側のルーター（カスタマーゲートウェイデバイス）は、データセンター内のファイアウォールやNATデバイスの背後にあり、インターネットへ直接アクセスできるのはファイアウォール/NATのパブリックIPアドレスのみです。SysOps管理者がAWSでカスタマーゲートウェイリソースを作成する際、どのアドレスを指定すればVPN接続が正しく確立できるでしょうか？

正解: 2. カスタマーゲートウェイデバイスの前段にあるNATのパブリックIPアドレスを指定する

AWSカスタマーゲートウェイリソースのIPアドレスには、オンプレミス側からインターネット経由でアクセス可能なパブリックIPアドレスを指定する必要があります。NATやファイアウォールの背後にあるルーターでは、外部からの通信にはNATデバイスのパブリックIPが使われるため、AWS側にもそのパブリックIPを登録することでSite-to-Site VPNが正しく確立されます。

他の選択肢

カスタマーゲートウェイデバイスのプライベートIPアドレス: インターネットから直接到達できないため、VPN接続が確立できません。
NATデバイスのMACアドレス: Customer Gatewayリソースの作成時にMACアドレスを指定する方法はなく、IPアドレスが必要です。
プライベートDNS名: プライベートホスト名はインターネット側からは解決できず、VPN確立には実グローバルIPアドレスが必須です。

第8問: HTTP 404応答の回数を運用効率よく監視する

ある動画配信企業は、Amazon EC2上のウェブサーバーでホストされているアプリケーションのログをAmazon CloudWatch Logsに送信しています。ログにはHTTPレスポンスコードが記録されており、システム障害を早期発見するために「HTTP 404」の発生件数をリアルタイムで監視したいと考えています。SysOps管理者は、なるべく自動化され、管理負荷の少ない方法を希望しています。この要件を満たすには、どのようなソリューションを選べばよいでしょうか？

正解: 1. CloudWatch Logsのメトリクスフィルターを作成してHTTP 404応答の発生回数をカウントする

CloudWatch Logsのメトリクスフィルターを用いると、特定パターン（本例ではHTTP 404レスポンス）に一致するログイベントの回数を自動的にCloudWatchメトリクスとしてカウントできます。このメトリクスに対してアラームを設定すれば、404の発生回数が一定を超えたタイミングで通知を受け取ることが可能になり、運用効率を高めることができます。追加のスクリプトやLambda関数を記述する手間も最小限です。

他の選択肢

サブスクリプションフィルターを使ってリアルタイムにLambdaへ送る方法は柔軟性がありますが、集計処理やメトリクス化を手動で実装する必要があり運用負担が高くなります。
Logs InsightsでLambdaが定期クエリする手法は、メトリクス化が自動ではないため、リアルタイム監視には向いておらず保守コストが増加します。
手動でLogs Insightsを実行するスクリプトは自動化が不十分で、エラー件数のリアルタイム検知には適していません。

第9問: 内部Webアプリケーションの可用性を向上させるための最適なAuto Scaling構成

あるコンサルティング企業は、Application Load Balancerの背後でAmazon EC2インスタンスが稼働する社内向けのWebアプリケーションを運用しています。インスタンスは単一のアベイラビリティゾーンに配置されたAuto Scalingグループ上で稼働中です。システムの可用性を高めるため、SysOps管理者はどうすればよいでしょうか？

正解: 2. Auto Scalingグループの構成を変更し、同じリージョン内の複数アベイラビリティゾーンを使用するよう設定する

単一のアベイラビリティゾーンのみを使っている場合、AZ障害が発生するとアプリケーションが停止するリスクがあります。同じリージョン内の複数AZをAuto Scalingグループに指定すれば、片方のAZが問題を起こしても他方が稼働を継続でき、可用性が向上します。Application Load Balancerを使用している場合も、マルチAZのインスタンスを背後に置くことで健全なインスタンスが存在するAZへトラフィックを振り分けられます。

他の選択肢

最小インスタンス数を増やす: 単一AZに多くのインスタンスを置いても、AZ障害には対応できず可用性向上には限度があります。
別リージョンに構成: 大規模かつコスト増になるうえ、クロスリージョンロードバランサの設定が複雑化し、今回の可用性改善要件には過剰な場合があります。
ALBを削除しNLBに切り替え: 通信プロトコルの制御が変わるだけで、AZ障害への耐性は向上しません。

第10問: Auto Scalingグループ内の全EC2インスタンスが同一ファイルセットを共有

あるデータ分析企業は、LinuxベースのEC2インスタンスをAuto Scalingグループ上で運用しており、起動テンプレートでEBS gp3ボリュームを利用する構成になっています。最近、これらのインスタンス全体で共通のデータファイルを共有しつつ、一貫性の高いアクセスを確保する必要が生じました。SysOps管理者がこの要件を満たすためには、どのようなアプローチを取るべきでしょうか？

正解: 4. EFSファイルシステムを作成し、マウント操作をユーザーデータに記述した新しい起動テンプレートを使用するようAuto Scalingグループを更新する

Amazon EFSを使用すれば、複数のEC2インスタンスで同一ファイルシステムを共有し、一貫したデータアクセスを実現できます。ユーザーデータでマウントコマンドを指定しておくと、スケールアウト時に新規インスタンスが立ち上がった際にも自動的にEFSをマウントして共通データにアクセスできます。これにより、データの整合性を保ちつつ、運用負荷を抑えたスケーリングが可能となります。

他の選択肢

マルチアタッチEBSボリュームは一部のボリュームタイプでサポートされていますが、同時書き込みに対する整合性維持が難しく、EFSほど簡易ではありません。
cronジョブでEBS間を同期する方法は管理が煩雑になり、スケーリング時にリアルタイムで反映されないリスクがあります。
起動テンプレートでEFSを新規作成する形ではなく、先にEFSを作成し、そのマウント設定をテンプレートに含める方が実運用では一般的です。各インスタンスで別々にEFSを生成するのは推奨されません。