AWS SAP-C02 D2 新規ソリューション設計（2025年最新）｜DR4戦略・RTO/RPO・サーバーレス・コスト最適化

目次

1. はじめに — D2「新規ソリューションの設計」とは

本記事は「AWS SAP-C02試験対策」シリーズの Vol2 です。
シリーズ全体像は Vol0 ロードマップ を、組織的複雑性（マルチアカウント・ハイブリッドネットワーク）は Vol1 組織的複雑性への設計 をお読みください。

ここから扱うのは第2ドメイン D2「Design for New Solutions（新規ソリューションの設計）」 です。
出題比率は 29%・87問 と全4ドメイン最大で、試験合格に直結する最重要領域です。
Associate レベル（SAA-C03）と最も大きく異なるのは、単一サービスの使い方を問うのではなく、複数サービスを組み合わせてゼロから設計するトレードオフ判断 を問う点です。
「RTO をどこまで縮めるかによってコストはどう変わるか」「サーバーレスとコンテナをどう使い分けるか」という設計判断軸が Professional 帯の核心です。

この記事（Vol2）で得られること

  • D2の出題範囲と Professional 帯の設計思考（§1〜§2）
  • 事業継続性の設計原則 — Multi-AZ/Multi-Region の使い分け（§3）
  • DR戦略4パターン（RTO/RPO×コストのトレードオフ）（§4）
  • サーバーレス/コンテナ/EC2の選択基準とイベント駆動設計（§5）
  • データベース選定 — Aurora/RDS/DynamoDB/ElastiCache の使い分け（§6）
  • コスト最適化設計（Reserved/Savings Plans/Spot/Compute Optimizer）（§7）
  • セキュリティ統制の設計（KMS/VPC/WAF/Shield）（§8）
  • ハイブリッド・移行設計（Direct Connect/DMS/Snow Family）（§9）
  • パフォーマンス設計（Auto Scaling/CloudFront/Route 53）（§10）

1-1. D2の出題範囲と頻出サービス

D2 ではゼロから新規ワークロードを設計する観点で問われます。
300問の実測データから D2 の頻出サービスを整理すると、Lambda(184)・VPC(179)・Aurora(53)・DynamoDB(51)・EventBridge(54)・SQS(50) が高頻度で登場します。
「どのサービスを単体で使うか」ではなく「これらを組み合わせてどう設計するか」が問われる点に注意してください。

テーマ代表サービス・概念
事業継続性・高可用性Multi-AZ / Multi-Region / DR戦略4種 / RTO・RPO
サーバーレス・イベント駆動Lambda / DynamoDB / EventBridge / SQS / SNS / API Gateway
データベース選定Aurora Global / RDS Multi-AZ / DynamoDB グローバルテーブル / ElastiCache
コスト最適化Reserved Instances / Savings Plans / Spot / Compute Optimizer
セキュリティKMS / VPC / WAF / Shield / IAM
ハイブリッド・移行Direct Connect / VPN / Transit Gateway / DMS / Snow Family
パフォーマンスAuto Scaling / CloudFront / ALB・NLB / Route 53
Professional帯の設計思考（SAA-C03との違い）

  • トレードオフの定量化: RTO を 8時間 → 15分に短縮するためのコスト増加を試算して判断する
  • 複数サービスの組み合わせ: SQS + Lambda + DynamoDB + EventBridge を組み合わせた非同期処理を一枚の設計図として描ける
  • 非機能要件の競合解消: コスト最適化とゼロ RTO という相反する要件を「Pilot Light で折り合い」などと説明できる
  • Bloom L4-L6: 「正しいのはどれか」(L1) ではなく「この要件なら何を選ぶか・なぜか」(L4-L6) の問題が中心

2. 新規設計の判断フレームワーク

新規ソリューション設計の試験問題は、要件（機能・非機能）→ 設計判断 → サービス選択 という流れで解きます。
まず要件を4つの非機能軸で整理し、それぞれの設計判断を積み重ねる手法が Professional 帯では有効です。

設計軸問われる判断主要サービス
可用性・信頼性SLA目標・障害範囲・RTO/RPOMulti-AZ / Multi-Region / Auto Scaling
パフォーマンスレスポンスタイム・スループットCloudFront / ElastiCache / Aurora
セキュリティ暗号化・アクセス制御・境界防御KMS / IAM / VPC / WAF
コスト利用量予測・価格モデル選択Reserved / Spot / Savings Plans

これら4軸の要件は互いに競合するのが Professional 帯らしい問題の特徴です。
「高い可用性を求めると Multi-Region になるためコストが増大する」「Spot を使うとコストは下がるが突然中断される」という競合を正しく解消する設計判断が問われます。

3. 事業継続性と高可用性 — Multi-AZ/Multi-Region設計

3-1. アベイラビリティゾーン（AZ）による可用性設計

1つのリージョン内に複数の AZ を使う Multi-AZ 設計は、ハードウェア障害・電源障害・ネットワーク障害などのインフラレベルの障害から守ります。
RDS Multi-AZ はスタンバイ AZ へ自動フェイルオーバー（通常1〜2分）し、EC2 + Auto Scaling Group は複数 AZ にインスタンスを分散して単一 AZ 障害に耐えます。
「AZ障害に耐えるだけでよいか、リージョン全体の障害も想定するか」が設計の分岐点です。

構成保護範囲コスト目安代表ユースケース
Single-AZAZ 内冗長のみ低開発・テスト環境
Multi-AZAZ 障害耐性中本番の標準構成
Multi-Regionリージョン障害・地理的DR高金融・医療・グローバルサービス

3-2. Multi-Region 設計の判断基準

リージョン全体の障害（大規模自然災害・大規模サービス障害）に備えるには Multi-Region が必要です。
ただし Multi-Region は構築・運用コストが大幅に増大するため、RTO と RPO の目標値 を設定したうえで本当に必要かを判断します。

Multi-Region を採用する主な理由は次の3つです。

  1. DR（Disaster Recovery）: RTO 分単位・RPO ゼロに近い要件
  2. グローバル低レイテンシ: 世界各地のユーザーへの応答時間最適化（CloudFront・Global Accelerator）
  3. データ主権: EU・中国等の規制でデータを特定リージョンに留める場合でも、レプリケーション先としての別リージョン確保

3-3. RTO と RPO の定義

  • RTO（Recovery Time Objective）: 障害発生から業務再開までの許容時間
  • RPO（Recovery Point Objective）: 障害発生時点から「どこまで遡ってデータを失ってよいか」の許容時間

例として「RTO 4時間・RPO 1時間」は「4時間以内に復旧し、失うデータは最大1時間分まで許容する」という要件です。
この2つの目標値が DR 戦略の選択を決定づけます。

DR戦略4種選定フロー
DR戦略4種 RTO/RPO×コスト選定フロー

4. DR戦略4パターン — RTO/RPO設計判断

AWS Well-Architected Framework は DR 戦略を4段階に分類しています。
RTO と RPO が短くなるほどコストが上昇するトレードオフを正確に把握することが SAP-C02 の合格に直結します。

4-1. Backup and Restore（バックアップと復元）

最もシンプルで低コストな DR 戦略です。
データを定期的にバックアップ（S3・AWS Backup）し、障害発生時にバックアップから新たに環境を構築して復旧します。

項目特性
RTO数時間〜1日（インスタンス起動・データ復元に時間を要する）
RPOバックアップ間隔に依存（1時間〜1日）
コスト最も低い（スタンバイインスタンス不要）
適用場面社内システム・開発環境など SLA 要件が緩い用途

復旧手順を Runbook として文書化・自動化（CloudFormation/AWS Backup）しておくことで RTO を短縮できます。
「手順書がなければ復旧に丸1日かかる」というシナリオで Backup & Restore の限界が試験で問われます。

4-2. Pilot Light（パイロットライト）

本番に必要な最小限のコアコンポーネントだけを DR リージョンで常時稼働させ、障害時に残りを素早く起動する戦略です。
名前は「常にパイロットライト（種火）だけ灯しておく」ことに由来します。

項目特性
RTO数十分（主要コンポーネントはすでに起動済みのため）
RPO分単位（DB のリアルタイムレプリケーション）
コスト低〜中（コアコンポーネント分のみ常時費用）
適用場面金融・EC など中程度の可用性要件

典型的な構成は「DR リージョンで RDS リードレプリカのみ常時起動し、フェイルオーバー時に Standalone へ昇格 + EC2 Auto Scaling で Web/App 層を展開」です。
試験では「Pilot Light における DB の扱い（リードレプリカ常時稼働）」が頻出です。

4-3. Warm Standby（ウォームスタンバイ）

本番と同等のフルアーキテクチャを DR リージョンに縮小構成で常時稼働させます。
障害時はスケールアウト（インスタンス数・サイズ増加）によって本番同等にします。

項目特性
RTO分単位（スケールアウト時間のみ）
RPO分単位〜秒単位（DB リアルタイム同期）
コスト中〜高（DR 環境を常時小規模で稼働）
適用場面RTO が数十分以内に求められる重要ビジネスシステム

Warm Standby では Route 53 フェイルオーバールーティング と Amazon ELB を組み合わせて DR リージョンへのトラフィック切り替えを自動化します。

4-4. Multi-Site Active-Active（マルチサイト）

複数リージョンで本番相当のトラフィックを同時処理します。
障害発生時は残リージョンが全トラフィックを引き受けるため、理論上 RTO・RPO ともにゼロに近い値を実現できます。

項目特性
RTOほぼゼロ（DNS フェイルオーバーの時間のみ）
RPOゼロ（リアルタイム同期）
コスト最も高い（複数リージョンで本番全量稼働）
適用場面銀行・決済・医療など絶対ダウン不可のシステム

Aurora Global Database・DynamoDB グローバルテーブル・Amazon S3 クロスリージョンレプリケーションなどがデータ層の同期を担います。

4-5. DR戦略の選択判断フロー

試験ではシナリオを読んで適切な DR 戦略を選ぶ問題が出題されます。
以下のフローで判断を整理してください。

  1. RTO が 1時間以上許容できる → Backup & Restore で十分
  2. RTO が 30分〜1時間・コスト制約がある → Pilot Light
  3. RTO が 数分〜30分 → Warm Standby
  4. RTO が ゼロに近い・コスト制約なし → Multi-Site Active-Active
試験頻出: DR コスト比較の罠

  • 「コスト最小で RTO 1時間以内」→ Pilot Light（Backup は RTO 要件を満たせない可能性）
  • 「RPO 0」→ Active-Active のみ（他3戦略では何らかのデータロスがある）
  • 「AWS Elastic Disaster Recovery (DRS)」は継続的レプリケーションにより RTO 分単位、RPO 秒単位を安価に実現

5. サーバーレスとイベント駆動アーキテクチャ

5-1. Lambda・ECS・EC2 の選択基準

新規ワークロードを設計する際に最初の判断となるのが、実行環境の選択です。
SAP-C02 では「どのシナリオでどれを選ぶか」の設計判断が頻出です。

実行環境最適シナリオ考慮事項
Lambdaイベント駆動・短時間処理・スパイク負荷最大実行時間15分・コールドスタート・ステートレス前提
ECS Fargateコンテナ化・中長時間処理・サーバー管理不要Spot 対応可・Spot 中断への設計が必要
EC2特殊ハードウェア・既存ライセンス・GPU・長時間インスタンス管理・Auto Scaling 設計が必要
App RunnerWebアプリを最小設定でデプロイフルマネージド・スケーリング自動

Lambda は「起動時間に制約がなく、処理が15分以内に収まり、リクエスト数が予測困難なスパイク型」のシナリオで最強の選択肢です。
「処理時間が 15分を超える可能性がある」シナリオでは Lambda は不適切で、Step Functions + Lambda の組み合わせか、ECS/Fargate が正解になります。

5-2. イベント駆動アーキテクチャの設計

新規ソリューション設計で重要なのが、疎結合なイベント駆動パターン です。
SAP-C02 では SQS・SNS・EventBridge・Kinesis の使い分けが頻出です。

サービス役割選択理由
SQSキュー（Point-to-Point）順序保証（FIFO）・DLQ・可視性タイムアウト・ポーリング
SNSPub/Sub（1:N ファンアウト）複数サブスクライバーへの同時配信
EventBridgeイベントバス（ルーティング・フィルタリング）AWS サービス間・SaaS 連携・スケジュール実行
Kinesis Data Streamsストリーム処理（高スループット）リアルタイム・シーケンシャル・複数コンシューマー

典型的なイベント駆動設計パターンとして、「API Gateway → Lambda → SQS → Lambda（非同期処理）→ DynamoDB → EventBridge（後続処理トリガー）」という流れが試験で問われます。
「注文処理後にメール通知・在庫更新・ポイント付与を並行して行う」というシナリオでは SNS ファンアウトが適切です。

5-3. Lambda の耐障害設計

Lambda を使ったサーバーレスアーキテクチャでは、以下の耐障害設計が重要です。

  • DLQ（Dead Letter Queue）: 処理失敗したイベントを SQS または SNS へ退避
  • 同時実行制限: アカウント全体の上限（デフォルト 1000）を考慮した予約同時実行設定
  • 冪等性: 同じイベントが複数回届いても同じ結果になる設計（DynamoDB の条件付き書き込み等）
  • タイムアウト設計: 依存サービスのレイテンシを考慮した適切なタイムアウト値

6. データベース選定 — Aurora/RDS/DynamoDB/ElastiCache

6-1. RDS vs Aurora の選択基準

Amazon RDS と Amazon Aurora はどちらもリレーショナルデータベースですが、ユースケースと可用性要件によって使い分けます。

項目RDSAurora
対応エンジンMySQL/PostgreSQL/Oracle/SQL Server/MariaDBMySQL互換 / PostgreSQL互換
ストレージ冗長AZ 単位（EBS）3 AZ × 2 コピー（計6コピー）
読み取りレプリカ最大5台（リージョン内）最大15台（グローバル対応）
フェイルオーバー1〜2分通常30秒以下
コスト低やや高（性能・可用性との交換）
グローバルDBなしAurora Global Database（< 1秒レプリケーション）

「Oracle ライセンスを持ち込む」「MariaDB を使いたい」という場合は RDS、「高可用性・グローバル展開・高スループットのリレーショナルDB」なら Aurora を選択します。

6-2. DynamoDB — NoSQL の設計判断

DynamoDB は RTO ほぼゼロ・RPO ほぼゼロを実現できる NoSQL マネージドデータベースです。

機能内容
グローバルテーブル複数リージョンに自動レプリケーション（Active-Active）・RPO 秒単位
DAX（DynamoDB Accelerator）インメモリキャッシュ・読み取りレイテンシをマイクロ秒に短縮
オンデマンドキャパシティスパイク負荷に自動スケール（プロビジョンド vs オンデマンドの使い分け）
TTL有効期限付きデータの自動削除（セッション・キャッシュ）

「RDB か NoSQL か」の判断は、データ構造が固定でトランザクション整合性を必要とする場合は RDB を選択します。一方、スキーマが流動的でスケールの予測が難しい場合は DynamoDB が適切です。

6-3. ElastiCache — キャッシュ戦略

キャッシュを導入することでデータベースの負荷を軽減し、アプリケーションのレスポンスタイムを短縮します。

エンジン適用場面
Redisセッション管理・Pub/Sub・Sorted Set・永続化必要な場合
Memcachedシンプルなキャッシュ・マルチスレッド・高スループット

試験では「DB 読み取り負荷が高い」「セッション情報を水平スケール可能な形で共有したい」というシナリオで ElastiCache Redis が正解になります。

7. コスト最適化アーキテクチャ

7-1. 購入オプションの選択

EC2 および関連サービスの購入オプションは、ワークロードの予測可能性によって使い分けます。

購入オプション割引率適用条件
オンデマンド0%（基準）短期・予測不能な負荷
Reserved Instances（1年）最大40%1年間継続利用が確実なベースライン
Reserved Instances（3年）最大60%3年間継続利用が確実なコアシステム
Savings Plans（Compute）最大66%柔軟なコミットメント（Lambda/Fargate対応）
Spot Instances最大90%中断許容・バッチ・CI/CD
Dedicated Hosts—ライセンス持ち込み・コンプライアンス要件

典型的なコスト最適化設計は「ベースライン負荷を Reserved または Savings Plans でカバー + スパイクを Spot/オンデマンドで対応」という組み合わせです。

7-2. Compute Optimizer と right-sizing

AWS Compute Optimizer は機械学習を使って EC2・Lambda・ECS Fargate・EBS の利用状況を分析し、right-sizing（適切なサイズへの変更）を推奨します。
「EC2 インスタンスが過剰にプロビジョニングされている」というシナリオでは、Compute Optimizer の推奨に従ってダウンサイズすることがコスト削減の第一手です。

7-3. ストレージのコスト最適化

S3 のストレージクラス最適化は、データのアクセスパターンに基づいて設計します。

ストレージクラス特性コスト
S3 Standard頻繁アクセス・低レイテンシ高
S3 Intelligent-Tieringアクセス頻度不明・自動階層化中
S3 Standard-IA低頻度アクセス・取得コストあり低
S3 Glacier Instant Retrievalアーカイブ・ms 取得極低
S3 Glacier Deep Archive長期保存・12時間以内取得最低

S3 ライフサイクルポリシーを設定して、作成後 30日で Standard-IA、90日で Glacier Instant に移行する設計が試験頻出です。

8. セキュリティ統制 — 要件ベースの設計

8-1. 暗号化設計

データの暗号化要件を「保管中（at rest）」と「転送中（in transit）」に分けて設計します。

対象サービス・手法
保管中のデータ（S3/EBS/RDS）KMS マスターキー（CMK）・SSE-S3・SSE-KMS
転送中のデータTLS/HTTPS・ACM（証明書管理）・VPN / Direct Connect
Lambda 環境変数KMS で暗号化して SSM Parameter Store 経由で参照
Secrets ManagerDB 認証情報・API キーのローテーション自動化

KMS の エンベロープ暗号化（CMK でデータキーを暗号化 → データキーでデータを暗号化）は SAP-C02 で頻出の概念です。

8-2. VPCセキュリティ設計

新規ワークロードの VPC 設計では、以下の多層防御が標準です。

  1. パブリック/プライベートサブネット分離: Webサーバーはパブリック（ELB のみ）、App/DB はプライベート
  2. セキュリティグループ: インスタンス単位の「許可リスト」（デフォルト拒否）
  3. NACL: サブネット単位のステートレスフィルタリング（追加防御として）
  4. PrivateLink: AWS サービスや SaaS へのプライベート接続（インターネットを経由しない）
  5. VPC Flow Logs: トラフィックログ → Athena 分析

WAF と AWS Shield を CloudFront・ALB・API Gateway と組み合わせることで、DDoS 攻撃・SQL インジェクション・XSS などの外部脅威を防御します。

9. ハイブリッドアーキテクチャと移行設計

9-1. ハイブリッド接続の選択

オンプレミスと AWS を接続する方法の使い分けは SAP-C02 の D2 でも頻出です。

接続方式帯域幅安定性コスト適用場面
Site-to-Site VPN最大1.25 Gbpsインターネット経由（変動）低補助・低帯域・短期
Direct Connect1/10/100 Gbps専用線（安定）高本番・高帯域・長期
Direct Connect + VPN専用線+暗号化高高セキュリティ要件が高い場合

複数拠点を持つ場合は AWS Transit Gateway でハブ&スポーク型の接続を集約します。
Transit Gateway を使うと VPC 間・VPN 間・Direct Connect 間のルーティングを単一の拠点で管理できます。

9-2. データ移行戦略

新規ソリューション設計に伴うデータ移行の選択基準は、データ量・ダウンタイム許容・データ種別 で決まります。

移行方式比較図
移行3種(Rehost/Replatform/Refactor)コスト×工数比較

移行6Rアプローチは既存ワークロードを「どの方法で AWS に移すか」の判断基準です。
D2 の新規ソリューション設計との関連では特に以下が重要です。

移行方式内容工数価値
Rehost（Lift & Shift）そのまま EC2 へ移行低速度優先・最初のステップ
Replatform最小限の改修（RDS 化・マネージドサービス活用）中コスト・運用改善
Refactor（Re-architect）サーバーレス・マイクロサービスへ再設計高長期的価値最大

D2「新規ソリューション設計」の文脈では Refactor が最も重要で、「なぜ今回は Refactor が最適か・Rehost ではダメなのか」を説明できるかが問われます。

9-3. データ移行ツールの選択

ツール用途
AWS DMS（Database Migration Service）稼働中 DB のオンライン移行・異種DB間移行
AWS SCT（Schema Conversion Tool）Oracle→Aurora 等のスキーマ変換
Snow Family（Snowball Edge）オフライン大量データ転送（数十 TB〜 PB）
AWS DataSyncNFS/SMB → S3/EFS への継続的データ同期
Transfer FamilySFTP/FTPS/FTP → S3・EFS への移行

「ネットワーク帯域が限られ 80TB のデータを移行する」 → Snowball Edge、「稼働中 Oracle DB を Aurora PostgreSQL へ移行」 → DMS + SCT、「NAS 上のファイルを S3 へ継続同期」 → DataSync が典型的な正解パターンです。

10. パフォーマンス設計 — Auto Scaling/CloudFront/Route 53

10-1. Auto Scaling の設計

EC2 Auto Scaling はスケーリングポリシーの選択が試験頻出です。

ポリシー種別動作適用場面
ターゲット追跡スケーリングCPU 60%等の目標値を維持するよう自動調整最も一般的・推奨
ステップスケーリングCloudWatch アラームの閾値に応じた段階的増減細かな制御が必要な場合
スケジュールスケーリング時刻指定での増減夜間縮小・月末スパイク対策
予測スケーリングML による将来負荷予測に基づく事前スケール定期的なスパイクがある場合

10-2. CloudFront とグローバル配信

Amazon CloudFront はコンテンツを エッジロケーション（200以上の拠点）にキャッシュして配信し、オリジンの負荷とレイテンシを同時に削減します。

  • 静的コンテンツ: S3 + CloudFront で高速・低コスト配信
  • 動的コンテンツ: ALB + CloudFront（キャッシュヘッダー制御）
  • API のグローバル高速化: CloudFront + API Gateway + Lambda（Lambda@Edge）

AWS Global Accelerator は Anycast IP を使って最寄りの AWS エッジから AWS バックボーンネットワーク経由でルーティングし、レイテンシとパケットロスを削減します。
「グローバルユーザー向け Web アプリの応答速度改善」では CloudFront、「UDP・TCP プロトコルのグローバル高速化」では Global Accelerator が正解です。

10-3. Route 53 によるトラフィック制御

Route 53 のルーティングポリシーの使い分けは D2 で頻出です。

ルーティング動作用途
フェイルオーバープライマリ障害時にセカンダリへ切り替えActive-Passive DR
加重ルーティング複数レコードに重みを付けて分散Blue/Green デプロイ
レイテンシルーティングレイテンシが最も低いリージョンへ誘導マルチリージョン低レイテンシ
地理的ルーティング発信元の国・地域に基づいてルーティングコンプライアンス・データ主権
マルチバリュー回答最大8台のアドレスをランダム返答簡易ロードバランシング
よく出る D2 設計判断パターン

  • 「コスト最小かつ高可用性」 → Spot + ALB + Auto Scaling（中断許容の設計が必要）
  • 「グローバルユーザーへの低レイテンシ読み取り」 → DynamoDB グローバルテーブル or Aurora Global Database
  • 「リアルタイム処理・数千 TPS」 → Kinesis Data Streams + Lambda（SQS FIFO は高スループット不向き）
  • 「オンプレ Oracle → AWS 移行・無停止」 → DMS + SCT（最初はリードレプリカとして稼働、カットオーバー後にプロモート）
  • 「セキュリティ要件で S3 データを暗号化必須」 → SSE-KMS（顧客管理キー CMK で監査証跡も確保）

11. デプロイ戦略 — Blue/Green・カナリア・ローリング

D2 の「デプロイ戦略」も重要なテーマです。新規ソリューションのリリース方法による RTO・リスクのトレードオフを把握してください。

戦略仕組みリスク切り戻し
Blue/Green新旧2環境を並行稼働、Route 53 で切り替え低（問題があれば即切り戻し）即時（DNS 切り替え）
カナリア新バージョンへ徐々にトラフィック移行低（少量で問題検出）Route 53 加重変更
ローリング既存インスタンスを順次更新中（新旧混在期間あり）困難（ロールバック複雑）
ImmutableAuto Scaling で全台新バージョン起動後に切り替え低スケールイン

AWS CodeDeploy が EC2/Lambda へのデプロイ戦略（Blue/Green・カナリア・ローリング）を標準サポートしています。
「新バージョンのデプロイ中に問題を検出したら即座にロールバックしたい」→ Blue/Green が最適、「ECS/Lambda への段階的デプロイ」→ CodeDeploy のカナリアデプロイが正解です。

12. CertTrend LMS で300問チェック

D2「新規ソリューションの設計」の理解を問題演習で定着させましょう。
CertTrend LMS には SAP-C02 全300問（D2: 87問）が収録されています。

CertTrend LMS で SAP-C02 D2 を演習する →

D2 は「設計判断・トレードオフ評価」問題が大半です。
LMS では「なぜこの選択肢が正しいか」を解説で確認し、設計判断の根拠を言語化できるまで繰り返し解くことをおすすめします。

13. 実務で深掘り — D2 関連本番運用記事

SAP-C02 の D2 試験対策で学んだ設計原則を、実際の本番運用レベルで理解するための参考記事です。

【本番運用】AWS Resilience Hub / FIS / Backup — RTO/RPO設計と実践 →
【本番運用】Lambda / API Gateway / Step Functions — サーバーレス本番運用 →
【本番運用】Macie / Inspector / Network Firewall — セキュリティ統制設計 →
【本番運用】DMS / SCT / DataSync — データ移行設計の実践 →

次のドメインは D3「Continuous Improvement for Existing Solutions（既存ソリューションの継続的改善）」です。
本番システムの運用改善・コスト最適化・可観測性向上を扱う Vol3 継続的改善 に続きます。

移行と近代化（6R戦略・MGN・DMS）は Vol4 移行と近代化の加速 で解説しています。

シリーズ全体の学習ロードマップは Vol0 SAP-C02 試験対策ロードマップ をご参照ください。

AWSの最新記事8件