Q64 — AWS SAA-C03 第17章

第 64/89 問 | ← 第17章

Q1364. ある企業は、AWS上で数十のマルチティアアプリケーションをホストしています。プレゼンテーション層およびロジック層は、Amazon EBSボリュームを使用するAmazon EC2 Linuxインスタンスで構成されています。同社は、新機能をデプロイする際にEC2インスタンスにOSの脆弱性が導入されないよう保証するソリューションを必要としています。同社は、カスタムAMIを用いてAuto Scalingグループ内でEC2インスタンスをデプロイしています。このソリューションは、同社がホストするすべてのアプリケーションに対応できるスケーラビリティを備える必要があります。これらの要件を満たすソリューションはどれですか？

正解: D. EC2 Image Builder を使用して、新機能をデプロイする際に新しいAMIを作成します。新しいAMIのビルドコンポーネントに update-linux コンポーネントを含めます。既存のAuto Scalingグループを使用して、新しいAMIをデプロイします。

解説

正解は D です。「EC2 Image Builder を使用して、新機能をデプロイする際に新しいAMIを作成します。新しいAMIのビルドコンポーネントに update-linux コンポーネントを含めます。既存のAuto Scalingグループを使用して、新しいAMIをデプロイします。」 解説： 同社には以下の要件を満たす、スケーラブルかつ自動化・セキュアなソリューションが必要です。 ・カスタムAMI経由でデプロイされるEC2インスタンスにOS脆弱性が導入されないよう保証すること ・すべてのマルチティアアプリケーション間で一貫性を確保すること ・既存のAuto Scalingグループとシームレスに統合できること なぜ選択肢 D が最適か： EC2 Image Builder ・AMI作成を自動化：すべてのインスタンスが安全で標準化されたイメージから構築されることを保証します。 ・update-linux コンポーネントの活用：AMI構築時にOSパッチおよびセキュリティ更新を自動適用します。 ・スケーラビリティ：手動介入なしで数十のアプリケーションをサポートできます。 ・Auto Scalingとの統合：既存のAuto Scalingグループを活用し、新しいAMIを自動的に展開できます。 デプロイ時点での脆弱性防止 ・セキュリティ更新をAMIに「焼き込む（bake in）」ことで、インスタンス起動時から安全な状態になります（実行中のインスタンスへの後続パッチ適用とは異なります）。 ・実行中のインスタンスをパッチ適用する場合と比較して、攻撃対象領域（attack surface）が小さく、すでに侵害されている可能性のある期間（リスクウィンドウ）も発生しません。 他の選択肢が不適切な理由： A. Amazon Inspector を使用した脆弱性パッチ適用 ・Inspector は脆弱性の「検出」のみ可能であり、「修正（パッチ適用）」はできません。 ・デプロイ後のスキャン：スキャンおよびパッチ適用が完了するまでの間、インスタンスは脆弱なままです（リスクウィンドウあり）。 ・AMIの自動化なし：今後のデプロイが安全である保証がありません。 B. AWS Backup ＋ EBSスナップショットによるAMI作成 ・バックアップにはセキュリティ更新は含まれません：バックアップからの復元により、脆弱性が再導入される可能性があります。 ・手動作業：バックアップからAMIを作成するのはエラーが発生しやすく、スケーラブルではありません。 ・予防的セキュリティなし：脆弱性対策ではなく、障害発生後の対応（リアクティブ）に依存しています。 C. AWS Systems Manager Patch Manager をカスタムAMIに適用 ・Patch Manager は実行中のインスタンスに対してパッチを適用しますが、AMI自体は更新しません。 ・古い脆弱なAMIからインスタンスが起動し続けます：Patch Manager の実行までセキュリティギャップが存在します。 ・スケーラビリティ不足：数十のアプリケーションに対し、各インスタンス単位でのパッチ適用は手動またはスケジュール管理が必要で非効率です。 比較表： | 選択肢 | AMI作成時点で脆弱性を防止？ | 自動化・スケーラブル？ | Auto Scalingと統合可能？ | 主な用途 | |--------|---------------------------|------------------------|--------------------------|----------| | D | ○（パッチがAMIに組み込まれる） | ○（EC2 Image Builder） | ○（シームレスなデプロイ） | スケール可能な予防的セキュリティ | | A | ×（検出のみ、パッチ不可） | ×（スキャン後の手動対応） | ×（AMIには影響なし） | 脆弱性スキャン（予防ではない） | | B | ×（バックアップはパッチ適用しない） | ×（手動AMI作成） | ×（直接統合なし） | ディザスタリカバリ（セキュリティ目的ではない） | | C | ×（実行中インスタンスのみ対象） | △（インスタンス単位パッチ） | ×（AMIは引き続き脆弱） | 後続パッチ適用（リアクティブ） | 結論： 選択肢 D は、最も安全でスケーラブルかつ自動化されたソリューションです。その理由は以下の通りです。 ・EC2 Image Builder により、AMIが事前にパッチ適用済みとなるため、インスタンス起動時から安全です。 ・update-linux コンポーネントにより、OS更新が自動化され、人的ミスが削減されます。 ・既存のAuto Scalingグループと連携可能であり、運用への影響を最小限に抑えられます。 選択肢 A、B、C はいずれも脆弱性の予防に失敗しているか、スケーラビリティに欠けています。 最終的な正解： D