AWS SAA-C03 詳細リファレンス

AWS上に仮想サーバー（インスタンス）を立て、OS・ミドルウェア・アプリまで完全に制御できる最も基本的なコンピュート。数分で起動でき、停止・終了すれば課金も止まる。Auto ScalingやELBと組み合わせて高可用なWeb基盤を作るのが定番。

• インスタンスタイプ: 用途で選ぶ。M=汎用(バランス)／C=CPU重視(計算・バッチ)／R・X=メモリ重視(インメモリDB・キャッシュ)／I・D=ストレージI/O重視／G・P=GPU(機械学習・描画)／T=バースト可能(平常は低CPUで時々スパイク。CPUクレジットを貯めて消費)。世代が新しいほど高性能・低価格
• 購入オプション: オンデマンド(秒課金・最も柔軟)／RI・Savings Plans(1〜3年コミットで最大72%、全額/一部/前払いなし)／スポット(余剰枠を最大90%引きだがAWS都合で2分前通知の上中断。中断OKなバッチ向き)／Dedicated Host(物理サーバーを占有。ソケット/コア指定のBYOLライセンスやコンプライアンス要件向け)
• ストレージ: EBS=ネットワーク接続の永続ディスク(停止/終了しても残せる・スナップショット可)。インスタンスストア=物理ホスト直結で超高速だが停止・終了でデータ消失する揮発領域(キャッシュ/スクラッチ用途)
• ネットワーク/配置: ENI・セカンダリIP・Elastic IP、拡張ネットワーキング(SR-IOV)で高スループット。プレイスメントグループ＝クラスタ(同一AZに密集し低遅延・高帯域)／スプレッド(物理ハードを分けて障害を分離)／パーティション(大規模分散システム向け)
• 運用・権限: AMI(OS＋設定のテンプレート)から起動、ユーザーデータで起動時スクリプト実行。IAMロールをアタッチすると一時認証情報が自動配布されキー埋め込み不要。ステータスチェック2種(システム/インスタンス)＋自動復旧で障害対応

CPU使用率やリクエスト数などに応じてEC2インスタンスの台数を自動で増減し、コストと可用性・性能を両立させる。希望/最小/最大台数を定義し、ALBやヘルスチェックと連携して不健全なインスタンスを置き換える。

• スケーリングポリシー: ターゲット追跡(「平均CPU50%を維持」のように目標値を指定。最も簡単で推奨)／ステップ(アラームの逸脱幅に応じて増減量を段階的に変える)／シンプル(1アラームで固定数増減)／スケジュール(「平日9時に+5台」など予測可能な波に時間指定)。予測スケーリングは機械学習で先回り
• 起動テンプレート: AMI・インスタンスタイプ・SG・キーペア等の起動設定をバージョン管理。Mixed Instances Policyでスポットとオンデマンドを混在させコスト最適化
• 容量設定: 最小/希望/最大台数で範囲を定義し、複数AZ・複数サブネットに分散して可用性を確保。希望数を割ると自動補充
• ヘルスチェック: EC2(ハード障害)＋ELB(アプリ応答)。異常判定で該当インスタンスを終了→新規起動して自動入れ替え
• 暴走・誤動作の防止: クールダウン(連続スケーリングを抑制)／ウォームアップ(新インスタンスが計測に乗るまで待つ)／スケールイン保護(重要インスタンスの誤終了防止)／ライフサイクルフック(起動・終了の前後に処理を差し込む)

サーバーを管理せずにコードを実行できるサーバーレスの中核。S3アップロードやAPI Gatewayへのリクエスト、EventBridgeのスケジュールなどイベントをトリガーに起動し、実行時間とリクエスト数だけ課金される。

• 制約: 最大実行15分／メモリ128MB〜10GB(メモリに比例してCPUも増えるので、増やすと速くなりトータルで安くなることも)／/tmp最大10GB／デプロイzip 50MB・展開後250MB(超える場合はコンテナイメージ最大10GB)
• 課金: リクエスト数 × 実行時間(GB秒)。アイドル時は完全に無課金で、待機コストがほぼゼロ
• 同時実行: アカウント既定1,000(緩和申請可)。予約済み同時実行で特定関数に枠を確保し他関数の枯渇を防ぐ。急増時はバースト制限あり
• コールドスタート: 初回やスケール時に環境構築の遅延が発生。Provisioned Concurrencyで事前ウォーム、パッケージ縮小・軽量ランタイムで軽減
• 実行モデル: 同期(API Gateway)／非同期(S3・SNS。失敗時は自動リトライ＋DLQで退避)／ストリーム(SQS・DynamoDB/Kinesis Streamsをイベントソースマッピングでポーリング)。実行ロールで権限付与、VPC接続時はENI経由でプライベートリソースへ

Dockerコンテナの実行・配置・スケーリングを担うAWS独自のオーケストレーション。AWSサービスとの統合が深く、シンプルにコンテナを動かしたい場合の第一選択。

• 起動タイプ: EC2(クラスターのEC2群を自分で用意・管理。GPUやカスタムAMI、高密度配置でコスト最適化に向く)／Fargate(サーバーレスでホスト管理不要・タスク単位課金)
• 構成要素: タスク定義(コンテナ・CPU/メモリ・ボリューム・ロールを書いた設計図)→タスク(実行中の実体)→サービス(指定数を維持・ALB連携・ローリング/Blue Green更新)→クラスター(論理グループ)
• ネットワーク: awsvpcモードでタスクごとにENI(SGを直接適用)。ALB/NLBのターゲットグループに自動登録/解除
• 権限分離: タスクロール(コンテナ内アプリがAWSへアクセス)とタスク実行ロール(イメージpullやログ出力)を分ける。ECRからイメージ取得し、ログはCloudWatch Logsへ
• サービスのオートスケール(ターゲット追跡)、Service Connect/サービスディスカバリでサービス間通信

Kubernetesのコントロールプレーンをマネージドで提供。kubectl/Helmなど既存のK8sエコシステムをそのまま使え、マルチクラウドやオンプレK8sからの移植性を重視する場合に向く。

• マネージドなコントロールプレーン(APIサーバー・etcd)を複数AZで冗長化。Kubernetesと100%互換で、既存マニフェスト・kubectl・Helmがそのまま使える
• データプレーン: マネージドノードグループ(EC2を自動でプロビジョン・更新)／セルフマネージドノード／Fargate(ポッド単位サーバーレス)から選択
• AWS連携: IRSA(IAM Roles for Service Accounts)でポッド単位に最小権限を付与、AWS Load Balancer ControllerでALB/NLB連携、VPC CNIでポッドにVPCのIPを割り当て
• EKS Anywhere／EKS Distroでオンプレでも同一基盤を運用でき、マルチクラウドの移植性を最重視する場合に有利(その分ECSより運用は複雑)

ECS/EKSのコンテナを、土台のEC2を意識せずに実行できるサーバーレスエンジン。ホストのパッチ適用・スケーリング・キャパシティ管理が不要になる代わりに、EC2起動タイプよりコストは高め。

• タスク/ポッドに必要なvCPU・メモリの組み合わせを指定するだけで起動。ホストのプロビジョニング・パッチ・スケールはすべてAWSが担当
• タスクごとに専用ENIが割り当てられ独立したネットワーク(SG)で分離。インスタンスを他タスクと共有しないため分離レベルが高い
• 課金は割り当てたvCPU・メモリ × 実行時間。Fargate Spotで中断OKな処理を大幅割引
• EC2起動タイプより単価は高いが運用・パッチ対応が不要。常時稼働で密度を上げてコストを抑えたいならEC2型が有利、という使い分け

アプリのコードを渡すだけで、裏でEC2・ELB・Auto Scaling・RDS等を自動構成してデプロイ・運用してくれるPaaS。開発者はインフラ設計をせずにWebアプリを公開できる。

• 対応プラットフォーム: Java/.NET/PHP/Node.js/Python/Ruby/Go/Docker。OS・ランタイムのパッチはマネージドで、開発者の管理対象は自分のコードのみ
• 内部はCloudFormationでEC2・ELB・Auto Scaling・RDS等を自動構築。生成されたリソースには直接アクセス・カスタマイズも可能(ブラックボックスではない)
• デプロイ方式: All at once(高速だがダウンタイム)／Rolling(数台ずつ)／Rolling with additional batch(容量を維持)／Immutable(新インスタンス群を作って安全に置換)／Blue/Green(別環境を作りURL切替で即時ロールバック)
• .ebextensions で細かい構成を宣言、環境を Web 層 と Worker 層(SQSからジョブ処理)に分割できる。RDSは環境外に分離して作るのが本番の定石(環境削除でDBが消えるのを防ぐ)

小規模サイトやアプリを月額固定で手軽に立ち上げられるシンプルなVPS。コンピュート・ストレージ・転送量込みの定額で、WordPress等のブループリントが用意されている。

• コンピュート・SSDストレージ・データ転送量を含む月額固定で、コストが予測しやすい。設定項目が少なく数クリックで公開できる
• WordPress/LAMP/Node.js等のブループリント(雛形)、簡易ロードバランサー・マネージドDB・オブジェクトストレージ・コンテナも提供
• VPCピアリングで他のAWSサービスと連携可能。要件が大きくなったらEC2/RDS等の本格サービスへ移行する前提のエントリー向け

大量のバッチコンピューティングジョブを、ジョブキューとコンピュート環境で効率よく実行するマネージドサービス。ジョブ量に応じて最適なリソース（EC2/Fargate/スポット）を自動で割り当てる。

• 構成: ジョブ定義(Dockerイメージ・vCPU/メモリ・リトライ回数)→ジョブキュー(優先度付き)→コンピュート環境(EC2/Fargate/スポットを需要に応じ自動プロビジョン・スケール)
• マネージド型コンピュート環境がジョブ量に合わせてインスタンスを起動/停止し、最適なインスタンスタイプを選択。スポット併用で大幅コスト削減
• ジョブ種類: 配列ジョブ(同一処理を数千並列)／ジョブ依存関係(A完了後にB、の順序制御)。Lambdaの15分制限を超える長時間・高負荷バッチに最適
• EventBridgeのスケジュールやStep Functionsから起動してパイプライン化できる

AWSのインフラ（サーバー/ストレージ）を物理的にオンプレミスへ設置し、手元でAWS APIをそのまま使えるフルマネージドのハイブリッドソリューション。超低レイテンシーやデータ所在地（データレジデンシー）要件に対応。

• AWSが設計・配送・設置・保守までを担うフルマネージドの物理ラック/サーバーをオンプレに配置。EC2/EBS/S3 on Outposts/RDS/ECS/EKS/ALB等がローカルで動作
• 親リージョンのVPCを延伸して接続し、同じAPI・コンソール・ツールで一元管理。サービスリンク経由でコントロールプレーンと通信する(切断時はローカルは動作継続)
• 提供形態: Outposts ラック(42U・データセンター向け)／Outposts サーバー(1U・2U・小規模拠点向け)
• 用途: 工場/医療/取引など超低レイテンシーが要る処理、法規制でデータを国内/拠点内に置く必要がある場合(データレジデンシー)

HTTP経由でアクセスするオブジェクトストレージ。容量無制限・1オブジェクト最大5TB・イレブンナイン(99.999999999%)の耐久性。静的サイト、バックアップ、データレイク、ログ基盤など用途は無限。

• ストレージクラス: Standard(高頻度)／Standard-IA(低頻度・取り出し料あり・3AZ)／One Zone-IA(単一AZで安いが冗長性低)／Glacier Instant・Flexible・Deep Archive(アーカイブ)／Intelligent-Tiering(アクセス頻度を監視して自動で階層移動・取り出し料なし)。クラスごとに保存料と取り出し料・最小保存期間が異なる
• 暗号化: 現在はデフォルトでSSE-S3が自動適用。SSE-KMS(キー単位の権限・CloudTrailで利用を監査)／SSE-C(顧客が鍵を持ち込む)／クライアントサイド暗号化。バケットポリシーで非暗号化アップロードを拒否できる
• データ保護: バージョニング(上書き/削除から復元・MFA Delete)／ライフサイクル(期間経過でクラス移動・失効)／レプリケーション(CRR=別リージョン/SRR=同一リージョンへ非同期コピー)／オブジェクトロック(WORMで改ざん・削除を一定期間禁止)／イベント通知(Lambda/SQS/SNS)
• アクセス制御: IAM(誰が)＋バケットポリシー(リソース側)＋ACL(レガシー)。ブロックパブリックアクセスで意図しない公開を防止、署名付きURLで一時的な限定共有、OACでCloudFront経由のみ許可。VPCゲートウェイエンドポイントで非インターネット接続
• 性能: プレフィックスあたり3,500 PUT/5,500 GET/秒、自動でスケール。S3 Transfer Accelerationで遠距離アップロード高速化、マルチパートアップロードで大容量を分割

S3からオブジェクトを取得(GET)する際に、Lambda関数を経由してデータをその場で変換して返す仕組み。元オブジェクトは1つのまま保ち、呼び出し元やユースケースごとに異なる加工結果を返せるため、加工版の重複保存が不要になる。

• 構成: S3アクセスポイントの上にObject Lambdaアクセスポイントを作り、そこにLambdaを紐づける。アプリはそのエンドポイント経由でGETする
• 変換例: 個人情報(PII)のマスキング/削除、画像のリサイズ・ウォーターマーク、CSV↔JSON等のフォーマット変換、行フィルタリング、言語変換
• 利点: 加工済みコピーを別途保存・同期しなくてよい(単一の元データを正とする)。GET/LIST/HEADに対応

めったに使わないデータを極めて低コストで長期保管するアーカイブ専用クラス。取り出しに時間がかかる代わりに保存料が激安で、コンプライアンス由来の長期保持に最適。

• 料金の考え方: 保存料が安い代わりに取り出し料と取り出し時間がかかる。さらに各クラスに最小保存期間(IR=90日、Flexible=90日、Deep=180日)があり、早期削除すると差額を課金される
• 取り出し方法: Flexible は 迅速(1〜5分)／標準(3〜5時間)／大容量(5〜12時間)、Deep Archive は 標準(12時間)／大容量(48時間)。急ぎなら迅速、コスト重視なら大容量
• 使い方: 単独利用よりS3ライフサイクルで Standard→IA→Glacier→Deep Archive と自動移行させるのが定番。オブジェクトロックと組み合わせて法的保持(WORM)も実現
• Glacier Instant Retrieval は「ミリ秒取り出し＋低保存料」で、Standard-IAより低頻度なデータのコスト削減に向く

EC2にアタッチするブロックストレージ（仮想ディスク）。OSやDBのデータ領域に使い、スナップショットでS3に増分バックアップできる。単一AZに紐づく点が重要。

• SSD系(IOPS重視): gp3(IOPS/スループットを容量と独立して設定・コスパ良)／gp2(容量に比例してIOPS)／io2 Block Express・io1(最大数十万IOPS・ミッションクリティカルDB。Multi-Attachで同一AZの複数EC2に同時接続可)
• HDD系(スループット重視): st1(大きな順次読み書き・ログ/ビッグデータ)／sc1(アクセス頻度が低い大容量・最安)。HDDはブートボリューム不可
• スナップショット: S3に増分で保存(2回目以降は差分のみ)。別リージョン/別アカウントへコピー、AMI化、DLM(Data Lifecycle Manager)で自動取得・世代管理。復元したボリュームは初回アクセスが遅い(初期化)
• 暗号化: KMSで保管時・通信時・スナップショットまで暗号化。既存の非暗号化はスナップ→暗号化コピーで対応
• 可用性: 単一AZに紐づく(AZ障害で道連れ)。別AZ/別リージョンで使うにはスナップショット経由。容量・IOPS・タイプは稼働中に変更(Elastic Volumes)できる

複数のEC2から同時マウントできるマネージドNFSファイルシステム。容量は自動で伸縮し、複数AZにまたがって高可用。共有コンテンツやホームディレクトリ等に使う。

• NFSv4プロトコルでLinux専用(Windows共有は FSx for Windows)。各AZにマウントターゲットを作り、複数AZの多数のEC2/コンテナ/Lambdaから同時アクセス
• 容量: ペタバイト級まで自動で伸縮し、事前のサイズ指定が不要。使った分だけ課金
• ストレージクラス: Standard(複数AZ冗長)／One Zone(単一AZで安い)／各IA(低頻度で割安)。ライフサイクルで未アクセスのファイルを自動でIAへ移動しコスト削減
• 性能: パフォーマンスモード=汎用(低遅延・通常はこれ)/Max I/O(高並列・大規模)。スループットモード=バースト(容量に比例)/プロビジョンド(容量と独立して高スループットを確保)/Elastic(自動)
• 保管時/通信時の暗号化(KMS/TLS)、アクセスポイントでアプリ別のルート/権限を分離

特定プロトコル・用途に最適化されたフルマネージドファイルストレージ。4種類あり、どれを選ぶかが問われる。

• FSx for Windows File Server: SMBプロトコル＋Active Directory統合。Windowsの共有フォルダ・DFS・VSS(シャドウコピー)・ACLに対応。Multi-AZ配置で冗長化
• FSx for Lustre: HPC・機械学習・大規模分析向けの超高性能並列FS。S3とシームレス連携(S3を遅延ロード/書き戻し)。スクラッチ(高速・揮発)/永続の2タイプ
• FSx for NetApp ONTAP: NFS/SMB/iSCSIのマルチプロトコル。スナップショット・SnapMirror・重複排除/圧縮・自動階層化(低頻度を安価層へ)などNetApp機能をそのまま利用
• FSx for OpenZFS: NFSベースのLinux向け高性能FS。スナップショット・圧縮、低レイテンシーが必要なワークロード向け

オンプレのアプリからAWSストレージ（S3/EBS/Glacier）へシームレスにアクセスするハイブリッド接続。ローカルキャッシュで低レイテンシーを保ちつつ、実体はクラウドに置く。

• File Gateway: オンプレからNFS/SMBでマウントし、実体はS3オブジェクトとして保存(最頻出)。よく使うデータはローカルキャッシュで低遅延、S3のライフサイクルでGlacierへ移行も可
• Volume Gateway: iSCSIブロックを提供しEBSスナップショットとしてバックアップ。Cached(プライマリはS3・キャッシュのみローカル＝低コスト)／Stored(全データをローカル保持し非同期でS3へ＝低遅延)
• Tape Gateway: 仮想テープライブラリ(VTL)として既存バックアップソフトに見せ、テープをS3/Glacierに保存。物理テープ運用の置き換え
• 共通: オンプレに仮想アプライアンス(またはハードウェアアプライアンス)を設置し、ローカルキャッシュで低レイテンシーを保ちつつ実体をクラウドに置く

ネットワーク転送では時間がかかりすぎる大量データを、物理デバイスで運搬してAWSへ移行するサービス群。一部はエッジでの簡易処理にも対応。

• Snowcone: 8TB(HDD)/14TB(SSD)・手のひらサイズで持ち運び/IoT現場向け。Snowball Edge: 約80TB。Storage Optimized(移行向け)とCompute Optimized(EC2/Lambda/GPUでエッジ処理)の2系統
• Snowmobile: 最大100PB。コンテナトラックで運ぶデータセンター級の超大容量移行
• 流れ: コンソールで注文→デバイス到着→ローカルでデータ書き込み→返送→AWSがS3へ取り込み。電子インク配送ラベルで返送先自動切替
• 転送データはKMSで暗号化、改ざん検知(TPM)。判断目安: 回線速度とデータ量から転送日数を見積もり、ネット転送が週単位でかかるならSnowを検討(オンライン同期ならDataSync)

EC2/EBS/RDS/Aurora/DynamoDB/EFS/FSx/Storage Gateway等のバックアップを、1つのポリシーで集中管理するサービス。スケジュール・保持期間・コピーをルール化する。

• バックアッププラン: スケジュール(頻度)・保持期間・コールド層への移行・コピー先をポリシーとして定義し、タグ単位で対象リソースを自動選択(リソース・アサインメント)
• 範囲: クロスリージョン/クロスアカウントのコピーでDR・隔離保管。連続バックアップとポイントインタイムリストア(対応サービス)で任意時点に復元
• 改ざん対策: Vault Lock(WORM)で保持期間中の削除・短縮を不可能にし、ランサムウェア/誤削除に耐える。バックアップは暗号化(KMS)
• 統制: Organizations統合で全アカウントに統一ポリシーを強制、Backup Auditでコンプライアンス監査。手動の個別スナップショット運用を一元化できるのが価値

オンプレのNFS/SMBサーバーやオブジェクトストアから、S3/EFS/FSxへ高速かつ自動でデータをコピー・同期するサービス。一括移行にも定期同期にも使える。

• 専用プロトコルで最大10Gbpsの高スループット転送＋転送後に自動で整合性チェック(チェックサム検証)。帯域制限・ファイルフィルタ・上書き/削除の制御も可能
• エージェント: オンプレにDataSyncエージェント(VM)を設置してNFS/SMB/HDFS/オブジェクトストアを読み取り、S3/EFS/FSxへ転送。AWS内サービス間の転送はエージェント不要
• スケジュール: 一括の初回移行に加え、定期実行で差分のみ同期(変更分だけ転送するので継続同期が速い)
• 用途は移行・定期バックアップ・クロスリージョン/他クラウド転送。常時マウントしてリアルタイムに使うのはStorage Gateway、という棲み分け

SFTP/FTPS/FTP/AS2でのファイル転送を、サーバーを立てずにS3/EFSへ直結させるフルマネージドサービス。既存の取引先のやり方を変えずにクラウドへ移行できる。

• プロトコル: SFTP/FTPS/FTP/AS2(企業間EDI)。既存のSFTPクライアントやスクリプトを変更せずにエンドポイントだけAWSへ向ける
• 保存先: S3 または EFS。届いたファイルはそのままデータレイクやETLの入力にできる
• 認証: サービス管理(SSH鍵)／Active Directory／カスタムIdP(Lambda/API Gatewayで独自認証)。ユーザーごとにホームディレクトリ・アクセス範囲を制限
• サーバーの構築・パッチ・スケーリング・冗長化が不要(フルマネージド)。エンドポイントは公開/VPC内(プライベート)を選択可、固定IPも付与できる

オンプレや他クラウドのサーバーをブロックレベルで継続レプリケートし、災害時に数分でEC2として起動する低コストDR（旧CloudEndure DR）。平常時は安価な待機状態で保つ。

• 各サーバーにエージェントを入れ、ブロックレベルで継続レプリケーション。RPOは数秒、RTOは数分(起動するだけ)
• コスト構造: 平常時は低スペックなステージング領域(安いEBS＋最小コンピュート)だけを稼働させ、災害時に本番スペックのEC2へ自動変換して起動。常時フル稼働のスタンバイより大幅に安い(パイロットライト/ウォームスタンバイ的)
• 非破壊テスト: 本番に影響を与えずにDR起動の訓練(リハーサル)ができ、RTO/RPOを検証できる
• フェイルバック: 復旧後に元の環境(オンプレ/他リージョン)へ戻す。対応元は物理/仮想/各種クラウドと広い。兄弟のMGNは「移行」、DRSは「災害復旧(常時待機)」

オンプレや他クラウドのサーバーを、中身ほぼそのまま（リホスト＝リフト&シフト）AWSのEC2へ移行する主力サービス（旧CloudEndure Migration）。最も手間の少ない移行方式。

• サーバーにエージェントを入れてブロックレベルで継続レプリケート→準備が整ったら最小ダウンタイムでEC2へカットオーバー。OS・アプリ・設定をそのまま持ち込む(リホスト)
• テスト起動: 本番切替の前に隔離環境でテストインスタンスを起動して動作確認でき、切替の失敗リスクを下げる
• 移行戦略の位置づけ: 7RのうちRehost(リフト&シフト)を担う。アプリ改修を伴うRefactor/Replatformとは別。大量サーバーの一括移行を自動化・高速化
• 移行先のサブネット・インスタンスタイプ・ライセンス(BYOL)を指定可。複数サーバーをまとめて波状移行(ウェーブ)できる

複数の移行ツール（MGN/DMS等）を使った移行プロジェクトの進捗を、1か所のダッシュボードで横断的に追跡・可視化するサービス。大規模移行の司令塔。

• MGN/DMSなど複数の移行ツールのステータスを1つのダッシュボードに集約し、どのサーバー/アプリがどの段階(未着手/進行中/完了)かを横断的に可視化
• Application Discovery Service: オンプレのサーバー構成・使用率・サーバー間の依存関係を収集(エージェント型/エージェントレス)。どれを一緒に移行すべきか計画できる
• 移行をアプリケーション単位でグルーピングして進捗管理、Migration Hub Strategy Recommendationsで移行方式を提案
• 大規模・複数フェーズの移行で「全体像と進捗」を管理する司令塔。実際の移行作業はMGN/DMS等が担う

AWSへの移行を計画するために、オンプレミスのサーバー構成・パフォーマンス・サーバー間の依存関係を自動収集するサービス。何をどの順で・どれと一緒に移行するかを根拠を持って決められる。

• 2つの収集方式: エージェントレス(VMware vCenterにコネクタを置き仮想マシンを一括把握)／エージェント型(各サーバーに導入し、プロセスやネットワーク接続まで詳細収集)
• 収集内容: ホスト構成・CPU/メモリ/ディスク使用率・稼働プロセス・サーバー間のネットワーク接続(依存関係)
• 連携: 収集データはMigration Hubに集約して可視化・移行グルーピング。S3へエクスポートしAthena/QuickSightで分析も

物理/仮想/EC2/オンプレで稼働中のJava・.NETアプリケーションを、コード変更なしでコンテナ化するCLIツール。コンテナイメージとECS/EKS等へのデプロイ成果物を自動生成し、コンテナ化によるモダナイズ(リプラットフォーム)を加速する。

• 分析→変換: 稼働中アプリを解析(依存関係・構成を検出)し、Dockerfile＆コンテナイメージを生成
• デプロイ成果物: ECS/EKSのタスク定義・Kubernetesマニフェスト・CloudFormationテンプレートを出力、ECRへ登録、CI/CD(CodePipeline)へ組み込み
• 対象: Linux上のJava、Windows上の.NET(.NET Framework/.NET Core)。アプリ本体をそのまま箱詰め

オンプレミス環境を分析し、AWSへ移行した場合のコスト(TCO)と削減効果を試算して、移行の意思決定に使うビジネスケース(投資対効果)を作成するサービス。旧TSO Logic。移行そのものではなく「移行すべきか・いくら得か」の判断を支援する。

• データ収集: エージェントレスコレクター等でサーバーの使用状況・ライセンス・インベントリを収集
• 試算: 現行コストとAWS移行後の想定コストを比較し、最適なインスタンス選定・削減額をモデル化
• 成果物: 経営層向けの移行ビジネスケース(コスト比較レポート)。移行を始める前の企画フェーズで使う

MySQL/PostgreSQL/MariaDB/Oracle/SQL Serverに対応したマネージドRDB。パッチ適用・バックアップ・レプリケーションをAWSが管理し、運用負荷を大きく下げる。

• Multi-AZ: 別AZのスタンバイに同期レプリケーションし、障害時に自動フェイルオーバー(DNSが新マスターを指す)。スタンバイは読み取りに使えない(可用性専用)。Multi-AZ DBクラスターなら読み取り可能なスタンバイ2台
• リードレプリカ: 非同期レプリケーションの読み取り専用コピーを最大5台(別リージョン/別AZ可)。読み取り負荷を分散し、手動昇格で独立DB化も可能。レプリケーション遅延に注意
• バックアップ: 自動バックアップ(保持最大35日・ポイントインタイムリストア対応)＋手動スナップショット(無期限・別リージョン/別アカウントへコピー可)。復元は常に新インスタンスとして作成される
• 運用: パッチ・マイナーバージョンアップはメンテナンスウィンドウで自動、ストレージはgp3/io1、ストレージオートスケーリングで自動拡張
• セキュリティ: サブネットグループでVPC内に配置、SGで接続制御、保管時(KMS)・通信時(TLS)暗号化、IAMデータベース認証。RDS Proxyで接続プールしてLambda等の大量接続を捌く

RDS/Auroraへのデータベース接続をプールして共有するフルマネージドなプロキシ。大量かつ短命な接続(特にLambda)によるDBの接続枯渇やオーバーヘッドを防ぎ、フェイルオーバーも高速化する。

• コネクションプーリング: 確立済みのDB接続をプールで再利用し、DB側の接続数・メモリ消費を抑える。急な接続スパイクを吸収
• サーバーレスとの相性: Lambdaは実行のたびに接続を張りがちで枯渇しやすい。RDS Proxyを挟むと安定する
• 可用性・セキュリティ: フェイルオーバー時にプロキシが再接続を肩代わりしダウンタイムを最大66%短縮。認証はSecrets Manager/IAM、通信はTLS。VPC内に配置

MySQL/PostgreSQL互換のままスループット・可用性・自動拡張を底上げしたAWS独自開発のRDB。ストレージは自動で3AZに6コピー、最大128TBまで自動拡張。

• ストレージ構造: コンピュートとストレージが分離。データを自動で3AZ×2=6コピー保持し、10GB単位で最大128TBまで自動拡張。自己修復・バックアップはS3へ継続(性能影響なし)
• 性能/可用性: MySQL比5倍/PostgreSQL比3倍。リードレプリカ最大15台で、すべてが同じストレージを共有→レプリケーション遅延が小さくフェイルオーバーも速い(クラスターエンドポイント=書込/リーダーエンドポイント=読込)
• Aurora Serverless v2: 負荷に応じてACU単位でシームレスに自動スケール。断続的・予測不能なワークロードでコスト最適
• Global Database: プライマリから別リージョンへ1秒未満で複製(最大5セカンダリ)。リージョン障害時に約1分で昇格、低遅延のグローバル読み取り
• その他: バックトラック(MySQL・物理コピーなしで過去へ巻き戻し)、クローン(高速・低コスト複製)、Database Activity Streamsで監査。RDSと同じくMulti-AZ・自動バックアップ対応

Auroraクラスターを複数リージョンにまたがって構成し、プライマリリージョンからセカンダリへストレージレベルで高速レプリケーションする機能。地域規模の災害への備え(DR)と、各リージョンでの低遅延な読み取りを同時に実現する。

• 構成: 1つのプライマリ＋最大5つのセカンダリリージョン。セカンダリは読み取り専用で、各地のユーザーに低遅延配信
• レプリケーション: 専用のレプリケーションインフラで通常1秒未満の遅延、DB本体に負荷をかけない。標準でRPO約1秒
• フェイルオーバー: リージョン障害時にセカンダリを昇格(マネージドな計画外フェイルオーバーでRTO約1分)。書き込みフォワーディングでセカンダリ経由の書き込みも可能

キーを指定すると1桁ミリ秒で値が返る、容量無制限のフルマネージドNoSQL（キーバリュー/ドキュメント）。サーバーレスでキャパシティ管理も不要。

• データモデル: パーティションキー(＋ソートキー)で分散。GSI/LSI(セカンダリインデックス)で別キーの検索を可能にする。スキーマレスだが、アクセスパターンを先に設計するのが鉄則
• キャパシティ: オンデマンド(自動・予測不能な負荷)／プロビジョンド(RCU/WCUを指定・Auto Scalingで増減)。ホットパーティションに注意
• DAX: DynamoDB専用のインメモリキャッシュで読み取りをミリ秒→マイクロ秒に。読み取り集中ワークロード向け(ElastiCacheより統合が簡単)
• グローバルテーブル: 複数リージョンでアクティブ-アクティブレプリケーション。各地で低遅延の読み書き、リージョン障害にも強い
• 連携・保護: Streams(項目変更をLambdaやKinesisへ流す→イベント駆動)、TTLで期限切れ項目を自動削除、トランザクション(ACID)、PITR(35日)＋オンデマンドバックアップ、保管時暗号化(標準)

Redis/Memcachedのフルマネージドなインメモリキャッシュ。DBの読み取り負荷軽減、セッション管理、リアルタイムランキングなどに使う。

• Redis: レプリケーション＋自動フェイルオーバー(Multi-AZ)で高可用、スナップショットで永続化、Pub/Sub・ソート済みセット(ランキング)・地理空間など高機能。クラスターモードで水平分割(シャーディング)
• Memcached: マルチスレッドでシンプル・高速、ノード追加で水平スケール。永続化・レプリケーション・フェイルオーバーは無く、純粋な一時キャッシュ向け
• キャッシュ戦略: 遅延読み込み(Lazy Loading＝ミスしたらDBから取得して格納)／ライトスルー(書き込み時にキャッシュも更新)。TTLで古いデータを失効させ整合性を保つ
• 典型用途: DBの読み取り負荷軽減(前段キャッシュ)、セッションストア、レート制限カウンタ、リアルタイムランキング

ペタバイト級のデータウェアハウス。列指向ストレージでSQL分析クエリ(OLAP)が高速。BIダッシュボードや定常的な集計レポートの基盤。

• アーキテクチャ: リーダーノード(クエリ調整)＋複数コンピュートノードのMPP(超並列処理)。列指向＋圧縮で分析クエリのスキャン量を削減、ゾーンマップで不要ブロックを読み飛ばす
• Spectrum: S3のデータをロードせず直接SQLクエリし、クラスター内のデータと結合できる(データレイク連携)
• Serverless: クラスター管理なしで使った分だけ課金、断続的な分析に向く
• 性能/設計: 分散キー(JOIN先と揃える)・ソートキーの設計が効く。同時実行スケーリングでクエリ集中時に一時的にキャパシティ追加、マテリアライズドビューやResult Cacheで高速化
• 連携: S3へUNLOAD/COPY、Auroraからのゼロ ETL統合、データ共有で別クラスターへ共有。OLTPはRDS/Aurora、定常的な大規模分析がRedshift

ノード間の関係性を効率的に格納・探索するフルマネージドのグラフDB。ソーシャルグラフ、推薦、ナレッジグラフ、不正検出に向く。

• 2つのモデル: Property Graph(Apache TinkerPop / Gremlin・openCypher)と RDF(W3C標準 / SPARQL)。「友達の友達」「同時購入」「経路探索」のような関係の多段たどりが、リレーショナルのJOIN連鎖より高速
• 可用性: ストレージは3AZに6コピー、リードレプリカ最大15台＋自動フェイルオーバー(Multi-AZ)、ポイントインタイムリストア
• 用途: ソーシャルグラフ、レコメンド、ナレッジグラフ、不正検出(関連口座の探索)、ネットワーク/IT資産の依存関係。Neptune Serverlessで自動スケールも可能

MongoDB互換のフルマネージドなドキュメント(JSON)DB。柔軟なスキーマのデータを格納でき、MongoDBからの移行先として使う。

• MongoDB API互換で既存のドライバ・ツールがそのまま使える。JSONドキュメントを格納し、柔軟なスキーマ・インデックス・アドホッククエリに対応
• アーキテクチャ: Aurora同様にコンピュートとストレージを分離し、ストレージは自動で3AZに6コピー・自動拡張。リードレプリカ最大15台＋自動フェイルオーバー
• 保管時(KMS)/通信時(TLS)暗号化、自動バックアップ＋PITR。自前でMongoDBを運用する代わりにフルマネージドで使う移行先

すべての変更履歴がイミュータブル(変更不可)に記録され、暗号的に検証できる台帳(Ledger)DB。監査やコンプライアンス用途に向く。

• 仕組み: すべての変更は追記専用のジャーナルに順序付きで記録され、後から書き換え・削除できない(イミュータブル)。各エントリはSHA-256ハッシュで連結され、ダイジェストを使って改ざんが無いことを暗号的に検証(証明)できる
• SQLライクなPartiQLで操作、現在の状態と全履歴の両方を参照できる
• ブロックチェーンとの違い: QLDBは信頼できる中央(単一所有者)の台帳で高速・運用簡単。複数の当事者が分散合意で共有台帳を持つ用途はManaged Blockchain
• 用途: 金融取引履歴、サプライチェーン来歴、保険の請求履歴、システムの変更監査など「改ざんされていない証明」が要る記録

Apache Cassandra互換のフルマネージドDB。既存のCassandraアプリをコード変更なしで移行でき、サーバーレスで容量自動拡張。

• CQL(Cassandra Query Language)互換で、既存のCassandraドライバ・ツールをそのまま利用。サーバーレスでノード/クラスター管理が不要、テーブル単位で自動スケール
• キャパシティはオンデマンド/プロビジョンド(Auto Scaling)、データは複数AZに3重複製、PITR・暗号化対応
• 用途: 大規模な時系列/IoT/書き込み多めのワークロード、Cassandra運用から解放されたい移行先。マネージドで容量無制限にスケール

データベースをほぼ無停止でAWSへ移行するマネージドサービス。同種(Oracle→Oracle)も異種(Oracle→Aurora)も対応し、移行元を稼働させたまま継続レプリケートする。

• 構成: レプリケーションインスタンス(EC2)＋ソース/ターゲットのエンドポイントを定義し、移行タスクを実行。フルロード→CDC(変更データキャプチャ)で移行中の更新も追従し、切替直前まで同期してダウンタイムを最小化
• 移行タイプ: 既存データのみ／既存＋継続レプリケーション／継続レプリケーションのみ。継続を残せばクロスリージョン複製や常時同期にも使える
• 同種/異種: 同種(Oracle→Oracle)はそのまま。異種(Oracle→Aurora等)はSCTでスキーマ・ストアドプロシージャを自動変換(手動修正が要る箇所はレポート)
• ターゲットの広さ: RDS/Aurora/Redshift/DynamoDB/S3/Kinesis/OpenSearch等。DBだけでなくデータレイクやストリームへの取り込みにも使える
• 事前にApplication Discovery/SCTで評価。DMS=DBの移行、DataSync=ファイル、MGN=サーバー丸ごと、の役割分担

AWS内に論理的に分離された仮想ネットワークを構築する、全リソースの土台。サブネット分割・ルーティング・アクセス制御を自分で設計する。

• 構成要素: CIDRブロック(例 10.0.0.0/16)→サブネット(AZごとに切る)→ルートテーブルで経路を定義。パブリックサブネット=ルートに0.0.0.0/0→IGW、プライベート=外向きはNAT Gateway経由
• NACL(ネットワークACL): サブネット単位・ステートレス(戻りの通信も明示的に許可が必要)・番号の小さい順に評価し許可/拒否の両方を書ける。サブネット全体のブロックに向く
• セキュリティグループ: ENI(インスタンス)単位・ステートフル(許可した通信の戻りは自動許可)・許可ルールのみ。送信元に別のSGを指定でき、ティア間通信を柔軟に制御
• 接続オプション: VPCピアリング(1対1・推移不可)／Transit Gateway(多対多ハブ)／VPCエンドポイント(AWSサービスへプライベート)／IGW・NAT・VPN・Direct Connect
• 可視化/設計: VPCフローログでトラフィックを記録(Athena/CloudWatchで分析)。サブネットは複数AZに分けてマルチAZ可用性を確保するのが基本

VPC内からAWSサービスへ、インターネットを経由せずプライベートに接続する仕組み。セキュリティとパフォーマンスの両方が向上する。

• ゲートウェイ型: S3/DynamoDB専用。無料。ルートテーブルにエントリを追加する方式で、エンドポイントポリシーでアクセスを絞れる。リージョン内のみ
• インターフェース型(PrivateLink): その他の多数のサービス用。サブネットにENI＋プライベートDNSを作り、通常のサービス名でプライベート到達。時間課金＋データ処理課金(有料)
• どちらもトラフィックがAWS内部に閉じるため、IGW/NAT/インターネットが不要になりセキュリティ・コストの両面で有利
• 自社や他社のサービスを公開/利用するインターフェース型はPrivateLink(NLB＋エンドポイントサービス)として使える

VPCをインターネットに接続する出入口。パブリックサブネットのリソースが双方向(インバウンド/アウトバウンド)で外部と通信できるようにする。

• VPCに1つだけアタッチする水平スケール・冗長・高可用なコンポーネント(帯域上限や単一障害点が無い)
• パブリックサブネットのルートテーブルに 0.0.0.0/0 → IGW を追加して初めて外部疎通する
• 通信するリソースにパブリックIP または Elastic IPが必要(プライベートIPだけでは外に出られない)。IGWがNAT的にグローバルIPへ変換
• IPv6では egress-only インターネットゲートウェイで「外向きのみ」を実現(IPv4のNAT Gatewayに相当)

プライベートサブネットのリソースが、インターネットへ外向き(アウトバウンド)通信だけできるようにするマネージドサービス。外部からの接続開始は受け付けない。

• 配置: NAT Gateway自体はパブリックサブネットに置きElastic IPを持つ。プライベート機器の戻りを受けるためIGWへの経路が必要
• 経路: プライベートサブネットのルートに 0.0.0.0/0 → NAT Gateway。プライベート→NAT→IGW→インターネットの順で外向き通信、応答は同じ経路で戻る(外からの新規接続は不可)
• マネージド性: AWS管理で自動スケール(最大100Gbps)・高可用(AZ内で冗長)。AZ単位なので、AZ障害に備えるなら各AZにNAT Gatewayを置き各サブネットのルートを自AZのNATに向ける
• NATインスタンスとの違い: 旧式のNATインスタンス(EC2)は自前で可用性・スケール・パッチ管理が必要で、送信元/宛先チェックの無効化も要る。試験では「NAT Gatewayへ移行」が正解

受信トラフィックを複数のターゲット(EC2/コンテナ/Lambda/IP)へ自動分散し、高可用性とスケーラビリティを支える。ヘルスチェックで異常を除外する。

• ALB(L7): HTTP/HTTPSをパス・ホスト・ヘッダ・クエリで振り分け。ターゲットはEC2/IP/Lambda/コンテナ。WebSocket・HTTP/2、Cognito/OIDC認証、WAF連携、SNI複数証明書。スティッキーセッション対応
• NLB(L4): TCP/UDP/TLSを超低遅延・毎秒数百万リクエストで処理。静的IP/Elastic IPを持てる(ファイアウォール許可リスト向き)、送信元IP保持、PrivateLinkの提供基盤
• GWLB(L3): サードパーティの仮想アプライアンス(FW/IDS/IPS)へGENEVEでトラフィックを透過的に流し、検査用に一括スケール
• 共通機能: 複数AZのターゲットへ分散、ヘルスチェックで不健全を除外、クロスゾーン負荷分散、ACM証明書でTLS終端。Auto Scaling＋ALBが定番の高可用Web構成

世界中のエッジロケーションからコンテンツを配信するCDN。静的/動的の高速化、DDoS保護(Shield統合)、S3オリジンの保護(OAC)を提供する。

• 仕組み: 世界中のエッジロケーションにコンテンツをキャッシュし、ユーザー最寄りから配信。オリジン(S3/ALB/EC2/任意のHTTP)から取得し、TTLでキャッシュ。キャッシュヒットでオリジン負荷と遅延を削減
• オリジン保護: OAC(Origin Access Control)でS3を非公開にしCloudFront経由のみ許可。オリジンフェイルオーバーで冗長化
• エッジ処理: CloudFront Functions(超軽量・ヘッダ操作/リダイレクト)とLambda@Edge(重い処理・オリジン要求の加工)でリクエスト/レスポンスをカスタマイズ
• セキュリティ: 署名付きURL/Cookieで限定配信、地理制限、WAF連携、ACM証明書はus-east-1で作成。Shieldと合わせてDDoS耐性
• 動的コンテンツの高速化や、TCP/UDP最適化が要件ならGlobal Acceleratorと使い分け

高可用なマネージドDNS。ドメイン登録・DNSルーティング・ヘルスチェックを提供し、DR構成のフェイルオーバーに不可欠。

• ルーティングポリシー: シンプル／加重(比率分散・カナリア/B&Gに)／レイテンシー(最速リージョンへ)／フェイルオーバー(プライマリ障害でセカンダリへ)／地理的位置(国/地域別)／地理的近接(リソースへの距離＋バイアス)／マルチバリュー(複数の健全IPを返す簡易LB)
• ヘルスチェック: エンドポイントの死活・他チェックの集約・CloudWatchアラーム連動。異常なレコードを応答から外しフェイルオーバーを実現
• エイリアスレコード: ELB/CloudFront/S3/API Gateway等のAWSリソースをゾーン頂点(example.com)で指せて無料。CNAMEと違いルートドメインにも使える
• パブリック/プライベートホストゾーン、ドメイン登録、DNSSEC、Resolver(オンプレ⇔VPCの名前解決)。アクティブ-パッシブ/アクティブ-アクティブDRの要

VPCとオンプレミス間でDNSの名前解決を相互に行うためのハイブリッドDNS。VPC内に標準で存在するリゾルバー(サブネットの.2)を拡張し、エンドポイントを介してオンプレとAWSの双方向で名前解決できるようにする。

• インバウンドエンドポイント: オンプレのDNSサーバーから、VPC内やRoute 53プライベートホストゾーンの名前を問い合わせられるようにする(オンプレ→AWS方向)
• アウトバウンドエンドポイント: VPC内のリソースから、オンプレのDNSサーバーへ名前解決を転送する(AWS→オンプレ方向)
• Forward(転送)ルール: 「example.internal はオンプレDNSへ」のようにドメイン条件で転送先を指定。DX/VPN経由でオンプレDNSに到達

REST/HTTP/WebSocket APIを作成・公開・管理するフルマネージドサービス。Lambdaと組み合わせてサーバーレスAPIを構築する定番。

• API種類: REST API(機能豊富・APIキー/使用量プラン/リクエスト検証)／HTTP API(低コスト・低遅延・シンプル)／WebSocket API(双方向リアルタイム)
• 保護/性能: スロットリング(レート/バースト制限)、レスポンスキャッシュ(オリジン負荷軽減)、リクエスト検証、CORS、WAF連携
• 認証: IAM(SigV4)／Cognito User Pool／Lambdaオーソライザー(独自トークン検証)／APIキー(利用量管理)
• 統合先: Lambda(サーバーレス定番)／HTTP/任意バックエンド／AWSサービス直結。ステージ(dev/prod)・カナリアデプロイ・ステージ変数でバージョン管理。プライベートAPI(VPCエンドポイント)も可

オンプレとAWSを専用線で接続し、インターネットを経由しない一貫した帯域と低レイテンシーを実現する。開通に数週間〜数ヶ月かかる。

• 接続形態: 専用接続(1/10/100Gbps・物理ポート占有)／ホスト接続(パートナー経由で50Mbps〜)。DXロケーションでAWSと相互接続し、開通に数週間〜数ヶ月
• 仮想インターフェース(VIF): プライベートVIF(VPCへ)／パブリックVIF(S3等のパブリックサービスへ)／トランジットVIF(Transit Gateway経由で多数VPC)
• 暗号化: 専用線自体はインターネットを通らないがデフォルト暗号化なし。要件があればIPsec VPNを重ねる(またはMACsec)
• 冗長化: 単一DXは単一障害点。DX×2(別ロケーション)で高可用、またはDX＋VPNバックアップで安価に冗長化。安定帯域はDX、即時/安価/バックアップはVPN

インターネット経由で暗号化トンネルを張り、オンプレやリモートユーザーとVPCを安全に接続する。Direct Connectより安価で即座に使える。

• Site-to-Site VPN: オンプレのカスタマーゲートウェイ ⇔ AWSのVGW(またはTGW)をIPsecトンネルで接続。各接続は冗長な2トンネル、静的ルート or BGP(動的)。インターネット経由のため帯域・遅延はベストエフォート
• Client VPN: リモートユーザーのPC/スマホ ⇔ VPC(OpenVPNベース)。証明書/AD/SAMLで認証し、在宅勤務のアクセスに
• 用途: Direct Connect開通までの暫定、DXのバックアップ(DX＋VPN)、小規模/即時のハイブリッド。DX上にVPNを重ねて暗号化することも

多数のVPCとオンプレをハブ&スポーク型で中央接続する。VPCピアリングの1対1では管理しきれない大規模ネットワークを一元化する。

• ハブ&スポーク: 各VPC/VPN/Direct Connectを「アタッチメント」としてTGWに1本ずつ接続するだけで相互接続。VPCピアリングのフルメッシュ(N×Nの管理地獄)を解消
• 推移的ルーティング: ピアリングは A⇔B⇔C でも A→C 不可だが、TGWは中継できる。TGWルートテーブルで「どのアタッチメント同士を通すか」を制御し、セグメント分離(本番/開発を遮断)も可能
• 数千VPC＋オンプレをリージョン内で集約、TGWピアリングでリージョン間も接続。Network Managerで全体を可視化
• 規模が小さい(2〜3VPC)ならVPCピアリングで十分。多数・将来拡張・オンプレ集約ならTGW

自社サービス(NLBの裏)を、他のVPCやアカウントへインターネットを経由せずプライベートに公開する。ピアリングと違い一方向・特定サービスのみ。

• 提供側: サービスをNLB(またはGWLB)の裏に置き、エンドポイントサービスとして公開。許可した利用者だけが接続できる
• 利用側: 自VPCにインターフェースVPCエンドポイント(ENI)を作り、プライベートIPでサービスへ到達。トラフィックはインターネットに出ない
• VPCピアリングとの違い: ピアリングは双方向で全リソースが見えるが、PrivateLinkは公開した1サービスだけ・一方向。CIDRが重複していても接続でき、攻撃面が小さい
• 用途: SaaS型の社内/社外向けサービス提供、アカウント横断のマイクロサービス公開、AWSサービスへのプライベート接続(インターフェース型エンドポイントの実体)

ユーザーのトラフィックを最寄りエッジからAWSのバックボーンに乗せ、最適なリージョンへ最短経路で届ける。固定Anycast IPを2つ付与する。

• 仕組み: 2つの固定Anycast IPを入口に、ユーザーを最寄りエッジからAWSのバックボーンに載せて最適リージョンのエンドポイント(ALB/NLB/EC2/EIP)へ。公衆インターネットの不安定区間を避け、遅延・ジッタ・パケットロスを改善
• キャッシュしない: CloudFrontと違いコンテンツを保持せず、TCP/UDP全般のネットワーク経路最適化(HTTPに限らない)。ゲーム/IoT/VoIP/金融など非HTTPや動的トラフィックに有効
• フェイルオーバー: エンドポイントのヘルスチェックで異常リージョンを即座に外す。IPは固定なのでDNS伝播を待たずに切替、トラフィックダイヤルで加重・段階移行
• 固定IPでファイアウォール許可リストにも向く。キャッシュ配信ならCloudFront、経路最適化ならGlobal Accelerator

「誰が・何に・何をできるか」を制御する認証認可サービス。ユーザー/グループ/ロール/ポリシーで全AWSのアクセスを管理する全セキュリティの土台。

• 構成要素: ユーザー(人)／グループ(ユーザーの束)／ロール(AWSサービスや一時的な引き受け先に付与・キー不要)／ポリシー(JSONで許可・拒否を定義)。EC2/Lambdaには必ずロールで権限を渡す
• ポリシーの種類: アイデンティティベース(誰に)／リソースベース(S3バケット等に直接)／SCP(組織の上限)／パーミッションバウンダリー(個人の上限)／セッションポリシー。すべてのポリシーを統合して評価
• 評価順: デフォルト拒否 → いずれかの明示的拒否があれば拒否(最優先) → 明示的許可があれば許可
• 原則: ルートユーザーは封印しMFA、最小権限、ロールの一時認証情報(STS)を使う。クロスアカウントは信頼ポリシー＋AssumeRole
• IAM Access Analyzerで外部公開を検出、認証情報レポート/Access Advisorで棚卸し、ポリシーは条件(Condition)でIP・MFA・タグ等を絞れる

複数のポリシーが重なった時に「結局できるか」を決める判定順序。明示的拒否が最優先という原則が肝。SCPは組織全体の権限上限を定める。

• 評価フロー: ①暗黙の拒否(デフォルト)→②適用される全ポリシーに明示的拒否があれば即拒否→③明示的許可があれば許可→無ければ拒否。拒否は常に許可に勝つ
• SCP: Organizations/OU/アカウントに適用する権限のガードレール(上限)。許可を“付与”するのではなく、IAMで許可されていてもSCPの範囲外はできない。管理アカウントには効かない点に注意
• パーミッションバウンダリー: 個々のIAMユーザー/ロールが持てる最大権限を制限。「開発者が自分でロールを作れるが、与えられる権限の上限は超えられない」を実現
• 重なり順: 実効権限 = アイデンティティ許可 ∩ パーミッションバウンダリー ∩ SCP（さらにリソースポリシーやセッションポリシーを加味）。どこか一つでも拒否/範囲外なら不可

有効期限付きの一時的なセキュリティ認証情報を発行するサービス。長期アクセスキーより安全で、クロスアカウントやフェデレーションの基盤になる。

• AssumeRole: 信頼関係のある別ロールを引き受け、有効期限付き(15分〜最大12時間)の一時キー(アクセスキー＋シークレット＋セッショントークン)を取得。クロスアカウントアクセスの基本
• フェデレーション: AssumeRoleWithSAML(社内AD/IdP)／AssumeRoleWithWebIdentity(Cognito・Google等のOIDC)で外部IDからAWSへ。社内ユーザーにIAMユーザーを作らず一時権限を配れる
• 長期アクセスキーは漏洩リスクが高く非推奨。EC2/Lambdaのロールやフェデレーションで常に一時認証情報を使うのが定石。GetSessionTokenでMFA必須化も可能

オンプレミスのサーバー・他クラウド・コンテナなどAWSの外で動くワークロードに、X.509証明書を使ってIAMロールの一時認証情報を取得させるサービス。従来はIAMユーザーの長期アクセスキーを配って実現していたハイブリッドのアクセスを、キーレスで安全にする。

• 信頼アンカー: 自社のプライベートCAやACM Private CAを登録し、そのCAが発行した証明書を持つワークロードを信頼
• プロファイル＋ロール: どのIAMロールを引き受けられるかを定義。ワークロードは証明書で署名したリクエストを送る
• 認証フロー: 証明書で認証 → IAM Roles Anywhereが検証 → STSの一時認証情報(有効期限付き)を返す → AWSへアクセス
• 長期アクセスキーをサーバーに置かないため漏洩・ローテーション負荷を排除。証明書を失効させれば即時にアクセスを無効化

暗号化キーの作成・管理・ローテーションを行い、S3/EBS/RDS等のAWSサービスと統合してデータ暗号化を一元化する。誰がキーを使ったかをCloudTrailで追跡できる。

• キー種別: カスタマー管理キー(CMK・ポリシー/ローテーション/削除を自分で制御)／AWS管理キー(サービスが自動管理)／AWS所有キー。対称/非対称、HSMで保護され鍵自体は外部に出ない
• エンベロープ暗号化: データはデータキーで暗号化し、そのデータキーをKMSのマスターキーで暗号化。GenerateDataKey/Decryptで大容量も効率的に
• 統合: S3(SSE-KMS)・EBS・RDS・Secrets Manager等と統合。CloudTrailにキー使用が記録され「誰がいつ復号したか」を監査。キーポリシー＋IAMで二重に権限制御、グラントで一時委譲
• カスタマー管理キーは年1回の自動ローテーション(古い鍵も保持し復号可)。専有ハードウェアやFIPS 140-2 Level3が要るならCloudHSM、外部鍵はExternal Key Store

DBパスワードやAPIキー等の秘密情報を安全に保管し、定期的に自動ローテーションするサービス。RDS/Aurora/Redshiftとネイティブ統合する。

• 自動ローテーション: Lambda(回転関数)でDBパスワード等を定期的に新しくし、RDS/Aurora/Redshift/DocumentDBはネイティブ統合でアプリ無停止に更新
• 取得方法: アプリは起動時/必要時にAPIで取得(コードに秘密を書かない)。クライアントキャッシュで呼び出し回数を抑制、KMSで暗号化、リソースポリシーでクロスアカウント共有
• Parameter Store(SSM)との違い: 機能差は主に自動ローテーションの有無と料金。単純な設定値・環境変数なら無料のParameter Store、自動ローテーションや厳格な秘密管理が要るならSecrets Manager(有料)
• クロスリージョンレプリケーション、削除時の復旧猶予期間あり

SSL/TLS証明書を無料で発行し、期限前に自動更新するサービス。ALB/NLB/CloudFront/API Gatewayにワンクリックで統合できる。

• パブリック証明書は無料で発行し、有効期限前に自動更新(失効によるサイト停止を防ぐ)。DNS検証(推奨・自動更新が楽)/メール検証
• 統合先: ALB/NLB/CloudFront/API Gateway。これらでTLS終端する。EC2には直接インポートできない(EC2上は自前で管理。プライベートCA(ACM PCA)は内部用)
• リージョン注意: CloudFrontで使う証明書は必ずus-east-1で作成。ALB等はそのリージョンで作成
• 秘密鍵はACMが管理し外部に出ない。インポート証明書(外部発行)も使えるが自動更新は不可

L7でリクエストをフィルタするWebアプリケーションファイアウォール。SQLインジェクション・XSS・IPブロック・レート制限などのルールを定義する。

• Web ACL: ルールの集合で各リクエストを Allow/Block/Count/CAPTCHA。条件は IP・地理・ヘッダ・ボディ・URI・SQLi/XSSパターン・レートベース(単位時間の上限超過で遮断)など
• マネージドルール: AWSやサードパーティの定義済みルール(OWASP Top10・既知の悪性IP・ボット対策)をすぐ適用。誤検知はCountモードで検証してから有効化
• 適用先(L7): CloudFront／ALB／API Gateway／AppSync／Cognito。複数アカウントへ一括適用するならFirewall Manager
• 役割分担: L7アプリ攻撃=WAF、L3/L4のDDoS=Shield、L3/L4のパケット制御=SG/NACL。CloudFront＋Shield＋WAFが定番の多層防御

DDoS攻撃からリソースを保護する。StandardはL3/L4を無料・自動で、Advancedは高度な保護と24時間の専門チーム(DRT)を提供する。

• Standard: 全ユーザーに無料・自動適用。SYN/UDPフラッド等のL3/L4の一般的なDDoSを常時緩和(CloudFront/Route 53/ELBで特に強力)
• Advanced: 有料(約$3,000/月＋データ転送)。L3-L7の高度な緩和、攻撃の可視化、24時間のDRT(対応チーム)支援、DDoS起因のスケールアウト費用を補償、WAF利用込み
• 守る対象: CloudFront・Route 53・Global Accelerator・ALB/NLB・Elastic IP。アプリ層(L7)の攻撃はWAFと組み合わせて防ぐ
• 「24/7専門サポート・コスト保護・大規模攻撃対策」が要件ならAdvanced、通常はStandardで十分

VPC Flow Logs/CloudTrail/DNS Logsを機械学習で分析し、不正アクセスや異常行動を自動検出する。有効化するだけで設定不要。

• 仕組み: VPC Flow Logs・CloudTrail(管理＋S3/Lambdaデータイベント)・DNSログを機械学習＋脅威インテリジェンスで継続分析。エージェント不要・有効化するだけでログ自体は別保存も不要
• 検出例: 暗号通貨マイニング、漏洩した認証情報での不正API、ポートスキャン/ブルートフォース、C&C(マルウェア)通信、異常な地理からのアクセス、S3の不審な操作
• 対処連携: 検出(Findings)をEventBridgeへ流しLambda/SNS/Security Hubで自動対応(該当IPの遮断、隔離など)。Organizationsで全アカウントを委任管理者が一元監視
• 追加保護: EKS/RDS/Lambda/S3 Protection、Malware Protection。役割は検出(原因調査はDetective、脆弱性はInspector、S3機密はMacie)

EC2/コンテナイメージ/Lambdaのソフトウェア脆弱性(CVE)とネットワーク到達可能性を自動スキャンし、深刻度付きでレポートする。

• 対象と仕組み: EC2(SSMエージェント経由でOS/パッケージを継続スキャン)／ECRコンテナイメージ(プッシュ時＋継続)／Lambda関数。新しいCVEが公表されると自動で再評価
• 評価内容: ソフトウェア脆弱性(CVE)に加えネットワーク到達可能性(意図せず外部公開されたポート)を分析し、リスクスコア付きで優先度を提示
• 結果はSecurity Hub/EventBridgeに集約して自動チケット化。エージェントベースで定期スキャン設定が不要(旧Inspector Classicより自動化)
• 役割の違い: Inspector=内部の脆弱性/パッチ漏れ、GuardDuty=外部脅威の検出、Macie=S3の機密データ

S3内の個人情報(PII)やクレジットカード番号などの機密データを機械学習で自動検出・分類する。データプライバシー対応に使う。

• 機密データ検出: 機械学習＋マネージド識別子でS3内のPII(氏名/住所)・クレジットカード番号・認証情報・健康情報などを自動検出・分類。正規表現のカスタム識別子(社員番号等)も定義可
• バケット可視化: S3全体の暗号化状況・公開設定・共有状態を継続評価し、危険なバケットを洗い出す
• 検出結果はEventBridge/Security Hubへ連携して自動対応(通知・是正)。コスト最適化のためサンプリングや対象バケット指定が可能
• 用途: GDPR/PCI DSS等のコンプライアンス、データ流出の予防。S3に特化(EC2/コンテナの脆弱性はInspector、脅威検出はGuardDuty)

複数のAWSアカウントや業務アプリへのシングルサインオンを提供する(旧AWS SSO)。Organizations配下に一元的なアクセス管理を実現する。

• ID source: 内蔵ディレクトリ／AWS Managed Microsoft AD・AD Connector／外部IdP(Okta・Azure AD等をSAML 2.0・SCIMで同期)から選択。ユーザーは1回のログインで対象すべてにアクセス
• 許可セット(Permission Set): IAMポリシーの束を定義し、「このグループ × このアカウント = この権限」を割り当て。裏でアカウント側にIAMロールが自動作成される
• Organizations配下の複数アカウントを横断して一元管理。SAML対応の外部業務アプリへのSSOにも対応
• 旧称AWS SSO。アカウント数が増えてもアクセス管理が破綻しないようにするのが狙い(個別IAMユーザーの乱立を防ぐ)

Web/モバイルアプリにユーザー登録・ログイン・MFAを追加し、さらにAWSリソースへの一時アクセス権も付与できる。

• User Pool(認証): アプリ独自のユーザーディレクトリ。サインアップ/サインイン・MFA・パスワードポリシー・ソーシャル/SAML/OIDCフェデレーション、Hosted UIを提供し、成功するとJWTトークンを発行
• Identity Pool(認可): User Poolや外部IdPのトークンを受け取り、STSで一時的なAWS認証情報を発行。これでアプリから直接S3/DynamoDB等へ安全にアクセス(認証済み/未認証ロールを使い分け)
• 典型フロー: User Poolでログイン→JWT取得→Identity Poolで一時AWS認証情報→AWSリソースへ。API GatewayのCognitoオーソライザーで保護も可
• 用途: Web/モバイルの会員認証、B2Cの大規模ユーザー管理。社内・複数AWSアカウントのSSOはIAM Identity Center

WindowsのActive DirectoryをAWS上で提供する。ドメイン参加・SSO・グループポリシー管理を実現し、オンプレADとの連携も可能。

• AWS Managed Microsoft AD: 本物のMicrosoft ADをマネージドで提供(Multi-AZ)。オンプレADと信頼関係を結べ、グループポリシー・スキーマ拡張に対応。FSx for Windows/RDS for SQL Server/WorkSpaces/QuickSight等と統合
• AD Connector: ADをクラウドに置かず、認証をオンプレADへ転送するプロキシ。既存ADをそのまま使いたい/ID情報を持ち出したくない場合
• Simple AD: Samba互換の小規模・低コスト版(一部AD機能のみ)。信頼関係やスキーマ拡張は不可
• 選択軸: AWS上でフル機能のAD/信頼関係→Managed Microsoft AD、オンプレ認証を流用→AD Connector、小規模で安く→Simple AD

Network FirewallはVPC全体を守るマネージドFW(IDS/IPS)、Firewall Managerは複数アカウントのセキュリティルールを一括管理する。

• Network Firewall: VPC境界に置くマネージドなステートフルFW＋IDS/IPS。送信先ドメイン/FQDNフィルタリング、Suricata互換ルールで侵入防止、TLS検査。専用サブネットを作り対象トラフィックを誘導する
• 適用範囲: SGはインスタンス単位、NACLはサブネット単位の単純な許可/拒否。Network FirewallはVPC全体の高度な検査(L3-L7)を担い、これらを補完
• Firewall Manager: Organizations配下の全アカウント/新規アカウントへ自動でセキュリティポリシーを適用。WAFルール・Shield Advanced・Network Firewall・SGの監査/共通設定を一元統制
• 単一アカウントの設定はWAF/SG/Network Firewall個別で十分。複数アカウントを横断して統制したいときにFirewall Manager(前提: AWS ConfigとOrganizations)

GuardDuty等が検出したセキュリティ問題の根本原因を、ログを自動でグラフ化して関連を可視化し調査するサービス。

• VPC Flow Logs・CloudTrail・GuardDuty検出結果を取り込み、自動でグラフ(振る舞いグラフ)化。エンティティ(IP/ユーザー/インスタンス)ごとの活動を時系列で関連付ける
• 「この検出は普段と比べて異常か」「いつから・どこから始まったか」「他に影響範囲はあるか」を視覚的にたどり、根本原因と影響範囲の調査を高速化
• 機械学習・統計で通常のベースラインからの逸脱を示す。前段のGuardDutyやSecurity Hubの検出を起点に深掘りする位置づけ
• 役割整理: GuardDuty=検出 → Detective=原因調査。Security Hubは各種検出の集約ダッシュボード

GuardDuty・Inspector・Macie・Firewall Manager等の検出結果や、各種セキュリティ基準への準拠チェックを1か所に集約し、重要度順に一元管理するサービス。組織全体のセキュリティ体制を可視化し、対応漏れを防ぐ。

• 集約: 各サービスの検出結果を共通形式ASFF(AWS Security Finding Format)で統合し、重要度でスコアリング・優先度付け
• 基準チェック: CIS AWS Foundations Benchmark／AWS基礎セキュリティベストプラクティス／PCI DSS等に自動で継続評価し準拠状況をスコア表示
• 自動化・統制: 検出をEventBridgeへ流して自動修復/通知、Organizationsで委任管理者が全アカウントを一元集約

AWSリソースのメトリクス監視、ログ収集・分析、アラーム通知を行う統合モニタリング。閾値超えでSNS通知やAuto Scaling、Lambdaを自動起動する。

• メトリクス: 標準(CPU・ネットワーク・ELBリクエスト等)＋カスタム(メモリ/ディスクはエージェント必須)。1分(標準)/1秒(詳細・高解像度)、ダッシュボードで可視化
• Logs: アプリ/システムログを収集・保存し、Logs Insightsでクエリ検索。メトリクスフィルタでログから数値メトリクスを生成しアラーム化
• Alarm: 閾値超過(または異常検知)で SNS通知／Auto Scaling／EC2アクション／Lambda を起動。複合アラームで条件を組み合わせ
• その他: EventBridge(旧CloudWatch Events)でイベント駆動、Synthetics(外形監視)、Container/Lambda Insights、ServiceLens(X-Ray連携)。CloudWatch=性能監視、CloudTrail=操作監査の役割分担

すべてのAWS API操作(コンソール含む)を記録する監査証跡。「誰が・いつ・何を・どこから」を追跡し、セキュリティ監査に必須。

• イベント種類: 管理イベント(リソースの作成/変更/削除など・既定で記録)／データイベント(S3オブジェクトやLambda実行など高頻度・追加設定)／Insightsイベント(普段と違うAPI急増を自動検出)
• 保存と保護: ログをS3に長期保存(ライフサイクルでGlacierへ)、CloudWatch Logsへ連携してリアルタイム監視/アラート。ログファイル整合性検証＋S3オブジェクトロックで改ざん防止
• 組織トレイル: Organization Trailで全アカウントのログを管理アカウントに集約。直近90日はEvent historyで無料閲覧
• 「誰が・いつ・どこから・何をした」の監査が役割。設定の準拠性はConfig、性能はCloudWatchと補完関係。Athenaでログを分析するのが定番

リソースの設定変更を継続的に記録し、ルールベースで準拠性を自動評価する。非準拠リソースの自動修復も可能。

• 記録: リソースの設定を継続記録し、変更タイムラインと関係(誰が・いつ・どの構成から変わったか)を保持。「過去のある時点の構成」を再現できる
• Configルール: マネージド/カスタム(Lambda)で「SGがポート22を全開放していないか」等を継続的に準拠評価。準拠/非準拠を可視化
• 自動修復: 非準拠リソースをSSM Automationで自動是正。コンフォーマンスパックでルール群をテンプレ一括適用、Aggregatorで複数アカウント/リージョンを集約
• 役割: Config=設定が正しいか(状態の準拠) / CloudTrail=誰が変更したか(操作の記録)。両者で監査を構成

マイクロサービスやサーバーレスで、1つのリクエストが各サービスをどう流れ、どこで遅延・エラーが起きたかを可視化する分散トレーシング。

• 仕組み: リクエストにトレースIDを付与し、通過した各サービスが「セグメント/サブセグメント」を記録。これを束ねて1リクエストのエンドツーエンドを再構成する
• サービスマップ: API Gateway→Lambda→DynamoDB のような呼び出し関係と各区間の所要時間・エラー率を図で表示し、ボトルネックや失敗箇所を一目で特定
• 導入: Lambda/API Gateway/ECS/EC2/Elastic Beanstalk等と統合。SDK/エージェントで計測、サンプリングで負荷とコストを制御、注釈/メタデータで絞り込み
• CloudWatch ServiceLensでメトリクス/ログ/トレースを統合表示。CloudWatch=何が遅い/異常か、X-Ray=なぜ・どこで遅いかを補完

EC2やオンプレサーバーの運用を一元化するサービス群。SSHなしのリモートアクセス、パッチ適用、設定値管理などを提供する。

• Session Manager: SSHキーやポート22を開けず、IAM権限でブラウザ/CLIからシェルアクセス。操作ログをS3/CloudWatchに残せて監査性が高い(踏み台不要)
• Parameter Store: 設定値・シークレットを階層管理。標準は無料(SecureStringはKMS暗号化)。Secrets Managerとの違いは自動ローテーションの有無
• Patch Manager: OS/アプリのパッチ適用をベースライン＋メンテナンスウィンドウで自動化。Run Commandで多数のインスタンスに一括コマンド、State Managerで構成を維持
• その他: Automation(運用手順のワークフロー化・自動修復)、Inventory(資産棚卸し)、Fleet Manager。オンプレサーバーもエージェントで一元管理

アカウントをベストプラクティスに照らして自動点検し、コスト・性能・セキュリティ・耐障害性・サービス上限の改善点を提案する。

• 5カテゴリ: コスト最適化／パフォーマンス／セキュリティ／耐障害性(信頼性)／サービス上限(クォータ)を自動チェックし、推奨アクションを提示
• プラン差: Basic/Developerは基本的なセキュリティ・上限チェックのみ。Business以上で全項目が解放され、EventBridge/週次メールで通知も可能
• 例: 使われていないEIP/EBS、公開された権限、上限に近いリソース、Multi-AZ未構成などを発見
• 役割: ベストプラクティス全般を広く。EC2等のサイズ最適化に特化するのはCompute Optimizer、設定の準拠評価はConfig

複数アカウントをOU(組織単位)でまとめ、SCPで統制し、一括請求でボリュームディスカウントを得る。

• 構造: 管理(マスター)アカウントの下にOU(組織単位)で階層化し、用途別にアカウントを分離(本番/開発/監査など)。アカウント分離が最強の分離境界
• SCP: OU/アカウントに権限の上限(ガードレール)を適用。「特定リージョン以外を禁止」「S3公開を禁止」などを全体に強制(管理アカウントには効かない)
• 一括請求(Consolidated Billing): 全アカウントの利用を合算してボリュームディスカウント、RI/Savings Plansを共有。コストはタグ/アカウントで配分
• サービス連携: Backup/Config/GuardDuty/CloudTrail等を委任管理者で一元化。新規アカウント作成の自動化と統制はControl Towerが上位で担う

Organizationsの上に立ち、ベストプラクティスに沿ったマルチアカウント環境を自動構築・統制する。

• ランディングゾーン: Organizations・SCP・一元ログ(CloudTrail/Config集約用のログアーカイブ＆監査アカウント)・SSOなどをベストプラクティス構成で自動セットアップ
• ガードレール(コントロール): 予防的(SCPで禁止)＋検出的(Config Rulesで違反検知)を選んで一括適用。必須/強く推奨/選択のレベル分け
• Account Factory: 新規アカウントを定義済みの設定・ネットワーク・ガードレール付きでセルフサービス発行。手作業のばらつきを排除
• 位置づけ: Organizationsが“仕組み”、Control Towerは“ベストプラクティスを自動適用するダッシュボード”。大規模マルチアカウントの初期整備と統制に

管理者が承認したIT製品(主にCloudFormationテンプレート)をカタログ化し、利用者がガバナンスを守ったままセルフサービスでプロビジョニングできるようにするサービス。標準化された構成だけを展開させ、シャドーIT・設定のばらつきを防ぐ。

• 製品とポートフォリオ: 製品=CloudFormationテンプレート(EC2＋RDS構成など)。ポートフォリオ=製品の束で、ユーザー/グループ/ロールにアクセス権を付与
• ガバナンス: 起動制約(Launch Constraint)で利用者本人の権限が無くても所定のロールで展開でき、テンプレート制約で選べるパラメータ値を制限。承認外の構成は作れない
• 運用: 製品のバージョン管理、TagOptionで必須タグを強制、Organizations経由でポートフォリオを各アカウントへ共有

AWS側の障害情報や、自分のアカウントに影響するイベント(メンテ予定・障害)を通知するダッシュボード。

• Service Health Dashboard: AWS全体のサービス稼働状況(公開ページ)。Personal Health Dashboard(現AWS Health): 自分のアカウント・リソースに実際に影響するイベントだけを通知
• イベント例: メンテナンス予定、基盤障害、EC2再起動/リタイア予定、証明書失効、APIの非推奨化など。事前にアクションを促す
• EventBridge連携で発生時にLambda/SNSを自動起動(該当インスタンスの移行・通知など)。Organizationsビューで全アカウントを集約
• 「自分の環境に効くAWS側の障害/予定をいち早く知り自動対応する」のが役割

システム間に待ち行列(キュー)を挟んで送信側と受信側を切り離し、非同期処理を実現する。処理速度の差を吸収し、スパイクを平準化する。

• Standard: ほぼ無制限のスループット・順序保証なし・最低1回配信(まれに重複)。FIFO: 厳密な順序・正確に1回(重複排除)。最大300/3,000 TPS(バッチ)。冪等設計が前提
• 可視性タイムアウト: 取得したメッセージを一定時間“見えなく”して二重処理を防ぐ。処理が長引くなら延長、失敗で時間切れになると再配信される
• 受信: ロングポーリング(空応答とコストを削減)、バッチ取得。最大保持4日(既定)〜14日、メッセージ最大256KB(大きいデータはS3＋拡張クライアント)
• DLQ: 既定回数失敗したメッセージを退避し、本流を詰まらせず後で分析/再処理。SNS＋SQSファンアウト(1通知→複数キューが各自処理)が定番。1対1=SQS、1対多=SNS

1つのメッセージを購読する全サブスクライバー(SQS/Lambda/HTTP/Email/SMS)へ一斉配信するPub/Sub型メッセージング。1対多の通知に使う。

• Pub/Sub: パブリッシャーがトピックに1回発行→購読する全サブスクライバーへプッシュ配信。サブスクライバーはSQS/Lambda/HTTP(S)/Email/SMS/モバイルプッシュ/Kinesis Firehose
• メッセージフィルタリング: 属性に基づき各サブスクライバーへ配信を絞り込み(不要な配信を減らす)。FIFOトピックで順序保証・重複排除も可
• ファンアウト: 1トピック→複数SQSキューに同時配信し、各システムが独立・非同期に処理(疎結合・並列化)。SAA超定番パターン
• 信頼性: 配信失敗時のリトライ＋DLQ、保管時暗号化、メッセージアーカイブ/リプレイ。SNS=即時の一斉プッシュ通知、SQS=溜めてポーリングの違い

AWSサービス/SaaS/カスタムアプリのイベントをルールで振り分けるサーバーレスイベントバス(CloudWatch Eventsの後継)。

• イベントバス＋ルール: AWSサービスのイベント(EC2状態変化・S3操作・CodePipeline等)やカスタム/SaaSイベントを、パターンマッチのルールでフィルタし最大5ターゲット(Lambda/SQS/SNS/Step Functions等)へルーティング
• スケジューラ: cron/rate式で定期実行(「毎日0時にLambda」など)。バッチやクリーンアップの起動に
• 連携: SaaS(Datadog/Zendesk等)のパートナーイベントバス、スキーマレジストリでイベント構造を管理、Pipesでソース→フィルタ/変換→ターゲットを直結、アーカイブ＆リプレイ
• SNSとの違い: SNSは単純な一斉プッシュ、EventBridgeは多数のイベント源を内容で振り分けるのが得意(CloudWatch Eventsの後継)

複数のLambda等をステートマシン(状態遷移図)でワークフロー化する。条件分岐・並列・リトライ・エラー処理を宣言的に定義する。

• 2タイプ: Standard(最大1年・正確に1回・実行履歴を保持・長時間/監査向き)／Express(最大5分・大量/秒・低コスト・IoTやストリーム処理向き)
• 状態(ステート): Task(処理)/Choice(分岐)/Parallel(並列)/Map(動的並列)/Wait/Retry・Catch(リトライ/エラー処理)をASL(JSON)で宣言。フローが可視化され運用しやすい
• 連携: Lambda・ECS・SNS/SQS・DynamoDB等200以上のAPIを直接呼べる。コールバックパターンで人手承認や外部完了待ちも表現
• 「LambdaからLambdaを直呼びして制御が複雑化」するアンチパターンを解消し、長い/分岐のあるワークフローのオーケストレーションを担う

ログ・IoT・クリックストリームなどのリアルタイムデータを収集し、カスタムアプリで低遅延に処理するサービス。かつての“Kinesisファミリー”のうち、取り込みを担うコアが Kinesis Data Streams で名称は変わっていない。配信・分析は別サービスに独立・改名した（下記）。

• Kinesis Data Streams：取り込み。名称そのまま
• Kinesis Data Firehose → Amazon Data Firehose（2024年に改名・Kinesisから独立。別項目）
• Kinesis Data Analytics → Managed Service for Apache Flink（2023年に改名・独立。別項目）
• Kinesis Video Streams：名称そのまま
• → 試験は新名称で出るので、旧名（学習時の名前）と新名をセットで覚える

• シャードで構成する低遅延ストリーム。複数コンシューマーが同じデータを並行処理でき、保持1〜365日で再処理(リプレイ)可。スループットはシャード数で調整(オンデマンドも)。順序はシャード内で保証
• 配信だけでよいなら → Amazon Data Firehose、リアルタイム集計/異常検知 → Managed Service for Apache Flink
• SQSは1回消費のキュー、Kinesis Data Streamsは複数読者＋順序＋リプレイ

流れ続けるストリーミングデータに対し、SQLまたはApache Flinkで集計・変換・異常検知をリアルタイムに実行するフルマネージドサービス。データを溜めてからの後追い分析ではなく、到着したそばから処理する。

• 入力: Kinesis Data Streams / Amazon MSK(Kafka) 等のストリームを購読
• 処理: 時間ウィンドウ(タンブリング/スライディング)集計、フィルタ、ストリーム結合、異常検知。状態(ステート)を保持した連続処理と、イベント時刻ベースの正確な集計
• 出力(シンク): S3 / OpenSearch / Kinesis・Firehose / Lambda / 別ストリームへ
• サーバー/クラスター管理不要で自動スケール。現行はApache Flinkベース(Java/Python/Scala)。Studioノートブックで対話的に開発（旧・SQL方式のKinesis Data Analytics for SQLは廃止）

ストリーミングデータを、コードを書かずにS3/Redshift/OpenSearch等へニアリアルタイムで自動配信するフルマネージドサービス。シャード管理不要で「とにかくデータレイク等へ流し込む」用途の定番。

• 入力: Kinesis Data Streams / アプリからの直接PUT / MSK / CloudWatch Logs等
• 配信先(宛先): S3 / Redshift / OpenSearch / Splunk / Datadog等のHTTPエンドポイント
• バッファリング: サイズ(MB)または時間(秒)でまとめてから配信(完全なリアルタイムではなくニアリアルタイム)。配信失敗時はS3へ退避
• 変換: Lambdaで加工、GZIP等で圧縮、JSON→Parquet/ORCへ列指向変換、動的パーティショニング。サーバーレスで自動スケール

Salesforce・SAP・Slack・Google Analytics・Zendesk等のSaaSと、S3/Redshift等のAWSサービスの間で、データをノーコードで安全に双方向転送するフルマネージドな統合サービス。

• フロー設定: 送信元/送信先・フィールドのマッピング・フィルタ・変換・検証をGUIで定義(コード不要)
• 実行トリガー: オンデマンド/スケジュール/イベント駆動(SaaS側の更新を検知)
• セキュリティ: 転送中/保管時の暗号化、PrivateLinkでインターネットを経由しないプライベート転送

Apache Kafkaをフルマネージドで提供するサービス。Kafkaブローカーやメタデータ管理(Zookeeper/KRaft)の構築・パッチ・スケール・監視をAWSが担い、既存のKafkaアプリ・ツールをそのまま使える。

• 互換性: オープンソースKafkaと互換で、既存のプロデューサー/コンシューマー・コネクタ・運用ツールが変更なしで動く(Kafkaからの移行に最適)
• 運用: Multi-AZでブローカーを冗長配置、保管時(KMS)/通信時(TLS)暗号化、IAM/SASL-SCRAM認証、CloudWatch/オープンモニタリング
• 形態: プロビジョンド(ブローカー数を指定)とMSK Serverless(自動スケール)。MSK ConnectでKafka Connectコネクタをマネージド実行

ActiveMQ/RabbitMQ互換のマネージドブローカー。既存のJMS/AMQP/MQTT等を使うアプリをコード変更なしでクラウド移行できる。

• 2エンジン: Apache ActiveMQ／RabbitMQをマネージドで提供。業界標準プロトコル(JMS/AMQP/MQTT/STOMP/OpenWire等)に対応し、既存アプリをコード変更ほぼ無しで移行
• Multi-AZのアクティブ/スタンバイで高可用、ブローカーのプロビジョニング・パッチ・バックアップをAWSが管理
• キュー(1対1)とトピック(Pub/Sub)の両方、永続化・順序・トランザクションなどブローカー機能をそのまま利用
• 使い分け: 新規はSQS/SNS(スケール・サーバーレス・低運用)、既存のメッセージング資産を“そのまま”クラウドへ移行するならAmazon MQ

複数のデータソースを1つのGraphQLエンドポイントで統合し、リアルタイムのデータ同期やモバイルのオフライン同期も提供する。

• GraphQL: 1つのエンドポイントで必要なフィールドだけを取得(過不足のないレスポンス)。スキーマ＋リゾルバーで複数データソースを束ねる
• データソース: DynamoDB/Lambda/Aurora(RDS Data API)/OpenSearch/任意のHTTPに接続し、1クエリで複数ソースから集約
• リアルタイム: サブスクリプション(WebSocket)で変更をクライアントへプッシュ。オフライン同期(モバイルでローカル変更→オンライン時に解決)に強い
• 認証はCognito/IAM/API Key/OIDC/Lambda、キャッシュやWAFも。REST/単純API→API Gateway、複雑なデータ取得/リアルタイム/モバイル→AppSync

S3のデータをサーバーレスで直接SQLクエリできるインタラクティブ分析。スキャンしたデータ量だけ課金され、インフラ管理は不要。

• 仕組み: Presto/TrinoベースのSQLエンジンがS3を直接クエリ。事前のサーバー構築・ロード不要で、スキャンしたデータ量で課金(1TBあたり数ドル)
• カタログ: Glue Data Catalogでテーブル定義(スキーマ)を管理。クローラーでスキーマ自動検出、CSV/JSON/Parquet/ORC/Avro等に対応
• コスト/性能最適化: Parquet/ORC(列指向)＋圧縮＋パーティション分割でスキャン量を激減=料金と速度を改善。パーティション射影で大量パーティションも高速
• 用途: S3上のログ(VPC Flow Logs/CloudTrail/ALB)のアドホック分析、データレイク照会、QuickSightの裏側。定常的な大規模分析はRedshift、大規模分散処理はEMR

データをダッシュボードやグラフで可視化・共有するサーバーレスBI。SPICE(インメモリエンジン)で高速表示する。

• SPICE: 超高速のインメモリ列指向エンジンにデータを取り込み、ダッシュボードを高速表示(直接クエリも選択可)
• データソース: S3/Athena/Redshift/RDS/Aurora/DynamoDB、オンプレDB、SaaSなど。グラフ・ピボット・地図で可視化し組織で共有
• ML Insights: 異常検知・予測、自然言語で質問するQuickSight Q。行/列レベルセキュリティでユーザーごとに見える範囲を制限
• サーバーレスで、ユーザー単位/セッション単位課金、アプリへの埋め込み(Embedded)も可能。「ダッシュボード・BI・可視化」の要件で選ぶ

Hadoop/Spark/Hive/Presto等のビッグデータフレームワークをマネージドで実行する。大規模な分散ETL・機械学習に使う。

• フレームワーク: Apache Spark/Hadoop/Hive/Presto/HBase/Flink等をマネージドなクラスターで実行。大規模ETL・機械学習・ペタバイト級分析に
• 実行環境: EC2(マスター/コア/タスクノード)／EKS／EMR Serverless(キャパシティ管理不要)。タスクノードにスポットを使い大幅コスト削減
• ストレージ分離: EMRFSでS3をデータレイクとして使い、計算と保存を分離(クラスターは使い捨て=トランジェント可)。処理後にクラスターを終了してコスト最適化
• 使い分け: フレームワークでの大規模分散処理/MLはEMR、S3への手軽なSQLはAthena、定常DWHはRedshift

データの抽出・変換・ロード(ETL)とメタデータ管理をサーバーレスで行う。バラバラなデータを分析できる形に整える。

• Data Catalog: テーブル定義の中央メタストア。Athena/EMR/Redshift Spectrum/Lake Formationが共通参照する“データの目次”
• Crawler: データソースを走査してスキーマ・パーティションを自動検出しカタログに登録
• Job: サーバーレスでETLを実行(Spark/PySpark/Python Shell)。DynamicFrameで半構造データを扱い、ブックマークで増分処理。ビジュアルETLのGlue Studio、データ品質、ノーコード加工のDataBrewも
• イベント/スケジュールのトリガーでパイプライン化。Athena＋Glue Data Catalogはサーバーレス分析の定番。サーバー管理ありの大規模はEMR

S3ベースのデータレイクの構築と、列レベル/行レベルのきめ細かいアクセス制御を一元管理する。

• 一元的なアクセス制御: S3＋Glue Data Catalogの上に立ち、テーブル/列/行/セル単位のきめ細かな権限を一箇所で集中管理。タグベースアクセス制御(LF-Tags)で大規模にスケール
• 取り込み・クレンジング・カタログ化をブループリントで自動化し、データレイクの構築を数日→数時間に短縮
• Athena/Redshift Spectrum/EMR/QuickSight等がLake Formationの権限に従ってアクセス。誰がどのデータを参照したかも監査
• 「データレイクの権限を部署/利用者ごとに細かく統制したい」要件で選ぶ(S3バケットポリシーだけでは難しい粒度)

全文検索とログのリアルタイム分析・可視化を行うマネージドサービス(旧Elasticsearch Service)。

• 全文検索: 転置インデックスで大量ドキュメントを高速・あいまい検索(オートコンプリート・スコアリング・日本語形態素)。アプリの検索機能の裏側に
• ログ分析: アプリ/インフラ/監査ログを取り込み、OpenSearch Dashboardsでリアルタイムに可視化・アラート(集中ログ基盤)
• 取り込み: Amazon Data Firehose(旧Kinesis Data Firehose)→OpenSearchやLogstash/Fluent Bit経由が定番。マネージドクラスター(マルチAZ)/OpenSearch Serverlessを選択
• 用途: サイト内検索、SIEM的なセキュリティ分析、observabilityのログ集約。CloudWatch Logsより高度な全文検索・可視化が要るとき

AWSリソースをJSON/YAMLテンプレートで自動プロビジョニングするIaC。環境の再現性・バージョン管理・自動ロールバックを実現する。

• スタック: テンプレート(JSON/YAML)から作るリソースの集合を一括で作成/更新/削除。失敗時は自動ロールバック、削除保護やDeletionPolicyでデータ保全
• 再利用性: パラメータ・マッピング・条件・組み込み関数(Ref/GetAtt)で環境差分を吸収、ネストスタック/モジュールで部品化、Outputs/エクスポートでスタック間連携
• StackSets: 1つのテンプレートを複数アカウント×複数リージョンへ一括展開・更新(Organizations連携)。全社共通のガードレール配布に
• 安全な変更: 変更セットで更新前に影響をプレビュー、ドリフト検出で手動変更との差分を検知。CDK(コードでテンプレ生成)やSAM(サーバーレス)も同じ基盤。Terraformとの違いはAWSネイティブ

「ソース→ビルド→テスト→デプロイ」の一連のリリース作業を自動化するCI/CDの司令塔。

• ステージ構成: Source(CodeCommit/GitHub/S3)→Build(CodeBuild)→Test→Deploy(CodeDeploy/CloudFormation/ECS等)を自動でつなぐ。変更を検知すると自動実行
• 制御: ステージ間に手動承認ゲート、並列/順次アクション、失敗時の停止。アーティファクトはS3で受け渡し
• サードパーティ(GitHub/Jenkins)や各種デプロイ先と統合。マルチアカウント/マルチリージョンのデプロイも構成可
• 位置づけ: CI/CDのオーケストレーター(全体の流れ)。実作業はCodeBuild(ビルド)・CodeDeploy(デプロイ)が担う

ソースのコンパイル・テスト・パッケージ化を行うフルマネージドビルドサービス。ビルドサーバーの管理不要で使った分だけ課金。

• buildspec.ymlでフェーズ(install/pre_build/build/post_build)とコマンドを定義し、マネージドなDockerコンテナでコンパイルやテストやDockerイメージのビルドを実行
• サーバー管理不要・使った分(ビルド時間)だけ課金。並列ビルド、キャッシュ、カスタムイメージ、VPC接続に対応
• 成果物(アーティファクト)はS3へ、ログはCloudWatch Logsへ。CodePipelineの「ビルド」ステージとして使うのが定番

EC2/Lambda/ECSへのアプリデプロイを自動化する。ダウンタイムゼロのBlue/Greenデプロイもサポート。

• In-place: 既存インスタンス上でアプリを順次入れ替え(EC2/オンプレ向け、ダウンタイムが出得る)。Blue/Green: 新環境(Green)を作りトラフィックを切替、問題時は即ロールバック(ダウンタイムゼロ)
• 段階的切替: Lambda/ECSでは Canary(一部→全体)/Linear(段階)/All-at-once。CloudWatchアラームで自動ロールバック
• appspec.ymlでデプロイ手順とフック(BeforeInstall/AfterInstall等)を定義。ALB連携でトラフィックを制御
• 対象はEC2/オンプレ/Lambda/ECS。「ダウンタイムゼロ」「安全な切り戻し」が要件ならBlue/Green

Dockerコンテナイメージを保存・管理するフルマネージドレジストリ。ECS/EKSと統合してプル/プッシュする。

• プライベート/パブリックリポジトリにDockerイメージを保存。IAM＋リポジトリポリシーでアクセス制御、保管時暗号化、クロスリージョン/クロスアカウントのレプリケーション
• 脆弱性スキャン: プッシュ時(基本)＋継続(拡張・Inspector統合)でイメージのCVEを検出。イミュータブルタグで上書き防止
• ライフサイクルポリシーで古い/未使用イメージを自動削除しコスト削減。ECS/EKS/Lambda(コンテナ)がここからpull
• CodeBuildでビルドしたイメージをECRにpush→ECS/EKSがデプロイ、というコンテナCI/CDの保管庫の役割

過去・現在のコストをグラフで分析し将来を予測する。サービス別・タグ別など多次元で掘り下げできる。

• 可視化: 過去13ヶ月のコスト/使用量をサービス別・アカウント別・タグ別・リージョン別などでグラフ化し、内訳を掘り下げ。12ヶ月先までの予測
• 最適化提案: 使用パターンを分析してRI/Savings Plansの購入推奨、Rightsizing推奨、RI/SPの利用率・カバレッジレポート
• コスト配分タグで部門/プロジェクト別に按分。粒度の細かい生データはCost and Usage Report(CUR)→Athena/QuickSightで深掘り
• 役割: 分析・予測・最適化のヒント。予算超過の“通知”はBudgetsと使い分け

コストや使用量に予算を設定し、超えそうになったら通知する。自動でリソース停止などのアクションも可能。

• 予算タイプ: コスト予算／使用量予算／RI・SPの利用率・カバレッジ予算。月次/四半期/年次や任意期間で設定
• アラート: 実績値だけでなく予測値が閾値(例80%/100%)に達したらEmail/SNS/Chatbotで通知。先回りで気付ける
• Budget Actions: 閾値超過時に自動アクション(IAMポリシーをデタッチして新規作成を止める、EC2/RDSを停止するなど)で暴走コストを抑制
• 役割: コストの“見張りと自動対応”。傾向の分析・予測はCost Explorer

EC2/EBS/Lambda/ECS Fargateの使用状況をMLで分析し、最適なリソースサイズを推奨する。

• 対象: EC2(インスタンスタイプ)・EBS(ボリュームタイプ/IOPS)・Lambda(メモリ)・ECS on Fargate・Auto Scaling Group。機械学習で使用パターンを分析
• CloudWatchメトリクスを14日以上収集し、過剰(オーバープロビジョニング)/不足を検出。推奨タイプと予測パフォーマンス＋コスト削減額を提示
• メモリ使用率まで見るにはCloudWatchエージェントが必要。役割はリソースの適正サイズ(Rightsizing)に特化
• Trusted Advisor(ベストプラクティス全般)より深いサイズ最適化、RI/SP購入の最適化はCost Explorerと役割分担

1時間あたりの使用量を1〜3年コミットして最大72%割引を受ける料金プラン。RIより柔軟で、EC2/Lambda/Fargateを横断適用できる。

• Compute Savings Plans: EC2/Fargate/Lambdaを横断し、インスタンスファミリー/サイズ/リージョン/OSが変わっても割引が効く最も柔軟なタイプ(最大66%)
• EC2 Instance Savings Plans: 特定リージョン×特定ファミリーに限定する代わりに割引率が大きい(最大72%)。サイズやOSの変更には追従
• RIとの違い: RIは“インスタンスを予約”、SPは“1時間あたりの使用金額($/h)をコミット”。SPの方が柔軟で管理が楽(キャパシティ予約は別途ODCRで)
• 支払いは全額/一部/前払いなし。安定稼働分をSP/RIで割引、変動分はオンデマンド、中断可はスポット、という組み合わせが定石

EC2/RDS/ElastiCache/Redshift等を1〜3年予約して割引を受ける購入オプション。安定稼働のワークロード向け。

• 対象: EC2に加えRDS/ElastiCache/Redshift/OpenSearch等も予約割引(SPはこれらに非対応なので、DBの割引はRIが必要)
• 支払い: 全額前払い(最大割引)/一部前払い/前払いなし。1年 or 3年
• 種類: Standard RI(タイプ変更不可・最大割引・RIマーケットプレイスで売却可)／Convertible RI(ファミリー/OS等を変更可・割引やや低)
• スコープ: リージョン(柔軟・容量保証なし)/ゾーン(特定AZでキャパシティ予約付き)。「24/365の安定稼働DB」はRI全額前払いが鉄板