【無料】AWS SOA-C03練習問題15問｜Udemy講師作成

AWS SOA無料問題集です。正解と解説を確認する際は右側のボタンを押下してください。

問題集の完全版は以下Udemyにて発売しているためお買い求めください。問題集への質問はUdemyのQA機能もしくはUdemyのメッセージにて承ります。Udemyの問題4から15問抜粋しております。

多くの方にご好評いただき、講師評価 4.5/5.0 を獲得できております。ありがとうございます。

特別価格： 通常2,600円 → 1,500円

講師クーポン適用で42%OFF

講師クーポン【全出題範囲網羅+詳細解説】AWS SOA-C03日本語実践問題260問(シスオプスアドミニストレータアソシエイト)

問題文：
ある企業の内部Webアプリケーションのユーザーが、短期間アプリケーションのパフォーマンス問題を経験しました。アプリケーションには、Amazon Elastic Kubernetes Service（Amazon EKS）クラスターで実行されるフロントエンドWebサーバーが含まれています。アプリケーションには、1つのDBインスタンスを含むバックエンドのAmazon Aurora PostgreSQL DBクラスターも含まれています。SysOps管理者は、パフォーマンス問題の原因がDBクラスターの高使用率であることを特定しました。単一のwriterインスタンスは11分間、90%以上の使用率を経験しました。高使用率の原因は、週に1回実行されるようにスケジュールされた自動レポートでした。このレポートはデータベースに対して読み取り専用のクエリのみを実行します。レポートが毎週実行されるときにユーザーがパフォーマンス問題を経験しないようにするために、SysOps管理者は何をすべきですか？
選択肢：
A. DBインスタンスのサイズを増やします。レポートの次回スケジュール実行時にパフォーマンスを監視します。
B. readerインスタンスを追加します。レポートアプリケーションのデータベース接続文字列を、新しく作成されたreaderインスタンスを使用するように変更します。
C. 別のwriterインスタンスを追加します。レポートアプリケーションのデータベース接続文字列を、新しく作成されたwriterインスタンスを使用するように変更します。
D. DBクラスターのオートスケーリングを構成します。最小キャパシティユニット、最大キャパシティユニット、ターゲット使用率を設定します。

正解：B

A. DBインスタンスのサイズを増やします。レポートの次回スケジュール実行時にパフォーマンスを監視します。

不正解 DBインスタンスのサイズを増やすことで、より多くのCPUとメモリリソースを提供し、高負荷に対応できますが、これは最適なアプローチではありません。レポートが読み取り専用である場合、writerインスタンスの容量を増やすよりも、読み取りワークロードを専用のreaderインスタンスに分離する方がコスト効率が高く、スケーラブルです。writerインスタンスのリソースをトランザクション処理のために確保すべきです。

B. readerインスタンスを追加します。レポートアプリケーションのデータベース接続文字列を、新しく作成されたreaderインスタンスを使用するように変更します。

正解レポートが読み取り専用のクエリで構成されている場合、Aurora readerインスタンスを追加し、レポートワークロードをreaderに向けることがAuroraの推奨されるベストプラクティスです。これにより、プライマリwriterインスタンスはトランザクション処理（INSERT、UPDATE、DELETE）に専念でき、読み取り専用のレポートクエリは専用のreaderで処理されます。writerインスタンスへの負荷を軽減し、コスト効率も高く、将来的なスケーラビリティも向上します。

C. 別のwriterインスタンスを追加します。レポートアプリケーションのデータベース接続文字列を、新しく作成されたwriterインスタンスを使用するように変更します。

不正解 Aurora PostgreSQLは、複数のwriterインスタンス（マルチマスター構成）をサポートしていません。Aurora MySQLにはマルチマスター機能がありますが、PostgreSQLバージョンには実装されていません。Aurora PostgreSQLでは、1つのwriterインスタンスと複数のreaderインスタンスという構成のみが可能です。したがって、この選択肢は技術的に実現不可能です。

D. DBクラスターのオートスケーリングを構成します。最小キャパシティユニット、最大キャパシティユニット、ターゲット使用率を設定します。

不正解 標準のAurora（プロビジョニング済み）では、readerインスタンスのAuto Scalingは可能ですが、問題文はwriterインスタンスの負荷が問題であることを示しています。まず、読み取りワークロードをreaderインスタンスに分離することが先決です。その後、必要に応じてreaderインスタンスのAuto Scalingを構成できます。また、「キャパシティユニット」という用語はServerless固有のもので、標準のプロビジョニング済みAuroraには適用されません。

問われている要件

週次の読み取り専用レポート実行時のDBクラスター高使用率問題を解決すること
ユーザーがパフォーマンス問題を経験しないようにすること
writerインスタンスの90%以上の使用率を改善すること
コスト効率の高い持続可能なソリューションを実装すること

前提知識

Aurora PostgreSQLのアーキテクチャと読み取りスケーリング

Amazon Aurora PostgreSQLは、クラウド向けに最適化されたリレーショナルデータベースエンジンです。1つのプライマリ(writer)インスタンスと最大15個のAurora Replica(reader)インスタンスで構成されるクラスター構成をサポートします。writerインスタンスは読み取りと書き込みの両方を処理できますが、readerインスタンスは読み取り専用のクエリを処理します。すべてのインスタンスは同じ共有ストレージボリュームにアクセスし、レプリケーションラグはミリ秒単位で非常に低くなります。この設計により、読み取りワークロードを効率的にスケールできます。

読み取りワークロードの分離のベストプラクティス

Auroraの推奨アーキテクチャでは、読み取り専用のワークロードをreaderインスタンスにオフロードすることが基本原則です。レポート、分析クエリ、読み取り専用のアプリケーション、ビジネスインテリジェンス（BI）ツールなどは、readerインスタンスに向けるべきです。これにより、writerインスタンスはOLTP（オンライントランザクション処理）ワークロード、つまりINSERT、UPDATE、DELETEなどのトランザクション処理に専念でき、全体的なパフォーマンスとスループットが向上します。読み取りと書き込みのワークロードを分離することで、リソースの競合が減少します。

Auroraエンドポイントの種類と使い分け

Auroraクラスターには複数のエンドポイントがあります。クラスターエンドポイント（writerエンドポイント）は常にプライマリwriterインスタンスを指し、書き込み操作に使用します。リーダーエンドポイントは、利用可能なすべてのreaderインスタンス間で読み取りトラフィックを自動的にロードバランシングします。カスタムエンドポイントを使用すると、特定のインスタンスのサブセットを指定して、ワークロードごとに異なる接続先を定義できます。レポートアプリケーションは、リーダーエンドポイントまたはカスタムエンドポイントを使用するように構成すべきです。

垂直スケーリングと水平スケーリングの比較

垂直スケーリング（スケールアップ）は、DBインスタンスのサイズを大きくすることで、より多くのCPU、メモリ、ネットワーク帯域幅を提供します。上限があり、短時間のダウンタイムが発生する可能性があります。水平スケーリング（スケールアウト）は、readerインスタンスを追加することで読み取り容量を増やします。ダウンタイムなしで実施でき、より柔軟でコスト効率が高くなります。読み取り専用の負荷が高い場合、水平スケーリングが推奨されるアプローチです。必要に応じて複数のreaderを追加でき、不要になれば削除できるため、柔軟性が高くなります。

コスト効率とパフォーマンス最適化

writerインスタンスのサイズを増やすことは、より高価なインスタンスクラスに移行することを意味し、コストが大幅に増加する可能性があります。一方、readerインスタンスを追加することで、読み取りワークロードのみに必要な容量を追加でき、writerインスタンスは小さく保つことができます。また、読み取り専用のワークロードをreaderに分離することで、writerインスタンスのリソースが解放され、トランザクション処理のパフォーマンスが向上します。これは、コストとパフォーマンスの両方の観点から最適なアプローチです。

解くための考え方

この問題のキーポイントは、「レポートはデータベースに対して読み取り専用のクエリのみを実行する」という前提条件です。この情報があることで、最適な解決策が明確になります。

まず、問題の本質を理解します。writerインスタンスが90%以上の使用率を経験したのは、読み取り専用のレポートクエリが原因です。つまり、書き込みワークロードではなく、読み取りワークロードがwriterインスタンスに過負荷をかけています。

Auroraのアーキテクチャでは、writerインスタンスは読み取りと書き込みの両方を処理できますが、読み取り専用のワークロードをwriterで処理することは非効率です。writerインスタンスはトランザクション処理のために予約し、読み取り専用のワークロードは専用のreaderインスタンスで処理すべきです。

readerインスタンスを追加してレポートアプリケーションの接続文字列を変更するアプローチには、以下の利点があります：

writerインスタンスの負荷が軽減され、トランザクション処理に専念できる
レポートクエリは専用のreaderで処理され、パフォーマンスが向上する
将来的に読み取り負荷が増加しても、追加のreaderインスタンスを追加できる
コスト効率が高い（writerのサイズを増やすより安価）

writerインスタンスのサイズを増やすアプローチは、読み取り専用ワークロードに対する最適な解決策ではありません。writerインスタンスは書き込み処理のために使用すべきで、読み取り専用の負荷のためにサイズを増やすことは、リソースの無駄遣いとなります。

複数のwriterインスタンスを追加する提案は、Aurora PostgreSQLが複数のwriterをサポートしていないため、技術的に不可能です。

オートスケーリングを構成する提案は、まず読み取りワークロードをreaderに分離することが先決であり、その後必要に応じてAuto Scalingを検討すべきです。

したがって、レポートが読み取り専用である場合、readerインスタンスを追加してレポートワークロードをreaderに向けることが、Auroraのベストプラクティスに沿った最適な解決策です。

参考資料

問題文：
企業は、すべてのAmazon EC2インスタンスでIPv6のみを使用したいと考えています。EC2インスタンスはインターネットからアクセス可能であってはなりませんが、EC2インスタンスはインターネットにアクセスできる必要があります。企業はデュアルスタックVPCとIPv6のみのサブネットを作成しました。CloudOps管理者は、これらの要件を満たすためにVPCをどのように設定する必要がありますか。
選択肢：
A. NAT ゲートウェイを作成してアタッチする。すべてのIPv6トラフィックをNAT ゲートウェイに向けるエントリを含むカスタムルートテーブルを作成する。カスタムルートテーブルをIPv6のみのサブネットにアタッチする
B. インターネットゲートウェイを作成してアタッチする。すべてのIPv6トラフィックをインターネットゲートウェイに向けるエントリを含むカスタムルートテーブルを作成する。カスタムルートテーブルをIPv6のみのサブネットにアタッチする
C. Egress-only インターネットゲートウェイを作成してアタッチする。すべてのIPv6トラフィックをEgress-only インターネットゲートウェイに向けるエントリを含むカスタムルートテーブルを作成する。カスタムルートテーブルをIPv6のみのサブネットにアタッチする
D. インターネットゲートウェイとNAT ゲートウェイを作成してアタッチする。すべてのIPv6トラフィックをインターネットゲートウェイに向け、すべてのIPv4トラフィックをNAT ゲートウェイに向けるエントリを含むカスタムルートテーブルを作成する。カスタムルートテーブルをIPv6のみのサブネットにアタッチする

正解：C

A. NAT ゲートウェイを作成してアタッチする。すべてのIPv6トラフィックをNAT ゲートウェイに向けるエントリを含むカスタムルートテーブルを作成する。カスタムルートテーブルをIPv6のみのサブネットにアタッチする

不正解 NAT ゲートウェイはIPv4トラフィック専用のサービスであり、IPv6トラフィックをサポートしていません。IPv6アーキテクチャでは、アドレス空間が十分に大きいため、ネットワークアドレス変換（NAT）の概念が存在しません。すべてのIPv6アドレスはグローバルにユニークであり、プライベートIPv6アドレスからパブリックIPv6アドレスへの変換は不要です。したがって、IPv6のみのサブネットでNAT ゲートウェイを使用することは技術的に不可能であり、この選択肢は要件を満たせません。

B. インターネットゲートウェイを作成してアタッチする。すべてのIPv6トラフィックをインターネットゲートウェイに向けるエントリを含むカスタムルートテーブルを作成する。カスタムルートテーブルをIPv6のみのサブネットにアタッチする

不正解 インターネットゲートウェイは双方向通信を許可するゲートウェイです。つまり、アウトバウンド（インスタンスからインターネットへ）とインバウンド（インターネットからインスタンスへ）の両方向のトラフィックを許可します。この設定では、パブリックIPv6アドレスを持つEC2インスタンスがインターネットから直接アクセス可能になってしまい、「インターネットからアクセス可能であってはならない」という要件を満たしません。セキュリティグループで制御することも可能ですが、より適切なソリューションが存在します。

C. Egress-only インターネットゲートウェイを作成してアタッチする。すべてのIPv6トラフィックをEgress-only インターネットゲートウェイに向けるエントリを含むカスタムルートテーブルを作成する。カスタムルートテーブルをIPv6のみのサブネットにアタッチする

正解 Egress-only インターネットゲートウェイは、IPv6トラフィック専用のゲートウェイで、アウトバウンド通信のみを許可し、インバウンド通信を自動的にブロックします。これはIPv4におけるNAT ゲートウェイに相当する機能をIPv6で提供しますが、アドレス変換は行いません。ステートフルな接続追跡により、インスタンスから開始された接続の応答トラフィックは許可されますが、インターネットから新規に開始された接続は拒否されます。::/0（すべてのIPv6アドレス）をEgress-only IGWに向けるルートを設定することで、要件を完全に満たすことができます。

D. インターネットゲートウェイとNAT ゲートウェイを作成してアタッチする。すべてのIPv6トラフィックをインターネットゲートウェイに向け、すべてのIPv4トラフィックをNAT ゲートウェイに向けるエントリを含むカスタムルートテーブルを作成する。カスタムルートテーブルをIPv6のみのサブネットにアタッチする

不正解 この選択肢には複数の問題があります。まず、IPv6のみのサブネットではIPv4トラフィックが存在しないため、NAT ゲートウェイは完全に不要です。次に、インターネットゲートウェイを使用すると、IPv6インスタンスへのインバウンド接続が許可されてしまい、セキュリティ要件を満たしません。IPv6のみのサブネットでは、IPv4関連のルーティングエントリも意味を持ちません。この設定は過剰に複雑で、コストも高く、要件を満たさない不適切なアプローチです。

問われている要件

すべてのEC2インスタンスでIPv6アドレスのみを使用し、IPv4は使用しない環境を構築する必要がある
EC2インスタンスからインターネットへのアウトバウンド通信を許可する必要がある
インターネットからEC2インスタンスへのインバウンド通信を完全にブロックする必要がある
デュアルスタックVPCとIPv6のみのサブネットという既存の環境に対して適切なゲートウェイとルーティングを設定する必要がある
セキュリティを維持しながらインターネット接続を実現するコスト効率の良いソリューションが求められている

前提知識

IPv6とIPv4の根本的な違い

IPv6は128ビットのアドレス空間を提供し、IPv4の32ビットアドレス空間と比較して事実上無限のアドレスを利用できます。この豊富なアドレス空間により、IPv6ではすべてのデバイスにグローバルにユニークなアドレスを割り当てることが可能です。IPv4では、プライベートアドレス空間（10.0.0.0/8、172.16.0.0/12、192.168.0.0/16）とNATによるアドレス変換が必要でしたが、IPv6にはプライベートアドレスとパブリックアドレスの区別という概念がありません。すべてのIPv6アドレスはグローバルユニキャストアドレスとして機能するため、ネットワークアドレス変換は不要であり、実装されていません。AWSでは、IPv6のみのサブネットに配置されたEC2インスタンスには、自動的にグローバルユニキャストIPv6アドレスが割り当てられます。

VPCゲートウェイの種類と役割

AWSのVPCには、インターネット接続を提供するための複数のゲートウェイタイプがあります。インターネットゲートウェイは、IPv4とIPv6の両方をサポートし、双方向通信を許可するゲートウェイです。VPCとインターネット間のトラフィックを転送し、パブリックIPv4アドレスまたはIPv6アドレスを持つリソースに対して、インバウンドとアウトバウンドの両方向の接続を可能にします。NAT ゲートウェイは、IPv4専用のサービスで、プライベートIPv4アドレスを持つリソースがインターネットにアクセスできるようにしますが、インターネットからの接続は開始できません。マネージドサービスであり、高可用性とスケーラビリティを提供しますが、IPv6トラフィックには対応していません。Egress-only インターネットゲートウェイは、IPv6専用のゲートウェイで、IPv4のNAT ゲートウェイに相当する機能を提供しますが、アドレス変換は行いません。

Egress-only インターネットゲートウェイの特徴

Egress-only インターネットゲートウェイは、IPv6トラフィック専用に設計されたステートフルなゲートウェイです。インスタンスから開始されたアウトバウンド接続とその応答トラフィックを許可しますが、インターネットから新規に開始されたインバウンド接続は自動的にブロックされます。接続の状態を追跡することで、既存の接続に属する応答パケットは通過を許可し、新規の接続試行は拒否するという動作を実現します。VPCごとに複数のEgress-only IGWを作成できますが、通常は1つで十分です。追加の料金は発生せず、データ転送料金のみが課金されます。ルートテーブルでは、::/0（すべてのIPv6アドレス）の宛先をEgress-only IGWにルーティングすることで、すべてのアウトバウンドIPv6トラフィックがこのゲートウェイを経由するように設定します。

IPv6のみのサブネットとデュアルスタックVPC

デュアルスタックVPCは、IPv4とIPv6の両方のアドレス範囲をサポートするVPCです。VPC作成時にIPv4 CIDRブロックが必須ですが、追加でIPv6 CIDRブロックを関連付けることができます。IPv6のみのサブネットは、このデュアルスタックVPC内に作成され、IPv6 CIDRブロックのみが割り当てられたサブネットです。このサブネット内に起動されたEC2インスタンスには、IPv6アドレスのみが割り当てられ、IPv4アドレスは割り当てられません。IPv6のみのサブネットでは、IPv4関連のネットワーク機能（NAT ゲートウェイ、IPv4ルーティングなど）は使用できず、使用する必要もありません。すべての通信はIPv6プロトコルを使用して行われます。セキュリティグループとネットワークACLは、IPv6トラフィックを適切に制御するように設定する必要があります。

解くための考え方

この問題は、IPv6のみを使用する環境でのインターネット接続の実装方法を問うています。重要なポイントは、アウトバウンド接続を許可しながらインバウンド接続を防ぐという、一方向性の通信制御を実現することです。

まず、IPv6とIPv4の根本的な違いを理解する必要があります。IPv4では、プライベートアドレスを使用するインスタンスがインターネットにアクセスするためにNAT ゲートウェイを使用しますが、IPv6にはプライベートアドレスとパブリックアドレスの区別がなく、NATという概念自体が存在しません。したがって、NAT ゲートウェイを使用するという選択肢は、IPv6環境では技術的に不可能です。NAT ゲートウェイはIPv4トラフィックのみをサポートし、IPv6トラフィックを処理することはできません。

次に、インターネットゲートウェイの使用を考えます。インターネットゲートウェイはIPv6トラフィックをサポートしますが、双方向通信を許可するため、インスタンスがインターネットからアクセス可能になってしまいます。もちろん、セキュリティグループでインバウンド通信を制御することは可能ですが、これはネットワークレイヤーではなくインスタンスレイヤーでの制御となります。より適切なアプローチは、ネットワークアーキテクチャレベルでインバウンド接続を防ぐことです。

Egress-only インターネットゲートウェイは、まさにこの要件のために設計されたIPv6専用のゲートウェイです。IPv4のNAT ゲートウェイと同様の役割を果たしますが、アドレス変換は行いません。ステートフルな接続追跡機能により、インスタンスから開始された接続の応答トラフィックは自動的に許可されますが、インターネットから新規に開始された接続は自動的にブロックされます。この動作は、セキュリティグループやネットワークACLによる追加の設定なしに実現されます。

ルーティングの設定も重要です。カスタムルートテーブルに::/0（すべてのIPv6アドレスを表す）をEgress-only IGWに向けるルートエントリを追加し、このルートテーブルをIPv6のみのサブネットに関連付けます。これにより、サブネット内のすべてのインスタンスからのアウトバウンドIPv6トラフィックがEgress-only IGWを経由してインターネットに到達します。

インターネットゲートウェイとNAT ゲートウェイの両方を使用する選択肢は、いくつかの理由で不適切です。まず、IPv6のみのサブネットではIPv4トラフィックが存在しないため、NAT ゲートウェイは完全に不要です。次に、インターネットゲートウェイの使用はインバウンド接続を許可してしまうため、セキュリティ要件を満たしません。また、不要なリソースを配置することで、コストも無駄に増加します。したがって、Egress-only インターネットゲートウェイを使用し、適切なルーティングを設定するアプローチが、技術的に正しく、セキュリティ要件を満たし、コスト効率も高い最適なソリューションとなります。

参考資料

問題文：
ある企業は、単一のAWSリージョンにあるAmazon EC2インスタンス上でワークロードを実行しています。この企業は、各EC2インスタンスの日次バックアップを作成する必要があります。CloudOps管理者は、バックアップ作成プロセスを自動化するソリューションを実装する必要があります。最小の運用オーバーヘッドでこの要件を満たすソリューションはどれですか？
選択肢：
A. AWS CLIを使用するシェルスクリプトを作成する。すべてのインスタンスをリストアップし、各インスタンスのスナップショットを作成するようにシェルスクリプトを構成する。シェルスクリプトをホストする新しいインスタンスを起動する。24時間ごとにシェルスクリプトを実行するcron jobを設定する
B. EC2コンソールを使用して、各インスタンスのAuto Recoveryオプションを有効にする。Auto Recoveryオプションを24時間ごとに実行するようにスケジュールする
C. インスタンス上に日次cron jobを作成するシェルスクリプトを作成する。AWS CLIを使用して各インスタンスのスナップショットを作成するようにcron jobを構成する。インスタンスプロファイルにスナップショットを作成するために必要な権限があることを確認する。インスタンスのユーザーデータの一部として実行されるようにシェルスクリプトを追加する
D. AWS Backupを使用して、日次デフォルトテンプレートを使用するバックアッププランを作成する。バックアップ対象のリソースとしてEC2インスタンスを指定する

正解：D

A. AWS CLIを使用するシェルスクリプトを作成する。すべてのインスタンスをリストアップし、各インスタンスのスナップショットを作成するようにシェルスクリプトを構成する。シェルスクリプトをホストする新しいインスタンスを起動する。24時間ごとにシェルスクリプトを実行するcron jobを設定する

不正解 この方法は技術的には機能しますが、運用オーバーヘッドが非常に高くなります。スクリプトをホストする専用のEC2インスタンスを維持する必要があり、そのインスタンス自体の可用性管理、パッチ適用、コスト管理が必要になります。また、スクリプトのメンテナンス、エラーハンドリング、ログ管理なども手動で実装する必要があります。新しいインスタンスが追加された場合、スクリプトを更新してそのインスタンスを含める必要があり、スケーラビリティにも課題があります。

B. EC2コンソールを使用して、各インスタンスのAuto Recoveryオプションを有効にする。Auto Recoveryオプションを24時間ごとに実行するようにスケジュールする

不正解 Auto Recoveryはバックアップ機能ではありません。Auto Recoveryは、EC2インスタンスのシステムステータスチェックが失敗した際に、同じハードウェア上でインスタンスを自動的に再起動する機能です。インスタンスID、プライベートIPアドレス、Elastic IPアドレス、メタデータなどは保持されますが、スナップショットやバックアップを作成する機能はありません。また、Auto Recoveryを定期的にスケジュールする機能も存在しません。この選択肢は要件を満たしません。

C. インスタンス上に日次cron jobを作成するシェルスクリプトを作成する。AWS CLIを使用して各インスタンスのスナップショットを作成するようにcron jobを構成する。インスタンスプロファイルにスナップショットを作成するために必要な権限があることを確認する。インスタンスのユーザーデータの一部として実行されるようにシェルスクリプトを追加する

不正解 各インスタンス上でcron jobを実行する方法は、分散管理となり運用オーバーヘッドが高くなります。すべてのインスタンスでスクリプトとcron jobを個別に管理する必要があり、インスタンス数が増えるほど管理コストが増大します。インスタンスが停止している場合はバックアップが実行されず、Auto Scalingで新しいインスタンスが起動する際にはユーザーデータで毎回スクリプトを適用する必要があります。バックアップの一元管理や監視も困難です。

D. AWS Backupを使用して、日次デフォルトテンプレートを使用するバックアッププランを作成する。バックアップ対象のリソースとしてEC2インスタンスを指定する

正解 AWS Backupは、AWSリソースのバックアップを一元管理できるフルマネージドサービスです。バックアッププランを一度設定するだけで、タグベースまたはリソースIDベースで複数のEC2インスタンスのバックアップを自動化できます。スケジュール設定、保持期間管理、ライフサイクルポリシー、クロスリージョンコピーなどの機能が組み込まれています。スクリプトやインフラの保守が不要で、バックアップの状態を中央コンソールで監視でき、最小の運用オーバーヘッドで要件を満たせます。

問われている要件

単一リージョン内のすべてのEC2インスタンスの日次バックアップを自動化すること
バックアップ作成プロセスの運用オーバーヘッドを最小限に抑えること
定期的なスケジュール実行により継続的なバックアップを確保すること
新しいインスタンスの追加やインスタンス数の変動に対応できるスケーラブルなソリューションであること
バックアップの管理と監視を効率的に行えること

前提知識

EC2スナップショットとバックアップの基本

EC2のバックアップは、EBSボリュームのスナップショットを作成することで実現されます。スナップショットはAmazon S3に保存され、増分バックアップとして機能します。初回は完全コピーですが、2回目以降は変更された部分のみが保存されるため、ストレージコストが最適化されます。スナップショットからは新しいEBSボリュームを作成でき、そのボリュームを使用して元のインスタンスを復元したり、新しいインスタンスを起動したりできます。手動でのスナップショット作成も可能ですが、自動化が推奨されます。

AWS Backupの特徴

AWS Backupは、複数のAWSサービスのバックアップを一元管理できるフルマネージドサービスです。EC2、EBS、RDS、DynamoDB、EFS、FSx、Storage Gatewayなど多様なリソースに対応しています。バックアッププランではスケジュール、保持期間、ライフサイクルルールを定義でき、タグベースでリソースを自動的に選択できます。クロスリージョン、クロスアカウントのバックアップコピーもサポートし、コンプライアンス要件への対応も容易です。AWS BackupではAWS Backup Vaultでバックアップを暗号化して保存し、バックアップの削除を防ぐVault Lockも提供します。

EC2 Auto Recoveryの目的

EC2 Auto Recoveryは、インスタンスの自動復旧機能であり、バックアップソリューションではありません。システムステータスチェックが失敗した場合、たとえばハードウェア障害やネットワーク接続の問題が発生した場合に、Amazonは自動的にインスタンスを復旧します。インスタンスは同じインスタンスID、プライベートIPアドレス、Elastic IPアドレス、メタデータを保持したまま再起動されます。ただし、データのバックアップやスナップショットの作成は行わず、あくまでインスタンスの可用性を維持するための機能です。

スクリプトベースのバックアップ自動化

AWS CLIやSDKを使用してスクリプトでバックアップを自動化することも可能です。この方法では、スクリプトでインスタンスをリストアップし、CreateSnapshotAPIを呼び出してスナップショットを作成します。Lambda関数やEC2インスタンス上のcron jobでスクリプトを定期実行できます。柔軟性は高いですが、エラーハンドリング、ログ管理、リトライロジック、通知機能などをすべて自分で実装する必要があり、運用負荷が高くなります。また、スクリプトを実行するインフラの維持管理も必要です。

解くための考え方

この問題のキーポイントは「最小の運用オーバーヘッド」という要件です。すべての選択肢は技術的にはバックアップを実現できる可能性がありますが、運用の複雑さと保守の手間が大きく異なります。運用オーバーヘッドを評価する際には、初期設定の複雑さ、継続的な保守作業、スケーラビリティ、障害時の対応、監視と管理の容易さなどを考慮する必要があります。

シェルスクリプトとcron jobを使用する方法は、カスタマイズ性が高い反面、すべてを手動で構築し保守する必要があります。専用のEC2インスタンスでスクリプトを実行する場合、そのインスタンス自体の可用性管理が必要になり、インスタンスが停止すればバックアップも停止します。各EC2インスタンス上でcron jobを実行する方法は、さらに管理が複雑になります。インスタンスごとにスクリプトを配置し、更新があればすべてのインスタンスで変更する必要があります。

Auto Recoveryは、名前から誤解を招きやすい選択肢ですが、バックアップ機能ではありません。インスタンスの復旧機能であり、データのスナップショットを作成する機能は持っていません。そもそも定期的なスケジュール実行の機能もないため、この選択肢は要件を満たしません。

AWS Backupは、まさにこのような要件のために設計されたマネージドサービスです。バックアッププランを一度作成すれば、指定したリソースの自動バックアップが継続的に実行されます。タグベースでリソースを選択できるため、新しいインスタンスが追加されても、適切なタグが付与されていれば自動的にバックアップ対象に含まれます。スケジュール管理、保持期間の自動管理、バックアップの状態監視などがすべて組み込まれており、スクリプトやインフラの保守が不要です。クロスリージョンバックアップやコンプライアンスレポート機能も標準で提供されるため、将来的な要件拡張にも対応できます。運用オーバーヘッドを最小限に抑えるという要件に最も適した選択肢です。

参考資料

問題文：
ある企業は、Application Load Balancer（ALB）の背後にある3つのAmazon EC2インスタンス上でWebアプリケーションを実行しています。企業は、ランダムなトラフィック増加の期間中に、アプリケーションのパフォーマンスが低下することに気付いています。SysOps管理者は、増加するトラフィックに対応するためにアプリケーションをスケーリングする必要があります。これらの要件を満たすソリューションはどれですか？
選択肢：
A. Amazon CloudWatchアラームを作成してアプリケーションのレイテンシーを監視し、目標の閾値に達した場合に各EC2インスタンスのサイズを増やす
B. Amazon EventBridge（Amazon CloudWatch Events）ルールを作成してアプリケーションのレイテンシーを監視し、目標の閾値に達した場合にEC2インスタンスをALBに追加する
C. ターゲット追跡スケーリングポリシーを持つEC2インスタンスのAuto Scalingグループにアプリケーションをデプロイする。Auto ScalingグループにALBをアタッチする
D. スケジュールされたスケーリングポリシーを持つEC2インスタンスのAuto Scalingグループにアプリケーションをデプロイする。Auto ScalingグループにALBをアタッチする

正解：C

A. Amazon CloudWatchアラームを作成してアプリケーションのレイテンシーを監視し、目標の閾値に達した場合に各EC2インスタンスのサイズを増やす

不正解 CloudWatchアラームでレイテンシーを監視し、インスタンスサイズを増やす方法は、垂直スケーリング（スケールアップ）のアプローチです。インスタンスサイズの変更には、インスタンスの停止と再起動が必要で、ダウンタイムが発生します。また、手動操作が必要となり、ランダムなトラフィック増加に迅速に対応できません。さらに、インスタンスサイズには上限があり、無限にスケールアップすることはできません。水平スケーリング（スケールアウト）の方が、可用性とコスト効率の面で優れています。

B. Amazon EventBridge（Amazon CloudWatch Events）ルールを作成してアプリケーションのレイテンシーを監視し、目標の閾値に達した場合にEC2インスタンスをALBに追加する

不正解 EventBridgeルールを使用してEC2インスタンスをALBに追加する方法は、カスタムの自動化ソリューションですが、Auto Scalingが提供する包括的な機能を再実装することになります。インスタンスの起動、ヘルスチェック、ターゲットグループへの登録、スケールインの処理など、すべてを手動で実装する必要があり、複雑で保守が困難です。また、複数のメトリクスに基づく高度なスケーリング戦略や、クールダウン期間の管理なども自分で実装する必要があります。Auto Scalingを使用する方が、運用オーバーヘッドが大幅に削減されます。

C. ターゲット追跡スケーリングポリシーを持つEC2インスタンスのAuto Scalingグループにアプリケーションをデプロイする。Auto ScalingグループにALBをアタッチする

正解ターゲット追跡スケーリングポリシーを持つAuto Scalingグループは、指定したメトリクス（CPU使用率、リクエスト数、ネットワークトラフィックなど）を目標値に維持するように自動的にインスタンス数を調整します。トラフィックが増加するとメトリクスが上昇し、Auto Scalingが自動的にインスタンスを追加してメトリクスを目標値に戻します。トラフィックが減少すると、不要なインスタンスを削除してコストを最適化します。ALBとの統合により、新しいインスタンスは自動的にロードバランサーに登録され、トラフィックの分散が行われます。ランダムなトラフィック増加に対して最も効果的なソリューションです。

D. スケジュールされたスケーリングポリシーを持つEC2インスタンスのAuto Scalingグループにアプリケーションをデプロイする。Auto ScalingグループにALBをアタッチする

不正解 スケジュールされたスケーリングポリシーは、予測可能なトラフィックパターンに適しています。たとえば、毎日午前9時にトラフィックが増加し、午後6時に減少するといった定期的なパターンがある場合に有効です。しかし、問題文では「ランダムな期間のトラフィック増加」と明記されており、予測不可能なトラフィックパターンです。スケジュールされたスケーリングでは、突発的なトラフィック増加に対応できず、パフォーマンスの低下を防ぐことができません。また、トラフィックがない時間帯でも余分なインスタンスが稼働し、コストが無駄になる可能性があります。

問われている要件

ランダムに発生するトラフィック増加に自動的に対応すること
トラフィック増加時のアプリケーションパフォーマンスの低下を防ぐこと
Application Load Balancerと統合してトラフィックを効率的に分散すること
手動介入なしに動的にスケーリングを実行すること
トラフィック減少時にはコストを最適化するためにスケールインすること

前提知識

Auto Scalingグループの基本概念

Amazon EC2 Auto Scalingは、アプリケーションの需要に応じてEC2インスタンスの数を自動的に調整するサービスです。最小容量、希望容量、最大容量を定義し、その範囲内でインスタンス数を動的に変更します。ヘルスチェック機能により、異常なインスタンスを自動的に検出して置き換え、アプリケーションの可用性を維持します。複数のアベイラビリティーゾーンにインスタンスを分散配置し、ゾーン障害に対する耐性を提供します。Application Load BalancerやNetwork Load Balancerと統合することで、新しく起動されたインスタンスは自動的にロードバランサーのターゲットグループに登録されます。

ターゲット追跡スケーリングポリシー

ターゲット追跡スケーリングポリシーは、特定のメトリクスを目標値に維持するように自動的にスケーリングを調整します。平均CPU使用率、リクエスト数、ネットワーク使用量などの事前定義されたメトリクスや、カスタムCloudWatchメトリクスを使用できます。たとえば、平均CPU使用率を50%に維持するように設定すると、Auto ScalingはCPU使用率が50%を超えるとインスタンスを追加し、50%を下回るとインスタンスを削除します。内部的にCloudWatchアラームを自動作成し、継続的に監視します。スケールアウトとスケールインの両方を自動的に処理し、アプリケーションのパフォーマンスとコストのバランスを取ります。

スケジュールされたスケーリングポリシー

スケジュールされたスケーリングは、特定の日時や定期的なスケジュールに基づいてキャパシティを変更します。予測可能なトラフィックパターンがある場合に有効で、たとえば営業時間中はインスタンス数を増やし、夜間は減らすといった設定が可能です。Cron式を使用して、毎週月曜日の午前8時にスケールアウトするといった複雑なスケジュールも定義できます。しかし、実際のトラフィック状況に関係なくスケジュールに従って実行されるため、突発的なトラフィック変動には対応できません。ターゲット追跡スケーリングと組み合わせて使用することで、ベースラインのキャパシティをスケジュールで管理し、追加の変動をターゲット追跡で処理することも可能です。

動的スケーリングとステップスケーリング

動的スケーリングには、ターゲット追跡スケーリング、ステップスケーリング、シンプルスケーリングの3種類があります。ターゲット追跡は最もシンプルで推奨される方法で、目標値を設定するだけで自動的に調整されます。ステップスケーリングは、メトリクスの変化の大きさに応じて異なるスケーリングアクションを実行します。たとえば、CPU使用率が60%から70%の場合は1インスタンス追加、70%から80%の場合は2インスタンス追加といった段階的な対応が可能です。シンプルスケーリングは、単一のスケーリング調整のみを実行し、クールダウン期間を待つ必要があるため、現在は推奨されていません。

Application Load Balancerとの統合

Application Load BalancerをAuto Scalingグループと統合すると、新しく起動されたEC2インスタンスは自動的にALBのターゲットグループに登録されます。ALBはヘルスチェックを実行し、健全なインスタンスにのみトラフィックをルーティングします。Auto Scalingグループは、ALBのヘルスチェック結果を使用して、インスタンスの健全性を判断できます。ALB RequestCountPerTargetメトリクスを使用したターゲット追跡スケーリングにより、各インスタンスが処理するリクエスト数を一定に保つことができます。これにより、トラフィックが増加すると自動的にインスタンスが追加され、各インスタンスの負荷が均等に保たれます。

垂直スケーリングと水平スケーリングの比較

垂直スケーリング（スケールアップ）は、既存のインスタンスのサイズを大きくすることで容量を増やします。実装は簡単ですが、インスタンスの停止と再起動が必要でダウンタイムが発生します。また、インスタンスサイズには上限があり、単一障害点のリスクも高まります。水平スケーリング（スケールアウト）は、インスタンス数を増やすことで容量を増やします。ダウンタイムなしにスケーリングでき、複数のインスタンスに負荷を分散することで可用性が向上します。コスト効率も良く、需要に応じて柔軟にスケールインできます。クラウド環境では、水平スケーリングが推奨されるアプローチです。

解くための考え方

この問題の核心は、ランダムに発生するトラフィック増加に対して、自動的かつ効率的にスケーリングを実行する方法を選択することです。キーワードは「ランダムな期間のトラフィック増加」と「パフォーマンスの低下を防ぐ」です。

まず、スケーリングのアプローチには垂直スケーリングと水平スケーリングがあります。インスタンスサイズを増やす方法は垂直スケーリングですが、これにはいくつかの問題があります。インスタンスの停止と再起動が必要でダウンタイムが発生し、手動操作が必要で自動化が困難です。さらに、インスタンスサイズには上限があり、コストも急激に増加します。

次に、スケーリングの自動化方法を考えます。EventBridgeとLambdaを組み合わせてカスタムソリューションを構築することも技術的には可能ですが、これはAuto Scalingが提供する機能を再実装することになります。インスタンスの起動、ヘルスチェック、ロードバランサーへの登録、スケールインのロジック、クールダウン期間の管理など、すべてを自分で実装する必要があり、複雑で保守が困難です。既存のマネージドサービスを使用する方が、運用効率が高くなります。

スケーリングのタイミングについて、スケジュールベースと動的スケーリングがあります。スケジュールされたスケーリングは、予測可能なトラフィックパターンには効果的ですが、問題文では「ランダムな期間」と明記されています。これは予測不可能なトラフィック変動を意味しており、スケジュールベースでは対応できません。スケジュールされたスケーリングでは、トラフィックが増加していないのにインスタンスを起動したり、トラフィックが増加しているのにスケールアウトが遅れたりする可能性があります。

ターゲット追跡スケーリングポリシーを使用するAuto Scalingグループは、この要件に最も適しています。平均CPU使用率やALBのリクエスト数などのメトリクスを継続的に監視し、目標値を維持するように自動的にインスタンス数を調整します。トラフィックが増加するとメトリクスが上昇し、Auto Scalingは自動的に新しいインスタンスを起動します。新しいインスタンスはALBに自動登録され、ヘルスチェックに合格するとトラフィックを受け取り始めます。これにより、アプリケーションのパフォーマンスが維持されます。トラフィックが減少すると、不要なインスタンスは自動的に終了され、コストが最適化されます。

このソリューションは、完全に自動化されており、手動介入は不要です。ランダムなトラフィック変動に迅速に対応し、高可用性を維持しながら、コスト効率も最適化できます。ALBとの統合により、新しいインスタンスへのトラフィック分散も自動的に処理されます。これが、問題の要件を満たす最適なソリューションです。

参考資料

問題文：
あるCloudOps管理者が、企業のディザスタリカバリ手順を担当しています。この企業は、本番アカウントにソースAmazon S3バケットを持っており、ソースから非本番アカウントの宛先S3バケットにオブジェクトをレプリケートしたいと考えています。SysOps管理者は、ソースS3バケットを宛先S3バケットにコピーするために、S3クロスリージョン、クロスアカウントレプリケーションを設定しました。SysOps管理者が宛先S3バケット内のオブジェクトにアクセスしようとすると、Access Deniedエラーが発生します。この問題を解決するソリューションはどれですか？
選択肢：
A. レプリケーション設定を変更して、オブジェクトの所有権を宛先S3バケット所有者に変更する
B. レプリケーションルールがソースS3バケット内のすべてのオブジェクトに適用され、単一のプレフィックスにスコープされていないことを確認する
C. S3 Replication Time Control（S3 RTC）が経過したときにリクエストを再試行する
D. レプリケートされたオブジェクトのストレージクラスが、ソースS3バケットと宛先S3バケットの間で変更されなかったことを確認する

正解：A

A. レプリケーション設定を変更して、オブジェクトの所有権を宛先S3バケット所有者に変更する

正解クロスアカウントレプリケーションでは、デフォルトでソースアカウントがレプリケートされたオブジェクトの所有権を保持します。これにより、宛先アカウントのユーザーがオブジェクトにアクセスしようとするとAccess Deniedエラーが発生します。レプリケーション設定でAccessControlTranslation設定を有効にすることで、オブジェクトの所有権を宛先バケット所有者に変更できます。さらに、宛先バケットポリシーでs3:ObjectOwnerOverrideToBucketOwner権限をソースアカウントに付与する必要があります。これにより宛先アカウントが完全な制御を得られます。

B. レプリケーションルールがソースS3バケット内のすべてのオブジェクトに適用され、単一のプレフィックスにスコープされていないことを確認する

不正解 レプリケーションルールのスコープは、どのオブジェクトがレプリケートされるかを決定しますが、レプリケート後のアクセス権限には影響しません。問題文では、オブジェクトは既にレプリケートされているが、アクセス時にAccess Deniedエラーが発生しています。これはレプリケーションルールの範囲の問題ではなく、オブジェクトの所有権とアクセス権限の問題です。すべてのオブジェクトまたは特定のプレフィックスのオブジェクトをレプリケートするかどうかは、アクセス許可エラーの解決には関係ありません。

C. S3 Replication Time Control（S3 RTC）が経過したときにリクエストを再試行する

不正解 S3 Replication Time Controlは、99.99%のオブジェクトを15分以内にレプリケートすることを保証する機能です。これはレプリケーションの完了タイミングに関する機能であり、アクセス権限の問題とは無関係です。オブジェクトが既にレプリケートされているが、所有権の問題でアクセスできない状況では、時間が経過してもAccess Deniedエラーは解決しません。レプリケーション設定で所有権を変更しない限り、この問題は継続します。

D. レプリケートされたオブジェクトのストレージクラスが、ソースS3バケットと宛先S3バケットの間で変更されなかったことを確認する

不正解 ストレージクラスは、オブジェクトの保存方法とコストに影響を与えますが、アクセス権限には影響しません。S3 Glacier Deep ArchiveやS3 Glacierなどのアーカイブストレージクラスでは、オブジェクトを取得する前に復元が必要ですが、これは別のエラーメッセージを生成します。Access Deniedエラーは、IAM権限またはオブジェクト所有権の問題を示しており、ストレージクラスの変更では解決できません。レプリケーション設定でストレージクラスを変更することも可能ですが、これは本質的な問題ではありません。

問われている要件

クロスリージョン、クロスアカウントのS3レプリケーションを正しく機能させること
宛先アカウントのユーザーが、レプリケートされたオブジェクトにアクセスできるようにすること
ソースアカウントから宛先アカウントへのオブジェクトレプリケーションを継続すること
Access Deniedエラーを解決し、宛先バケット内のオブジェクトへの適切なアクセス制御を実装すること
ディザスタリカバリシナリオで、非本番アカウントが本番データに確実にアクセスできるようにすること

前提知識

S3レプリケーションの基本

Amazon S3レプリケーションは、バケット間でオブジェクトを自動的かつ非同期的にコピーする機能です。クロスリージョンレプリケーション（CRR）では、異なるAWSリージョン間でレプリケートでき、クロスアカウントレプリケーションでは、異なるAWSアカウント間でレプリケートできます。レプリケーション設定には、ソースバケット、宛先バケット、レプリケートするオブジェクトの範囲（全オブジェクトまたは特定のプレフィックス）、ストレージクラスの変更オプションなどが含まれます。レプリケーションは新しいオブジェクトに対してのみ適用され、既存のオブジェクトをレプリケートするには、S3 Batch Replicationを使用します。

クロスアカウントレプリケーションにおけるオブジェクト所有権

クロスアカウントレプリケーションでは、デフォルトでソースアカウントがレプリケートされたオブジェクトの所有権を保持します。つまり、オブジェクトが宛先バケットにコピーされても、所有者はソースアカウントのままです。このため、宛先アカウントのユーザーやロールがオブジェクトにアクセスしようとすると、適切な権限がない限りAccess Deniedエラーが発生します。この問題を解決するには、レプリケーション設定でAccessControlTranslation設定を有効にし、オブジェクトの所有権を宛先バケット所有者に変更する必要があります。これにより、宛先アカウントがオブジェクトの完全な制御を得ることができます。

AccessControlTranslationとオーバーライド権限

AccessControlTranslationは、レプリケーション設定の一部で、レプリケートされたオブジェクトの所有権を宛先バケット所有者に変更するための設定です。この設定を有効にするには、宛先バケットのバケットポリシーで、ソースアカウントにs3:ObjectOwnerOverrideToBucketOwner権限を明示的に付与する必要があります。この権限により、ソースアカウントはオブジェクトをレプリケートする際に、所有権を宛先アカウントにオーバーライドできます。適切に設定されると、レプリケートされたすべてのオブジェクトは宛先アカウントが所有者となり、宛先アカウントのIAMポリシーやバケットポリシーに従ってアクセス制御されます。

S3バケットポリシーとIAM権限の関係

S3のアクセス制御は、バケットポリシー、IAMポリシー、ACL、オブジェクト所有権の組み合わせで決定されます。クロスアカウントアクセスでは、ソースアカウントのIAMロールまたはユーザーに宛先バケットへの書き込み権限が必要で、宛先バケットのバケットポリシーでソースアカウントからのアクセスを許可する必要があります。オブジェクトの所有権が異なる場合、所有者アカウントのポリシーが優先され、他のアカウントからのアクセスは制限されます。このため、クロスアカウントレプリケーションでは、所有権の変更が重要になります。

S3 Replication Time Controlの役割

S3 Replication Time Controlは、レプリケーションの予測可能性を向上させる機能で、99.99%のオブジェクトを15分以内にレプリケートすることを保証します。この機能は、コンプライアンスやディザスタリカバリの要件を満たすために使用されますが、アクセス権限やオブジェクト所有権には影響しません。RTCはレプリケーションのタイミングと信頼性を管理する機能であり、レプリケート後のアクセス制御とは独立しています。

解くための考え方

この問題の核心は、クロスアカウントS3レプリケーションにおけるAccess Deniedエラーの原因を特定し、適切な解決策を選択することです。問題文から、レプリケーション設定は既に完了しており、オブジェクトは宛先バケットにレプリケートされていると推測できます。しかし、宛先アカウントのSysOps管理者がオブジェクトにアクセスしようとするとエラーが発生しています。

まず、クロスアカウントレプリケーションのデフォルト動作を理解する必要があります。S3のクロスアカウントレプリケーションでは、レプリケートされたオブジェクトはデフォルトでソースアカウントの所有のままです。つまり、オブジェクトが物理的に宛先バケットに存在していても、所有者はソースアカウントです。宛先アカウントのユーザーがこれらのオブジェクトにアクセスするには、ソースアカウントが明示的に権限を付与するか、オブジェクトの所有権を宛先アカウントに移転する必要があります。

レプリケーションルールのスコープは、どのオブジェクトがレプリケートされるかを決定しますが、レプリケート後のアクセス権限には影響しません。すべてのオブジェクトをレプリケートしても、特定のプレフィックスのみをレプリケートしても、所有権の問題は解決しません。S3 Replication Time Controlは、レプリケーションの完了タイミングを保証する機能であり、アクセス権限とは無関係です。ストレージクラスの変更も、アクセス制御には影響しません。

正解は、レプリケーション設定を変更してオブジェクトの所有権を宛先バケット所有者に変更することです。これは、AccessControlTranslation設定を有効にすることで実現できます。この設定により、レプリケートされたオブジェクトの所有権が自動的に宛先アカウントに移転され、宛先アカウントのIAMポリシーやバケットポリシーに従ってアクセス制御されるようになります。ただし、この設定を有効にするには、宛先バケットのバケットポリシーで、ソースアカウントにs3:ObjectOwnerOverrideToBucketOwner権限を付与する必要があります。これにより、ソースアカウントはレプリケーション時にオブジェクトの所有権を変更できるようになります。この解決策により、宛先アカウントのユーザーは、追加の権限設定なしにレプリケートされたオブジェクトにアクセスできるようになり、ディザスタリカバリシナリオでも問題なく機能します。

参考資料

問題文：
組織は、ファイルシステム ID が `fs-85ba41fc` の Amazon Elastic File System (EFS) ボリュームを作成し、10個の Amazon EC2 ホストにマウントして使用しています。
しかし、ファイルシステムが暗号化されていないことを懸念しています。EFS を暗号化するための最適な方法を選択してください。
選択肢：
A. 各ホストのローカルドライブで暗号化を有効にします。ホストを再起動して、ドライブを暗号化します。
B. AWS コマンドラインインターフェース (CLI) を使用して、既存の EFS ボリュームの暗号化を有効にします。
C. 新しいボリュームを作成して暗号化を有効にし、元のボリュームのデータをすべてコピーします。その後、各ホストを新しいボリュームに再接続します。
D. Amazon EFS ボリュームへの各 EFS 接続で暗号化を有効にします。暗号化を有効にするには、各接続を再作成する必要があります。

正解：C

A. 各ホストのローカルドライブで暗号化を有効にします。ホストを再起動して、ドライブを暗号化します。

不正解 ローカルドライブの暗号化はEC2インスタンスのEBSボリュームを暗号化する機能で、EFSファイルシステム自体の暗号化とは別の仕組みです。EFSはネットワークファイルシステムとして動作するため、クライアント側のローカル暗号化ではファイルシステム本体のデータ保護にはなりません。EFS暗号化は保存時暗号化として、ファイルシステムレベルでAES-256暗号化により実装される必要があります。

B. AWS コマンドラインインターフェース (CLI) を使用して、既存の EFS ボリュームの暗号化を有効にします。

不正解 Amazon EFSでは、ファイルシステム作成後に暗号化設定を変更することは技術的に不可能です。保存時暗号化はファイルシステムの作成時にのみ設定でき、既存の未暗号化ファイルシステムを後から暗号化に変更するAPIやCLIコマンドは存在しません。この制限はEFSの設計上の特性であり、暗号化を行うには新しいファイルシステムの作成が必須となります。

C. 新しいボリュームを作成して暗号化を有効にし、元のボリュームのデータをすべてコピーします。その後、各ホストを新しいボリュームに再接続します。

正解 EFSの暗号化を実現する唯一の方法は、暗号化を有効にした新しいファイルシステムを作成し、既存データを移行することです。この手順では、AWS DataSyncやrsyncなどのツールを使用してデータを効率的にコピーし、すべてのEC2ホストのマウント設定を新しいファイルシステムIDに更新します。移行中はダウンタイムが発生しますが、データの完全性を保ちながら暗号化要件を満たせる確実な方法です。

D. Amazon EFS ボリュームへの各 EFS 接続で暗号化を有効にします。暗号化を有効にするには、各接続を再作成する必要があります。

不正解 EFSには接続レベルで暗号化を設定する機能は存在しません。保存時暗号化はファイルシステム全体の属性として設定されるもので、個別のマウント接続やクライアント単位で制御することはできません。転送時暗号化はマウント時にTLSを有効化することで可能ですが、これは保存時のデータ暗号化とは異なる仕組みであり、今回の要件には対応できません。

問われている要件

既存の未暗号化EFSファイルシステムを暗号化状態に変更すること
複数のEC2ホストからアクセス可能な暗号化ファイルシステムを構築すること
データの整合性と可用性を維持しながら暗号化を実装すること
運用中のシステムへの影響を最小限に抑えた移行手順を実行すること
セキュリティとコンプライアンス要件を満たす暗号化レベルを達成すること

前提知識

ファイルストレージサービスの特徴

Amazon EFS はNFSv4.1およびv4.0プロトコルをサポートする完全マネージド型のファイルストレージサービスです。ペタバイト規模まで自動拡張し、数千の同時接続をサポートします。保存時暗号化はAES-256アルゴリズムを使用し、ファイルシステム作成時にのみ設定可能です。暗号化設定の変更は技術的に不可能で、複数のアベイラビリティーゾーン間での冗長化により高可用性を実現し、大規模なファイル共有や並列アクセスが必要なアプリケーションに適用されます。
Amazon EBS は最大80TBまでサポートするブロックストレージサービスで、EC2インスタンス専用の持続性ストレージを提供します。保存時暗号化は作成時または既存ボリュームのスナップショット作成時に設定でき、転送時暗号化はEC2とEBS間で自動的に実装されます。EBSは単一インスタンスからのアクセスに限定され、ファイルシステムレベルでの共有アクセスには適していません。

データ転送・移行ツールについて

AWS DataSync は最大10Gbpsの転送スループットを持つフルマネージド型データ転送サービスで、自動的なデータ整合性チェックとEnd-to-End暗号化を提供します。ファイル属性、タイムスタンプ、アクセス権限を含むメタデータの完全保持をサポートし、ネットワーク最適化により効率的な転送を実現します。大容量データの一括移行や定期的な同期処理に適用されます。
rsync はオープンソースのファイル同期ツールで、差分転送アルゴリズムにより変更されたデータのみを転送します。SSH経由での暗号化転送や詳細なファイル属性保持機能を持ちますが、手動設定が必要で大規模環境では運用負荷が高くなります。小中規模のデータ移行や手動制御が必要な環境に適用されます。

暗号化・セキュリティサービスについて

AWS Key Management Service（KMS）は最大4KBのデータキー暗号化と年間数百万のオペレーションをサポートする暗号鍵管理サービスです。カスタマーマネージドキーとAWSマネージドキーを提供し、キーの自動ローテーション、細粒度アクセス制御、CloudTrailとの統合による操作ログ記録機能を持ちます。EFSの保存時暗号化では必須のサービスとして、データ暗号化キーの生成と管理に適用されます。
保存時暗号化（Encryption at Rest）はデータがストレージに書き込まれる前に自動的に暗号化し、読み取り時に透過的に復号化する仕組みです。EFSではAES-256暗号化が使用され、アプリケーションレベルでの変更は不要です。転送時暗号化（Encryption in Transit）はクライアントとEFS間の通信をTLS 1.2で保護し、マウント時にstunnelプロセスを使用して実装されます。

解くための考え方

この問題の核心は、Amazon EFSの暗号化設定に関する技術的制約を理解することです。EFSでは保存時暗号化がファイルシステムの根本的な属性として扱われ、作成後の変更は不可能という重要な特性があります。

既存の未暗号化ファイルシステムを暗号化するには、新しい暗号化済みファイルシステムを作成し、データを移行する以外に方法はありません。この移行プロセスでは、データの整合性を保ちながら、効率的で信頼性の高い転送を実現する必要があります。

データ移行の方法として、AWS DataSyncが最も適しています。DataSyncは自動的なデータ検証機能を持ち、ファイル属性やタイムスタンプを含むメタデータを完全に保持できます。また、転送の進捗監視や失敗時の自動リトライ機能により、大規模なデータ移行でも安全に実行できます。

代替手段としてrsyncも利用可能ですが、手動での設定と監視が必要になります。移行手順では、まず新しい暗号化ファイルシステムを作成し、適切なKMSキーを設定した後、データ転送を実行します。転送完了後は、全てのEC2インスタンスのマウント設定を更新し、アプリケーションの動作確認を行います。

この方式により、既存システムへの影響を最小限に抑えながら、セキュリティ要件を満たす暗号化されたファイルシステムに移行できます。

参考資料

問題文：
ある会社では、すべての監査ログを10年間アーカイブする必要があります。また、将来の編集からログを保護する仕組みが求められています。
この要件を満たす最適なソリューションを選択してください。
選択肢：
A. Amazon S3 Glacier ボールトにデータを保存し、ボールトロックポリシーを Write-Once Read-Many (WORM) アクセス用に構成します。
B. Amazon S3 標準 – 低頻度アクセス (S3 標準 – IA) にデータを保存し、多要素認証 (MFA) を構成します。
C. Amazon S3 標準 – 低頻度アクセス (S3 標準 – IA) にデータを保存し、サーバー側の暗号化を構成します。
D. Amazon Elastic Block Store (Amazon EBS) ボリュームにデータを保存し、AWS Key Management Service (AWS KMS) 暗号化を構成します。

正解：A

A. Amazon S3 Glacier ボールトにデータを保存し、ボールトロックポリシーを Write-Once Read-Many (WORM) アクセス用に構成します。

正解 Amazon S3 Glacier Vault Lockは規制要件とコンプライアンス要件に対応するWORM機能を提供します。ボールトロックポリシーを設定することで、指定期間中のアーカイブ削除を防止でき、365日などの保持期間を設定して監査ログを確実に保護できます。ただし現在のベストプラクティスでは、S3 Glacierストレージクラス（Deep Archive）とS3 Object Lockの組み合わせが推奨されており、こちらの方がより柔軟で管理しやすい仕組みです。

B. Amazon S3 標準 – 低頻度アクセス (S3 標準 – IA) にデータを保存し、多要素認証 (MFA) を構成します。

不正解 S3標準-IAは頻繁にアクセスしないデータ向けのストレージクラスで、10年間の長期アーカイブには適していません。MFAは削除操作に対する追加認証を提供しますが、WORM機能は提供しないため、権限のあるユーザーでも削除を防止する規制要件には対応できません。長期保存のコスト効率性も悪く、監査ログのアーカイブ要件を満たしません。

C. Amazon S3 標準 – 低頻度アクセス (S3 標準 – IA) にデータを保存し、サーバー側の暗号化を構成します。

不正解 サーバー側暗号化はデータ保護のための暗号化機能を提供しますが、データの編集や削除を防止するWORM機能ではありません。暗号化されたデータでも適切な権限があれば変更や削除が可能であり、規制や監査要件で求められる不変性は実現できません。また、S3標準-IAは長期アーカイブには不適切でコストも高くなります。

D. Amazon Elastic Block Store (Amazon EBS) ボリュームにデータを保存し、AWS Key Management Service (AWS KMS) 暗号化を構成します。

不正解 Amazon EBSはEC2インスタンス向けのブロックストレージサービスで、長期アーカイブストレージには設計されていません。EBSボリュームは単一インスタンスに接続され、インスタンス終了時にデータが失われるリスクがあります。WORM機能も提供されておらず、KMS暗号化は保存時の暗号化のみで削除防止効果はありません。10年間の監査ログ保管には不適切です。

問われている要件

監査ログを10年間という長期間にわたって確実に保管できること
将来的な編集や改ざんから完全にログを保護する仕組みがあること
規制要件やコンプライアンス要件に対応できる不変性の実現
大容量データの長期保存に適したコスト効率性を持つこと
監査証跡として法的な証明力を持つ信頼性のあるストレージであること

前提知識

アーカイブストレージサービスの特徴

Amazon S3 Glacier（従来サービス）は専用のボールトロックポリシーにより強固なWORM機能を提供します。ボールトロックポリシーは一度設定されると変更や削除ができず、最大365日以上の保持期間設定が可能です。SEC 17a-4、CFTC、FINRAなどの金融規制に準拠した設計となっており、監査や規制要件の厳しい業界での長期データ保管に適用されます。ただし現在は後継のS3 Glacierストレージクラスの使用が推奨されています。
S3 Glacierストレージクラス（S3 Glacier Flexible Retrieval、Deep Archive）は現在推奨される長期アーカイブソリューションで、S3 Object Lockと組み合わせてWORM機能を実現します。Deep Archiveは最小180日の保持期間があり、12時間以内での復元が可能です。オブジェクトあたり40KBの追加メタデータが必要ですが、AWSで最も低コストなストレージオプションとして長期データ保管に適用されます。

データ保護・セキュリティサービスについて

S3 Object Lockは現在の標準WORM実装で、保持期間とリーガルホールドの2つの方法でオブジェクト保護を管理します。Cohasset Associates による規制適合性評価を受けており、SEC、CFTC、FINRA規制環境での使用が認定されています。ガバナンスモードとコンプライアンスモードを提供し、柔軟性と厳格性のバランスを取った運用が可能で、現代的な監査ログ保護に適用されます。
AWS Key Management Service（KMS）は暗号鍵管理サービスで、保存時および転送時の暗号化を提供します。年間数百万のオペレーションに対応し、カスタマーマネージドキーとAWSマネージドキーを選択できます。CloudTrail統合による操作ログ記録機能を持ちますが、データの削除防止機能は提供せず、WORM要件には対応できません。

ストレージクラス・ブロックストレージサービスについて

Amazon S3標準-IAは月1回程度のアクセス頻度のデータに適したストレージクラスで、最小30日の保持期間があります。ミリ秒レベルの高速アクセスが可能ですが、長期アーカイブには不適切でコスト効率性も低くなります。10年間の監査ログ保管では年間コストが大幅に増加し、企業の予算に大きな負担となるため適用されません。
Amazon EBSは最大80TBまでサポートするEC2専用ブロックストレージで、高IOPS性能と低遅延アクセスを提供します。単一インスタンス接続の制限があり、インスタンス終了時のデータ消失リスクや可用性の課題があります。長期アーカイブストレージとしては設計されておらず、10年間の継続運用には不適切で運用コストも高くなります。

解くための考え方

この問題は監査ログの長期保管要件を満たすストレージソリューションの選択問題です。10年間という長期保管と編集防止という2つの要件を同時に満たす必要があります。

長期アーカイブの観点では、コスト効率性が重要な要素となります。S3標準-IAのような頻繁アクセス用ストレージでは10年間の保管コストが非常に高額になります。一方、Glacierストレージは長期保管に最適化されており、大幅なコスト削減が可能です。

編集防止の観点では、WORM（Write-Once Read-Many）機能が必須となります。単なる暗号化やアクセス制御では、適切な権限を持つユーザーによる意図的または意図しない削除を防げません。真の不変性を実現するには、技術的にデータの変更や削除を不可能にする仕組みが必要です。

従来のS3 Glacier Vault Lockは、この要件を満たす確実な方法です。ボールトロックポリシーは一度ロック状態になると、AWS自体でも変更できない強固な保護を提供します。金融業界などの厳格な規制要件にも対応しており、監査ログの保護には適しています。

ただし現在のAWSベストプラクティスでは、S3 GlacierストレージクラスとS3 Object Lockの組み合わせが推奨されています。これは管理の柔軟性と統合性の面で優れており、新規システム構築時はこちらを検討すべきです。しかし、選択肢に含まれていないため、従来のGlacier Vault Lockが正解となります。

参考資料

問題文：
ある企業は、Amazon EC2 インスタンスでアプリケーションをホストしています。また、Amazon RDS for PostgreSQL を使用してデータベースをホストしています。
この企業は、データベースインスタンスへのすべての接続を暗号化する必要があります。この要件を満たす最適なソリューションを選択してください。
選択肢：
A. カスタム PostgreSQL 拡張機能を使用し、SSL/TLS をデータベースにパッチ適用します。
B. AWS Key Management Service (AWS KMS) 暗号化キーを使用してデータベースを暗号化します。
C. カスタムパラメーターグループを使用して、データベースへの SSL 接続を強制します。
D. インバウンドセキュリティグループルールを使用して、データベースへの SSL 接続を許可します。

正解：C

A. カスタム PostgreSQL 拡張機能を使用し、SSL/TLS をデータベースにパッチ適用します。

不正解 PostgreSQLのSSL/TLSサポートは標準機能として組み込まれており、カスタム拡張機能やパッチ適用は不要です。RDS for PostgreSQLは標準でTLSバージョン1.1、1.2、1.3をサポートしており、追加の拡張機能を使用することなくSSL/TLS暗号化を実現できます。このアプローチは不必要に複雑で、RDSの管理されたサービスの利点を無効化してしまいます。

B. AWS Key Management Service (AWS KMS) 暗号化キーを使用してデータベースを暗号化します。

不正解 AWS KMSは保存時暗号化（encryption at rest）を提供するサービスで、ディスク上のデータを暗号化します。転送時暗号化（encryption in transit）とは異なる仕組みであり、クライアントとデータベース間の接続を暗号化する機能は提供しません。データベース接続の暗号化にはSSL/TLSが必要で、KMS暗号化では要件を満たすことができません。

C. カスタムパラメーターグループを使用して、データベースへの SSL 接続を強制します。

正解カスタムパラメーターグループを作成し、rds.force_sslパラメーターを1に設定することで、すべてのクライアント接続でSSL/TLS暗号化を強制できます。デフォルトパラメーターグループは変更不可のため、カスタムパラメーターグループの作成が必要です。このパラメーターが有効な場合、暗号化されていない接続は自動的に拒否され、確実にすべての接続が保護されます。

D. インバウンドセキュリティグループルールを使用して、データベースへの SSL 接続を許可します。

不正解 セキュリティグループはネットワークレベルでのアクセス制御を提供し、ポートやプロトコル、ソースIPアドレスベースの通信許可を管理します。SSL接続の許可はできますが、SSL使用の強制はできません。セキュリティグループの設定だけではクライアントが非暗号化接続を試行することを防げず、暗号化要件の確実な実施には不十分です。

問われている要件

データベースインスタンスへのすべての接続が暗号化されている必要があること
非暗号化接続の使用を完全に防止する仕組みが求められること
既存のアプリケーションへの影響を最小限に抑えた実装が必要であること
規制要件やセキュリティ基準を満たす確実な暗号化の実現
管理されたサービスとしてのRDSの利点を活用した設定方法であること

前提知識

データベース暗号化サービスの特徴

RDS for PostgreSQL SSL/TLS機能はSecure Socket LayerとTransport Layer Securityをサポートし、TLSバージョン1.1、1.2、1.3に対応しています。クライアントとDB インスタンス間のデータ通信を暗号化し、業界標準の暗号化プロトコルによる転送時保護を提供します。SSL証明書は各DBインスタンス作成時にAmazon RDSが自動生成し、証明書チェーン検証によるなりすまし攻撃からの保護機能も含まれ、金融や医療など高セキュリティ要件の業界に適用されます。
AWS Key Management Service（KMS）は保存時暗号化専用のサービスで、年間数百万のオペレーションをサポートします。AES-256暗号化アルゴリズムを使用してDBインスタンス基盤サーバー上でデータを暗号化し、透過的な暗号化・復号化処理を提供します。カスタマーマネージドキーとAWSマネージドキーの選択が可能で、CloudTrailによる鍵使用監査機能を持ちますが、転送時データの暗号化機能は提供しません。

パラメーター管理サービスについて

RDS パラメーターグループはデータベースエンジンの設定を管理する仕組みで、各DBエンジンバージョンに対応したデフォルト設定を提供します。静的パラメーターは変更後にDB インスタンスの再起動が必要で、動的パラメーターは即座に反映されます。rds.force_sslは静的パラメーターのため、有効化には再起動が必要ですが、一度設定されると確実にSSL接続を強制でき、規制コンプライアンス要件の実現に適用されます。
カスタムパラメーターグループの作成はデフォルトグループのコピーから開始し、特定の設定値を変更して独自の構成を定義します。最大100個のカスタムパラメーターグループを作成可能で、複数のDBインスタンスに同じグループを適用して設定の一貫性を保てます。パラメーター変更はコンソール、AWS CLI、APIを通じて実行でき、大規模環境での自動化に適用されます。

ネットワーク・アクセス制御サービスについて

Amazon RDS セキュリティグループはネットワークファイアウォール機能を提供し、インバウンドとアウトバウンドの通信制御を管理します。ポート番号、プロトコル、ソースIPアドレス、他のセキュリティグループを指定した細粒度なアクセス制御が可能です。最大100個のルールを設定でき、VPCセキュリティグループとの統合によるネットワークレベルでの包括的な保護を提供しますが、アプリケーションレベルの暗号化制御は含まれません。
PostgreSQL拡張機能はデータベース機能を拡張するモジュールシステムで、RDS for PostgreSQLでは事前承認された拡張機能のみがサポートされます。SSL/TLS機能は PostgreSQLコア機能として標準実装されており、追加の拡張機能は不要です。カスタム拡張機能の導入はRDSの管理された環境では制限され、セキュリティと安定性の観点から推奨されません。

解くための考え方

この問題は転送時暗号化（encryption in transit）の実装に関する問題で、クライアントとデータベース間の通信を保護する仕組みが求められています。保存時暗号化（encryption at rest）とは異なる概念であることを理解することが重要です。

RDS for PostgreSQLでSSL接続を強制する標準的な方法は、カスタムパラメーターグループを使用することです。デフォルトパラメーターグループは読み取り専用のため、設定変更にはカスタムグループの作成が必須となります。

rds.force_sslパラメーターは PostgreSQLの標準機能で、このパラメーターを1に設定することで、すべてのクライアント接続でSSL/TLS暗号化が強制されます。暗号化されていない接続試行は自動的に拒否され、確実にセキュリティ要件を満たすことができます。

他の選択肢では、PostgreSQL拡張機能によるSSL実装は標準機能で十分であるため不要、KMS暗号化は保存時のみの保護で転送時には効果なし、セキュリティグループは通信の許可・拒否制御であり暗号化の強制とは別の仕組みであり、いずれも要件を満たしません。

実装手順としては、まずカスタムパラメーターグループを作成し、rds.force_sslパラメーターを1に設定します。その後、このパラメーターグループをDBインスタンスに適用し、再起動して設定を有効化します。この方法により、確実で管理しやすいSSL接続の強制が実現できます。

参考資料

問題文：
企業は、AWS 内の Amazon EC2 および Amazon RDS へのリソースの追跡を厳格化したいと考えています。このため、すべての AWS リソースに対して厳格なタグ付け要件を実装することを決定しました。CloudOps管理者は、準備していないリソースを特定する必要があります。
この要件を満たす最も効率的なソリューションを選択してください。
選択肢：
A. 指定されたタグのすべてのリソースを評価するカスタム AWS Lambda 関数を呼び出す AWS Config のルールを作成します。
B. 指定されたタグのためのすべての作成または更新されたリソースを評価するために、マネージドルールで Amazon EventBridge にルールを作成します。
C. 指定されたタグのためにすべての作成または更新されたリソースを評価するカスタム AWS Lambda 関数を呼び出す Amazon EventBridge のルールを作成します。
D. AWS Config で、指定したタグのすべてのリソースを評価する `required-tags` マネージドルールを使用します。

正解：D

A. 指定されたタグのすべてのリソースを評価するカスタム AWS Lambda 関数を呼び出す AWS Config のルールを作成します。

不正解 カスタムLambda関数を使用してAWS Configルールを作成する方法は技術的に可能ですが、required-tagsマネージドルールという既成のソリューションが存在するため非効率です。カスタム実装では開発工数、テスト工数、保守運用コストが発生し、デバッグや機能拡張の負担も増加します。

B. 指定されたタグのためのすべての作成または更新されたリソースを評価するために、マネージドルールで Amazon EventBridge にルールを作成します。

不正解 Amazon EventBridgeにマネージドルールを作成するという表現は技術的に正確ではありません。EventBridgeはイベント駆動型のサービスでありリソースのタグ評価には適していません。また、EventBridgeのマネージドルールという概念は存在せず、AWS Configのマネージドルールと混同された記述となっています。

C. 指定されたタグのためにすべての作成または更新されたリソースを評価するカスタム AWS Lambda 関数を呼び出す Amazon EventBridge のルールを作成します。

不正解 EventBridgeとカスタムLambda関数の組み合わせはリアルタイムなイベント処理には適していますが、既存リソース全体の継続的な監視には不向きです。また、カスタム実装により開発・運用コストが増大し、AWS Configのマネージドルール機能と比較して効率性に劣ります。

D. AWS Config で、指定したタグのすべてのリソースを評価する `required-tags` マネージドルールを使用します。

正解 AWS Configのrequired-tagsマネージドルールは、指定されたタグがリソースに適切に設定されているかを自動評価する最適なソリューションです。既存の全リソースを継続的に監視し、タグ付け要件に準拠していないリソースを自動検出できます。カスタム開発不要で設定も簡単で運用負担を最小化できます。

問われている要件

すべてのAWSリソースに対する厳格なタグ付け要件の実装
タグ付けされていないリソースの特定と継続的な監視
運用効率を重視した最適なソリューションの選択
EC2およびRDSを含む複数のAWSサービスへの対応
管理者の運用負担を最小化する実装方法

前提知識

AWS設定監視サービスの特徴

AWS Config：AWSリソースの設定変更を記録し、設定の準拠性を評価するサービスで、マネージドルールにより事前定義されたルールセットを利用可能
Configuration Item：各リソースの設定情報を時系列で記録し、設定変更の履歴追跡が可能
評価範囲：アカウント内のすべてのサポートされたリソースタイプを自動で対象とし、リージョン単位での設定が可能

マネージドルールとカスタムルール

required-tagsマネージドルール：指定されたタグキーがリソースに存在するかを評価し、タグ値の検証も可能で設定が簡単
カスタムルール：Lambda関数を使用した独自の評価ロジックを実装可能だが、開発・テスト・運用コストが発生
評価トリガー：設定変更時や定期実行により自動評価を実施し、非準拠リソースを即座に特定

イベント処理サービスについて

Amazon EventBridge：AWSサービスからのイベントをルーティングし、リアルタイム処理に適しているがタグ評価の継続監視には不向き
イベントパターン：特定のリソース変更イベントをキャッチ可能だが、既存リソース全体の評価には限界がある

解くための考え方

この問題では、企業全体のタグ付け要件を効率的に実装し、継続的に監視する最適な方法を選択する必要があります。まず、要件を整理すると、既存のすべてのリソースを評価し、今後作成されるリソースも継続的に監視する仕組みが必要です。

AWS Configは、まさにこのようなリソース設定の準拠性を評価するために設計されたサービスです。特にrequired-tagsマネージドルールは、タグ付け要件の評価に特化した機能で、複雑な設定なしに即座に利用できます。このルールを使用することで、指定されたタグキーがリソースに存在するかどうかを自動的に評価し、非準拠のリソースを特定できます。

一方、カスタムLambda関数やEventBridgeを使用したソリューションは、技術的には実現可能ですが、開発工数、テスト、運用保守のコストが発生します。また、EventBridgeはイベント駆動型の処理に適しており、継続的なリソース監視よりもリアルタイムなイベント処理に向いています。

運用効率を重視する観点から、既存のマネージドサービスを活用することで、開発リスクを排除し、AWSが提供する信頼性の高い機能を利用できます。required-tagsマネージドルールは、設定が簡単で、すべてのサポートされたリソースタイプに対応し、準拠性レポートの生成も自動化されているため、最も効率的なソリューションと言えます。

参考資料

問題文：
企業のアーキテクチャチームは、会社のメインの AWS 本番アカウントで新しい Amazon EC2 インスタンスが起動されるたびに、すぐにメール通知を受け取る必要があります。
この要件を満たす最適な方法を選択してください。
選択肢：
A. Amazon Simple Notification Service (SNS) トピックと、メールプロトコルを使用するサブスクリプションを作成します。サブスクライバーとしてアーキテクチャチームのメールアドレスを入力します。EC2 インスタンスの起動時に反応する Amazon EventBridge ルールを作成し、ルールのターゲットとして SNS トピックを指定します。
B. Amazon Simple Queue Service (SQS) キューと、電子メールプロトコルを使用するサブスクリプションを作成します。サブスクライバーとしてアーキテクチャチームのメールアドレスを入力します。EC2 インスタンスの起動時に反応する Amazon EventBridge ルールを作成し、ルールのターゲットとして SQS キューを指定します。
C. スマートホストコネクタを介してメールメッセージを送信するユーザーデータスクリプトを作成します。ユーザーデータスクリプトにはアーキテクチャチームのメールアドレスを受信者として含めます。すべての新しい EC2 インスタンスに標準化されたビルドプロセスの一部としてユーザーデータスクリプトが含まれていることを確認します。
D. Amazon Simple Notification Service (SNS) トピックを作成します。EC2 イベントを SNS トピックに発行するように AWS Systems Manager を設定します。SNS トピックをポーリングする AWS Lambda 関数を作成し、アーキテクチャチームのメールアドレスにメッセージを送信するように設定します。

正解：A

A. Amazon Simple Notification Service (SNS) トピックと、メールプロトコルを使用するサブスクリプションを作成します。サブスクライバーとしてアーキテクチャチームのメールアドレスを入力します。EC2 インスタンスの起動時に反応する Amazon EventBridge ルールを作成し、ルールのターゲットとして SNS トピックを指定します。

正解 SNSトピックとEventBridgeルールの組み合わせは、EC2インスタンス起動イベントをリアルタイムで検出し、即座にメール通知を送信する最適なソリューションです。EventBridgeはEC2のStateChange Notificationイベントを自動キャッチし、SNSは複数の宛先に同時配信が可能で、設定も簡単です。管理負担が最小で信頼性が高い標準的な実装方式です。

B. Amazon Simple Queue Service (SQS) キューと、電子メールプロトコルを使用するサブスクリプションを作成します。サブスクライバーとしてアーキテクチャチームのメールアドレスを入力します。EC2 インスタンスの起動時に反応する Amazon EventBridge ルールを作成し、ルールのターゲットとして SQS キューを指定します。

不正解 SQSはメッセージキューイングサービスであり、メール送信機能は提供していません。SQSにメッセージが送信された後、別途Lambda関数などでメッセージを取得し、メール送信処理を実装する必要があります。また、SQSには電子メールプロトコルを使用するサブスクリプション機能は存在せず、技術的に実現不可能な構成です。

C. スマートホストコネクタを介してメールメッセージを送信するユーザーデータスクリプトを作成します。ユーザーデータスクリプトにはアーキテクチャチームのメールアドレスを受信者として含めます。すべての新しい EC2 インスタンスに標準化されたビルドプロセスの一部としてユーザーデータスクリプトが含まれていることを確認します。

不正解 ユーザーデータスクリプトによるメール送信は、各EC2インスタンスに個別の設定が必要で管理が非効率的です。インスタンス起動時の処理時間増加、メール送信失敗時の再試行機構の不備、スクリプト管理の複雑化などの問題があります。さらに、AMIやAutoScalingグループでの統一的な管理が困難になります。

D. Amazon Simple Notification Service (SNS) トピックを作成します。EC2 イベントを SNS トピックに発行するように AWS Systems Manager を設定します。SNS トピックをポーリングする AWS Lambda 関数を作成し、アーキテクチャチームのメールアドレスにメッセージを送信するように設定します。

不正解 この構成には複数の技術的誤りがあります。Systems ManagerはEC2イベントをSNSに自動発行する機能を持たず、SNSはプッシュ型通知サービスであるためポーリングされません。また、SNS自体がメール送信機能を提供しているため、Lambdaを追加する構成は冗長で不必要な複雑性を増します。

問われている要件

新しいEC2インスタンス起動イベントのリアルタイム検知と即座の通知
アーキテクチャチーム宛ての確実なメール配信機能の実装
本番環境での安定性と管理効率を重視したソリューション選択
スケーラブルで運用負担の少ないイベント駆動型アーキテクチャの構築
複数の受信者への同時配信とメール配信の信頼性確保

前提知識

イベント駆動型通知サービスの特徴

Amazon EventBridge：以前のCloudWatch Eventsの進化版で、EC2ライフサイクルイベントやAWSサービス間のイベントルーティングに特化したサーバーレスイベントバス
EC2 State Change Notification：インスタンスの起動、停止、終了などの状態変化を自動検出し、JSONフォーマットでイベント情報を提供
ルールパターンマッチング：特定のイベントタイプやリソース属性に基づいたフィルタリングが可能で、必要なイベントのみを対象とした処理が実現
ターゲット設定：SNS、Lambda、SQS、Kinesisなど複数のAWSサービスをターゲットとして指定可能

通知サービスの比較と適用場面

Amazon SNS：プッシュ型通知サービスでメール、SMS、HTTP、Lambda、SQSなど多様なプロトコルをサポート、ファンアウト配信により複数の宛先への同時配信が可能
Amazon SQS：メッセージキューイングサービスでアプリケーション間の非同期通信に特化、Direct-to-Email機能は存在せず、別途処理機構が必要
トピックベース配信：SNSトピックを使用することで購読者の動的な追加・削除が容易で、配信先の管理を簡素化
デッドレターキュー：配信失敗時の再試行とエラーハンドリング機能により通知の信頼性を向上

EC2インスタンス管理とユーザーデータの制約

ユーザーデータスクリプト：インスタンス起動時に一度だけ実行されるCloud-Initスクリプトで、主に初期設定用途に使用
実行環境の制限：インスタンス内部での実行のため外部依存関係やネットワーク接続に依存し、失敗時のエラーハンドリングが困難
管理の複雑性：AMI作成、AutoScalingグループ、LaunchTemplateでの統一管理が必要で、スクリプトの更新時に全体的な再デプロイが発生
セキュリティリスク：メール送信に必要な認証情報やSMTPサーバー情報をユーザーデータに含める必要があり、セキュリティ上のリスクが増大

Systems Managerとその他のサービス連携

AWS Systems Manager：EC2およびオンプレミスサーバーの管理サービスで、パッチ適用、設定管理、ドキュメント実行に特化
EventBridgeとの連携：Systems Manager自体はEventBridgeにイベントを発行する機能は持たないが、Systems Managerが実行するタスクの結果をEventBridge経由で通知可能
サービス間統合：各AWSサービスは特定の役割に最適化されており、適切なサービス選択により効率的なアーキテクチャを構築可能

解くための考え方

EC2インスタンスの起動イベントを検知してメール通知を送信するシステムを設計する場合、イベント駆動型アーキテクチャの原則に基づいて最適なサービス組み合わせを選択する必要があります。

まず、EC2インスタンスの起動を検知する仕組みを考えると、EventBridgeが最適な選択肢です。EventBridgeはEC2のライフサイクルイベントを自動的に検出し、State Change Notificationとして詳細な情報を提供します。このイベントには、インスタンスID、起動時刻、インスタンスタイプ、可用性ゾーンなどの有用な情報が含まれており、通知内容を充実させることができます。

次に、メール通知の実装については、SNSが最も直接的で効率的なソリューションです。SNSはメールプロトコルを直接サポートしており、複数の受信者への同時配信、配信の信頼性確保、エラーハンドリング機能を提供しています。メールアドレスの追加や削除も簡単で、運用面での柔軟性が高いのが特徴です。

他の選択肢を検討すると、SQSを使用した場合はメッセージキューに格納された後、別途メール送信処理を実装する必要があり、不必要な複雑性が生じます。ユーザーデータスクリプトを使用した場合は、各インスタンスに個別の設定が必要で、管理負担が大幅に増加し、失敗時の対処も困難になります。

Systems ManagerとLambdaを組み合わせた複雑な構成も、SNSの直接的なメール配信機能を考慮すると冗長であり、障害点の増加と運用コストの増大につながります。

理想的なアーキテクチャでは、EventBridgeルールでEC2起動イベントを検出し、即座にSNSトピックにメッセージを送信することで、シンプルで信頼性の高いリアルタイム通知システムを構築できます。この構成は、AWSのサーバーレスアーキテクチャの利点を最大限に活用し、運用負担を最小化しながら高い可用性を実現します。

参考資料

問題文：
CloudOps管理者は、Ubuntu を実行している数百の Amazon EC2 インスタンスにデプロイされたカスタムアプリケーションのログファイルを収集し、Amazon CloudWatch Logs に保存する必要があります。
運用オーバーヘッドを最小限に抑えつつ、ログファイルを収集するための最適な方法を選択してください。
選択肢：
A. 各 EC2 インスタンスで Amazon Linux パッケージマネージャを使用して CloudWatch エージェントをインストールし、アプリケーションログファイルを収集するように各エージェントを構成します。
B. AWS Systems Manager Parameter Store に CloudWatch エージェント構成を保存します。Systems Manager を使用して、各 EC2 インスタンスに CloudWatch エージェントをインストールし、アプリケーションログファイルを収集するように各エージェントを構成します。
C. AWS Systems Manager を使用して、各 EC2 インスタンスに CloudWatch エージェントをインストールします。CloudWatch 構成ウィザードを使用して各エージェントを構成し、アプリケーションログファイルを収集するように設定します。
D. 各 EC2 インスタンス上の syslogd サービスを構成して、アプリケーションログファイルを収集し、CloudWatch Logs に送信します。

正解：B

A. 各 EC2 インスタンスで Amazon Linux パッケージマネージャを使用して CloudWatch エージェントをインストールし、アプリケーションログファイルを収集するように各エージェントを構成します。

不正解 Amazon LinuxパッケージマネージャはUbuntu環境では使用できません。UbuntuではAptパッケージマネージャを使用する必要があります。また、数百のインスタンスに対して個別にエージェントをインストールし構成する方法は、手動作業が多く運用負担が非常に大きくなります。スケールアウト時の追加設定や設定変更時の一括更新も困難です。

B. AWS Systems Manager Parameter Store に CloudWatch エージェント構成を保存します。Systems Manager を使用して、各 EC2 インスタンスに CloudWatch エージェントをインストールし、アプリケーションログファイルを収集するように各エージェントを構成します。

正解 Parameter StoreにCloudWatchエージェントの構成ファイルを保存し、Systems Managerを使用して一括インストール・構成する方法は最も効率的です。Run Commandを使用して数百のインスタンスに同時にエージェントをデプロイでき、構成の統一性と管理の簡素化を実現します。設定変更時もParameter Storeの更新だけで全インスタンスに反映可能です。

C. AWS Systems Manager を使用して、各 EC2 インスタンスに CloudWatch エージェントをインストールします。CloudWatch 構成ウィザードを使用して各エージェントを構成し、アプリケーションログファイルを収集するように設定します。

不正解 Systems Managerでのエージェントインストール自動化は適切ですが、CloudWatch構成ウィザードを使用した個別構成は運用負担を大きく増加させます。数百のインスタンスに対して手動でウィザードを実行することは現実的ではなく、構成の一貫性確保も困難になります。また、設定変更時に全インスタンスでの再設定が必要となります。

D. 各 EC2 インスタンス上の syslogd サービスを構成して、アプリケーションログファイルを収集し、CloudWatch Logs に送信します。

不正解 syslogdサービスの直接構成によるCloudWatch Logs送信は技術的に可能ですが、CloudWatchエージェントと比較して機能が限定的です。ログのフィルタリング、メタデータの追加、複数ログファイルの柔軟な管理などの高度な機能が利用できません。また、syslog設定の管理とトラブルシューティングの複雑性も増大します。

問われている要件

Ubuntu環境の数百のEC2インスタンスでのCloudWatchエージェント大規模展開
カスタムアプリケーションログファイルのCloudWatch Logsへの効率的な収集
運用オーバーヘッド最小化を重視したスケーラブルな管理手法の実装
構成の統一性確保と変更管理の簡素化を実現するソリューション選択
新規インスタンス追加時の自動化対応と既存インスタンスの一括管理

前提知識

CloudWatchエージェントの特徴と機能

CloudWatch Agent：統合ログおよびメトリクス収集エージェントで、EC2インスタンスやオンプレミスサーバーからのデータ収集に特化
マルチプラットフォーム対応：Amazon Linux、Ubuntu、CentOS、Windows Serverなど幅広いOSをサポートし、統一的な設定と管理が可能
高度なログ処理機能：ログファイルのフィルタリング、パターンマッチング、メタデータ追加、複数ログストリームの同時処理をサポート
JSON形式設定ファイル：詳細なログ収集設定とカスタマイズが可能で、複雑なログファイル構成にも対応

AWS Systems Managerによる大規模管理

Systems Manager Run Command：数千のインスタンスに対する並列コマンド実行機能で、エージェントのインストールや設定変更を一括処理
Systems Manager Agent（SSM Agent）：Ubuntu 16.04以降にプリインストールされており、追加設定なしでSystems Manager機能を利用可能
Session Manager：SSH接続不要でのリモートアクセス機能を提供し、セキュリティ要件の厳しい環境でも管理作業を実行可能
インベントリ管理：インスタンス構成情報の収集と追跡により、エージェント導入状況の一元的な把握が可能

Parameter Storeによる構成管理

AWS Systems Manager Parameter Store：階層化された設定データの安全な保存と共有機能で、暗号化オプションとアクセス制御を提供
設定の中央管理：CloudWatchエージェントの構成ファイルを一箇所で管理し、複数のインスタンス間での設定統一を実現
バージョン管理：構成変更の履歴追跡と以前のバージョンへのロールバック機能により、変更管理の安全性を確保
動的設定更新：Parameter Store の値更新により、エージェント再起動時に最新設定を自動取得可能

従来のログ収集手法との比較

syslogd設定：システム標準のログ管理機能だが、CloudWatch Logsとの直接連携機能は限定的で、追加のフォワーダー設定が必要
rsyslogやsyslog-ng：より高機能なsyslog実装だが、CloudWatchエージェントと比較して設定の複雑性とメンテナンス負担が増大
カスタムスクリプト：独自のログ転送スクリプトの作成も可能だが、エラーハンドリング、再送機能、監視機能の実装が必要で開発・運用コストが高い

解くための考え方

大規模なEC2環境でのログ収集システムを設計する場合、スケーラビリティと運用効率性を両立させることが最重要課題となります。数百のインスタンスという規模では、手動での個別設定や管理は現実的ではなく、自動化とインフラストラクチャ・アズ・コードの原則に基づいたアプローチが必須です。

まず、CloudWatchエージェントの選択は妥当です。これは、AWSが公式に提供するログ収集エージェントであり、CloudWatch Logsとのネイティブ統合、豊富なログ処理機能、マルチプラットフォーム対応などの利点があります。syslogdなどの従来手法と比較して、AWS環境に最適化された機能と信頼性を提供します。

次に、大規模展開の実現方法として、Systems Managerが最適な選択肢です。Run Command機能により、数百のインスタンスに対して並列でエージェントのインストールと構成を実行できます。また、Session Managerを使用することで、セキュリティを維持しながらリモート管理作業を実施可能です。

構成管理の観点では、Parameter Storeの活用が重要な差別化要因となります。CloudWatchエージェントの設定ファイルをParameter Storeに保存することで、全インスタンスで統一された構成を確保できます。設定変更が必要な場合も、Parameter Storeの値を更新するだけで、全インスタンスに新しい設定を配布できます。

この構成では、新規インスタンスの追加時にも、同じSystems Managerコマンドを実行するだけでエージェント環境を自動構築できます。AutoScalingグループと組み合わせることで、インスタンスの自動スケーリング時にも一貫したログ収集環境を維持できます。

運用面では、CloudWatch Metricsを通じてエージェントの稼働状況を監視し、異常があれば即座に検知・対応できます。また、Systems Managerのインベントリ機能により、エージェントのバージョンや設定状況を一元的に把握でき、コンプライアンス管理も効率化されます。

このアプローチにより、初期導入時の作業効率化だけでなく、継続的な運用における管理負担の最小化と、設定変更時の迅速な対応が実現されます。

参考資料

問題文：
誤動作するプロセスは、プロセス全体を使用し、100% 実行されることが知られています。CloudOps管理者は、問題が 2 分以上発生した場合に Amazon EC2 インスタンスを再起動するプロセスを自動化したいと考えています。
これを実現する最適な方法を選択してください。
選択肢：
A. 基本モニタリングを使用して、EC2 インスタンスの Amazon CloudWatch アラームを作成します。インスタンスを再起動するアクションを追加します。
B. EC2 のヘルスチェックによって呼び出される EC2 インスタンスを再起動する AWS Lambda 関数を作成します。
C. 詳細モニタリングを使用して、EC2 インスタンスの Amazon CloudWatch アラームを作成します。インスタンスを再起動するアクションを追加します。
D. EC2 インスタンスを再起動する AWS Lambda 関数を作成し、2 分ごとにスケジュールに基づいて起動させます。

正解：C

A. 基本モニタリングを使用して、EC2 インスタンスの Amazon CloudWatch アラームを作成します。インスタンスを再起動するアクションを追加します。

不正解 基本モニタリングはメトリクスを5分間隔で収集するため、2分以上という条件を正確に検出できません。最短でも5分後の検出となり、要件である2分以上の問題継続を検知する精度が不十分です。また、アラーム評価期間も5分間隔となるため、迅速な対応ができません。

B. EC2 のヘルスチェックによって呼び出される EC2 インスタンスを再起動する AWS Lambda 関数を作成します。

不正解 EC2ヘルスチェックは主にインスタンスの到達可能性やシステム状態をチェックする機能で、CPU使用率100%という特定のメトリクス条件での判定はサポートしていません。ヘルスチェック失敗時のLambda関数実行も標準機能として提供されておらず、カスタム実装が必要で複雑性が増します。

C. 詳細モニタリングを使用して、EC2 インスタンスの Amazon CloudWatch アラームを作成します。インスタンスを再起動するアクションを追加します。

正解詳細モニタリングによりメトリクス収集間隔を1分に短縮できるため、CPU使用率100%の状態を精密に監視可能です。CloudWatchアラームで評価期間を2分、データポイント数を2に設定することで、2分間連続でCPU使用率100%の条件を満たした場合のみインスタンス再起動アクションを実行できます。設定も簡単で信頼性が高いソリューションです。

D. EC2 インスタンスを再起動する AWS Lambda 関数を作成し、2 分ごとにスケジュールに基づいて起動させます。

不正解 スケジュールベースの定期実行では、実際のCPU使用率状況に関係なくインスタンスが再起動されるため、正常動作中のアプリケーションにも悪影響を与えます。また、問題発生タイミングとスケジュール実行タイミングがずれる可能性があり、適切な問題解決にならない可能性があります。

問われている要件

CPU使用率100%という特定の異常状態の継続的な監視と検出
問題発生から正確に2分以上経過した時点での自動的なインスタンス再起動
誤検知を避けるための精密な条件設定と信頼性の高い自動化機構
運用負担を最小化する簡潔で保守性の高いソリューション実装
正常動作時への影響を排除した条件ベースの適切なアクション実行

前提知識

CloudWatchモニタリングレベルの特徴

基本モニタリング：無料で提供される5分間隔のメトリクス収集で、標準的なEC2監視に適用、CPU使用率、ネットワーク、ディスクI/Oなどの基本メトリクスを提供
詳細モニタリング：有料オプションとして1分間隔のメトリクス収集を提供し、より精密な監視と迅速な異常検出が可能、高解像度メトリクスによる詳細な分析をサポート
カスタムメトリクス：アプリケーション固有のメトリクスを送信可能で、ビジネス要件に応じた監視項目を設定、1秒から1分間隔での送信が可能

CloudWatchアラームの動作メカニズム

アラーム状態：OK、ALARM、INSUFFICIENT_DATAの3つの状態を持ち、メトリクス値と閾値の比較結果により状態が変化
評価期間とデータポイント：指定された評価期間内の複数データポイントを統計的に処理し、M個中N個の条件一致でアラーム状態に遷移
アクション設定：アラーム状態変化時にSNS通知、EC2アクション（再起動、停止、終了）、Auto Scalingアクションなど複数のアクションを実行可能
統計処理：Average、Maximum、Minimum、Sum、SampleCountなどの統計関数により、複数データポイントを集約して評価

EC2インスタンスアクションの種類と影響

再起動（Reboot）：インスタンスストアは維持され、EBSボリュームやElastic IPアドレスは保持、数分でサービス復旧が可能
停止（Stop）：EBSベースインスタンスのみ対応、インスタンスストアデータは失われるが、EBSデータは保持、パブリックIPアドレスは変更される可能性
終了（Terminate）：インスタンスとインスタンスストアを完全削除、EBSボリュームの削除設定に応じてデータが保持または削除

代替監視手法との比較

EC2ヘルスチェック：SystemStatusCheckとInstanceStatusCheckによりハードウェアとソフトウェア障害を検出、但しCPU使用率などの性能メトリクスは対象外
Auto Scalingヘルスチェック：インスタンスの応答性とサービス可用性を評価、アプリケーションレベルでのヘルスチェックも可能だが、特定メトリクス閾値での判定は不可
カスタム監視スクリプト：任意の監視ロジックを実装可能だが、開発・運用コストが高く、CloudWatchの標準機能と比較して信頼性面でリスク

解くための考え方

この問題は、特定の性能異常状態を精密に検出し、適切なタイミングで自動復旧アクションを実行する監視システムの設計に関するものです。CPU使用率100%という明確な異常指標と、2分以上という具体的な継続時間条件が与えられているため、これらの要件を正確に満たす技術選択が重要です。

まず、監視の精度要件を分析すると、2分以上という条件を満たすためには、少なくとも1分間隔でのメトリクス収集が必要です。5分間隔の基本モニタリングでは、最短でも5分後の検出となり、要件の2分という条件を正確に判定できません。詳細モニタリングの1分間隔であれば、2つの連続するデータポイントで条件判定が可能になります。

CloudWatchアラームの設定では、評価期間を2分、データポイント数を2、閾値をCPU使用率90%以上（100%に近い値）として設定することで、2分間連続して高CPU使用率が継続した場合のみアラームが発火するように調整できます。この設定により、一時的なCPUスパイクや短期間の高負荷による誤検知を回避できます。

アクション実行の信頼性の観点では、CloudWatchアラームのEC2アクション機能は、AWSが提供する標準的な自動化機能であり、高い信頼性と保守性を持っています。カスタムLambda関数やスクリプトベースの実装と比較して、障害点が少なく、運用負担も最小限に抑えられます。

インスタンス再起動の影響を考慮すると、再起動アクションはEBSボリュームやネットワーク設定を維持しながら、オペレーティングシステムとアプリケーションプロセスをリセットします。誤動作したプロセスを強制終了し、システムを正常状態に復旧させる効果的な手段です。

他の選択肢と比較すると、ヘルスチェックベースやスケジュールベースのアプローチは、特定の性能メトリクス条件での精密な制御ができないため、要件に適合しません。また、無条件での定期再起動は、正常動作中のサービスにも悪影響を与える可能性があります。

結論として、詳細モニタリングとCloudWatchアラームの組み合わせにより、要件を満たす精密で信頼性の高い自動復旧システムを構築でき、運用効率とシステムの可用性を同時に向上させることができます。

参考資料

問題文：
アプリケーション A は、Network Load Balancer (NLB) の背後にある Amazon EC2 インスタンスで実行されています。EC2 インスタンスは Auto Scaling グループ内にあり、NLB に関連付けられている同じサブネット内にあります。オンプレミス環境の他のアプリケーションは、ポート 8080 でアプリケーション A と通信できません。
この問題をトラブルシューティングするために、CloudOps管理者はフローログを分析しました。フローログには次のレコードが含まれています。
123456789010 eni-12345b8ca123456789 192.168.0.3 172.31.16.139 59003 8080 1 4 336 1432917027 1432917142 ACCEPT OK
123456789010 eni-12345b8ca123456789 192.168.0.3 172.31.16.139 8080 59003 1 4 336 1432917094 1432917142 REJECT OK
トラフィックが拒否された理由を選択してください。
選択肢：
A. NLB のセキュリティグループには、オンプレミス環境からのトラフィックに対する Allow ルールがありません。
B. EC2 インスタンスのセキュリティグループには、NLB からのトラフィックに対する Allow ルールがありません。
C. オンプレミス環境の ACL が、AWS 環境へのトラフィックを許可していません。
D. サブネットに関連するネットワーク ACL は、一時ポート（エフェメラルポート）範囲のアウトバウンドトラフィックを許可していません。

正解：D

A. NLB のセキュリティグループには、オンプレミス環境からのトラフィックに対する Allow ルールがありません。

不正解 Network Load Balancer自体にはセキュリティグループを直接適用することはできません。NLBはレイヤー4で動作し、トラフィックを透過的にターゲットインスタンスに転送します。セキュリティグループの制御はターゲットインスタンス側で行われるため、この選択肢は技術的に不正確です。また、フローログの分析からも異なる問題であることが明確です。

B. EC2 インスタンスのセキュリティグループには、NLB からのトラフィックに対する Allow ルールがありません。

不正解 フローログの最初のレコードでACCEPT OKが記録されており、192.168.0.3から172.31.16.139のポート8080へのインバウンドトラフィックは正常に許可されています。セキュリティグループはステートフルであるため、インバウンド接続が許可されている場合、対応するアウトバウンド応答も自動的に許可されます。問題はセキュリティグループレベルではありません。

C. オンプレミス環境の ACL が、AWS 環境へのトラフィックを許可していません。

不正解 VPCフローログはAWS環境内のネットワークインターフェイスでキャプチャされたトラフィックを記録しており、オンプレミス環境のACL設定は直接影響しません。フローログでREJECT OKが記録されているのはAWS側のネットワーク制御によるものです。オンプレミス側の問題であれば、AWS側のフローログには異なるパターンで記録されます。

D. サブネットに関連するネットワーク ACL は、一時ポート（エフェメラルポート）範囲のアウトバウンドトラフィックを許可していません。

正解フローログの2番目のレコードで、172.31.16.139のポート8080から192.168.0.3のポート59003へのアウトバウンドトラフィックがREJECT OKとなっています。ポート59003はエフェメラルポート範囲（通常1024-65535）に含まれており、ネットワークACLでこの範囲のアウトバウンドトラフィックが許可されていないことが原因です。ネットワークACLはステートレスなので明示的な許可が必要です。

問われている要件

VPCフローログレコードの詳細分析によるネットワーク通信問題の根本原因特定
インバウンドとアウトバウンドトラフィックの動作パターン理解と問題箇所の絞り込み
Network Load BalancerとEC2インスタンス間の通信フローの技術的把握
エフェメラルポート範囲とネットワークACL設定の相互関係の理解
ステートフルとステートレスなセキュリティ機能の動作差異の認識

前提知識

VPCフローログの構造と分析手法

フローログフォーマット：account-id、interface-id、srcaddr、dstaddr、srcport、dstport、protocol、packets、bytes、windowstart、windowend、action、flowlogstatusの各フィールドで構成
actionフィールド：ACCEPTは通信許可、REJECTは通信拒否を示し、セキュリティグループまたはネットワークACLによる制御結果を反映
方向性の判別：srcaddrとdstaddrの組み合わせから、インバウンドとアウトバウンドトラフィックを識別可能
トラフィック分析：同一セッション内でのリクエストとレスポンスのペアを分析することで、通信の成功・失敗パターンを特定

Network Load Balancerのアーキテクチャ特性

レイヤー4動作：IP層とトランスポート層でのパケット転送を実行し、アプリケーション層の内容は解析しない透過的な負荷分散
セキュリティグループ非適用：NLB自体にはセキュリティグループを設定できず、トラフィック制御はターゲットインスタンス側で実装
クロスゾーン負荷分散：複数のアベイラビリティゾーンのターゲットに均等にトラフィックを分散し、高可用性を実現
プリザベーション機能：送信元IPアドレスをターゲットインスタンスまで保持するため、ログ分析やアクセス制御で元の送信者を特定可能

セキュリティグループとネットワークACLの動作差異

セキュリティグループ：ステートフル動作でインバウンド許可時に対応するアウトバウンドを自動許可、インスタンスレベルでの制御を実行
ネットワークACL：ステートレス動作でインバウンドとアウトバウンドを個別に制御、サブネットレベルでの包括的なトラフィック制御を提供
ルール評価順序：ネットワークACLは番号順に評価され最初にマッチしたルールを適用、セキュリティグループは全てのルールが評価される
デフォルト設定：デフォルトネットワークACLは全トラフィック許可、カスタムネットワークACLは全トラフィック拒否の初期状態

エフェメラルポートとポート範囲管理

エフェメラルポート定義：クライアント側で動的に割り当てられる一時的なポート番号で、通常1024から65535の範囲で使用
OS依存の範囲設定：LinuxやWindowsなどのOSごとに異なるエフェメラルポート範囲が設定され、NAT Gatewayでは1024-65535を使用
ネットワークACL設定：エフェメラルポート範囲のアウトバウンド通信を明示的に許可しないと、TCPセッションの応答パケットが拒否される
アプリケーション影響：Webアプリケーションやデータベースアクセスで、クライアントからのリクエストに対する応答が正常に返信されない障害が発生

解くための考え方

フローログ分析によるネットワーク問題の診断では、まずトラフィックの方向性と結果を正確に理解することが重要です。提供されたフローログレコードを詳しく分析すると、明確なパターンが見えてきます。

最初のレコード「192.168.0.3 172.31.16.139 59003 8080」は、オンプレミス環境（192.168.0.3）からEC2インスタンス（172.31.16.139）のポート8080へのインバウンド接続を示しており、結果はACCEPT OKとなっています。これは、セキュリティグループやネットワークACLのインバウンドルールが適切に設定されていることを意味します。

問題は2番目のレコード「172.31.16.139 8080 59003」で明らかになります。これはEC2インスタンスのポート8080からオンプレミス環境のポート59003（エフェメラルポート）への応答トラフィックを示しており、結果はREJECT OKとなっています。TCPセッションでは、クライアントがサーバーに接続した後、サーバーからクライアントに応答パケットが返信される必要がありますが、この応答が拒否されているため、通信全体が失敗しています。

ネットワークACLの動作特性を考慮すると、ステートレスな制御であるため、インバウンドとアウトバウンドのルールを個別に設定する必要があります。多くの場合、インバウンドのHTTP/HTTPSポート（80、443、8080など）は明示的に許可されますが、エフェメラルポート範囲のアウトバウンド通信は見落とされがちです。

エフェメラルポート59003は、クライアント側で動的に割り当てられたポート番号で、サーバーからの応答を受信するために使用されます。ネットワークACLでこの範囲（通常1024-65535）のアウトバウンド通信が許可されていない場合、TCPハンドシェイクは正常に完了せず、アプリケーションレベルでの通信エラーが発生します。

セキュリティグループが原因ではない理由は、ステートフル動作により、インバウンド接続が許可された場合、対応するアウトバウンド応答が自動的に許可されるためです。フローログでインバウンドがACCEPTされているのに、セキュリティグループがアウトバウンドを拒否することは技術的にありえません。

解決策としては、サブネットに関連付けられたネットワークACLのアウトバウンドルールに、エフェメラルポート範囲（1024-65535）への通信を許可するルールを追加する必要があります。これにより、インバウンド接続に対する適切な応答が可能になり、オンプレミス環境からアプリケーションAへの通信が正常に動作するようになります。

参考資料

問題文：
ある企業が新しいアプリケーションを Amazon EC2 インスタンスにデプロイします。アプリケーションコードは Git Hubリポジトリに保存されています。同社は、AWS CodePipeline を使用して継続的インテグレーションおよびデリバリープロセスで EC2 インスタンスにコードをデプロイします。
CloudOps管理者は、機密データベース情報が EC2 インスタンス上で適切に構成されていることを確認し、認証情報の偶発的な漏洩を防ぐ必要があります。
最も安全な方法で機密情報を保存および取得できるソリューションを選択してください。（2つ選択）
選択肢：
A. AWS Secrets Manager に値を保存します。アプリケーションの起動時にこれらの値を取得するようにコードを更新します。環境変数として値を保存します。
B. EC2 インスタンス上のファイルに構成情報を保存します。基盤となるドライブが AWS Key Management Service (AWS KMS) によって暗号化されていることを確認し、アプリケーションの起動時にファイルを読み込むようにアプリケーションを更新します。
C. AWS Lambda 関数に値を保存します。アプリケーションの起動時に Lambda 関数を呼び出すようにコードを更新します。環境変数として値を挿入するよう Lambda 関数を設定します。
D. AWS Systems Manager Parameter Store に値を Secure String として保存します。アプリケーションの起動時にこれらの値を取得するようにコードを更新します。環境変数として値を保存します。
E. Amazon S3 バケット内のテキストファイルに値を保存します。CI/CD パイプラインで、アプリケーションが読み取り可能なディスク上の適切な場所にある EC2 インスタンスにファイルをコピーします。

正解：A, D

A. AWS Secrets Manager に値を保存します。アプリケーションの起動時にこれらの値を取得するようにコードを更新します。環境変数として値を保存します。

正解 AWS Secrets Managerは機密情報管理に特化したマネージドサービスで、データベース認証情報の保存と取得に最適化されています。AES-256暗号化、IAMによるきめ細かなアクセス制御、自動ローテーション機能、監査ログ機能を提供し、認証情報の漏洩リスクを最小限に抑えます。アプリケーション起動時のAPI呼び出しで安全に取得可能です。

B. EC2 インスタンス上のファイルに構成情報を保存します。基盤となるドライブが AWS Key Management Service (AWS KMS) によって暗号化されていることを確認し、アプリケーションの起動時にファイルを読み込むようにアプリケーションを更新します。

不正解 EC2インスタンス上のファイル保存は複数のセキュリティリスクを内包します。インスタンスへの不正アクセス時のファイル直接読み取り、適切なファイル権限設定の管理負担、インスタンススナップショットやAMIでの意図しない機密情報の複製などが問題となります。KMS暗号化だけでは包括的な保護は不十分です。

C. AWS Lambda 関数に値を保存します。アプリケーションの起動時に Lambda 関数を呼び出すようにコードを更新します。環境変数として値を挿入するよう Lambda 関数を設定します。

不正解 Lambda関数は機密情報の永続的な保存用途に設計されておらず、関数コード内やレイヤーに機密情報を保存することは重大なセキュリティリスクです。関数のソースコード閲覧、CloudWatch Logsでの意図しない出力、関数の更新時の機密情報露出などの危険性があり、適切な機密情報管理手法ではありません。

D. AWS Systems Manager Parameter Store に値を Secure String として保存します。アプリケーションの起動時にこれらの値を取得するようにコードを更新します。環境変数として値を保存します。

正解 Systems Manager Parameter StoreのSecure String機能は、KMS暗号化による機密パラメータの安全な保存を提供します。IAMによる詳細なアクセス制御、バージョン管理機能、CloudTrailによる監査ログ記録が可能で、コスト効率が高く機密情報管理に適しています。アプリケーションから直接API経由で安全に取得できます。

E. Amazon S3 バケット内のテキストファイルに値を保存します。CI/CD パイプラインで、アプリケーションが読み取り可能なディスク上の適切な場所にある EC2 インスタンスにファイルをコピーします。

不正解 S3バケットでのテキストファイル保存は、一般的なオブジェクトストレージでの機密情報管理であり、専門的なセキュリティ機能が不足しています。バケットポリシーの設定ミス、パブリックアクセスの意図しない有効化、ファイルの平文での保存リスクなど、機密情報管理には不適切な手法です。

問われている要件

データベース認証情報などの機密情報の安全な保存と暗号化による保護
CI/CDパイプラインを通じた自動デプロイ時の認証情報の安全な取得機構
認証情報の偶発的な漏洩防止とアクセス制御の厳格な管理
アプリケーション起動時の効率的で自動化された機密情報取得プロセス
監査要件とコンプライアンス対応を考慮したセキュリティベストプラクティスの実装

前提知識

機密情報管理専用サービスの特徴

AWS Secrets Manager：データベースやAPIキーなどの機密情報管理に特化し、RDSやAuroraとの統合による自動ローテーション機能を提供、JSON形式での複雑な認証情報構造をサポート
Parameter Store Secure String：KMS暗号化によるパラメータ保護機能で、階層化された名前空間管理と詳細なアクセス制御を実現、標準ティアとアドバンスティアでの機能差異
暗号化とキー管理：AWS KMSとの統合により、カスタマーマネージドキーまたはAWSマネージドキーでの暗号化オプションを選択可能
自動ローテーション：Secrets Managerでは事前定義されたLambda関数による認証情報の定期的な更新を自動実行

CI/CDパイプラインでの機密情報管理

CodePipeline統合：ビルドおよびデプロイステージでの環境変数としての機密情報注入機能により、ソースコードからの機密情報分離を実現
IAMロール設定：EC2インスタンスやCodeBuildサービスロールに適切な権限を付与し、最小権限の原則に基づいたアクセス制御を実装
環境固有設定：開発、ステージング、本番環境ごとの異なる認証情報を安全に管理し、環境間の設定ミスを防止
デプロイ時セキュリティ：デプロイプロセス中の一時的な認証情報露出を防ぎ、ログやデバッグ情報での意図しない出力を回避

従来手法との比較とリスク分析

ファイルベース保存：設定ファイルや環境ファイルでの平文保存は、ファイルシステムレベルでのアクセス制御の複雑性とバックアップ時の機密情報露出リスク
ハードコーディング：ソースコード内への直接記述は、バージョン管理システムでの履歴保持とコードレビュー時の機密情報漏洩の最大リスク要因
環境変数のみ：プロセス環境での平文保存は、メモリダンプやプロセス一覧での機密情報の意図しない露出可能性
S3オブジェクト：専用機密情報管理機能の欠如により、バージョニングとライフサイクル管理での複雑性増大

アクセス制御とモニタリング機能

IAM統合：リソースベースポリシーとIDベースポリシーの組み合わせによる詳細なアクセス権限制御とクロスアカウントアクセス管理
CloudTrail監査：機密情報へのアクセス履歴の完全な記録と、異常なアクセスパターンの検出による包括的な監査証跡
VPCエンドポイント：プライベートネットワーク経由でのAPI呼び出しにより、機密情報取得時のネットワークレベルでのセキュリティ強化
タグベース制御：リソースタグを活用した条件付きアクセス制御により、環境やプロジェクト単位での機密情報の分離管理

解くための考え方

機密データベース情報の安全な管理において、最も重要な原則は「機密情報の専門的な管理サービスの利用」と「最小権限アクセスの実装」です。従来のファイルベースやハードコーディングによる管理手法は、現代のクラウドセキュリティ要件を満たすことができません。

AWS Secrets Managerは、機密情報管理に特化して設計されたサービスで、データベース認証情報の管理において理想的な機能を提供します。特に重要なのは自動ローテーション機能で、定期的にパスワードを変更することで、長期間同一の認証情報を使用することによるリスクを大幅に軽減できます。また、RDSやAuroraとのネイティブ統合により、データベースエンジンレベルでの認証情報更新を自動化できます。

Systems Manager Parameter StoreのSecure String機能は、コスト効率と機能性のバランスが優れた選択肢です。特に、階層化されたパラメータ管理により、環境やアプリケーションごとの設定を体系的に整理でき、大規模なシステムでの運用効率を向上させます。KMS統合により、暗号化キーの管理も柔軟に対応できます。

CI/CDパイプラインでの機密情報取得において、これらの専門サービスを活用することで、ソースコード内での機密情報の露出を完全に排除できます。デプロイ時にアプリケーションが直接APIを呼び出して必要な認証情報を取得する仕組みにより、デプロイパッケージ内に機密情報を含める必要がなくなります。

アクセス制御の観点では、IAMロールとポリシーを適切に設定することで、必要な機密情報にのみアクセス可能な権限体系を構築できます。また、CloudTrailによる監査ログにより、いつ、誰が、どの機密情報にアクセスしたかを完全に追跡可能で、セキュリティインシデント発生時の迅速な対応を支援します。

環境変数への機密情報設定については、アプリケーション起動時にAPI経由で取得した値を環境変数に設定する方式により、プロセスレベルでの一時的な保存は許容されます。重要なのは、永続的な保存場所として専門的な管理サービスを使用し、取得プロセスを自動化することです。

結論として、AWS Secrets ManagerとSystems Manager Parameter Store Secure Stringの組み合わせにより、包括的で多層的な機密情報管理体制を構築でき、企業のセキュリティ要件とコンプライアンス要件を同時に満たすことができます。

参考資料

問題文：
ある企業では、内部向けのWebアプリケーションを運用しており、Amazon EC2インスタンス上で実行されています。これらのインスタンスは、Application Load Balancer（ALB）の背後に配置されており、単一のAvailability Zone（AZ）内のAmazon EC2 Auto Scalingグループで管理されています。
CloudOps管理者は、このアプリケーションの可用性を高める必要があります。
CloudOps管理者は、要件を満たすためにどのアクションを取るべきですか？
選択肢：
A. Auto Scalingグループの最大インスタンス数を増やし、ピーク時の需要に対応できるようにする。
B. Auto Scalingグループの最小インスタンス数を増やし、ピーク時の需要に対応できるようにする。
C. Auto Scalingグループを更新し、同じAWSリージョン内の第2のAvailability Zoneに新しいインスタンスを起動できるようにする。
D. Auto Scalingグループを更新し、異なるAWSリージョンのAvailability Zoneに新しいインスタンスを起動できるようにする。

正解：C

A. Auto Scalingグループの最大インスタンス数を増やし、ピーク時の需要に対応できるようにする。

不正解 最大インスタンス数の増加はスケーラビリティ向上には有効ですが、可用性改善にはなりません。単一AZ内でインスタンス数を増やしても、そのAZで障害が発生した場合、全てのインスタンスが同時に影響を受けるため、単一障害点の問題は解決されません。可用性向上には地理的な分散が必要です。

B. Auto Scalingグループの最小インスタンス数を増やし、ピーク時の需要に対応できるようにする。

不正解 最小インスタンス数の増加は基本キャパシティの確保には役立ちますが、可用性向上にはつながりません。単一AZ構成では、AZ障害時に全インスタンスが停止するリスクが残り続けます。冗長性の確保には複数AZへの分散配置が必要で、インスタンス数の増加だけでは根本的な解決策になりません。

C. Auto Scalingグループを更新し、同じAWSリージョン内の第2のAvailability Zoneに新しいインスタンスを起動できるようにする。

正解 Auto Scalingグループを複数AZに拡張することで、真の高可用性を実現できます。一つのAZで障害が発生しても、他のAZのインスタンスが継続稼働し、ALBが自動的に健全なインスタンスにトラフィックをルーティングします。これにより単一障害点が排除され、システム全体の可用性が大幅に向上します。

D. Auto Scalingグループを更新し、異なるAWSリージョンのAvailability Zoneに新しいインスタンスを起動できるようにする。

不正解 Auto Scalingグループは単一リージョン内でのみ動作する仕組みのため、異なるリージョンのAZにインスタンスを配置することは技術的に不可能です。マルチリージョン構成を実現するには、各リージョンに独立したAuto Scalingグループを作成し、Route 53のDNSフェイルオーバー機能などを組み合わせた別のアーキテクチャが必要です。

問われている要件

単一AZ構成による単一障害点の排除と高可用性アーキテクチャの実現
Application Load Balancerと連携した効果的な冗長性の確保
システム障害時の自動フェイルオーバー機能の実装
既存のAuto Scalingグループ構成の最適化による可用性改善
内部Webアプリケーションの継続的なサービス提供能力の向上

前提知識

高可用性アーキテクチャの基本原則

単一障害点排除：システム内の単一コンポーネント障害でサービス全体が停止しない設計原則で、冗長化による耐障害性向上を実現
Availability Zone分散：物理的に独立したデータセンター間でのリソース分散配置により、局所的障害への耐性を確保
自動フェイルオーバー：障害検知時の自動的なトラフィック切り替え機能により、手動介入なしでのサービス継続を実現
負荷分散：複数のコンピュートリソース間でのトラフィック分散により、個別リソースの障害影響を最小化

Auto ScalingグループとマルチAZ構成

AZ間インスタンス分散：Auto Scalingグループの複数AZ設定により、各AZに均等にインスタンスを配置し、AZ障害時の影響を局所化
ヘルスチェック連携：EC2ヘルスチェックとELBヘルスチェックの組み合わせにより、インスタンスとアプリケーション層双方の健全性を監視
自動置換機能：不健全なインスタンスの自動検知と新しいインスタンスでの置換により、常時健全なキャパシティを維持
スケーリングポリシー：各AZ内でのバランスを保ちながらのスケールアウト・インにより、可用性を維持した動的な容量調整を実現

Application Load Balancerの高可用性機能

クロスAZ負荷分散：複数AZのターゲットインスタンス間での自動的なトラフィック分散により、単一AZへの集中を回避
ヘルスチェック機能：定期的なターゲット健全性確認により、異常インスタンスへのトラフィック送信を自動停止
ゾーン障害時の自動迂回：特定AZ障害時の自動的なトラフィック再ルーティングにより、ユーザー影響を最小化
スティッキーセッション：必要に応じたセッション維持機能により、アプリケーション要件との両立を実現

リージョンとAZの関係性

リージョン内AZ：同一リージョン内の複数AZは低レイテンシネットワークで接続され、同期レプリケーションや負荷分散に適用
AZ独立性：各AZは独立した電力供給、冷却システム、ネットワーク接続を持ち、他AZの障害から物理的に隔離
Auto Scalingグループの制約：単一リージョン内でのみ動作する仕様により、リージョン間での自動スケーリングは不可
マルチリージョン戦略：災害復旧やより広範囲な障害対策には、Route 53やCloudFormationスタックセットなど別の仕組みが必要

解くための考え方

高可用性の実現において最も重要なのは、システム内の単一障害点を特定し、適切な冗長化戦略を実装することです。現在の構成では、全てのEC2インスタンスが単一のAvailability Zone内に配置されているため、そのAZで障害が発生した場合、アプリケーション全体が利用不可能になる重大なリスクがあります。

AWSの高可用性設計において、Availability Zoneレベルでの分散配置は基本的なベストプラクティスです。各AZは物理的に独立したデータセンターであり、電力供給、ネットワーク接続、冷却システムなどが完全に分離されています。そのため、一つのAZで障害が発生しても、他のAZは正常に動作し続けることができます。

Auto Scalingグループを複数のAZに拡張することで、インスタンスが自動的に複数のAZ間に分散配置されます。この設定により、Auto Scalingグループは各AZに均等にインスタンスを配置しようとし、特定のAZが利用不可能になった場合でも、残りのAZでサービスを継続できます。

Application Load Balancerは、この多AZ構成と完璧に連携します。ALBは定期的にヘルスチェックを実行し、異常なインスタンスを自動的に検出してトラフィックの配信を停止します。AZ障害時には、影響を受けたAZ内の全インスタンスが自動的に配信対象から除外され、健全なAZのインスタンスのみにトラフィックが転送されます。

インスタンス数の増加は、処理能力の向上には有効ですが、可用性の根本的な改善にはなりません。単一AZ内でどれだけインスタンス数を増やしても、そのAZ全体が障害を起こせば、全てのインスタンスが同時に影響を受けることに変わりはありません。

マルチリージョン構成は、より広範囲な災害に対する保護を提供しますが、Auto Scalingグループの仕組みでは実現できません。Auto Scalingグループは単一リージョン内でのみ動作するように設計されており、異なるリージョンのリソースを管理することはできません。マルチリージョン構成を実現するには、各リージョンに独立したインフラを構築し、Route 53のDNSベースのフェイルオーバー機能などを活用する必要があります。

結論として、既存のAuto Scalingグループ設定を複数AZに拡張することで、最小限の変更で最大の可用性向上効果を得ることができ、コスト効率と運用効率の両面で最適なソリューションとなります。

参考資料

筆者のUdemy講師ページはこちら。

【無料】AWS SOA-C03練習問題15問｜Udemy講師作成

スポンサーリンク