AWS SAA-C03 やさしいサービス解説

各サービスを「たとえ話 + 具体例 + 似たサービスとの違い + 試験での出方」で理解する。検索して、開いて読むだけ。

サービス名でも、悩みのキーワードでも検索できます
該当するサービスが見つかりませんでした。別のキーワードでお試しください。
⚙ コンピューティング10 services
Amazon EC2クラウド上の仮想サーバー

🎯 ひとことで

AWSの中に自分専用のパソコン（サーバー）を1台借りるサービス。OSもアプリも自由に入れられる、いちばん基本のサービス。

💡 たとえると「電源とネット回線付きの空き部屋」を時間貸しで借りる感じ。部屋（サーバー）の中に何を置くか（OS・アプリ）は全部自分で決める。要らなくなったら返せば課金も止まる。

⚙️ 仕組み・ポイント

  • インスタンスタイプで性能を選ぶ：M(バランス) / C(CPU強め) / R(メモリ強め) / G・P(GPU)
  • 買い方で値段が大きく変わるのが最重要ポイント↓
買い方特徴向いている用途
オンデマンド使った分だけ。一番割高短期・読めない負荷
リザーブド(RI)1〜3年予約で最大75%引き24時間ずっと動かす本番
Savings PlansRIより柔軟に割引安定利用＋構成変更したい
スポット最大90%引き。ただし途中で止められる中断OKなバッチ処理
Dedicated Host物理サーバーを丸ごと占有ライセンスの縛りがある時
✅ 試験ではこう出る「中断OKで最安」→スポット ／ 「24時間365日動かす＋割引」→RI or Savings Plans ／ 「物理占有・ライセンス」→Dedicated Host
EC2 Auto Scalingサーバー台数を自動で増減

🎯 ひとことで

アクセスが増えたらEC2を自動で増やし、減ったら自動で減らす仕組み。お金とパフォーマンスの両方をムダなく保つ。

💡 たとえるとレジの行列が伸びたら店員を呼んで増やし、暇になったら帰すお店。お客（アクセス）の数に合わせてスタッフ（サーバー）を最適化する。

⚙️ 仕組み・ポイント（スケーリング方法4種）

  • ターゲット追跡：「CPU 70%を保つ」のように目標値を指定（一番よく使う）
  • ステップ：段階に応じて増やす量を変える
  • シンプル：1つの条件で固定数を増減
  • スケジュール：「平日9時に増やす」など時間で予約

ふつう ALB（ロードバランサー）+ Auto Scaling をセットで使い、増えたサーバーに自動で振り分ける。

✅ 試験ではこう出る「CPU使用率を一定に保つ」→ターゲット追跡 ／ 「平日だけ・決まった時間に増やす」→スケジュール
AWS Lambdaサーバーなしでコード実行

🎯 ひとことで

サーバーを一切用意せず、コードだけ置いておくと、何かが起きた瞬間だけ動いてくれるサービス。動いた時間だけ課金。

💡 たとえると「人感センサー付きの照明」。誰か来た（イベント発生）時だけパッと点いて、用が済んだら消える。点いている間だけ電気代がかかる＝待機コストがゼロに近い。

⚙️ 仕組み・ポイント

  • トリガー例：S3にファイルが置かれた／API Gatewayにリクエストが来た／定時になった
  • 最大実行時間は15分（これが重要な制約）
  • メモリ128MB〜10GB、使った分（リクエスト数×実行時間）だけ課金
  • たまにしか呼ばれないと初回が遅い（コールドスタート）→ Provisioned Concurrencyで対策
🔀 似たサービスとの違い処理が15分を超えるなら Lambda は使えない → 長時間バッチは AWS Batch / Fargate へ。
✅ 試験ではこう出る「イベント駆動・短時間・管理不要」→Lambda。API Gateway + Lambda はサーバーレスの王道パターン
Amazon ECSコンテナの管理・実行

🎯 ひとことで

Dockerコンテナ（アプリを箱詰めしたもの）を、AWS上で動かす・並べる・増減させるための管理役。

💡 たとえるとコンテナ＝「同じ規格の引っ越し箱」。ECSはその箱をどこのトラックに何個積むか采配する配車係。箱の中身（アプリ）は同じまま、どこでも同じように動く。

⚙️ 仕組み・ポイント（起動タイプ2種）

  • EC2起動タイプ：土台のサーバー(EC2)を自分で管理。GPUや細かい調整ができる
  • Fargate起動タイプ：土台を意識しない（サーバーレス）。楽だが少し割高
🔀 似たサービスとの違いECS＝AWS独自でシンプル。EKS＝Kubernetes互換。迷ったら「Kubernetesを使いたいか？」で決める。
✅ 試験ではこう出る「コンテナ＋AWS統合重視」→ECS ／ 「K8s互換」→EKS
Amazon EKSマネージドKubernetes

🎯 ひとことで

業界標準のコンテナ管理ツール「Kubernetes」を、AWSが面倒な部分を肩代わりして提供してくれるサービス。

💡 たとえるとKubernetesという「世界共通の配車システム」をそのまま使える状態でレンタル。だから他社クラウドやオンプレで作った設定（マニフェスト）をそのまま持ち込める。

⚙️ 仕組み・ポイント

  • Kubernetesと100%互換。kubectl / Helm などの既存ツールがそのまま使える
  • 土台はFargate または EC2ノードグループから選べる
  • EKS Anywhere：オンプレでも同じK8sを動かせる
✅ 試験ではこう出る「Kubernetes互換」「K8sのスキル・ツールを活かす」「マルチクラウドで移植したい」→EKS
AWS Fargateサーバーレスのコンテナ実行基盤

🎯 ひとことで

ECSやEKSのコンテナを、土台のサーバーを一切意識せずに動かせる実行エンジン。パッチもスケールも全自動。

💡 たとえると「車を持たずにタクシーに乗る」感覚。車（EC2）の整備・駐車・給油を気にせず、行きたい所（コンテナ実行）だけ伝えればいい。便利な分、運賃は少し高め。

⚙️ 仕組み・ポイント

  • CPU・メモリの量を指定するだけでコンテナが立ち上がる
  • EC2起動タイプよりコストは高いが運用負荷ほぼゼロ
  • ECS・EKSのどちらの土台としても使える
✅ 試験ではこう出る「コンテナを動かしたいが、サーバー管理はしたくない」→Fargate
Elastic BeanstalkWebアプリを丸ごと自動構築

🎯 ひとことで

アプリのコードを渡すだけで、裏でEC2・ロードバランサー・Auto Scalingなどを自動で組み立てて公開してくれるサービス（PaaS）。

💡 たとえると「材料を渡すと、調理から盛り付けまで全部やってくれるシェフ」。あなたはレシピ（コード）を用意するだけで、料理（インフラ）の段取りは任せられる。

⚙️ 仕組み・ポイント

  • 対応言語：Java / .NET / PHP / Node.js / Python / Ruby / Go / Docker
  • OSやランタイムの更新もAWSが面倒を見る
  • 裏ではCloudFormationが動いてリソースを管理している
🔀 似たサービスとの違いBeanstalk＝Webアプリを手軽にデプロイ。CloudFormation＝インフラ全体を細かく設計。手軽さ重視か、制御重視か。
✅ 試験ではこう出る「最小限の管理でWebアプリをデプロイ」「PaaS」→Beanstalk
Amazon Lightsailシンプルで定額のVPS

🎯 ひとことで

小さなサイトやアプリを、月額固定でサクッと立てられるシンプル版サーバー。EC2より設定が圧倒的に少ない。

💡 たとえるとEC2が「自分で家具を選ぶワンルーム」なら、Lightsailは「家具家電付きのマンスリーマンション」。考えることが少なく、料金も毎月一定で読みやすい。

⚙️ 仕組み・ポイント

  • 月額固定（計算・ストレージ・転送量込み）で料金が分かりやすい
  • WordPress・LAMP・Node.js などの雛形（ブループリント）が用意済み
  • 機能は限定的だが、その分シンプル
✅ 試験ではこう出る「簡単・安い・小規模」→Lightsail。深くは問われないが、選択肢の消去法で登場する
AWS Batch大量バッチ処理の実行

🎯 ひとことで

大量の「まとめて処理する系の仕事（バッチ）」を、キューに溜めて順番に・効率よく実行してくれるサービス。

💡 たとえるとクリーニング店の受付。出された洗濯物（ジョブ）を順番待ちの棚（キュー）に並べ、空いた洗濯機（サーバー）に自動で割り当てて回していく。

⚙️ 仕組み・ポイント

  • ジョブ定義（Docker）→ キューに投入 → 自動で実行環境を確保して処理
  • EC2・Fargate・スポットを自動で選んでコスト最適化
  • Lambdaの15分制限を超える長時間処理に向く
✅ 試験ではこう出る「大量バッチ・15分超・ジョブのスケジューリング」→Batch。短時間イベント→Lambda、長時間バッチ→Batch
AWS OutpostsAWSを自社内に設置

🎯 ひとことで

AWSのサーバー機器を物理的に自社のデータセンターに置くサービス。手元でAWSのAPIがそのまま使える。

💡 たとえるとクラウドという「遠くの大きな倉庫」の小型支店を、自分の家の隣に建てる感じ。近いから速いし、データを建物の外に出さなくて済む。

⚙️ 仕組み・ポイント

  • 機器の配送・設置・保守までAWSがやる（フルマネージド）
  • EC2・EBS・S3・RDS・ECS などがオンプレ側で動く
  • AWSリージョンと繋がり、一元管理できる
✅ 試験ではこう出る「超低レイテンシーでオンプレ連携」「データを国内に保持（データレジデンシー）」→Outposts
🗃 ストレージ17 services
Amazon S3万能オブジェクトストレージ

🎯 ひとことで

容量無制限で、写真・動画・バックアップ・ログなどあらゆるファイルをネット越しに置ける倉庫。AWSで最も使われる基盤サービス。

💡 たとえると無限に広がる「貸し倉庫」。1つの荷物（オブジェクト）にラベル（キー）を付けて預け、URLで取り出す。倉庫の棚にも高い棚（すぐ出せる）〜激安の地下倉庫（出すのに時間がかかる）のランクがある。

⚙️ 仕組み・ポイント（ストレージクラス＝棚のランク）

  • Standard：普通によく使うデータ
  • Standard-IA / One Zone-IA：たまにしか使わない（低頻度）データ。安い
  • Glacier 系：アーカイブ用。取り出しに時間がかかる代わりに激安
  • Intelligent-Tiering：アクセス頻度をAWSが見て自動で最適な棚に移す

他にも：バージョニング（履歴保存）／ライフサイクル（自動で安い棚へ移動）／CRR（別リージョンへ複製）／暗号化（SSE-S3 / SSE-KMS / SSE-C）。

✅ 試験ではこう出る「最小コストで長期保存」→Glacier Deep Archive ／ 「アクセス頻度が読めない」→Intelligent-Tiering ／ 「暗号化を監査したい」→SSE-KMS
S3 Object Lambda取得時にデータを動的加工

🎯 ひとことで

S3からファイルを取り出す瞬間にLambdaを挟んで、中身をその場で加工して返す仕組み。元のファイルは1つのまま、相手に応じて違う見せ方ができる。

💡 たとえると倉庫(S3)から品物を出す時に、受け取る人に合わせて“加工してから渡す仕分け係(Lambda)”。ある人には個人情報を黒塗り、ある人には縮小版、という具合。元の品物は保管したまま。

⚙️ 仕組み・ポイント

  • GET時にLambdaで変換(個人情報マスキング・リサイズ・フォーマット変換・フィルタ)
  • S3アクセスポイント経由で適用
  • 加工版を別途保存しないので、元データを複製せず管理がシンプル
✅ 試験ではこう出る「S3取得時にデータを動的に加工/マスキングして返す(元データは変えない)」→S3 Object Lambda
S3 Glacier激安アーカイブ保管

🎯 ひとことで

めったに使わないデータをとにかく安く長期保管する専用ストレージ。取り出しに時間がかかる代わりに激安。

💡 たとえると「トランクルームの最奥」や「銀行の貸金庫」。普段は出さない大事な書類を格安で預けるが、取り出すには手続きと待ち時間が要る。

⚙️ 仕組み・ポイント（3つのティア＝取り出し速度の違い）

ティア取り出しアクセス頻度の目安
Instant Retrievalミリ秒四半期に1回くらい
Flexible Retrieval数分〜12時間年1〜2回
Deep Archive12時間年1回以下・最安
✅ 試験ではこう出る「7〜10年保存・ほぼ取り出さない」→Deep Archive。S3ライフサイクルで自動移行が定番
Amazon EBSEC2の仮想ディスク

🎯 ひとことで

EC2にくっつけて使う外付けハードディスク（仮想ディスク）。OSやデータベースのデータを保存する。

💡 たとえるとパソコン本体（EC2）に挿す「SSD/HDD」。本体を捨ててもディスクを別の本体に挿し替えられる。ただし1台のパソコンに挿す前提で、同じAZ（建物）の中だけ。

⚙️ 仕組み・ポイント

  • gp3/gp2：汎用SSD。だいたいこれでOK
  • io2/io1：高速SSD。DBなど高い性能が要る時
  • st1：スループット重視HDD（ログ・ビッグデータ）／sc1：コールドHDD（安い大容量）
  • 単一AZに紐づく。スナップショットを取るとS3にバックアップされる
🔀 似たサービスとの違いEBS＝1台のEC2用ディスク。EFS＝複数EC2で共有するファイル置き場。S3＝ネット越しのオブジェクト倉庫。
✅ 試験ではこう出る「高IOPSなDB用ディスク」→io2 ／ 「ログ・大容量」→st1。「EBSは単一AZ」は頻出
Amazon EFS複数EC2で共有するファイル置き場

🎯 ひとことで

複数のEC2から同時にアクセスできる共有ファイル置き場。容量は自動で伸び縮みし、複数AZにまたがって壊れにくい。

💡 たとえるとオフィスの「共有ネットワークドライブ」。何人（何台）でも同じフォルダを開いて読み書きできる。EBSが個人のUSBメモリなら、EFSはみんなの共有フォルダ。

⚙️ 仕組み・ポイント

  • NFSプロトコル／Linux専用（Windowsで共有したいなら FSx for Windows）
  • 容量は使った分だけ自動で拡張・縮小
  • ライフサイクルで低頻度クラス(IA)へ自動移行してコスト削減
✅ 試験ではこう出る「複数EC2から共有アクセス・NFS」→EFS。Windowsなら→FSx for Windows
Amazon FSx用途特化のファイルストレージ

🎯 ひとことで

「特定のOSや用途に合わせた専用ファイルサーバー」をマネージドで提供。4種類あり、どれを選ぶかが問われる。

💡 たとえるとEFSが「汎用の共有フォルダ」なら、FSxは「用途別の専門店」。Windows専門・超高速計算専門…と、目的に最適化された棚が選べる。

⚙️ 仕組み・ポイント（4種）

  • FSx for Windows File Server：SMB＋Active Directory統合。Windowsファイル共有
  • FSx for Lustre：HPC・機械学習向けの超高速。S3と透過連携
  • FSx for NetApp ONTAP：NFS/SMB/iSCSIのマルチプロトコル
  • FSx for OpenZFS：Linux向け高性能
✅ 試験ではこう出る「Windows共有・SMB・AD統合」→FSx for Windows ／ 「HPC・機械学習・S3連携」→FSx for Lustre
Storage GatewayオンプレとAWSストレージの橋渡し

🎯 ひとことで

オンプレのアプリから、AWSのストレージ(S3/EBS/Glacier)を“すぐ近くにあるように”使える橋渡し装置。手元にキャッシュを置くので速い。

💡 たとえると「クラウド倉庫への宅配窓口」を自社内に置く感じ。よく使う物は窓口の棚（キャッシュ）に置いておき、それ以外は裏のクラウド倉庫から自動で取り寄せる。

⚙️ 仕組み・ポイント（3種）

  • File Gateway：NFS/SMB → S3。ファイル共有のクラウド拡張（最頻出）
  • Volume Gateway：iSCSI → EBSスナップショット
  • Tape Gateway：仮想テープ → S3/Glacier。テープバックアップ置き換え
🔀 似たサービスとの違いStorage Gateway＝常時つなぎっぱなしでリアルタイム利用。DataSync＝一括転送・定期同期（移行プロジェクト）。
✅ 試験ではこう出る「オンプレから常時AWSストレージを使う」→Storage Gateway
Snow Family物理デバイスでデータ運搬

🎯 ひとことで

ネット転送だと何週間もかかる大量データを、物理デバイスに入れて宅配便で運んでAWSに移すサービス。

💡 たとえると巨大ファイルをアップロードするより、HDDに入れて宅配で送った方が速い状況。「トラックいっぱいのデータは、高速道路より物理的に運んだ方が速い」という発想。

⚙️ 仕組み・ポイント

  • Snowcone：8〜14TB。手のひらサイズ
  • Snowball Edge：80TB。エッジで簡単な計算(Lambda/EC2)も実行可
  • Snowmobile：100PB。コンテナトラックで運ぶ超大容量
✅ 試験ではこう出る「数十TB以上をネット転送すると数週間かかる」→Snow Familyを検討。回線が細い・データが巨大、がキーワード
AWS Backup複数サービスのバックアップを一元管理

🎯 ひとことで

EC2・EBS・RDS・DynamoDB・EFS などバラバラなサービスのバックアップを、1か所のルールでまとめて管理するサービス。

💡 たとえると家中の色々な機器のバックアップを、各自バラバラにやるのではなく「毎週日曜に全部まとめて保存、30日で古いのは削除」と一つの方針で集中管理する執事。

⚙️ 仕組み・ポイント

  • バックアッププランでスケジュールと保持期間をポリシー化
  • クロスリージョン／クロスアカウントのバックアップに対応
  • Organizationsと統合して複数アカウントを一括管理
✅ 試験ではこう出る「複数サービスのバックアップを一元化・自動化」「コンプライアンスでバックアップ必須」→AWS Backup
AWS DataSync大量データを高速・自動で転送

🎯 ひとことで

オンプレのファイルサーバーからS3/EFS/FSxへ、高速かつ自動でデータをコピー・同期するサービス。移行や定期バックアップに使う。

💡 たとえると「全自動の引っ越し業者」。荷物（データ）を運び、ちゃんと届いたか検品（整合性チェック）までやってくれる。一回の大移動にも、毎晩の差分同期にも使える。

⚙️ 仕組み・ポイント

  • ネット経由で最大10Gbpsの高スループット＋自動で整合性チェック
  • スケジュール設定で定期的な差分同期ができる
  • オンプレにDataSyncエージェントを入れて使う
✅ 試験ではこう出るDataSync＝一括転送/定期同期（移行）、Storage Gateway＝常時接続でリアルタイム利用。この使い分けが頻出
Transfer FamilyサーバーレスSFTP→S3/EFS

🎯 ひとことで

昔ながらのSFTP/FTPSでのファイルやり取りを、サーバーを立てずにS3/EFSへ直結させるサービス。既存の取引先のやり方を変えずに済む。

💡 たとえると取引先が「いつものSFTPで送るよ」と言ってくる。その受け口だけAWSが用意し、届いたファイルは自動でS3の倉庫へ。受付窓口の運用を全部おまかせにできる。

⚙️ 仕組み・ポイント

  • 対応プロトコル：SFTP / FTPS / FTP / AS2
  • 保存先：S3 または EFS
  • 認証：IAM / Managed AD / カスタム(Lambda)。サーバーの構築・パッチ不要
✅ 試験ではこう出る「既存のSFTPでファイルをS3に受け渡し」「サーバー管理なしのSFTP」→Transfer Family
Elastic Disaster Recovery低コストのサーバー丸ごとDR

🎯 ひとことで

オンプレや他クラウドのサーバーを丸ごとAWSに常時コピーしておき、災害時に数分でEC2として起動する低コストDRサービス（旧CloudEndure / 略称DRS）。

💡 たとえると本番マシンの「影武者」をAWSに薄く待機させておく。普段は最小コストの待機状態で、本番が倒れた瞬間に影武者がフル稼働して身代わりになる。

⚙️ 仕組み・ポイント

  • ブロックレベルの継続レプリケーションでRPO数秒・RTO数分
  • 平常時は安いステージング領域だけ稼働 → フェイルオーバー時にフル起動
  • 復旧後に元環境へ戻すフェイルバックも可能
🔀 似たサービスとの違いAWS Backup＝データの定期バックアップ。DRS＝サーバーを丸ごと素早く復旧（DR）。守る対象が「データ」か「稼働そのもの」か。
✅ 試験ではこう出る「低コストでRTO/RPOを最小化するDR」「サーバー丸ごとのDR」→Elastic Disaster Recovery
Application Migration Serviceサーバーを丸ごとEC2へ移行（MGN）

🎯 ひとことで

オンプレや他クラウドのサーバーを、中身ほぼそのまま（リホスト＝リフト&シフト）AWSのEC2へ移行する主力サービス（旧CloudEndure Migration、略称MGN）。

💡 たとえると家を建て直さず「家財道具ごとそっくり引っ越す」イメージ。中身（OS・アプリ）はいじらず、置き場所だけAWSへ移す。一番手間の少ない移行方法。

⚙️ 仕組み・ポイント

  • エージェントでサーバーを継続レプリケート → 最小ダウンタイムでEC2へカットオーバー
  • 本番切替前にテスト用インスタンスを起動して動作確認できる
🔀 似たサービスとの違いDRSと仕組みは兄弟。MGN＝移行（一度きりの引っ越し）、DRS＝災害復旧（常時待機）。DMS＝DBの移行、DataSync＝ファイルの移行、MGN＝サーバー丸ごと。
✅ 試験ではこう出る「サーバー群を最小ダウンタイムでEC2へリホスト/リフト&シフト」→MGN
Migration Hub移行の進捗を一元管理

🎯 ひとことで

いろいろな移行ツール（MGN/DMS等）を使った移行プロジェクトの進み具合を、1か所のダッシュボードでまとめて追跡・可視化するサービス。

💡 たとえると大規模な引っ越しの「進捗管理ボード」。どの部屋（サーバー/アプリ）がどこまで運び終わったかを一覧で把握できる司令塔。

⚙️ 仕組み・ポイント

  • Application Migration Service / DMS などの移行状況を集約して可視化
  • Discovery Service でオンプレの構成・依存関係を事前に把握できる
✅ 試験ではこう出る「複数サービスにまたがる移行の進捗を一元管理・可視化」→Migration Hub
Application Discovery Service移行前にオンプレを棚卸し

🎯 ひとことで

移行を始める前に、オンプレのサーバー構成・使用状況・サーバー同士のつながり(依存関係)を自動で調べて、移行計画を立てやすくするサービス。

💡 たとえると引っ越し前の「家財の棚卸し＋配線チェック」。どの機器がどれと繋がっているかを把握しておけば、何を一緒に運ぶべきか・何が止まると困るかが分かり、移行の失敗を防げる。

⚙️ 仕組み・ポイント

  • エージェントレス(VMware vCenter経由)とエージェント型を選べる
  • CPU/メモリ使用率・稼働プロセス・ネットワーク接続を収集
  • 収集データはMigration Hubに集約して可視化・計画に利用
🔀 移行の流れDiscovery(把握) → Migration Hub(計画・進捗) → MGN/DMS(実行)。Discoveryは“移行の入口”。
✅ 試験ではこう出る「移行前にオンプレの構成・依存関係を把握・棚卸し」→Application Discovery Service
App2Container (A2C)既存アプリをコンテナ化

🎯 ひとことで

今動いているJava/.NETのアプリを、コードを書き換えずにコンテナ化して、ECS/EKSで動かせる形(イメージ＋デプロイ定義)に自動変換してくれるCLIツール。

💡 たとえると昔ながらの料理(既存アプリ)を、レシピは変えずに「どこでも同じに作れる冷凍パック(コンテナ)」に詰め直してくれる加工屋。中身は同じまま、扱いやすい形にしてくれる。

⚙️ 仕組み・ポイント

  • 稼働中アプリを分析→依存関係を含めてコンテナイメージ化
  • ECS/EKS/App Runner用のデプロイ定義(CloudFormation)とECR登録まで生成
  • サーバー丸ごとの移行(MGN)ではなく、アプリの「コンテナへのリプラットフォーム」
🔀 使い分けMGN＝サーバーをそのままEC2へ(リホスト)。App2Container＝アプリをコンテナ化してECS/EKSへ(モダナイズ)。
✅ 試験ではこう出る「既存のJava/.NETアプリをコンテナ化してECS/EKSへ」→App2Container
Migration Evaluator移行のコスト効果を試算

🎯 ひとことで

今のオンプレ環境を調べて、AWSに移行したらどれくらい安くなるか(投資対効果)を試算し、移行のビジネスケースを作るサービス(旧TSO Logic)。

💡 たとえると引っ越し前の「見積もり・費用対効果シミュレーション」。今の家賃(オンプレ費用)と引っ越し後の家賃(AWS費用)を比べて、「移った方がいくら得か」を経営層に示す資料を作る。

⚙️ 仕組み・ポイント

  • 現行の使用状況を収集し、AWS移行後のコストを予測
  • 移行の投資対効果(ビジネスケース)をレポート化
  • 「移行すべきか/どれだけ安くなるか」の意思決定を支援
🔀 似たものとの違い構成・依存関係の“把握”はApplication Discovery Service、進捗管理はMigration Hub、コスト効果の“試算”がMigration Evaluator。
✅ 試験ではこう出る「AWS移行のコスト削減効果・ビジネスケースを試算したい」→Migration Evaluator
📊 データベース12 services
Amazon RDSマネージドな普通のRDB

🎯 ひとことで

MySQLやPostgreSQLなど定番のリレーショナルDBを、面倒な管理（バックアップ・パッチ・冗長化）はAWS任せで使えるサービス。

💡 たとえると自分でDBサーバーを建てて世話するのが「持ち家＋自分でメンテ」なら、RDSは「メンテ付き賃貸」。住み心地（DBの中身）は同じで、設備の保守だけ大家(AWS)がやる。

⚙️ 仕組み・ポイント（最重要な2つを混同しない）

Multi-AZリードレプリカ
目的可用性（壊れたら自動切替）性能（読み取りを分散）
複製方式同期非同期
使う場面障害時のフェイルオーバー読み取りが多くて重い

自動バックアップ最大35日＋手動スナップショットは無期限。

✅ 試験ではこう出るMulti-AZ=フェイルオーバー用、リードレプリカ=読み取り分散用の違いは超頻出。「Oracle/SQL Serverを使いたい」→RDS一択
RDS ProxyDBへの接続をプールして共有

🎯 ひとことで

RDS/Auroraへの接続を使い回して共有する仲介役。特にLambdaのように短い接続が大量に来る場面で、DBの接続数が枯渇するのを防ぐ。

💡 たとえるとDBへの入口に置く「相乗りタクシー乗り場」。全員が個別にタクシー(接続)を呼ぶと足りなくなるので、乗り場でまとめて相乗りさせ、限られた台数を効率よく回す。

⚙️ 仕組み・ポイント

  • コネクションプールで接続を再利用し、DB側の接続数を抑制
  • フェイルオーバー時間を短縮(プロキシがアプリの再接続を肩代わり)
  • Secrets Managerと統合して認証、IAM認証にも対応
✅ 試験ではこう出る「Lambda等からRDSへの大量接続で接続枯渇・性能低下」→RDS Proxy
Amazon AuroraAWS製の高性能RDB

🎯 ひとことで

RDSの強化版。MySQL/PostgreSQL互換のまま性能・可用性・自動拡張を大幅に底上げしたAWS独自開発のDB。

💡 たとえると同じ「メンテ付き賃貸」でも、Auroraは免震構造でハイスペックな高級物件。データを自動で3つのAZに6コピー保管するので地震（障害）に滅法強い。

⚙️ 仕組み・ポイント

  • MySQLの5倍／PostgreSQLの3倍のスループット、最大128TBまで自動拡張
  • Aurora Serverless：使用量に応じて自動スケール。不規則な負荷に最適
  • Global Database：別リージョンへ1秒以内で複製。クロスリージョンDR
  • リードレプリカ最大15台
✅ 試験ではこう出る「高可用性RDB＋コスト最適化」→Aurora ／ 「使用頻度が不規則」→Aurora Serverless ／ 「クロスリージョンDR」→Global Database
Aurora Global DatabaseAuroraを複数リージョンへ複製

🎯 ひとことで

Auroraを複数リージョンにまたがって展開し、メインのリージョンから他リージョンへ1秒未満でデータをコピーする機能。地域災害への備え(DR)と、世界各地での速い読み取りを両立する。

💡 たとえると本店(プライマリ)の帳簿を、各地の支店(セカンダリ)にほぼリアルタイムで写し続ける。本店が被災しても、支店が即座に本店へ昇格して営業を続けられる。

⚙️ 仕組み・ポイント

  • 1プライマリ＋最大5セカンダリリージョン、各リージョンで読み取り可能
  • 専用インフラで複製、通常RPO約1秒・RTO約1分
  • リージョン障害時はセカンダリを昇格して継続
🔀 似たものとの違いMulti-AZ＝同一リージョン内の可用性(AZ障害対策)。Global Database＝リージョンをまたぐDR・グローバル読み取り。読み取り分散だけならリードレプリカ。
✅ 試験ではこう出る「RDBでクロスリージョンDR・低RPO/RTO・グローバル低遅延読み取り」→Aurora Global Database
Amazon DynamoDB超高速・無限スケールのNoSQL

🎯 ひとことで

キーを指定すると1桁ミリ秒で値が返る、容量無制限のNoSQL。サーバー管理もキャパシティの心配も不要。

💡 たとえると巨大な「ロッカー」。番号（キー）を言えば一瞬で中身が出てくる。中を一覧で眺めたり複雑な条件で探したりは苦手だが、番号での出し入れは爆速＆いくらでも増設できる。

⚙️ 仕組み・ポイント

  • キャパシティ：オンデマンド(自動) / プロビジョンド(予約)
  • DAX：DynamoDB専用キャッシュ。応答をマイクロ秒に
  • グローバルテーブル：複数リージョンでアクティブ-アクティブ複製
  • ストリーム：変更をリアルタイム検知してLambda起動など
🔀 似たサービスとの違い複雑なJOINやトランザクションが必要 → RDS/Aurora。単純なキー検索を爆速・大量に → DynamoDB。
✅ 試験ではこう出る「キーバリュー・ミリ秒・サーバーレスDB・セッション管理」→DynamoDB
Amazon ElastiCacheインメモリキャッシュ

🎯 ひとことで

Redis/Memcachedを使った超高速メモリ上のキャッシュ。DBへのアクセスを肩代わりして読み取り負荷を減らす。

💡 たとえるとよく使う資料を毎回書庫(DB)に取りに行かず、手元の付箋・メモ(メモリ)に控えておく。取りに行く手間が消えるので一瞬で答えられる。

⚙️ 仕組み・ポイント

  • Redis：高機能。レプリケーション・永続化・Multi-AZ・ランキング(ソート済みセット)・Pub/Sub
  • Memcached：シンプルで速い。マルチスレッド。永続化なし
✅ 試験ではこう出る「DBの読み取り負荷を減らす・セッション管理」→ElastiCache。「高可用性/永続化/ランキング」→Redis、「単純キャッシュだけ」→Memcached
Amazon Redshift分析用データウェアハウス

🎯 ひとことで

大量データに対する分析・集計クエリを高速で回すためのデータウェアハウス。BIダッシュボードや定常レポートの土台。

💡 たとえるとRDSが「日々の伝票を1枚ずつ処理する窓口」なら、Redshiftは「全伝票を集計して経営レポートを作る分析室」。大量データの集計が桁違いに速い（列指向ストレージのため）。

⚙️ 仕組み・ポイント

  • Spectrum：S3上のデータをロードせず直接SQLクエリ
  • Serverless：キャパシティ管理不要のサーバーレス版
  • 同時実行スケーリングで急なクエリ増加に自動対応
✅ 試験ではこう出るOLTP(取引)→RDS/Aurora、OLAP(分析)→Redshift。「大量データの定常的な分析・BI」がキーワード
Amazon Neptune関係性を扱うグラフDB

🎯 ひとことで

「AさんとBさんは友達」「この商品とあの商品は一緒に買われる」といった“つながり・関係性”を高速にたどる専用DB。

💡 たとえると人物相関図や路線図のようなもの。「この人の友達の友達は？」を、表をいちいち結合せず線をたどるだけで一瞬で探せる。

⚙️ 仕組み・ポイント

  • Property Graph(Gremlin) と RDF(SPARQL) の両方をサポート
  • リードレプリカ最大15台、Multi-AZ対応
✅ 試験ではこう出る「ソーシャルネットワーク・推薦エンジン・不正検出・関係性の探索」→Neptune
Amazon DocumentDBMongoDB互換のドキュメントDB

🎯 ひとことで

MongoDB互換で、JSONのような柔軟なドキュメントを保存・検索できるマネージドDB。MongoDBの移行先。

💡 たとえるとカチッと決まった表（RDB）ではなく、項目がバラバラでもOKな自由形式のカード（JSON文書）を大量に保管する仕組み。

⚙️ 仕組み・ポイント

  • MongoDB 3.6/4.0/5.0互換API
  • ストレージは自動で3AZに6コピー、最大64TB
🔀 似たサービスとの違いDynamoDB＝キーバリュー型。DocumentDB＝ドキュメント(JSON)型でMongoDB互換。
✅ 試験ではこう出る「MongoDB互換・ドキュメント型NoSQL」→DocumentDB
Amazon QLDB改ざん検知できる台帳DB

🎯 ひとことで

正式名 Quantum Ledger Database＝「台帳（帳簿）」のDB。過去の記録が書き換えられていないことを暗号的に証明できるのが最大の特徴。

💡 たとえると銀行の通帳。普通のDBは「残高800円」と過去を上書きできてしまうが、QLDBは入出金の履歴が鎖のように連鎖して記録され、途中をこっそり変えると必ずバレる。

⚙️ 仕組み・ポイント

  • 全ての変更がイミュータブル（変更不可）なジャーナルに記録される
  • SHA-256のハッシュチェーンで改ざんを暗号的に検証できる
🔀 ブロックチェーンとの違いブロックチェーン（Bitcoin等）はみんなで分散管理。QLDBはAWSが1つの中央DBで管理。だから速くて運用が楽、でも分散はしない。分散台帳が欲しいなら Managed Blockchain。
✅ 試験ではこう出る「変更履歴を残したい」ではなく 「改ざんされていないことを証明したい」「監査証跡」「イミュータブル」 が出たら→QLDB。※ニッチなサービスで、キーワード反応で十分（QLDBは新規利用停止・2025年でサポート終了）
Amazon KeyspacesCassandra互換DB

🎯 ひとことで

Apache Cassandra互換のマネージドDB。既存のCassandraアプリをコード変更なしで移せる。

💡 たとえると「Cassandraという方言をそのまま喋れる、運用おまかせのDB」。今あるCassandra用のコードをそのまま持ち込める。

⚙️ 仕組み・ポイント

  • CQL(Cassandra Query Language)互換
  • オンデマンド/プロビジョンドのキャパシティ
✅ 試験ではこう出る「Cassandra互換・Cassandraの移行」→Keyspaces。深くは出ないが選択肢で登場
AWS DMSDBをAWSへ移行

🎯 ひとことで

データベースをほぼ止めずにAWSへ引っ越しさせるサービス。同じ種類同士でも、別エンジンへの引っ越しでも対応。

💡 たとえると営業中のお店を閉めずに引っ越す引っ越し業者。営業しながら少しずつ荷物を運び、最後の一瞬だけ切り替えるのでお客（サービス）への影響が最小。

⚙️ 仕組み・ポイント

  • 継続的レプリケーション(CDC)：移行中の変更も追従し、切替時のダウンタイムを最小化
  • SCT(Schema Conversion Tool)：異種DB間でスキーマやストアドプロシージャを自動変換（例：Oracle→Aurora）
  • 移行先：RDS / Aurora / Redshift / DynamoDB / S3 など
🔀 似たサービスとの違いDMS＝データベースの移行、DataSync＝ファイルの移行。対象が「DB」か「ファイル」か。
✅ 試験ではこう出る「DBを最小ダウンタイムで移行」→DMS ／ 「異種DBエンジンへ移行」→DMS＋SCT
🌐 ネットワーク14 services
Amazon VPC自分専用の仮想ネットワーク

🎯 ひとことで

AWSの中に作る自分専用の区切られたネットワーク。サブネットの分割やアクセス制御を自分で設計する、全リソースの土台。

💡 たとえると大きなビルの中に借りる「自社フロア」。フロア内を部屋（サブネット）に区切り、表玄関（パブリック）と奥の金庫室（プライベート）を分け、ドアごとに通行ルール（SG/NACL）を決める。

⚙️ 仕組み・ポイント（SGとNACLの違いが最重要）

セキュリティグループ(SG)NACL
適用範囲インスタンス単位サブネット単位
性質ステートフル(戻りは自動許可)ステートレス(in/out両方要設定)
ルール許可のみ許可＋拒否、番号順に評価

NAT Gateway＝プライベートサブネットから外向き通信だけ通す出口。

✅ 試験ではこう出る「SG=ステートフル / NACL=ステートレス」の違い、パブリック/プライベートサブネット設計、NAT Gatewayの役割が頻出
VPCエンドポイントAWSサービスへ非インターネット接続

🎯 ひとことで

VPCの中からS3やDynamoDBなどのAWSサービスへ、インターネットを通らずに直接つなぐ仕組み。安全で速い。

💡 たとえると普段は表通り（インターネット）を通って隣のビルに行くところを、ビル同士をつなぐ専用の連絡通路を作る感じ。外を通らないので安全、しかも近道。

⚙️ 仕組み・ポイント（2種類）

  • ゲートウェイエンドポイント：S3/DynamoDB専用。無料。ルートテーブルに追加
  • インターフェースエンドポイント(PrivateLink)：その他のサービス用。ENI経由。有料
✅ 試験ではこう出る「インターネットを経由せずにS3アクセス」→ゲートウェイエンドポイント(無料)。S3/DynamoDBはゲートウェイ型、それ以外はインターフェース型
Internet Gateway (IGW)VPCのインターネット出入口

🎯 ひとことで

VPCをインターネットにつなぐ出入口。パブリックサブネットのリソースが、外と双方向（行きも帰りも）で通信できるようになる。

💡 たとえると自社ビル（VPC）の「正面玄関」。ここを通って外の世界（インターネット）と人が出入りできる。玄関を使うには通行証（パブリックIP）が要る。

⚙️ 仕組み・ポイント

  • VPCに1つアタッチ → パブリックサブネットのルートテーブルに 0.0.0.0/0 → IGW を追加
  • 通信するリソースにパブリックIP / Elastic IPが必要
🔀 似たものとの違いIGW＝パブリック向け（双方向）。NAT Gateway＝プライベートの外向きのみ。VPCエンドポイント＝AWSサービスへ非公開接続。
✅ 試験ではこう出る「パブリックサブネットからインターネットに接続」→IGW
NAT Gatewayプライベートの外向き通信だけ通す

🎯 ひとことで

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

💡 たとえると建物の「一方通行の通用口」。中の人は外に出て買い物（パッチ取得など）できるが、外から勝手に入ってくることはできない。だから安全。

⚙️ 仕組み・ポイント

  • NAT Gatewayはパブリックサブネットに置き、IGW経由で外へ出る
  • プライベートサブネットのルートテーブルに 0.0.0.0/0 → NAT Gateway を追加
  • 高可用性はAZ単位。マルチAZにするには各AZにNAT Gatewayを置く
🔀 似たものとの違いNATインスタンス(旧式)はEC2を自前管理。NAT Gatewayはフルマネージドで自動スケール・高可用。試験では「NATインスタンス→NAT Gatewayへ移行」が定番。
✅ 試験ではこう出る「プライベートのEC2をパッチ更新等で外に出したい（インバウンドは不要）」→NAT Gateway
Elastic Load Balancingトラフィックを自動で振り分け

🎯 ひとことで

受け取ったアクセスを複数のサーバーに自動で振り分ける係。1台に集中させず、高可用性とスケールを支える。

💡 たとえると銀行やレジの「こちらの窓口へどうぞ」と案内する整理係。お客（リクエスト）を空いている窓口（サーバー）に均等に振り分け、故障中の窓口には案内しない。

⚙️ 仕組み・ポイント（3種・どれを選ぶかが問われる）

  • ALB：L7(HTTP/HTTPS)。パス/ホスト単位の振り分け、WebSocket、Cognito認証
  • NLB：L4(TCP/UDP)。超低レイテンシー、毎秒数百万、静的IP対応
  • GWLB：L3。サードパーティのFW/IDSを透過的にスケール
✅ 試験ではこう出る「Webアプリ」→ALB ／ 「極低レイテンシー/静的IP/非HTTP」→NLB ／ 「セキュリティアプライアンス」→GWLB
Amazon CloudFront世界中に高速配信するCDN

🎯 ひとことで

コンテンツを世界中の拠点(エッジ)にキャッシュして、ユーザーの近くから配信するCDN。表示を速くし、攻撃からも守る。

💡 たとえると本社（オリジン）まで毎回取りに行くのではなく、各地の支店(エッジ)に在庫を置いておく。近所の支店から届くので速いし、本社の負担も減る。

⚙️ 仕組み・ポイント

  • OAC：S3を直接公開せず、CloudFront経由のみ許可
  • Lambda@Edge / CloudFront Functions：エッジでコードを実行（リクエスト加工）
🔀 似たサービスとの違いCloudFront＝コンテンツをキャッシュ(HTTP中心)。Global Accelerator＝キャッシュせずTCP/UDPの経路を最適化。
✅ 試験ではこう出る「グローバル配信・S3の静的コンテンツ配信」→CloudFront。セキュリティ3点セット＝CloudFront＋Shield＋WAF
Amazon Route 53DNS＋賢いルーティング

🎯 ひとことで

ドメイン名(example.com)をIPに変換するDNS。さらに「どのサーバーに案内するか」を状況に応じて賢く振り分けられる。

💡 たとえると電話の総合受付。かかってきた電話(アクセス)を、一番近い支店・一番空いている窓口・生きている窓口へ自動で取り次ぐ交換手。

⚙️ 仕組み・ポイント（ルーティング6種）

  • シンプル / 加重(比率・カナリア) / レイテンシー(最速リージョン)
  • フェイルオーバー(障害時にセカンダリへ) / 地理的位置 / マルチバリュー
✅ 試験ではこう出る「アクティブ-パッシブDR」→フェイルオーバー＋ヘルスチェック（超頻出）／ 「カナリアデプロイ」→加重 ／ 「最速応答」→レイテンシー
Route 53 Resolverオンプレ⇔AWSのDNS名前解決

🎯 ひとことで

VPCとオンプレミスの間で、お互いのDNS(名前→IP変換)を引けるようにするハイブリッドDNS。「オンプレからAWS内の名前を引く」「AWSからオンプレの名前を引く」を両方実現。

💡 たとえると社内(オンプレ)と支社(AWS)で別々の「電話帳(DNS)」を持っているのを相互に照会できるようにする取次窓口。相手側の内線番号(名前)も引けるようになる。

⚙️ 仕組み・ポイント

  • インバウンドエンドポイント: オンプレ→VPC内(Route 53)の問い合わせを受ける
  • アウトバウンドエンドポイント: VPC→オンプレDNSへ問い合わせを転送
  • Forward(転送)ルール: 「このドメインだけオンプレDNSへ」と条件付き転送
✅ 試験ではこう出る「オンプレとAWSでDNS名前解決を相互に(ハイブリッドDNS)」→Route 53 Resolver
API GatewayAPIの作成・公開・管理

🎯 ひとことで

APIの受付・認証・流量制限などをまとめて引き受ける玄関口。Lambdaと組ませてサーバーレスAPIを作る定番。

💡 たとえると会社の「総合受付＋警備員」。来訪者(リクエスト)の身元確認(認証)、混雑時の入場制限(スロットリング)をして、適切な担当(Lambda)に取り次ぐ。

⚙️ 仕組み・ポイント

  • スロットリング(レート制限)でAPIを守る／レスポンスキャッシュで高速化
  • 認証：IAM / Cognito User Pool / Lambdaオーソライザー
  • ステージ(dev/prod)でバージョン管理
✅ 試験ではこう出るLambda＋API Gateway＝サーバーレスの定番。REST→API Gateway、GraphQL→AppSync
AWS Direct ConnectオンプレとAWSを専用線で接続

🎯 ひとことで

自社データセンターとAWSを専用線で直結。インターネットを通らないので、帯域が安定し低レイテンシー。

💡 たとえると一般道（インターネット）ではなく、自社とAWSを結ぶ専用の高速道路を敷設する。渋滞（混雑）の影響を受けず、いつも一定の速さで通れる。ただし開通に時間がかかる。

⚙️ 仕組み・ポイント

  • 1/10/100Gbps の専用接続。セットアップに数週間〜数ヶ月
  • デフォルトでは暗号化なし（必要ならVPNを重ねる）
✅ 試験ではこう出る「安定帯域・低レイテンシー・ハイブリッド」→Direct Connect。冗長化はDX＋VPNバックアップ。「すぐ必要」ならVPN
AWS VPN暗号化トンネルで接続

🎯 ひとことで

インターネット越しに暗号化トンネルを張って、オンプレやリモートPCとVPCを安全につなぐ。Direct Connectより安く、すぐ使える。

💡 たとえると一般道(インターネット)を通るが、中身が見えない装甲トラック(暗号化トンネル)で運ぶ。専用道路ほど安定はしないが、今日からすぐ走れて安い。

⚙️ 仕組み・ポイント

  • Site-to-Site VPN：オンプレのルーター ⇔ AWS（VGW）
  • Client VPN：リモートユーザーのPC/スマホ ⇔ VPC
✅ 試験ではこう出る「すぐ・安くハイブリッド接続」→VPN ／ 「安定・高帯域」→Direct Connect
Transit Gateway多数のVPCを中央集約接続

🎯 ひとことで

たくさんのVPCやオンプレを1つのハブに集めて、まとめて接続・ルーティングする仕組み。大規模ネットワークの整理役。

💡 たとえるとVPC同士を1本ずつ繋ぐ(ピアリング)のは「全員と個別に電話線を引く」状態でぐちゃぐちゃに。Transit Gatewayは中央の電話交換機。みんなが交換機に1本繋ぐだけで全員と通話できる。

⚙️ 仕組み・ポイント

  • 数千のVPC・オンプレを接続、ルートテーブルで一元管理
  • VPCピアリングは推移的ルーティング不可（A⇔B⇔CでもA→C不可）。TGWなら可能
✅ 試験ではこう出る「多数のVPCをフルメッシュ接続・一元管理」→Transit Gateway。2〜3個ならVPCピアリングで十分
AWS PrivateLink自社サービスをプライベート公開

🎯 ひとことで

自社で作ったサービスを、他のVPCやアカウントへインターネットを通さずプライベートに公開する仕組み。

💡 たとえると建物全体を行き来できるようにする(ピアリング)のではなく、「この窓口だけ」に通じる専用ドアを相手のフロアに1つ作る。見せたいサービスだけ、一方向で安全に提供できる。

⚙️ 仕組み・ポイント

  • 提供側：NLBの前にエンドポイントサービスを作成
  • 利用側：インターフェースVPCエンドポイントで接続
  • VPCのCIDRが重複していても接続できる
🔀 似たサービスとの違いVPCピアリング＝双方向で全通信。PrivateLink＝一方向・特定サービスのみ。
✅ 試験ではこう出る「自社サービスを他VPC/アカウントにプライベート公開」→PrivateLink
Global AcceleratorAWS網で経路を最適化

🎯 ひとことで

ユーザーのトラフィックを最寄りのエッジからAWSの高速バックボーンに乗せ、最適なリージョンへ最短ルートで届ける。固定IPが2つもらえる。

💡 たとえると目的地まで一般道を乗り継ぐと遅い。Global Acceleratorは最寄りのICからAWS専用高速道路に乗せて、渋滞を避けて最短で送り届ける。

⚙️ 仕組み・ポイント

  • TCP/UDP全般を最適化（HTTPに限らない）
  • 固定IP(Anycast)でDNS伝播を待たずにフェイルオーバー
  • CloudFrontと違いキャッシュはしない（ネットワーク層の最適化）
✅ 試験ではこう出る「固定IP・ゲーム/IoT/VoIP・TCP/UDP最適化」→Global Accelerator。キャッシュしたいならCloudFront
🔒 セキュリティ・ID18 services ・配点30%
AWS IAM誰が何をできるかを管理

🎯 ひとことで

「誰が・何に・何をできるか」を決めるAWSの認証認可の根幹。全セキュリティの土台。

💡 たとえるとビルの「入館管理＋鍵の発行システム」。社員証(ユーザー)、部署(グループ)、来客用の一時パス(ロール)を発行し、ドアごとに通行可否(ポリシー)を設定する。

⚙️ 仕組み・ポイント

  • 基本原則：最小権限（必要な分だけ与える）
  • ロール：EC2やLambdaにAWSへのアクセス権を渡す方法。アクセスキーをコードに書くのは絶対NG
  • ポリシー種類：アイデンティティベース / リソースベース / SCP / パーミッションバウンダリー
✅ 試験ではこう出るEC2からS3へのアクセスは必ずIAMロール。アクセスキーをEC2に置く選択肢は常にNG
IAM ポリシー評価 / SCP権限の判定ロジック

🎯 ひとことで

複数のルールが重なった時に「結局できるのか／できないのか」を決める判定順序。「明示的拒否が最優先」が肝。

💡 たとえると会社の規則。社長(IAM許可)が「いいよ」と言っても、就業規則(SCP)で禁止されていたらできない。「禁止」は何よりも強い。

⚙️ 仕組み・ポイント

  • 判定：デフォルト拒否 → 明示的拒否が最優先 → 明示的許可
  • SCP：Organizations配下の権限の上限(ガードレール)。許可を“与える”のではなく“上限を制限”する
  • パーミッションバウンダリー：個々のユーザー/ロールの最大権限を制限
✅ 試験ではこう出るSCPで拒否すればIAMで許可してもアクセス不可。「部門ごとに制限」→SCP、「開発者が作るロールの上限」→パーミッションバウンダリー
AWS STS一時的な認証情報を発行

🎯 ひとことで

有効期限付きの“一時パス”を発行する仕組み。ずっと使える鍵より安全。

💡 たとえると来客に渡す「数時間で失効する入館パス」。落としても期限切れになるので、ずっと有効な合鍵を渡すよりずっと安全。

⚙️ 仕組み・ポイント

  • AssumeRole：別のロールの権限を一時的に引き受ける（クロスアカウント・フェデレーション）
  • 常に一時認証情報を推奨（長期アクセスキーはリスク）
✅ 試験ではこう出る「別アカウントのリソースにアクセス」→STS AssumeRole。外部IdPからのフェデレーション認証にも使う
IAM Roles AnywhereAWS外のサーバーにIAMロールを

🎯 ひとことで

EC2なら当たり前に使えるIAMロールを、オンプレや他クラウドのサーバーでも、X.509証明書を使って利用できるようにする仕組み。長期アクセスキーを配らずに済む。

💡 たとえると社外の人に合鍵(長期アクセスキー)を渡す代わりに、本人確認済みの社員証(証明書)を見せれば、その場で時間制限付きの入館パス(一時認証情報)を発行する仕組み。鍵を持ち歩かせないので安全。

⚙️ 仕組み・ポイント

  • 信頼アンカーに認証局(CA)を登録し、その証明書を持つ外部ワークロードを信頼
  • 証明書で認証 → STSで一時認証情報を取得 → AWSへアクセス
  • オンプレ等にIAMアクセスキーを置かなくて済む(漏洩リスク排除)
🔀 使い分けAWS内のEC2/Lambdaは普通のIAMロール。AWS外(オンプレ・他クラウド・オンプレK8s)はIAM Roles Anywhere。人間の複数アカウントSSOはIAM Identity Center。
✅ 試験ではこう出る「オンプレ/他クラウドのサーバーに長期キーを置かずAWSへアクセス」→IAM Roles Anywhere
AWS KMS暗号化キーの管理

🎯 ひとことで

データを暗号化する鍵を作って・管理して・自動で交換するサービス。S3/EBS/RDSなどと統合。

💡 たとえると「金庫の鍵を一括管理する鍵管理室」。誰がいつどの鍵を使ったかの記録(CloudTrail)も残せるので、監査に強い。

⚙️ 仕組み・ポイント（S3暗号化の3方式）

  • SSE-S3：S3が鍵を管理。とりあえず暗号化したい時
  • SSE-KMS：KMSで鍵管理。誰が使ったか監査できる（CloudTrail追跡）
  • SSE-C：顧客が鍵を持ち込む。自社で完全管理

カスタマー管理キーは年1回の自動ローテーション可。

✅ 試験ではこう出る「暗号化を監査・キー使用を追跡」→SSE-KMS一択。「とりあえず暗号化」→SSE-S3
Secrets Manager秘密情報の保管＋自動更新

🎯 ひとことで

DBパスワードやAPIキーなどの秘密情報を安全に保管し、定期的に自動で変更(ローテーション)できるサービス。

💡 たとえるとパスワードを付箋やコードに書く代わりに、自動で定期的に鍵を付け替えてくれる金庫。アプリは金庫に「今の鍵ちょうだい」と聞きに行く。

⚙️ 仕組み・ポイント

  • 自動ローテーション：Lambdaで定期的にパスワードを変更
  • RDS/Aurora/Redshift とネイティブ統合
🔀 似たサービスとの違い最大の差は自動ローテーションの有無。Secrets Manager＝自動ローテーションあり(有料)。Parameter Store＝設定値管理(無料、ローテーションなし)。
✅ 試験ではこう出る「RDSパスワードの自動ローテーション」→Secrets Manager
ACMSSL/TLS証明書を無料発行・自動更新

🎯 ひとことで

HTTPS化に必要なSSL/TLS証明書を無料で発行し、期限切れ前に自動で更新してくれるサービス。

💡 たとえるとサイトの「本物であることの証明書(身分証)」を無料で発行し、有効期限が来たら勝手に更新してくれる。失効によるサイト停止を防げる。

⚙️ 仕組み・ポイント

  • パブリック証明書は無料、DNS検証 or メール検証
  • 統合先：ALB/NLB/CloudFront/API Gateway。EC2には直接使えない
✅ 試験ではこう出る「HTTPS化・SSL証明書」→ACM。CloudFrontで使うならus-east-1で証明書を作る点に注意
AWS WAFWebアプリ用ファイアウォール

🎯 ひとことで

Webへの悪意あるリクエスト(SQLインジェクション・XSS等)をL7でフィルタするファイアウォール。特定IPブロックやレート制限も。

💡 たとえると店の入口に立つ「用心棒」。怪しい客(攻撃リクエスト)や出禁の客(ブロックIP)を見分けて、入店させない。

⚙️ 仕組み・ポイント

  • マネージドルール（AWS/サードパーティの定義済みルール）が使える
  • 適用先：ALB / CloudFront / API Gateway / AppSync
✅ 試験ではこう出る「SQLインジェクション防止・特定IPブロック・レート制限」→WAF。L3/L4の保護はSG/NACL、DDoSはShield
AWS ShieldDDoS攻撃からの保護

🎯 ひとことで

DDoS攻撃(大量アクセスでサービスを潰す攻撃)から守るサービス。Standardは無料で自動、Advancedは高度な保護＋専門チーム。

💡 たとえると大量の人が一斉に押し寄せて店を機能停止させる嫌がらせ(DDoS)に対する「群衆整理・防御部隊」。Advancedなら24時間の専門チームが付く。

⚙️ 仕組み・ポイント

  • Shield Standard：無料・自動。L3/L4のDDoS保護
  • Shield Advanced：有料($3,000/月)。高度なL3-L7保護、DRT(専門チーム)24/7、攻撃によるコスト増の保護
✅ 試験ではこう出る「DDoS対策」→Shield。「24/7専門チーム・コスト保護」→Advanced。CloudFront＋Shield＋WAF＝3点セット
Amazon GuardDutyAIによる脅威検出

🎯 ひとことで

各種ログを機械学習で自動分析して、不正アクセスや怪しい動きを検出する。有効化するだけ、設定不要。

💡 たとえると建物の「AI監視カメラ＋警報装置」。いつもと違う不審な動き(異常APIや通信)を自動で見つけてアラートを出す。

⚙️ 仕組み・ポイント

  • VPC Flow Logs / CloudTrail / DNS Logs を分析
  • 検出例：暗号通貨マイニング、不正API、ブルートフォース、C&C通信
  • EventBridge連携で検出時にLambdaで自動対処
✅ 試験ではこう出る「不正アクセス・悪意ある活動の検出」→GuardDuty。Inspector(脆弱性)・Macie(S3データ)との違いを整理
Amazon Inspector脆弱性の自動スキャン

🎯 ひとことで

EC2やコンテナイメージのソフトウェアの脆弱性(CVE)やパッチ漏れを自動スキャンするサービス。

💡 たとえると建物の「定期点検・健康診断」。鍵の壊れた窓(脆弱性)や老朽箇所(パッチ漏れ)を見つけて報告してくれる。

⚙️ 仕組み・ポイント

  • EC2：SSMエージェント経由でOS/パッケージの脆弱性を検出
  • ECR：イメージのプッシュ時に自動スキャン／Lambda：関数の脆弱性
✅ 試験ではこう出るGuardDuty＝外部からの脅威検出、Inspector＝内部の脆弱性スキャン(パッチ漏れ等)の違いが頻出
Amazon MacieS3の機密データを検出

🎯 ひとことで

S3の中に個人情報(PII)やクレジットカード番号などの機密データが紛れていないか自動検出・分類する。

💡 たとえると大量の書類倉庫(S3)を巡回して、「ここにマイナンバーが入った書類があります」と指摘してくれる個人情報の番人。

⚙️ 仕組み・ポイント

  • S3バケットの暗号化/公開状態の可視化＋機密データ検出
  • 検出結果をEventBridge→SNS等で通知
✅ 試験ではこう出る「S3に個人情報が含まれていないか・データ分類・PII検出」→Macie
IAM Identity Center複数アカウントへのSSO

🎯 ひとことで

複数のAWSアカウントや業務アプリへ1回のログインでアクセス(SSO)できるサービス。旧称AWS SSO。

💡 たとえると1枚の社員証で全部署・全ビルのドアを開けられる共通入館システム。アカウントごとに別々にログインしなくて済む。

⚙️ 仕組み・ポイント

  • Organizations配下の全アカウントに一元アクセス
  • 社内AD・SAML2.0の外部IdP(Okta等)と統合可能
  • 許可セットで各アカウントの権限を定義
✅ 試験ではこう出る「マルチアカウントの一元アクセス管理・SSO」→IAM Identity Center
Amazon Cognitoアプリのユーザー認証

🎯 ひとことで

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

💡 たとえるとアプリの「会員登録＆ログイン受付」。受付で本人確認(User Pool)した後、館内で使える一時パス(Identity Pool→AWS認証情報)を発行する2段構え。

⚙️ 仕組み・ポイント

  • User Pool：ログイン・MFA・JWT発行（認証＝本人確認）
  • Identity Pool：トークンを元に一時AWS認証情報(STS)を発行（認可＝AWSアクセス権）
✅ 試験ではこう出る典型：User Poolでログイン→トークン取得→Identity Poolで一時AWS認証情報→S3/DynamoDBへ。「モバイルアプリからAWSリソース」→Cognito
Directory ServiceマネージドActive Directory

🎯 ひとことで

Windows環境で使うActive Directory(ユーザー/PCの一元管理)をAWS上で提供。オンプレADとの連携も可能。

💡 たとえると会社の「社員名簿＋権限台帳(AD)」をクラウドに置く。PCのドメイン参加やログイン管理をAWS上で完結できる。

⚙️ 仕組み・ポイント（3タイプ）

  • AWS Managed Microsoft AD：本物のMicrosoft AD。オンプレADと信頼関係。FSx for Windows / RDS for SQL Server / WorkSpacesと統合
  • AD Connector：オンプレADへのプロキシ（認証を転送、ADはクラウドに置かない）
  • Simple AD：Samba互換の小規模・低コスト版
✅ 試験ではこう出る「FSx for Windows/SQL ServerにAD統合」→Managed Microsoft AD ／ 「オンプレADの認証をそのまま使う」→AD Connector
Network Firewall / Firewall ManagerVPCの防御＋複数アカウント統制

🎯 ひとことで

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

💡 たとえるとNetwork Firewallは敷地全体の門に立つ常駐警備員(出入りを検査)。Firewall Managerは全支店の警備方針を本社が一括で決める統括部門。

⚙️ 仕組み・ポイント

  • Network Firewall：VPC境界でステートフルなIDS/IPS、送信先ドメインフィルタリング
  • Firewall Manager：Organizations配下の全アカウントにWAF/Shield/Network Firewall/SGルールを一括適用
✅ 試験ではこう出る「VPC全体のIDS/IPS・ドメイン制御」→Network Firewall ／ 「複数アカウントのFWルールを一元管理」→Firewall Manager
Amazon Detectiveインシデントの根本原因を調査

🎯 ひとことで

GuardDutyなどが検出した問題の“原因”を深掘り調査するサービス。ログを自動でグラフ化して関連を可視化。

💡 たとえると警報(GuardDuty)が鳴った後に現場に入る「捜査・鑑識チーム」。証拠(ログ)をつなぎ合わせ、「いつ・どこから・何が起きたか」を時系列で解明する。

⚙️ 仕組み・ポイント

  • VPC Flow Logs / CloudTrail / GuardDuty結果を自動で関連付け
  • IP・ユーザー・リソースごとの挙動を時系列で可視化
✅ 試験ではこう出るGuardDuty＝検出、Detective＝原因の深掘り調査。「インシデントの根本原因分析」→Detective
Security Hubセキュリティ検出結果の一元管理

🎯 ひとことで

GuardDutyやInspector、Macieなどあちこちのセキュリティサービスの検出結果を1か所にまとめ、重要度順に一覧で見られるようにする統合ダッシュボード。

💡 たとえると各部署(各セキュリティサービス)からバラバラに上がってくる報告を、一枚の状況ボードに集約する管制室。全体のセキュリティ状態がひと目で分かり、対応漏れを防ぐ。

⚙️ 仕組み・ポイント

  • 複数サービスの検出結果を共通形式(ASFF)で統合、重要度でスコアリング
  • CISベンチマーク・AWS基礎セキュリティ・PCI DSS等の基準に自動チェック
  • EventBridgeで自動対応、Organizationsで全アカウントを集約
🔀 役割の整理GuardDuty＝脅威の検出、Detective＝原因の調査、Security Hub＝それらの結果を集約・可視化する司令塔。
✅ 試験ではこう出る「複数のセキュリティサービスの検出を一元管理・組織のセキュリティ体制を可視化」→Security Hub
👁 監視・管理10 services
CloudWatchメトリクス監視・ログ・アラーム

🎯 ひとことで

AWSリソースの状態(CPU等)を監視し、ログを集め、閾値を超えたら通知・自動アクションする統合モニタリング。

💡 たとえると家の「健康モニター＋警報器」。室温やCPU(体温)を常に測り、異常値になったらアラーム(SNS通知)を鳴らし、必要なら換気(Auto Scaling)を自動で始める。

⚙️ 仕組み・ポイント

  • 標準メトリクス(CPU・ネットワーク)＋カスタムメトリクス(メモリ等)
  • CloudWatch Logs：ログの収集・検索／Alarms：閾値でSNS通知/Auto Scaling/Lambda
✅ 試験ではこう出る「メモリ使用率の監視」→CloudWatchエージェントが必須(標準にメモリはない)。CloudWatch＝性能監視、CloudTrail＝操作の監査
CloudTrail誰が何をしたかの監査ログ

🎯 ひとことで

AWSへのすべての操作(API呼び出し)を記録する監査証跡。「誰が・いつ・何を・どこから」やったかを追える。

💡 たとえると建物の「入退室＋操作の防犯カメラ記録」。後から「誰がこのリソースを消したのか？」を巻き戻して確認できる。

⚙️ 仕組み・ポイント

  • 管理イベント(作成/削除など)はデフォルト有効、データイベント(S3オブジェクト操作等)は追加設定
  • ログはS3に保存、CloudWatch Logsに連携可。Insightsで異常検知
✅ 試験ではこう出る「誰がリソースを削除したか・セキュリティ監査」→CloudTrail。Config＝「設定が正しいか」、CloudTrail＝「誰が変更したか」
AWS Config設定変更の記録＋準拠チェック

🎯 ひとことで

リソースの設定変更を記録し、「ルールに沿っているか(準拠)」を自動チェックする。例：「SGがポート22を全開放していないか」。

💡 たとえると「設定の点検官＋変更履歴ノート」。決められた基準(社内規定)を満たしているか巡回点検し、違反を見つけたら指摘・自動修正する。

⚙️ 仕組み・ポイント

  • 設定のスナップショットと変更タイムライン
  • Configルール(マネージド/カスタム)＋非準拠の自動修復(SSM連携)
✅ 試験ではこう出る「設定が基準に準拠しているか・設定変更の追跡」→Config。CloudTrail(操作記録)とは補完関係
AWS X-Ray分散アプリのリクエストを追跡

🎯 ひとことで

マイクロサービスやサーバーレスで、1つのリクエストがどのサービスをどう通り、どこで時間がかかった/失敗したかを可視化する分散トレーシング。

💡 たとえると荷物の「追跡番号」。発送から到着まで、どの集配所（サービス）を何時に通過し、どこで止まっているかを1本の線で追える。遅れの原因がひと目で分かる。

⚙️ 仕組み・ポイント

  • サービスマップ：API Gateway→Lambda→DynamoDB のような流れと所要時間を図で表示
  • トレース：区間（セグメント）ごとに遅延・エラーを分析
  • Lambda / API Gateway / EC2 / ECS などと統合
🔀 似たサービスとの違いCloudWatch＝メトリクス/ログの監視、CloudTrail＝誰が操作したかの監査、X-Ray＝リクエストがサービスをどう流れたかの追跡。
✅ 試験ではこう出る「マイクロサービス/サーバーレスのボトルネック・遅延箇所を特定」→X-Ray
Systems Managerサーバー運用を一元化

🎯 ひとことで

EC2やオンプレサーバーの運用作業(リモート操作・パッチ・設定値管理)をまとめて行う道具箱。

💡 たとえると全サーバーを手元から操作できる「統合リモコン＋管理コンソール」。各部屋(サーバー)に行かなくても、まとめて操作・点検できる。

⚙️ 仕組み・ポイント

  • Session Manager：SSH/RDPなしでブラウザからアクセス（ポート22を開けなくていい）
  • Parameter Store：設定値・シークレットを無料で階層管理（自動ローテーションはなし）
  • Patch Manager：パッチ適用の自動化／Run Command：一括コマンド実行
✅ 試験ではこう出る「SSHポートを開けずにEC2にアクセス」→Session Manager ／ 「設定値管理(無料)」→Parameter Store
Trusted Advisorベストプラクティス自動チェック

🎯 ひとことで

アカウントをベストプラクティスに照らして自動点検し、改善点を提案。コスト・性能・セキュリティ・耐障害性・上限を横断的にチェック。

💡 たとえると「お得・安全・健康診断をまとめてやる総合アドバイザー」。使ってない契約(無駄コスト)や戸締まり忘れ(セキュリティ)を指摘してくれる。

⚙️ 仕組み・ポイント

  • 5カテゴリ：コスト最適化 / 性能 / セキュリティ / 耐障害性 / サービス上限
  • 全項目を見るにはBusiness以上のサポートプランが必要
🔀 似たサービスとの違いTrusted Advisor＝ベストプラクティス全般を広く。Compute Optimizer＝EC2等のサイズ最適化に特化。
✅ 試験ではこう出る「未使用リソースの検出・セキュリティのベストプラクティス」→Trusted Advisor（フルチェックはBusiness以上）
Organizations複数アカウントの一元管理

🎯 ひとことで

たくさんのAWSアカウントをグループ(OU)にまとめ、ルール(SCP)で統制し、請求も一本化する仕組み。

💡 たとえるとグループ企業の「本社管理部門」。各子会社(アカウント)を部門ごとにまとめ、共通規則を課し、支払いも本社で一括（→ボリューム割引）。

⚙️ 仕組み・ポイント

  • OU：アカウントの論理グループ（開発/本番など）
  • SCP：OU/アカウントの権限上限のガードレール
  • 一括請求：利用量を合算してボリュームディスカウント
✅ 試験ではこう出る「部門ごとにアカウント分離＋一元管理」→Organizations＋SCP。「S3公開を全社禁止」等のガードレール
Control Towerマルチアカウント環境を自動構築

🎯 ひとことで

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

💡 たとえるとOrganizationsが「管理の仕組み」なら、Control Towerは「最初から正しく整った状態でアカウントを払い出してくれる自動セットアップ係」。新規子会社をテンプレ通りに即開設。

⚙️ 仕組み・ポイント

  • ランディングゾーン：ベストプラクティス環境を自動構築
  • ガードレール：予防的(SCP)／検出的(Config Rules)
  • Account Factory：新規アカウントのプロビジョニング自動化
✅ 試験ではこう出る「新規アカウントにベストプラクティスを自動適用」→Control Tower
Service Catalog承認済み構成をセルフサービス提供

🎯 ひとことで

管理者が「これは使ってOK」と承認した構成(テンプレート)をカタログに並べ、利用者はそこから選んで自分でデプロイできるようにする仕組み。ルールを守らせつつ手間を減らす。

💡 たとえると社内の「承認済み備品カタログ」。社員は載っているものから選んで注文するだけ。勝手な型番(野良リソース)は頼めないので、統制が効いたまま各自が自由に調達できる。

⚙️ 仕組み・ポイント

  • 製品(CloudFormationテンプレート)をポートフォリオにまとめ、ユーザー/グループに公開
  • 起動制約・IAMで「許可された構成・権限だけ」で展開(野良リソースを防ぐ)
  • パラメータで選択肢を制限、バージョン管理、Organizations間で共有
🔀 似たものとの違いIaCの土台はCloudFormation、組織のガードレールはSCP/Control Tower。その上で「使ってよい製品の配布」がService Catalog。
✅ 試験ではこう出る「承認済みの構成だけを利用者にセルフサービスで展開・標準化とガバナンス」→Service Catalog
Health DashboardAWS障害・自分への影響を通知

🎯 ひとことで

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

💡 たとえると電力会社の「停電・メンテ情報のお知らせ」。全体の障害情報に加えて、“あなたの家に影響する”ものだけを個別に教えてくれる。

⚙️ 仕組み・ポイント

  • Service Health Dashboard：AWS全体の状態
  • Personal Health Dashboard：自分のリソースに影響するイベント
  • EventBridge連携で発生時にLambda/SNS通知を自動実行
✅ 試験ではこう出る「自分のリソースに影響するAWS障害を通知」→Personal Health Dashboard＋EventBridge
🔗 アプリ統合11 services
Amazon SQSメッセージキューで疎結合

🎯 ひとことで

システム間に「待ち行列(キュー)」を挟んで、送る側と受ける側を切り離す仕組み。処理速度の差を吸収して非同期処理にする。

💡 たとえると飲食店の「注文票ホルダー」。客(送信側)はどんどん注文票を挿し、キッチン(受信側)は自分のペースで取って処理する。直接やり取りしないので片方が混んでも崩れない。

⚙️ 仕組み・ポイント

  • Standard：順序保証なし・スループット無制限・最低1回配信(重複あり得る)
  • FIFO：厳密な順序・正確に1回配信
  • DLQ：失敗メッセージを隔離／可視性タイムアウト：処理中は他から見えなくする
✅ 試験ではこう出る「システム間の疎結合・非同期処理」→SQS。1対1=SQS、1対多=SNS。SNS＋SQSファンアウトは超頻出
Amazon SNSPub/Subで一斉通知

🎯 ひとことで

1つのメッセージを購読している全員に一斉配信するPub/Sub型メッセージング。1対多の通知に使う。

💡 たとえると「メルマガ・一斉同報」。1回送れば、購読者(SQS/Lambda/メール/SMS)全員に同時に届く。

⚙️ 仕組み・ポイント

  • トピックに送ると複数サブスクライバーへ同時配信
  • サブスクリプションフィルタで配信先を絞れる
🔀 ファンアウトパターンSNSトピック→複数のSQSキューに同時配信→各キューを別システムが独立処理。SAA超定番。
✅ 試験ではこう出る「1イベントを複数システムに通知」→SNS。SNS＋SQSファンアウトを覚える
Amazon EventBridgeイベントを賢くルーティング

🎯 ひとことで

AWSやSaaSの“出来事(イベント)”をルールで振り分けて、適切な処理を起動するサーバーレスのイベントバス。CloudWatch Eventsの後継。

💡 たとえると会社の「メール仕分け＋自動転送ルール」。「〇〇が起きたら△△に回す」を定義しておくと、出来事に応じて自動で担当(Lambda等)に振り分けてくれる。

⚙️ 仕組み・ポイント

  • AWSサービスのイベント(EC2状態変化、S3操作等)を自動キャプチャ
  • ルールでフィルタ→ターゲット(Lambda/SQS/Step Functions)へ
  • cron式で定期実行(スケジューラ)、SaaS(Datadog等)とも連携
✅ 試験ではこう出る「AWSサービスのイベントに反応して処理を起動」「毎日0時にLambda」→EventBridge
Step Functions処理を視覚的にワークフロー化

🎯 ひとことで

複数のLambdaなどを「次にこれ、条件によって分岐」と視覚的な流れ図(ステートマシン)で組み立てるオーケストレーション。

💡 たとえると料理の「レシピのフローチャート」。各工程(Lambda)の順番・分岐・やり直し(リトライ)を一枚の図で管理。誰が見ても流れが分かる。

⚙️ 仕組み・ポイント

  • Standard：最大1年・実行保証あり／Express：最大5分・高スループット・低コスト
  • ASL(JSON)でワークフロー定義。「LambdaからLambdaを直接呼ぶ」アンチパターンの解消に使う
✅ 試験ではこう出る「複数Lambdaの順序制御・条件分岐のあるワークフロー」→Step Functions
Amazon Kinesis Data Streamsリアルタイムのストリーム取り込み

🎯 ひとことで

次々と流れてくるリアルタイムデータ(ログ・IoT・クリック)を受け取り、カスタムアプリで低遅延に処理する。Kinesisの中核で、名称は今も「Kinesis」。

💡 たとえると絶え間なく流れる「ベルトコンベア」。流れてくる荷物(データ)を、その場で加工したり、決まった倉庫(S3等)へ自動で振り分けたりする。
⚠️ 名称変更に注意（試験でつまずきやすい）昔の“Kinesisファミリー”は分割・改名済み。Kinesis Data Streams＝取り込み（名称そのまま）／配信はAmazon Data Firehose（旧 Kinesis Data Firehose）／分析はManaged Service for Apache Flink（旧 Kinesis Data Analytics）。試験は新名称で出るので、旧名とセットで覚える。

⚙️ 仕組み・ポイント

  • Kinesis Data Streams：シャードで低遅延・複数コンシューマー・再処理(保持1〜365日)
  • 配信だけなら → Amazon Data Firehose（別項目・旧Firehose）
  • リアルタイム集計/異常検知 → Managed Service for Apache Flink（別項目・旧Data Analytics）
✅ 試験ではこう出る「カスタムリアルタイム処理/再処理」→Kinesis Data Streams ／ 「S3/Redshiftに自動配信・管理最小」→Amazon Data Firehose
Managed Service for Apache Flinkストリームをリアルタイム分析

🎯 ひとことで

流れてくるデータ(ストリーム)に対して、SQLやApache Flinkでその場でリアルタイムに集計・変換・異常検知するマネージドサービス(旧Kinesis Data Analytics)。

💡 たとえるとベルトコンベア(Kinesis)を流れる商品を横で見ながら、「直近1分の合計」「異常品の検知」をその場で計算し続ける検品員。溜めてから後で集計するのではなく、流れているそばから処理する。

⚙️ 仕組み・ポイント

  • 入力: Kinesis Data Streams / Amazon MSK(Kafka) などのストリーム
  • 時間ウィンドウ集計・フィルタ・結合・異常検知をリアルタイム実行
  • 結果を S3 / OpenSearch / Lambda / 別ストリームへ。サーバー管理不要で自動スケール
🔀 似たものとの違いData Streams＝取り込み、Firehose＝S3等へ配信、Flink＝流れの中でのリアルタイム分析。溜めたデータの後追い分析はAthena/EMR。
✅ 試験ではこう出る「ストリームデータをリアルタイムにSQLで集計・異常検知」→Managed Service for Apache Flink
Amazon Data FirehoseストリームをS3等へ自動配信

🎯 ひとことで

流れてくるストリームデータを、コードを書かずにS3/Redshift/OpenSearch等へニアリアルタイムで自動的に届けて貯めるサービス(旧Kinesis Data Firehose)。

💡 たとえるとベルトコンベアを流れてくる荷物を、決まった倉庫(S3等)へ自動で運び込む仕分けロボット。一定量/一定時間ごとにまとめて配送し、運ぶ前に箱詰め(圧縮・変換)もしてくれる。自分で配送トラック(サーバー)を持たなくていい。

⚙️ 仕組み・ポイント

  • 入力: Kinesis Data Streams / 直接PUT / MSK 等。配信先: S3 / Redshift / OpenSearch / Splunk / HTTP
  • バッファ(サイズ/時間)でまとめて配信、Lambdaで変換・圧縮・Parquet化
  • シャード管理不要・自動スケール。完全マネージド
🔀 似たものとの違いData Streams＝カスタム処理/低遅延/再処理ができる代わりにシャード管理あり。Firehose＝とにかくS3等へ流し込むのが楽(管理最小)。
✅ 試験ではこう出る「ストリームを管理不要でS3/Redshift/OpenSearchに自動ロード」→Data Firehose
AWS AppFlowSaaS↔AWSをノーコード連携

🎯 ひとことで

SalesforceやSlackなどのSaaSと、S3/Redshift等のAWSの間で、データをコードなしで安全にやり取りするフルマネージドな連携サービス。

💡 たとえると別々のアプリ同士をつなぐ「設定だけで動くデータの宅配便」。Salesforceの顧客データを毎朝S3へ、のような定型のやり取りを、プログラムを書かずに自動化できる。

⚙️ 仕組み・ポイント

  • 双方向のデータフローをGUIで設定(コード不要)
  • オンデマンド/スケジュール/イベント駆動で実行、フィルタ・マッピング・変換
  • PrivateLinkでインターネットを通さずプライベート転送も可能
🔀 似たものとの違い汎用的なETL/データ加工はGlue、ストリーミングはKinesis/Firehose。AppFlowはSaaSとの定型データ連携に特化。
✅ 試験ではこう出る「SaaS(Salesforce等)とAWS間でデータをノーコード連携」→AppFlow
Amazon MSKマネージドApache Kafka

🎯 ひとことで

Apache Kafka(分散ストリーミング基盤)をフルマネージドで提供するサービス。既存のKafkaアプリをコード変更なしで動かせ、サーバー運用はAWS任せ。

💡 たとえるとKinesisが「AWS純正のストリーミング」なら、MSKは「業界標準のKafkaという機材を運用付きでレンタル」。今あるKafka資産をそのまま持ち込める。

⚙️ 仕組み・ポイント

  • Kafka/メタデータ管理の構築・パッチ・スケール・監視をマネージド
  • 既存のKafka API・ツール・コネクタがそのまま使える
  • Multi-AZで高可用、暗号化、MSK Serverless / MSK Connectも
🔀 似たものとの違い新規でAWSネイティブならKinesis(運用最小)。既存のKafka資産を活かす/Kafka互換が必要ならMSK。Amazon MQ(ActiveMQ/RabbitMQ)ともまた別。
✅ 試験ではこう出る「既存のApache Kafkaをマネージドで運用・Kafka互換のストリーミング」→Amazon MSK
Amazon MQ既存メッセージブローカーの移行先

🎯 ひとことで

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

💡 たとえるとSQS/SNSが「AWS純正の新しい仕組み」なら、Amazon MQは「昔から使っている機材(プロトコル)をそのまま動かせる互換機」。引っ越しても操作を変えずに済む。

⚙️ 仕組み・ポイント

  • ActiveMQ / RabbitMQ の2エンジン、Multi-AZで高可用性
  • 既存プロトコル(JMS/AMQP/MQTT/STOMP)との互換性が最大の特徴
✅ 試験ではこう出る新規構築→SQS/SNS、既存プロトコル互換が必要→Amazon MQ。「JMS」「移行」がキーワード
AWS AppSyncマネージドGraphQL API

🎯 ひとことで

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

💡 たとえると必要なデータを「あれとこれだけください」と1回でまとめて注文できる窓口(GraphQL)。モバイルアプリのリアルタイム更新やオフライン同期に強い。

⚙️ 仕組み・ポイント

  • GraphQLスキーマ＋リゾルバーで DynamoDB/Lambda/RDS/HTTP に接続
  • サブスクリプション(WebSocket)でリアルタイム更新／オフライン同期
✅ 試験ではこう出るREST→API Gateway、GraphQL・リアルタイムデータ同期→AppSync
📈 分析6 services
Amazon AthenaS3に直接SQLクエリ

🎯 ひとことで

S3に置いたデータをサーバーを立てず、その場でSQLクエリできる。スキャンしたデータ量だけ課金。

💡 たとえると倉庫(S3)の中身を、わざわざDBに移し替えずにその場で「この条件のものを集計して」と問い合わせられる。準備不要で手軽。

⚙️ 仕組み・ポイント

  • Presto/TrinoベースのSQL。CSV/JSON/Parquet/ORC対応
  • Glue Data Catalogと統合してテーブル定義を管理
  • Parquet(列指向)に変換するとスキャン量が減りコスト削減
🔀 似たサービスとの違いAthena＝S3のアドホッククエリ(小〜中規模)。EMR＝大規模分散処理。Redshift＝定常的なDWH分析。
✅ 試験ではこう出る「S3のログをアドホック分析・サーバーレスSQL」→Athena。VPC Flow Logs/CloudTrail分析の定番。Glue Catalog連携も頻出
Amazon QuickSightサーバーレスBI・可視化

🎯 ひとことで

データをダッシュボードやグラフに可視化して共有するBIサービス。SPICEというインメモリエンジンで高速表示。

💡 たとえると数字の羅列(データ)を、見やすい「グラフ付きの経営ダッシュボード」に仕立てる可視化ツール。Excelのグラフのクラウド版・組織共有版。

⚙️ 仕組み・ポイント

  • データソース：S3/RDS/Redshift/Athena/DynamoDB等
  • ML Insights：異常検知・予測・自然言語クエリ(QuickSight Q)
✅ 試験ではこう出る「ダッシュボード作成・データの可視化・BI」→QuickSight
Amazon EMR大規模ビッグデータ処理

🎯 ひとことで

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

💡 たとえると1人では何年もかかる作業を、大勢で手分けして一気に片付ける「大規模作業チーム」。巨大データの集計を多数のサーバーで分散処理する。

⚙️ 仕組み・ポイント

  • EC2/EKS/Serverless の3つの実行環境
  • スポットインスタンスでコスト削減、S3をデータレイクに連携
✅ 試験ではこう出る「大規模分散ETL・Hadoop/Spark・機械学習」→EMR。手軽なS3クエリならAthena
AWS GlueサーバーレスETL＋データカタログ

🎯 ひとことで

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

💡 たとえると食材(生データ)を洗って・切って・下ごしらえする「セントラルキッチン」。形式バラバラのデータを、分析しやすい状態に自動で整える。

⚙️ 仕組み・ポイント

  • Data Catalog：メタデータの中央カタログ。Athena/EMR/Redshiftが参照
  • Crawler：データを自動スキャンしてスキーマ検出／Job：変換処理
✅ 試験ではこう出る「データ変換パイプライン・メタデータ管理」→Glue。Athena＋Glue Data Catalogの組み合わせは頻出
Lake Formationデータレイクを安全に構築・統制

🎯 ひとことで

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

💡 たとえると巨大な「データの貯水池(レイク)」の管理者。誰がどの棚・どの列・どの行まで見ていいかを細かく一括でコントロールする。

⚙️ 仕組み・ポイント

  • 列レベル/行レベルのきめ細かいアクセス制御
  • Glue Data Catalogの上に構築され、取り込みも自動化(ブループリント)
✅ 試験ではこう出る「データレイクのアクセス制御を一元管理・列/行レベルのセキュリティ」→Lake Formation
OpenSearch Service全文検索・ログ分析・可視化

🎯 ひとことで

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

💡 たとえると大量の文書やログから「あのキーワードを含むものを一瞬で探す」高機能検索エンジン＋、結果をグラフで見せるダッシュボード。

⚙️ 仕組み・ポイント

  • 全文検索(ドキュメント検索・オートコンプリート)
  • ログのリアルタイム分析・可視化。Kinesis Firehose→OpenSearchのパイプラインが定番
✅ 試験ではこう出る「全文検索・ログのリアルタイム分析と可視化」→OpenSearch
🚀 デプロイ・IaC5 services
CloudFormationインフラをコードで自動構築(IaC)

🎯 ひとことで

AWSリソースをテンプレート(設計図)に書いて、ボタン一つで丸ごと自動構築・複製する(Infrastructure as Code)。

💡 たとえると「組み立て家具の設計図＋自動組み立てロボット」。同じ設計図(テンプレート)から、まったく同じ環境を何度でも・何箇所でも正確に再現できる。

⚙️ 仕組み・ポイント

  • スタック：テンプレートから作るリソースの集合。一括作成・更新・削除
  • StackSets：複数アカウント/リージョンに同じ環境を一括展開
  • ドリフト検出(実物と設計図の差分)、変更セット(更新前プレビュー)
✅ 試験ではこう出る「再現可能なデプロイ・環境の複製・マルチリージョンに同じ環境」→CloudFormation(StackSets)
CodePipelineCI/CDパイプラインの自動化

🎯 ひとことで

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

💡 たとえると工場の「ベルトコンベア(生産ライン)」。コードを乗せれば、各工程(ビルド・テスト・デプロイ)を順に自動で通って本番リリースまで運ばれる。

⚙️ 仕組み・ポイント

  • ステージ間に手動承認ゲートを置ける
  • GitHub/Jenkins等のサードパーティとも統合
✅ 試験ではこう出るSAAでは深くは出ないが、CodeCommit→CodeBuild→CodeDeploy→CodePipelineのCI/CDフローを理解しておく
CodeBuildマネージドなビルドサービス

🎯 ひとことで

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

💡 たとえると設計図(ソース)から実際に組み立てて検品する「製造ライン担当」。自前の工場(ビルドサーバー)を持たずに、必要な時だけ借りる。

⚙️ 仕組み・ポイント

  • buildspec.yml でビルド手順を定義
  • Docker環境でビルド、カスタムイメージも利用可
✅ 試験ではこう出るCI/CDの「ビルド」担当。CodeCommit(ソース)→CodeBuild(ビルド)→CodeDeploy(デプロイ)
CodeDeployデプロイの自動化

🎯 ひとことで

EC2/Lambda/ECSへのアプリのデプロイを自動化。ダウンタイムゼロのBlue/Greenデプロイも可能。

💡 たとえるとBlue/Greenは「営業中の店の隣に新装開店した店をこっそり用意し、準備できたら一斉に客を新店へ誘導、旧店を閉める」方式。お客を待たせず切り替えられる。

⚙️ 仕組み・ポイント

  • In-place：既存サーバー上で入れ替え(ダウンタイムあり得る)
  • Blue/Green：新環境を作って切替→旧削除。ダウンタイムゼロ
✅ 試験ではこう出る「ダウンタイムゼロのデプロイ」→Blue/Greenデプロイ
Amazon ECRDockerイメージの保管庫

🎯 ひとことで

DockerコンテナイメージをAWS上に保存・管理する専用倉庫(レジストリ)。ECS/EKSと統合して使う。

💡 たとえるとコンテナ(引っ越し箱)の「テンプレート保管庫」。ここに置いた箱の雛形を、ECS/EKSが必要な時に取り出して大量複製する。

⚙️ 仕組み・ポイント

  • プライベート/パブリックリポジトリ
  • イメージスキャン：プッシュ時に自動で脆弱性チェック(Inspector統合)
  • ライフサイクルポリシーで古いイメージを自動削除
✅ 試験ではこう出るECS/EKSのイメージ管理に使う。イメージスキャンで脆弱性検出も可能
💰 コスト管理5 services
Cost Explorerコストの可視化・分析・予測

🎯 ひとことで

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

💡 たとえると家計簿アプリの「支出分析グラフ」。何にいくら使ったかを可視化し、来月の出費を予測。節約ポイント(RI/SP)も提案してくれる。

⚙️ 仕組み・ポイント

  • 過去13ヶ月のデータ＋12ヶ月先までの予測
  • RI/Savings Plans推奨、タグでコスト配分
🔀 似たサービスとの違いCost Explorer＝分析、Budgets＝予算超過のアラート通知。
✅ 試験ではこう出る「コストの傾向を分析・コスト予測」→Cost Explorer
AWS Budgets予算超過のアラート

🎯 ひとことで

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

💡 たとえると「今月◯円まで」と決めておくと、近づいたら『そろそろ予算オーバーですよ』とアラートを出してくれる見張り役。

⚙️ 仕組み・ポイント

  • 予算タイプ：コスト/使用量/RI・SP利用率
  • 実際値 or 予測値が閾値到達で通知（Email/SNS）
  • Budget Actions：超過時にIAM変更やEC2/RDS停止を自動実行
✅ 試験ではこう出る「コストが閾値を超えたら通知・予算超過アラート」→Budgets
Compute Optimizerリソースの適正サイズを推奨

🎯 ひとことで

EC2/EBS/Lambda等の使用状況をMLで分析し、「もっと小さく/大きくすべき」と最適サイズを提案する。

💡 たとえると「そのプラン、オーバースペックですよ。1つ下げても困りませんよ」と教えてくれる料金プランの見直しアドバイザー。

⚙️ 仕組み・ポイント

  • CloudWatchメトリクスを14日以上収集して分析
  • 余剰/不足を検出し、コスト削減見積もりも提示
✅ 試験ではこう出る「EC2インスタンスタイプの最適化・適正サイズ」→Compute Optimizer（Trusted Advisorは全般、こちらはサイズ特化）
Savings Plans使用量コミットで割引

🎯 ひとことで

「1時間あたり◯ドル使う」と1〜3年コミットすると最大72%割引。RIより柔軟で、EC2/Lambda/Fargateを横断適用。

💡 たとえると「毎月これくらい使うから」とまとめ買いを約束して割引を得る定額コミット契約。RIより縛りがゆるく、構成を変えても割引が効く。

⚙️ 仕組み・ポイント

  • Compute Savings Plans：EC2/Lambda/Fargate横断。最も柔軟
  • EC2 Instance Savings Plans：特定ファミリー+リージョン限定。割引が大きい
  • RIと違い「使用量をコミット」する仕組み
✅ 試験ではこう出る「柔軟性＋割引」→Compute Savings Plans。RIとの違い＝SPの方が柔軟
Reserved Instances予約購入で割引

🎯 ひとことで

EC2/RDS等を1〜3年予約することで割引を受ける購入オプション。ずっと動かす安定ワークロード向け。

💡 たとえると賃貸の「定期借家(年契約)」。短期(オンデマンド)より割安だが、途中解約しにくい。ずっと住む(動かす)前提なら最もお得。

⚙️ 仕組み・ポイント

  • 支払い：全額前払い(最大割引)/一部前払い/前払いなし
  • Standard RI：変更不可・最大割引／Convertible RI：タイプ変更可・割引やや低
✅ 試験ではこう出る「24時間365日の安定稼働DB」→RI(全額前払い) ／ 「開発・断続利用」→オンデマンド ／ 「中断可能バッチ」→スポット
AWS SAA-C03 試験対策 | やさしいサービス解説 | マップ収録の全サービスを噛み砕いて解説