DVA-C02 D1 AWSサービスでの開発 徹底解説（2025年最新）｜Lambda・DynamoDB・疎結合設計

1. はじめに — D1「AWSサービスでの開発」とは

本記事は「AWS DVA-C02 試験対策」シリーズの Vol1 です。
シリーズ全体像（試験仕様・4ドメイン俯瞰・学習順序）をまだ確認していない方は、Vol0 ロードマップ を先にご覧ください。

DVA-C02（AWS Certified Developer – Associate）は Associate レベル の試験で、65問・130分・合格スコア720という仕様です。
D1「Development with AWS Services（AWSサービスでの開発）」は出題比率 32% と4ドメイン中で最大であり、問題バンク400問では 127問 をカバーする最重要ドメインです。
Lambda・DynamoDB・API Gateway という サーバーレス三本柱 への深い理解と、疎結合・冪等性・キャッシュ戦略などの設計原則が問われます。

2. D1 出題範囲と配点（127問・32%・最大配点）

2-1. 公式タスクステートメント

公式試験ガイド（DVA-C02 Version 1.3）によると、D1 は以下の3つのタスクステートメントで構成されています。

T1.1 では SDK/CLI の活用・疎結合・冪等性・指数バックオフなどの設計知識が、T1.2 では Lambda のイベントソースマッピング・並行性・レイヤーなどの実装知識が、T1.3 では DynamoDB のキー設計・インデックス・Query vs Scan や S3 のストレージクラスなどのデータストア知識が問われます。

2-2. 出題傾向のポイント

D1 は「コードを書く開発者の視点」が全問に通底しています。
SAA-C03（アーキテクチャ設計視点）と異なり、DVA-C02 D1 では「Lambda のデプロイパッケージを最小化するにはどうするか」「DynamoDB のホットパーティション問題を避けるキー設計は何か」といった 実装レベルの判断 が全問に通底する点を特徴とします。

3. Lambda の開発・設定

3-1. イベントソースマッピング

Lambda の呼び出しには3つの方式があり、イベントソースによって自動的に方式が決まります。

SQS を使ったイベントソースマッピングの重要ポイント

• Lambda は SQS をポーリングし、メッセージをバッチ（最大10,000件）で受け取ります。
• バッチ処理に成功するとメッセージが自動削除されます。
• バッチ内のメッセージが1件でも失敗すると、バッチ全体がリトライ対象になります。
• ReportBatchItemFailures を使うと、失敗したメッセージIDのみをリトライ対象に指定できます（部分的なバッチ失敗レポート）。

Kinesis Data Streams との違い

Kinesis では、シャードごとに1つの Lambda インスタンスがポーリングします。
処理順序がシャード単位で保証される一方、シャード内の処理失敗はシャード全体をブロックします。
bisectOnFunctionError を有効にすると、失敗バッチを2分割して問題レコードを特定しやすくなります。

3-2. 並行性（Concurrency）

Lambda の並行性には3つの概念があります。

アカウントレベルの同時実行数上限

デフォルトでは、リージョンあたりの同時実行数は1,000（クォータ申請で増加可能）です。
アカウント内のすべての Lambda 関数がこの上限を共有します。

予約済み並行性（Reserved Concurrency）

特定の関数に対して同時実行数の上限を予約します。
この設定には2つの効果があります。

1. 上限の保証: 設定値を超える同時実行は TooManyRequestsException でスロットルされます。
2. 他関数からの保護: 予約した分は他の関数が使えないため、重要な関数への並行数を確保できます。

プロビジョニング済み並行性（Provisioned Concurrency）

事前に Lambda インスタンスを初期化しておくことで、コールドスタートを排除します。
コードの初期化処理（グローバルスコープの処理）があらかじめ完了した状態で待機するため、高スループット・低レイテンシが要求されるAPIバックエンドで有効です。

3-3. レイヤー（Layer）

Lambda レイヤーは、共通の依存ライブラリ・カスタムランタイム・設定ファイルを関数間で共有する仕組みです。

レイヤーの主な用途

• 複数の関数で使う共通ライブラリ（例: AWS X-Ray SDK, Lambda Powertools）をレイヤーとして切り出します。
• 関数コードのサイズを削減でき、コードの更新とライブラリの更新を独立して管理できます。

レイヤーの制約（公式）

3-4. 環境変数とVPCアクセス

環境変数

Lambda の環境変数は、コードを変更せずに設定値を外部化するために使います。
デフォルトでは AWS 管理キーで暗号化されますが、KMS カスタマー管理キー（CMK）を指定して暗号化できます。
機密情報（APIキーやパスワード）は、環境変数よりも AWS Secrets Manager または AWS Systems Manager Parameter Store（SecureString）に保存する方が安全です。

VPCアクセス

Lambda をプライベートサブネット内の RDS や ElastiCache に接続するには、VPC 設定を有効にします。
Lambda 実行ロールに AWSLambdaVPCAccessExecutionRole ポリシーをアタッチすると、Lambda はサブネット内に Elastic Network Interface（ENI）を作成してプライベートリソースにアクセスできます。

VPC 内の Lambda からインターネットに出る場合は、NAT Gateway が必要です。
Lambda に Elastic IP を割り当てることはできないため、固定 IP が必要なシナリオでは NAT Gateway に Elastic IP を付与します。

4. DynamoDB のデータモデリング

4-1. キー設計

DynamoDB のテーブルは、すべてのデータアクセスがキーを通じて行われる キーバリューストア の設計思想に基づいています。

パーティションキー（Partition Key / PK）

データを物理的に分散させるためのキーです。
DVA-C02 で最も重要なのは「高カーディナリティ（High Cardinality）のパーティションキーを選択する」という原則です。

ホットパーティションの例として、status カラム（値が “active”/”inactive” の2種類のみ）をパーティションキーに使うと、特定パーティションにアクセスが集中してスロットリングが発生します。
UUID や UserID のように値の種類が多いカラムを選ぶことで、アクセスが均等に分散されます。

ソートキー（Sort Key / SK）

パーティションキーと組み合わせて複合キーを構成します。
同一パーティション内での並び順を制御し、レンジクエリ（begins_with, between, >, < 等）を効率的に実行できます。

4-2. インデックス（GSI・LSI）

GSI（Global Secondary Index）

元のテーブルとは異なるパーティションキー・ソートキーの組み合わせで検索するためのインデックスです。

LSI（Local Secondary Index）

同じパーティションキーを持ちながら、ソートキーのみ変更するインデックスです。

4-3. Query vs Scan

Query（クエリ）

パーティションキーを指定して、同一パーティション内のアイテムを効率的に検索します。
ソートキーに対する条件式（begins_with, between など）をキー条件式として追加でき、結果をソートキーの昇順・降順で返せます。
消費する Read Capacity Unit（RCU）は 返却されたアイテムのサイズ に基づきます（フィルタ式は後処理のため、スキャンされたサイズで課金）。

Scan（スキャン）

テーブルまたはインデックスの全アイテムを読み取ります。
RCU の消費が大きく、テーブルが大きいほどコストと時間が増大します。
FilterExpression で結果を絞り込めますが、課金はフィルタ前の全スキャン量に基づきます。

試験では「効率的なデータ取得」を問われた場合に Scan ではなく Query を選択する のが正解となるパターンが多く見られます。
どうしてもアクセスパターンが合わない場合は、GSI を追加して Query できる設計に変更することが推奨されます。

4-4. 整合性モデル

DynamoDB は読み取り時に整合性モデルを選択できます。

5. API Gateway の開発

5-1. 統合タイプとLambdaプロキシ

API Gateway から Lambda を呼び出す際、統合タイプとして Lambdaプロキシ統合 と Lambda（非プロキシ）統合 の2種類があります。

Lambdaプロキシ統合（推奨）

クライアントからのリクエスト全体（ヘッダー・クエリ文字列・ボディ・パスパラメータなど）が、構造化された JSON イベントオブジェクトとして Lambda に渡されます。
Lambda からのレスポンスも statusCode・headers・body を含む JSON 形式で返す必要があります。
マッピングテンプレートの設定が不要で、シンプルに実装できます。

Lambda 非プロキシ統合

リクエスト・レスポンスの変換を API Gateway 側でコントロールしたい場合に使います。
Velocity Template Language（VTL）を使ったマッピングテンプレートを定義します。

5-2. マッピングテンプレートとバリデーション

マッピングテンプレート（VTL）

API Gateway のリクエスト統合・レスポンス統合でデータを変換する仕組みです。
例えば、クライアントから受け取った JSON を Lambda が期待する別のフォーマットに変換したり、Lambda のレスポンスをクライアント向けに整形したりできます。

リクエストバリデーション

API Gateway には、リクエストを Lambda へ転送する前にバリデーションを実行する機能があります。

• ボディバリデーション: JSON Schema を定義したモデルと照合します。
• クエリ文字列・ヘッダーバリデーション: 必須パラメータが存在するかチェックします。

バリデーションに失敗すると、Lambda が呼び出される前に API Gateway から 400 Bad Request が返ります。
これにより Lambda の無駄な呼び出しを減らし、コストを最適化できます。

5-3. ステータスコード

メソッドレスポンスと統合レスポンス

API Gateway では、Lambda からのレスポンスをクライアントへ返す際に「統合レスポンス」でステータスコードのマッピングを定義できます。
Lambda プロキシ統合の場合は、Lambda 関数内で statusCode を明示的に設定します。

試験でよく問われる HTTP ステータスコードの区別は以下の通りです。

API Gateway の統合タイムアウトは 最大29秒 です。Lambda のタイムアウト設定が29秒を超えていても、API Gateway からは504が返ります。

6. 疎結合・冪等性・指数バックオフ・DLQ

6-1. 疎結合設計の原則

密結合 vs 疎結合

密結合アーキテクチャでは、サービスAがサービスBを同期的に直接呼び出します。
サービスBが遅延・障害を起こすと、サービスAも影響を受けます。

疎結合アーキテクチャでは、サービス間にメッセージキュー（SQS）やイベントバス（EventBridge）を介在させます。
サービスBが一時的に停止しても、SQS にメッセージが蓄積されるだけで、サービスAは影響を受けずに継続できます。

SQS による非同期化（Point-to-Point）

1つのプロデューサーが SQS キューにメッセージを送信し、1つのコンシューマーが処理します。
Lambda をコンシューマーにする場合、イベントソースマッピングを設定するだけで自動的にポーリング・処理が行われます。

SNS による Fan-Out（Pub/Sub）

1つのプロデューサーが SNS トピックにメッセージを発行すると、サブスクライブした複数のエンドポイント（SQS・Lambda・Email・HTTP など）に同時配信されます。
SNS → 複数 SQS → 複数 Lambda という組み合わせで、スケーラブルな非同期処理パイプラインを構築できます。

6-2. 冪等性（Idempotency）

冪等性とは

同じリクエストを複数回実行しても、1回実行した場合と同じ結果になる性質です。
ネットワークの再試行やメッセージの重複配信が起きる分散システムでは、冪等な処理設計が不可欠です。

冪等性の実現方法

• 冪等トークン（Idempotency Key）: リクエストごとにユニークなキーを付与し、サーバー側で処理済みかどうかを DynamoDB に記録します。
• 条件付き書き込み（ConditionalExpression）: DynamoDB の condition_expression で既存アイテムが存在しない場合のみ書き込む設計。
• Lambda Powertools の Idempotency モジュール: DynamoDB と連携して自動的に冪等性を管理します。

6-3. 指数バックオフ（Exponential Backoff）とジッター

指数バックオフ

API のリクエストが失敗したとき、一定時間待ってリトライします。
リトライのたびに待機時間を指数関数的に増やすことで、過負荷状態のサービスへの集中リトライを避けます。

待機時間 = min(上限時間, 初期待機時間 × 2^リトライ回数)

例えば初期待機時間を100ミリ秒、上限を20秒とすると、リトライ回数ごとに 100ms → 200ms → 400ms → 800ms … と増加します。

ジッター（Jitter）

複数のクライアントが同じタイミングで失敗してリトライすると、再試行のタイミングが重なって再度スロットルを引き起こすことがあります（Thundering Herd 問題）。
ジッターは待機時間にランダム値を加えることで、リトライのタイミングを分散させます。

AWS SDK の標準的なリトライポリシーには指数バックオフとジッターが含まれており、Retry と MaxAttempts の設定で制御できます。

6-4. DLQ（Dead Letter Queue）

DLQ の役割

処理に繰り返し失敗したメッセージを退避させるためのキューまたはトピックです。
本処理のメッセージキューから切り離すことで、失敗メッセージが正常メッセージの処理を妨げないようにします。

Lambda での DLQ 設定

• 非同期呼び出し（S3, SNS 等からの呼び出し）: Lambda 関数の設定で DLQ（SQS または SNS）を指定。デフォルトは2回リトライ後に廃棄されますが、DLQ を設定すると廃棄前に転送されます。
• イベントソースマッピング（SQS）: SQS キュー側の RedrivePolicy で DLQ を設定。maxReceiveCount 回以上受信されたメッセージが自動的に DLQ に移動されます。

7. キャッシュ戦略

キャッシュは読み取りパフォーマンスの向上とデータベース負荷軽減のために使われます。
DVA-C02 では ElastiCache（Redis/Memcached）と API Gateway のキャッシュが主な対象です。

7-1. Write-Through（書き込み貫通）

データを書き込む際、データベースとキャッシュの両方に同時に書き込む パターンです。

特徴

• キャッシュと DB が常に同期されるため、一貫性が高い（Stale データが発生しにくい）
• 書き込みのレイテンシが増加する（DB + キャッシュの両方の書き込みが完了するまで待機）
• 書き込んでも読み取られないデータもキャッシュされるため、キャッシュ容量が無駄になることがあります

7-2. Read-Through（読み取り貫通）

キャッシュに対してデータを要求し、キャッシュミスの場合はキャッシュ自身がDBから取得して補充する パターンです。

特徴

• アプリケーションコードが DB と直接やり取りしないため、シンプルな実装になります
• キャッシュミス発生時（初回や TTL 切れ後）は DB へのアクセスが発生するため、レイテンシが高くなります

7-3. Lazy Loading（遅延読み込み）

読み取り時にキャッシュを確認し、キャッシュミスの場合のみアプリケーションが DB から取得してキャッシュに保存する パターンです。

特徴

• 実際に必要なデータのみキャッシュされるため、キャッシュ容量を効率的に使えます
• キャッシュミス時はキャッシュ確認・DB 読み取り・キャッシュ書き込みの3ステップを経るためレイテンシが高まります
• キャッシュのデータが DB の最新状態と乖離する（Stale データ）リスクがあります。TTL を組み合わせて緩和します

7-4. TTL（Time To Live）

キャッシュに保存されたデータの有効期限を設定する機能です。
TTL が切れたデータは自動的に無効化され、次のアクセス時に DB から最新データを取得してキャッシュが更新されます。

TTL の役割

• Stale データの問題を軽減します（頻繁に変わるデータは短い TTL、ほとんど変わらないデータは長い TTL を設定）
• キャッシュメモリを自動解放し、容量を効率化します

8. SDK/CLI の活用

8-1. AWS SDK

AWS SDK は Python（boto3）・JavaScript/TypeScript・Java・.NET・Go・Ruby・PHP など各プログラミング言語向けに提供されており、AWS サービスを API 経由で操作するためのライブラリです。

認証情報の解決順序（デフォルト認証情報プロバイダーチェーン）

AWS SDK は以下の順序で認証情報を探します。

1. コード内に直接記述した認証情報（非推奨）
2. 環境変数（AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY）
3. ~/.aws/credentials ファイル（aws configure で設定）
4. コンテナ認証情報（ECS タスクロール）
5. EC2 インスタンスメタデータ / ECS タスクロール / IAM ロール

EC2 インスタンスや Lambda 関数に IAM ロールを割り当てると、SDK が自動的に一時認証情報を取得・使用します。
これにより、アクセスキーをコードや環境変数にハードコードする必要がなく、安全なアクセスが可能です。

ページネーション

S3 の list_objects_v2 や DynamoDB の scan のように、結果が大量の場合はページネーション（NextContinuationToken / LastEvaluatedKey 等）を使います。
boto3 の Paginator を利用すると、全ページを自動的にイテレートできます。

8-2. AWS CLI

AWS CLI は AWS SDK のコマンドラインラッパーで、シェルスクリプトや手動操作でのサービス操作に使います。

プロファイル管理

複数の AWS アカウントや IAM ユーザーを切り替える場合は ~/.aws/config と ~/.aws/credentials にプロファイルを定義します。

aws s3 ls --profile my-profile --region ap-northeast-1

--output json / --output table / --output text で出力形式を切り替えられ、スクリプト処理では --query で JMESPath フィルタリングも可能です。

9. SAM によるローカルテスト

9-1. SAM CLI の基本コマンド

AWS SAM（Serverless Application Model）は、サーバーレスアプリケーションの定義・ビルド・デプロイを行う IaC（Infrastructure as Code）フレームワークです。
template.yaml に Lambda・API Gateway・DynamoDB 等のリソースを宣言的に定義できます。

主なコマンド

ローカル実行の例

# テストイベントを使ってローカルでLambdaを実行
sam local invoke MyFunction --event events/test-event.json

# API GatewayをローカルでエミュレートしてHTTPリクエストをテスト
sam local start-api
curl http://localhost:3000/hello

9-2. ユニットテストの統合

SAM テンプレートから Lambda 関数のユニットテストを行う際は、Lambda ハンドラーを直接テストフレームワーク（pytest, Jest 等）で呼び出す方式が基本です。
イベントオブジェクトをテストファイル内でモックとして定義し、ハンドラー関数に渡してアサーションを行います。

sam local invoke はコンテナ上でリアルな Lambda 実行環境を再現するため、ローカルでの統合テストに活用できます。
ただし、RDS や ElastiCache への接続は --docker-network オプションでローカルコンテナネットワークを指定する必要があります。

10. S3 Storage Classes と開発での活用

10-1. ストレージクラス一覧

S3 にはデータのアクセス頻度・耐久性要件・コストに応じた複数のストレージクラスがあります。

10-2. ライフサイクルルール

S3 ライフサイクルルールを使うと、オブジェクトの経過日数に応じてストレージクラスの自動移行やオブジェクトの自動削除を設定できます。

ライフサイクルルールの例

ルール:
- 0日目: Standard（アップロード直後）
- 30日後: Standard-IA に移行
- 90日後: Glacier Flexible Retrieval に移行
- 365日後: 削除

開発でよくある活用シナリオとして、ログファイルを Standard で保存し、一定期間後は Glacier へ移行してコストを削減する設計があります。

11. CertTrend LMS で 400 問チェック

D1「AWSサービスでの開発」のキー概念を一通り学んだら、実際に問題を解いて定着を確認しましょう。
CertTrend LMS の DVA-C02 コースでは、D1 から D4 まで400問を学習モード・本番形式（65問・130分・720点換算）で演習できます。

LMS での学習のコツ

• D1 は127問（32%）と最大配点ドメインです。まず D1 のみに絞った演習モードで弱点を洗い出してから、他ドメインに進むのが効率的です。
• Lambda のイベントソースマッピング・DynamoDB のキー設計・疎結合のシナリオ問題は複数回解いて体に染み込ませることを推奨します。
• 間違えた問題は解説の「誤答理由」まで確認し、なぜその選択肢が誤りなのかを言えるようになるまで繰り返しましょう。

12. 実務で深掘り — D1 関連の本番運用記事

DVA-C02 D1 で学んだサーバーレス・疎結合・キャッシュの概念を実務レベルで深く理解したい方は、以下の本番運用記事もあわせてご覧ください。