39
27

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@kentaro_kawamura(川村 賢太郎)in富士通株式会社 Developers' Cafe

【2026年版】AWS SAP(SAP-C02)直前対策チートシート

39
Posted at

はじめに

2026年1月23日、AWS SAP(SAP-C02)に合格しました。
当初はUdemyなどで模擬試験をひたすら解いていましたが、SAPは試験範囲が広いためか、似たような問題で間違えてしまったり、解説が頭に入らなかったりしました。

そこで勉強法を切り替え、試験ガイドをベースに「迷いやすいポイント」を体系的に整理し直したところ、Udemyの問題の解説もスッと入るようになり、理解も進みました。

この記事は、その時に作成した「試験直前に絶対に見直したいポイント」と、実際の試験で自分で迷ったポイントをまとめたものです。
これから受験される方が、試験当日の電車の中などでサッと見返せる「チートシート」として役立てば嬉しいです。

今回の試験のスコアです。
image.png

目次

  1. SAP試験について
  2. Domain 1: 組織の複雑さに対応するソリューションの設計
    • マルチアカウント戦略とガバナンス
    • 別アカウントへのAssume Role（スイッチロール）の仕組み
    • 大規模ネットワーク接続
    • Route 53 ResolverによるハイブリッドDNS解決
    • Egress VPC とは
  3. Domain 2: 新しいソリューションの設計
    • 災害復旧 (DR) の4段階とコスト
    • 防御と検知のセキュリティ
    • 信頼性とパフォーマンスの設計パターン
    • AWS Global Accelerator とは
  4. Domain 3: 既存のソリューションの継続的な改善
    • 運用自動化の鉄板パターン
    • セキュリティの改善
    • トラブルシューティングとコスト分析
  5. Domain 4: ワークロードの移行とモダナイゼーション
    • 移行戦略「7つのR」
    • AWS Keyspaces とは
    • データ移行ツール
    • データベース移行

1. SAP試験について

SAP試験の特徴

Associateレベル（SAA）が「1つのVPC、単一アカウント」の箱庭的な設計だったのに対し、Professional（SAP）は「数百のアカウント、グローバル展開、ハイブリッド接続」というエンタープライズ規模の設計が求められます。

問題を解くときの考え方

上記で触れたようにSAP試験はエンタープライズ規模の設計になります。
そのため、回答を選ぶ際に共通する考え方があります。
試験問題を解く際は、常に以下の3点を意識してください。

  1. Scale (規模係数 x100): 「1台なら手動でいいが、1000台ならどうするか？」→ 手動操作はNG、自動化・マネージドサービスが正解。
  2. Trade-off (トレードオフ): 「コスト最優先」なのか「ダウンタイムゼロ」なのか。要件によって正解（Active-ActiveかBackupか）が変わる。
  3. Governance (統制): 人の善意に頼らず、システム的にガードレール（SCP, Config）を敷く。

2. Domain 1: 組織の複雑さに対応するソリューションの設計 (約26%)

このドメインのテーマは「マルチアカウント統制」と「大規模ネットワーク」です。

2.1 マルチアカウント戦略とガバナンス

数百のアカウントを管理するために、AWS OrganizationsとControl Towerが必須となります。

AWS Organizations & SCP (Service Control Policies)

  • SCPの役割:ルートユーザーでも無効化できない「ガードレール」です。
  • 判定ロジック:
    • 明示的なDeny (Explicit Deny) は最も強力です。IAMで許可されていてもSCPで禁止されていれば操作できません。
    • SCPは「許可(Allow)」を与えるものではなく、「最大権限を制限する」ものです。
  • 継承: OU（組織単位）の階層構造において、親OUのSCPは子アカウントに継承されます。

AWS Control Tower

  • Landing Zone:ベストプラクティスに基づいたマルチアカウント環境（ログ集約、SSOなど）を自動展開します。
  • 必須アカウントの役割:
    • Log Archiveアカウント: CloudTrailやConfigログを一元管理。S3バケットポリシーで削除・改ざんを厳重に禁止します。
    • Auditアカウント: Security HubやGuardDutyなどの監査ツールを集約し、セキュリティチームが監視します。
  • Account Factory: Service Catalogを利用して、ネットワーク設定済みの新規アカウント発行を自動化します。
    • コスト管理の罠: 親アカウントで購入したRI/Savings Plansはデフォルトで共有されますが、特定の開発用アカウント等で共有したくない場合は、共有の無効化設定が必要です。

別アカウントへのAssume Role（スイッチロール）の仕組み

Organizations環境下やマルチアカウント環境で、「管理アカウントからメンバーアカウントを操作する」手順は頻出です。

  1. IAMロールの作成 (メンバーアカウント側):
    • 操作される側のアカウントにIAMロール（例: CrossAccountRole）を作成します。
    • 信頼ポリシー (Trust Policy): 「誰が」このロールになれるかを定義します。ここで「管理アカウントのID (Principal: AWS: 111122223333)」を指定します。
  2. IAMポリシーの設定 (管理アカウント側):
    • 操作する側のユーザー（またはグループ）に、「sts:AssumeRole」アクションを許可するポリシーをアタッチします。
    • Resourceには、上記で作ったロールのARNを指定します。
  3. スイッチロールの実行:
    • 管理アカウントのユーザーが AssumeRole APIを叩く（またはコンソールでスイッチする）と、一時的な認証情報（AccessKey, SecretKey, SessionToken）が発行され、メンバーアカウントの操作が可能になります。
  • OrganizationAccountAccessRole:
    • AWS Organizationsでアカウントを新規作成した場合、自動的にこの名前のロールが作成されます。これには管理アカウントからの信頼ポリシーが最初から設定されており、AdministratorAccess権限を持っています。

2.2 大規模ネットワーク接続

「100個のVPCとオンプレミスをどう繋ぐか」という問いへの回答です。

接続サービスの比較と使い分け

サービス 特徴 選択の判断基準 (Decision Logic)
Transit Gateway (TGW) ハブ＆スポーク型。数千のVPCやVPNを集約可能。 「運用効率」優先。管理が圧倒的に楽。ルーティングテーブルを一箇所で制御したい場合。
VPC Peering 1対1の接続。ゲートウェイ処理料がかからない。 「コスト」優先。ただしフルメッシュ接続（N×N）になり管理が複雑化するため、接続数が少ない場合限定。
Direct Connect (DX) 専用線接続。安定した帯域と低遅延。 「一貫したネットワーク性能」が必要な場合。導入に数週間かかる。
Site-to-Site VPN インターネット経由のIPsec接続。 「スピード・安さ」。DXのバックアップ、または小規模拠点の接続。

Route 53 ResolverによるハイブリッドDNS解決

オンプレミスとAWSでお互いのサーバー名（ホスト名）を解決する仕組みです。ここが試験の最難関ポイントの一つです。

通常、オンプレミスのDNSサーバーはAWS内のプライベートDNS名（*.compute.internal）を知りません。逆もしかりです。これを解決するのが Route 53 Resolver Endpointsです。

  1. オンプレミスからAWSの名前を解決したい (Inbound Endpoint)

    • 使うもの:Inbound Endpoint (インバウンドエンドポイント)。
    • 仕組み:
      1. VPC内にENI（エンドポイント）を作成します。これにはIPアドレスが割り当てられます。
      2. オンプレミスのDNSサーバー（ADなど）に「条件付きフォワーダー (Conditional Forwarder)」を設定します。
      3. 「*.amazonaws.com などのクエリは、Inbound EndpointのIPへ転送しろ」と設定します。
    • 流れ: [オンプレPC] → [オンプレDNS] → (転送) → [Inbound Endpoint] → [Route 53 Resolver] → [AWSリソースIP]

  2. AWSからオンプレミスの名前を解決したい (Outbound Endpoint)

    • 使うもの: Outbound Endpoint (アウトバウンドエンドポイント) と Resolver Rule (リゾルバールール)。
    • 仕組み:
      1. VPC内にENI（Outbound Endpoint）を作成します。
      2. Route 53 Resolver Rule を作成します。「corp.example.com へのクエリは、オンプレミスのDNSサーバーIPへ転送しろ」と定義します。
      3. このルールをVPCに関連付けます。
    • 流れ: [EC2] → [Route 53 Resolver] → (ルール一致) → [Outbound Endpoint] → (転送) → [オンプレDNS] → [オンプレリソースIP]

試験での迷いポイント:

  • 「AWSからオンプレを引きたい」のに「Inbound Endpoint」を選ばないでください。Outboundです。
  • 「Conditional Forwarder（条件付き転送）」の設定場所は、オンプレDNSサーバー側です。

Gemini_Generated_Image_7chnjq7chnjq7chn.png

Route 53を使ったオンプレDNS利用については以下の記事がわかりやすかったです。
AWS環境でオンプレミスDNSを使える方法 (Route 53 Resolver アウトバウンドエンドポイント)

Egress VPC とは

「Egress (イグレス/エグレス)」とは「出口、外への通信」のことです。
多数のVPCがある環境で、それぞれにNAT Gatewayやインターネットゲートウェイを置くと、管理が煩雑になり、コストもかさみます。また、セキュリティ監査も大変です。

  • アーキテクチャ:
    • 専用の 「Egress VPC」 を1つ作成します。
    • 各アプリVPC（Spoke VPC）からのインターネット向け通信は、すべて Transit Gateway を経由して、このEgress VPCに集めます。
    • Egress VPC内に、NAT Gateway や Network Firewall、Proxyサーバー を集中配置します。
  • メリット:
    • コスト削減: NAT GatewayをVPCごとに置かなくて済む。
    • セキュリティ一元化: 全てのインターネット向け通信を1箇所（Network Firewall等）で検査・フィルタリングできる。
  • 試験でのキーワード: 「中央集権的なアウトバウンドトラフィックの検査」「NAT Gatewayのコスト削減」「管理オーバーヘッドの削減」。

2.3 ネットワークセキュリティと通信制御

  • VPC Endpoints (PrivateLink):
    • Gateway型 (無料): S3とDynamoDBのみ。ルートテーブルで制御。
    • Interface型 (有料): その他のサービス。ENIを使用。オンプレミスからもDX経由で利用可能。
  • AWS Network Firewall:
    • ドメインフィルタリング (URL Filtering): NAT Gatewayではできない「特定のURL（example.com）へのアクセスのみ許可」を実現する場合の正解。

3. Domain 2: 新しいソリューションの設計 (約29%)

試験の最大範囲です。「要件定義から設計へ」のプロセスが問われます。

3.1 災害復旧 (DR) の4段階とコスト

RPO（データ損失許容）とRTO（復旧時間）の要件に対し、コストが見合う戦略を選びます。

戦略 概要 RPO/RTO コスト
Backup & Restore データをS3に退避。障害時にインフラ構築。 時間単位 (遅い) 最安
Pilot Light DBデータのみ同期。Appサーバーは停止中。 数十分 安い
Warm Standby 最小構成で稼働。障害時にスケールアウト。 数分 中
Multi-site Active/Active 両リージョンで常時稼働。 ほぼゼロ 高 (2倍以上)
  • AWS Backup: クロスリージョン、クロスアカウントでのバックアップを一元管理。
  • S3 Object Lock: Compliance Mode（ルートユーザーでも削除不可）と Governance Mode（特定権限で削除可）の違いを区別してください。

3.2 セキュリティ

  • Layer 7 (App): AWS WAF (SQLi, XSS対策)。
  • Layer 3/4 (Net): AWS Shield (DDoS対策)。Advanced版はコスト保護（攻撃によるスケーリング費用の返金）がつきます。
  • データ保護:
    • Secrets Manager: DBパスワードの自動ローテーションが必要ならこれ一択。
    • KMS vs CloudHSM: 「FIPS 140-2 Level 3」「シングルテナント」要件ならCloudHSM。

3.3 信頼性とパフォーマンスの設計パターン

メッセージングサービスの使い分け

  • Amazon SQS: バッファリング（Pull型）。
  • Amazon SNS: ファンアウト（Push型）。

AWS Global Accelerator について

CloudFrontと混同しやすいですが、役割が違います。

  • 概要: AWSのグローバルバックボーンネットワークを使って、ユーザーのトラフィックを最適化するサービスです。
  • 特徴:
    1. 静的 Anycast IP: 2つの固定IPアドレスが提供されます。DNSキャッシュの問題（TTL待ち）がなく、即時フェイルオーバーが可能です。
    2. プロトコル: TCPとUDPに対応しています（CloudFrontはHTTP/Sのみ）。
    3. 非キャッシュ: データをキャッシュしません。
  • 試験での選択基準:
    • 「UDPを使いたい（ゲーム、VoIP）」 → Global Accelerator。
    • 「クライアントに固定IPアドレスを提供したい（ファイアウォールの許可リスト用など）」 → Global Accelerator。
    • 「DNSの伝播遅延（TTL）を待たずに即時フェイルオーバーしたい」 → Global Accelerator。
    • 「Webコンテンツをキャッシュして高速化したい」 → CloudFront。
  • Custom Routing: ユーザーを特定のEC2インスタンスの特定のポートに決定論的にルーティングする機能（対戦ゲームのマッチング等で使用）。

4. Domain 3: 既存のソリューションの継続的な改善 (約25%)

「Day 2 Operations（運用フェーズ）」です。キーワードは「自動化」と「自己修復」。

4.1 運用自動化

  • パッチ適用: SSHログインはアンチパターン。Systems Manager (SSM) Patch Manager でスケジュール管理します。
  • 接続管理: 踏み台サーバー（Bastion Host）は廃止し、SSM Session Manager を使用します。
  • 構成監査と修復:
    • AWS Config: 「あるべき姿」を定義。
    • 自動修復 (Remediation): Config Rulesで違反検知 → SSM Automation をトリガーして自動修復。

4.2 セキュリティの改善 (検知と対応)

  • Amazon Inspector: 脆弱性スキャン。EC2/ECRの中身をチェック。
  • Amazon GuardDuty: 脅威検知。ログを分析し、攻撃の兆候を見つける。エージェントレス。
  • Security Hub: 結果を一元管理。

4.3 パフォーマンスとコストの分析

  • AWS X-Ray: 分散アプリのボトルネック特定。
  • AWS Compute Optimizer: リソースのRightsizing推奨。
  • コスト分析: 詳細分析は CUR + Athena + QuickSight。
  • AWS Budgets Actions: 予算超過時に「EC2を停止する」などの実力行使を自動化。

5. Domain 4: ワークロードの移行とモダナイゼーション (約20%)

オンプレミスからAWSへの「移行」と、その後の「進化」です。

5.1 移行戦略「7つのR」

  1. Rehost (Lift & Shift): 期限切迫。ツールは MGN (Application Migration Service)。
  2. Replatform: DBをRDSへ。
  3. Refactor (Re-architect): クラウドネイティブ化（Lambda等）。
  4. Relocate: VMware Cloud on AWS へvMotion。

AWS Keyspaces とは

試験で突然選択肢に出てきて焦るサービスの一つです。

  • 正式名称: Amazon Keyspaces (for Apache Cassandra)。
  • 正体: マネージド Apache Cassandra です。
  • 特徴:
    • サーバーレス: サーバー管理不要。オートスケーリング対応。
    • 互換性: 既存のCassandra用コード（CQL）やドライバーがそのまま使えます。
  • 試験での出題パターン:
    • 「オンプレミスでCassandraを使っている。運用負荷を減らしたい。コードは書き換えたくない（または最小限にしたい）」
    • → 正解: Replatform (AWS Keyspaces への移行)。
    • DynamoDBも選択肢に出ますが、DynamoDBはAPIが違うためコードの大幅な書き換え（Refactor）が必要です。「コード変更最小」ならKeyspacesです。

5.2 データ移行ツール

ツール 特徴と選択理由
AWS DataSync 「回線がある」場合の高速オンライン転送。NFS/SMB/Object対応。移行の主力ツール。
Snow Family 「回線がない」または「PB級で転送に数ヶ月かかる」場合。オフライン移行。
Storage Gateway 「ハイブリッド運用」用。移行ではなく、オンプレからAWSストレージをマウントして使い続ける場合。
AWS Transfer Family 「SFTP / FTPS / FTP」 という単語が出たらこれ。既存のSFTPサーバーをサーバーレス化。

5.3 データベース移行ツール

  • AWS DMS (Database Migration Service):
    • CDC (Change Data Capture): 移行中もデータ同期を続けることで、切り替え時のダウンタイムを最小化します。
  • SCT (Schema Conversion Tool):
    • 異種間移行 (Heterogeneous): Oracle → Aurora PostgreSQLのようにDBの種類が変わる場合、スキーマ（テーブル定義やPL/SQL）を自動変換するために必須です。

さいごに

ここまで読んでいただきありがとうございました。
SAP試験は190分、75問と他の試験に比べても体力が必要な試験になります。
試験前にこちらをさっと見返していただいて、落ち着いて試験に臨んでいただければともいます。
皆さんの合格を心より応援しています！

39
27
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
39
27

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?