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

正解：A、B、D

A. 共有サービスアカウントに共通ライブラリ用のリポジトリを作成し、各チームのリポジトリからアップストリームとして参照させます。

正解 共有サービスアカウントに共通ライブラリを集約し、各チームのリポジトリのアップストリームに設定します。チームのリポジトリにパッケージが無ければ共有リポジトリから自動で取得・キャッシュされるため、各チームが個別にコピーを持つ必要がなくなり、バージョンも一貫します。

B. 共有サービスアカウントにドメインを1つだけ作成し、組織全体への読み取りアクセスとリポジトリ作成権限を付与します。

正解 ドメインを共有サービスアカウントに1つだけ置いて中央管理すれば、設定やポリシーの一貫性を保てます。組織全体への読み取り許可で共通ライブラリを全チームが使え、リポジトリ作成権限で各チームは必要に応じて自前のリポジトリを用意できます。管理の一元化と組織全体での共有を同時に実現します。

C. 各チームが他チームのリポジトリを直接アップストリームリポジトリに指定して、必要なパッケージを相互に取り寄せます。

不正解 チームが互いのリポジトリを直接参照すると、チーム間の依存が複雑に絡み合います。あるチームの変更が別のチームへ予期せぬ影響を与え、影響範囲の追跡も難しくなります。共通ライブラリは中央の共有サービスアカウントで一元管理する方が一貫性を保ちやすくなります。

D. 各チームのアカウントに自チーム用のリポジトリを作成し、そのリポジトリへの読み取り・書き込み権限をチームに完全に付与します。

正解 各チームが自アカウント内のリポジトリを完全に管理できるようにすれば、パッケージの公開やバージョン管理を他チームの承認なしで進められ、開発サイクルに合わせた自律的な運用が可能になります。チーム固有のパッケージを扱ううえで、この自由度は重要です。

E. 各タイトルの開発チームのアカウントごとに CodeArtifact ドメインを個別に作成し、それぞれのドメイン内で読み取りと書き込みを許可します。

不正解 タイトルの数だけドメインが増えるため、ドメインごとの権限設定やポリシー管理がチーム数に比例して増えます。共通ライブラリを全チームへ届けるにはドメインをまたいだ権限調整も必要になり、一元管理とは逆の方向です。「最小限の管理工数」という要件を満たせません。

F. 共有の必要が生じるたびに、相手チームのアカウントからの読み取りを許可するリソースポリシーをチーム間で1件ずつ作成します。

不正解 チーム間で読み取りを1件ずつ許可していくと、チーム数が増えるほどポリシーの数と更新作業が増えます。新しいチームが加わるたびに既存ポリシーの見直しが要り、拡張性に欠けます。中央管理と比べて追加の複雑さが増えるだけで、最小限の管理工数にはなりません。

全体的な説明

問われている要件

• 12 本のゲームタイトルごとに専用の AWS アカウントがあり、共有サービスアカウントへは制限付きのアクセスだけが許可されていること
• 各チームが自チームのパッケージを公開・更新できる十分な権限を持つこと
• 認証・課金・分析基盤などの共通ライブラリを組織全体で参照できるようにすること
• これらを最小限の管理工数で満たすこと

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

前提知識

AWS CodeArtifact

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

ドメイン（Domain）：

• CodeArtifactの最上位のリソースで、リポジトリの論理的なグループ
• 1つのAWSアカウントには複数のドメインを作成可能
• ドメイン内のリポジトリは、同じドメイン内の他のリポジトリをアップストリームとして参照可能
• 異なるAWSアカウント間でドメインを共有することも可能（ドメイン所有アカウントとは別のアカウントがドメイン内にリポジトリを所有することもでき、その場合はドメイン所有アカウントがドメインのリソースポリシーでCreateRepository権限を付与する）

リポジトリ（Repository）：

• パッケージを格納する場所
• 特定のパッケージタイプ（npm、Maven、PyPI、NuGet、Cargo、Ruby、Swift、汎用パッケージ）をサポート
• 1つのドメインには複数のリポジトリを作成可能

アップストリームリポジトリ（Upstream Repository）：

• あるリポジトリが別のリポジトリをアップストリームとして参照することができる仕組み
• リポジトリ内でパッケージが見つからない場合、アップストリームリポジトリが自動的に検索される
• これにより、パッケージの依存関係を効率的に解決できる
• パッケージが見つかると、そのパッケージは自動的にリポジトリにコピーされる（キャッシング）
• アップストリームは同一ドメイン内のリポジトリを対象とし、1つのリポジトリに直接設定できるアップストリームは最大10個

パブリックリポジトリ接続：

• CodeArtifactリポジトリからnpmjs.orgやMaven Centralなどのパブリックリポジトリに接続可能
• これにより、パブリックパッケージを安全に利用できる

リソースポリシー：

• リソース（ドメインやリポジトリ）へのアクセス制御を細かく設定可能
• 組織内の特定のアカウントやIAMプリンシパルにリソースへのアクセスを許可できる

AWS Organizations

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

アカウント管理：

• 複数のAWSアカウントを組織単位（OU）に整理
• アカウントの一元的な作成と管理

一元的なポリシー管理：

• サービスコントロールポリシー（SCP）を使用してアカウント間で一貫したポリシーを適用
• タグポリシーやバックアップポリシーの一元管理

一括請求：

• 組織内のすべてのアカウントの一括請求
• ボリュームディスカウントの適用

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

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

IAMロールの引き受け（AssumeRole）：

• あるアカウントのIAMエンティティが別のアカウントのIAMロールを引き受ける
• 一時的な認証情報を使用して、別アカウントのリソースにアクセス

リソースポリシー：

• S3バケットポリシーやCodeArtifactリソースポリシーなど
• リソース側でどのプリンシパル（ユーザー、ロール、アカウント）がアクセスできるかを定義

AWS Resource Access Manager（RAM）：

• 特定のAWSリソースを複数のアカウントと共有するためのサービス
• 共有可能なリソースタイプは限定的

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

中央集権型管理：

• 共通サービスやツールは中央のアカウントで管理
• 各チームや環境に専用のアカウントを提供

最小権限の原則：

• 各アカウントやIAMエンティティには必要最小限の権限のみを付与
• 権限の範囲を制限することでセキュリティリスクを最小化

自律性とガバナンスのバランス：

• チームに十分な自律性を与える一方で、組織全体の一貫性やコンプライアンスを確保
• ガードレールを設定しつつ、イノベーションを妨げない

アーキテクチャ図の解説

アーキテクチャ図

共有サービスアカウントに単一のドメインを置き、その下に共通ライブラリ用のリポジトリを集約します。組織全体にはドメインへの読み取りアクセスとリポジトリ作成権限が与えられ、各開発チームはその権限で自アカウントにリポジトリを作成してパッケージを管理します。共通ライブラリのリポジトリは各チームのリポジトリからアップストリームとして参照されるため、チーム側にパッケージが無ければ共有リポジトリから自動で取得・キャッシュされます。ドメインをチームごとに分けたり、チーム同士でアップストリームを直接張ったりすると、権限設定がチーム数ぶんに増えたり依存関係が複雑化したりして、管理工数が膨らみます。ドメインを中央に1つに絞ることで、共有と自律性を最小の管理コストで両立できます。

解くための考え方

共有ドメインとアップストリーム参照で、権限設定の重複を減らせるかを見ます。

管理の複雑さを最小化：

• 多数のドメインやリポジトリを個別に管理するのではなく、中央で管理する方法を検討
• 権限設定やポリシー管理の回数を減らす方法を考える

チームの自律性の確保：

• 各チームが自身のパッケージを独自に管理できる権限を確保
• チーム固有の開発サイクルに影響を与えない構成を検討

共有ライブラリへのアクセス：

• 組織全体で共有ライブラリにアクセスする効率的な方法を検討
• 一貫性のあるバージョン管理と配布を確保

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

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

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

参考資料

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

正解：C

A. パーミッションセットへ拒否を追加し、aws:SourceAccount が管理アカウント ID と一致するリクエストに対して sso:* と sso-directory:* を拒否するよう設定します。

不正解 パーミッションセットという制御点の選択と、`sso:*`/`sso-directory:*` を拒否する方針は正しいのですが、発動条件に使ったキーがこの場面には存在しません。`aws:SourceAccount` がリクエストコンテキストに現れるのは、AWSサービスが利用者の代わりにサービス間リクエストを発行する場合に限られます。担当者がコンソールやCLIから直接IAM Identity Centerを操作するリクエストにはこのキーが含まれないため、条件は一致せず、Denyは一度も発動しません。結果として管理アカウント内のSSO操作は許可されたままになります。

B. 管理アカウントを新しい OU へ移し、その OU に SCP をアタッチし直して管理アカウントへの制限を実現します。

不正解 この案は「SCPはアタッチ先のOU配下にだけ効く」という理解に立っていますが、そもそもSCPが適用されるのはメンバーアカウントのプリンシパルだけで、管理アカウントのプリンシパルには届きません。管理アカウントをどのOUへ置いてもSCPの効力範囲に含めることはできないため、クラウド基盤チームの操作権限はそのまま残ります。SCPで管理アカウントを縛ること自体が成立しないのです。

C. パーミッションセットへ拒否を追加し、aws:PrincipalAccount が管理アカウント ID と一致する場合に限って sso:* / sso-directory:* を拒否するよう設定します。

正解 パーミッションセットという制御点の選択と、`sso:*`/`sso-directory:*` を拒否する方針は正しく、さらに発動条件に使うキーも適切です。`aws:PrincipalAccount` は呼び出し側の所属アカウントを表し、あらゆるリクエストに必ず含まれるため、管理アカウント内の操作だけを正確に捉えられます。PlatformOpsに`sso:*`と`sso-directory:*`の拒否ステートメントを足し、発動条件をこのキーと管理アカウントIDの一致に限定すれば、メンバーアカウントでの業務は従来どおり許可され、管理アカウント内の操作だけが止まります。パーミッションセットは管理アカウントにプロビジョニングされるIAMロールとして評価されるため、SCPが届かない管理アカウント内でもこの制限だけは実効します。

D. ルートへ適用している SCP を書き換え、クラウド基盤チームのロール ARN と管理アカウント ID を発動条件として追加します。

不正解 OUを付け替える案と同じ誤りを、条件式の側から繰り返したものです。SCPにロールARNやアカウントIDの条件を書き込んでも、SCPが効くのはメンバーアカウントだけという制約は変わりません。したがって管理アカウント内でクラウド基盤チームが行うIAM Identity Centerの操作には、このポリシーは一切効きません。

全体的な説明

問われている要件

• AWS Organizationsを利用する組織で、クラウド基盤チームが管理アカウント内でIAM Identity Centerを操作できないようにすること
• クラウド基盤チームは「PlatformOps」パーミッションセット経由でAdministratorAccessを持ち、全アカウントでIAM Identity Centerを操作できること
• セキュリティ監査チームが組織ルートに適用したSCPは管理アカウントに効かず、アクセスが続いていること
• SCPが効かない理由を組織の仕様として理解し、管理アカウントにだけ届く別の制御点を選ぶこと

前提知識

AWS Organizations

AWS Organizationsは、複数のAWSアカウントを一元管理するためのサービスです。主な特性は次のとおりです。

組織構造：

• 管理アカウント：組織の作成と管理を行う最上位のアカウント
• メンバーアカウント：組織に属するその他のアカウント
• 組織単位（OU）：アカウントを論理的に束ねるグループ化の仕組み

サービスコントロールポリシー（SCP）：

• 組織内のアカウントに許可される操作の上限を決めるガードレールです
• 配下のメンバーアカウントのIAMユーザー・ロールに継承されます
• 重要な制限: 管理アカウントのユーザー・ロールには適用されず、効力が及ぶのはメンバーアカウントだけです（メンバーアカウント側ではrootユーザーにも適用されます）
• サービスにリンクされたロール（service-linked role）にもSCPは適用されません

一括請求：

• 組織内のすべてのアカウントの使用料を一括で管理します

IAM Identity Center (旧AWS SSO)

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

パーミッションセット：

• IAM Identity Centerで定義される権限のまとまりです
• AWS管理ポリシー（例：AdministratorAccess）をベースにできます
• カスタムの権限内容を定義することもできます

グループと割り当て：

• IDプロバイダー（例：Active Directory）から同期されたユーザーグループを使います
• グループへパーミッションセットを割り当て、対象のAWSアカウントに適用します

アクセス制御：

• パーミッションセットは各アカウントへIAMロールとしてプロビジョニングされます
• ユーザーがアカウントへアクセスすると、対応するIAMロールが引き受けられます

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

IAMポリシーは以下の順序で評価されます。

1. **明示的な拒否**: いずれかのポリシーに “Effect”: “Deny” があれば、そのアクセスは拒否されます

2. **明示的な許可**: 拒否がなく “Effect”: “Allow” があれば、アクセスは許可されます

3. **暗黙的な拒否**: 許可も無い場合は、デフォルトで拒否されます

IAMポリシーの条件キー

条件キーを使うと、DenyやAllowが効く状況を絞り込めます。

• aws:SourceAccount: サービス間リクエストにおいて、リクエストを所有するアカウントIDが入るキーです（ユーザーの直接リクエストには含まれません）
• aws:PrincipalAccount: リクエストを行うプリンシパルが属するアカウントIDです（すべてのリクエストに含まれます）
• aws:PrincipalOrgID: プリンシパルが所属する組織のIDを条件に指定します
• aws:ResourceAccount: 操作対象リソース側のアカウントIDを条件に指定します

アーキテクチャ図の解説

アーキテクチャ図

拒否の条件は、アクションだけでなく「どのアカウントに対して行われた操作か」にも結び付いています。修正後のPlatformOpsパーミッションセットは、リクエスト元のaws:PrincipalAccountが管理アカウントIDと一致する場合にのみsso:*とsso-directory:*を拒否します（①②）。管理アカウント内でも対象外のサービス操作はDenyの範囲外として許可され（③）、メンバーアカウントでの操作は条件が不一致のため従来どおり評価されます（④）。条件を付けずにアクションだけで拒否すると、メンバーアカウント側で行う正規の設定変更まで巻き添えで止まり、運用が回らなくなります。拒否の範囲を「どのアクションか」ではなく「どのアカウントに対してか」で絞るのが、この種のガードレールの定石です。

アーキテクチャ図

SCPの効果が組織の階層のどこまで届き、どこで止まるかを示した図です。ルートにアタッチしたSCPは配下のOUとメンバーアカウントへ継承され、メンバーアカウント側ではSSO経由のアクセスを制限できますが、管理アカウントのプリンシパルには適用されません。そのためAdministratorAccessを持つクラウド基盤チームは、管理アカウントのIAM Identity Center設定をそのまま操作できてしまいます。これはAWS Organizationsの仕様であり、設定ミスではありません。「ルートにSCPを付けたのだから組織全体を封じた」と読み替えてしまうのが、この構成でもっとも起きやすい誤解です。管理アカウントを塞ぐには、SCPではなくパーミッションセット自体の修正が必要になります。

解くための考え方

制御点が「組織」側にあるか「アイデンティティ」側にあるかを見極めます。

SCPの限界を確認する：

• SCPは管理アカウントのプリンシパルに適用されないため、OUの組み替えや条件の追加では管理アカウントを制限できません
• ルートのSCPが効いていないのは設定ミスではなく仕様です

パーミッションセットの性質を確認する：

• クラウド基盤チームの権限は「PlatformOps」パーミッションセットがプロビジョニングするIAMロールから来ています
• このロールは管理アカウント内にも存在するため、パーミッションセットの内容は管理アカウント内でも評価されます

制御点を選ぶ：

• 管理アカウント内だけで効かせたい制限は、パーミッションセット内の条件付きDenyで実装します
• 条件キーには、直接リクエストにも必ず含まれるaws:PrincipalAccountを使います（aws:SourceAccountはサービス間リクエストにしか含まれないため不適です）

この整理に従えば、既存のパーミッションセットへ管理アカウントIDを条件とするDenyを追加する選択肢が残ります。メンバーアカウントでの権限はそのままに、管理アカウント内でのIAM Identity Center操作だけを止められます。

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

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

このポリシーは、プリンシパルの所属アカウントが管理アカウントの場合にのみsso:*およびsso-directory:*を拒否し、それ以外の操作はすべて許可します。直接リクエストにも必ず含まれるaws:PrincipalAccountを使うことで、コンソール・CLIのいずれからの操作も確実に判定できます（aws:SourceAccountはこの用途には使えません）。

参考資料

• IAM Identity Center (AWS SSO) の概要
• サービスコントロールポリシー (SCP)
• AWS グローバル条件コンテキストキー（aws:PrincipalAccount 等）
• AWS Organizations のアカウント管理

正解：B

A. 集中管理する S3 バケットを保存先にした AWS Backup のバックアッププランを作成し、現在のロググループをすべて関連付けます。新規のロググループは AWS Systems Manager Automation で追加し、AWS Config ルールと自動修復で実装します。

不正解 AWS Backup は CloudWatch Logs をネイティブにサポートしていません。また、AWS Backup と Systems Manager を組み合わせる方式は複雑で、リアルタイムのログ転送には適しません。新規ロググループへの適用には手動の組み込みが残り、将来のロググループまで自動でカバーできません。

B. CloudWatch Logs の出力先（Destination）と Kinesis Data Firehose 経由で S3 バケットへ配信します。既存ロググループにはサブスクリプションフィルターを設定し、新規ロググループには EventBridge と Lambda で同じ設定を自動適用します。

正解 CloudWatch Logs のデータをリアルタイムで特定の S3 バケットへ転送できます。既存のロググループにはサブスクリプションフィルターを設定して宛先へ送信し、Kinesis Data Firehose（2024年2月に Amazon Data Firehose へ改称）が S3 バケットへ配信します。新規のロググループは EventBridge が作成を検知し、Lambda がサブスクリプションフィルターを自動で設定します。これにより、現在と将来のロググループの両方をリアルタイムで集約できます。

C. AWS Organizations のバックアップポリシーを実装し、全ロググループのデータを指定の S3 バケットへ保存するよう設定します。あわせて S3 バケットポリシーを更新し、組織内の全アカウントからのアクセスを許可します。

不正解 Organizations のバックアップポリシーが制御するのは AWS Backup のバックアッププランであり、CloudWatch Logs のデータを S3 へリアルタイムに転送する機能はありません。バックアップはスケジュールに基づくコピーなので、ログのリアルタイム集約という要件を満たせません。

D. AWS Backup でバックアッププランを作成して特定の S3 バケットを保存先に指定し、このプランにロググループを割り当てて組織内の全アカウントを対象に含めます。

不正解 AWS Backup は CloudWatch Logs をバックアップ対象としてネイティブにサポートしていません。AWS Backup が扱うのは EC2 インスタンス、RDS データベース、DynamoDB テーブル、EFS ファイルシステム、Amazon S3 などで、CloudWatch Logs は直接のバックアップ対象にできません。さらに AWS Backup の保存先はバックアップボールトであり、任意の S3 バケットを保存先として指定することもできません。加えて定期的なスナップショットによるバックアップなので、リアルタイム転送という要件も満たせません。

全体的な説明

問われている要件

• 40 を超える各アカウントの CloudWatch Logs に蓄積される再生・配信ログを、リアルタイムに特定アカウント内の S3 バケットへ転送すること
• 既存のロググループだけでなく、新しいサービス追加で生まれる将来のロググループにも自動で適用されること
• 複数アカウントにまたがるログを単一のアカウントへ集約し、データ分析基盤へ渡すこと

前提知識

CloudWatch Logs

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

ロググループ：

• ログストリームの論理的なグループ
• アプリケーション、サービス、環境ごとに作成されることが多いです
• 保持期間、アクセス制御などの設定はロググループレベルで適用されます

ログストリーム：

• 同じソースからのイベントシーケンス
• 例えば、1つのアプリケーションインスタンスからのログなど

サブスクリプションフィルター：

• ロググループからリアルタイムでデータを他のAWSサービスに転送するための仕組み
• サポートされる宛先には、Lambda、Kinesis Data Streams、Amazon Data Firehose（旧Kinesis Data Firehose）、別のアカウントのCloudWatch Logs宛先などがあります
• 2024年1月以降は、アカウントレベルのサブスクリプションフィルターポリシーにより、アカウント内の現在・将来のロググループへ一括で適用することも可能（ただし設定はアカウントごとに必要で、1アカウントにつき1つのサブスクリプションフィルターポリシーを持てます）

クロスアカウントデータ共有：

• CloudWatch Logs宛先（Destination）を使用して、あるアカウントのログデータを別のアカウントに送信できます
• 宛先アカウントではIAMロールと宛先ポリシーを使用してアクセス制御を設定できます

Amazon Data Firehose（旧Amazon Kinesis Data Firehose）

Amazon Data Firehose（2024年2月にAmazon Kinesis Data Firehoseから名称変更）は、ストリーミングデータを目的の宛先にリアルタイムで配信するためのフルマネージドサービスです：

主な特徴：

• データの変換、バッチ処理、圧縮をサポート
• 宛先には、S3、Redshift、OpenSearch Service、Splunkなどがあります
• バッファリング、リトライなどの機能を提供

CloudWatch Logsとの統合：

• サブスクリプションフィルターとCloudWatch Logs宛先を通じて、CloudWatch LogsからFirehoseにデータを直接送信可能
• データをS3に保存する前に処理または変換できます

AWS Lambda

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

主な特徴：

• サーバー管理不要でコードを実行
• さまざまなイベントソースからトリガー可能
• AWSのサービスと連携して自動化タスクを実行

CloudWatch Logsとの統合：

• CloudWatch Logsからイベントを受け取り処理できます
• PutSubscriptionFilter APIを呼び出して、サブスクリプションフィルターを動的に設定できます

Amazon EventBridge

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

主な特徴：

• イベントパターンに基づいてルールを定義
• イベントが発生したときに特定のアクションをトリガー
• 複数のAWSサービスとの統合

CloudWatch Logsとの統合：

• ロググループの作成など、CloudTrailが記録したAPI呼び出し（CreateLogGroupなど）をイベントとして検出可能（この検出にはCloudTrailの証跡が有効になっている必要があります）
• 検出したイベントに基づいて、Lambda関数などのターゲットを起動できます

AWS Organizations

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

主な特徴：

• 複数のAWSアカウントを組織単位にグループ化
• 一元的なポリシー管理を提供
• アカウント間のリソース共有をサポート

リソース共有：

• 特定のS3バケットに対するアクセス許可を組織内の複数アカウントに付与可能
• IAMロールとリソースポリシーを使用して、クロスアカウントアクセスを設定

アーキテクチャ図の解説

アーキテクチャ図

リアルタイム集約にはバックアップではなく、サブスクリプションフィルターと Firehose の組み合わせが要る点が要点です。既存のロググループはサブスクリプションフィルターから宛先（Destination）へ転送し、Kinesis Data Firehose を経由して特定アカウントの S3 バケットへ格納します。将来のロググループは EventBridge が作成を検知し、Lambda がフィルターを自動付与します。AWS Backup はスケジュール型スナップショットで、CloudWatch Logs をネイティブにサポートしておらず、リアルタイム転送を満たせません。即時性を「バックアップで足りる」と読み替えるのが起きやすい誤解です。

解くための考え方

既存と新規のロググループの両方を、リアルタイムに単一アカウントへ集約できるかを見ます。

リアルタイムデータ転送：

• CloudWatch Logsデータをリアルタイムで転送する方法を選択します
• データの遅延を最小限に抑える必要があります

クロスアカウント設定：

• 複数アカウントからのデータを単一のアカウントに集約する方法を設計します
• 適切なアクセス制御を確保します

自動化と将来のロググループ対応：

• 新しいロググループが作成されたときに自動的に設定を適用する方法を検討します
• 継続的なメンテナンスを最小限に抑えます

次の構成で、既存と新規のロググループをリアルタイムに集約します：

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ストリーム

正解：C

A. セキュリティ設定を指定する Systems Manager Run Command タスクを作成し、Systems Manager Maintenance Windows で毎日実行するようスケジュールしてターゲットを設定します。

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

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

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

C. セキュリティ設定を定義した Systems Manager コマンドドキュメントを紐付けた State Manager の関連付けを作成し、タグクエリでインスタンスを即時に検出して構成を適用します。

正解 Systems Manager State Manager は、インスタンスの構成を定義して維持するサービスです。関連付けを作成し、Auto Scaling グループが自動付与するタグをターゲットに指定することで、新しく起動されたインスタンスを即座に識別して必要なセキュリティ設定を適用できます。SSM Agent が動作を開始すると定義済みの構成がすぐに適用され、タグクエリで対象が動的に検出されるため、Auto Scaling で増えたインスタンスも取りこぼしません。この方式は「起動直後に即座に」という要件を満たします。

D. セキュリティ設定を記した Systems Manager Run Command ドキュメントを作成し、インスタンスが最新のパッチ基準を満たしていない場合に Run Command を実行するよう Systems Manager Compliance を使用します。

不正解 Systems Manager Compliance は、パッチ適用状況やアソシエーションのコンプライアンスを評価する機能であり、構成を自動的に適用するツールではありません。評価はインスタンスがしばらく稼働した後に行われるため、「起動直後に即座に」という要件を満たせません。また、パッチ基準への準拠状況を OS 構成の適用に結び付けるのは、別々の作業を不適切に関連付けており、信頼性の高い自動化にはなりません。

全体的な説明

問われている要件

• 決済処理を担う EC2 インスタンスは Auto Scaling グループによって作成され、キャンペーン時に数十台から数百台へ増減すること
• インスタンスには既に SSM Agent が組み込まれ、起動時に自動でタグが付与されること
• セキュリティ基準を満たす OS 設定を「起動直後に即座に」適用すること

前提知識

AWS Systems Manager (SSM)

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

SSM Agent：

• EC2インスタンスにインストールされるソフトウェア
• Systems Managerサービスとインスタンス間の通信を可能にします
• コマンドの実行、パッチ適用、インベントリ収集などの機能を提供

State Manager：

• インスタンスの設定を定義し、維持するためのサービス
• 関連付け（Association）を通じて、インスタンスに対する設定を適用
• インスタンスが起動すると速やかに適用されます（SSM Agentが動作開始すれば）
• タグをターゲットにした関連付けでは、一致するタグを持つマネージドノードが新たに追加されると関連付けが自動的に適用され、その場で1回実行されてから以降はスケジュールに従います（この即時実行はコマンドドキュメントまたはポリシードキュメントを使う関連付けが対象で、Automationランブックを使う関連付けには当てはまりません）
• スケジュールに基づいて定期的に適用することも可能

Run Command：

• インスタンスでコマンドをリモートで実行するサービス
• オンデマンドで実行されます
• コマンドドキュメントを使用してタスクを定義

Maintenance Windows：

• 定期的なメンテナンス作業をスケジュールするためのサービス
• 特定の時間帯にタスクを実行

Patch Manager：

• パッチの適用を管理するためのサービス
• パッチベースラインを使用して適用するパッチを定義

Compliance：

• パッチ適用状況やアソシエーションコンプライアンスを評価するサービス
• 設定の適用自体は行いません

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

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

タグクエリ：

• 特定のタグキーと値に基づいてインスタンスを動的に選択
• 例：tag:Environment=Production

Auto Scalingグループとタグ：

• Auto Scalingグループは、起動するインスタンスに自動的にタグを付与できます
• これらのタグを使用して、Systems Manager操作のターゲットを指定できます

アーキテクチャ図の解説

アーキテクチャ図

タグクエリによる動的なターゲット検出が、起動直後の自動適用を実現する要点です。Auto Scaling グループは AMI からインスタンスを起動してタグを付与し（①）、SSM Agent が起動します（②）。Agent は State Manager のタグクエリで検出され（③）、State Manager がコマンドドキュメントを送信して（④）セキュリティ設定を適用します（⑤）。スケジュール型の Maintenance Windows と異なり、ウィンドウ開始を待たず速やかに設定が行き渡るため、決済処理を担うインスタンスが未設定のまま残りにくくなります。ここを「定期実行で十分」と読み替えると、起動から適用までに監査基準を満たさないインスタンスが残るのが落とし穴です。

解くための考え方

起動直後にセキュリティ設定を適用でき、台数の増減にも追従できるかを見ます。

即時性：

• インスタンス起動後すぐに設定を適用する必要があります
• 定期的なスケジュールではなく、イベント駆動型のアプローチが望ましいです

自動化：

• 手動介入なしで設定を適用できます
• Auto Scalingによって動的に変化するインスタンス群を対象にできます

一貫性：

• すべてのインスタンスに同じ設定が確実に適用されます
• 設定のドリフトを防止します

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

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

• 作成したコマンドドキュメントを指定
• Auto Scalingグループが付与するタグを使用してターゲットを指定（例：tag:AutoScalingGroupName=my-asg）
• 関連付けのスケジュール（適用頻度）を設定（新たに起動したインスタンスにはスケジュールを待たずに検出直後の1回が実行されます）

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

参考資料

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

正解：A

A. Amazon EC2 の API アクションだけが許可され、EC2 以外の API はすべて拒否されます。

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

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

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

C. Amazon EC2 の API アクションは拒否され、EC2 以外の API はすべて許可されます。

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

D. すべての AWS サービスの API アクションが許可されます。

不正解 Service Control Policy（SCP）は組織内のアカウントで利用可能な最大権限を制限します。SCP は許可リストとして機能し、明示的に許可されていないアクションは実行できません。BizUnit OU の SCP を EC2 API アクションのみを許可するものに置き換えた場合、配下の全アカウント（Platform OU のアカウントも含む）の最大権限は EC2 API のみになります。AdministratorAccess が付与されたロールでも、EC2 以外のサービスへのアクセスは制限されます。すべての API アクションが許可されるという結論は誤りです。

全体的な説明

問われている要件

• AWS Organizations 内で SCP の変更が、アカウントに設定された IAM ロールの権限にどう影響するかを理解すること
• 具体的には、BizUnit OU から FullAWSAccess SCP を削除して EC2 API アクションのみを許可する SCP に置き換えた場合に、Platform OU の 18 個のアカウントに設定された管理者 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ポリシーの許可範囲の共通部分」として決まります。管理者ロールのアクション要求はSCP評価とIAMポリシー評価の両方を通過する必要があり（①②）、SCPがガードレールとしてEC2 API以外を拒否し（③）、IAMポリシーは全APIを許可しますがSCPの制約を上書きできません（④）。AdministratorAccessを付与されたロールでも、SCPがEC2のみ許可なら実効権限はEC2 APIだけに絞られます。ここを「AdministratorAccessがあるから全部できる」と読み替えるのが最も起きやすい誤解です。SCPはIAMポリシーを無効化するのではなく、最大権限を制限するという関係を押さえる必要があります。

アーキテクチャ図

上位OUのSCP制限は、配下のアカウントまで継承されます。BizUnit OUのSCPをEC2のみ許可に変更すると、その制限はPlatform OUのアカウントへ波及します。Platform OUにFullAWSAccessが残っていても、上位のEC2のみ許可SCPが制約となり、アカウントの実効権限は全SCPの論理積であるEC2 APIのみになります。AdministratorAccessを付与された管理者ロールもEC2 APIだけに制限されます。「子OUにFullAWSAccessが残っているから大丈夫」と考えるのが、この構成で最も起きやすい誤解です。SCPはルートからアカウントまでの全経路でAND評価されることを押さえる必要があります。

解くための考え方

実効権限はSCPとIAMポリシーの共通部分です。次の点を見ます。

組織構造の理解:

• 組織ルートの下にBizUnit OU（FullAWSAccess SCPが適用されている）があり、その下にPlatform OU（FullAWSAccess SCPが適用されている）がある
• Platform OUには複数のAWSアカウントがあり、各アカウントにFullAWSAccess SCPが適用され、管理者IAMロールにAdministratorAccessポリシーが設定されている

SCPの変更の影響:

• BizUnit OUからFullAWSAccess SCPを削除し、EC2 APIアクションのみを許可するSCPに置き換える
• この変更はBizUnit OUのすべての子OU（Platform OU）とアカウントに影響する

有効な権限の計算:

• 初期状態: SCPからすべてのアクション許可（FullAWSAccess）、IAMからすべてのアクション許可（AdministratorAccess）→ 有効権限はすべてのアクション許可
• 変更後: SCPからEC2 APIアクションのみ許可、IAMからすべてのアクション許可（AdministratorAccess）→ 有効権限はEC2 APIアクションのみ許可

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

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

参考資料

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

正解：B

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

不正解 この方法には複数の問題があります。「パブリックアクセスブロック」を無効にすると、意図しない公開アクセスからバケットを守る機能が外れてセキュリティリスクが高まります。これは商品管理担当者のアクセス問題とは無関係です。また、`aws:SourceAccount` は AWS のサービスプリンシパルがリソースを直接呼び出したときにのみリクエストコンテキストに含まれる条件キーであり、IAM ユーザーやロールが自ら発行するリクエストには含まれません。したがってこの条件をバケットポリシーに追加しても商品管理担当者のアクセス可否には効かず、むしろ条件が一致せずアクセスを妨げる結果になり得ます（呼び出し元アカウントで判定したい場合は `aws:PrincipalAccount` を使います）。加えて、組織内に存在する SCP や IAM 権限境界など、より上位の制約も考慮していないため、根本解決になりません。

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

正解 この方法は、S3 アクセス問題の最も有力な根本原因に対処しています。AWS Organizations の構造内では、SCP は OU 内のすべてのアカウントに影響し、IAM ポリシーより上位の制約として機能します。S3 バケットへのアクセスを拒否している SCP の存在を確認することは、根本原因の特定に欠かせません。IAM 権限境界もユーザーやロールの最大権限を制限するため、S3 アクセスを妨げる原因になります。これらを確認して調整すれば根本原因に対処できます。さらに、変更を CodeCommit へコミットして CloudFormation でデプロイすることで、IaC のベストプラクティスに沿った一貫性のある変更管理になります。

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

不正解 この方法はアクセス問題を解決するのではなく、むしろ複雑にします。担当者の OU で IAM リソースへの変更を防止する SCP を実装すると、担当者が自分の IAM 権限を管理する能力をさらに制限します。また、`aws:SourceAccount` は AWS のサービスプリンシパルによる直接呼び出しでのみリクエストに含まれる条件キーであり、担当者本人の IAM プリンシパルによるリクエストには含まれないため、この条件を足しても担当者のアクセスが通るようにはなりません。問題は既存の SCP や IAM 権限境界など上位の制約にあり、この解決策ではそれらの確認が行われていません。デプロイの方法は正しいものの、適切な解決策をデプロイしていません。

D. 商品管理担当者のアクセスを制限している IAM 権限境界がないか確認し、あれば調整します。影響を受けている担当者アカウントに AWS Config レコーダーを実装して設定ミスを修正し、解決策を CodeCommit リポジトリにコミットして CloudFormation でデプロイします。

不正解 IAM 権限境界の確認など一部は適切ですが、不完全です。権限境界はユーザーやロールの最大権限を制限するため、アクセス問題の原因になることは確かにあります。しかし、AWS Config レコーダーの実装は設定変更の記録とコンプライアンス監視に役立つものの、即時の問題解決策ではありません。また、OU レベルで適用されている SCP を確認する点が欠けています。CodeCommit と CloudFormation によるデプロイは適切ですが、根本原因に対処していません。

全体的な説明

問われている要件

• AWS Organizations の構造内で複数の AWS アカウントが異なる OU に分けて管理されていること
• すべてのリソース（IAM ポリシーや S3 ポリシーを含む）が CloudFormation を通じてデプロイされ、テンプレートとコードが CodeCommit に保存されていること
• 問題の S3 バケットには既にバケットポリシーが設定されていること
• 30 名ほどの商品管理担当者の一部がこの S3 バケットにアクセスできないこと
• アクセス問題を解決する最も適切なアプローチを選択すること

前提知識

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

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

組織構造：

• 組織のルート：組織の最上位コンテナ
• 組織単位（OU）：アカウントの論理的なグループ。階層構造を形成できます
• アカウント：個々のAWSアカウント

サービスコントロールポリシー（SCP）：

• AWS Organizationsの機能で、組織内のアカウントで利用可能な最大権限を制限します
• OU単位で適用され、その下のすべてのアカウントに影響します
• IAMポリシーよりも優先されます（SCPで拒否されるとIAMで許可されていても拒否されます）
• 「許可リスト」または「拒否リスト」として機能します
• 組織レベルのガードレールとしては、2024年11月に追加されたリソースコントロールポリシー（RCP）もあり、こちらはS3などのリソース側に対して組織横断で権限の上限を設定します

アクセス制御階層：

• SCPはアカウントの最大権限を制限する最上位の制約
• IAM権限境界はユーザーやロールに設定できる最大権限を制限
• IAMポリシー（アイデンティティベースまたはリソースベース）が実際のアクセス許可を決定
• リソースポリシー（S3バケットポリシーなど）も権限を制御

IAM権限境界

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

機能：

• アイデンティティに付与できる最大権限を制限します
• 権限境界自体はアクセス権を付与しません
• アイデンティティベースのポリシーと権限境界の共通部分が実際の権限となります

評価ロジック：

• アイデンティティにアクションの実行を許可するには、アイデンティティポリシーと権限境界の両方でそのアクションが許可されている必要があります
• 権限境界で明示的に許可されていないアクションは、アイデンティティポリシーで許可されていても実行できません

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

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

機能：

• バケットレベルでのアクセス制御を定義
• プリンシパル（ユーザー、ロール、アカウント）ごとに異なるアクセス権限を設定可能
• クロスアカウントアクセスを許可する手段として使用可能

パブリックアクセスブロック：

• バケットレベルまたはアカウントレベルで設定可能
• 意図しないパブリックアクセスを防ぐためのセキュリティ機能
• 商品管理担当者の正規アクセスには通常影響しません

条件キー：

• aws:SourceAccount：AWSのサービスプリンシパルがリソースを直接呼び出す場合にのみリクエストコンテキストに含まれ、その呼び出しの起点となったアカウントを表します。IAMユーザーやロールが自ら発行するリクエストには含まれないため、人が行うアクセスの制御には使えません
• aws:PrincipalAccount：リクエストを行ったプリンシパルが属するアカウントを指定（すべてのリクエストで利用可能）
• aws:PrincipalOrgID：プリンシパルが属する組織を指定
• aws:PrincipalTag：プリンシパルに付けられたタグに基づいてアクセスを制御

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

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

AWS CloudFormation：

• AWSリソースをテンプレート（YAMLまたはJSON）として定義
• スタックを通じてリソースを一括デプロイおよび管理
• 変更の追跡と一貫したデプロイを可能にします

AWS CodeCommit：

• マネージドのGitリポジトリサービス
• インフラストラクチャコードのバージョン管理とコラボレーションを可能にします
• 2024年7月に新規顧客への提供が一時停止されましたが、2025年11月に一般提供（GA）へ復帰し、現在は新規のアカウントでもリポジトリを作成できます

アーキテクチャ図の解説

アーキテクチャ図

S3バケットポリシーが設定済みでも、上位の評価層で拒否があればアクセス不能になります。商品管理担当者のアクセスは、まずSCP（第1層）で評価され（①）、通ればIAM権限境界（第2層）、IAMポリシー（第3層）と順に評価されて（②③）、最後にバケットポリシー（第4層）に到達します（④）。上位で拒否されると、下位のIAMポリシーやバケットポリシーが許可していてもアクセスは通りません。解決策はSCPと権限境界を確認・調整し、その変更をCodeCommitへコミットしてCloudFormationでデプロイすることです。バケットポリシーだけを直したりパブリックアクセスブロックを外したりしても、上位の制約が残る限り根本解決にならない、というのがこの構成で最も起きやすい誤解です。

解くための考え方

評価の何層目で拒否されているかを先に切り分けます。

アクセス制御階層の理解：

• AWS Organizationsのアクセス制御は階層的です
• 最上位から順に：SCP → IAM権限境界 → IAMポリシー → リソースポリシー
• 上位レベル（SCPやIAM権限境界）で許可されていないアクションは、下位レベルで許可されていても実行できません

問題の根本原因の特定：

• S3バケットポリシーは設定されていることが既に分かっています
• アクセス問題の原因は、より上位の制約（SCPやIAM権限境界）にある可能性が高いです
• OUレベルでのSCPの設定が商品管理担当者のアクセスを妨げている可能性があります
• IAM権限境界が商品管理担当者の権限を制限している可能性もあります

変更管理の一貫性：

• すべてのリソースはCloudFormationを通じてデプロイされています
• テンプレートとコードはCodeCommitリポジトリに保存されています
• 解決策も同じ管理方法に従う必要があります

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

参考資料

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

正解：D

A. 既存の処理ロジックはそのままにコンテナ化し、AWS Fargate上で実行する方式へ移行します。ステージが進むごとにコンテナを順番に呼び出すよう設定します。

不正解 コンテナ化でデプロイの一貫性は高まりますが、Fargateはコンテナの実行基盤を提供するだけであり、ワークフローの制御や状態追跡、エラー処理の機能は備えていません。ステージ間の調整、データの受け渡し、失敗したステージだけの再実行は引き続き自前で構築する必要があります。さらにステージのたびにコンテナを起動するオーバーヘッドが生じるため、5分以内で完了する短い処理には効率面で見合いません。

B. アップロードされた動画をAmazon S3へ書き込む受け口を用意し、S3のイベント通知からAmazon SNSトピックへメッセージを送ります。あわせて新着動画を常時監視して処理を開始するEC2インスタンスを配置し、各ステージの中間成果物をS3に保存します。

不正解 ステージ間の中間成果物をS3に置き、S3のイベント通知とSNSトピックを経由して処理を進める構成です。ただし、ステージごとの状態管理と、失敗したステージだけを再実行する仕組みは自前で実装する必要があります。さらにEC2インスタンスを常時稼働させて動画を待ち受ける方式は、イベントが発生したときだけ動くサーバーレス構成に比べて管理とコストの負担が大きくなります。5分以内で終わる各ステージには、この構成は複雑すぎます。

C. Amazon Kinesis Data Streamsへレコードを送る受け口を実装し、AWS Lambda関数を組み合わせて処理を複数の単位に分割して実行します。

不正解 Kinesis Data Streamsは連続するデータのストリーム処理には向いていますが、複数ステージで構成されるワークフローの管理や、途中の失敗ステージだけを再処理する機能は持ち合わせていません。ストリームは順次処理されるため、中間ステージ単体の再実行は標準では行えません。Lambda関数同士のデータ受け渡しや状態管理も自前実装になり、この要件を効率的には満たせません。

D. AWS Step Functionsを組み込んだ受け口を実装し、処理をStep FunctionsとAWS Lambda関数で管理する個別のタスクへ分割します。

正解 Step Functionsは、複数ステージのワークフロー管理に最も適したサービスです。各ステージを個別のステートとして定義し、それぞれをLambda関数で実行できます。Step Functionsには次の利点があります。

1. 状態管理: 各ステージの成功・失敗・進行中を自動で追跡します。

2. エラーハンドリング: 失敗したステージだけを再試行する仕組みが組み込まれています。

3. ワークフロー制御: 条件分岐、並列処理、待機など複雑な制御が可能です。

4. サーバーレス: Lambdaと統合し、必要なときだけリソースを使います。

5. 可視化: 実行状況を視覚的に監視できます。

各ステージをLambda関数で実装し、Step Functionsでワークフローを管理すれば、失敗したステージのみを再処理する要件を効率よく満たせます。各ステージは5分以内で、Lambdaの実行時間上限（最大15分）にも収まります。

全体的な説明

問われている要件

• 動画が「取り込み、トランスコード、サムネイル生成、配信準備」の4つの連続ステージで処理されること
• 処理基盤がEC2インスタンス上のAuto Scalingグループで動き、各ステージの計算負荷が高いこと
• 各ステージが5分以内に完了すること
• 現在は1つのステージが失敗すると全体を最初から再処理していること
• 失敗したステージのみを再処理して効率を高めること

前提知識

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

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

AWS Step Functions

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

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

AWS Lambda

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

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

アーキテクチャ図の解説

アーキテクチャ図

複数のステージを1つのステートマシンで直列に管理し、失敗したステージだけへ差し戻す構成です。アップロードAPIがStep Functionsへワークフロー開始を要求すると（①）、ステートマシンは取り込み・トランスコード・サムネイル生成の各ステージをLambda関数として順次呼び出します（②③④）。全ステージが成功した場合だけ処理完了に到達します（⑤）。途中のステージが失敗すると、Step FunctionsのRetryが同じステージへ制御を戻し（⑥⑦）、最初からやり直すことなく当該ステージだけを再実行します。状態追跡とリトライを自前で組まずに済むのが、S3やストリーム、コンテナで代用する案との決定的な違いです。各Lambdaの実行時間は5分以内に収まり、最大15分の上限に抵触しません。

解くための考え方

失敗したステージだけへ差し戻せ、状態をマネージドに追跡できるかを見ます。

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. 必要に応じてフォールバック（代替処理）やエラー通知を実装

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

参考資料

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

正解：A、B

A. スキャン完了イベントでAWS Lambda関数を起動するAmazon EventBridgeルールを設定します。このLambda関数はAmazon Inspectorの結果を評価し、CI/CDワークフローへApprovedまたはRejectedステータスを送信します。

正解 拡張スキャンでイメージがスキャンされると、スキャン完了イベントがAmazon EventBridgeへ送信されます。EventBridgeルールでこのイベントを検知してLambda関数を呼び出し、LambdaがAmazon Inspectorの結果からCRITICALやHIGHの有無を評価して、CodePipelineへApprovedまたはRejectedを送信します。CodePipelineには承認ステージを設けられるため、評価結果に応じてデプロイを進行または停止できます。これにより、CRITICALまたはHIGHの脆弱性を持つイメージのデプロイを防げます。

B. Amazon ECRの拡張スキャンをリポジトリに設定します。

正解 拡張スキャンはAmazon Inspectorを使って実行され、OSパッケージに加えて、Java、Python、JavaScript、Goなど各種プログラミング言語のパッケージの脆弱性もスキャンします。コンテナイメージに含まれる幅広い脆弱性を検出し、Common Vulnerability Scoring System（CVSS）スコアに基づく重大度評価でCRITICALやHIGHを特定できます。これにより、OSと言語の両方をカバーする要件を満たせます。

C. CRITICALまたはHIGHの脆弱性を持つイメージにRejectedステータスを付与するよう、Amazon ECRを構成します。

不正解 Amazon ECRには、イメージに対して「Rejected」というステータスを明示的に付与する機能はありません。ECRは脆弱性をスキャンして結果を報告できますが、スキャン結果に基づいてイメージへステータスを割り当てる機能はネイティブには備えていません。スキャン結果でパイプラインの進行を制御するには、別のロジックやサービスが必要です。

D. スキャン完了イベントでAWS Lambda関数を起動するAmazon EventBridgeルールを設定します。このLambda関数は、旧基本スキャンで使われていたClairスキャンの結果を評価し、CI/CDワークフローへApprovedまたはRejectedステータスを送信します。

不正解 Clairは、以前のECR旧基本スキャンで使われていたオープンソースの脆弱性スキャンツールです。現在の基本スキャンはAWSネイティブの技術へ置き換えられており（Clairベースの旧基本スキャンは2025年10月にサポート終了）、Clairによるスキャンは言語パッケージの検出が限定的で、要件を満たしません。

E. Amazon ECRの基本スキャンをリポジトリに設定します。

不正解 基本スキャンはAWSネイティブのスキャン技術を使い、一般的なOSパッケージの脆弱性検出を改善していますが、検出対象はオペレーティングシステムのパッケージに限られます。npm、pip、gemなどのプログラミング言語パッケージの検出は提供されません。要件はOSと言語の両方のパッケージをスキャンすることなので、基本スキャンだけでは不十分です。

全体的な説明

問われている要件

• オペレーティングシステムとプログラミング言語の両方のパッケージに対する脆弱性スキャンを行うこと
• AWS CodePipeline、CodeBuild、CodeDeployで構成されるCI/CDワークフローへ統合すること
• コンテナイメージをAmazon ECRリポジトリへ保管していること
• CRITICALまたはHIGHの脆弱性が存在しないイメージのみをデプロイ可能にすること

前提知識

Amazon ECRのイメージスキャン

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

基本スキャン：

• 以前の基本スキャン（旧スキャン）はClairに基づいていましたが、新しいバージョンではAWSネイティブのスキャンテクノロジーを使用（Clairベースの旧基本スキャンは2025年10月にサポート終了）
• 一般的なオペレーティングシステム全体での脆弱性検出を改善
• CVEデータベースを用いて、オペレーティングシステムのパッケージの脆弱性のみをスキャン
• npm、pip、gemなどのプログラミング言語パッケージは対象外
• 追加費用なしで利用可能

拡張スキャン：

• Amazon Inspectorを使用して実行
• オペレーティングシステムパッケージだけでなく、プログラミング言語のパッケージ（Java、Python、JavaScript、Goなど）もスキャン
• AWS Security Hubと統合可能
• CVE（共通脆弱性識別子）情報と詳細な修復ガイダンスを提供
• CVSSスコアに基づいた重大度評価（CRITICAL、HIGH、MEDIUM、LOW）
• Amazon Inspector利用料金が適用

スキャンの実行タイミングは種類によって異なります。基本スキャンは手動スキャンとプッシュ時スキャンに対応し、拡張スキャンはプッシュ時スキャンと継続的スキャンに対応します（拡張スキャンでは手動スキャンは行えません）。継続的スキャンでは、新しい脆弱性が公表されるたびに結果が更新され、Amazon InspectorがEventBridgeへイベントを送信します。スキャン結果はAmazon ECRコンソールで確認でき、APIを通じて取得することも可能です。

Amazon EventBridgeとLambda

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

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

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

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

AWS CodePipelineの承認アクション

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

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

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

アーキテクチャ図の解説

アーキテクチャ図

拡張スキャンと承認ステージの自動制御を組み合わせ、脆弱なイメージをデプロイの手前で止めます。CodeBuildがビルドしたイメージをECRへPUSHすると（①②）、ECRの拡張スキャンがAmazon Inspectorを介してOSと言語の両方のパッケージを検査します（③）。スキャン完了イベントをEventBridgeが検知してLambdaを呼び出し（④⑤）、LambdaがCRITICAL/HIGHの有無を評価して承認ステージへApproved/Rejectedを送ります（⑥）。脆弱性がなければCodeDeployがデプロイし（⑦）、あればRejectedとなりパイプラインが停止します（⑧）。基本スキャンはOSパッケージのみが対象で言語パッケージを検出できないため、この要件では不十分です。

解くための考え方

OSと言語の両方をスキャンし、CRITICAL/HIGHならデプロイを止められるかを見ます。

1. **脆弱性スキャンの範囲**：

– オペレーティングシステムパッケージだけでなく、プログラミング言語のパッケージもスキャンする必要がある

– 新しい基本スキャンはオペレーティングシステムの脆弱性検出が改善されたが、対象はOSパッケージのみでプログラミング言語パッケージは検出できない

– 拡張スキャンはOSと言語の両方をカバーし、セキュリティ分析の対象を広げます

2. **自動化と統合**：

– スキャン結果を自動的に評価し、CI/CDワークフローに統合する仕組みが必要

– EventBridgeとLambdaを組み合わせることで、スキャン完了をトリガーに自動評価が可能

– CodePipelineの承認アクションと連携して、パイプラインの進行を制御できる

3. **コストと機能のバランス**：

– 基本スキャンは追加費用なしで利用可能だが、機能は限定的

– 拡張スキャンはAmazon Inspector利用料金が発生するが、OSと言語の両方を検出できる

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

1. **Amazon ECRの拡張スキャンを実装する**：

– オペレーティングシステムとプログラミング言語のパッケージ両方の脆弱性をスキャン

– CVSSスコアに基づいた重大度評価で、CRITICALやHIGHの脆弱性を特定

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

– スキャン完了を自動的に検知し、結果を評価

– 評価結果に基づいてCodePipelineの進行を制御

– CRITICALまたはHIGHの脆弱性が存在する場合、パイプラインを停止

拡張スキャンと承認ステージで、CRITICAL/HIGHのイメージはデプロイ前に止まります。

参考資料

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

正解：D

A. 成功・失敗したパイプライン実行の情報をCloudWatchカスタムメトリクスとして記録するLambda関数を用意し、5分ごとにこの関数を起動するEventBridgeルールを設定します。このメトリクスを使ってCloudWatchダッシュボードを作成します。

不正解 5分おきにLambda関数を動かすため、パイプライン実行が起きていない時間帯も関数が動き続け、無駄なリソース消費とコストが生じます。実際の実行とメトリクス記録の間に最大5分のずれが生じ、リアルタイム性も損なわれます。実行時間が5分未満のパイプラインでは、その実行を取りこぼす恐れもあります。

B. 成功・失敗した実行の詳細をAmazon DynamoDBへ記録するLambda関数を用意し、各実行の成功または失敗の直後にこの関数を起動するEventBridgeルールを設定します。DynamoDBのデータをAmazon QuickSightで読み込んでダッシュボードを作成します。

不正解 実行イベントをトリガーにする点は効率的ですが、DynamoDBへの保存とQuickSightでのダッシュボード作成には、テーブル設計や接続設定など追加の作業が生じます。QuickSightはサブスクリプション型のサービスで追加コストもかかります。デプロイサイクル時間や復旧時間という基本的な指標の可視化であればCloudWatchだけで足りるため、この構成は過剰です。

C. 成功・失敗した実行の詳細をAmazon DynamoDBへ記録するLambda関数を用意し、5分ごとにこの関数を起動するEventBridgeルールを設定します。DynamoDBに保存したデータをAmazon QuickSightで読み込んでダッシュボードを作成します。

不正解 5分おきの実行は、パイプライン実行がない時間帯にも不要な処理を生み、リアルタイム性も下がります。さらにDynamoDBとQuickSightを組み合わせる複雑な構成は「最小限の設定」に反します。定期実行のLambdaがDynamoDBからデータを取り出して分析する分、処理負荷も増えます。

D. 成功・失敗したパイプライン実行の詳細をCloudWatchカスタムメトリクスとして記録するLambda関数を用意し、各実行の成功または失敗の直後にこの関数を起動するEventBridgeルールを設定します。このメトリクスを使ってCloudWatchダッシュボードを作成します。

正解 パイプライン実行が成功または失敗した時点のイベントをトリガーにLambda関数を起動するため、実行が発生したときだけリソースを使います。Lambdaは開始と終了の差分からデプロイサイクル時間を算出し、障害からの復旧に関する指標も記録できます。CloudWatchカスタムメトリクスとダッシュボードはAWS標準サービスだけで完結し、追加サービスを要しないため「最小限の設定」を満たします。

全体的な説明

問われている要件

• 平均的なデプロイサイクル時間（コードがビルドされてからデプロイが完了するまでの時間）を可視化すること
• 障害からの復旧時間（デプロイ失敗から正常なデプロイまでの時間）を可視化すること
• リアルタイムに可視化できること
• 「最小限の設定」で実現できること（シンプルで管理オーバーヘッドが少ないこと）

前提知識

AWS DevOpsサービス

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

AWS CodePipeline：

• ソフトウェアリリースのワークフローを自動化するサービス
• 各パイプラインは、ソース、ビルド、デプロイなどの複数のステージで構成される
• パイプラインの実行状態は「成功」「失敗」などのイベントとして通知される

AWS CodeBuild：

• フルマネージドのビルドサービス
• ソースコードのコンパイル、テストの実行、パッケージの生成などを行う

AWS CodeDeploy：

• アプリケーションのデプロイを自動化するサービス
• EC2インスタンス、Lambda関数、ECSサービスなどにデプロイ可能

AWS モニタリングサービス

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

Amazon CloudWatch：

• AWSリソースとアプリケーションのモニタリングサービス
• メトリクスの収集、ログの保存、アラームの設定、ダッシュボードの作成が可能
• カスタムメトリクスの作成に対応し、独自の測定データを記録できる
• ネイティブなダッシュボード機能を持ち、グラフやウィジェットを配置可能
• なお、2025年2月のアップデートにより、CodePipelineはパイプライン実行の成功/失敗数や実行時間などのメトリクスをCloudWatchにネイティブに発行するようになった。ただし、障害からの復旧時間のような独自の指標を算出するには、本問のようにイベント駆動でカスタムメトリクスを記録する構成が引き続き有効である

Amazon EventBridge：

• サーバーレスのイベントバスサービス
• AWSサービスからのイベントを検出し、指定したターゲット（Lambda関数など）にルーティング
• スケジュールベース（時間間隔）またはイベントベース（特定のイベント発生時）のルール設定が可能

Amazon DynamoDB：

• フルマネージドのNoSQLデータベースサービス
• スケーラブルな高性能データストレージを提供
• 時系列データなど、様々な形式のデータを保存可能

Amazon QuickSight：

• ビジネスインテリジェンスとデータ可視化サービス
• 様々なデータソースからデータを取得し、インタラクティブなダッシュボードを作成可能
• 高度な分析機能を提供するが、追加のセットアップとコストが必要
• 2025年10月にAmazon Quick Suiteへ発展し、BI機能は「Quick Sight」という名称になった（既存のダッシュボード・データ接続・権限設定はそのまま引き継がれ、サブスクリプション型で追加コストが必要な点も変わらない）

アーキテクチャ図の解説

アーキテクチャ図

パイプラインの成功・失敗イベントを契機に、必要なときだけLambdaを動かしてメトリクスを積み上げます。各マイクロサービスのCodePipelineが成功または失敗すると、EventBridgeへイベントが自動送信されます（①）。EventBridgeはイベント発生時にのみLambdaを呼び出し（②）、Lambdaがデプロイサイクル時間と障害からの復旧時間を算出してCloudWatchのカスタムメトリクスへ書き込みます（③）。ダッシュボードはこのメトリクスをそのまま表示します（④）。5分おきの定期実行と異なり、実行のない時間帯に無駄な起動が起きず、リアルタイム性も保たれます。DynamoDBと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が動き、算出した値をカスタムメトリクスとして記録します。

参考資料

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