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

正解：A

A. セッションを Amazon ElastiCache for Memcached に保存します。Memcached API を使用してセッション管理を行います。

正解 ElastiCache for Memcached はインメモリデータストアとして設計されており、受講生のセッションデータの保存と共有に最適です。複数の EC2 インスタンスが同じ Memcached クラスターにアクセスできるため、Auto Scaling でインスタンスが追加・削除されてもセッション状態を維持できます。また、インメモリ型のため読み書き速度が非常に高速で、学習プラットフォームのレスポンス時間に悪影響を与えません。

B. セッションを Amazon Elastic Block Store (Amazon EBS) に保存し、Auto Scaling グループ内の各 EC2 インスタンスに EBS ボリュームをマウントします。

不正解 EBS ボリュームは単一の EC2 インスタンスにのみアタッチできる設計となっており、複数のインスタンス間での同時アクセスはできません。マルチアタッチ機能が一部の EBS タイプで提供されていますが、ファイルシステムレベルでの同期やロック機能がないため、セッションデータの整合性を保証できません。また、ブロックストレージへのファイルアクセスはネットワーク経由のキャッシュアクセスと比較して遅くなります。

C. セッションを Amazon Redshift クラスターに保存します。Amazon Redshift API を使用してセッションデータを管理します。

不正解 Redshift はデータウェアハウスサービスとして設計されており、受講履歴や成績などの大量データの分析処理に最適化されています。セッションデータのような小さなデータの高頻度な読み書きには適していません。また、Redshift はバッチ処理向けに最適化されているため、リアルタイムでのセッション管理には遅延が生じる可能性があります。コスト面でも、セッション管理のためにデータウェアハウスを運用するのは非効率的です。

D. セッションを Amazon Simple Notification Service (SNS) トピックに発行し、Auto Scaling グループ内の EC2 インスタンスを SNS トピックにサブスクライブします。

不正解 SNS はメッセージ配信サービスであり、データの永続化や状態管理を目的としていません。SNS で配信されたメッセージは一度配信されると削除されるため、受講生のセッション状態を継続的に保存する用途には使用できません。また、セッションデータの取得や更新といった操作を SNS で行うことは設計上適していません。SNS はイベント通知やメッセージ配信に特化したサービスです。

全体的な説明

問われている要件

• Amazon EC2 Auto Scaling を使用したウェブアプリケーションのスケーリング環境
• スケールイン時のセッション喪失を防ぐセッション管理の実装
• 複数の EC2 インスタンス間でのセッション状態の共有と保持
• 高速で効率的なセッションデータへのアクセス

前提知識

セッション管理の重要性

ウェブアプリケーションにおけるセッション管理は、ユーザーの状態（ログイン情報、カート内容、画面遷移状態など）を保持するために不可欠です。

• セッションデータはユーザー体験に直結する重要な情報
• Auto Scaling でインスタンスが削除されると、そのインスタンスのローカルセッションは失われる
• セッション喪失により、ユーザーは再ログインやデータ入力のやり直しが必要になる

Amazon ElastiCache for Memcached

ElastiCache for Memcached は、インメモリキャッシュサービスとして以下の特徴を持ちます：

• 高速性: メモリ上でのデータ処理により、ミリ秒レベルの高速アクセス
• 分散型アーキテクチャ: 複数のノードでデータを分散保存
• スケーラビリティ: ノードの追加・削除によるキャパシティ調整が可能
• マネージドサービス: AWS が運用・管理を行うため、運用負荷が軽減

その他の AWS サービスの特徴

• Amazon EBS: ブロックレベルストレージで単一インスタンス専用
• Amazon Redshift: 大容量データの分析処理に特化したデータウェアハウス
• Amazon SNS: プッシュメッセージ配信サービス

図による解説

解くための考え方

セッション管理の要件を満たすためには、以下の条件を満たすサービスが必要です：

複数インスタンスからの同時アクセス可能性、高速なデータ読み書き性能、データの永続性と可用性の確保。

ElastiCache for Memcached は、これらすべての要件を満たします。インメモリ型により高速アクセスが可能で、分散アーキテクチャにより複数インスタンスでの共有ができます。

他の選択肢は、EBS は単一インスタンス専用、Redshift は分析用途、SNS はメッセージ配信用途と、それぞれセッション管理には適していません。

参考資料

• Amazon ElastiCache とは
• Amazon EC2 Auto Scaling とは
• ElastiCache for Memcached の使用

正解：D

A. 別の Lambda 関数のトリガーに切り替えます。

不正解 別の関数にトリガーを切り替える方法は技術的には可能ですが、効率的ではありません。S3イベント通知の設定変更、新しい関数の作成、古い関数の削除など、多くの手動作業が必要になります。また、複数のバージョンをテストする際に毎回新しい関数を作成する必要があり、管理が煩雑になります。さらに、S3バケットのイベント通知設定を頻繁に変更することで、設定ミスのリスクも高まります。

B. Lambda 関数のタグを使用します。

不正解 タグはAWSリソースの分類、識別、課金管理などの目的で使用される機能です。タグを変更してもLambda関数の実行バージョンが変わることはありません。S3イベント通知は特定の関数またはエイリアスに対して設定されるため、タグの値によって呼び出されるバージョンを制御することはできません。タグは管理上の情報であり、実行時の動作には影響しません。

C. Lambda 関数の環境変数を使用します。

不正解 環境変数は関数内部で参照される設定値を管理するために使用されます。環境変数を変更しても、S3イベント通知が呼び出すLambda関数のバージョン自体は変更されません。環境変数は関数の動作をカスタマイズするために使用されるものであり、どのバージョンの関数が実行されるかを制御する仕組みではありません。また、環境変数の変更には関数の更新が必要な場合があります。

D. Lambda 関数のエイリアスを使用します。

正解 エイリアスはLambda関数の特定のバージョンに対して人間が理解しやすい名前を付ける機能です。S3イベント通知をエイリアスに対して設定することで、エイリアスが指すバージョンを変更するだけで、簡単に異なるバージョンの関数を呼び出すことができます。例えば、「prod」エイリアスを本番用バージョンに、「test」エイリアスをテスト用バージョンに設定し、S3イベント通知は「test」エイリアスに向けておけば、テストが完了した際にエイリアスの指す先を変更するだけで本番環境に切り替えられます。

全体的な説明

問われている要件

• Amazon S3をイベントソースとして使用したLambda関数の自動実行
• 複数のLambda関数バージョンの効率的な管理と切り替え
• S3イベント通知設定を変更せずにバージョンを切り替える仕組み
• 開発・テスト・本番環境での関数バージョン管理の簡素化

前提知識

Amazon S3イベント通知

S3イベント通知は、S3バケット内で特定の操作（オブジェクトの作成、削除、復元など）が発生した際に、自動的に他のAWSサービスに通知を送る機能です。

• 対象となる操作タイプを指定可能（PUT、POST、COPY、DELETE など）
• 特定のプレフィックスやサフィックスを持つオブジェクトのみを対象にできる
• Lambda関数、SQS、SNSなどを通知先として設定可能
• イベント通知は設定後、リアルタイムで動作

Lambda関数のバージョニング

Lambda関数では、コードの変更履歴を管理するためのバージョニング機能があります。

• $LATEST: 常に最新の編集可能なバージョンを指す
• 番号付きバージョン: 公開時に作成される不変のバージョン（例：1、2、3…）
• 各バージョンは独立したARNを持つ
• 一度公開されたバージョンは変更不可

Lambda エイリアス

エイリアスは特定のLambda関数バージョンに対して付けるラベル機能です。

• 人間が理解しやすい名前を使用（例：prod、staging、dev）
• エイリアス自体も独自のARNを持つ
• エイリアスが指すバージョンは変更可能
• 重み付きエイリアス機能により、複数バージョン間でトラフィック分散も可能
• S3イベント通知やAPI Gatewayなど、外部サービスからの呼び出し先として使用可能

図による解説

解くための考え方

Lambda関数の複数バージョンを効率的に管理し切り替えるためには、エイリアス機能の活用が最適です。

S3イベント通知をエイリアスに対して設定することで、エイリアスが指すバージョンを変更するだけで呼び出される関数を切り替えられます。

この方法により、S3バケットのイベント通知設定を変更することなく、Lambda関数のバージョン切り替えが可能になります。開発フローでは「dev」→「staging」→「prod」といったエイリアスを使い分けることで、段階的なデプロイメントも実現できます。

参考資料

• AWS Lambda エイリアス
• Amazon S3 Event Notifications
• AWS Lambda バージョニング

正解：D

A. Amazon S3、AWS CodeBuild、GitHub

不正解 この組み合わせにはデプロイメント自動化に必要なサービスが不足しています。GitHubでソースコード管理、CodeBuildでアプリケーションのビルドは可能ですが、S3は単なるストレージサービスであり、実際のアプリケーションデプロイメントを実行する機能はありません。ビルドされたアーティファクトをS3に保存することはできますが、そこからターゲット環境への自動デプロイには別のサービス（CodeDeployなど）が必要です。

B. Amazon S3、AWS CodeBuild、Amazon Elastic Container Service (Amazon ECS)

不正解 この組み合わせではソースコード管理の仕組みが含まれていません。ECSはコンテナベースのアプリケーション実行環境として優れていますが、ソースコードの変更を検知してパイプラインをトリガーする機能はありません。また、GitHubやBitbucketなどのソースリポジトリがなければ、チームメンバーのコード変更をトリガーとした自動化プロセスを開始できません。さらに、この問題はJavaアプリケーションについて言及しており、必ずしもコンテナ化が要件ではありません。

C. Amazon CodeGuru、GitHub、AWS CodeBuild

不正解 CodeGuruはコード品質の分析やパフォーマンスの最適化を行うサービスであり、CI/CDパイプラインの必須コンポーネントではありません。この組み合わせではソースコード管理（GitHub）とビルド（CodeBuild）は含まれていますが、デプロイメント自動化に必要なCodeDeployが欠けています。ビルドが完了した後、アプリケーションを実際の環境にデプロイする仕組みがないため、完全な自動化は実現できません。

D. GitHub、AWS CodeBuild、AWS CodeDeploy

正解 この組み合わせがCI/CDパイプラインの構築に最適です。GitHubがGitベースのソースコード管理を提供し、開発チームのコード変更を管理します。CodeBuildがJavaアプリケーションのコンパイル、テスト実行、アーティファクト生成を自動化します。CodeDeployが構築されたアプリケーションをEC2インスタンス、オンプレミスサーバー、Lambda関数などの様々なターゲット環境に自動デプロイします。これらのサービスはCodePipelineと統合され、完全な自動化されたCI/CDプロセスを実現します。

全体的な説明

問われている要件

• AWS CodePipelineを使用したJavaアプリケーションのCI/CD自動化
• ソースコードの変更をトリガーとした自動的なビルドとデプロイ
• チームメンバーが協力して開発できるソースコード管理システム
• アプリケーションの構築から本番環境への配布まで全工程の自動化

前提知識 CI/CD（継続的インテグレーション/継続的デプロイメント） CI/CDは現代のソフトウェア開発において標準的な手法で、以下の段階から構成されます：

• 継続的インテグレーション（CI）: 開発者が頻繁にコードをメインブランチにマージし、自動的にビルドとテストを実行
• 継続的デプロイメント（CD）: ビルドとテストに成功したコードを自動的に本番環境にデプロイ
• 品質向上、バグの早期発見、リリース頻度の向上などの利点

GitHub（Gitベースのリポジトリ） 代表的なGitベースのソースコード管理プラットフォームです：

• プライベート／パブリックなGitリポジトリをクラウド上で管理
• 組織・チーム単位のアクセス制御とレビュー機能を提供
• Gitベースの標準的な操作（コミット、プッシュ、マージ）に対応
• GitHub App や GitHub Actions など拡張機能が豊富
• CodePipelineとのネイティブ統合（CodeStar Connections経由）に対応

AWS CodeBuild フルマネージドなビルドサービスで、以下の機能を提供します：

• ソースコードのコンパイル、テスト実行、デプロイ用アーティファクトの作成
• Java、Python、Node.js、.NETなど多様なプログラミング言語をサポート
• カスタムビルド環境やDockerコンテナの使用が可能
• buildspec.ymlファイルによるビルドプロセスの定義
• 使用した分だけの課金体系

AWS CodeDeploy アプリケーションデプロイメントを自動化するサービス：

• EC2インスタンス、オンプレミスサーバー、Lambda関数、ECSサービスへのデプロイをサポート
• Blue/Green デプロイメント、ローリングデプロイメントなど複数のデプロイ戦略
• デプロイ中の自動ロールバック機能
• アプリケーション仕様ファイル（appspec.yml）によるデプロイプロセスの定義

図での解説

解くための考え方 完全なCI/CDパイプラインを構築するには、三つの主要コンポーネントが必要です。 まず、ソースコード管理システムとしてGitHubが、チームでの協業とバージョン管理を可能にします。次に、ビルドシステムとしてCodeBuildが、Javaアプリケーションのコンパイルとテストを自動実行します。 最後に、デプロイメントシステムとしてCodeDeployが、ビルドされたアプリケーションを本番環境に自動配布します。これらのサービスをCodePipelineで統合することで、コード変更から本番リリースまでの全プロセスが自動化されます。

参考資料

• AWS CodePipeline とは
• GitHub Docs
• AWS CodeBuild とは
• AWS CodeDeploy とは

正解：D

A. Amazon EC2

不正解 EC2は仮想サーバーインスタンスを提供するコンピューティングサービスであり、認証やユーザー管理機能は含まれていません。EC2上にカスタム認証システムを構築することは技術的には可能ですが、開発コスト、運用コスト、セキュリティ対策、スケーラビリティ確保などの観点で非効率的です。限られた予算での開発という要件を考慮すると、専用のマネージドサービスを利用する方が適切です。また、SAML 2.0統合やモバイルアプリケーション向けの最適化も独自に実装する必要があります。

B. AWS IAM

不正解 IAMはAWSリソースへのアクセス制御を管理するサービスであり、主にAWSサービス間の権限管理に使用されます。eラーニングプラットフォームの学生ユーザーに対する認証や一般的なユーザー登録機能は提供していません。IAMは組織内のAWS利用者やシステム間の認証には適していますが、不特定多数の外部ユーザーが利用するプラットフォームのユーザー管理には設計されていません。また、SAML 2.0プロバイダーとの統合機能もエンドユーザー向けには限定的です。

C. AWS Lambda

不正解 Lambdaはサーバーレスでコードを実行するコンピューティングサービスです。Lambda関数を使用してカスタム認証システムを構築することは可能ですが、ユーザー管理、セッション管理、SAML統合、セキュリティ対策などを全て独自に実装する必要があります。これは開発工数とコストの増大を招き、限られた予算という制約に適していません。また、拡張性のある学生データベースの管理や、モバイル・ウェブアプリケーション向けのSDK提供なども別途考慮する必要があります。

D. Amazon Cognito

正解 Amazon Cognitoはモバイルアプリケーションやウェブアプリケーション向けのユーザー認証・管理に特化したマネージドサービスです。ユーザープール機能により、ユーザー登録、ログイン、パスワード管理などの基本的な認証機能を提供します。SAML 2.0アイデンティティプロバイダーとのフェデレーション連携にも対応しており、各大学の既存のSAML 2.0システムと簡単に統合できます。コスト面では使用量に応じた課金で、小規模から大規模まで効率的にスケールします。また、iOS、Android、JavaScript向けのSDKが提供され、開発工数を大幅に削減できます。

全体的な説明

問われている要件

• 限られた予算でのeラーニングプラットフォーム開発
• 大学が保有する既存のSAML 2.0アイデンティティプロバイダーとの統合
• 学生ユーザーの登録と認証機能の実装
• 拡張性のあるサービスアーキテクチャの構築

前提知識

Amazon Cognito の概要

Amazon Cognitoは、モバイルアプリケーションやウェブアプリケーション向けのユーザー認証・認可・管理を行うフルマネージドサービスです。以下の主要機能を提供します：

• ユーザープール: ユーザーの登録、認証、プロフィール管理
• アイデンティティプール: AWSリソースへの一時的なアクセス権限付与
• フェデレーション: 外部アイデンティティプロバイダーとの連携
• マルチファクタ認証（MFA）: セキュリティ強化のための二要素認証

SAML 2.0 統合機能

CognitoはSAML 2.0標準をサポートし、既存のエンタープライズアイデンティティシステムと統合できます：

• Active Directory Federation Services (AD FS)
• Shibboleth
• Okta、Ping Identity などのクラウドアイデンティティプロバイダー
• カスタムSAML 2.0実装

統合により、組織の既存ユーザーディレクトリを活用しながら、新しいモバイルアプリケーションでのシングルサインオン（SSO）を実現できます。

コスト効率性

Cognitoは従量課金制を採用しており、以下の特徴があります：

• 月間アクティブユーザー（MAU）ベースの課金
• 小規模利用時の無料利用枠
• サーバー運用コストやインフラ管理コストが不要
• 開発・運用工数の大幅削減

拡張性とパフォーマンス

• 数百万ユーザーまでの自動スケーリング
• グローバルに分散されたインフラストラクチャ
• 高可用性とディザスタリカバリ機能
• AWSの他のサービスとのネイティブ統合

図による解説

解くための考え方

モバイルアプリケーションの認証システム構築において、Amazon Cognitoが最適な理由は以下の通りです。

既存のSAML 2.0プロバイダーとの統合が標準機能として提供されており、複雑な実装が不要です。ユーザー登録、認証、パスワード管理などの基本機能が即座に利用可能で、開発工数を大幅に削減できます。

マネージドサービスとして提供されるため、サーバー管理、セキュリティパッチ適用、スケーリング対応などの運用負荷がありません。限られた予算内で拡張性のあるシステムを構築するには、このような専用サービスの活用が最も効率的です。

参考資料

• Amazon Cognito とは
• Amazon Cognito ユーザープール
• Amazon Cognito での SAML アイデンティティプロバイダーの追加

正解：A、E

A. 各 IAM ユーザーのみにアクセスを許可するための API のリソースポリシーを作成します。

正解 API Gatewayのリソースポリシーは、どのAWSアカウントのIAMユーザーやロールがAPIにアクセスできるかを制御する重要な仕組みです。リソースポリシーでは、特定のAWSアカウントからのアクセスを許可し、さらに特定のIAMユーザーに限定することができます。JSON形式でCondition要素を使用して、aws:userid条件キーで個別のIAMユーザーを指定したり、aws:PrincipalArn条件キーでユーザーのARNを指定することで、きめ細かいアクセス制御が実現できます。

B. 提携先企業の各 IAM ユーザーのみにアクセスを許可するために、API 用の Amazon Cognito オーソライザーを作成します。API のメソッド認証タイプを COGNITO_USER_POOLS に設定します。

不正解 Cognitoオーソライザーは、Cognitoユーザープールで管理されるユーザーの認証に使用される仕組みです。IAMユーザーは組織内のAWSリソースアクセス管理に使用されるものであり、Cognitoユーザープールとは全く異なる認証システムです。IAMユーザーの認証情報（アクセスキーとシークレットキー）を使用してCognitoユーザープールで認証することはできません。また、COGNITO_USER_POOLS認証タイプはJWTトークンベースの認証であり、IAM認証とは仕組みが異なります。

C. Amazon Cognito ユーザープールを作成し、提携先企業の各 IAM ユーザーをユーザープールに追加します。API のメソッド認証タイプを COGNITO_USER_POOLS に設定します。Amazon Cognito で IAM 認証情報を使用して認証します。

不正解 IAMユーザーをCognitoユーザープールに直接追加することはできません。これらは全く異なる認証システムです。IAMユーザーはAWSアカウント内のエンティティであり、プログラマティックアクセス（APIアクセス）やAWSマネジメントコンソールアクセス用の認証情報を持ちます。一方、Cognitoユーザープールはアプリケーション固有のユーザーを管理するサービスで、ユーザー名/パスワード、ソーシャルログイン、SAMLなどの認証方式を使用します。

D. Amazon Cognito ID プールを作成し、提携先企業の各 IAM ユーザーを ID プールに追加します。API のメソッド認証タイプを COGNITO_USER_POOLS に設定します。リクエストヘッダーにアクセストークンを追加します。

不正解 Cognito IDプール（フェデレーテッドアイデンティティ）は、外部のアイデンティティプロバイダー（Cognitoユーザープール、Facebook、Google、SAMLプロバイダーなど）で認証されたユーザーに、一時的なAWSクレデンシャルを提供する仕組みです。IAMユーザーをIDプールに直接追加するという概念は存在しません。また、認証タイプがCOGNITO_USER_POOLSとなっていますが、これはIDプールではなくユーザープールの認証タイプです。

E. IAM アクセス許可ポリシーを作成し、提携先企業の各 IAM ユーザーにポリシーをアタッチします。API のメソッド承認タイプを AWS_IAM に設定します。署名バージョン 4 を使用して API リクエストに署名します。

正解 IAMアクセス許可ポリシーにより、IAMユーザーが特定のAPI Gatewayリソースに対してexecute-api:Invokeアクションを実行する権限を付与できます。メソッドの認証タイプをAWS_IAMに設定することで、API GatewayがIAMベースの認証を要求するようになります。AWS Signature Version 4は、AWSサービスへのHTTPリクエストに署名するための標準的な仕組みで、IAMユーザーのアクセスキーとシークレットキーを使用してリクエストの真正性を証明します。これにより、認証されたIAMユーザーのみがAPIにアクセスできます。

全体的な説明

問われている要件

• Amazon API GatewayのREST APIへのアクセス制御
• 別のAWSアカウントのIAMユーザーのみにアクセスを限定
• 最適な手順を2つ選択する必要がある
• クロスアカウントでのIAMベース認証の実装

前提知識

Amazon API Gatewayのアクセス制御

API Gatewayでは複数の認証・認可方式を提供しており、用途に応じて選択できます：

• AWS_IAM認証: IAMユーザー、ロール、ポリシーを使用した認証
• Cognitoユーザープール: アプリケーションユーザーの認証
• Lambda オーソライザー: カスタム認証ロジック
• APIキー: シンプルなキーベース認証

IAMベース認証の仕組み

IAMベース認証では以下の要素が連携します：

• IAMユーザー/ロール: 認証の主体となるエンティティ
• アクセス許可ポリシー: IAMユーザーに付与される権限
• リソースポリシー: API Gateway側でのアクセス制御ルール
• AWS Signature Version 4: リクエスト署名による認証

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

異なるAWSアカウント間でのアクセス制御には、以下の設定が必要です：

• API Gateway側のリソースポリシーで外部アカウントのプリンシパルを許可
• 呼び出し元アカウントのIAMユーザーに適切な権限ポリシーを付与
• 両方のアカウントでの設定が一致していることが重要

AWS Signature Version 4

AWS Signature Version 4は、AWSサービスへのHTTPリクエストに署名するための標準プロトコルです：

• リクエストヘッダー、ペイロード、クエリパラメータなどを含む署名を生成
• タイムスタンプベースの署名により、リプレイ攻撃を防止
• IAMアクセスキーとシークレットキーを使用した署名生成

解くための考え方

別のAWSアカウントのIAMユーザーにのみAPI Gatewayへのアクセスを許可するには、二重のアクセス制御が必要です。

まず、API Gateway側でリソースポリシーを設定し、特定のAWSアカウントからの特定のIAMユーザーのみアクセスを許可します。リソースポリシーではCondition要素を使用して、aws:useridやaws:PrincipalArnなどの条件キーで詳細な制御が可能です。

次に、呼び出し元アカウントで、各IAMユーザーにAPI Gatewayリソースへのexecute-api:Invoke権限を付与するアクセス許可ポリシーをアタッチします。同時に、APIのメソッド認証タイプをAWS_IAMに設定し、AWS Signature Version 4を使用してリクエストに署名することで、セキュアな認証を実現します。

参考資料

• API Gateway リソースポリシーの例
• API Gateway での AWS IAM による認証とアクセス許可
• AWS Signature Version 4 署名プロセス

正解：B、D

A. DynamoDB テーブルにトリガーを作成して、変更を Amazon Kinesis Data Streams に発行します。

不正解 DynamoDB自体には、変更を直接Kinesis Data Streamsに発行するネイティブなトリガー機能はありません。DynamoDBでデータ変更をキャプチャするためには、DynamoDB Streamsという専用の機能を使用する必要があります。Kinesis Data Streamsは大量のリアルタイムデータストリーミングに適していますが、DynamoDBの変更追跡には、まずDynamoDB Streamsを有効化し、その後でLambda関数などを経由してKinesisに送信する必要があります。この選択肢は技術的に不正確な実装方法を示しています。

B. DynamoDB Streams を診療記録テーブルで有効にします。

正解 DynamoDB Streamsは、DynamoDBテーブルでのデータ変更（項目の作成、更新、削除）をキャプチャするためのマネージドサービスです。Streamsを有効にすることで、変更されたデータ項目の詳細情報（変更前後の値、変更タイプなど）が時系列順にストリームレコードとして保存されます。ストリームレコードは最大24時間保持され、複数のコンシューマーが並行してデータを読み取ることができます。これは外部APIへの変更通知を実現するための基盤となる重要な設定です。

C. Amazon Simple Notification Service (Amazon SNS) のトピックにストリームを配信し、トピックにコンプライアンス監査 API をサブスクライブします。

不正解 DynamoDB Streamsから直接SNSトピックに配信する機能は存在しません。DynamoDB Streamsは、Lambda関数、Kinesis Client Library、またはKinesis Data Analytics等によって処理される必要があります。SNSを使用する場合は、Lambda関数がDynamoDB Streamsのレコードを受信し、その後でSNSにメッセージを発行するという間接的なアーキテクチャが必要です。また、外部APIを直接SNSトピックにサブスクライブすることも一般的ではなく、通常はHTTPSエンドポイントやLambda関数を介して外部APIを呼び出します。

D. ストリームをポーリングし、コンプライアンス監査用の外部 API を呼び出すように AWS Lambda 関数を設定します。

正解 Lambda関数をDynamoDB Streamsのトリガーとして設定することで、テーブルに変更が発生するたびに自動的にLambda関数が実行されます。Lambda関数は、DynamoDB Streamsのイベントレコードを受信し、変更された項目の詳細情報を解析して、適切な形式で外部APIに送信できます。Lambdaはサーバーレスなので、インフラ管理が不要で、変更の頻度に応じて自動的にスケールします。また、エラーハンドリング、リトライ機能、デッドレターキューなどの信頼性機能も利用できます。

E. Amazon Managed Streaming for Apache Kafka (Amazon MSK) データストリームに変更を発行する Amazon EventBridge (Amazon CloudWatch Events) のイベントを構成します。

不正解 この選択肢は複雑すぎる上に、技術的に正確ではありません。Amazon MSKは大規模なリアルタイムストリーミングアプリケーション用のApache Kafkaサービスですが、DynamoDBの変更追跡という要件に対しては過剰な仕組みです。また、DynamoDB自体がEventBridge（旧CloudWatch Events）に直接変更イベントを送信する機能はありません。シンプルな外部API呼び出しという要件に対して、複雑で不必要なアーキテクチャを提案しています。

全体的な説明

問われている要件

• 複数の業務アプリケーションが読み書きするDynamoDBテーブルの変更監視
• データ変更時の外部APIへの自動通知機能
• 効率的で信頼性の高い変更検知とAPI連携の実装
• リアルタイムでの変更追跡システムの構築

前提知識

DynamoDB Streamsの概要

DynamoDB Streamsは、DynamoDBテーブルのデータ変更をキャプチャするマネージドサービスです：

• 変更キャプチャ: INSERT、UPDATE、DELETE操作を自動検知
• ストリームレコード: 変更されたアイテムの情報を時系列で保存
• ビューオプション: KEYS_ONLY、NEW_IMAGE、OLD_IMAGE、NEW_AND_OLD_IMAGESから選択可能
• 保持期間: ストリームレコードは最大24時間保持
• 順序保証: パーティションキー単位での順序保証

ストリームレコードの内容

各ストリームレコードには以下の情報が含まれます：

• イベントタイプ（INSERT、MODIFY、REMOVE）
• 変更されたアイテムのプライマリキー
• 変更前後のアイテム値（ビューオプションによる）
• タイムスタンプ
• その他のメタデータ

AWS Lambda統合

LambdaはDynamoDB Streamsのネイティブトリガーとして機能します：

• 自動ポーリング: Lambdaサービスが自動的にストリームをポーリング
• 並列処理: 複数のシャードから並行してレコードを処理
• エラーハンドリング: 自動リトライとデッドレターキュー機能
• スケーラビリティ: 変更頻度に応じた自動スケーリング

外部API統合のベストプラクティス

Lambda関数での外部API呼び出しでは以下を考慮します：

• HTTPクライアントライブラリの使用（requests、boto3等）
• 適切なタイムアウト設定
• エラーハンドリングとリトライロジック
• 認証方式の実装（API Key、OAuth等）
• レート制限への対応

図による解説

解くための考え方

DynamoDBテーブルの変更を外部APIに通知するには、変更検知と通知処理の二段階アプローチが最適です。

まず、DynamoDB Streamsを有効化することで、テーブルの全ての変更がリアルタイムでキャプチャされます。Streamsは変更の詳細情報を提供し、複数のコンシューマーでの処理が可能です。

次に、Lambda関数をStreamsのトリガーとして設定することで、変更発生時に自動的に外部API呼び出しが実行されます。Lambdaはサーバーレスで管理が簡単で、変更頻度に関係なく効率的にスケールします。この組み合わせにより、シンプルで信頼性の高いリアルタイム通知システムが構築できます。

参考資料

• DynamoDB Streams を使用した変更データのキャプチャ
• DynamoDB ストリームでの Lambda の使用
• DynamoDB Streams レコード処理

正解：C

A. PutMetricData 権限を持つ IAM ユーザーを作成し、Auto Scaling 起動テンプレートを修正して、そのユーザー認証情報をインスタンスのユーザーデータに埋め込みます。

不正解 この方法は重大なセキュリティリスクを伴います。IAMユーザーの認証情報（アクセスキーとシークレットキー）をユーザーデータに含めることは、認証情報の漏洩につながる可能性が高いです。ユーザーデータはプレーンテキストで保存され、EC2インスタンスのメタデータサービス経由でアクセス可能なため、インスタンスにアクセスできる任意のユーザーや悪意のあるプロセスが認証情報を取得できてしまいます。また、起動テンプレートやスナップショット、ログにも認証情報が残る可能性があります。

B. CloudWatch メトリクスポリシーを変更して、Auto Scaling グループ内のゲームサーバーインスタンスに PutMetricData 権限を許可します。

不正解 「CloudWatch メトリクスポリシー」という概念はAWSには存在しません。CloudWatchはメトリクスの収集と監視を行うサービスですが、IAMのようなアクセス制御機能は持っていません。EC2インスタンスにAWSサービスへのアクセス権限を付与するには、IAMロールまたはIAMユーザーの認証情報を使用する必要があります。

C. PutMetricData 権限を持つ IAM ロールを作成し、そのロールをゲームサーバーインスタンスに割り当てるよう Auto Scaling 起動テンプレートを変更します。

正解 この方法はAWSのセキュリティベストプラクティスに完全に準拠した最も安全なアプローチです。IAMロールをEC2インスタンスに関連付けることで、インスタンス上のアプリケーションがAWS STSを通じて一時的な認証情報を自動取得できます。これらの認証情報は定期的に自動更新され、手動管理が不要です。認証情報がコードやファイルに埋め込まれることがないため、漏洩リスクが最小化されます。また、IAMロールの権限は最小権限の原則に従って細かく制御できます。

D. PutMetricData 権限を持つ IAM ユーザーを作成し、そのユーザー認証情報をプライベートコードリポジトリに格納します。ゲームサーバーアプリケーションが起動時に認証情報をリポジトリから取得するよう実装します。

不正解 認証情報をプライベートリポジトリに保存することは、非常に深刻なセキュリティリスクです。リポジトリへのアクセス権を持つ開発者や、リポジトリが侵害された場合に、認証情報が露出する可能性があります。また、バージョン管理システムの履歴に認証情報が残り続けるため、削除が困難になります。さらに、認証情報の定期的なローテーション、配布、更新などの管理負荷も発生します。この方法はAWSセキュリティベストプラクティスに反しています。

全体的な説明

問われている要件

• EC2インスタンスからCloudWatchへのカスタムメトリクス送信
• Auto Scalingグループでのセキュアな認証方法の実装
• CloudWatch PutMetricData APIの安全な利用
• 最小権限の原則に基づくアクセス制御の確立

前提知識

IAMロールとEC2インスタンスプロファイル

IAMロールは、AWSリソースに一時的な権限を付与するためのAWSのアイデンティティです：

• 一時的認証情報: STSによって発行される時限付きのアクセスキー
• 自動ローテーション: 認証情報が定期的に自動更新される
• インスタンスプロファイル: EC2インスタンスにIAMロールを関連付けるためのコンテナ
• メタデータサービス: EC2インスタンス内から認証情報を安全に取得

AWS Security Token Service (STS)

STSは一時的なセキュリティ認証情報を提供するサービスです：

• AssumeRole: IAMロールを引き受けて一時認証情報を取得
• 認証情報の有効期限: 通常15分から12時間の範囲で設定可能
• 最小権限: 必要最小限の権限のみを付与
• 監査: CloudTrailによるAPI呼び出しの完全な監査証跡

CloudWatchカスタムメトリクス

CloudWatchカスタムメトリクスは、アプリケーション固有の監視データを送信する機能です：

• PutMetricData API: カスタムメトリクスをCloudWatchに送信
• メトリクス名前空間: カスタムメトリクスを整理するための論理的グループ
• ディメンション: メトリクスをフィルタリングするためのキー値ペア
• 集計: 時間ベースでのメトリクス値の集計

Auto Scaling起動テンプレート

起動テンプレートは、EC2インスタンスの起動設定を定義するリソースです：

• IAMインスタンスプロファイル: インスタンスに関連付けるIAMロールを指定
• セキュリティグループ: ネットワークアクセス制御
• ユーザーデータ: インスタンス起動時に実行されるスクリプト
• タグ: リソース管理のためのメタデータ

図による解説

解くための考え方

EC2インスタンスが安全にAWSサービスにアクセスするためには、IAMロールの使用が絶対的なベストプラクティスです。

IAMロールを使用することで、認証情報のハードコーディング、手動管理、漏洩リスクを完全に排除できます。EC2インスタンスはメタデータサービスを通じて自動的に一時認証情報を取得し、AWS STSによって定期的に更新されます。

Auto Scaling環境では、新しく作成されるインスタンスも自動的に同じロールを継承するため、スケーラビリティとセキュリティの両方が確保されます。起動テンプレートでIAMインスタンスプロファイルを指定することで、すべてのインスタンスが一貫したセキュリティ設定で起動されます。

最小権限の原則に従い、CloudWatch PutMetricData権限のみを持つ専用のIAMロールを作成することで、セキュリティリスクを最小化できます。

参考資料

• IAM ロールを使用した Amazon EC2 インスタンスで実行されるアプリケーションへのアクセス権限の付与
• カスタムメトリクスの発行
• 起動テンプレートを使用したインスタンスの起動

正解：A

A. S3 署名付き URL を使用して、技術仕様書を協力会社と共有します。有効期限を 7 日間に設定します。

正解 S3署名付きURLは、協力会社などの外部ユーザーとファイルを安全に共有するための最適な方法です。署名付きURLは、指定した有効期限内でのみ特定のS3オブジェクトへのアクセスを許可する一時的なURLです。7日間の有効期限を設定することで、期限後は自動的にアクセスが無効になります。協力会社の担当者はAWSアカウントやIAM認証情報を必要とせず、通常のWebブラウザでファイルにアクセスできます。また、最小権限の原則に従い、特定のファイルのみへのアクセスに限定できるため、セキュリティリスクを最小化できます。

B. S3 バケットへの読み取り専用アクセス権を持つ一時的な IAM ユーザーを作成し、アクセスキーを協力会社と共有します。7 日後に認証情報を失効させます。

不正解 IAMユーザーのアクセスキーを協力会社と共有することは、重大なセキュリティリスクを伴います。アクセスキーが漏洩や悪用された場合、製造会社のAWSリソースに不正アクセスされる可能性があります。また、協力会社がアクセスキーを適切に管理する保証がなく、メール、チャット、その他の通信手段で認証情報が露出するリスクがあります。さらに、IAMユーザーの管理、認証情報の配布、削除などの運用負荷も発生し、AWSセキュリティベストプラクティスにも反しています。

C. 技術仕様書を Amazon WorkDocs フォルダに移動します。WorkDocs フォルダのリンクを協力会社と共有します。

不正解 Amazon WorkDocsはファイル共有とコラボレーション機能を提供するサービスですが、この選択肢には複数の問題があります。まず、既存のS3バケットからWorkDocsへのファイル移動という余分な作業が必要です。また、WorkDocsは通常、組織内でのファイル共有に使用されるサービスであり、短期間の外部向け共有には適していません。WorkDocsのセットアップ、ユーザー管理、ライセンス費用なども考慮する必要があり、シンプルな7日間のファイル共有という要件に対して過剰なソリューションです。

D. S3 バケットへの読み取り専用アクセス権を持つロールを作成し、このロールの Amazon リソースネーム (ARN) を協力会社と共有します。

不正解 IAMロールのARNを協力会社と共有しても、協力会社の担当者がそのロールを直接使用することはできません。IAMロールは、AWSサービス間や信頼されたエンティティ間でのアクセス権限委譲に使用される仕組みです。協力会社がロールを引き受けるためには、適切な信頼関係の設定、STSトークンの取得、AWS CLIやSDKの使用などの複雑な手順が必要になります。また、このような設定は協力会社に過度な技術的知識を要求し、一般的なファイル共有の用途には適していません。

全体的な説明

問われている要件

• 外部の協力会社を対象とした7日間限定のファイル共有
• 製造会社が管理するAmazon S3バケットに保存された技術仕様書の共有
• セキュリティを確保した安全な共有方法の選択
• 期限付きアクセス制御の実装

前提知識

S3署名付きURL（Pre-signed URL）

S3署名付きURLは、S3オブジェクトへの一時的なアクセスを提供する仕組みです：

• 時限付きアクセス: 指定した有効期限後に自動的にアクセス無効化
• 署名による認証: AWS認証情報を使用してURLに署名を付与
• 特定オブジェクト限定: 個別のファイルのみへのアクセス許可
• HTTPメソッド制限: GET、PUT、DELETEなど特定の操作のみ許可可能
• IPアドレス制限: 特定のIPアドレスからのアクセスのみ許可可能

署名付きURLの生成方法

署名付きURLは以下の要素で構成されます：

• バケット名とオブジェクトキー: アクセス対象の特定
• AWS認証情報: URL署名のためのアクセスキーとシークレットキー
• 有効期限: URLの有効期限（最大7日間）
• 署名: リクエストの真正性を証明するハッシュ値
• 追加パラメータ: Content-Type、Content-Dispositionなどの制御

セキュリティ上の利点

署名付きURLの使用により以下のセキュリティメリットが得られます：

• 認証情報の非共有: IAMユーザーやアクセスキーの共有が不要
• 最小権限: 特定のファイルのみへのアクセス制限
• 時間制限: 自動的な期限切れによるアクセス無効化
• 監査証跡: CloudTrailでのアクセスログ記録
• 取り消し不可: 一度生成したURLは変更不可（セキュリティ特性）

外部ユーザー共有のベストプラクティス

外部ユーザーとのファイル共有では以下を考慮します：

• 必要最小限のアクセス: 特定ファイルのみへの読み取り専用アクセス
• 適切な有効期限: 業務要件に応じた期間設定
• HTTPSの使用: データ転送時の暗号化
• アクセス監視: CloudWatchやCloudTrailでのアクセス監視
• ファイル暗号化: S3での保存時暗号化の有効化

図による解説

解くための考え方

外部ユーザーへの安全なファイル共有には、署名付きURLが最適な選択です。

この方法により、外部ユーザーはAWSアカウントや複雑な認証情報を必要とせず、通常のWebブラウザで簡単にファイルにアクセスできます。7日間の有効期限設定により、期限後の自動アクセス無効化が保証されます。

署名付きURLは、企業のセキュリティを維持しながら、外部ユーザーに必要最小限のアクセス権限を提供する理想的なソリューションです。設定も簡単で、運用負荷が少なく、AWSセキュリティベストプラクティスに完全に準拠しています。

他の選択肢は、セキュリティリスク、運用負荷、または過度な複雑性といった問題を抱えており、シンプルな外部ファイル共有という要件には適していません。

参考資料

• 署名付き URL を使用したオブジェクトのアップロード
• 署名付き URL と署名付きクッキーによるプライベートコンテンツの配信
• Amazon S3 セキュリティのベストプラクティス

正解：C

A. Amazon CodeGuru

不正解 Amazon CodeGuruは機械学習を活用したコード品質とアプリケーションパフォーマンスの改善サービスです。CodeGuru ReviewerはコードレビューとJavaアプリケーションのセキュリティ分析を行い、CodeGuru Profilerはランタイムパフォーマンスの分析と最適化を支援します。これらの機能はコード品質向上には有効ですが、アプリケーションアーティファクトをEC2インスタンスや工場内オンプレミスサーバーにデプロイする機能は提供していません。CI/CDパイプラインでのデプロイステージには適用できません。

B. Amazon S3

不正解 Amazon S3は高耐久なオブジェクトストレージサービスであり、アーティファクトの保存には利用できますが、EC2インスタンスやオンプレミスサーバーへのデプロイを自動化する機能は提供していません。S3イベントで通知を行うことは可能ですが、デプロイメント手順の実行やロールバック制御などは担えないため、CI/CDパイプラインのデプロイステージには適していません。

C. AWS CodeDeploy

正解 AWS CodeDeployは、アプリケーションのデプロイメント自動化に特化したマネージドサービスです。Amazon EC2インスタンス、オンプレミスサーバー、AWS Lambda関数、Amazon ECSサービスに対してアプリケーションを自動デプロイできます。Blue/Greenデプロイメント、ローリングデプロイメント、インプレースデプロイメントなど複数のデプロイ戦略をサポートし、デプロイ中の自動ロールバック機能も提供します。CodePipelineとのネイティブ統合により、CI/CDパイプラインのデプロイステージとして簡単に組み込むことができます。

D. AWS CodeArtifact

不正解 AWS CodeArtifactは、ソフトウェア開発で使用される依存関係やパッケージを安全に保存・管理・共有するためのパッケージリポジトリサービスです。npm、pip、Maven、NuGetなどの一般的なパッケージマネージャーと統合でき、組織内でのパッケージ管理を簡素化します。しかし、アプリケーションアーティファクトをEC2インスタンスや工場内オンプレミスサーバーにデプロイする機能は持っておらず、デプロイメント自動化の要件を満たしません。

全体的な説明

問われている要件

• CI/CDパイプラインでのデプロイメント自動化
• Amazon EC2インスタンスとオンプレミスサーバーの両方への対応
• AWS CodePipelineとの統合によるアーティファクトデプロイ
• 継続的デリバリープロセスの効率化

前提知識 AWS CodeDeployの概要 AWS CodeDeployは、アプリケーションのデプロイメントを自動化するフルマネージドサービスです：

• 多様な環境対応: EC2、オンプレミス、Lambda、ECSへのデプロイメント
• デプロイ戦略: Blue/Green、ローリング、インプレース、カナリアデプロイメント
• 自動ロールバック: デプロイ失敗時の自動的な前バージョンへの復旧
• 統合性: CodePipelineやその他のCI/CDツールとのシームレスな統合

EC2インスタンスへのデプロイメント EC2インスタンスでのCodeDeploy利用には以下が必要です：

• CodeDeployエージェント: インスタンス上で動作するデプロイメント処理プログラム
• IAMサービスロール: CodeDeployがEC2インスタンスにアクセスするための権限
• アプリケーション仕様ファイル: appspec.ymlによるデプロイ手順の定義
• デプロイグループ: デプロイ対象インスタンスの論理的なグループ化

オンプレミスサーバーへのデプロイメント オンプレミス環境では追加の設定が必要です：

• インスタンス登録: オンプレミスサーバーをCodeDeployに登録
• タグベース管理: サーバーの分類と管理のためのタグ付け
• ネットワーク接続: AWSサービスへのHTTPS接続確保
• 認証設定: IAMユーザーまたはロールによる認証

CI/CDパイプラインでの統合 CodePipelineとCodeDeployの統合により以下が実現できます：

• 自動トリガー: ソースコード変更時の自動デプロイ開始
• ステージ管理: 開発、ステージング、本番環境への段階的デプロイ
• 承認プロセス: 手動承認ステップの組み込み
• 並列デプロイ: 複数環境への同時デプロイメント

デプロイメント戦略 CodeDeployは複数のデプロイメント戦略を提供します：

• インプレースデプロイメント: 既存インスタンス上でのアプリケーション更新
• Blue/Greenデプロイメント: 新しい環境でのテスト後のトラフィック切り替え
• ローリングデプロイメント: インスタンスを段階的に更新
• カナリアデプロイメント: 一部のトラフィックで新バージョンをテスト

図での解説

解くための考え方 CI/CDパイプラインでEC2インスタンスとオンプレミスサーバーの両方にデプロイするには、AWS CodeDeployが最適な選択です。 CodeDeployは、これら両方の環境に対応した唯一のAWSマネージドデプロイメントサービスです。CodePipelineとのネイティブ統合により、ソースコード変更から本番環境デプロイまでの全プロセスを自動化できます。 Blue/Greenデプロイメントやローリングデプロイメントなどの高度なデプロイ戦略により、本番環境でのリスクを最小化しながら継続的デリバリーを実現できます。また、自動ロールバック機能により、問題発生時の迅速な復旧も可能です。 他の選択肢は、コード品質向上（CodeGuru）、オブジェクトストレージ（S3）、パッケージ管理（CodeArtifact）に特化しており、デプロイメント自動化という要件を満たしません。 参考資料

• AWS CodeDeploy とは
• Amazon EC2 インスタンスのコンピューティングプラットフォームでの CodeDeploy の使用
• オンプレミスインスタンスのコンピューティングプラットフォームでの CodeDeploy の使用