AIAI Agent Dev Labaiagentdev-lab.com
3分適性診断 →

STEP 1 · 学習

SAP-C02 学習ソリューションアーキテクト – プロフェッショナル

公式の出題分野ごとに要点を読み、各分野の最後にある「この分野を練習する」でその分野だけの問題を解きます。分野の比率が大きいほど本試験での出題が多くなります。

01

複雑な組織に対応するソリューションの設計

Design Solutions for Organizational Complexity

26%

学習目標

  • 多数の VPC・オンプレミス拠点を Transit Gateway・Direct Connect・Site-to-Site VPN・PrivateLink で接続し、Route 53 Resolver でハイブリッド DNS を設計できる
  • Organizations・Control Tower・SCP・RCP・委任管理者で、複数アカウントの統制とログの集約を設計できる
  • IAM Identity Center と外部 ID プロバイダー、クロスアカウントのロール、KMS のキーポリシーで、組織横断のアクセスと暗号化を設計できる
  • RPO/RTO に応じた DR（Elastic Disaster Recovery を含む）と、タグ・Cost Categories・購入オプションによるコストの見える化を設計できる

要点

  • VPC が数十以上あるなら、ピアリングの網の目ではなく Transit Gateway のハブ＆スポーク。ルートテーブルを分けると、本番と開発の VPC 同士は通信させず、共有サービス VPC にだけ通す、といった分離ができる（ピアリングは推移的ルーティングをしない）。
  • オンプレミスとの接続：安定した帯域と低遅延が必要なら Direct Connect（複数のロケーションに2本以上で冗長化）、すぐに使いたい・バックアップ回線なら Site-to-Site VPN。複数リージョンの VPC には Direct Connect ゲートウェイ経由で接続する。
  • ハイブリッド DNS：AWS からオンプレミスの名前を引くには Route 53 Resolver のアウトバウンドエンドポイントと転送ルール、オンプレミスから AWS のプライベートホストゾーンを引くにはインバウンドエンドポイント。転送ルールは RAM で他のアカウントと共有できる。
  • 別の VPC・別のアカウントにある1つのサービスだけを公開するなら PrivateLink（エンドポイントサービス）。CIDR が重複していても使え、VPC 全体を接続しない。
  • マルチアカウント：Control Tower のランディングゾーンでログアーカイブ・監査用のアカウントを分け、組織の CloudTrail 証跡と Config アグリゲーターで集約する。GuardDuty・Security Hub はセキュリティ用アカウントを委任管理者にして全アカウントを一元管理する。
  • SCP はアカウントの IAM プリンシパルが使える権限の上限、RCP はリソース側（S3・KMS など）へのアクセスの上限を組織全体で決める。どちらも権限を与えるものではない。
  • コストの見える化：コスト配分タグ（タグポリシーで値を統一）と Cost Categories で事業部ごとに費用を割り当て、Budgets と Cost Anomaly Detection で予算超過や異常を通知する。一括請求では Savings Plans・RI の割引が組織内で共有される。

業務での使いどころ

  • 総務グループ会社 8社の約 40 アカウントを Control Tower で整備し、各社の VPC を Transit Gateway に集約。本社のデータセンターとは2拠点の Direct Connect で接続する。
  • 経理タグポリシーで「CostCenter」タグの値を統一し、Cost Categories で事業部別の費用を毎月配賦。予算の 80% で部門長に通知する。
  • 営業販売代理店のアカウントに、受注 API だけを PrivateLink で公開し、社内のネットワーク全体には接続させない。

公式のタスクステートメント（英語）

  • 1.1 ネットワーク接続戦略を設計する。
  • 1.2 セキュリティコントロールを規定する。
  • 1.3 信頼性とレジリエンスに優れたアーキテクチャを設計する。
  • 1.4 マルチアカウント AWS 環境を設計する。
  • 1.5 コスト最適化と可視化の戦略を決定する。

公式の学習リソース

この分野を練習する（78問）→次の分野を読む ↓
02

新しいソリューションのための設計

Design for New Solutions

29%

学習目標

  • CloudFormation（StackSets・変更セット）・CDK・CodePipeline・CodeDeploy で、ロールバックできるデプロイ戦略（ブルー/グリーン・カナリア・ローリング）を設計できる
  • マルチ AZ・マルチリージョンのデータ複製（Aurora Global Database・DynamoDB グローバルテーブル・S3 レプリケーション）と DR テストを設計できる
  • 最小権限、WAF・Shield Advanced・Network Firewall、暗号化と鍵管理、パッチ管理を要件から組み合わせられる
  • 目的別データベース、キャッシュ、エッジ、疎結合の構成と購入オプションで、性能とコストの目標を両立できる

要点

  • デプロイ：インフラはコード化（CloudFormation・CDK）し、複数アカウント・リージョンへの同じ構成の展開は StackSets。本番の変更は変更セットで差分を確認してから実行する。
  • ブルー/グリーンは新旧の環境を並べて切り替え、問題があればすぐ戻せる。カナリアは一部の通信だけを新しい版に流して様子を見る。データベースのエンジン更新には RDS ブルー/グリーンデプロイが使える。
  • マネージドサービスに任せる：パッチ適用やスケーリングの運用負荷を減らすため、EC2 上の自前運用より RDS・Aurora・Fargate・Lambda などを優先する、という判断がよく問われる。
  • 事業継続：RPO/RTO を満たす複製方式を選ぶ。リレーショナル DB のリージョン間は Aurora Global Database、NoSQL のマルチリージョン書き込みは DynamoDB グローバルテーブル、オブジェクトは S3 レプリケーション（期限付きの複製なら S3 RTC）。
  • 大規模な Web アプリの攻撃対策：CloudFront＋AWS WAF（マネージドルール・レートベースのルール）＋Shield Advanced。VPC 内の通信の検査は Network Firewall、サードパーティの仮想アプライアンスは Gateway Load Balancer。
  • 信頼性：疎結合（SQS・SNS・EventBridge・Step Functions）、再試行とべき等性、サービスクォータの事前引き上げ。Route 53 のルーティング（レイテンシー・位置情報・フェイルオーバー・加重）を要件で選ぶ。
  • 性能とコスト：目的別データベース（DynamoDB・ElastiCache・OpenSearch・Timestream・Neptune など）を用途で選ぶ。Graviton、Savings Plans、スポット、Auto Scaling の予測スケーリングで、性能を保ちながら費用を下げる。

業務での使いどころ

  • 営業全国の代理店向け受注サイトを CloudFront・WAF・ALB・Aurora で新規構築し、CodePipeline からブルー/グリーンでリリース。問題があれば数分で旧版に戻す。
  • 経理新しい経費精算システムで、東京の Aurora を大阪に Aurora Global Database で複製し、四半期に一度リージョン切り替えの DR テストを行う。
  • 総務入退室ログの検索用に OpenSearch Service、在席状況のキャッシュに ElastiCache を採用し、目的に合わせてデータベースを使い分ける。

公式のタスクステートメント（英語）

  • 2.1 ビジネス要件を満たすデプロイ戦略を設計する。
  • 2.2 事業の継続性を確保するソリューションを設計する。
  • 2.3 要件に基づいてセキュリティコントロールを決定する。
  • 2.4 信頼性の要件を満たす戦略を策定する。
  • 2.5 パフォーマンス目標を満たすソリューションを設計する。
  • 2.6 ソリューションの目標と目的を達成するためのコスト最適化戦略を決定する。

公式の学習リソース

この分野を練習する（87問）→次の分野を読む ↓
03

既存のソリューションの継続的な改善

Continuous Improvement for Existing Solutions

25%

学習目標

  • CloudWatch（メトリクス・ログ・Synthetics）、EventBridge、Systems Manager Automation で、監視・アラート・自動修復を整備できる
  • Config ルールと修復アクション、Security Hub、Access Analyzer、Secrets Manager で、既存環境のセキュリティを継続的に改善できる
  • ボトルネックを特定し、キャッシュ・リードレプリカ・エッジ・インスタンスの見直しで性能を改善できる
  • 単一障害点の除去、自己修復、障害注入テスト（FIS）と、Compute Optimizer・Trusted Advisor・S3 Storage Lens によるコスト改善を進められる

要点

  • 運用の改善は「見える化→アラート→自動修復」。CloudWatch のアラームや EventBridge のルールから Systems Manager Automation のランブックを実行して、決まった手順の復旧を自動化する。
  • 手作業のデプロイや設定変更が障害の原因なら、CI/CD とコード化、変更セットでのレビュー、ローリングやブルー/グリーンへの切り替えを提案する。
  • セキュリティの継続的な改善：Config ルールで設定のずれを検出し、修復アクションで自動的に直す。Security Hub で検出結果を集約し、Access Analyzer で外部に公開されたリソースや使われていない権限を見つける。
  • ハードコードされた認証情報は Secrets Manager（自動ローテーション）や Parameter Store に移す。EC2 への SSH の踏み台は Session Manager に置き換えると、ポートを開けずに操作ログも残せる。
  • 性能：まずメトリクスでボトルネック（CPU・IOPS・DB 接続・ネットワーク）を特定してから対策する。読み取りの多い DB はキャッシュとリードレプリカ、世界の利用者には CloudFront や Global Accelerator。
  • 信頼性：単一 AZ・単一インスタンス・単一回線などの単一障害点をなくす。AWS FIS で障害を意図的に起こし、復旧の手順と仕組みが働くかを本番に近い環境で確かめる。
  • コスト：Compute Optimizer で過大なリソース、Trusted Advisor でアイドル資源、S3 Storage Lens で不要なデータを見つける。NAT ゲートウェイ経由の転送や AZ 間通信などのネットワーク費用も見直す。

業務での使いどころ

  • 総務社内ポータルの EC2 が週に一度メモリ不足で止まる。CloudWatch エージェントでメモリを監視し、閾値で Systems Manager Automation が再起動とログ収集を自動で行う。
  • 経理会計システムの設定にデータベースのパスワードが平文で書かれていた。Secrets Manager に移して自動ローテーションし、Config ルールで再発を検出する。
  • 営業見積システムの応答が遅い。X-Ray でデータベースの呼び出しがボトルネックと分かり、ElastiCache の導入で応答を改善する。

公式のタスクステートメント（英語）

  • 3.1 全体的な運用上の優秀性を高めるための戦略を作成する。
  • 3.2 セキュリティを向上させるための戦略を決定する。
  • 3.3 パフォーマンスを改善するための戦略を決定する。
  • 3.4 信頼性を向上させるための戦略を決定する。
  • 3.5 コスト最適化の機会を特定する。

公式の学習リソース

この分野を練習する（75問）→次の分野を読む ↓
04

ワークロードの移行とモダナイゼーションの加速

Accelerate Workload Migration and Modernization

20%

学習目標

  • Migration Hub・Application Discovery Service でポートフォリオを評価し、7 つの R（リホスト・リプラットフォーム・リファクタリングなど）と TCO で移行の優先順位とウェーブを決められる
  • Application Migration Service・DMS・SCT・DataSync・Transfer Family・Snow Family から、アプリ・データベース・データの移行手段を選べる
  • 移行先として EC2・Elastic Beanstalk・ECS/EKS/Fargate、EBS・EFS・FSx・S3・Storage Gateway、RDS・DynamoDB などを選べる
  • Lambda・コンテナ・目的別データベース・SQS/SNS/EventBridge/Step Functions で、疎結合・サーバーレスへのモダナイゼーションを提案できる

要点

  • 移行の評価：Application Discovery Service（エージェントまたはエージェントレス）でサーバーの構成・利用率・依存関係を収集し、Migration Hub で進捗を一元管理する。依存関係の強いサーバーは同じウェーブで移す。
  • 7 つの R：リホスト（そのまま移す）、リプラットフォーム（OS や DB をマネージドに置き換える程度の小さな変更）、リファクタリング（クラウドネイティブに作り直す）、再購入（SaaS へ）、リロケート、保持、廃止。期限が厳しいならまずリホスト、のちに最適化。
  • サーバーの移行は Application Migration Service（ブロックレベルの継続的な複製で、短い切り替え時間）。データベースは DMS（全量ロード＋CDC で稼働させながら移行）、異なるエンジン間ならスキーマ変換に SCT（または DMS Schema Conversion）。
  • データの移行：ネットワーク経由でファイルを継続的に同期するなら DataSync、SFTP・FTPS の取引先連携は Transfer Family、回線が細い・数百 TB 以上なら Snowball Edge。移行の途中でもオンプレミスから使い続けるなら Storage Gateway。
  • 移行先の選択：Windows のファイル共有は FSx for Windows File Server、NetApp からの移行は FSx for NetApp ONTAP、Linux の共有は EFS。商用 DB のライセンスやOS への特別なアクセスが必要なら RDS Custom や EC2 上の自前運用も選択肢。
  • モダナイゼーション：バッチやイベント処理は Lambda と EventBridge、長時間の手順は Step Functions、モノリスの一部をコンテナ化して ECS/Fargate に切り出す（ストラングラーパターン）。
  • 目的別データベースへの置き換え：セッションや高速な参照は ElastiCache/DynamoDB、全文検索は OpenSearch、負荷が読めない RDB は Aurora Serverless v2。

業務での使いどころ

  • 総務データセンターの契約更新までの 9か月で 120 台のサーバーを移行。Application Discovery Service で依存関係を調べ、ウェーブごとに Application Migration Service でリホストする。
  • 経理オンプレミスの Oracle の会計 DB を、DMS の全量ロードと CDC で Aurora PostgreSQL へ移行。スキーマは SCT で変換し、月末を避けて切り替える。
  • 営業夜間バッチで作っていた見込み客リストを、EventBridge のスケジュールと Lambda・Step Functions に置き換え、サーバーの運用をなくす。

公式のタスクステートメント（英語）

  • 4.1 移行が可能な既存のワークロードとプロセスを選択する。
  • 4.2 既存ワークロードの最適な移行アプローチを決定する。
  • 4.3 既存ワークロードの新しいアーキテクチャを決定する。
  • 4.4 モダナイゼーションと機能強化の機会を決定する。

公式の学習リソース

この分野を練習する（60問）→模擬試験に挑戦する →

読み終えたら

全分野を練習する（300問）模擬試験（75問・180分）SAP-C02 のトップへ
ご利用上の注意（非公式・独自問題・合格保証なし）