AWS SAA-C03 全サービスマップ

⚙

コンピューティング

10 services

Amazon EC2

AWS上に仮想サーバー（インスタンス）を立てるサービス。OS・ミドルウェア・アプリまで完全に制御できる、最も基本的なコンピュートサービス。

インスタンスタイプ: M(汎用) / C(CPU最適化) / R(メモリ最適化) / I,D(ストレージ最適化) / G,P(GPU)
購入オプション: オンデマンド(従量) / RI(1-3年予約,最大75%割引) / スポット(最大90%割引,中断あり) / Savings Plans(柔軟な割引) / Dedicated Host(物理ホスト占有,ライセンス要件)

試験頻出: 「中断OK+最安」→スポット / 「ホスト占有+ライセンス」→Dedicated Host / 「24/365+割引」→RI or Savings Plans

EC2 Auto Scaling

CPU使用率やリクエスト数などに応じて、EC2インスタンスの台数を自動で増減させるサービス。ALBと組み合わせて高可用性Webアプリを構築する定番。

スケーリングポリシー4種:
・ターゲット追跡: 「CPU使用率70%を維持」のように目標値を指定
・ステップ: アラームの段階に応じて増減量を変える
・シンプル: 1つのアラームに対して固定数の増減
・スケジュール: 「平日9時にスケールアウト、18時にスケールイン」

試験頻出: 「CPU70%維持」→ターゲット追跡 / 「平日だけ起動」→スケジュール
クールダウン期間でスケーリング暴走を防ぐ。ヘルスチェックはEC2/ELBの2種

AWS Lambda

サーバーを一切管理せずにコードを実行できるサーバーレスサービス。S3へのアップロードやAPI Gatewayのリクエストなど、イベントをトリガーに自動実行される。

制約: 最大実行時間15分 / メモリ128MB〜10GB / デプロイパッケージ最大250MB(展開後)
課金: リクエスト数 + 実行時間(メモリ量 x 秒数) / 無料枠: 月100万リクエスト
コールドスタート対策: Provisioned Concurrencyで事前にインスタンスを温めておく

試験頻出: 「短時間処理」「イベント駆動」「管理不要」→Lambda / 15分超え→Batch or Fargate
API Gateway + Lambda = サーバーレスの定番パターン

Amazon ECS

Dockerコンテナの実行・管理・スケーリングを行うオーケストレーションサービス。AWSサービスとの統合が深く、AWS環境でコンテナを動かす第一選択。

起動タイプ2種:
・EC2起動タイプ: 自分でEC2クラスターを管理。GPUやカスタムAMIが使える
・Fargate起動タイプ: サーバーレス。インフラ管理不要だがEC2型より高コスト
構成要素: タスク定義(コンテナ設定) → サービス(稼働数管理) → クラスター(論理グループ)

試験頻出: 「コンテナ + AWS統合を重視」→ECS / 「K8s互換」→EKS
ECS vs EKSで迷ったらKubernetes要件の有無で判断

Amazon EKS

Kubernetesのコントロールプレーンをマネージドで提供するサービス。K8sのエコシステム（Helm, kubectl等）をそのまま使える。マルチクラウドやオンプレK8sからの移行に最適。

・Kubernetesと100%互換、既存K8sマニフェストをそのまま利用可能
・Fargate or EC2ノードグループで起動
・EKS Anywhere: オンプレミスでもK8sクラスターを管理可能

試験頻出: 「Kubernetes互換」「K8sのスキル/ツールを活かしたい」「マルチクラウド移植性」→EKS

AWS Fargate

ECSやEKSのコンテナを、EC2インスタンスを意識せずに実行できるサーバーレスコンピュートエンジン。ホストの管理・パッチ適用・スケーリングが全自動。

・CPU/メモリの組み合わせを指定するだけでコンテナが起動
・EC2起動タイプよりコストは高いが、運用負荷がゼロに近い
・タスクごとにENI(ネットワークインターフェース)が割り当てられる

試験頻出: 「コンテナ + 管理の手間を最小化」「サーバーレスでコンテナ」→Fargate

Elastic Beanstalk

WebアプリやAPIのデプロイ・スケーリング・管理を自動化するPaaS。開発者はアプリコードだけ用意すれば、裏でEC2/ELB/Auto Scaling/RDS等を自動構成してくれる。

・対応言語: Java, .NET, PHP, Node.js, Python, Ruby, Go, Docker
・プラットフォーム管理(OS/ランタイム更新)はAWSが担当
・内部でCloudFormationを使用してリソースを管理
・基盤のリソース（EC2等）に直接アクセスも可能

試験頻出: 「最小限の管理でWebアプリをデプロイ」「PaaS」→Beanstalk
CloudFormation=インフラ全体の細かい制御、Beanstalk=Webアプリの手軽なデプロイ

Amazon Lightsail

小規模なWebサイトやアプリを、月額固定料金で簡単に立ち上げられるシンプルなVPS。EC2より設定が少なく、WordPress等のブループリントが用意されている。

・月額固定料金（コンピュート/ストレージ/転送量込み）
・WordPress, LAMP, Node.js等のブループリントあり
・EC2に比べて機能は限定的だが、圧倒的にシンプル

試験頻出: 「簡単・安い・小規模」→Lightsail。SAA試験では深く出ないが選択肢の消去法で登場する

AWS Batch

大量のバッチコンピューティングジョブを効率的に実行するサービス。ジョブキューとコンピュート環境を自動管理し、ジョブ量に応じて最適なリソースを割り当てる。

・ジョブ定義(Docker) → ジョブキューに投入 → コンピュート環境で自動実行
・EC2/Fargate/スポットインスタンスを自動選択
・Lambdaの15分制限を超える長時間バッチ処理に最適

試験頻出: 「大量バッチ処理」「15分超え」「ジョブのスケジューリング」→Batch
短時間イベント→Lambda、長時間バッチ→Batch

AWS Outposts

AWSのインフラ（サーバー/ストレージ）を物理的にオンプレミスに設置するサービス。AWS APIをローカルで使え、超低レイテンシーやデータ居住要件に対応。

・AWSが機器を配送・設置・保守（フルマネージド）
・EC2, EBS, S3, RDS, ECS, EKS等がオンプレで動作
・AWSリージョンと接続して一元管理

試験頻出: 「低レイテンシーでオンプレ連携」「データを国内に保持（データレジデンシー）」「ハイブリッドクラウド」→Outposts

🗃

ストレージ

17 services

Amazon S3

HTTP経由でアクセスするオブジェクトストレージ。容量無制限、1オブジェクト最大5TB。静的Webホスティング、バックアップ、データレイクなど万能。

ストレージクラス: Standard / IA(低頻度) / One Zone-IA / Glacier Instant / Glacier Flexible / Deep Archive / Intelligent-Tiering(自動最適化)
暗号化: SSE-S3(S3管理) / SSE-KMS(監査可能) / SSE-C(顧客提供キー)
機能: バージョニング / ライフサイクルポリシー / クロスリージョンレプリケーション(CRR) / オブジェクトロック / イベント通知

試験頻出: ライフサイクルポリシー(自動クラス移行)、暗号化方式の選択(監査→SSE-KMS)、CRR(DR用)、「最小コスト長期保存」→Deep Archive、「パターン不明」→Intelligent-Tiering

S3 Object Lambda

S3からオブジェクトを取得(GET)する際に、Lambda関数を通してデータをその場で加工して返す仕組み。元データは1つのまま、呼び出し側ごとに違う見せ方ができる。

・取得時にLambdaで変換(個人情報マスキング/リサイズ/フォーマット変換/フィルタ)
・S3アクセスポイント経由で適用
・加工版を別途保存せず、元オブジェクトを複製しなくて済む

試験頻出: 「S3取得時にデータを動的に加工/マスキングして返したい(元データは変えない)」→S3 Object Lambda

S3 Glacier

アーカイブ専用の低コストストレージ。取得に時間がかかる代わりに非常に安い。コンプライアンスや法規制による長期データ保持に最適。

3つのティア:
・Glacier Instant Retrieval: ミリ秒で取得。四半期に1回程度のアクセス
・Glacier Flexible Retrieval: 数分〜12時間。年1-2回アクセス
・Glacier Deep Archive: 12時間。最安。年1回以下のアクセス

試験頻出: 取り出し時間とコストのトレードオフ。「7-10年保存,ほぼアクセスなし」→Deep Archive。S3ライフサイクルポリシーで自動移行が定番

Amazon EBS

EC2インスタンスにアタッチするブロックストレージ（仮想ディスク）。OSやデータベースのディスクとして使う。スナップショットでバックアップ可能。

ボリュームタイプ:
・gp3/gp2: 汎用SSD。ほとんどのワークロードに対応
・io2/io1: プロビジョンドIOPS SSD。DB等の高IO要件向け。Multi-Attach対応(io1/io2)
・st1: スループット最適化HDD。ビッグデータ/ログ処理
・sc1: コールドHDD。アクセス頻度が低い大容量データ

試験頻出: 単一AZに紐づく(マルチAZ不可)。「高IOPS DB」→io2、「ログ/ビッグデータ」→st1。スナップショットはS3に保存(増分バックアップ)

Amazon EFS

複数のEC2インスタンスから同時にマウントできるマネージドNFSファイルシステム。容量は自動拡張/縮小。マルチAZ対応で高可用性。

・NFSv4プロトコル / Linux専用（Windows不可 → FSx for Windowsを使う）
・ストレージクラス: Standard / IA(低頻度) / ライフサイクル管理で自動移行
・パフォーマンスモード: 汎用(デフォルト) / Max I/O(大規模並列)

試験頻出: 「複数EC2からの共有アクセス」「NFS」→EFS。EBSは基本1EC2に紐づく。WindowsならFSx for Windows

Amazon FSx

特定のファイルシステムプロトコルに対応したフルマネージドファイルストレージ。用途別に4種類ある。

・FSx for Windows File Server: SMBプロトコル、Active Directory統合。Windowsファイル共有
・FSx for Lustre: HPCや機械学習向け高性能FS。S3と透過的に連携可能
・FSx for NetApp ONTAP: マルチプロトコル(NFS/SMB/iSCSI)
・FSx for OpenZFS: Linux向け高性能FS

試験頻出: 「Windows共有」「SMB」「AD統合」→FSx Windows / 「HPC」「機械学習」「S3連携」→FSx Lustre

Storage Gateway

オンプレミスのアプリケーションからAWSストレージ（S3/EBS/Glacier）にシームレスにアクセスするためのハイブリッド接続サービス。ローカルキャッシュで低レイテンシー。

3種類:
・File Gateway: NFS/SMB → S3。ファイル共有のクラウド拡張。最頻出
・Volume Gateway: iSCSI → EBS Snapshots。Cached(キャッシュ)とStored(全データローカル)の2モード
・Tape Gateway: 仮想テープライブラリ → S3/Glacier。テープバックアップの置き換え

試験頻出: 「オンプレのバックアップをAWSに」→Storage Gateway。常時ハイブリッド接続=Storage GW、一括転送/移行=DataSync

Snow Family

ネットワーク経由では時間がかかりすぎる大量データを、物理デバイスで運搬してAWSに移行するサービス。一部はエッジコンピューティングにも対応。

・Snowcone: 8-14TB。持ち運び可能な小型デバイス
・Snowball Edge: 80TB。エッジコンピューティング(Lambda/EC2互換)も実行可能
・Snowmobile: 100PB。コンテナトラックで運搬する超大容量

試験頻出: 「ネットワーク転送で1週間以上」「10TB超」→Snow Family検討。目安: 100Mbpsで50TB≒46日 → Snowball Edgeの方が速い

AWS Backup

EC2/EBS/RDS/DynamoDB/EFS/FSx等、複数AWSサービスのバックアップを一元管理するサービス。バックアッププラン（スケジュール・保持期間）をポリシーとして定義。

・バックアッププランで自動スケジュール設定
・クロスリージョンバックアップ / クロスアカウントバックアップ対応
・AWS Organizations と統合してマルチアカウントのバックアップポリシーを一元管理

試験頻出: 「複数サービスのバックアップポリシーを一元化」「コンプライアンス要件でバックアップを自動化」→AWS Backup

AWS DataSync

オンプレミスのNFS/SMBサーバーからS3/EFS/FSxへ、高速・自動でデータを転送するサービス。定期的なデータ同期や一括移行に使う。

・ネットワーク経由で最大10Gbpsのスループット
・自動でデータ検証（整合性チェック）
・スケジュール設定で定期的な差分同期が可能
・オンプレにDataSyncエージェントをインストールして使用

試験頻出: Storage Gateway=常時接続ハイブリッド（アプリからリアルタイムアクセス）、DataSync=一括転送/定期同期（移行プロジェクト）の使い分け

Transfer Family

SFTP/FTPS/FTPプロトコルでS3やEFSへ直接ファイル転送できるフルマネージドサービス。既存のSFTPクライアントやワークフローをそのままクラウドストレージに接続できる。

・対応プロトコル: SFTP / FTPS / FTP / AS2
・保存先: S3 または EFS
・認証: IAM / Managed AD / カスタム(Lambda・API Gateway)
・サーバーの構築・運用・パッチ適用が不要

試験頻出: 「既存のSFTPでS3にファイルを受け渡し」「サーバー管理なしのSFTP」→Transfer Family

Elastic Disaster Recovery

オンプレや他クラウドのサーバーをブロックレベルで継続的にAWSへレプリケートし、災害時に数分でEC2として起動する低コストDRサービス（旧CloudEndure DR / 略称 DRS）。

・継続的レプリケーションでRPO数秒・RTO数分を実現
・通常時は低コストのステージング領域のみ稼働、フェイルオーバー時にフル起動
・物理/仮想/クラウドの各種サーバーに対応
・フェイルバック（本番復旧後に元環境へ戻す）も可能

試験頻出: 「低コストでRTO/RPOを最小化するDR」「サーバー丸ごとのDR」→Elastic Disaster Recovery。データのバックアップ＝AWS Backup、サーバーのDR＝DRS

Application Migration Service

オンプレや他クラウドのサーバーを、ブロックレベルで継続レプリケートし、ほぼそのまま(リホスト/リフト&シフト)AWSのEC2へ移行する主力サービス。旧CloudEndure Migration、略称MGN。

仕組み: エージェントでサーバーを継続レプリケート → 最小ダウンタイムでEC2へカットオーバー
テスト起動: 本番切替前に検証用インスタンスを起動して動作確認できる
DRS(Elastic Disaster Recovery)との違い: 仕組みは兄弟。MGN=移行(一度きりの引っ越し)、DRS=災害復旧(常時待機)

試験頻出: 「サーバー群を最小ダウンタイムでEC2へリホスト/リフト&シフト移行」→MGN。DMS=DBの移行、DataSync=ファイルの移行、MGN=サーバー丸ごとの移行

Migration Hub

複数の移行ツール(MGN/DMS等)を使った移行プロジェクトの進捗を、1か所のダッシュボードで一元的に追跡・可視化するサービス。

役割: どのサーバー/アプリがどこまで移行したかを横断的に可視化
連携: Application Migration Service / DMS などの状況を集約
関連: Discovery Service でオンプレの構成・依存関係を事前把握できる

試験頻出: 「複数サービスにまたがる移行の進捗を一元管理・可視化」→Migration Hub

Application Discovery Service

オンプレミスのサーバー構成・性能・サーバー間の依存関係を収集し、AWSへの移行計画を立てるためのサービス。収集データはMigration Hubで可視化する。

・エージェントレス(VMware vCenter経由)とエージェント型(個別サーバーに導入)
・CPU/メモリ使用率・稼働プロセス・ネットワーク接続(依存関係)を収集
・どのサーバーを一緒に移行すべきかをグルーピング・計画
・データはMigration Hubに集約、S3エクスポート→Athena分析も可能

試験頻出: 「移行前にオンプレの構成・依存関係を把握・棚卸し」→Application Discovery Service。把握→計画(Migration Hub)→実行(MGN/DMS)の流れ

App2Container (A2C)

既存のJava/.NETアプリを、コード変更なしでコンテナ化するCLIツール。コンテナイメージとECS/EKS用のデプロイ定義を自動生成し、コンテナ化によるモダナイズを支援する。

・物理/仮想/EC2/オンプレで動く稼働中アプリを分析しコンテナ化
・Dockerイメージ＋ECS/EKS/App Runnerのデプロイ成果物(CFn)を生成
・ECRへ登録、CI/CD(CodePipeline)へ組み込み
・サーバー丸ごと移行(MGN)ではなく「コンテナへのリプラットフォーム」

試験頻出: 「既存のJava/.NETアプリをコンテナ化してECS/EKSへ移行(モダナイズ)」→App2Container。サーバー丸ごとのリホストはMGN

Migration Evaluator

オンプレ環境を分析し、AWSへ移行した場合のコスト削減効果を試算して、移行のビジネスケース(投資対効果)を作成するサービス。旧TSO Logic。

・現行の使用状況を収集し、AWS移行後のコストを予測
・移行の投資対効果(ビジネスケース)をレポート化
・「移行すべきか/どれだけ安くなるか」の意思決定を支援

試験頻出: 「AWS移行のコスト削減効果・ビジネスケースを試算」→Migration Evaluator。構成/依存の把握はApplication Discovery Service

📊

データベース

12 services

Amazon RDS

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

Multi-AZ: 同期レプリケーションで別AZにスタンバイ。障害時自動フェイルオーバー。読取分散ではない
リードレプリカ: 非同期レプリケーション。読取トラフィックの分散用。最大5台(Aurora15台)
バックアップ: 自動バックアップ(35日) + 手動スナップショット(無期限)

試験頻出: Multi-AZ=フェイルオーバー用(可用性)、リードレプリカ=読取分散用(パフォーマンス)。この違いは超頻出。Oracle/SQL Server→RDS一択

RDS Proxy

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

・コネクションプールで接続を再利用し、DBの接続数を抑制
・Lambdaなどサーバーレスからの大量接続に最適
・フェイルオーバー時間を短縮(アプリの再接続を肩代わり)
・Secrets ManagerとIAM認証を統合

試験頻出: 「Lambda等からRDSへの大量接続で接続枯渇・性能低下」→RDS Proxyでコネクションプール

Amazon Aurora

AWS独自開発の高性能リレーショナルDB。MySQL5倍・PostgreSQL3倍のスループット。自動で3AZに6コピーのストレージ、最大128TB自動拡張。

Aurora Serverless: 使用量に応じて自動スケール。断続的/予測不能なワークロードに最適
Aurora Global Database: 最大5つのセカンダリリージョンに1秒以内のレプリケーション
リードレプリカ: 最大15台。フェイルオーバーターゲットとしても機能

試験頻出: 「高可用性RDB+コスト最適化」→Aurora / 「使用頻度が不規則」→Aurora Serverless / 「クロスリージョンDR」→Global Database

Aurora Global Database

Auroraを複数リージョンにまたがって展開し、プライマリからセカンダリへ1秒未満でレプリケーションする機能。クロスリージョンDRとグローバルな低遅延読み取りを実現。

・1プライマリ＋最大5セカンダリリージョン、各リージョンで読み取り可能
・専用インフラで複製、通常RPO約1秒・RTO約1分
・リージョン障害時はセカンダリを昇格(マネージド/手動)
・書き込みフォワーディングでセカンダリ経由の書き込みも可能

試験頻出: 「RDBでクロスリージョンDR・低RPO/RTO・グローバルな低遅延読み取り」→Aurora Global Database。同一リージョンの可用性はMulti-AZ

Amazon DynamoDB

フルマネージドNoSQLデータベース。キーバリュー/ドキュメント型。1桁ミリ秒のレイテンシーで無限にスケール。サーバーレスで容量やスループットの管理不要。

キャパシティモード: オンデマンド(自動) / プロビジョンド(予約,Auto Scaling対応)
DAX: DynamoDB専用インメモリキャッシュ。マイクロ秒の応答時間
グローバルテーブル: マルチリージョンのアクティブ-アクティブレプリケーション
ストリーム: テーブル変更をリアルタイムキャプチャ(Lambda連携等)

試験頻出: 「キーバリュー」「ミリ秒」「サーバーレスDB」「セッション管理」→DynamoDB。複雑なJOIN/トランザクション→RDS/Aurora

Amazon ElastiCache

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

Redis: レプリケーション、永続化、ソート済みセット、Pub/Sub、Multi-AZ。高機能
Memcached: マルチスレッド、シンプル、スケールアウト向き。永続化なし

試験頻出: 「DBの読取負荷軽減」「セッション管理」→ElastiCache。「高可用性/永続化/ランキング」→Redis、「シンプルなキャッシュのみ」→Memcached

Amazon Redshift

ペタバイト規模のデータウェアハウス。列指向ストレージでSQL分析クエリが高速。BIダッシュボードやバッチ分析レポートの基盤として使う。

Redshift Spectrum: S3上のデータをRedshiftクラスターにロードせず直接SQLクエリ
Redshift Serverless: キャパシティ管理不要のサーバーレスオプション
・同時実行スケーリングで急増するクエリに自動対応

試験頻出: OLTP(トランザクション)→RDS/Aurora、OLAP(分析)→Redshift。「大量データの定常的な分析クエリ」「BI」がキーワード

Amazon Neptune

フルマネージドのグラフデータベース。ノード間の関係性を効率的に格納・クエリする。ソーシャルグラフ、ナレッジグラフ、推薦エンジン、不正検出に最適。

・Property Graph(Apache TinkerPop/Gremlin)とRDF(SPARQL)の両方をサポート
・リードレプリカ最大15台、Multi-AZ対応

試験頻出: 「ソーシャルネットワーク」「推薦エンジン」「不正検出」「関係性の探索」→Neptune

Amazon DocumentDB

MongoDB互換のフルマネージドドキュメントデータベース。JSONライクなドキュメントを格納し、柔軟なクエリが可能。MongoDBからの移行先として。

・MongoDB 3.6/4.0/5.0互換API
・ストレージは自動で3AZに6コピー、最大64TB

試験頻出: 「MongoDB互換」「ドキュメント型NoSQL」→DocumentDB。DynamoDB=キーバリュー型、DocumentDB=ドキュメント(JSON)型

Amazon QLDB

台帳（レジャー）データベース。全ての変更履歴がイミュータブル（変更不可）に記録され、暗号的に検証可能。監査やコンプライアンス要件に対応。

・すべてのデータ変更はイミュータブルなジャーナルに記録
・SHA-256ハッシュチェーンで改ざん防止を暗号的に検証
・中央集権型（ブロックチェーンとは異なる）。分散台帳→Managed Blockchain

試験頻出: 「変更履歴の改ざん防止」「監査証跡」「イミュータブルな記録」→QLDB
※QLDBは新規利用停止・2025年でサポート終了。試験では「改ざん検知＝QLDB」のキーワード対応のみでOK

Amazon Keyspaces

Apache Cassandra互換のフルマネージドデータベース。既存のCassandraアプリケーションをコード変更なしで移行可能。サーバーレスで容量自動拡張。

・CQL(Cassandra Query Language)互換
・オンデマンド/プロビジョンドキャパシティ

試験頻出: 「Cassandra互換」「Cassandraの移行」→Keyspaces。深くは出ないが選択肢として登場

AWS DMS

データベースをほぼダウンタイムなしでAWSへ移行するマネージドサービス。同種移行（Oracle→Oracle）も異種移行（Oracle→Aurora）も対応。移行元を稼働させたまま継続的にレプリケート。

継続的レプリケーション(CDC): 移行中も変更を追従し、切替時のダウンタイムを最小化
SCT(Schema Conversion Tool): 異種DB間でスキーマ/ストアドプロシージャを自動変換
・移行先: RDS / Aurora / Redshift / DynamoDB / S3 / Kinesis 等
・レプリケーションインスタンス(EC2)上で実行

試験頻出: 「DBを最小ダウンタイムで移行」→DMS。「異種DBエンジンへ移行」→DMS+SCT。DMS=DB移行、DataSync=ファイル移行の使い分けが頻出

🌐

ネットワーク

14 services

Amazon VPC

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

構成要素: サブネット(パブリック/プライベート) / ルートテーブル / Internet Gateway(IGW) / NAT Gateway / NACL / セキュリティグループ(SG)
NACL: サブネットレベル、ステートレス(in/out両方ルール必要)、番号順に評価
SG: インスタンスレベル、ステートフル(戻りトラフィックは自動許可)、全ルール評価

試験頻出: パブリック/プライベートサブネット設計、NAT GW(プライベート→インターネットのアウトバウンドのみ)、NACL=ステートレス vs SG=ステートフルの違い

VPCエンドポイント

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

ゲートウェイエンドポイント: S3/DynamoDB専用。無料。ルートテーブルにエントリ追加
インターフェースエンドポイント(PrivateLink): その他のAWSサービス用。ENI経由。有料

試験頻出: 「インターネット経由せずS3アクセス」→VPCゲートウェイエンドポイント(無料)。S3/DynamoDB=ゲートウェイ型、それ以外=インターフェース型

Internet Gateway (IGW)

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

仕組み: VPCに1つアタッチ → パブリックサブネットのルートテーブルに 0.0.0.0/0 → IGW を追加
条件: 通信するリソースにパブリックIP / Elastic IPが必要
NAT Gatewayとの違い: IGW=パブリック向け(双方向)、NAT Gateway=プライベートの外向きのみ

試験頻出: 「パブリックサブネットからインターネット」→IGW。プライベートの外向きだけ→NAT Gateway、AWSサービスへ非公開接続→VPCエンドポイント

NAT Gateway

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

仕組み: NAT Gatewayはパブリックサブネットに配置し、プライベートサブネットのルートテーブルに 0.0.0.0/0 → NAT Gateway を追加。IGW経由で外へ出る
高可用性: AZ単位。マルチAZ化するには各AZにNAT Gatewayを置く
NATインスタンス(旧式)との違い: NAT Gatewayはフルマネージドで自動スケール・高可用。NATインスタンスはEC2を自前管理する旧方式

試験頻出: 「プライベートサブネットのEC2をパッチ更新等でインターネットに出したい(インバウンドは不要)」→NAT Gateway。「NATインスタンスで問題」→NAT Gatewayに移行が定番

Elastic Load Balancing

受信トラフィックを複数のターゲット(EC2, コンテナ, Lambda等)に自動分散するサービス。高可用性とスケーラビリティの基盤。

ALB: L7(HTTP/HTTPS)。パスベース/ホストベースルーティング、WebSocket、Cognito認証統合
NLB: L4(TCP/UDP)。超低レイテンシー、毎秒数百万リクエスト、静的IP/Elastic IP対応
GWLB: L3。サードパーティFW/IDS等のアプライアンスを透過的にスケーリング

試験頻出: 「Webアプリ」→ALB / 「極低レイテンシー/静的IP/非HTTP」→NLB / 「セキュリティアプライアンス」→GWLB

Amazon CloudFront

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

OAC(Origin Access Control): S3バケットを直接公開せず、CloudFront経由のみアクセス許可
Lambda@Edge: エッジロケーションでカスタムコード実行（リクエスト/レスポンス加工）
CloudFront Functions: Lambda@Edgeより軽量・高速（ヘッダー操作等）

試験頻出: 「グローバル配信」「S3の静的コンテンツ配信」→CloudFront。セキュリティ3点セット: CloudFront + Shield + WAF

Amazon Route 53

高可用性のマネージドDNSサービス。ドメイン登録、DNSルーティング、ヘルスチェックの3機能。DR構成のフェイルオーバーに不可欠。

ルーティングポリシー6種:
・シンプル(1レコード) / 加重(比率分散/カナリア) / レイテンシー(最速リージョンへ)
・フェイルオーバー(障害時にセカンダリへ) / 地理的位置(地域別) / マルチバリュー(複数健全リソース)

試験頻出: 「アクティブ-パッシブDR」→フェイルオーバー+ヘルスチェック(超頻出) / 「リージョン別に最速応答」→レイテンシー / 「カナリアデプロイ」→加重

Route 53 Resolver

VPCとオンプレミス間でDNSの名前解決を相互に行うためのハイブリッドDNSサービス。オンプレ→AWS、AWS→オンプレの双方向の名前解決を実現する。

・インバウンドエンドポイント: オンプレからVPC内(Route 53等)への問い合わせを受ける
・アウトバウンドエンドポイント: VPCからオンプレのDNSへ問い合わせを転送
・Forwardルール(転送ルール): 「このドメインはオンプレDNSへ」と条件付き転送
・VPC標準のリゾルバー(.2)を拡張したもの

試験頻出: 「オンプレとAWS間でDNS名前解決を相互に(ハイブリッドDNS)」→Route 53 Resolver(インバウンド/アウトバウンドエンドポイント)

API Gateway

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

・スロットリング(レート制限)でAPI保護
・APIレスポンスキャッシュでパフォーマンス向上
・認証: IAM / Cognito User Pool / Lambdaオーソライザー
・ステージ(dev/staging/prod)でバージョン管理

試験頻出: Lambda + API Gateway = サーバーレスの定番。REST API→API GW、GraphQL→AppSync

AWS Direct Connect

オンプレミスのデータセンターとAWSを専用線で接続するサービス。インターネットを経由しないため、一貫した帯域幅と低レイテンシーを実現。

・接続速度: 1Gbps / 10Gbps / 100Gbps(専用接続) or 50Mbps〜10Gbps(ホスト接続)
・セットアップに数週間〜数ヶ月かかる
・暗号化はデフォルトでは無し（必要ならVPNを重ねる）

試験頻出: 「安定帯域」「低レイテンシー」「ハイブリッド接続」→Direct Connect。冗長性にはDX+VPNバックアップ。すぐ必要→VPN

AWS VPN

インターネット経由でオンプレミスやリモートユーザーとAWS VPCを暗号化トンネルで接続するサービス。Direct Connectより安価で即座に利用可能。

Site-to-Site VPN: オンプレミスのルーター⇔AWS VGW(Virtual Private Gateway)で接続
Client VPN: リモートユーザーのPC/スマホからVPCにアクセス

試験頻出: 「すぐにハイブリッド接続が必要」→VPN / 「コスト低く素早く接続」→VPN / 「安定・高帯域」→Direct Connect

Transit Gateway

複数のVPCとオンプレミスネットワークをハブ&スポーク型で中央接続するサービス。VPCピアリングの1対1接続では管理しきれない大規模環境向け。

・数千のVPCとオンプレミスを接続可能
・ルートテーブルで一元的にルーティング管理
・VPCピアリングは推移的ルーティング不可（A⇔B⇔CでもA→Cは不可）、Transit GWなら可能

試験頻出: 「数十のVPCをフルメッシュ接続」「VPC+オンプレの一元管理」→Transit Gateway。2-3個のVPC→VPCピアリングで十分

AWS PrivateLink

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

・サービスプロバイダー側: NLBの前にエンドポイントサービスを作成
・コンシューマー側: インターフェースVPCエンドポイントで接続
・VPCのCIDRが重複していても接続可能

試験頻出: 「自社サービスを他VPC/アカウントにプライベート公開」→PrivateLink。ピアリング=双方向全通信、PrivateLink=一方向・特定サービスのみ

Global Accelerator

AWSのグローバルネットワーク(バックボーン)を使って、ユーザーのトラフィックを最寄りのエッジから最適なリージョンにルーティングするサービス。固定Anycast IP 2つ付与。

・TCP/UDPトラフィックの最適化（HTTPに限らない）
・固定IPアドレスでDNS伝播を待たずにフェイルオーバー
・CloudFrontと違いキャッシュはしない。ネットワーク層の最適化

試験頻出: CloudFront=コンテンツキャッシュ(HTTP)、Global Accelerator=TCP/UDPの最適ルーティング。「固定IP」「ゲーム/IoT/VoIP」→GA

🔒

セキュリティ・ID

18 services 配点30% 最重要

AWS IAM

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

基本原則: 最小権限の原則（必要最低限の権限のみ付与）
ロール: EC2やLambdaにAWSサービスへのアクセス権限を付与（アクセスキーをコードに書くのは絶対NG）
ポリシー種類: アイデンティティベース / リソースベース / SCP / パーミッションバウンダリー

試験頻出: EC2からS3等へのアクセスは必ずIAMロール。クロスアカウントアクセスもロール+STS AssumeRole。アクセスキーをEC2に置く選択肢は常にNG

IAM ポリシー評価

複数のポリシーが適用される場合の評価ロジック。「デフォルト拒否→明示的拒否が最優先→明示的許可」の3段階で判定される。

SCP(サービスコントロールポリシー): Organizations内のアカウントレベルで最大権限を制限するガードレール。権限を付与するのではなく上限を制限
パーミッションバウンダリー: IAMユーザー/ロールの最大権限を制限。「開発者が自分でロールを作れるが、特定権限は超えられない」

試験頻出: SCPで拒否→IAMで許可してもアクセス不可。「部門ごとにアクセス制限」→SCP、「開発者の最大権限を制限」→パーミッションバウンダリー

AWS STS

一時的なセキュリティ認証情報（アクセスキー+シークレットキー+セッショントークン）を発行するサービス。有効期限付きで、長期認証情報より安全。

AssumeRole: 別のIAMロールの権限を一時的に引き受ける。クロスアカウントアクセスやフェデレーションに使用
・常に一時認証情報を推奨（長期アクセスキーはリスク）

試験頻出: 「別アカウントのリソースにアクセス」→STS AssumeRole。外部IdPからのフェデレーション認証にも使用

IAM Roles Anywhere

AWSの外（オンプレサーバー・他クラウド・コンテナ）のワークロードに、X.509証明書を使ってIAMロールの一時認証情報を取得させる仕組み。長期アクセスキーを配らずに済む。

・信頼アンカーに認証局(CA)を登録し、その証明書を持つ外部ワークロードを信頼
・証明書で認証 → STSで一時認証情報を取得 → AWSへアクセス
・オンプレ等にIAMアクセスキーを置かずに済む(キー漏洩リスクを排除)

試験頻出: 「オンプレ/他クラウドのサーバーに長期アクセスキーを置かずAWSアクセス」→IAM Roles Anywhere(証明書ベース)。AWS内のEC2ならIAMロールで十分

AWS KMS

暗号化キーの作成・管理・ローテーションを行うサービス。S3/EBS/RDS等のAWSサービスと統合して、データの暗号化を一元管理。

CMK(カスタマーマスターキー): AWS管理キー / カスタマー管理キー / AWS所有キー
S3暗号化方式: SSE-S3(S3管理,簡単) / SSE-KMS(監査可能,CloudTrailで追跡) / SSE-C(顧客提供キー)
・キーローテーション: カスタマー管理キーは年1回自動ローテーション設定可能

試験頻出: 「暗号化の監査」「キーの使用を追跡」→SSE-KMS一択。「とりあえず暗号化」→SSE-S3。「自社キー完全管理」→SSE-C

Secrets Manager

データベースのパスワードやAPIキーなどのシークレットを安全に保存・取得・自動ローテーションするサービス。RDS/Redshift/DocumentDBと統合してパスワードを自動更新。

・自動ローテーション: Lambda関数を使って定期的にパスワードを自動変更
・RDS/Aurora/Redshiftとのネイティブ統合
・Parameter Store(無料)との違い: 自動ローテーション機能の有無が最大の差

試験頻出: 「RDSパスワードの自動ローテーション」→Secrets Manager / 「設定値・環境変数の管理(無料)」→Parameter Store

ACM

SSL/TLS証明書の発行・管理・自動更新を行うサービス。パブリック証明書は無料で発行でき、ELB/CloudFront/API Gatewayにワンクリックで統合。

・パブリック証明書: 無料。DNS検証 or メール検証
・自動更新: 有効期限前に自動で証明書を更新
・統合先: ALB/NLB/CloudFront/API Gateway。EC2には直接使えない（EC2上で手動管理が必要）

試験頻出: 「HTTPS化」「SSL証明書」→ACM。CloudFrontで使う場合はus-east-1リージョンでACM証明書を作成する必要あり

AWS WAF

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

・マネージドルール: AWSやサードパーティが提供する定義済みルールセット
・適用先: ALB / CloudFront / API Gateway / AppSync
・Web ACL: ルールの集合。Allow/Block/Countのアクション

試験頻出: 「SQLインジェクション防止」「特定IPブロック」「レート制限」→WAF。NW層(L3/L4)の保護→SG/NACL。DDoS→Shield

AWS Shield

DDoS攻撃からAWSリソースを保護するサービス。StandardはL3/L4の基本保護を無料・自動で提供。Advancedは高度な保護と24/7専門チームサポート。

Shield Standard: 無料。自動有効。L3/L4レベルのDDoS保護
Shield Advanced: 有料($3,000/月)。高度なL3-L7保護、DRT(DDoS Response Team)の24/7サポート、DDoS攻撃によるコスト増の保護

試験頻出: 「DDoS対策」→Shield。「24/7専門チーム」「コスト保護」→Shield Advanced。CloudFront+Shield+WAF=セキュリティ3点セット

Amazon GuardDuty

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

・検出例: 暗号通貨マイニング、不正なAPI呼び出し、ブルートフォース攻撃、C&C通信
・EventBridge連携で検出時にLambdaで自動対処（IPブロック等）
・Organizations統合でマルチアカウント一元管理

試験頻出: 「不正アクセスの検出」「悪意のあるアクティビティ」→GuardDuty。Inspector(脆弱性スキャン)、Macie(S3データ分類)との違いを整理

Amazon Inspector

EC2インスタンスやコンテナイメージのソフトウェア脆弱性(CVE)とネットワーク到達可能性を自動スキャンするサービス。結果をSeverity付きでレポート。

・EC2: SSMエージェント経由でOS/パッケージの脆弱性を検出
・ECR: コンテナイメージのプッシュ時に自動スキャン
・Lambda: 関数コードとレイヤーの脆弱性を検出

試験頻出: GuardDuty=外部攻撃の検出（脅威インテリジェンス）、Inspector=内部の脆弱性スキャン（パッチ漏れ等）の違い

Amazon Macie

S3バケット内の機密データ（PII: 個人情報、クレジットカード番号、マイナンバー等）を機械学習で自動検出・分類するサービス。データプライバシーとコンプライアンス対応。

・S3バケットのインベントリと暗号化/公開状態の可視化
・カスタムデータ識別子の定義も可能
・検出結果をEventBridge→SNS等で通知

試験頻出: 「S3に個人情報が含まれていないか」「データ分類」「PII検出」→Macie。S3に特化した機密データ検出

IAM Identity Center

複数のAWSアカウントやビジネスアプリケーションへのシングルサインオン(SSO)を提供するサービス。旧名AWS SSO。Organizations配下のアカウントに一元的なアクセス管理。

・Organizations配下の全アカウントに1回のログインでアクセス
・社内Active DirectoryやSAML2.0対応の外部IdP(Okta等)と統合可能
・アクセス許可セットで各アカウントの権限を定義

試験頻出: 「マルチアカウントの一元アクセス管理」「SSO」→IAM Identity Center

Amazon Cognito

Web/モバイルアプリにユーザー認証・認可機能を追加するサービス。ユーザー登録・ログイン・MFA、そしてAWSリソースへの一時的なアクセス権限の付与を提供。

User Pool: ユーザーの登録・ログイン・MFA。JWTトークンを発行。認証(Authentication)
Identity Pool: User Poolや外部IdPのトークンを元に、一時的なAWS認証情報(STS)を発行。認可(Authorization)

試験頻出: 典型パターン: User Poolでログイン→トークン取得→Identity Poolで一時AWS認証情報→S3/DynamoDB等にアクセス。「モバイルアプリからAWSリソース」→Cognito

Directory Service

マネージドなActive Directoryを提供するサービス。Windowsワークロードのドメイン参加・SSO・グループポリシー管理をAWS上で実現。オンプレADとの連携も可能。

AWS Managed Microsoft AD: 本物のMicrosoft AD。オンプレADと信頼関係構築可。FSx for Windows / RDS for SQL Server / WorkSpacesと統合
AD Connector: オンプレADへのプロキシ（認証をオンプレに転送、ADはクラウドに置かない）
Simple AD: Samba互換の小規模・低コスト版（一部AD機能のみ）

試験頻出: 「FSx for Windows / SQL ServerにAD統合」→Managed Microsoft AD。「オンプレADの認証をそのまま使う」→AD Connector

Network Firewall / Firewall Manager

VPC全体を保護するマネージドネットワークファイアウォール(L3-L7)と、複数アカウント横断でセキュリティポリシーを一元管理するFirewall Manager。

Network Firewall: VPC境界でステートフルな侵入検知/防止(IDS/IPS)、ドメインフィルタリング、トラフィック制御
Firewall Manager: Organizations配下の全アカウントにWAF / Shield Advanced / Network Firewall / SGのルールを一括適用・統制

試験頻出: 「VPC全体のIDS/IPS・送信先ドメイン制御」→Network Firewall。「複数アカウントのWAF/FWルールを一元管理」→Firewall Manager

Amazon Detective

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

・VPC Flow Logs / CloudTrail / GuardDuty検出結果を自動で関連付け
・エンティティ（IP/ユーザー/リソース）ごとの挙動を時系列で可視化
・MLで通常の挙動からの逸脱を分析

試験頻出: GuardDuty=検出、Detective=原因の深掘り調査、Inspector=脆弱性スキャン、Macie=S3機密データ。「インシデントの根本原因分析」→Detective

Security Hub

GuardDuty・Inspector・Macie等の検出結果や、各種セキュリティ基準のチェックを1か所に集約し、優先度付きで一元管理するセキュリティ統合ダッシュボード。

・複数のセキュリティサービスの結果を統合(ASFF形式)
・CISベンチマーク/AWS基礎セキュリティ/PCI DSS等の自動チェック
・重要度でスコアリング、EventBridgeで自動対応
・Organizationsで全アカウントを一元集約

試験頻出: 「複数のセキュリティサービスの検出結果を一元管理・組織のセキュリティ体制を可視化」→Security Hub。検出はGuardDuty、原因調査はDetective

👁

監視・管理

10 services

CloudWatch

AWSリソースのメトリクス監視、ログ収集・分析、アラーム通知を行う統合モニタリングサービス。EC2のCPU使用率等を監視し、閾値超えでSNS通知やAuto Scaling連動。

メトリクス: EC2標準(CPU,ディスク,ネットワーク) + カスタムメトリクス(メモリ,ディスク使用率)
CloudWatch Logs: アプリケーション/システムログの収集・保存・検索
CloudWatch Alarms: メトリクスの閾値に基づいてSNS通知/Auto Scalingアクション/Lambda実行

試験頻出: 「メモリ使用率の監視」→CloudWatchエージェントが必須（デフォルトメトリクスにメモリはない）。CloudWatch=パフォーマンス監視、CloudTrail=操作の監査

CloudTrail

全てのAWS APIコール（管理コンソール操作含む）を記録する監査証跡サービス。「誰が」「いつ」「何を」「どこから」操作したかを追跡。セキュリティ監査とトラブルシュートに必須。

・管理イベント(デフォルト有効): リソースの作成/削除/変更等のAPI
・データイベント(追加設定): S3オブジェクトレベル操作、Lambda関数実行等
・CloudTrail Insights: 異常なAPIアクティビティを自動検出
・ログはS3に保存、CloudWatch Logsに連携可能

試験頻出: 「誰がリソースを削除した？」「セキュリティ監査」→CloudTrail。Config=「設定が正しいか」、CloudTrail=「誰が変更したか」

AWS Config

AWSリソースの設定変更を継続的に記録し、ルールベースでコンプライアンス（準拠性）を自動評価するサービス。「SGがポート22を全開放していないか」等のチェック。

・リソース設定のスナップショットと変更タイムライン
・Configルール: マネージドルール(AWSが事前定義) / カスタムルール(Lambda)
・非準拠リソースの自動修復(SSM Automationと連携)
・コンフォーマンスパック: ルールのセットを一括適用

試験頻出: 「すべてのSGが特定ルールに準拠しているか」「設定変更の追跡」→Config。CloudTrail(操作記録)とConfigは補完関係

AWS X-Ray

マイクロサービスやサーバーレスなど分散アプリで、1つのリクエストが各サービスをどう流れたかを可視化(分散トレーシング)し、遅延やエラーの原因箇所を特定するサービス。

サービスマップ: リクエストが通る各コンポーネント(API Gateway→Lambda→DynamoDB等)の関係と所要時間を図示
トレース: どこで時間がかかったか・どこでエラーが出たかをセグメント単位で分析
対応: Lambda / API Gateway / EC2 / ECS / Elastic Beanstalk 等と統合

試験頻出: 「マイクロサービス/サーバーレスのボトルネックや遅延箇所を特定」「リクエストのエンドツーエンド追跡」→X-Ray。CloudWatch=メトリクス/ログ、X-Ray=リクエストの追跡

Systems Manager

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

Session Manager: SSH/RDPなしでブラウザからシェルアクセス（ポート22を開けなくてよい）
Parameter Store: 設定値・シークレットの階層的管理。無料（Secrets Managerとの違い=自動ローテーションなし）
Patch Manager: OSパッチ適用の自動化・スケジューリング
Run Command: 複数サーバーに一括でコマンド実行

試験頻出: 「SSHポートを開けずにEC2にアクセス」→Session Manager。「設定値管理(無料)」→Parameter Store

Trusted Advisor

AWSアカウントをベストプラクティスに照らして自動チェックし、改善推奨を提示するサービス。コスト削減、パフォーマンス改善、セキュリティ強化の機会を発見。

5カテゴリ: コスト最適化 / パフォーマンス / セキュリティ / 耐障害性 / サービス制限
・Basic/Developer: 基本的なセキュリティチェックのみ
・Business/Enterprise: 全チェック項目が利用可能

試験頻出: 「未使用リソースの検出」「セキュリティのベストプラクティス」→Trusted Advisor。フルチェックにはBusiness以上のサポートプランが必要

Organizations

複数のAWSアカウントをOU（組織単位）でグルーピングし、SCP（サービスコントロールポリシー）で一元管理するサービス。一括請求でボリュームディスカウントも。

OU: アカウントの論理グループ（例: 開発/本番/セキュリティ）
SCP: OU/アカウントに適用する最大権限のガードレール。権限を付与するのではなく制限する
一括請求(Consolidated Billing): 全アカウントの利用量を合算→ボリュームディスカウント

試験頻出: 「部門ごとにアカウント分離+一元管理」→Organizations+SCP。「S3バケットの公開を禁止」等のガードレール用途

Control Tower

AWS Organizationsの上に構築された、マルチアカウント環境のセットアップとガバナンスを自動化するサービス。ベストプラクティスに基づくガードレールを自動適用。

・ランディングゾーン: ベストプラクティスに基づくマルチアカウント環境を自動構築
・ガードレール: 予防的(SCP) / 検出的(Config Rules) の2種類
・Account Factory: 新規アカウントのプロビジョニングを自動化

試験頻出: 「新規アカウントのベストプラクティス適用を自動化」→Control Tower。Organizations=管理の仕組み、Control Tower=ベストプラクティスの自動適用

Service Catalog

管理者が承認済みのIT製品（CloudFormationテンプレート）をカタログ化し、ユーザーがガバナンスを守ったままセルフサービスでデプロイできるようにするサービス。

・製品(CFnテンプレート)をポートフォリオにまとめ、ユーザー/グループに公開
・起動制約・IAMで「許可された構成だけ」を展開させる(野良リソース防止)
・パラメータで利用者の選択肢を制限、バージョン管理
・Organizations経由でポートフォリオを各アカウントへ共有

試験頻出: 「承認済みの構成だけを利用者にセルフサービスで展開させたい・標準化とガバナンス」→Service Catalog

Health Dashboard

AWSサービスの障害情報と、自分のアカウントに影響する固有イベントを通知するダッシュボード。障害発生時にEventBridgeと連携して自動対処も可能。

Service Health Dashboard: AWS全体のサービス状態
Personal Health Dashboard: 自分のリソースに影響するイベント（メンテナンス予定、障害等）
・EventBridge連携でイベント発生時にLambda/SNS通知を自動実行

試験頻出: 「自分のリソースに影響するAWS障害を通知」→Personal Health Dashboard+EventBridge

🔗

アプリ統合

11 services

Amazon SQS

フルマネージドのメッセージキューサービス。システム間を疎結合にして非同期処理を実現する基本ツール。送信側と受信側が独立して動作し、処理速度の差を吸収。

Standard: 順序保証なし、スループット無制限、少なくとも1回配信（重複あり得る）
FIFO: 厳密な順序保証、正確に1回配信、300TPS（バッチで3,000TPS）
DLQ(デッドレターキュー): 処理に失敗したメッセージを隔離→後で分析・再処理
可視性タイムアウト: メッセージ取得後、他のコンシューマーに見えなくなる期間

試験頻出: 「システム間のデカップリング」「非同期処理」→SQS。1対1=SQS、1対多=SNS。SNS+SQSファンアウトパターンは超頻出

Amazon SNS

Pub/Sub(発行/購読)型のメッセージングサービス。1つのトピックにメッセージを送ると、購読している全てのサブスクライバー(SQS/Lambda/HTTP/Email/SMS)に同時配信。

・トピック: メッセージの発行先。複数のサブスクライバーが購読
・サブスクリプションフィルタ: メッセージ属性で配信先をフィルタリング
・FIFO トピック: 順序保証付きPub/Sub（FIFO SQSと連携）

試験頻出: 「1つのイベントを複数のシステムに通知」→SNS。SNS+SQSファンアウト: SNSトピック→複数SQSキューに同時配信→各独立処理。SAA超定番パターン

Amazon EventBridge

AWSサービス/SaaS/カスタムアプリのイベントをルールベースでルーティングするサーバーレスイベントバス。CloudWatch Eventsの後継で、より多機能。

・AWSサービスのイベント（EC2状態変更、S3操作等）を自動キャプチャ
・ルールでイベントをフィルタ→ターゲット(Lambda/SQS/Step Functions等)に配信
・スケジュール: cron式で定期実行（EventBridge Scheduler）
・SaaSパートナー統合: Zendesk, Datadog等のイベントも受信可能

試験頻出: 「AWSサービスのイベントに反応して処理起動」→EventBridge。「毎日0時にLambda実行」等のスケジュール実行にも使う

Step Functions

Lambda等のAWSサービスをステートマシン（状態遷移図）で視覚的にワークフロー化するオーケストレーションサービス。条件分岐・並列実行・エラーハンドリングを宣言的に定義。

Standard: 最大1年の実行、実行保証あり、状態保存
Express: 最大5分、高スループット（毎秒10万以上）、低コスト
・ASL(Amazon States Language)でワークフローをJSON定義
・「Lambda内でLambdaを呼ぶ」アンチパターンの解消に使う

試験頻出: 「複数Lambdaの順序制御」「条件分岐のあるワークフロー」→Step Functions。Lambda間の直接呼び出しはアンチパターン

Amazon Kinesis Data Streams

リアルタイムのストリーミングデータ（ログ、IoT、クリックストリーム等）を収集し、カスタムアプリで低遅延に処理するサービス。Kinesisの中核（名称は現在も「Kinesis」）。

Kinesis Data Streams: シャードで低遅延処理・複数コンシューマー・再処理(保持1〜365日)。※これがコアで名称そのまま
【名称変更に注意】 かつての“Kinesisファミリー”は分割済み↓
・配信 → Amazon Data Firehose（旧 Kinesis Data Firehose）※別項目に独立
・分析 → Managed Service for Apache Flink（旧 Kinesis Data Analytics）※別項目に独立
・動画 → Amazon Kinesis Video Streams（名称そのまま）

試験頻出: 取り込み/低遅延/再処理→Kinesis Data Streams / 配信→Amazon Data Firehose / 分析→Managed Service for Apache Flink。※試験は新名称で出題。Firehose・分析はKinesisから独立済み（旧名も認識できるように）

Managed Service for Apache Flink

ストリーミングデータに対し、SQLやApache Flinkでリアルタイムに集計・変換・異常検知を行うマネージドサービス。旧Kinesis Data Analytics。

・入力: Kinesis Data Streams / Amazon MSK(Kafka) などのストリーム
・処理: 時間ウィンドウ集計・フィルタ・結合・異常検知をリアルタイム実行
・出力: S3 / OpenSearch / Lambda / 別ストリーム等へ
・サーバー/クラスター管理不要、自動スケール

試験頻出: 「ストリームデータをリアルタイムにSQL分析・集計・異常検知」→Managed Service for Apache Flink。取り込み→Data Streams、配信→Firehose、分析→Flink

Amazon Data Firehose

ストリーミングデータを、コードを書かずにS3/Redshift/OpenSearch等へニアリアルタイムで自動配信するフルマネージドサービス。旧Kinesis Data Firehose。

・入力: Kinesis Data Streams / 直接PUT / MSK 等
・配信先: S3 / Redshift / OpenSearch / Splunk / 各種HTTP(SaaS)
・バッファリング(サイズ/時間)でまとめて配信、Lambdaで変換・圧縮・Parquet変換
・シャード管理不要・自動スケール(サーバーレス)

試験頻出: 「ストリームを管理不要でS3/Redshift/OpenSearchに自動ロード」→Data Firehose。カスタム処理/低遅延/再処理が要るならData Streams

AWS AppFlow

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

・双方向のデータフローをGUIで設定(コード不要)
・オンデマンド / スケジュール / イベント駆動で実行
・フィルタ・マッピング・変換、PrivateLinkでプライベート転送
・SaaS↔AWSの定型データ連携に特化

試験頻出: 「SaaS(Salesforce等)とAWS間でデータをノーコード連携」→AppFlow。汎用ETLはGlue、ストリーミングはKinesis/Firehose

Amazon MSK

Apache Kafkaをフルマネージドで提供するサービス。既存のKafkaアプリをそのまま使え、ブローカーの構築・運用・パッチ・スケーリングをAWSが管理する。

・Managed Streaming for Apache Kafka。Kafka/メタデータ管理をマネージド運用
・既存のKafka API・ツール・コネクタがそのまま使える(移行向け)
・Multi-AZ配置で高可用、保管時/通信時の暗号化
・MSK Serverless / MSK Connect(コネクタ)も提供

試験頻出: 「既存のApache Kafkaをマネージドで・Kafka互換のストリーミング基盤」→Amazon MSK。新規・AWSネイティブで運用最小ならKinesis

Amazon MQ

Apache ActiveMQ/RabbitMQ互換のマネージドメッセージブローカー。既存のJMS/AMQP/MQTT/STOMP対応アプリケーションをコード変更なしでクラウド移行できる。

・ActiveMQ / RabbitMQ の2つのエンジンから選択
・Multi-AZ配置で高可用性
・既存プロトコルとの互換性が最大の特徴

試験頻出: 新規構築→SQS/SNS（AWSネイティブ）、既存プロトコル互換が必要→Amazon MQ。「JMS」「AMQP」「MQTT」「移行」がキーワード

AWS AppSync

フルマネージドのGraphQL APIサービス。複数のデータソース（DynamoDB/Lambda/RDS/HTTP）を1つのGraphQLエンドポイントで統合し、リアルタイムデータ同期も提供。

・GraphQLスキーマを定義→リゾルバーでデータソースとマッピング
・サブスクリプション: WebSocket経由のリアルタイムデータ更新
・オフラインサポート: モバイルアプリのオフライン→オンライン同期

試験頻出: REST API→API Gateway、GraphQL→AppSync。「リアルタイムデータ同期」もAppSyncのキーワード

📈

分析

6 services

Amazon Athena

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

・Presto/Trino ベースのSQLエンジン
・CSV/JSON/Parquet/ORC等の多様なフォーマットに対応
・Glue Data Catalogと統合してテーブルメタデータを管理
・Parquet形式(列指向)に変換するとスキャン量が減ってコスト削減

試験頻出: 「S3のログをアドホック分析」「サーバーレスSQL」→Athena。VPC Flow Logs/CloudTrailのログ分析にAthenaは定番パターン。Glue Catalog連携も頻出

Amazon QuickSight

サーバーレスのBIサービス。データをダッシュボードやグラフで可視化し、組織内で共有。SPICE（インメモリエンジン）でデータをキャッシュし高速表示。

・データソース: S3/RDS/Redshift/Athena/DynamoDB等
・SPICE: Super-fast Parallel In-memory Calculation Engine
・ML Insights: 異常検知、予測、自然言語でのクエリ(QuickSight Q)

試験頻出: 「ダッシュボード作成」「データの可視化」「BI」→QuickSight

Amazon EMR

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

・EC2/EKS/Serverlessの3つの実行環境
・スポットインスタンスでコスト削減可能
・S3をデータレイクとして連携

試験頻出: Athena=S3のアドホッククエリ(小〜中規模)、EMR=大規模分散ETL/ML、Redshift=DWH(定常分析)。使い分けが重要

AWS Glue

サーバーレスのETL(抽出・変換・ロード)サービス。データソースの発見・メタデータ管理・データ変換パイプラインの構築を自動化。

Glue Data Catalog: メタデータの中央カタログ。Athena/EMR/Redshiftがテーブル定義として参照
Glue Crawler: データソースを自動スキャンしてスキーマを検出→Data Catalogに登録
Glue Job: PySpark/Python Shell/Sparkでデータ変換パイプラインを実行

試験頻出: 「データ変換パイプライン」「メタデータ管理」→Glue。Athena+Glue Data Catalogの組み合わせは非常に頻出

Lake Formation

S3ベースのデータレイクをセキュアに構築・管理するサービス。データの収集・クレンジング・カタログ化・アクセス制御を一元的に提供。

・データレイクのセットアップを数日→数時間に短縮
・列レベル/行レベルのきめ細かいアクセス制御
・Glue Data Catalogの上に構築されている
・データソースからS3への取り込みを自動化(ブループリント)

試験頻出: 「データレイクのアクセス制御を一元管理」「列/行レベルのセキュリティ」→Lake Formation

OpenSearch Service

全文検索、ログ分析、リアルタイム可視化を提供するマネージドサービス。旧Amazon Elasticsearch Service。OpenSearch Dashboardsでデータを可視化。

・全文検索エンジン（ドキュメント検索、オートコンプリート等）
・ログ分析: VPC Flow Logs/CloudTrail/アプリログをリアルタイム分析・可視化
・Amazon Data Firehose(旧Kinesis Data Firehose)→OpenSearchのパイプラインが定番

試験頻出: 「全文検索」「ログのリアルタイム分析・可視化」→OpenSearch。Kinesis→OpenSearchの組み合わせでリアルタイムログ分析パイプライン

🚀

デプロイ・IaC

5 services

CloudFormation

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

・スタック: テンプレートから作成されるリソースの集合。一括作成・更新・削除
・StackSets: 複数アカウント/リージョンに同じテンプレートを一括展開
・ドリフト検出: 実際のリソースとテンプレートの差分を検出
・変更セット: 更新前にどのリソースが変更されるかプレビュー

試験頻出: 「インフラの再現可能なデプロイ」「環境の複製」「マルチリージョンに同じ環境」→CloudFormation(StackSets)

CodePipeline

Source→Build→Test→Deployの一連のCI/CDパイプラインを自動化するサービス。CodeCommit/GitHub等のソースからCodeBuild/CodeDeployまでをオーケストレーション。

・ステージ間の承認アクション(手動承認ゲート)も設定可能
・サードパーティ統合: GitHub, Jenkins等

試験頻出: SAA試験では深く出ないが、DevOps関連の選択肢として登場。CodeCommit→CodeBuild→CodeDeploy→CodePipelineのCI/CDフローを理解しておく

CodeBuild

ソースコードのコンパイル、テスト実行、デプロイパッケージ作成を行うフルマネージドビルドサービス。ビルドサーバーの管理不要。使った分だけ課金。

・buildspec.ymlでビルドコマンドを定義
・Docker環境でビルド実行、カスタムイメージも利用可能

試験頻出: CI/CDパイプラインの「ビルド」担当。CodeCommit(ソース)→CodeBuild(ビルド)→CodeDeploy(デプロイ)

CodeDeploy

EC2/Lambda/ECSへのアプリケーションデプロイを自動化するサービス。In-placeデプロイとBlue/Greenデプロイの2戦略をサポート。

In-place: 既存インスタンス上でアプリを入れ替え（ダウンタイムあり得る）
Blue/Green: 新環境(Green)を構築→トラフィック切替→旧環境(Blue)を削除。ダウンタイムゼロ
・appspec.ymlでデプロイ手順を定義

試験頻出: 「ダウンタイムゼロのデプロイ」→Blue/Greenデプロイ

Amazon ECR

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

・プライベートリポジトリ / パブリックリポジトリ(ECR Public Gallery)
・イメージスキャン: プッシュ時に自動で脆弱性スキャン（Inspector統合）
・ライフサイクルポリシー: 古いイメージの自動削除

試験頻出: ECS/EKSのコンテナ実行時のイメージ管理に使う。イメージスキャンで脆弱性検出も可能

💰

コスト管理

5 services

Cost Explorer

AWSの過去・現在のコストを可視化・分析し、将来のコストを予測するサービス。サービス別、アカウント別、タグ別など多次元でコストを掘り下げ可能。

・過去13ヶ月のコストデータを保持
・12ヶ月先までのコスト予測
・RI/Savings Plans推奨機能: 使用パターンを分析し、最適な購入オプションを提案
・タグでリソースを分類→部門別/プロジェクト別のコスト配分

試験頻出: 「コストの傾向を分析」「コスト予測」→Cost Explorer。Cost Explorer=分析、Budgets=アラート通知の使い分け

AWS Budgets

コスト/使用量/予約カバレッジの予算を設定し、閾値を超えた時にアラート通知を送るサービス。SNS通知やAuto Scaling等のアクションも自動実行可能。

・予算タイプ: コスト予算 / 使用量予算 / RI利用率予算 / SP利用率予算
・アラート: 実際値 or 予測値が閾値に達したら通知(Email/SNS)
・Budget Actions: 閾値超過時にIAMポリシー変更やEC2/RDS停止を自動実行

試験頻出: 「コストが閾値を超えたら通知」「予算超過アラート」→Budgets

Compute Optimizer

EC2/EBS/Lambda/ECS Fargateの使用パターンをMLで分析し、最適なリソースサイズ（インスタンスタイプ、メモリ設定等）を推奨するサービス。

・CloudWatchメトリクスを14日以上収集して分析
・推奨: オーバープロビジョニング(余剰)やアンダープロビジョニング(不足)を検出
・コスト削減額の見積もりも提示

試験頻出: 「EC2インスタンスタイプの最適化」「リソースの適正サイズ」→Compute Optimizer。Trusted Advisor(ベストプラクティス全般)との違いに注意

Savings Plans

1時間あたりの使用量($/hr)を1年or3年コミットすることで、最大72%の割引を受けられる料金プラン。RIより柔軟で、EC2/Lambda/Fargateを横断して適用可能。

Compute Savings Plans: EC2/Lambda/Fargate横断。インスタンスファミリー/リージョン/OS変更可能。最も柔軟
EC2 Instance Savings Plans: 特定のインスタンスファミリー+リージョンに限定。その分割引が大きい
・RIと異なりインスタンスを「予約」するのではなく、「使用量をコミット」する仕組み

試験頻出: 「柔軟性+割引」→Compute Savings Plans。「最大割引」→EC2 Instance SP or RI全額前払い。RIとの違い=SPの方が柔軟

Reserved Instances

EC2/RDS/ElastiCache/Redshift等の1年or3年の予約で割引を受ける購入オプション。安定した24/365稼働のワークロードに最適。

支払い: 全額前払い(最大割引) / 一部前払い / 前払いなし(最小割引)
Standard RI: インスタンスタイプ変更不可。最大の割引率
Convertible RI: インスタンスタイプ/OS等を変更可能。割引率はやや低い
・RIマーケットプレイスで不要なRIを売買可能(Standardのみ)

試験頻出: 「24/365安定稼働の本番DB」→RI(全額前払い)。「開発環境/断続利用」→オンデマンド。「中断可能バッチ」→スポット