AWS Certified Solutions Architect – Professional (SAP-C02) 完全学習ガイド

試験概要

特徴

SAP は AWS認定試験の中で最難関の1つ。
「最適解」ではなく「複数のトレードオフを理解した上での最良の判断」が問われる。
問題は長文シナリオ形式で、複数の条件を同時に満たす解答を選ぶ必要がある。

ドメイン別出題割合

Domain 1: 組織の複雑さに対応した設計（26%）

1-1. マルチアカウント戦略の設計

ランディングゾーンの設計:

AWS Organizations 構造設計:

Root
├── Management OU
│   └── Management Account（請求集約、SCP管理のみ）
│
├── Security OU
│   ├── Security Tooling Account
│   │   → GuardDuty管理者, Security Hub管理者, Inspector委任
│   └── Log Archive Account
│       → CloudTrail集約, Config集約, VPC Flow Logs
│
├── Infrastructure OU
│   └── Shared Services Account
│       → VPC共有(RAM), IAM Identity Center, ECR
│
├── Sandbox OU（制限付き実験環境）
│
└── Workloads OU
    ├── Prod OU
    │   ├── Prod Account A
    │   └── Prod Account B
    ├── NonProd OU
    │   ├── Staging Account
    │   └── Dev Account
    └── (ドメイン別に分割)

設計原則:
  → アカウント = 信頼境界 = セキュリティ爆発半径の分離
  → OU = SCPのガードレール適用単位
  → 最低でもSecurity/Log/SharedServicesは分離する

Control Tower のカスタマイズ:

Control Tower Customizations（CfCT）:
  → CloudFormationテンプレートを全アカウントに展開
  → SCP追加、IAMロール作成、共通リソース作成を自動化

Account Factory:
  → 新規アカウントを標準化されたテンプレートで作成
  → Account Factory for Terraform (AFT): Terraformで管理
  → ServiceCatalogベースのセルフサービス

ガードレール（Guardrails）:
  必須: 無効化不可（CloudTrail有効化等）
  強く推奨: 有効化推奨
  選択的: 必要に応じて有効化

AWS Config Aggregator:
  → 全アカウントのConfig結果を1ヶ所に集約
  → 組織全体のコンプライアンス状態を可視化

1-2. ハイブリッド接続の設計

Direct Connect 詳細:

接続タイプ:
  Dedicated Connection: 1Gbps, 10Gbps, 100Gbps
    → コロケーション施設でAWSポートに直接接続
    
  Hosted Connection: 50Mbps〜10Gbps
    → Direct ConnectパートナーのAWSとの共有接続を利用

Virtual Interface (VIF):
  Private VIF: VPC内のリソースへのアクセス（プライベートIPアドレス）
  Public VIF: AWSパブリックサービスへのアクセス（S3等）
  Transit VIF: Transit Gatewayと接続（複数VPCへのアクセス）

高可用性設計:
  Active-Active: 2本のDC + BGPでトラフィック分散
  Active-Passive: 1本がダウンしたら自動フェイルオーバー
  バックアップVPN: DXのバックアップとしてVPNを用意

コスト注意点:
  → 転送料金はDX経由の方がインターネット経由より安い
  → ただしDX自体の接続料金（ポート時間）が発生

Transit Gateway の高度な設計:

TGW ルーティングドメインの分離:
  Production VPC ─┐
  Staging VPC ───┤── TGW Route Table A（Production用）
                 │
  Dev VPC ───────┤── TGW Route Table B（NonProd用）
                 │
  Shared Services─┴── 全テーブルに関連付け（共通サービス）

マルチリージョン TGW ピアリング:
  ap-northeast-1 TGW ←──→ us-east-1 TGW（ピアリング接続）
  → ステップ: TGWピア接続作成 → ルート設定（BGP非使用）

TGW + Direct Connect Gateway:
  → 1つのDXGWで複数リージョンのTGWに接続
  → オンプレから全リージョンのVPCへアクセス可能

Domain 2: 新規ソリューションの設計（29%）

2-1. 高度なデータ設計

Aurora Advanced 設計:

Aurora Global Database:
  → プライマリリージョン: 読み書き
  → セカンダリリージョン（最大5）: 読み取りのみ
  → レプリカラグ: 通常1秒未満
  → フェイルオーバー（計画的）: < 1分
  → フェイルオーバー（非計画的）: < 1分（RTO）
  → RPO: 通常1秒未満

Aurora Serverless v2:
  → 0.5〜128 ACU（Aurora Capacity Units）でオートスケール
  → スケールの応答性: 秒単位（v1は分単位）
  → Dev/Test環境からProd環境まで幅広く対応
  → Writer/Reader両方をServerlessにできる

Aurora Machine Learning:
  → AuroraからSageMakerやComprehendを直接呼び出し
  → SQLで機械学習推論
  SELECT product_id, aws_comprehend_detect_sentiment(review_text, 'en') 
  FROM product_reviews;

Babelfish for Aurora PostgreSQL:
  → SQL Server のT-SQLを PostgreSQL で実行
  → SQL Serverからの移行コストを削減

DynamoDB 高度な設計:

DynamoDB Accelerator (DAX):
  → インメモリキャッシュ（マイクロ秒レイテンシ）
  → APIはDynamoDBと互換（SDK変更最小）
  → マルチAZ クラスター（3ノード以上）
  → Write-through vs Read-through キャッシュ
  → 注意: DaxはGetItem/Query/Scanのキャッシュ（TransactWriteはキャッシュしない）

DynamoDB Streams + Kinesis Data Streams:
  DynamoDB Streams: 変更を24時間保持
  Kinesis Data Streams: 変更を最大365日保持（より長い分析に適合）
  
  DynamoDB → Kinesis Data Streams → Lambda（集計）→ DynamoDB（集計結果保存）

DynamoDB Export to S3:
  → PITRを使ってある時点のスナップショットをS3にエクスポート
  → AthenaでSQLクエリ可能
  → 本番テーブルの読み取りキャパシティに影響なし

TTLとアーカイブパターン:
  DynamoDB（ホットデータ, TTL付き）
    → TTL期限切れ → DynamoDB Streams
    → Lambda → S3 Glacier（コールドデータアーカイブ）

2-2. コスト最適化の高度な設計

Savings Plans の最適化:

Savings Plansの種類と適用範囲:

Compute Savings Plans（最も柔軟）:
  → EC2（インスタンスタイプ・リージョン問わず）
  → Lambda（関数レベル）
  → Fargate
  → 割引率: 最大66%

EC2 Instance Savings Plans（最も安い）:
  → 特定のインスタンスファミリーとリージョン
  → 割引率: 最大72%

SageMaker Savings Plans:
  → SageMaker専用

購入戦略:
  Step 1: Cost Explorerで推奨Savings Plansを確認
  Step 2: ベースロード（P99の使用量）をSavings Plansでカバー
  Step 3: スパイク部分はオンデマンドでカバー
  Step 4: バッチ処理はスポットインスタンス

Savings Plans vs Reserved Instances:
  → SP: 柔軟（インスタンスタイプ変更可、Fargate/Lambda対応）
  → RI: 特定のインスタンスタイプに縛られるが若干安い

2-3. セキュリティアーキテクチャの高度化

ゼロトラストネットワーク設計:

従来のネットワーク境界モデル:
  外部(危険) ←─── Firewall ────→ 内部(安全)
  問題: 内部の侵害者・マルウェアに対して無力

ゼロトラストモデル:
  "Never trust, always verify"
  → 全てのアクセスを検証（内部からでも）
  → 最小権限
  → マイクロセグメンテーション

AWSでのゼロトラスト実装:
  IAM Identity Center（認証・認可の一元化）
  ├── デバイス評価（Verified Access）
  ├── アプリケーション単位のアクセス制御
  └── セッション単位のログ記録

AWS Verified Access:
  → VPNなしで社内アプリへの安全なアクセス
  → 毎リクエストで条件を評価
  → 条件: デバイス状態（ManagedDeviceのみ）、ユーザーグループ、IP等
  → CloudWatchでアクセスログ

Network Firewall:
  → VPCにデプロイするL7ステートフルファイアウォール
  → Suricata互換のルール（IDS/IPS）
  → 集中検査アーキテクチャ（Inspection VPC）:
    
    Internet Gateway
         ↓
    Firewall Subnet（Network Firewall）
         ↓
    Application Subnet（EC2/ECS）

Domain 3: 既存ソリューションの継続的改善（25%）

3-1. パフォーマンス改善の設計

データベースパフォーマンスの改善:

RDS Performance Insights:
  → DBのクエリパフォーマンスを可視化
  → DB Load（AAS: Average Active Sessions）でボトルネック特定
  → 重いクエリのSQLを特定 → クエリ最適化

Aurora I/O Optimized:
  → I/Oコストを排除（月額で固定）
  → I/O集約的ワークロードで最大40%コスト削減
  → I/O比率が高い（読み書きコストが大きい）場合に有効

ElastiCache のキャッシュ戦略:
  Cache-Aside（Lazy Loading）:
    1. アプリがキャッシュを確認
    2. ミスの場合: DBから取得 → キャッシュに保存
    → キャッシュが古いデータを含む可能性あり
  
  Write-Through:
    1. DBへの書き込みと同時にキャッシュを更新
    → 常に最新データ / 書き込みが少し遅くなる
  
  TTL設定:
    → データの鮮度要件に合わせてTTLを設定
    → 短すぎる: DBアクセスが増える
    → 長すぎる: 古いデータを返す可能性

グローバル展開のアーキテクチャ:

シナリオ: 日本、米国、欧州のユーザーへのAPIサービス

パターン1: CloudFront + Origin（単一リージョン）
  → 静的/キャッシュ可能なコンテンツに有効
  → 動的APIは恩恵が少ない

パターン2: Global Accelerator + マルチリージョン
  → TCPレベルのルーティング改善（20-60%のレイテンシ削減）
  → 固定IPアドレスを提供（IPホワイトリスト不要）
  → ヘルスチェックによる自動フェイルオーバー

パターン3: Route 53 レイテンシールーティング + マルチリージョン
  → 各リージョンに完全なスタック
  → DNS解決時にレイテンシーが最小のリージョンへ
  → フェイルオーバーの反映にDNS TTLの時間がかかる

データの整合性設計:
  DynamoDB Global Tables:
    → Active-Active（全リージョンで読み書き可能）
    → 結果整合性（Last-Writer-Wins）
    → 設計上の注意: 書き込み競合の回避

  Aurora Global Database:
    → Active-Passive（セカンダリは読み取りのみ）
    → 強整合性の書き込みはプライマリのみ
    → フェイルオーバーで昇格可能

Domain 4: ワークロードの移行と最新化（20%）

4-1. 移行戦略の設計

7R 移行フレームワーク:

Retire（廃止）:
  → 使われていないシステムを廃止
  → 移行前の棚卸しで10-20%が廃止対象

Retain（維持）:
  → 移行しない（クラウドに移す理由がない、規制上不可等）
  → 再評価スケジュールを設定する

Rehost（Lift & Shift）:
  → そのままEC2に移行
  → ツール: AWS Application Migration Service (MGN)
  → コード変更なし、最速移行

Relocate:
  → VMwareをAWS上のVMware Cloudに移行
  → EC2への移行なし、VMwareのまま

Replatform（Lift, Tinker & Shift）:
  → 最小限の変更でAWSのマネージドサービスへ
  → 例: MySQL on EC2 → RDS MySQL
  → ツール: AWS DMS

Repurchase（Drop & Shop）:
  → SaaSへ切り替え
  → 例: CRM on EC2 → Salesforce

Refactor（Re-architect）:
  → クラウドネイティブに再設計
  → 最大のメリット、最大の工数
  → モノリス → マイクロサービス

AWS Application Migration Service (MGN):

移行プロセス:
1. ソースサーバーにエージェントをインストール
2. 継続的レプリケーション開始（本番稼働中に実施）
3. テスト移行（本番影響なし）
4. カットオーバーウィンドウで切り替え

特徴:
  → 継続レプリケーション: 変更分のみ同期
  → RTO: 分単位
  → RPO: サブ秒（ほぼリアルタイム）
  → 非破壊的（元のサーバーには影響なし）

Database Migration Service (DMS):

サポートする移行パターン:
  Oracle → Aurora PostgreSQL（異種DB間）
  SQL Server → RDS SQL Server（同種、バージョンアップ）
  MongoDB → DocumentDB（NoSQL間）
  On-premise Oracle → S3（アーカイブ）

Schema Conversion Tool (SCT):
  → スキーマ・ストアドプロシージャ・ビューを変換
  → 変換できない部分はレポートで確認

継続的レプリケーション（CDC: Change Data Capture）:
  → 一括移行後も差分を継続的に同期
  → カットオーバー時のRPOを最小化

長文シナリオ問題の解き方

SAP特有の問題形式

典型的な問題文の長さ: 100〜200語

含まれる情報:
  1. ビジネス要件（可用性, SLA, RTO/RPO）
  2. 技術的制約（既存システム, 予算, スキル）
  3. 規制要件（コンプライアンス, データ居住性）
  4. 移行・変更の制約（ダウンタイム不可等）

解答プロセス:
  Step 1: 要件を箇条書きにする
    → 何が必要か / 何は絶対NGか / 予算制約
  
  Step 2: 各選択肢を評価する
    → 全要件を満たすか
    → アンチパターンが含まれていないか
    → コスト・複雑性は妥当か

  Step 3: 最善の組み合わせを選ぶ
    → 複数条件を全て満たす選択肢は1つのみ

よく出るシナリオパターン:

シナリオ1: 「オンプレのOracleをコスト削減しながら移行」
  → SCT + DMS で Aurora PostgreSQL へ（Replatform）
  → または: 既存Oracleを維持しながら RDS Custom Oracle（ライセンス持ち込み可能）

シナリオ2: 「グローバルユーザーへのAPI、RTO/RPO最小化」
  → Aurora Global Database + Route 53 レイテンシールーティング
  → フェイルオーバーのスクリプト化（SSM Automation）

シナリオ3: 「コンプライアンス対応、SOC2/PCI」
  → AWS Config + Conformance Packs（PCI DSS テンプレート）
  → Security Hub（一元管理）
  → CloudTrail（全操作ログ、改ざん検証付き）
  → S3 Object Lock（ログの削除不可）

シナリオ4: 「大企業のマルチアカウント統制」
  → Control Tower（ランディングゾーン）
  → IAM Identity Center（シングルサインオン）
  → SCP（ガードレール）
  → AWS Config Aggregator（全体のコンプライアンス可視化）

学習計画（12週間）

Week 1-4: コア強化

Week 1: マルチアカウント設計
  → Organizations, Control Tower, SCP, IAM Identity Center
  
Week 2: ネットワーク深掘り
  → Direct Connect, Transit Gateway, Network Firewall
  
Week 3: データベース高度な設計
  → Aurora Global, DynamoDB高度機能, ElastiCacheパターン
  
Week 4: コスト最適化
  → Savings Plans計算, 移行後のコスト試算

Week 5-8: 設計パターン習得

• Week 5: DR戦略（RTO/RPO別の実装パターン）
• Week 6: セキュリティ（ゼロトラスト, SIEM/SOAR）
• Week 7: 移行戦略（7R, DMS, MGN）
• Week 8: 模擬試験1回目（75問）+ 復習

Week 9-12: 仕上げ

• Week 9-10: 弱点ドメインの集中学習
• Week 11: 模擬試験3回（75問×3）
• Week 12: 最終確認と試験

推奨学習リソース

公式:
  → AWS公式Exam Guide（試験ガイド）を熟読
  → AWS公式の参照アーキテクチャ（aws.amazon.com/architecture）
  → AWSブログ（"aws.amazon.com/blogs/architecture"）
  → re:Inventのアーキテクチャセッション動画（YouTube）

実践:
  → 実際にAWSコンソールで設計を実装する
  → 模擬問題を問題形式で解く（Tutorials Dojo等）
  → 間違えた問題の根拠を必ずドキュメントで確認する

アーキテクチャ図

AWS Organizations ランディングゾーン設計

flowchart TB
    Root["🏢 Root\n(Organizations管理アカウント)"]

    subgraph Foundation["基盤OU"]
        SecurityOU["Security OU"]
        InfraOU["Infrastructure OU"]
    end

    subgraph Security["セキュリティアカウント"]
        SecTooling["Security Tooling\nGuardDuty管理者\nSecurity Hub集約\nMAcie管理者"]
        LogArchive["Log Archive\nCloudTrail集約\nConfig集約\nVPC Flow Logs"]
    end

    subgraph Infra["インフラアカウント"]
        SharedSvc["Shared Services\nAD/DNS/Patch\nAMI管理"]
        Network["Network\nTransit Gateway\nDirect Connect"]
    end

    subgraph Workloads["Workloads OU"]
        ProdOU["Production OU\nSCP: 厳格制限"]
        DevOU["Development OU\nSCP: 標準制限"]
        SandboxOU["Sandbox OU\nSCP: 最小制限"]
    end

    Root --> Foundation & Workloads
    Foundation --> Security & Infra
    Security --> SecTooling & LogArchive
    Infra --> SharedSvc & Network
    Workloads --> ProdOU & DevOU & SandboxOU

ハイブリッドネットワーク設計

flowchart LR
    OnPrem["オンプレミス\nデータセンター\n192.168.0.0/16"]

    subgraph DX["Direct Connect"]
        DXLOC["DX Location\n(東京)"]
        VIF1["Private VIF 1\n(10Gbps)"]
        VIF2["Private VIF 2\n(バックアップ)"]
    end

    subgraph TGW["Transit Gateway\n(ap-northeast-1)"]
        direction TB
        TGWRT_Prod["本番RT\n(制限あり)"]
        TGWRT_Dev["開発RT\n(制限あり)"]
        TGWRT_OnPrem["オンプレRT"]
    end

    subgraph VPCs["VPCs"]
        VPC_Prod["本番VPC\n10.0.0.0/16"]
        VPC_Dev["開発VPC\n10.1.0.0/16"]
        VPC_Shared["共有VPC\n10.2.0.0/16\n(DNS/AD)"]
    end

    OnPrem <-->|"専用線"| DXLOC
    DXLOC --> VIF1 & VIF2
    VIF1 & VIF2 --> TGWRT_OnPrem
    TGWRT_OnPrem <--> VPC_Shared
    TGWRT_Prod <--> VPC_Prod
    TGWRT_Dev <--> VPC_Dev

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

SAP-C02 は複数ページのシナリオ問題が多い。選択肢を慎重に分析してください。

問題 1

ある企業は AWS Organizations で 50 アカウントを管理しています。全アカウントで「東京リージョン（ap-northeast-1）と大阪（ap-northeast-3）以外でのリソース作成を禁止」したいと考えています。IAM管理者ロールはこの制限の影響を受けてはいけません。最も適切な実装はどれですか？

• A. 各アカウントのIAMポリシーにリージョン条件を追加する
• B. Organizations の SCP に NotAction + StringNotIn 条件でリージョン制限を設定し、IAM管理者ロールを除外する
• C. AWS Config ルールでリージョン制限違反を検出して自動削除する
• D. CloudFormation StackSets で全アカウントにリージョン制限ポリシーをデプロイする

{
  "Effect": "Deny",
  "NotAction": ["iam:*", "organizations:*", "support:*", "sts:*"],
  "Resource": "*",
  "Condition": {
    "StringNotIn": {
      "aws:RequestedRegion": ["ap-northeast-1", "ap-northeast-3"]
    },
    "ArnNotLike": {
      "aws:PrincipalARN": "arn:aws:iam::*:role/IAMAdminRole"
    }
  }
}

問題 2

マルチリージョン Active-Active 構成の Web アプリケーションで、東京・バージニアの両リージョンのユーザーが同一の DynamoDB テーブルのデータを読み書きします。各リージョンのユーザーには低レイテンシを提供しつつ、データの整合性も確保したい場合、最適な構成はどれですか？

• A. DynamoDB をバージニアに集中配置し、東京からはクロスリージョンアクセス
• B. 東京に DynamoDB を配置し、バージニアには Read Replica を作成する
• C. DynamoDB Global Tables でマルチリージョンマルチアクティブ構成にする
• D. 各リージョンに独立した DynamoDB を配置し、Lambda で同期する

問題 3

企業が新しいAWSアカウントを大量（週に数件）にプロビジョニングしています。各アカウントには標準の VPC、サブネット、セキュリティグループ、IAMロール、CloudTrail 設定を適用する必要があります。最も効率的な自動化方法はどれですか？

• A. 各アカウントに手動で CloudFormation スタックをデプロイする
• B. AWS Control Tower の Account Factory でアカウントプロビジョニングを自動化する
• C. Organizations の API を使って Lambda でアカウント設定を自動化する
• D. Terraform を使って全アカウントの設定を管理する

問題 4

オンプレミスの Oracle データベース（10TB）を AWS に移行したいと考えています。移行中のダウンタイムを最小化し（最大2時間）、移行後は Amazon Aurora PostgreSQL に変換したい場合、最適なサービスの組み合わせはどれですか？

• A. RDS スナップショットインポート + AWS Database Migration Service（DMS）
• B. AWS Schema Conversion Tool（SCT）でスキーマ変換 + DMS の CDC（継続的データレプリケーション）
• C. AWS DataSync でデータをS3に転送後、Aurora にインポート
• D. Snowball で物理的にデータを転送し、Aurora にロード

問題 5

大企業が AWS への移行計画を立てています。既存の700台のサーバーをどう移行するか評価しています。一部のアプリケーションはクラウドに最適化する価値がありますが、他は単純な移行のみで十分です。使用すべきフレームワークと最初のステップはどれですか？

• A. 全アプリを一度にリアーキテクトしてマイクロサービスに移行する
• B. 7R 移行戦略でアプリを分類し、ビジネス価値の高いものから段階的に移行する
• C. 全サーバーを EC2 に Rehost（Lift & Shift）してから最適化する
• D. オンプレミスと AWS をハイブリッドで運用しながら段階的に移行する

問題 6

本番環境の Aurora MySQL クラスターで書き込みインスタンスの CPU が 90% を超えています。アプリケーションは読み取りが 70%、書き込みが 30% です。最もコスト効率よく問題を解決する方法はどれですか？

• A. Aurora インスタンスクラスをより大きなサイズにスケールアップする
• B. Aurora Read Replica を追加し、アプリの読み取りをリーダーエンドポイントに向ける
• C. Aurora Serverless v2 に移行する
• D. Aurora Global Database を追加する

問題 7

ある金融企業はオンプレミスのメインフレームと AWS 上の新しいアプリケーションが同じデータを参照する必要があります。データの一貫性が最も重要で、オンプレミスとAWSが同じデータソースを持つべきです。最適なアーキテクチャはどれですか？

• A. AWS で新しいデータベースを作り、Lambda でオンプレミスと定期的に同期する
• B. オンプレミスのDBはそのまま、Direct Connect + PrivateLink で AWS からアクセスする
• C. AWS Storage Gateway でオンプレミスのデータを S3 にキャッシュする
• D. AWS Database Migration Service でオンプレミスからAWSにリアルタイム同期する

SAP-C02 追加詳解セクション

Solutions Architect Professional の特徴

Professional試験は Associate より複雑なシナリオを扱う。複数のサービスを組み合わせた設計・コスト最適化・移行戦略が中心。

移行戦略（7R）（試験最頻出）

7R（移行戦略）:

1. Retire（廃止）
   → 使用されていないアプリを廃止
   → コスト削減効果: 大

2. Retain（保留）
   → 規制・依存関係・リスクで移行できないものを一時的に保留
   → 後で再評価

3. Rehost（リホスト）= Lift and Shift
   → アプリをそのまま（変更最小）でクラウドへ
   → EC2に同じ構成でデプロイ
   → 迅速だがクラウドの恩恵は少ない

4. Relocate（再配置）
   → VMware等のプラットフォームをクラウドへ（変更最小）
   → VMware Cloud on AWS

5. Repurchase（再購入）= Drop and Shop
   → SaaSに移行（CRM → Salesforce等）
   → 既存のライセンスを廃止

6. Replatform（リプラットフォーム）= Lift, Tinker, and Shift
   → 一部最適化しながら移行
   → RDS（マネージドDB）への移行（DBエンジンは変えない）
   → Elastic Beanstalkへの移行

7. Refactor / Re-architect（リファクタリング）
   → アーキテクチャを根本から再設計
   → モノリス → マイクロサービス
   → 最高の効果だが最もコスト・時間がかかる

エンタープライズ設計パターン

Landing Zone / Control Tower

AWS Control Tower:
  → マルチアカウント環境のゴバナンスを自動化
  → Landing Zone（セキュアなマルチアカウント基盤）の自動構築

コンポーネント:
  Management Account: 組織の管理
  Log Archive Account: CloudTrail/Config ログを一元保管
  Audit Account: セキュリティツール（GuardDuty/SecurityHub）の集約
  
  Guardrails:
    → Mandatory（必須）: 無効化不可の基本セキュリティルール
    → Strongly Recommended: 無効化可能だが推奨
    → Elective: オプション

Service Control Policies（SCP）

SCP の特徴:
  → AWS Organizationsで組織全体のポリシーを設定
  → OU（組織単位）またはアカウントに適用
  → IAMと独立（SCPは権限の最大境界を定義）
  → SCPはルートアカウントには適用できない

SCP vs IAMの優先順位:
  有効なアクション = IAMポリシーで許可 AND SCPで許可
  → どちらかがDenyすると実行不可
  → 両方がAllowしないと実行不可

ユースケース:
  → 本番アカウントでEC2の特定インスタンスタイプを禁止
  → 全アカウントで特定リージョンのみ使用許可
  → S3バケットの削除を禁止

高度なネットワーク設計

AWS Transit Gateway

概念:
  → 複数のVPC・オンプレミスを単一のハブで接続
  → 以前はVPCピアリング（n対nでフルメッシュが必要）が必要だった

Transit Gatewayのメリット:
  → Hub-and-Spoke モデル（中央集権的接続）
  → 複数VPC間のルーティング管理が簡単
  → 共有サービス（セキュリティ・DNS等）へのアクセスを一元化

ルートテーブル:
  → TGW専用のルートテーブルで接続関係を制御
  → 本番VPCと開発VPCを分離（相互通信不可）しながら共有VPCには両方から接続可

TGW Connect:
  → GRE/BGPでSD-WANとの統合に使用

SAP-C02 模擬問題

問題 SAP-01

「データベースを変えずにアプリケーションを最小限の変更でAWSに移行し、マネージドデータベースサービスを活用したい」移行戦略はどれですか？

• A. Rehost（リホスト）
• B. Replatform（リプラットフォーム）
• C. Refactor（リファクタリング）
• D. Retain（保留）

問題 SAP-02

SCPで「全ての組織アカウントでap-northeast-1（東京）リージョン以外のAWSサービスを使用できないよう制限したい」場合の正しい設定はどれですか？

• A. 全IAMユーザーにDenyポリシーを適用する
• B. 組織のルートまたはOUにSCPを適用してap-northeast-1以外をDenyする
• C. VPCセキュリティグループで他リージョンへのアクセスをブロックする
• D. CloudFrontでリージョン制限を設定する

問題 SAP-03

AWS Transit Gatewayが解決する問題として正しいものはどれですか？

• A. 複数VPC間でS3へのアクセスを集約する
• B. n個のVPCをフルメッシュのVPCピアリングなしに相互接続するハブ&スポーク型ネットワーク
• C. Direct Connectの帯域幅を自動的に増加させる
• D. マルチリージョンのRoute 53ルーティングを管理する

SAP-C02 試験直前チェックリスト

• [ ] 7R（Retire/Retain/Rehost/Relocate/Repurchase/Replatform/Refactor）の定義
• [ ] SCP vs IAMポリシーの優先順位
• [ ] AWS Control Tower のコンポーネント（Management/Log Archive/Audit Account）
• [ ] Transit Gateway のハブ&スポーク設計
• [ ] VPCピアリング vs Transit Gateway の使い分け
• [ ] AWS Organizations の OU と SCP の適用

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

Domain 1 詳細: マルチアカウント設計の深掘り

AWS Organizations 完全設計ガイド

OU設計のベストプラクティス

推奨OU構造（大企業向け）

Root
├── Security OU（セキュリティ基盤）
│   ├── Log Archive Account     ← CloudTrail/Config集約先
│   └── Security Tooling Account ← GuardDuty/SecurityHub委任管理者
│
├── Infrastructure OU（共有インフラ）
│   └── Shared Services Account  ← DNS/AD/ECR/IAM Identity Center
│
├── Workloads OU（アプリ環境）
│   ├── Production OU
│   │   ├── App-A Production Account
│   │   └── App-B Production Account
│   ├── Non-Production OU
│   │   ├── Staging Accounts
│   │   └── Development Accounts
│   └── Sandbox OU  ← 実験用（制限付き）
│
└── Transitional OU（移行中アカウント一時格納）

SCP 設計パターン集

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyLeavingOrganization",
      "Effect": "Deny",
      "Action": "organizations:LeaveOrganization",
      "Resource": "*"
    },
    {
      "Sid": "DenyOutsideRegions",
      "Effect": "Deny",
      "Action": "*",
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:RequestedRegion": [
            "ap-northeast-1",
            "us-east-1"
          ]
        },
        "ArnNotLike": {
          "aws:PrincipalArn": [
            "arn:aws:iam::*:role/AdminRole",
            "arn:aws:iam::*:role/OrganizationAccountAccessRole"
          ]
        }
      }
    },
    {
      "Sid": "DenyRootUserActions",
      "Effect": "Deny",
      "Action": "*",
      "Resource": "*",
      "Condition": {
        "StringLike": {
          "aws:PrincipalArn": "arn:aws:iam::*:root"
        }
      }
    },
    {
      "Sid": "ProtectSecurityServices",
      "Effect": "Deny",
      "Action": [
        "cloudtrail:StopLogging",
        "cloudtrail:DeleteTrail",
        "guardduty:DeleteDetector",
        "guardduty:DisassociateFromMasterAccount",
        "config:DeleteConfigurationRecorder",
        "config:StopConfigurationRecorder"
      ],
      "Resource": "*",
      "Condition": {
        "ArnNotLike": {
          "aws:PrincipalArn": "arn:aws:iam::*:role/SecurityAdminRole"
        }
      }
    }
  ]
}

AWS RAM（Resource Access Manager）による共有

RAM でのリソース共有パターン
┌─────────────────────────────────────────────────────────────┐
│  Shared Services Account（VPCオーナー）                      │
│  ┌─────────────────────────────────────────────────────┐   │
│  │  中央VPC (10.0.0.0/16)                              │   │
│  │  ├── Shared Subnet A (10.0.1.0/24) ─→ Account A  │   │
│  │  ├── Shared Subnet B (10.0.2.0/24) ─→ Account B  │   │
│  │  └── Shared Subnet C (10.0.3.0/24) ─→ Account C  │   │
│  └─────────────────────────────────────────────────────┘   │
│                                                             │
│  RAM 共有リソース:                                           │
│  ・VPCサブネット（最も一般的）                               │
│  ・Route 53 Resolver Rules（DNS解決ルール）                 │
│  ・Transit Gateway                                         │
│  ・License Manager設定                                      │
│  ・AWS Glue Data Catalog                                   │
└─────────────────────────────────────────────────────────────┘

import boto3

ram = boto3.client('ram')

# リソース共有の作成（VPCサブネットを組織内で共有）
response = ram.create_resource_share(
    name='shared-vpc-subnets',
    resourceArns=[
        'arn:aws:ec2:ap-northeast-1:123456789:subnet/subnet-0123456789abcdef0',
        'arn:aws:ec2:ap-northeast-1:123456789:subnet/subnet-0987654321fedcba0',
    ],
    principals=[
        'arn:aws:organizations::123456789:ou/o-xxxx/ou-xxxx-xxxxxxxx'  # OU全体に共有
    ],
    allowExternalPrincipals=False  # 組織内のみ
)

Domain 2 詳細: アーキテクチャ設計の深掘り

ネットワーク設計の複雑なシナリオ

Transit Gateway ハブアンドスポーク

Transit Gateway マルチアカウント設計
┌────────────────────────────────────────────────────────────────┐
│  Networking Account（Transit Gateway オーナー）                 │
│  ┌──────────────────────────────────────────────────────────┐  │
│  │  Transit Gateway (TGW)                                   │  │
│  │  ├── Route Table: Production（厳格なルーティング）         │  │
│  │  ├── Route Table: Non-Production（開発環境向け）           │  │
│  │  └── Route Table: Shared Services（全環境からアクセス可）  │  │
│  └──────────────────────────────────────────────────────────┘  │
│           ↕ TGW Attachment (RAM共有)                           │
│  ┌────────────────────────────────────────────────────────┐    │
│  │  Production VPCs          Non-Prod VPCs                │    │
│  │  App-A (10.1.0.0/16)     Dev-A (10.10.0.0/16)         │    │
│  │  App-B (10.2.0.0/16)     Dev-B (10.11.0.0/16)         │    │
│  └────────────────────────────────────────────────────────┘    │
│                                                                │
│  AWS Direct Connect / VPN                                     │
│  ↕ TGW ↔ オンプレミス                                          │
└────────────────────────────────────────────────────────────────┘

Prod-to-Dev 通信: Route Table で分離（Prod→Dev 拒否）
Dev-to-Shared: 全環境からShared Servicesへのアクセスは許可

import boto3

ec2 = boto3.client('ec2')

# Transit Gateway の作成（Networking Account）
tgw_response = ec2.create_transit_gateway(
    Description='Organization-wide Transit Gateway',
    Options={
        'AmazonSideAsn': 64512,
        'DefaultRouteTableAssociation': 'disable',  # カスタムルートテーブルを使用
        'DefaultRouteTablePropagation': 'disable',
        'VpnEcmpSupport': 'enable',
        'DnsSupport': 'enable',
        'MulticastSupport': 'enable'
    },
    TagSpecifications=[
        {
            'ResourceType': 'transit-gateway',
            'Tags': [
                {'Key': 'Name', 'Value': 'org-tgw'},
                {'Key': 'Environment', 'Value': 'all'}
            ]
        }
    ]
)

# Production 用ルートテーブル作成
prod_rt = ec2.create_transit_gateway_route_table(
    TransitGatewayId=tgw_response['TransitGateway']['TransitGatewayId'],
    TagSpecifications=[
        {
            'ResourceType': 'transit-gateway-route-table',
            'Tags': [{'Key': 'Name', 'Value': 'prod-route-table'}]
        }
    ]
)

AWS PrivateLink vs VPCピアリング vs Transit Gateway

大規模Webアプリの設計パターン

グローバルトラフィック最適化

グローバル配信アーキテクチャ
┌──────────────────────────────────────────────────────────────────┐
│  世界中のユーザー                                                   │
│              ↓                                                    │
│  Route 53 (グローバルDNS)                                         │
│  ・Latency-based ルーティング（最も応答速度が速いリージョンへ）      │
│  ・Failover ルーティング（プライマリ障害時にセカンダリへ）           │
│              ↓                                                    │
│  CloudFront (グローバルCDN, 450+ エッジロケーション)               │
│  ・静的コンテンツのキャッシュ                                        │
│  ・SSL/TLS終端                                                    │
│  ・WAF統合（DDoS/SQLi/XSS対策）                                  │
│  ・Lambda@Edge（動的レスポンス変換）                               │
│              ↓                                                    │
│  Application Load Balancer（ALB）                                 │
│  ・コンテンツベースルーティング（/api/* → ECS、/* → S3）           │
│  ・ECS Fargate コンテナクラスター（Auto Scaling）                  │
│              ↓                                                    │
│  マルチAZ Aurora（リードレプリカによる読み取り分散）                 │
│  ElastiCache Redis（セッション管理/キャッシュ）                     │
└──────────────────────────────────────────────────────────────────┘

マイクロサービス設計パターン

サービスメッシュ（AWS App Mesh）

# App Mesh Virtual Service 設定
apiVersion: appmesh.k8s.aws/v1beta2
kind: VirtualService
metadata:
  name: payment-service
  namespace: production
spec:
  awsName: payment.production.svc.cluster.local
  provider:
    virtualRouter:
      virtualRouterRef:
        name: payment-router

---
apiVersion: appmesh.k8s.aws/v1beta2
kind: VirtualRouter
metadata:
  name: payment-router
  namespace: production
spec:
  listeners:
    - portMapping:
        port: 8080
        protocol: http
  routes:
    - name: payment-route
      httpRoute:
        match:
          prefix: /
        action:
          weightedTargets:
            - virtualNodeRef:
                name: payment-v2
              weight: 10  # 新バージョンに10%
            - virtualNodeRef:
                name: payment-v1
              weight: 90  # 旧バージョンに90%
        retryPolicy:
          httpRetryEvents:
            - server-error
          maxRetries: 3
          perRetryTimeout:
            unit: s
            value: 5

Event-Driven Architecture

イベント駆動アーキテクチャパターン
┌─────────────────────────────────────────────────────────────────┐
│  注文サービス → SQS (FIFO) → 在庫サービス                         │
│                           → 支払いサービス                        │
│                           → 通知サービス                          │
│                                                                  │
│  SAGA パターン（分散トランザクション）:                             │
│                                                                  │
│  注文作成 → 在庫引当て → 支払い処理 → 注文確定                    │
│      ↑失敗時のロールバック（補償トランザクション）                   │
│  注文キャンセル ← 在庫戻し ← 支払い返金                           │
│                                                                  │
│  Step Functions + Lambda で SAGA を実装:                         │
│  ・成功: 全ステップを順次実行                                      │
│  ・失敗: Catchで補償ステップを実行                                 │
└─────────────────────────────────────────────────────────────────┘

# Step Functions による SAGA パターン（State Machine定義）
import json

saga_definition = {
    "Comment": "Order Processing SAGA",
    "StartAt": "ReserveInventory",
    "States": {
        "ReserveInventory": {
            "Type": "Task",
            "Resource": "arn:aws:lambda:us-east-1:123:function:reserve-inventory",
            "Catch": [
                {
                    "ErrorEquals": ["InsufficientInventory"],
                    "Next": "CancelOrder",
                    "ResultPath": "$.error"
                }
            ],
            "Next": "ProcessPayment"
        },
        "ProcessPayment": {
            "Type": "Task",
            "Resource": "arn:aws:lambda:us-east-1:123:function:process-payment",
            "Catch": [
                {
                    "ErrorEquals": ["PaymentFailed"],
                    "Next": "ReleaseInventory",
                    "ResultPath": "$.error"
                }
            ],
            "Next": "ConfirmOrder"
        },
        "ConfirmOrder": {
            "Type": "Task",
            "Resource": "arn:aws:lambda:us-east-1:123:function:confirm-order",
            "End": True
        },
        # 補償トランザクション
        "ReleaseInventory": {
            "Type": "Task",
            "Resource": "arn:aws:lambda:us-east-1:123:function:release-inventory",
            "Next": "CancelOrder"
        },
        "CancelOrder": {
            "Type": "Task",
            "Resource": "arn:aws:lambda:us-east-1:123:function:cancel-order",
            "End": True
        }
    }
}

Domain 3 詳細: 既存ソリューションの継続的改善

パフォーマンス最適化

データベース最適化パターン

データベース選択フローチャート
                ┌──────────────────────────────────┐
                │  データはリレーショナル？           │
                └─────────────────┬────────────────┘
                                  │
          ┌───────────────────────┼───────────────────────┐
          ↓ YES                                           ↓ NO
  ┌───────────────────┐                         ┌────────────────────┐
  │  スケール要件？    │                         │  データモデルは？   │
  └────────┬──────────┘                         └──────────┬─────────┘
           │                                               │
  ┌────────┴────────┐                    ┌────────────────┬┴──────────────┐
  ↓ 小〜中規模       ↓ 大規模              ↓ KVS            ↓ ドキュメント    ↓ 時系列
 Aurora            Aurora              DynamoDB         DocumentDB      Timestream
 PostgreSQL/       Serverless v2       （低レイテンシ）    （MongoDB互換）   （IoT/監視）
 MySQL             （自動スケール）

ElastiCache 最適化

import boto3
import json
from redis import Redis
from redis.cluster import RedisCluster

# Redis Cluster Mode 設定
redis_cluster = RedisCluster(
    startup_nodes=[
        {"host": "my-cluster.abc123.0001.use1.cache.amazonaws.com", "port": 6379}
    ],
    decode_responses=True,
    ssl=True,
    ssl_certfile=None,
    ssl_check_hostname=False
)

# キャッシュ戦略1: Cache-Aside（最も一般的）
def get_user_profile(user_id: str) -> dict:
    cache_key = f"user:profile:{user_id}"
    
    # キャッシュから取得試行
    cached = redis_cluster.get(cache_key)
    if cached:
        return json.loads(cached)
    
    # キャッシュミス: DBから取得
    user = db.get_user(user_id)
    
    # キャッシュに保存（TTL: 1時間）
    redis_cluster.setex(
        cache_key,
        3600,
        json.dumps(user)
    )
    return user

# キャッシュ戦略2: Write-Through（書き込みと同時にキャッシュ更新）
def update_user_profile(user_id: str, data: dict) -> dict:
    # DBを更新
    updated = db.update_user(user_id, data)
    
    # キャッシュも同時更新（一貫性保証）
    cache_key = f"user:profile:{user_id}"
    redis_cluster.setex(cache_key, 3600, json.dumps(updated))
    
    return updated

# キャッシュ戦略3: Read-Through（キャッシュが自動的にDBを参照）
# ElastiCache for Redis と AWS Lambda を組み合わせた実装

コスト最適化の高度な戦略

AWS Cost Optimization Hub 活用

コスト最適化フレームワーク
┌────────────────────────────────────────────────────────────────┐
│  継続的なコスト最適化プロセス                                     │
│                                                                │
│  1. 可視化（Cost Explorer / Cost & Usage Report）               │
│     ・タグによるコスト按分                                        │
│     ・サービス/アカウント/リージョン別コスト分析                  │
│                                                                │
│  2. 割引の活用                                                  │
│     ・Reserved Instances（1/3年コミット、最大72%割引）          │
│     ・Savings Plans（Compute/EC2/SageMaker）                   │
│     ・Spot Instances（最大90%割引、中断許容ワークロード）        │
│                                                                │
│  3. リソースの最適化                                             │
│     ・Compute Optimizer（EC2/Lambda/EBS/ECS適正サイズ推奨）    │
│     ・S3 Intelligent-Tiering                                  │
│     ・未使用リソースの特定・削除                                  │
│                                                                │
│  4. アーキテクチャ最適化                                         │
│     ・Serverless（Lambda/Fargate）への移行                     │
│     ・Graviton（ARM）インスタンスへの移行（20%安価）            │
│     ・データ転送コストの削減（S3 Transfer Acceleration等）     │
└────────────────────────────────────────────────────────────────┘

import boto3

ce = boto3.client('ce')

# コスト最適化レコメンデーションの取得
response = ce.get_rightsizing_recommendation(
    Service='AmazonEC2',
    Configuration={
        'RecommendationTarget': 'SAME_INSTANCE_FAMILY',
        'BenefitsConsidered': True
    }
)

for rec in response['RightsizingRecommendations']:
    print(f"インスタンスID: {rec['CurrentInstance']['ResourceId']}")
    print(f"現在タイプ: {rec['CurrentInstance']['ResourceDetails']['EC2ResourceDetails']['InstanceType']}")
    
    if rec['RightsizingType'] == 'MODIFY':
        target = rec['ModifyRecommendationDetail']['TargetInstances'][0]
        print(f"推奨タイプ: {target['ResourceDetails']['EC2ResourceDetails']['InstanceType']}")
        print(f"月間節約額: ${target['EstimatedMonthlySavings']}")

Domain 4 詳細: 移行と最新化

7R 移行戦略の詳細

AWS Application Migration Service（MGN）

import boto3

mgn = boto3.client('mgn')

# ソースサーバーの一覧確認
servers = mgn.describe_source_servers(
    filters={'isArchived': False}
)

for server in servers['items']:
    print(f"サーバーID: {server['sourceServerID']}")
    print(f"ライフサイクル状態: {server['lifeCycle']['state']}")
    print(f"データレプリケーション状態: {server['dataReplicationInfo']['dataReplicationState']}")

# テストインスタンスの起動
mgn.start_test(
    sourceServerIDs=['s-0123456789abcdef0'],
    tags={'TestType': 'Pre-Migration'}
)

# 本番カットオーバー
mgn.start_cutover(
    sourceServerIDs=['s-0123456789abcdef0']
)

データベース移行戦略

AWS DMS（Database Migration Service）

DMS 移行パターン
┌──────────────────────────────────────────────────────────────┐
│  ホモジニアス移行（同一データベース）                            │
│  Oracle → Oracle on RDS                                     │
│  MySQL → MySQL on Aurora                                    │
│  ・DMS の Full Load のみで対応                               │
│                                                              │
│  ヘテロジニアス移行（異なるデータベース）                        │
│  Oracle → Aurora PostgreSQL                                 │
│  SQL Server → Aurora MySQL                                  │
│  ・スキーマ変換: AWS Schema Conversion Tool (SCT) で変換     │
│  ・データ移行: DMS で継続的レプリケーション                    │
│                                                              │
│  カットオーバー手順:                                          │
│  1. Full Load（初期データ移行）                               │
│  2. CDC（Change Data Capture）で差分を継続レプリケーション     │
│  3. アプリの接続切り替え（メンテナンスウィンドウ内）            │
│  4. DMS タスク停止                                           │
└──────────────────────────────────────────────────────────────┘

SAP-C02 模擬試験（75問）

問題セット1（25問）

Q1. ある企業が現在、オンプレミスのOracle RACを使用しています。AWS移行を検討していますが、Oracleライセンスのコストを最小化したいと考えています。最適な移行先は？

• A) Oracle on EC2（Dedicated Host）
• B) RDS for Oracle
• C) Aurora PostgreSQL（Oracleからの移行）
• D) DynamoDB

正解: C - Aurora PostgreSQLへの移行でOracleライセンスが不要になり最大コスト削減が可能。AWS SCTとDMSを使ってスキーマとデータを変換します。一定の移行工数はかかりますが長期的なライセンスコスト削減は大きいです。

Q2. 世界中のユーザーが利用するWebアプリがあり、各国のユーザーに低レイテンシを提供したい。データは法的要件から各国内に保存する必要がある。最適なアーキテクチャは？

• A) 単一リージョン + CloudFront
• B) Route 53 地理的ルーティング + 各リージョンでのスタック + DynamoDB Global Tables
• C) Transit Gateway + マルチリージョンEC2
• D) CloudFront のみ

正解: B - 地理的ルーティングで各ユーザーを最寄りのリージョンにルーティング。各リージョンに独立したスタックをデプロイし、データはそのリージョンに保存。DynamoDB Global Tablesで複数リージョンにアクティブなデータ層を提供します。

Q3. 1000個のVPCを持つ組織で、全VPCからオンプレミスのDNSサーバーに名前解決できるようにしたい。最もスケーラブルな設計は？

• A) 各VPCにRoute 53 Resolverエンドポイントを設置
• B) Shared Services VPCにRoute 53 Resolver インバウンド/アウトバウンドエンドポイントを設置し、Forwarder Ruleを各VPCにRAMで共有
• C) 全VPCをピアリング接続
• D) EC2ベースのDNSサーバーを各VPCに設置

正解: B - Shared Services VPCの集中型Route 53 ResolverエンドポイントをRAMで全VPCに共有するパターンが最もスケーラブルです。新しいVPCは共有ルールに追加するだけで対応できます。

Q4. あるEC2ワークロードで急激なトラフィック増加が週末に発生する。コストを最小化しながら対応するには？

• A) 常に最大容量を確保
• B) スケジュールスケーリング（週末前にスケールアウト）+ On-Demand ベース + Spot Instance（追加容量）
• C) Reserved Instance のみ
• D) Lambdaに移行

正解: B - ベースはReserved Instance（または最小On-Demand）で常時確保し、予測可能な週末増加はScheduled Scalingで事前スケールアウト。追加のバーストキャパシティはSpot Instanceで対応します。コストを最小化しながら可用性を確保できます。

Q5. あるサービスがAuroraと通信していますが、接続数の増加によりDB接続プールの上限に近づいています。最小限の変更で解決するには？

• A) Auroraインスタンスをより大きいサイズにスケールアップ
• B) RDS Proxyを導入して接続プールを一元管理
• C) 複数のAuroraインスタンスを作成
• D) DynamoDBに移行

正解: B - RDS Proxyはデータベース接続をプールして再利用します。アプリからはProxyへの接続を維持し、Proxyが少数の長期接続でAuroraに接続します。Lambda/ECSからの大量の短命接続によるDB接続圧迫の解消に最適です。

Q6. S3に保存された機密データに対して、誰がいつアクセスしたかを追跡し、PII（個人識別情報）を自動検出したい。最適な組み合わせは？

• A) CloudTrail + 手動確認
• B) S3 Access Logs + Lambda
• C) Amazon Macie（PII検出）+ CloudTrail（アクセス記録）+ Security Hub（統合管理）
• D) GuardDuty のみ

正解: C - Macieは機械学習でS3のPIIを自動検出。CloudTrailはS3データイベントを記録してアクセス監査を提供。Security Hubで両サービスの検出事項を一元管理し、自動修復アクションを設定できます。

Q7. マルチアカウント環境で、すべてのアカウントのEC2インスタンスに最新のセキュリティパッチを週次で自動適用したい。最もスケーラブルな実装は？

• A) 各アカウントでCronジョブを設定
• B) Organizations のバックアップポリシー使用
• C) AWS Systems Manager のマルチアカウントパッチ管理（Quick Setup）+ AWS Organizations統合
• D) CodeDeploy で各アカウントにデプロイ

正解: C - SSM Quick Setup の「Patch Policy」を使うと組織全体または特定OUのアカウントにパッチベースラインとメンテナンスウィンドウを一括設定できます。Organizations統合により新規アカウントにも自動適用されます。

Q8. APIゲートウェイがバックエンドのサービスに対してスパイクトラフィックを直接流している。バックエンドの過負荷を防ぎたい。最適な解決策は？

• A) Lambda を API Gateway の前に配置
• B) SQS キューを API Gateway と Lambda/ECS の間に配置（非同期処理に変更）
• C) CloudFront でキャッシュ
• D) API Gateway のUsage Plan でスロットリング

正解: B - API Gateway → SQS → Lambda/ECS パターンでバックエンドをスパイクトラフィックから保護します。SQSがバッファとして機能し、バックエンドは自身の処理能力に合わせたペースで消費できます（非同期処理に変換が必要）。

Q9. 複数のAWSアカウントで実行されているLambda関数が同じElasticSearchクラスター（OpenSearch）に書き込む必要がある。最もセキュアな実装は？

• A) 全アカウントのLambdaに同じAPIキーを設定
• B) OpenSearchのリソースベースポリシーで各アカウントのLambda実行ロールにアクセスを許可
• C) VPCピアリングと特定SGの許可のみ
• D) パブリックエンドポイントを使用

正解: B - OpenSearchのリソースベースポリシー（Access Policy）でPrincipal: {"AWS": ["arn:aws:iam::ACCOUNT_A:role/LambdaRole", "arn:aws:iam::ACCOUNT_B:role/LambdaRole"]}を設定します。各アカウントのLambda実行ロールにes:ESHttpPost等の権限を付与します。

Q10. 高トラフィックなWebアプリでDDoS攻撃を検知・緩和し、コストを最小化したい。最適な構成は？

• A) EC2インスタンスの前にNGFWを配置
• B) CloudFront + AWS Shield Standard + AWS WAF（ALBの前）
• C) AWS Shield Advanced（全リソースに）
• D) Route 53 フェイルオーバーのみ

正解: B - CloudFront（エッジでDDoS緩和）+ Shield Standard（追加費用なし）+ WAF（SQLi/XSS等のアプリ層攻撃対策）の組み合わせがコスト効率最高です。Shield Advancedは$3,000/月以上かかるため、より大規模な保護が必要な場合に検討します。

Q11-Q25: 追加問題（短答形式）

SAP-C02 学習戦略

推奨学習計画（45日間）

フェーズ1（Day 1-15）: コア技術の深掘り
  ・マルチアカウント設計（Organizations/RAM/Control Tower）
  ・ネットワーク設計（TGW/Direct Connect/PrivateLink）
  ・データベース最適化（Aurora/ElastiCache/DynamoDB Global Tables）

フェーズ2（Day 16-30）: 高度なシナリオ対応
  ・移行戦略（7R/DMS/MGN）
  ・コスト最適化（RI/Savings Plans/Spot/Compute Optimizer）
  ・セキュリティ設計（GuardDuty/Macie/Security Hub/WAF/Shield）

フェーズ3（Day 31-45）: 模擬試験と弱点補強
  ・75問 × 3回の模擬試験
  ・間違えた問題の徹底分析
  ・AWS Well-Architected Framework の5柱を復習

SAP-C02 AWS Certified Solutions Architect Professional 完全学習ガイド 完了

高度なアーキテクチャパターン集

サーバーレスアーキテクチャ設計

API Gateway + Lambda パターン

サーバーレスWebアプリアーキテクチャ
┌────────────────────────────────────────────────────────────────┐
│  フロントエンド                                                  │
│  S3（静的サイトホスティング）+ CloudFront                        │
│                  ↓ HTTPS                                       │
│  API Gateway（REST/HTTP/WebSocket）                            │
│  ├── /api/users/* → Lambda（Node.js/Python）                  │
│  ├── /api/products/* → Lambda（カスタム認証）                   │
│  └── /api/events/* → WebSocket API → Lambda                   │
│                  ↓                                             │
│  Lambda（ビジネスロジック）                                       │
│  ├── DynamoDB（プライマリデータ）                                │
│  ├── ElastiCache（セッション・キャッシュ）                       │
│  ├── S3（ファイルストレージ）                                    │
│  └── SQS/SNS（非同期メッセージ）                                │
│                  ↓                                             │
│  Amazon Cognito（認証/認可）                                    │
│  ├── User Pool（ユーザー管理）                                   │
│  └── Identity Pool（AWS認証情報の払い出し）                      │
└────────────────────────────────────────────────────────────────┘

# Cognito JWT 検証（API Gateway Lambda Authorizer）
import json
import urllib.request
import jwt  # PyJWT

def lambda_handler(event, context):
    """API GatewayのLambdaオーソライザー"""
    token = event.get('authorizationToken', '').replace('Bearer ', '')
    
    try:
        # Cognitoの公開鍵を取得
        region = 'ap-northeast-1'
        user_pool_id = 'ap-northeast-1_XXXXXXXXX'
        
        jwks_url = f'https://cognito-idp.{region}.amazonaws.com/{user_pool_id}/.well-known/jwks.json'
        with urllib.request.urlopen(jwks_url) as response:
            jwks = json.loads(response.read())
        
        # JWTを検証・デコード
        decoded = jwt.decode(
            token,
            jwks,
            algorithms=['RS256'],
            audience=f'arn:aws:execute-api:{region}:123456789:api-id/prod/*'
        )
        
        # アクセス許可ポリシーを返す
        return {
            'principalId': decoded['sub'],
            'policyDocument': {
                'Version': '2012-10-17',
                'Statement': [{
                    'Action': 'execute-api:Invoke',
                    'Effect': 'Allow',
                    'Resource': event['methodArn']
                }]
            },
            'context': {
                'userId': decoded['sub'],
                'email': decoded.get('email', ''),
                'groups': ','.join(decoded.get('cognito:groups', []))
            }
        }
    
    except Exception as e:
        # 認証失敗
        raise Exception('Unauthorized')

大規模データ処理アーキテクチャ

データレイクアーキテクチャ

モダンデータレイクアーキテクチャ
┌────────────────────────────────────────────────────────────────┐
│  データソース                                                    │
│  ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐        │
│  │  RDS/    │ │  IoT     │ │ClickStream│ │  SaaS    │        │
│  │  Aurora  │ │  デバイス │ │ (Web ログ)│ │ API      │        │
│  └────┬─────┘ └────┬─────┘ └────┬─────┘ └────┬─────┘        │
│       └────────────┴────────────┴────────────┘               │
│                         ↓                                     │
│  データ取り込みレイヤー                                           │
│  ┌──────────┐ ┌──────────┐ ┌──────────┐                      │
│  │ Kinesis  │ │  DMS     │ │  AWS     │                      │
│  │ Firehose │ │ (CDC)    │ │ DataSync │                      │
│  └────┬─────┘ └────┬─────┘ └────┬─────┘                      │
│       └────────────┴────────────┘                             │
│                         ↓                                     │
│  S3 Data Lake（Raw/Processed/Curated の3層）                   │
│  ├── s3://datalake/raw/          ← 生データ                   │
│  ├── s3://datalake/processed/    ← 変換・クリーニング済み       │
│  └── s3://datalake/curated/      ← 分析用最終データ            │
│                         ↓                                     │
│  処理・変換レイヤー                                              │
│  ┌──────────┐ ┌──────────┐ ┌──────────┐                      │
│  │  Glue    │ │  EMR     │ │  Lambda  │                      │
│  │  ETL     │ │  Spark   │ │  (軽量)  │                      │
│  └────┬─────┘ └────┬─────┘ └────┬─────┘                      │
│       └────────────┴────────────┘                             │
│                         ↓                                     │
│  分析・可視化レイヤー                                            │
│  ┌──────────┐ ┌──────────┐ ┌──────────┐                      │
│  │  Athena  │ │ Redshift │ │QuickSight│                      │
│  │  (SQL)   │ │(DWH)     │ │  (BI)    │                      │
│  └──────────┘ └──────────┘ └──────────┘                      │
│  Glue Data Catalog（メタデータ管理）                             │
│  Lake Formation（アクセス制御）                                  │
└────────────────────────────────────────────────────────────────┘

Direct Connect 詳細設計

冗長性のあるDirect Connect 構成

Direct Connect 高可用性設計

パターン1: デュアル接続（推奨）
   本社 ────── DX Location A ── AWS
        \                      /
         \─── DX Location B ──/

パターン2: DX + VPN バックアップ
   本社 ────── Direct Connect ── AWS
        \                       /
         \───── Site-to-Site VPN/
         （DX障害時に自動フェイルオーバー）

パターン3: 複数ロケーション + TGW
   本社 ───┐
            ├── DX Location A ──┐
           拠点A                 ├── Transit Gateway ── VPCs
            ├── DX Location B ──┘
           拠点B

import boto3

directconnect = boto3.client('directconnect')

# 仮想インターフェース（VIF）の一覧
vifs = directconnect.describe_virtual_interfaces()

for vif in vifs['virtualInterfaces']:
    print(f"VIF ID: {vif['virtualInterfaceId']}")
    print(f"タイプ: {vif['virtualInterfaceType']}")  # private/public/transit
    print(f"VLAN: {vif['vlan']}")
    print(f"BGP ASN: {vif['asn']}")
    print(f"状態: {vif['virtualInterfaceState']}")  # available/down/etc.

# 接続の詳細
connections = directconnect.describe_connections()

AWS Well-Architected Framework 5つの柱

運用上の優秀性（Operational Excellence）

設計原則:

• インフラをコードで管理（IaC）
• 頻繁で小さな変更を加える
• 障害予測と改善を繰り返す
• 失敗から学ぶ

主要サービス: CloudFormation, CodePipeline, SSM, CloudWatch, X-Ray

セキュリティ（Security）

設計原則:

• 強力なIDベースの基盤（IAM最小権限）
• 追跡可能性の確保（CloudTrail, Config）
• 全レイヤーでのセキュリティ適用
• 機密データの保護（KMS, Macie）

主要サービス: IAM, KMS, GuardDuty, SecurityHub, WAF, Shield

信頼性（Reliability）

設計原則:

• 変化から復旧（Auto Scaling, Multi-AZ）
• 需要を管理（SQS, Kinesis バッファ）
• 変更の自動化（CloudFormation, CodeDeploy）
• 障害の予測と防止（カオスエンジニアリング）

主要サービス: Route 53, ELB, Auto Scaling, RDS Multi-AZ, S3

パフォーマンス効率（Performance Efficiency）

設計原則:

• 最新テクノロジーの活用
• グローバル展開（CloudFront, Global Accelerator）
• サーバーレスの活用
• 適切なテクノロジーの選択

主要サービス: CloudFront, Lambda, DynamoDB, ElastiCache, Kinesis

コスト最適化（Cost Optimization）

設計原則:

• クラウドコストを把握（Cost Explorer, Budgets）
• 需要に合わせたリソース供給（Auto Scaling）
• 適切な課金モデルの選択（Spot, Reserved, Savings Plans）
• 不要な費用の排除（未使用リソースの削除）

主要サービス: Cost Explorer, Trusted Advisor, Compute Optimizer, Savings Plans

サステナビリティ（Sustainability）（6つ目の柱）

設計原則:

• 消費の最大化（利用率を上げてワット/処理を下げる）
• 新しいより効率的なハードウェアへの対応（Graviton）
• マネージドサービスの活用

SAP-C02 追加模擬問題 25問

Q26. ある企業が複数リージョンでAurora PostgreSQLを使用しています。各リージョンでの書き込みが必要で、RPOをゼロに近づけたい。最適なソリューションは？

• A) 各リージョンに独立したAuroraクラスター
• B) Aurora Global Database（プライマリ1つ）
• C) Aurora Global Database + 計画的フェイルオーバー
• D) DynamoDB Global Tablesに移行

正解: C - Aurora Global Databaseは1つのリマリリージョンで書き込みを受け付け、セカンダリリージョンへは1秒未満のレプリケーションを実現。計画的フェイルオーバーで書き込みリージョンを切り替えられます。真のActive-Active書き込みにはDynamoDB Global Tablesへの移行が必要ですが、PostgreSQL機能が必要な場合はAurora Global Databaseが最適です。

Q27. ALBのアクセスログをS3に保存し、週次でAthenaで分析したい。コストを最小化しながらクエリパフォーマンスを最適化するには？

• A) ログをそのままS3に保存してAthenaでクエリ
• B) S3のログをパーティション化（日付/リージョン）し、Glue Crawlerでスキーマ自動検出、Athena クエリのPARTITION PROJECTIONを設定
• C) CloudWatch Logs Insightsを使用
• D) Redshiftにロードしてクエリ

正解: B - パーティション化により不必要なデータスキャンを避けてコストを削減。Partition Projectionを使うとパーティションメタデータをGlue Catalogに登録せずに動的に推定できます。Athenaはスキャンしたデータ量に課金されるため、パーティション効率化は重要です。

Q28. Lambda関数がAurora PostgreSQLに接続する際に発生する接続過多問題を解決する最適な方法は？

• A) Lambdaの同時実行数を下げる
• B) RDS Proxyを使ってLambdaの接続をプール
• C) AuroraインスタンスをXLに変更
• D) DynamoDBに移行

正解: B - LambdaはリクエストごとにDB接続を作成・削除するため、高並行時に接続数が急増します。RDS Proxyは接続を事前に確立してプールし、Lambda→Proxy→Auroraの形で多数のLambda呼び出しを少数のDB接続にまとめます。

Q29. S3バケットのデータに対して列レベルのアクセス制御が必要です（特定ユーザーはSSNカラムにアクセス不可）。最適な実装は？

• A) S3バケットポリシーで制御
• B) AWS Lake Formation の列レベルセキュリティ（Column-Level Security）
• C) KMSでカラムごとに暗号化
• D) IAMポリシーで制御

正解: B - Lake Formationの列レベルセキュリティにより、Athena/Glue/EMRなどのデータアクセスに対してカラム単位でアクセス制御できます。「analytics-teamはSSNカラムへのアクセス不可」といった設定がGlue Data Catalogを通じて一元管理できます。

Q30. マルチリージョンのAWS環境で、すべてのリージョンのCloudTrailログを単一のS3バケットに集約し、タンパリングを防止したい。最適な設計は？

• A) 各リージョンに別々のS3バケット
• B) 組織のCloudTrail証跡（Organization Trail）をus-east-1で作成し、Log File Validation有効化
• C) EventBridgeで全リージョンのログを転送
• D) Lambda関数でリージョン間コピー

正解: B - Organization Trail は全メンバーアカウントの全リージョンのイベントを自動収集し、指定したS3バケット（Log Archive Account）に送信します。Log File Validationで改ざん検知が可能です。新しいアカウント/リージョンも自動的にカバーされます。

Q31-Q50: 追加問題（短答）

SAP-C02 最終まとめ

試験で頻出の設計判断基準

判断基準1: RPO/RTO と コスト
  RPO/RTO要件 → DR戦略を選択
  ┌──────────────────────────────────────────────┐
  │ Active/Active → RPO=0, RTO=0 → コスト最高    │
  │ Warm Standby → RPO=秒, RTO=分 → コスト高     │
  │ Pilot Light  → RPO=分, RTO=時間 → コスト中   │
  │ Backup/Restore→ RPO=時間, RTO=日 → コスト低  │
  └──────────────────────────────────────────────┘

判断基準2: データ量とコスト
  データ転送量 → 最適なデータ転送方法を選択
  < 数十TB: DataSync, Kinesis, DMS
  数十TB〜数百TB: Snowball Edge
  > 数百TB: Snowball Edge複数台, Snowmobile

判断基準3: スケールと複雑さ
  VPC数が少ない (< 10): VPCピアリング
  VPC数が多い (10+): Transit Gateway
  サービス公開: AWS PrivateLink

判断基準4: コスト優先 vs 機能優先
  コスト最優先: Spot Instance, Serverless, S3
  機能優先: Aurora, ElastiCache, EKS

重要な数値・制限の一覧

SAP-C02 AWS Certified Solutions Architect Professional 完全学習ガイド（最終版）

高可用性設計の詳細パターン

Multi-AZ vs Multi-Region 設計

可用性設計の選択基準
┌────────────────────────────────────────────────────────────────┐
│  Single AZ → 開発/テスト環境のみ                                │
│  Multi-AZ  → 本番環境の標準（リージョン内障害から保護）          │
│  Multi-Region → ビジネス継続性/DR/規制要件/グローバル配信        │
└────────────────────────────────────────────────────────────────┘

Multi-AZ 設計例（ap-northeast-1）:
  AZ-a: EC2 Auto Scaling, RDS Primary, ElastiCache Primary
  AZ-c: EC2 Auto Scaling, RDS Standby, ElastiCache Replica
  AZ-d: EC2 Auto Scaling（オプション）
  ALB: 全AZにわたってトラフィック分散

Multi-Region 設計例（Active/Passive DR）:
  ap-northeast-1（プライマリ）:
    ・Full Production Stack
    ・RDS Aurora（Writable）
    ・ElastiCache Cluster
  
  us-east-1（セカンダリ/DR）:
    ・Standby Infrastructure
    ・Aurora Global Database（Read-only）
    ・S3 Cross-Region Replication
    
  フェイルオーバー: Route 53 Failover + 手動または自動昇格

ECS/EKS 高度なパターン

ECS カスタムスケーリング

import boto3

# ECS Service Auto Scaling（カスタムメトリクスベース）
ecs = boto3.client('ecs')
autoscaling = boto3.client('application-autoscaling')

# スケーリング対象の登録
autoscaling.register_scalable_target(
    ServiceNamespace='ecs',
    ResourceId='service/my-cluster/my-service',
    ScalableDimension='ecs:service:DesiredCount',
    MinCapacity=2,
    MaxCapacity=50
)

# カスタムメトリクス（SQSキューの深さ）ベースのスケーリング
autoscaling.put_scaling_policy(
    PolicyName='sqs-queue-depth-scaling',
    ServiceNamespace='ecs',
    ResourceId='service/my-cluster/my-service',
    ScalableDimension='ecs:service:DesiredCount',
    PolicyType='TargetTrackingScaling',
    TargetTrackingScalingPolicyConfiguration={
        'TargetValue': 10,  # キュー内メッセージ数が10を維持するようスケーリング
        'CustomizedMetricSpecification': {
            'Namespace': 'AWS/SQS',
            'MetricName': 'ApproximateNumberOfMessagesVisible',
            'Dimensions': [
                {'Name': 'QueueName', 'Value': 'my-processing-queue'}
            ],
            'Statistic': 'Average'
        },
        'ScaleOutCooldown': 30,
        'ScaleInCooldown': 300
    }
)

EKS KEDA（Kubernetes Event-Driven Autoscaling）

# KEDA ScaledObject - SQS キューの深さに基づくスケーリング
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: order-processor-scaler
  namespace: production
spec:
  scaleTargetRef:
    name: order-processor
  pollingInterval: 30
  cooldownPeriod: 300
  minReplicaCount: 0   # アイドル時は0に縮小
  maxReplicaCount: 100
  triggers:
    - type: aws-sqs-queue
      authenticationRef:
        name: keda-trigger-auth-aws
      metadata:
        queueURL: https://sqs.ap-northeast-1.amazonaws.com/123456789/orders
        queueLength: '5'   # SQSメッセージ5件につき1 Pod
        awsRegion: ap-northeast-1

CloudFront 高度な設定

Cache Key 最適化

import boto3
import json

cloudfront = boto3.client('cloudfront')

# Cache Policy 作成（Cache Key最適化）
cache_policy = cloudfront.create_cache_policy(
    CachePolicyConfig={
        'Name': 'optimized-cache-policy',
        'DefaultTTL': 86400,      # 24時間
        'MaxTTL': 604800,          # 7日間
        'MinTTL': 0,
        'ParametersInCacheKeyAndForwardedToOrigin': {
            'EnableAcceptEncodingGzip': True,
            'EnableAcceptEncodingBrotli': True,
            'HeadersConfig': {
                'HeaderBehavior': 'none'  # ヘッダーはキャッシュキーに含めない
            },
            'CookiesConfig': {
                'CookieBehavior': 'none'  # Cookieはキャッシュキーに含めない
            },
            'QueryStringsConfig': {
                'QueryStringBehavior': 'whitelist',
                'QueryStrings': {
                    'Quantity': 2,
                    'Items': ['lang', 'version']  # 特定のクエリのみキャッシュキーに含める
                }
            }
        }
    }
)

# Origin Request Policy（Originに転送する情報）
origin_request_policy = cloudfront.create_origin_request_policy(
    OriginRequestPolicyConfig={
        'Name': 'include-auth-header',
        'HeadersConfig': {
            'HeaderBehavior': 'whitelist',
            'Headers': {
                'Quantity': 2,
                'Items': ['Authorization', 'X-User-ID']  # Originに認証ヘッダーを転送
            }
        },
        'CookiesConfig': {'CookieBehavior': 'none'},
        'QueryStringsConfig': {'QueryStringBehavior': 'all'}
    }
)

SAP-C02 追加模擬問題 (25問, 51-75)

Q51. 大規模なデータウェアハウスワークロードでRedshiftの書き込みパフォーマンスを最大化するには？

• A) 単一ノードクラスターを使用
• B) COPY コマンドを使用してS3から並列ロード + 適切なDistribution StyleとSort Key
• C) INSERT文を大量実行
• D) DynamoDBからStreams経由でロード

正解: B - RedshiftのCOPYコマンドはS3の複数ファイルを並列でロードするため最速です。Distribution Style（KEY/EVEN/ALL）とSort Keyを適切に設定することでクエリパフォーマンスも最大化できます。

Q52. オンプレミスのActive DirectoryユーザーがAWSリソースにシングルサインオンでアクセスするには？

• A) 全ユーザーのIAMユーザーを作成
• B) AWS IAM Identity Center（SSO）とAD Connectorを使用してオンプレADをフェデレーション
• C) SAML 2.0のみで実装
• D) Cognitoのみで対応

正解: B - IAM Identity Center（旧SSO）とAD Connectorを組み合わせることで、オンプレミスADのユーザーとグループをAWSに同期し、シングルサインオンで複数AWSアカウントにアクセスできます。

Q53. マイクロサービスアーキテクチャで「サービス間の認証」を最も安全に実装するには？

• A) APIキーを各サービスに配布
• B) サービスメッシュ（App Mesh）+ mTLS（相互TLS認証）
• C) VPCセキュリティグループのみで制御
• D) IAMロールのみで制御

正解: B - mTLS（mutual TLS）はクライアントとサーバーの両方が証明書で認証します。AWS Private Certificate Authority（ACM PCA）で証明書を発行し、App Meshでmutual TLSを強制することで、すべてのサービス間通信を暗号化・認証できます。

Q54. IoTデバイスが1秒間に100万件のデータを送信する。リアルタイムでの異常検知とデータレイクへの保存が必要。最適なアーキテクチャは？

• A) IoT → SQS → Lambda → S3
• B) IoT Core → Kinesis Data Streams → Lambda（異常検知）+ Kinesis Firehose（S3へ）
• C) IoT → DynamoDB → Athena
• D) IoT → SNS → S3

正解: B - IoT Coreでデバイス管理、Kinesis Data Streamsでリアルタイムストリーム処理（Lambda連携）、Kinesis FirehoseでS3への自動バッファリング保存。Lambda@StreamsでリアルタイムML異常検知も可能です。

Q55. Lambda関数のコールドスタートを最小化しながらコストも最適化するには？

• A) 全Lambda関数にプロビジョニングされた同時実行を設定
• B) パフォーマンスクリティカルな関数のみにProvisioned Concurrency + Lambda SnapStart（Java）
• C) Lambda をやめてECS Fargateに移行
• D) 全関数を同時実行500に固定

正解: B - Provisioned ConcurrencyはコールドスタートなしのWarm状態を維持しますが常時コストがかかります。本当にクリティカルな関数のみに適用し、JavaアプリケーションではLambda SnapStartで初期化済みスナップショットから起動できます。

Q56-Q75: 短答形式追加問題

SAP-C02 最終チェックリスト

必須理解事項

ネットワーク

• [ ] Transit Gateway のルートテーブルとアタッチメントの設計を説明できる
• [ ] Direct Connect + VPN フェイルオーバーを設計できる
• [ ] Route 53 の全ルーティングポリシー（Latency/Geolocation/Geoproximity/Failover/Weighted/IP-Based）を説明できる
• [ ] VPC ピアリング vs TGW vs PrivateLink の使い分けを判断できる
• [ ] Network Firewall vs WAF vs Security Group の使い分けを説明できる

マルチアカウント

• [ ] Organizations の OU 設計（Security/Infrastructure/Workloads/Sandbox）を設計できる
• [ ] SCP で特定リージョン以外でのリソース作成を禁止できる
• [ ] RAM でサブネットを組織全体に共有できる
• [ ] Control Tower のランディングゾーンを設計できる

データベース

• [ ] Aurora Global Database のフェイルオーバーと RTO/RPO を説明できる
• [ ] RDS Proxy の適用場面（Lambda/ECSの多数接続）を説明できる
• [ ] Redshift の COPY コマンドと Distribution Style を説明できる
• [ ] DynamoDB Global Tables の Active-Active パターンを設計できる

コスト最適化

• [ ] Spot Instance の中断時の処理（ライフサイクルフック/スポット中断通知）を説明できる
• [ ] Savings Plans（Compute vs EC2 vs SageMaker）の違いを説明できる
• [ ] Compute Optimizer の推奨事項の活用方法を説明できる

セキュリティ

• [ ] AWS Shield Advanced の主な追加機能（DDoS Cost Protection/専用サポート）を説明できる
• [ ] GuardDuty の委任管理者（Delegated Admin）を設定できる
• [ ] IAM Identity Center でADフェデレーションを設定できる

SAP-C02 AWS Certified Solutions Architect Professional 完全学習ガイド 全セクション完了

移行戦略の詳細実装

AWS Migration Hub を使った移行管理

import boto3

# Migration Hub で移行進捗を一元管理
migrationhub = boto3.client('mgh')

# 移行タスクのインポート
migrationhub.import_migration_task(
    ProgressUpdateStream='DMS',
    MigrationTaskName='oracle-to-aurora-migration',
)

# 進捗更新
migrationhub.notify_migration_task_state(
    ProgressUpdateStream='DMS',
    MigrationTaskName='oracle-to-aurora-migration',
    Task={
        'Status': 'IN_PROGRESS',
        'StatusDetail': 'フルロード: 75%完了',
        'ProgressPercent': 75
    },
    UpdateDateTime='2024-01-15T10:30:00Z',
    NextUpdateSeconds=300
)

# リソースの関連付け
migrationhub.associate_discovered_resource(
    ProgressUpdateStream='DMS',
    MigrationTaskName='oracle-to-aurora-migration',
    DiscoveredResource={
        'ConfigurationId': 'd-1234567890',  # Application Discovery Serviceから
        'Description': 'Oracle DB Server (192.168.1.100)'
    }
)

Snowball Family を使った大規模データ移行

データ転送方法の選択ガイド
┌────────────────────────────────────────────────────────────────┐
│  データ量と利用可能な帯域幅                                        │
│                                                                │
│  < 1TB, 100Mbps回線（約22時間）: DataSync推奨                   │
│  1-10TB, 100Mbps回線（約22時間〜9日）: DataSync + 最適化         │
│  10-80TB: Snowball Edge (Storage Optimized, 80TB)             │
│  80TB-100PB: 複数のSnowball + Snowball Edge Compute            │
│  > 100PB: Snowmobile（トラック搭載のコンテナ）                   │
│                                                                │
│  AWS Snow Familyの転送速度:                                     │
│  Snowball Edge Storage: 80TB, 10Gbps内部接続                  │
│  Snowball Edge Compute: EC2/Lambda/MLエッジ処理                │
│  Snowcone: 8TB, IoTエッジ、5G対応                              │
└────────────────────────────────────────────────────────────────┘

アプリケーション最新化戦略

コンテナ化（Lift & Shift → Containerize）

# マルチステージビルドによる最適化
FROM maven:3.9-amazoncorretto-21 AS builder
WORKDIR /app
COPY pom.xml .
RUN mvn dependency:go-offline -q
COPY src/ ./src/
RUN mvn package -DskipTests -q

FROM amazoncorretto:21-alpine
WORKDIR /app

# 非rootユーザーでの実行
RUN addgroup -S appgroup && adduser -S appuser -G appgroup
USER appuser

COPY --from=builder /app/target/app.jar .

# ヘルスチェック
HEALTHCHECK --interval=30s --timeout=10s --retries=3 \
  CMD curl -f http://localhost:8080/actuator/health || exit 1

EXPOSE 8080
ENTRYPOINT ["java", "-jar", "app.jar"]

# AWS App2Container でレガシーJavaアプリを自動コンテナ化
# （実際はCLIツール、以下はプロセスの説明）

"""
App2Container ワークフロー:
1. java analyze --application-id com.example.myapp
   → 実行中のJavaプロセスを分析

2. java extract --application-id com.example.myapp
   → Dockerイメージと ECS タスク定義を生成

3. generate app-deployment --application-id com.example.myapp
   → CloudFormationテンプレートを生成

4. deploy --application-id com.example.myapp
   → ECS Fargate にデプロイ
"""

セキュリティアーキテクチャの高度な設計

ゼロトラストアーキテクチャ（ZTA）

AWS でのゼロトラスト実装
┌────────────────────────────────────────────────────────────────┐
│  ネットワーク層（Never Trust, Always Verify）                   │
│  ├── AWS Verified Access（VPN不要のアプリアクセス）             │
│  ├── VPC Lattice（サービス間ゼロトラスト通信）                  │
│  └── AWS Network Firewall（不正通信のブロック）                 │
│                                                                │
│  アイデンティティ層                                              │
│  ├── IAM Identity Center（SSO + 強力なMFA）                   │
│  ├── Cognito（ユーザー認証 + Adaptive Auth）                   │
│  └── AWS Certificate Manager PCA（mTLS証明書）                │
│                                                                │
│  データ層                                                       │
│  ├── KMS（データ暗号化、きめ細かいキーポリシー）                  │
│  ├── Macie（機密データ自動検出）                                │
│  └── Lake Formation（列/行レベルのデータアクセス制御）            │
│                                                                │
│  可視性/監視層                                                  │
│  ├── GuardDuty（脅威インテリジェンス）                          │
│  ├── CloudTrail（全API監査ログ）                               │
│  ├── Security Hub（統合セキュリティスコア）                     │
│  └── Amazon Detective（インシデント調査）                       │
└────────────────────────────────────────────────────────────────┘

AWS IAM の高度な設定

アイデンティティベースポリシー vs リソースベースポリシー

// アイデンティティベースポリシー（ユーザー/ロールにアタッチ）
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::my-bucket/*",
      "Condition": {
        "StringEquals": {
          "s3:prefix": ["${aws:username}/*"]  // ユーザー名をプレフィクスに
        }
      }
    }
  ]
}

// リソースベースポリシー（S3バケットポリシー）
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::123456789:role/DataScienceRole"
      },
      "Action": ["s3:GetObject", "s3:ListBucket"],
      "Resource": [
        "arn:aws:s3:::analytics-bucket",
        "arn:aws:s3:::analytics-bucket/*"
      ],
      "Condition": {
        "StringEquals": {
          "aws:RequestedRegion": "ap-northeast-1"
        },
        "Bool": {
          "aws:SecureTransport": "true"  // HTTPS のみ許可
        }
      }
    },
    {
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:*",
      "Resource": [
        "arn:aws:s3:::analytics-bucket",
        "arn:aws:s3:::analytics-bucket/*"
      ],
      "Condition": {
        "Bool": {
          "aws:SecureTransport": "false"  // HTTP を拒否
        }
      }
    }
  ]
}

Permission Boundary（権限境界）

# Permission Boundary を使ったアカウント権限委任
# 開発チームに「特定のIAMロールしか作れない」制約を設定

permission_boundary_policy = {
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:*",
                "dynamodb:*",
                "lambda:*"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Deny",
            "Action": [
                "iam:CreateUser",
                "iam:CreateRole",
                "iam:PutRolePolicy",
                "iam:AttachRolePolicy"
            ],
            "Resource": "*",
            "Condition": {
                "StringNotEquals": {
                    "iam:PermissionsBoundary": "arn:aws:iam::123456789:policy/DeveloperPermissionBoundary"
                }
            }
        }
    ]
}

# 開発チームのロールに Permission Boundary を設定
import boto3
iam = boto3.client('iam')

iam.create_role(
    RoleName='dev-team-role',
    AssumeRolePolicyDocument=json.dumps({
        "Version": "2012-10-17",
        "Statement": [{
            "Effect": "Allow",
            "Principal": {"AWS": "arn:aws:iam::123456789:root"},
            "Action": "sts:AssumeRole"
        }]
    }),
    PermissionsBoundary='arn:aws:iam::123456789:policy/DeveloperPermissionBoundary'
)

エンタープライズのためのAWS設計

大規模組織のAccount Vending Machine

Account Vending Machine（AVM）
└── Service Catalog + Lambda + Organizations

新規アカウント作成フロー:
1. 申請者がService Catalogで製品を選択（アカウントタイプ: Dev/Staging/Prod）
2. パラメータ入力（アカウント名、OwnerEmail、OU、予算上限）
3. Service Catalog → CloudFormation → Lambda をトリガー
4. Lambda が Organizations API で新規アカウント作成
5. アカウントを指定OUに移動
6. Baseline StackSet（CloudTrail/Config/GuardDuty等）を自動デプロイ
7. IAM Identity Center でSSOアクセスを設定
8. 申請者にアカウントID/ログインURLを通知

コスト配分タグ（Cost Allocation Tags）

import boto3

# コスト配分タグの有効化
ce = boto3.client('ce')

# ユーザー定義タグをコスト配分に使用
activated_tags = ce.get_tags(
    SearchString='CostCenter',
    TimePeriod={
        'Start': '2024-01-01',
        'End': '2024-01-31'
    }
)

# コスト按分レポートの取得
cost_by_tag = ce.get_cost_and_usage(
    TimePeriod={'Start': '2024-01-01', 'End': '2024-01-31'},
    Granularity='MONTHLY',
    Filter={
        'Tags': {
            'Key': 'Environment',
            'Values': ['Production']
        }
    },
    GroupBy=[
        {'Type': 'TAG', 'Key': 'CostCenter'},
        {'Type': 'DIMENSION', 'Key': 'SERVICE'}
    ],
    Metrics=['UnblendedCost', 'UsageQuantity']
)

for result in cost_by_tag['ResultsByTime'][0]['Groups']:
    print(f"コストセンター: {result['Keys'][0]}")
    print(f"サービス: {result['Keys'][1]}")
    print(f"コスト: ${result['Metrics']['UnblendedCost']['Amount']}")

AWS Trusted Advisor の活用

Trusted Advisor 5つのカテゴリ

コスト最適化:
  ・未使用のEC2インスタンス
  ・アイドル状態のリソース（ELB/NAT Gateway等）
  ・予約済みインスタンスの最適化

パフォーマンス:
  ・EC2インスタンスの高使用率
  ・CloudFrontのコンテンツ配信最適化
  ・EBSプロビジョニングIOPSの最適化

セキュリティ:
  ・S3バケットのパブリックアクセス
  ・セキュリティグループの全開放ルール
  ・ルートアカウントのMFA未設定

耐障害性:
  ・Auto Scalingグループの最適化
  ・RDSのマルチAZ未設定
  ・S3バージョニング未設定

サービス制限:
  ・VPC制限の接近
  ・EC2インスタンス数の上限接近
  ・IAMリソース数の上限接近

試験対策: よく出る比較表

サービス比較マスターリスト

付録: SAP-C02 重要なAWSサービス一覧

ネットワーキング

• VPC: 仮想プライベートクラウド基盤
• Transit Gateway: マルチVPC/オンプレ統合ハブ
• Direct Connect: 専用線でオンプレを接続
• PrivateLink: サービスをVPC内部で安全に公開
• Route 53: DNS + ヘルスチェック + トラフィック管理
• CloudFront: グローバルCDN + セキュリティ
• Global Accelerator: グローバル静的IPでネットワーク最適化
• VPC Lattice: マイクロサービス間の通信管理

ストレージ

• S3: オブジェクトストレージ（Standard/IA/Glacier/Intelligent-Tiering）
• EBS: ブロックストレージ（EC2専用）
• EFS: マネージドNFSファイルシステム
• FSx for Windows: Windows SMBファイルシステム
• FSx for Lustre: 高性能並列ファイルシステム
• Storage Gateway: オンプレとS3を統合

データベース

• Aurora: MySQL/PostgreSQL互換高性能DB
• RDS: マネージドリレーショナルDB（6種類）
• DynamoDB: サーバーレスNoSQLキーバリューDB
• ElastiCache: マネージドRedis/Memcached
• Neptune: グラフデータベース
• Timestream: 時系列データベース
• Redshift: データウェアハウス

セキュリティ

• IAM: アイデンティティとアクセス管理
• KMS: 暗号化キー管理
• Secrets Manager: シークレット管理・自動ローテーション
• GuardDuty: 脅威インテリジェンス
• Macie: S3データ機密情報検出
• Inspector: 脆弱性スキャン（EC2/Lambda/ECR）
• Security Hub: セキュリティ集中管理
• WAF: Webアプリファイアウォール
• Shield: DDoS保護

SAP-C02 完全ガイド 全セクション追加完了

高度なサーバーレス設計パターン

API Gateway + Lambda の本番設計

本番グレードのサーバーレスAPI
┌────────────────────────────────────────────────────────────────┐
│  クライアント (Web/Mobile/Service)                              │
│              ↓ HTTPS                                           │
│  Route 53 + ACM (SSL証明書)                                    │
│              ↓                                                 │
│  CloudFront (CDN + WAF + DDoS保護)                             │
│              ↓                                                 │
│  API Gateway (REST or HTTP API)                                │
│  ├── Usage Plan + API Key (スロットリング)                      │
│  ├── Lambda Authorizer (JWT検証)                               │
│  ├── Canary Deployment (新APIバージョンテスト)                   │
│  └── VPC Link (プライベートバックエンド接続)                     │
│              ↓                                                 │
│  Lambda (Provisioned Concurrency for hot paths)               │
│  ├── Layers (共通ライブラリ)                                    │
│  ├── Power Tools (構造化ログ/X-Ray/パラメータ)                  │
│  └── VPC接続 (RDS/ElastiCache)                                │
└────────────────────────────────────────────────────────────────┘

EventBridge の高度なパターン

import boto3
import json

events = boto3.client('events')

# Event Bus ポリシー（クロスアカウントイベント受信）
events.put_permission(
    EventBusName='custom-event-bus',
    Action='events:PutEvents',
    Principal='*',
    StatementId='AllowOrgPutEvents',
    Condition={
        'Type': 'StringEquals',
        'Key': 'aws:PrincipalOrgID',
        'Value': 'o-xxxxxxxxxxxx'
    }
)

# Archive ルール（イベントのアーカイブ）
events.create_archive(
    ArchiveName='business-events-archive',
    EventSourceArn='arn:aws:events:us-east-1:123456789:event-bus/custom-event-bus',
    Description='Full event archive for replay',
    EventPattern=json.dumps({
        'source': ['com.mycompany.orders']
    }),
    RetentionDays=365
)

# アーカイブからのリプレイ
events.start_replay(
    ReplayName='replay-2024-01-15',
    Description='バグ修正後の1月15日イベントの再処理',
    EventSourceArn='arn:aws:events:us-east-1:123456789:archive/business-events-archive',
    EventStartTime='2024-01-15T00:00:00Z',
    EventEndTime='2024-01-15T23:59:59Z',
    Destination={
        'Arn': 'arn:aws:events:us-east-1:123456789:event-bus/custom-event-bus',
        'FilterArns': [
            'arn:aws:events:us-east-1:123456789:rule/custom-event-bus/process-orders-rule'
        ]
    }
)

SAP高難度シナリオ問題（上級）

シナリオ1: グローバル金融サービス

状況: 金融サービス企業が世界5リージョン（us-east-1, eu-west-1, ap-northeast-1, ap-southeast-1, sa-east-1）でActive/Active展開を計画。

• 要件: GDPR（EU）/ PIPL（中国）に準拠したデータレジデンシー
• 要件: 99.999%可用性 (5ナイン)
• 要件: PCI DSS Level 1 準拠
• 要件: RTOゼロ、RPOゼロ

推奨アーキテクチャ:

Route 53 + Global Accelerator（全リージョンへのAnycasting）
     ↓
各リージョンにフルスタック:
- CloudFront + WAF（Layer 7保護）
- ALB + ECS Fargate（アプリ層）
- DynamoDB Global Tables（データ層、Active-Active）
- ElastiCache Redis Cluster（セッション管理）
- S3 Cross-Region Replication（ファイルストレージ）
- Secrets Manager Multi-Region Replication（シークレット管理）

セキュリティ:
- AWS Security Hub（全リージョン集中管理）
- GuardDuty（全リージョン有効化）
- AWS Config Multi-Region（コンプライアンス監視）
- CloudTrail Organization Trail（集中監査）
- AWS Network Firewall（厳格なネットワーク制御）

データレジデンシー（EU向け）:
- eu-west-1 のDynamoDBデータは他リージョンにレプリケートしない
- Lake Formation でEUデータへのアクセスをEU内のみに制限
- SCPで eu-west-1 アカウントのデータ転出を禁止

シナリオ2: レガシーシステムの段階的モダナイゼーション

状況: 20年前のモノリシックJavaアプリ（500万行）のリファクタリング

段階的アプローチ（Strangler Fig パターン）:

Phase 1（Month 1-3）: Lift & Shift
  - オンプレEC2のAMI作成 → EC2への移行（Rehost）
  - ALBの前に配置してトラフィック制御の準備

Phase 2（Month 4-6）: 認証マイクロサービス化
  - 認証機能をLambda + Cognito に切り出し
  - CloudFront + Lambda@Edge で認証をエッジで処理
  - モノリスへのトラフィックは既存フロー継続

Phase 3（Month 7-12）: データ層の分離
  - オラクルDBからAurora PostgreSQLへDMSで移行
  - Read traffic を Aurora Read Replica へ移行
  - New Write APIをマイクロサービスとして切り出し

Phase 4（Month 13-18）: フロントエンドの分離
  - React SPAをS3 + CloudFrontで独立デプロイ
  - API GatewayでBack-for-Frontend(BFF)を実装

Phase 5（Month 19-24）: 残りのモノリスのサービス化
  - 機能ドメインごとにECS Fargateサービスへ分割
  - App Mesh でサービスメッシュを導入
  - 最終的にモノリスを廃止

コスト最適化の実践パターン

RI（Reserved Instance）購入戦略

RI購入戦略フレームワーク

1. ベースラインの特定
   Cost Explorer の「Reserved Instance recommendations」で
   過去30/60/90日の安定した使用量を分析

2. Standard RI vs Convertible RI
   Standard RI:
   ・特定のインスタンスタイプに固定
   ・最大72%割引
   ・1年または3年コミット
   
   Convertible RI:
   ・異なるインスタンスタイプに変換可能
   ・最大66%割引
   ・柔軟性が必要な場合

3. Savings Plans（RI代替）
   Compute Savings Plans:
   ・EC2/Lambda/Fargate全体に適用
   ・最大66%割引
   ・最も柔軟性が高い
   
   EC2 Instance Savings Plans:
   ・特定リージョン/インスタンスファミリー固定
   ・最大72%割引

4. 購入タイミング
   ・全額前払い（All Upfront）: 最大割引
   ・一部前払い（Partial Upfront）: バランス型
   ・前払いなし（No Upfront）: キャッシュフロー重視

コスト最適化 自動化

import boto3
from datetime import datetime, timedelta

# 未使用リソースの自動特定（Weekly レポート）
ce = boto3.client('ce')
ec2 = boto3.client('ec2')

# 1週間以上停止したEC2インスタンスを特定
def find_idle_instances():
    # CloudWatch メトリクスでCPU使用率が1%未満のインスタンスを検索
    cloudwatch = boto3.client('cloudwatch')
    
    instances = ec2.describe_instances(
        Filters=[{'Name': 'instance-state-name', 'Values': ['running']}]
    )
    
    idle_instances = []
    for reservation in instances['Reservations']:
        for instance in reservation['Instances']:
            # 過去7日間のCPU使用率最大値を取得
            metrics = cloudwatch.get_metric_statistics(
                Namespace='AWS/EC2',
                MetricName='CPUUtilization',
                Dimensions=[{
                    'Name': 'InstanceId',
                    'Value': instance['InstanceId']
                }],
                StartTime=datetime.utcnow() - timedelta(days=7),
                EndTime=datetime.utcnow(),
                Period=86400,
                Statistics=['Maximum']
            )
            
            max_cpu = max([m['Maximum'] for m in metrics['Datapoints']], default=0)
            
            if max_cpu < 1.0:  # CPU最大使用率が1%未満
                idle_instances.append({
                    'instance_id': instance['InstanceId'],
                    'instance_type': instance['InstanceType'],
                    'max_cpu_7d': max_cpu,
                    'tags': {tag['Key']: tag['Value'] for tag in instance.get('Tags', [])}
                })
    
    return idle_instances

idle = find_idle_instances()
for inst in idle:
    print(f"アイドルインスタンス: {inst['instance_id']} ({inst['instance_type']}) - Max CPU 7d: {inst['max_cpu_7d']:.1f}%")

SAP-C02 第3セット模擬問題（25問）

Q1. ECS タスクが RDS に接続する際に「too many connections」エラーが発生している。最小限の変更で解決するには？

• A) RDSインスタンスをより大きなサイズに変更
• B) RDS Proxyを導入してECSタスクの接続を集約
• C) DynamoDBに移行
• D) ECSサービスのタスク数を減らす

正解: B

Q2. 数千のEBSボリュームのスナップショット管理を自動化するには？

• A) Lambda + EventBridge で毎日実行
• B) AWS Backup（ライフサイクルポリシー付き）とAWS Backup Organizations統合
• C) CloudFormation で管理
• D) 手動管理のみ

正解: B

Q3. オンプレからAWSへの移行中、アプリのDNSエンドポイントを変更せずに段階的に移行するには？

• A) 全サーバーを一斉に移行
• B) Route 53 Weighted ルーティングでオンプレと AWS に段階的にトラフィックを振り分け
• C) DNSキャッシュをすべてフラッシュ
• D) ALBのみで対応

正解: B

Q4-Q25: 追加問題（短答形式）

SAP-C02 最終模擬問題セット完了 AWS Certified Solutions Architect Professional 完全学習ガイド 全コンテンツ完了

第7章: コスト最適化・財務管理

7.1 AWS Cost Management 詳細

import boto3
import json
from datetime import datetime, timedelta

# コスト配分タグ戦略
COST_ALLOCATION_TAGS = {
    'mandatory': ['Environment', 'CostCenter', 'Owner', 'Project'],
    'optional': ['Application', 'Team', 'DataClassification'],
    'automation': ['aws:createdBy', 'aws:cloudformation:stack-name']
}

# AWS Organizations Cost Management
class OrganizationalCostManager:
    def __init__(self):
        self.ce_client = boto3.client('ce', region_name='us-east-1')
        self.budgets_client = boto3.client('budgets', region_name='us-east-1')
        self.org_client = boto3.client('organizations')
    
    def get_account_costs(self, start_date, end_date, granularity='MONTHLY'):
        """アカウント別コスト分析"""
        response = self.ce_client.get_cost_and_usage(
            TimePeriod={'Start': start_date, 'End': end_date},
            Granularity=granularity,
            Metrics=['BlendedCost', 'UnblendedCost'],
            GroupBy=[
                {'Type': 'DIMENSION', 'Key': 'LINKED_ACCOUNT'},
                {'Type': 'DIMENSION', 'Key': 'SERVICE'}
            ]
        )
        return response['ResultsByTime']
    
    def create_ou_budget(self, account_id, ou_id, monthly_limit_usd):
        """OU別予算設定"""
        self.budgets_client.create_budget(
            AccountId=account_id,
            Budget={
                'BudgetName': f'OU-{ou_id}-MonthlyBudget',
                'BudgetLimit': {'Amount': str(monthly_limit_usd), 'Unit': 'USD'},
                'TimeUnit': 'MONTHLY',
                'BudgetType': 'COST',
                'CostFilters': {
                    'LinkedAccount': self.get_accounts_in_ou(ou_id)
                }
            },
            NotificationsWithSubscribers=[
                {
                    'Notification': {
                        'NotificationType': 'FORECASTED',
                        'ComparisonOperator': 'GREATER_THAN',
                        'Threshold': 80,
                        'ThresholdType': 'PERCENTAGE'
                    },
                    'Subscribers': [{
                        'SubscriptionType': 'SNS',
                        'Address': f'arn:aws:sns:us-east-1:{account_id}:CostAlerts'
                    }]
                }
            ]
        )
    
    def get_accounts_in_ou(self, ou_id):
        """OU内のアカウントリスト取得"""
        paginator = self.org_client.get_paginator('list_accounts_for_parent')
        accounts = []
        for page in paginator.paginate(ParentId=ou_id):
            accounts.extend([a['Id'] for a in page['Accounts']])
        return accounts
    
    def analyze_ri_coverage(self):
        """Reserved Instance カバレッジ分析"""
        response = self.ce_client.get_reservation_coverage(
            TimePeriod={
                'Start': (datetime.now() - timedelta(days=30)).strftime('%Y-%m-%d'),
                'End': datetime.now().strftime('%Y-%m-%d')
            },
            Granularity='MONTHLY',
            GroupBy=[{'Type': 'DIMENSION', 'Key': 'SERVICE'}]
        )
        
        coverage_data = {}
        for group in response['Total']['CoverageHours']:
            service = group.get('Attributes', {}).get('SERVICE', 'Unknown')
            coverage = float(group.get('CoverageHoursPercentage', 0))
            coverage_data[service] = coverage
        
        return coverage_data
    
    def get_rightsizing_recommendations(self):
        """EC2のリソースサイジング推薦"""
        response = self.ce_client.get_rightsizing_recommendation(
            Service='AmazonEC2',
            Configuration={
                'RecommendationTarget': 'SAME_INSTANCE_FAMILY',
                'BenefitsConsidered': True
            }
        )
        
        recommendations = []
        for rec in response['RightsizingRecommendations']:
            if rec['RightsizingType'] == 'MODIFY':
                detail = rec['ModifyRecommendationDetail']
                recommendations.append({
                    'instance_id': rec['CurrentInstance']['ResourceId'],
                    'current_type': rec['CurrentInstance']['ResourceDetails']['EC2ResourceDetails']['InstanceType'],
                    'recommended_type': detail['TargetInstances'][0]['ResourceDetails']['EC2ResourceDetails']['InstanceType'],
                    'estimated_monthly_savings': detail['TargetInstances'][0]['EstimatedMonthlySavings']['Value']
                })
        
        return recommendations

7.2 AWS Compute Optimizer

import boto3

compute_optimizer = boto3.client('compute-optimizer', region_name='us-east-1')

def get_ec2_recommendations(account_ids=None):
    """EC2インスタンスの最適化推薦"""
    
    kwargs = {
        'filters': [
            {'name': 'Finding', 'values': ['Overprovisioned', 'Underprovisioned']},
            {'name': 'RecommendationSourceType', 'values': ['Ec2Instance']}
        ]
    }
    
    if account_ids:
        kwargs['accountIds'] = account_ids
    
    response = compute_optimizer.get_ec2_instance_recommendations(**kwargs)
    
    recommendations = []
    for rec in response['instanceRecommendations']:
        recommendations.append({
            'instance_arn': rec['instanceArn'],
            'current_type': rec['currentInstanceType'],
            'finding': rec['finding'],
            'recommendations': [
                {
                    'type': r['instanceType'],
                    'performance_risk': r['performanceRisk'],
                    'rank': r['rank']
                }
                for r in rec['recommendationOptions'][:3]
            ],
            'utilization_metrics': {
                m['name']: {
                    'min': m['statistics'][0]['value'],
                    'max': m['statistics'][1]['value'],
                    'avg': m['statistics'][2]['value']
                }
                for m in rec['utilizationMetrics']
            }
        })
    
    return recommendations

def get_lambda_recommendations():
    """Lambda関数のメモリ最適化推薦"""
    response = compute_optimizer.get_lambda_function_recommendations(
        filters=[{'name': 'Finding', 'values': ['Overprovisioned', 'Underprovisioned']}]
    )
    
    return [
        {
            'function_arn': rec['functionArn'],
            'current_memory': rec['currentMemorySize'],
            'finding': rec['finding'],
            'recommended_memory': rec['memorySizeRecommendationOptions'][0]['memorySize'],
            'estimated_savings': rec['memorySizeRecommendationOptions'][0].get('estimatedMonthlySavings', {})
        }
        for rec in response['lambdaFunctionRecommendations']
    ]

第8章: ハイブリッド・マルチクラウド設計

8.1 AWS Outposts

import boto3

outposts_client = boto3.client('outposts', region_name='ap-northeast-1')
ec2_client = boto3.client('ec2', region_name='ap-northeast-1')

# Outpostリソース確認
def get_outpost_resources(outpost_id):
    response = outposts_client.list_assets(OutpostIdentifier=outpost_id)
    return response['Assets']

# Outpost サブネットにEC2インスタンス起動
def launch_instance_on_outpost(outpost_subnet_id, outpost_id):
    """オンプレミスOutpostにEC2インスタンスを起動"""
    
    response = ec2_client.run_instances(
        ImageId='ami-12345678',  # Outpost対応AMI
        InstanceType='m5.xlarge',
        MinCount=1,
        MaxCount=1,
        SubnetId=outpost_subnet_id,  # Outpostサブネット
        Placement={
            'Tenancy': 'default',
            'HostId': outpost_id  # Outpost ホスト指定
        },
        TagSpecifications=[{
            'ResourceType': 'instance',
            'Tags': [
                {'Key': 'Location', 'Value': 'OnPremises-Outpost'},
                {'Key': 'OutpostId', 'Value': outpost_id}
            ]
        }]
    )
    return response['Instances'][0]['InstanceId']

# Outpost S3アクセスポイント（Local Zone S3）
def create_outpost_s3_bucket(outpost_arn, bucket_name):
    s3_client = boto3.client('s3-outposts')
    
    response = s3_client.create_bucket(
        Bucket=bucket_name,
        OutpostId=outpost_arn
    )
    return response['BucketArn']

8.2 AWS Systems Manager Hybrid Activations

import boto3

ssm_client = boto3.client('ssm', region_name='ap-northeast-1')

# ハイブリッドアクティベーション（オンプレミスサーバー登録）
def create_hybrid_activation(registration_limit=5, iam_role=None):
    """オンプレミスサーバーをSSMに登録するためのActivationを作成"""
    
    response = ssm_client.create_activation(
        Description='OnPremises servers activation',
        DefaultInstanceName='OnPremServer',
        IamRole=iam_role or 'SSMServiceRole',  # SSMサービスロール
        RegistrationLimit=registration_limit,
        ExpirationDate='2026-12-31T00:00:00',
        Tags=[
            {'Key': 'Environment', 'Value': 'hybrid'},
            {'Key': 'Location', 'Value': 'datacenter-tokyo'}
        ]
    )
    
    return {
        'activation_id': response['ActivationId'],
        'activation_code': response['ActivationCode'],
        'registration_command': f'amazon-ssm-agent -register -code {response["ActivationCode"]} -id {response["ActivationId"]} -region ap-northeast-1'
    }

# オンプレミスサーバーへのコマンド実行
def run_command_on_hybrid(instance_ids, commands):
    """SSM管理のオンプレミスサーバー（mi-xxxxx形式）に対してコマンド実行"""
    
    response = ssm_client.send_command(
        InstanceIds=instance_ids,  # mi-xxxxx 形式
        DocumentName='AWS-RunShellScript',
        Parameters={'commands': commands},
        OutputS3BucketName='ssm-command-output',
        OutputS3KeyPrefix='hybrid-commands/'
    )
    
    return response['Command']['CommandId']

8.3 AWS Storage Gateway

┌─────────────────────────────────────────────────────────────┐
│              AWS Storage Gateway タイプ比較                   │
├──────────────────────┬──────────────────────────────────────┤
│  File Gateway        │ NFS/SMBマウントでS3にファイル保存      │
│                      │ オンプレ→S3のファイルストレージ        │
│                      │ ユースケース: バックアップ、アーカイブ  │
├──────────────────────┼──────────────────────────────────────┤
│  Volume Gateway      │ iSCSIブロックストレージとしてS3を提供  │
│  (Cached)            │ 頻繁にアクセスするデータをローカルキャッシュ│
│  (Stored)            │ データをローカルに保存、S3にバックアップ│
├──────────────────────┼──────────────────────────────────────┤
│  Tape Gateway        │ 仮想テープライブラリ（VTL）          │
│                      │ 既存テープバックアップソフトウェア互換  │
│                      │ データはS3 Glacier/Deep Archiveに保存 │
└──────────────────────┴──────────────────────────────────────┘

第9章: 高度なアイデンティティ管理

9.1 AWS IAM Identity Center 設計

import boto3

sso_admin_client = boto3.client('sso-admin', region_name='us-east-1')
identitystore_client = boto3.client('identitystore', region_name='us-east-1')

def get_sso_instance():
    response = sso_admin_client.list_instances()
    return response['Instances'][0]

instance = get_sso_instance()
instance_arn = instance['InstanceArn']
identity_store_id = instance['IdentityStoreId']

# Permission Setの作成
def create_permission_set(name, description, session_duration='PT8H'):
    response = sso_admin_client.create_permission_set(
        InstanceArn=instance_arn,
        Name=name,
        Description=description,
        SessionDuration=session_duration,  # ISO 8601 duration
        RelayState='https://console.aws.amazon.com/'
    )
    return response['PermissionSet']['PermissionSetArn']

# AWS管理ポリシーをPermission Setに添付
def attach_managed_policy_to_permission_set(permission_set_arn, policy_arn):
    sso_admin_client.attach_managed_policy_to_permission_set(
        InstanceArn=instance_arn,
        PermissionSetArn=permission_set_arn,
        ManagedPolicyArn=policy_arn
    )

# カスタムインラインポリシーをPermission Setに添付
def put_inline_policy(permission_set_arn, policy_document):
    sso_admin_client.put_inline_policy_to_permission_set(
        InstanceArn=instance_arn,
        PermissionSetArn=permission_set_arn,
        InlinePolicy=json.dumps(policy_document)
    )

# アカウントへのアクセス割り当て（グループベース）
def assign_group_access(account_id, permission_set_arn, group_id):
    sso_admin_client.create_account_assignment(
        InstanceArn=instance_arn,
        TargetId=account_id,
        TargetType='AWS_ACCOUNT',
        PermissionSetArn=permission_set_arn,
        PrincipalType='GROUP',
        PrincipalId=group_id
    )

# グループの作成
def create_group(group_name, description):
    response = identitystore_client.create_group(
        IdentityStoreId=identity_store_id,
        DisplayName=group_name,
        Description=description
    )
    return response['GroupId']

# ユーザーをグループに追加
def add_user_to_group(user_id, group_id):
    identitystore_client.create_group_membership(
        IdentityStoreId=identity_store_id,
        GroupId=group_id,
        MemberId={'UserId': user_id}
    )

# 権限管理の自動化（新アカウントに標準ロールを自動付与）
def setup_standard_account_access(new_account_id):
    """新しいアカウントに標準権限セットを自動付与"""
    
    standard_assignments = [
        {
            'permission_set': 'ViewOnlyAccess',
            'policy_arn': 'arn:aws:iam::aws:policy/job-function/ViewOnlyAccess',
            'groups': ['all-developers', 'all-ops']
        },
        {
            'permission_set': 'PowerUserAccess',
            'policy_arn': 'arn:aws:iam::aws:policy/PowerUserAccess',
            'groups': ['senior-engineers']
        },
        {
            'permission_set': 'AdministratorAccess',
            'policy_arn': 'arn:aws:iam::aws:policy/AdministratorAccess',
            'groups': ['cloud-admins']
        }
    ]
    
    for assignment in standard_assignments:
        ps_arn = create_permission_set(
            assignment['permission_set'],
            f'Standard {assignment["permission_set"]} for account {new_account_id}'
        )
        attach_managed_policy_to_permission_set(ps_arn, assignment['policy_arn'])
        
        for group_name in assignment['groups']:
            group_id = get_group_id_by_name(group_name)
            if group_id:
                assign_group_access(new_account_id, ps_arn, group_id)

9.2 クロスアカウントアクセス設計

import boto3
import json

# アカウントA: リソースアカウント（S3バケット所有者）
def setup_cross_account_s3_access(bucket_name, consumer_account_id):
    s3_client = boto3.client('s3')
    
    # バケットポリシーで他アカウントへのアクセスを許可
    bucket_policy = {
        'Version': '2012-10-17',
        'Statement': [
            {
                'Sid': 'CrossAccountAccess',
                'Effect': 'Allow',
                'Principal': {
                    'AWS': f'arn:aws:iam::{consumer_account_id}:role/CrossAccountRole'
                },
                'Action': [
                    's3:GetObject',
                    's3:ListBucket',
                    's3:PutObject'
                ],
                'Resource': [
                    f'arn:aws:s3:::{bucket_name}',
                    f'arn:aws:s3:::{bucket_name}/*'
                ],
                'Condition': {
                    'StringEquals': {
                        'aws:PrincipalOrgID': 'o-example12345'  # 組織内のみ
                    }
                }
            }
        ]
    }
    
    s3_client.put_bucket_policy(
        Bucket=bucket_name,
        Policy=json.dumps(bucket_policy)
    )

# アカウントB: 消費者アカウント（AssumeRoleでアクセス）
def assume_role_and_access_s3(role_arn, bucket_name, object_key):
    sts_client = boto3.client('sts')
    
    # 一時認証情報の取得（最大12時間）
    assumed_role = sts_client.assume_role(
        RoleArn=role_arn,
        RoleSessionName='CrossAccountS3Access',
        DurationSeconds=3600,
        ExternalId='unique-external-id-12345',  # セキュリティ強化
        Tags=[
            {'Key': 'Department', 'Value': 'Engineering'},
            {'Key': 'Purpose', 'Value': 'DataAnalysis'}
        ]
    )
    
    credentials = assumed_role['Credentials']
    
    # 一時認証情報でS3クライアント作成
    s3_client = boto3.client(
        's3',
        aws_access_key_id=credentials['AccessKeyId'],
        aws_secret_access_key=credentials['SecretAccessKey'],
        aws_session_token=credentials['SessionToken']
    )
    
    response = s3_client.get_object(Bucket=bucket_name, Key=object_key)
    return response['Body'].read()

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

問題1 AWS Control Towerで新しいOUを作成する際に自動適用されるガードレールの種類は？

A) 予防的ガードレールのみ B) 検出的ガードレールのみ C) 予防的ガードレール（SCP）と検出的ガードレール（AWS Config）の両方 D) ガードレールは手動で適用する必要がある

正解: C 解説: Control Towerガードレール: 予防的（Preventive）: SCP（Service Control Policies）で特定のアクションを禁止。必須（Mandatory）と強く推奨（Strongly Recommended）がある。検出的（Detective）: AWS Config Rulesでコンプライアンス違反を検出。オプションの推奨も含む。新しいOUの登録時に必須ガードレールが自動適用される。

問題2 AWS Organizationsのサービスコントロールポリシー（SCP）の「DenyList」と「AllowList」戦略の違いは？

A) DenyListはより安全で常に推奨される B) DenyList: FullAWSAccess付与後に特定アクションを拒否（デフォルト許可に例外を追加）。AllowList: FullAWSAccessなしに特定アクションのみ許可（デフォルト拒否） C) AllowListはより多くのSCPが必要になる D) DenyListはOUレベルでのみ使用可能

正解: B 解説: SCP戦略: DenyList（推奨）: まずFullAWSAccess（全許可）を適用し、禁止したいアクションをExplicitDenyで追加。管理が容易で新サービスにも対応。AllowList: デフォルトのFullAWSAccessを削除し、明示的なAllowリストのみ付与。最小権限だが新しいサービスが使えなくなるリスク。ほとんどの組織でDenyListを推奨。

問題3 マルチアカウント環境でCloudFormation StackSetsを使用する際の「SELF_MANAGED」と「SERVICE_MANAGED」の違いは？

A) SELF_MANAGEDはより安全 B) SELF_MANAGED: 管理者・実行IAMロールを手動作成が必要。SERVICE_MANAGED: Organizations統合で自動権限管理、OU全体への自動デプロイ対応 C) SERVICE_MANAGEDはCloudFormationの古いモード D) 機能的な違いはない

正解: B 解説: StackSets権限モード: SELF_MANAGED: AWSCloudFormationStackSetAdministrationRoleとAWSCloudFormationStackSetExecutionRoleを各アカウントで手動作成。Organizations外の単独アカウントにも対応。SERVICE_MANAGED: Organizationsサービス連携ロールで自動管理。新しいOUメンバーへの自動デプロイ（AutoDeployment）が可能。OU/タグベースのターゲット指定。

問題4 Transit Gatewayを使用したスポーク間通信（VPC-to-VPC）のルーティング設計で、開発・本番の分離を実現する方法は？

A) 各VPCに個別のInternet Gatewayを設定する B) TGWルートテーブルを環境別に分離し、開発VPCと本番VPCのアタッチメントを別ルートテーブルに関連付けて相互ルートを追加しない C) NACLでVPC間通信をブロックする D) セキュリティグループのみで制御する

正解: B 解説: TGWルートテーブル分離: 本番ルートテーブル→本番VPCアタッチメントのルートのみ含む。開発ルートテーブル→開発VPCアタッチメントのルートのみ含む。共有サービスVPC（DNS、AD等）のルートは両方のルートテーブルに追加。このアーキテクチャでDev→Prod通信はルーティング不可になりTGWレベルで分離を実現。

問題5 AWS Configのアグリゲーター（Aggregator）の目的は？

A) Config評価を高速化する B) 複数アカウント・複数リージョンのConfig結果を単一アカウントに集約して組織全体のコンプライアンスを可視化 C) ConfigルールをOrganizations全体に自動デプロイする D) Configデータを低コストのS3 Glacierに保存する

正解: B 解説: AWS Config Aggregator: Organizations管理アカウントから設定することで全メンバーアカウント・全リージョンのConfig評価結果を集約ビューで確認。コンプライアンスダッシュボードの一元化が可能。注意: Aggregatorはデータ集約のみ。ルールのデプロイはOrganizational Config Rules（CloudFormation StackSets経由）で別途設定。

問題6 AWS Lambdaのデプロイ方法の中で、最もゼロダウンタイムに近いトラフィック移行はどれですか？

A) Lambda関数の全置換（デプロイ後すべてのリクエストが新バージョンへ） B) Lambda関数のエイリアスとトラフィック重み付け（Weighted Alias）を使用したカナリアデプロイ C) Lambda関数の並列実行を増やす D) CloudFront OriginGroupで新旧Lambdaをフェイルオーバー設定

正解: B 解説: Lambda Weighted Alias: エイリアス（本番）に新バージョンを追加して重み（例: 10%→50%→100%）を徐々に変更。AWS CodeDeployのLambaデプロイ設定: CodeDeployDefault.LambdaLinear10PercentEvery1Minute等でトラフィックを自動的に増加。アラームと組み合わせた自動ロールバック（AutoRollback設定）も可能。

問題7 マルチリージョン Active-Active アーキテクチャで Route 53 Latency Routing を使用する場合の課題は？

A) Route 53がDNSキャッシュを使用するため即時フェイルオーバーができない（TTL分遅延） B) Latency Routingは1リージョンのみ対応 C) Route 53はHTTPS通信のみサポート D) 同一リージョンに複数のエンドポイントを設定できない

正解: A 解説: Route 53のフェイルオーバー遅延: DNS TTL（30秒〜5分）とクライアントのDNSキャッシュにより即時切り替えが困難。対策: ①TTLを短縮（30秒以下）→リゾルバーへの負荷増加②AWS Global Accelerator使用（Anycastでのルーティングはエニーキャストのため即時切り替え）③ヘルスチェックの評価間隔を最短10秒に設定。

問題8 AWS Well-Architected FrameworkのReliabilityの柱で推奨される「カオスエンジニアリング」ツールは？

A) AWS Fault Injection Simulator (FIS) B) AWS CloudFormation ドリフト検出 C) AWS Config コンプライアンス評価 D) CloudWatch アラーム

正解: A 解説: AWS Fault Injection Simulator（FIS）: 制御されたカオスエンジニアリング実験を実行。EC2の強制終了、RDSフェイルオーバー、レイテンシー注入（EC2ネットワーク遅延）、CPU/メモリ負荷注入等のアクションを実験として定義し実行。Stop条件（CloudWatchアラーム）でリスク制御。本番環境での弾力性テストに活用。

問題9 AWS Lake Formation で外部アカウントとデータを共有する際の推奨アーキテクチャは？

A) S3バケットポリシーのみで共有 B) AWS RAM（Resource Access Manager）でGlue Catalogリソースを共有し、Lake Formation権限で細かいアクセス制御 C) クロスアカウントIAMロールのみで制御 D) データをコピーしてコンシューマーアカウントのS3に保存

正解: B 解説: Lake Formation クロスアカウント共有: プロデューサーアカウントがRAMを使用してGlue Database/TableリソースをコンシューマーアカウントまたはOrganization全体に共有。コンシューマーはRAM招待を受け入れ後、Lake FormationのGRANT PERMISSIONSでアクセス権限を付与。データはプロデューサーのS3に残り、コンシューマーはAthenaCrossAccount経由でクエリ可能。

問題10 EKSのPod Security Standards（PSS）とは何ですか？

A) Kubernetesのセキュリティグループ設定 B) Podの実行権限を制限する3つのポリシーレベル（Privileged/Baseline/Restricted）のKubernetes標準 C) EKSクラスターのネットワークポリシー D) EKSノードのIAMポリシー

正解: B 解説: Pod Security Standards（PSS）: Kubernetes 1.25でPodSecurityPolicyの後継として導入。3レベル: Privileged（制限なし、信頼されたワークロード用）、Baseline（最小限の制限、既知の権限昇格を防止）、Restricted（ベストプラクティス準拠、最も厳格）。名前空間レベルでpod-security.kubernetes.io/enforce: restricted等のラベルで適用。

問題11 AWS Service Catalog の主な使用目的は？

A) AWSサービスのコスト比較 B) 承認済みのAWSリソース構成（Product）をセルフサービスプロビジョニングで一般ユーザーに提供し、ガバナンスを維持 C) AWSマーケットプレイスとの統合 D) カスタムコストアラートの作成

正解: B 解説: AWS Service Catalog: CloudFormationテンプレートを「製品（Product）」として登録し、「ポートフォリオ（Portfolio）」でまとめてユーザー/グループに配布。ユーザーは承認済みの構成のみをセルフサービスで起動できる。IT管理者はテンプレートを標準化（セキュリティ設定、タグ付け、コスト割り当て）してガバナンスを確保。

問題12 AWS Backupでクロスアカウントバックアップを設定する目的は？

A) バックアップをより高速にコピーするため B) ランサムウェアや誤削除からの保護（バックアップアカウントを隔離してメインアカウントの侵害から保護） C) バックアップコストを削減するため D) バックアップを圧縮するため

正解: B 解説: クロスアカウントバックアップ（AWS Backup）: バックアップデータを別AWSアカウント（バックアップ専用アカウント）にコピー。主なアカウントが侵害されてもバックアップが保護される。AWS Organizations統合でOrganizations全体のバックアップポリシーを一元管理し、クロスアカウントコピーを自動化。SCP（サービスコントロールポリシー）でバックアップの削除を禁止する追加保護も可能。

問題13 Amazon EventBridge Event Busのアーキテクチャで、クロスアカウントイベント転送の実装方法は？

A) CloudWatch Logsのクロスアカウントサブスクリプション B) ソースアカウントのEventBridgeルールでターゲットに別アカウントのEvent Bus ARNを指定し、ターゲットアカウントのEvent BusリソースポリシーでPutEventsを許可 C) SNSクロスアカウントサブスクリプションを使用する D) EventBridgeはクロスアカウント転送をサポートしない

正解: B 解説: EventBridgeクロスアカウント: ①ターゲットアカウントのEvent BusにリソースポリシーでPutEvents権限を付与（ソースアカウントのARNまたはOrgID条件で制限）②ソースアカウントのルールにターゲットとしてターゲットアカウントのEvent Bus ARNを指定。クロスリージョンも同様の手順。Organizations全体のAuditアカウントへのイベント集約に有用。

問題14 AWS Organizationsの「委任管理者（Delegated Administrator）」の概念は？

A) Organizations管理アカウントの権限を別アカウントに完全委譲する B) 特定のAWSサービス（Security Hub、GuardDuty等）の管理を、管理アカウント以外のメンバーアカウントに委任する機能 C) IAMユーザーへの管理者権限委任 D) CloudFormation StackSetsの実行権限の委任

正解: B 解説: 委任管理者: 各AWSサービスの組織全体管理をセキュリティ/監査専用アカウントに委任可能。例: Security Hubの委任管理者→セキュリティアカウント。AWS Config Aggregatorの委任→Auditorアカウント。Organizations管理アカウントで敏感な操作を減らせる。対応サービス: Security Hub、GuardDuty、Macie、Inspector、Firewall Manager、Config等。

問題15 大規模なマルチリージョンアーキテクチャでRoute 53のアクティブ-アクティブ設定に必要な要素は？

A) 各リージョンに同一のEC2インスタンスを起動するだけ B) ヘルスチェック、Latency/Weighted Routing、データレイヤーのマルチリージョン対応（DynamoDB Global Tables等）、CloudFrontエッジキャッシング C) Route 53以外のロードバランサーは不要 D) アクティブ-アクティブはAWS内部サービスでのみ可能

正解: B 解説: Active-Active マルチリージョン要件: ①DNS: Route 53 Latency/Weighted Routing + HealthCheck②計算: 各リージョンにECS/EKS/Lambdaスタック③データ: DynamoDB Global Tables（マルチ書き込み）またはAurora Global Database④セッション: ElastiCache Global Datastore（Redis）またはDynamoDB⑤CDN: CloudFront（静的コンテンツ）⑥グローバルレート制限: AWS WAF with Global Rulesets。

問題16 AWS CloudTrail Lakeを従来のCloudTrailと比較した際の主な利点は？

A) CloudTrail Lakeの方が常に安価 B) CloudTrail Lakeはイベントデータを最大7年間保持し、SQLでリアルタイム分析が可能。S3エクスポートやAthenaの設定不要 C) CloudTrail Lakeはリアルタイムアラートをサポートしない D) CloudTrail Lakeは特定のサービスのみ対応

正解: B 解説: CloudTrail Lake vs 従来CloudTrail: 従来: イベントをS3に保存→S3+Athenaで分析（設定が複雑）→保持期間は手動管理。CloudTrail Lake: マネージドなデータレイクとして最大7年保持→コンソールまたはAPIで直接SQLクエリ→複数アカウント・OUのログを自動統合→Event Data Storeで複数のソース（CloudTrail、Config、Security Hub等）を統合分析可能。

問題17 Amazon GuardDuty Malware Protectionの機能は？

A) Lambdaのコードをスキャンする B) EBS volumeのマルウェアスキャン（EC2インスタンスのEBSボリュームをエージェントレスでスキャン） C) S3バケットのHTTPSエンドポイント保護 D) ネットワークトラフィックのマルウェア検出のみ

正解: B 解説: GuardDuty Malware Protection: EC2インスタンスやECSのEBSボリュームをエージェントレス（インスタンス停止不要）でスキャン。スキャントリガー: ①GuardDuty FindingによるOn-demand（悪意あるIPとの通信検出後）②S3のオブジェクトアップロード時のスキャン（Malware Scan for S3）。検出後は自動隔離（EventBridge + Lambda）が推奨パターン。

問題18 AWS Organizations でサービス連携ロール（SLR: Service-Linked Role）が自動作成される仕組みは？

A) 管理アカウントで手動作成する必要がある B) AWSサービスが特定機能を有効化した際にサービス専用のIAMロールを自動作成（信頼ポリシーはサービスに固定、権限は変更不可） C) CloudFormationで明示的に定義が必要 D) SLRはOrganizationsでは使用できない

正解: B 解説: Service-Linked Role（SLR）: AWSサービスが特定機能のために自動作成する特別なIAMロール。例: ElasticLoadBalancing.amazonaws.comが必要とするAWSServiceRoleForElasticLoadBalancing。特徴: ①AWSサービスの信頼ポリシーに固定②サービスに最小権限で事前定義③手動で作成/削除は可能だが権限の変更は不可④サービスが使用中は削除不可。

問題19 SageMaker Feature Storeを使用する主な理由は？

A) モデルのデプロイを高速化するため B) 機械学習の特徴量をオンライン（低レイテンシー）とオフライン（バッチ）の両方で再利用可能な形で一元管理するため C) SageMakerのコストを削減するため D) ノートブックのバージョン管理のため

正解: B 解説: SageMaker Feature Store: オンラインストア（DynamoDB: <1msレイテンシー、リアルタイム推論向け）とオフラインストア（S3: バッチ学習・バックフィル向け）の2層構造。特徴: ①チームをまたいだ特徴量の再利用②特徴量の一貫性（学習と推論で同じ変換を保証）③タイムトラベル（過去の特徴量を学習に使用）④特徴量カタログ（メタデータ管理）。MLOpsの重要コンポーネント。

問題20 AWS Migration Hub Orchestratorの主な機能は？

A) AWSへの移行コストを自動試算する B) アプリケーション移行のワークフロー（再ホスト・リプラットフォーム等）を定義・自動化・追跡する移行オーケストレーションサービス C) オンプレミスサーバーの自動検出 D) 移行後のコスト最適化

正解: B 解説: AWS Migration Hub Orchestrator: 移行プロセスを定義されたテンプレートまたはカスタムワークフローとして自動化。統合サービス: AWS Application Migration Service（MGN）、AWS Database Migration Service（DMS）、CloudEndure等。移行ステップ（Discovery→Test→Cutover）を可視化し、進捗追跡。大規模移行（100台以上）での一元管理に有用。

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

ドメイン1: 組織の複雑さに対する設計 (26%)

• [ ] Organizations（OU構造、SCP、委任管理者）
• [ ] Control Tower（Landing Zone、ガードレール、アカウントファクトリー）
• [ ] IAM Identity Center（Permission Sets、グループマッピング）
• [ ] クロスアカウントアクセス（AssumeRole、外部ID）
• [ ] CloudFormation StackSets（SELF_MANAGED vs SERVICE_MANAGED）
• [ ] Service Catalog（承認済みリソースの配布）
• [ ] AWS Config Aggregator（マルチアカウント集約）

ドメイン2: 新しいソリューションの設計 (29%)

• [ ] Transit Gateway（ルートテーブル、アタッチメント、RAM共有）
• [ ] Direct Connect（冗長設計、LAG、BGP）
• [ ] Site-to-Site VPN + DX バックアップ
• [ ] Global Accelerator vs CloudFront の使い分け
• [ ] Aurora Global Database（フェイルオーバー、RPO/RTO）
• [ ] DynamoDB Global Tables（LWW競合解決）
• [ ] Route 53 Resolver（DNS Firewall、フォワーダー）

ドメイン3: 移行の計画と実行 (15%)

• [ ] AWS Migration Evaluation（7R: リタイア、保持、リホスト、リプラットフォーム、リファクタリング、リパーチェス、リロケート）
• [ ] AWS DMS（CDCレプリケーション）
• [ ] AWS Application Migration Service（MGN）
• [ ] AWS DataSync（オンプレ→S3/EFS）
• [ ] Snow Family（Snowcone、Snowball、Snowmobile）

ドメイン4: コスト最適化 (20%)

• [ ] AWS Cost Explorer（Savings Plans推薦、リサイジング推薦）
• [ ] AWS Compute Optimizer（EC2/Lambda/EBS最適化）
• [ ] Reserved Instance vs Savings Plans
• [ ] Spot Instances（スポットフリート、中断対応）
• [ ] Storage コスト最適化（S3 Intelligent-Tiering、Lifecycle）

ドメイン5: 継続的改善 (10%)

• [ ] Well-Architected Framework（5つの柱）
• [ ] AWS Fault Injection Simulator（カオスエンジニアリング）
• [ ] CloudTrail Lake（ログ分析）
• [ ] AWS Health Dashboard（サービスイベント通知）

第10章: 高度なセキュリティ設計

10.1 ゼロトラストアーキテクチャ

┌─────────────────────────────────────────────────────────────┐
│            ゼロトラスト アーキテクチャ原則                    │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  「信頼せず、常に検証する（Never Trust, Always Verify）」    │
│                                                             │
│  ┌──────────────────────────────────────────────────────┐   │
│  │  従来のペリメーターセキュリティ                         │   │
│  │  内部ネットワーク = 信頼                               │   │
│  │  外部ネットワーク = 不信頼                             │   │
│  └──────────────────────────────────────────────────────┘   │
│                                                             │
│  ┌──────────────────────────────────────────────────────┐   │
│  │  ゼロトラスト                                          │   │
│  │  ・すべてのアクセスを明示的に検証                      │   │
│  │  ・最小権限アクセス                                    │   │
│  │  ・侵害を想定した設計                                  │   │
│  │  ・マイクロセグメンテーション                          │   │
│  └──────────────────────────────────────────────────────┘   │
│                                                             │
│  AWS実装:                                                   │
│  ・IAM Identity Center（認証）                              │
│  ・AWS Verified Access（ネットワーク不要のアプリアクセス）   │
│  ・VPC Security Groups（マイクロセグメンテーション）         │
│  ・CloudTrail + GuardDuty（継続的監視）                     │
│  ・Secrets Manager（シークレット管理）                       │
└─────────────────────────────────────────────────────────────┘

import boto3

# AWS Verified Access (ゼロトラストアプリアクセス)
def setup_verified_access(app_endpoint, trust_provider_arn):
    """VPNなしで企業アプリへのゼロトラストアクセスを設定"""
    
    ec2_client = boto3.client('ec2')
    
    # Verified Access インスタンス作成
    va_instance = ec2_client.create_verified_access_instance(
        Description='Enterprise ZeroTrust Access',
        Tags=[{'Key': 'Name', 'Value': 'Enterprise-VA'}]
    )
    va_instance_id = va_instance['VerifiedAccessInstance']['VerifiedAccessInstanceId']
    
    # Trust Provider のアタッチ（IAM Identity Center等）
    ec2_client.attach_verified_access_trust_provider(
        VerifiedAccessInstanceId=va_instance_id,
        VerifiedAccessTrustProviderId=trust_provider_arn
    )
    
    # Verified Access グループ作成（アクセスポリシー定義）
    va_group = ec2_client.create_verified_access_group(
        VerifiedAccessInstanceId=va_instance_id,
        Description='Engineering Team Access',
        PolicyDocument="""
        permit(principal, action, resource)
        when {
            context.identity.groups.contains("Engineering") &&
            context.device.is_managed == true &&
            context.risk.score < 50
        };
        """
    )
    va_group_id = va_group['VerifiedAccessGroup']['VerifiedAccessGroupId']
    
    # エンドポイント作成（内部ALBをVerified Access経由で公開）
    va_endpoint = ec2_client.create_verified_access_endpoint(
        VerifiedAccessGroupId=va_group_id,
        EndpointType='load-balancer',
        AttachmentType='vpc',
        LoadBalancerOptions={
            'Protocol': 'https',
            'Port': 443,
            'LoadBalancerArn': app_endpoint,
            'SubnetIds': ['subnet-12345678', 'subnet-87654321']
        },
        SseSpecification={'CustomerManagedKeyEnabled': True}
    )
    
    return va_endpoint

10.2 セキュリティレイクハウス（Amazon Security Lake）

import boto3

# Amazon Security Lake セットアップ
def setup_security_lake():
    sl_client = boto3.client('securitylake', region_name='us-east-1')
    
    # Security Lake の有効化（OCSF形式でセキュリティログを統合）
    response = sl_client.create_data_lake(
        configurations=[
            {
                'region': 'ap-northeast-1',
                'encryptionConfiguration': {
                    'kmsKeyId': 'arn:aws:kms:ap-northeast-1:123456789012:key/key-id'
                },
                'lifecycleConfiguration': {
                    'transitions': [
                        {
                            'days': 60,
                            'storageClass': 'ONEZONE_IA'
                        }
                    ],
                    'expiration': {'days': 365}
                },
                'replicationConfiguration': {
                    'regions': ['us-east-1'],  # クロスリージョンレプリケーション
                    'roleArn': 'arn:aws:iam::123456789012:role/SecurityLakeReplicationRole'
                }
            }
        ],
        metaStoreManagerRoleArn='arn:aws:iam::123456789012:role/SecurityLakeMetastoreManagerRole'
    )
    
    return response

# ソースの追加（AWS標準ソース）
def add_aws_sources():
    sl_client = boto3.client('securitylake', region_name='us-east-1')
    
    sl_client.create_aws_log_source(
        sources=[
            {
                'account': '123456789012',
                'regions': ['ap-northeast-1', 'us-east-1'],
                'sourceName': 'ROUTE53',
                'sourceVersion': '2.0'
            },
            {
                'account': '123456789012',
                'regions': ['ap-northeast-1'],
                'sourceName': 'VPC_FLOW',
                'sourceVersion': '2.0'
            },
            {
                'account': '123456789012',
                'regions': ['ap-northeast-1'],
                'sourceName': 'CLOUD_TRAIL_MGMT',
                'sourceVersion': '2.0'
            },
            {
                'account': '123456789012',
                'regions': ['ap-northeast-1'],
                'sourceName': 'SH_FINDINGS',
                'sourceVersion': '2.0'
            }
        ]
    )

追加模擬問題（10問）

問題A AWS Well-Architected Frameworkの6つの柱として正しいのはどれですか？

A) 可用性、スケーラビリティ、信頼性、セキュリティ、パフォーマンス、コスト B) 運用上の優秀性、セキュリティ、信頼性、パフォーマンス効率性、コスト最適化、サステナビリティ C) 可用性、障害耐性、セキュリティ、コスト効率性、スケーラビリティ、監視 D) セキュリティ、可用性、パフォーマンス、スケーラビリティ、回復力、コスト

正解: B 解説: AWS Well-Architected Frameworkの6柱（2021年にSustainabilityが追加）: ①運用上の優秀性（Operational Excellence）②セキュリティ（Security）③信頼性（Reliability）④パフォーマンス効率性（Performance Efficiency）⑤コスト最適化（Cost Optimization）⑥サステナビリティ（Sustainability）。旧5柱にSustainabilityが追加された。

問題B AWS Security Hubの「ASFF（Amazon Security Finding Format）」とは？

A) AWS独自のログ形式 B) Security Hubが使用する標準化されたセキュリティ検出結果のJSONスキーマ（AWS・パートナー・カスタムのfindingsを統一） C) AWS CloudTrailのログ形式 D) GuardDutyの脅威インテリジェンス形式

正解: B 解説: ASFF（Amazon Security Finding Format）: Security Hubが使用するセキュリティ検出結果の標準JSON形式。GuardDuty、Inspector、Macie、サードパーティ製品等のfindingsをASFF形式に統一して管理。フィールド: SchemaVersion、ProductArn、Resources、Severity、Workflow、Remediation等。Security Hub管理者アカウントでOrganizations全体のASFF findingsを集約分析可能。

問題C Amazon Inspector V2 が従来のInspector V1と異なる主な機能は？

A) Inspector V2はEC2のみ対応 B) Inspector V2はエージェントレスでECRコンテナイメージのスキャン、Lambda関数のコードスキャン、継続的評価に対応 C) Inspector V2はスキャン費用が高い D) Inspector V2はOrganizations非対応

正解: B 解説: Inspector V2の改善点: ①エージェントレス（SSM Agentのみ必要）②ECRコンテナイメージの脆弱性スキャン③Lambda関数のコードと依存関係スキャン④継続的評価（リアルタイムで新しいCVEを評価）⑤Organizations統合（全アカウント一括有効化）⑥Security Hubとの自動統合⑦リスクスコア（CVSS + エクスポージャー情報）。

問題D AWS Fault Injection Simulator（FIS）を使用したカオスエンジニアリングの「Stop Condition」の目的は？

A) 実験を即座に停止するタイミングをLambda関数で制御するため B) CloudWatchアラーム等の条件が満たされた場合に自動的に実験を停止して、本番への影響を限定するセーフガード C) FIS実験のスケジュール管理のため D) テスト環境でのみ実験を実行するための制御

正解: B 解説: FIS Stop Condition: 実験実行中にCloudWatchアラームがALARMになった場合、FISが自動的に実験を停止（アクションのロールバック）するセーフガード。例: エラー率が5%を超えたらStop。本番カオス実験での最重要安全機能。設定: アラームARNと実験への適用タイミング（Before/After/Any）。Stop Conditionなしでの本番実験は非推奨。

問題E Amazon Macie の「分類ジョブ」と「自動検出」の違いは？

A) 違いはない B) 分類ジョブ: 手動でスキャンスコープ（バケット・プレフィックス）を指定してオンデマンドまたはスケジュール実行。自動検出: 全S3バケットをMacieが継続的に監視してPII/機密データをサンプリング検出 C) 自動検出はより深いスキャンを実行する D) 分類ジョブはコストが無料

正解: B 解説: Macie分類方法: ①自動検出（Automated Discovery）: すべてのS3バケットを毎日サンプリングスキャン（全オブジェクトの一部を検査）→バケットの機密度ランキングを自動生成。②分類ジョブ: 特定バケット/プレフィックスに対して100%スキャンを実行。PCI-DSS/HIPAAコンプライアンス要件での完全スキャンに使用。コスト: オブジェクト数に比例。

問題F AWS Private Certificate Authority（PCA）の主な使用目的は？

A) パブリックSSL証明書の無料発行 B) 企業内部向けのプライベートPKI（証明書認証局）をAWS上で構築・管理し、内部サービスのmTLSや内部ドメイン証明書を発行 C) AWS Certificate Manager(ACM)の代替サービス D) コードサイニング証明書の発行

正解: B 解説: AWS Private CA: エンタープライズPKI向け。ルートCAまたは下位CAとして機能。用途: ①マイクロサービス間mTLS（相互TLS認証）②VPN/IoTデバイス証明書③内部Webサービス証明書（ACMと統合してALBに自動配布）④Kubernetes（cert-manager統合）。ACM Private CAから名称変更。年間$400/CA + 発行証明書数に応じた費用。

問題G AWS Network Access Analyzer の目的は？

A) VPCフローログの解析ツール B) VPCのネットワーク設定を分析し、予期しないネットワークアクセスパス（例: インターネットから直接プライベートEC2へのパス）を特定 C) CloudWatchのネットワークメトリクス監視 D) Direct Connectの帯域幅最適化

正解: B 解説: Network Access Analyzer: VPCのルートテーブル、セキュリティグループ、NACLなどの設定を分析して、定義したポリシーに違反するネットワークパスを発見。例: 「インターネットゲートウェイからプライベートサブネットのEC2への直接パスが存在する」等を検出。VPC Reachability Analyzerは特定の2点間のパスをデバッグ。Network Access Analyzerは組織全体の意図しないアクセスを網羅的に検出。

問題H SageMaker MLOpsでモデルの「ドリフト」を継続的に監視する機能は？

A) SageMaker Experiments B) SageMaker Model Monitor（データドリフト、モデル品質、バイアスドリフトを本番エンドポイントで継続監視） C) SageMaker Debugger D) SageMaker Feature Store

正解: B 解説: SageMaker Model Monitor 4種類: ①Data Quality Monitor: 入力データの統計的ドリフト検出（平均・分散・欠損値等）②Model Quality Monitor: 予測精度の低下検出（精度・AUC等）③Bias Drift Monitor: バイアス指標の変化検出④Explainability Monitor: 特徴量重要度の変化検出。スケジュール実行でS3の推論ログと基準値を比較し、CloudWatchアラームと統合。

問題I Amazon EKS のCluster Autoscalerと Karpenterの主な違いは？

A) KarpenterはEC2インスタンスの管理をしない B) Cluster Autoscaler: ASGベース（事前定義ノードグループ）でスケール。Karpenter: ASG不要でEC2を直接プロビジョニング（より高速・柔軟・コスト効率） C) KarpenterはFargateのみ対応 D) 機能に違いはない

正解: B 解説: Karpenter vs Cluster Autoscaler: Cluster Autoscaler: AWS Auto Scaling Group経由でノード追加→ノードグループとインスタンスタイプを事前定義→スケールに数分かかる場合がある。Karpenter: AWSのEC2 Fleet APIを直接呼び出し→Podの要件（CPU/Memory/GPU/Spot等）に合わせて最適なインスタンスタイプを動的選択→30秒以内にノード追加。Spotインスタンスのコスト最適化にも優れる。

問題J AWS Application Migration Service（AWS MGN）の「Test Mode」と「Cutover Mode」の違いは？

A) Test Modeはコストが高い B) Test Mode: 本番トラフィックに影響なく移行後のインスタンスをテスト環境として起動・検証。Cutover Mode: テスト完了後に実際の本番移行（ソースサーバーの停止）を実行 C) Cutover Modeはデータを削除する D) 両方とも同じ動作をする

正解: B 解説: AWS MGN（Application Migration Service）移行フロー: ①Replication: ソースサーバーのデータを継続的にAWSにレプリケーション②Launch Test Instance: テストモードで移行先インスタンスを起動→動作確認③Launch Cutover Instance: カットオーバーモードで本番移行→ソースサーバーを停止④ファイナライズ: ターゲットインスタンスをクリーンアップして通常のEC2インスタンスに変換。Test Modeは何度でも繰り返し可能。

SAP 追加学習: 設計判断マトリクス

┌─────────────────────────────────────────────────────────────┐
│              SAP試験 設計パターン決定表                       │
├──────────────────────────────────────────────────────────────┤
│ シナリオ                    │ 推奨ソリューション              │
├──────────────────────────────────────────────────────────────┤
│ 大規模ファイル転送           │ DataSync, Snow Family          │
│ リアルタイムデータレプリケ   │ DMS CDC + Kinesis              │
│ アプリの段階的移行           │ AWS MGN (Server Migration)     │
│ データベース移行             │ AWS DMS                        │
│ オンプレ→AWSの定期バックアップ│ Storage Gateway + Backup       │
│ 複数アカウント SSO           │ IAM Identity Center            │
│ 組織全体のセキュリティ統制   │ Control Tower + SCPs           │
│ グローバルアクセラレーション  │ Global Accelerator > CloudFront│
│ VPN + DX 冗長化             │ VPN over DX (BGP AS PATH)      │
│ コンテナ化マイクロサービス   │ EKS + Karpenter + Service Mesh │
│ サーバーレス高可用性         │ Lambda + DynamoDB Global Tables │
│ 大規模分析ワークロード       │ EMR on EC2/Serverless + S3     │
└──────────────────────────────────────────────────────────────┘