目次

AWS Certified Solutions Architect – Associate (SAA-C03) 完全学習ガイド

試験概要

項目 内容
試験コード SAA-C03
正式名称 AWS Certified Solutions Architect – Associate
難易度 ★★★☆☆ (Associate)
問題数 65問（採点対象: 50問）
試験時間 130分
合格スコア 720/1000
有効期限 3年
受験料 $150 USD
推奨経験 AWSでの実務経験1年以上
前提推奨 CLF-C02取得またはAWS基礎知識

対象者

  • AWSのシステム設計を担当するソリューションアーキテクト
  • インフラエンジニア・クラウドエンジニア
  • バックエンドエンジニアでAWSの知識を体系化したい方

ドメイン別出題割合

ドメイン 出題割合 重要度
Domain 1: セキュアなアーキテクチャの設計 30% ★★★★★
Domain 2: 弾力性のあるアーキテクチャの設計 26% ★★★★★
Domain 3: 高パフォーマンスなアーキテクチャの設計 24% ★★★★
Domain 4: コスト最適化されたアーキテクチャの設計 20% ★★★★

Domain 1: セキュアなアーキテクチャの設計（30%）

1-1. IAM 詳細設計

IAMポリシーの評価ロジック（重要）:

評価順序:
1. Denyが1つでもあれば → 拒否（明示的Deny）
2. Allowが1つでもあれば → 許可
3. どちらもなければ → 暗黙的Deny（デフォルト）

ポリシー優先度:
  明示的Deny > Allowの組み合わせ > 暗黙的Deny

IAMポリシーの種類:

アイデンティティベースポリシー:
  → IAMユーザー/グループ/ロールにアタッチ
  → 「この主体は何ができるか」

リソースベースポリシー:
  → S3バケット、SQSキュー、KMSキー等にアタッチ
  → 「このリソースに誰がアクセスできるか」

SCPポリシー:
  → AWS Organizations経由でアカウントに適用
  → AllowではなくPermission boundaryとして機能

パーミッションバウンダリー:
  → IAMエンティティが持てる権限の上限を設定
  → 「最大これだけ」という上限

クロスアカウントアクセスのパターン:

# アカウントAのLambdaがアカウントBのS3にアクセスする場合

# アカウントBのS3バケットポリシー（リソースベース）
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": {
      "AWS": "arn:aws:iam::ACCOUNT-A-ID:role/lambda-role"
    },
    "Action": "s3:GetObject",
    "Resource": "arn:aws:s3:::my-bucket/*"
  }]
}

# アカウントAのLambdaロール（アイデンティティベース）
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": "s3:GetObject",
    "Resource": "arn:aws:s3:::my-bucket/*"
  }]
}

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

セキュリティグループ vs NACL:

項目 セキュリティグループ NACL
適用単位 EC2インスタンス サブネット
ステート ステートフル（戻りトラフィック自動許可） ステートレス（IN/OUT別々設定）
ルール Allow のみ Allow / Deny 両方
ルール評価 全ルールを評価 番号順に評価（最初にマッチ）
デフォルト 全インバウンド拒否 全許可

多層防御アーキテクチャ:

Internet
    │
[Route 53] → DNS解決
    │
[CloudFront] → CDN、WAFルール
    │
[ALB] → L7ロードバランシング
    │
[Security Group (ALB)] → 80/443のみ許可
    │
Public Subnet
    │
[Security Group (EC2)] → ALBからのみ受信
    │
Private Subnet
    │
[Security Group (RDS)] → EC2からの3306のみ受信
    │
Isolated Subnet（インターネットへの経路なし）

1-3. データ保護設計

暗号化オプション一覧:

保管時暗号化:
  S3:  SSE-S3（AWSが鍵管理）、SSE-KMS（KMSで管理）、SSE-C（顧客が鍵提供）
  EBS: デフォルト暗号化（KMS使用）
  RDS: ストレージ暗号化（KMS使用）
  
転送時暗号化:
  ACM（AWS Certificate Manager）でTLS証明書を発行
  → ALB/CloudFront/API Gatewayにアタッチ

KMSキーの種類:
  AWS管理キー: AWSが自動管理（無料、ローテーション年1回自動）
  顧客管理キー(CMK): 顧客が作成・管理（$1/月、ローテーション設定可）
  顧客提供キー: クライアントが鍵を管理（S3のSSE-Cのみ）

Domain 2: 弾力性のあるアーキテクチャの設計（26%）

2-1. 高可用性（HA）設計パターン

マルチAZ vs マルチリージョン:

マルチAZ（同一リージョン内）:
  → AZ障害に対する保護
  → フェイルオーバー: 数秒〜数分
  → コスト: 中
  → 用途: 一般的な本番システム

  典型例:
  - RDS Multi-AZ: スタンバイを別AZに自動作成
  - ALB: 複数AZにトラフィックを分散
  - EC2 Auto Scaling: 複数AZにインスタンスを分散

マルチリージョン（複数リージョン）:
  → リージョン障害・災害に対する保護
  → フェイルオーバー: 数分〜数十分
  → コスト: 高
  → 用途: 金融・医療・グローバル展開

  典型例:
  - Route 53 Failover: プライマリ/セカンダリの切り替え
  - Aurora Global Database: 1秒未満のレプリケーション
  - DynamoDB Global Tables: マルチリージョン書き込み
  - S3 Cross-Region Replication

RDSのHA設計:

RDS Multi-AZ Deployment:
  ├── プライマリ（書き込み・読み取り）
  └── スタンバイ（同期レプリケーション、自動フェイルオーバー）
      → フェイルオーバー所要時間: 60〜120秒

RDS Read Replica:
  ├── プライマリ（書き込み）
  └── リードレプリカ（非同期レプリケーション、読み取りスケール）
  → リードレプリカは別リージョンにも作成可能
  → マスター昇格が可能（DR用途）

注意: Multi-AZ = HA(自動フェイルオーバー) / Read Replica = スケール(DR)

2-2. Auto Scaling 設計

EC2 Auto Scaling の設定要素:

起動テンプレート: 作成するインスタンスの設定
  → AMI、インスタンスタイプ、SG、ユーザーデータ

Auto Scalingグループ: スケールの管理単位
  → 最小/最大/希望するキャパシティ
  → 対象AZ（複数AZで均等分散）

スケーリングポリシー:
  動的スケーリング:
    シンプルスケーリング: CloudWatchアラーム → 台数増減
    ステップスケーリング: メトリクス値の大きさに応じて段階的増減
    ターゲット追跡スケーリング: 目標メトリクス値を維持（推奨）
      例: CPU使用率を50%に維持
  
  予測スケーリング:
    → 過去の使用パターンを機械学習で分析して事前スケール
    → 週次や時間帯パターンがあるワークロードに有効

スケーリングのウォームアップとクールダウン:

クールダウン（Cooldown）:
  → スケーリングアクション後の一時停止期間
  → デフォルト300秒（5分）
  → この間は追加のスケーリングアクションをスキップ

ウォームアップ（Warm-up）:
  → 新しいインスタンスがトラフィックを受ける前の準備時間
  → 起動直後のインスタンスがメトリクスに反映されるまでの待機

2-3. SQS / SNS による非同期設計

SQS の設計パターン:

標準キュー:
  → 高スループット（ほぼ無制限）
  → At-least-once delivery（重複配信あり）
  → 順序は保証されない
  → 用途: 処理順序不要・ベき等処理

FIFOキュー:
  → 順序保証（先入れ先出し）
  → Exactly-once processing
  → スループット制限: 300TPS（バッチ使用で3000TPS）
  → 用途: 処理順序が重要（金融取引等）

Dead Letter Queue (DLQ):
  → maxReceiveCount回処理に失敗したメッセージを転送
  → 処理失敗の原因調査・アラーム設定に利用

Visibility Timeout:
  → コンシューマーがメッセージを処理中に他のコンシューマーから見えなくする時間
  → 処理時間 + バッファを設定（デフォルト30秒、最大12時間）

SQS + Lambda の設定:

Lambda Event Source Mapping:
  → SQSをLambdaのトリガーに設定
  → バッチサイズ: 1〜10,000（FIFO: 1〜10）
  → バッチウィンドウ: 最大5分（メッセージを蓄積してから処理）

エラーハンドリング:
  → 処理失敗 → Visibility Timeoutが切れたら再キュー
  → maxReceiveCount超 → DLQへ転送
  → BisectOnFunctionError: バッチの二分割で問題メッセージを特定

2-4. データ持続性設計

S3 のデータ保護:

バージョニング:
  → 同一キーの全バージョンを保持
  → 誤削除・誤上書きからの保護
  → Delete Markerにより「論理削除」
  
MFA Delete:
  → バージョン完全削除にMFAを要求
  → バージョニング有効時のみ設定可能

Object Lock:
  → WORM（Write Once, Read Many）の実現
  → Compliance Mode: 誰も削除できない（Root含む）
  → Governance Mode: 特定ユーザーのみ削除可能

Replication:
  → CRR(Cross-Region Replication): 別リージョンへ
  → SRR(Same-Region Replication): 同一リージョン内
  → バージョニングが前提

Domain 3: 高パフォーマンスなアーキテクチャの設計（24%）

3-1. コンピューティング最適化

Lambda パフォーマンス設計:

コールドスタート対策:
  → Provisioned Concurrency: 事前に実行環境を起動しておく
  → ランタイム選択: Python/Node.jsはコールドスタートが速い
  → 関数サイズ削減: 不要な依存関係を削除

同時実行数制御:
  → Reserved Concurrency: 関数専用のリミット設定
    例: 重要APIに500を予約 → 他の関数から枯渇されない
  → 同時実行数 = (毎秒の呼び出し数) × (実行時間)

メモリと実行時間のトレードオフ:
  → メモリを増やすとCPUも比例して増加
  → 128MB〜10,240MBまで選択可能
  → コストはメモリ × 実行時間で計算
  → 場合によってメモリを増やして実行時間を短縮した方が安くなる

ECS Fargate vs EC2:

Fargate（サーバーレスコンテナ）:
  → EC2インスタンスの管理が不要
  → タスク単位の課金（起動時間×vCPU/メモリ）
  → OSパッチ適用は不要
  → 適切: スパイクトラフィック、バッチ処理

EC2起動タイプ:
  → EC2インスタンス上でコンテナを起動
  → インスタンスの管理が必要
  → スポットインスタンスで大幅コスト削減可能
  → 適切: GPUワークロード、高ネットワーク要件

3-2. データベース最適化

ElastiCache のユースケース:

Redis:
  → 高度なデータ構造（ソート済みセット、ハッシュ等）
  → Multi-AZ対応（クラスターモード）
  → Pub/Sub機能
  → 永続化オプション（AOF/RDB）
  → 用途: セッション管理、ランキング、Pub/Sub

Memcached:
  → シンプルなキャッシュ（文字列のみ）
  → マルチスレッド
  → 永続化なし（再起動でデータ消失）
  → 用途: シンプルなキャッシュ、水平スケール

セッションストレージ as a Cache パターン:
  ALB → EC2/Lambda
          ↓ セッション書き込み
        ElastiCache(Redis)
          ↑ セッション読み取り
  → スケールアウト時もセッションが維持される

DynamoDB 設計パターン:

パーティションキー設計原則:
  → カーディナリティが高いキーを選ぶ（= 値のバリエーションが多い）
  → 特定のキーに「ホットパーティション」が発生しないように

Global Secondary Index (GSI):
  → メインキーとは別の属性で検索可能にする
  → 別のパーティションキー + ソートキーを定義
  → 最大20個

Local Secondary Index (LSI):
  → 同じパーティションキーで別のソートキーを追加
  → テーブル作成時のみ定義可能（後から追加不可）
  → 最大5個

DynamoDB Streams + Lambda:
  → テーブルの変更をキャプチャ → Lambda起動
  → 集計計算、他システムへの通知に活用

3-3. ネットワーク最適化

CloudFront の詳細設定:

オリジン設定:
  → S3 Bucket Origin: 静的コンテンツ配信
  → Custom Origin (ALB/EC2): 動的コンテンツ対応

キャッシュポリシー:
  → TTL (Time to Live): キャッシュの有効期間
  → Cache-Control: MaxAge, s-maxageヘッダーで制御
  → キャッシュキー: URL、ヘッダー、クッキー、クエリ文字列

OAC (Origin Access Control):
  → CloudFront経由のみS3アクセスを許可
  → S3バケットをパブリック公開せずにCDN配信

Geo Restriction（地域制限）:
  → 特定国からのアクセスを許可/拒否

Lambda@Edge / CloudFront Functions:
  → CDNエッジでコードを実行（認証・リライト等）
  → Lambda@Edge: 最大5秒、N.Virginia等にデプロイ
  → CloudFront Functions: 最大1ms、超軽量処理

Route 53 ルーティングポリシー（試験頻出）:

シンプルルーティング: 1つのリソースへ
レイテンシーベースルーティング: レイテンシーが最小のリージョンへ
地理的ルーティング: ユーザーの地理的場所に基づく
地理的近接性ルーティング: 地理的近さ + バイアス値
加重ルーティング: 重みに基づいてトラフィック分散（Canaryデプロイに活用）
フェイルオーバールーティング: ヘルスチェック失敗時にセカンダリへ
複数値回答ルーティング: 複数のIPを返しクライアントで選択

ヘルスチェック:
  → エンドポイントの死活監視
  → フェイルオーバールーティングと組み合わせて自動切り替え

Domain 4: コスト最適化されたアーキテクチャの設計（20%）

4-1. コスト最適化の4つの柱

1. 適切なサービス選択:

サーバーレスファースト戦略:
  散発的トラフィック → Lambda（リクエスト単位課金）
  常時稼働APIサーバー → ECS Fargate（時間課金）
  
ストレージ最適化:
  頻繁アクセス → S3 Standard
  月1回程度   → S3 Standard-IA
  年1回程度   → S3 Glacier Flexible Retrieval
  7年保管     → S3 Glacier Deep Archive

2. 購入オプションの最適化:

ベースロード: リザーブドインスタンス（RI）またはSavings Plans
  → 1年 or 3年コミット
  → Compute Savings Plans: Lambda/Fargate/EC2に適用（最も柔軟）
  → EC2 Instance Savings Plans: 特定インスタンスタイプ（最も安い）

スパイク/バースト: オンデマンド + スポットの組み合わせ
  → Auto Scalingグループでスポットインスタンスを混在

定期バッチ処理: スポットインスタンス
  → 最大90%削減
  → 中断が発生した場合の再開設計が必要

3. スケールに合わせたサイジング:

AWS Compute Optimizer:
  → EC2/Lambda/EBS/ECS Fargateの最適サイズを推奨
  → 過去14日のメトリクスを分析

リソースの定期見直し:
  → タグによるコスト配賦 → チーム別コストを可視化
  → Cost Explorerで不使用リソースを特定

4. データ転送コストの最適化:

データ転送コストが発生するケース:
  ✅ AZ間転送: 課金あり
  ✅ リージョン間転送: 課金あり
  ✅ インターネットへのアウトバウンド: 課金あり
  ✅ Direct Connect: 安価だが接続料金あり
  
  ❌ 同一AZ内: 無料（プライベートIPアドレス使用時）
  ❌ S3/DynamoDB/Gateway型VPCエンドポイント: 無料
  ❌ CloudFrontへのアウトバウンド: S3→CloudFrontは無料

コスト削減策:
  → S3/DynamoDBにはGateway型VPCエンドポイントを使用
  → CloudFrontで転送コストを削減（オリジンへのリクエスト数削減）

重要アーキテクチャパターン集

パターン1: 3層Webアーキテクチャ

[ユーザー]
    ↓ HTTPS
[Route 53] ─ 地理/フェイルオーバールーティング
    ↓
[CloudFront + WAF] ─ CDN + L7保護
    ↓
[ALB] ─ HTTP/HTTPSルーティング、SSLターミネーション
    ↓
[EC2 Auto Scaling Group] ─ 複数AZ、ターゲット追跡スケーリング
    ↓
[RDS Multi-AZ] ─ プライマリ (書き込み)
              └─ Read Replica (読み取り)

[ElastiCache] ─ セッション + クエリキャッシュ
[S3 + CloudFront] ─ 静的アセット

パターン2: イベント駆動サーバーレスアーキテクチャ

[API Gateway] → Lambda → DynamoDB
                  ↓
              SQS → Lambda Worker → RDS/外部API
                        ↓ 失敗
                       DLQ → アラーム → SNS通知

[S3イベント] → Lambda → Rekognition/Transcribe → DynamoDB保存
             → EventBridge → Step Functions（複数ステップ処理）

パターン3: データ分析パイプライン

[源泉データ]
    ↓
[Kinesis Data Streams] ─ リアルタイムストリーム
    ↓                      ↓
[Kinesis Firehose]     [Lambda/Flink] ─ リアルタイム処理
    ↓                                     ↓
[S3 Raw Zone]                        [OpenSearch/DynamoDB]
    ↓
[Glue ETL] ─ Parquet変換、パーティショニング
    ↓
[S3 Processed Zone]
    ↓
[Athena] ─ アドホック分析
[Redshift] ─ DWH・BI
[QuickSight] ─ 可視化

学習計画（8週間）

Week 1-2: 基礎固め

Week 1:
  月: IAM（ポリシー評価ロジック、クロスアカウント）
  火: VPC（CIDR設計、サブネット、SG vs NACL）
  水: EC2（インスタンスタイプ、購入オプション、Auto Scaling）
  木: RDS/Aurora（マルチAZ、Read Replica、フェイルオーバー）
  金: S3（ストレージクラス、バージョニング、暗号化）
  週末: 各サービスの実際のコンソール操作

Week 2:
  月: Lambda（同時実行、コールドスタート、設計パターン）
  火: SQS/SNS（メッセージキュー設計、DLQ、FIFO）
  水: DynamoDB（パーティション設計、GSI/LSI、ストリーム）
  木: CloudFront/Route53（ルーティングポリシー、HA設計）
  金: ECS/EKS/Fargate（コンテナ設計）
  週末: 模擬問題30問

Week 3-4: 設計パターン習得

Week 3:
  → HA設計パターン10種を図で描いて理解する
  → DR戦略（RTO/RPOの概念と実装）
  → マルチリージョン設計の具体例を1つ詳細に学ぶ

Week 4:
  → コスト最適化パターン（Savings Plans計算）
  → セキュリティ設計（責任共有モデルの深い理解）
  → 暗号化設計（KMS、ACM、SSE-S3 vs SSE-KMS）
  → 模擬問題50問

Week 5-6: 弱点強化

Week 5:
  → 模擬試験1回（65問、時間計測）
  → 間違えた問題の復習・ノート整理

Week 6:
  → 弱点ドメインに集中
  → 公式サンプル問題を全問解く

Week 7-8: 仕上げ

Week 7:
  → 模擬試験3回（毎日1回）
  → 合格ライン（72%）を安定して超えるまで

Week 8:
  → 最終確認（暗記事項のチェックリスト）
  → 体調管理・試験会場の確認

頻出問題パターン

パターン1: 「最もコスト効率の良い方法は」

重要な優先順位:
  1. サーバーレス（Lambda/Fargate）→ アイドル時コスト0
  2. マネージドサービス → 運用コスト削減
  3. スポットインスタンス → バッチ処理
  4. Savings Plans/RI → ベースロードの削減
  5. S3ストレージ階層化 → データ保管コスト

パターン2: 「高可用性を確保するには」

必須要素:
  1. 複数AZ（単一AZ構成は高可用性でない）
  2. Auto Scaling（インスタンス障害時の自動置換）
  3. ヘルスチェック（ELB + Route 53）
  4. データの冗長化（RDS Multi-AZ、DynamoDB等）

パターン3: 「スケーラビリティの問題」

ボトルネック別解決策:
  Webサーバー: Auto Scaling + ALB
  DB書き込み: DynamoDBへ移行、Kinesis + バッファリング
  DB読み取り: ElastiCacheでキャッシュ、Read Replica
  セッション: ElastiCache、DynamoDBにセッション外部化
  静的アセット: S3 + CloudFront

パターン4: 「セキュリティ設計」

機密データ:
  → KMSで暗号化（SSE-KMS）
  → IAMポリシーで最小権限
  → VPCエンドポイントでインターネット経由を排除

監査:
  → CloudTrail（API呼び出しログ）
  → Config（設定変更履歴）
  → GuardDuty（脅威検知）

アクセス制御:
  → IAMロール（EC2/Lambda等のサービスロール）
  → リソースベースポリシー（S3バケット等）
  → VPCセキュリティグループ（最小開放）

重要数値・制限値チートシート

Lambda:
  最大実行時間: 15分（900秒）
  メモリ: 128MB〜10,240MB（10GB）
  デプロイパッケージ: 50MB（zip）/250MB（展開後）/10GB（コンテナ）
  同時実行デフォルト上限: アカウント全体で1,000（上限緩和可能）

SQS:
  メッセージ保持期間: 1分〜14日（デフォルト4日）
  最大メッセージサイズ: 256KB
  Visibility Timeout: 0秒〜12時間（デフォルト30秒）
  ロングポーリング最大: 20秒

DynamoDB:
  1アイテムの最大サイズ: 400KB
  パーティションごとの上限: 1,000 WCU、3,000 RCU
  GSI: 最大20個
  LSI: 最大5個（テーブル作成時のみ）

S3:
  オブジェクト最大サイズ: 5TB
  マルチパートアップロード推奨: 100MB以上
  1バケットの最大オブジェクト数: 無制限

RDS:
  Multi-AZ フェイルオーバー時間: 60〜120秒
  最大バックアップ保持期間: 35日
  
EC2:
  インスタンスメタデータURL: http://169.254.169.254/latest/meta-data/
  
Route 53:
  最大ヘルスチェック: リージョンごと200
  
KMS:
  カスタムキーのローテーション: 最短90日（デフォルト無効）

アーキテクチャ図

高可用性 3層 Web アーキテクチャ

flowchart TB
    Internet["🌐 Internet"]

    subgraph CF["CloudFront (CDN)"]
        CFD["Distribution\nWAF適用・HTTPS強制"]
    end

    subgraph VPC["VPC (10.0.0.0/16)"]
        subgraph PubSubnet["Public Subnet (10.0.0.0/24, 10.0.1.0/24)"]
            ALB["Application Load Balancer\n(Multi-AZ)"]
            NAT["NAT Gateway\n(AZ毎に配置)"]
        end

        subgraph AppSubnet["Private Subnet - App (10.0.10.0/24, 10.0.11.0/24)"]
            ASG["Auto Scaling Group\nEC2 / ECS"]
        end

        subgraph DataSubnet["Private Subnet - Data (10.0.20.0/24, 10.0.21.0/24)"]
            RDS["RDS Aurora\nMulti-AZ (Writer + Reader)"]
            Cache["ElastiCache Redis\n(読み取りキャッシュ)"]
        end
    end

    Internet --> CFD --> ALB
    ALB --> ASG
    ASG --> Cache
    ASG --> RDS
    ASG --> NAT --> Internet
    style PubSubnet fill:#fef3c7
    style AppSubnet fill:#dbeafe
    style DataSubnet fill:#dcfce7

RDS Multi-AZ vs Read Replica

flowchart LR
    subgraph MultiAZ["Multi-AZ（可用性）"]
        M_Primary["Primary DB\n(AZ-A)\n読み書き可"]
        M_Standby["Standby DB\n(AZ-B)\n同期レプリケーション\n※普段は待機"]
        M_Primary -->|"同期"| M_Standby
        M_Primary -->|"フェイルオーバー\n(1-2分)"| M_Standby
    end

    subgraph ReadReplica["Read Replica（性能）"]
        R_Primary["Primary DB\n(AZ-A)\n書き込み"]
        R_Replica1["Read Replica\n(AZ-B)\n読み取りのみ"]
        R_Replica2["Read Replica\n(別リージョン)\n読み取りのみ"]
        R_Primary -->|"非同期"| R_Replica1
        R_Primary -->|"非同期"| R_Replica2
    end

S3 ストレージクラス選択フロー

flowchart TD
    Start(["S3ストレージクラス選択"]) --> Q1{"アクセス頻度は？"}
    Q1 -->|"頻繁"| Q2{"レイテンシ要件は？"}
    Q1 -->|"不明・変動"| IntelTier["S3 Intelligent-Tiering\n（自動最適化）"]
    Q1 -->|"月1回以下"| Q3{"最終アクセスから？"}
    Q2 -->|"ミリ秒"| S3STD["S3 Standard\n（汎用）"]
    Q2 -->|"AZ障害許容可"| S3IA_1Z["S3 One Zone-IA\n（低コスト）"]
    Q3 -->|"〜3ヶ月"| S3IA["S3 Standard-IA\n（低頻度アクセス）"]
    Q3 -->|"3〜12ヶ月"| Glacier_I["S3 Glacier\nInstant Retrieval"]
    Q3 -->|"12ヶ月〜7年"| Glacier_F["S3 Glacier\nFlexible Retrieval\n(1分〜12時間)"]
    Q3 -->|"7年以上"| Glacier_D["S3 Glacier\nDeep Archive\n(12〜48時間)"]

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

問題 1

Webアプリケーションのバックエンドがトラフィック急増時にスロットリングエラーを返しています。非同期的にリクエストをバッファリングし、バックエンドの処理速度に合わせて順次処理するアーキテクチャとして最適なものはどれですか？

  • A. ALB + Auto Scaling（スケールアウト）
  • B. Amazon SQS（キュー）を介した非同期処理
  • C. ElastiCache でキャッシュ層を追加
  • D. CloudFront でエッジキャッシュを追加
正解と解説

正解: B

解説:

  • B（SQS）が正解: SQS キューがメッセージ（リクエスト）を蓄積し、バックエンドが処理できる速度で取り出して処理します。「疎結合（デカップリング）」パターンの典型例です。
  • A（Auto Scaling）: スケールアウトで対応可能ですが、起動時間のラグがあります。また急激なスパイクには追いつけない場合があります。SQSはバッファとして機能し、インスタンス数に関係なく安全にリクエストを受け付けます。
  • C（ElastiCache）: 読み取りの高速化・DB負荷軽減には有効ですが、書き込みリクエストのバッファリングには使いません。
  • D（CloudFront）: 静的コンテンツのキャッシュには有効ですが、APIリクエストのバッファリングには使いません。

SQS + Lambda/EC2 の典型パターン:

  • Client → API Gateway → SQS Queue → Lambda / EC2 Consumer
  • ↑ バッファ（最大14日間メッセージ保持）

問題 2

RDSデータベースの読み取り負荷が高くなっており、応答時間が低下しています。最もコスト効率よく解決する方法はどれですか？

  • A. RDSインスタンスをより大きなサイズにアップグレード（スケールアップ）
  • B. RDS Multi-AZ を有効化する
  • C. RDS Read Replica を追加し、読み取り処理を分散する
  • D. 別のリージョンにRDSインスタンスを追加する
正解と解説

正解: C

解説:

  • C（Read Replica）が正解: Read Replicaは読み取り専用レプリカで、SELECT文を分散することでプライマリDBの負荷を大幅に軽減します。
  • A（スケールアップ）: コストが高い（インスタンスサイズ変更）。根本原因（読み取り負荷分散）を解決しない。ダウンタイムが発生します。
  • B（Multi-AZ）: 高可用性（HA）のための機能で、スタンバイへの読み取りはできません。フェイルオーバー用途のみです。これは試験頻出の誤解です。
  • D（別リージョン）: クロスリージョン Read Replica は可能ですが、コストが高く、主にDR（災害対策）用途です。

Multi-AZ vs Read Replica（試験必須）:

項目 Multi-AZ Read Replica
目的 高可用性（HA） 読み取りスケール
レプリケーション 同期 非同期
スタンバイへの読み取り ❌ 不可 ✅ 可能
フェイルオーバー 自動 手動昇格

問題 3

ある企業はS3に重要なドキュメントを保存しています。誤削除を防ぎ、削除されたファイルを30日以内であれば復元できるようにしたいと考えています。最も適切な設定はどれですか？

  • A. S3 バケットの MFA Delete を有効化する
  • B. S3 バージョニングを有効化し、ライフサイクルルールで古いバージョンを30日後に削除する
  • C. AWS Backup でS3のバックアップを30日間保持する
  • D. S3 Cross-Region Replication でバックアップリージョンに複製する
正解と解説

正解: B

解説:

  • B（バージョニング + ライフサイクル）が正解: バージョニングを有効にすると、オブジェクトを「削除」しても実際にはDelete Markerが付くだけで以前のバージョンが残ります。30日以内は任意のバージョンに復元可能。ライフサイクルルールで古いバージョンを自動削除してコストを最適化できます。
  • A（MFA Delete）: 追加の保護として有効ですが、単独ではバージョン管理はできません。バージョニング有効化が前提。また日常運用でMFAが必要になり煩雑です。
  • C（AWS Backup）: バックアップソリューションとして有効ですが、細かいバージョン管理には向きません。
  • D（CRR）: 別リージョンへのレプリケーションはDR目的。誤削除からの保護にはなりません（削除もレプリケーションされます）。

問題 4

マイクロサービスアーキテクチャで、あるサービスから別のサービスへイベントを発行し、複数の購読者（メールサービス・ログサービス・分析サービス）が同時にそのイベントを受信したいと考えています。最適なAWSのパターンはどれですか？

  • A. SQS で全サービスが同一キューをポーリング
  • B. SNS でトピックに発行し、各サービスのSQSキューがサブスクライブする（SNS + SQS ファンアウト）
  • C. Kinesis Data Streams で全サービスが同一ストリームを読む
  • D. EventBridge でルールを作成して各サービスにルーティング
正解と解説

正解: B

解説:

  • B（SNS + SQS ファンアウト）が正解: SNSトピックに発行すると、全サブスクライバーに同時配信されます（ファンアウト）。各サービスが独立したSQSキューを持つことで、処理速度の差異を吸収し、疎結合を実現します。
flowchart LR
    Publisher["発行元サービス"] --> SNS["SNS Topic"]
    SNS --> SQS1["SQS Queue\n→ メールサービス"]
    SNS --> SQS2["SQS Queue\n→ ログサービス"]
    SNS --> SQS3["SQS Queue\n→ 分析サービス"]
  • A（SQS単一キュー）: 1つのメッセージは1つのコンシューマーにしか届きません。複数サービスでの受信には不適切。
  • C（Kinesis）: 可能ですが、リアルタイムストリーミング分析向け。シンプルなファンアウトには過剰です。
  • D（EventBridge）: 正しく動作しますが、SNS+SQSパターンの方が「ファンアウト」として一般的に認知されています。EventBridgeはより複雑なイベントルーティングに適します。

問題 5

あるWebアプリケーションはリージョン全体の障害に備えて別リージョンにDR（災害対策）環境を持ちたいと考えています。RTO（目標復旧時間）は15分以内、RPO（目標復旧時点目標）は1時間以内です。最もコスト効率の高いDR戦略はどれですか？

  • A. バックアップ＆リストア（Backup & Restore）
  • B. パイロットライト（Pilot Light）
  • C. ウォームスタンバイ（Warm Standby）
  • D. マルチサイトアクティブ/アクティブ
正解と解説

正解: C

解説: RTO 15分、RPO 1時間の要件に対して各戦略を評価します:

  • A（Backup & Restore）: 最もコスト低いが、RTO数時間〜。15分以内のRTOを満たせません。
  • B（Pilot Light）: コアコンポーネントのみ稼働（DB等）。RTO 10分〜60分程度。RPOは短くできますが、RTOが15分以内に確実に収まらない可能性があります。
  • C（Warm Standby）: 縮小版のフル環境が常時稼働。RTOは数分〜15分で要件を満たします。コストはMulti-siteより低い。
  • D（Multi-site Active/Active）: 最も高い可用性だがコストが2倍。RTOはほぼ0ですが、RTO 15分という要件に対してはオーバースペックです。

DR戦略の比較（RTO昇順）:

戦略 RTO RPO コスト
Backup & Restore 数時間 数時間 最低
Pilot Light 10-60分 分単位 低
Warm Standby 数分-15分 秒-分 中
Multi-site Active ほぼ0 ほぼ0 最高

問題 6

Lambda 関数が DynamoDB から大量データを取得する処理で、Lambdaのタイムアウト（15分）を超えてしまうことがあります。このアーキテクチャを改善する方法として最も適切なものはどれですか？

  • A. Lambda の並列実行数を増やす
  • B. SQS でメッセージを分割し、各 Lambda が小さなバッチを処理する
  • C. EC2 インスタンスで長時間処理を実行する
  • D. Lambda のメモリを最大値に増やす
正解と解説

正解: B

解説:

  • B（SQS + Lambda の分割処理）が正解: 大きな処理を小さなチャンクに分割し、それぞれを短時間のLambda実行で処理します。SQSがバッファとして機能し、並列処理も実現できます。
  • A（並列実行数）: 並列化は速度向上に有効ですが、1回のLambda実行時間制限（15分）は変わりません。
  • C（EC2）: Lambdaの制約を回避できますが、インフラ管理が発生し、サーバーレスの利点が失われます。AWS Batch や Fargate がより適切な代替です。
  • D（メモリ増加）: CPUも比例して増加しますが、処理内容（I/O待ち）によってはメモリが問題でない場合があります。根本的なアーキテクチャ改善にはなりません。

サーバーレスでの長時間処理パターン:

  • SQS → Lambda (小バッチ) + DynamoDB
  • または
  • Step Functions（状態管理・再実行・並列化）

問題 7

ある企業はアプリケーションのコンテナをAWSで実行したいと考えています。インフラの管理（EC2インスタンスのパッチ・容量管理）を一切行いたくない場合、最も適切なサービスはどれですか？

  • A. Amazon ECS（EC2起動タイプ）
  • B. Amazon EKS（EC2ノードグループ）
  • C. Amazon ECS（Fargate起動タイプ）
  • D. Amazon EC2 + Docker
正解と解説

正解: C

解説:

  • C（ECS Fargate）が正解: Fargateはサーバーレスコンテナ実行環境です。EC2インスタンスのプロビジョニング・パッチ・スケーリングが不要。コンテナのCPU/メモリを指定するだけです。
  • A（ECS EC2起動タイプ）: ECSの管理はAWSですが、EC2インスタンス自体の管理（パッチ・容量計画）はお客様の責任です。
  • B（EKS EC2ノード）: Kubernetesコントロールプレーンはマネージドですが、ノード（EC2）の管理は必要です。EKS Fargateも選択肢として存在します。
  • D（EC2 + Docker）: 全て自己管理。最も管理負荷が高いです。

「インフラ管理不要」のキーワードが出たら Fargate を選ぶ。

問題 8

ユーザーが S3 にアップロードした画像を自動的にサムネイル変換するシステムを構築したいと考えています。イベント駆動でサーバーレスな最適なアーキテクチャはどれですか？

正解と解説

正解: B

解説:

  • B が正解: S3イベント通知でオブジェクト作成（PutObject）をトリガーにLambdaを直接起動できます。完全サーバーレスで、Lambdaがサムネイル生成後に別のS3バケット/プレフィックスに保存します。

アーキテクチャ:

  • S3(元画像バケット) → [ObjectCreated event] → Lambda(サムネイル変換) → S3(サムネイルバケット)

  • A（EC2ポーリング）: サーバー管理が必要。ポーリングによる遅延とコスト無駄。

  • C（SQS + EC2）: 機能しますが、サーバーレス要件を満たしません。

  • D（CloudWatch Events）: スケジュール実行（定期実行）に使います。S3オブジェクトアップロードのリアルタイムトリガーには使いません。

S3 イベント通知の送信先: Lambda / SQS / SNS

問題 9

グローバルに展開するゲームアプリケーションで、世界中のプレイヤーのランキングデータを低レイテンシで読み書きしたい場合に最も適したDynamoDBの機能はどれですか？

正解と解説

正解: C

解説:

  • C（Global Tables）が正解: DynamoDB Global Tables は、複数リージョンにテーブルをレプリケーションするマルチリージョンのマルチアクティブ（読み書き両方可）ソリューションです。各リージョンのプレイヤーが最も近いリージョンのテーブルで低レイテンシ読み書きができます。
  • A（Auto Scaling）: DynamoDBのキャパシティ（RCU/WCU）を自動調整。スケーリングの話でマルチリージョンではありません。
  • B（DAX）: 読み取りキャッシュ（マイクロ秒レイテンシ）。単一リージョン内の読み取り高速化。グローバル分散ではありません。
  • D（Streams）: テーブルの変更履歴をキャプチャするストリーム機能。Lambda連携やGlobal Tables内部でも使われますが、グローバル低レイテンシ解決策ではありません。

問題 10

EC2インスタンスにアタッチされたEBSボリュームのパフォーマンスが低下しています。調査すると、I/Oのスループットがボリュームの最大値に達していることがわかりました。最もコスト効率の良い解決策はどれですか？

  • A. EC2インスタンスを大きなサイズに変更する
  • B. EBSボリュームを削除して新しいボリュームを作成する
  • C. EBSボリュームのタイプをgp3に変更し、スループットとIOPSをニーズに合わせて設定する
  • D. インスタンスにEBSボリュームを追加で接続する
正解と解説

正解: C

解説:

  • C（gp3への変更・チューニング）が正解: gp3 は gp2 と比較してIOPS（最大16,000）とスループット（最大1,000MiB/s）を独立して設定可能です。コストはgp2より約20%安く、ダウンタイムなしで変更（Elastic Volumes）できます。
  • A（インスタンスサイズ変更）: インスタンスサイズはEBSのIOPS上限に影響しますが、ボリューム自体の制限を超えることはできません。ダウンタイムも発生します。
  • B（ボリューム再作成）: 同じタイプで作り直しても改善しません。タイプ変更が必要です。
  • D（追加ボリューム）: RAID 0構成でスループットを向上させることは可能ですが、複雑さとコストが増加します。

gp2 vs gp3 比較（試験頻出）:

項目 gp2 gp3
ベースIOPS 3 IOPS/GB 3,000 IOPS（固定）
最大IOPS 16,000 16,000
スループット 250 MiB/s 1,000 MiB/s
IOPS独立設定 ❌ ✅
コスト 基準 約20%安

SAA-C03 追加詳解セクション

VPC 設計詳細（試験最頻出）

VPC コンポーネント全体像

VPC（10.0.0.0/16）
├── パブリックサブネット（10.0.1.0/24）
│   ├── Internet Gateway（IGW）接続
│   ├── NAT Gatewayの設置場所
│   └── ELB（ALB）の配置場所
├── プライベートサブネット（10.0.2.0/24）
│   ├── EC2（Webサーバー）
│   ├── RDS（データベース）
│   └── NAT GatewayへのルートテーブルでInternet出口
└── ルートテーブル（Route Table）
    ├── パブリック用: 0.0.0.0/0 → IGW
    └── プライベート用: 0.0.0.0/0 → NAT Gateway

セキュリティグループ vs NACL（試験最頻出比較）

比較項目 セキュリティグループ（SG） ネットワークACL（NACL）
適用レベル インスタンス（ENI）レベル サブネットレベル
ルールの評価 全ルールを評価（番号なし） 番号順（小さい方が優先）
ステートフル/レス ステートフル（戻りトラフィック自動許可） ステートレス（送受信別々に定義必要）
デフォルト動作 全インバウンド拒否・全アウトバウンド許可 全トラフィック許可（デフォルトNACL）
拒否ルール 設定不可（許可のみ） 設定可能（明示的拒否ルール）
ユースケース 通常のアクセス制御 IPブロックリスト・DDoS対策
  • 試験での問い方:
  • 「特定のIPアドレスからのアクセスをブロックしたい」
  • → NACL（Deny ルール）を使う（SGはDenyルールがない）

VPC Flow Logs

用途:
  → VPCのネットワークトラフィックを記録
  → セキュリティ監査・トラブルシューティング
  → 異常なトラフィックパターンの検出

記録先: CloudWatch Logs または S3

記録される情報:
  送信元IP・送信先IP・プロトコル・ポート・許可/拒否

注意: リアルタイムではない（数分の遅延がある）

VPC エンドポイント（試験頻出）

ゲートウェイ型エンドポイント（Gateway Endpoint）:
  対応サービス: S3, DynamoDB のみ
  特徴:
    → VPCのルートテーブルにルートが追加される
    → 追加コストなし（無料）
    → インターネットを経由しない

インターフェイス型エンドポイント（Interface Endpoint / AWS PrivateLink）:
  対応サービス: S3以外の多数のAWSサービス（SSM, SQS, CloudWatch等）
  特徴:
    → ENI（プライベートIPアドレス）がサブネットに作成される
    → コストがかかる（時間課金 + データ転送量）
    → DNS解決でPrivateLinkエンドポイントを使用

使用ケース:
  「プライベートサブネットからS3にインターネット経由せずアクセス」
  → S3 ゲートウェイエンドポイントを設定
  
  「プライベートサブネットからSSM Parameter Storeにアクセス」
  → SSMのインターフェイスエンドポイントを作成

RDS 詳細設計

RDS Multi-AZ vs Read Replica

Multi-AZ（高可用性）:
  目的: 障害時の自動フェイルオーバー（HA）
  仕組:
    → 同期レプリケーション（プライマリからスタンバイへ）
    → スタンバイは読み取りトラフィックを処理しない（スタンバイ専用）
    → フェイルオーバー時間: 通常60〜120秒
  フェイルオーバートリガー:
    → インスタンス障害・AZ障害
    → インスタンスタイプ変更（メンテナンス）
    → OSパッチ適用
  DNS: CNAME（フェイルオーバー時にCNAMEが新プライマリを指す）

Read Replica（読み取りスケーリング）:
  目的: 読み取りパフォーマンスの向上
  仕組:
    → 非同期レプリケーション（レプリカラグが発生する可能性）
    → Read Replicaはリードオンリーエンドポイント
    → 最大15個のRead Replica（Auroraは最大15個）
  クロスリージョンレプリカ: 別リージョンにもレプリカ作成可能
  昇格: Read ReplicaをStandaloneインスタンスに昇格可能

試験での問い方:
  「読み取りが多い・DBのCPU使用率が高い」   → Read Replica
  「データベースの可用性を高めたい・DR」    → Multi-AZ
  「両方必要」                            → Multi-AZ + Read Replica

RDS Proxy

用途:
  → Lambda + RDS の接続数問題を解決
  → Lambda はスケールアウトで接続数が急増する
  → RDS は接続数に上限がある（max_connections）
  → RDS Proxy が接続プールを管理し、接続数を制限

メリット:
  → DB接続数の最大66%削減
  → フェイルオーバー時間の短縮（66%削減）
  → IAM認証・Secrets Managerとの統合

対応DB: MySQL/PostgreSQL/MariaDB/SQL Server

S3 詳細設計

S3 ストレージクラス比較（試験最頻出）

クラス 耐久性 可用性 最小保存期間 ユースケース
Standard 99.999999999% 99.99% なし 頻繁にアクセスするデータ
Intelligent-Tiering 99.999999999% 99.9% なし アクセスパターン不明
Standard-IA 99.999999999% 99.9% 30日 月1回程度のアクセス（取得料金あり）
One Zone-IA 99.999999999% 99.5% 30日 再作成可能なデータ・コスト最優先
Glacier Instant Retrieval 99.999999999% 99.9% 90日 アーカイブ（ミリ秒取得）
Glacier Flexible Retrieval 99.999999999% 99.99% 90日 アーカイブ（1-5時間取得）
Glacier Deep Archive 99.999999999% 99.99% 180日 長期保存（12時間取得） 
試験選択基準:
  「頻繁アクセス・コスト気にしない」     → Standard
  「アクセス頻度不明・自動最適化」       → Intelligent-Tiering
  「月1回程度・取得速度は普通でいい」    → Standard-IA
  「7年以上保存・コスト最安」           → Glacier Deep Archive
  「アーカイブだがミリ秒で取得したい」   → Glacier Instant Retrieval

S3 セキュリティ

バケットポリシー（Bucket Policy）:
  → バケット・オブジェクト単位でのリソースベースポリシー
  → 他アカウントへのアクセス許可に使用
  → 例: CloudFront OAC（Origin Access Control）からのアクセス許可

ACL（Access Control List）:
  → レガシー機能（新規では使用非推奨）
  → オブジェクト単位の細かい権限設定

ブロックパブリックアクセス:
  → デフォルトで有効（S3の誤公開を防ぐ）
  → 意図しないパブリックアクセスを防止

S3 オブジェクトロック（Object Lock）:
  Governance Mode: 特定の権限を持つユーザーは削除可能
  Compliance Mode: ロック期間中は誰も削除できない（SEC 17a-4対応）

S3 レプリケーション

クロスリージョンレプリケーション（CRR）:
  → 別リージョンのバケットへの自動コピー
  → レイテンシ低減・DR（ディザスタリカバリ）

同一リージョンレプリケーション（SRR）:
  → 同一リージョン内の別バケットへのコピー
  → ログ集約・本番→テスト環境のデータコピー

前提条件:
  → ソース・宛先バケット両方でバージョニングが有効
  → レプリケーションは有効後に追加されたオブジェクトのみ対象

EC2 詳細設計

EC2 購入オプション比較（試験最頻出）

タイプ 割引 コミットメント ユースケース
オンデマンド なし（定価） なし 短期・予測不能なワークロード
リザーブドインスタンス（Standard） 最大72% 1年 or 3年 24/7稼働の定常ワークロード
コンバーティブルRI 最大54% 1年 or 3年 インスタンスタイプ変更が必要な場合
Savings Plans 最大66% 1年 or 3年 柔軟な割引（RI代替）
スポットインスタンス 最大90% なし（中断リスクあり） バッチ・ML訓練・CI/CDジョブ
Dedicated Host 高い 1年 or 3年 ライセンス持込（BYOL）・コンプライアンス
Dedicated Instance 高い なし 占有ハードウェアが必要なコンプライアンス 
試験選択基準:
  「最もコスト削減・定常24/7ワークロード」    → RI Standard (3年, All Upfront)
  「中断されても良い・バッチ処理・最安」       → スポットインスタンス
  「Windowsライセンス持込（BYOL）」          → Dedicated Host
  「柔軟にインスタンスタイプを変えながら割引」  → Savings Plans or Convertible RI

Auto Scaling 詳細

スケーリングポリシー比較

シンプルスケーリング:
  → CloudWatchアラームが発火 → 固定数のインスタンスを追加/削除
  → クールダウン期間: 前回のスケーリングから次まで最低待機時間
  → レガシー（ターゲット追跡が推奨）

ターゲット追跡スケーリング（Target Tracking）:
  → メトリクスを目標値に維持するよう自動調整
  → 例: CPU使用率を50%に維持
  → 最も推奨される方式

ステップスケーリング:
  → アラームの違反度（ステップ）によって異なる増減数を設定
  → 例: CPU 70-80%: +1台、CPU 80-90%: +2台、CPU 90%+: +3台

スケジュールドスケーリング:
  → 予測可能なトラフィックパターンに対して事前にスケール
  → 例: 毎日9時にmin=10、17時にmin=2に設定

CloudFront と Route 53

CloudFront の設定

オリジン（Origin）:
  → コンテンツの取得元: S3, ALB, EC2, API Gateway等

キャッシュ動作（Cache Behavior）:
  → パスパターンごとに異なるオリジンやキャッシュポリシーを設定
  → 例: /api/* → ALBへ、/*.html → S3へ

OAC（Origin Access Control）:
  → CloudFrontからS3へのアクセスを制限
  → 直接S3 URLへのアクセスをブロックし、CloudFront経由のみ許可

地理的制限（Geo Restriction）:
  → 特定の国からのアクセスをブロック/許可

署名付きURL vs 署名付きCookie:
  → 署名付きURL: 単一ファイルへの一時的アクセス
  → 署名付きCookie: 複数ファイルへの一時的アクセス（動画ストリーミング等）

Route 53 ルーティングポリシー（試験頻出）

ポリシー 説明 ユースケース
シンプル 1つのIPアドレスに解決 シンプルな1サーバー構成
加重（Weighted） トラフィックを重みで分散 Blue/Green デプロイ・A/Bテスト
フェイルオーバー プライマリ→セカンダリへ自動切替 アクティブ-パッシブDR
レイテンシー 最も低レイテンシのリージョンに誘導 グローバルユーザーへの低遅延
地理位置情報 ユーザーの位置に基づいてルーティング コンテンツのローカライズ・規制対応
複数値応答 最大8つのIPをランダムに返す シンプルなロードバランシング
IP-Based クライアントのIPに基づいてルーティング ISPやオフィスIPによる誘導

ELB（Elastic Load Balancer）詳細

ALB（Application Load Balancer）:
  → Layer 7（HTTP/HTTPS）
  → コンテンツベースルーティング（パス・ホスト・ヘッダー）
  → ターゲット: EC2, ECS, Lambda, IP
  → WebSocket対応

NLB（Network Load Balancer）:
  → Layer 4（TCP/UDP/TLS）
  → 超高スループット・低レイテンシ（マイクロ秒オーダー）
  → 固定IPアドレス（Elastic IPが割り当て可能）
  → ターゲット: EC2, IP, ALB

CLB（Classic Load Balancer）:
  → レガシー（新規利用は非推奨）

試験での問い方:
  「固定IPが必要なロードバランサー」 → NLB
  「パスベースルーティング」         → ALB
  「超高スループット・TCPロードバランシング」 → NLB
  「Lambda をターゲットにしたい」   → ALB

追加模擬問題（SAA-C03本番形式）

セクション1: セキュリティ設計

問題 SAA-01

プライベートサブネット内のEC2インスタンスがS3にインターネットを経由せずにアクセスするための、最もコスト効率の良い方法はどれですか？

  • A. インターネットゲートウェイをVPCに追加する
  • B. S3 ゲートウェイエンドポイントをVPCに設定する
  • C. NAT Gatewayを経由してS3にアクセスする
  • D. S3インターフェイスエンドポイントを作成する
正解と解説

正解: B

S3 ゲートウェイエンドポイントは無料で、インターネットを経由せずにプライベートサブネットからS3にアクセスできる。NAT Gatewayを使う方法はデータ転送コストが発生する。S3インターフェイスエンドポイントは有料（時間課金）。

問題 SAA-02

「特定のIPアドレス（悪意あるボット）からのアクセスを即座にブロックしたい」場合の最適な方法はどれですか？

  • A. セキュリティグループに拒否ルールを追加する
  • B. ネットワークACL（NACL）に拒否ルールを追加する
  • C. IAMポリシーにDenyルールを追加する
  • D. Route 53のヘルスチェックを使用する
正解と解説

正解: B

NACLはサブネットレベルで明示的な拒否ルールを設定できる。セキュリティグループは拒否ルールを設定できない（許可ルールのみ）。特定IPのブロックにはNACLが最適。

問題 SAA-03

RDSでデータベース障害時に最短時間でフェイルオーバーしたい。どの設定が必要ですか？

  • A. Read Replicaを2つ作成する
  • B. RDS Multi-AZを有効にする
  • C. ElastiCacheをフロントに配置する
  • D. Auto Scalingを有効にする
正解と解説

正解: B

RDS Multi-AZは同期レプリケーションによってスタンバイインスタンスを維持し、障害時に自動的にフェイルオーバー（60〜120秒）する。Read Replicaは読み取りスケーリング用で自動フェイルオーバーではない。

問題 SAA-04

S3バケットに保存された機密ファイルについて「規制上、オブジェクト保存後3年間は絶対に削除・変更できないようにしたい」場合の設定はどれですか？

  • A. S3 バージョニングを有効にする
  • B. S3 Object Lock（Compliance Mode）を設定する
  • C. S3 クロスリージョンレプリケーションを有効にする
  • D. S3ライフサイクルポリシーで削除を禁止する
正解と解説

正解: B

S3 Object Lock のCompliance Modeはロック期間中、管理者を含む誰もオブジェクトを削除・変更できない（SEC 17a-4, FINRA等の規制対応）。Governance Modeは特別な権限を持つユーザーは削除可能。

問題 SAA-05

EC2インスタンス上のWebアプリケーションから「SSM Parameter Storeの機密パラメータ（SecureString）」を取得したい。インターネット接続なしで実現する方法はどれですか？

  • A. EC2にElastic IPを割り当てる
  • B. SSMのVPCインターフェイスエンドポイントを作成する
  • C. NAT GatewayからSSMにアクセスする
  • D. EC2からパブリックサブネットへ移動する
正解と解説

正解: B

SSM（Systems Manager）はゲートウェイエンドポイント対象外のため、インターフェイスエンドポイント（AWS PrivateLink）を作成してプライベートアクセスが必要。

セクション2: 可用性・スケーラビリティ設計

問題 SAA-06

「読み取りが多いWebアプリケーションでRDSのCPU使用率が高い」問題を解決する最も適切な方法はどれですか？

  • A. RDS インスタンスタイプをアップグレードする（スケールアップ）
  • B. RDS Read Replicaを追加してアプリを変更（読み取りをReplicaへ誘導）
  • C. RDS Multi-AZを有効にする
  • D. ElastiCacheでよくアクセスするデータをキャッシュする
正解と解説

正解: D（または B も正解として採用される場合あり）

ElastiCacheでよくアクセスされるデータをキャッシュすることでRDBへの読み取りクエリ数を削減し、CPU負荷を下げる。これが最もスケーラブルな解決策。Read Replicaはクエリ数は変わらず分散するだけ。

問題 SAA-07

グローバルユーザー向けのAPIで「ユーザーから最も近いリージョンのALBにルーティングしたい」場合、Route 53でどのルーティングポリシーを使いますか？

  • A. 加重（Weighted）ルーティング
  • B. フェイルオーバールーティング
  • C. レイテンシールーティング
  • D. 地理位置情報ルーティング
正解と解説

正解: C

レイテンシールーティングはユーザーから各AWSリージョンへの実測レイテンシーに基づき、最も低レイテンシーのリージョンに誘導する。地理位置情報はユーザーの物理的位置（国・大陸）を基準にルーティングする（コンテンツローカライズ等）。

問題 SAA-08

EC2 Auto Scalingで「予測可能なトラフィック増加（毎日9-18時に高負荷）」に対応するスケーリング方法はどれですか？

  • A. ターゲット追跡スケーリング
  • B. ステップスケーリング
  • C. スケジュールドスケーリング
  • D. シンプルスケーリング
正解と解説

正解: C

スケジュールドスケーリングは予測可能な時間帯のトラフィックに備えて事前にスケールアウトする。ターゲット追跡やステップスケーリングはメトリクスに基づく事後的なスケーリング。

問題 SAA-09

CloudFrontで「プレミアム会員のみが動画コンテンツにアクセスできるようにしたい（複数のコンテンツファイル）」場合の方法はどれですか？

  • A. CloudFront 署名付きURL（Signed URL）
  • B. CloudFront 署名付きCookie（Signed Cookie）
  • C. S3バケットポリシーでIP制限
  • D. OACで直接S3へのアクセスを制限
正解と解説

正解: B

署名付きCookieは1つのCookieで複数のファイルへのアクセスを制御できる（動画配信サービス等）。署名付きURLは単一ファイルへの一時的アクセスに使用する。

問題 SAA-10

Lambda関数が「突発的に1秒あたり数千件のリクエストが来る」ことで、バックエンドのRDSへの接続が枯渇する問題が発生している。最も適切な解決策はどれですか？

  • A. Lambdaのタイムアウト設定を増やす
  • B. RDS Proxyを使用してLambdaとRDSの間に接続プールを設置する
  • C. Lambda Reserved Concurrencyを1に設定する
  • D. RDSのmax_connectionsパラメータを増やす
正解と解説

正解: B

RDS Proxyは接続プールを管理し、Lambda側が多くの接続を作成しても、RDSへの接続数は管理された数に制限される。LambdaのスケールアウトとRDSの接続数の不一致を解決するサービス。

セクション3: コスト最適化

問題 SAA-11

「開発・テスト環境のEC2インスタンスは平日9-18時のみ稼働し、夜間・週末は停止したい」最もコスト効率の良い方法はどれですか？

  • A. スポットインスタンスを使用する
  • B. Instance Schedulerを使ってEventBridgeでEC2を自動停止/起動する
  • C. AutoScalingグループで夜間はminを0にする
  • D. RIを購入して固定費を下げる
正解と解説

正解: B

AWS Instance Scheduler（またはEventBridge + Lambda）でスケジュールどおりにEC2を自動停止/起動することで、使用していない時間のコストを削減できる。稼働時間が週40時間（全体の24%）なら76%コスト削減可能。

問題 SAA-12

「S3に保存した大量のログファイルは最初の30日間は頻繁に参照され、30-90日は時々参照され、90日後はほぼ参照されない。7年間保存義務がある」最もコスト最適化されたS3ライフサイクル設定はどれですか？

  • A. 全期間 Standard
  • B. 0日目: Standard → 30日目: Standard-IA → 90日目: Glacier Flexible Retrieval
  • C. 0日目: Standard-IA → 90日目: Glacier Deep Archive
  • D. 0日目: Standard → 90日目: Glacier Deep Archive
正解と解説

正解: B

アクセスパターンに合わせたライフサイクル:

  • 0-30日: Standard（頻繁アクセス）
  • 30-90日: Standard-IA（月1回程度）
  • 90日以降: Glacier Flexible Retrieval（アーカイブ・7年間保存）

問題 SAA-13

「24時間365日稼働する本番RDSインスタンスのコストを最大限削減したい」場合の最も適切な購入方法はどれですか？

  • A. オンデマンドインスタンス
  • B. スポットインスタンス
  • C. 1年 All Upfront リザーブドインスタンス
  • D. 3年 All Upfront リザーブドインスタンス
正解と解説

正解: D

24/365稼働の定常ワークロードには3年 All Upfront のリザーブドインスタンスが最もコスト削減効果が高い（最大72%割引）。RDSはスポットインスタンスをサポートしない。

問題 SAA-14

「ECSコンテナのワークロードが急増した場合に自動でスケールアウトしたい」場合、どのAuto Scalingを使いますか？

  • A. EC2 Auto Scaling
  • B. ECS Service Auto Scaling（Application Auto Scaling）
  • C. AWS Fargate の自動スケール
  • D. CloudWatch Alarmに基づく手動スケール
正解と解説

正解: B

ECS Service Auto ScalingはECSサービスのタスク数をメトリクスに基づき自動増減する。ターゲット追跡スケーリング、ステップスケーリング、スケジュールドスケーリングが使用可能。

問題 SAA-15

「会社のオンプレミスデータセンターとAWSを専用線で接続したい。インターネットを経由せず、安定した帯域幅が必要」最も適切なサービスはどれですか？

  • A. AWS Site-to-Site VPN
  • B. AWS Direct Connect
  • C. AWS Transit Gateway
  • D. AWS PrivateLink
正解と解説

正解: B

AWS Direct ConnectはオンプレミスとAWSを専用の物理回線（1Gbps, 10Gbps等）で接続する。インターネットを経由しないため、安定した帯域幅・低レイテンシ・セキュアな接続を実現。VPNはインターネット経由で暗号化トンネル。

SAA-C03 試験合格のための学習戦略

重要サービス選択フローチャート

「どのデータベースを選ぶか？」

NoSQLが必要?
  → DynamoDB（スケーラブル・サーバーレス）

リレーショナル?
  → MySQL/PostgreSQL互換: Aurora（性能）またはRDS
  → 大規模データウェアハウス: Redshift
  → OracleやSQL Server: RDS（マネージドEC2）

キャッシュ?
  → Redis: 複雑なデータ構造・HA・Pub/Sub
  → Memcached: シンプルキャッシュ・マルチスレッド

「どのコンピューティングを選ぶか？」

サーバーレス・イベント駆動?
  → Lambda（15分以内の処理）
  → Fargate（コンテナ・長時間処理）

コンテナオーケストレーション?
  → ECS（AWS独自・シンプル）
  → EKS（Kubernetes・複雑・マルチクラウド）

VM（仮想サーバー）が必要?
  → EC2（フル制御・OSレベルカスタマイズ）

機械学習?
  → SageMaker

SAA-C03 試験直前チェックリスト

  • [ ] セキュリティグループ vs NACLの違い（Stateful vs Stateless）
  • [ ] RDS Multi-AZ vs Read Replicaの使い分け
  • [ ] S3全ストレージクラスの特徴（Standard/IA/Glacier等）
  • [ ] EC2購入オプション（オンデマンド/RI/Savings Plans/スポット）
  • [ ] Auto Scalingの3つのスケーリングポリシー
  • [ ] Route 53のルーティングポリシー7種
  • [ ] ALB vs NLBの違い
  • [ ] VPCゲートウェイエンドポイント vs インターフェイスエンドポイント
  • [ ] CloudFront 署名付きURL vs Cookie
  • [ ] Direct Connect vs Site-to-Site VPN
  • [ ] RDS Proxyの用途
  • [ ] ElastiCache Redis vs Memcached

付録: SAA-C03 頻出サービス一覧

★★★ 必ず覚えるサービス

サービス SAA試験での重点
Amazon VPC サブネット設計・SG/NACL・エンドポイント
Amazon EC2 購入オプション・Auto Scaling・ELB
Amazon S3 ストレージクラス・セキュリティ・レプリケーション
Amazon RDS Multi-AZ・Read Replica・Proxy
Amazon Aurora MySQL/PostgreSQL互換・高性能・Auto Scaling
Amazon DynamoDB NoSQL・グローバルテーブル・DAX
Amazon CloudFront CDN・OAC・署名付きURL/Cookie
Amazon Route 53 ルーティングポリシー7種・ヘルスチェック
AWS ELB（ALB/NLB） Layer4/7・ルーティング・固定IP
AWS IAM ポリシー・ロール・STS
Amazon ElastiCache Redis vs Memcached・セッション管理
AWS Direct Connect 専用線・帯域保証
AWS VPN Site-to-Site・Client VPN
AWS Lambda サーバーレス・15分タイムアウト
Amazon SQS/SNS 非同期通信・イベント駆動
Amazon ECS/EKS コンテナオーケストレーション
AWS KMS 暗号化キー管理
AWS Secrets Manager 認証情報管理・自動ローテーション
AWS CloudTrail APIコール監査
Amazon CloudWatch メトリクス・ログ・アラーム

高可用性アーキテクチャ設計

Multi-Region アーキテクチャ

DR 戦略と AWS サービス:

Backup & Restore (RPO: 時間, RTO: 時間):
  S3 CRR でデータを別リージョンに複製
  RDS スナップショットをクロスリージョンコピー
  復旧時: スナップショットから RDS を起動

Pilot Light (RPO: 分, RTO: 分〜時間):
  データ: RDS クロスリージョンレプリカ（常時同期）
  インフラ: CloudFormation テンプレート（起動準備）
  復旧時: レプリカを昇格、インスタンスを起動

Warm Standby (RPO: 秒, RTO: 分):
  縮小スケールのシステムを別リージョンで常時稼働
  Route 53 フェイルオーバーで切り替え

Active-Active (RPO: 0, RTO: 0):
  両リージョンで同時にトラフィックを処理
  Route 53 Latency/Weighted でトラフィック分散
  DynamoDB Global Tables / Aurora Global Database

ECS と EKS の選択

Amazon ECS（Elastic Container Service）:
  AWS ネイティブ、シンプル
  Launch Types:
    EC2: ホストを自分で管理（コスト最適化可能）
    Fargate: サーバーレス（インフラ管理不要）
  
  Task Definition: コンテナ設定の定義
  Service: タスクの数を維持・ロードバランサーと統合
  
Amazon EKS（Elastic Kubernetes Service）:
  Kubernetes 標準、ポータビリティ
  Node Types:
    Managed Node Group: AWS がノードのライフサイクル管理
    Self-Managed Node: 自分でノードを管理
    Fargate: サーバーレス
  
  EKS vs ECS 選択:
    Kubernetes が必要/既存の K8s スキル → EKS
    AWS ネイティブでシンプル/初学者 → ECS

AWS Fargate:
  ECS と EKS 両方で使用可能
  コンテナのインフラ管理不要
  タスク/Pod レベルで CPUとメモリを指定
  サイズ変更が柔軟

マイクロサービスアーキテクチャ

典型的なマイクロサービス構成:

API Gateway（エントリーポイント）
    ↓
Lambda / ECS Services（各マイクロサービス）
    ↓
SQS/SNS/EventBridge（非同期通信）
    ↓
DynamoDB / RDS / ElastiCache（データストア）

サービスディスカバリ:
  AWS Cloud Map: サービスレジストリ（DNS/API）
  ECS Service Connect: ECS サービス間の通信を簡素化
  App Mesh: サービスメッシュ（mTLS/トラフィック制御）

Circuit Breaker パターン:
  App Mesh / ALB でヘルスチェックと自動フェイルオーバー
  Lambda でリトライロジックと DLQ を活用

ストレージサービス詳細

EFS（Elastic File System）

EFS の特徴:
  共有ファイルシステム（複数 EC2 インスタンスが同時マウント）
  自動スケール（容量の事前設定不要）
  マルチ AZ（標準）またはシングル AZ（コスト削減）

パフォーマンスモード:
  General Purpose（デフォルト）: 低レイテンシ、汎用
  Max I/O: 高スループット、高レイテンシ（数万クライアント）

スループットモード:
  Bursting: ファイルシステムサイズに比例
  Provisioned: 必要なスループットを事前設定（高コスト）
  Elastic（推奨）: 自動スケール（新デフォルト）

ストレージクラス:
  Standard: 頻繁なアクセス
  Standard-IA: 低頻度アクセス（コスト削減）
  One Zone: 単一 AZ（さらに安価）
  
vs S3 vs EBS:
  EFS: 共有ファイルシステム、複数 EC2、Linux のみ
  EBS: 単一 EC2 に接続するブロックストレージ
  S3: オブジェクトストレージ、HTTP API
  FSx for Windows: Windows ファイルサーバー（SMB）

Amazon FSx

FSx for Windows:
  SMB プロトコル（Windows ファイル共有）
  Active Directory 統合
  SQL Server や IIS との統合

FSx for Lustre:
  HPC（高性能コンピューティング）向け
  S3 との直接統合（S3 をデータリポジトリとして使用）
  ML 学習データの高速入出力
  最大数百 GB/秒のスループット

FSx for NetApp ONTAP:
  NetApp ONTAP 互換（オンプレからの移行）
  NFS/SMB/iSCSI をサポート
  データ圧縮・重複排除

FSx for OpenZFS:
  Linux/macOS 向けファイルシステム
  高性能・低レイテンシ

データベースサービス詳細

Aurora 高度な機能

Aurora Serverless v2:
  オンデマンドで Aurora の容量を自動調整
  ACU（Aurora Capacity Unit）単位でスケール
  0.5 ACU〜 最大 128 ACU
  ユースケース: 断続的なワークロード、開発/テスト環境

Aurora Global Database:
  1プライマリリージョン + 最大5セカンダリリージョン
  クロスリージョンレプリケーション: 通常 < 1 秒
  ユースケース: グローバルなアプリケーション、DR
  フェイルオーバー: セカンダリを昇格（RPO < 1秒、RTO < 1分）

Aurora Machine Learning:
  Aurora SQL から SageMaker/Comprehend を呼び出し
  例: SELECT predict_sentiment(comment_text) FROM reviews;

ElastiCache 詳細

Redis クラスターモード 有効 vs 無効:
  クラスターモード無効:
    1プライマリ + 最大5レプリカ
    スケールアップ（垂直）のみ
    
  クラスターモード有効:
    複数シャード（水平スケール）
    シャードごとにプライマリ+レプリカ
    ノード障害時は自動フェイルオーバー

エビクション戦略（メモリが満杯の時）:
  noeviction: エラーを返す（危険）
  allkeys-lru: 全キーから LRU で削除（最も一般的）
  volatile-lru: TTL があるキーから LRU で削除
  allkeys-random: ランダム削除

セッション管理でのキャッシュ戦略:
  Write-Through: DB とキャッシュを同時に更新（一貫性高）
  Lazy Loading: キャッシュミス時のみ DB から取得（コスト効率）
  Write-Behind: キャッシュのみ更新して非同期で DB に反映（低レイテンシ）

DynamoDB グローバルテーブル

特徴:
  複数リージョンに自動的にデータを複製
  各リージョンで読み書き可能（Active-Active）
  結果整合性（通常 < 1 秒のレプリケーション遅延）

ユースケース:
  グローバルなユーザー基盤のアプリ
  Active-Active DR

DynamoDB Streams が必要:
  グローバルテーブルは内部的に DynamoDB Streams を使用
  有効化されていないと機能しない

コスト:
  書き込み: rWCU（複製される書き込みは全リージョンで課金）
  読み取り: 通常の RCU と同じ

ネットワーク詳細

Direct Connect + VPN ハイブリッド接続

接続オプション:

Site-to-Site VPN:
  設定: 最短数時間
  帯域: 最大 1.25 Gbps
  レイテンシ: 変動（インターネット経由）
  コスト: 低い
  
Direct Connect:
  設定: 数週間〜数ヶ月
  帯域: 最大 100 Gbps（10G ポート x10）
  レイテンシ: 安定（専用線）
  コスト: 高い（月額固定費）
  
組み合わせ（推奨 HA 設計）:
  Primary: Direct Connect（メイン）
  Backup: VPN（Direct Connect 障害時のフォールバック）

Direct Connect Gateway:
  1つの DX Gateway で複数の VPC と接続（同一/異なるリージョン）
  Transit Gateway との組み合わせで大規模接続

Direct Connect HA:
  冗長性レベル:
    最大回復性: 2箇所のデータセンターに各2回線（合計4回線）
    高い回復性: 2箇所のデータセンターに各1回線
    開発/テスト: 1回線

VPC Peering:
  2つの VPC を直接接続
  双方向通信（全プライベートトラフィック）
  IP CIDR の重複は不可
  Transit: A→B→C の通信不可（VPC B を経由して C に接続できない）
  
AWS PrivateLink（VPC Interface Endpoint）:
  サービスを NLB で公開 → 消費者 VPC に ENI として接続
  一方向（サービス利用側からのアクセスのみ）
  CIDR の重複があっても使用可能
  SaaS サービスの提供に最適
  
使い分け:
  相互通信が必要 → VPC Peering
  サービス公開（一方向）→ PrivateLink
  CIDR 重複がある → PrivateLink
  大規模マルチVPC → Transit Gateway

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

Well-Architected コスト最適化の柱

5つのベストプラクティス:
1. クラウド財務管理の実践
   - コスト割り当てタグ
   - AWS Organizations + 統合請求
   - Budgets + コストアノマリー検出

2. 支出と使用量の可視化
   - Cost Explorer でコスト分析
   - CUR（Cost and Usage Report）で詳細分析

3. コスト効率の高いリソース
   - Compute Optimizer の推奨事項
   - 適切なインスタンスタイプ選択
   - マネージドサービスの活用

4. 需要を管理してリソースを最適化
   - Auto Scaling でオーバープロビジョニングを防ぐ
   - Spot インスタンスの活用

5. 継続的な最適化
   - 未使用リソースの定期的な削除
   - RI/Savings Plans の最適なサイズへの変更

Storage コスト最適化

S3 Intelligent-Tiering vs S3 ライフサイクルポリシー:

S3 Intelligent-Tiering:
  アクセスパターンが不明/変動する場合
  自動的に適切なストレージクラスに移行
  監視・自動化の費用: $0.0025/1,000 オブジェクト/月
  
  ティア:
    Frequent Access (アクセス > 30日前)
    Infrequent Access (30〜90日間アクセスなし)
    Archive Instant (90〜180日間アクセスなし)
    Archive Access (90〜365日間アクセスなし)
    Deep Archive Access (180日+)

ライフサイクルポリシー:
  アクセスパターンが既知/予測可能な場合
  ルールで明示的に移行タイミングを設定
  Intelligent-Tiering の監視費用なし（大量小ファイル向き）

EBS コスト最適化:
  gp3 への移行（gp2 より 20% 安）
  未使用のスナップショット定期削除
  Amazon Data Lifecycle Manager でスナップショット自動削除

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

サーバーレスアーキテクチャパターン

Web アプリケーション（SPA + API）:
  CloudFront + S3（静的コンテンツ）
  API Gateway + Lambda（API）
  Cognito（認証）
  DynamoDB（データ）

イベント駆動処理:
  S3 イベント → Lambda（ファイル処理）
  DynamoDB Streams → Lambda（データ変換）
  SQS → Lambda（キュー処理）

ストリーミング処理:
  Kinesis Data Streams → Lambda（リアルタイム分析）
  MSK → Lambda（Kafka メッセージ処理）

バッチ処理:
  EventBridge Scheduler → Lambda（定期バッチ）
  S3 → Lambda（ファイルバッチ処理）
  EventBridge Pipe（S3→SQS→Lambda）

API のオーケストレーション:
  Step Functions でマイクロサービスを組み合わせ
  エラー処理・リトライ・並列実行を視覚的に定義

模擬試験追加問題（30問）

問題 16

Web アプリケーションは ALB の背後で EC2 インスタンスが動いています。夜間（22:00-06:00）はほぼトラフィックがありませんが、昼間は高負荷です。最もコスト効率の高い設計はどれですか？

  • A. 常時最大の台数のインスタンスを起動する
  • B. Auto Scaling グループにスケジュールドスケーリングとターゲット追跡ポリシーを組み合わせる
  • C. 夜間は ALB を削除して朝に再作成する
  • D. Reserved Instance を購入して常時起動する
正解と解説

正解: B

組み合わせアプローチ:

  1. スケジュールドスケーリング: 22:00 → 最小インスタンス数（1〜2台）、08:00 → 適切な最小数
  2. ターゲット追跡ポリシー: CPU 使用率などに基づいて動的にスケール

夜間に最小構成まで縮小し、昼間のトラフィック増加に自動対応します。

D（Reserved Instance）は常時起動が前提のためコスト最適ではありません。

問題 17

オンプレミスの Oracle データベースを AWS に移行する際、コードの最小変更で高可用性を実現したい場合、最適な選択肢はどれですか？

  • A. Amazon RDS for Oracle（Multi-AZ）
  • B. Amazon Aurora PostgreSQL（Oracle 互換モード）
  • C. Amazon DynamoDB
  • D. Amazon Redshift
正解と解説

正解: A

Oracle からの移行で「コードの最小変更」という要件には、RDS for Oracle が最適です。Oracle SQL、ストアドプロシージャ、Oracle 固有の機能をそのまま使用できます。

Multi-AZ で自動フェイルオーバーによる高可用性も実現できます。

Aurora PostgreSQL への移行（B）はコスト削減になりますが、Oracle 固有の SQL/機能の書き換えが必要になります。

問題 18

大量のファイルを S3 にアップロードするアプリケーションで、転送速度を最大化する方法はどれですか？

  • A. S3 Transfer Acceleration を使用する
  • B. マルチパートアップロードを使用する
  • C. S3 Transfer Acceleration とマルチパートアップロードを組み合わせる
  • D. S3 Express One Zone に変更する
正解と解説

正解: C

組み合わせが最適:

  • マルチパートアップロード: ファイルを複数のパーツに分割して並列アップロード（100MB 以上の場合に推奨、5GB 以上は必須）
  • Transfer Acceleration: CloudFront のエッジロケーションを経由してアップロード。地理的に離れた場所からの転送速度を向上

単独より組み合わせが最も速いです。

問題 19

Amazon RDS の Read Replica からのデータ読み取り整合性について正しい説明はどれですか？

  • A. Read Replica は常に強整合性のデータを返す
  • B. Read Replica は結果整合性で、レプリケーション遅延がある場合は若干古いデータを返す可能性がある
  • C. Read Replica は非同期レプリケーションで、常に古いデータを返す
  • D. Read Replica と プライマリで整合性は同じ
正解と解説

正解: B

RDS Read Replica:

  • 非同期レプリケーション: プライマリへの書き込みが Read Replica に反映されるまでわずかな遅延がある
  • 通常: ミリ秒〜数秒の遅延
  • 負荷が高い場合: 遅延が大きくなる可能性

レプリカラグ（Replica Lag）を CloudWatch で監視することが重要です。

Multi-AZ との違い:

  • Multi-AZ: 同期レプリケーション（強整合性）、読み取りには使えない
  • Read Replica: 非同期（結果整合性）、読み取りに使える

問題 20

VPC のパブリックサブネットとプライベートサブネットを作成しました。プライベートサブネットのEC2インスタンスがインターネットにアウトバウンド通信できるようにするには何が必要ですか？（2つ選択）

  • A. パブリックサブネットに NAT ゲートウェイを配置する
  • B. プライベートサブネットのルートテーブルに NAT ゲートウェイへのルートを追加する
  • C. プライベートサブネットにインターネットゲートウェイを直接アタッチする
  • D. EC2 インスタンスにパブリック IP アドレスを割り当てる
  • E. プライベートサブネットに Elastic IP を付与する
正解と解説

正解: A, B

プライベートサブネットのインターネットアクセスには:

  1. A: パブリックサブネットに NAT ゲートウェイを作成（Elastic IP が自動割り当て）
  2. B: プライベートサブネットのルートテーブルに 0.0.0.0/0 → NAT GW のルートを追加

NATゲートウェイの経路:

  • プライベートサブネット EC2 → NAT GW（パブリックサブネット）→ IGW → インターネット

C（プライベートサブネットに直接 IGW）: 不可（プライベートサブネットの定義と矛盾） D（パブリック IP）: プライベートサブネットでパブリック IP はルーティングされない

問題 21〜45（ショート形式）

問題 21: Aurora Multi-Master の機能は何ですか？ → 正解: 複数のプライマリノードから同時に書き込み可能（現在は Aurora MySQL 2.x でのみサポート、廃止方向）。Aurora Global Database（Active-Active）を使用するのがより現代的なアプローチ

問題 22: S3 の「クロスリージョンレプリケーション（CRR）」を設定する際の前提条件は？ → 正解: バージョニングの有効化（送信側・受信側の両方）。IAM ロール（S3 がレプリケーションを実行するための権限）。ソースとデスティネーションは異なるリージョン

問題 23: CloudFront の「Geo Restriction」と WAF の「Geo Match」の違いは？ → 正解: Geo Restriction（CloudFront レベル）: シンプルな国レベルの制限のみ。WAF Geo Match（WAF レベル）: 国レベルだけでなく、他の WAF ルール（IP/レート制限等）と組み合わせた柔軟な制御が可能

問題 24: Amazon Kinesis Data Streams と Amazon SQS の主な違いは？ → 正解: KDS: データを 1〜365 日間保持（リプレイ可能）、複数コンシューマーが独立して読み取り。SQS: メッセージは一度処理されると削除（通常）、FIFOで順序保証。KDS は「ストリーミング/リプレイ」、SQS は「キュー/分散処理」

問題 25: AWS Lambda と Amazon ECS（Fargate）の使い分けは？ → 正解: Lambda: 短時間（15分以内）、イベント駆動、シンプルな処理、自動スケール。ECS Fargate: 長時間処理、コンテナ化されたアプリ、より多くのリソース必要、既存コンテナの移行

問題 26: Route 53 の「Geolocation ルーティング」と「Latency ルーティング」の違いは？ → 正解: Geolocation: ユーザーの地理的な場所（国/大陸）でルーティング（法的要件/コンテンツのローカライズ）。Latency: ユーザーから各リージョンへの実際の測定レイテンシでルーティング（パフォーマンス最適化）

問題 27: ELB の「スティッキーセッション（Sticky Sessions）」を使う理由と問題点は？ → 正解: 理由: ユーザーの状態をサーバー側で管理する（ステートフル）アプリ。問題点: 特定のインスタンスに負荷が集中し、Auto Scaling の効果が減少。推奨: ElastiCache でセッションを外部管理してステートレスにする

問題 28: Amazon CloudFront で「OAC（Origin Access Control）」を使用する理由は？ → 正解: S3 バケットへの直接アクセスを禁止し、CloudFront 経由のみアクセスを許可。OAI（旧）の後継で、SSE-KMS の暗号化もサポート。バケットポリシーで CloudFront サービスプリンシパルを許可

問題 29: Auto Scaling の「インスタンス保護（Instance Protection）」の用途は？ → 正解: 特定のインスタンスをスケールインから保護する。長時間処理中のインスタンスが意図せず削除されるのを防ぐ。処理完了後に保護を解除してスケールイン可能にする

問題 30: Amazon SQS の「メッセージ保持期間（Message Retention Period）」のデフォルトと最大値は？ → 正解: デフォルト 4 日、最大 14 日。可視性タイムアウト（Visibility Timeout）はデフォルト 30 秒、最大 12 時間。Long Polling の最大待機時間は 20 秒

問題 31: EC2 の「プレイスメントグループ（Placement Group）」の種類と用途は？ → 正解: Cluster: 同一 AZ の低レイテンシ（HPC/分散ML）。Spread: 異なるラックに分散（HA、最大7台/AZ）。Partition: 独立したパーティションに分散（Cassandra/Kafka等の分散DB、独立した障害ドメイン）

問題 32: AWS Lambda の「デスティネーション（Destinations）」の用途は？ → 正解: 非同期呼び出しの成功・失敗時に別のサービス（Lambda/SQS/SNS/EventBridge）に結果を転送。従来のDLQより詳細な情報（入力データ+結果）を転送できる。失敗データの分析やリプロセスに活用

問題 33: Amazon Aurora の「ストレージ自動スケール」の特徴は？ → 正解: ストレージは 10GB から始まり最大 128TB まで自動的に増加。縮小はしない（使用済みスペースは保持）。ストレージを事前にプロビジョニングする必要なし。コスト: 実際のストレージ使用量のみ課金

問題 34: VPC の「デフォルト VPC」の特徴は？ → 正解: 全 AWS アカウントに自動作成（リージョンごと）。CIDR: 172.31.0.0/16。各 AZ にデフォルトサブネット（/20）。インターネットゲートウェイ付き。インスタンスにパブリック IP 自動割り当て。本番環境での使用は非推奨

問題 35: AWS Outposts の用途は？ → 正解: AWS のインフラとサービスをオンプレミスに持ち込む。低レイテンシが必要な場合（工場のリアルタイム制御等）、データレジデンシー要件がある場合。同じ AWS API/サービスをオンプレでも使用できる

問題 36: Amazon CloudWatch の「ダッシュボード」と「ServiceLens」の違いは？ → 正解: ダッシュボード: カスタムメトリクスのグラフ/アラームを可視化。ServiceLens: CloudWatch、X-Ray、アラームを統合した観測性ビュー。マイクロサービスのサービスマップ、依存関係、ヘルスを統合表示

問題 37: Amazon RDS の「Proxy」を使用するメリットは？ → 正解: 接続プールによる DB 接続数の削減（Lambda等の大量短期接続に対応）。IAM 認証の統合（DB パスワード不要）。フェイルオーバー時の接続維持（Multi-AZ フェイルオーバーが高速化）

問題 38: AWS Wavelength のユースケースは？ → 正解: 5G キャリアのエッジに AWS インフラを配置。超低レイテンシが必要なアプリ（AR/VR、自動運転、リアルタイムゲーム）。5Gデバイスからのデータ処理を最寄りのキャリアエッジで実行

問題 39: S3 の「同一リージョンレプリケーション（SRR）」のユースケースは？ → 正解: (1) ログ集約（複数ソースバケット → 集約バケット）、(2) 本番データを開発/テスト環境にコピー、(3) コンプライアンス要件で同リージョン内の冗長コピー、(4) アカウント間のデータ共有

問題 40: VPC の「フローログ」のREJECTアクションが記録される理由は？ → 正解: セキュリティグループまたは NACL によってパケットが拒否された場合。SG の場合: インバウンドの許可ルールに一致しない。NACL の場合: 拒否ルール（Deny）に一致したか、許可ルールに一致しなかった

問題 41: Amazon Cognito の「ユーザープールのカスタムドメイン」の設定方法は？ → 正解: Cognito デフォルトドメイン（xxx.auth.region.amazoncognito.com）またはカスタムドメイン（ACM 証明書が必要、us-east-1 に ACM 証明書を作成）を設定。ホストされた UI で標準的なログイン画面を提供

問題 42: EC2 の「Hibernation（ハイバネーション）」をサポートするインスタンスの要件は？ → 正解: (1) HVM ベースのインスタンス、(2) RAM サイズ ≤ 150 GB、(3) ルートボリューム（EBS）が暗号化されている、(4) インスタンスストアなし、(5) 起動後 60 日以内でないとハイバネーションできない（最大 60 日まで）

問題 43: AWS Global Accelerator と CloudFront の違いは？ → 正解: Global Accelerator: TCP/UDP トラフィック（非HTTP含む）、固定の静的IPアドレスを提供、アプリのパフォーマンス最適化（L4）。CloudFront: HTTP/HTTPS コンテンツ配信・キャッシュ（L7/CDN）。動的ウェブアプリにはGA、静的コンテンツキャッシュには CF

問題 44: Amazon SQS の「Delay Queue」と「Message Timer」の違いは？ → 正解: Delay Queue: キュー全体のデフォルト遅延（0〜15分）。Message Timer: 個々のメッセージに個別の遅延を設定（メッセージ送信時に設定）。両者を組み合わせた場合、Message Timer が優先

問題 45: AWS Step Functions の「Activity Task」の用途は？ → 正解: AWS 外部のワーカー（オンプレミス/他クラウド）が Step Functions のタスクを処理できる仕組み。ワーカーが GetActivityTask でタスクをポーリングし、処理後に SendTaskSuccess/Failure で報告

学習戦略

SAA-C03 試験の特徴

問題の傾向:
  - 「最もコスト効率の高い」選択肢を選ぶ問題が多い
  - HA（高可用性）設計問題
  - セキュリティのベストプラクティス
  - マイグレーション戦略

よく出るシナリオ:
  - オンプレミスから AWS への移行
  - 断続的なワークロードの最適化
  - DR 設計（RTO/RPO 要件）
  - マルチアカウント設計

頻出の「ひっかけ」:
  - Read Replica と Multi-AZ の使い分け（読み取りスケール vs HA）
  - SQS と Kinesis の使い分け（キュー vs ストリーミング）
  - S3 ストレージクラスの選択（コスト vs アクセス頻度）

30日学習プラン

Week 1: コアサービス
  Day 1-2:  EC2（購入オプション/Auto Scaling/ELB）
  Day 3-4:  S3（ストレージクラス/セキュリティ/CRR）
  Day 5-7:  VPC（設計/SG/NACL/エンドポイント）

Week 2: データベースと高可用性
  Day 8-9:  RDS（Multi-AZ/Read Replica/Proxy/Aurora）
  Day 10-11: DynamoDB（GSI/LSI/グローバルテーブル/DAX）
  Day 12-13: ElastiCache + Storage（EFS/FSx）
  Day 14:   高可用性設計（DR戦略/マルチリージョン）

Week 3: セキュリティとネットワーク
  Day 15-16: IAM（ポリシー/ロール/STS/Permission Boundary）
  Day 17-18: 暗号化（KMS/Secrets Manager/ACM）
  Day 19-20: ネットワーク詳細（Direct Connect/Transit GW/PrivateLink）
  Day 21:   CloudFront + Route 53 詳細

Week 4: 仕上げ
  Day 22-24: 模擬試験（本ノートの問題）
  Day 25-27: 弱点補強
  Day 28-30: 直前チェック

試験直前チェックリスト（SAA-C03）

アーキテクチャ設計

  • [ ] RTO/RPO に応じた DR 戦略を選択できる
  • [ ] Multi-AZ（HA）と Read Replica（スケール）の使い分けを説明できる
  • [ ] 適切なストレージサービス（S3/EBS/EFS/FSx）を選択できる
  • [ ] VPC 設計（パブリック/プライベートサブネット/ルーティング）を設計できる
  • [ ] サーバーレスアーキテクチャのユースケースを説明できる

コスト最適化

  • [ ] EC2 購入オプション（On-Demand/RI/SP/Spot）を使い分けられる
  • [ ] S3 ストレージクラスを適切に選択できる
  • [ ] Auto Scaling でオーバープロビジョニングを防げる
  • [ ] Serverless（Lambda/Fargate）のコストメリットを説明できる

セキュリティ

  • [ ] IAM のベストプラクティスを説明できる
  • [ ] KMS の暗号化オプション（AWS管理/カスタマー管理）を説明できる
  • [ ] VPC セキュリティグループと NACL の違いを説明できる
  • [ ] S3 バケットのセキュリティ設定を実装できる

SAA-C03 ソリューションアーキテクトアソシエイト完全ガイド追加セクション完了

第5章: 高度なネットワーク設計

5.1 VPC設計パターン

┌─────────────────────────────────────────────────────────────┐
│               ハブアンドスポーク VPC設計                       │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│    ┌────────────────────────────────────┐                   │
│    │         Hub VPC (共有サービス)       │                   │
│    │  ・DNS (Route 53 Resolver)         │                   │
│    │  ・AD (Directory Service)          │                   │
│    │  ・セキュリティサービス              │                   │
│    │  ・Transit Gateway アタッチメント   │                   │
│    └────────────────┬───────────────────┘                   │
│                     │ Transit Gateway                        │
│         ┌───────────┼───────────┐                           │
│         │           │           │                           │
│    ┌────▼───┐  ┌────▼───┐  ┌───▼────┐                      │
│    │Spoke A │  │Spoke B │  │Spoke C │                      │
│    │(Dev)   │  │(Prod)  │  │(Shared)│                      │
│    └────────┘  └────────┘  └────────┘                      │
│                                                             │
│  ・TGWでルートテーブル隔離（Dev→Prod通信を制限）               │
│  ・Shared ServicesはAll Spoke VPCとピアリング               │
└─────────────────────────────────────────────────────────────┘

import boto3
import json

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

# Transit Gateway 作成
def create_transit_gateway():
    response = ec2_client.create_transit_gateway(
        Description='Hub-and-Spoke TGW',
        Options={
            'AmazonSideAsn': 64512,
            'AutoAcceptSharedAttachments': 'disable',
            'DefaultRouteTableAssociation': 'disable',  # カスタムルートテーブル管理
            'DefaultRouteTablePropagation': 'disable',
            'DnsSupport': 'enable',
            'VpnEcmpSupport': 'enable',
            'MulticastSupport': 'disable'
        },
        TagSpecifications=[{
            'ResourceType': 'transit-gateway',
            'Tags': [{'Key': 'Name', 'Value': 'Main-TGW'}]
        }]
    )
    return response['TransitGateway']['TransitGatewayId']

# TGW ルートテーブル設定（環境分離）
def setup_tgw_route_tables(tgw_id, prod_attachment_id, dev_attachment_id, shared_attachment_id):
    
    # 本番用ルートテーブル（Dev→Prod通信ブロック）
    prod_rt = ec2_client.create_transit_gateway_route_table(
        TransitGatewayId=tgw_id,
        TagSpecifications=[{
            'ResourceType': 'transit-gateway-route-table',
            'Tags': [{'Key': 'Name', 'Value': 'Production-RT'}]
        }]
    )
    prod_rt_id = prod_rt['TransitGatewayRouteTable']['TransitGatewayRouteTableId']
    
    # 本番アタッチメントを本番RTに関連付け
    ec2_client.associate_transit_gateway_route_table(
        TransitGatewayRouteTableId=prod_rt_id,
        TransitGatewayAttachmentId=prod_attachment_id
    )
    
    # SharedサービスへのルートをProd RTに追加
    ec2_client.create_transit_gateway_route(
        TransitGatewayRouteTableId=prod_rt_id,
        DestinationCidrBlock='10.100.0.0/16',  # Shared VPC CIDR
        TransitGatewayAttachmentId=shared_attachment_id
    )
    
    return prod_rt_id

# VPCエンドポイント作成
def create_vpc_endpoints(vpc_id, subnet_ids, sg_id):
    endpoints = {}
    
    # Gateway型エンドポイント（S3、DynamoDB）
    s3_endpoint = ec2_client.create_vpc_endpoint(
        VpcEndpointType='Gateway',
        VpcId=vpc_id,
        ServiceName='com.amazonaws.ap-northeast-1.s3',
        RouteTableIds=['rtb-12345678']
    )
    endpoints['s3'] = s3_endpoint['VpcEndpoint']['VpcEndpointId']
    
    # Interface型エンドポイント（SSM等）
    ssm_services = [
        'com.amazonaws.ap-northeast-1.ssm',
        'com.amazonaws.ap-northeast-1.ssmmessages',
        'com.amazonaws.ap-northeast-1.ec2messages'
    ]
    
    for service in ssm_services:
        endpoint = ec2_client.create_vpc_endpoint(
            VpcEndpointType='Interface',
            VpcId=vpc_id,
            ServiceName=service,
            SubnetIds=subnet_ids,
            SecurityGroupIds=[sg_id],
            PrivateDnsEnabled=True
        )
        endpoints[service.split('.')[-1]] = endpoint['VpcEndpoint']['VpcEndpointId']
    
    return endpoints

# PrivateLinkエンドポイントサービス作成
def create_privatelink_service(nlb_arn):
    """NLBをバックエンドにPrivateLinkサービスを作成"""
    
    response = ec2_client.create_vpc_endpoint_service_configuration(
        NetworkLoadBalancerArns=[nlb_arn],
        AcceptanceRequired=True,  # 手動承認
        PrivateDnsName='api.service.internal',
        TagSpecifications=[{
            'ResourceType': 'vpc-endpoint-service',
            'Tags': [{'Key': 'Name', 'Value': 'MyAPIService'}]
        }]
    )
    
    service_id = response['ServiceConfiguration']['ServiceId']
    service_name = response['ServiceConfiguration']['ServiceName']
    
    # アクセス許可するプリンシパルを設定
    ec2_client.modify_vpc_endpoint_service_permissions(
        ServiceId=service_id,
        AddAllowedPrincipals=[
            'arn:aws:iam::444455556666:root',  # 特定アカウントを許可
            'arn:aws:iam::777788889999:role/ConsumerRole'
        ]
    )
    
    return service_name

5.3 AWS Direct Connect 設計

┌─────────────────────────────────────────────────────────────┐
│                Direct Connect 冗長設計                       │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  オンプレミス DC1       AWS                                  │
│  ┌──────────────┐      ┌────────────────────────────┐      │
│  │ Router A     ├─────→│ DX Location A              │      │
│  │              │      │  Virtual Interface (VIF)   │      │
│  │   BGP AS     ├─────→│                            │      │
│  │  65000       │      └────────────┬───────────────┘      │
│  └──────────────┘                   │                       │
│                                     │ Direct Connect GW     │
│  オンプレミス DC2                    │                       │
│  ┌──────────────┐      ┌────────────▼───────────────┐      │
│  │ Router B     ├─────→│ DX Location B              │      │
│  │              │      │  Virtual Interface (VIF)   │      │
│  └──────────────┘      └────────────────────────────┘      │
│                                                             │
│  ・異なるDCからの2本のDX回線（Active-Active or Active-Passive）│
│  ・LAG（Link Aggregation Group）で帯域幅増加                  │
│  ・バックアップとしてSite-to-Site VPN（IPsec）               │
└─────────────────────────────────────────────────────────────┘

第6章: データベース設計・最適化

6.1 RDS Multi-AZ vs Read Replica

┌─────────────────────────────────────────────────────────────┐
│              RDS Multi-AZ vs Read Replica                   │
├──────────────────────┬──────────────────────────────────────┤
│     Multi-AZ         │        Read Replica                  │
├──────────────────────┼──────────────────────────────────────┤
│ 高可用性目的          │ 読み取りスケールアウト目的              │
│ 同期レプリケーション   │ 非同期レプリケーション                 │
│ スタンバイは読み取り不可│ 読み取りトラフィックを受信             │
│ 自動フェイルオーバー   │ 手動昇格（新マスターに）               │
│ 同一リージョン内      │ クロスリージョン可能                   │
│ フェイルオーバー60-120秒│ レプリカラグあり                     │
└──────────────────────┴──────────────────────────────────────┘

Aurora Multi-Master（廃止済み）→ Aurora Serverless v2 推奨

import boto3

rds_client = boto3.client('rds', region_name='ap-northeast-1')

# RDS Aurora クラスター作成
def create_aurora_cluster(cluster_id, db_name):
    cluster = rds_client.create_db_cluster(
        DBClusterIdentifier=cluster_id,
        Engine='aurora-mysql',
        EngineVersion='8.0.mysql_aurora.3.04.0',
        MasterUsername='admin',
        MasterUserPassword='SecurePassword123!',
        DatabaseName=db_name,
        StorageEncrypted=True,
        DeletionProtection=True,
        EnableCloudwatchLogsExports=['error', 'general', 'slowquery', 'audit'],
        BackupRetentionPeriod=7,
        PreferredBackupWindow='02:00-03:00',
        PreferredMaintenanceWindow='sun:03:00-sun:04:00'
    )
    
    # Writerインスタンス作成
    writer = rds_client.create_db_instance(
        DBInstanceIdentifier=f'{cluster_id}-writer',
        DBInstanceClass='db.r7g.xlarge',
        Engine='aurora-mysql',
        DBClusterIdentifier=cluster_id,
        PubliclyAccessible=False,
        AutoMinorVersionUpgrade=True,
        MonitoringInterval=60,
        MonitoringRoleArn='arn:aws:iam::123456789012:role/rds-monitoring-role',
        EnablePerformanceInsights=True,
        PerformanceInsightsRetentionPeriod=7
    )
    
    # Readerインスタンス作成（読み取りスケールアウト）
    reader = rds_client.create_db_instance(
        DBInstanceIdentifier=f'{cluster_id}-reader-1',
        DBInstanceClass='db.r7g.large',
        Engine='aurora-mysql',
        DBClusterIdentifier=cluster_id,
        PubliclyAccessible=False
    )
    
    return cluster, writer, reader

# RDS Proxy 設定
def create_rds_proxy(cluster_arn, secret_arn, vpc_sg_id, subnet_ids):
    rds_client.create_db_proxy(
        DBProxyName='aurora-proxy',
        EngineFamily='MYSQL',
        Auth=[
            {
                'AuthScheme': 'SECRETS',
                'SecretArn': secret_arn,
                'IAMAuth': 'REQUIRED'
            }
        ],
        RoleArn='arn:aws:iam::123456789012:role/rds-proxy-role',
        VpcSecurityGroupIds=[vpc_sg_id],
        VpcSubnetIds=subnet_ids,
        RequireTLS=True,
        IdleClientTimeout=1800,
        ConnectionPoolConfig={
            'MaxConnectionsPercent': 80,
            'MaxIdleConnectionsPercent': 50,
            'ConnectionBorrowTimeout': 120
        }
    )

6.2 DynamoDB 設計パターン

import boto3
from boto3.dynamodb.conditions import Key, Attr
import json

dynamodb = boto3.resource('dynamodb', region_name='ap-northeast-1')
ddb_client = boto3.client('dynamodb', region_name='ap-northeast-1')

# テーブル設計: シングルテーブルデザイン
def create_single_table():
    """
    E-commerce シングルテーブル設計
    PK: CUSTOMER#<customer_id>, SK: PROFILE
    PK: CUSTOMER#<customer_id>, SK: ORDER#<order_id>
    PK: ORDER#<order_id>, SK: ITEM#<item_id>
    PK: PRODUCT#<product_id>, SK: DETAILS
    """
    
    table = dynamodb.create_table(
        TableName='EcommerceTable',
        KeySchema=[
            {'AttributeName': 'PK', 'KeyType': 'HASH'},
            {'AttributeName': 'SK', 'KeyType': 'RANGE'}
        ],
        AttributeDefinitions=[
            {'AttributeName': 'PK', 'AttributeType': 'S'},
            {'AttributeName': 'SK', 'AttributeType': 'S'},
            {'AttributeName': 'GSI1PK', 'AttributeType': 'S'},
            {'AttributeName': 'GSI1SK', 'AttributeType': 'S'}
        ],
        GlobalSecondaryIndexes=[
            {
                'IndexName': 'GSI1',
                'KeySchema': [
                    {'AttributeName': 'GSI1PK', 'KeyType': 'HASH'},
                    {'AttributeName': 'GSI1SK', 'KeyType': 'RANGE'}
                ],
                'Projection': {'ProjectionType': 'ALL'}
            }
        ],
        BillingMode='PAY_PER_REQUEST',  # オンデマンド
        SSESpecification={
            'Enabled': True,
            'SSEType': 'KMS',
            'KMSMasterKeyId': 'alias/dynamodb-key'
        },
        StreamSpecification={
            'StreamEnabled': True,
            'StreamViewType': 'NEW_AND_OLD_IMAGES'
        },
        PointInTimeRecoverySpecification={
            'PointInTimeRecoveryEnabled': True
        }
    )
    
    table.wait_until_exists()
    return table

# DynamoDB DAX クラスター
def create_dax_cluster(cluster_name, subnet_group, sg_id):
    dax_client = boto3.client('dax')
    
    response = dax_client.create_cluster(
        ClusterName=cluster_name,
        NodeType='dax.r5.large',
        ReplicationFactor=3,  # 3ノードクラスター（Multi-AZ）
        IamRoleArn='arn:aws:iam::123456789012:role/DAXRole',
        SubnetGroupName=subnet_group,
        SecurityGroupIds=[sg_id],
        SSESpecification={'Enabled': True},
        ClusterEndpointEncryptionType='TLS'
    )
    
    return response['Cluster']['ClusterDiscoveryEndpoint']

# DynamoDB Global Tables
def setup_global_tables(table_name, regions):
    ddb_client.update_table(
        TableName=table_name,
        ReplicaUpdates=[
            {
                'Create': {
                    'RegionName': region,
                    'KMSMasterKeyId': f'alias/dynamodb-{region}'
                }
            }
            for region in regions
        ]
    )

# ConditionExpression によるオプティミスティックロック
def optimistic_lock_update(table, pk, sk, expected_version, new_data):
    table = dynamodb.Table('EcommerceTable')
    
    try:
        response = table.update_item(
            Key={'PK': pk, 'SK': sk},
            UpdateExpression='SET #data = :new_data, version = :new_version',
            ConditionExpression='version = :expected_version',
            ExpressionAttributeNames={'#data': 'data'},
            ExpressionAttributeValues={
                ':new_data': new_data,
                ':new_version': expected_version + 1,
                ':expected_version': expected_version
            },
            ReturnValues='ALL_NEW'
        )
        return response['Attributes']
    except dynamodb.meta.client.exceptions.ConditionalCheckFailedException:
        raise Exception(f"Optimistic lock conflict: item was modified by another process")

6.3 ElastiCache 設計

┌─────────────────────────────────────────────────────────────┐
│          ElastiCache Redis vs Memcached 比較                 │
├──────────────────────┬──────────────────────────────────────┤
│       Redis          │         Memcached                    │
├──────────────────────┼──────────────────────────────────────┤
│ 複雑なデータ型対応    │ シンプルなキー・バリュー               │
│ (List, Set, Hash等) │                                      │
│ Pub/Sub             │ 高速シンプルキャッシュ                  │
│ Lua スクリプト       │ マルチスレッド（CPUコア活用）           │
│ レプリケーション      │ レプリケーションなし                   │
│ スナップショット      │ 永続化なし                            │
│ クラスターモード      │ スケールアウト（ノード追加）            │
│ Sorted Sets（ランキング）│                                   │
└──────────────────────┴──────────────────────────────────────┘

import redis
import boto3
import json
import hashlib

# ElastiCache Redis クライアント
class CacheClient:
    def __init__(self, endpoint, port=6379, use_tls=True):
        self.client = redis.Redis(
            host=endpoint,
            port=port,
            ssl=use_tls,
            ssl_cert_reqs='required',
            decode_responses=True
        )
    
    # キャッシュアサイドパターン
    def get_with_cache(self, key, ttl, fetch_func):
        cached = self.client.get(key)
        if cached:
            return json.loads(cached)
        
        data = fetch_func()
        self.client.setex(key, ttl, json.dumps(data))
        return data
    
    # セッション管理
    def create_session(self, session_id, user_data, ttl=3600):
        pipeline = self.client.pipeline()
        pipeline.hmset(f'session:{session_id}', user_data)
        pipeline.expire(f'session:{session_id}', ttl)
        pipeline.execute()
    
    # レートリミット (Sliding Window)
    def check_rate_limit(self, user_id, limit=100, window=60):
        key = f'rate:{user_id}'
        now = int(time.time())
        
        pipeline = self.client.pipeline()
        pipeline.zremrangebyscore(key, 0, now - window)
        pipeline.zcard(key)
        pipeline.zadd(key, {str(now): now})
        pipeline.expire(key, window)
        results = pipeline.execute()
        
        current_count = results[1]
        return current_count < limit
    
    # リーダーボード (Sorted Set)
    def update_leaderboard(self, game_id, user_id, score):
        key = f'leaderboard:{game_id}'
        self.client.zadd(key, {user_id: score})
    
    def get_top_players(self, game_id, count=10):
        key = f'leaderboard:{game_id}'
        return self.client.zrevrange(key, 0, count-1, withscores=True)

第7章: アプリケーション統合

7.1 SQS設計パターン

import boto3
import json
import hashlib
import time

sqs_client = boto3.client('sqs', region_name='ap-northeast-1')

# SQS キュー作成（デッドレターキュー付き）
def create_queue_with_dlq(queue_name, visibility_timeout=30, max_receive_count=3):
    
    # DLQ作成
    dlq_response = sqs_client.create_queue(
        QueueName=f'{queue_name}-dlq',
        Attributes={
            'MessageRetentionPeriod': '1209600',  # 14日間
            'KmsMasterKeyId': 'alias/sqs-key'
        }
    )
    dlq_arn = sqs_client.get_queue_attributes(
        QueueUrl=dlq_response['QueueUrl'],
        AttributeNames=['QueueArn']
    )['Attributes']['QueueArn']
    
    # メインキュー作成
    main_queue = sqs_client.create_queue(
        QueueName=queue_name,
        Attributes={
            'VisibilityTimeout': str(visibility_timeout),
            'MessageRetentionPeriod': '345600',  # 4日間
            'ReceiveMessageWaitTimeSeconds': '20',  # Long Polling
            'RedrivePolicy': json.dumps({
                'deadLetterTargetArn': dlq_arn,
                'maxReceiveCount': str(max_receive_count)
            }),
            'KmsMasterKeyId': 'alias/sqs-key'
        }
    )
    
    return main_queue['QueueUrl'], dlq_response['QueueUrl']

# FIFO キュー（順序保証・重複排除）
def create_fifo_queue(queue_name):
    response = sqs_client.create_queue(
        QueueName=f'{queue_name}.fifo',
        Attributes={
            'FifoQueue': 'true',
            'ContentBasedDeduplication': 'true',  # メッセージハッシュで重複排除
            'DeduplicationScope': 'messageGroup',  # メッセージグループ内で重複排除
            'FifoThroughputLimit': 'perMessageGroupId',  # グループごとのスループット
            'VisibilityTimeout': '30',
            'ReceiveMessageWaitTimeSeconds': '20'
        }
    )
    return response['QueueUrl']

# ファンアウトパターン（SNS→SQS）
def setup_fanout_pattern(topic_name, queue_names):
    sns_client = boto3.client('sns', region_name='ap-northeast-1')
    
    # SNSトピック作成
    topic = sns_client.create_topic(Name=topic_name)
    topic_arn = topic['TopicArn']
    
    subscriptions = []
    for queue_name in queue_names:
        queue_url, _ = create_queue_with_dlq(queue_name)
        queue_arn = sqs_client.get_queue_attributes(
            QueueUrl=queue_url,
            AttributeNames=['QueueArn']
        )['Attributes']['QueueArn']
        
        # SQSキューポリシー（SNSからのメッセージを許可）
        policy = {
            'Version': '2012-10-17',
            'Statement': [{
                'Effect': 'Allow',
                'Principal': {'Service': 'sns.amazonaws.com'},
                'Action': 'sqs:SendMessage',
                'Resource': queue_arn,
                'Condition': {
                    'ArnEquals': {'aws:SourceArn': topic_arn}
                }
            }]
        }
        sqs_client.set_queue_attributes(
            QueueUrl=queue_url,
            Attributes={'Policy': json.dumps(policy)}
        )
        
        # SNSサブスクリプション
        sub = sns_client.subscribe(
            TopicArn=topic_arn,
            Protocol='sqs',
            Endpoint=queue_arn,
            Attributes={
                'FilterPolicy': json.dumps({  # メッセージフィルタリング
                    'event_type': [queue_name.split('-')[-1]]
                })
            }
        )
        subscriptions.append(sub['SubscriptionArn'])
    
    return topic_arn, subscriptions

7.2 EventBridge 高度な設定

import boto3
import json

eb_client = boto3.client('events', region_name='ap-northeast-1')

# EventBridgeカスタムイベントバス
def create_event_driven_architecture():
    
    # カスタムイベントバス作成
    bus = eb_client.create_event_bus(
        Name='OrderProcessingBus',
        Tags=[{'Key': 'Environment', 'Value': 'production'}]
    )
    bus_arn = bus['EventBusArn']
    
    # リソースポリシー（クロスアカウントイベント受信）
    eb_client.put_permission(
        EventBusName='OrderProcessingBus',
        StatementId='AllowPartnerAccount',
        Action='events:PutEvents',
        Principal='444455556666',
        Condition={
            'Type': 'StringEquals',
            'Key': 'aws:PrincipalOrgID',
            'Value': 'o-example12345'
        }
    )
    
    # イベントルール: 注文作成→Lambda処理
    rule1 = eb_client.put_rule(
        Name='OrderCreatedRule',
        EventPattern=json.dumps({
            'source': ['com.myapp.orders'],
            'detail-type': ['Order Created'],
            'detail': {
                'order_amount': [{'numeric': ['>', 10000]}],  # $10000超
                'region': ['ap-northeast-1', 'ap-northeast-3']
            }
        }),
        EventBusName='OrderProcessingBus',
        State='ENABLED'
    )
    
    # ルールのターゲット設定（複数ターゲット）
    eb_client.put_targets(
        Rule='OrderCreatedRule',
        EventBusName='OrderProcessingBus',
        Targets=[
            {
                'Id': 'OrderProcessor',
                'Arn': 'arn:aws:lambda:ap-northeast-1:123456789012:function:process-order',
                'RetryPolicy': {
                    'MaximumRetryAttempts': 2,
                    'MaximumEventAgeInSeconds': 3600
                }
            },
            {
                'Id': 'OrderAuditLog',
                'Arn': 'arn:aws:logs:ap-northeast-1:123456789012:log-group:/orders/audit',
            },
            {
                'Id': 'HighValueOrderAlert',
                'Arn': 'arn:aws:sns:ap-northeast-1:123456789012:HighValueOrders',
                'InputTransformer': {
                    'InputPathsMap': {
                        'order_id': '$.detail.order_id',
                        'amount': '$.detail.order_amount'
                    },
                    'InputTemplate': '"High-value order <order_id> for {{CONTENT}}lt;amount> received"'
                }
            }
        ]
    )
    
    return bus_arn

# EventBridge Scheduler
def create_scheduled_jobs():
    scheduler_client = boto3.client('scheduler', region_name='ap-northeast-1')
    
    # Cronスケジュール: 毎日午前2時にデータ処理
    scheduler_client.create_schedule(
        Name='DailyDataProcessing',
        ScheduleExpression='cron(0 2 * * ? *)',
        ScheduleExpressionTimezone='Asia/Tokyo',
        Target={
            'Arn': 'arn:aws:lambda:ap-northeast-1:123456789012:function:nightly-batch',
            'RoleArn': 'arn:aws:iam::123456789012:role/SchedulerRole',
            'RetryPolicy': {
                'MaximumRetryAttempts': 3,
                'MaximumEventAgeInSeconds': 3600
            }
        },
        FlexibleTimeWindow={
            'Mode': 'FLEXIBLE',
            'MaximumWindowInMinutes': 30  # 前後30分以内に実行
        },
        State='ENABLED'
    )

7.3 Step Functions ワークフロー

import boto3
import json

sfn_client = boto3.client('stepfunctions', region_name='ap-northeast-1')

# 注文処理ワークフロー定義
ORDER_WORKFLOW = {
    "Comment": "Order Processing Workflow",
    "StartAt": "ValidateOrder",
    "States": {
        "ValidateOrder": {
            "Type": "Task",
            "Resource": "arn:aws:lambda:ap-northeast-1:123456789012:function:validate-order",
            "Retry": [
                {
                    "ErrorEquals": ["Lambda.ServiceException", "Lambda.TooManyRequestsException"],
                    "IntervalSeconds": 2,
                    "MaxAttempts": 3,
                    "BackoffRate": 2.0
                }
            ],
            "Catch": [
                {
                    "ErrorEquals": ["ValidationError"],
                    "Next": "HandleValidationError",
                    "ResultPath": "$.error"
                }
            ],
            "Next": "CheckInventory"
        },
        "CheckInventory": {
            "Type": "Task",
            "Resource": "arn:aws:states:::dynamodb:getItem",
            "Parameters": {
                "TableName": "Inventory",
                "Key": {
                    "ProductId": {"S.{{CONTENT}}quot;: "$.product_id"}
                }
            },
            "ResultPath": "$.inventory",
            "Next": "InventoryAvailable?"
        },
        "InventoryAvailable?": {
            "Type": "Choice",
            "Choices": [
                {
                    "Variable": "$.inventory.Item.quantity.N",
                    "NumericGreaterThan": 0,
                    "Next": "ProcessPayment"
                }
            ],
            "Default": "HandleOutOfStock"
        },
        "ProcessPayment": {
            "Type": "Task",
            "Resource": "arn:aws:states:::sqs:sendMessage.waitForTaskToken",
            "Parameters": {
                "QueueUrl": "https://sqs.ap-northeast-1.amazonaws.com/123456789012/payment-queue",
                "MessageBody": {
                    "order_id.{{CONTENT}}quot;: "$.order_id",
                    "amount.{{CONTENT}}quot;: "$.amount",
                    "task_token.{{CONTENT}}quot;: "$.Task.Token"
                }
            },
            "HeartbeatSeconds": 300,
            "TimeoutSeconds": 600,
            "Next": "UpdateInventory"
        },
        "UpdateInventory": {
            "Type": "Task",
            "Resource": "arn:aws:states:::dynamodb:updateItem",
            "Parameters": {
                "TableName": "Inventory",
                "Key": {
                    "ProductId": {"S.{{CONTENT}}quot;: "$.product_id"}
                },
                "UpdateExpression": "SET quantity = quantity - :qty",
                "ExpressionAttributeValues": {
                    ":qty": {"N.{{CONTENT}}quot;: "States.Format('{}', $.quantity)"}
                }
            },
            "Next": "SendConfirmation"
        },
        "SendConfirmation": {
            "Type": "Task",
            "Resource": "arn:aws:states:::sns:publish",
            "Parameters": {
                "TopicArn": "arn:aws:sns:ap-northeast-1:123456789012:OrderConfirmations",
                "Message.{{CONTENT}}quot;: "States.Format('Order {} confirmed', $.order_id)"
            },
            "End": True
        },
        "HandleValidationError": {
            "Type": "Task",
            "Resource": "arn:aws:lambda:ap-northeast-1:123456789012:function:handle-error",
            "End": True
        },
        "HandleOutOfStock": {
            "Type": "Task",
            "Resource": "arn:aws:states:::sns:publish",
            "Parameters": {
                "TopicArn": "arn:aws:sns:ap-northeast-1:123456789012:OutOfStock",
                "Message.{{CONTENT}}quot;: "States.Format('Product {} is out of stock', $.product_id)"
            },
            "End": True
        }
    }
}

def create_order_workflow():
    response = sfn_client.create_state_machine(
        name='OrderProcessingWorkflow',
        definition=json.dumps(ORDER_WORKFLOW),
        roleArn='arn:aws:iam::123456789012:role/StepFunctionsRole',
        type='STANDARD',
        loggingConfiguration={
            'level': 'ALL',
            'includeExecutionData': True,
            'destinations': [{
                'cloudWatchLogsLogGroup': {
                    'logGroupArn': 'arn:aws:logs:ap-northeast-1:123456789012:log-group:/sfn/orders:*'
                }
            }]
        },
        tracingConfiguration={'enabled': True}  # X-Ray トレーシング
    )
    return response['stateMachineArn']

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

問題1 複数のAWSリージョンにまたがるマイクロサービスアーキテクチャで、データの一貫性を最優先にする場合の最適なデータベース選択は？

A) Aurora Global Database（読み取り専用レプリカ） B) DynamoDB Global Tables（マルチリージョン・マルチアクティブ書き込み） C) RDS PostgreSQL + クロスリージョンRead Replica D) ElastiCache Redis Cluster

正解: B 解説: DynamoDB Global Tablesはマルチリージョンでのアクティブ・アクティブ書き込みをサポートし、競合解決（Last Writer Wins）も自動実行。Aurora Global Databaseはプライマリリージョンのみ書き込み可能（リードレプリカのみマルチリージョン）。高可用性・低レイテンシーのグローバルアプリケーションにはGlobal Tablesが最適。

問題2 EC2インスタンスが1000台のフリートで、全インスタンスに対してOSパッチを24時間以内に適用する最も効率的な方法は？

A) Lambda関数で全インスタンスにSSH接続してパッチを実行 B) SSM Patch Manager + Maintenance Windowsで自動パッチ適用 C) CloudFormation StackSetsで全インスタンスを再デプロイ D) AWS Systems Manager Run Commandでスクリプトを並列実行

正解: B 解説: SSM Patch ManagerはパッチベースラインとパッチグループでEC2フリートを管理し、Maintenance Windowsで自動スケジュール実行が可能。コンプライアンスレポートもCloudWatchダッシュボードで確認可能。Run CommandはAd hocな1回限りのコマンド実行向き。大規模フリートの継続的パッチ管理はPatch Managerが最適。

問題3 SQS キューのメッセージが処理失敗し続ける場合に、無限ループを防ぐ最適な設定は？

A) メッセージ可視性タイムアウトを無制限に設定する B) Dead Letter Queue（DLQ）を設定し、maxReceiveCountを超えたメッセージをDLQに移動 C) メッセージを手動で削除するLambdaを作成する D) キューのメッセージ保持期間を短縮する

正解: B 解説: DLQはmaxReceiveCount（1-1000）を超えたメッセージを受け取り、無限再試行ループを防ぐ。DLQのメッセージを後で分析して失敗原因を調査できる。CloudWatchアラームでDLQのメッセージ数を監視してアラート通知を設定するのがベストプラクティス。

問題4 ALBを使用したWebアプリケーションで、特定のURLパスを異なるECSサービスにルーティングする方法は？

A) Route 53の加重ルーティングを使用する B) ALBのリスナールールにパスベースルーティング条件を設定する C) CloudFrontビヘイビアでパスパターンを設定する D) API Gatewayをフロントエンドに追加する

正解: B 解説: ALBリスナールールで/api/*→ECSサービスA、/web/*→ECSサービスBのようなパスベースルーティングが可能。優先度（Priority）の数値が低いルールが優先。デフォルトルールは最後に評価。ホストベース（Host header）、HTTPメソッド、クエリ文字列でも条件付けが可能。

問題5 マルチアカウント環境でVPCのIPアドレス空間を管理する最適なサービスは？

A) AWS Config でVPC CIDRの重複を検出する B) Amazon VPC IP Address Manager（IPAM）でIPプールを一元管理 C) Route 53 プライベートホストゾーンでIPアドレス管理 D) Systems Manager Parameter StoreにIPアドレスを保存する

正解: B 解説: VPC IPAM（IP Address Manager）はOrganizations統合により、複数アカウントのIPアドレス空間を一元管理。IPプールの階層管理（組織→OU→アカウント→リージョン）、VPC作成時のCIDR自動割り当て、重複検出機能を提供。CIDR計画の必要なエンタープライズ環境で必須ツール。

問題6 Amazon API Gatewayで100000 RPSのトラフィックに対応するための設定は？

A) API Gatewayのデフォルトスロットリング（10000 RPS）のままにする B) スロットリングリミットの引き上げをAWSサポートに依頼し、バックエンドにSQSキューを追加 C) API GatewayをLambda関数で置き換える D) CloudFrontをAPI Gatewayの前段に配置してキャッシュする

正解: D / B（複合） 解説: 高トラフィック対応: ①CloudFront+API Gatewayのキャッシュで実際のバックエンドへのリクエストを削減。②スロットリングの引き上げリクエスト（Account level: 10000 RPS、Method level: 設定可能）。③バックエンドにSQSを挟んでAsync処理でピーク対応。API Gateway利用量プラン（Usage Plans）でAPIキーベースのレート制限も設定可能。

問題7 Lambda関数のコールドスタート問題を解決するための最適なアプローチは？

A) Lambda関数のタイムアウトを増やす B) Provisioned Concurrencyを設定する、またはSnapStartを使用する（Java） C) Lambda関数のメモリを最大に設定する D) Lambda関数をEC2に移行する

正解: B 解説: Provisioned ConcurrencyはLambda実行環境を事前にウォームアップしておく機能。コールドスタート遅延をほぼゼロに削減。Auto Scalingと組み合わせて動的なプロビジョニングも可能。Java関数にはSnapStart（Firecracker技術）も有効で初期化済みスナップショットから起動。コスト: Provisioned Concurrencyは常時課金。

問題8 CloudFrontディストリビューションでS3バケットのコンテンツをセキュアに配信する場合の最新の推奨設定は？

A) S3バケットをパブリックにしてCloudFrontからアクセス B) Origin Access Identity（OAI）を使用する C) Origin Access Control（OAC）を使用する（OAIの後継） D) CloudFrontのSignedURLのみを使用する

正解: C 解説: OAC（Origin Access Control）はOAI（Origin Access Identity）の後継サービス。署名付きリクエスト（SigV4）でセキュアなS3アクセス。S3サーバーサイド暗号化（SSE-KMS）対応。すべてのS3リージョンとHTTP方式対応。新規設定はOACを推奨。OAIはレガシー扱い。

問題9 ECS FargateとEC2起動タイプの主な違いは？

A) FargateはDockerイメージをサポートしない B) Fargateはサーバー管理不要（クラスターインスタンス管理不要）、タスク単位の課金 C) FargateはEC2より常にコストが低い D) FargateはAuto Scalingをサポートしない

正解: B 解説: Fargate: インフラ管理不要（ECSクラスターのEC2インスタンス管理不要）、タスク実行時間とCPU/メモリ使用量で課金、スケーリング速度が速い。EC2起動タイプ: EC2インスタンスを自分で管理、GPUやカスタムネットワーク設定が必要な場合に有用、長時間実行・高密度タスクはEC2の方がコスト効率が良い場合も。

問題10 Kinesis Data Streams と SQS の使い分けの主な基準は？

A) Kinesisはリアルタイム分析・複数コンシューマーが同じデータを読む、SQSはメッセージキューで1コンシューマーが1メッセージを処理 B) SQSはリアルタイム処理向き、Kinesisはバッチ処理向き C) KinesisはAWS外部サービスに対応しない D) SQSは最大1MBのメッセージのみサポート（実際は正しい）

正解: A 解説: Kinesis Data Streams: ストリームデータの複数コンシューマー（Enhanced Fan-out）、24時間〜365日のデータ保持、順序保証（シャードレベル）、リアルタイム分析（KDA、Lambda）。SQS: P2Pメッセージキュー、1メッセージを1コンシューマーが処理（FIFO）、デカップリング、マイクロサービス間通信。ストリーミング=Kinesis、非同期タスク=SQS。

問題11 Lambda関数で実行時間が増大しているが、コードの変更なしにパフォーマンス改善する方法は？

A) Lambdaのタイムアウトを増やす B) メモリ割り当てを増やす（CPUも比例して増加） C) Lambda関数をEC2に移行する D) API GatewayのタイムアウトをLambdaに合わせる

正解: B 解説: Lambdaのメモリ割り当てを増やすとCPU能力も比例して増加（128MB→10240MB）。計算集中型のタスクはメモリ増加により実行時間を短縮でき、コスト（メモリ×時間）が下がる場合も。Lambda Power Tuningツールで最適なメモリ設定をテスト可能。

問題12 AWS WAFのマネージドルールグループとカスタムルールの違いは？

A) マネージドルールはAWSまたはパートナーが管理するルールセット（OWASP Top 10等）、カスタムルールは自分で定義するIPセット・文字列マッチ等のルール B) マネージドルールはより低コスト C) カスタムルールの方が検出精度が高い D) マネージドルールはCloudFrontでのみ使用可能

正解: A 解説: AWS WAFマネージドルールグループ: AWSとAWSマーケットプレイスパートナー（Fortinet、Imperva等）が提供。SQL Injection、XSS、既知の悪意あるIPセット（AWSManagedRulesAmazonIpReputationList）等。自動的に最新化。カスタムルール: 独自のIPブロックリスト、レートリミット、地域制限、ヘッダー・クエリ文字列検査等。

問題13 Amazon S3でマルチパートアップロードが推奨されるファイルサイズの閾値は？

A) 1MB以上 B) 100MB以上（推奨） C) 1GB以上 D) 5GB以上（必須）

正解: B 解説: S3マルチパートアップロード推奨: 100MB以上。必須: 5GBを超えるファイル（シングルPUTの最大5GB）。利点: ①並列アップロードで高速化②失敗パートのみ再送③大ファイルのアップロード中断・再開。S3 Transfer Accelerationとの組み合わせで長距離アップロードを高速化。

問題14 複数のAWSアカウントで共通のIAMポリシーを管理する最も効率的な方法は？

A) 各アカウントに同じIAMポリシーを手動でコピーする B) AWS Organizations + SCPで組織レベルのガードレールを設定し、CloudFormation StackSetsで共通IAMロールをデプロイ C) AWS IAM Identity Centerで集中管理 D) Active Directoryフェデレーションを使用する

正解: C / B（複合） 解説: IAM Identity Center（旧SSO）: 人（ユーザー）へのアクセス管理に最適。Permission Setsを定義してアカウント×グループに割り当て。SAML/OIDC IdPとの統合。StackSets: マシンアカウント（EC2、Lambda等のサービスロール）の共通ロール管理に有用。SCPs: 全アカウントへの強制的なガードレール（最小権限原則の強制）。

問題15 EBS gp3とgp2の主な違いは？

A) gp3は古いサービスでgp2が現行 B) gp3はIOPSとスループットを独立して設定可能で、ベースラインIOPSがgp2の3000より高い C) gp3はgp2より常に高コスト D) gp3はEC2インスタンスにアタッチできない

正解: B 解説: gp3: ベースラインIOPS 3000、スループット125MB/s（追加設定なし）。最大16000 IOPS、1000MB/sをgp2より低コストで実現。IOPSとスループットを独立設定（gp2はIOPS=3 x GB）。コスト: gp3はgp2比20%安価。新規ボリュームはgp3を推奨。

問題16 Spot Instancesのスポット中断（Interruption）を処理するベストプラクティスは？

A) スポット中断を完全に防ぐことは不可能なのでSpot不使用 B) Spot Instance Interruption Noticeを2分前に検出し、ステートを保存またはグレースフルシャットダウン C) スポットインスタンスを常にスポット価格の2倍で設定する D) スポットインスタンスは常にSpot Fleetで管理する

正解: B 解説: スポット中断通知は2分前にEC2 Instance Metadata ServiceとEventBridgeで通知。対策: ①アプリケーションがIMDSv2で中断通知を定期ポーリング②EventBridgeルールでLambdaを起動してドレイン処理③チェックポイント/ステート保存④Auto Scalingのインスタンス置き換え（Capacity Rebalancing）。

問題17 AWS CloudTrailのData Eventsを有効化する主な目的は？

A) EC2インスタンスの起動・停止ログ記録 B) S3オブジェクトレベルの操作（GetObject、PutObject）やLambda関数の呼び出しログ記録 C) RDSデータベース操作のログ記録 D) CloudFormationスタック変更のログ記録

正解: B 解説: CloudTrailには2種類のイベントがある。Management Events（デフォルト有効）: AWS APIコントロールプレーン操作（CreateBucket、RunInstances等）。Data Events（追加料金、デフォルト無効）: データプレーン操作（S3: GetObject/PutObject/DeleteObject、Lambda: InvokeFunction、DynamoDB: GetItem/PutItem等）。セキュリティ監査にはData Events有効化が重要。

問題18 Amazon EKSでポッドのAWSリソースへのアクセスをセキュアに管理する方法は？

A) EKSノードのEC2インスタンスプロファイルにIAMポリシーを追加する B) IRSA（IAM Roles for Service Accounts）でサービスアカウントにIAMロールを付与 C) Kubernetes Secretsに AWS認証情報を保存する D) 全ポッドにAWS管理者権限を付与する

正解: B 解説: IRSA（IAM Roles for Service Accounts）: Kubernetes Service AccountとIAM RoleをOIDCフェデレーションで紐付け。ポッドレベルの最小権限IAMロールを付与可能。ノードレベル（EC2インスタンスプロファイル）より粒度が細かく、最小権限原則に沿う。kubectl annotateでService AccountにIAMロールARNを付与。

問題19 Amazon Cognito User PoolsとIdentity Poolsの使い分けは？

A) 両方とも同じ機能を提供する B) User Pools: ユーザー認証（サインイン・サインアップ）。Identity Pools: 認証後にAWSリソースへの一時的な認証情報（IAMロール）を付与 C) Identity Pools: ユーザー認証、User Pools: AWSリソースアクセス D) User Poolsはモバイルアプリのみサポートする

正解: B 解説: User Pools: ユーザーディレクトリ（サインアップ/サインイン）、MFA、パスワードポリシー、ソーシャルIDプロバイダー連携（Google/Facebook/SAML）、JWTトークン発行。Identity Pools: User PoolsやSNS等の外部IdP認証後に一時的なAWS認証情報（STS）を発行。認証済みユーザー向けS3/DynamoDBアクセス等に使用。

問題20 AWS Systems Managerのパラメータ階層（階層型パラメータ）の利点は？

A) 格納できるパラメータ数が増える B) 環境・アプリ・コンポーネント別のパラメータ管理、IAMポリシーでパス前方一致アクセス制御が可能 C) パラメータの暗号化が自動化される D) リージョン間のパラメータ同期が可能

正解: B 解説: 階層型パラメータ例: /production/myapp/database/password。IAMでリソース=arn:aws:ssm:*:*:parameter/production/myapp/*のようにパス前方一致で制御。GetParametersByPath APIで階層全体を取得可能。環境分離（/dev/ vs /prod/）が容易。SecureStringで特定パスのみKMS暗号化も可能。

問題21 AWS Backupを使用して組織全体のバックアップポリシーを管理する場合の設定は？

A) 各アカウントで個別にAWS Backupを設定する B) AWS Organizations管理アカウントからBackup Policyをデプロイして全メンバーアカウントに適用 C) CloudFormation StackSetsでBackup計画をデプロイする D) 手動でS3にスナップショットをコピーする

正解: B 解説: AWS Backup + Organizations統合: Organizations管理アカウントでBackup Policyを作成し、特定のOUまたは全アカウントに適用。バックアップ計画（バックアップ頻度、保持期間、クロスリージョンコピー）を組織全体で一元管理。コンプライアンス要件（SOC2、HIPAA等）のバックアップ要件を自動適用。

問題22 アプリケーションのP99レイテンシーを短縮するための設計変更で最も効果的なのは？

A) EC2インスタンスをより高いタイプにアップグレードする B) キャッシュ層（ElastiCache）の追加、読み取り集中型のDBアクセスを最適化 C) ロードバランサーのアルゴリズムを変更する D) CloudFrontのTTLを延長する

正解: B 解説: P99レイテンシー（99パーセンタイル）が高い原因の多くはDB読み取り。ElastiCacheでホットデータをキャッシュすると応答時間が大幅短縮（ms→μs）。また、RDSのRead Replicaで読み取り分散、接続プーリング（RDS Proxy）でコネクション遅延も削減。N+1クエリ問題の解消もP99改善に有効。

問題23 S3のオブジェクトロック（Object Lock）のWORM（Write Once Read Many）モードの違いは？

A) ComplianceモードとGovernanceモードが存在する B) ComplianceモードはrootでもAWSでも削除不可、Governanceモードはs3:BypassGovernanceRetention権限で削除可能 C) 両モードに違いはない D) GovernanceモードはS3バージョニングを無効化する

正解: B 解説: Object Lock: Compliance Mode: オブジェクト保持期間中は誰も（rootユーザー、AWSサポートも）削除・変更不可。SEC 17a-4等の厳格なコンプライアンス要件向け。Governance Mode: s3:BypassGovernanceRetention権限を持つユーザーのみ削除可能。監査目的での保護。Legal Holdは保持期間に関わらず削除不可（明示的に解除まで）。

問題24 サーバーレスWebアプリケーションのAPIレイヤーで、APIキー管理とレート制限が必要な場合の最適な設計は？

A) Lambda関数内でAPIキーを検証する B) API Gateway + Usage Plans + API Keysでレート制限とクォータを管理 C) CloudFront関数でAPIキーを検証する D) WAFのカスタムルールでAPIキーを検証する

正解: B 解説: API Gateway Usage Plans: APIキーごとのスロットリング（Req/秒）とクォータ（月次Req数）を設定。API Keyをクライアントに配布し、X-API-Keyヘッダーで認証。Cognito認証とAPIキーの組み合わせでBtoB APIのアクセス管理に最適。Usage Plansで課金階層（Free/Basic/Premium）も実装可能。

問題25 Amazon ECS Blue/Greenデプロイメントの仕組みは？

A) 新バージョンを別クラスターに完全デプロイしてDNSを切り替える B) AWS CodeDeployがALBのターゲットグループを切り替えてトラフィックを段階的に新環境に移行 C) CloudFormationのスタック更新で自動的にBlue/Greenが実行される D) Route 53の加重ルーティングでトラフィックを分割する

正解: B 解説: ECS CodeDeploy Blue/Green: ①新タスク定義でGreenターゲットグループにデプロイ②ALBリスナールールでBlue（旧）/Green（新）のトラフィック割合を徐々に変更③全トラフィックがGreenに移行後、Blueタスクを終了④ロールバックはBlueに戻す（CodeDeploy設定）。ダウンタイムゼロデプロイが可能。

問題26 AWS Organizationsのサービスコントロールポリシー（SCP）はどこに適用されますか？

A) IAMユーザーとロールに直接適用される B) OU（組織ユニット）とアカウントに適用され、そのアカウント内のIAMエンティティの最大権限を制限する C) 管理アカウントにも適用される D) SCPはDenyポリシーのみサポートする

正解: B 解説: SCP（Service Control Policy）: OU/アカウントに適用する境界ポリシー。アカウント内のIAM（root含む全ユーザー・ロール）の最大権限を制限。SCPはAllowとDenyどちらも設定可能（ただし明示的なAllowがないとSCPはデフォルトで全拒否）。注意: 管理アカウント（Root）自体にはSCPは適用されない。

問題27 Amazon Rekognitionを使用した画像分析でコストを最小化する場合の設計は？

A) 全画像を常時リアルタイムで分析する B) 事前にS3にアップロードし、Lambda+SQSでバッチ非同期処理として分析 C) EC2 GPU インスタンスで独自モデルを動作させる D) 1回のAPI呼び出しで複数フレームを送信する

正解: B 解説: Rekognition DetectLabels等はリクエスト単位課金。コスト最適化: ①バッチ処理でリクエスト数を最適化②S3画像の場合はS3オブジェクトをRekognition APIに直接渡す（転送コスト削減）③Lambda+SQSで非同期バッチ処理④Rekognition Video（動画）の場合はStartJobで非同期処理。

問題28 マルチリージョンアクティブ-アクティブアーキテクチャで必要なデータベースの要件は？

A) 全リージョンで読み取り専用レプリカが必要 B) マルチリージョンでの書き込み対応（DynamoDB Global Tables、Aurora Global DBのWrite Forwarding） C) リージョン間でのデータ同期は不要 D) 単一リージョンのDBを全リージョンから使用できる

正解: B 解説: Active-Active: 全リージョンで読み書きが必要。DynamoDB Global Tables: マルチリージョン書き込み対応（LWW競合解決）。Aurora Global Database + Write Forwarding: セカンダリリージョンからの書き込みをプライマリに転送。ElastiCache Global Datastore: クロスリージョンキャッシュ。Route 53 Latencyルーティングで最近接リージョンへ誘導。

問題29 AWS Lambdaのデプロイパッケージサイズ制限は？

A) 1MB（ZIP、直接アップロード） B) ZIP 50MB（直接）/ 250MB（アンZIP）、S3経由で250MB（ZIP）/ 512MB（アンZIP） C) 100MB（ZIP）、無制限（S3経由） D) 10MB（ZIP）、50MB（S3経由）

正解: B 解説: Lambda デプロイパッケージサイズ制限: 直接アップロード: ZIP 50MB。S3経由: ZIP 250MB、展開後 250MB。コンテナイメージ: 最大10GB（ECR）。大きな依存関係はLambda Layersに分離（最大5レイヤー、合計250MB）。コンテナイメージはサイズ制限が大きい。

問題30 Amazon CloudWatchのRetention Policyの観点から最適な設計は？

A) 全ロググループを永久保存する（デフォルト設定を維持） B) アプリケーションログ: 30-90日、セキュリティ監査ログ: 1-7年、デバッグログ: 7-14日と用途別に設定 C) 全ロググループを7日間のみ保存する D) ログはS3にエクスポートして全てCloudWatchから削除する

正解: B 解説: CloudWatchログ保存コスト最適化: デフォルトは無期限（コスト無制限）。推奨: ①デバッグ・詳細ログ: 7-14日（開発用）②アプリアクセスログ: 30-90日③セキュリティ/監査（CloudTrail等）: 1-7年（コンプライアンス要件）。長期保存はS3エクスポート→S3 Glacier/Deep Archiveでコスト削減。Terraform/CloudFormationでライフサイクル設定を自動適用。

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

ドメイン1: セキュアなアーキテクチャ設計 (30%)

  • [ ] IAM（ポリシータイプ: アイデンティティ、リソース、権限境界、SCP、セッション）
  • [ ] MFA強制（IAMポリシーCondition: aws:MultiFactorAuthPresent）
  • [ ] KMS（CMK、データキー、エンベロープ暗号化）
  • [ ] S3（バケットポリシー、Block Public Access、Object Lock、MFA Delete）
  • [ ] VPC（セキュリティグループ vs NACL、VPC Flow Logs）
  • [ ] AWS WAF（マネージドルール、カスタムルール）
  • [ ] Shield（Standard vs Advanced）
  • [ ] Cognito（User Pools vs Identity Pools）

ドメイン2: 弾力性のあるアーキテクチャ (26%)

  • [ ] EC2 Auto Scaling（起動テンプレート、スケーリングポリシー）
  • [ ] ELB（ALB/NLB/GLBの使い分け）
  • [ ] Route 53（7つのルーティングポリシー）
  • [ ] CloudFront（OAC、Lambda@Edge、Functions）
  • [ ] Multi-AZ vs Read Replica
  • [ ] Aurora（Global Database、Serverless v2）
  • [ ] DynamoDB（Global Tables、DAX、Point-in-Time Recovery）
  • [ ] SQS/SNS（DLQ、FIFO、ファンアウト）

ドメイン3: 高パフォーマンスアーキテクチャ (24%)

  • [ ] EC2（インスタンスタイプ、Spot Fleet、Placement Groups）
  • [ ] EBS（gp2 vs gp3、io2 Block Express）
  • [ ] EFS（スループットモード、ストレージクラス）
  • [ ] ElastiCache（Redis vs Memcached）
  • [ ] Lambda（メモリ=CPU、Provisioned Concurrency、SnapStart）
  • [ ] API Gateway（キャッシュ、スロットリング、Usage Plans）
  • [ ] Step Functions（Standard vs Express）
  • [ ] Kinesis vs SQS の使い分け

ドメイン4: コスト最適化アーキテクチャ (20%)

  • [ ] EC2 料金（On-Demand、Reserved、Savings Plans、Spot）
  • [ ] S3（ストレージクラス選択、Intelligent-Tiering）
  • [ ] データ転送コスト（同一AZ内無料、クロスAZ有料、インターネット有料）
  • [ ] Serverless（Lambda、Fargate）の従量課金モデル
  • [ ] RDS（Multi-AZのコスト、Read Replicaのコスト）
  • [ ] CloudFront（データ転送コスト削減）

試験のポイント

  1. 「最もコスト効率が良い」= Spot + Auto Scaling / Serverless が多い
  2. 「最も高可用性」= Multi-AZ + Auto Scaling が多い
  3. 「最もセキュア」= IAM最小権限 + KMS暗号化 + VPC Endpoints が多い
  4. 「最も運用効率が良い」= マネージドサービス活用が多い
  5. 新しいサービスを優先（OAC > OAI, gp3 > gp2等）

第8章: コンテナ・サーバーレス高度設計

8.1 Amazon EKS 設計

import boto3
import json

eks_client = boto3.client('eks', region_name='ap-northeast-1')

# EKSクラスター作成
def create_eks_cluster(cluster_name, vpc_id, subnet_ids, sg_id):
    response = eks_client.create_cluster(
        name=cluster_name,
        version='1.29',
        roleArn='arn:aws:iam::123456789012:role/EKSClusterRole',
        resourcesVpcConfig={
            'subnetIds': subnet_ids,
            'securityGroupIds': [sg_id],
            'endpointPublicAccess': False,  # プライベートエンドポイントのみ
            'endpointPrivateAccess': True,
            'publicAccessCidrs': []
        },
        logging={
            'clusterLogging': [
                {
                    'types': ['api', 'audit', 'authenticator', 'controllerManager', 'scheduler'],
                    'enabled': True
                }
            ]
        },
        encryptionConfig=[
            {
                'resources': ['secrets'],
                'provider': {
                    'keyArn': 'arn:aws:kms:ap-northeast-1:123456789012:key/key-id'
                }
            }
        ],
        tags={
            'Environment': 'production',
            'Team': 'platform'
        }
    )
    return response['cluster']

# マネージドノードグループ作成
def create_node_group(cluster_name, node_group_name, subnet_ids):
    response = eks_client.create_nodegroup(
        clusterName=cluster_name,
        nodegroupName=node_group_name,
        scalingConfig={
            'minSize': 2,
            'maxSize': 10,
            'desiredSize': 3
        },
        diskSize=100,
        subnets=subnet_ids,
        instanceTypes=['m5.xlarge'],
        amiType='AL2_x86_64',
        nodeRole='arn:aws:iam::123456789012:role/EKSNodeRole',
        updateConfig={
            'maxUnavailable': 1
        },
        labels={
            'role': 'application',
            'environment': 'production'
        },
        taints=[],
        tags={'Name': node_group_name},
        launchTemplate={
            'id': 'lt-12345678',
            'version': '$Latest'
        }
    )
    return response['nodegroup']

# Fargate Profile（サーバーレスポッド）
def create_fargate_profile(cluster_name, profile_name, subnet_ids):
    response = eks_client.create_fargate_profile(
        clusterName=cluster_name,
        fargateProfileName=profile_name,
        podExecutionRoleArn='arn:aws:iam::123456789012:role/EKSFargateRole',
        subnets=subnet_ids,  # プライベートサブネット必須
        selectors=[
            {
                'namespace': 'fargate-workloads',
                'labels': {'compute': 'fargate'}
            }
        ]
    )
    return response['fargateProfile']

8.2 Lambda コンテナイメージ

# Dockerfile for Lambda Container
FROM public.ecr.aws/lambda/python:3.12

# 依存関係インストール
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

# アプリケーションコード
COPY app/ ${LAMBDA_TASK_ROOT}/

# エントリーポイント
CMD ["handler.lambda_handler"]

# Lambda コンテナイメージのECRデプロイ
import boto3
import subprocess

def deploy_lambda_container(function_name, ecr_repo_uri, tag='latest'):
    ecr_client = boto3.client('ecr', region_name='ap-northeast-1')
    lambda_client = boto3.client('lambda', region_name='ap-northeast-1')
    
    # ECRレポジトリ作成
    try:
        ecr_client.create_repository(
            repositoryName=function_name,
            imageScanningConfiguration={'scanOnPush': True},
            encryptionConfiguration={'encryptionType': 'KMS'}
        )
    except ecr_client.exceptions.RepositoryAlreadyExistsException:
        pass
    
    image_uri = f'{ecr_repo_uri}/{function_name}:{tag}'
    
    # Lambda関数作成/更新
    try:
        lambda_client.update_function_code(
            FunctionName=function_name,
            ImageUri=image_uri
        )
    except lambda_client.exceptions.ResourceNotFoundException:
        lambda_client.create_function(
            FunctionName=function_name,
            PackageType='Image',
            Code={'ImageUri': image_uri},
            Role='arn:aws:iam::123456789012:role/LambdaExecutionRole',
            Timeout=900,
            MemorySize=3008,
            Environment={
                'Variables': {
                    'ENVIRONMENT': 'production'
                }
            },
            VpcConfig={
                'SubnetIds': ['subnet-12345678'],
                'SecurityGroupIds': ['sg-12345678']
            }
        )

8.3 AWS App Runner

import boto3

apprunner_client = boto3.client('apprunner', region_name='ap-northeast-1')

# ECRコンテナからApp Runnerサービス作成
def create_app_runner_service(service_name, ecr_image_uri):
    response = apprunner_client.create_service(
        ServiceName=service_name,
        SourceConfiguration={
            'ImageRepository': {
                'ImageIdentifier': ecr_image_uri,
                'ImageConfiguration': {
                    'Port': '8080',
                    'RuntimeEnvironmentVariables': {
                        'ENVIRONMENT': 'production',
                        'DB_SECRET_ARN': 'arn:aws:secretsmanager:...'
                    }
                },
                'ImageRepositoryType': 'ECR'
            },
            'AutoDeploymentsEnabled': True,
            'AuthenticationConfiguration': {
                'AccessRoleArn': 'arn:aws:iam::123456789012:role/AppRunnerECRRole'
            }
        },
        InstanceConfiguration={
            'Cpu': '1 vCPU',
            'Memory': '2 GB',
            'InstanceRoleArn': 'arn:aws:iam::123456789012:role/AppRunnerInstanceRole'
        },
        AutoScalingConfigurationArn='arn:aws:apprunner:...:autoscalingconfiguration/...',
        HealthCheckConfiguration={
            'Protocol': 'HTTP',
            'Path': '/health',
            'Interval': 10,
            'Timeout': 5,
            'HealthyThreshold': 1,
            'UnhealthyThreshold': 5
        },
        NetworkConfiguration={
            'EgressConfiguration': {
                'EgressType': 'VPC',
                'VpcConnectorArn': 'arn:aws:apprunner:...:vpcconnector/...'
            }
        }
    )
    return response['Service']['ServiceArn']

第9章: 機械学習・AI統合

9.1 Amazon SageMaker 基本

import boto3
import sagemaker
from sagemaker.sklearn.estimator import SKLearn

# SageMaker 学習ジョブ
def train_model(bucket_name, training_data_key):
    sagemaker_client = boto3.client('sagemaker', region_name='ap-northeast-1')
    
    estimator = SKLearn(
        entry_point='train.py',
        source_dir='./src',
        framework_version='1.2-1',
        instance_type='ml.m5.xlarge',
        instance_count=1,
        role='arn:aws:iam::123456789012:role/SageMakerRole',
        hyperparameters={
            'n_estimators': 100,
            'max_depth': 5
        },
        output_path=f's3://{bucket_name}/model-output/',
        enable_sagemaker_metrics=True
    )
    
    estimator.fit({
        'train': f's3://{bucket_name}/{training_data_key}/train/',
        'validation': f's3://{bucket_name}/{training_data_key}/validation/'
    })
    
    return estimator

# SageMaker エンドポイント（リアルタイム推論）
def deploy_endpoint(estimator, instance_type='ml.t3.medium'):
    predictor = estimator.deploy(
        initial_instance_count=1,
        instance_type=instance_type,
        endpoint_name='my-classifier',
        data_capture_config=sagemaker.model_monitor.DataCaptureConfig(
            enable_capture=True,
            sampling_percentage=100,
            destination_s3_uri=f's3://{bucket_name}/data-capture/'
        )
    )
    return predictor

# SageMaker Serverless Inference
def create_serverless_endpoint(model_name):
    sagemaker_client = boto3.client('sagemaker')
    
    sagemaker_client.create_endpoint_config(
        EndpointConfigName=f'{model_name}-serverless-config',
        ProductionVariants=[{
            'ModelName': model_name,
            'VariantName': 'AllTraffic',
            'ServerlessConfig': {
                'MemorySizeInMB': 2048,
                'MaxConcurrency': 50
            }
        }]
    )
    
    sagemaker_client.create_endpoint(
        EndpointName=f'{model_name}-serverless',
        EndpointConfigName=f'{model_name}-serverless-config'
    )

9.2 Amazon Bedrock 統合

import boto3
import json

bedrock_runtime = boto3.client('bedrock-runtime', region_name='us-east-1')

# Claude モデルへのリクエスト
def invoke_claude(prompt, max_tokens=1000):
    response = bedrock_runtime.invoke_model(
        modelId='anthropic.claude-3-5-sonnet-20241022-v2:0',
        body=json.dumps({
            'anthropic_version': 'bedrock-2023-05-31',
            'max_tokens': max_tokens,
            'messages': [
                {'role': 'user', 'content': prompt}
            ]
        }),
        contentType='application/json'
    )
    
    result = json.loads(response['body'].read())
    return result['content'][0]['text']

# Converse API（マルチターン会話）
def multi_turn_conversation(messages):
    response = bedrock_runtime.converse(
        modelId='anthropic.claude-3-5-sonnet-20241022-v2:0',
        messages=messages,
        inferenceConfig={
            'maxTokens': 2000,
            'temperature': 0.7
        }
    )
    return response['output']['message']

# RAG パターン（Bedrock Knowledge Base）
bedrock_agent = boto3.client('bedrock-agent-runtime', region_name='us-east-1')

def rag_query(knowledge_base_id, query):
    response = bedrock_agent.retrieve_and_generate(
        input={'text': query},
        retrieveAndGenerateConfiguration={
            'type': 'KNOWLEDGE_BASE',
            'knowledgeBaseConfiguration': {
                'knowledgeBaseId': knowledge_base_id,
                'modelArn': 'arn:aws:bedrock:us-east-1::foundation-model/anthropic.claude-3-5-sonnet-20241022-v2:0',
                'retrievalConfiguration': {
                    'vectorSearchConfiguration': {
                        'numberOfResults': 5,
                        'overrideSearchType': 'HYBRID'  # セマンティック + キーワード
                    }
                }
            }
        }
    )
    return response['output']['text']

模擬試験 セット3（15問追加）

問題31 Amazon ECS on Fargateでタスクがシークレットを安全に取得する方法は？

A) 環境変数にシークレットをハードコードする B) タスク定義でSecrets Manager ARNまたはParameter Store ARNを参照し、タスク実行ロールに取得権限を付与 C) EC2インスタンスプロファイルを使用する D) Lambdaで事前にシークレットを取得してS3に保存する

正解: B 解説: ECSタスク定義のsecretsフィールドにSecrets Manager ARNまたはSSM Parameter Store ARNを指定。タスク実行ロール（ecsTaskExecutionRole）にsecretsmanager:GetSecretValueまたはssm:GetParameters権限を付与。シークレットは環境変数としてコンテナに注入される。ハードコードは絶対禁止。

問題32 S3 Intelligent-Tieringはどのユースケースに最も適していますか？

A) アクセスパターンが予測可能なデータ B) アクセスパターンが不規則または不明で、コスト最適化したい中〜長期データ C) 頻繁にアクセスするホットデータ D) 即時削除が必要なデータ

正解: B 解説: S3 Intelligent-Tiering: 自動的にアクセス頻度を監視し、30日間アクセスがなければ低頻度アクセス層に移動（追加コストなし）。90日で Archive Instant Access、180日でDeep Archive層へ移動（オプション）。少額のモニタリング費用あり（オブジェクト単位）。アクセスパターンが読めない場合の最適解。

問題33 AWS Transit Gatewayのルートテーブルを使用した環境分離の目的は？

A) 高速データ転送 B) 開発・テスト・本番VPC間の通信を選択的に許可または遮断 C) コスト削減 D) DNS解決の最適化

正解: B 解説: TGWルートテーブル: VPCアタッチメントを特定のルートテーブルに関連付け。ルートテーブルに許可する宛先CIDRのみを追加。例: Dev VPCからProd VPCへのルートを追加しない→通信不可。Shared Services VPCのルートを全ルートテーブルに追加→全環境からアクセス可。マルチアカウント環境のネットワーク管理の核心。

問題34 Amazon API GatewayのVPCリンクの用途は？

A) API GatewayをVPCのElasticIPに直接接続する B) プライベートVPCリソース（NLB経由）にAPI Gatewayからプライベート通信でアクセス C) CloudFrontとAPI Gatewayを接続する D) クロスリージョンのAPI Gateway統合に使用する

正解: B 解説: VPC Link: プライベートサブネットのNLBをバックエンドとするAPI Gateway統合。インターネットを通らずVPC内リソースにアクセス。REST API: VpcLink。HTTP API: VPC Link（異なる仕組み）。マイクロサービスのプライベートエンドポイントをAPI Gateway経由で公開する際に使用。

問題35 CloudFormationスタックを削除した際にS3バケットが削除されないようにする方法は？

A) S3バケットリソースのDeletionPolicyをRetainに設定する B) S3バケットにオブジェクトロックを設定する C) S3バケットをCloudFormation外で作成する D) CloudFormationのTermination Protectionを有効化する

正解: A 解説: CloudFormation DeletionPolicy: Retain: スタック削除時にリソースを保持（削除しない）。Delete: スタック削除時にリソースも削除（デフォルト）。Snapshot: RDS/EBS等でスタック削除前にスナップショット作成後削除。重要なデータを含むS3バケット、RDSインスタンスにはDeletionPolicy: Retainが推奨。

SAA追加学習ポイント

アーキテクチャ選択の判断基準

┌─────────────────────────────────────────────────────────────┐
│                 コンピューティング選択指針                     │
├──────────────────────────────────────────────────────────────┤
│ EC2:          長時間実行、OSレベル制御が必要、ライセンス持込み │
│ ECS Fargate:  コンテナ化、インフラ管理不要、時間課金          │
│ EKS:          Kubernetes互換、大規模マイクロサービス          │
│ Lambda:       イベント駆動、短時間実行、従量課金              │
│ App Runner:   シンプルなコンテナWebアプリ、フルマネージド     │
│ Batch:        大規模バッチ処理、GPU/HPC対応                   │
├──────────────────────────────────────────────────────────────┤
│                 ストレージ選択指針                             │
├──────────────────────────────────────────────────────────────┤
│ S3:           オブジェクトストレージ、無制限スケール           │
│ EBS:          EC2ブロックストレージ、単一インスタンスアタッチ  │
│ EFS:          NFS共有ファイル、複数EC2/ECSから同時アクセス    │
│ FSx for Windows: SMB共有、Windows Serverアプリ               │
│ FSx for Lustre: HPC、機械学習、高スループットが必要           │
├──────────────────────────────────────────────────────────────┤
│                 データベース選択指針                           │
├──────────────────────────────────────────────────────────────┤
│ RDS Aurora:   リレーショナル、高可用性、自動スケール           │
│ DynamoDB:     NoSQL、ミリ秒レイテンシー、無制限スケール        │
│ ElastiCache:  インメモリキャッシュ、セッション管理             │
│ Neptune:      グラフデータベース、関係性分析                   │
│ Timestream:   時系列データ、IoT・監視メトリクス               │
│ DocumentDB:   MongoDB互換、ドキュメントデータ                  │
│ Keyspaces:    Apache Cassandra互換                            │
│ Redshift:     データウェアハウス、大規模分析クエリ             │
└─────────────────────────────────────────────────────────────┘

暗記必須: ポート番号

サービス ポート
SSH 22
HTTP 80
HTTPS 443
MySQL/Aurora 3306
PostgreSQL 5432
Redis 6379
Memcached 11211
Microsoft SQL Server 1433
Oracle 1521
RDP 3389
SMTP 25
NFS 2049
SMB 445

暗記必須: サービス制限

サービス 制限値
S3 オブジェクト最大サイズ 5TB
S3 マルチパート必須 5GB超
Lambda 最大タイムアウト 15分
Lambda 最大メモリ 10240MB
SQS メッセージ最大サイズ 256KB
SQS 最大保持期間 14日
SNS メッセージ最大サイズ 256KB
DynamoDB アイテム最大サイズ 400KB
API Gateway タイムアウト 29秒
CloudFormation テンプレート最大サイズ 1MB（S3）
EBS gp3 最大IOPS 16000
EBS io2 Block Express 最大IOPS 256000