AWS Certified Developer – Associate (DVA-C02) 完全学習ガイド

試験概要

SAA-C03との違い

SAA（アーキテクト）が「何を使うか・どう組み合わせるか」を問うのに対し、DVAは**「どう実装するか・どうデバッグするか」**という開発者視点の問いが多い。

• 具体的なAPIの挙動・エラーコードの知識
• SDK/CLI の使い方
• CI/CDの実装方法
• デバッグとトラブルシューティング

ドメイン別出題割合

Domain 1: AWSサービスを使った開発（32%）

1-1. Lambda 深掘り

Lambda実行モデルの詳細:

# Lambda関数の基本構造
def handler(event, context):
    """
    event: トリガーからのイベントデータ
    context: 実行コンテキスト（残り時間、リクエストID等）
    """
    
    # コンテキストオブジェクトの活用
    remaining_ms = context.get_remaining_time_in_millis()
    request_id = context.aws_request_id
    function_name = context.function_name
    
    # タイムアウト前に処理を打ち切る例
    if remaining_ms < 5000:  # 5秒未満なら早期リターン
        return {"status": "timeout_imminent"}
    
    return {"status": "success"}

Lambda環境変数の暗号化:

import boto3
import os

# デプロイ時に暗号化した環境変数を復号して使用
kms = boto3.client('kms')

def decrypt_env(encrypted_value):
    response = kms.decrypt(
        CiphertextBlob=bytes.fromhex(encrypted_value)
    )
    return response['Plaintext'].decode('utf-8')

# または Secrets Managerを使用（推奨）
def get_secret(secret_name):
    secrets_client = boto3.client('secretsmanager')
    response = secrets_client.get_secret_value(SecretId=secret_name)
    return response['SecretString']

Lambda Layers の活用:

Lambda Layers:
  → 共通ライブラリを複数関数で共有
  → 関数サイズの削減
  → 最大5つのレイヤーをアタッチ可能
  → AWS SDK、共通ユーティリティ、設定ファイル等

ファイル構造（Python）:
  layer.zip
  └── python/
      └── lib/
          └── python3.x/
              └── site-packages/
                  ├── requests/
                  └── boto3/

Lambda Destinations（試験頻出）:

非同期呼び出しのみで使用可能

成功時の送信先:
  → SQS, SNS, Lambda, EventBridge

失敗時の送信先:
  → SQS, SNS, Lambda, EventBridge

注意: DLQ（Dead Letter Queue）との違い
  → DLQ: 失敗時のみ、SQS/SNSのみ
  → Destinations: 成功/失敗両方、4つの送信先

1-2. API Gateway 詳細

API Gatewayの3つのタイプ:

HTTP API:
  → 低レイテンシー、低コスト（REST APIの約70%安）
  → Lambda/HTTPバックエンド対応
  → JWT/OAuth 2.0認証
  → Swagger/OpenAPIインポート

REST API:
  → 全機能（APIキー、使用量プラン、WAF等）
  → リクエスト/レスポンス変換（マッピングテンプレート）
  → ステージ変数

WebSocket API:
  → 双方向通信
  → $connect/$disconnect/$default ルート
  → チャット、リアルタイム通知に活用

API Gatewayのキャッシュ:

キャッシュ設定:
  → ステージレベルで有効化
  → TTL: 0〜3600秒（デフォルト300秒）
  → キャッシュキー: メソッド、クエリ文字列、ヘッダー

キャッシュ無効化:
  → Cache-Control: max-age=0 ヘッダーをリクエストに付与
  → IAM権限が必要

コスト: 0.5GB〜237GBのキャッシュサイズを選択（時間課金）

統合タイプ（試験頻出）:

AWS: Lambdaを統合、レスポンス変換が必要な場合
AWS_PROXY (Lambda Proxy): マッピングなし、event/statusCodeをそのまま渡す
HTTP: HTTPバックエンド、変換あり
HTTP_PROXY: HTTPバックエンド、変換なし（パススルー）
MOCK: バックエンドなし、静的レスポンスを返す

1-3. DynamoDB 開発者視点

DynamoDB API の操作:

import boto3
from decimal import Decimal

dynamodb = boto3.resource('dynamodb')
table = dynamodb.Table('Products')

# Put Item
table.put_item(
    Item={
        'PK': 'USER#user1',
        'SK': 'PRODUCT#prod1',
        'price': Decimal('29.99'),  # floatではなくDecimalを使用
        'name': 'Widget'
    },
    ConditionExpression='attribute_not_exists(PK)'  # 冪等性のための条件
)

# Get Item（強整合性読み取り）
response = table.get_item(
    Key={'PK': 'USER#user1', 'SK': 'PRODUCT#prod1'},
    ConsistentRead=True  # デフォルトは結果整合性読み取り
)

# Update Item（条件付き更新）
table.update_item(
    Key={'PK': 'USER#user1', 'SK': 'PRODUCT#prod1'},
    UpdateExpression='SET price = :new_price ADD version :inc',
    ConditionExpression='version = :expected_version',
    ExpressionAttributeValues={
        ':new_price': Decimal('24.99'),
        ':inc': 1,
        ':expected_version': 5  # 楽観的ロック
    }
)

# Query（パーティションキーが必須）
response = table.query(
    KeyConditionExpression=Key('PK').eq('USER#user1') & Key('SK').begins_with('ORDER#'),
    FilterExpression=Attr('status').eq('ACTIVE'),
    Limit=10,
    ExclusiveStartKey=last_evaluated_key  # ページネーション
)

DynamoDB Transactional API:

# TransactWriteItems: 最大25アイテムの原子的操作
dynamodb_client = boto3.client('dynamodb')

response = dynamodb_client.transact_write_items(
    TransactItems=[
        {
            'Put': {
                'TableName': 'Orders',
                'Item': {'orderId': {'S': 'order1'}, 'status': {'S': 'CREATED'}},
                'ConditionExpression': 'attribute_not_exists(orderId)'
            }
        },
        {
            'Update': {
                'TableName': 'Inventory',
                'Key': {'productId': {'S': 'prod1'}},
                'UpdateExpression': 'SET stock = stock - :qty',
                'ConditionExpression': 'stock >= :qty',
                'ExpressionAttributeValues': {':qty': {'N': '1'}}
            }
        }
    ]
)

1-4. SQS / SNS / EventBridge 実装

SQS メッセージ処理パターン:

import boto3
import json

sqs = boto3.client('sqs')
QUEUE_URL = 'https://sqs.ap-northeast-1.amazonaws.com/123456789/my-queue'

# メッセージ送信（MessageDeduplicationId で冪等性）
sqs.send_message(
    QueueUrl=QUEUE_URL,
    MessageBody=json.dumps({'action': 'process', 'id': 'item1'}),
    MessageGroupId='group1',           # FIFOキューのみ
    MessageDeduplicationId='unique-id-1'  # FIFOキューの重複排除
)

# ロングポーリング（コスト削減）
response = sqs.receive_message(
    QueueUrl=QUEUE_URL,
    MaxNumberOfMessages=10,
    WaitTimeSeconds=20,  # 最大20秒待機（ロングポーリング）
    VisibilityTimeout=60
)

# メッセージ処理後に削除
for message in response.get('Messages', []):
    # 処理...
    sqs.delete_message(
        QueueUrl=QUEUE_URL,
        ReceiptHandle=message['ReceiptHandle']
    )

SNS Fan-out パターン:

SNSトピック → SQSキュー A → Lambda Worker A (処理A)
           → SQSキュー B → Lambda Worker B (処理B)
           → メールサブスクリプション

メリット:
  → 1つのイベントを複数の処理で並行処理
  → SQSバッファリングで処理レートを調整
  → 各処理が独立して失敗・再試行できる

Domain 2: セキュリティ（26%）

2-1. 認証・認可の実装

Cognito の詳細:

User Pool（認証）:
  → ユーザー登録・ログインを管理
  → JWT（IDトークン、アクセストークン、リフレッシュトークン）を発行
  → MFA、パスワードポリシー設定
  → ソーシャルログイン（Google, Facebook等）連携
  → Lambdaトリガー（Pre/Post認証フック）

Identity Pool（認可）:
  → CognitoユーザープールやソーシャルIDPと連携
  → IAM一時認証情報を発行
  → AWS サービスに直接アクセス可能（S3, DynamoDB等）

よくある構成:
  [アプリ] → [Cognito User Pool] → [JWTトークン]
                                        ↓
  [API Gateway] ← JWT検証 ← [Cognito Authorizer]
                                        ↓
  [Lambda] ← cognito:username, cognito:groups

API Gatewayの認証方式比較:

IAM認証:
  → SigV4署名でリクエスト
  → AWS SDKで自動処理
  → 同一AWSアカウント/クロスアカウントのサービス間

Cognito User Pool Authorizer:
  → JWTトークンを検証
  → フロントエンドアプリ（モバイル/SPA）向け

Lambda Authorizer:
  → カスタム認証ロジック（APIキー検証、独自JWT等）
  → 結果をIAMポリシーとして返す
  → キャッシュTTLで同一トークンの再検証を省略

Secrets Manager vs Parameter Store:

Secrets Manager:
  → 自動ローテーション（Lambda連携）
  → クロスアカウントアクセス
  → コスト: $0.40/シークレット/月
  → 用途: DBパスワード、APIキー（ローテーションが必要なもの）

SSM Parameter Store:
  → Standard: 無料（最大4KB）
  → Advanced: $0.05/パラメータ/月（最大8KB）
  → SecureString: KMSで暗号化
  → 用途: 設定値、接続文字列（ローテーション不要のもの）

実装例（Lambda）:

import boto3
import json

def get_db_password():
    # Secrets Manager
    client = boto3.client('secretsmanager')
    response = client.get_secret_value(SecretId='prod/db/password')
    secret = json.loads(response['SecretString'])
    return secret['password']

# 接続プールの初期化はハンドラー外で（コールドスタート時のみ実行）
db_password = get_db_password()

def handler(event, context):
    # ここでdb_passwordを使用
    pass

2-2. 一時的認証情報

STS (Security Token Service) の活用:

import boto3

sts = boto3.client('sts')

# AssumeRole: 別ロールに切り替え
response = sts.assume_role(
    RoleArn='arn:aws:iam::123456789:role/target-role',
    RoleSessionName='my-session',
    DurationSeconds=3600,
    ExternalId='unique-external-id'  # クロスアカウント時のセキュリティ
)

credentials = response['Credentials']
# AccessKeyId, SecretAccessKey, SessionToken を使用
temp_client = boto3.client(
    's3',
    aws_access_key_id=credentials['AccessKeyId'],
    aws_secret_access_key=credentials['SecretAccessKey'],
    aws_session_token=credentials['SessionToken']
)

# Assume Role with Web Identity: Cognitoフェデレーション
response = sts.assume_role_with_web_identity(
    RoleArn='arn:aws:iam::123456789:role/cognito-role',
    RoleSessionName='cognito-session',
    WebIdentityToken=cognito_id_token
)

Domain 3: デプロイメント（24%）

3-1. CI/CD パイプライン

CodePipeline の構成:

Source Stage: CodeCommit/GitHub/S3
  → ソースコードの変更をトリガー

Build Stage: CodeBuild
  → buildspec.yml に基づいてビルド・テスト
  → Dockerイメージ作成、単体テスト実行
  → テスト結果をS3/CodeBuildレポートに出力

Test Stage: CodeBuild / Lambda / Device Farm
  → 統合テスト、E2Eテスト

Deploy Stage: CodeDeploy / CloudFormation / ECS
  → アプリケーションのデプロイ

buildspec.yml の構造:

version: 0.2

env:
  variables:
    DOCKER_BUILDKIT: "1"
  parameter-store:
    DB_PASSWORD: "/prod/db/password"
  secrets-manager:
    API_KEY: "prod/api-key:api_key"

phases:
  install:
    runtime-versions:
      python: 3.11
    commands:
      - pip install -r requirements.txt

  pre_build:
    commands:
      - echo "Running tests..."
      - python -m pytest tests/ -v
      - aws ecr get-login-password | docker login --username AWS --password-stdin $ECR_URI

  build:
    commands:
      - echo "Building Docker image..."
      - docker build -t $IMAGE_NAME:$CODEBUILD_RESOLVED_SOURCE_VERSION .
      - docker tag $IMAGE_NAME:$CODEBUILD_RESOLVED_SOURCE_VERSION $ECR_URI/$IMAGE_NAME:latest

  post_build:
    commands:
      - docker push $ECR_URI/$IMAGE_NAME:latest
      - printf '[{"name":"app","imageUri":"%s"}]' $ECR_URI/$IMAGE_NAME:latest > imagedefinitions.json

artifacts:
  files:
    - imagedefinitions.json
    - appspec.yml

cache:
  paths:
    - /root/.cache/pip/**/*

3-2. SAM (Serverless Application Model)

SAM テンプレートの構造:

AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31

Globals:
  Function:
    Runtime: python3.11
    Timeout: 30
    MemorySize: 256
    Environment:
      Variables:
        TABLE_NAME: !Ref UsersTable

Resources:
  ApiFunction:
    Type: AWS::Serverless::Function
    Properties:
      CodeUri: src/
      Handler: app.handler
      Events:
        GetUsers:
          Type: Api
          Properties:
            Path: /users
            Method: get
            Auth:
              Authorizer: CognitoAuthorizer

      Policies:
        - DynamoDBCrudPolicy:
            TableName: !Ref UsersTable

  UsersTable:
    Type: AWS::Serverless::SimpleTable
    Properties:
      PrimaryKey:
        Name: userId
        Type: String

  # API Gateway定義
  MyApi:
    Type: AWS::Serverless::Api
    Properties:
      StageName: prod
      Auth:
        DefaultAuthorizer: CognitoAuthorizer
        Authorizers:
          CognitoAuthorizer:
            UserPoolArn: !GetAtt UserPool.Arn

SAM CLI コマンド:

# ローカルでLambdaを実行
sam local invoke ApiFunction --event events/api-event.json

# ローカルAPI Gatewayを起動
sam local start-api --port 3000

# ビルド
sam build

# デプロイ（初回はガイド付き）
sam deploy --guided

# ログをリアルタイムで確認
sam logs -n ApiFunction --stack-name my-stack --tail

3-3. Elastic Beanstalk デプロイ戦略

デプロイポリシー（試験頻出）:

All at once（全置換）:
  → 全インスタンスを一度に更新
  → ダウンタイムあり
  → 開発環境向け

Rolling（ローリング）:
  → 一度にバッチ単位で更新
  → キャパシティが一時的に低下
  → バッチサイズを設定

Rolling with additional batch:
  → 追加のインスタンスを起動してから更新
  → 常時フルキャパシティを維持
  → コスト増加

Immutable（イミュータブル）:
  → 新しいインスタンスグループを作成して切り替え
  → ゼロダウンタイム
  → 失敗時は新グループを削除するだけで即ロールバック

Blue/Green（Traffic Splitting）:
  → 新環境を並行作成
  → URL Swapで切り替え
  → 旧環境を維持してロールバック可能

3-4. CodeDeploy

appspec.yml（EC2/オンプレ用）:

version: 0.0
os: linux
files:
  - source: /
    destination: /var/www/html

hooks:
  BeforeInstall:
    - location: scripts/install_dependencies.sh
      timeout: 300
      runas: root
  
  AfterInstall:
    - location: scripts/change_permissions.sh
      timeout: 300
  
  ApplicationStart:
    - location: scripts/start_server.sh
      timeout: 300
  
  ValidateService:
    - location: scripts/basic_health_check.sh
      timeout: 300

ECSのBlue/Greenデプロイ（試験頻出）:

CodeDeployによるECS Blue/Green:
  1. 新タスク定義を作成（グリーン）
  2. グリーン環境にデプロイ
  3. テストトラフィックをグリーンにルーティング（テストリスナー）
  4. 検証後、本番トラフィックを切り替え（Canary/Linear/AllAtOnce）
  5. 待機時間後、ブルー環境を削除

トラフィックシフト設定:
  Canary10Percent5Minutes: 最初5分間は10%、その後100%
  Linear10PercentEvery1Minute: 1分ごとに10%ずつ増加
  AllAtOnce: 一度に100%切り替え

Domain 4: トラブルシューティングと最適化（18%）

4-1. X-Ray によるトレーシング

X-Ray の実装:

from aws_xray_sdk.core import xray_recorder
from aws_xray_sdk.core import patch_all

# AWS SDKの呼び出しを自動トレース
patch_all()

@xray_recorder.capture('process_order')
def process_order(order_id):
    # カスタムアノテーション（検索可能）
    xray_recorder.current_subsegment().put_annotation('orderId', order_id)
    
    # カスタムメタデータ（詳細情報、検索不可）
    xray_recorder.current_subsegment().put_metadata('orderDetails', {
        'items': 3,
        'total': 29.99
    })
    
    # 手動でサブセグメントを作成
    with xray_recorder.in_subsegment('validate_inventory'):
        check_inventory(order_id)
    
    return {"status": "processed"}

def handler(event, context):
    return process_order(event['orderId'])

X-Rayの概念:

Trace: 1つのリクエスト全体の記録（複数サービスをまたぐ）
Segment: 1サービスの処理記録
Subsegment: Segment内の詳細処理記録

Sampling Rules:
  → デフォルト: 最初のリクエスト + 5%のリクエストを記録
  → カスタムルール: 特定パスや条件のリクエスト率を調整
  
Service Map: サービス間の依存関係を可視化
Insights: 異常検知（エラー率の突然の上昇等）

4-2. CloudWatch によるモニタリング

カスタムメトリクスの送信:

import boto3
import datetime

cloudwatch = boto3.client('cloudwatch')

# カスタムメトリクスを送信
cloudwatch.put_metric_data(
    Namespace='MyApp/OrderProcessing',
    MetricData=[
        {
            'MetricName': 'OrderProcessingTime',
            'Value': 245.0,
            'Unit': 'Milliseconds',
            'Timestamp': datetime.datetime.utcnow(),
            'Dimensions': [
                {'Name': 'Environment', 'Value': 'prod'},
                {'Name': 'Region', 'Value': 'ap-northeast-1'}
            ]
        },
        {
            'MetricName': 'FailedOrders',
            'Value': 1.0,
            'Unit': 'Count'
        }
    ]
)

CloudWatch Logs Insights クエリ:

# エラーログを時系列で集計
fields @timestamp, @message
| filter @message like /ERROR/
| stats count() as errorCount by bin(5m)
| sort @timestamp desc

# Lambda の実行時間P99を計算
fields @duration
| filter @type = "REPORT"
| stats pct(@duration, 99) as p99Duration by bin(1h)

# 特定のリクエストIDをトレース
fields @timestamp, @message, @requestId
| filter @requestId = "abc123"
| sort @timestamp asc

4-3. よくあるエラーと対処法

DynamoDBのエラー:

ProvisionedThroughputExceededException:
  → 原因: キャパシティ上限に達した
  → 対処: 指数バックオフでリトライ / Auto Scalingを設定 / オンデマンドモードに変更

ConditionalCheckFailedException:
  → 原因: 条件式が満たされなかった（楽観的ロック失敗等）
  → 対処: リトライ / エラーハンドリングを実装

ValidationException:
  → 原因: リクエストのパラメータが不正
  → 対処: リクエストパラメータを確認（型エラー等）

ResourceNotFoundException:
  → 原因: テーブルが存在しない / 環境変数のミス
  → 対処: テーブル名と環境変数を確認

Lambda のエラー:

TooManyRequestsException (429):
  → 同時実行数の制限超過
  → 対処: Reserved Concurrencyを増加 / SQSでバッファリング

TaskTimedOut:
  → 実行時間が15分を超えた
  → 対処: 処理を分割 / Step Functionsに移行

OutOfMemoryError:
  → メモリ不足
  → 対処: メモリ割り当てを増加

AccessDeniedException:
  → IAMロールの権限不足
  → 対処: 実行ロールに必要な権限を追加

API Gatewayのエラー:

403 Forbidden:
  → IAM認証失敗 または Lambda Authorizer拒否

429 Too Many Requests:
  → スロットリング（デフォルト: アカウント全体で10,000 RPS）
  → 対処: Usage PlanでAPIキーごとのレート制限を設定

502 Bad Gateway:
  → Lambdaからの不正なレスポンス形式
  → Lambda Proxy統合の場合: statusCode, headersが必須

504 Gateway Timeout:
  → Lambdaの実行時間がAPI Gatewayのタイムアウト(29秒)を超えた
  → 対処: 非同期処理に変更（SQS経由）

学習計画（6週間）

Week 1-2: コアサービスの実装知識

Week 1:
  月: Lambda（詳細な実行モデル、エラーハンドリング）
  火: API Gateway（統合タイプ、認証方式）
  水: DynamoDB（API操作、トランザクション）
  木: SQS/SNS（メッセージ処理パターン）
  金: Cognito（UserPool vs Identity Pool）
  週末: 実際にLambda + API Gateway + DynamoDBでCRUD APIを作る

Week 2:
  月: S3 イベント通知とLambda連携
  火: Step Functions（ステートマシン設計）
  水: EventBridge（イベントパターン、スケジュール）
  木: ElastiCache（キャッシュパターンの実装）
  金: Kinesis（Producer/Consumerの実装）
  週末: 模擬問題30問

Week 3-4: セキュリティとデプロイ

Week 3:
  月: IAM深掘り（ポリシー評価、クロスアカウント）
  火: Secrets Manager / Parameter Store
  水: KMS（暗号化の実装）
  木: CloudWatch / X-Ray（トレーシングの実装）
  金: STS AssumeRole の実装パターン

Week 4:
  月: CodePipeline / CodeBuild / CodeDeploy
  火: SAM（Serverless Application Model）
  水: Elastic Beanstalk（デプロイポリシー）
  木: CloudFormation / CDK 基礎
  金: ECR + ECS デプロイ
  週末: 模擬問題50問

Week 5-6: 仕上げ

• Week 5: 模擬試験と弱点強化
• Week 6: 最終確認と試験

頻出問題パターンと解き方

パターン1: 「どのAWSサービスを使うか」

タスクのスケジュール実行:
  → EventBridge Scheduler または EventBridge Rules + cron式

キューからの処理失敗を保全:
  → DLQ（Dead Letter Queue）

非同期処理の成功/失敗を別サービスへ通知:
  → Lambda Destinations

Lambdaの実行時間が15分超え:
  → Step Functions（最大1年の状態管理）

複数ステップの処理で一部失敗時にロールバック:
  → Step Functions（Saga パターン）

パターン2: 「パフォーマンスの改善」

DynamoDBの読み取りが遅い:
  → DAX (DynamoDB Accelerator) でキャッシュ（マイクロ秒レイテンシ）
  → GSIでアクセスパターンを最適化

API Gatewayのレイテンシ改善:
  → キャッシュを有効化
  → Lambda ProvisionedConcurrencyでコールドスタート排除
  → HTTP APIを使用（REST APIより低レイテンシ）

S3からの大ファイルダウンロード高速化:
  → S3 Multipart Download / Range GET
  → CloudFrontでキャッシュ
  → S3 Transfer Acceleration（グローバル）

パターン3: 「コスト削減」

Lambdaのコスト削減:
  → メモリ最適化（Power Tuning Toolで最適メモリを探す）
  → 実行時間削減（処理の最適化）
  → ARM64 (Graviton2) アーキテクチャに切り替え（20%安）

DynamoDBのコスト削減:
  → TTL（Time to Live）で不要データを自動削除
  → オンデマンド → プロビジョニングモード（トラフィックが予測可能な場合）

アーキテクチャ図

サーバーレス API アーキテクチャ

sequenceDiagram
    participant Client as クライアント
    participant AGW as API Gateway
    participant Auth as Cognito Authorizer
    participant Lambda as Lambda Function
    participant DDB as DynamoDB
    participant SQS as SQS Queue

    Client->>AGW: POST /orders (JWT Token)
    AGW->>Auth: トークン検証
    Auth-->>AGW: 認可OK (Principal: user-id)
    AGW->>Lambda: イベント + コンテキスト
    Lambda->>DDB: putItem (注文データ)
    DDB-->>Lambda: 成功レスポンス
    Lambda->>SQS: メッセージ送信 (非同期処理)
    Lambda-->>AGW: 200 OK { orderId: "xxx" }
    AGW-->>Client: 200 OK

CodePipeline CI/CD フロー

flowchart LR
    subgraph Source["① Source Stage"]
        CodeCommit["CodeCommit\n(git push)"]
    end
    subgraph Build["② Build Stage"]
        CodeBuild["CodeBuild\nbuildspec.yml実行\n- テスト\n- Docker Build\n- ECRプッシュ"]
    end
    subgraph Staging["③ Deploy Staging"]
        ECS_Stg["ECS Staging\n(Blue/Green Deploy)"]
        Test["統合テスト\n(Lambda Test)"]
    end
    subgraph Approval["④ 承認ゲート"]
        Manual["手動承認\n(SNS通知→Slack)"]
    end
    subgraph Prod["⑤ Deploy Production"]
        ECS_Prod["ECS Production\nCanary (10%→100%)"]
    end

    CodeCommit --> CodeBuild --> ECS_Stg --> Test --> Manual --> ECS_Prod
    style Source fill:#fef3c7
    style Build fill:#dbeafe
    style Staging fill:#dcfce7
    style Approval fill:#fce7f3
    style Prod fill:#fee2e2

X-Ray トレース構成

flowchart TB
    subgraph Request["リクエストフロー"]
        AGW["API Gateway\n(Segment)"]
        Lambda1["Lambda\nFunction A\n(Segment)"]
        Lambda2["Lambda\nFunction B\n(Subsegment)"]
        DDB["DynamoDB\n(Subsegment)"]
        S3["S3\n(Subsegment)"]
    end

    subgraph XRay["X-Ray Service Map"]
        ServiceMap["X-Ray Console\n・Trace ID で追跡\n・レイテンシ分布\n・エラー率\n・サービスマップ"]
    end

    AGW -->|"Trace Header\nX-Amzn-Trace-Id"| Lambda1
    Lambda1 --> Lambda2
    Lambda1 --> DDB
    Lambda1 --> S3
    Lambda1 -.->|"セグメント送信"| ServiceMap
    Lambda2 -.->|"セグメント送信"| ServiceMap

本試験形式 模擬問題（詳細解説付き）

問題 1

Lambda 関数が実行中に他の AWS サービス（DynamoDB、S3 等）にアクセスするための最もセキュアな方法はどれですか？

• A. 環境変数にアクセスキーとシークレットキーを設定する
• B. Lambda の実行ロール（IAM Role）に必要な権限を持つポリシーをアタッチする
• C. Lambda コード内にアクセスキーをハードコードする
• D. Secrets Manager からアクセスキーを取得する

問題 2

DynamoDB テーブルへの書き込みがスロットリングされています。テーブルのパーティションキーが userId で、特定のユーザーへのアクセスが集中しています。最も適切な解決策はどれですか？

• A. DynamoDB Auto Scaling を有効にする
• B. RCU と WCU のキャパシティを手動で増やす
• C. Write Sharding を実装してパーティションキーにランダムサフィックスを追加する
• D. DynamoDB DAX を追加する

# Write Sharding実装例
import random
user_id = "user_12345"
shard_suffix = random.randint(1, 10)
partition_key = f"{user_id}_{shard_suffix}"
# 読み取り時は全シャードをScatter-gather

問題 3

Lambda 関数のコールドスタートを最小化したい。最も効果的な方法を2つ選んでください。

• A. Lambda のメモリを増やす（最大10GB）
• B. Provisioned Concurrency を設定する
• C. Lambda のタイムアウト値を増やす
• D. デプロイパッケージサイズを小さくし Lambda Layers を活用する
• E. Lambda を VPC 内に配置する

問題 4

Elastic Beanstalk でアプリケーションの新バージョンをデプロイする際、本番環境で完全な停止時間なしに、問題があった場合でも即座に旧バージョンにロールバックできる方法はどれですか？

• A. All at once デプロイ
• B. Rolling デプロイ
• C. Rolling with additional batch デプロイ
• D. Blue/Green デプロイ（URL スワップ）

問題 5

Lambda 関数が外部 API を呼び出していますが、一時的なエラーが発生することがあります。リトライ間隔を指数関数的に増やし（Exponential Backoff）、最終的に失敗したリクエストを記録したい場合の設計として最も適切なものはどれですか？

• A. Lambda の組み込みリトライ機能（2回）に任せる
• B. Lambda コード内で指数バックオフを実装し、最終失敗を DLQ（デッドレターキュー）に送る
• C. Lambda Destinations の onFailure で SQS に失敗イベントを送る
• D. AWS SDK のデフォルトリトライ設定に任せる

問題 6

AWS SAM テンプレートで、API Gateway + Lambda + DynamoDB の構成を定義したいと考えています。Lambda 関数に DynamoDB への読み書き権限を付与する最もシンプルな方法はどれですか？

• A. Lambda リソースに IAM ポリシーをインラインで記述する
• B. SAM の Policies プロパティに DynamoDBCrudPolicy を指定する
• C. CloudFormation の AWS::IAM::Role リソースを別途定義する
• D. Lambda 環境変数にアクセスキーを設定する

# SAM テンプレート例
MyFunction:
  Type: AWS::Serverless::Function
  Properties:
    Handler: index.handler
    Runtime: python3.12
    Policies:
      - DynamoDBCrudPolicy:        # SAM Policy Template
          TableName: !Ref MyTable

問題 7

API Gateway REST API のキャッシュが有効になっていますが、特定の管理者ユーザーは常に最新データを取得したい場合、どうすれば良いですか？

• A. キャッシュを無効化する（全ユーザーに影響）
• B. HTTP ヘッダー Cache-Control: max-age=0 をリクエストに含める
• C. API のステージ変数でキャッシュを制御する
• D. Lambda 関数内でキャッシュをバイパスするロジックを実装する

問題 8

CodeDeploy を使って EC2 インスタンスにアプリケーションをデプロイする際に使用する設定ファイルはどれですか？

• A. buildspec.yml
• B. appspec.yml
• C. taskdef.json
• D. template.yaml

# appspec.yml（EC2/オンプレミス用）
version: 0.0
os: linux
files:
  - source: /
    destination: /var/www/html/
hooks:
  BeforeInstall:
    - location: scripts/stop_server.sh
      timeout: 60
  AfterInstall:
    - location: scripts/install_dependencies.sh
  ApplicationStart:
    - location: scripts/start_server.sh
  ValidateService:
    - location: scripts/validate.sh

追加学習：DVA-C02 重要サービス詳解

Lambda 詳細（続き）

Lambda コールドスタートとウォームスタート

コールドスタート（Cold Start）:
  発生タイミング:
    → 初回呼び出し時
    → 長期間未使用後
    → スケールアウト時（新しい実行環境の作成）

  オーバーヘッド要因:
    → コンテナ作成
    → ランタイム初期化
    → 関数コードのダウンロード・初期化

  コールドスタート最小化の方法:
    → Provisioned Concurrency（プロビジョニング済み同時実行）
    → ARM/Graviton2 アーキテクチャの使用
    → 関数サイズの最小化（不要な依存関係を削除）
    → Lambda SnapStart（Java11以降で使用可能）

ウォームスタート（Warm Start）:
  → 既存の実行環境が再利用される
  → オーバーヘッドが小さい
  → グローバルスコープの変数・接続が再利用される

Lambda 同時実行

アカウントレベルのデフォルト同時実行上限: 1,000

Reserved Concurrency（予約済み同時実行）:
  → 関数専用の同時実行数を確保
  → 他の関数がこのキャパシティを使用できない
  → throttling（429エラー）が発生するリスクも

Provisioned Concurrency（プロビジョニング済み同時実行）:
  → 指定数の実行環境を事前初期化
  → コールドスタートを完全に排除
  → コストが追加発生（アイドル時も課金）

Unreserved Concurrency（未予約同時実行）:
  → アカウントの残り同時実行枠
  → 予約設定なしの関数が共有

試験での問い方:
  「コールドスタートを排除したい」 → Provisioned Concurrency
  「重要な関数に同時実行を保証したい」 → Reserved Concurrency

Lambda 実行時間とメモリ

メモリとCPUの関係:
  → 1,769MB のメモリ = 1 vCPU に相当
  → メモリを増やすとCPUも増加する
  → CPU集約的な処理はメモリを増やすことで高速化できる
  → コスト = GB×秒（メモリ×実行時間）

DynamoDB 深掘り

DynamoDB キャパシティモード

プロビジョンドキャパシティ（Provisioned）:
  → 読み取り/書き込みキャパシティユニット（RCU/WCU）を事前設定
  → Auto Scalingで自動調整可能
  → 予測可能なトラフィックに最適
  → Reserved Capacity購入でさらにコスト削減

  RCU（Read Capacity Unit）:
    → 強整合性読み取り: 4KB/s = 1 RCU
    → 結果整合性読み取り: 8KB/s = 1 RCU（2倍効率）
    → トランザクション読み取り: 4KB/s = 2 RCU

  WCU（Write Capacity Unit）:
    → 1KB/s = 1 WCU
    → トランザクション書き込み: 1KB/s = 2 WCU

オンデマンドキャパシティ（On-Demand）:
  → トラフィックに応じて自動スケール
  → キャパシティの事前設定不要
  → 突発的・予測不能なトラフィックに最適
  → プロビジョンドより単価は高い

DynamoDB インデックス

グローバルセカンダリインデックス（GSI）:
  → テーブルとは異なるPK/SKでクエリ可能
  → 別のキャパシティを持つ（テーブルとは独立）
  → テーブル作成後も追加可能
  → 最大20個まで作成可能
  → 結果整合性読み取りのみ

ローカルセカンダリインデックス（LSI）:
  → テーブルと同じPKで異なるSKを定義
  → テーブル作成時のみ追加可能（後から追加不可）
  → テーブルのキャパシティを共有
  → 最大5個
  → 強整合性読み取りが可能

試験でのポイント:
  「異なる検索パターンを後から追加したい」 → GSI
  「テーブルと同じパーティションキーで別の属性を検索したい（作成時）」 → LSI

DynamoDB Streams

特徴:
  → テーブルの変更（挿入・更新・削除）をストリームに記録
  → 変更後24時間保持
  → Lambda トリガーとして使用可能

使用ケース:
  → リアルタイムデータ変更通知
  → クロスリージョンレプリケーション
  → 変更履歴の監査ログ
  → ElasticSearchへのデータ同期

StreamViewType:
  KEYS_ONLY: PKとSKのみ
  NEW_IMAGE: 変更後のアイテム全体
  OLD_IMAGE: 変更前のアイテム全体
  NEW_AND_OLD_IMAGES: 変更前後両方

SQS 詳細

SQS キューの種類

標準キュー（Standard Queue）:
  → ほぼ無制限のスループット
  → 少なくとも1回の配信保証（重複配信の可能性あり）
  → ベストエフォートの順序（順序保証なし）

FIFOキュー（FIFO Queue）:
  → 順序保証（先入れ先出し）
  → 正確に1回の処理（重複なし）
  → スループット上限: 3,000件/秒（バッチ使用時）
  → キュー名は .fifo で終わる必要がある

選択基準:
  「順序が重要」「重複処理が致命的」 → FIFO
  「高スループット優先」「重複処理を許容できる」 → Standard

SQS 可視性タイムアウト

可視性タイムアウト（Visibility Timeout）:
  → コンシューマーがメッセージを受信すると、
    他のコンシューマーから一時的に不可視になる時間
  → デフォルト: 30秒
  → 最大: 12時間

フロー:
  ①キューにメッセージが届く
  ②コンシューマーがメッセージを受信（ReceiveMessage）
    → 可視性タイムアウト開始（デフォルト30秒）
  ③コンシューマーが処理完了
  ④DeleteMessageでメッセージを削除
  
  ※処理が30秒以内に終わらない場合:
    → タイムアウト後に再び可視になる
    → 別のコンシューマーが再処理（重複処理の可能性）
    → 対策: ChangeMessageVisibility で延長

Long Polling（ロングポーリング）:
  → 空のキューへのポーリング回数を減らしてコスト削減
  → WaitTimeSeconds: 1〜20秒（20秒が最大）
  → ReceiveMessage APIで設定

Dead Letter Queue（DLQ）

概念:
  → 処理に繰り返し失敗したメッセージを転送するキュー
  → MaxReceiveCount: 何回失敗したらDLQへ転送するか（1〜1000）

用途:
  → 処理失敗の原因分析
  → 失敗メッセージの再処理（DLQリドライブ機能）
  → アラーム設定（DLQにメッセージが溜まったら通知）

注意: FIFOキューのDLQはFIFOキューである必要がある

IAM 深掘り（開発者視点）

IAM Roles for EC2 / Lambda（インスタンスプロファイル）

IAMロールをEC2に割り当てるメリット:
  → アクセスキーをコードやEC2に保存しなくていい
  → IMDS（Instance Metadata Service）から一時的な認証情報を自動取得
  → 認証情報のローテーションが自動的に行われる

Lambdaの場合:
  → 実行ロール（Execution Role）をLambdaに割り当て
  → Lambda関数がAWSサービスにアクセスするための権限
  → boto3はこのロールの認証情報を自動的に使用する

IAM ポリシーの構造

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",          // Allow または Deny
      "Action": [
        "s3:GetObject",
        "s3:PutObject"
      ],
      "Resource": "arn:aws:s3:::my-bucket/*",
      "Condition": {
        "StringEquals": {
          "s3:prefix": ["uploads/"]
        }
      }
    }
  ]
}

STS（Security Token Service）

sts:AssumeRole:
  → 別のAWSアカウントまたは同一アカウントのロールを一時的に引き受ける
  → 一時的な認証情報（15分〜12時間有効）を発行

クロスアカウントアクセスのフロー:
  Account A のLambda
    → sts:AssumeRole を呼び出し
    → Account B の信頼ポリシーで許可
    → 一時的認証情報取得
    → Account B のS3にアクセス

Web Identity Federation:
  → CognitoやGoogle/FacebookでのサインインユーザーにAWSリソースへのアクセスを付与
  → sts:AssumeRoleWithWebIdentity

CI/CD 詳細

CodePipeline の構造

Pipeline構造:
  Source Stage → Build Stage → Test Stage → Deploy Stage

各StageはActionsで構成:
  Source Action: CodeCommit/GitHub/S3 → アーティファクトを出力
  Build Action: CodeBuild → コンパイル・テスト・パッケージ
  Approval Action: 手動承認ゲート
  Deploy Action: CodeDeploy/ECS/Beanstalk/CloudFormation

CodeBuild の buildspec.yml 構造

version: 0.2

env:
  variables:
    MY_VAR: "value"
  parameter-store:
    DB_PASSWORD: "/myapp/db/password"  # SSM Parameter Store参照
  secrets-manager:
    API_KEY: "arn:aws:secretsmanager:..."

phases:
  install:
    runtime-versions:
      nodejs: 18
    commands:
      - npm install
  pre_build:
    commands:
      - echo Logging in to Amazon ECR...
      - aws ecr get-login-password --region $AWS_DEFAULT_REGION
  build:
    commands:
      - echo Build started on `date`
      - npm run build
      - npm test
  post_build:
    commands:
      - echo Build completed on `date`
      - docker push $ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG

artifacts:
  files:
    - '**/*'
  base-directory: dist

cache:
  paths:
    - node_modules/**/*  # node_modulesをキャッシュ

CodeDeploy デプロイ設定

デプロイグループの設定:
  Deployment Type:
    In-place:  既存インスタンスを順次更新
    Blue/Green: 新環境を作成してから切り替え

デプロイ設定（Deployment Configuration）:
  EC2/オンプレミス:
    CodeDeployDefault.AllAtOnce: 全インスタンス一括更新
    CodeDeployDefault.HalfAtATime: 半数ずつ更新
    CodeDeployDefault.OneAtATime: 1台ずつ更新

  Lambda:
    Canary10Percent10Minutes: 10%に10分デプロイ後100%
    Linear10PercentEvery3Minutes: 3分ごとに10%ずつ
    AllAtOnce: 一括切り替え

appspec.yml のライフサイクルフック（EC2）:
  BeforeInstall → Install → AfterInstall
  → ApplicationStart → ValidateService

ElastiCache

Memcached vs Redis:

Memcached:
  → マルチスレッド（スケールアウト）
  → データ型: 文字列のみ
  → レプリケーション・永続化なし
  → セッションキャッシュ等のシンプルな用途

Redis:
  → シングルスレッド（アトミック操作）
  → 豊富なデータ型（String/List/Set/Hash/Sorted Set）
  → レプリケーション・Multi-AZ対応
  → スナップショット（永続化）
  → Pub/Sub、Leaderboard、セッション管理に最適

試験での問い方:
  「ランキング・ソート済みデータ構造」 → Redis (Sorted Set)
  「セッション管理・シンプルキャッシュ」 → どちらでも可（マルチスレッドならMemcached）
  「Multi-AZ・フェイルオーバー対応」 → Redis

X-Ray 詳細

X-Rayのコンポーネント

Trace: 1回のリクエストの全体像
  → 複数のSegmentから構成される

Segment: 1つのサービスが処理した時間
  → 例: Lambda関数の実行時間

Subsegment: Segment内の詳細な操作
  → 例: DynamoDBへのAPI呼び出し時間

Sampling Rule（サンプリングルール）:
  → 全てのリクエストをトレースするとコストが高くなる
  → デフォルト: 1リクエスト/秒 + 5%をサンプリング
  → カスタムルールで特定パス・HTTPメソッドのサンプリング率を変更

Annotations（注釈）:
  → インデックス化されるKey-Valueペア
  → フィルタ検索が可能
  → 例: user_id = "user123" でフィルタ

Metadata（メタデータ）:
  → インデックス化されない追加情報
  → 検索には使えないが詳細情報を格納できる

X-Ray デーモン

X-Ray SDK → X-Ray Daemon → X-Ray API

Daemon:
  → バックグラウンドプロセスとして実行
  → SDKからトレースデータをUDPで受信（ポート2000）
  → AWS X-Ray APIにバッファリングして送信

EC2/ECS での設定:
  → EC2: daemon をインストールして起動
  → ECS: サイドカーコンテナとして実行
  → Lambda: 自動的にdaemonが実行される（設定不要）

Elastic Beanstalk 詳細

.ebextensions による設定

# .ebextensions/01_nginx.config
option_settings:
  aws:elasticbeanstalk:environment:proxy:
    ProxyServer: nginx

# カスタムコマンドの実行
commands:
  01_install_package:
    command: "yum install -y amazon-cloudwatch-agent"
    
# ファイルの作成
files:
  "/etc/nginx/conf.d/proxy.conf":
    content: |
      client_max_body_size 20M;

Beanstalk デプロイポリシー（試験最頻出）

選択基準:
  「ダウンタイム許容・最速デプロイ」       → All at once
  「本番・ゼロダウンタイム・追加コスト不可」 → Rolling
  「本番・ゼロダウンタイム・キャパシティ維持」→ Rolling with additional batch
  「最速ロールバック・テスト可能」          → Immutable / Blue/Green

CloudWatch 詳細

CloudWatch Logs

ロググループ（Log Group）:
  → ログストリームをまとめるコンテナ
  → 保持期間: 1日〜無期限（デフォルトは無期限）
  → Lambda関数名がそのままロググループ名に

ログストリーム（Log Stream）:
  → 同一ソースからの連続したログイベント
  → Lambdaでは実行環境ごとにストリームが作成される

ログインサイトクエリ:
  fields @timestamp, @message
  | filter @message like /ERROR/
  | sort @timestamp desc
  | limit 20

メトリクスフィルター:
  → ログパターンから CloudWatch Metricsを生成
  → 例: ERROR ログの数をカウントしてアラームを設定

CloudWatch アラーム

アラームの状態:
  OK: 閾値以内
  ALARM: 閾値超過
  INSUFFICIENT_DATA: データ不足（初期状態）

アクション:
  → SNSへの通知
  → Auto Scalingアクション（スケールアウト/イン）
  → EC2インスタンスの停止・再起動・終了

Composite Alarm（複合アラーム）:
  → 複数のアラームを AND/OR 条件で組み合わせ
  → アラームストームを防ぐ（個別の誤アラームで通知しない）

追加模擬問題（DVA-C02本番形式）

セクション1: Lambda・API Gateway

問題 DVA-01

Lambda関数がDynamoDBにアクセスする際、最もセキュアな認証情報の管理方法はどれですか？

• A. 環境変数にアクセスキーとシークレットキーを直接設定する
• B. Lambda関数にIAM実行ロールを割り当て、DynamoDBへの最小権限ポリシーをアタッチする
• C. Lambda関数のコード内にアクセスキーをハードコーディングする
• D. Lambda Layersにアクセスキーを含む設定ファイルを保存する

問題 DVA-02

Lambda関数でコールドスタートを完全に排除したい。最も適切な設定はどれですか？

• A. Reserved Concurrencyを高い値に設定する
• B. Provisioned Concurrencyを有効にする
• C. タイムアウト値を最大（900秒）に設定する
• D. メモリを最大（10GB）に設定する

問題 DVA-03

API Gatewayで「バックエンドサーバーなしに静的なレスポンスを返したい」場合、使用する統合タイプはどれですか？

• A. AWS
• B. HTTP_PROXY
• C. MOCK
• D. AWS_PROXY

問題 DVA-04

Lambda関数の非同期呼び出しで、失敗したイベントを保持して後で再処理したい。最も適切な設定はどれですか？

• A. Lambda Layersを設定する
• B. DLQ（Dead Letter Queue）にSQSキューを設定する
• C. Lambda Destinationsの成功時送信先にSQSを設定する
• D. Reserved Concurrencyを1に設定する

問題 DVA-05

API Gatewayの「ステージ変数（Stage Variables）」の主な用途はどれですか？

• A. APIキーを暗号化する
• B. 本番/ステージング環境で異なるLambdaエイリアスやバックエンドURLを設定する
• C. APIのレート制限を設定する
• D. CORSヘッダーを自動的に追加する

セクション2: DynamoDB・SQS

問題 DVA-06

DynamoDBで「書き込み時に既にアイテムが存在する場合は更新しない」という冪等性を保証したい。正しい方法はどれですか？

• A. UpdateItemを使用する
• B. PutItemにConditionExpression attribute_not_exists(PK) を追加する
• C. BatchWriteItemを使用する
• D. TransactWriteItemsを使用する

問題 DVA-07

DynamoDBで「最近のリクエストを元に戻す（ポイントインタイムリカバリ）」機能の特徴はどれですか？

• A. 1時間ごとのスナップショットを35日間保持する
• B. 過去35日間の任意の時点にテーブルを復元できる継続的バックアップ
• C. テーブルを削除した場合は復元不可
• D. 手動でバックアップを取得してから有効化が必要

問題 DVA-08

SQSのメッセージが処理完了後も再度キューに現れる場合、最も可能性の高い原因はどれですか？

• A. メッセージのサイズが上限を超えている
• B. 処理完了後にDeleteMessageを呼び出していない
• C. キューの暗号化が有効になっていない
• D. メッセージのRetentionPeriodが短すぎる

問題 DVA-09

SQSで「順序保証」と「重複排除」が必要な場合、どのキュータイプを使用しますか？

• A. Standard Queue
• B. FIFO Queue
• C. どちらでも同じ
• D. Dead Letter Queue

問題 DVA-10

DynamoDBのGSI（グローバルセカンダリインデックス）とLSI（ローカルセカンダリインデックス）の違いとして正しいものはどれですか？

• A. GSIはテーブル作成後に追加できないが、LSIは追加できる
• B. LSIはテーブルと異なるパーティションキーを持つが、GSIは同じパーティションキーを使う
• C. GSIはテーブル作成後に追加できるが、LSIはテーブル作成時のみ追加可能
• D. LSIは全リージョンでレプリケートされるが、GSIは同一リージョンのみ

セクション3: セキュリティ・CI/CD

問題 DVA-11

Secrets Managerに保存したデータベース認証情報を、Lambda関数から安全に取得したい。最も適切な方法はどれですか？

• A. 環境変数にSecrets ManagerのARNを設定し、sdkで取得する
• B. コード内にシークレットをハードコーディングする
• C. S3にシークレットを保存してLambdaから読み込む
• D. Lambda Layersにシークレットを保存する

問題 DVA-12

CodeDeployでLambda関数をデプロイする際に「10分かけて10%ずつトラフィックを新バージョンにシフトしたい」場合、使用するデプロイ設定はどれですか？

• A. CodeDeployDefault.LambdaAllAtOnce
• B. CodeDeployDefault.LambdaCanary10Percent10Minutes
• C. CodeDeployDefault.LambdaLinear10PercentEvery10Minutes
• D. CodeDeployDefault.LambdaBlueGreen

問題 DVA-13

CodeBuildでSSM Parameter Storeの値を環境変数として使用したい。buildspec.ymlの正しい書き方はどれですか？

• A. env: variables: DB_PASS: "/app/db/password"
• B. env: parameter-store: DB_PASS: "/app/db/password"
• C. env: secrets: DB_PASS: "/app/db/password"
• D. env: ssm: DB_PASS: "/app/db/password"

問題 DVA-14

Cognito User Poolsのユーザーに対して「特定のS3バケット内の自分のディレクトリのみ」アクセスを許可したい。最も適切な方法はどれですか？

• A. User Poolのグループで全バケットへのアクセスを許可する
• B. IAMポリシーで ${cognito-identity.amazonaws.com:sub} 変数を使って各ユーザーのプレフィックスのみ許可する
• C. S3バケットポリシーで全Cognitoユーザーに全オブジェクトのアクセスを許可する
• D. Lambda関数でアクセス制御を実装する

問題 DVA-15

Elastic Beanstalkで「本番環境へのデプロイ中もサービスを停止せず、かつ追加コストを最小限にしたい」場合、最も適切なデプロイポリシーはどれですか？

• A. All at once
• B. Rolling
• C. Immutable
• D. Blue/Green

問題 DVA-16

CloudWatchメトリクスでカスタムメトリクスを送信する際のAPIはどれですか？

• A. PutMetricAlarm
• B. PutMetricData
• C. GetMetricStatistics
• D. CreateMetricStream

問題 DVA-17

X-RayのAnnotationとMetadataの違いとして正しいものはどれですか？

• A. Annotationはインデックスされ検索可能、Metadataは検索不可でサイズ制限なし
• B. Metadataはインデックスされ検索可能、Annotationは検索不可
• C. AnnotationとMetadataは全く同じ機能
• D. Annotationはリクエスト単位、MetadataはSegment単位で設定する

問題 DVA-18

ElastiCache Redisで「ユーザーのセッション情報を複数のAZに渡って高可用性で管理したい」場合の設定はどれですか？

• A. Memcachedをマルチノードクラスターで設定する
• B. Redis（Cluster Mode無効）でマルチAZレプリケーション + 自動フェイルオーバーを有効にする
• C. DynamoDBをセッションストアとして使用する（ElastiCacheは不要）
• D. Redis ClusterモードでHash槽を分散する

問題 DVA-19

Kinesisデータストリームとの統合でLambdaを使う際、「バッチサイズ100件のうち1件が処理失敗した場合、その失敗した1件から再試行したい」場合の設定はどれですか？

• A. BisectOnFunctionError を有効にする
• B. MaximumRetryAttempts を高い値に設定する
• C. DestinationにSQS DLQを設定する
• D. ParallelizationFactor を増やす

問題 DVA-20

CloudFormation スタックの更新で「特定のリソースが意図せず置き換えられること（Replacement）」を防ぎたい。適切な設定はどれですか？

• A. スタックポリシー（Stack Policy）で置き換えを拒否するルールを設定する
• B. DeletionPolicyをRetainに設定する
• C. UpdateReplacePolicy をDeleteに設定する
• D. スタックを削除して再作成する

DVA-C02 試験合格のための学習戦略

よく混同するポイント一覧

試験直前チェックリスト（DVA）

Domain 1（AWSサービスを使った開発）

• [ ] Lambda の実行モデル（コールドスタート・同時実行・タイムアウト設定）
• [ ] Lambda Destinations と DLQ の違い
• [ ] API Gateway の統合タイプ（MOCK/AWS/AWS_PROXY/HTTP/HTTP_PROXY）
• [ ] DynamoDB の RCU/WCU 計算方法
• [ ] DynamoDB GSI vs LSI の使い分け
• [ ] DynamoDB Streams のユースケース
• [ ] SQS の可視性タイムアウトとDLQの仕組み
• [ ] SQS Standard vs FIFO の使い分け
• [ ] ElastiCache Redis vs Memcached の使い分け

Domain 2（セキュリティ）

• [ ] IAM実行ロールを使ったLambdaの認証情報管理
• [ ] Secrets Manager vs SSM Parameter Store の使い分け
• [ ] STS AssumeRoleによるクロスアカウントアクセス
• [ ] Cognito User Pools vs Identity Pools の違い

Domain 3（デプロイメント）

• [ ] Beanstalk の5つのデプロイポリシーの特徴
• [ ] CodeDeploy の appspec.yml の構造
• [ ] CodeBuild の buildspec.yml の構造
• [ ] CodeDeploy の Lambda デプロイ設定（Canary/Linear）
• [ ] SAM テンプレートの基本構造

Domain 4（トラブルシューティングと最適化）

• [ ] X-Ray の Annotation vs Metadata の違い
• [ ] X-Ray デーモンの役割
• [ ] CloudWatch Logs のメトリクスフィルター
• [ ] CloudWatch の Composite Alarmの用途

付録: DVA-C02 頻出サービス一覧

★★★ 必ず覚えるサービス

Lambda 高度な機能

Lambda Extensions

Lambda Extensions はLambdaのライフサイクルに統合される補助プロセスです。

Extension の種類:
  Internal Extension: Lambda 関数プロセスと同じプロセス内で動作
  External Extension: 別プロセスとして動作（関数の前後に実行）

ユースケース:
  - APM エージェント（Datadog/New Relic）
  - セキュリティエージェント
  - カスタムロギング/オブザーバビリティ
  - 設定取得の事前ロード
  
ライフサイクルとの統合:
  Init フェーズ: Extension の初期化
  Invoke フェーズ: 関数実行と並行
  Shutdown フェーズ: アカウント後処理

Lambda コンテナイメージ

コンテナイメージサポート:
  最大サイズ: 10 GB（ZIP は 50 MB / 250 MB 解凍後）
  ベースイメージ: AWS 提供のランタイムイメージ or カスタム
  
メリット:
  - 大規模なデペンデンシー（ML ライブラリ等）に対応
  - 既存のコンテナワークフローとの統合
  - ローカルでのテストが容易
  
デプロイ手順:
  Docker Build → ECR Push → Lambda 関数作成（イメージ URI）

注意:
  コールドスタートは ZIP デプロイよりも遅い場合がある
  Snapstart は Java ランタイムのみ（コールドスタート削減）

Lambda SnapStart（Java）

SnapStart の動作:
  1. 関数を公開（Publish）すると自動的に Init フェーズを実行
  2. メモリスナップショットを取成
  3. 呼び出し時はスナップショットから即座に再開

効果:
  - Java の長い初期化時間（Spring Boot等）を最大 10 倍削減
  - コールドスタートを 1 秒以内に

制約:
  - Java 11/21 のみ
  - Versioned 関数のみ（$LATEST は不可）
  - ユニーク性のあるデータ（UUID/乱数）の扱いに注意

API Gateway 高度な機能

WebSocket API

WebSocket API のユースケース:
  - リアルタイムチャットアプリケーション
  - ライブダッシュボード
  - ゲームのリアルタイム通信
  - 株価・為替レートの配信

ルート:
  $connect: クライアント接続時
  $disconnect: クライアント切断時
  $default: 未定義のルート
  カスタムルート: メッセージの内容に応じた処理

バックエンドからクライアントへの送信:
  API Gateway Management API:
  POST https://{api-id}.execute-api.{region}.amazonaws.com/{stage}/@connections/{connectionId}

HTTP API vs REST API:

HTTP API（新しい）:
  低レイテンシ、低コスト（REST API の約70%安）
  JWT 認証（Cognito/OIDC）
  自動デプロイ
  Lambda Proxy 統合のみ
  
REST API（旧、より多機能）:
  API キー管理
  リクエスト/レスポンスの変換（マッピングテンプレート）
  キャッシュ
  カスタム認証（Lambda Authorizer）
  WAF 統合

選択基準:
  シンプルな Lambda プロキシ → HTTP API
  高度な機能（変換/キャッシュ/API Key）→ REST API

DynamoDB 高度な機能

DynamoDB Transactions

トランザクション操作:
  TransactWriteItems: 最大 25 アイテムを Atomically に書き込み
  TransactGetItems: 最大 25 アイテムを一貫性ある読み取り

ユースケース:
  - 口座振替（A から減額 AND B への加算を原子的に実行）
  - 在庫管理（在庫確認 AND 予約を原子的に実行）

コスト:
  通常の書き込み: 1 WCU/KB
  トランザクション書き込み: 2 WCU/KB（2倍）
  
条件付き書き込みとの違い:
  条件付き: 単一アイテムへの原子操作（楽観的ロック）
  トランザクション: 複数アイテムにまたがる原子操作

DynamoDB Accelerator (DAX)

DAX の特徴:
  インメモリキャッシュクラスター（DynamoDB 専用）
  レイテンシ: ミリ秒 → マイクロ秒（最大 10 倍高速化）
  
キャッシュの種類:
  Item Cache: GetItem/BatchGetItem のキャッシュ
  Query Cache: Query/Scan のキャッシュ
  
TTL: デフォルト 5 分（カスタマイズ可能）

DAX vs ElastiCache:
  DAX: DynamoDB 専用、DynamoDB API と互換
  ElastiCache: 汎用キャッシュ（複数のデータソースに対応）
  
向いているユースケース:
  DAX: 同じアイテムへの繰り返し読み取り（ホットパーティション対策）
  ElastiCache: アプリケーション計算結果のキャッシュ

DynamoDB の設計パターン

One-Table Design:
  複数のエンティティタイプを1つのテーブルで管理
  
  PK          SK              Type    Attributes
  USER#001    PROFILE         User    {name, email}
  USER#001    ORDER#2024-001  Order   {items, total}
  PRODUCT#A   META            Product {name, price}
  
  アクセスパターン:
    GetUser(userId):         PK=USER#userId, SK=PROFILE
    ListOrders(userId):      PK=USER#userId, SK begins_with ORDER#
    GetProduct(productId):   PK=PRODUCT#productId, SK=META

アクセスパターン駆動設計:
  DynamoDB は「アクセスパターンを先に決めてからモデリング」
  → RDB の正規化とは逆のアプローチ

SQS/SNS/EventBridge 詳細

SQS の詳細設定

メッセージの属性:
  最大 10 個のメッセージ属性
  型: String, Number, Binary

メッセージの重複:
  Standard SQS: 少なくとも1回配信（重複の可能性あり）
  FIFO SQS: 正確に1回配信（Deduplication ID で重複排除）

FIFO の Deduplication:
  ContentBased: メッセージ本文のハッシュ
  MessageDeduplicationId: 明示的に設定
  5分間ウィンドウで重複排除

SQS Extended Client:
  2 MB 超のメッセージを S3 に保存してポインタのみ SQS に格納
  Java SDK で提供（`software.amazon.payloadoffloading`）

EventBridge 詳細

EventBridge のコンポーネント:
  イベントバス: Default（AWS サービス）、カスタム、パートナー
  ルール: イベントパターンマッチング
  ターゲット: 20 以上（Lambda/SQS/SNS/Step Functions/API GW 等）

イベントパターン例:
{
  "source": ["aws.s3"],
  "detail-type": ["Object Created"],
  "detail": {
    "bucket": {
      "name": ["my-bucket"]
    },
    "object": {
      "key": [{"prefix": "uploads/"}]
    }
  }
}

EventBridge Pipes:
  ソース → フィルタリング → エンリッチメント → ターゲット
  ソース: SQS/DynamoDB Streams/Kinesis/Kafka
  エンリッチメント: Lambda/API GW/Step Functions
  ターゲット: 60 以上のサービス
  
EventBridge Scheduler:
  1回または繰り返しのスケジュールイベント
  クロスアカウント/クロスリージョンのターゲット
  タイムゾーン対応

Kinesis 高度な機能

Kinesis Consumer 拡張ファンアウト

標準 vs 拡張ファンアウト:

標準コンシューマー:
  全コンシューマーで2MB/秒/シャードを共有
  ポーリング型（GetRecords）
  コスト: 低い
  
拡張ファンアウト（EFO）:
  コンシューマーごとに2MB/秒/シャードを確保
  プッシュ型（SubscribeToShard）
  レイテンシ: 約70ms（標準は最大200ms）
  コスト: シャード時間 + データ取得の費用

使い分け:
  2つ以上のコンシューマーが同じシャードを読む → EFO
  低コスト優先（コンシューマーが少ない）→ 標準

Kinesis Data Firehose の変換

Firehose のデータ変換（Lambda）:
  データ受信 → Lambda 関数で変換 → S3/Redshift/OpenSearch に配信
  
変換関数の戻り値:
{
  "recordId": "xxx",
  "result": "Ok",  // Ok / Dropped / ProcessingFailed
  "data": "base64エンコードされたデータ"
}

動的パーティショニング:
  配信前にデータのフィールドを使って S3 プレフィックスを動的生成
  例: s3://bucket/year=2024/month=01/day=15/

AWS SAM 詳細

SAM テンプレートリファレンス

AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31

Globals:
  Function:
    Runtime: python3.11
    Timeout: 30
    Environment:
      Variables:
        TABLE_NAME: !Ref OrdersTable

Resources:
  # API + Lambda の組み合わせ
  OrdersApi:
    Type: AWS::Serverless::Api
    Properties:
      StageName: prod
      Auth:
        DefaultAuthorizer: CognitoAuth
        Authorizers:
          CognitoAuth:
            UserPoolArn: !GetAtt UserPool.Arn

  GetOrderFunction:
    Type: AWS::Serverless::Function
    Properties:
      Handler: app.get_order
      Events:
        GetOrder:
          Type: Api
          Properties:
            RestApiId: !Ref OrdersApi
            Path: /orders/{orderId}
            Method: GET
      Policies:
        - DynamoDBReadPolicy:
            TableName: !Ref OrdersTable

  # DynamoDB テーブル
  OrdersTable:
    Type: AWS::Serverless::SimpleTable
    Properties:
      PrimaryKey:
        Name: orderId
        Type: String
      ProvisionedThroughput:
        ReadCapacityUnits: 5
        WriteCapacityUnits: 5

  # SQS でトリガーされる Lambda
  ProcessOrderFunction:
    Type: AWS::Serverless::Function
    Properties:
      Handler: processor.handler
      Events:
        SQSEvent:
          Type: SQS
          Properties:
            Queue: !GetAtt OrderQueue.Arn
            BatchSize: 10
            FunctionResponseTypes:
              - ReportBatchItemFailures

  OrderQueue:
    Type: AWS::SQS::Queue
    Properties:
      VisibilityTimeout: 120
      RedrivePolicy:
        deadLetterTargetArn: !GetAtt OrderDLQ.Arn
        maxReceiveCount: 3

  OrderDLQ:
    Type: AWS::SQS::Queue

SAM Local でのローカルテスト

# SAM CLI でローカル実行
# 1. API をローカルで起動
sam local start-api --port 3000

# 2. Lambda 関数を直接呼び出し
sam local invoke GetOrderFunction   --event events/get-order.json

# 3. DynamoDB Local と組み合わせ
sam local start-api   --env-vars env.json   --docker-network sam-network

# 4. ビルドと デプロイ
sam build
sam deploy --guided  # 初回（sam config.toml に設定を保存）
sam deploy  # 2回目以降

AWS Amplify と AppSync

AWS AppSync（GraphQL API）

AppSync のコンポーネント:
  Schema: GraphQL スキーマ定義
  Resolver: データソースへのマッピング
  Data Sources: DynamoDB/Lambda/RDS/HTTP API/OpenSearch
  
リアルタイム機能:
  Subscriptions: WebSocket でリアルタイム更新を配信
  ユースケース: チャット/通知/コラボレーションアプリ

Amplify との統合:
  Amplify CLI で AppSync API を自動生成
  フロントエンド（React/Vue/Angular）から自動生成されたコードを使用

Resolver マッピングテンプレート（VTL）:
#set($id = $context.arguments.id)
{
  "version": "2017-02-28",
  "operation": "GetItem",
  "key": {
    "id": $util.dynamodb.toDynamoDBJson($id)
  }
}

Cognito 詳細

User Pool vs Identity Pool 詳細

Cognito User Pool（認証）:
  ユーザーディレクトリ
  ユーザー登録/ログイン/パスワードリセット
  MFA（TOTP/SMS）
  フェデレーション（Google/Facebook/SAML）
  JWT トークン発行（ID Token/Access Token/Refresh Token）
  
  カスタムフロー（Lambda Triggers）:
    Pre Sign-up: 登録前の検証
    Post Confirmation: 登録確認後の処理
    Pre Authentication: 認証前の検証
    Post Authentication: 認証後の処理
    Pre Token Generation: トークン生成前にカスタムクレームを追加

Cognito Identity Pool（認可）:
  AWS 認証情報（STS 一時認証情報）の発行
  認証済みロール と 未認証ロール（ゲスト）を設定
  対応 IdP: Cognito User Pool / Google / Facebook / SAML / OIDC
  
  取得フロー:
    User Pool でログイン → ID Token 取得
    → Identity Pool で STS AssumeRoleWithWebIdentity
    → 一時 AWS 認証情報（Access Key + Secret + Token）
    → S3/DynamoDB 等に直接アクセス

模擬試験追加問題（30問）

問題 21

AWS Lambda 関数が DynamoDB テーブルから読み取りを行いますが、しばらく使用されなかった後の最初の呼び出しが遅いと報告されています。この問題の原因と解決策はどれですか？

• A. Lambda 関数のメモリを増やす
• B. プロビジョニングされた同時実行数（Provisioned Concurrency）を設定する
• C. Lambda 関数のタイムアウト値を増やす
• D. DynamoDB のキャパシティモードをオンデマンドに変更する

# Lambda Provisioned Concurrency の設定
aws lambda put-provisioned-concurrency-config     --function-name MyFunction     --qualifier prod     --provisioned-concurrent-executions 5

問題 22

API Gateway で特定のクライアント IP からのリクエストのみを許可したい場合、最も効率的な方法はどれですか？

• A. Lambda Authorizer でカスタム IP チェックを実装する
• B. API Gateway のリソースポリシーで IP 制限を設定する
• C. WAF のマネージドルールで IP を制限する
• D. API Gateway のステージポリシーで IP 制限する

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": "*",
      "Action": "execute-api:Invoke",
      "Resource": "arn:aws:execute-api:*:*:*",
      "Condition": {
        "IpAddress": {
          "aws:SourceIp": ["203.0.113.0/24", "198.51.100.10/32"]
        }
      }
    }
  ]
}

問題 23

DynamoDB の GSI（グローバルセカンダリインデックス）とLSI（ローカルセカンダリインデックス）の主な違いはどれですか？（2つ選択）

• A. GSI は作成後に追加できるが、LSI はテーブル作成時のみ
• B. LSI は同じパーティションキーを使用し、GSI は異なるパーティションキーを使用できる
• C. GSI は強整合性読み取りをサポートしない
• D. LSI は追加のキャパシティを消費しない

問題 24

AWS CodeDeploy の appspec.yml で BeforeInstall フックに指定されたスクリプトの用途は何ですか？

• A. アプリケーションのインストール前にサービスを停止する
• B. デプロイが成功したことを確認するヘルスチェック
• C. 古いバージョンのアプリケーションを削除する
• D. 新しいバージョンのアプリケーションを設定する

問題 25

X-Ray で「アノテーション（Annotation）」と「メタデータ（Metadata）」の違いはどれですか？

• A. アノテーションはインデックス化されてフィルタリングに使用でき、メタデータはインデックス化されない
• B. アノテーションはコスト無料で、メタデータは課金される
• C. アノテーションはサブセグメントのみに使用でき、メタデータはセグメントのみ
• D. 機能的な違いはない

import aws_xray_sdk.core as xray

# アノテーション: インデックス化 → フィルタリングに使用
xray.put_annotation('userId', 'user123')
xray.put_annotation('orderId', 'order456')

# メタデータ: インデックス化されない → 詳細なデバッグ情報
xray.put_metadata('requestData', {
    'body': request.body,
    'headers': dict(request.headers)
})

問題 26〜50（ショート形式）

問題 26: Lambda 関数の最大タイムアウト時間は？ → 正解: 15 分（900 秒）。デフォルトは 3 秒。それ以上処理が必要な場合は Step Functions や ECS を検討

問題 27: SQS の「Long Polling」を有効にするメリットは？ → 正解: メッセージがない場合にすぐ空のレスポンスを返す代わりに最大 20 秒待機する。API コール数を削減し、コストと不要な処理を削減。ReceiveMessageWaitTimeSeconds で設定

問題 28: DynamoDB の「条件式（ConditionExpression）」の用途は？ → 正解: 書き込み操作（Put/Update/Delete）時に特定の条件が満たされている場合のみ実行。例: 在庫が 0 より大きい場合のみ在庫を減らす（楽観的ロック実装）

問題 29: API Gateway の「使用量プラン（Usage Plan）」の用途は？ → 正解: API キーごとにリクエストレート（req/秒）とクォータ（req/日/週/月）の上限を設定。テナント別の従量課金やプランの階層化（Basic/Pro/Enterprise）に使用

問題 30: Lambda のLAMBDA_TASK_ROOT環境変数が指すディレクトリは？ → 正解: /var/task - Lambda 関数コードがデプロイされるディレクトリ。関数パッケージのルートパスとして使用

問題 31: CodeBuild のbuildspec.ymlでenv/secrets-managerセクションの用途は？ → 正解: AWS Secrets Manager からシークレットを取得して環境変数として使用。ハードコードなしで秘密情報をビルド環境に注入。例: MY_SECRET: arn:aws:secretsmanager:region:account:secret:name

問題 32: ElastiCache Redis の「Redis Cluster モード」の利点は？ → 正解: データを複数のシャードに分散（水平スケーリング）。シャードごとにレプリカを持ち、高可用性を維持。通常モードより大規模なデータセットを扱える。ただし MULTI/EXEC トランザクションは同一スロット内のみ

問題 33: CloudFormation のOutputsセクションとクロススタック参照の仕組みは？ → 正解: Outputs で値をエクスポート（Export）して別スタックからFn::ImportValueで参照。例: VPC スタックの VpcId を App スタックで参照。依存関係が生まれるため、参照先スタックは先に削除不可

問題 34: SNS の「フィルターポリシー（Filter Policy）」の用途は？ → 正解: サブスクライバーが受け取るメッセージを属性でフィルタリング。例: 注文サービスは order_type=premium のメッセージのみ受信。不要なメッセージの処理コストを削減

問題 35: AWS X-Ray Daemon の役割は？ → 正解: X-Ray SDK からトレースデータを受け取り、X-Ray API に非同期で送信するプロセス。UDP ポート 2000 でデータを受信。ECS/EC2 上でサイドカーとして動作。Lambda では自動で含まれる

問題 36: Elastic Beanstalk の.ebextensionsディレクトリに置くファイルの形式は？ → 正解: YAML または JSON 形式の設定ファイル（拡張子 .config）。packages（パッケージインストール）、files（ファイル作成）、commands（コマンド実行）、container_commands（デプロイ後コマンド）セクションを含む

問題 37: CodeDeploy の「In-Place デプロイ」と「Blue/Green デプロイ」の違いは？ → 正解: In-Place: 既存インスタンスを停止して新バージョンをインストール（ダウンタイムあり）。Blue/Green: 新しいインスタンスセットに新バージョンをデプロイ後、LB でトラフィックを切り替え（ゼロダウンタイム、迅速なロールバック）

問題 38: Lambda の「Lambda@Edge」のユースケースは？ → 正解: CloudFront のエッジロケーションで Lambda を実行。ユーザーに近い場所でリクエスト/レスポンスを変換。A/Bテスト、認証/認可の実装、コンテンツのパーソナライズ。レイテンシ削減が目的

問題 39: DynamoDB Streams で「NEW_AND_OLD_IMAGES」の Stream View Type を使う理由は？ → 正解: 変更前後両方のアイテム状態を取得。変更差分の分析や CDC（Change Data Capture）に使用。Lambda トリガーで差分に基づいたビジネスロジックを実行（例: 更新前後で価格が変わった場合のみ通知）

問題 40: API Gateway の「Integration Timeout」のデフォルト値と最大値は？ → 正解: デフォルト 29 秒、最大 29 秒（REST API）。これ以上の処理時間が必要な場合は非同期パターン（SQS/Lambda の非同期呼び出し）を検討。Lambda の 15 分タイムアウトより短いことに注意

問題 41: AWS Step Functions の「Standard」と「Express」ワークフローの違いは？ → 正解: Standard: 実行ごとに1回確実（Exactly-once）、最大1年、監査可能、高コスト。Express: 少なくとも1回（At-least-once）、最大5分、高スループット/低コスト。Standard は注文処理等、Express はストリーミング処理等

問題 42: Lambda の「Reserved Concurrency」と「Provisioned Concurrency」の違いは？ → 正解: Reserved: その関数が使える最大同時実行数を予約（他の関数への影響を制限）、コールドスタートは防げない。Provisioned: 指定数の実行環境を初期化済みで常時待機（コールドスタートを防ぐ）。費用が異なる

問題 43: SQS の「メッセージグループ ID（MessageGroupId）」はどのキュータイプで使用されますか？ → 正解: FIFO キューのみ。同じ MessageGroupId のメッセージは順序保証。複数の MessageGroupId を使うことで、グループ内は順序保証しつつグループ間は並列処理（並列度 = MessageGroupId の数）

問題 44: CloudFormation の「カスタムリソース（Custom Resource）」のレスポンスに含めるStatusフィールドの値は？ → 正解: SUCCESS または FAILED。cfn-response モジュールまたは Pre-signed URL への HTTP PUT リクエストで CloudFormation にレスポンスを返す。FAILED + Reason でエラーの原因を伝える

問題 45: API Gateway のステージ変数（Stage Variables）の用途は？ → 正解: ステージ（dev/staging/prod）ごとに異なる設定値を保持。Lambda 関数 ARN、HTTP エンドポイント URL、設定値等を環境別に切り替え。例: ${stageVariables.lambdaAlias} で Lambda のエイリアスを参照

問題 46: Elastic Beanstalk の環境タイプ「Worker」環境の特徴は？ → 正解: SQS キューからメッセージを消費するバックグラウンド処理専用。Worker デーモンが SQS からメッセージを取得してアプリに POST リクエストを送信。cron.yaml で定期タスクも設定可能

問題 47: Lambda 関数のコードで環境変数を使う際の注意点は？ → 正解: process.env.VAR_NAME（Node.js）や os.environ['VAR_NAME']（Python）でアクセス。KMS による暗号化（at rest）をサポート。シークレットは Secrets Manager を使用し、環境変数には機密情報を直接置かない

問題 48: CodePipeline の「手動承認アクション（Manual Approval Action）」の実装方法は？ → 正解: パイプラインの任意のステージに「Approval」タイプのアクションを追加。指定した SNS トピックに通知 → 承認者がコンソール/CLI/Slack から承認。承認までパイプラインは一時停止。タイムアウト設定可能（デフォルト7日）

問題 49: DynamoDB の「テーブルクラス」で「Standard-IA」を選択する理由は？ → 正解: アクセス頻度が低いテーブル（ログ/履歴データ等）のストレージコストを削減。ストレージ費用が Standard の約 60% 安。ただし読み書きコスト（RCU/WCU）は標準より高い。アクセス少 + データ多い場合に最適

問題 50: Lambda の/tmpディレクトリの特性は？ → 正解: 最大 10 GB の一時ストレージ（デフォルト 512 MB、設定で最大 10 GB）。コンテナ（実行環境）の間で共有（ウォームコンテナでは前回のデータが残っている可能性あり）。関数終了後にクリアされる保証なし

試験直前最終チェック

Lambda 試験頻出ポイント

コールドスタート対策:
  Provisioned Concurrency → 常に初期化済みの実行環境を維持
  SnapStart（Java）→ メモリスナップショットから高速起動
  最小化: デプロイパッケージサイズを削減（依存関係の最適化）

同時実行数管理:
  アカウント全体のデフォルト: 1,000
  Reserved Concurrency: 最大同時実行を制限（他関数を保護）
  Burst Limit: 初期バースト（リージョンにより 500〜3,000）

コスト最適化:
  メモリ量が実行時間に比例（CPUも）
  128MB〜 vs 3,009MBの最適点を見つける
  Lambda Power Tuning（OSS ツール）で最適化

CI/CD パイプライン 試験頻出ポイント

CodePipeline の構造:
  Stage → Action の階層
  Source → Build → Test → Deploy → Approval → Notify
  
  Source: CodeCommit/GitHub/S3
  Build: CodeBuild/Jenkins
  Deploy: CodeDeploy/ECS/CloudFormation/Beanstalk
  
Artifact の流れ:
  各ステージのアウトプットが次ステージのインプット
  S3 バケット（Artifact Store）で受け渡し

CodeBuild のキャッシュ:
  S3 キャッシュ: ビルドアーティファクトを S3 にキャッシュ
  Local キャッシュ: コンテナのローカルキャッシュ（依存関係など）
  → ビルド時間とコストを削減

DVA-C02 開発者アソシエイト完全ガイド追加セクション完了

第6章: 開発ツール・CI/CD 詳細

6.1 AWS CodePipeline 高度な設定

import boto3
import json

cp_client = boto3.client('codepipeline', region_name='ap-northeast-1')

# マルチステージパイプライン定義
PIPELINE_DEFINITION = {
    'name': 'MyAppPipeline',
    'roleArn': 'arn:aws:iam::123456789012:role/CodePipelineRole',
    'artifactStore': {
        'type': 'S3',
        'location': 'my-pipeline-artifacts',
        'encryptionKey': {
            'id': 'arn:aws:kms:ap-northeast-1:123456789012:key/key-id',
            'type': 'KMS'
        }
    },
    'stages': [
        {
            'name': 'Source',
            'actions': [{
                'name': 'Source',
                'actionTypeId': {
                    'category': 'Source',
                    'owner': 'AWS',
                    'provider': 'CodeStarSourceConnection',
                    'version': '1'
                },
                'configuration': {
                    'ConnectionArn': 'arn:aws:codestar-connections:ap-northeast-1:123456789012:connection/abc123',
                    'FullRepositoryId': 'myorg/myapp',
                    'BranchName': 'main',
                    'DetectChanges': 'true'
                },
                'outputArtifacts': [{'name': 'SourceArtifact'}]
            }]
        },
        {
            'name': 'Build',
            'actions': [{
                'name': 'Build',
                'actionTypeId': {
                    'category': 'Build',
                    'owner': 'AWS',
                    'provider': 'CodeBuild',
                    'version': '1'
                },
                'configuration': {
                    'ProjectName': 'MyAppBuild'
                },
                'inputArtifacts': [{'name': 'SourceArtifact'}],
                'outputArtifacts': [{'name': 'BuildArtifact'}]
            }]
        },
        {
            'name': 'Test',
            'actions': [
                {
                    'name': 'IntegrationTest',
                    'actionTypeId': {
                        'category': 'Test',
                        'owner': 'AWS',
                        'provider': 'CodeBuild',
                        'version': '1'
                    },
                    'configuration': {'ProjectName': 'IntegrationTests'},
                    'inputArtifacts': [{'name': 'BuildArtifact'}],
                    'runOrder': 1
                },
                {
                    'name': 'SecurityScan',
                    'actionTypeId': {
                        'category': 'Test',
                        'owner': 'AWS',
                        'provider': 'CodeBuild',
                        'version': '1'
                    },
                    'configuration': {'ProjectName': 'SecurityScan'},
                    'inputArtifacts': [{'name': 'BuildArtifact'}],
                    'runOrder': 1  # IntegrationTestと並列実行
                }
            ]
        },
        {
            'name': 'DeployStaging',
            'actions': [{
                'name': 'DeployToStaging',
                'actionTypeId': {
                    'category': 'Deploy',
                    'owner': 'AWS',
                    'provider': 'ECS',
                    'version': '1'
                },
                'configuration': {
                    'ClusterName': 'staging-cluster',
                    'ServiceName': 'myapp-staging',
                    'FileName': 'imagedefinitions.json'
                },
                'inputArtifacts': [{'name': 'BuildArtifact'}]
            }]
        },
        {
            'name': 'Approval',
            'actions': [{
                'name': 'ManualApproval',
                'actionTypeId': {
                    'category': 'Approval',
                    'owner': 'AWS',
                    'provider': 'Manual',
                    'version': '1'
                },
                'configuration': {
                    'NotificationArn': 'arn:aws:sns:ap-northeast-1:123456789012:PipelineApprovals',
                    'CustomData': 'Please review staging environment before production deployment',
                    'ExternalEntityLink': 'https://staging.myapp.com'
                }
            }]
        },
        {
            'name': 'DeployProd',
            'actions': [{
                'name': 'DeployToProduction',
                'actionTypeId': {
                    'category': 'Deploy',
                    'owner': 'AWS',
                    'provider': 'CodeDeployToECS',
                    'version': '1'
                },
                'configuration': {
                    'ApplicationName': 'MyApp',
                    'DeploymentGroupName': 'MyApp-Production',
                    'TaskDefinitionTemplateArtifact': 'BuildArtifact',
                    'AppSpecTemplateArtifact': 'BuildArtifact',
                    'Image1ArtifactName': 'BuildArtifact',
                    'Image1ContainerName': 'IMAGE1_NAME'
                },
                'inputArtifacts': [{'name': 'BuildArtifact'}]
            }]
        }
    ]
}

def create_pipeline():
    response = cp_client.create_pipeline(pipeline=PIPELINE_DEFINITION)
    return response['pipeline']['name']

6.2 AWS CodeBuild 高度な設定

# buildspec.yml
version: 0.2

env:
  variables:
    ENVIRONMENT: "production"
  parameter-store:
    DB_PASSWORD: "/myapp/database/password"
  secrets-manager:
    API_KEY: "myapp/api-key:api_key"

phases:
  install:
    runtime-versions:
      python: 3.12
      nodejs: 20
    commands:
      - echo Install phase started
      - pip install -r requirements.txt
      - npm ci
    
  pre_build:
    commands:
      - echo Pre-build phase started
      - aws ecr get-login-password --region $AWS_DEFAULT_REGION | docker login --username AWS --password-stdin $AWS_ACCOUNT_ID.dkr.ecr.$AWS_DEFAULT_REGION.amazonaws.com
      - COMMIT_HASH=$(echo $CODEBUILD_RESOLVED_SOURCE_VERSION | cut -c 1-7)
      - IMAGE_TAG=${COMMIT_HASH:=latest}
      # ユニットテスト実行
      - python -m pytest tests/unit/ -v --junitxml=test-results/unit-tests.xml
    
  build:
    commands:
      - echo Build started on `date`
      # Dockerイメージビルド
      - docker build -t $ECR_REPOSITORY_URI:$IMAGE_TAG .
      - docker tag $ECR_REPOSITORY_URI:$IMAGE_TAG $ECR_REPOSITORY_URI:latest
      # SBOMスキャン
      - trivy image --exit-code 1 --severity HIGH,CRITICAL $ECR_REPOSITORY_URI:$IMAGE_TAG
    
  post_build:
    commands:
      - echo Post build phase started
      - docker push $ECR_REPOSITORY_URI:$IMAGE_TAG
      - docker push $ECR_REPOSITORY_URI:latest
      # imagedefinitions.json 作成
      - printf '[{"name":"myapp","imageUri":"%s"}]' $ECR_REPOSITORY_URI:$IMAGE_TAG > imagedefinitions.json
      # taskdef.json の IMAGE1_NAME を実際のイメージURIに置換
      - sed -i 's|IMAGE1_NAME|'"$ECR_REPOSITORY_URI:$IMAGE_TAG"'|g' taskdef.json

artifacts:
  files:
    - imagedefinitions.json
    - taskdef.json
    - appspec.yaml
  name: BuildOutput

reports:
  UnitTestResults:
    files:
      - 'test-results/unit-tests.xml'
    file-format: JUNITXML
  CoverageReport:
    files:
      - 'coverage/coverage.xml'
    file-format: COBERTURAXML

cache:
  paths:
    - '/root/.cache/pip/**/*'
    - 'node_modules/**/*'

6.3 AWS CodeDeploy 詳細

import boto3
import json

cd_client = boto3.client('codedeploy', region_name='ap-northeast-1')

# ECS Blue/Green デプロイグループ
def create_ecs_deployment_group(app_name, group_name, cluster_name, service_name):
    response = cd_client.create_deployment_group(
        applicationName=app_name,
        deploymentGroupName=group_name,
        serviceRoleArn='arn:aws:iam::123456789012:role/CodeDeployRole',
        deploymentConfigName='CodeDeployDefault.ECSAllAtOnce',
        deploymentStyle={
            'deploymentType': 'BLUE_GREEN',
            'deploymentOption': 'WITH_TRAFFIC_CONTROL'
        },
        ecsServices=[{
            'serviceName': service_name,
            'clusterName': cluster_name
        }],
        loadBalancerInfo={
            'targetGroupPairInfoList': [{
                'targetGroups': [
                    {'name': 'MyApp-Blue-TG'},
                    {'name': 'MyApp-Green-TG'}
                ],
                'prodTrafficRoute': {
                    'listenerArns': ['arn:aws:elasticloadbalancing:...']
                },
                'testTrafficRoute': {
                    'listenerArns': ['arn:aws:elasticloadbalancing:...:listener/test']
                }
            }]
        },
        blueGreenDeploymentConfiguration={
            'terminateBlueInstancesOnDeploymentSuccess': {
                'action': 'TERMINATE',
                'terminationWaitTimeInMinutes': 5
            },
            'deploymentReadyOption': {
                'actionOnTimeout': 'CONTINUE_DEPLOYMENT',
                'waitTimeInMinutes': 0
            }
        },
        autoRollbackConfiguration={
            'enabled': True,
            'events': [
                'DEPLOYMENT_FAILURE',
                'DEPLOYMENT_STOP_ON_ALARM',
                'DEPLOYMENT_STOP_ON_REQUEST'
            ]
        },
        alarmConfiguration={
            'enabled': True,
            'alarms': [
                {'name': 'MyApp-Error-Rate-Alarm'},
                {'name': 'MyApp-5xx-Alarm'}
            ]
        }
    )
    return response['deploymentGroupId']

# EC2/オンプレミス デプロイ設定
APPSPEC_EC2 = """
version: 0.0
os: linux
files:
  - source: /
    destination: /var/www/myapp
hooks:
  BeforeInstall:
    - location: scripts/install_dependencies.sh
      timeout: 300
      runas: root
  AfterInstall:
    - location: scripts/change_permissions.sh
      timeout: 30
      runas: root
  ApplicationStart:
    - location: scripts/start_server.sh
      timeout: 30
      runas: myuser
  ApplicationStop:
    - location: scripts/stop_server.sh
      timeout: 30
      runas: myuser
  ValidateService:
    - location: scripts/validate_service.sh
      timeout: 60
"""

# Lambda デプロイ設定
APPSPEC_LAMBDA = """
version: 0.0
Resources:
  - MyLambdaFunction:
      Type: AWS::Lambda::Function
      Properties:
        Name: "MyFunction"
        Alias: "live"
        CurrentVersion: "1"
        TargetVersion: "2"
Hooks:
  - BeforeAllowTraffic: "LambdaBeforeHook"
  - AfterAllowTraffic: "LambdaAfterHook"
"""

第7章: Lambda 高度な機能

7.1 Lambda Powertools

# Lambda Powertools for Python
from aws_lambda_powertools import Logger, Tracer, Metrics
from aws_lambda_powertools.metrics import MetricUnit
from aws_lambda_powertools.utilities.typing import LambdaContext
from aws_lambda_powertools.utilities.data_classes import (
    SQSEvent, APIGatewayProxyEventV2, DynamoDBStreamEvent
)
from aws_lambda_powertools.event_handler import APIGatewayRestResolver
from aws_lambda_powertools.utilities.batch import (
    BatchProcessor, EventType, process_partial_response
)

logger = Logger(service='order-service', level='INFO')
tracer = Tracer(service='order-service')
metrics = Metrics(namespace='MyApp', service='order-service')
app = APIGatewayRestResolver()

processor = BatchProcessor(event_type=EventType.SQS)

# APIエンドポイント（API Gateway統合）
@app.get('/orders/<order_id>')
@tracer.capture_method
def get_order(order_id: str):
    logger.info('Getting order', extra={'order_id': order_id})
    metrics.add_metric(name='GetOrderCount', unit=MetricUnit.Count, value=1)
    
    # ビジネスロジック
    order = fetch_order(order_id)
    
    if not order:
        return {'statusCode': 404, 'body': {'message': 'Order not found'}}
    
    return {'statusCode': 200, 'body': order}

@app.post('/orders')
@tracer.capture_method
def create_order():
    body = app.current_event.json_body
    logger.info('Creating order', extra={'body': body})
    
    order_id = process_order(body)
    metrics.add_metric(name='OrdersCreated', unit=MetricUnit.Count, value=1)
    
    return {'statusCode': 201, 'body': {'order_id': order_id}}

# SQSバッチ処理
def process_record(record: SQSEvent.SQSMessage):
    """SQSレコードの処理（部分失敗対応）"""
    payload = json.loads(record.body)
    logger.info('Processing SQS record', extra={'payload': payload})
    
    # 処理ロジック
    handle_event(payload)

@logger.inject_lambda_context(correlation_id_path='headers.x-correlation-id')
@tracer.capture_lambda_handler
@metrics.log_metrics(capture_cold_start_metric=True)
def lambda_handler(event: dict, context: LambdaContext):
    # APIGatewayプロキシイベントの場合
    if 'httpMethod' in event:
        return app.resolve(event, context)
    
    # SQSバッチイベントの場合
    return process_partial_response(
        event=event,
        record_handler=process_record,
        processor=processor,
        context=context
    )

7.2 Lambda Extensions

# Lambda Extensions: カスタム拡張機能の実装
import http.server
import requests
import os
import json
import threading

LAMBDA_EXTENSION_NAME = 'my-extension'
LAMBDA_RUNTIME_API = os.environ.get('AWS_LAMBDA_RUNTIME_API')

class LambdaExtension:
    def __init__(self):
        self.ext_id = None
    
    def register(self):
        """拡張機能を登録"""
        response = requests.post(
            f'http://{LAMBDA_RUNTIME_API}/2020-01-01/extension/register',
            headers={'Lambda-Extension-Name': LAMBDA_EXTENSION_NAME},
            json={'events': ['INVOKE', 'SHUTDOWN']}
        )
        self.ext_id = response.headers['Lambda-Extension-Identifier']
        return self.ext_id
    
    def next_event(self):
        """次のイベントを待機"""
        response = requests.get(
            f'http://{LAMBDA_RUNTIME_API}/2020-01-01/extension/event/next',
            headers={'Lambda-Extension-Identifier': self.ext_id},
            timeout=None  # 長時間待機
        )
        return response.json()
    
    def run(self):
        """イベントループ"""
        self.register()
        
        while True:
            event = self.next_event()
            event_type = event['eventType']
            
            if event_type == 'INVOKE':
                # 関数呼び出し前の処理（例: メトリクス収集開始）
                pass
            elif event_type == 'SHUTDOWN':
                # クリーンアップ（例: バッファのフラッシュ）
                self.flush_metrics()
                break
    
    def flush_metrics(self):
        """収集したメトリクスをフラッシュ"""
        # カスタムメトリクスを外部に送信
        pass

if __name__ == '__main__':
    extension = LambdaExtension()
    extension.run()

7.3 Lambda@Edge と CloudFront Functions

// CloudFront Functions: HTTPヘッダー操作（軽量処理）
function handler(event) {
    var request = event.request;
    var headers = request.headers;
    var uri = request.uri;
    
    // セキュリティヘッダーの追加
    var response = {
        statusCode: 200,
        statusDescription: 'OK',
        headers: {
            'strict-transport-security': {
                value: 'max-age=63072000; includeSubdomains; preload'
            },
            'x-content-type-options': { value: 'nosniff' },
            'x-frame-options': { value: 'DENY' },
            'x-xss-protection': { value: '1; mode=block' }
        }
    };
    
    // URLリライト
    if (uri === '/') {
        request.uri = '/index.html';
    }
    
    // APIキー検証
    var apiKey = headers['x-api-key'] ? headers['x-api-key'].value : '';
    if (uri.startsWith('/api/') && !validateApiKey(apiKey)) {
        return {
            statusCode: 401,
            statusDescription: 'Unauthorized',
            body: JSON.stringify({error: 'Invalid API key'})
        };
    }
    
    return request;
}

function validateApiKey(key) {
    // 簡単なAPIキー検証（CloudFront Functionsでは外部呼び出し不可）
    var validKeys = ['key1', 'key2'];
    return validKeys.includes(key);
}

# Lambda@Edge: 認証・A/Bテスト（重い処理）
import json
import jwt
import boto3
import hashlib

def viewer_request_handler(event, context):
    """ビューワーリクエスト: 認証チェック"""
    request = event['Records'][0]['cf']['request']
    headers = request['headers']
    
    # Cookieから認証トークンを取得
    auth_token = None
    if 'cookie' in headers:
        cookies = headers['cookie'][0]['value']
        for cookie in cookies.split(';'):
            if 'auth_token=' in cookie.strip():
                auth_token = cookie.strip().split('=')[1]
    
    # 保護されたパスの確認
    uri = request['uri']
    if uri.startswith('/protected/'):
        if not auth_token:
            return {
                'status': '302',
                'statusDescription': 'Found',
                'headers': {
                    'location': [{
                        'key': 'Location',
                        'value': f'/login?redirect={uri}'
                    }]
                }
            }
        
        try:
            # JWTトークン検証
            payload = jwt.decode(auth_token, 'secret', algorithms=['HS256'])
            # ヘッダーにユーザー情報を追加（オリジンに転送）
            request['headers']['x-user-id'] = [{
                'key': 'X-User-Id',
                'value': payload.get('sub', '')
            }]
        except jwt.InvalidTokenError:
            return {
                'status': '401',
                'statusDescription': 'Unauthorized',
                'body': json.dumps({'error': 'Invalid token'})
            }
    
    return request

def origin_request_handler(event, context):
    """オリジンリクエスト: A/Bテスト"""
    request = event['Records'][0]['cf']['request']
    headers = request['headers']
    
    # A/Bテスト: ユーザーIDに基づいてオリジンを変更
    user_id = headers.get('x-user-id', [{'value': 'anonymous'}])[0]['value']
    
    # ハッシュで50/50分割
    hash_value = int(hashlib.md5(user_id.encode()).hexdigest(), 16) % 100
    
    if hash_value < 50:
        # バリアントA
        request['origin']['custom']['domainName'] = 'origin-a.example.com'
        request['headers']['x-ab-variant'] = [{'key': 'X-AB-Variant', 'value': 'A'}]
    else:
        # バリアントB
        request['origin']['custom']['domainName'] = 'origin-b.example.com'
        request['headers']['x-ab-variant'] = [{'key': 'X-AB-Variant', 'value': 'B'}]
    
    return request

第8章: 監視・デバッグ・トレーシング

8.1 AWS X-Ray 詳細

import boto3
import json
from aws_xray_sdk.core import xray_recorder, patch_all
from aws_xray_sdk.core.models.segment import Segment

# X-Ray パッチ（自動インストルメンテーション）
patch_all()  # boto3, requests, httplib等を自動計測

# X-Ray セグメント/サブセグメント
@xray_recorder.capture('process_order')
def process_order(order_data):
    
    # カスタムアノテーション（フィルタリング用）
    xray_recorder.current_segment().put_annotation('order_id', order_data['order_id'])
    xray_recorder.current_segment().put_annotation('customer_id', order_data['customer_id'])
    
    # カスタムメタデータ（詳細情報）
    xray_recorder.current_segment().put_metadata('order_details', order_data)
    
    # サブセグメント: DynamoDB操作
    with xray_recorder.in_subsegment('save_to_dynamodb') as subsegment:
        subsegment.put_annotation('table', 'Orders')
        dynamodb = boto3.resource('dynamodb')
        table = dynamodb.Table('Orders')
        table.put_item(Item=order_data)
    
    # サブセグメント: SNS通知
    with xray_recorder.in_subsegment('send_notification') as subsegment:
        sns = boto3.client('sns')
        sns.publish(
            TopicArn='arn:aws:sns:ap-northeast-1:123456789012:OrderNotifications',
            Message=json.dumps({'order_id': order_data['order_id']})
        )
    
    return {'status': 'processed'}

# X-Ray グループとフィルター
xray_client = boto3.client('xray')

def create_xray_group(group_name, filter_expression):
    response = xray_client.create_group(
        GroupName=group_name,
        FilterExpression=filter_expression,
        InsightsConfiguration={
            'InsightsEnabled': True,
            'NotificationsEnabled': True
        }
    )
    return response['Group']

# フィルター例
groups = [
    {
        'name': 'HighLatency',
        'filter': 'responsetime > 5'  # 5秒以上
    },
    {
        'name': 'Errors',
        'filter': 'error = true OR fault = true'
    },
    {
        'name': 'ProductionService',
        'filter': 'annotation.Environment = "production" AND service("order-service")'
    }
]

8.2 Amazon CloudWatch Synthetics

import boto3

cw_client = boto3.client('cloudwatch', region_name='ap-northeast-1')
synthetics_client = boto3.client('synthetics', region_name='ap-northeast-1')

# Canaryの作成（APIエンドポイント監視）
def create_api_canary(canary_name, api_url):
    
    canary_code = """
const synthetics = require('Synthetics');
const log = require('SyntheticsLogger');

const apiCanaryBlueprint = async function () {
    const validateSuccessful = async function(res) {
        return new Promise((resolve, reject) => {
            if (res.statusCode < 200 || res.statusCode > 299) {
                throw `Failed with status code: ${res.statusCode}`;
            }
            const responseBody = [];
            res.on('data', (d) => { responseBody.push(d); });
            res.on('end', () => {
                const body = JSON.parse(Buffer.concat(responseBody).toString());
                if (!body.status || body.status !== 'healthy') {
                    throw `Unhealthy response: ${JSON.stringify(body)}`;
                }
                resolve();
            });
        });
    };

    const options = {
        hostname: '%s',
        method: 'GET',
        path: '/health',
        port: 443,
        protocol: 'https:'
    };

    const response = await synthetics.executeHttpStep('Verify health endpoint', options, validateSuccessful);
};

exports.handler = async () => {
    return await apiCanaryBlueprint();
};
""" % api_url
    
    response = synthetics_client.create_canary(
        Name=canary_name,
        Code={
            'Handler': 'apiCanary.handler',
            'ZipFile': create_zip_from_code(canary_code)
        },
        ArtifactS3Location=f's3://canary-results-{canary_name}/',
        ExecutionRoleArn='arn:aws:iam::123456789012:role/CloudWatchSyntheticsRole',
        Schedule={
            'Expression': 'rate(5 minutes)'
        },
        RunConfig={
            'TimeoutInSeconds': 60
        },
        FailureRetentionPeriodInDays=31,
        SuccessRetentionPeriodInDays=31,
        RuntimeVersion='syn-nodejs-puppeteer-7.0'
    )
    
    synthetics_client.start_canary(Name=canary_name)
    return response['Canary']['Id']

模擬試験 セット2（25問）

問題1 CodePipelineでGitHub（GitHub Actions以外）からソースコードを取得する最新の推奨方法は？

A) CodePipeline Source ActionでOAuthトークンを設定する B) CodeStar ConnectionsでGitHub App接続を作成し、CodeStarSourceConnectionアクションを使用する C) CodeCommitにGitHubをミラーリングする D) S3にコードをアップロードしてS3 Source Actionを使用する

正解: B 解説: CodeStar Connections（現在はAWS Connections）は最新のGitHub統合方法。OAuth 1.0の代わりにGitHub Appを使用し、よりセキュアで安定した接続を提供。コンソールでConnection設定後、AWSとGitHubアカウントを承認（ハンドシェイク）するだけで完了。BitbucketやGitLab.comにも対応。

問題2 AWS SAM（Serverless Application Model）テンプレートでLambda関数にAPI Gatewayを自動的に作成する方法は？

A) CloudFormationテンプレートにAPI Gatewayリソースを手動追加する B) SAMテンプレートのEvents プロパティにHttpApiまたはApiイベントを定義する C) Serverless Frameworkを別途インストールする D) SAM CLIのsamコマンドのみでデプロイ可能

正解: B 解説: SAMテンプレートのLambda関数にEventsセクションを追加しType: HttpApi（HTTP API v2）またはType: Api（REST API v1）を指定すると、API Gatewayが自動作成される。SAMはCloudFormationの拡張で、sam build+sam deployでデプロイ。AWS::Serverless::Function等のSAMリソースタイプをCloudFormationリソースに変換。

問題3 Lambda関数でDynamoDB接続を効率化する方法は？

A) 毎回のリクエストで新しいDynamoDB接続を作成する B) DynamoDB接続を関数ハンドラー外（グローバルスコープ）で初期化し、ウォームコンテナ間で再利用する C) DynamoDB DAXを常に使用する D) Lambda関数ごとに専用のDynamoDBテーブルを作成する

正解: B 解説: Lambda実行モデル: 関数ハンドラー外のコードはコンテナ起動時（コールドスタート）にのみ実行され、ウォームコンテナ間で再利用される。DynamoDBクライアント等の接続をグローバルスコープで初期化することでウォームリクエストでの接続オーバーヘッドを削減。/tmpディレクトリ（512MB）も再利用される。

問題4 X-Rayのサンプリングルールを使用する主な目的は？

A) X-Rayデータのリアルタイムアラートを設定する B) トレースするリクエストの割合を制御してコストとパフォーマンスを最適化する C) X-Rayデータを他のAWSアカウントに共有する D) X-RayセグメントをS3にアーカイブする

正解: B 解説: X-Rayサンプリング: デフォルトは毎秒1リクエスト+5%のリクエスト。高トラフィックで全トレースは不要かつコスト高。カスタムサンプリングルールでURL、HTTPメソッド、サービス名に基づくサンプリングレート設定可能。例: ヘルスチェック0%、重要APIエンドポイント100%。

問題5 Lambda関数の同時実行数制限の設定方法は？

A) CloudWatchアラームで制限する B) Lambda関数のConcurrency設定で予約同時実行（Reserved Concurrency）を設定する C) API Gatewayのスロットリングで制限する D) VPCサブネットで制限する

正解: B 解説: Lambda Reserved Concurrency: 関数レベルで最大同時実行数を設定。利点: ①特定関数の無制限スケールを防止（コスト制御）②重要な関数のキャパシティを確保。制限: Reserved Concurrency=0で関数を無効化可能。アカウントの同時実行上限（デフォルト1000）内で各関数に割り当て。Provisioned ConcurrencyはReserved内で設定。

問題6 API Gateway REST APIでレスポンスボディの変換を行う方法は？

A) Lambda関数内でレスポンスを変換する B) API Gatewayのマッピングテンプレート（Velocity Template Language）でレスポンスを変換する C) CloudFront Functionsでレスポンスを変換する D) ALBのレスポンスルールで変換する

正解: B 解説: API Gateway統合レスポンスのマッピングテンプレート（VTL: Velocity Template Language）でレスポンスボディを変換可能。例: Lambda関数の生レスポンスをJSON形式に整形、エラーコードの変換。HTTP API（v2）はVTLサポートなし（Lambda Proxyのみ）。REST API（v1）はより柔軟な変換が可能。

問題7 AWS Secrets Managerでシークレットのローテーションを実装する場合、Lambda関数に必要なステップは？

A) createSecret、setSecret、testSecret、finishSecretの4ステップ B) generatePassword、storeSecret、rotateSecret の3ステップ C) updatePassword、validatePassword の2ステップ D) rotateSecret の1ステップのみ

正解: A 解説: Secrets Manager ローテーションLambdaの4ステップ（SecretRotationStep環境変数で判別）: 1.createSecret: 新しいシークレット値（AWSPENDING）を作成。2.setSecret: バックエンド（DB等）のパスワードを変更。3.testSecret: 新しい値で接続テスト。4.finishSecret: AWSPENDING→AWSCURRENTにラベル移動。失敗時はAWSDEPRECATEDのロールバック。

問題8 DynamoDB StreamsとAWS Lambda統合での部分的バッチ失敗を処理する方法は？

A) 全バッチを失敗させてSQS DLQに移動する B) FunctionResponseTypes: [ReportBatchItemFailures]を設定し、Lambda関数から失敗アイテムのシーケンス番号を返す C) Lambda関数内で各レコードをtry/catchで囲む（失敗を無視） D) DynamoDB Streamsのシャードを増やす

正解: B 解説: DynamoDB Streams + Lambda の Partial Batch Response（部分失敗対応）: Lambda EventSource MappingのFunctionResponseTypesにReportBatchItemFailuresを設定。Lambda関数がエラーを持つレコードのitemIdentifier（シーケンス番号）を含むbatchItemFailuresリストを返すことで、失敗レコードのみ再試行。成功レコードは再処理されない。

問題9 CDK（Cloud Development Kit）の主な利点は？

A) CloudFormationより高速なデプロイ B) TypeScript/Python等のプログラミング言語でIaCを記述でき、ロジック・再利用・テストが容易 C) GUIでインフラを定義できる D) AWSコンソールの操作を自動記録する

正解: B 解説: AWS CDK: TypeScript、Python、Java、Go等でCloudFormationテンプレートを生成するIaCフレームワーク。利点: ①ループ・条件分岐でDRY原則②関数・クラスでコード再利用（Construct）③ユニットテスト（CDK Assertions）④IDEのオートコンプリート。CDKアプリ→cdk synth→CloudFormationテンプレート→デプロイ。

問題10 ECSタスク定義のloggingDriverにawslogsを設定した場合の動作は？

A) ログはECS APIから取得する B) コンテナログがCloudWatch Logsに自動的に送信される C) ログがS3に保存される D) ログがKinesisに送信される

正解: B 解説: ECSタスク定義のloggingConfiguration: awslogsドライバー設定でコンテナのSTDOUT/STDERRをCloudWatch Logsに自動送信。設定: awslogs-group（ロググループ名）、awslogs-region、awslogs-stream-prefix（タスクIDを自動付与）。タスク実行ロールにlogs:CreateLogStream、logs:PutLogEvents権限が必要。

問題11 SQSのLong Pollingを有効化する方法と利点は？

A) ReceiveMessageWaitTimeSecondsを20に設定（最大）、空のレスポンス削減とコスト最適化 B) ReceiveMessageWaitTimeSecondsを0に設定してShort Polling C) SQSのキューポリシーでLong Pollingを有効化する D) Lambda ESMでLong Pollingは自動的に管理される

正解: A 解説: SQS Long Polling: ReceiveMessageWaitTimeSecondsを1-20秒に設定（キューまたはAPIリクエスト）。メッセージがない場合に最大waitTimeSeconds待機してから空のレスポンスを返す。Short Polling（=0）は即座に返す→空のレスポンスが多発→無駄なAPIコール→コスト増加。Long Pollingで空レスポンス削減しコスト最大90%削減可能。

問題12 AWS CloudFormation ChangeSetを使用する主な理由は？

A) デプロイ速度の向上 B) スタック更新前に変更内容をプレビューして意図しない変更を防ぐ C) CloudFormationテンプレートの自動生成 D) リソースの自動タグ付け

正解: B 解説: CloudFormation ChangeSet: create-change-set→変更内容プレビュー→execute-change-setの2段階更新。本番環境での誤更新防止に重要。変更タイプ（Add/Modify/Remove）とリソースが影響を受けるか（直接/間接）が表示される。AWS CDK deployもデフォルトでChangeSetsを使用。CI/CDパイプラインのApprovalステップでChangeSet確認が推奨。

問題13 DynamoDB TTL（Time To Live）の動作は？

A) TTL設定後即座にアイテムが削除される B) TTLはUNIXタイムスタンプ（数値型）で設定し、期限切れ後48時間以内にバックグラウンドで削除される（課金対象外） C) TTLはISO8601形式の文字列で設定する D) TTL削除はDynamoDB Streamsに記録されない

正解: B 解説: DynamoDB TTL: 指定した属性（UNIXタイムスタンプ、数値型）が現在時刻を過ぎた後、48時間以内にバックグラウンドで削除。削除時にReadCapacityを消費しないためコスト効率良い。TTL削除はDynamoDB StreamsにuserIdentity: {type: "Service", principalId: "dynamodb.amazonaws.com"}として記録される→Lambdaで後処理可能。

問題14 Lambda関数でS3からファイルをダウンロードする最も効率的な方法は？

A) requests.get()でS3のパブリックURLから取得する B) boto3 S3クライアントのget_object()またはdownload_file()メソッドを使用する C) SSMパラメータにファイル内容を保存して取得する D) Lambda環境変数にファイル内容をBase64エンコードして保存する

正解: B 解説: Lambda→S3アクセス: ①get_object()→response['Body'].read()でメモリに読み込み（小〜中ファイル向け）。②download_file(Bucket, Key, '/tmp/file')で/tmpに保存（最大10GB、Lambda ephemeral storage）。大ファイルはストリーミング処理（get_object()のBodyをiterchunks）。Lambda実行ロールにs3:GetObject権限が必要。

問題15 AWS AppSync（GraphQL API）と API Gateway（REST API）の使い分けの基準は？

A) AppSyncはAWS内部のみ、API GatewayはインターネットAPI向け B) AppSync: リアルタイムデータ（Subscriptions/WebSocket）、柔軟なクエリ（GraphQL）、オフライン対応。API Gateway: シンプルなREST/HTTP API、ルーティングロジック重視 C) AppSyncはコストが常に高い D) API GatewayはGraphQL APIをサポートしない

正解: B 解説: AppSync: GraphQL API。Subscription（WebSocket）でリアルタイムデータプッシュ。DynamoDB、Lambda、HTTP、OpenSearch、RDS等の複数データソースを1つのAPIに統合。Amplifyとの統合が容易。モバイル/Webのリアルタイムアプリ（チャット、ダッシュボード等）に適。API Gateway: HTTP/REST/WebSocket API。既存HTTPバックエンドへのプロキシ、使用量プラン、カスタムオーソライザーが必要な場合。

問題16 CodeDeployのEC2/オンプレミスデプロイで使用するAppSpecファイルのhooksの実行順序は？

A) ApplicationStop → BeforeInstall → Install → AfterInstall → ApplicationStart → ValidateService B) BeforeInstall → Install → AfterInstall → ApplicationStart → ValidateService C) BeforeInstall → AfterInstall → ApplicationStart D) ValidateService → ApplicationStart → Install → BeforeInstall

正解: A 解説: EC2 CodeDeployライフサイクルイベント（順序）: ApplicationStop→DownloadBundle→BeforeInstall→Install→AfterInstall→ApplicationStart→ValidateService。各フックでスクリプトを実行可能。失敗するとデプロイがロールバック（自動ロールバック設定時）。DownloadBundleとInstallはCodeDeployエージェントが制御（hookは設定不可）。

問題17 Amazon SQS FIFOキューのスループット制限を緩和する方法は？

A) より多くのSQSキューを作成する B) MessageGroupIdを異なる値で設定し、高スループット設定（DeduplicationScope=messageGroup）を有効化する C) SQS ExtendedClientでペイロードをS3に保存する D) SQSをKinesisに置き換える

正解: B 解説: SQS FIFO標準: デフォルト300 TPS（バッチで3000 TPS）。高スループットFIFO（FifoThroughputLimit=perMessageGroupId）: メッセージグループごとに最大3000 TPS（バッチで30000 TPS）。MessageGroupIdを分散させることで並列処理を最大化。同じMessageGroupId内は順序保証だが、異なるGroupId間は並列処理可能。

問題18 Lambda Layersの主なユースケースは？

A) Lambda関数の実行速度向上 B) 共通ライブラリ・依存関係の複数Lambda関数間での共有、デプロイパッケージサイズの削減 C) Lambda関数のVPC設定 D) Lambda関数の同時実行数制御

正解: B 解説: Lambda Layers: 最大5個のLayerを関数にアタッチ可能（合計250MB）。用途: ①NumPy/Pandas等の大型ライブラリを共有（全関数で重複をなくす）②カスタムランタイム（PowerShell等）③共通ユーティリティコード。Lambda Powertoolsもレイヤーで提供。ARNを指定してアカウント間共有も可能。

問題19 API Gatewayのリクエストバリデーションを使用する主な目的は？

A) APIのレスポンス時間を短縮する B) バックエンドに到達する前にリクエストパラメータ・ボディのスキーマを検証してLambdaの無駄な呼び出しを防ぐ C) API GatewayのIPフィルタリング D) SSL証明書の検証

正解: B 解説: API Gateway Request Validation: JSON Schema（OpenAPI仕様）でリクエストボディ・クエリ文字列・ヘッダーを定義し、不正なリクエストをAPI Gatewayレベルで400 Bad Requestとして拒否。Lambda関数への無駄な呼び出しを削減→コスト削減。バリデーターを作成してAPIのメソッドに関連付けることで有効化。

問題20 AWS CloudWatch Logs Metric FilterでSyntaxErrorの発生数を監視する場合の設定は？

A) CloudWatchアラームにLambda関数のエラーメトリクスを使用する B) ロググループにメトリクスフィルターを作成し、パターン[ERROR] SyntaxErrorにマッチする際にカウントするカスタムメトリクスを発行する C) X-Rayでエラーをトレースする D) AWS Config でエラーを検出する

正解: B 解説: CloudWatch Logs Metric Filter: ロググループのログパターンにマッチした際にカスタムメトリクスを発行する機能。設定: パターン（例: [timestamp, requestId, level=ERROR, message=*SyntaxError*]）→メトリクス名前空間・名前・値を定義。そのメトリクスに基づいてアラームを設定。構造化ログ（JSON）の特定フィールドに基づくフィルタも可能。

問題21 AWS CloudFormationでスタック間のリソース参照を行う方法は？

A) StackIDを直接ハードコードする B) ExportsでリソースARNを出力しImportValue関数でクロススタック参照する C) SSMパラメータを経由してリソース情報を共有する D) CloudFormationスタックは分割できない

正解: B 解説: CloudFormation クロススタック参照: エクスポートスタックでOutputsセクションにExport.Nameを定義。インポートスタックで!ImportValue ExportName関数で参照。注意: エクスポートされた値が使用中のスタックは削除・変更不可（スタック間の依存関係）。SSMパラメータ経由の方が柔軟（スタック間の疎結合）。CDKではCfnOutput.importValue()。

問題22 CodeBuildのビルドコンテナでDockerビルドを実行する場合の設定は？

A) CodeBuildはDockerビルドをサポートしない B) privilegedModeをtrueに設定して特権モードでビルドコンテナを実行する C) EC2インスタンスでDockerビルドを実行してCodeBuildに転送する D) Dockerビルドはコンテナ内では不可能

正解: B 解説: CodeBuild環境のprivilegedMode: trueに設定するとDockerデーモンをビルドコンテナ内で実行可能（Docker-in-Docker）。CodeBuildプロジェクトのEnvironment設定でprivilegedMode: true。ECRへのDockerイメージプッシュにはCodeBuildサービスロールにECR権限も必要。ECRを使わないローカルビルドも可能だがECRへのプッシュが推奨。

問題23 Lambda関数の環境変数を動的に変更する最も効率的な方法は？

A) Lambda関数を毎回再デプロイする B) Systems Manager Parameter StoreまたはSecrets Managerを使用して実行時に設定値を取得する C) 環境変数はLambdaデプロイ時にしか変更できない D) DynamoDBに設定を保存して毎リクエストで取得する

正解: B 解説: SSM Parameter StoreやSecrets Managerを実行時に参照することで、Lambda再デプロイなしに設定変更可能。推奨パターン: Lambda初期化フェーズ（グローバルスコープ）でパラメータをキャッシュし、TTLベースで定期更新。/aws/reference/secretsmanager/ プレフィックスでSecrets Managerの値をSSM Parameter Store経由で取得も可能。AWS AppConfigも動的設定管理に有用。

問題24 AWS SAM CLIで本番環境と同等のローカルテスト環境を構築する方法は？

A) sam local start-api でLambda + API Gatewayをローカルエミュレート B) Docker不要でローカルテスト可能 C) AWSコンソールからのみテスト可能 D) ローカルテストにはAWS認証情報が不要

正解: A 解説: SAM CLI ローカルテスト: sam local start-apiでAPI GatewayとLambdaをDockerコンテナでローカル実行。sam local invokeで単一Lambda関数をイベントJSONで直接呼び出し。Docker Desktop必須。AWS SDK呼び出しはLocalStackまたは実AWSアカウントに接続。sam local generate-eventでイベントJSONのテンプレート生成可能。

問題25 DynamoDB Global Tables v2（2019）のデータ競合解決方式は？

A) 書き込みタイムスタンプベースのLast-Writer-Wins（LWW） B) ベクタークロックによる競合検出と手動解決 C) マスターリージョンへのすべての書き込み転送 D) 競合が発生した場合はエラーを返す

正解: A 解説: DynamoDB Global Tables v2のLast-Writer-Wins（LWW）: 複数リージョンで同じアイテムに同時書き込みが発生した場合、タイムスタンプが最新の書き込みが勝つ。各リージョンで書き込み可能（Active-Active）。注意: NTP同期の問題で稀に古い値で上書きされる可能性あり。条件付き書き込み（ConditionExpression）を使用して競合を最小化することが推奨。

DVA試験 最終チェックリスト

ドメイン1: AWSサービスの開発 (32%)

• [ ] Lambda（コールドスタート、Provisioned Concurrency、環境変数、レイヤー）
• [ ] API Gateway（REST vs HTTP API、マッピングテンプレート、カスタムオーソライザー）
• [ ] DynamoDB（シングルテーブルデザイン、GSI設計、TTL、Streams、Transaction）
• [ ] SQS（Long Polling、DLQ、可視性タイムアウト、FIFO）
• [ ] SNS（フィルタリングポリシー、ファンアウト）
• [ ] EventBridge（カスタムバス、ルール、スケジューラー）
• [ ] S3（Pre-signed URL、マルチパート、S3イベント通知）
• [ ] Secrets Manager（ローテーションLambdaの4ステップ）

ドメイン2: セキュリティ (26%)

• [ ] IAM（ポリシー、ロール、AssumeRole）
• [ ] Cognito（User Pools、Identity Pools、フェデレーション）
• [ ] KMS（暗号化コンテキスト、キーポリシー）
• [ ] AWS WAF（ルール、マネージドルールグループ）
• [ ] API Gatewayオーソライザー（Lambda、Cognito、IAM）

ドメイン3: デプロイ (24%)

• [ ] CodePipeline（ステージ、アクション、承認）
• [ ] CodeBuild（buildspec.yml、キャッシュ、Dockerビルド）
• [ ] CodeDeploy（デプロイ設定、AppSpec、ライフサイクルフック）
• [ ] SAM（テンプレート、sam CLI、ローカルテスト）
• [ ] CDK（Construct、Stack、App、cdk synth/deploy）
• [ ] Elastic Beanstalk（デプロイポリシー、.ebextensions）
• [ ] CloudFormation（ChangeSet、カスタムリソース、StackSets）

ドメイン4: トラブルシューティング・最適化 (18%)

• [ ] CloudWatch（Logs Insights、メトリクスフィルター、アラーム）
• [ ] X-Ray（セグメント、サブセグメント、アノテーション、サンプリング）
• [ ] Lambda Powertools（Logger、Tracer、Metrics）
• [ ] CloudWatch Synthetics（Canary）
• [ ] AWS Config（コンプライアンス評価）

試験のポイント

1. Lambda実行環境の再利用（グローバルスコープでの初期化）
2. DynamoDB ConditionExpression（オプティミスティックロック）
3. SQS Visibility Timeout > Lambda Timeout（処理時間 × 6倍推奨）
4. API Gateway 29秒タイムアウト制限（非同期パターンが必要）
5. CodeDeploy ライフサイクルイベントの順序を暗記