AWS SAA-C03 比較チートシート

試験で最も問われる「A vs B どっち使う？」を完全網羅

🔄 名称変更（リブランド）早見表 — 試験は新名称で出る
古い教材で覚えた名前と、現在AWS／試験で使われる名前の対応。旧名だけで覚えていると本試験で名前が一致せずつまずきやすい要注意ポイント。旧名も“認識用”に覚えておく。
学習時に見かける旧名 → 現在の名称（試験で出る）
Kinesis Data Firehose→Amazon Data Firehose
Kinesis Data Analytics→Amazon Managed Service for Apache Flink
AWS SSO→AWS IAM Identity Center
Amazon Elasticsearch Service→Amazon OpenSearch Service
CloudEndure Migration→AWS Application Migration Service（MGN）
CloudEndure Disaster Recovery→AWS Elastic Disaster Recovery（DRS）
TSO Logic→Migration Evaluator
※ Kinesis Data Streams と Kinesis Video Streams は名称そのまま（Kinesisの中核はData Streams）。
※ Amazon QLDB は名称変更ではないが新規利用停止・2025年でサポート終了。試験ではキーワード対応のみでOK。
VS SQS vs SNS 統合
「システム間を疎結合にしたい」と言われた時に、メッセージの流れが1対1か1対多かで決まる。この2つの組み合わせ（ファンアウト）パターンはSAA超頻出。

SQS

メッセージキュー — 送って、1つのコンシューマーが取りに来る
  • 1対1の非同期メッセージング
  • コンシューマーがポーリングで取得（プルモデル）
  • メッセージを最大14日間保持
  • Standard: 順序なし/無制限/少なくとも1回配信
  • FIFO: 順序保証/正確に1回/300TPS
  • DLQ: 処理失敗メッセージを隔離して後で分析
  • 可視性タイムアウトで重複処理を防止

SNS

Pub/Sub — トピックに送ると、全サブスクライバーに同時配信
  • 1対多のプッシュ型メッセージング
  • トピックにパブリッシュ→全サブスクライバーに即時プッシュ
  • メッセージを保持しない（配信したら消える）
  • サブスクライバー: SQS/Lambda/HTTP/Email/SMS
  • メッセージフィルタリング: 属性で配信先を振り分け
  • FIFO トピック対応（FIFO SQSと連携）
1つのコンシューマーが処理 → SQS  |  複数のシステムに同時配信 → SNS  |  1イベント→複数の独立処理 → SNS+SQSファンアウト
「注文イベントで在庫更新+メール通知+分析記録を同時実行」→SQSだけでは1対1なのでNG。SNS→複数SQSのファンアウトが正解。SQS単体で複数処理はできない。
VS Kinesis vs Amazon MSK 統合
「リアルタイムのストリーミング基盤が欲しい」時、AWSネイティブで作るか、既存のApache Kafka資産を活かすかで決まる。

Kinesis (Data Streams / Firehose)

AWSネイティブのストリーミング — 運用が軽い
  • AWS独自。新規構築で運用最小にしたい時の第一選択
  • Data Streams: シャードで低遅延・複数コンシューマー・再処理(1〜365日)
  • Firehose: S3/Redshift/OpenSearchへコードなし自動配信
  • Kafka互換ではない（クライアントはKinesis API）

Amazon MSK

マネージドApache Kafka — 既存資産をそのまま
  • Apache Kafka互換。既存のプロデューサー/コンシューマー・ツールをそのまま
  • ブローカー/メタデータ管理・パッチ・スケールをAWSが担当
  • Multi-AZで高可用、MSK Serverless / MSK Connectも
  • Kafka運用から解放されたい移行に最適
新規・AWSネイティブで運用最小 → Kinesis  |  既存Kafka資産/Kafka互換が必要 → MSK  |  ActiveMQ/RabbitMQ互換 → Amazon MQ
「オンプレのKafkaをそのままAWSへ」→Kinesisはコード改修が必要。MSKが正解。新規で運用を最小化したいだけならKinesisが有利。
VS GuardDuty vs Security Hub セキュリティ
セキュリティ系は役割分担が問われる。「検出する」か「集約・可視化する」か「原因を調査する」かで使い分ける。

GuardDuty

脅威“検出” — ログをMLで分析
  • VPC Flow Logs/CloudTrail/DNSログをMLで分析し脅威を検出
  • 暗号通貨マイニング/不正API/ブルートフォース等
  • 有効化するだけ・エージェント不要
  • あくまで“見つける”のが役割

Security Hub

検出結果の“集約・可視化” — 司令塔
  • GuardDuty/Inspector/Macie等の検出を1か所に集約(ASFF)
  • CIS/AWS基礎/PCI DSS等の基準チェックとスコア
  • EventBridge連携・Organizationsで全アカウント一元管理
  • 組織全体のセキュリティ体制を可視化
脅威を検出 → GuardDuty  |  複数の検出を集約・準拠を可視化 → Security Hub  |  検出の根本原因を調査 → Detective
「組織全体のセキュリティ状態を一元的に把握」→個別のGuardDutyではなくSecurity Hubで集約。原因の深掘り調査はDetective。
VS ALB vs NLB vs GWLB NW
「ロードバランサーを配置したい」で必ず出る比較。問題文のプロトコル（HTTP？TCP？）と要件（パスルーティング？静的IP？セキュリティアプライアンス？）でレイヤーを見極めるのが鍵。

ALB

L7ロードバランサー — HTTPリクエストの中身を見てルーティング
  • レイヤー7（HTTP/HTTPS/gRPC）で動作
  • パスベース・ホストベースルーティング対応
  • WebSocketとHTTP/2をネイティブサポート
  • ターゲットグループ: EC2/ECS/Lambda/IP
  • スティッキーセッション（Cookie）対応
  • WAFとの統合でWebアプリ保護

NLB

L4ロードバランサー — パケットレベルで超高速に振り分け
  • レイヤー4（TCP/UDP/TLS）で動作
  • 超低レイテンシー（数百万リクエスト/秒）
  • 静的IP / Elastic IPをAZごとに割当可能
  • 送信元IPアドレスを保持（クライアントIPが見える）
  • PrivateLink（VPCエンドポイントサービス）に必須
  • TLSターミネーション対応

GWLB

L3ゲートウェイ — トラフィックをセキュリティ機器に透過的に転送
  • レイヤー3（IPパケット）で動作
  • ファイアウォール/IDS/IPS等の仮想アプライアンスをスケール
  • GENEVEプロトコル（ポート6081）でカプセル化
  • トラフィックの透過的インスペクション
  • Gateway Load Balancer Endpointで別VPCから利用
HTTP/パスルーティング/WAF → ALB  |  超低レイテンシー/静的IP/PrivateLink → NLB  |  セキュリティアプライアンス透過検査 → GWLB
「固定IPが必要」「PrivateLinkで公開したい」→ALBではなくNLB。ALBは動的IPなので固定IPが欲しければNLBを前段に置くか、NLB単体を使う。GWLBはアプライアンス以外では出ない。
VS Aurora vs RDS DB
どちらもマネージドRDBだが、可用性・スケーラビリティ・コストの要件で使い分ける。「MySQL/PostgreSQLで高可用性」と言われたらAurora、「Oracle/SQL Serverが必要」ならRDS一択。

Aurora

AWS独自エンジン — MySQL/PostgreSQL互換で圧倒的な可用性
  • MySQL5倍/PostgreSQL3倍のスループット
  • 3AZ・6コピー自動レプリケーション（4/6書込OK）
  • ストレージ最大128TB自動拡張（10GB単位）
  • 最大15リードレプリカ（レプリカラグ10-20ms）
  • Aurora Serverless v2: ACU単位で自動スケール
  • Aurora Global Database: クロスリージョン1秒以内レプリカ
  • フェイルオーバー30秒以内

RDS

標準RDB管理サービス — 6エンジン対応の万能型
  • MySQL/PostgreSQL/MariaDB/Oracle/SQL Server/DB2
  • Multi-AZ: 同期スタンバイ1台（フェイルオーバー60-120秒）
  • Multi-AZ Cluster: 書込1台+読取2台（PostgreSQL/MySQL）
  • ストレージ最大64TB（gp3/io1/io2）
  • 最大5リードレプリカ
  • 自動バックアップ（最大35日）+ 手動スナップショット
  • 小〜中規模ならAuroraよりコスト安
MySQL/PG+高可用性+高性能 → Aurora  |  Oracle/SQL Server必須 → RDS  |  不規則ワークロード+コスト最適化 → Aurora Serverless v2
「Auroraは全DBエンジンに対応」は嘘。MySQL/PostgreSQL互換のみ。Oracle/SQL Serverが問題文に出たらRDS一択。また「リードレプリカ5台以上」が要件ならRDS(5台)ではなくAurora(15台)。
VS DynamoDB vs RDS/Aurora DB
データベース選択の最も基本的な分岐点。データの関係性（JOIN）が必要か、スケールと速度が優先かで決まる。SAA頻出の「どのDBを選ぶ？」問題の入口。

DynamoDB

フルマネージドNoSQL — キーで引いて1桁ミリ秒で返す
  • キーバリュー+ドキュメント型NoSQL
  • 1桁ミリ秒のレイテンシー（DAXでマイクロ秒）
  • テーブル容量無制限自動スケール
  • オンデマンド or プロビジョニング容量モード
  • DynamoDB Streams: 変更をリアルタイムキャプチャ
  • グローバルテーブル: マルチリージョン Active-Active
  • TTL: 期限切れデータの自動削除

RDS/Aurora

リレーショナルDB — SQLでJOINして複雑なクエリを実行
  • SQLベースのリレーショナルモデル
  • ACIDトランザクション保証
  • 複雑なJOIN/集約/サブクエリに対応
  • 外部キー制約によるデータ整合性
  • スキーマによる厳密なデータ構造
  • 既存SQLアプリケーションの移行先として最適
複雑なクエリ/JOIN/ACID → RDS/Aurora  |  シンプルkey-value+無限スケール+低レイテンシー → DynamoDB  |  セッション管理/ゲームスコア → DynamoDB
「DynamoDBでJOIN」はできない。問題文に「複雑なリレーション」「既存のSQLクエリをそのまま使いたい」があればRDS/Aurora。逆に「スキーマが頻繁に変わる」「無限にスケールしたい」はDynamoDB。
VS ElastiCache: Redis vs Memcached DB
キャッシュ層を追加する時の選択。機能の豊富さ（Redis）vs シンプルさ（Memcached）で分かれるが、試験では9割方Redisが正解。Memcachedが正解になるケースを覚える方が効率的。

Redis

多機能キャッシュ — データ構造+永続化+レプリケーション全部入り
  • Multi-AZ自動フェイルオーバー対応
  • レプリケーション（最大5リードレプリカ）
  • データの永続化（AOF/RDB）
  • ソート済みセット: リアルタイムランキングに最適
  • Pub/Sub メッセージング機能
  • Luaスクリプト/トランザクション対応
  • バックアップ・リストア対応

Memcached

シンプルキャッシュ — マルチスレッドで純粋なキャッシュ性能を追求
  • マルチスレッドアーキテクチャ（マルチコア活用）
  • シンプルなキーバリューのみ
  • スケールアウトが容易（ノード追加でシャーディング）
  • 永続化なし（純粋なキャッシュ用途）
  • Multi-AZ非対応、レプリケーションなし
  • バックアップ・リストア非対応
高可用性/永続化/複雑なデータ型 → Redis  |  リーダーボード/ランキング → Redis  |  純粋にシンプルなキャッシュ+マルチスレッド → Memcached
「ランキング機能」「リーダーボード」が出たらRedisのソート済みセット一択。Memcachedにはデータ構造がない。また「キャッシュの永続化」「フェイルオーバー」が要件ならMemcachedは除外。
比較 S3 ストレージクラスの使い分け Storage
アクセス頻度と取り出し時間がクラス選択の決め手。ライフサイクルポリシーで自動移行する設計パターンが頻出。「最小コストで保存」系の問題は必ずこの比較に帰着する。
クラス アクセス頻度 取得時間 最低保存期間 AZ
Standard頻繁即時なし3AZ+
Standard-IA低頻度即時30日3AZ+
One Zone-IA低頻度・再作成可能即時30日1AZ
Glacier Instant四半期1回ミリ秒90日3AZ+
Glacier Flexible年1-2回分〜12時間90日3AZ+
Deep Archive年1回以下12〜48時間180日3AZ+
Intelligent-Tieringパターン不明自動最適化なし3AZ+
最小コスト長期保存（取出し遅くてOK） → Deep Archive  |  アクセス頻度不明 → Intelligent-Tiering  |  低頻度だが即座に取得 → Standard-IA / Glacier Instant
「アーカイブ+すぐ取り出したい」→Deep ArchiveではなくGlacier Instant Retrieval。One Zone-IAは再作成可能なデータのみ（サムネイル等）。重要データをOne Zoneに置く選択肢は罠。
VS EBS vs EFS vs S3 Storage
AWSストレージの3本柱。ブロック vs ファイル vs オブジェクトの違いと、「誰がどうアクセスするか」で決まる。EC2ディスク/共有ファイル/静的コンテンツの使い分けが鍵。

EBS

ブロックストレージ — EC2の仮想ディスク
  • ブロックレベルストレージ
  • 1つのEC2にアタッチ（io1/io2はマルチアタッチ可）
  • 単一AZ内でレプリケート
  • gp3/gp2/io1/io2/st1/sc1の6タイプ
  • OS起動ディスク/データベースに利用
  • スナップショットでバックアップ（S3に保存）
  • 暗号化はワンクリック（KMS連携）

EFS

ファイルシステム — 複数EC2からNFSマウント
  • NFS v4プロトコル（POSIXファイルシステム）
  • 複数EC2/コンテナから同時マウント
  • マルチAZ対応（リージョンをまたぐ）
  • Linux専用（Windowsは非対応→FSx）
  • 自動スケール（ペタバイト級まで）
  • ライフサイクル管理でIA移行可能

S3

オブジェクトストレージ — HTTPでどこからでもアクセス
  • オブジェクト（キー/バリュー）ストレージ
  • 容量無制限（1オブジェクト最大5TB）
  • HTTP/HTTPSでアクセス（REST API）
  • 静的Webホスティング対応
  • バージョニング/ライフサイクル/レプリケーション
  • 他サービスとの連携が最も広い
EC2のOSディスク/DB → EBS  |  複数EC2でファイル共有 → EFS  |  静的コンテンツ/バックアップ/データレイク → S3
「Windowsインスタンスで共有ストレージ」→EFSではなくAmazon FSx for Windows。EFSはLinux（NFS）のみ。また「EBSを複数EC2で共有」は基本不可（io1/io2マルチアタッチは同一AZ限定の特殊用途）。
VS Direct Connect vs VPN NW
オンプレミス接続の2択。「安定帯域+低レイテンシー」か「すぐ使える+安い」かで決まる。DX開通までの間VPNを使うバックアップパターンも頻出。

Direct Connect (DX)

専用線 — オンプレとAWSをプライベートに直結
  • 専用物理回線（インターネットを経由しない）
  • 一貫した帯域（1Gbps / 10Gbps / 100Gbps）
  • 低レイテンシーで安定した通信品質
  • セットアップに数週間〜数ヶ月必要
  • デフォルトでは暗号化なし（必要ならVPNを重ねる）
  • DX Gateway: 複数リージョンのVPCに接続可能
  • LAG（Link Aggregation Group）で帯域束ね

Site-to-Site VPN

暗号化トンネル — インターネット経由ですぐ繋がる
  • インターネット経由のIPSecトンネル
  • 暗号化された通信（デフォルトで暗号化）
  • セットアップ数分〜数時間
  • 帯域はインターネット品質に依存（不安定）
  • VPN接続あたり最大1.25Gbps
  • コスト: DXより大幅に安い
  • 冗長化: 2つのトンネルが自動作成
安定+高帯域+低レイテンシー → Direct Connect  |  すぐ+安く+暗号化 → VPN  |  DX開通までの暫定+冗長性 → DX + VPNバックアップ
「DXはデフォルトで暗号化されている」は嘘。DX上で暗号化したければDX + VPNの組み合わせが必要。また「すぐにオンプレ接続が必要」→DXは数ヶ月かかるのでVPNが正解。
VS CloudWatch vs CloudTrail vs Config 監視
AWS監視三兄弟。それぞれ「何を見ているか」がまったく違う。パフォーマンス？操作ログ？設定変更？問題文のキーワードで一発判定できる。

CloudWatch

パフォーマンス監視 — メトリクス・ログ・アラーム
  • メトリクス: CPU/メモリ/ディスク/ネットワーク監視
  • アラーム: 閾値超えでSNS通知/Auto Scaling
  • Logs: ログ収集・検索・分析
  • カスタムメトリクス（アプリ独自値）
  • ダッシュボードでグラフ可視化
  • Events/EventBridge: イベント駆動自動化

CloudTrail

API操作記録 — 誰が・いつ・何をしたかの監査証跡
  • API呼び出しの完全な記録（監査証跡）
  • 誰が（IAMユーザー/ロール）操作したか
  • 管理イベント/データイベント/Insightsイベント
  • デフォルト90日保持（証跡作成でS3に永続化）
  • セキュリティ分析・コンプライアンス監査に必須
  • 組織全体の証跡で一元管理可能

Config

設定変更追跡 — リソースが基準に準拠しているか評価
  • リソースの設定変更履歴を記録
  • コンプライアンスルールで自動評価
  • 「SG でポート22が開いている」等を検出
  • 修復アクション（SSM Automation連携）
  • リソース間の関係性マッピング
  • マルチアカウント集約（Aggregator）
「CPUが高い/アラーム」 → CloudWatch  |  「誰が削除した？/監査」 → CloudTrail  |  「設定は基準準拠？/コンプライアンス」 → Config
「SGの変更を検知して通知」→Config Rules（設定変更の評価）。「SGを変更した人を特定」→CloudTrail（API操作の記録）。目的が「検知」か「犯人特定」かで使い分け。CloudWatchはリソースのパフォーマンスだけ。
VS GuardDuty vs Inspector vs Macie Security
セキュリティ検出サービス三兄弟。外からの攻撃（GuardDuty）、中の弱点（Inspector）、データの機密性（Macie）と守る対象が全然違う。問題文の「何を守りたいか」で一発。

GuardDuty

脅威検出 — 外部攻撃・不審な動きをAIで発見
  • 脅威インテリジェンスベースの検出
  • VPCフローログ/CloudTrail/DNS自動分析
  • 不正アクセス・暗号通貨マイニング検出
  • マルウェア検出（EBS スキャン）
  • 有効化するだけ（エージェント不要）
  • EventBridgeで自動修復連携

Inspector

脆弱性スキャン — EC2/コンテナ/Lambdaの弱点を発見
  • ソフトウェアのCVE脆弱性を自動スキャン
  • 対象: EC2/ECRコンテナ/Lambda
  • ネットワーク到達可能性のチェック
  • SSM Agentと連携（EC2の場合）
  • 重要度スコアで優先順位付け
  • Security Hubに結果を集約

Macie

機密データ発見 — S3の中のPII/機密情報をAIで検出
  • S3バケット特化の機密データ検出
  • PII（個人情報）を機械学習で発見
  • クレジットカード番号/SSN/メールアドレス等
  • データの自動分類とインベントリ
  • バケットの公開設定・暗号化状態も評価
  • コンプライアンス対応（GDPR/HIPAA等）
外部攻撃/不審なアクティビティ → GuardDuty  |  EC2/コンテナの脆弱性 → Inspector  |  S3の機密データ発見 → Macie
「S3の不正アクセスを検知」→MacieではなくGuardDuty（S3保護機能あり）。Macieは「中身に個人情報があるか」の検出。「EC2のパッチ未適用を検出」→GuardDutyではなくInspector。
VS Secrets Manager vs Parameter Store Security
機密情報の管理方法。「自動ローテーション」が必要かが最大の判断基準。DBのパスワードを定期的に変えたいならSecrets Manager、設定値を安く管理したいならParameter Store。

Secrets Manager

シークレット管理 — パスワードの自動ローテーションが得意
  • 自動ローテーション（Lambda関数で定期変更）
  • RDS/Aurora/Redshift/DocumentDBとネイティブ統合
  • シークレットごとに$0.40/月
  • API呼び出し: $0.05/10,000回
  • クロスアカウント共有対応
  • CloudTrailでアクセス監査
  • 自動的に暗号化（KMS連携）

Systems Manager Parameter Store

パラメータ管理 — 設定値もシークレットも階層的に管理
  • 階層構造（/app/prod/db_url のようなパス）
  • String / StringList / SecureString（KMS暗号化）
  • Standard: 無料（10,000パラメータまで）
  • Advanced: 有料（100,000パラメータ、ポリシー対応）
  • 自動ローテーションは自前実装が必要
  • CloudFormation/Lambdaとの連携が容易
  • バージョン管理・変更通知対応
DBパスワード自動ローテーション → Secrets Manager  |  設定値/環境変数の管理 → Parameter Store  |  コスト最小で暗号化保存 → Parameter Store (SecureString)
「パスワードの定期的な自動ローテーション」が問題文にあればSecrets Manager一択。Parameter StoreのSecureStringでも暗号化はできるが、ローテーションの仕組みは自分で作る必要がある。コストだけならParameter Store。
VS Cognito User Pool vs Identity Pool Security
認証（あなたは誰？）と認可（何ができる？）は別物。User Poolで本人確認し、Identity Poolで「このユーザーはS3のこのバケットにアクセスできる」を実現する。2つの組み合わせパターンが超頻出。

User Pool

認証 (Authentication) — ユーザー登録・ログイン・トークン発行
  • ユーザーディレクトリ（登録/ログイン管理）
  • MFA対応（SMS/TOTP）
  • ソーシャルログイン（Google/Facebook/Apple）
  • SAML/OIDC連携（企業IdP）
  • JWT トークン（ID/Access/Refresh）発行
  • カスタムUIまたはHosted UI
  • Lambda トリガーでフローカスタマイズ

Identity Pool (Federated Identities)

認可 (Authorization) — 一時的なAWS認証情報を付与
  • 一時的AWS認証情報（STS）の発行
  • S3/DynamoDB等のAWSリソースへ直接アクセス
  • User Pool/Google/Facebook/SAML等からフェデレーション
  • 認証済み/未認証ユーザーに別のIAMロール
  • きめ細かいアクセス制御（ユーザーIDベース）
  • モバイル/SPAからAWSリソースを直接操作
典型パターン: User Poolでログイン → JWTトークン取得 → Identity Poolで一時AWS認証情報 → S3/DynamoDB直接アクセス
「ログイン機能が欲しい」→User Pool。「ログイン後にS3にファイルアップロードしたい」→User Pool＋Identity Pool。Identity Pool単体では「誰か」を管理できない。2つセットで使うパターンを覚える。
VS CloudFront vs Global Accelerator NW
どちらもAWSエッジロケーションを使って高速化するが、キャッシュするか（CloudFront）、最適経路で届けるか（GA）で役割が違う。プロトコル（HTTP？TCP/UDP？）と固定IPの要否がポイント。

CloudFront

CDN — エッジでコンテンツをキャッシュして高速配信
  • コンテンツキャッシュ（静的+動的）
  • HTTP/HTTPSプロトコル専用
  • オリジン: S3/ALB/EC2/カスタム
  • Lambda@Edge/CloudFront Functionsでエッジ処理
  • OAC（Origin Access Control）でS3を非公開に
  • 地理制限（Geo Restriction）対応
  • 署名付きURL/Cookieでコンテンツ保護

Global Accelerator

ネットワーク最適化 — AWSバックボーンで最寄りリージョンへ高速ルーティング
  • TCP/UDPをAWSグローバルネットワーク経由で最適ルーティング
  • 固定Anycast IP（2つ）を提供
  • キャッシュなし（毎回オリジンまで到達）
  • エンドポイント: ALB/NLB/EC2/Elastic IP
  • ヘルスチェック+自動フェイルオーバー
  • エンドポイント重み設定（Blue/Green デプロイ）
HTTP/コンテンツキャッシュ/S3配信 → CloudFront  |  非HTTP(TCP/UDP)/固定IP/ゲーム/IoT → Global Accelerator  |  IPアドレスのホワイトリスト要件 → GA（固定IP）
「固定IPでHTTPを配信したい」→CloudFrontは動的IPなのでNG。Global Accelerator（固定Anycast IP）を使う。ただし「S3静的サイトを高速配信」ならCloudFront一択（GAはS3をオリジンにできない）。
VS Transit Gateway vs VPCピアリング NW
VPC同士の接続方法の比較。2-3個ならピアリングで十分だが、数が増えるとフルメッシュが爆発する。「多数のVPCを一元管理」はTransit Gateway一択。

Transit Gateway (TGW)

ハブ&スポーク — 中央ハブで多数のVPC/オンプレを一元接続
  • ハブ&スポーク型ネットワーク
  • 数千のVPC+VPN+DXを1つのハブで接続
  • 推移的ルーティング対応（A→TGW→B→TGW→C）
  • ルートテーブルで通信の分離が可能
  • マルチキャスト対応
  • リージョン間ピアリング対応
  • RAM（Resource Access Manager）で他アカウントと共有

VPCピアリング

1対1接続 — 2つのVPCを直接プライベートにつなぐ
  • 1対1のVPC間プライベート接続
  • 推移的ルーティング不可（A↔B, B↔C でも A↔C は通らない）
  • クロスリージョン/クロスアカウント対応
  • 帯域制限なし（高パフォーマンス）
  • 低コスト（データ転送料金のみ）
  • CIDRが重複不可
2-3個のVPCを安く接続 → VPCピアリング  |  多数VPC+オンプレの一元管理 → Transit Gateway  |  推移的通信が必要 → Transit Gateway
「VPC AとB、BとCがピアリングしていればAからCに通信できる」→できない（推移的ルーティング不可）。3つ以上のVPCが相互通信するならTransit Gatewayが正解。ピアリングだとフルメッシュ接続が必要。
VS Kinesis Data Streams vs Amazon Data Firehose 統合
ストリーミングデータの処理方法。「リアルタイムにカスタム処理」か「とにかくS3/Redshiftに流し込む」かで決まる。管理の手間とリアルタイム性のトレードオフ。

Kinesis Data Streams

カスタムストリーム処理 — シャードを管理してリアルタイムに処理
  • リアルタイム（200ms以下のレイテンシー）
  • シャード単位でスループット管理（1MB/s入力）
  • データ保持1日〜365日
  • コンシューマー: Lambda/KCL/Flink等でカスタム処理
  • プロビジョンド or オンデマンド容量モード
  • 複数コンシューマーが同じデータを読める（ファンアウト）
  • Enhanced Fan-Out: コンシューマーごとに2MB/s

Amazon Data Firehose

マネージド配信パイプ — S3/Redshift/OpenSearchに自動で流し込む（旧 Kinesis Data Firehose）
  • ニアリアルタイム（最小60秒バッファ）
  • フルマネージド（シャード管理不要、自動スケール）
  • 配信先: S3/Redshift/OpenSearch/Splunk/HTTP
  • データ変換（Lambda連携で加工可能）
  • データ圧縮/フォーマット変換（Parquet/ORC）
  • データを保持しない（配信したら終わり）
  • 従量課金（処理データ量のみ）
カスタムリアルタイム処理/複数コンシューマー → Data Streams  |  S3/Redshiftへのデータ投入 → Firehose  |  管理の手間を最小に → Firehose
「リアルタイムダッシュボード」→Firehose（60秒遅延）ではなくData Streams。「ログをS3に保存」→Data Streams（シャード管理が面倒）ではなくFirehose。「リアルタイム」と「ニアリアルタイム」の違いを見逃さない。
VS SCP vs IAMポリシー Security
権限管理の2階層構造。SCPは「できることの上限」を組織レベルで設定し、IAMポリシーはその範囲内で「具体的にやれること」を個人/ロールに付与する。両方許可されて初めてアクセス可能。

SCP (Service Control Policy)

ガードレール — アカウント全体の権限の天井を決める
  • OrganizationsのOU/アカウントに適用
  • 権限を付与しない（上限を制限するだけ）
  • SCPで拒否 → IAMで許可しても絶対不可
  • 管理アカウントには適用されない
  • OU階層で継承（上位の制限が下位に波及）
  • 「この組織ではap-northeast-1以外使えない」等の大枠制御

IAMポリシー

個別権限 — ユーザー/ロールに具体的なアクセスを許可
  • ユーザー/グループ/ロールに直接アタッチ
  • 権限を付与する（Allow/Deny）
  • Identity-based / Resource-based の2種類
  • きめ細かいAction/Resource/Condition指定
  • ポリシーの評価ロジック: 明示的Deny > Allow > 暗黙的Deny
  • SCPの許可範囲内でのみ有効
SCP許可 + IAM許可 → アクセス可能  |  SCP拒否 → IAMで何を許可してもアクセス不可  |  組織全体のリージョン制限 → SCP
「SCPで全権限を許可すれば全操作できる」→嘘。SCPは上限を決めるだけで、IAMポリシーで実際に許可しなければ何もできない。また管理アカウント（root）にはSCPが効かない→管理アカウントでの操作制限は別の仕組みが必要。
VS CloudFormation vs Elastic Beanstalk Compute
インフラを自動構築する2つの方法。CloudFormationは「何でも定義できるIaC」、Beanstalkは「Webアプリを手軽にデプロイするPaaS」。問題文の「制御レベル」で判断。

CloudFormation

IaC — JSON/YAMLでAWSインフラを丸ごとコード化
  • Infrastructure as Code（全AWSリソース対応）
  • JSON/YAMLのテンプレートでスタック定義
  • ネストスタックで大規模構成を分割管理
  • ドリフト検出（手動変更の検知）
  • Change Sets: 変更内容のプレビュー
  • StackSets: マルチアカウント/リージョン展開
  • ロールバック自動（失敗時に元に戻す）

Elastic Beanstalk

PaaS — コードをアップロードするだけでWebアプリがデプロイされる
  • Webアプリ特化のPaaS（内部でCFnを使用）
  • 対応: Java/Python/Node/.NET/Go/Docker等
  • EC2/ALB/ASG/RDS等を自動プロビジョニング
  • デプロイ戦略: All at once/Rolling/Blue-Green等
  • 環境設定はカスタマイズ可能（.ebextensions）
  • 無料（作成されたリソース分のみ課金）
インフラ全体を細かく定義/再現 → CloudFormation  |  Webアプリを手軽にデプロイ → Elastic Beanstalk  |  マルチアカウント一斉展開 → CloudFormation StackSets
「Beanstalkはサーバーレス」→違う（内部でEC2が動いている）。サーバーレスのWebアプリならLambda + API Gateway。また「既存のVPC/サブネット構成を含めたインフラ全体をテンプレート化」はBeanstalkの範疇外→CloudFormation。
VS Lambda vs Fargate vs EC2 Compute
コンピュート選択の3段階。管理負担と自由度のトレードオフ: Lambda（関数だけ書く）→ Fargate（コンテナだけ定義）→ EC2（全部自分で管理）。問題文の「制限時間」と「制御要件」が鍵。

Lambda

関数実行 — イベントをトリガーにコードを走らせる
  • イベント駆動（S3/API GW/SQS等がトリガー）
  • 実行時間最大15分
  • メモリ: 128MB〜10GB
  • 同時実行: デフォルト1000（引き上げ可能）
  • コールドスタート（初回起動遅延）あり
  • サーバー管理完全不要
  • 実行時間×メモリ量の従量課金

Fargate

サーバーレスコンテナ — コンテナイメージを渡すだけで実行
  • ECS/EKSのサーバーレス起動タイプ
  • 実行時間制限なし
  • Dockerコンテナをそのまま実行
  • vCPU/メモリをタスク単位で指定
  • EC2インスタンスの管理不要
  • ECS Service+ALBで常時稼働も可能
  • EC2起動タイプより割高

EC2

仮想サーバー — OS含めて何でも自由にカスタマイズ
  • OS レベルの完全制御
  • GPU/カスタムドライバ/特殊ソフト対応
  • 実行時間制限なし
  • インスタンスタイプでハードウェア選択
  • Auto Scaling Group でスケール
  • パッチ適用/監視等の運用負荷あり
  • 購入オプション（RI/Spot等）でコスト最適化
短い処理/イベント駆動/15分以内 → Lambda  |  コンテナ+管理不要/長時間実行 → Fargate  |  OS制御/GPU/特殊要件 → EC2
「15分以上の処理」→Lambdaは不可。Fargate or EC2。「GPUが必要」→FargateはGPU非対応→EC2。「最小の運用負荷で」→LambdaかFargate（EC2はNG）。「Dockerイメージで実行」→Lambdaもコンテナイメージ対応しているが、15分制限は変わらない。
VS Athena vs Redshift vs EMR 分析
データ分析サービスの3択。頻度（たまに vs 常時）、規模（GBs vs PBs）、処理（SQL vs カスタム）で分岐する。「S3のログをSQLで分析したい」はほぼAthena。

Athena

サーバーレスSQL — S3のデータに直接クエリ実行
  • S3上のデータに直接SQLクエリ
  • サーバーレス（インフラ管理不要）
  • スキャン量課金（$5/TB）
  • Parquet/ORC形式でコスト削減（列圧縮）
  • Glueデータカタログと連携
  • アドホック分析/ログ調査に最適

Redshift

データウェアハウス — PB級データの定常分析
  • 列指向ストレージのDWH
  • 常時稼働クラスター（Serverlessもあり）
  • 大量データの複雑な集約/JOINが高速
  • Redshift Spectrum: S3データも直接クエリ
  • COPY/UNLOADでS3とデータ連携
  • BIツール（QuickSight等）連携に最適

EMR

ビッグデータ基盤 — Hadoop/Sparkで大規模分散処理
  • Hadoop/Spark/Hive/Presto等のOSSフレームワーク
  • PB級の分散ETL/データ変換
  • 機械学習/データサイエンス処理
  • EC2/EKS/Serverlessの起動モード
  • スポットインスタンスでコスト最適化
  • 高度にカスタマイズ可能な処理パイプライン
たまにS3をSQL分析/ログ調査 → Athena  |  常時BIダッシュボード/定常分析 → Redshift  |  大規模ETL/Spark/ML → EMR
「S3のアクセスログを月1回分析したい」→Redshift（常時稼働でコスト高）ではなくAthena。「毎日のBIレポート+大量JOIN」→Athena（スキャンコスト爆発）ではなくRedshift。分析頻度とデータ量がキーワード。
VS NAT Gateway vs NATインスタンス NW
プライベートサブネットからインターネットへ出る方法。試験ではほぼ100%「NAT Gateway」が正解。NATインスタンスは「既存環境の移行」文脈でのみ登場する旧式ソリューション。

NAT Gateway

マネージドNAT — AWSが管理する高可用なNATサービス
  • フルマネージド（パッチ/監視不要）
  • AZ内で高可用性（自動スケール、最大45Gbps）
  • Elastic IP1つを関連付け
  • SG不要（NACLのみで制御）
  • マルチAZ冗長化はAZごとに1つ配置
  • ポートフォワーディング不可
  • 時間課金 + データ処理料金

NATインスタンス

EC2ベースNAT — 自分でEC2を立ててNAT設定する旧式方式
  • EC2インスタンス上でNAT設定
  • 手動管理（パッチ/監視/スケール全部自分）
  • 送信元/宛先チェック無効化が必要
  • セキュリティグループで制御
  • ポートフォワーディング可能
  • 踏み台サーバー兼用可能
  • スポット/小型インスタンスで低コスト可能
試験の答え: ほぼ100% NAT Gateway。NATインスタンスは旧式 → 「NAT GWに移行」が正解パターン  |  ポートフォワーディング必要 → NATインスタンス（稀なケース）
「NATインスタンスで問題が起きている」→答えはNAT Gatewayに移行。「コスト削減のためNATインスタンスにする」は罠選択肢（管理コスト増大）。「NATインスタンスの送信元/宛先チェック」の知識は試験で問われることがある。
VS SSE-S3 vs SSE-KMS vs SSE-C Security
S3のサーバーサイド暗号化3方式。「誰がキーを管理するか」と「監査ログが必要か」で選ぶ。2023年からSSE-S3がデフォルト有効になった点も重要。

SSE-S3

S3管理キー — とりあえず暗号化したいならこれ
  • S3がキーを管理（完全自動）
  • AES-256暗号化
  • 2023年1月からデフォルトで有効
  • 追加コストなし
  • キーのローテーションはAWSが自動
  • 監査証跡なし（誰がキーを使ったか不明）

SSE-KMS

KMS管理キー — 監査+きめ細かいアクセス制御
  • AWS KMSがキーを管理
  • CloudTrailでキー使用の監査証跡
  • キーポリシーで誰が復号できるか制御
  • カスタマーマネージドキー or AWSマネージドキー
  • 自動ローテーション（1年ごと）
  • API制限あり（リクエストクォータに注意）

SSE-C

顧客提供キー — 自社でキーを完全管理したい場合
  • 顧客がキーを提供（毎回リクエストに含める）
  • AWSはキーを保持しない
  • HTTPS必須（HTTPは使用不可）
  • キー管理の全責任が顧客側
  • キーを紛失→データ復元不可能
  • S3コンソールからは操作不可（API/CLI必須）
とりあえず暗号化（デフォルト） → SSE-S3  |  監査証跡/アクセス制御/ローテーション → SSE-KMS  |  自社キー完全管理（規制要件） → SSE-C
「暗号化キーの使用ログを監査したい」→SSE-S3では監査不可→SSE-KMS。「大量のS3 GETリクエスト+SSE-KMS」→KMSのリクエストクォータ制限でスロットリングされる→S3バケットキーの有効化で解決。
比較 EC2購入オプション Cost
EC2のコスト最適化の要。ワークロードの特性（安定/変動/中断OK）でオプションを使い分ける。複数オプションの組み合わせも頻出パターン。
オプション 割引率 コミット ユースケース
オンデマンドなしなし短期/テスト/予測不能
リザーブド (RI)最大72%1年 or 3年24/365安定稼働（DB等）
Savings Plans最大72%1年 or 3年（$/時間）EC2/Fargate/Lambdaの柔軟割引
スポット最大90%なし（2分前通知で中断）バッチ/CI/CD/耐障害処理
Dedicated HostRI適用可オンデマンド or RIライセンス要件（BYOL）
Dedicated Instance割増なし物理分離要件（コンプライアンス）
24/365安定稼働 → RI / Savings Plans  |  中断OK（バッチ/分散処理） → スポット  |  ライセンスBYOL → Dedicated Host  |  柔軟にサービスまたぎ割引 → Compute Savings Plans
「スポットインスタンスでデータベースを動かす」→中断されるのでNG。DBは安定稼働が必要→RI。「Dedicated HostとDedicated Instanceの違い」→Hostは物理サーバー丸ごと専有（ソケット/コア単位のライセンス対応）、Instanceは同じ物理HWに他テナントが来ないだけ。
比較 Storage Gateway の種類 Storage
オンプレミスとAWSストレージのハイブリッド接続を実現する3タイプ。問題文の「オンプレからどのプロトコルでアクセスするか」（NFS/iSCSI/テープ）で決まる。

S3 File Gateway

ファイル → S3 — NFS/SMBでS3を透過的にアクセス
  • NFS/SMBプロトコルでアクセス
  • ファイルとして操作→S3オブジェクトとして保存
  • ローカルキャッシュで頻繁アクセスを高速化
  • Active Directory統合（SMB）
  • S3ライフサイクルポリシー適用可能
  • オンプレのファイルサーバー拡張に最適

Volume Gateway

ブロック → EBS — iSCSIでオンプレにボリュームを提供
  • iSCSIプロトコルでブロックアクセス
  • Cached: プライマリデータはS3、キャッシュはローカル
  • Stored: プライマリデータはローカル、S3にバックアップ
  • EBSスナップショットとしてバックアップ
  • スナップショットからEC2にボリュームを復元可能

Tape Gateway

仮想テープ → Glacier — テープバックアップをクラウドに移行
  • 仮想テープライブラリ（VTL）を提供
  • 既存のバックアップソフトと互換性あり
  • テープはS3/Glacier/Deep Archiveに保存
  • 物理テープの購入/管理/保管コスト削減
  • レガシーバックアップシステムのクラウド移行
ファイル共有(NFS/SMB)→S3 → S3 File GW  |  ブロックストレージ(iSCSI) → Volume GW  |  テープバックアップのクラウド移行 → Tape GW
「オンプレのバックアップをGlacierに保存したい」+「テープ」→Tape Gateway。「テープ」がなければFile GWかも。Volume GWの「Cached vs Stored」は頻出: データをローカルに置きたい→Stored、S3に置いてコスト削減→Cached。
比較 Route 53 ルーティングポリシー NW
DNSレベルでトラフィックをどこに向けるか。「DR（フェイルオーバー）」「レイテンシー最適化」「カナリアリリース（加重）」のどれが問われているかを問題文から読み取る。
ポリシー 用途 ヘルスチェック
シンプル1レコード（デフォルト）。複数値を返す場合はクライアントがランダム選択不可
加重 (Weighted)トラフィック比率分散。カナリアリリース（90%旧/10%新）対応
レイテンシー最も低レイテンシーのリージョンへルーティング対応
フェイルオーバープライマリ障害時にセカンダリへ自動切替（Active-Passive DR）必須
地理的位置ユーザーの地域/国に基づくルーティング（コンテンツローカライズ/規制対応）対応
地理的近接性リソースまでの距離+バイアス値でルーティング（Traffic Flow必要）対応
マルチバリュー最大8つの健全なリソースIPをランダム返却（簡易LB）対応
DR構成/Active-Passive → フェイルオーバー  |  カナリアリリース（10%だけ新バージョン） → 加重  |  最速リージョンへ → レイテンシー  |  国ごとに異なるコンテンツ → 地理的位置
「レイテンシーベース」と「地理的位置ベース」を混同しない。レイテンシーは実測の応答速度で判断、地理的位置はユーザーの所在国/地域で判断（コンプライアンス要件向き）。フェイルオーバーにはヘルスチェックが必須。
AWS SAA-C03 比較チートシート | 25パターン | 2026年3月作成
免責事項　本サイトは AWS 認定試験の学習用に個人が作成した非公式の教材です。Amazon Web Services（AWS）とは一切関係がなく、AWS が提供・承認・推奨するものではありません。「AWS」および関連する名称・ロゴは Amazon.com, Inc. またはその関連会社の商標です。掲載の問題・解説はすべて独自に作成したオリジナルであり、AWS 公式の試験問題や特定の書籍・問題集からの転載ではありません。内容の正確性は保証されません。