【SAA-C03】直前チートシート (3/6) データベース・ネットワーキング

この記事の位置づけ

SAA-C03 直前チートシート全 6 回の第 3 回（データベース・ネットワーキング）です。当日戦略・早見表 200 行・シリーズ目次は 第 1 回 にあります。各トピックは「要点 → 比較表 → 引っかけ」の順で、優先度 A（毎回級）→ B（頻出）→ C（たまに）の順に読んでください。数値・仕様は改定されることがあるので、受験前に公式の試験ガイドで最終確認を。

データベース

DBは「可用性＝Multi-AZ／読み取り＝リードレプリカ・キャッシュ／リージョンDR＝Aurora Global・Global Tables」の3軸で判定。A（RDS・Aurora・DynamoDB・ElastiCache・DB選定）を先に読み、B以降は設問キーワード→サービスの対応だけ確認。

RDS Multi-AZ vs リードレプリカ vs Multi-AZ DBクラスター　A: 毎回級

可用性はMulti-AZ、読み取りスケールはリードレプリカ。混同がSAA最頻出の引っかけ

• Multi-AZ（インスタンス）→別AZに同期スタンバイ、障害時はDNS（CNAME）自動切替で通常60〜120秒、スタンバイは読み取り不可、同一リージョン内のHA
• フェイルオーバー発火→AZ/インスタンス障害・ストレージ障害・ネットワーク断・インスタンスクラス変更・OSパッチ・手動（reboot with failover）。クエリ遅延など性能低下では発火しない
• バックアップ・パッチはスタンバイ側で実行→本番I/Oへの影響なし。既存DBを後からMulti-AZ化可（Modify）
• Multi-AZ DBクラスター→3AZに「読み取り可能な」スタンバイ2台（MySQL/PostgreSQL）、半同期、フェイルオーバー通常35秒未満、ライター/リーダーエンドポイント
• リードレプリカ→非同期、MySQL/MariaDB/PostgreSQL/SQL Serverは最大15台、Oracleは5台、同一AZ/別AZ/別リージョン可、レプリカごとに別エンドポイント（アプリ側で振り分け）
• リードレプリカは昇格して独立DBに（DR代替）、レプリカ自体のMulti-AZ化も可、自動バックアップ有効が前提
• Multi-AZとリードレプリカは併用可能。「レポート/分析クエリで本番が遅い」→レプリカに分離が定石

RDSの3方式の比較

項目	Multi-AZ（インスタンス）	Multi-AZ DBクラスター	リードレプリカ
目的	可用性（HA）	HA＋読み取り分散	読み取りスケール／DR
レプリケーション	同期	半同期（2台中1台のACK）	非同期
スタンバイ/レプリカの読取	不可	可（リーダーEP）	可
台数	1	2	最大15（Oracleは5）
配置	別AZ・同一リージョン	3AZ・同一リージョン	同一/別AZ/別リージョン
切替	自動・通常60〜120秒	自動・通常35秒未満	手動で昇格
エンドポイント	同じ（DNS切替）	ライター/リーダー	レプリカごとに別

引っかけ

• 「読み取り負荷を分散したい」→リードレプリカ（Multi-AZのスタンバイは読めない。ただしMulti-AZ DBクラスターのスタンバイは読める）
• 「別リージョンにDR」→クロスリージョンリードレプリカ or Aurora Global（Multi-AZは同一リージョンのAZ障害対策）
• 「アプリを変えずに自動フェイルオーバー」→Multi-AZ（エンドポイント名が変わらない）。レプリカ昇格はアプリの接続先変更が必要
• 公式サンプル問題10：Aurora Multi-AZで「スタンバイから読む」は不正解（RDSのスタンバイは読み取り不可）

RDS バックアップ・スナップショット・暗号化　A: 毎回級

自動バックアップは35日まで、暗号化は作成時のみ。既存DBの暗号化は「スナップショット→暗号化コピー→復元」

• 自動バックアップ→保持0〜35日（コンソール既定7日、0で無効）、日次スナップショット＋5分ごとのトランザクションログ→PITR（最新復元可能時点は通常5分以内）
• 自動バックアップはDB削除で消えるのが既定（保持設定も可）→長期保管は手動スナップショット or AWS Backup（35日超の要件）
• 手動スナップショット→削除するまで永続（リージョンあたり100個まで）、PITR不可、別リージョンコピー・他アカウント共有可
• 復元は常に「新しいDBインスタンス」として作成→既存を上書きしない。エンドポイント名の切替が必要
• 暗号化（KMS）は作成時のみ指定。暗号化DBのスナップショット・レプリカは暗号化、非暗号化には戻せない。暗号化スナップショットの別リージョンコピー→コピー先リージョンのKMSキーを指定
• 転送時→SSL/TLS（rds.force_ssl等）。Oracle/SQL ServerはTDEも可
• ストレージ自動スケーリング→閾値超過で自動拡張、最大64TiB（SQL Serverは16TiB）が目安、縮小は不可（自動でも手動でも減らせない）
• Provisioned IOPS（io1/io2）で一貫した高I/O、gp3で汎用。EC2自前DBは「運用負荷」でRDSに負ける

引っかけ

• 「既存RDSを暗号化」で設定変更（Modify）を選ぶ→不可。スナップショット→暗号化コピー→復元
• 「特定の秒に戻す」→PITR（自動バックアップが必要）。手動スナップショットは取得時点のみ
• AWSマネージドキー（aws/rds）で暗号化したスナップショットは他アカウントに共有不可→カスタマーマネージドキーで暗号化
• 「複数サービスのバックアップを一元管理・35日超」→AWS Backup（RDS単体の自動バックアップは35日が上限）

RDS Proxy・IAM DB認証・RDS Custom・監視　A: 毎回級

Lambdaからの接続枯渇→RDS Proxy。OSを触りたい→RDS Custom。遅いSQL→Performance Insights

• RDS Proxy→接続プーリング・多重化。Lambda等の大量短命接続による「too many connections」を防ぐ、フェイルオーバー時間を最大66%短縮（DNSキャッシュをバイパス）、アプリ改修はエンドポイント差替えのみ
• RDS Proxy→IAM認証の強制・Secrets Managerで認証情報管理。対応：MySQL/PostgreSQL/MariaDB/SQL Server/Aurora
• IAM DB認証→パスワード不要、15分有効の認証トークン（MySQL/MariaDB/PostgreSQL）、SSL/TLSで暗号化。パスワードの自動ローテーション→Secrets Manager
• RDS Custom→Oracle/SQL ServerでOS・DBへの管理者アクセス（独自パッチ・サードパーティエージェント）が必要なとき
• 拡張モニタリング→OSレベル（プロセス/スレッド別CPU・メモリ）を最短1秒粒度でCloudWatch Logsへ。CloudWatch標準メトリクスはハイパーバイザー視点
• Performance Insights（CloudWatch Database Insightsに統合）→DB負荷・待機イベント・上位SQLを可視化
• ブルー/グリーンデプロイ→本番と同期したステージング環境を作り1分程度で切替（メジャーバージョンアップ・スキーマ変更をほぼ無停止で）
• インスタンスクラス変更はダウンタイムあり（Multi-AZならフェイルオーバーで短縮）。RDSはプライベートサブネット＋SGでアプリ層SGからのみ許可

引っかけ

• 「Lambdaからの接続でDB接続数超過」→RDS Proxy（インスタンスサイズ拡大ではない）
• 「OSにログインしてパッチ/エージェント導入」→RDS Custom or EC2（通常RDSはOSアクセス不可）
• 「どのSQLが負荷の原因か」→Performance Insights、「OSのプロセス単位のメモリ」→拡張モニタリング
• 「DBパスワードを定期ローテーション」→Secrets Manager（Parameter Storeにローテーション機能はない）

Aurora 基本（ストレージ・レプリカ・エンドポイント）　A: 毎回級

6コピー共有ストレージ＋最大15レプリカ。レプリカが読み取りスケールとフェイルオーバー先を兼ねる

• MySQL/PostgreSQL互換、MySQLの最大5倍・PostgreSQLの最大3倍のスループット。RDS MySQLより約20%高い（目安）
• ストレージ→3AZ×2＝6コピー、10GB単位で最大128TiB（最新バージョンは256TiB）に自動拡張、使った分だけ課金。2コピー喪失でも書込可・3コピー喪失でも読取可、自己修復
• Auroraレプリカ→最大15台、共有ストレージのため遅延は通常100ミリ秒未満、自動フェイルオーバーの昇格先（通常30秒以内・60秒未満）、優先度Tier 0〜15で昇格順を制御
• エンドポイント→クラスター（ライター）／リーダー（レプリカに負荷分散）／カスタム（分析用の大型レプリカ群など）／インスタンス
• レプリカのAuto Scaling→CPU使用率や接続数でレプリカ台数を自動増減
• バックアップ→継続的・PITR、保持1〜35日、性能影響なし。クローン→コピーオンライトで高速・低コストに検証環境（クロスアカウントはRAM共有）
• Multi-AZ→レプリカを別AZに置くだけで実現（RDSのような専用スタンバイ機は不要）。レプリカ無しの障害時は同一AZで再作成（10分程度）
• RDS→Aurora移行→スナップショット復元 or Auroraリードレプリカ作成→昇格。IAM認証・RDS Proxy対応

引っかけ

• 公式サンプル問題10：「読み取りI/Oが書き込みを遅くする」→Auroraレプリカを追加しアプリをリーダーエンドポイントへ
• 「別のAuroraクラスターを作ってレプリカとしてリンク」は不正解→同一クラスターにレプリカを追加
• 「本番データで手早く検証したい」→クローン（スナップショット復元より速く安い）
• 「レプリカ15台・自動フェイルオーバー先・128TiB以上の自動拡張」はAurora。RDS MySQLは15台でも共有ストレージではなく非同期

Aurora Global Database / Serverless v2 / バックトラック　A: 毎回級

リージョンDR（RPO約1秒・RTO1分未満）はGlobal Database、断続的負荷はServerless v2、誤操作の巻き戻しはバックトラック

• Global Database→1プライマリ＋最大10セカンダリリージョン（旧上限5）、ストレージレベル物理レプリケーション、遅延通常1秒未満、RPO約1秒・RTO1分未満（目安）
• セカンダリは読み取り専用（各最大16レプリカ）、Write Forwardingでセカンダリが受けた書込をプライマリへ転送。計画切替はマネージドフェイルオーバー（スイッチオーバー）、災害時は切り離し＆昇格
• Serverless v2→ACU（0.5刻み、最大256）で秒単位に自動スケール、アイドル時は0 ACUへ自動停止可（2024〜、対応バージョンのみ）、Multi-AZ・Global・プロビジョンド混在対応。断続的・予測不能・開発/テスト向け
• Data API→HTTPSでSQL実行、VPC設定や接続管理なしでLambdaから利用
• バックトラック（Aurora MySQLのみ）→最大72時間、リストア不要でクラスターをインプレースで過去時点に巻き戻し（分単位）。PITRは新クラスター作成
• Babelfish for Aurora PostgreSQL→SQL Serverアプリ（T-SQL/TDS）をほぼ改修なしで移行
• 「RPO 1秒未満・RTO 1分未満のクロスリージョンDB」「グローバルユーザーへの低遅延読み取り」→Global Database が定番解

引っかけ

• 「RPO 1秒未満のマルチリージョンRDB」→Aurora Global（RDSクロスリージョンリードレプリカは遅延が大きい。NoSQLならDynamoDB Global Tables）
• 「誤ったDELETEを最速で取り消す」→バックトラック（Aurora MySQL）。PITRは別クラスター復元で時間がかかる
• 「常時高負荷で安定」にServerlessは割高→プロビジョンド＋リザーブド
• 「Global Databaseのセカンダリに直接書き込む」→セカンダリは読み取り専用。Write Forwardingか昇格

DynamoDB 基礎（キャパシティモード・RCU/WCU・整合性）　A: 毎回級

予測不能→オンデマンド、安定→プロビジョンド＋Auto Scaling。強い整合性はRCU2倍でGSI不可

• フルマネージドNoSQL（キー・バリュー/ドキュメント）、3AZに自動レプリケーション、どんな規模でも1桁ミリ秒、項目最大400KB、スキーマレス、サーバーレス
• キー→パーティションキー（必須）＋ソートキー（任意）。高カーディナリティのキーでホットパーティション回避
• RCU→4KB以下の強い整合性読取1回/秒（結果整合性なら2回、トランザクションは2RCU）。WCU→1KB以下の書込1回/秒（トランザクションは2WCU）
• 例：8KBを強い整合性で毎秒10回→2RCU×10＝20RCU、結果整合性なら10RCU
• オンデマンド→リクエスト課金、予測不能・スパイク・新規ワークロード。プロビジョンド→RCU/WCU指定＋Auto Scaling、安定負荷で安い、超過→ProvisionedThroughputExceededException
• 整合性→既定は結果整合性、強い整合性は読み取りAPIのパラメータで指定、GSIは結果整合性のみ
• モード切替は24時間に1回。プロビジョンドは予約キャパシティで割引
• 「セッション・カート・リーダーボード・IoTメタデータ・毎秒数十万リクエスト」→DynamoDB。「複雑なJOIN・集計」→RDS/Aurora

キャパシティモードの比較

項目	オンデマンド	プロビジョンド
課金	リクエスト数	RCU/WCU×時間
向く負荷	予測不能・スパイク・新規	安定・予測可能
スロットリング	ほぼなし	超過時に発生（Auto Scalingで緩和）
コスト	単価は高い	安い（予約キャパシティでさらに割引）

引っかけ

• 「トラフィックが予測不能・急増」→オンデマンド、「安定負荷でコスト最適化」→プロビジョンド＋Auto Scaling（逆を選ばない）
• 「常に最新を読む」→強い整合性（RCU2倍、GSIでは不可）
• 「400KB超のデータ」→本体はS3、DynamoDBにはキーとS3のパスだけ
• 「複雑な結合が必要なリレーショナルデータ」にDynamoDBは不向き→RDS/Aurora

DynamoDB GSI vs LSI　A: 毎回級

後から追加できるのはGSIだけ。強い整合性が使えるのはLSIだけ

• 「既存テーブルに別の検索パターン（別のパーティションキー）を追加」→GSI
• 「同じパーティションキーで別のソート順・強い整合性が必要」→LSI（テーブル作成時に設計）
• GSIは独自のRCU/WCU→GSIのWCU不足はベーステーブルの書き込みもスロットルする
• 射影（KEYS_ONLY / INCLUDE / ALL）でインデックスに含める属性を絞りRCUとストレージを節約
• Query（キー指定・効率的）を使いScan（全件読み・高コスト）は避ける。フィルタ式は読み取り後に適用されRCUは減らない

GSIとLSIの比較

項目	GSI	LSI
パーティションキー	別のキーを指定可	テーブルと同じ
ソートキー	任意	別のソートキー
作成タイミング	いつでも追加/削除	テーブル作成時のみ
整合性	結果整合性のみ	強い整合性も可
キャパシティ	独自のRCU/WCU	テーブルと共有
上限	20/テーブル（既定・引上げ可）	5/テーブル（固定）
サイズ制限	なし	パーティションキーあたり10GB

引っかけ

• 「テーブル作成後にインデックスを追加したい」→GSIのみ（LSIは後から追加不可）
• 「GSIで強い整合性の読み取り」は不可（結果整合性のみ）
• 「Scanが遅い・高い」→GSI＋Query化 or 並列Scan（RCUを上げるだけは不正解になりやすい）

DynamoDB 拡張機能（DAX・TTL・Global Tables・PITR・テーブルクラス・トランザクション）　A: 毎回級

マイクロ秒→DAX、自動削除→TTL、マルチリージョン→Global Tables、35日復元→PITR

• DAX→DynamoDB専用インメモリキャッシュ、読み取りをミリ秒→マイクロ秒、API互換でDAXクライアントに差替えるだけ、ライトスルー、読み取り集中・ホットキー対策。VPC内クラスター（Multi-AZ推奨）
• TTL→属性のUNIX時刻（秒・Number型）で期限切れ項目を自動削除、無料・WCU消費なし、削除は期限から通常数日以内（即時ではない。旧記載は48時間以内）、削除もStreamsに流れる（サービス削除として）
• Global Tables→マルチリージョン・マルチアクティブ（全リージョンで読み書き）、Streams必須、既定は結果整合（MREC）で競合はLast Writer Wins。2025年6月からマルチリージョン強整合性（MRSC）モードも選択可（同一アカウントのみ）。リージョンDR＋グローバル低レイテンシ
• PITR→直近35日の任意の秒に「新テーブルとして」復元。オンデマンドバックアップは無期限保持。AWS Backupでクロスリージョン/クロスアカウントコピー
• テーブルクラス Standard-IA→ストレージ単価が安く読み書き単価が高い→低頻度アクセスの大容量テーブル（ログ・履歴）
• トランザクション→TransactWriteItems/TransactGetItems、複数テーブル・複数項目のACID、キャパシティ消費2倍
• S3エクスポート（PITR必須、RCU消費なし）→Athena分析。VPCゲートウェイエンドポイント（無料）でプライベート接続。暗号化は常時（KMSキー選択可）
• Contributor Insightsでホットキー検出。DynamoDB Streams→次トピック

引っかけ

• 「マイクロ秒の読み取り・アプリ変更最小」→DAX（ElastiCacheは汎用でコード変更が必要）。DAXは書き込み性能を上げない
• 「TTLで即座に消える」は誤り→数日程度の遅延があり得る。クエリ側でフィルタして期限切れを除外
• 「Global Tablesで強い整合性」→試験の想定は結果整合・LWW（不可）。現行はMRSCモードで可能だが設問に明記がなければ結果整合で判断
• 「復元で既存テーブルを上書き」は不可→新テーブルに復元しアプリの参照先を切替

ElastiCache Redis vs Memcached　A: 毎回級

永続化・レプリケーション・フェイルオーバー・複雑なデータ構造が要る→Redis。単純キャッシュでマルチスレッド→Memcached

• 「リーダーボード/ランキング」→Redisソート済みセット、「複数EC2でセッション共有＋耐障害性」→Redis（またはDynamoDB）
• Redisクラスターモード有効→シャーディングで書き込みもスケール。Multi-AZ自動フェイルオーバー、AUTH/RBAC・IAM認証、保存時/転送時暗号化、HIPAA/PCI対応
• Global Datastore for Redis/Valkey→クロスリージョンレプリケーション（読み取り・DR、通常1秒未満）
• ElastiCache Serverless→容量計画不要、Redis/Valkey/Memcached対応。Valkey→Redis OSS互換フォーク、試験では「Redis」として出る
• ElastiCacheはRDS/Aurora等の読み取り負荷軽減・レイテンシ短縮。書き込み集中には効かない
• DAX→DynamoDB専用、ElastiCache→汎用。MemoryDB→Redis互換の永続プライマリDB（キャッシュではない）
• ELBのスティッキーセッションよりセッションをElastiCache/DynamoDBに外出し→ステートレス化してASGで自由にスケール

Redis（Valkey互換含む）とMemcachedの比較

項目	Redis	Memcached
データ構造	文字列・リスト・ハッシュ・ソート済みセット・地理空間	文字列（単純KV）
永続化	スナップショット/AOF あり	なし
レプリケーション/Multi-AZ	あり（自動フェイルオーバー）	なし
スレッド	シングル（クラスターモードでシャーディング）	マルチスレッド
Pub/Sub・トランザクション・Lua	あり	なし
暗号化・認証	保存時/転送時・AUTH/RBAC	限定的
バックアップ/復元	あり	なし
向く用途	セッション・ランキング・Pub/Sub・HAが要るキャッシュ	大規模で単純なオブジェクトキャッシュ

引っかけ

• 「フェイルオーバー/永続化/Pub/Sub/ランキング」→Redis（Memcachedは不可）
• 「最もシンプル・マルチスレッドで水平スケール・失われてもよい」→Memcached
• 公式サンプル問題7：「書き込みが追いつかない」にElastiCacheは不正解→SQSでバッファしワーカーが書き込む
• 「DynamoDBの読み取りをキャッシュ」→DAX優先（ElastiCacheはコード変更が必要）

DB選定マッピング（要件→サービス）　A: 毎回級

データの形と要件で1対1に決まる。「〇〇互換」「グラフ」「時系列」「台帳」は即答問題

• Neptune→グラフDB（プロパティグラフ/RDF）、Gremlin・openCypher・SPARQL、Multi-AZ・最大15レプリカ。SNSの友達関係・レコメンド・不正検知・ナレッジグラフ
• DocumentDB→MongoDB互換API、Aurora類似の6コピーストレージ・最大15レプリカ。既存MongoDBアプリの移行
• Keyspaces→Apache Cassandra互換（CQL）、サーバーレス、オンデマンド/プロビジョンド、PITR
• Timestream→時系列DB、メモリストア→磁気ストアに自動階層化、時系列関数。IoTセンサー・メトリクス（LiveAnalytics版は2025年6月20日から新規顧客の受付停止、既存顧客は継続利用可。InfluxDB版が推奨・継続）
• QLDB→中央集権型の改ざん不可台帳、ジャーナルのハッシュチェーンで検証可能。分散台帳（複数組織）はManaged Blockchain。QLDBは2025年7月31日にサポート終了（完全シャットダウン）
• MemoryDB→Redis/Valkey互換の耐久性のあるプライマリDB（マルチAZトランザクションログ）、マイクロ秒読取・1桁ミリ秒書込
• Aurora vs RDS→Auroraは高性能・高可用性・自動拡張だが約20%高い（目安）。小規模・低負荷ならRDS。運用負荷最小ならAurora Serverless v2
• Aurora vs DynamoDB→JOIN・トランザクション・既存SQLアプリ→Aurora、キー・バリュー・超スケール・スキーマ変動→DynamoDB

キーワード→DBサービス

問題文のキーワード	サービス	一言
リレーショナル・JOIN・ACID・既存SQLアプリ	RDS / Aurora	OLTP。運用負荷最小・高性能ならAurora
キー・バリュー・1桁ms・無制限スケール・サーバーレス	DynamoDB	セッション/カート/IoTメタデータ
インメモリ・マイクロ秒・キャッシュ	ElastiCache / DAX	DAXはDynamoDB専用
Redis互換で耐久性のあるプライマリDB	MemoryDB	キャッシュではなくDB
列指向・DWH・OLAP・ペタバイト	Redshift	S3直接クエリはSpectrum
グラフ・関係性・レコメンド・不正検知	Neptune	Gremlin/openCypher/SPARQL
MongoDB互換・JSONドキュメント	DocumentDB	既存MongoDBアプリ
Cassandra互換・CQL・ワイドカラム	Keyspaces	サーバーレス
時系列・IoTセンサー・メトリクス	Timestream	自動階層化（新規はInfluxDB版）
改ざん不可・検証可能な台帳（中央集権）	QLDB（2025年7月終了）	分散台帳はManaged Blockchain
SQL Serverアプリを改修なしでAuroraへ	Babelfish for Aurora PostgreSQL	T-SQL/TDS互換

引っかけ

• 「MongoDBをそのまま移行」→DocumentDB（DynamoDBではない）、「Cassandra」→Keyspaces、「SQL Serverアプリを改修なしで」→Babelfish for Aurora PostgreSQL
• 「友達の友達」「関係性の探索」→Neptune（RDSの再帰JOINではない）
• 「Redshiftで数万TPSのOLTP」「DynamoDBで複雑JOIN」「RDS LIKE検索で全文検索」は不正解
• QLDB/Timestream（LiveAnalytics）は廃止・縮小済みだが問題文には残る→「改ざん不可の台帳」「時系列」のキーワード判定だけでよい

DynamoDB Streams　B: 頻出

テーブル変更を24時間記録しLambdaをトリガー。長期保持・多数コンシューマーはKinesis Data Streams for DynamoDB

• 項目の追加/更新/削除を時系列に記録、保持24時間、各レコードはストリームに1回だけ出現（Lambda側の再試行で重複処理はあり得る→処理は冪等に）
• 同一項目（同一プライマリキー）内は変更順序を保証（パーティション全体・テーブル全体では保証なし）
• Lambdaのイベントソースマッピング（ポーリング）でトリガー。バッチサイズ・失敗時のDLQ/送信先を設定可
• Global Tablesの内部実装、TTLによる削除もストリームに流れる→監査ログ・アーカイブに使える
• Kinesis Data Streams for DynamoDB→保持最大365日、複数コンシューマー・拡張ファンアウト、Firehose経由でS3/OpenSearchへ
• 用途→変更をトリガーに在庫更新・通知・集計、別データストアへのレプリケーション、OpenSearchへの検索インデックス同期

ストリームのビュータイプ

ビュータイプ	含まれる内容
KEYS_ONLY	キー属性のみ
NEW_IMAGE	変更後の項目全体
OLD_IMAGE	変更前の項目全体
NEW_AND_OLD_IMAGES	変更前後の両方（最多）

引っかけ

• 「変更前後の差分を比較する処理」→NEW_AND_OLD_IMAGES（それ以外では変更前が取れない）
• 「24時間超の保持」「多数のコンシューマーで並行読み取り」→Kinesis Data Streams for DynamoDB（Streams単体は24時間・Lambda直結が主用途）
• 「Streams→SNSへ直接配信」は不可→Lambda経由
• 「Streamsに長期保存」は誤り→Lambda等でS3へ転送

DMS / SCT / CDC　B: 頻出

異種移行はSCT＋DMS、同種はDMSのみ。最小ダウンタイムは「フルロード＋CDC」

• DMS→レプリケーションインスタンス（Multi-AZ可）＋ソース/ターゲットエンドポイント＋タスク。ソースDBは稼働したまま移行。DMS Serverlessもあり
• 同種（MySQL→RDS MySQL）も異種（Oracle→Aurora PostgreSQL）も可。ターゲットはRDS/Aurora/DynamoDB/S3/Redshift/Kinesis/OpenSearch/DocumentDB等
• SCT→異種移行でスキーマ・ストアドプロシージャ・関数を変換するツール。同種なら不要。DWH（Teradata/Oracle→Redshift）も対象
• 大容量＋帯域不足→SCT＋Snowball Edgeで初期ロード、DMS CDCで差分同期
• MySQL→Aurora MySQLはDMSなしでも可（スナップショット復元／Auroraリードレプリカ昇格／S3上のバックアップから復元）
• DMSのデータ検証機能で移行後の行数・内容を比較。DMS Fleet Advisorでオンプレ・自前DBの棚卸し

DMSの移行タイプ

項目	フルロード	CDC	フルロード＋CDC
内容	既存データを一括コピー	変更差分のみ継続反映	一括コピー後に差分を継続
用途	一回限りの移行（停止可）	別手段で移行済みの差分同期・並行稼働	最小ダウンタイム移行の定番
ソース停止	移行中は書込停止が安全	不要	カットオーバー時のみ

引っかけ

• 「Oracle→Aurora PostgreSQL」→SCT＋DMS、「MySQL→Aurora MySQL」→DMSのみ（SCT不要）
• 「ダウンタイムをほぼゼロで移行」→フルロード＋CDC（ダンプ＆リストアではない）
• 「新旧DBを並行稼働し差分を反映」→CDCのみ
• 「DMSがストアドプロシージャも変換する」は誤り→SCT

Redshift　B: 頻出

列指向・MPPのDWH（OLAP）。S3を直接クエリならSpectrum、同時実行急増ならConcurrency Scaling

• 列指向＋MPP、ペタバイト級DWH、分析・集計（OLAP）向け。リーダーノード（クエリ計画・無料）＋コンピュートノード
• RA3→コンピュートとストレージを分離（マネージドストレージ＝S3ベース）、必要な分だけ独立にスケール。DC2はローカルSSDの旧世代
• Redshift Spectrum→S3上のデータをロードせず外部テーブル（Glue Data Catalog）としてクエリ、Redshift内テーブルとJOIN可
• Concurrency Scaling→同時クエリ急増時に一時クラスターを自動追加（24時間ごとに1時間分の無料クレジット、最大30時間まで蓄積）
• Redshift Serverless→クラスター管理不要、RPU課金、断続的・予測不能な分析。一時停止（Pause）でコスト削減
• 設計→分散スタイル（KEY/EVEN/ALL/AUTO）とソートキーでJOIN・フィルタ高速化。COPYでS3から並列ロード（INSERTより速い）
• Multi-AZ対応（RA3）。マルチリージョンは不可→自動スナップショットのクロスリージョンコピーでDR。拡張VPCルーティングでS3通信をVPC内に閉じる
• WLM（ワークロード管理）でキュー/優先度、Federated QueryでRDS/Auroraを直接クエリ、データ共有でクラスター間共有

引っかけ

• 「S3のログをたまにSQLで分析・サーバー管理なし」→Athena（Redshiftへのロードは過剰）
• 「OLTP・頻繁な小さな更新」→RDS/Aurora（Redshiftは分析特化）
• 「クエリの同時実行数が急増」→Concurrency Scaling（ノード追加/サイズ変更ではない）
• 「S3のデータとRedshiftのデータを結合」→Spectrum。「JOINが遅い」→分散キー見直し（ノード追加より先）

キャッシュ戦略・DAX vs ElastiCache・MemoryDB　B: 頻出

常に最新→ライトスルー、容量節約→遅延読み込み。読み取り集中はキャッシュ、書き込み集中はキューやシャーディング

• 遅延読み込み（Lazy Loading）→キャッシュミス時にDBから取得してキャッシュへ。必要な分だけ保持、初回は遅い・古いデータの可能性
• ライトスルー→DB書込時にキャッシュも更新。常に最新、書込遅延と読まれないデータの無駄。TTL併用が定石
• セッション管理→Redis/DynamoDBに外出し→Webサーバーをステートレス化→ASGで増減自由（スティッキーセッションは次善）
• DAX→DynamoDB専用・API互換・変更最小。ElastiCache→RDS/Aurora等汎用、アプリ側でキャッシュロジックを実装
• MemoryDB→Redis/Valkey互換で「データ損失不可」のプライマリDB。ElastiCache＝キャッシュ、MemoryDB＝DB本体
• 読み取り集中→リードレプリカ or キャッシュ（同一クエリの繰り返しならキャッシュが最も効く）。書き込み集中→SQSバッファ・シャーディング・DynamoDB

引っかけ

• 「常に最新のデータをキャッシュから返す」→ライトスルー、「キャッシュ容量を抑え読み取りだけ速く」→遅延読み込み
• 「Redis互換でデータ損失が許されないプライマリDB」→MemoryDB（ElastiCacheではない）
• 「同一クエリが繰り返される読み取り負荷」→ElastiCache（大型インスタンス化やレプリカ追加より効果的・安価）

DBコスト最適化パターン　B: 頻出

開発環境は停止/サーバーレス、安定負荷はリザーブド、変動負荷はオンデマンド。読み取り対策で大型化しない

• 開発/検証DB→RDS停止（最大7日、7日後に自動起動。リードレプリカ付き/レプリカ自身は停止不可）／Aurora Serverless v2（0 ACUへ自動停止）／Auroraクローンで検証環境
• 安定負荷→RDS/Aurora/ElastiCache/Redshift/OpenSearchのリザーブド（1年/3年）、DynamoDB予約キャパシティ
• 変動・断続的負荷→DynamoDBオンデマンド、Aurora Serverless v2、Redshift Serverless。安定なら DynamoDBプロビジョンド＋Auto Scaling
• 読み取り負荷→インスタンス拡大の前にリードレプリカ／ElastiCache／DAX（大型インスタンスを回避）
• 低頻度データ→DynamoDB Standard-IA。I/O課金が総額の25%超→Aurora I/O-Optimized（目安）
• バックアップ→保持期間を要件に合わせ短縮、放置された手動スナップショットの削除、AWS Backupライフサイクルでコールド階層へ
• Graviton（db.r7g等）で価格性能向上。非本番はMulti-AZ不要・単一AZ・小さいクラス
• 一時的なS3データ分析→Athena。Redshiftは低頻度データをS3に置きSpectrumで参照、Concurrency Scalingの無料枠

引っかけ

• 「開発環境のコスト削減」→夜間停止/Serverless（Multi-AZやリザーブドは不要）
• 「読み取り負荷対策」で「インスタンスサイズ拡大」は運用/コストで不正解になりやすい
• 「RDS停止は永続」ではない→7日後に自動起動。長期停止はスナップショット→削除→必要時に復元
• 「本番と同じ可用性を非本番にも」は過剰。要件を満たす最安を選ぶ

DynamoDB 設計・スロットリング対策・アクセス制御　C: たまに

ProvisionedThroughputExceededは「RCUを上げる」より、キー設計・DAX・オンデマンド・バックオフで解く

• スロットリング対策→指数バックオフ（SDK既定）、パーティションキーの分散（高カーディナリティ・乱数サフィックスの書込シャーディング）、オンデマンド切替、DAX、Auto Scaling
• ホットパーティション→Contributor Insightsで検出。適応キャパシティは自動、バーストキャパシティは直近5分の未使用分
• バッチ→BatchWriteItem（25項目/16MB）、BatchGetItem（100項目/16MB）。大きな属性はS3へ（400KB制限）
• Query（キー指定）優先、Scanは並列Scan・ページング・Limitで影響を抑える。フィルタ式はRCUを減らさない
• 細粒度アクセス→IAM条件 dynamodb:LeadingKeys で「自分のパーティションキーの項目のみ」、Cognito IDプールと組合せ。リソースベースポリシーにも対応（2024〜）
• 暗号化は常時（AWS所有/AWSマネージド/カスタマーマネージドキー）、VPCゲートウェイエンドポイント（無料）でインターネット非経由

引っかけ

• 「スロットリングが発生」で「単純にRCU/WCUを上げる」は最適解でないことが多い→キー設計/DAX/オンデマンド/バックオフ
• 「Scanで全件読んでフィルタ」はRCU浪費→GSI＋Query
• 「ユーザーが自分の項目だけ読めるように」→IAM条件 dynamodb:LeadingKeys（アプリ側実装ではない）

ネットワーキング・コンテンツ配信

問題文の制約語（インターネット非経由／固定IP／多数VPC／暗号化／今すぐ／最安）で候補を1つに絞る分野。比較表を上から眺め、traps の「→」だけ最後にもう一度読む。2019年からの上書き：多数VPC接続=Transit Gateway、S3非公開配信=OAC（旧OAI）、GWLB追加で4種・CLBは答えにならない、「閉域で」=VPCエンドポイント/PrivateLink、軽いエッジ処理=CloudFront Functions。

VPC基礎（CIDR・サブネット・ルートテーブル・IGW）　A: 毎回級

AWS上の自分専用ネットワーク。サブネットはAZ単位、パブリック/プライベートはルートテーブルで決まる

• CIDRは/16〜/28。作成後に主CIDRは変更不可、セカンダリCIDRの追加は可。リージョンあたりVPC既定5個
• サブネットは1つのAZに属す（AZをまたげない）。各サブネットで5IP予約（.0=ネットワーク／.1=ルーター／.2=DNS／.3=予約／末尾=ブロードキャスト）
• パブリックサブネット＝ルートテーブルに 0.0.0.0/0→IGW。プライベート＝そのルートなし（NAT経由 or 閉域）
• IGWは1VPCに1つ、水平スケールで帯域制限なし。ルートは最長一致、ローカルルート（VPC内）が最優先
• DNS属性 enableDnsSupport と enableDnsHostnames を両方ON→パブリックDNS名・プライベートホストゾーンが機能
• IPv6はグローバルユニキャストのみ。アウトバウンド専用→Egress-only IGW
• アカウント間でサブネットを共有→RAM（VPC共有）。ピアリングは別VPC同士の接続

引っかけ

• 「プライベートサブネットのEC2は直接インターネットから到達不可」→ IGWルート追加・EIP付与は要件違反、正解はNAT GW＋ルート更新（公式サンプル問1）
• 「サブネットを2つのAZにまたがって作成」→ 不可。AZごとにサブネットを作りELB/ASGで分散
• 「プライベートホストゾーンが引けない」→ VPCのDNS属性が無効（NACL/SGではない）
• 「別アカウントとサブネットを共有」→ RAM（VPCピアリングではない）

NAT Gateway vs NATインスタンス　A: 毎回級

プライベートサブネットからの片方向アウトバウンド。マネージドのNAT GWが原則、Egress-only IGWはIPv6版

• NAT GWはパブリックサブネットに置きEIP必須＋プライベート側ルートテーブルに 0.0.0.0/0→NAT GW（この2手順が複数選択の定番）
• 5Gbpsから最大100Gbpsへ自動スケール、AZ内で冗長。SGはアタッチ不可（サブネットのNACLは効く）。インバウンドは受け付けない
• AZ単位→HAには各AZに1つ置き、各AZのプライベートサブネットは同一AZのNAT GWへ向ける
• 2025/11〜「リージョナルNAT GW」（VPC単位で全AZに自動展開、パブリックサブネット不要）も登場。試験は従来のAZ単位（ゾーナル）で考えればよい
• 課金＝時間＋処理GB。S3/DynamoDB宛はGateway型エンドポイント（無料）に逃がして削減
• NATインスタンス＝EC2で自己管理、送信元/送信先チェック無効化が必須、SG可、踏み台・ポート転送兼用可、冗長化は自前
• IPv6のアウトバウンド→Egress-only IGW（NAT GWはIPv4）。CIDR重複環境のVPC間通信→プライベートNAT GW

NAT Gateway vs NATインスタンス

項目	NAT Gateway	NATインスタンス
管理	マネージド	自己管理（EC2）
帯域	5→最大100Gbps自動	インスタンスサイズ依存
冗長	AZ内自動、AZごとに配置	自前スクリプト等
SG	不可	可
送信元/送信先チェック	不要	無効化必須
踏み台/ポート転送	不可	可
向き	本番・安定運用	最安・小規模・踏み台兼用

引っかけ

• 「NAT GWをプライベートサブネットに配置」→ 不正解（パブリックサブネット必須）
• 「単一NAT GWを全AZで共有」→ 安いがAZ障害で他AZも外に出られない＋AZ間転送料。HA要件なら各AZに配置
• 「NAT GWのデータ処理料が高い（S3への大量転送）」→ Gateway型VPCエンドポイント（NAT GW増設ではない）
• 「NAT GWにSGを付けて制御」→ 不可。制御はEC2側SGかサブネットのNACL

セキュリティグループ vs ネットワークACL　A: 毎回級

SG＝インスタンス（ENI）の門番・ステートフル・Allowのみ、NACL＝サブネットの門番・ステートレス・Denyも書ける

• SG：ENI単位、ステートフル（戻りは自動許可）、Allowルールのみ、全ルール評価、既定＝イン全拒否/アウト全許可、変更は即時反映
• SGのソースに別SG IDを指定（DB SGはWeb SGからの3306のみ）＝階層間制御の定石。1ENIに既定5個まで
• NACL：サブネット単位、ステートレス（戻りも明示。エフェメラル1024-65535を両方向で許可）、AllowとDeny両方
• NACLは番号（1〜32766）の小さい順に評価し最初の一致で確定。デフォルトNACL＝全許可、カスタムNACL＝全拒否。1サブネット1NACL
• 特定IPの「拒否」はNACL（SGはDenyを書けない）。L7ならWAFのIPセット
• ALB→EC2：EC2のSGでALBのSGをソースに許可。NLBは送信元IPが保持されるのでクライアントIPを許可（NLBにSGを付けた場合はNLBのSGをソース参照も可）
• SGが付くもの：EC2/ENI、ALB/NLB、RDS、VPC内Lambda、EFSマウントターゲット、Interfaceエンドポイント。付かないもの：NAT GW、Gateway型エンドポイント

SG vs NACL

項目	セキュリティグループ	ネットワークACL
適用単位	ENI（インスタンス）	サブネット
状態	ステートフル	ステートレス
ルール	Allowのみ	Allow＋Deny
評価	全ルール	番号順・最初の一致
既定	イン拒否/アウト許可	デフォルト=全許可、カスタム=全拒否
ソース指定	CIDR/SG ID/プレフィックスリスト	CIDRのみ

引っかけ

• 「特定IPからの攻撃を遮断」→ NACLのDenyルール（SGでは不可）
• 「HTTPを許可したのに応答が返らない」→ NACLのアウトバウンドでエフェメラルポート未許可（ステートレスの典型）
• 「ルールの評価順序」を問われたら NACLのみ（SGは順序なし・全評価）

VPCエンドポイント（Gateway vs Interface/PrivateLink）　A: 毎回級

「インターネットを経由せずAWSサービスへ」の定番解。S3/DynamoDBは無料のGateway型、それ以外と自社サービス公開はPrivateLink

• Gateway型：S3とDynamoDBのみ、ルートテーブルにプレフィックスリストを追加、無料、SG不可、同一リージョンのVPC内からのみ
• Interface型（PrivateLink）：サブネットにENI＋プライベートIP、SGで制御、AZごとの時間＋GB課金、ほぼ全サービス対応、プライベートDNSでサービス名のまま解決
• S3はGateway/Interface両方あり。オンプレ（DX/VPN経由）やピアリング先から使うならInterface型
• エンドポイントポリシーで許可操作/バケットを制限。S3バケットポリシーに aws:SourceVpce / aws:SourceVpc 条件で「このエンドポイント経由のみ」
• PrivateLink：提供側にNLB（GWLBも可）、利用側にInterfaceエンドポイント。CIDR重複OK、ピアリング不要、一方向、数千VPCへ提供可
• スレッドの要点：API GatewayプライベートAPI＝Interfaceエンドポイント＋リソースポリシーでVPCエンドポイントIDを指定。VPC内リソースへの統合はVPCリンク
• S3アクセスポイントをVPCオリジン限定＋Gateway型エンドポイント、Session Manager（ssm/ssmmessages/ec2messages）もInterface型で閉域化

Gateway型 vs Interface型

項目	Gateway型	Interface型（PrivateLink）
対象	S3・DynamoDB	ほぼ全サービス＋自社/SaaS
実体	ルートテーブルのエントリ	サブネット内ENI＋プライベートIP
料金	無料	AZ毎の時間＋GB
SG	不可	可
オンプレ/他VPCから	不可	可（DX/VPN/ピアリング経由）
DNS	不要（プレフィックスリスト）	プライベートDNS

引っかけ

• 「VPC内からS3へ最も安く閉域で」→ Gateway型（Interface型は有料）
• 「オンプレからS3へプライベートに」→ Interface型（Gateway型はVPC外から使えない）
• 「SaaSを多数の顧客VPCに提供」「CIDRが重複」→ PrivateLink（ピアリング/TGWは重複不可・スケールしない）
• 「エンドポイントポリシーで許可すればIAM不要」→ 誤り。IAM/バケットポリシーとの積集合で決まる

ELB：ALB / NLB / GWLB / CLB　A: 毎回級

L7＝ALB、L4・固定IP＝NLB、サードパーティFW挿入＝GWLB。CLBは旧世代で答えにならない（スレッドで整理済み）

• ALB（L7）：HTTP/HTTPS/gRPC/WebSocket、ホスト/パス/ヘッダー/クエリ/送信元IPルーティング、ターゲット＝EC2/IP/Lambda/ECS（動的ポート）、WAF・Cognito認証・リダイレクト可、固定IPなし、X-Forwarded-Forで元IP
• NLB（L4）：TCP/UDP/TLS、超低遅延・毎秒数百万リクエスト、AZごとに静的IP/EIP、送信元IP保持、PrivateLinkの裏側、ALBをターゲットにできる
• GWLB（L3）：サードパーティ仮想アプライアンス（FW/IDS/IPS）を透過的に挿入、GENEVE 6081、GWLBエンドポイントで経路に割り込む
• 「ALBに固定IPが必要」→ 前段にNLB（ALBをターゲット）または Global Accelerator
• ELBはリージョン内のみ（複数AZに分散）。リージョン間の分散はRoute 53 / Global Accelerator
• CloudFront経由のみALBに通す：カスタムヘッダー＋リスナールール、またはCloudFrontマネージドプレフィックスリストをSGで許可。2024/11〜はCloudFront VPCオリジンでALB/NLB/EC2をプライベートサブネットに置いたまま配信可（最新の正解候補）
• 2019年からの差分：GWLB追加で4種、NLBもSG対応（2023/8〜）、CLBは新規非推奨

ELB 3種の使い分け

項目	ALB	NLB	GWLB
レイヤー	L7	L4	L3
プロトコル	HTTP/HTTPS/gRPC/WS	TCP/UDP/TLS	IP（GENEVE 6081）
固定IP	なし	AZごと静的/EIP	—
WAF	可	不可	不可
ルーティング	パス/ホスト/ヘッダー	ポート/フロー	全通過
ターゲット	EC2/IP/Lambda/ECS	EC2/IP/ALB	仮想アプライアンス
典型	Web/API/コンテナ	固定IP/UDP/PrivateLink	FW/IDS/IPS挿入

引っかけ

• 「固定IP／ホワイトリスト登録が必要」→ NLB（ALBはIPが変動）
• 「UDP」「TCPゲーム」「超低遅延」→ NLB（ALBはHTTP系のみ）
• 「WAFで保護したい」→ ALB / CloudFront / API Gateway（NLBには付けられない）
• 「サードパーティFWを通す」→ GWLB。「パス/ホストで振分け」「マイクロサービス」→ ALB

Route 53 ルーティングポリシー　A: 毎回級

DNSで振り分ける8種。位置情報（ユーザーの所在地）と地理的近接性（リソースとの距離＋バイアス）の区別が肝

• シンプル：1レコードに複数値可、ヘルスチェック不可。加重：0〜255の比率（A/B・カナリア・段階移行、0で停止）
• レイテンシー：実測で最も低遅延のリージョンへ（利用者の場所ではなく遅延）
• フェイルオーバー：アクティブ/パッシブ、プライマリにヘルスチェック必須、セカンダリにS3静的サイト（エイリアス）も可
• 位置情報：ユーザーの国/大陸/州で振分け（コンテンツ制限・ローカライズ）、デフォルト（*）レコードを必ず置く
• 地理的近接性：リソースの位置＋バイアス（-99〜+99）で範囲を伸縮。2024/1〜通常のレコードでも設定可（以前はTraffic Flow限定、地図表示はTraffic Flowのみ）
• 複数値回答：最大8つの正常レコードをランダム返却（簡易LB）。IPベース：クライアントのCIDRで振分け
• アクティブ/アクティブは加重 or レイテンシー＋ヘルスチェックで実現。DR用は事前にTTLを短く

ルーティングポリシーの判断基準

ポリシー	判断基準	典型キーワード
加重	指定した比率	A/Bテスト・段階移行
レイテンシー	実測の遅延	最速リージョン
フェイルオーバー	ヘルスチェック	アクティブ/パッシブDR
位置情報	ユーザーの所在地	国別コンテンツ・規制
地理的近接性	リソースとの距離＋バイアス	トラフィックの寄せ
複数値回答	正常な最大8件	簡易LB
IPベース	クライアントCIDR	ISP/拠点別

引っかけ

• 「国ごとに別コンテンツ／配信規制」→ 位置情報（レイテンシーではない）
• 「最も近い（速い）リージョンへ」→ レイテンシー。「一部リージョンにトラフィックを寄せる／バイアス」→ 地理的近接性
• 「アクティブ/パッシブのDR自動切替」→ フェイルオーバー＋ヘルスチェック
• 「シンプルルーティングにヘルスチェック」→ 不可（複数値回答を使う）

CloudFront（OAC・署名付きURL/Cookie・キャッシュ・Origin Shield）　A: 毎回級

エッジでキャッシュするCDN。S3非公開配信＝OAC、有料コンテンツ＝署名付きURL/Cookie、独自ドメイン証明書はus-east-1

• オリジン：S3（OAC）、ALB/EC2、API Gateway、任意HTTP、VPCオリジン（2024/11〜、プライベートサブネットのALB/NLB/EC2）。オリジングループでフェイルオーバー（プライマリ5xx→セカンダリ）
• OAC（旧OAI）：S3はパブリックアクセスブロックのまま、バケットポリシーでそのディストリビューションのみ許可。SSE-KMSオブジェクトもOACなら配信可
• 署名付きURL＝個別ファイル、署名付きCookie＝複数ファイル/サイト全体（URL変更不要）。キーグループの公開鍵で署名
• 地理的制限：国単位の許可/拒否リスト。フィールドレベル暗号化：機密フィールドをエッジで公開鍵暗号化
• キャッシュ：デフォルトTTL 24時間、キャッシュポリシーでキー（ヘッダー/クエリ/Cookie）を最小化しヒット率向上。無効化は月1,000パスまで無料
• Origin Shield：リージョナルエッジキャッシュとオリジンの間に集約キャッシュ層→全リージョナルエッジからの要求を1か所に集めオリジン負荷・転送コスト削減。価格クラスで配信エッジを絞ればコスト減
• 独自ドメインの証明書はACM us-east-1。WAF/Shield統合、SGは付かない。HTTP/2・HTTP/3対応、HTTPSリダイレクト可
• S3/ELB→CloudFrontの転送は無料、CloudFront→インターネットはS3直より安い

引っかけ

• 「S3に直接アクセスさせずCloudFront経由のみ」→ OAC＋バケットポリシー（S3の署名付きURLと混同しない）
• 「S3静的サイトにHTTPS」→ CloudFront＋ACM（us-east-1）。S3のWebサイトエンドポイントはHTTPのみ
• 「会員向け動画を複数ファイルまとめて制限」→ 署名付きCookie。1ファイルだけ→ 署名付きURL
• 「OAI」は旧方式、選択肢にOACがあればOAC。「UDP／固定IP」→ CloudFrontではなくGlobal Accelerator

CloudFront vs Global Accelerator　A: 毎回級

HTTPをキャッシュして速く＝CloudFront、固定IP・TCP/UDPをAWS網で速く＝Global Accelerator

• Global Accelerator：2つの静的Anycast IP、L4 TCP/UDP、キャッシュなし、最寄りエッジからAWSバックボーンで最適リージョンへ。エンドポイント＝ALB/NLB/EC2/EIP（複数リージョン可）
• ヘルスチェックで秒単位のリージョンフェイルオーバー。IPが変わらないのでDNS TTLに依存しない
• 用途：ゲーム（UDP）、VoIP、IoT（MQTT）、金融APIのIP許可リスト、マルチリージョンActive-Active
• CloudFront：L7 HTTP(S)のみ、エッジキャッシュ、動的コンテンツもバックボーン経由で高速化、IPは変動
• 両者ともShield Standardで保護。GAは固定時間＋プレミアム転送料、CloudFrontは転送＋リクエスト課金

CloudFront vs Global Accelerator

項目	CloudFront	Global Accelerator
レイヤー	L7 HTTP/HTTPS	L4 TCP/UDP
キャッシュ	あり	なし
IP	変動	静的Anycast IP×2
エンドポイント	S3/ALB/任意HTTP	ALB/NLB/EC2/EIP
切替	オリジングループ	ヘルスチェックで秒単位
典型	Web/動画/API	ゲーム/VoIP/IoT/IP許可リスト

引っかけ

• 「静的IP」「UDP」「HTTP以外」→ Global Accelerator（CloudFront/ALBでは不可）
• 「キャッシュで負荷軽減」「動画・静的配信」→ CloudFront（GAはキャッシュしない）
• 「DNSキャッシュで切替が遅い」→ Global Accelerator（IP固定で即時フェイルオーバー）
• 「ALBに固定IPを付けたい」→ Global Accelerator または前段にNLB

VPCピアリング vs Transit Gateway　B: 頻出

1対1で少数＝ピアリング、多数VPC・オンプレを束ねるハブ＝Transit Gateway（2019年以降の定番解、スレッドで確認）

• ピアリング：1対1、非推移（A-B, B-CでもA-Cは不通）、CIDR重複不可、クロスアカウント/リージョン可、両側のルートテーブルにルート追加、接続自体は無料
• ピアリング経由で相手VPCのIGW/NAT GW/VPCエンドポイント/VGWは使えない（エッジ間ルーティング不可）。SG参照は同一リージョンのみ（別リージョンはCIDR指定）
• N個をフルメッシュにすると N(N-1)/2 本→運用負荷で不正解の目印
• TGW：リージョナルなハブ。VPC/Site-to-Site VPN/DX（トランジットVIF）/リージョン間ピアリング/Connectをアタッチ、推移的ルーティング
• TGWルートテーブルで分離（本番と開発を通さない）、VPN ECMPで帯域集約、マルチキャスト対応、RAMで組織内共有
• 課金：アタッチメントごとの時間＋処理GB。2〜3VPCならピアリングが安い
• 共有NAT/Network Firewallによる集約アウトバウンド（検査VPC）はTGWで実現

ピアリング vs TGW

項目	VPCピアリング	Transit Gateway
接続形態	1対1	ハブ&スポーク
推移性	なし	あり
CIDR重複	不可	不可
オンプレ接続	不可（別途VPN/DX）	VPN/DXを集約
料金	転送のみ	アタッチ時間＋GB
規模	少数	数千VPC

引っかけ

• 「数十のVPCを相互接続」「オンプレと多数VPC」→ TGW（ピアリングのメッシュは不正解）
• 「ピアリングで相手VPCのNAT/IGW/エンドポイントを共有」→ 不可
• 「CIDRが重複するVPC同士」→ ピアリングもTGWも不可 → PrivateLink かプライベートNAT GW
• 「2つのVPCだけを最安で」→ ピアリング（TGWは過剰）

Site-to-Site VPN vs Direct Connect　B: 頻出

今すぐ・安く・暗号化＝VPN、安定した大帯域・低遅延＝DX（暗号化なし、開通に数週間〜数か月）

• Site-to-Site VPN：インターネット経由IPsec。カスタマーゲートウェイ（オンプレ）＋仮想プライベートゲートウェイ or TGW、トンネル2本で冗長、1トンネル既定1.25Gbps（2025/11〜最大5Gbpsトンネルも選択可。試験は1.25Gbps前提でOK）
• VPNは数分〜数時間で開設、標準で暗号化、帯域はインターネット品質に依存（保証なし）。TGWのECMPで複数VPNを束ねて増速
• Accelerated VPN：Global Accelerator経由でTGWへ。VPN CloudHub：複数拠点をVGWでハブ接続
• DX：専用線。専用接続1/10/100/400Gbps、ホスト型接続50Mbps〜25Gbps。一貫した低遅延・帯域、転送料がインターネット経由より安い
• DXはデフォルトで暗号化されない→必要ならDX上にIPsec VPN（パブリックVIF経由）または専用接続のMACsec
• Client VPN：リモートユーザーのPCからVPCへOpenVPN（AD/SAML/相互証明書認証）。拠点間はSite-to-Site

VPN vs DX

項目	Site-to-Site VPN	Direct Connect
経路	インターネット	専用線
開設	数分〜数時間	数週間〜数か月
帯域	1.25Gbps/トンネル（5Gbps選択可）・変動	50Mbps〜400Gbps・一定
暗号化	IPsecで標準	なし（VPN over DX / MACsec）
コスト	安い	高い（大量転送では転送料が安い）
用途	即時・バックアップ・小規模	安定・大容量・ハイブリッド本番

引っかけ

• 「来週までに接続」「すぐ必要」→ VPN（DXは間に合わない）
• 「DXは暗号化されている」→ 誤り。「専用線かつ暗号化」→ DX上にIPsec VPN
• 「一貫した性能で大量データ・低遅延」→ DX。「VPNに帯域保証がある」→ 誤り
• 「在宅の個人ユーザーがVPCへ接続」→ Client VPN（Site-to-Siteではない）

Direct Connect 詳細（VIF・DX Gateway・冗長化）　B: 頻出

VIFの3種類と冗長構成の型を覚える。バックアップはDX×2（別ロケーション）かDX＋VPN

• プライベートVIF→VPC（VGW経由）、パブリックVIF→S3等のパブリックサービス（VPN over DXにも使う）、トランジットVIF→TGW（DX Gateway経由）
• DX Gateway：グローバルリソース。1本のDXから複数リージョン・複数アカウントのVPC/TGWへ接続
• 専用接続（Dedicated）＝AWSから1/10/100/400Gbpsの物理ポート、ホスト型（Hosted）＝パートナー経由で50Mbps〜25Gbps
• LAG：同帯域の複数接続をLACPで束ねる。BGP必須、BFDで高速障害検知
• 冗長化の型：最大の回復力（99.99%）＝2ロケーション以上×各2本（別デバイス終端）、高い回復力（99.9%）＝2ロケーション×各1本、開発/テスト用＝1ロケーション2本（別デバイス）。コスト重視＝DX＋バックアップVPN
• DX SiteLink：DXロケーション経由でオンプレ拠点同士を接続。暗号化はMACsec（専用接続）またはIPsec VPN
• パブリックVIFでS3/DynamoDBへ直接（VPCを経由しない）。VPC内の閉域S3アクセスはInterfaceエンドポイント

引っかけ

• 「DX障害時のバックアップを安く」→ Site-to-Site VPN（同じ経路をBGP広告、DXを優先）
• 「複数リージョンのVPCに1本のDXで」→ DX Gateway（リージョンごとにDXを引かない）
• 「DXでTGWに接続」→ トランジットVIF＋DX Gateway（プライベートVIFではない）
• 「単一DX 1本で高可用性」→ 不十分。別ロケーションの2本目かVPNバックアップ

Route 53：エイリアス vs CNAME・ヘルスチェック・Resolver　B: 頻出

Zone Apexはエイリアス一択。ハイブリッドDNSはResolverエンドポイント（インバウンド＝オンプレ→AWS、アウトバウンド＝AWS→オンプレ）

• エイリアス：AWSリソース（ELB/CloudFront/S3静的サイト/API GW/Global Accelerator/Beanstalk/Interfaceエンドポイント/同ゾーン内レコード）向け、Zone Apex可、クエリ無料、TTLはリソース側
• CNAME：任意のDNS名を指せるがZone Apex不可、クエリ有料。example.com（ネイキッド）にELB→エイリアス
• ヘルスチェック3種：エンドポイント（HTTP/HTTPS/TCP、既定30秒・高速10秒、複数リージョンのチェッカー）、計算済み（子の組合せ）、CloudWatchアラーム連動
• チェッカーはインターネット側から→プライベートIPのリソースはCloudWatchアラーム連動型で。ELB配下はELBのヘルスチェックを使う
• プライベートホストゾーン：VPC内部DNS、複数VPC・別アカウントのVPCにも関連付け可。VPCのDNS属性ON必須
• Resolver：インバウンドエンドポイント＝オンプレ→VPCのプライベートゾーン解決、アウトバウンドエンドポイント＋転送ルール＝VPC→オンプレDNS（条件付きフォワーディング）
• Resolver DNS Firewall：VPCからの名前解決をドメインで許可/拒否（Firewall Managerで組織一括）。Route 53 ARC：リージョン切替のルーティング制御
• 短いTTL→フェイルオーバーが速いがクエリ増。DNSSEC署名対応、ドメイン登録も可

エイリアス vs CNAME

項目	エイリアス	CNAME
指せる先	AWSリソース/同ゾーンのレコード	任意のDNS名
Zone Apex	可	不可
クエリ課金	無料（AWSリソース）	有料
TTL	リソース側で自動	自分で設定
ヘルスチェック	Evaluate Target Health	レコードに紐付け

引っかけ

• 「example.com（Zone Apex）をALB/CloudFrontに向ける」→ エイリアス（CNAMEは不可）
• 「オンプレのサーバーがVPC内のプライベートDNS名を引く」→ インバウンドエンドポイント。「EC2がオンプレADのDNSを引く」→ アウトバウンド＋転送ルール
• 「プライベートサブネットのEC2をRoute 53ヘルスチェック」→ 直接は不可 → CloudWatchアラーム連動
• 「Route 53ヘルスチェックが失敗し続ける」→ SG/NACLでチェッカーのIP範囲を許可していない

ELB 細目（スティッキー・クロスゾーン・TLS終端・ヘルスチェック）　B: 頻出

既定値を押さえる。特に「NLBのクロスゾーンは既定OFF」と「登録解除の遅延300秒」

• クロスゾーン負荷分散：ALBは既定ON・無料、NLB/GWLBは既定OFF（有効化でAZ間転送料）。OFFだとAZごとのターゲット数差でトラフィックが偏る
• スティッキーセッション：ALBは期間ベース（AWSALB Cookie）とアプリケーションCookie、NLBは送信元IPベース。ターゲットグループ単位。より良い設計はElastiCache/DynamoDBへのセッション外出し
• TLS終端：ALB/NLBともACM証明書、SNIで1リスナーに複数証明書。ALB→ターゲット再暗号化可、NLBはTCPリスナーでTLSパススルーも可
• ヘルスチェック：ALB＝HTTP/HTTPS/gRPCのパス、NLB＝TCP/HTTP/HTTPS。ASGのヘルスチェックタイプをELBにすると異常インスタンスを置換
• 登録解除の遅延（Connection Draining）既定300秒（0〜3600）。ALBアイドルタイムアウト既定60秒
• ALBはSG必須。内部（internal）ELBはプライベートIPのみで非公開。アクセスログはS3へ（既定OFF）
• ターゲットグループにインスタンスIDとIPは混在不可、パブリックIPはターゲット不可。ALB→Lambdaは同期呼出し
• ELBはDNS名固定・IP変動（TTL 60秒）。fail-open：全ターゲット異常なら全ターゲットへ転送

ALB vs NLB の既定値

項目	ALB	NLB
クロスゾーン既定	ON（無料）	OFF（有効化で課金）
スティッキー	Cookie	送信元IP
TLS終端	可（ACM/SNI）	可（ACM/SNI）/パススルー
送信元IP	X-Forwarded-For	そのまま保持
SG	必須	任意（2023/8〜）
ヘルスチェック	HTTP/HTTPS/gRPC	TCP/HTTP/HTTPS

引っかけ

• 「AZ間でトラフィックが偏る（NLB）」→ クロスゾーン負荷分散を有効化（ALBは既にON）
• 「ELBのヘルスチェックは異常なのにASGが入替えない」→ ASGのヘルスチェックタイプがEC2のまま→ELBに変更
• 「1つのALBで複数ドメインのHTTPS」→ SNI（ドメインごとにALBを作らない）
• 「スティッキーセッションで解決」より、ステートレス化（ElastiCache/DynamoDB）が「より良い」正解になりやすい

エッジ処理：Lambda@Edge vs CloudFront Functions　B: 頻出

軽いヘッダー/URL書換え＝CloudFront Functions、外部呼出しやオリジン側の処理＝Lambda@Edge（スレッドで差分として確認）

• CloudFront Functions（2021〜）：JavaScriptのみ、実行1ms未満、ビューワーリクエスト/レスポンスのみ、ヘッダー操作・URL書換・リダイレクト・キャッシュキー正規化。Lambda@Edgeより安価で高頻度向け
• Lambda@Edge：Node.js/Python、4イベント（ビューワー/オリジン×リクエスト/レスポンス）、ネットワーク・外部API・S3読取可。us-east-1で作成しエッジに複製
• Lambda@Edgeの用途：User-Agent別コンテンツ、A/Bテスト、オリジンの動的選択、JWT検証などの認証、画像リサイズ
• Lambda@Edgeの制約：VPCアクセス・環境変数・レイヤー・プロビジョニング済み同時実行不可、番号付きバージョン必須（$LATEST不可）、ビューワー系は短いタイムアウト
• 2019年からの差分：CloudFront Functionsが追加。単純処理でLambda@Edgeを選ぶと「コスト・遅延」で負ける

CloudFront Functions vs Lambda@Edge

項目	CloudFront Functions	Lambda@Edge
言語	JavaScript	Node.js / Python
イベント	ビューワー2種	ビューワー＋オリジン4種
実行時間	1ms未満	秒単位
外部呼出し	不可	可
料金	安い	高い
用途	ヘッダー/URL/リダイレクト	動的オリジン/認証/A/B

引っかけ

• 「オリジンリクエストを書き換える」「外部サービスを呼ぶ」「S3を読む」→ Lambda@Edge（CloudFront Functionsは不可）
• 「ヘッダー追加/リダイレクトを最も安く・低遅延で」→ CloudFront Functions
• 「Lambda@Edgeを東京リージョンで作成」→ 不可（us-east-1で作成）

ネットワーク・データ転送コストの型　B: 頻出

受信無料・送信課金。同一AZプライベートIPは無料、AZ間/リージョン間/インターネット出は課金。NAT料金はエンドポイントで逃がす

• インバウンド（インターネット→AWS）無料、アウトバウンドは課金。同一AZ内のプライベートIP通信は無料
• AZ間はGBあたり双方向に課金、リージョン間も課金。パブリックIP/EIP経由は同一AZでも課金→プライベートIPで通信
• NAT GW：時間＋処理GB。S3/DynamoDBはGateway型エンドポイント（無料）へ。AZごとにNAT GWを置けばAZ間転送料も回避
• Interfaceエンドポイント：AZ毎の時間＋GB。それでもNAT GW経由より安いことが多い
• CloudFront：S3/ELB→CloudFrontは無料、CloudFront→インターネットはS3/EC2直より安い。価格クラスでエッジ限定
• DX：継続的な大量アウトバウンドではインターネット経由よりGB単価が安い
• TGW：アタッチ時間＋処理GB。ピアリングは同一AZ内無料・AZ間課金。NLBクロスゾーンONでAZ間課金
• S3 CRR等のリージョン間レプリケーションも転送料→必要データのみ複製

引っかけ

• 「プライベートサブネットからS3への転送費が高い」→ Gateway型エンドポイント（NAT GW増設ではない）
• 「EC2同士の通信コストを下げる」→ 同一AZ・プライベートIP（パブリックIPは課金）
• 「AZ間転送料を減らす」と「複数AZの可用性」はトレードオフ。HA要件があれば安さより複数AZ
• 「S3から世界へ大量配信のコスト」→ CloudFrontを前置き（転送単価が下がり、S3→CFは無料）

VPC Flow Logs・Reachability Analyzer・Traffic Mirroring　C: たまに

フローログ＝誰と誰が通ったか（メタデータ）、Traffic Mirroring＝パケットの中身、Reachability Analyzer＝経路診断

• Flow Logs：VPC/サブネット/ENI単位でIPトラフィックのメタデータ（送信元/宛先IP・ポート・プロトコル・バイト数・ACCEPT/REJECT）。集計間隔1分/10分（既定10分）
• 宛先：CloudWatch Logs / S3 / Firehose。S3に置いてAthenaで分析が定番。パケットの中身は記録しない
• 記録されないもの：Amazon DNSサーバー（Route 53 Resolver）へのDNSクエリ、DHCP、インスタンスメタデータ（169.254.169.254）、Time Sync（169.254.169.123）、Windowsライセンス認証、ARP、VPCルーター予約IP宛
• SG/NACLで落ちているか→REJECTを検索。GuardDutyもフローログを自動分析（有効化不要）
• Traffic Mirroring：ENIのパケットをコピーしてセキュリティアプライアンス（NLB/ENI）へ→中身の解析・IDS
• Reachability Analyzer：送信元→宛先の到達可能性を設定から静的に診断（SG/NACL/ルートのどこで止まるか）
• Network Access Analyzer：意図しない経路（インターネット到達など）を検出

引っかけ

• 「パケットの中身を検査」→ Traffic Mirroring（フローログはメタデータのみ）
• 「なぜ通信できないかを特定」→ Reachability Analyzer（試行錯誤ではない）
• 「DNSクエリを記録したい」→ フローログでは不可 → Route 53 Resolverクエリログ

VPC IPAM・セカンダリCIDR・ENI・Network Firewall（触れる程度）　C: たまに

IP一元管理＝IPAM、固定プライベートIPの引継ぎ＝セカンダリENI付替え、VPC境界のドメイン制御＝Network Firewall（スレッドで整理）

• VPC IPAM：複数アカウント・複数リージョンのCIDRをプール階層で一元管理、重複防止、自動割当、使用状況の監視。Organizations統合（スレッドの定番解答）
• セカンダリCIDR：VPC作成後にIP範囲を追加（主CIDRは変更不可）。サブネットのIP枯渇対策
• ENI：プライマリENIはデタッチ不可、セカンダリENIは同一AZ内の別インスタンスに付替え可→固定プライベートIP/MACを引継ぐフェイルオーバー（公式サンプル問3）
• ENIが持つもの：プライベートIP（複数可）、EIP、SG、MAC、送信元/送信先チェックフラグ
• Network Firewall（2020〜）：VPC単位のマネージドFW、ステートフル/ステートレス、Suricata互換IPS、ドメイン/URLフィルタ。専用サブネットに置きルートテーブルで経路を通す
• Network Firewallの守備範囲：アウトバウンドの「特定ドメインのみ許可」など。WAFはL7 HTTP、SG/NACLはドメイン指定不可。Firewall Managerで組織一括
• EKSのVPC CNI/カスタムネットワーキングは範囲外（スレッドで確認済み）

引っかけ

• 「複数アカウント・VPCでIPの重複/枯渇を防ぐ」→ VPC IPAM（手動台帳ではない）
• 「プライベートIPを引き継いで待機系へ即時切替」→ セカンダリENIの付替え（EIP/ALBではない）
• 「VPCから特定ドメインへのアウトバウンドのみ許可」→ Network Firewall（SG/NACLはドメイン不可）

おわりに

前の回: 第2回 ／ 次の回: 第4回

早見表と他の回への目次は 第 1 回 にまとめています。