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

正解: B, C, D

A. 各チームのアカウントにドメインを作成し、それぞれのドメイン内で読み取りおよび書き込み権限を付与する。

不正解 この方法では各チームのアカウントにCodeArtifactドメインを個別に作成することになります。ドメインは管理の単位であり、各ドメインごとに権限設定やポリシー管理が必要になります。組織全体で多数のチームがある場合、ドメインごとの設定と管理が必要になるため管理オーバーヘッドが大きくなります。
また、組織全体で共有ライブラリへのアクセスを提供するためには、各ドメイン間での権限設定が複雑になり、「最小限の管理労力」という要件を満たせません。

B. 共有サービスアカウントにドメインを作成し、組織全体の読み取りアクセスと CreateRepository 権限を付与する。

正解 共有サービスアカウントに単一のCodeArtifactドメインを作成し、組織全体に読み取りアクセスとリポジトリ作成権限を付与する方法は、管理を一元化できます。ドメインはCodeArtifactの最上位のリソースであり、1つのドメインを中央で管理することで設定の一貫性が保たれます。
組織全体に読み取りアクセスを付与することで共有ライブラリを全チームが利用でき、CreateRepository権限によって各チームは必要に応じて自分のリポジトリを作成できます。
これにより、管理の簡素化と組織全体での共有を同時に実現できます。

C. 各チームのアカウントにリポジトリを作成し、チームにそのリポジトリへの完全な読み取りおよび書き込み権限を付与する。

正解 この方法では、各チームが自身のアカウント内にリポジトリを作成し、そのリポジトリに対する完全な管理権限を持つことができます。これにより、各チームは自分たちのパッケージを独自に管理できる柔軟性が確保されます。
チーム固有のパッケージ管理においては、チームが自律的に操作できることが重要であり、この方法はその要件を満たします。各チームが自分たちの開発サイクルに合わせてパッケージをアップロードしたり、バージョン管理したりする際に、他チームの承認を待つ必要がなく効率的です。

D. 共有サービスアカウントにリポジトリを作成し、組織全体に読み取りアクセスを付与し、このリポジトリを各チームのリポジトリのアップストリームリポジトリとして設定する。

正解 この設定では、共有サービスアカウントに共有ライブラリ用のリポジトリを作成し、組織全体がそれを読み取れるようにします。
さらに、各チームのリポジトリからこの共有リポジトリを「アップストリームリポジトリ」として参照できるようにします。アップストリーム設定により、チームのリポジトリにパッケージがない場合、自動的に共有リポジトリから取得できるようになります。
これは共有ライブラリを効率的に利用するための最適な方法で、各チームが共有ライブラリを個別にコピーする必要がなくなり、一貫性のあるバージョン管理が可能になります。

E. チーム間で共有パッケージが必要な場合に、他のチームのアカウントからの読み取りアクセスを有効にするリソースポリシーを作成する。

不正解 各チーム間で個別にリソースポリシーを設定して読み取りアクセスを許可する方法は、チーム数が増えるにつれて管理が複雑になります。
N個のチームがあれば、潜在的にN×(N-1)の権限設定が必要になる可能性があります。また、新しいチームが追加されるたびに既存のポリシーを更新する必要があり、スケーラビリティに欠けます。
さらに、この方法は前述の中央管理アプローチと重複し、追加の複雑性をもたらすだけです。「最小限の管理労力」という要件を考えると、この方法は効率的とは言えません。

F. 他のチームのリポジトリをアップストリームリポジトリとして指定する。

不正解 各チームが他チームのリポジトリを直接アップストリームリポジトリとして指定する方法は、依存関係が複雑になる可能性があります。
チームA→チームB→チームCという依存関係が生まれると、変更の影響範囲の追跡が難しくなります。また、特定のチームのリポジトリに依存することで、そのチームの変更が他チームに予期せぬ影響を与える可能性があります。
さらに、チーム間の直接依存は、一元的な管理や一貫性の確保を難しくします。共有ライブラリは中央管理された共有サービスアカウントで管理する方が効率的で一貫性が保たれます。

問われている要件

この問題では、AWS Organizationsを使用して複数のAWSアカウントを管理する企業が、AWS CodeArtifactを使用してアプリケーションのパッケージ管理を組織全体でサポートするための最適な方法を問うています。主な要件は以下の通りです：

1. 各アプリケーションチームには専用のアカウントがあり、共有サービスアカウントへの制限付きアクセスがある
2. 各チームは自身のパッケージを管理する十分な権限が必要
3. 一部の共有ライブラリは組織全体でアクセス可能にする必要がある
4. これらの要件を最小限の管理労力で満たすこと

これらの要件を満たすためには、中央集権的な管理と各チームの自律性のバランスを取る必要があります。

前提知識

AWS CodeArtifact

AWS CodeArtifactは、ソフトウェア開発プロセスで使用されるパッケージ（ライブラリやフレームワークなど）の管理を行うフルマネージドサービスです。主な特徴と概念は以下の通りです：

1. ドメイン（Domain）：
   • CodeArtifactの最上位のリソースで、リポジトリの論理的なグループ
   • 1つのAWSアカウントには複数のドメインを作成可能
   • ドメイン内のリポジトリは、同じドメイン内の他のリポジトリをアップストリームとして参照可能
   • 異なるAWSアカウント間でドメインを共有することも可能
2. リポジトリ（Repository）：
   • パッケージを格納する場所
   • 特定のパッケージタイプ（npm、Maven、PyPI、Nugetなど）をサポート
   • 1つのドメインには複数のリポジトリを作成可能
3. アップストリームリポジトリ（Upstream Repository）：
   • あるリポジトリが別のリポジトリをアップストリームとして参照することができる仕組み
   • リポジトリ内でパッケージが見つからない場合、アップストリームリポジトリが自動的に検索される
   • これにより、パッケージの依存関係を効率的に解決できる
   • パッケージが見つかると、そのパッケージは自動的にリポジトリにコピーされる（キャッシング）
4. パブリックリポジトリ接続：
   • CodeArtifactリポジトリからnpmjs.orgやMaven Centralなどのパブリックリポジトリに接続可能
   • これにより、パブリックパッケージを安全に利用できる
5. リソースポリシー：
   • リソース（ドメインやリポジトリ）へのアクセス制御を細かく設定可能
   • 組織内の特定のアカウントやIAMプリンシパルにリソースへのアクセスを許可できる

AWS Organizations

AWS Organizationsは、複数のAWSアカウントを一元管理するためのサービスです。主な機能は以下の通りです：

1. アカウント管理：
   • 複数のAWSアカウントを組織単位（OU）に整理
   • アカウントの一元的な作成と管理
2. 一元的なポリシー管理：
   • サービスコントロールポリシー（SCP）を使用してアカウント間で一貫したポリシーを適用
   • タグポリシーやバックアップポリシーの一元管理
3. 一括請求：
   • 組織内のすべてのアカウントの一括請求
   • ボリュームディスカウントの適用

クロスアカウントアクセス

AWSでは、異なるアカウント間でのリソース共有やアクセス許可を設定する方法がいくつかあります：

1. IAMロールの引き受け（AssumeRole）：
   • あるアカウントのIAMエンティティが別のアカウントのIAMロールを引き受ける
   • 一時的な認証情報を使用して、別アカウントのリソースにアクセス
2. リソースポリシー：
   • S3バケットポリシーやCodeArtifactリソースポリシーなど
   • リソース側でどのプリンシパル（ユーザー、ロール、アカウント）がアクセスできるかを定義
3. AWS Resource Access Manager（RAM）：
   • 特定のAWSリソースを複数のアカウントと共有するためのサービス
   • 共有可能なリソースタイプは限定的

マルチアカウント戦略のベストプラクティス

1. 中央集権型管理：
   • 共通サービスやツールは中央のアカウントで管理
   • 各チームや環境に専用のアカウントを提供
2. 最小権限の原則：
   • 各アカウントやIAMエンティティには必要最小限の権限のみを付与
   • 権限の範囲を制限することでセキュリティリスクを最小化
3. 自律性とガバナンスのバランス：
   • チームに十分な自律性を与える一方で、組織全体の一貫性やコンプライアンスを確保
   • ガードレールを設定しつつ、イノベーションを妨げない

解くための考え方

この問題を解くためには、以下の点を考慮する必要があります：

1. 管理の複雑さを最小化：
   • 多数のドメインやリポジトリを個別に管理するのではなく、中央で管理する方法を検討
   • 権限設定やポリシー管理の回数を減らす方法を考える
2. チームの自律性の確保：
   • 各チームが自身のパッケージを独自に管理できる権限を確保
   • チーム固有の開発サイクルに影響を与えない構成を検討
3. 共有ライブラリへのアクセス：
   • 組織全体で共有ライブラリにアクセスする効率的な方法を検討
   • 一貫性のあるバージョン管理と配布を確保

これらの考慮点に基づくと、最適な解決策は以下の組み合わせになります：

1. 共有サービスアカウントに1つのドメインを作成し、組織全体に読み取りアクセスとCreateRepository権限を付与する
2. 各チームがそのドメイン内に自分たちのリポジトリを作成し、そのリポジトリに対する完全な管理権限を持つ
3. 共有ライブラリ用のリポジトリを共有サービスアカウントに作成し、それを各チームのリポジトリのアップストリームリポジトリとして設定する

この組み合わせにより、中央管理と各チームの自律性のバランスを取りながら、最小限の管理労力で要件を満たすことができます。

参考資料

• AWS CodeArtifact のドメイン
• AWS CodeArtifact とは
• AWS CodeArtifact の概念
• AWS CodeArtifact のリポジトリ
• ドメインポリシー

正解: D

A. 管理アカウント用の新しい組織単位 (OU) を作成し、アカウントをそこに移動する。現在の SCP を削除し、新しい OU に適用する。

不正解 この方法には根本的な問題があります。サービスコントロールポリシー(SCP)は組織内の管理アカウントには効果がないという特性があります。SCPは管理アカウント以外のメンバーアカウントにのみ影響します。そのため、管理アカウントを新しいOUに移動し、そのOUにSCPを適用したとしても、SCPは管理アカウントには影響せず、DevOpsチームは引き続きIAM Identity Centerにアクセスできてしまいます。SCPを使用しての管理アカウントへのアクセス制限は不可能です。

B. 管理アカウント内の SCP を修正し、DevOps グループのロール ARN を参照する条件を追加して、管理アカウントの AWS ID を含める。

不正解 この方法には根本的な問題があります。サービスコントロールポリシー(SCP)は組織内の管理アカウントには効果がないという特性があります。SCPは管理アカウント以外のメンバーアカウントにのみ影響します。そのため、SCPを修正して条件を追加しても、管理アカウント内でのDevOpsチームの権限には影響しません。
C. IAM Identity Center に新しいパーミッションセットを作成し、一般的なアクセスを許可するが、sso:* および sso-directory:* アクションを明示的に拒否する。このパーミッションセットを DevOps グループに管理アカウント内で割り当てる。

不正解 この方法は、既存のパーミッションセット(AdministratorAccess)と競合する新しいパーミッションセットを作成するため複雑になります。DevOpsグループにはすでに「DevOps」という名前のパーミッションセットが割り当てられており、それにはAdministratorAccessポリシーが含まれています。このパーミッションセットを残したまま新しいパーミッションセットを追加しても、IAMの評価ロジックにより、明示的な拒否がない限り許可が優先されるため、既存のAdministratorAccessポリシーが引き続き有効になる可能性があります。

D. 現在の DevOps パーミッションセットを修正し、sso:* および sso-directory:* アクションを拒否する明示的な条件を追加し、aws:SourceAccount と管理アカウント ID を比較する条件を含める。

正解 この方法は、既存のDevOpsパーミッションセットを直接修正し、管理アカウントでのIAM Identity Center関連のアクション(sso:およびsso-directory:)を明示的に拒否する条件を追加するアプローチです。aws:SourceAccount条件キーを使用して管理アカウントIDと一致する場合にのみこの制限を適用することで、他のアカウントでの権限には影響を与えずに、管理アカウントでのIAM Identity Centerへのアクセスを制限できます。パーミッションセットの修正は、既存の権限構造を大きく変更せずに目的を達成できます。

問われている要件

この問題では、AWS Organizationsを利用している組織において、DevOpsチームが管理アカウント内でIAM Identity Centerにアクセスできないようにする方法を問うています。現状、DevOpsチームには「DevOps」という名前のパーミッションセットが割り当てられており、そのパーミッションセットにはAdministratorAccess IAM管理ポリシーが含まれています。セキュリティチームは組織のルートにSCPを適用してアクセスを制限しようとしましたが、DevOpsチームは依然としてアクセスできています。問題を解決するための最も効果的な方法を選択する必要があります。

前提知識

AWS Organizations

AWS Organizationsは、複数のAWSアカウントを一元管理するためのサービスで、以下の主要な特性があります：

1. 組織構造：
   • 管理アカウント：組織の作成と管理を行う最上位のアカウント
   • メンバーアカウント：組織に属する他のアカウント
   • 組織単位（OU）：アカウントを論理的にグループ化する構造
2. サービスコントロールポリシー（SCP）：
   • 組織内のアカウントに対するアクセス許可の上限を設定するポリシー
   • IAMユーザーやロールが持つ権限の「ガードレール」として機能
   • 重要な制限: SCPは管理アカウントには適用されない
3. 一括請求：
   • 組織内のすべてのアカウントの使用料を一括で管理

IAM Identity Center (旧AWS SSO)

IAM Identity Centerは、複数のAWSアカウントとアプリケーションへのシングルサインオンアクセスを提供するサービスです：

1. パーミッションセット：
   • IAM Identity Centerで定義される権限のコレクション
   • AWS管理ポリシー（例：AdministratorAccess）をベースにすることができる
   • カスタム権限を定義することも可能
2. グループと割り当て：
   • IDプロバイダー（例：Active Directory）から同期されたユーザーグループ
   • グループにパーミッションセットを割り当て、それを特定のAWSアカウントに適用
3. アクセス制御：
   • パーミッションセットはIAMロールとして各アカウントにプロビジョニングされる
   • ユーザーがアカウントにアクセスすると、対応するIAMロールが引き受けられる

IAMポリシーの評価ロジック

IAMポリシーは以下のロジックで評価されます：

1. 明示的な拒否：ポリシー内に明示的な拒否（”Effect”: “Deny”）がある場合、そのアクセスは拒否される
2. 明示的な許可：明示的な拒否がなく、明示的な許可（”Effect”: “Allow”）がある場合、アクセスは許可される
3. 暗黙的な拒否：明示的な許可がない場合、デフォルトでアクセスは拒否される

IAMポリシーの条件キー

IAMポリシーには条件キーを使用して、ポリシーが適用される条件を詳細に指定できます：

1. aws:SourceAccount：リクエストの送信元のアカウントIDを指定
2. aws:PrincipalOrgID：プリンシパルが属する組織IDを指定
3. aws:ResourceAccount：リソースが属するアカウントIDを指定

解くための考え方

この問題を解決するためには、以下の要点を考慮する必要があります：

1. SCPの制限を理解する：
   • SCPは管理アカウントには適用されないため、管理アカウント内でのアクセス制限には別のアプローチが必要
   • DevOpsチームがIAM Identity Centerにアクセスできている原因はここにある
2. パーミッションセットの役割を理解する：
   • DevOpsチームには「DevOps」という名前のパーミッションセットが割り当てられている
   • このパーミッションセットにはAdministratorAccess IAM管理ポリシーが含まれている
   • この広範な権限により、DevOpsチームは管理アカウント内でIAM Identity Centerにアクセスできる
3. 最小特権の原則を適用する：
   • DevOpsチームには必要な権限を維持しつつ、IAM Identity Centerへのアクセスのみを制限する
   • 具体的には、sso:*およびsso-directory:*アクションを制限する
4. 条件付きアクセス制御を実装する：
   • 特定のアカウント（管理アカウント）でのみ制限を適用するために条件キーを使用する
   • aws:SourceAccountを使用して、管理アカウントIDと一致する場合にのみ制限を適用する

これらの考慮点を踏まえると、最適なアプローチは既存のDevOpsパーミッションセットを修正し、管理アカウントでのIAM Identity Center関連アクションを明示的に拒否することです。これにより、DevOpsチームは他のリソースやメンバーアカウントへのアクセスを維持しつつ、管理アカウント内でのIAM Identity Centerへのアクセスが制限されます。

パーミッションセットの修正例：

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Deny",
            "Action": [
                "sso:*",
                "sso-directory:*"
            ],
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "aws:SourceAccount": "管理アカウントID"
                }
            }
        },
        {
            "Effect": "Allow",
            "Action": "*",
            "Resource": "*"
        }
    ]
}

このポリシーでは、管理アカウントからのリクエストの場合にのみsso:*およびsso-directory:*アクションを明示的に拒否し、それ以外のすべてのアクションを許可しています。

参考資料

• IAM Identity Center (AWS SSO) の概要
• サービスコントロールポリシー (SCP)
• IAM ポリシーでの条件キー aws:SourceAccount の使用
• AWS Organizations のアカウント管理

正解: D

A. Organizations組織のバックアップポリシーを実装し、すべてのロググループデータを指定された S3 バケットに保存するように設定する。S3 バケットポリシーを更新して、組織内のすべてのアカウントがアクセスできるようにする。

不正解 AWS Organizationsのバックアップポリシーは主にAWS Backupサービスを制御するためのものであり、CloudWatch Logsデータを直接S3バケットにリアルタイムに転送する機能はありません。

B. AWS Backup を使用してバックアッププランを作成し、特定の S3 バケットをリポジトリとして指定する。このプランにロググループリソースを割り当て、すべての組織アカウントを対象に含める。

不正解 AWS Backupは現在、CloudWatch Logsをネイティブにサポートしていないため、このアプローチは技術的に実装できません。AWS Backupは主にEC2インスタンス、RDSデータベース、DynamoDBテーブル、EFSファイルシステムなどのリソースのバックアップを管理するためのサービスであり、CloudWatch Logsリソースは直接のバックアップ対象として設定できません。また、AWS Backupは定期的なスナップショットによるバックアップを行うサービスであり、リアルタイムデータ転送という要件も満たせません。

C. AWS Backup を使用して集中管理された S3 バケットを対象とするバックアッププランを作成する。現在のすべてのロググループをプランにリンクし、組織内のすべてのアカウントを対象に含める。AWS Systems Manager Automation を使用して新しいロググループを関連付け、AWS Config ルールと自動修正を使用して実装する。

不正解 AWS BackupはCloudWatch Logsをネイティブにサポートしていません。また、AWS BackupとSystems Managerを組み合わせたアプローチは複雑であり、リアルタイムのログデータ転送には不適切です。この方法では新しいロググループの処理に手動設定が必要になる可能性が高いです。

D. CloudWatch Logs の出力先を特定のアカウントで作成し、Amazon Kinesis Data Firehose ストリームを設定する。ストリームのターゲットとして S3 バケットを指定する。既存のロググループにはサブスクリプションフィルターを設定し、AWS Lambda 関数と EventBridge ルールを使用して CloudWatch Logs PutSubscriptionFilter API を自動化し、新しいロググループをキャプチャする。

正解 このアプローチはCloudWatch Logsデータをリアルタイムで特定のS3バケットに転送するという要件を満たしています。主要コンポーネントは以下の通りです:

1. CloudWatch Logsの宛先(Destination)を作成し、Kinesis Data Firehoseストリームをターゲットとして設定します。
2. Kinesis Data Firehoseストリームを設定し、データを特定のS3バケットに送信します。
3. 既存のロググループにサブスクリプションフィルターを設定し、ログデータを宛先に送信します。
4. EventBridgeルールを設定して新しいロググループの作成を検出します。
5. Lambda関数を使用して、新しいロググループにサブスクリプションフィルターを自動的に適用します。

この方法は、現在のロググループと将来作成されるロググループの両方からのデータをリアルタイムで特定のS3バケットに転送するという要件を完全に満たします。

問われている要件

この問題では、AWS Organizationsに複数のアカウントを持つ組織が、以下の要件を満たすソリューションを求めています：

1. CloudWatch Logsのデータをリアルタイムに特定のAWSアカウント内のS3バケットに転送する
2. 現在のロググループと将来作成されるロググループの両方を対象にする

つまり、複数アカウントにわたるすべてのCloudWatch Logsデータを集約し、リアルタイムで特定のアカウントのS3バケットに保存する必要があります。また、新しいロググループが作成された場合にも、自動的にこのデータ転送設定が適用される必要があります。

前提知識

CloudWatch Logs

Amazon CloudWatch Logsは、ログデータを保存、監視、アクセスするためのAWSサービスです。主な機能と概念は以下の通りです：

1. ロググループ：
   • ログストリームの論理的なグループ
   • アプリケーション、サービス、環境ごとに作成されることが多い
   • 保持期間、アクセス制御などの設定はロググループレベルで適用される
2. ログストリーム：
   • 同じソースからのイベントシーケンス
   • 例えば、1つのアプリケーションインスタンスからのログなど
3. サブスクリプションフィルター：
   • ロググループからリアルタイムでデータを他のAWSサービスに転送するための仕組み
   • サポートされる宛先には、Lambda、Kinesis Data Streams、Kinesis Data Firehose、別のアカウントのCloudWatch Logs宛先などがある
4. クロスアカウントデータ共有：
   • CloudWatch Logs宛先（Destination）を使用して、あるアカウントのログデータを別のアカウントに送信することができる
   • 宛先アカウントではIAMロールを使用してアクセス制御を設定できる

Amazon Kinesis Data Firehose

Amazon Kinesis Data Firehoseは、ストリーミングデータを目的の宛先にリアルタイムで配信するためのフルマネージドサービスです：

1. 主な特徴：
   • データの変換、バッチ処理、圧縮をサポート
   • 宛先には、S3、Redshift、Elasticsearch、Splunkなどがある
   • バッファリング、リトライなどの機能を提供
2. CloudWatch Logsとの統合：
   • サブスクリプションフィルターとCloudWatch Logs宛先を通じて、CloudWatch LogsからFirehoseにデータを直接送信可能
   • データをS3に保存する前に処理または変換することができる

AWS Lambda

AWS Lambdaは、サーバーレスでコードを実行するサービスで、イベント駆動のアプリケーションを構築するのに適しています：

1. 主な特徴：
   • サーバー管理不要でコードを実行
   • さまざまなイベントソースからトリガー可能
   • AWSのサービスと連携して自動化タスクを実行
2. CloudWatch Logsとの統合：
   • CloudWatch Logsからイベントを受け取り処理することができる
   • PutSubscriptionFilter APIを呼び出して、サブスクリプションフィルターを動的に設定できる

Amazon EventBridge

Amazon EventBridgeは、イベント駆動型アーキテクチャを構築するためのサーバーレスイベントバスサービスです：

1. 主な特徴：
   • イベントパターンに基づいてルールを定義
   • イベントが発生したときに特定のアクションをトリガー
   • 複数のAWSサービスとの統合
2. CloudWatch Logsとの統合：
   • ロググループの作成など、CloudWatch Logsのイベントを検出可能
   • 検出したイベントに基づいて、Lambda関数などのターゲットを起動できる

AWS Organizations

AWS Organizationsは、複数のAWSアカウントを一元管理するためのサービスです：

1. 主な特徴：
   • 複数のAWSアカウントを組織単位にグループ化
   • 一元的なポリシー管理を提供
   • アカウント間のリソース共有をサポート
2. リソース共有：
   • 特定のS3バケットに対するアクセス許可を組織内の複数アカウントに付与可能
   • IAMロールとリソースポリシーを使用して、クロスアカウントアクセスを設定

解くための考え方

この問題を解決するためには、以下の要素を考慮する必要があります：

1. リアルタイムデータ転送：
   • CloudWatch Logsデータをリアルタイムで転送する方法を選択する
   • データの遅延を最小限に抑える必要がある
2. クロスアカウント設定：
   • 複数アカウントからのデータを単一のアカウントに集約する方法を設計する
   • 適切なアクセス制御を確保する
3. 自動化と将来のロググループ対応：
   • 新しいロググループが作成されたときに自動的に設定を適用する方法を検討する
   • 継続的なメンテナンスを最小限に抑える

これらの要素を考慮した上で、以下のソリューションが最適であると判断できます：

1. CloudWatch Logs宛先の設定：
   • 特定のアカウントにCloudWatch Logs宛先を作成
   • 宛先をKinesis Data Firehoseストリームに設定
2. Kinesis Data Firehoseの設定：
   • FirehoseストリームのターゲットをS3バケットに設定
   • 適切なバッファリング、圧縮、パーティション設定を行う
3. サブスクリプションフィルターの設定：
   • 既存のロググループにサブスクリプションフィルターを設定
   • フィルターを通じてデータをCloudWatch Logs宛先に送信
4. 自動化の実装：
   • EventBridgeルールを設定して新しいロググループの作成を検出
   • Lambda関数を使用して新しいロググループにサブスクリプションフィルターを自動的に適用

このアプローチは、現在と将来のロググループからのデータをリアルタイムで指定のS3バケットに転送するという要件を満たします。

参考資料

• Amazon CloudWatch Logs: Subscription Filters
• Amazon Data Firehose とは何ですか?
• Amazon CloudWatch Logs とは（CloudWatch ログと組み合わせ）
• CloudWatch Logs宛先への送信先としてのFirehoseストリーム

正解: B

A. インスタンスの構成に必要な内容を記載したSystems Manager Run Commandドキュメントを作成し、インスタンスが最新のパッチ基準を満たしていない場合にRun Commandを実行するようSystems Manager Complianceを使用する。

不正解 このアプローチには複数の問題があります。Systems Manager Complianceは主にインスタンスのパッチ適用状況やアソシエーションコンプライアンスを評価するためのものであり、自動的に構成を適用するツールではありません。コンプライアンスの評価は通常、インスタンスが一定期間稼働した後に行われるため、「起動後に即座に」という要件を満たせません。
また、パッチ基準への準拠状況に基づいてインスタンス構成を適用するという方法は、パッチ適用とOS構成という別々の作業を不適切に関連付けており、信頼性の高い自動化方法とはいえません。

B. Systems ManagerコマンドドキュメントにリンクされたSystems Manager State Managerの関連付けを作成し、即時にタグクエリを実行して構成を適用する。

正解 Systems Manager State Managerは、EC2インスタンスの設定を定義し維持するための最適なツールです。関連付け(Association)を作成し、Auto Scalingグループによって自動的に付与されるタグをターゲットとして使用することで、新しく起動されたインスタンスを即座に識別し、必要な構成を適用できます。
State Managerは、インスタンスが起動し、Systems Manager Agentが動作を開始するとすぐに、定義された設定を適用します。また、タグクエリを使用することで、特定のインスタンスグループを動的にターゲットにできるため、Auto Scalingグループで新しいインスタンスが起動した場合でも自動的に検出されます。この方法は「起動後に即座に」という要件を満たし、効率的に一貫した構成を提供します。

C. 必要なインスタンス設定を指定するSystems Manager Run Commandタスクを作成し、Systems Manager Maintenance Windowsを使用してこれを毎日実行するようスケジュールし、ターゲットを設定する。

不正解 Maintenance Windowsは、定期的なメンテナンス作業をスケジュールするためのものであり、インスタンス起動後に即座に構成を適用するという要件には適していません。毎日のスケジュールでは、新しく起動されたインスタンスが次のメンテナンスウィンドウまで最大24時間待機する可能性があります。この間、インスタンスは必要な構成を満たしていない状態で稼働することになり、「起動後に即座に」という要件を満たせません。また、Maintenance Windowsは特定の時間帯に実行されるため、Auto Scalingによって起動時間がばらつくインスタンスに対しては効率的ではありません。

D. Systems Manager Patch Managerのパッチベースラインと、Auto Scalingグループと同じタグを使用したグループを設定する。グループをベースラインに関連付け、パッチ適用にSystems Manager Run Commandを使用する。

不正解 Patch Managerは、セキュリティパッチやソフトウェア更新プログラムの適用を管理するためのツールであり、オペレーティングシステムの構成管理を主な目的としていません。パッチベースラインは、どのパッチを適用するかを定義するもので、オペレーティングシステムの設定には直接関係ありません。また、パッチ適用作業は通常、インスタンス起動直後ではなく、スケジュールに従って実行されるため、「起動後に即座に」という要件を満たせません。さらに、パッチ適用はシステム設定とは別の作業であり、この方法では必要なオペレーティングシステム設定を確実に適用できません。

問われている要件

この問題では、Amazon EC2 Auto Scalingグループから起動されるインスタンスが、起動後に即座に適切なオペレーティングシステムの設定を満たす必要があります。重要なポイントは以下の通りです：

1. EC2インスタンスはAuto Scalingグループによって作成される
2. インスタンスには既にSystems Manager Agent（SSM Agent）がインストールされている
3. インスタンスには自動的にタグが付与される
4. 必要な構成を「起動後に即座に」適用する必要がある

これらの要件を踏まえて、起動されたインスタンスに効率的に設定を適用する方法を選択する必要があります。

前提知識

AWS Systems Manager (SSM)

AWS Systems Managerは、AWSリソースの管理を自動化するためのサービスです。主要なコンポーネントは以下の通りです：

1. SSM Agent：
   • EC2インスタンスにインストールされるソフトウェア
   • Systems Managerサービスとインスタンス間の通信を可能にする
   • コマンドの実行、パッチ適用、インベントリ収集などの機能を提供
2. State Manager：
   • インスタンスの設定を定義し、維持するためのサービス
   • 関連付け（Association）を通じて、インスタンスに対する設定を適用
   • インスタンスが起動するとすぐに適用される（SSM Agentが動作開始すれば）
   • スケジュールに基づいて定期的に適用することも可能
3. Run Command：
   • インスタンスでコマンドをリモートで実行するサービス
   • オンデマンドで実行される
   • コマンドドキュメントを使用してタスクを定義
4. Maintenance Windows：
   • 定期的なメンテナンス作業をスケジュールするためのサービス
   • 特定の時間帯にタスクを実行
5. Patch Manager：
   • パッチの適用を管理するためのサービス
   • パッチベースラインを使用して適用するパッチを定義
6. Compliance：
   • パッチ適用状況やアソシエーションコンプライアンスを評価するサービス
   • 設定の適用自体は行わない

EC2インスタンスのタグ付けとターゲティング

AWSリソースに対するタグ付けは、リソースの識別や整理に役立ちます。Systems Managerでは、タグを使用してターゲットインスタンスを指定できます：

1. タグクエリ：
   • 特定のタグキーと値に基づいてインスタンスを動的に選択
   • 例：tag:Environment=Production
2. Auto Scalingグループとタグ：
   • Auto Scalingグループは、起動するインスタンスに自動的にタグを付与できる
   • これらのタグを使用して、Systems Manager操作のターゲットを指定できる

解くための考え方

この問題の要件を満たすためには、以下の点を考慮する必要があります：

1. 即時性：
   • インスタンス起動後すぐに設定を適用する必要がある
   • 定期的なスケジュールではなく、イベント駆動型のアプローチが望ましい
2. 自動化：
   • 手動介入なしで設定を適用できる
   • Auto Scalingによって動的に変化するインスタンス群を対象にできる
3. 一貫性：
   • すべてのインスタンスに同じ設定が確実に適用される
   • 設定のドリフトを防止する

これらの要件を満たすベストプラクティスは、Systems Manager State Managerを使用することです。State Managerの関連付けは、インスタンスの起動時に自動的に適用され、定義された状態を維持します。タグを使用してターゲットを指定することで、Auto Scalingグループによって起動される新しいインスタンスも自動的に対象になります。

State Managerを使用した具体的な実装手順は以下の通りです：

1. システム設定を定義するコマンドドキュメント（例：AWS-RunPowerShellScriptやAWS-RunShellScript）を作成または選択
2. State Manager関連付けを作成し、以下を設定：
   • 作成したコマンドドキュメントを指定
   • Auto Scalingグループが付与するタグを使用してターゲットを指定（例：tag:AutoScalingGroupName=my-asg）
   • 関連付けの適用頻度を設定（この場合は「即時」実行が望ましい）
3. 関連付けを有効化

この方法により、新しく起動されたインスタンスは、SSM Agentが動作を開始するとすぐに必要な設定が適用されます。また、State Managerは定期的に設定の状態を確認し、必要に応じて再適用するため、設定のドリフトも防止できます。

参考資料

• AWS Systems Manager State Manager
• AWS Systems Manager とは
• AWS Systems Manager のコンプライアンス
• コマンドドキュメントプラグインリファレンス

正解: B

A. すべてのAPIアクションが許可される。

不正解 Service Control Policy(SCP)はAWS Organizationsの機能であり、組織内のアカウントで利用可能な最大権限を制限します。SCPは「許可リスト」として機能し、明示的に許可されていないアクションは実行できません。Department OUからFullAWSAccess SCPを削除し、EC2 APIアクションのみを許可するSCPに置き換えた場合、Department OU下の全アカウント(つまりEngineering OUのアカウントも含む)で利用可能な最大権限はEC2 APIアクションのみになります。
そのため、AdministratorAccessポリシーが付与されているIAMロールであっても、EC2以外のサービスへのアクセスは制限されることになります。すべてのAPIアクションが許可されるという結論は誤りです。

B. EC2 APIアクションのみが許可され、それ以外のAPIはすべて拒否される。

正解 Service Control Policy(SCP)はアカウントで実行可能な最大権限セットを定義します。SCPがEC2 APIアクションのみを許可する場合、IAMポリシー(この場合はAdministratorAccess)がより広範な権限を付与していても、実際に使用できる権限はSCPとIAMポリシーの共通部分に制限されます。
つまり、AdministratorAccessは理論上すべてのAPIアクションを許可しますが、SCPがEC2 APIアクションのみを許可している場合、管理者IAMロールはEC2 APIアクションのみを実行できるようになります。これは、SCPがフィルターとして機能し、IAMポリシーで許可されている権限のうち、SCPでも許可されている権限のみが有効になるためです。

C. すべてのリソースに対するすべてのAPIアクションへのアクセスが禁止される。

不正解 SCPをEC2 APIアクションのみを許可するものに変更しても、EC2 APIアクションへのアクセスは引き続き許可されます。SCPは「許可リスト」として機能するため、明示的に許可されたAPIアクション(この場合はEC2 API)は引き続き使用可能です。したがって、すべてのAPIアクションが禁止されるわけではなく、EC2 APIアクションは引き続き許可されます。

D. EC2 APIアクションは拒否され、それ以外のAPIはすべて許可される。

不正解 この解釈は完全に逆です。SCPはアカウントで実行可能な最大権限を定義します。Department OUのSCPをEC2 APIアクションのみを許可するものに変更した場合、EC2 APIアクションは明示的に許可され、その他のAPIアクションは暗黙的に拒否されます。SCPは「許可リスト」であり、明示的に許可されていないものはすべて拒否されるため、EC2以外のAPIアクションがすべて許可されるという結論は誤りです。

問われている要件

この問題では、AWS Organizations内のService Control Policy（SCP）の変更が、組織内のアカウントに設定されているIAMロールの権限にどのような影響を与えるかを理解する必要があります。具体的には、Department OUからFullAWSAccess SCPを削除し、Amazon EC2 APIアクションのみを許可するSCPに置き換えた場合に、Engineering OUのアカウントに設定されている管理者IAMロール（AdministratorAccess管理ポリシーを持つ）の権限がどうなるかを問われています。

前提知識

AWS Organizations とサービスコントロールポリシー（SCP）

AWS Organizationsは、複数のAWSアカウントを一元管理するためのサービスで、サービスコントロールポリシー（SCP）を使用して組織内のアカウントの権限を一括制御できます。

• 組織構造:
  • 組織ルート: 組織の最上位コンテナ
  • 組織単位（OU）: アカウントの論理的なグループ。階層構造を形成できる
  • アカウント: 個々のAWSアカウント
• SCP（Service Control Policy）の特性:
  • SCPは組織内のアカウントで利用可能な最大権限を制限するポリシー
  • SCPは「許可リスト」であり、明示的に許可されていないアクションは拒否される
  • SCPは階層構造で適用され、上位レベルでの制限は下位レベルに継承される
  • アカウントで実行できるアクションは、そのアカウントに適用されるすべてのSCPの論理的な積（AND）
  • デフォルトではFullAWSAccessポリシーが適用され、すべてのアクションを許可
  • SCPはIAMポリシーをオーバーライドするのではなく、制限する
• フルAWSアクセスSCP:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "*",
      "Resource": "*"
    }
  ]
}

• EC2 APIのみを許可するSCP（例）:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "ec2:*",
      "Resource": "*"
    }
  ]
}

IAMポリシーとSCPの関係

IAMポリシーとSCPは連携して動作し、最終的な権限を決定します:

• 権限の評価モデル:
  • 明示的な拒否が優先される
  • アクションが許可されるためには、適用されるすべてのポリシータイプで許可されなければならない
  • SCPとIAMポリシーの論理的な積（AND）が最終的な有効権限
• AdministratorAccess IAM管理ポリシー:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "*",
      "Resource": "*"
    }
  ]
}

• SCPとIAMポリシーの相互作用:
  • SCPは「ガードレール」として機能し、IAMで付与できる最大権限を制限
  • IAMポリシーで許可されているアクションでも、SCPで許可されていなければ拒否される
  • 最終的な権限 = SCPで許可されている権限 ∩ IAMポリシーで許可されている権限

解くための考え方

この問題を解決するには、SCPとIAMポリシーがどのように相互作用するかを理解し、以下のポイントを考慮する必要があります:

1. 組織構造の理解:
   • 組織ルート
     • Department OU (FullAWSAccess SCPが適用されている)
       • Engineering OU (FullAWSAccess SCPが適用されている)
         • 複数のAWSアカウント (各アカウントにFullAWSAccess SCPが適用され、管理者IAMロールにAdministratorAccessポリシーが設定されている)
2. SCPの変更の影響:
   • Department OUからFullAWSAccess SCPを削除し、EC2 APIアクションのみを許可するSCPに置き換える
   • この変更はDepartment OUのすべての子OU（Engineering OU）とアカウントに影響する
3. 有効な権限の計算:
   • 初期状態:
     • SCPから: すべてのアクション許可 (FullAWSAccess)
     • IAMから: すべてのアクション許可 (AdministratorAccess)
     • 有効権限: すべてのアクション許可
   • 変更後:
     • SCPから: EC2 APIアクションのみ許可
     • IAMから: すべてのアクション許可 (AdministratorAccess)
     • 有効権限: EC2 APIアクションのみ許可

従って、Department OUのSCPを変更した後、管理者IAMロールはEC2 APIアクションのみを実行でき、他のすべてのAPIアクションは拒否されることになります。これは、SCPが「許可リスト」として機能し、IAMポリシーで許可されている権限のうち、SCPでも許可されている権限のみが有効になるためです。

SCPの階層的な適用を考慮すると、Department OUに適用されるSCPの制限は、その下のEngineering OUとそのアカウントすべてに継承されます。したがって、Department OUのSCPがEC2 APIアクションのみを許可する場合、Engineering OUのアカウントの管理者IAMロールは、AdministratorAccessポリシーが付与されていても、EC2 APIアクションのみを実行できます。

参考資料

• サービスコントロールポリシー (SCP)
• IAM ポリシーと SCP の違い
• IAM ポリシーの仕組み
• SCP の継承

正解: D

A. S3バケットポリシーを更新する。S3の「パブリックアクセスブロック」オプションを無効にする。S3バケットポリシーにaws:SourceAccount条件を追加し、該当する開発者のAWSアカウントIDを含める。

不正解 このアプローチには複数の問題があります。まず、「パブリックアクセスブロック」を無効にすることはセキュリティ上のリスクを大きく高めます。パブリックアクセスブロックはS3バケットを意図しない公開アクセスから保護する機能であり、開発者のアクセス問題とは関係がありません。
また、aws:SourceAccount条件の追加は、クロスアカウントアクセスを制御するために有効な方法ですが、それだけでは根本的な問題解決になりません。組織内に存在する可能性があるSCP(サービスコントロールポリシー)やIAM権限境界などのより上位の制約を考慮していないため、これだけでは不十分です。

B. 開発者のアクセスを制限しているIAM権限境界がないか確認する。制限がある場合は調整する。影響を受けている開発者アカウントにAWS Configレコーダーを実装し、アクセス問題を引き起こしている設定ミスを修正する。解決策をCodeCommitリポジトリにコミットし、CloudFormationを使用してデプロイする。

不正解 この方法はIAM権限境界の確認など一部適切な要素を含んでいますが、不完全です。IAM権限境界はユーザーやロールに設定できる最大権限を制限するため、開発者のアクセス問題の原因となる可能性は確かにあります。しかし、AWS Configレコーダーの実装は、設定ミスを検出するのに役立つ可能性がありますが、即時の問題解決策ではありません。AWS Configは主に設定変更を記録し、コンプライアンスをモニタリングするためのものであり、アクセス問題の根本原因を特定するためのツールではありません。また、OUレベルで適用されている可能性のあるSCPを確認する点が欠けています。CodeCommitとCloudFormationを使用した変更のデプロイは適切ですが、問題の根本原因に対処していない可能性があります。

C. 開発者OUでIAMリソースへの変更を防止するSCPを実装する。S3ポリシーにaws:SourceAccount条件を追加し、該当する開発者のAWSアカウントIDを含める。解決策をCodeCommitリポジトリにコミットし、CloudFormationを使用してデプロイする。

不正解 この方法はアクセス問題を解決するのではなく、むしろ複雑にする可能性があります。開発者OUでIAMリソースへの変更を防止するSCPを実装することは、既存のアクセス問題とは無関係であり、むしろ開発者が自分のIAM権限を管理する能力をさらに制限することになります。また、S3ポリシーにaws:SourceAccount条件を追加することは有効かもしれませんが、それだけでは問題の根本原因に対処していない可能性があります。問題は既存のSCPやIAM権限境界など、より上位の制約にある可能性が高いですが、この解決策ではそれらの確認が行われていません。CodeCommitとCloudFormationを使用したデプロイのアプローチは正しいですが、適切な解決策をデプロイしていないため不正解です。

D. S3バケットへの開発者からのアクセスを拒否しているSCPが存在しないことを確認する。IAMポリシーの権限境界がアクセスを妨げていないことを確認する。必要に応じてSCPやIAMポリシーの権限境界を調整し、CodeCommitリポジトリに変更をコミットして、CloudFormationを使用してデプロイする。

正解 この方法は、S3アクセス問題の最も可能性の高い根本原因に対処しています。AWS Organizationsの構造内では、SCPはOU内のすべてのアカウントに影響を与え、IAMポリシーよりも上位の制約として機能します。
まず、S3バケットへのアクセスを拒否しているSCPの存在を確認することは、問題の根本原因を特定するための重要な手順です。
次に、IAMポリシーの権限境界の確認も重要です。権限境界はユーザーやロールに設定できる最大権限を制限するため、S3アクセスを妨げている可能性があります。これらを確認し、必要に応じて調整することで、アクセス問題の根本原因に対処できます。
さらに、変更をCodeCommitリポジトリにコミットし、CloudFormationを使用してデプロイすることで、インフラストラクチャのコード管理(IaC)のベストプラクティスに従った一貫性のある変更管理が可能になります。

問われている要件

この問題では、AWS Organizations内で複数のAWSアカウントを管理しており、開発者が特定のS3バケットにアクセスできないという問題を解決する方法を問われています。主なポイントは以下の通りです：

1. AWS Organizationsの構造内で、複数のAWSアカウントが異なるOUに分けて管理されている
2. すべてのリソース（IAMポリシーやS3ポリシーを含む）はCloudFormationを通じてデプロイされている
3. テンプレートとコードはCodeCommitリポジトリに保存されている
4. 問題のS3バケットには既にバケットポリシーが設定されている
5. 一部の開発者がこのS3バケットにアクセスできない

この状況を踏まえて、アクセス問題を解決するための最も適切なアプローチを選択する必要があります。

前提知識

AWS Organizationsの構造とポリシー階層

AWS Organizationsは、複数のAWSアカウントを一元管理するためのサービスです。主要な概念と構造は以下の通りです：

1. 組織構造：
   • 組織のルート：組織の最上位コンテナ
   • 組織単位（OU）：アカウントの論理的なグループ。階層構造を形成できる
   • アカウント：個々のAWSアカウント
2. サービスコントロールポリシー（SCP）：
   • AWS Organizationsの機能で、組織内のアカウントで利用可能な最大権限を制限する
   • OU単位で適用され、その下のすべてのアカウントに影響する
   • IAMポリシーよりも優先される（SCPで拒否されるとIAMで許可されていても拒否される）
   • 「許可リスト」または「拒否リスト」として機能する
3. アクセス制御階層：
   • SCPはアカウントの最大権限を制限する最上位の制約
   • IAM権限境界はユーザーやロールに設定できる最大権限を制限
   • IAMポリシー（アイデンティティベースまたはリソースベース）が実際のアクセス許可を決定
   • リソースポリシー（S3バケットポリシーなど）も権限を制御

IAM権限境界

IAM権限境界は、IAMエンティティ（ユーザーまたはロール）に設定できる最大権限を定義するポリシーです：

1. 機能：
   • アイデンティティに付与できる最大権限を制限する
   • 権限境界自体はアクセス権を付与しない
   • アイデンティティベースのポリシーと権限境界の共通部分が実際の権限となる
2. 評価ロジック：
   • アイデンティティにアクションの実行を許可するには、アイデンティティポリシーと権限境界の両方でそのアクションが許可されている必要がある
   • 権限境界で明示的に許可されていないアクションは、アイデンティティポリシーで許可されていても実行できない

S3バケットポリシーとアクセス制御

S3バケットポリシーは、特定のS3バケットに対するアクセスを制御するリソースベースのポリシーです：

1. 機能：
   • バケットレベルでのアクセス制御を定義
   • プリンシパル（ユーザー、ロール、アカウント）ごとに異なるアクセス権限を設定可能
   • クロスアカウントアクセスを許可する手段として使用可能
2. パブリックアクセスブロック：
   • バケットレベルまたはアカウントレベルで設定可能
   • 意図しないパブリックアクセスを防ぐためのセキュリティ機能
   • 開発者の正規アクセスには通常影響しない
3. 条件キー：
   • aws:SourceAccount：リクエストの送信元のアカウントを指定
   • aws:PrincipalOrgID：プリンシパルが属する組織を指定
   • aws:PrincipalTag：プリンシパルに付けられたタグに基づいてアクセスを制御

インフラストラクチャのコード化（IaC）

AWSリソースをコードとして管理するプラクティスは、一貫性と再現性を確保するために重要です：

1. AWS CloudFormation：
   • AWSリソースをテンプレート（YAMLまたはJSON）として定義
   • スタックを通じてリソースを一括デプロイおよび管理
   • 変更の追跡と一貫したデプロイを可能にする
2. AWS CodeCommit：
   • マネージドのGitリポジトリサービス
   • インフラストラクチャコードのバージョン管理とコラボレーションを可能にする

解くための考え方

この問題を解決するためには、以下の点を考慮する必要があります：

1. アクセス制御階層の理解：
   • AWS Organizationsのアクセス制御は階層的である
   • 最上位から順に：SCP → IAM権限境界 → IAMポリシー → リソースポリシー
   • 上位レベルで拒否されると、下位レベルでの許可は無効になる
2. 問題の根本原因の特定：
   • S3バケットポリシーは設定されていることが既に分かっている
   • アクセス問題の原因は、より上位の制約（SCPやIAM権限境界）にある可能性が高い
   • OUレベルでのSCPの設定が開発者のアクセスを妨げている可能性がある
   • IAM権限境界が開発者の権限を制限している可能性もある
3. 変更管理の一貫性：
   • すべてのリソースはCloudFormationを通じてデプロイされている
   • テンプレートとコードはCodeCommitリポジトリに保存されている
   • 解決策も同じ管理方法に従う必要がある

これらの点を考慮すると、最も適切なアプローチは以下のステップを含むものになります：

1. S3バケットへのアクセスを拒否しているSCPが存在しないか確認する
2. IAMポリシーの権限境界がアクセスを妨げていないか確認する
3. 必要に応じてSCPやIAM権限境界を調整する
4. 変更をCodeCommitリポジトリにコミットし、CloudFormationを使用してデプロイする

参考資料

• S3 バケットポリシーの使用
• AWS Organizations SCP によるアクセス制御
• IAM 権限境界の設定

正解: D

A. レコードをAmazon S3に書き込むウェブサービスを開発する。Amazon S3イベント通知を設定して、メッセージをAmazon SNSトピックに送信する。新しいレコードをスキャンして処理を開始するためのEC2インスタンスをデプロイし、中間結果を次のステージのためにAmazon S3に保存する。

不正解 この手順はステージ間のデータを保存するためにAmazon S3を使用し、S3イベント通知とSNSトピックを介して処理を進めるものです。しかし、この方法には複数の欠点があります。まず、各ステージの状態管理を明示的に実装する必要があり、失敗したステージのみを再処理する仕組みを自前で構築しなければなりません。
また、EC2インスタンスを手動でスケーリングする必要があり、イベント駆動型の効率的な実行に適していません。ステージごとのエラー処理やリトライロジックもアプリケーションレベルで実装する必要があり、複雑性が増します。
さらに、各ステージが5分以内に完了する処理には、EC2インスタンスはLambda関数と比較して管理のオーバーヘッドがかかります。

B. アプリケーション内で処理ロジックを実装する。アプリケーションをコンテナ環境で動作するように変更し、AWS Fargateを使用してこれらのコンテナを管理する。ステージの進行に合わせてコンテナが自動的に呼び出されるように設定する。

不正解 この手順は、アプリケーションをコンテナ化してAWS Fargateで実行することを提案しています。コンテナ化によりデプロイの一貫性は向上しますが、この方法にもいくつかの課題があります。
まず、Fargateはコンテナの実行環境を提供するだけであり、ワークフロー管理やステージの状態追跡、エラーハンドリングの機能は含まれていません。これらの機能はアプリケーション内で実装する必要があり、複雑性が増します。
また、ステージ間の調整やデータの受け渡し、失敗したステージのみを再実行する仕組みも自前で構築する必要があります。
さらに、Fargateはコンテナを実行するための優れたサービスですが、ステージごとのコンテナ起動には一定のオーバーヘッドがあり、5分以内に完了する計算処理に対しては非効率になる可能性があります。この方法では、ワークフロー管理という課題に対して十分な解決策を提供していません。

C. Amazon Kinesisデータストリームを使用してレコードを送信するウェブサービスを実装する。AWS Lambda関数を使用して処理を分割する。

不正解 Amazon Kinesisデータストリームは連続的なデータ処理に適していますが、この方法にはいくつかの制限があります。Kinesisはストリーミングデータの処理に優れていますが、複数のステージを持つワークフローの管理や、失敗したステージのみを再処理するという要件には対応していません。
ストリームデータの処理は順次実行されるため、中間の失敗したステージだけを再処理する機能は標準で提供されていません。
また、Lambda関数間のデータの受け渡しやステージの状態管理は自前で実装する必要があります。Kinesisを使用したストリーム処理では、データの順序性は保証されますが、ワークフローの状態管理やエラー処理、特定ステージの再処理といった機能は含まれていないため、問題の要件を効率的に満たすことができません。

D. AWS Step Functionsを利用するウェブサービスを実装し、処理をStep FunctionsとAWS Lambda関数で管理されるタスクに分割する。

正解 AWS Step Functionsは、まさにこのような複数ステージのワークフロー管理に最適なサービスです。各処理ステージを個別のステート(状態)として定義でき、それぞれのステートはAWS Lambda関数によって実行できます。Step Functionsの主な利点は以下の通りです:

1. 状態管理: 各ステージの状態(成功/失敗/進行中)を自動的に追跡します。
2. エラーハンドリング: 特定のステージが失敗した場合、そのステージのみを再試行する仕組みが組み込まれています。
3. ワークフロー制御: 条件分岐、並列処理、待機状態など、複雑なワークフロー制御が可能です。
4. サーバーレス: Lambda関数との統合により、必要なときだけリソースを使用するサーバーレスアーキテクチャを実現できます。
5. ビジュアル化: ワークフローの実行状況を視覚的に監視できます。

各ステージをLambda関数として実装し、Step Functionsを使用してワークフローを管理することで、失敗したステージのみを再処理する要件を効率的に実現できます。また、Lambda関数は必要なときだけ起動されるため、リソース効率も向上します。5分以内に完了する計算処理は、Lambda関数の実行時間制限(最大15分)内に収まるため、技術的にも適しています。

問われている要件

この問題では、複数の連続ステージでデータを処理するアプリケーションの改善策を求められています。現状の課題と要件は以下の通りです：

1. アプリケーションはEC2インスタンス上のAuto Scalingグループで動作している
2. 処理は複数の連続ステージで構成され、各ステージは計算負荷が高い
3. 各ステージは5分以内に完了する
4. 現在は、あるステージが失敗すると全体が最初から再処理される
5. 改善目標：失敗したステージのみを再処理できるようにして効率を高める

この問題の本質は、複数ステージのワークフローを管理し、特定のステージが失敗した場合に、そのステージだけを再処理できる仕組みを構築することです。

前提知識

ワークフロー管理の考え方

複数のステージを持つデータ処理ワークフローを効率的に管理するには、以下の要素を考慮する必要があります：

1. 状態管理: 各ステージの実行状態（未実行、実行中、成功、失敗）を追跡する仕組み
2. エラーハンドリング: ステージの失敗を検出し、適切に対応する仕組み
3. 再処理: 特定のステージだけを再実行できる仕組み
4. データの受け渡し: ステージ間でデータを効率的に受け渡す仕組み
5. スケーラビリティ: 処理量の増加に対応できる柔軟性

AWS Step Functions

AWS Step Functionsは、ワークフローを視覚的に構築し管理できるサービスです：

1. ステートマシン: JSON形式で定義されるワークフロー
2. ステート（状態）: ワークフローの各ステップ。Task、Choice、Parallel、Mapなど様々なタイプがある
3. タスク: 実際の処理を行うステート。Lambda関数、ECSタスク、他のAWSサービスなどを呼び出せる
4. 入出力処理: JSONデータを入力として受け取り、処理結果をJSONデータとして次のステートに渡せる
5. エラーハンドリング: Retry（再試行）やCatch（エラー捕捉）などの機能が組み込まれている
6. 実行履歴: ワークフローの実行状況や結果をログとして保存

AWS Lambda

AWS Lambdaは、サーバーレスでコードを実行できるコンピューティングサービスです：

1. イベント駆動: 様々なイベントをトリガーにして関数を実行できる
2. スケーラビリティ: 需要に応じて自動的にスケールする
3. 短時間実行: 現在は最大15分間の実行が可能
4. ステートレス: 基本的にステートレスだが、外部サービスと連携して状態を管理できる
5. リソース効率: 実行時間に応じた課金で、アイドル時間のコストがない

解くための考え方

この問題を解決するための最適な手順を考えるには、以下の観点で各選択肢を評価します：

1. ワークフロー管理機能: ステージ間の依存関係や制御フローを適切に管理できるか
2. 状態管理: 各ステージの実行状態を追跡できるか
3. エラーハンドリング: ステージの失敗を検出し、適切に対応できるか
4. 再処理能力: 失敗したステージのみを再実行できるか
5. リソース効率: 必要なときだけリソースを使用する効率的な実行が可能か
6. 開発・運用の複雑性: 実装や運用にかかる労力はどの程度か

これらの観点から各選択肢を分析すると：

• S3 + SNS + EC2の組み合わせ：ステージの状態管理やエラーハンドリング、再処理の仕組みを自前で実装する必要があり、複雑性が高い
• コンテナ化 + Fargate：ワークフロー管理の機能が不足しており、状態管理やエラーハンドリングも自前で実装する必要がある
• Kinesis + Lambda：ストリーム処理には適しているが、特定ステージの再処理という要件に直接対応していない
• Step Functions + Lambda：ワークフロー管理、状態追跡、エラーハンドリング、再処理の機能が組み込まれており、サーバーレスで効率的

AWS Step FunctionsとLambdaの組み合わせは、以下のような実装が可能です：

1. 各処理ステージを個別のLambda関数として実装
2. Step Functionsのステートマシンで、各ステージの順序や依存関係を定義
3. ステージ間のデータはStep Functionsの入出力メカニズムを使用して受け渡し
4. エラーハンドリングにStep FunctionsのRetry機能を使用し、失敗したステージのみを再試行
5. 必要に応じてFall back（代替処理）やエラー通知を実装

この手順により、失敗したステージのみを再処理するという要件を効率的に満たすことができます。

参考資料

• AWS Step Functions: ワークフローを使用してアプリケーションを構築する
• AWS Step Functions でのエラー処理
• AWS Lambda: ステートレスなサーバーレスコンピューティング
• Step Functions と Lambda の統合

正解: B, D

A. Amazon ECRの基本スキャンを実装する。

不正解 Amazon ECRの基本スキャンにはAWS新しいバージョンが提供されており、これはAmazonのネイティブスキャンテクノロジーを使用しています。この新しい基本スキャンは、一般的なオペレーティングシステム全体での脆弱性検出を改善していますが、主にオペレーティングシステムパッケージの脆弱性スキャンに焦点を当てています。
プログラミング言語のパッケージ(npm、pip、gem、nugetなど)に対する包括的な脆弱性検出機能は限定的です。問題の要件では、オペレーティングシステムとプログラミング言語の両方のパッケージに対する脆弱性スキャンが求められているため、基本スキャンだけでは要件を完全に満たすことができません。

B. Amazon ECRの拡張スキャンを実装する。

正解 Amazon ECRの拡張スキャンは、Amazon Inspectorを使用して実行されます。この機能は、オペレーティングシステムのパッケージだけでなく、さまざまなプログラミング言語のパッケージ(Java、Python、JavaScript、Goなど)における脆弱性もスキャンできます。拡張スキャンを使用することで、コンテナイメージに含まれる幅広い脆弱性を検出可能となり、CRITICALおよびHIGHの脆弱性を特定できるようになります。拡張スキャンは、Common Vulnerability Scoring System(CVSS)スコアに基づいて脆弱性の重大度を評価し、詳細な結果を提供します。これにより、問題の要件であるオペレーティングシステムとプログラミング言語のパッケージに対する包括的な脆弱性検出が可能になります。

C. CI/CDワークフロー内でCRITICALまたはHIGHの脆弱性を持つイメージに対してRejectedステータスを設定するようにAmazon ECRを設定する。

不正解 Amazon ECR自体にはイメージに対して「Rejected」というステータスを明示的に設定する機能は存在しません。ECRはイメージの脆弱性をスキャンし、その結果を報告することはできますが、スキャン結果に基づいてイメージにステータスを割り当てる機能はネイティブには提供していません。
CI/CDワークフローのパイプラインの一部として、スキャン結果に基づいた判断を行い、パイプラインの進行を制御するためには、追加のロジックやサービスが必要です。また、この選択肢ではスキャン結果を自動的に評価して、CI/CDワークフローの進行を制御する方法が具体的に示されていないため、要件を完全には満たしません。

D. イメージスキャンの完了時にAWS Lambda関数をトリガーするAmazon EventBridgeルールを設定する。このLambda関数はAmazon Inspectorの結果を評価し、CI/CDワークフローにApprovedまたはRejectedステータスを送信する。

正解 この選択肢は、スキャン結果の自動評価と、それに基づいたCI/CDワークフローの制御を実現するための適切な方法を示しています。Amazon ECR(特に拡張スキャン)でイメージがスキャンされると、スキャン完了イベントがAmazon EventBridgeに送信されます。EventBridgeルールを設定することで、このイベントをトリガーにLambda関数を実行できます。Lambda関数はAmazon Inspectorのスキャン結果を取得し、CRITICALまたはHIGHの脆弱性が存在するかどうかを評価します。その評価結果に基づいて、CI/CDワークフロー(AWS CodePipeline)に「Approved」または「Rejected」のステータスを送信することができます。CodePipelineにはApproval(承認)ステージを設定できるため、Lambda関数からの評価結果に基づいて、パイプラインの進行を制御することが可能です。これにより、CRITICALまたはHIGHの脆弱性が存在するイメージのデプロイを防止できます。

E. スキャン後にAWS Lambda関数をトリガーするAmazon EventBridgeルールを設定する。このLambda関数はClairスキャンの結果を評価し、CI/CDワークフローにApprovedまたはRejectedステータスを送信する。

不正解 Clairは以前のAmazon ECRの旧基本スキャンで使用されていたオープンソースの脆弱性スキャンツールであり、現在の新しい基本スキャンではAmazonのネイティブスキャンテクノロジーに置き換えられています。旧基本スキャンはプログラミング言語のパッケージに対する脆弱性検出が限定的であり、問題の要件を完全に満たしません。

問われている要件

この問題では、CI/CDワークフローにコンテナイメージのセキュリティスキャンを統合し、CRITICALおよびHIGHの脆弱性が存在するイメージがプロダクション環境にデプロイされないようにする方法を問われています。具体的な要件は以下の通りです：

1. オペレーティングシステムおよびプログラミング言語のパッケージに対する脆弱性スキャンを行う
2. AWS CodePipeline、CodeBuild、CodeDeployを使用したCI/CDワークフローに統合する
3. Amazon ECRリポジトリを使用している
4. CRITICALおよびHIGHの脆弱性が存在しないイメージのみをデプロイ可能にする

これらの要件を満たすためには、適切なイメージスキャンソリューションの選択と、スキャン結果に基づいてCI/CDワークフローを制御する仕組みが必要です。

前提知識

Amazon ECRのイメージスキャン

Amazon ECRは、主に2種類のイメージスキャンオプションを提供しています：

1. 基本スキャン：
   • 以前の基本スキャン（旧スキャン）はClairに基づいていましたが、新しいバージョンではAmazonのネイティブスキャンテクノロジーを使用
   • 一般的なオペレーティングシステム全体での脆弱性検出を改善
   • 主にオペレーティングシステムのパッケージレベルでの脆弱性をスキャン
   • プログラミング言語のパッケージに対する包括的な検出は限定的
   • 追加費用なしで利用可能
2. 拡張スキャン：
   • Amazon Inspectorを使用して実行
   • オペレーティングシステムパッケージだけでなく、プログラミング言語のパッケージ（Java、Python、JavaScript、Goなど）も包括的にスキャン
   • AWS Security Hubと統合可能
   • CVE（共通脆弱性識別子）情報と詳細な修復ガイダンスを提供
   • CVSSスコアに基づいた重大度評価（CRITICAL、HIGH、MEDIUM、LOW）
   • Amazon Inspector利用料金が適用

スキャンは、手動で開始するか、プッシュ時に自動的に実行するように設定できます。スキャン結果はAmazon ECRコンソールで確認でき、APIを通じて取得することも可能です。

AWS EventBridgeとLambda

AWS EventBridgeは、イベント駆動型アーキテクチャを実現するためのサービスです：

1. イベントバス：アプリケーションやAWSサービスからのイベントを受信
2. ルール：特定のイベントパターンに一致した場合にアクションを実行
3. ターゲット：ルールに一致した場合に呼び出されるリソース（Lambda関数など）

AWS Lambda関数は、Amazon ECRのスキャン結果を評価し、必要なアクションを実行するために使用できます：

1. イベント駆動：EventBridgeからのイベントをトリガーに実行
2. スキャン結果の取得：ECR APIを使用してスキャン結果を取得
3. 結果の評価：CRITICALやHIGHの脆弱性が存在するかを評価
4. アクションの実行：評価結果に基づいてCodePipelineに承認/拒否を送信

AWS CodePipelineの承認アクション

AWS CodePipelineには、パイプラインの進行を制御するための承認アクションが組み込まれています：

1. 手動承認：ユーザーがコンソールやCLIを通じて承認/拒否を行う
2. 自動承認：Lambda関数などから承認/拒否のステータスを送信
3. 承認ステータス：Approved（承認）またはRejected（拒否）

Lambda関数からCodePipelineの承認アクションにステータスを送信するには、AWS SDKのput-approval-result APIを使用します。

解くための考え方

この問題を解決するための最適なアプローチを選択するには、以下の点を考慮する必要があります：

1. 脆弱性スキャンの範囲：
   • オペレーティングシステムパッケージだけでなく、プログラミング言語のパッケージもスキャンする必要がある
   • 新しい基本スキャンはオペレーティングシステムの脆弱性検出が改善されたが、プログラミング言語パッケージの包括的なスキャンは限定的
   • 拡張スキャンは両方をカバーしており、より包括的なセキュリティ分析を提供する
2. 自動化と統合：
   • スキャン結果を自動的に評価し、CI/CDワークフローに統合する仕組みが必要
   • EventBridgeとLambdaを組み合わせることで、スキャン完了をトリガーに自動評価が可能
   • CodePipelineの承認アクションと連携して、パイプラインの進行を制御できる
3. コストと機能のバランス：
   • 基本スキャンは追加費用なしで利用可能だが、機能は限定的
   • 拡張スキャンはAmazon Inspector利用料金が発生するが、より包括的な検出能力を提供

これらの考慮点から、最適な解決策は以下の組み合わせになります：

1. Amazon ECRの拡張スキャンを実装する：
   • オペレーティングシステムとプログラミング言語のパッケージ両方の脆弱性をスキャン
   • CVSSスコアに基づいた重大度評価で、CRITICALやHIGHの脆弱性を特定
2. イメージスキャンの完了時にAWS Lambda関数をトリガーするAmazon EventBridgeルールを設定する。このLambda関数はAmazon Inspectorの結果を評価し、CI/CDワークフローにApprovedまたはRejectedステータスを送信する：
   • スキャン完了を自動的に検知し、結果を評価
   • 評価結果に基づいてCodePipelineの進行を制御
   • CRITICALまたはHIGHの脆弱性が存在する場合、パイプラインを停止

これにより、問題の要件を満たすセキュアなCI/CDワークフローが実現できます。

参考資料

• Amazon ECR のセキュリティスキャン
• Amazon EventBridge を使用したイベント処理
• AWS Lambda: イベント駆動型コンピューティング
• [終了予告] Amazon ECRの古い基本スキャン(CLAIR)が2025年10月1日でサポート終了します

正解: B

A. 成功および失敗したパイプライン実行に関するAmazon CloudWatchのカスタムメトリクスを作成するAWS Lambda関数を設計する。Amazon EventBridgeルールを設定して、5分ごとにLambda関数をトリガーする。これらのメトリクスを使用してCloudWatchダッシュボードを作成する。

不正解 この手順では、Lambda関数を定期的(5分ごと)に実行して、パイプラインの実行状況を監視します。しかし、この方法にはいくつかの問題があります。まず、パイプライン実行が発生していない時間帯でもLambda関数が実行され続けるため、不要なリソース消費とコストが発生します。また、5分間隔で実行する場合、実際のパイプライン実行とメトリクス収集の間に最大5分のずれが生じる可能性があり、リアルタイム性が損なわれます。パイプラインの実行時間が短い場合、5分以内に完了した実行を正確に測定できない可能性もあります。

B. 成功および失敗したパイプライン実行の詳細を記録するAmazon CloudWatchカスタムメトリクスを作成するAWS Lambda関数を設計する。Amazon EventBridgeルールを設定して、各成功または失敗の実行後にLambda関数をトリガーする。これらのメトリクスを使用してCloudWatchダッシュボードを作成する。

正解 この手順は、最小限の設定でパイプラインのパフォーマンス指標を可視化するのに最適です。パイプラインの実行が成功または失敗した時点でイベントが発生し、それをトリガーにLambda関数が実行されます。これにより、パイプラインの実行に関連するイベント発生時のみLambda関数が起動するため、リソース効率が高くなります。
Lambda関数はパイプライン実行の開始時間と終了時間の差分から正確なデプロイサイクル時間を計算でき、障害からの復旧に関する指標も記録できます。CloudWatchカスタムメトリクスは、ネイティブなAWSサービスとして簡単に設定できるため、追加のサービスが不要で「最小限の設定」という要件を満たします。
また、CloudWatchダッシュボードは、これらのカスタムメトリクスを視覚的に表示する方法を提供します。

C. 成功および失敗した実行の詳細をAmazon DynamoDBに記録するAWS Lambda関数を開発する。Amazon EventBridgeルールを設定して、各成功または失敗の実行後にLambda関数をトリガーする。Amazon QuickSightを使用してDynamoDBデータからダッシュボードを作成する。

不正解 この方法は、パイプラインの実行成功や失敗時にイベントベースでLambda関数をトリガーする点は効率的ですが、全体としては複雑さが増しています。DynamoDBを使用してデータを保存し、QuickSightを使用してダッシュボードを作成する手順は、より高度なデータ分析や可視化が必要な場合には適していますが、「最小限の設定」という要件には合致しません。DynamoDBテーブルの設計、プロビジョニング、QuickSightのセットアップと接続設定など、追加の作業が必要になります。また、QuickSightはサブスクリプションベースのサービスであり、追加のコストが発生します。基本的なパイプラインの実行時間や復旧時間の可視化であれば、CloudWatchのネイティブな機能だけで十分対応できるため、この複雑な手順は必要以上のオーバーヘッドを生じさせます。

問われている要件

この問題では、AWS CodePipeline、CodeBuild、CodeDeployを使用している企業が、以下の指標を可視化するダッシュボードを求めています：

1. 平均的なデプロイサイクル時間（コードがビルドされてからデプロイが完了するまでの時間）
2. 障害からの復旧時間（デプロイ失敗から正常なデプロイまでの時間）

重要なのは、この可視化ソリューションが「最小限の設定」で実現できることです。つまり、シンプルかつ効率的で、管理オーバーヘッドが少ないソリューションが求められています。

前提知識

AWS DevOpsサービス

AWS CodePipeline、CodeBuild、CodeDeployは、アプリケーションのビルド、テスト、デプロイを自動化するためのAWSのCI/CDサービスです：

1. AWS CodePipeline：
   • ソフトウェアリリースのワークフローを自動化するサービス
   • 各パイプラインは、ソース、ビルド、デプロイなどの複数のステージで構成される
   • パイプラインの実行状態は「成功」「失敗」などのイベントとして通知される
2. AWS CodeBuild：
   • フルマネージドのビルドサービス
   • ソースコードのコンパイル、テストの実行、パッケージの生成などを行う
3. AWS CodeDeploy：
   • アプリケーションのデプロイを自動化するサービス
   • EC2インスタンス、Lambda関数、ECSサービスなどにデプロイ可能

AWS モニタリングサービス

AWS提供するモニタリングとダッシュボード作成のためのサービスには以下があります：

1. Amazon CloudWatch：
   • AWSリソースとアプリケーションのモニタリングサービス
   • メトリクスの収集、ログの保存、アラームの設定、ダッシュボードの作成が可能
   • カスタムメトリクスの作成に対応し、独自の測定データを記録できる
   • ネイティブなダッシュボード機能を持ち、グラフやウィジェットを配置可能
2. Amazon EventBridge：
   • サーバーレスのイベントバスサービス
   • AWSサービスからのイベントを検出し、指定したターゲット（Lambda関数など）にルーティング
   • スケジュールベース（時間間隔）またはイベントベース（特定のイベント発生時）のルール設定が可能
3. Amazon DynamoDB：
   • フルマネージドのNoSQLデータベースサービス
   • スケーラブルな高性能データストレージを提供
   • 時系列データなど、様々な形式のデータを保存可能
4. Amazon QuickSight：
   • ビジネスインテリジェンスとデータ可視化サービス
   • 様々なデータソースからデータを取得し、インタラクティブなダッシュボードを作成可能
   • 高度な分析機能を提供するが、追加のセットアップとコストが必要

解くための考え方

この問題を解決するための最適な手順を選択するには、以下の観点で評価する必要があります：

1. 設定の最小化：
   • 最小限のサービスと設定で要件を満たせるか
   • 管理オーバーヘッドは少ないか
2. データ収集の効率性：
   • 必要なデータを効率的に収集できるか
   • 無駄な処理やリソース消費はないか
3. 可視化の適切性：
   • 求められる指標（デプロイサイクル時間、復旧時間）を適切に可視化できるか
   • リアルタイム性は確保されているか
4. コスト効率：
   • 不要なサービスやリソース消費を避けられているか
   • スケーリングしても効率的か

これらの観点から各選択肢を分析すると：

• 5分ごとのLambda実行 + CloudWatchダッシュボード：
  • パイプライン実行がない時間も無駄にLambda関数が実行される
  • リアルタイム性に欠ける
  • 設定は比較的シンプルだが、リソース効率が悪い
• イベントベースのLambda実行 + CloudWatchダッシュボード：
  • 必要な時だけLambda関数が実行され、リソース効率が良い
  • リアルタイムにデータが収集される
  • AWS標準サービスのみで実現でき、設定が最小限
• イベントベースのLambda実行 + DynamoDB + QuickSight：
  • 必要な時だけLambda関数が実行される点は良い
  • しかし、DynamoDBとQuickSightは追加の設定とコストが必要
  • 高度な分析には適しているが、基本的な指標の表示には過剰
• 5分ごとのLambda実行 + DynamoDB + QuickSight：
  • 無駄なLambda実行とリアルタイム性の欠如
  • 追加の設定とコストが必要
  • 最も効率が悪く、複雑な手順

以上の分析から、「イベントベースのLambda実行 + CloudWatchダッシュボード」が最も要件に合致していることがわかります。この手順では、CodePipelineの成功/失敗イベントをトリガーにLambda関数が実行され、その中でパイプラインの実行時間や復旧時間をCloudWatchカスタムメトリクスとして記録します。これらのメトリクスはCloudWatchダッシュボードで視覚化され、最小限の設定で要件を満たすことができます。

参考資料

• Amazon CloudWatch でのカスタムメトリクスの作成
• AWS Lambda とは
• Amazon EventBridge でのルール設定
• AWS CodePipeline イベントの処理
• CloudWatch ダッシュボードの作成

正解: A

A. Amazon EventBridgeルールを設定し、RDSイベントからRDSストレージ自動スケーリングアクティビティを検出する。AWS Lambda関数を設定してCloudWatchカスタムメトリクスを記録する。このEventBridgeルールをLambda関数をトリガーするように設定し、CloudWatchダッシュボードでカスタムメトリクスを表示する。

正解 この方法は、RDSストレージの自動スケーリングアクションを効率的に監視してCloudWatchダッシュボードに表示するための最適な手順です。Amazon RDSは、ストレージの自動スケーリングが発生すると、EventBridgeにイベントを送信します。EventBridgeルールを設定することで、これらの特定のイベントを検出し、Lambda関数をトリガーできます。Lambda関数内では、イベントの詳細を処理してCloudWatchカスタムメトリクスを作成します。カスタムメトリクスには、自動スケーリングの発生時間、関連するDBインスタンス、変更前後のストレージサイズなどの重要な情報を含めることができます。これらのカスタムメトリクスはCloudWatchダッシュボードに直接表示でき、様々なウィジェットやグラフ形式で視覚化できます。この方法の利点は、イベント駆動型であるため、自動スケーリングが発生した時にのみリソースが使用されること、また必要なカスタム情報を正確に記録できることです。これにより、最小限のオーバーヘッドで効率的な監視が可能になります。

B. AWS CloudTrailトレイルを管理イベント有効で設定する。これらの管理イベントをAmazon CloudWatch Logsに送信する。CloudWatch Logs内でRDSストレージ自動スケーリングアクティビティを特定するメトリクスフィルターを作成する。CloudWatchダッシュボードでこのメトリクスフィルターを表示する。

不正解 この方法には根本的な問題があります。CloudWatch Logsのメトリクスフィルタを使用してログイベントからメトリクスを作成することは可能ですが、これらのメトリクスフィルタ自体をCloudWatchダッシュボードに直接表示することはできません。メトリクスフィルタは、ログデータからメトリクスを生成するための手段であり、表示対象ではありません。メトリクスフィルタから生成されるメトリクスをダッシュボードに表示する必要があります。また、CloudTrailを使用してRDS自動スケーリングイベントを捕捉する方法は、RDSが直接EventBridgeに送信するイベントを使用する方法と比較して複雑です。RDSのAPI呼び出しを記録するCloudTrailログは膨大な量になる可能性があり、その中から自動スケーリングに関連するイベントだけを正確にフィルタリングするのは困難です。

C. Amazon EventBridgeルールを作成して、RDSイベントからRDSストレージ自動スケーリングアクションを検出する。CloudWatchアラームを作成し、EventBridgeルールがCloudWatchアラームのステータスを変更するように設定する。CloudWatchダッシュボードでアラームステータスを表示する。

不正解 この方法の問題点は、EventBridgeルールが直接CloudWatchアラームのステータスを変更する機能を持っていないことです。EventBridgeルールは、Lambda関数やSNSトピックなどのターゲットをトリガーすることはできますが、直接CloudWatchアラームの状態を変更することはできません。CloudWatchアラームは通常、メトリクスのしきい値を監視するために使用され、メトリクスの値がしきい値を超えた場合にアラーム状態が変化します。自動スケーリングイベントのような一時的なイベントを検出するために、アラームを継続的に使用することは設計上適切ではありません。また、アラームステータスはOK/ALARM/INSUFFICIENT_DATAの3つの状態しかなく、自動スケーリングイベントの詳細(例:スケーリング前後のストレージサイズや影響を受けたDBインスタンスなど)を記録するには不十分です。このため、この方法は技術的に実現不可能であり、効率的でもありません。

D. AWS CloudTrailトレイルをデータイベント有効で設定する。これらのデータイベントをAmazon CloudWatch Logsに送信する。CloudWatch Logs内でRDSストレージ自動スケーリングアクションをキャプチャするメトリクスフィルターを作成する。CloudWatchダッシュボードでこのメトリクスフィルターを表示する。

不正解 CloudWatch Logsのメトリクスフィルタ自体はダッシュボードに表示できず、フィルタから生成されるメトリクスを表示する必要があります。さらに、CloudTrailのデータイベントはS3オブジェクトレベルのAPIコールやLambda関数の実行など、データプレーンのアクティビティに関連するもので、RDSストレージの自動スケーリングのような管理イベントを追跡するためには適していません。

問われている要件

この問題では、Amazon RDSストレージの自動スケーリングアクションをAmazon CloudWatchダッシュボードに表示する最も効率的な方法を選択する必要があります。要件は以下の通りです：

1. RDSストレージの自動スケーリングアクションを検出する
2. これらのアクションをCloudWatchダッシュボードに表示する
3. 最も効率的な方法を選択する

これを実現するためには、自動スケーリングイベントを適切に検出し、それをCloudWatchメトリクスに変換して、ダッシュボードで視覚化する必要があります。

前提知識

Amazon RDSストレージの自動スケーリング

Amazon RDSのストレージ自動スケーリングは、データベースのストレージを自動的に増加させる機能です：

1. 動作原理：
   • 設定された最大ストレージしきい値までDBインスタンスのストレージ容量を自動的に増加
   • 空きストレージが一定のしきい値を下回ると自動的にスケーリングが発生
   • アラートや手動介入なしに実行される
2. イベント通知：
   • ストレージ自動スケーリングが発生すると、RDSはイベントを生成
   • これらのイベントはAmazon EventBridgeによって検出可能
   • イベントには、スケーリング前後のストレージサイズ、DBインスタンス識別子などの情報が含まれる

Amazon EventBridgeとAWS Lambda

Amazon EventBridgeは、様々なAWSサービスからのイベントを処理するためのサーバーレスイベントバスサービスです：

1. イベントルール：
   • 特定のイベントパターンに基づいてルールを作成
   • イベントが発生すると、ルールに一致した場合にアクションがトリガーされる
   • ターゲットとして、Lambda関数やSNSトピックなどを設定可能
2. AWS Lambda：
   • サーバーレスでコードを実行するコンピューティングサービス
   • イベント駆動型の処理に最適
   • CloudWatchカスタムメトリクスの作成など、データ処理タスクを実行可能

Amazon CloudWatchメトリクスとダッシュボード

CloudWatchは、AWSリソースのモニタリングとオブザーバビリティを提供するサービスです：

1. メトリクス：
   • サービスやアプリケーションの状態を表す時系列データポイント
   • AWS提供の標準メトリクスのほか、カスタムメトリクスも作成可能
   • 名前空間、メトリクス名、およびディメンションによって一意に識別される
2. カスタムメトリクス：
   • PutMetricDataAPIを使用して独自のメトリクスを作成
   • 特定のイベントやアクションを数値データとして記録可能
   • AWS Lambdaなどから簡単に生成できる
3. ダッシュボード：
   • メトリクスを視覚的に表示するためのカスタマイズ可能なホームページ
   • グラフ、数値、ゲージなど様々なウィジェットを配置可能
   • 単一のビューで複数のメトリクスを監視可能

AWS CloudTrailとCloudWatch Logs

AWS CloudTrailとCloudWatch Logsは、ログ記録と監視に関連するサービスです：

1. CloudTrail：
   • AWSアカウント内のAPI呼び出しを記録するサービス
   • 管理イベント（コントロールプレーン操作）とデータイベント（データプレーン操作）を追跡可能
   • ログをS3バケットやCloudWatch Logsに配信可能
2. CloudWatch Logs：
   • ログデータの集約、保存、監視を行うサービス
   • メトリクスフィルターを使用してログイベントからメトリクスを生成可能
   • ただし、メトリクスフィルター自体はダッシュボードに表示できず、生成されたメトリクスを表示する必要がある

解くための考え方

この問題を解決するための最適な方法を選択するには、以下の観点で評価する必要があります：

1. 効率性：
   • 設定の複雑さは最小限か
   • リソース使用量やコストは適切か
   • 必要なときだけリソースが使用されるか
2. 正確性：
   • RDSストレージの自動スケーリングイベントを確実に検出できるか
   • 必要な情報（スケーリング前後のサイズ、対象DBインスタンスなど）を十分に記録できるか
3. 表示の適切性：
   • CloudWatchダッシュボードに正しく表示できるか
   • 視覚的に理解しやすい形式で表示できるか

これらの観点から各選択肢を分析すると：

• EventBridge + Lambda + CloudWatchカスタムメトリクス：
  • イベント駆動型で、ストレージ自動スケーリング発生時のみリソースを使用する（効率的）
  • RDSからのイベントを直接検出できる（正確）
  • カスタムメトリクスはCloudWatchダッシュボードに直接表示可能（適切）
  • 必要な情報を柔軟に記録可能（高い自由度）
• CloudTrail管理イベント + CloudWatch Logs + メトリクスフィルター：
  • すべてのAPI呼び出しを記録するため、不要なログも大量に生成される（非効率的）
  • 特定のイベントを正確にフィルタリングするのが難しい場合がある（精度の問題）
  • メトリクスフィルター自体はダッシュボードに表示できない（表示の問題）
  • 追加のコストが発生する可能性がある（コスト効率が低い）
• EventBridge + CloudWatchアラーム：
  • 技術的に実現不可能（EventBridgeが直接アラームステータスを変更できない）
  • アラームステータスはOK/ALARM/INSUFFICIENT_DATAの3状態のみ（情報不足）
  • イベントの詳細情報を記録できない（情報不足）
• CloudTrailデータイベント + CloudWatch Logs + メトリクスフィルター：
  • RDSストレージの自動スケーリングはデータイベントではなく管理イベント（不適切）
  • より高いコストが発生する（非効率的）
  • メトリクスフィルター自体はダッシュボードに表示できない（表示の問題）

以上の分析から、「EventBridge + Lambda + CloudWatchカスタムメトリクス」が最も効率的かつ適切な方法であることがわかります。イベント駆動型で、必要なときだけリソースを使用し、RDSストレージの自動スケーリングイベントを正確に検出して、必要な情報をCloudWatchダッシュボードに表示することができます。

参考資料

• Amazon RDS イベント通知
• Amazon EventBridge を使用したイベント監視
• AWS Lambda による CloudWatch メトリクスの作成
• CloudWatch ダッシュボードの作成と使用

正解: B, D

A. Amazon AuroraのSingle-AZクラスターを複数のAWSリージョンにまたがってデプロイし、災害時にAuroraの組み込みリカバリ機能を利用する。

不正解 まず、Amazon AuroraのSingle-AZクラスターは、単一のアベイラビリティゾーン内のみでデプロイされるため、ゾーン障害には対応できますが、それだけではリージョン障害に対応することはできません。
また、複数のリージョンに単独のAuroraクラスターをデプロイしても、クラスター間のデータ同期の仕組みが明示されていないため、RPO(リカバリポイント目標)の2時間以内という要件を満たすことが困難です。

B. 2つのAWSリージョンにAmazon Auroraグローバルデータベースを設定し、障害発生時にはセカンダリリージョンをプライマリに変更する。アプリケーションがセカンダリリージョンのAuroraクラスターエンドポイントにアクセスするよう調整する。

正解 Amazon Auroraグローバルデータベースは、複数のAWSリージョンにまたがるデプロイを可能にし、プライマリリージョンからセカンダリリージョンへの低レイテンシでの複製を提供します。データベースの書き込みはプライマリリージョンで行われ、通常1秒未満の遅延でセカンダリリージョンに複製されるため、RPOの2時間以下という要件を十分に満たします。
リージョン障害が発生した場合、マネージドフェイルオーバーまたは手動プロセス(マニュアルフェイルオーバー)を通じて、セカンダリリージョンを新しいプライマリリージョンに昇格させることができます。
このプロセスは通常数分で完了し、RTOの10分以内という要件を満たすことができます。アプリケーションがセカンダリリージョンのエンドポイントにアクセスするよう調整することで、データベース層での迅速なリカバリが可能になります。この方法は特にデータベースの高可用性に重点を置いており、クロスリージョンのデータ一貫性と低いRPO/RTOの両方を実現できる適切な選択です。

C. 複数のAWSリージョンにわたるAmazon Auroraクラスターをデプロイし、ネットワークロードバランサーを使用してこれらのリージョン間でデータベースリクエストを分散させる。

不正解 ネットワークロードバランサー(NLB)は単一のリージョン内でしか動作せず、複数のAWSリージョン間でのデータベースリクエストの分散には使用できません。
また、複数のリージョンにデータベースをデプロイする場合、データベース間の一貫性を維持するためには、適切なレプリケーション戦略が必要です。単純に複数のAuroraクラスターをデプロイしてロードバランサーでリクエストを分散させるだけでは、データの一貫性が確保されず、異なるリージョンで異なるデータが表示される可能性があります。
さらに、リクエストをリージョン間で分散させる方法は、一般的にはデータベースの読み取りスケーラビリティを向上させるためのものであり、ディザスタリカバリの目的には適していません。これらの理由から、この方法は特にRPOとRTOの要件を満たす効果的なディザスタリカバリ戦略とはいえません。

D. アプリケーションを2つのAWSリージョンにまたがってデプロイし、Amazon Route 53のフェイルオーバールーティングを使用して両リージョンのアプリケーションロードバランサーにトラフィックを分散させる。各リージョンにヘルスチェックとAuto Scalingグループを実装する。

正解 2つのAWSリージョンにアプリケーションをデプロイすることで、リージョン障害に対する保護が提供されます。Amazon Route 53のフェイルオーバールーティングにより、プライマリリージョンで障害が発生した場合、トラフィックが自動的にセカンダリリージョンにリダイレクトされます。ヘルスチェックにより、リージョンの状態が継続的に監視され、問題が検出されると自動的にフェイルオーバーがトリガーされます。
Auto Scalingグループは、各リージョンでの需要に応じてリソースを自動的に調整し、パフォーマンスを維持します。Route 53のDNS変更は通常数秒から数分で反映されるため、RTOの10分以内という要件を満たすことができます。
ただし、この選択肢だけではデータベース層のレプリケーションについての言及がないため、もう一方の選択肢(Auroraグローバルデータベース)と組み合わせることで、アプリケーションとデータベースの両方の高可用性が確保され、完全なディザスタリカバリソリューションとなります。

E. アプリケーションを2つのAWSリージョンにデプロイする。AWS Global Acceleratorを使用して、両リージョンのアプリケーションロードバランサー (ALB) にトラフィックを分散させる。ヘルスチェックとAuto Scalingグループを各リージョンに実装する。

不正解 この方法はアプリケーション層のグローバルな可用性を向上させる方法ですが、ディザスタリカバリの観点からは不完全です。AWS Global Acceleratorは、グローバルIPアドレスを使用して複数のリージョンのエンドポイントにトラフィックをルーティングすることができますが、主にパフォーマンスの改善とグローバルユーザーへの低レイテンシアクセスを目的としています。
ディザスタリカバリの文脈では、Global Acceleratorはヘルスチェックに基づいて異常なエンドポイントからトラフィックを自動的に移動させることができますが、この選択肢には重要な欠点があります。
まず、データベースのレプリケーション戦略について言及がないため、リージョン間でのデータ一貫性をどのように維持するのかが不明です。また、Global Acceleratorはトラフィックの分散に重点を置いていますが、RPO(リカバリポイント目標)を確保するためのデータバックアップやレプリケーションの戦略は明確ではありません。さらに、トラフィックの分散はRTOを短縮するのに役立ちますが、データの一貫性や完全性の確保なしには、ディザスタリカバリソリューションとはなりません。

問われている要件

この問題では、MySQLデータベースを使用し、Amazon EC2インスタンス上で動作するアプリケーションのバックアップおよびディザスタリカバリ計画を策定する必要があります。主な要件は以下の通りです：

1. リカバリポイント目標（RPO）: 2時間以下
   • これは、障害発生時に失われる可能性のあるデータ量の最大値を意味します
   • 2時間以下のRPOを実現するには、少なくとも2時間ごとのデータバックアップまたはレプリケーションが必要です
2. リカバリ時間目標（RTO）: 10分以内
   • これは、障害発生からシステム復旧までの最大許容時間を意味します
   • 10分以内のRTOを実現するには、迅速な障害検出と自動または半自動のフェイルオーバーメカニズムが必要です
3. リージョン障害への対応
   • これは、単一のAWSリージョン全体が利用できなくなった場合でも、システムが稼働し続ける必要があることを意味します
   • マルチリージョンのデプロイメントとフェイルオーバーメカニズムが必要です

これらの要件を満たすためには、アプリケーション層とデータベース層の両方に対する適切な戦略が必要です。

前提知識

リカバリポイント目標（RPO）とリカバリ時間目標（RTO）

ディザスタリカバリ計画における重要な概念：

1. RPO（Recovery Point Objective）：
   • 障害発生時に許容できるデータ損失の最大量
   • RPOが小さいほど、より頻繁なバックアップまたは継続的なレプリケーションが必要
   • 例：RPOが2時間の場合、最大2時間分のデータ損失が許容される
2. RTO（Recovery Time Objective）：
   • 障害発生からシステム復旧までの最大許容時間
   • RTOが小さいほど、より迅速なフェイルオーバーメカニズムとより高度な自動化が必要
   • 例：RTOが10分の場合、障害発生から10分以内にシステムを復旧する必要がある

Amazon Auroraグローバルデータベース

複数のAWSリージョンにまたがるデータベースの高可用性を提供するサービス：

1. アーキテクチャ：
   • プライマリリージョンと1つ以上のセカンダリリージョンで構成
   • プライマリリージョンで書き込みが行われ、セカンダリリージョンにレプリケーション
   • 各リージョンのクラスターは複数のAZにまたがり、リージョン内の高可用性を確保
2. レプリケーション：
   • プライマリからセカンダリへの典型的な遅延は1秒未満
   • ストレージレベルでのレプリケーションによる低いオーバーヘッド
   • 非同期レプリケーションのため、極めて低いRPOを実現可能
3. フェイルオーバー：
   • 管理されたフェイルオーバーまたは手動フェイルオーバーをサポート
   • セカンダリリージョンを新しいプライマリに昇格させる通常数分の操作
   • フェイルオーバー時間は通常、10分以内のRTOを満たす

Route 53のフェイルオーバールーティング

DNSベースのトラフィックルーティングとフェイルオーバー機能：

1. フェイルオーバールーティングポリシー：
   • プライマリとセカンダリのリソースを指定
   • ヘルスチェックに基づいて自動的にルーティングを切り替え
   • プライマリリソースが異常な場合、トラフィックを自動的にセカンダリにリダイレクト
2. ヘルスチェック：
   • エンドポイントの定期的なモニタリングを提供
   • HTTP、HTTPS、TCP、または他のAWSリソースの状態をチェック
   • 障害を迅速に検出し、フェイルオーバーをトリガー
3. DNS伝播：
   • DNSの変更が世界中に反映されるのに通常数秒から数分かかる
   • TTL（Time To Live）設定により伝播時間を調整可能
   • 適切に構成されたシステムで10分以内のRTOを実現可能

解くための考え方

この問題を解決するための最適な戦略を選択するには、以下の点を考慮する必要があります：

1. データの整合性と最小のデータ損失：
   • RPO 2時間以下を実現するためには、2時間よりも頻繁なデータバックアップまたはほぼリアルタイムのレプリケーションが必要
   • クロスリージョンレプリケーションが適切なソリューションとなる
2. 迅速な復旧：
   • RTO 10分以内を実現するためには、迅速なフェイルオーバーメカニズムが必要
   • 自動または半自動のフェイルオーバーが望ましい
3. リージョン障害への耐性：
   • マルチリージョンデプロイメントが必須
   • 適切なフェイルオーバー戦略とリージョン間のデータレプリケーション

これらの考慮事項を踏まえ、以下の2つの選択肢が最適な解決策となります：

1. Amazon Auroraグローバルデータベース：
   • 複数リージョンにまたがるデータベースレプリケーションを提供
   • 1秒未満のレプリケーション遅延で2時間以下のRPOを大幅に上回る
   • 数分以内でのセカンダリからプライマリへの昇格で10分以内のRTOを満たす
2. Route 53フェイルオーバールーティングを使用したマルチリージョンアプリケーションデプロイメント：
   • アプリケーション層のクロスリージョン高可用性を確保
   • ヘルスチェックによる迅速な障害検出
   • 自動フェイルオーバーによる10分以内のRTO
   • Auto Scalingによるリソースの自動管理

これら2つの選択肢を組み合わせることで、アプリケーション層とデータベース層の両方に対する包括的なディザスタリカバリソリューションが実現します。一方のみでは、全体的なシステムの回復力は不完全となります。

参考資料

• Amazon Aurora グローバルデータベース
• Amazon Route 53 フェイルオーバールーティング
• AWS ディザスタリカバリのアーキテクチャ
• Amazon Aurora の耐障害性
• マルチリージョンクロスアカウントハイアベイラビリティ

正解: A

A. プライマリリージョンとセカンダリリージョンのS3バケット間で双方向のS3バケットレプリケーションを設定する。DynamoDBテーブルをグローバルテーブルに移行し、セカンダリリージョンを追加リージョンとして選択する。

正解 この方法は、S3とDynamoDBの両方のデータに対して、リアルタイムかつ効率的なレプリケーションを実現します。
S3の双方向バケットレプリケーションは、プライマリとセカンダリの両リージョンで行われた変更を自動的に反映します。オブジェクトが一方のリージョンで作成、更新、または削除されると、これらの変更は他方のリージョンに自動的にレプリケートされます。このプロセスは完全に自動化されており、管理オーバーヘッドがほとんどありません。
同様に、DynamoDBグローバルテーブルは、複数のリージョンにまたがるフルマネージドのマルチリージョンレプリケーションを提供します。グローバルテーブルに構成すると、任意のリージョンで行われた変更は通常1秒以内に他のすべてのリージョンに自動的に伝播されます。これにより、リアルタイムの要件が満たされます。
また、どちらのソリューションもAWSによって完全に管理されるため、複雑なカスタムコードやインフラストラクチャの管理が不要となり、運用効率が最大化されます。

B. S3バケットのすべてに対して、プライマリリージョンとセカンダリリージョン間でS3バッチオペレーションを使用してコピータスクを設定する。DynamoDBテーブルをグローバルテーブルに変換し、セカンダリリージョンを追加リージョンとして構成する。

不正解 この方法は、DynamoDBのグローバルテーブルを使用する部分は適切ですが、S3データのレプリケーション戦略に問題があります。
S3バッチオペレーションは、大量のS3オブジェクトに対してバッチ処理を実行するためのツールであり、定期的なジョブとして実行されます。これは継続的な自動レプリケーションを提供するものではなく、スケジュールされたバッチジョブに依存します。そのため、「リアルタイムにレプリケート」という要件を満たすことができません。バッチジョブの間に発生した変更は、次のジョブが実行されるまでレプリケートされないため、両リージョン間でデータの不整合が生じる期間が発生します。また、バッチジョブの設定、スケジューリング、モニタリングには追加の運用オーバーヘッドが必要となり、運用効率も最適ではありません。

C. 両リージョンのS3バケット間で双方向のS3バケットレプリケーションを確立する。DynamoDBテーブルでDynamoDB Streamsを有効にし、両リージョンにAWS Lambda関数をデプロイして、これらのストリームをサブスクライブし、他のリージョンのテーブルに新しいレコードをレプリケートする。

不正解 この方法は、S3の双方向バケットレプリケーションを使用する部分は適切ですが、DynamoDBデータのレプリケーション方法に効率上の問題があります。
DynamoDB StreamsとLambda関数を使用したカスタムレプリケーションソリューションは技術的には機能しますが、複雑なカスタムコードの開発と維持が必要となり、これには相当な開発と運用のオーバーヘッドが伴います。

D. すべてのS3バケットの間でプライマリリージョンとセカンダリリージョン間でS3バッチオペレーションを使用してレプリケーションタスクを設定する。DynamoDBテーブルでDynamoDB Streamsを有効にし、各リージョンでAWS Lambda関数を設定してストリームをサブスクライブし、他のリージョンのテーブルに新しいエントリをレプリケートする。

不正解 S3バッチオペレーションの使用は、リアルタイムのレプリケーション要件を満たさず、DynamoDB StreamsとLambda関数によるカスタムレプリケーションは運用効率が低いです。
S3バッチオペレーションは、定期的なスケジュールで実行されるバッチジョブであり、継続的なリアルタイムレプリケーションではありません。これにより、バッチジョブの間に行われた変更はリアルタイムに反映されず、両リージョン間でデータの不整合が生じます。
また、DynamoDBデータのレプリケーションにカスタムLambda関数を使用することは、複雑なコード開発、デプロイメント、モニタリング、メンテナンスを必要とし、運用オーバーヘッドが大きくなります。

問われている要件

この問題では、現在1つのAWSリージョンで運用されているアプリケーションを、以下の要件を満たしながらセカンダリリージョンに拡張する必要があります：

1. Amazon DynamoDBテーブルとAmazon S3バケットのデータが両リージョン間で同期されること
2. 更新がリアルタイムにレプリケートされること
3. 最高の運用効率で実現すること

これらの要件を満たすには、DynamoDBテーブルとS3バケットの両方に対して、リアルタイムで効率的なレプリケーション戦略を選択する必要があります。

前提知識

Amazon S3クロスリージョンレプリケーション

Amazon S3は、異なるリージョン間でのデータレプリケーションをサポートするいくつかの機能を提供しています：

1. S3クロスリージョンレプリケーション（CRR）：
   • 異なるAWSリージョン間でS3オブジェクトを自動的にコピー
   • 単方向または双方向のレプリケーションが可能
   • レプリケーションルールに基づいて選択的に適用可能
   • オブジェクトの作成、更新、削除を自動的にレプリケート
2. 双方向レプリケーション：
   • 双方向のクロスリージョンレプリケーションは、両方のバケットで変更されたオブジェクトを相互にレプリケート
   • リージョンA→リージョンBとリージョンB→リージョンAの両方向のレプリケーションルールを設定
   • 変更が発生したバケットからもう一方のバケットへ自動的にレプリケート
3. S3バッチオペレーション：
   • 大量のS3オブジェクトに対してバッチ処理を実行するためのツール
   • 特定のタイミングで実行される一時的なジョブ
   • 継続的な自動レプリケーションではなく、スケジュールされたタスクとして機能
   • リアルタイムレプリケーションには適していない

DynamoDBのレプリケーションオプション

DynamoDBには、複数リージョン間でのデータレプリケーションに関する以下のオプションがあります：

1. DynamoDBグローバルテーブル：
   • 複数のAWSリージョンにまたがるフルマネージドのマルチリージョンレプリケーション
   • 任意のリージョンで行われた変更を他のすべてのリージョンに自動的にレプリケート
   • 通常1秒以内の遅延でリージョン間のデータを同期
   • 自動的な競合解決メカニズムを提供（最新の書き込みが優先）
   • 完全に管理されたサービスで、インフラストラクチャやコードの管理が不要
2. DynamoDB Streams + Lambda：
   • DynamoDB Streamsはテーブルの変更をキャプチャし、時系列で表示
   • AWS Lambda関数を使用して、これらの変更を別のリージョンのテーブルにレプリケート
   • カスタムコードの開発と管理が必要
   • 双方向レプリケーションのための競合解決ロジックを手動で実装する必要がある
   • エラー処理、再試行ロジック、モニタリングを自分で管理する必要がある

解くための考え方

この問題を解決するための最適な戦略を選択するには、以下の点を考慮する必要があります：

1. リアルタイムレプリケーション：
   • 更新がリアルタイムにレプリケートされる必要がある
   • バッチオペレーションや手動プロセスではなく、自動的かつ継続的なレプリケーションが必要
2. 運用効率：
   • カスタムコードの開発と維持の複雑さを最小限に抑える
   • インフラストラクチャのプロビジョニングと管理の負担を軽減
   • 信頼性の高い自動化されたソリューションを優先
3. ソリューションの適合性：
   • S3データとDynamoDBデータの両方に対して適切なレプリケーション戦略を選択
   • 各サービスの特性に最適なレプリケーション方法を採用

これらの考慮事項を踏まえると、最適な解決策は以下のようになります：

• S3データの場合：
  • 双方向のS3バケットレプリケーションを設定
  • 自動的かつリアルタイムにオブジェクトの変更をレプリケート
  • マネージドサービスとして、運用オーバーヘッドを最小限に抑える
• DynamoDBデータの場合：
  • DynamoDBグローバルテーブルを使用
  • フルマネージドのリアルタイムレプリケーションを提供
  • 競合解決、エラー処理、スケーリングが自動的に管理される

この「プライマリリージョンとセカンダリリージョンのS3バケット間で双方向のS3バケットレプリケーションを設定し、DynamoDBテーブルをグローバルテーブルに移行する」方法は、リアルタイムレプリケーションと最高の運用効率という両方の要件を満たします。

参考資料

• Amazon S3 クロスリージョンレプリケーション
• Amazon DynamoDB グローバルテーブル
• DynamoDB グローバルテーブルのベストプラクティス
• S3バッチオペレーションの概要

正解: A

A. ALBのクロスゾーン負荷分散を無効にし、Amazon Route 53 Application Recovery Controller を使用してゾーナルシフトを実行し、影響を受けたゾーンを迂回する。

正解 ALBのクロスゾーン負荷分散を無効にすることで、各AZのロードバランサーノードは同じAZ内のターゲットにのみトラフィックを分散するようになります。これにより、AZ間でのトラフィック分散が停止し、各AZは独立して動作するようになります。
次に、Amazon Route 53 Application Recovery Controller(ARC)のゾーナルシフト機能を使用して、影響を受けたAZへのトラフィックを明示的に停止します。ゾーナルシフトは、特定のAZ内のAWSリソースへのトラフィックルーティングを一時的に停止するための機能で、影響を受けたAZを意図的に迂回することができます。
これら2つの機能を組み合わせることで、障害が発生したAZへのトラフィックルーティングを完全に回避し、他の健全なAZにのみトラフィックをルーティングすることが可能になります。この方法は、検証のために特定のAZへのトラフィックをルーティングしないという要件を最も直接的かつ効果的に満たします。

B. ALBのターゲットグループでクロスゾーン負荷分散を無効にし、Amazon Route 53 Application Recovery Controller を使用して影響を受けたゾーンからゾーナルシフトを開始する。

不正解 この選択肢の問題点は、クロスゾーン負荷分散の設定場所にあります。ALBのターゲットグループレベルでクロスゾーン負荷分散を無効にするという記述は技術的に正確ではありません。実際には、ALBのクロスゾーン負荷分散設定は、ターゲットグループ単位ではなく、ロードバランサー自体のプロパティとして設定されます(Application Load Balancerの場合)。そのため、「ALBのターゲットグループでクロスゾーン負荷分散を無効にする」という前半の記述は誤っています。
また、Amazon Route 53 ARCを使用してゾーナルシフトを開始するという部分は正しい方法ですが、設定の前提が誤っているため、全体としてこの選択肢は適切ではありません。

C. ALBのDNSホスト名を使用してAmazon Route 53 Application Recovery Controller リソースセットを設定し、影響を受けたゾーンからのゾーナルシフトをリソースセットに対して実行する。

不正解 この選択肢の主な問題点は、ALBのDNSホスト名を使ってRoute 53 ARCリソースセットを設定する方法では、特定のAZへのトラフィック制御を行えない点にあります。
ALBのDNSホスト名はロードバランサー全体を指し、特定のAZを識別するものではありません。Route 53 ARCのゾーナルシフトは、特定のAZ内のリソースへのトラフィックをシフトするために使用されますが、それをALBのDNSホスト名に適用しても、ALB自体は複数のAZにまたがって動作しているため、特定のAZのみをターゲットにすることはできません。
また、この方法ではクロスゾーン負荷分散の無効化についても言及されていないため、ALBが依然として全てのAZにトラフィックを分散する可能性があります。そのため、この方法では特定のAZへのトラフィックルーティングを制御するという要件を満たすことができません。

D. ALBのターゲットグループのARNを使用してAmazon Route 53 Application Recovery Controller リソースセットを設定し、ElbV2TargetGroupsCanServeTrafficルールを用いて準備チェックを含める。

不正解 ElbV2TargetGroupsCanServeTrafficルールは、ターゲットグループ全体がトラフィックを処理できるかどうかを確認するためのものであり、特定のAZへのトラフィックルーティングを制御するためのものではありません。さらに、この選択肢ではクロスゾーン負荷分散の設定については言及されていないため、ALBが依然として全てのAZにトラフィックを分散する可能性があります。

問われている要件

この問題では、部分的なサービス停止が発生したアベイラビリティゾーン（AZ）内のEC2インスタンスが他の健全なインスタンスに影響を与えないようにするため、ApplicationLoad Balancer（ALB）が特定のAZへトラフィックをルーティングしないようにする最適な方法を選択する必要があります。重要な要件は以下の通りです：

1. 障害が発生したAZへのトラフィックルーティングを停止すること
2. 他の健全なAZのインスタンスは引き続き正常にトラフィックを処理できること
3. DevOpsエンジニアが行った調整を検証するために、特定のAZへのトラフィックを制御できること

これらの要件を満たすためには、ALBの設定とトラフィック制御メカニズムを適切に組み合わせる必要があります。

前提知識

ALBのクロスゾーン負荷分散

Application Load Balancer（ALB）は、複数のアベイラビリティゾーン（AZ）にまたがるEC2インスタンスにトラフィックを分散するために使用されます。ALBのクロスゾーン負荷分散には以下の特徴があります：

1. クロスゾーン負荷分散が有効な場合:
   • 各AZのロードバランサーノードは、すべてのAZの登録済みターゲットにトラフィックを均等に分散します
   • これがデフォルト設定であり、すべてのターゲットに均等にトラフィックが分散されます
   • AZ間のEC2インスタンス数の不均衡があっても、各インスタンスは均等な負荷を受けます
2. クロスゾーン負荷分散が無効な場合:
   • 各AZのロードバランサーノードは、同じAZ内の登録済みターゲットにのみトラフィックを分散します
   • AZごとに受信するトラフィックの量に基づいて、インスタンスへの負荷が決まります
   • 特定のAZへのトラフィックルーティングを停止すると、そのAZ内のインスタンスはトラフィックを受け取りません
3. 設定場所:
   • Application Load Balancerの場合、クロスゾーン負荷分散はロードバランサーレベルで設定されます
   • Network Load Balancerとゲートウェイロードバランサーの場合は、ターゲットグループレベルで設定されます

Amazon Route 53 Application Recovery Controller (ARC)

Amazon Route 53 ARCは、アプリケーションの回復力を高め、障害発生時のトラフィック管理を支援するためのサービスです：

1. ゾーナルシフト:
   • 特定のAZ内のAWSリソースへのトラフィックルーティングを一時的に停止する機能
   • 障害が発生したAZを意図的に迂回することで、アプリケーションの可用性を維持
   • リソースのタイプに応じて、異なるレベルでゾーナルシフトを適用可能
2. リソースセット:
   • 監視および回復アクションの対象となるAWSリソースのグループ
   • 同じタイプのリソース（例：ALB、EC2インスタンス）をグループ化
3. 準備チェック:
   • リソースがトラフィックを処理する準備ができているかを確認するチェック
   • ElbV2TargetGroupsCanServeTrafficなどのルールを使用して、特定の条件を評価

解くための考え方

この問題を解決するための最適な方法を選択するには、以下の観点で各選択肢を評価する必要があります：

1. トラフィック制御の粒度:
   • 特定のAZへのトラフィックを正確に制御できるか
   • 他の健全なAZへのトラフィックに影響を与えないか
2. 実装の正確性:
   • 技術的に正確で実装可能か
   • AWSサービスの実際の機能と一致しているか
3. 効果の検証:
   • DevOpsエンジニアの調整を検証するために適切なフィードバックを提供できるか
   • 一時的な変更を行い、元に戻すことができるか

これらの観点から各選択肢を分析すると：

• ALBのクロスゾーン負荷分散を無効にし、Route 53 ARCゾーナルシフトを使用:
  • クロスゾーン負荷分散を無効にすることで、各AZは独立して動作し、特定のAZへのトラフィック制御が可能になる
  • ゾーナルシフトにより、影響を受けたAZへのトラフィックを完全に停止できる
  • 両機能を組み合わせることで、最も直接的かつ効果的に要件を満たす
• ALBのターゲットグループでクロスゾーン負荷分散を無効にし、ゾーナルシフトを使用:
  • ALBのクロスゾーン負荷分散はターゲットグループレベルではなく、ロードバランサーレベルで設定される
  • 技術的に不正確であるため、実装できない
• ALBのDNSホスト名を使用してリソースセットを設定し、ゾーナルシフトを実行:
  • ALBのDNSホスト名はロードバランサー全体を指し、特定のAZを識別できない
  • ゾーナルシフトを適用しても、特定のAZのみをターゲットにすることはできない
• ターゲットグループのARNを使用してリソースセットを設定し、準備チェックを含める:
  • ターゲットグループは通常、複数のAZにまたがるため、特定のAZのみを対象とした制御が難しい
  • 準備チェックはリソースの状態を監視するものであり、直接的なトラフィック制御メカニズムではない

以上の分析から、「ALBのクロスゾーン負荷分散を無効にし、Amazon Route 53 Application Recovery Controller を使用してゾーナルシフトを実行し、影響を受けたゾーンを迂回する」という方法が最も適切であることがわかります。この方法により、特定のAZへのトラフィックを効果的に制御し、DevOpsエンジニアの調整を適切に検証することができます。

参考資料

• Application Load Balancer のクロスゾーン負荷分散
• Amazon Route 53 Application Recovery Controller
• Route 53 ARC でのゾーナルシフト
• ALBのアベイラビリティゾーンとターゲットグループの設定
• AWS のディザスタリカバリと高可用性

正解: B

A. サービスに関連付けられたセキュリティグループが ALB からのトラフィックを許可していることを確認する。

不正解 セキュリティグループの設定は、ALBからECSタスクへの接続可否に関わる問題です。もしセキュリティグループが原因であれば、すべてのヘルスチェックが一貫して失敗し、タスクが起動しても接続できないという状態になります。
問題の説明では「タスクが終了して再起動を繰り返す」とあり、これはタスクが一時的に起動しているが、ヘルスチェックの猶予期間内に正常応答できないことを示唆しています。セキュリティグループの問題であれば、タスクは起動したまま残りますが、ヘルスチェックは常に失敗し続けるでしょう。

B. サービスの ALB ヘルスチェックの猶予期間を延長する。

正解 ALBヘルスチェックの猶予期間は、新しいタスクが起動してからヘルスチェックが成功するまでに許容される時間です。問題の説明から、新しいコンテナイメージを使用するようにタスク定義が更新された後に問題が発生したことがわかります。
新しいコンテナイメージは、以前のイメージよりも初期化に時間がかかる可能性があります（例：アプリケーションの起動時処理が増加、依存関係の解決に時間がかかるなど）。ヘルスチェックの猶予期間を延長することで、タスクが完全に初期化され、正常に応答できるようになるまでの時間を確保できます。これにより、タスクが終了して再起動を繰り返すという問題が解決される可能性が高いです。

C. サービスの「最低正常率」構成を引き上げる。

不正解 「最低正常率」はECSサービスのデプロイ設定であり、デプロイ中に維持すべき正常タスクの最小割合を指定します。この値を引き上げると、デプロイ時により多くのタスクが正常である必要がありますが、タスクのヘルスチェック失敗そのものを解決するものではありません。
実際には、最低正常率を引き上げると、問題が発生している状況ではデプロイがさらに困難になる可能性があります。なぜなら、より多くの新しいタスクが正常である必要があるのに、新しいタスクはヘルスチェックに失敗し続けているからです。

D. ALB ヘルスチェックの間隔を短くする。

不正解 ヘルスチェックの間隔を短くすると、ヘルスチェックがより頻繁に実行されるようになります。問題の状況では、タスクが初期化に十分な時間を取れていない可能性が高いです。ヘルスチェックの間隔を短くすると、タスクが準備できる前により頻繁にヘルスチェックが実行されることになり、問題をさらに悪化させる可能性があります。
タスクが準備できていない状態でヘルスチェックが実行されると失敗し、失敗回数が増えるとタスクは異常と判断されて終了し、再起動されるというサイクルが加速してしまいます。

問われている要件

この問題では、Amazon ECSとALBを使用したウェブアプリケーションにおいて、タスク定義を新しいコンテナイメージに更新した後に発生したサービス障害の診断と解決方法が問われています。具体的には、サービスがALBのヘルスチェックに失敗し続け、タスクが終了して再起動を繰り返すという問題状況において、DevOpsエンジニアとしてどのように対応すべきかを判断する必要があります。

前提知識

Amazon ECSのタスクライフサイクル

Amazon ECSのタスクは、以下のライフサイクルを持ちます：

1. PROVISIONING: タスクのリソースをプロビジョニングしている状態
2. PENDING: タスクがコンテナインスタンスに配置される待機状態
3. RUNNING: タスクが実行中の状態
4. DEPROVISIONING: タスクが終了処理中の状態
5. STOPPED: タスクが停止した状態

タスクが正常に終了した場合や、ヘルスチェックに失敗した場合など、様々な理由でタスクは停止状態になることがあります。ECSサービスは、設定された必要タスク数を維持するために、停止したタスクを自動的に再起動します。

Application Load Balancer (ALB) のヘルスチェック

ALBは、ターゲットグループに登録されたターゲット（この場合はECSタスク）の健全性を定期的に確認するためにヘルスチェックを行います。ヘルスチェックには以下の重要な設定があります：

1. ヘルスチェックのパス: ALBがリクエストを送信するエンドポイント（例：/health）
2. 間隔: ヘルスチェックを実行する頻度
3. タイムアウト: ヘルスチェックリクエストに対するレスポンスを待つ時間
4. 正常しきい値: ターゲットが正常と見なされるまでに必要な連続した成功ヘルスチェックの数
5. 異常しきい値: ターゲットが異常と見なされるまでに必要な連続した失敗ヘルスチェックの数

ECSサービスの設定

ECSサービスには、デプロイメントとヘルスチェックに関連する重要な設定があります：

1. デプロイメント設定:
   • 最小正常率: デプロイ中に常に実行状態を維持する必要があるタスクの割合
   • 最大率: 一度に実行できるタスクの最大数（サービスの望ましいタスク数に対する割合）
2. ヘルスチェック猶予期間:
   • 新しいタスクが起動してから最初のヘルスチェックが実行されるまでの猶予期間
   • この期間中、タスクのヘルスステータスがチェックされない、または失敗しても無視される
   • これにより、タスクがアプリケーションを完全に初期化し、リクエストに応答できるようになるまでの時間を確保できる

コンテナの初期化時間と起動時間

コンテナイメージが変更されると、以下の要因により初期化時間が変わる可能性があります：

1. アプリケーションの初期化処理:
   • データベース接続の確立
   • キャッシュの準備
   • 設定ファイルの読み込み
   • 依存サービスとの接続確立
2. コンテナイメージのサイズと内容:
   • イメージサイズが大きい場合、ダウンロードと展開に時間がかかる
   • より多くの依存関係がある場合、初期化に時間がかかる
3. システムリソース:
   • メモリとCPUの制約が厳しい場合、初期化が遅くなる

新しいコンテナイメージが以前のイメージよりも初期化に時間がかかる場合、既存のヘルスチェック猶予期間が不十分になり、タスクが準備できる前にヘルスチェックが失敗する可能性があります。

ヘルスチェック設定の最適化

ヘルスチェック設定の最適化には、以下の点を考慮する必要があります：

1. 猶予期間の適切な設定:
   • アプリケーションの実際の起動時間に基づいて設定
   • 余裕を持たせる（例：平均起動時間 + 10〜20秒）
2. ヘルスチェックエンドポイントの設計:
   • 軽量で高速に応答するエンドポイントを使用
   • アプリケーションの重要なコンポーネントの健全性を確認する
3. ヘルスチェックの間隔とタイムアウト:
   • 間隔を長くすると、タスクの起動時間に余裕ができる
   • タイムアウトを長くすると、応答時間が遅いタスクでも正常と判断される可能性がある

ヘルスチェックの猶予期間を延長することは、新しいコンテナイメージの初期化時間が長い場合の最も直接的な解決策です。これにより、タスクが完全に起動して応答できるようになるまでの時間を確保できます。

解くための考え方

この問題を解くためには、以下の手順で考えるとよいでしょう：

1. 問題の根本原因を特定する：
   • 問題が発生したタイミングは「新しいコンテナイメージを使用するようタスク定義を更新し、サービスに適用した後」
   • 症状は「サービスがALBのヘルスチェックに失敗し続け、タスクが終了して再起動を繰り返す」
2. 可能性のある原因を検討する：
   • 新しいコンテナイメージの初期化時間が長い
   • コンテナが正しく起動していない
   • ヘルスチェックの設定と実際のアプリケーションの状態が一致していない
   • ネットワーク接続の問題
3. 選択肢を評価する：
   • どの選択肢が問題の根本原因に対処しているか
   • どの選択肢が症状（タスクの再起動サイクル）を緩和できるか

ここで重要なのは、「タスクが終了して再起動を繰り返す」という症状です。これは、タスクが一時的に起動するものの、ALBのヘルスチェックに合格できず、その結果タスクが不健全と判断されて終了し、新しいタスクが起動するというサイクルを示唆しています。新しいコンテナイメージを使用するように変更した直後に問題が発生したことから、新しいイメージが起動して準備が整うまでの時間が、設定されたヘルスチェックの猶予期間よりも長くなっている可能性が高いです。

• Application Load Balancer ヘルスチェックの設定
• Amazon ECS タスクのヘルスチェック
• Amazon ECS サービスの定義パラメータ
• Amazon ECS タスクの起動時間を最適化する