EC2は、AWSのデータセンター上に「仮想的なコンピューター（インスタンス）」を立てて使うサービスです。「AMI」というOSやソフトのテンプレートから起動し、Webサーバー・アプリ・バッチ処理などを動かします。物理サーバーの購入や設置が不要で、数分で用意でき、不要になれば削除できます。

用語のキホン：リージョンとアベイラビリティゾーン

リージョンは「東京」「大阪」のような地理的に離れた大きな拠点、アベイラビリティゾーン（AZ）はリージョン内にある独立したデータセンター群です。1つのAZが障害で止まっても他のAZは生き残るため、サーバーを複数AZに分散して置くことが可用性設計の基本になります。なお、起動した1台1台のサーバーのことをインスタンスと呼びます。

主な構成要素

用途に応じてインスタンスタイプ（ファミリー）を選びます。バランス型の「t/m系（汎用）」、CPU重視の「c系（コンピュート最適化）」、メモリ重視の「r系（メモリ最適化）」などがあります。ディスクはEBSを接続し、ネットワークはENI（ネットワークインターフェース）とセキュリティグループで制御します。同じ構成を再利用したいときは、設定をまとめた「起動テンプレート」を使います。

料金と可用性

料金は用途で選びます。常時稼働なら割引のある「Savings Plans・リザーブド」、途中で止まってもよい処理なら最大約9割引の「スポット」です。EC2単体は1台のサーバーに過ぎないため、実運用では複数AZに分散し、Auto ScalingとELBを組み合わせて可用性とスケールを確保します。

Auto Scaling（EC2 Auto Scaling）は「Auto Scalingグループ（ASG）」という単位でEC2の台数を管理し、「最小・希望・最大」を決めておくと負荷に応じて自動で増減します。どんなインスタンスを増やすかは「起動テンプレート」で定義します。

用語のキホン：スケールアウトとスケールイン

スケールアウトは「台数を増やす」こと、スケールインは「台数を減らす」ことを指し、どちらも横に並べる台数を増減する水平スケーリングです。一方、1台あたりのCPUやメモリを大きくする（インスタンスタイプを上げる）のはスケールアップ、小さくするのはスケールダウンで、こちらは1台の性能を変える垂直スケーリングと呼びます。Auto Scalingが自動で行うのは主に水平方向で、負荷が上がれば自動でスケールアウト、下がれば自動でスケールインします。

スケーリングポリシー

増減の判断方法にはいくつかあります。目標値（例：CPU 50%）を保つように調整するターゲット追跡、しきい値ごとに段階的に増やすステップスケーリング、時間を決めて増減するスケジュールがあります。無駄な増減を防ぐ「クールダウン」、起動直後の準備時間を扱う「ウォームプール」なども関係します。

自己修復と連携

ヘルスチェック（EC2のステータス、またはELBのヘルスチェック）で異常と判断されたインスタンスを自動で終了し、新しく立て直す自己修復が大きな役割です。複数AZにまたがって台数を均等化し、ELBと組み合わせるのが定番構成です。

アプリケーションはEC2だけで動いているわけではなく、背後のデータベースやキャッシュも同時に負荷を受けます。EC2だけを増やしてもデータベースが追いつかなければ意味がありません。AWS Auto Scalingはアプリケーション全体を見た拡張を可能にします。

用語のキホン：EC2 Auto Scalingとの違い

ここは混同しやすい重要な区別です。Amazon EC2 Auto Scalingは、EC2インスタンスの台数だけを増減させる機能で、Auto Scalingグループ（同じ設定のインスタンス群の管理単位）を作り、最小・希望・最大の台数を指定して運用します。これに対してAWS Auto Scalingは、複数のサービスにまたがるリソースを1つのスケーリングプランとしてまとめて管理する上位の仕組みです。対象にはEC2 Auto Scalingグループ、DynamoDBのテーブルとインデックス、Auroraのリードレプリカ、ECSサービス、Spot Fleetなどが含まれます。試験で「単一のアプリケーションを構成する複数リソースを統合的にスケールしたい」とあれば、こちらを選びます。

スケーリング方式

ターゲット追跡は、CPU使用率70パーセントといった目標値を維持するように自動調整する方式で、最も設定が簡単です。ステップスケーリングは、しきい値の超過幅に応じて増減量を変える方式、スケジュールスケーリングは、負荷の増える時間帯があらかじめ分かっている場合に時刻で増減させる方式です。AWS Auto Scalingでは、可用性優先・コスト優先などの方針を選ぶだけで推奨設定を生成することもできます。

Lambdaは、サーバーの構築やOS管理をせずに「関数（コード）」を実行できるサービスです。何かのイベントをきっかけに自動で動き、実行時間（ミリ秒単位）と割り当てメモリに応じて課金されます。待機している間は料金がかかりません。

用語のキホン：サーバーレスとイベント駆動

サーバーレスとは「サーバーが無い」という意味ではなく、サーバーの用意・管理を利用者が意識しなくてよい方式のことです。イベント駆動とは、常に動かし続けるのではなく「何かが起きたとき（イベント）」にだけ処理を動かす考え方です。Lambdaはこの2つの代表で、イベントが来たときだけ動き、動いた分だけ課金されます。

実行の仕組み

呼び出し方は、応答を待つ同期（API Gatewayなど）、投げっぱなしの非同期（S3イベントなど・自動リトライあり）、順番に処理するストリーム（DynamoDB StreamsやKinesis）があります。割り当てメモリを増やすとCPUも比例して増えます。最大実行時間は15分で、それを超える処理には向きません。しばらく呼ばれないと初回起動が少し遅くなる「コールドスタート」も特徴です。

関連する仕組み

共通ライブラリは「レイヤー」で共有でき、VPC内のリソース（RDS等）へアクセスするにはVPC接続の設定が必要です。過負荷を防ぐ「同時実行数」の管理や、失敗時の退避先（デッドレターキュー）も重要です。

FargateはECSとEKSの両方で使える「起動タイプ」です。コンテナに必要なCPUとメモリを指定するだけで実行され、その裏側のサーバーは意識しません。

用語のキホン：サーバーレスコンテナという考え方

従来のEC2起動タイプでは、コンテナを載せるためのEC2群（クラスター）を自分で用意し、台数が足りているか、OSに脆弱性がないかを管理する必要がありました。Fargateはこの層をAWSに委ねる方式で、サーバーレスコンテナと呼ばれます。利用者の責任範囲がコンテナイメージとその設定だけに縮まるため、運用負荷が大きく下がります。これは責任共有モデルにおける境界線が、より AWS 側に寄ることを意味します。

トレードオフ

単価はEC2起動タイプより割高で、GPUの利用や細かなカーネル設定はできません。「変動が大きく管理を減らしたい」ならFargate、「常時高負荷でコストを詰めたい・特殊要件がある」ならEC2起動タイプ、が基本の判断軸です。

言語やプラットフォーム（Java、Python、Node.jsなど）を選んでコードを上げると、必要なリソースが自動的に用意され、その後の監視やスケーリングまで面倒を見てくれます。

用語のキホン：PaaSと「環境」

PaaSとは、アプリを動かす土台一式が提供され、利用者はアプリの中身に集中できる提供形態のことです。自分でサーバーを組むIaaS（EC2など）と、コードだけを預けるFaaS（Lambda）の中間にあたります。デプロイ先の単位を環境と呼び、本番用・検証用のように分けて作ります。重要なのは、自動生成されたEC2やELBは隠されているわけではなく普通に操作できる点で、必要なら設定ファイルで細かく調整できます。

どんなときに選ぶか

「インフラの知識が浅いチームが素早く公開したい」「構成は標準的でよい」という場合に向きます。逆に、独自のネットワーク構成や細かなチューニングが要件なら、EC2やコンテナで自前構築するほうが適します。

AWS Batchは、数千件規模のジョブを受け付け、実行に必要なEC2やFargateを自動的に起動・停止します。利用者はジョブの定義とキューへの投入だけを行えばよく、サーバーの用意や後片付けを意識しません。

用語のキホン：バッチ処理とジョブキュー

バッチ処理とは、画面で対話しながらではなく「まとめて一括で」実行する処理のことです（夜間集計、動画変換、科学計算など）。ジョブキューは実行待ちの仕事を並べておく待ち行列で、優先度を付けられます。ジョブ定義には「どのコンテナイメージで、CPUとメモリをどれだけ使うか」を書きます。Batchはキューの溜まり具合に応じてコンピューティング環境（実行用のEC2群）を自動で増減させ、仕事がなくなればゼロ台まで縮小するため、待機コストが発生しません。

コスト最適化との相性

バッチ処理は「途中で止まっても、もう一度実行すればよい」ものが多く、中断を許容できます。この性質は余剰リソースを安く使うスポットインスタンスと非常に相性がよく、最大約90%の割引を活かせます。試験でも「大量計算をできるだけ安く」という要件でよく登場します。

コンテナで Web サービスを公開するには、通常はクラスター、タスク定義、ロードバランサー、証明書などを組み合わせます。App Runner はそれらを内部に隠し、利用者にはソースと最小限の設定だけを求めます。リポジトリへの push を検知した自動デプロイにも標準で対応します。

用語のキホン：PaaS とコンテナの自動デプロイ

PaaS（Platform as a Service）とは、OS やミドルウェア、実行基盤の管理を提供者側が引き受け、利用者はアプリケーションのコードだけに集中できる提供形態を指します。対して IaaS は仮想サーバーまでが提供範囲で、その上の構成は利用者の責任です。App Runner は PaaS 寄りの位置づけで、コンテナという可搬性のある形式を入力としながら、実行基盤の設定を利用者から見えなくしています。利用者が触るのはポート番号、環境変数、CPU とメモリの大きさ、同時実行数といった項目に限られ、その代わり細かな制御はできません。

Elastic Beanstalk・Fargate との違い

Elastic Beanstalk は EC2 やロードバランサーを利用者のアカウント内に実際に作り、必要ならその設定を直接変更できます。管理対象は見えており、自由度が高い代わりに考慮点も残ります。AWS Fargate はサーバー管理の不要なコンテナ実行基盤ですが、ECS や EKS のクラスター、タスク定義、ロードバランサーは利用者が設計します。App Runner はその設計自体を不要にした最も抽象度の高い選択肢で、常時稼働の HTTP サービスを素早く立ち上げたい場合に向きます。逆に、バッチ処理、細かなネットワーク制御、複雑なサービス間連携が必要なら Fargate を選びます。

AWS の標準的なサービス群は柔軟である反面、選択肢が多く初期構築に時間がかかります。Lightsail は構成をあらかじめ組み合わせた「プラン」として提示し、選ぶだけで動く状態にします。WordPress などのアプリケーションが導入済みのイメージも用意されています。

用語のキホン：抽象化された仮想サーバーと定額課金

クラウドの仮想サーバーは通常、CPU、メモリ、ストレージ、データ転送量をそれぞれ個別に選び、個別に課金されます。この方式は無駄がない反面、月額費用の見積もりが難しくなります。Lightsail はこれらを束ねたバンドルとして提供し、一定のデータ転送量まで含んだ月額固定料金にしています。設定項目を減らして分かりやすさを優先した設計であり、その分だけ選べる構成の幅は狭くなります。

EC2 との違いと移行

Amazon EC2 はインスタンスタイプ、ネットワーク、セキュリティグループ、Auto Scaling などを細かく設計でき、大規模で複雑な要件に応えられます。Lightsail はその大半を固定しており、VPC の詳細設計や高度なスケーリングには向きません。ただし VPC ピアリングで既存の VPC と接続でき、規模が大きくなった際には EC2 へ移行する経路も用意されています。SAP-C02 では、本格的な本番基盤ではなく、小規模・短期・低運用負荷という条件が示されたときの選択肢として押さえます。

AWSが管理するラックが自社施設に届き、設置後はクラウドと同じAPIやツールで操作できます。運用・保守はAWSが担当します。

用語のキホン：ハイブリッドクラウドとデータレジデンシー

ハイブリッドクラウドとは、クラウドと自社設備を組み合わせて使う形態です。Outpostsはその極端な形で、AWSそのものを自社内に置きます。導入理由は主に2つあります。1つはデータレジデンシー——「データを特定の国や施設の外に出してはならない」という法規制や社内規程の要件です。もう1つは低遅延で、工場の製造ラインのようにミリ秒単位の応答が必要な場合、クラウドまでの通信の往復時間が無視できなくなります。

似た選択肢との切り分け

低遅延が目的なら、通信事業者の5G網の中に配置するAWS Wavelength、大都市圏のエッジに配置するLocal Zonesも候補です。「自社の建物の中に置く必要がある」ならOutposts、と切り分けると迷いません。

通常、スマートフォンからクラウドへの通信は、基地局から事業者網を抜けてインターネットを経由します。Wavelengthは事業者網の内部（Wavelength Zone）にEC2などを配置し、この経路を大幅に短縮します。

用語のキホン：エッジコンピューティングと遅延

遅延（レイテンシー）とは、データが往復するのにかかる時間のことです。距離が長いほど、また経由する機器が多いほど大きくなります。エッジコンピューティングとは、処理をできるだけ利用者の近くで行い、この遅延を削る考え方です。AWSにはエッジ配置の選択肢が段階的に用意されており、利用者に近い順に、事業者5G網内のWavelength、大都市圏のLocal Zones、自社施設内のOutposts、そして通常のリージョンとなります。

向いている用途

AR・VR、リアルタイム対戦ゲーム、自動運転車からの映像解析、工場の遠隔制御など、数十ミリ秒の差が体験や安全性を左右する用途に向きます。逆に、通常のWebサイトやバッチ処理では、リージョンで十分です。

ECSは、コンテナをまとめて運用するためのAWS独自のサービスです。IAMやELB、CloudWatchとそのまま統合できるため、AWS中心の構成では最も導入しやすい選択肢になります。

用語のキホン：コンテナとオーケストレーション

コンテナとは、アプリと必要なライブラリを1つにまとめ、どの環境でも同じように動かせるようにした軽量な実行単位です。仮想マシンと違いOSごと持たないため、起動が速く軽量です。多数のコンテナについて「何個動かすか、異常なら再起動するか、どう振り分けるか」まで自動で管理する仕組みをオーケストレーションと呼び、ECSがこれを担います。

タスクとサービス

実際に動くコンテナのひとまとまりをタスク、その設計図をタスク定義と呼びます。そして「常時この数のタスクを維持し、落ちたら補充する」という継続稼働の仕組みがサービスです。動かす土台は、自分で管理するEC2起動タイプと、AWSに任せるFargateから選べます。

EKSは、コンテナオーケストレーションの業界標準であるKubernetesを、AWS上でマネージドに使えるようにしたサービスです。

用語のキホン：Kubernetesとコントロールプレーン

Kubernetesは、コンテナの配置・自動復旧・負荷分散を宣言的に管理するオープンソースの基盤です。「あるべき状態」をマニフェストに書くと、実際の状態がそこへ収束します。Kubernetesは指令を出すコントロールプレーンと、実際にコンテナが動くデータプレーン（ワーカーノード）に分かれ、このうち構築・運用が最も難しいコントロールプレーンをAWSが管理してくれるのがEKSです。コンテナの最小実行単位はポッドと呼ばれます。

ECSとの選び分け

AWSに寄せてシンプルに運用したいならECS、既存のKubernetes資産や他クラウドとの共通化を活かしたいならEKSが基本です。EKSは機能が豊富な反面、学習コストと管理コストは高くなります。

ECSやEKSがコンテナを起動する際、その元になるイメージを取得する先がECRです。プライベートな倉庫として、社内のイメージを安全に保管できます。

用語のキホン：イメージ・レジストリ・タグ

コンテナイメージは、アプリと実行環境をまとめて固めた「テンプレート」で、これを起動したものがコンテナです。そのイメージを保管・配布する場所がレジストリで、ECRがこれにあたります。イメージにはタグ（v1.2、latestなど）を付けて版を区別します。ただしタグは付け替えられるため、同一性を厳密に保証したい場合は内容から算出されるダイジェストで指定します。

セキュリティとコスト管理

登録時に自動で脆弱性スキャンを行えます（Amazon Inspectorと連携）。またライフサイクルポリシーで「古いイメージは自動削除」と設定でき、保管料金の膨張を防げます。

手元のサーバーにエージェントを導入すると、そのサーバーがECSの「外部インスタンス」として登録され、AWSのコンソールから同じようにコンテナを配置できるようになります。

用語のキホン：コントロールプレーンだけをクラウドに置く

ポイントは、指令を出す側（コントロールプレーン）はAWS上にあり、実際にコンテナが動く場所（データプレーン）だけが自社にあるという構成です。これにより、管理画面・権限管理・デプロイ手順はクラウドと共通化しつつ、処理そのものは手元で実行できます。データを外に出せない、あるいは既存のハードウェアを使い切りたい、という事情に応えます。

Outpostsとの違い

OutpostsはAWSのハードウェアを自社に置くのに対し、ECS Anywhereはすでにある自社のサーバーをそのまま使う点が異なります。追加のハードウェア投資が不要な分、手軽に始められます。

EKS Anywhereは、AWSが検証した構成のKubernetesクラスターを自社設備上に作るためのソフトウェアです。インストーラーや更新手順が用意され、自前でKubernetesを組むより運用が安定します。

用語のキホン：ECS Anywhereとの決定的な違い

名前は似ていますが構造が異なります。ECS AnywhereはコントロールプレーンがAWS上にあり、常時接続が前提です。一方EKS Anywhereはコントロールプレーンも含めて完全に自社内で完結し、インターネットから切り離された環境（エアギャップ環境）でも動作します。「クラウドに繋がらない場所でも動かす必要があるか」が選択の分かれ目になります。

EKSとの関係

AWS上のEKSと同じディストリビューション（EKS Distro）を使うため、両者でバージョンや挙動を揃えやすく、将来クラウドへ移行する際の差異も小さく抑えられます。

EKS Distro（EKS-D）は、AWSがEKSで実際に動かしているKubernetesとその依存コンポーネントを、テスト済みの組み合わせとして公開したものです。

用語のキホン：ディストリビューションとは

ディストリビューションとは、本体のソフトウェアに、動作に必要な周辺部品とバージョンの組み合わせを添えて「これで動きます」とまとめた配布物のことです（Linuxのディストリビューションと同じ考え方です）。Kubernetesは多数の部品の組み合わせで成り立っており、その相性合わせが運用上の大きな負担になります。EKS-Dはその検証済みの組み合わせを提供することで、この負担を減らします。

3つの関係の整理

EKS＝AWSがフルマネージドで運用、EKS Anywhere＝自社設備に構築する製品、EKS Distro＝その土台となる部品の配布、という関係です。EKS-Dは最も自由度が高い代わりに、構築と運用は完全に自己責任となります。

S3は、写真・動画・ログ・バックアップなどの「オブジェクト（ファイル）」を、容量を気にせず保管できるサービスです。データは「バケット」に入れ、「キー（ファイル名のようなもの）」で管理します。保存したデータは自動的に複数AZへ複製され、99.999999999%（イレブンナイン）という非常に高い耐久性を実現します。書き込み後すぐ読める「強い整合性」を持ちます。

用語のキホン：3種類のストレージ

AWSのストレージは大きく3種類あり、役割が異なります。オブジェクトストレージ（S3）はファイルを丸ごと出し入れする方式でWeb配信やバックアップ向き、ブロックストレージ（EBS）はOSやDBが使うディスク、ファイルストレージ（EFS）は複数サーバーで共有するフォルダです。S3はこのうちオブジェクト型で、ファイルの部分書き換えより「まるごと保存・取得」を得意とします。

コスト最適化と管理機能

アクセス頻度に応じ「標準／標準-IA（低頻度）／One Zone-IA／Glacier系（アーカイブ）」から選びます。自動で変化させたい場合は「ライフサイクルルール」で古いデータをGlacierへ移したり削除したりします。誤削除に備える「バージョニング」、別リージョンへ複製する「レプリケーション（CRR）」もあります。

セキュリティ

暗号化は「SSE-S3」「SSE-KMS」などから選べます。アクセス制御はバケットポリシー・IAM・ACLで行い、誤公開を防ぐ「ブロックパブリックアクセス」を有効にするのが基本です。VPC内から非インターネット経由でアクセスするにはゲートウェイ型VPCエンドポイントを使います。

EBSは、EC2にアタッチして使う永続的なディスクで、OSの起動ディスクやデータベースの保存領域として使います。ひとつのAZ内に存在し、原則1台のEC2に接続します（複数台で同時共有したい場合はEFS）。

用語のキホン：ブロックストレージとIOPS

ブロックストレージとは、データを一定サイズの「ブロック」に分けて扱う方式で、OSからは普通のハードディスクとして見えます。性能は2つの指標で表され、IOPSは「1秒間に何回読み書きできるか」（細かい処理の多さに効く）、スループットは「1秒間に何MB流せるか」（大きなファイルの転送に効く）を意味します。データベースは高IOPS、動画や分析処理は高スループットが重要になります。

ボリュームタイプ

用途で種類を選びます。汎用SSDのgp3（多くの用途の標準）、高IOPSが必要なDB向けのio2、大容量シーケンシャル向けのHDD系st1／sc1があります。gp3はIOPSとスループットを容量と独立して設定できます。io2は複数EC2から使う「マルチアタッチ」にも対応します。

バックアップと保護

「スナップショット」はその時点の増分バックアップをS3上に保存し、そこから復元・別AZや別リージョンへコピーできます。KMSで暗号化でき、ボリュームサイズやタイプは稼働中でも変更可能です。

EFSは、NFSという方式で複数のサーバーから同時に読み書きできる共有ファイルストレージです。複数AZにまたがって配置されるため可用性が高く、容量はデータ量に応じて自動で増減するため、事前の容量設計が不要です。

用語のキホン：ファイル共有とマウント

ファイルストレージは、フォルダとファイルの階層で扱う方式で、普段PCで使う感覚に最も近い形式です。NFSは、ネットワーク越しにその共有フォルダを使うための標準的な仕組みを指します。マウントとは、その共有フォルダを自分のサーバーの一部（例：/mnt/share）として接続し、ローカルのフォルダと同じように読み書きできる状態にすることです。

性能とコストの調整

アクセス頻度が低いファイルを自動で低コスト階層（IA）へ移す「ライフサイクル管理」でコストを抑えられます。用途に応じて性能モードやスループットモードを選び、細かなアクセス制御は「アクセスポイント」で行えます。1台専用のEBSと違い、複数台同時共有が最大の特長です。

FSxは1つのサービスではなく、目的別に4種類が用意されたファイルストレージのシリーズです。既存の業務システムをそのまま移すときに力を発揮します。

用語のキホン：4種類の使い分け

FSx for Windows File ServerはSMBプロトコルとActive Directory連携に対応し、Windowsの共有フォルダをそのまま移せます。FSx for Lustreは極めて高速な並列処理向けで、機械学習や流体解析などのHPC（高性能計算）で使われ、S3と連携して大量データを高速に読み込めます。FSx for NetApp ONTAPとFSx for OpenZFSは、それぞれ同名のストレージ製品と同じ機能（スナップショット、重複排除など）をAWS上で提供します。

EFSとの選び分け（頻出）

ここが試験の要点です。Linuxで共有したいならEFS（NFS）、Windowsで共有したいならFSx for Windows（SMB）、とにかく高速な並列I/Oが要るならFSx for Lustre、と対応させて覚えます。問題文に「Active Directory」「SMB」とあればFSx for Windows、「HPC」「機械学習の学習データ」とあればLustreが手がかりになります。

S3には用途別のストレージクラスがあり、そのうち長期保管（アーカイブ）向けの一群がGlacierです。耐久性は標準クラスと同じ99.999999999%を保ちながら、保管単価だけを大きく下げられます。

用語のキホン：ストレージクラスと取り出し時間のトレードオフ

S3の料金は「保管料金」と「取り出し料金」に分かれます。ストレージクラスとは、この2つのバランスを選ぶ仕組みです。頻繁に読むS3 標準は保管が高く取り出しは無料、めったに読まないGlacier系は保管が非常に安い代わりに取り出しに時間と料金がかかります。アーカイブ系は安い順に、数時間で取り出すGlacier Deep Archive、数分から数時間のGlacier Flexible Retrieval、ミリ秒で取り出せるGlacier Instant Retrievalがあります。「年に1回読むか読まないか」ならDeep Archive、「めったに読まないがすぐ必要」ならInstant Retrievalが適します。

ライフサイクルポリシーによる自動移行

実務では手動で移し替えず、ライフサイクルポリシーで「作成から30日で低頻度アクセスへ、90日でGlacierへ、1年でDeep Archiveへ、7年で削除」と自動化します。またアクセス傾向が読めない場合は、自動で最適なクラスへ移すIntelligent-Tieringが有効です。試験では「ログを7年保管、通常は参照しない」といった要件でDeep Archiveが正解になる形が頻出します。

自社内に仮想アプライアンス（または専用機器）を置くと、既存のサーバーからは普通のファイル共有やテープ装置に見え、その実体はS3などのAWSストレージになります。アプリを書き換えずにクラウドの容量を使えるのが利点です。

用語のキホン：3つのゲートウェイ型

接続の見え方によって3種類あり、これを区別できるかが試験のポイントです。ファイルゲートウェイはNFSやSMBの共有フォルダとして見え、置いたファイルはS3のオブジェクトになります。ボリュームゲートウェイはiSCSIのディスクとして見え、バックアップがS3に保存されます。テープゲートウェイは仮想テープ装置として見え、既存のバックアップソフトをそのまま使いながら、実際の保存先をS3 GlacierやDeep Archiveにできます。

キャッシュという考え方

すべての実体がクラウドにあると読み込みが遅くなるため、ゲートウェイは手元にローカルキャッシュを持ちます。よく使うデータは手元から高速に返し、それ以外はクラウドから取得する仕組みです。これにより「容量は実質無制限、体感速度はローカル並み」を両立します。物理テープ装置の廃止や、バックアップ保管先のクラウド化でよく採用されます。

サービスごとに個別のスナップショット設定を組むと、設定漏れや期間の不揃いが起きます。AWS Backupは、対象と頻度と保管期間をまとめて定義し、組織全体へ適用できます。

用語のキホン：バックアッププランとボールト

バックアッププランとは「毎日午前2時に取得し、30日間保管、月次分は1年保管」といった取得ルールの定義です。対象リソースは個別指定のほか、タグによる自動選択ができるため、新しく作られたリソースも条件に合えば自動的に保護されます。取得したバックアップの保管先はバックアップボールトと呼ばれ、KMSで暗号化されます。さらにボールトロックを有効にすると、管理者であっても保持期間内の削除ができなくなり、ランサムウェア対策や法令上の改ざん防止要件を満たせます。

コンプライアンス用途

取得状況をレポートでき、「すべてのリソースが計画どおり保護されているか」を監査時に示せます。個別スナップショットの寄せ集めでは難しい、この一元的な証明が採用理由になることが多い機能です。

災害対策のために本番と同じ規模の設備をもう一式用意すると、費用は倍近くになります。Elastic Disaster Recoveryは、複製先を安価なストレージ中心の待機構成に留めることで、この課題に応えます。実際の切り替え時に初めて本番相当のインスタンスを起動する仕組みです。

用語のキホン：RTO・RPOと継続的レプリケーション

災害対策の設計は2つの指標から始まります。RTO（目標復旧時間）は、障害発生からシステムが再び使えるようになるまでに許容できる時間です。RPO（目標復旧時点）は、どの時点までのデータなら失っても許容できるかを表し、言い換えれば失ってよいデータの時間幅です。この2つを短くするほど設計は高度になり、費用も上がります。継続的レプリケーションとは、ディスクへの書き込みをほぼリアルタイムで複製先へ送り続ける方式で、1日1回のバックアップと比べてRPOを大幅に短くできます。Elastic Disaster Recoveryはこの継続的レプリケーションによって、秒単位に近いRPOと分単位のRTOを目指せる位置づけのサービスです。

移行用途と復旧訓練

ディスクを丸ごと複製して起動するという仕組みは、リホスト型の移行そのものと同じです。そのため災害対策だけでなく、移行手段として使われることもあります。また、本番の複製を止めずにドリル（復旧訓練）用のインスタンスを起動できるため、実際に切り替えが成功するかを事前に検証できます。切り替え後にオンプレミスへ戻すフェイルバックにも対応しています。

RDSは、DBの構築・自動バックアップ・ソフト更新などをAWSが代行してくれるマネージドなリレーショナルデータベースです。MySQL・PostgreSQL・MariaDB・Oracle・SQL Server・Auroraなどのエンジンに対応します。設定は「パラメータグループ」で管理します。

用語のキホン：フェイルオーバーとレプリケーション

フェイルオーバーとは、稼働中の系（本番）に障害が起きたとき、自動で予備の系（待機系）に切り替えて処理を続けることです。レプリケーションはデータの複製で、本番と複製を常に一致させる「同期レプリケーション」（マルチAZで使用）と、少し遅れて追いつく「非同期レプリケーション」（リードレプリカで使用）があります。

可用性と読み取りスケール（頻出）

マルチAZ配置は、別AZの「待機系」へ同期複製し、障害時に自動で切り替える「可用性」の仕組みで、待機系は普段読み取りに使えません。一方リードレプリカは、読み取り専用コピーを増やして参照負荷を分散する「読み取りスケール」の仕組みです。目的が真逆なので必ず区別しましょう。

バックアップと接続管理

「自動バックアップ」で任意の時点に復元でき、手動「スナップショット」も取れます。接続が多い場合はRDS Proxyでコネクションをまとめて安定させられます。より高い性能・可用性が必要ならAurora（後述のDB群）も選択肢です。

Auroraは、既存のMySQLやPostgreSQLをクラウド向けに作り直したデータベースです。アプリケーション側から見れば普通のMySQL・PostgreSQLですが、内部の保存の仕組みが根本的に異なります。SAA-C03では「RDSより高い可用性と読み取り性能が欲しい場合の選択肢」として頻出します。

用語のキホン：クラスターとストレージ分離、ライターとリーダー

Auroraでは、SQLを処理するデータベースインスタンス（計算を担当するサーバー）と、データを実際に保存する共有ストレージ（保存領域）が切り離されています。この一式をまとめてクラスターと呼びます。クラスターの中で書き込みを受け付けるインスタンスをライター、読み取り専用のインスタンスをリーダーと呼び、ライターは1台、リーダーは複数台置けます。すべてのインスタンスが同じストレージを共有しているため、リーダーを増やしてもデータをコピーする必要がなく、読み取りの負荷分散をすばやく行えます。接続先としては、常にライターへつながるクラスターエンドポイントと、リーダーへ振り分けるリーダーエンドポイントという2つの窓口が用意されます。

6重複製とフェイルオーバー

Auroraのストレージは、3つのアベイラビリティゾーン（同一リージョン内の物理的に離れたデータセンター群）にそれぞれ2つずつ、合計6つのコピーとしてデータを保持します。そのため一部のコピーが失われても読み書きを続けられます。ライターに障害が起きると、リーダーの1つが自動的にライターへ昇格するフェイルオーバーが発生し、切り替えは通常きわめて短時間で完了します。昇格の順序は各リーダーに設定した優先度（ティア）で制御できます。RDSのマルチAZ配置が待機系へ切り替える仕組みなのに対し、Auroraでは待機系がそのまま読み取りにも使える点が違いです。

通常のAuroraでは、CPUやメモリの大きさを決めたインスタンスクラスを選んで起動します。Aurora Serverlessでは、その選択を行わず、実際の負荷に合わせてAWS側が容量を調整します。データベース本体の機能は通常のAuroraと同じです。

用語のキホン：キャパシティの自動スケーリング

スケーリングとは、処理能力を増やしたり減らしたりすることです。サーバーの台数を増やす方式をスケールアウト、1台の性能そのものを上げ下げする方式をスケールアップ・ダウンと呼びます。Aurora Serverlessは後者を自動で行い、容量はACU（Aurora Capacity Unit）という、CPUとメモリをまとめて表す単位で計られます。利用者は最小ACUと最大ACUという上下限だけを決めておき、その範囲内で実際の負荷に追従します。これにより、ピークに合わせて常時大きなインスタンスを動かし続ける無駄を避けられます。

使いどころと注意点

負荷が一日の中で大きく上下する場合や、開発・検証環境のように使わない時間が長い場合に効果が出ます。逆に、負荷が常に一定で高い本番システムでは、通常のAuroraをあらかじめ適切なサイズで動かすほうが素直で費用も読みやすくなります。世代によっては最小容量をゼロ近くまで下げて休止させられる設定もありますが、休止からの復帰にわずかな待ち時間が生じる点は考慮が必要です。

DynamoDBは、膨大なリクエストにもミリ秒単位で応答できるフルマネージドなNoSQLデータベースです。データは自動で複数AZへ複製され、サーバーを意識しません。

用語のキホン：NoSQLと整合性

NoSQLとは、表と表を結合するリレーショナルDBとは異なり、キーで高速に出し入れすることに特化したデータベースの総称です。読み取りには2種類あり、書き込み直後は少し古い値が返ることを許す代わりに速い結果整合性（既定・安価）と、常に最新を返す強い整合性（やや高コスト）を選べます。速さを取るか、最新であることを取るかで使い分けます。

キー設計とインデックス

各項目は「パーティションキー（＋任意のソートキー）」で管理します。性能を出すにはキー設計が重要です。別の条件で検索したいときは「GSI（グローバルセカンダリインデックス）」「LSI（ローカル〜）」を使います。処理能力は、使った分だけの「オンデマンド」か、あらかじめ確保する「プロビジョンド」から選びます。

拡張機能

変更を検知して後続処理につなげる「DynamoDB Streams」（Lambda連携）、世界規模の「グローバルテーブル」、期限切れ項目を自動削除する「TTL」、マイクロ秒応答の「DAX（キャッシュ）」などがあります。複雑な結合や集計が多い用途はRDSの方が向くこともあります。

ElastiCacheは、アクセスの多いデータをメモリ上に一時保存し、DBに毎回問い合わせずに高速に返す仕組みです。ディスクよりメモリの方が桁違いに速いため、応答時間を短縮でき、DBの読み取り負荷も大きく下げられます。

用語のキホン：インメモリとキャッシュ

インメモリとは、データをディスクではなくメモリ上に置くことで、ディスクより桁違いに速く読み書きできる方式です。キャッシュとは、よく使うデータの写しを手前に一時保存し、本体（DB）に毎回問い合わせず高速に返す仕組みです。写しが古くなりすぎないよう、一定時間で自動的に捨てる期限をTTLと呼びます。

RedisとMemcachedの違い

Redisは、データの永続化・レプリケーション（マルチAZ）・自動フェイルオーバー・豊富なデータ型（リストや順位表など）に対応し、高可用な用途に向きます。Memcachedはシンプルでマルチスレッド、単純なキャッシュを水平に増やしたいときに向きます。可用性やデータ構造が必要ならRedisを選ぶ、と覚えるとよいです。

業務システムのデータベースは「1件の注文を登録する」といった処理が得意ですが、「過去3年の売上を商品カテゴリ別に集計する」ような処理は苦手です。Redshift はこの後者、つまり分析専用に設計されたデータベースです。複数の業務システムからデータを集約し、全社の分析基盤として使われます。

用語のキホン：OLTP と OLAP、そして列指向ストレージ

OLTP（オンライントランザクション処理）とは、注文登録や在庫更新のように、少数の行を素早く読み書きする処理のことです。Amazon RDS や Aurora が担当する領域です。一方OLAP（オンライン分析処理）は、大量の行を読み込んで合計や平均を求める分析処理を指し、Redshift がこちらを担当します。Redshift が速い理由の一つが列指向ストレージ（データを行単位ではなく列単位でまとめて保存する方式）で、集計に必要な列だけを読めばよいため入出力量が大幅に減ります。加えてMPP（超並列処理。複数ノードで処理を分担する仕組み）により、各ノードが自分の担当データを同時に処理します。

使い分け：Athena・RDS との違いと Redshift Spectrum

都度の軽い分析やログ調査なら Athena、定常的に大量データを高速集計し BI ツールから何度も参照するなら Redshift、という整理が基本です。Redshift には Redshift Spectrum（S3 上のデータを Redshift から直接クエリする機能）があり、直近データはクラスター内、過去データは S3、という使い分けもできます。またサーバー管理を避けたい場合は、使った分だけ課金される Redshift Serverless という選択肢もあります。

DocumentDBは、MongoDBのAPI（操作の呼び出し方）に合わせて作られたマネージドサービスです。サーバーの構築やパッチ適用、バックアップはAWSが受け持ちます。ストレージはAuroraと同じ考え方で複数のアベイラビリティゾーンに複製され、リードレプリカも追加できます。

用語のキホン：ドキュメント指向データベース

ドキュメント指向データベースとは、行と列の表ではなく、ドキュメントと呼ばれる入れ子可能なデータのかたまりを単位として保存するデータベースです。ドキュメントはJSONに似た形式で表され、項目の構成がレコードごとに違っていても保存できます。この性質をスキーマレス（あらかじめ列の定義を固定しなくてよい）と呼びます。表形式のリレーショナルデータベースでは、商品ごとに属性が異なるようなデータを扱うと列が増えすぎがちですが、ドキュメント指向ならその情報を1つのドキュメントに素直に収められます。関連するデータをまとめて1件として読み書きできるため、アプリ側のオブジェクトとの相性がよいのも利点です。

DynamoDBとの使い分け

DynamoDBもキーと値を扱うNoSQLですが、こちらはキーを指定した高速なアクセスに最適化され、運用単位もテーブルごとです。DocumentDBはMongoDBの問い合わせ構文や集計処理をそのまま使いたい場合、あるいは既存のMongoDB資産を移行したい場合が主な選択理由になります。一方でDocumentDBはクラスターを常時起動する構成のため、アクセスが極端に少ない用途ではDynamoDBのほうが手軽です。

Neptuneは、データ同士の関係そのものを主役として保存するデータベースです。リレーショナルデータベースで何度も結合を重ねないと辿れないような関係を、少ない手数で探索できます。マネージドサービスとして、複数のアベイラビリティゾーンへの複製やリードレプリカに対応しています。

用語のキホン：グラフデータモデル

グラフとは、点と線でものごとの関係を表す考え方です。データベースでは、人や商品といった対象をノード（頂点）、「購入した」「友人である」といった関係をエッジ（辺）として保存します。ノードにもエッジにも属性を持たせられるため、「いつ購入したか」といった情報も関係の側に記録できます。この構造では、あるノードから隣のノードへ次々と辿るトラバースという操作が中心になり、関係が何段階も連なる検索でも性能が落ちにくいのが特徴です。表を結合していく方式では段数が増えるほど負荷が跳ね上がるため、この点が大きな違いになります。

問い合わせ言語と適用領域

Neptuneは、プロパティグラフ向けのGremlinやopenCypher、RDF向けのSPARQLといったグラフ用の問い合わせ言語に対応します。単純な集計や帳票のような用途ではリレーショナルデータベースのほうが適しており、あくまで関係の探索が中心となる場面で選びます。SAA-C03では「関係性をたどる要件が出てきたらNeptune」と対応づけて覚えておくとよいでしょう。

Apache Cassandraは、多数のサーバーに分散してデータを保持するオープンソースのデータベースですが、自前で運用するとクラスターの管理が重くなります。Keyspacesはその互換インターフェースをマネージドサービスとして提供し、ノードの増減やパッチ適用を意識せずに使えるようにしたものです。

用語のキホン：ワイドカラムストアとパーティションキー

ワイドカラムストアとは、行ごとに持つ列の顔ぶれが異なってもよい、表に似た構造のNoSQLデータベースです。データはキースペース（データベースに相当するまとまり）の中のテーブルとして定義されます。各行はパーティションキーという値によってどのサーバーに置くかが決まり、同じパーティションの中ではクラスタリングカラムによって並び順が決まります。この仕組みにより、キーを指定した読み書きが台数を増やしてもほぼ一定の速さで処理でき、書き込み量の多い時系列データと相性がよくなります。操作にはCQLという、SQLに似た専用の問い合わせ言語を使います。

DynamoDBとの使い分け

KeyspacesとDynamoDBは、どちらもキーで分散する点で発想が近く、性能特性も似ています。選択の決め手は互換性で、すでにCassandraを使っている、あるいはCassandraのドライバーやCQLを前提としたアプリがあるならKeyspacesが自然です。新規開発でAWSの他サービスとの連携を重視するなら、DynamoDBのほうが機能の選択肢が広くなります。

Timestreamはサーバーの管理が不要で、書き込み量に応じて自動的に拡張します。SQLに近い問い合わせ言語を備え、時間軸に沿った集計や補間の関数が最初から用意されています。

用語のキホン：時系列データ

時系列データとは、「いつ」「どの対象が」「どんな値だったか」の3点が組になって、時間の経過とともに積み上がっていくデータのことです。特徴は、過去のレコードをほとんど更新せず追記だけが続くこと、そして新しいデータほど頻繁に参照され、古いデータは集計にしか使われないことです。この性質に合わせてTimestreamは、直近のデータを高速なメモリストアに、古いデータを安価なマグネティックストアに自動的に移す階層構造を持ちます。利用者はどちらにあるかを意識せず同じクエリで横断的に検索でき、保持期間を設定しておけば期限切れのデータは自動で削除されます。

他のデータベースとの使い分け

DynamoDBでも時刻をソートキーにすれば時系列を保存できますが、期間をまたぐ集計や移動平均のような分析はアプリ側で実装する必要があります。RDSなどのリレーショナルデータベースは、書き込みが秒間数万件規模になると拡張が難しくなります。SAP-C02の観点では、追記中心で保持期間による自動削除と時間軸の分析関数が要件に挙がっていればTimestream、単一キーでの高速な読み書きが主目的ならDynamoDB、と読み分けます。

通常のデータベースを使う場合は、まずサーバーを用意し、テーブルを設計し、データを流し込む必要があります。Athena はこの手順を省き、S3 上の CSV や JSON、Parquet といったファイルを「テーブルのように見立てて」直接 SQL を投げられます。ログ分析のように「たまに分析したいが、そのために常時稼働のデータベースは持ちたくない」場面に向いています。

用語のキホン：スキーマオンリードとサーバーレス分析

従来のデータベースはスキーマオンライト（書き込み時にスキーマを決める方式）で、データを入れる前に列の名前や型を定義し、その形に合わせて変換してから格納します。これに対し Athena はスキーマオンリード（読み込み時にスキーマを当てる方式）で、ファイルはそのまま S3 に置いておき、クエリを実行する瞬間に「この列はこういう型だ」という定義を当てはめて解釈します。この定義はデータカタログ（AWS Glue データカタログ）に登録しておきます。さらに Athena はサーバーレス（利用者がサーバーを一切用意・管理しない形態）なので、クエリを投げない間は費用が発生しません。

試験ポイント：コストとパフォーマンスの改善策

Athena はスキャンしたデータ量で課金されるため、スキャン量を減らす工夫がそのまま費用削減になります。列指向フォーマットである Parquet や ORC（必要な列だけを読み出せるファイル形式）へ変換すると、全列を読まずに済みます。また日付などでフォルダを分けるパーティション（データを区切って格納する仕組み）を設計すると、対象期間のファイルだけをスキャンできます。圧縮も併用すると、さらにスキャン量を抑えられます。

ファイルにまとめてから夜間に処理する方式では、異常検知や即時のレコメンドには間に合いません。Kinesis Data Streams はデータを到着順に受け止める「川の流れ」のような役割を果たし、その流れを複数の処理系が同時に読み取れるようにします。

用語のキホン：ストリーミングデータとシャード

ストリーミングデータとは、終わりが定義されず継続的に発生し続けるデータのことです。これを扱うため、Kinesis Data Streams はシャード（ストリームを構成する処理単位。並列度と処理能力を決める単位）という概念を持ちます。シャードを増やすほど、同時に受け付けられるデータ量と読み出し能力が上がります。各データにはパーティションキー（どのシャードに振り分けるかを決める値）を付け、同じキーのデータは同じシャードに入るため、その中では順序が保たれます。データは保持期間（既定はおよそ1日で、設定により延長可能）の間ストリーム内に残り、その間は複数のコンシューマー（読み出し側アプリケーション）が独立して読めます。

使い分け：SQS との違い

Amazon SQS はキューであり、あるメッセージを1つの処理系が受け取って処理すると、そのメッセージは消えます。一方 Kinesis Data Streams はデータを保持期間中は消さないため、同じデータをリアルタイム集計・機械学習・アーカイブなど複数の用途で同時に読めます。「順序が必要」「同じデータを複数系統で処理したい」「読み直したい」といった要件があれば Kinesis、単純な処理の分散や疎結合化なら SQS、と判断します。

ストリーミングデータをただ S3 に貯めたいだけなのに、読み出しアプリケーションを自作して運用するのは負担が大きい作業です。Data Firehose はその配信部分を丸ごと引き受け、送信先とバッファ条件を指定するだけで動きます。シャード数の管理も不要で、流量に応じて自動的に拡張します。

用語のキホン：バッファリングとニアリアルタイム

Data Firehose はデータを1件ずつ書き出すのではなく、一定量または一定時間ぶんをバッファ（一時的にためておく領域）に蓄えてから、まとめて送信先に書き込みます。このため配信には数十秒から数分程度の遅れが生じ、これをニアリアルタイム（完全な即時ではないが十分に短い遅延）と呼びます。ミリ秒単位の即応性が必要な場合は Kinesis Data Streams と独自のコンシューマーを組み合わせます。配信の途中で AWS Lambda を呼び出してデータを加工したり、JSON を Parquet へ変換したりすることも設定で行えます。

使い分け：Kinesis Data Streams との関係

Data Streams は「保持して複数の処理系に読ませる」ためのもの、Data Firehose は「保存先へ届ける」ためのものです。両者は組み合わせて使うこともでき、Data Streams をソースにして Data Firehose で S3 へアーカイブする構成が一般的です。逆に、単に S3 へ貯めたいだけならデータ送信元から直接 Data Firehose に送ればよく、構成がシンプルになります。

分析の現場では、データが S3・RDS・オンプレミスのデータベースなどに散在し、形式もばらばらであることがほとんどです。Glue はこれらを横断して読み取り、必要な変換をかけて、分析基盤が扱いやすい形に整えます。サーバーの用意は不要で、処理が動いている間だけ課金されます。

用語のキホン：ETL とデータカタログ

ETL とは Extract（抽出）・Transform（変換）・Load（格納）の頭文字で、元データを取り出し、分析しやすい形に整えて、保存先に書き込む一連の処理を指します。Glue の中心にあるのが AWS Glue データカタログ（どこにどんな構造のデータがあるかを記録した中央のメタデータ台帳）です。ここには表名・列名・型・保存場所などが登録され、Athena や Redshift Spectrum、Amazon EMR から共通の定義として参照されます。カタログを埋めるのが Glue クローラー（対象のデータを走査して構造を自動推定し、カタログに登録する仕組み）で、新しいパーティションの追加も検出できます。実際の変換処理は Glue ジョブ（Apache Spark や Python で書かれた処理）として実行します。

試験ポイント：どの場面で選ぶか

「サーバーレスで ETL したい」「データの構造を自動で把握したい」という要件が出たら Glue が第一候補です。処理内容を細かく制御したい、既存の Spark や Hive の資産を使いたい、といった場合は Amazon EMR が適します。単発の軽い加工なら Lambda、常時流れるデータの変換なら Data Firehose の変換機能、という選択肢もあります。

数テラバイト規模のデータを1台のサーバーで処理しようとすると、時間もメモリも足りません。EMR は多数のサーバーに処理を分担させる仕組みを、数クリックまたは API 呼び出しで用意します。オープンソースの分散処理基盤をそのまま使えるため、既存のコードや知識を活かしやすいのが特徴です。

用語のキホン：分散処理とクラスターのノード構成

分散処理とは、大きな仕事を小さく分割して複数のサーバーで同時に実行し、結果を統合する考え方です。EMR のクラスターは役割の違うノード（クラスターを構成する個々のサーバー）で構成されます。全体を統括するプライマリノード、実際に計算とデータ保持を担うコアノード、計算だけを一時的に手伝うタスクノードの3種類です。タスクノードはデータを保持しないため、中断されても失われるものがなく、割安なスポットインスタンス（余剰キャパシティを安価に使える購入方式。中断される可能性がある）を割り当てるのが定石です。

試験ポイント：コスト最適化と Glue との使い分け

コストを問われた場合、コアノードはオンデマンドまたはリザーブド、タスクノードはスポット、という組み合わせが典型的な正解です。またデータを HDFS ではなく S3 に置く（EMRFS を利用する）ことで、クラスターを処理のたびに作って消せる一時クラスターの運用ができ、無駄な稼働時間をなくせます。Spark や Hive の細かな設定を自分で制御したいなら EMR、運用の手間を最小化したいなら Glue、と整理できます。

ログファイルの中から「特定のエラーメッセージを含む行」を探したいとき、ファイルを順に読んでいては時間がかかります。OpenSearch Service はあらかじめ検索用の索引を作っておくことで、この種の検索を瞬時に返します。オープンソースの OpenSearch および互換の Elasticsearch を、AWS が運用してくれる形です。

用語のキホン：全文検索と転置インデックス

全文検索とは、文書の中身の単語から目的の文書を探し出す仕組みです。これを支えるのが転置インデックス（単語ごとに「その単語がどの文書に出現するか」を一覧化したデータ構造）で、書籍の巻末索引と同じ発想です。データを取り込む際には文章を単語に分割するアナライザー（日本語なら形態素解析などを行う処理）が働き、索引が作られます。データはインデックス（表に相当する単位）に格納され、内部ではシャード（インデックスを分割した単位）とその複製であるレプリカに分かれて複数ノードに配置されるため、可用性と検索性能を両立できます。

使い分け：Athena や CloudWatch Logs との違い

数分以内の新しいログを対話的に検索し、ダッシュボードで常時監視したいなら OpenSearch Service が適します。長期保管したログをたまに SQL で集計するだけなら、S3 と Athena の方が安価です。ログの収集と簡易な検索だけであれば CloudWatch Logs で足りる場合もあります。実務ではデータ取り込み経路として Data Firehose を使い、S3 への長期保管と OpenSearch への直近データ投入を併用する構成がよく取られます。

以前はAmazon Kinesis Data Analyticsという名称で提供されていた機能が、現在の名前に変わりました。KinesisデータストリームやAmazon MSK（マネージドなApache Kafka）を入力とし、処理結果をS3やOpenSearch、別のストリームへ書き出します。

用語のキホン：ストリーム処理

ストリーム処理とは、データをいったん貯めてからまとめて処理するバッチ処理と対になる考え方で、データが到着した瞬間に処理を進める方式です。終わりのないデータの流れを扱うため、集計にはウィンドウという区切りを設けます。たとえば「直近5分間」で区切るタンブリングウィンドウや、1分ずつずらしながら5分間を見るスライディングウィンドウがあります。また、データが遅れて届くことを前提に、記録された発生時刻を基準に処理するイベントタイムという考え方を採り、遅延到着分をどこまで待つかを設定できます。処理の途中経過はチェックポイントとして保存され、障害時はそこから再開するため、集計の重複や欠落を防げます。

他の選択肢との使い分け

単純な変換やフィルタだけであれば、KinesisデータストリームをLambdaで処理するほうが構成も費用も軽くなります。Flinkが向くのは、複数のストリームを結合する、ウィンドウをまたいだ状態を保持する、順序や遅延を厳密に扱うといった複雑な処理です。数分から数時間ごとの集計で足りるならGlueやEMRによるバッチ処理を選び、秒単位の即時性が要件のときにこのサービスを検討します。

Apache Kafka は、大量のイベントを受け止めて多数のアプリケーションに配信する仕組みとして広く使われていますが、自前で運用すると複数ノードのクラスター管理が大きな負担になります。MSK はその運用部分を AWS が引き受け、利用者は Kafka の使い方だけに集中できます。

用語のキホン：Pub/Sub とトピック・パーティション

Kafka はPub/Sub（発行と購読。送信側と受信側が互いを直接知らずにやり取りするモデル）を実現する仕組みです。データはトピック（用途ごとに分けられたデータの入れ物）に書き込まれ、トピックはパーティション（並列処理と順序保証の単位。Kinesis のシャードに相当）に分割されます。読み手であるコンシューマーは自分がどこまで読んだかを示すオフセット（読み取り位置）を保持するため、同じデータを複数のアプリケーションが独立して読めます。クラスターを構成する各サーバーはブローカーと呼ばれます。

使い分け：Kinesis Data Streams との比較

機能としては Kinesis Data Streams と重なる部分が多く、新規に AWS だけで構築するなら運用が軽い Kinesis が選ばれやすい傾向があります。MSK が有利なのは、すでに Kafka を使っており移行時にアプリケーションを書き換えたくない場合や、Kafka Connect などのエコシステムを活用したい場合です。試験でも「既存の Kafka ワークロードを最小の変更で AWS へ移行したい」という文脈で正解になります。

データレイクを S3 と IAM ポリシーだけで運用すると、バケットやプレフィックス単位でしか権限を切れず、「この部署には売上テーブルの金額列だけ見せない」といった制御が難しくなります。Lake Formation はデータベースやテーブル、列といった分析の単位で権限を定義でき、その設定を Athena・Redshift Spectrum・EMR など複数の分析サービスに共通して効かせられます。

用語のキホン：データレイクと集中権限管理

データレイクとは、構造化データも非構造化データも、加工前の状態のまま一箇所に大量に貯めておく保管場所のことです。AWS では S3 がその実体を担い、AWS Glue データカタログが「どこに何があるか」の目録を担当します。ここで課題になるのが権限で、分析サービスごとにバラバラに設定すると管理が破綻します。Lake Formation はカタログ上のオブジェクトに対して権限を集中管理し、行レベル・列レベルのアクセス制御（特定の行や列だけを見せない、または見せる制御）や、値を伏せるデータマスキングにも対応します。

試験ポイント：どんな要件で選ぶか

試験では「複数部門が同じデータレイクを共有し、部門ごとに参照できる範囲を細かく分けたい」「権限を一箇所で管理したい」といった要件で登場します。単に S3 バケット全体へのアクセス可否を決めるだけなら IAM や S3 バケットポリシーで足り、Lake Formation は不要です。列や行の単位、あるいは複数アカウント間でのデータ共有という条件が付いたら Lake Formation を検討します。

データを分析基盤に集めても、意思決定者が見られなければ活用されません。QuickSight は SQL を書けない利用者でも、画面上の操作でグラフや表を組み立て、ダッシュボードとして関係者に配布できるようにします。Web アプリケーションへの埋め込みにも対応しています。

用語のキホン：BI とインメモリ集計エンジン

BI（ビジネスインテリジェンス）とは、蓄積したデータを集計・可視化して経営や業務の判断に役立てる取り組み全般を指します。QuickSight の特徴が SPICE（データをメモリ上に取り込んで保持する高速な集計エンジン）です。接続先のデータベースに毎回問い合わせるダイレクトクエリ方式と、あらかじめ SPICE に取り込んでおく方式を選べます。SPICE を使うと表示が速く、閲覧者が増えても接続先のデータベースに負荷をかけません。ただし取り込み時点のデータになるため、更新頻度の設計が必要です。

試験ポイント：どの場面で登場するか

試験では「分析結果を経営層に見せたい」「ダッシュボードを部門に共有したい」といった、可視化そのものが要件になる場面で選択します。データの保管は S3、集計は Athena や Redshift、可視化は QuickSight、という役割分担で構成図が描かれることが多いパターンです。可視化ではなく検索とログ監視が主目的であれば OpenSearch Dashboards の方が適します。

外部のデータを分析に取り込みたい場合、従来は提供元ごとに受け渡し方法を調整し、更新のたびにファイルを取得する仕組みを作る必要がありました。Data Exchange はその調達と受け取りを標準化し、購読したデータが更新されると自動で自社の S3 に届く形にできます。

用語のキホン：サードパーティデータとデータ購読

サードパーティデータとは、自社で収集したデータではなく、外部の提供者が作成・販売しているデータのことです。自社データだけでは見えない外部要因を分析に加えるために使われます。Data Exchange では提供者がデータセットを登録し、利用者はカタログから探して購読（利用契約を結んで継続的に受け取ること）します。無償のものと有償のものがあり、課金は AWS の請求にまとめられます。受け取り形式はファイル配信のほか、API 経由や Redshift のデータ共有としての提供もあります。

試験ポイント：登場する要件

試験では「外部の業界データを自社の分析基盤に安全かつ継続的に取り込みたい」「調達と権利処理の手間を減らしたい」という文脈で選択肢に現れます。自社内の別部門や別アカウントとのデータ共有が目的であれば、Lake Formation のクロスアカウント共有や S3 のアクセス許可の方が適切です。あくまで「外部から購入・購読する」点が識別のポイントです。

SQSはメッセージを一時的にためておくキュー、SNSは1つの通知を多数の宛先へ同時に配る仕組み、EventBridgeは発生したイベントを条件で振り分けるルーターです。

用語のキホン：密結合・疎結合・非同期

密結合とは、AがBを直接呼び出し、Bが落ちるとAも失敗してしまう状態です。間にキューを置き、Aは「メッセージを置くだけ」、Bは「空いたら取りに行く」形にするのが疎結合です。そして、相手の処理完了を待たずに次へ進む方式を非同期処理と呼びます。急な負荷でメッセージがたまっても、キューがバッファ（緩衝材）として働くため処理を取りこぼさず、たまった件数に応じてAuto Scalingで処理側の台数を増やす、という設計が可能になります。

3つの使い分け

1対1で確実に処理を渡したいならSQS、1つの出来事を複数の宛先へ同時に知らせたいならSNS、「S3にファイルが置かれた」「EC2が停止した」といったイベントを条件で振り分けたいならEventBridgeを選びます。

SQSはAWSで最も古くから提供されているサービスの一つで、分散システムの基本部品として位置づけられています。SAA-C03では「疎結合にする」「急なアクセス増を吸収する」という設計課題の答えとして頻繁に登場します。サーバーの管理は不要で、必要な分だけ自動的に拡張されます。

用語のキホン：キューイングと非同期処理

キューとは、処理してほしい仕事を一時的にためておく待ち行列のことです。仕事を出す側をプロデューサー（送信者）、取り出して処理する側をコンシューマー（受信者）と呼びます。送信者は受信者の返事を待たずに次の作業へ進めるため、この方式を非同期処理といいます。両者が直接つながっていない状態を疎結合と呼び、片方が障害で停止しても、もう片方は動き続けられるという利点があります。さらに、急激なアクセス増加が起きてもキューがメッセージをためて受信者を守るため、この効果を負荷平準化（バッファリング）と呼びます。

可視性タイムアウトとデッドレターキュー

受信者がメッセージを取り出すと、そのメッセージは一定時間ほかの受信者から見えなくなります。これを可視性タイムアウトといい、同じ仕事を複数のサーバーが二重に処理しないための仕組みです。受信者が処理を終えて削除操作を行えばメッセージは消えますが、時間内に終わらなければ再びキューに現れ、別の受信者が処理します。何度失敗しても消えないメッセージは他の処理を妨げるため、規定回数を超えたものを退避させる専用キューを用意します。これをデッドレターキュー（DLQ）と呼び、後から原因を調査できます。

標準キューとFIFOキューの使い分け

標準キューは非常に高いスループットを出せますが、順序は保証されず、まれに同じメッセージが二重に届くことがあります。そのため受信側は、同じ処理を複数回受け取っても結果が変わらない冪等（べきとう）な作りにしておく必要があります。一方FIFOキューは送った順番どおりに一度だけ届くことを保証しますが、処理できる件数の上限は標準キューより低くなります。試験では「順序が重要か」「重複を許容できるか」で選び分けます。

SNSはメッセージを保管して待たせるSQSとは役割が異なり、届いた瞬間に登録先へ押し出すのが特徴です。SAA-C03では、SQSとの組み合わせで出題されることが非常に多いサービスです。標準トピックのほかに、順序と重複排除を保証するFIFOトピックも用意されています。

用語のキホン：パブリッシュ・サブスクライブ（Pub/Sub）

パブリッシュ・サブスクライブとは、送信者が特定の相手を指定せず、トピックという名前の置き場所にメッセージを投げる通信方式です。メッセージを投げる行為をパブリッシュ（発行）、そのトピックを受け取りたいと登録することをサブスクライブ（購読）といいます。送信者は誰が受け取るかを知る必要がなく、受信側の追加や削除をしても送信側のコードは変わりません。SQSが一対一の受け渡しであるのに対し、こちらは一対多の配信になる点が大きな違いです。配信に失敗したメッセージはリトライされ、それでも届かない場合はデッドレターキューへ退避できます。

ファンアウトとメッセージフィルタリング

1つのSNSトピックに複数のSQSキューを購読させ、1回の発行で各キューへ同じメッセージを配る構成をファンアウトと呼びます。各キューの先で別々の処理を並行して走らせられるうえ、SQSが受け皿になるため、処理側が一時停止してもメッセージを失いません。また、メッセージに付けた属性をもとに購読者ごとに受け取る条件を絞るメッセージフィルタリングも設定でき、不要な処理の起動を減らせます。

EventBridgeは以前CloudWatch Eventsと呼ばれていたサービスが発展したもので、現在はAWS内のイベント連携における標準的な選択肢です。SAA-C03では「AWSリソースの状態変化に応じて自動処理を起動する」設計で登場します。イベントはJSON形式で表現され、内容を見て柔軟に条件を書ける点が強みです。

用語のキホン：イベント駆動アーキテクチャ

イベントとは「何かが起きた」という事実を表すデータで、たとえば「EC2インスタンスが停止した」「ファイルが保存された」といった記録です。イベントが発生したことをきっかけに処理を動かす設計をイベント駆動アーキテクチャと呼びます。定期的に状態を確認しにいくポーリング方式と比べて無駄が少なく、反応も早くなります。イベントの送り手と受け手は互いを知らないため、SNSと同様に疎結合が保たれます。

イベントバス・ルール・スケジュール

イベントバスはイベントが集まる経路で、AWSサービスの出来事が自動的に流れ込むデフォルトバス、自分のアプリ用に作るカスタムバス、SaaS連携用のパートナーイベントバスがあります。ルールはバスを流れるイベントを条件で選び分ける設定で、条件式をイベントパターンと呼びます。合致したイベントの送り先をターゲットといい、Lambda、SQS、SNS、Step Functionsなど多数を指定できます。さらにcron形式などで時刻を指定するスケジュールルールも作れるため、定期バッチの起動にも使えます。

Lambda関数を複数つなげて長い処理を組む場合、関数の中から次の関数を呼ぶ書き方では、エラー処理や進捗の把握が難しくなります。Step Functionsはその制御部分を外に切り出し、手順そのものを管理対象にします。SAA-C03では「複雑な業務フローを確実に、追跡可能な形で実行したい」場面の答えになります。

用語のキホン：ステートマシンとオーケストレーション

ステートマシンとは、処理が取りうる状態と、その間の移り方を並べた設計図のことです。Step Functionsではこれをステート（状態）の連なりとして定義し、1つの処理を表すTask、条件分岐のChoice、並列実行のParallel、繰り返しのMapといった種類を組み合わせます。こうして複数サービスの呼び出し順序と失敗時の振る舞いを一括して指揮することをオーケストレーションと呼びます。各処理が自律的に次を呼び合うコレオグラフィと対比される考え方で、全体の流れを1か所で把握したいときはオーケストレーションが向いています。実行の履歴はステップごとに残るため、どこで失敗したかを後から追えます。

標準ワークフローとExpressワークフロー

標準ワークフローは長時間の実行に向き、1回の実行が最長で1年ほど続けられ、実行履歴も詳細に残ります。人による承認待ちなど、時間のかかる業務フローに適しています。Expressワークフローは短時間で大量に実行する用途向けで、実行時間はおよそ5分までですが、高い頻度の呼び出しを低コストで処理できます。試験では「実行時間の長さ」と「実行回数の多さ」で選び分けます。

SQSやSNSはAWS独自の仕組みで、利用するにはAWSのSDKを使ったコードが必要です。すでに業界標準のプロトコルで作られたアプリケーションを持ち込む場合、その書き換えは大きな負担になります。Amazon MQはその負担を避けるための選択肢です。

用語のキホン：メッセージングプロトコルと標準規格

メッセージブローカーとは、アプリ同士のメッセージを仲介する専用ソフトウェアのことです。その通信手順にはJMS（Javaのメッセージング標準）、AMQP、MQTT、STOMPといった業界標準の規格があり、多くの既存システムがこれらに依存しています。Amazon MQはこれらの規格をそのまま話せるため、接続先の情報を変えるだけで移行できる場合があります。一方でSQSやSNSはこれらの規格に対応しておらず、独自のAPIで通信します。

SQS・SNSとの使い分け

試験では「既存のメッセージブローカーを使ったアプリを最小限の変更でAWSへ移行したい」という条件が出たらAmazon MQ、「新しくクラウド向けに作る」ならSQSやSNSが正解になります。Amazon MQはブローカーというインスタンスを起動して使うため、容量を意識した設計と、可用性のための待機系構成の検討が必要です。対してSQSやSNSは容量を意識せず自動的に拡張されます。

業務データがSaaSに分散していると、分析のためにAWS側へ集める仕組みが必要になります。従来はAPIを呼ぶプログラムを自作していましたが、認証や再試行、差分取得の管理が煩雑でした。AppFlowはその部分を肩代わりします。

用語のキホン：SaaS連携とデータ取り込み

SaaSはインターネット経由で使う業務アプリケーションのことで、データはその提供者側に保管されています。そこからデータを取り出してAWSへ運ぶ処理をデータ取り込み（インジェスト）と呼びます。AppFlowでは、この一連の設定をフローという単位で作り、接続元、接続先、対象データ、変換内容、実行タイミングを指定します。取り込み時に不要な項目を除いたり、条件で行を絞ったり、値を書き換えたりするマッピングと変換もフローの中で設定できます。通信はインターネットを経由せずAWS PrivateLinkを使う構成も選べ、データを外に出さずにやり取りできます。

他の連携手段との違い

AWS内のデータを加工して移す用途にはAWS Glueが使われますが、AppFlowはSaaSとの接続に特化しており、あらかじめ用意されたコネクタで認証まで面倒を見てくれる点が異なります。逆にAWSからSaaSへ書き戻す双方向の連携にも対応します。試験では「SaaSのデータをコードを書かずにS3へ集めたい」という文脈で候補になります。

AppSyncは、DynamoDBやLambda、RDSなど複数のデータ源を束ね、1本のGraphQL APIとしてアプリに提供します。サーバーの管理は不要です。

用語のキホン：GraphQLとRESTの違い

RESTは、用途ごとにURL（エンドポイント）を用意し、そこへ問い合わせる方式です。画面に必要な情報が3種類あれば3回呼ぶことになり、また不要な項目まで返ってくること（オーバーフェッチ）も起こります。GraphQLは、単一のエンドポイントに対して「欲しい項目だけ」を指定して問い合わせる方式で、1回の通信で過不足なく取得できます。通信量が限られるモバイルアプリで特に効果的です。

リアルタイムとオフライン

サブスクリプションという仕組みでデータ更新を自動的に受け取れるため、チャットや共同編集のようなリアルタイム機能を簡単に実装できます。またAmplifyと組み合わせると、電波の届かない場所で行った変更を、復帰時に自動で同期させることもできます。

使い続けることが確実なワークロードは、あらかじめ利用量を約束することで、オンデマンド料金と比べて最大およそ70%割引になります。コスト最適化の問題では必ず候補に挙がります。

用語のキホン：コミットメント割引と支払い方法

コミットメント割引とは「これだけ使うと約束する代わりに単価を下げてもらう」仕組みです。約束の単位が異なり、Savings Plansは「1時間あたり◯ドル分使う」という金額ベース、リザーブドインスタンス（RI）は「このタイプを何台」という数量ベースです。支払い方法は全額前払い・一部前払い・前払いなしから選べ、前払いが多いほど割引率は高くなります。

使い分けとスポットインスタンス

将来インスタンスタイプを変える可能性があるなら、柔軟なCompute Savings Plansが向きます。構成が固定でRDSやElastiCacheなどが対象ならRIを使います。一方、中断されても構わない処理には、AWSの余剰リソースを最大約90%引きで使えるスポットインスタンスが有効です。

請求書の合計金額だけでは、費用が増えた原因はわかりません。Cost Explorerは同じ費用データを多角的に切り替えて眺められるため、増加の要因を素早く特定できます。マネジメントコンソールから利用でき、分析用のAPIも提供されています。

用語のキホン：コスト配分とタグ

AWSの費用を部門やプロジェクトごとに把握するには、リソースに目印を付けておく必要があります。この目印がキーと値の組で付けるタグで、費用の集計軸として使うと宣言したものをコスト配分タグと呼びます。有効化した時点以降のデータに反映されるため、運用開始時に付与ルールを決めておくことが大切です。また複数アカウントをまとめて管理するAWS Organizationsを使っている場合、請求を1つにまとめる一括請求（コンソリデーティッドビリング）により、管理アカウントから全体の費用を横断的に分析できます。この仕組みには、複数アカウントの利用量を合算してボリューム割引が効きやすくなる利点もあります。

できることと近いサービスとの違い

Cost Explorerでは過去の費用推移の表示に加え、実績をもとにした将来の費用予測、Savings PlansやRIの購入推奨、購入済み割引がどれだけ使われたかを示す使用率レポートとカバレッジレポートが確認できます。あくまで分析と可視化のためのツールであり、予算超過を知らせる役割はAWS Budgets、明細レベルの生データはCost and Usage Reportが担います。

Cost Explorerが過去を振り返るツールであるのに対し、Budgetsは将来に向けた見張り役です。人が定期的に画面を確認しなくても、決めた条件に達した時点で自動的に知らせが届きます。SAA-C03では「コスト超過を早期に検知する」要件の答えとして登場します。

用語のキホン：しきい値とアラート

しきい値とは、そこを超えたら知らせる、と決めておく境目の数値です。Budgetsでは金額そのものだけでなく、予算に対する割合でも指定でき、たとえば80パーセントに達した時点で警告する、といった設定ができます。判定の対象は実績値のほかに、このままの傾向が続いた場合の月末着地を見積もった予測値も選べます。予測に基づく通知を使えば、月の途中で手を打つ余地が生まれます。通知の宛先にはメールのほかAmazon SNSのトピックを指定でき、SNS経由でLambdaを起動して自動対処につなげることもできます。

予算の種類とBudgets Actions

設定できる予算には、費用のコスト予算、実行時間などの使用量予算、購入した割引がどれだけ活用されたかを見るRI・Savings Plansの使用率予算やカバレッジ予算があります。さらにBudgets Actionsを使うと、しきい値を超えた際にIAMポリシーを適用してリソースの新規作成を制限したり、対象のEC2インスタンスを停止したりする自動対応を設定できます。通知だけで終わらせず、費用の暴走を止める仕組みまで作れる点が特徴です。

Cost Explorerの画面は手軽ですが、集計の切り口はあらかじめ用意されたものに限られます。CURはリソース単位・時間単位まで分解された生データを提供するため、独自の集計ロジックを組みたい組織に向いています。データ量が大きくなるため、分析には専用のサービスを組み合わせるのが一般的です。

用語のキホン：明細データと粒度

粒度とは、データがどれくらい細かく分かれているかを表す言葉です。CURでは時間単位、日単位、月単位から選べ、さらにリソースIDを含めるよう設定すれば、どのインスタンスにいくらかかったかまで追えます。出力されるファイルにはコスト配分タグの列も含められるため、組織独自の分類での集計が可能です。データはS3へCSVまたは列指向形式のParquetで置かれ、Parquetを選ぶと分析時の読み取り量が減って効率的です。数値は月内に随時更新され、最終的に確定した値へ収束していきます。

Cost Explorer・Budgetsとの使い分け

日常的に費用の傾向を眺めるならCost Explorer、超過を知らせたいならBudgets、社内システムに取り込んで独自集計や部門別請求を作り込むならCURという整理になります。CUR単体には可視化機能がないため、Athenaでクエリを実行し、QuickSightでダッシュボード化する構成がよく採られます。

VPCは、AWSの中に自分専用のネットワーク空間を作る仕組みです。まず「CIDR（例：10.0.0.0/16）」でIP範囲を決め、その中を「サブネット」に区切ります。インターネットに公開する層（パブリック）と、DBなど外に出さない層（プライベート）に分けて構築します。

用語のキホン：CIDRとサブネット

CIDR（例：10.0.0.0/16）は、使えるIPアドレスの範囲を表す書き方です。末尾の数字が小さいほど範囲は広く、大きいほど狭くなります。サブネットは、そのIP範囲をさらに小さく区切った区画で、AZごとに作成します。インターネットゲートウェイへの経路を持つ区画をパブリックサブネット、持たない区画をプライベートサブネットと呼び、この2つを分けることがVPC設計の出発点になります。

経路とゲートウェイ

通信の経路は「ルートテーブル」で決めます。インターネットとの出入り口には「インターネットゲートウェイ」、プライベートからの外向き通信だけを許す「NATゲートウェイ」を使います。AWSサービスへ非インターネット経由で繋ぐ「VPCエンドポイント」（S3等向けのゲートウェイ型、その他のインターフェース型）も重要です。

接続と可視化

VPC同士は「ピアリング」や「Transit Gateway」で接続します。通信の記録は「VPCフローログ」で確認できます。ほぼ全てのAWS設計の土台になるため、パブリックとプライベートの分離は必ず理解しておきましょう。

Direct Connect（DX）は、データセンターや拠点からAWSへ物理的な専用線を引くサービスです。インターネットVPNより安定した帯域と低い遅延が得られ、継続的に大量データをやり取りする場合は転送料金も安くなります。

用語のキホン：専用線とVPN、そして冗長化

VPNはインターネット上に暗号化したトンネルを作る方式で、すぐ使えて安価ですが、経路が混雑すれば速度は不安定になります。専用線は物理的に確保した回線なので品質が一定です。ただし物理回線は開通に数週間から数か月かかり、切れると復旧にも時間がかかります。そのため冗長化——複数回線を引く、またはVPNをバックアップとして併用する——が実務では必須になります。

仮想インターフェース（VIF）の種類

1本の物理回線の上に、用途別の論理的な接続を作ります。VPC内へ接続するプライベートVIF、S3などパブリックサービスへ接続するパブリックVIF、Transit Gatewayへ接続するトランジットVIFがあります。

Transit Gateway（TGW）は、複数のVPC・VPN・Direct Connectを1つのハブに接続し、その間の通信を中継するサービスです。TGW自身がルートテーブルを持ち、どの接続先どうしを通信させるかを制御できます。

用語のキホン：ハブアンドスポークとフルメッシュ

VPCどうしを1対1でつなぐVPCピアリングでは、VPCがN個あると必要な接続数はN×(N-1)÷2に膨れ上がります。この網の目状の形をフルメッシュと呼び、10個なら45本、20個なら190本にもなります。これに対し、中央にハブを1つ置き各VPCはハブにだけつなぐ形をハブアンドスポークと呼び、接続数はN本で済みます。Transit Gatewayはこのハブにあたります。

推移的ルーティングと分離

VPCピアリングは推移的ルーティング（AとB、BとCがつながっていてもAとCは通信できない）に対応しません。TGWは中継できるため、この制約を解消します。またルートテーブルを複数持てるので、「本番VPC群と開発VPC群は相互に通信させない」といった分離も設計できます。

通常、S3やDynamoDBはインターネット側のエンドポイントを持つため、プライベートサブネットからのアクセスにはNATゲートウェイが必要でした。VPCエンドポイントを作ると、その通信をAWS内部のネットワークだけで完結させられます。

用語のキホン：ゲートウェイ型とインターフェース型

ゲートウェイ型は、ルートテーブルに「S3宛はこちら」という経路を追加する方式です。対象はS3とDynamoDBのみで、追加料金はかかりません。インターフェース型（PrivateLink）は、サブネット内にENI（仮想的なネットワークカード）を作り、そのプライベートIP宛に通信する方式です。多くのAWSサービスや他社SaaSにも対応しますが、時間課金と転送量課金が発生します。

閉域化のメリット

インターネットゲートウェイもNATゲートウェイも経由しないため、通信がVPCの外に出ません。「社外に通信を出さないこと」が要件となる金融・医療などの環境で有効です。加えて、NATゲートウェイの処理量が減るぶん料金の削減にもつながります。

Route 53は、ドメイン名（例：example.com）を実際のサーバー（IPアドレス）に結びつけるDNSサービスです。ドメインの登録・管理もでき、公開向けの「パブリックホストゾーン」とVPC内向けの「プライベートホストゾーン」があります。AWSリソースを直接指す「エイリアスレコード」が便利です。

用語のキホン：DNSとレコード

DNSは、人が読みやすいドメイン名（example.com）を、コンピューターが使うIPアドレスに変換する「住所の電話帳」のような仕組みです。変換のルールはレコードという単位で登録し、IPを指すAレコード、別名のCNAME、AWSリソースを直接指すエイリアスなどがあります。変更の反映にかかる時間はTTL（キャッシュの有効期間）で調整します。

ルーティングポリシー

賢い振り分けが可能です。レイテンシー（最も速いリージョンへ）、加重（比率で分散）、位置情報（地域別）、フェイルオーバー（障害時に予備へ）、複数値回答などを使い分け、ヘルスチェックと連動させれば健全なサーバーへ自動誘導できます。オンプレとの相互名前解決には「Route 53 Resolver」を使います。

CloudFrontは、コンテンツを世界中の「エッジロケーション」にキャッシュし、利用者に最も近い拠点から配信するCDNです。遠くの元サーバー（オリジン）まで毎回取りに行かずに済むため、表示が速くなり、オリジンの負荷も下がります。オリジンにはS3・ELB・外部サーバーを指定できます。

用語のキホン：CDN・エッジ・オリジン

CDN（コンテンツ配信ネットワーク）とは、世界中に置いた拠点にコンテンツの写しを置き、利用者に近い場所から配る仕組みです。その配信拠点をエッジロケーション、元のデータがある場所（S3など）をオリジンと呼びます。エッジに写しを一時保存しておくことをキャッシュと言い、これにより表示が速くなり、オリジンへのアクセスも減ります。

キャッシュとカスタマイズ

パスごとの挙動は「ビヘイビア」で設定し、キャッシュ期間は「TTL」で調整、更新反映は「無効化（invalidation）」で行います。S3を安全に見せる「OAC」、限定配信の「署名付きURL/Cookie」、エッジで処理を差し込む「CloudFront Functions／Lambda@Edge」も使えます。

セキュリティ連携

WAFやAWS Shieldと組み合わせて、DDoSやWeb攻撃からの防御を強化できます。動的コンテンツの高速化にも利用されます。

ELBは、利用者からのリクエストを複数のEC2などに分散する仕組みです。内部は「リスナー（受け口）→ ルール → ターゲットグループ（振り分け先の束）」という構造で、各ターゲットの生死をヘルスチェックで監視し、正常なものにだけ振り分けます。

用語のキホン：L4・L7・ヘルスチェック

ロードバランサーは通信の「階層」で役割が分かれます。L7（アプリケーション層）はURLやHTTPの中身を見て振り分けられる高機能な層（ALBが対応）、L4（トランスポート層）はIPアドレスとポートだけを見て高速にさばく層（NLBが対応）です。ヘルスチェックとは、各サーバーへ定期的に通信して「生きているか」を確認する仕組みで、異常なサーバーへは振り分けないための要となります。

種類の使い分け

ALB（アプリケーションロードバランサー・L7）はHTTP/HTTPS向けで、URLパスやホスト名でルーティングでき、WAFと連携できます。NLB（ネットワークロードバランサー・L4）は超高スループット・低遅延・固定IPが必要な場合に使います。ほかにファイアウォール連携向けのGLBもあります。

可用性の要点

複数AZにまたがって配置し、AZ障害時も生きているAZへ振り向けます。「クロスゾーン負荷分散」で全AZのターゲットへ均等分散でき、必要なら「スティッキーセッション」で同じ利用者を同じサーバーへ固定できます。Auto Scalingと組み合わせると、増えた台数へ自動で振り分け、落ちた台数を自動で切り離せます。

インターネット経由の通信は、経路が混雑していると遠回りになり遅延が増えます。Global Acceleratorは利用者の近くのエッジロケーション（AWSが世界各地に持つ接続拠点）で通信を受け取り、そこから先はAWSが自前で敷設した回線を通します。結果として遅延のばらつきが減り、接続の安定性が上がります。

用語のキホン：エニーキャストIPとCloudFrontとの違い

Global Acceleratorが提供する静的エニーキャストIPアドレスとは、世界中の複数の拠点が同じIPアドレスを名乗り、利用者は自動的に最も近い拠点に届く仕組みのIPアドレスです。IPアドレスが変わらないため、企業のファイアウォールで許可リストに登録しやすいという利点があります。ここがCloudFrontとの最大の違いです。CloudFrontは画像や動画などの静的コンテンツをエッジにキャッシュ（複製して保管）してHTTPやHTTPSで配信するCDNですが、Global Acceleratorはキャッシュを持たず、TCPやUDPを含むあらゆる通信をそのまま高速に転送します。つまりCloudFrontは「コンテンツ配信の高速化」、Global Acceleratorは「接続そのものの高速化と可用性」が主眼です。

試験での判断基準

問題文に「HTTP以外のプロトコル」「オンラインゲーム」「IoTのUDP通信」「固定IPアドレスが必要」「複数リージョンへのフェイルオーバー」とあればGlobal Acceleratorです。「静的コンテンツのキャッシュ」「動画配信」「WAFと組み合わせた保護」とあればCloudFrontを選びます。両者は排他ではなく、CloudFrontの背後にGlobal Acceleratorを置く必要はありませんが、用途が異なるだけと理解しておきます。

拠点のルーターとAWS側の接続口の間にトンネルを張り、両者を1つのネットワークのように扱えるようにします。Direct Connectと比べて費用が安く導入が速い一方、通信はインターネットを経由するため速度や遅延は保証されません。試験では「短期間で」「低コストで」オンプレミスとつなぐ要件に対する解答になります。

用語のキホン：IPsecトンネルとカスタマーゲートウェイ

IPsecは、IPパケットそのものを暗号化して安全にやり取りするための標準的な通信規格です。この暗号化された通り道をトンネルと呼び、途中の経路で内容を盗み見られないようにします。AWS側の接続口は仮想プライベートゲートウェイ（VGW）またはTransit Gatewayで、拠点側の機器の情報をAWSに登録したものをカスタマーゲートウェイと呼びます。1つのVPN接続には冗長のためトンネルが2本用意されており、拠点側のルーターを2台に分ければさらに可用性を高められます。経路情報の交換は、手動で書く静的ルーティングと、BGPで自動的にやり取りする動的ルーティングのどちらかを選びます。

Direct Connectとの関係

帯域や遅延の安定が必須ならDirect Connect、コストと導入速度を優先するならSite-to-Site VPNという住み分けです。実務では、Direct Connectの敷設が完了するまでの暫定接続としてVPNを使い、その後もバックアップ回線として残す構成がよく取られます。またDirect Connectの上でVPNを併用して通信を暗号化する構成もあります。

セキュリティグループ（SG）は、EC2などインスタンス単位のファイアウォールです。ステートフルで、許可した通信の戻りは自動で通ります。書けるのは「許可」ルールだけで、デフォルトは全拒否から必要な通信を足していきます。SGは他のSGを参照でき（例：「このWeb-SGからのみ許可」）、柔軟に設計できます。

用語のキホン：ステートフルとステートレス

ステートフルとは、通信の「行き」を覚えていて、その「戻り」を自動的に許可する方式です（セキュリティグループ）。一方ステートレスは、行きと戻りをそれぞれ別の通信として扱うため、両方のルールを書かないと通信が成立しません（ネットワークACL）。NACLで「行き」だけ許可して戻り（エフェメラルポート）を書き忘れ、通信できない——というのが典型的なつまずきポイントです。

NACLとの違い・使い分け

ネットワークACL（NACL）は、サブネット単位のファイアウォールです。ステートレスで、行きと戻りの両方を明示する必要があります。「許可」と「拒否」の両方を番号順に評価するため、特定IPを丸ごとブロックする用途に向きます。SGを主に使い、NACLはサブネット全体の粗い制御として併用する「多層防御」が定石です。

IAMは、AWSの操作権限を管理する仕組みです。「ユーザー」「グループ」「ロール」に「ポリシー（許可の内容をJSONで記述）」を与えて制御します。安全のため、権限は必要最小限にする「最小権限の原則」が基本です。

用語のキホン：認証と認可

アクセス管理は「認証」と「認可」の2段階で考えます。認証（Authentication）は「あなたが誰か」を確かめること（ログイン）、認可（Authorization）は「その人が何をしてよいか」を決めることです。IAMは主にこの認可（ポリシーによる操作の許可・拒否）を担い、多要素認証（MFA）などで認証も強化できます。

ロールと一時認証

特に重要なのが「IAMロール」です。EC2・Lambdaなどにロールを付与すると、STSが発行する一時的な認証情報が自動で供給され、アクセスキーをコードに埋め込まずに安全にアクセスできます。外部IdP（Google等）と連携する「フェデレーション」やクロスアカウントアクセスもロールで実現します。

ポリシー評価と保護

ポリシーには識別ベース・リソースベース・権限境界・SCPなどがあり、評価では明示的な拒否が最優先されます。重要操作にはMFA（多要素認証）を必須にでき、ルートユーザーは極力使わないのが鉄則です。

IAM Identity Centerは、Organizations配下の多数のアカウントに対して、利用者が一度のログインで必要なアカウントと権限に切り替えられるようにするサービスです。ユーザーはIdentity Center内に作ることも、Active Directoryや外部IDプロバイダーと連携することもできます。

用語のキホン：シングルサインオンとフェデレーション

シングルサインオン（SSO）とは、1回の認証で複数のシステムを使えるようにすることです。フェデレーション（IDフェデレーション）とは、自社や外部サービスで管理しているIDを信頼し、AWS側にユーザーを作らずにログインさせる仕組みを指します。そして与える権限のまとまりを許可セットと呼び、「この人はこのアカウントでは読み取りのみ」といった割り当てを1か所で管理します。

IAMユーザーとの違い

アカウントごとにIAMユーザーを作ると、退職時の削除漏れや権限のばらつきが起きます。Identity Centerは都度一時的な認証情報を発行するため、期限のない長期アクセスキーを配布せずに済み、誰がどこに入れるかの棚卸しも1か所で完結します。

IAMユーザーのアクセスキーは無期限に使えるため、漏えいすると被害が長期化します。STSはこの前提を変え、数十分から数時間で自動的に失効する認証情報を配る仕組みを提供します。現在のAWS設計では、恒久キーを避けてSTSに寄せるのが原則です。

用語のキホン：AssumeRoleと信頼ポリシー

中心となる操作がAssumeRoleで、これは「あるIAMロールになりきる」ことを意味します。呼び出しに成功すると、アクセスキーID、シークレットアクセスキー、そしてセッショントークンの3点セットが返され、これを使ってAPIを呼ぶとそのロールの権限で操作できます。ここで重要なのが、ロールに2種類のポリシーが付く点です。権限ポリシーは「そのロールが何をできるか」を定めます。もう一つの信頼ポリシー（信頼関係）は「誰がこのロールを引き受けてよいか」を定めるもので、別アカウントのID、IAMユーザー、あるいはEC2やLambdaといったサービスを指定します。引き受ける側にもsts:AssumeRoleを許可する権限が必要で、両者がそろって初めて成立します。

主要なAPIと試験ポイント

外部のIDプロバイダー経由で入る場合は、OpenID Connect用のAssumeRoleWithWebIdentityや、企業のADなどSAML連携用のAssumeRoleWithSAMLを使います。EKSでPodにIAM権限を与えるIRSAも内部的には前者の仕組みです。クロスアカウントでは、第三者を介する場合の「混乱した代理人」問題（第三者が意図せず権限を悪用されること）を防ぐ外部IDという値を信頼ポリシーに要求できます。SAP-C02では「別アカウントのS3に安全にアクセスさせたい」「モバイルアプリに直接キーを埋め込みたくない」といった要件で、STSとロールの組み合わせが答えになります。

KMSは、暗号化に使う鍵（KMSキー／CMK）の作成・保管・アクセス制御をまとめて行うサービスです。S3・EBS・RDS・Secrets Managerなど多くのサービスと連携し、保管中データ（at rest）を簡単に暗号化できます（例：S3のSSE-KMS）。

用語のキホン：保管中と通信中の暗号化

暗号化は2つの場面で考えます。ディスクやS3に「置いてある」データを守るのが保管中の暗号化（at rest）で、これを担うのがKMSです。ネットワークを「流れている」データを守るのが通信中の暗号化（in transit）で、こちらはTLS（HTTPS）が担います。またKMSの鍵には、暗号化と復号に同じ鍵を使う「対称鍵」（一般的）と、別々の鍵を使う「非対称鍵」があります。

仕組みと権限

実データは「データキー」で暗号化し、そのデータキー自体をKMSキーで暗号化する「エンベロープ暗号化」が使われます。鍵の利用可否は「キーポリシー」で制御し、鍵の利用にはIAMの許可とキーポリシーの両方が必要な点が重要です。キーは自動ローテーションでき、細かな委任は「グラント」で行います。暗号化は「保管中＝KMS」「通信中＝TLS」と分けて理解しましょう。

暗号化の安全性は、鍵をいかに守るかにかかっています。CloudHSMは鍵を物理的な耐タンパー装置に閉じ込め、その装置の利用者はお客様専有となります。AWSの運用担当者であっても鍵の内容にアクセスできない構成を実現できる点が最大の価値です。

用語のキホン：HSMとシングルテナント、KMSとの違い

HSM（Hardware Security Module、ハードウェアセキュリティモジュール）とは、暗号鍵の生成・保管・演算を専用装置の内部だけで行い、鍵そのものを外部に取り出せないように設計された機器です。不正に開封されると鍵を自動消去する耐タンパー性を備えます。CloudHSMはこの装置を1顧客が占有するシングルテナント方式で、VPC内に配置され、装置の管理ユーザーもお客様が設定します。一方AWS KMSは複数顧客で基盤を共有するマルチテナントのマネージドサービスで、鍵の操作はAPIとIAMで制御しますが、鍵の管理主体はAWSと共同になります。KMSは他のAWSサービスとの統合が容易で安価、CloudHSMは鍵の完全な単独管理と特定の規格準拠が可能、という違いです。

試験での判断基準

問題文に「鍵をお客様が完全に管理」「FIPSの高いレベル準拠」「規制上AWSに鍵を預けられない」「独自の暗号処理をアプリから呼び出す」とあればCloudHSMです。逆に「S3やEBSの暗号化を簡単に」「キーローテーションを自動で」であればKMSを選びます。両者の中間として、KMSのカスタムキーストアとしてCloudHSMを裏側に置き、KMSの使いやすさとHSMの管理性を両立させる構成もあります。

証明書は有効期限があり、更新を忘れるとサイトが警告表示になって使えなくなります。ACMが発行するパブリック証明書は条件を満たせば自動更新されるため、この運用事故を根本的に防げます。

用語のキホン：SSL/TLS証明書とドメイン所有権の検証

TLS（かつてのSSL）は、通信を暗号化し、接続先が本物であることを確認するための規格です。その確認に使われるのが証明書で、「このドメイン名の持ち主はこの組織である」ことを認証局（CA、信頼された第三者機関）が保証した電子ファイルです。証明書の中には公開鍵が含まれ、対応する秘密鍵はサーバー側だけが持ちます。ACMで証明書を取得するにはドメインを本当に所有していることを示す必要があり、方法はDNS検証（指定されたレコードをDNSに追加する）とメール検証の2つです。自動更新を確実に働かせたいならDNS検証を選びます。

適用先と試験ポイント

ACMの証明書はElastic Load Balancing、CloudFront、API Gatewayなどに直接適用できますが、EC2インスタンスへ直接インストールすることはできません。この「秘密鍵を取り出せない」制約が出題されます。EC2上で使いたい場合はACM Private CAで発行するか、外部で取得した証明書をACMにインポートします。またCloudFrontに適用する証明書は米国東部（バージニア北部）リージョンで発行する必要がある点も頻出です。

認証の仕組みを自作すると、パスワードの安全な保管や多要素認証など考慮すべき点が多く、脆弱性の温床になりがちです。Cognitoはこれらをマネージドサービスとして提供します。試験ではアプリ利用者（エンドユーザー）向けの認証として登場し、AWSの操作権限を扱うIAMとは役割が異なる点に注意します。

用語のキホン：認証と認可、ユーザープールとIDプール

認証（Authentication）は「あなたは誰か」を確かめること、認可（Authorization）は「あなたは何をしてよいか」を決めることで、この2つは別の概念です。Cognitoのユーザープールは認証を担当し、ユーザーの名簿を保持してログインを処理し、成功するとJWT（JSON Web Token、利用者情報が入った署名付きの通行証）を発行します。一方IDプール（フェデレーテッドアイデンティティ）は認可を担当し、受け取ったトークンと引き換えに一時的なAWS認証情報を発行して、そのユーザーがS3やDynamoDBを直接操作できるようにします。この2つは単独でも組み合わせても使えます。

試験ポイントと使い分け

「モバイルアプリからS3へ直接ファイルをアップロードしたい」という要件では、アプリに固定のアクセスキーを埋め込むのではなくIDプールで一時的な認証情報を得るのが正解です。「API Gatewayで作ったAPIをログイン済みユーザーだけに公開したい」場合はユーザープールをオーソライザーとして設定します。なお社内従業員のAWSコンソールへのアクセス管理はIAM Identity Centerの領域であり、Cognitoはアプリ利用者向け、と区別して覚えます。

多くの企業はユーザーアカウントや端末をActive Directoryで一元管理しています。AWSへ移行する際にこの仕組みをどう扱うかが設計上の論点となり、Directory Serviceがその選択肢を提供します。

用語のキホン：ディレクトリサービスとドメイン参加、信頼関係

ディレクトリサービスとは、社員・端末・共有フォルダといった組織内の資源を階層構造の名簿として管理し、ログイン認証やアクセス権の付与を一元的に行う仕組みです。その代表がActive Directory（AD）で、管理範囲の単位をドメインと呼びます。サーバーやPCをそのドメインの管理下に置くことをドメイン参加といい、参加すると社員は自分のADアカウントでそのサーバーにログインできます。異なるドメイン同士でアカウントを相互に認め合う設定が信頼関係で、これを使うとオンプレミスのADアカウントのままAWS上の資源を利用できます。

3つの選択肢の使い分け

AWS Managed Microsoft ADは本物のADをAWSが運用するもので、信頼関係やグループポリシーなどAD本来の機能をフルに使えます。AD ConnectorはAWSにアカウントを保持せず、認証要求をオンプレミスのADへそのまま転送する橋渡し役で、既存のADをそのまま使い続けたい場合に選びます。Simple ADは小規模向けの互換実装で、信頼関係などの高度な機能は使えません。試験では「オンプレミスADとの信頼関係が必要」ならManaged Microsoft AD、「アカウントはオンプレミスに残したまま」ならAD Connectorが解答になります。

AWS RAMは、リソースをコピーしたり移動したりせずに、所有アカウントに置いたまま他アカウントへ利用権を渡す仕組みです。共有先はAWS Organizations内の組織全体、特定の組織単位、または個別のアカウントIDを指定できます。共有できるリソースの種類はサービス側で決められています。

用語のキホン：リソース共有とマルチアカウント設計

組織が大きくなると、部門やシステムごとにAWSアカウントを分けるマルチアカウント設計が一般的になります。請求の分離、権限の分離、障害の影響範囲の限定といった利点がある一方で、ネットワークのように本来1つにまとめたい要素まで重複してしまう問題が生じます。リソース共有は、この重複を避けるための考え方で、共通基盤を1つのアカウントに集約し、他アカウントはそれを借りて使います。共有されたリソースは所有アカウントの持ち物のままなので、課金や設定変更の責任は所有側に残り、利用側は決められた範囲で使うだけです。この責任の分かれ方が、統制のとれた運用につながります。

代表的な共有対象と使い分け

よく問われるのは共有VPCで、ネットワーク管理アカウントがVPCとサブネットを作り、それを各アプリケーションアカウントへ共有します。各アカウントは共有されたサブネットに自分のEC2やLambdaを配置でき、ネットワーク設計は一箇所で統制できます。ほかにTransit Gateway、Route 53 Resolverのルール、License Managerの設定などが共有対象です。VPCピアリングやTransit Gatewayが「ネットワーク同士をつなぐ」手段であるのに対し、AWS RAMは「同じリソースを一緒に使う」手段である、という違いを押さえてください。

AWS Secrets Managerは、機密情報を暗号化して保管し、必要なときにAPI経由で取得させる仕組みを提供します。取得できる相手はIAMのポリシーで細かく制御でき、いつ誰が取り出したかも記録されます。加えて、対応するデータベースであれば、パスワードの入れ替えを自動化できるのが最大の特徴です。

用語のキホン：シークレットとローテーション

シークレットとは、漏れると被害につながる情報のことで、データベースの接続情報、APIキー、外部サービスのトークンなどが該当します。これらをコードや設定ファイルに書き込むと、リポジトリの共有や退職者の端末を通じて流出する危険があり、変更のたびに全アプリケーションを直す必要も生じます。そこで、シークレットは専用の保管場所に置き、実行時に取り出す設計が推奨されます。ローテーションとは、その値を定期的に新しいものへ入れ替えることです。仮に古い値が漏れていても、入れ替え後は使えなくなるため、被害の及ぶ期間を短くできます。Secrets ManagerはLambda関数を使って、新しいパスワードの生成、データベース側への反映、シークレットの更新までを自動で行います。

Parameter Storeとの使い分け

Systems ManagerのParameter Storeも設定値を保管できますが、こちらは設定値全般の管理が主目的で、標準的な範囲であれば追加費用なしで使える点が利点です。一方Secrets Managerは、シークレット1件あたりの保管料が発生する代わりに、自動ローテーション、複数リージョンへの複製、データベースとの連携といった機能を備えています。試験では「パスワードを定期的に自動で入れ替えたい」という要件が出たらSecrets Manager、「暗号化は要るが単なる設定値でコストを抑えたい」ならParameter StoreのSecureStringが妥当な答えになります。

AWS WAFは、HTTPやHTTPSのリクエストの中身を見て、通すか遮断するかを判断するサービスです。ネットワーク層のファイアウォールでは見抜けない、アプリケーションの作りを悪用する攻撃に対応します。ルールを自分で書くほか、AWSやセキュリティベンダーが用意した管理ルールグループをそのまま適用することもできます。

用語のキホン：L7攻撃とレート制限

通信は役割ごとに階層に分けて考えられ、いちばん上のアプリケーション層はL7（レイヤー7）と呼ばれます。ここを狙う攻撃がL7攻撃で、見た目は正常なWebアクセスなのに、中身に不正な命令が仕込まれていたり、大量に繰り返されてサーバーを消耗させたりします。代表例がSQLインジェクション（入力欄にデータベースへの命令文を紛れ込ませ、情報を抜き取る攻撃）やクロスサイトスクリプティング（他人のブラウザで動く不正なスクリプトを埋め込む攻撃）です。これに対してレート制限（レートベースルール）は、同じ送信元からの一定時間内のリクエスト数を数え、しきい値を超えた送信元を一時的に遮断する仕組みです。中身が正常に見える攻撃でも、量の異常さで捉えられる点が特徴です。

ルールの構成と試験ポイント

ルールはWeb ACL（ルールをまとめた入れ物）に登録し、それを保護対象のリソースに関連付けて有効化します。判定条件にはIPアドレス、国（地理的一致）、URLのパス、ヘッダー、ボディの内容などを使え、動作は許可・ブロック・カウント（記録のみ）から選べます。試験では「特定の国からのアクセスを遮断したい」「1つのIPからの過剰なリクエストを止めたい」「SQLインジェクション対策をしたい」といった要件が出たらAWS WAFが答えになります。Shieldがネットワーク規模の飽和攻撃を担うのに対し、AWS WAFはリクエスト単位の中身の判定を担う、という役割の違いを押さえてください。

AWS Shieldは、AWS上のリソースをDDoS攻撃から保護する専用サービスです。Standardは申し込み不要で常時働いており、一般的なネットワーク層の攻撃を自動的に緩和します。Advancedは追加契約が必要で、より大規模な攻撃への対応、詳細な可視化、専門チームによる支援が受けられます。

用語のキホン：DDoS攻撃

DDoS攻撃（分散型サービス妨害攻撃）とは、多数の端末から一斉に大量の通信を送りつけ、対象のサーバーや回線を処理しきれない状態にしてサービスを止める攻撃です。大きく分けると、回線の帯域を埋め尽くすボリューム型、通信の接続手順の不備を突くプロトコル型、正常に見えるリクエストを大量に送るアプリケーション層型があります。攻撃元が世界中に分散しているため、単純に1つのIPアドレスを遮断しても止まりません。防御の基本は、攻撃の通信を利用者のサーバーに届く手前で吸収・振り分けること、そして正常な通信と攻撃通信を見分けて捨てることです。AWSの場合、CloudFrontやRoute 53のような世界中に分散した拠点を持つサービスを前段に置くこと自体が、攻撃を分散して受け止める効果を持ちます。

StandardとAdvancedの使い分け

Standardは全AWS利用者に自動適用され、代表的なネットワーク層・トランスポート層の攻撃を防ぎます。Advancedでは、対象リソースを指定した高度な検知、攻撃時の詳細なメトリクスや通知、AWSのDDoS対応チームへのエスカレーション、そして攻撃に起因して急増した利用料金の補填申請といった仕組みが利用できます。Advancedを契約するとAWS WAFの一部機能を追加費用なしで使える点も、試験では「大規模攻撃を受けても止まらない構成」を問う設問の判断材料になります。

AWS Network Firewallは、VPC内を通る通信を検査する、マネージドなネットワーク侵入検知・防御の仕組みです。専用のサブネットにファイアウォールのエンドポイントを配置し、ルートテーブルで通信をそこへ通すように設計します。ルールはステートレスとステートフルの2種類を組み合わせて記述します。

用語のキホン：ステートレスとステートフルの検査

ステートレスな検査とは、パケット1つ1つを前後の文脈と無関係に評価する方式です。処理が軽く高速ですが、「行きを許可したから帰りも許可する」という判断ができないため、往復の両方向にルールが必要になります。対してステートフルな検査は、通信の一連のやり取り（コネクション）を記憶したうえで判断します。行きの通信を許可すれば戻りの通信も自動的に許可され、さらに通信の流れ全体を見るため、接続先のドメイン名による制御や、既知の攻撃パターンとの照合も可能になります。AWSのセキュリティグループはステートフル、ネットワークACLはステートレスという対応関係を思い出すと理解しやすいでしょう。

他のサービスとの使い分け

セキュリティグループとネットワークACLはIPアドレスやポート番号の単位でしか制御できず、しかも設定はリソースごと、サブネットごとに分散します。AWS Network FirewallはVPC単位で通信を集約して検査でき、「許可した特定のドメインへの通信だけ外部に出す」といった要件に応えられます。一方、Webアプリケーションへの受信リクエストの中身を判定するのはAWS WAFの役目です。試験では「VPCから外部への通信を、許可リストのドメインだけに限定したい」という要件でAWS Network Firewallが選ばれます。

アカウントが数十に増えると、各アカウントで個別にWAFのルールを設定するのは現実的ではなく、設定漏れも生じます。Firewall Managerは中央のセキュリティ管理者が一度ポリシーを定義すれば、対象すべてに反映される仕組みを提供します。

用語のキホン：ファイアウォールとポリシーの一元管理

ファイアウォールとは、通信を検査して許可するか遮断するかを判断する仕組みの総称です。AWSでは、Webアプリへの攻撃を防ぐAWS WAF、大規模なDDoS攻撃から守るAWS Shield Advanced、VPCの通信を検査するAWS Network Firewall、そしてセキュリティグループがこれにあたります。Firewall Managerはこれらの設定をセキュリティポリシーとしてまとめ、適用範囲をアカウント単位やタグ単位で指定します。前提としてAWS Organizations（複数アカウントを組織として束ねる仕組み）が有効になっている必要があり、これは試験でよく問われる条件です。

試験での位置づけ

「複数アカウントにまたがって」「新規リソースにも自動的に」「セキュリティ設定の準拠状況を継続的に確認したい」という要件が並べばFirewall Managerです。単一アカウント・単一アプリの保護だけならAWS WAFを直接設定すれば足ります。設定の準拠監査という点でAWS Configと似ていますが、Firewall Managerはファイアウォール系に特化し、適用まで自動で行う点が異なります。

攻撃は静かに進行することが多く、ログを人が読んで気づくのは困難です。GuardDutyは機械学習と脅威情報を使い、通常と異なる振る舞いを自動的に浮かび上がらせます。試験では「継続的な脅威検知」というキーワードで登場します。

用語のキホン：脅威検知と分析対象のログ

脅威検知とは、システムへの攻撃や侵害の兆候を見つけ出す活動です。GuardDutyが分析するのは主に、VPC内の通信記録であるVPCフローログ、ドメイン名の名前解決の記録であるDNSログ、AWSへの操作履歴であるCloudTrailのイベントです。重要なのは、これらのログを利用者が自分で有効化していなくてもGuardDutyが独自に取得して分析する点で、そのため導入負荷がほぼありません。検知結果はFindings（検出結果）として重要度つきで表示され、EventBridgeと連携させれば自動で通知や対処を走らせられます。

似たサービスとの違い

Amazon InspectorはEC2やコンテナイメージの脆弱性、つまり「弱点があるか」を調べるサービスで、GuardDutyの「攻撃されているか」とは目的が異なります。AWS Security HubはGuardDutyやInspectorなど複数サービスの結果を集約して一覧するダッシュボードです。Amazon MacieはS3内の個人情報など機微データの発見に特化します。この4つの役割の違いは頻出の出題ポイントです。

Amazon Inspectorは、自分が動かしているソフトウェアの「弱点」を探すサービスです。OSやライブラリのバージョンを調べ、公開されている脆弱性情報と突き合わせて危険なものを洗い出します。EC2ではSystems Managerのエージェント経由で情報を集めるため、対象インスタンスの準備が前提になります。

用語のキホン：脆弱性とCVE

脆弱性とは、ソフトウェアの設計や実装の不備のうち、攻撃に悪用され得るものを指します。世界中で日々発見され、番号を付けて公開されます。この共通の識別番号がCVEで、「どのソフトのどのバージョンに、どんな問題があるか」を全世界で同じ名前で参照できるようにしたものです。重要なのは、自分が何も変更していなくても、新しい脆弱性が公表された瞬間に自分のシステムが危険な状態になり得る、という点です。だからこそ脆弱性管理は一度きりの点検ではなく、継続的なスキャンが必要になります。Amazon Inspectorはこの継続性を自動で担保します。

似たセキュリティサービスとの役割の違い

SAA試験では4つのサービスの役割を区別できるかが問われます。Amazon Inspectorは「弱点を探す」、Amazon GuardDutyはログを解析して「不審な振る舞いを検知する」、Amazon MacieはS3内の「機密データを見つける」、Amazon Detectiveは検知後に「原因と経緯を調査する」役割です。言い換えると、Inspectorは攻撃される前の予防、GuardDutyは攻撃中の検知、Detectiveは事後の分析にあたります。この時間軸で覚えると混同しにくくなります。

AWS Security Hubは、セキュリティ状況の全体像を把握するための集約点です。個々のサービスの画面を巡回する必要がなくなり、複数アカウント・複数リージョンの状況もまとめて見られます。検出結果はスコアや深刻度で整理され、優先して対処すべき項目が分かるようになっています。

用語のキホン：セキュリティ態勢管理とコンプライアンス標準

セキュリティ態勢管理とは、個別の攻撃に対処することではなく、「自分たちの環境が安全な状態に保たれているか」を継続的に測り、ずれを直していく取り組みを指します。そのものさしとなるのがコンプライアンス標準で、CISベンチマークやPCI DSSのように、業界で合意された設定基準の一覧です。Security Hubはこうした標準に含まれる項目を自動でチェックし、合格・不合格を判定します。判定の裏側ではAWS Configのルールが使われるため、Configを有効にしておくことが前提になります。標準に沿っているかを機械的に確認できることで、監査対応の負荷も大きく下がります。

他の管理系サービスとの使い分け

検出結果はAWS Security Finding Formatという共通の形式に変換されるため、出所の違うアラートを同じ基準で比較できます。AWS Configが「リソースの設定変更を記録し、あるべき状態からのずれを判定する」サービスであるのに対し、Security Hubは「Configを含む複数の情報源の結果を集約し、標準に照らして俯瞰する」上位の位置づけです。CloudTrailは操作の記録、GuardDutyは脅威の検知、Security Hubはそれらの結果の統合、と整理すると試験で迷いません。

Amazon Macieは、S3に何が入っているかを把握するためのサービスです。データが増えるほど「どこに個人情報があるか分からない」状態に陥りやすく、それ自体が大きなリスクになります。Macieはバケットの一覧と設定状況を継続的に評価しつつ、指定した対象を検査して機密データの所在を報告します。

用語のキホン：機密データとデータ分類

機密データとは、漏えいすると個人や組織に被害が及ぶ情報のことで、氏名や住所などの個人情報、クレジットカード番号や口座情報などの金融情報、認証情報などが含まれます。これらを守るための第一歩がデータ分類、つまり「どのデータがどれくらい重要か」に応じてラベル付けし、扱い方を変える取り組みです。分類ができていれば、重要度の高いデータにだけ強い暗号化やアクセス制限を適用する、といった合理的な対策が取れます。逆に分類ができていないと、すべてを最高水準で守るか、何も守らないかの極端な選択になりがちです。Macieはこの分類作業を自動化し、人手では追えない量のデータに対応します。

検出の仕組みと試験ポイント

Macieには、あらかじめ用意されたマネージドデータ識別子（一般的な機密情報のパターン）と、自分で正規表現などを定義するカスタムデータ識別子があります。社員番号や契約番号のような組織固有の形式は後者で検出します。検出結果はSecurity HubやEventBridgeへ連携でき、発見時に自動で通知や修復を走らせる構成が組めます。試験では「S3内に個人情報が存在しないか確認したい」「機密データを含むバケットが公開されていないか監視したい」という要件でMacieが正解になります。

GuardDutyが「何かおかしい」と教えてくれても、なぜそれが起きたのか、どこまで被害が及んだのかは別途調査が必要です。Detectiveはこの調査工程を支援します。

用語のキホン：検知と調査、そして根本原因分析

セキュリティ運用は大きく、異常を見つける検知と、その事象を掘り下げる調査に分かれます。調査で行うのが根本原因分析で、「いつ、どのアカウントの、どの権限が使われ、どこへ通信したか」を追跡します。Detectiveは複数のログを自動で収集し、リソース同士の関係をグラフモデル（点と線で関係性を表現したデータ構造）として保持します。これにより、あるIPアドレスから始まった一連の操作を、アカウントやインスタンスをまたいで一続きに辿れます。分析対象は数十日分がさかのぼれる形で保持されます。

GuardDutyやSecurity Hubとの関係

3つは役割分担の関係にあります。GuardDutyが検知し、Security Hubが結果を集約して一覧し、Detectiveが個別の事象を深掘りします。GuardDutyの検出結果の画面から直接Detectiveの調査画面へ遷移でき、この連携が試験で問われます。「検知後の調査を効率化したい」「侵害の範囲を特定したい」という文言があればDetectiveが答えです。

各種の認証や法令対応では、「本当に決められた設定になっているか」を示す証拠の提出が求められます。Audit Managerはこの証拠を継続的に自動収集し、監査担当者へ渡せる形に整えます。

用語のキホン：コンプライアンスと証跡、フレームワーク

コンプライアンスとは、法令や業界基準、社内規程に沿って運用できている状態を指します。それを示す記録が証跡（エビデンス）で、たとえば「暗号化が有効である設定内容」や「特定の操作が誰によって行われたかの記録」が該当します。Audit Managerは監査基準ごとの要求事項をまとめたフレームワークという雛形を持ち、PCI DSSやHIPAA、各種のセキュリティ基準に対応した既成のものを選ぶか、自社独自のものを作成できます。フレームワークを選んでアセスメント（評価）を開始すると、CloudTrailやConfig、Security Hubから関連データが自動で集められ続けます。

AWS Configとの違い

AWS Configはリソース設定の変更履歴を記録し、ルールへの準拠状況を評価するサービスで、いわば技術的なチェックの実行役です。Audit Managerはその結果を含む各種情報を、監査基準の項目に紐づけて証拠として整理し、報告書を生成する役です。「監査レポートの作成を自動化したい」とあればAudit Manager、「設定変更を追跡し準拠を判定したい」ならAWS Configと切り分けます。

クラウドを採用する際、「その基盤自体は信頼できるのか」を証明する資料が求められます。Artifactは、AWSが外部監査機関から受けた評価の報告書を利用者へ提供する窓口です。無料で利用でき、追加の設定も不要です。

用語のキホン：責任共有モデルと第三者監査報告書

AWSのセキュリティは責任共有モデルという考え方に基づきます。データセンターの物理的な安全やハードウェア、基盤ソフトウェアの保護はAWSの責任、その上に構築するOS・アプリケーション・データ・アクセス権限の設定は利用者の責任、という分担です。Artifactが提供するのはAWS側の責任範囲を証明する資料で、代表例がSOC報告書（内部統制の有効性を第三者が評価した報告書）やISO 27001の認証、PCI DSSの準拠証明です。あわせて、個人データの取り扱いに関するデータ処理契約など、AWSとの間で締結する契約類もここで確認・受諾できます。

試験での押さえどころ

Artifactが提供するのは「AWS側」の証明であり、利用者が自分の環境について作る証跡ではありません。自社環境の監査証跡はAudit ManagerやConfig、CloudTrailの領域です。この線引きが問われます。またSOC報告書などは機密情報を含むため、取得時に守秘義務条項への同意が必要である点も特徴です。

Organizationsは、複数のAWSアカウントをまとめて管理するサービスです。請求を1つに集約する「一括請求」、アカウントを階層化する「OU（組織単位）」、各アカウントの権限上限を定める「SCP（サービスコントロールポリシー）」が主な機能です。

用語のキホン：OU・SCP・ガードレール

OU（組織単位）は、アカウントをフォルダのようにまとめる入れ物で、部署や環境（本番・開発など）ごとに階層化します。SCPは、そのOUやアカウントが「使ってよいサービス・操作の上限」を定めるルールで、権限を与えるものではなく上限を絞るものです。このように「やってはいけないことを仕組みで防ぐ枠」をガードレールと呼びます。

SCPとIAMの関係（頻出）

SCPで許可されていても、IAMで権限を付けなければ操作はできません。逆にIAMで許可していても、SCPが禁止していれば実行できません。つまり実際にできること＝SCPが許す範囲とIAMの許可が重なった部分です。この二段構えが大規模環境の統制の土台になります。

Control Towerは、Organizationsを土台に、安全な初期環境（ランディングゾーン）を自動でセットアップします。アカウントの払い出し（Account Factory）、予防的・発見的なガードレール、ログの集約や監査アカウントの整備を一元管理できます。

用語のキホン：ランディングゾーンと2種類のガードレール

ランディングゾーンとは、これから使い始める前提として整えておく「安全な初期状態のAWS環境一式」のことです。ガードレールには2種類あり、予防的ガードレールは違反する操作をそもそも実行させない（SCPで禁止する）もの、発見的ガードレールは実行後に違反を見つけて通知する（AWS Configで検知する）ものです。「防ぐ」と「気づく」を組み合わせて統制します。

Organizationsとの役割分担

ゼロから手作業でマルチアカウント基盤を作る手間を大きく削減できます。Organizationsが「アカウントを束ねる土台」、Control Towerが「その土台の上に推奨構成を自動でセットアップし、継続的に統制する仕組み」と、役割を分けて理解しましょう。

本番環境と検証環境で設定が微妙に違ってしまう、という問題は多くの現場で起こります。CloudFormationはインフラの定義をコードとして扱うことで、この差異をなくします。テンプレートはJSONまたはYAML形式で記述します。

用語のキホン：スタック・変更セット・ドリフト・べき等性

スタックとは、1つのテンプレートから作られたリソースのまとまりのことです。スタックを削除すれば、その中のリソースがまとめて消えるため、後片付けが簡単になります。変更セットは、テンプレートを更新したときに「何が追加・変更・削除されるか」を実行前に確認できる差分プレビューの仕組みです。ドリフトは、テンプレートの定義とAWS上の実際の状態がずれてしまった状態を指し、誰かがコンソールから手作業で設定を変えた場合などに発生します。べき等性とは、同じ操作を何度実行しても結果が同じになる性質のことで、CloudFormationはこの性質を持つため、繰り返し適用しても環境が壊れません。

仕組みと試験ポイント

更新中にエラーが起きると、既定ではロールバック（変更前の状態へ自動的に戻す動作）が働き、中途半端な構成になることを防ぎます。複数のアカウントやリージョンへ同じテンプレートを一括展開したい場合はStackSetsという機能を使います。試験では「環境を再現可能にしたい」「インフラをコードで管理したい」という要件が出たら、まずCloudFormationを検討します。

クラウドの操作はほぼすべてAPI呼び出しとして行われます。CloudTrailはそのAPI呼び出しを記録し、後から検証できるようにします。既定でも直近の操作履歴は参照できますが、長期保存には証跡の作成が必要です。

用語のキホン：管理イベント・データイベント・証跡

管理イベントとは、リソースそのものを操作する記録のことで、EC2インスタンスの起動やIAMユーザーの作成などが該当します。データイベントは、リソース内のデータに対する操作の記録で、S3オブジェクトの読み書きやLambda関数の実行などが含まれます。データイベントは件数が非常に多くなるため、既定では記録されず、必要な対象を指定して有効化します。証跡（Trail）は、これらのイベントをS3バケットなどへ継続的に保存する設定のことです。証跡にはログファイル検証という機能があり、保存されたログが改ざんされていないかを確認できます。

CloudWatch・Configとの役割の違い

ここは試験で最も混同しやすい部分です。CloudTrailは「誰が何をしたか（操作の記録）」、CloudWatchは「今どう動いているか（メトリクスとログによる監視）」、Configは「今どういう設定になっているか、いつ変わったか（構成の状態と履歴）」を担当します。「不正なセキュリティグループ変更を行った犯人を特定したい」ならCloudTrail、「セキュリティグループが基準に違反していないか常に確認したい」ならConfigです。

CloudWatchは、AWSリソースやアプリの状態を監視するサービスです。CPU使用率などの「メトリクス」、アプリの「ログ（CloudWatch Logs）」、変化を表す「イベント（EventBridge）」を扱います。

用語のキホン：メトリクス・ログ・イベント

メトリクスは「CPU 70%」のような数値の時系列データ、ログはアプリやOSが出す文字の記録、イベントは「インスタンスが起動した」のような状態変化の通知です。CloudWatchはこの3つを扱い、メトリクスがしきい値を超えたら「アラーム」、イベントが起きたら「EventBridge」で、それぞれ次のアクションにつなげます。

アラームと自動化

「アラーム」でしきい値超過を検知し、SNS通知やAuto Scaling起動、Lambda実行などの自動アクションにつなげられます。OSの中の情報（メモリ使用率など）を取るには「CloudWatchエージェント」を入れます。ログを検索・分析する「Logs Insights」、状況を一覧化する「ダッシュボード」も便利です。

似たサービスとの違い

CloudWatchは「監視・メトリクス・ログ」、CloudTrailは「誰が何をしたかの監査証跡」、Configは「構成の評価」と目的が異なります。混同しやすいので区別しましょう。

インスタンス内部にログを置いたままにすると、そのインスタンスが終了した時点でログも失われます。オートスケーリングで頻繁にインスタンスが入れ替わる環境では特に深刻です。CloudWatch Logsは、ログをインスタンスの外に集約することでこの問題を解決します。

用語のキホン：メトリクスとログの違い

メトリクスは、CPU使用率のように「時刻と数値」の組で表される時系列データです。集計や閾値監視に向いており、保存効率も高い一方で、なぜその値になったのかという文脈は含みません。対してログは、「どのリクエストがどんなエラーで失敗したか」といった文章形式の記録で、原因究明に必要な詳細を持ちますが、そのままでは監視の対象にできません。CloudWatch Logsではログをロググループという単位でまとめ、その中の個々の出力元ごとにログストリームが作られます。保持期間はロググループごとに設定でき、無期限にすることも、一定日数で自動削除することもできます。

メトリクスフィルターとサブスクリプションフィルター

メトリクスフィルターは、ログの中から特定のパターンに一致する行を数え、その件数をメトリクスに変換する仕組みです。これにより「ERRORという文字列が5分間に10回以上出たら通知する」といったアラームを作れます。サブスクリプションフィルターは、ログを別のサービスへリアルタイムに転送する仕組みで、大量ログの分析基盤への連携に使われます。大量のログを本格的に検索したい場合は、CloudWatch Logs Insightsという専用のクエリ機能を使います。

「暗号化されていないEBSボリュームが存在しないか」「パブリック公開されたS3バケットがないか」といった確認を、人手で継続的に行うのは現実的ではありません。Configはこの点検を自動化します。

用語のキホン：構成項目・コンプライアンス・自動修復

構成項目（Configuration Item）とは、あるリソースのある時点の設定内容をスナップショットとして記録したものです。これが蓄積されることで、「1週間前はどういう設定だったか」を遡って確認できます。Configルールは、リソースが満たすべき条件を定義したもので、AWSがあらかじめ用意したマネージドルールと、Lambdaで独自に書くカスタムルールがあります。ルールに適合していれば準拠（Compliant）、違反していれば非準拠（Noncompliant）と判定されます。自動修復は、非準拠を検知した際にSystems Manager Automationのランブックを実行し、設定を自動的に正しい状態へ戻す仕組みです。

試験ポイント：継続的な評価という考え方

Configの本質は「一度きりの点検」ではなく「設定変更のたびに評価が走る継続的な監視」にあります。コンフォーマンスパックを使えば、複数のルールと修復設定をまとめて組織全体へ展開できます。監査証跡としての操作履歴が欲しいならCloudTrail、設定の状態と準拠状況が欲しいならConfig、と覚えてください。

Systems Managerは単一の機能ではなく、複数の機能の集合体です。EC2だけでなく、オンプレミスのサーバーや他クラウドの仮想マシンも管理対象にできます。

用語のキホン：マネージドノード・エージェント・ドキュメント

マネージドノードとは、Systems Managerの管理下に置かれたサーバーのことです。管理対象になるには、サーバー上でSSM Agentという常駐プログラムが動作し、かつそのサーバーにSystems Managerへのアクセスを許可するIAMロールが付与されている必要があります。ドキュメント（SSM Document）は、実行したい作業手順を記述した定義ファイルで、これを指定することでコマンドや自動化処理を実行します。重要なのは、エージェントがAWS側へ外向きに通信して指示を取りに行く方式のため、サーバー側で受信ポートを開ける必要がないという点です。

主な機能と試験ポイント

Session Managerは、SSHの鍵や踏み台サーバーなしでシェル接続できる機能で、ポート22を閉じたままの運用を可能にします。Patch ManagerはOSパッチの適用を定期実行し、Run Commandは多数のサーバーへ同じコマンドを一括投入します。Parameter Storeは設定値やパスワードを保管する場所で、暗号化にも対応します。なお、パスワードの自動ローテーションが要件に含まれる場合はSecrets Managerが適切です。

開発者に強い権限を与えると自由度は上がりますが、統制が効かなくなります。かといって権限を絞りすぎると、環境構築のたびに管理者へ依頼が集中します。Service Catalogはこのジレンマを解消します。

用語のキホン：製品・ポートフォリオ・起動制約

製品（Product）とは、CloudFormationテンプレートとして定義された1つのシステム構成のことです。バージョン管理ができ、承認された版だけを公開できます。ポートフォリオは製品をまとめた集合で、これに対して「この部門のユーザーだけが利用できる」といったアクセス権を設定します。起動制約（Launch Constraint）は、製品を起動する際に使うIAMロールを指定する仕組みです。これにより、利用者自身にはリソース作成権限がなくても、カタログ経由でなら構築できる、という状態が作れます。テンプレート制約を使えば、選べるインスタンスタイプを限定するといった制限も可能です。

試験ポイント：セルフサービスと統制の両立

試験では「開発者に自由に環境を作らせたいが、標準構成から外れさせたくない」という要件が出たらService Catalogが答えになります。CloudFormationが「構築の仕組み」であるのに対し、Service Catalogは「誰に何を作らせるかの統制」を担う層だと理解してください。

移行当日にインスタンスを大量に起動しようとして、アカウントの上限に阻まれるという失敗は珍しくありません。上限の引き上げには審査と時間がかかるため、直前の申請では間に合わないこともあります。Service Quotasは、この確認と申請を体系的に行うための窓口です。

用語のキホン：サービスクォータ（サービス上限）

サービスクォータとは、AWSアカウントやリージョンごとに定められた、リソースを作成できる数や処理の実行頻度の上限です。上限には2種類あり、申請によって引き上げられる調整可能な上限と、サービスの設計上変更できないハードな上限があります。上限はアカウント単位かつリージョン単位で管理されるのが一般的なので、複数リージョンへ展開する場合はそれぞれで確認が必要です。上限を超えるとAPIがエラーを返し、オートスケーリングが機能しないなど障害の直接原因になります。

大規模環境での運用

AWS Organizationsと組み合わせると、新しく作成されるアカウントに対して希望する上限値を自動的に適用するクォータリクエストテンプレートを用意できます。これにより、アカウントが増えるたびに手作業で申請する負担を減らせます。またCloudWatchと連携して、使用量が上限に近づいたときにアラームを出す設定も可能です。試験では「移行のカットオーバー直前に上限で失敗しないための事前対策」という文脈で登場します。

クラウド移行時には、余裕を見て大きめのインスタンスを選ぶことがよくあります。しかし稼働後の実測値を見ると、大半が過剰であるケースが少なくありません。Compute Optimizerはその判断を数値に基づいて行います。

用語のキホン：ライトサイジングと機械学習による分析

ライトサイジング（適正化）とは、ワークロードの実際の負荷に合わせてリソースのサイズを過不足なく調整することです。Compute OptimizerはCloudWatchのメトリクス履歴を機械学習で分析し、リソースを過剰プロビジョニング（スペック過剰）、プロビジョニング不足（スペック不足）、最適のいずれかに分類します。分析には一定期間分の測定データが必要で、稼働直後のリソースは判定できません。既定ではCPUやネットワークなどの標準メトリクスを使いますが、メモリ使用率まで踏まえた精度の高い提案が欲しい場合は、CloudWatchエージェントを導入してメモリのメトリクスを収集します。

対象リソースと試験ポイント

対象はEC2インスタンス、EC2 Auto Scalingグループ、EBSボリューム、Lambda関数、そしてECSのFargateサービスなどです。Trusted Advisorも低使用率のインスタンスを指摘しますが、Compute Optimizerは「どのインスタンスタイプへ変更すべきか」という具体的な移行先まで提示する点が異なります。

AWSは長年の運用で得られたベストプラクティスを蓄積しており、Trusted Advisorはそれを自分の環境に照らして自動チェックしてくれます。コンソールを開くだけで結果が確認でき、追加の設定はほとんど不要です。

用語のキホン：5つのチェックカテゴリ

Trusted Advisorの点検は、コスト最適化、パフォーマンス、セキュリティ、フォールトトレランス（障害耐性）、サービスクォータ（利用上限）という5つのカテゴリに分かれています。フォールトトレランスとは、一部が壊れてもシステム全体が動き続ける性質のことで、たとえばEC2が単一のアベイラビリティゾーンに偏っていないかが点検されます。サービスクォータとは、アカウントごとに定められた各リソースの作成上限のことで、上限に近づくと警告が出ます。なお、全カテゴリの全チェックを利用できるのはビジネス以上のサポートプランで、基本のプランでは一部のチェックに限定されます。

試験ポイント：他サービスとの使い分け

Trusted Advisorは「幅広く浅く、既定のベストプラクティスに照らして助言する」ツールです。より深く設計思想まで踏み込んで評価したい場合はWell-Architected Tool、EC2などのサイズが適切かを実測値から判断したい場合はCompute Optimizerが適します。

AWSは良いアーキテクチャの考え方をWell-Architected フレームワークとして文書化しています。このツールは、その文書をチェックリスト形式でシステムに適用し、レビュー結果をレポートとして残せるようにしたものです。

用語のキホン：6つの柱とワークロード

フレームワークは6つの柱で構成されます。運用上の優秀性（運用を継続的に改善できるか）、セキュリティ（データと資産を守れるか）、信頼性（障害から回復できるか）、パフォーマンス効率（リソースを適切に選び使えているか）、コスト最適化（不要な支出を避けられているか）、持続可能性（環境負荷を減らせているか）です。診断の単位はワークロードと呼ばれ、これは1つのビジネス価値を提供するアプリケーションとリソースのまとまりを指します。診断結果は高リスク項目と中リスク項目として提示され、改善計画を立てる材料になります。

試験ポイント：レビューのタイミング

Well-Architectedのレビューは、設計段階だけでなく本番稼働後も定期的に行うことが推奨されます。マイルストーンという機能で、ある時点のレビュー結果を保存でき、時間の経過とともにどれだけ改善したかを比較できます。自動で環境をスキャンするTrusted Advisorとは異なり、こちらは人が設問に答える定性的なレビューである点が違いです。

Windows ServerやSQL Server、Oracleなどのソフトウェアは、CPUコア数やソケット数に応じたライセンス契約が必要です。クラウドではインスタンスの起動が容易なため、気づかないうちに契約違反状態になるリスクがあります。

用語のキホン：ライセンス設定とBYOL

ライセンス設定（License Configuration）とは、「コア数の上限」「ソケット数の上限」といった契約条件をルールとして定義したものです。これをAMIやインスタンスに紐づけることで、起動時に上限を超えないかが自動的に検証されます。BYOL（Bring Your Own License、既存ライセンスの持ち込み）とは、すでに購入済みのライセンスをクラウド上でも使う形態のことです。BYOLでは物理サーバー単位のライセンス条件を満たす必要があるため、専有物理サーバーであるDedicated Hostと組み合わせて使うことが多くなります。

試験ポイント

上限を超えた場合の動作として、警告だけを出すか、起動そのものを禁止するかを選べます。Organizationsと連携すれば、組織内の全アカウントのライセンス利用状況をまとめて把握できます。「監査対応でライセンス準拠を証明したい」という要件で登場します。

システムに異常が出たとき、原因が自社の変更なのかAWS基盤側の問題なのかを早く判断できると、対応時間を大きく短縮できます。Health Dashboardはその判断材料を提供します。

用語のキホン：サービス正常性とアカウント固有のイベント

Health Dashboardには2つの視点があります。サービス正常性（Service health）は、全利用者に共通の、リージョンごとのサービス稼働状況を示す公開情報です。もう一方のアカウント固有のイベント（Your account health）は、自分のアカウントのリソースにだけ関係する通知で、たとえば「あなたが使っている特定のEC2インスタンスが基盤メンテナンスのため再起動されます」といった内容が届きます。後者はAWS Health APIで取得でき、EventBridgeと組み合わせて自動処理につなげられます。なおAPIによる取得はビジネス以上のサポートプランが前提です。

試験ポイント

試験では「AWS側の計画メンテナンス通知を自動で受け取り、対応を自動化したい」という要件で登場します。この場合、Health イベントをEventBridgeで受け取り、SNS通知やLambdaによる自動対応につなげる構成が定番です。

Grafanaは、時系列データをグラフとして表示するための定番ツールです。自前で構築するとサーバーの構築やバージョン更新、可用性の確保が必要になりますが、マネージドサービスではそれらをAWSが担います。

用語のキホン：可観測性とデータソース

可観測性（オブザーバビリティ）とは、システムの外から観測できる情報だけで内部の状態を理解できる性質のことで、主にメトリクス・ログ・トレースの3種類のデータで構成されます。Grafanaはその中でも可視化を担当し、データそのものを保存するのではなく、外部のデータソースに問い合わせて表示します。接続できるデータソースには、CloudWatch、Amazon Managed Service for Prometheus、OpenSearch、X-Ray、Timestreamなどがあり、AWS以外のシステムのデータも扱えます。ダッシュボードは複数のグラフを並べた画面のことで、既存のGrafanaダッシュボード定義をそのまま持ち込めます。

試験ポイント

認証にはIAM Identity Centerや外部のIDプロバイダを利用でき、閲覧のみ・編集可能といった権限の分離ができます。「オンプレミスとAWSのメトリクスを1つの画面で見たい」「既存のGrafana資産を活かしたい」という要件が判断の目安です。

KubernetesやECSなどのコンテナ環境では、Prometheusが事実上の標準的な監視基盤として広く使われています。ただし自前運用では、データ量の増加に伴うストレージ管理やスケーリングが課題になります。

用語のキホン：時系列データベースとスクレイピング

時系列データベースとは、時刻とセットになった数値を効率よく保存・検索することに特化したデータベースです。Prometheusはこの一種で、スクレイピングという方式でデータを集めます。これは、監視対象のアプリケーションが公開しているエンドポイントへ、Prometheus側から定期的に取りに行くプル型の収集方式です。データはメトリクス名とラベル（付随する属性情報）の組で識別され、PromQLという専用のクエリ言語で集計や比率計算を行います。Amazon Managed Service for Prometheusはこの保存・クエリ部分をマネージドで提供し、収集エージェント側は利用者が用意します。

試験ポイント：Grafanaとの関係

役割分担が理解のポイントです。Prometheusはデータの収集と保存、Grafanaは可視化を担当し、この2つは組み合わせて使うのが一般的です。AWSのマネージドなアプリケーション監視全般はCloudWatchが担いますが、既存のPromQLやKubernetes向けの監視資産を活かしたい場合にこちらが選ばれます。

マイクロサービスが増えると、チームごとにインフラ構成が微妙に食い違い、運用や監査が難しくなります。Proton は承認済みの構成をカタログ化し、開発者はパラメーターを指定するだけで準拠した環境を得られます。テンプレートを更新すれば、利用中の環境へ一括で反映することも可能です。

用語のキホン：セルフサービス型のプラットフォームエンジニアリング

プラットフォームエンジニアリングとは、社内の開発チームに対して、標準化された基盤を製品のように提供する取り組みを指します。その中核となるのがセルフサービスという考え方で、開発者がインフラ担当者へ依頼して待つのではなく、用意された選択肢から自分で環境を払い出せる状態を作ります。狙いは、統制（ガバナンス）と開発速度を両立させることです。Proton ではインフラ担当者が IaC（Infrastructure as Code、インフラ構成をコードとして定義する手法）でテンプレートを書き、開発者はその実装を知らずに利用します。

環境テンプレートとサービステンプレート

Proton のテンプレートは二層に分かれます。環境テンプレートは VPC やクラスターなど、複数のサービスが共有する土台を定義します。サービステンプレートは個々のアプリケーションの実行構成とデプロイ手順を定義し、環境の上に載せます。テンプレートは版管理されており、新しい版を公開して既存の利用先へ展開できるため、セキュリティ設定の更新を組織横断で適用しやすくなります。単に構成を作るだけの CloudFormation や CDK と異なり、「配布と版管理まで含めた運用」を担う点が違いです。

AWS CLIは自分のパソコンやサーバーにインストールして使います。マネジメントコンソールで行えることのほとんどは、CLIからも実行できます。裏側では同じAWS APIを呼び出しているため、CLIでの操作もCloudTrailに記録されます。

用語のキホン：プロファイル・認証情報・リージョン設定

CLIを使うには、まずAWSに自分が誰であるかを伝える認証情報が必要です。これはアクセスキーIDとシークレットアクセスキーの組、あるいはIAMロールによる一時的な認証情報として与えられます。プロファイルとは、この認証情報と既定リージョン、出力形式をまとめて名前を付けた設定の単位で、複数アカウントを扱う際は名前を切り替えて使い分けます。EC2やLambdaの上でCLIを動かす場合は、キーをファイルに置かずIAMロールを割り当てるのが推奨される方法です。キーの漏えいリスクがなく、認証情報が自動的に更新されるためです。

試験ポイント

コマンドは「aws サービス名 操作名」という形式で統一されています。結果はJSONなどの構造化データで返るため、他のツールと組み合わせた自動処理に向きます。試験では「アクセスキーをコードに埋め込むのは避け、IAMロールを使う」という原則が繰り返し問われます。

マネジメントコンソールは、AWSを学び始めるときの入口になる存在です。一方で、本番環境の運用では手作業による設定ミスや再現性の欠如が問題になるため、コードによる管理と併用するのが実務での基本になります。

用語のキホン：ルートユーザーとIAMユーザー・ロールの切り替え

コンソールへのサインイン方法は複数あります。ルートユーザーとは、アカウント作成時のメールアドレスでログインする最上位の利用者で、すべての操作が可能なため、日常的な作業には使わず厳重に保護すべき存在です。日常の操作にはIAMユーザーや、IAM Identity Centerを通じた一元的なサインインを使います。スイッチロールは、別アカウントのIAMロール（一時的な権限のまとまり）へ画面上で切り替える機能で、マルチアカウント環境では日常的に使われます。いずれの場合も多要素認証（パスワードに加えて別の要素で本人確認する仕組み）の有効化が強く推奨されます。

試験ポイント：グローバルとリージョンの区別

コンソールでは右上でリージョンを切り替えますが、IAMやRoute 53、CloudFrontなどはグローバルサービスのためリージョン選択の影響を受けません。リソースが見つからないときは、リージョンの選択間違いをまず疑うとよいでしょう。また、コンソールで行った操作もCLIと同様にCloudTrailへ記録されます。

DR（Disaster Recovery）設計は、まず要件を数値で定め、その数値を満たす最も安い構成を選ぶ、という順序で考えます。「とにかく万全に」ではコストが見合わなくなるためです。

用語のキホン：RTOとRPO

RTO（目標復旧時間）は「障害発生から復旧までに許容できる時間」、RPO（目標復旧時点）は「失ってもよいデータの時間幅」です。例えばRTO 1時間・RPO 15分なら、1時間以内にサービスを再開し、失うデータは直近15分ぶんまでに収める必要があります。RPOはバックアップの間隔とほぼ直結し、RTOは待機環境をどれだけ準備しておくかで決まります。どちらも厳しくするほどコストは上がります。

4つのDRパターン（コストが安い順）

バックアップ＆リストア：バックアップだけ取り、障害時に環境を作って復元（RTOは数時間以上）。パイロットライト：DBなど最小限だけ常時起動しておき、障害時にサーバー群を起動（数十分）。ウォームスタンバイ：縮小版を常時稼働させ、障害時に拡大（数分）。マルチサイト（アクティブ・アクティブ）：同等の環境を常時稼働させ即切替（ほぼゼロ）。

数百台規模のサーバーを移行するとき、どのサーバーがどこまで進んだのかを人手の表で管理するのは現実的ではありません。Migration Hubは、AWSの移行ツールや一部のパートナーツールから進捗情報を受け取り、単一のダッシュボードに集約します。移行プロジェクト全体の状態を把握するための入口として使われます。

用語のキホン：移行ポートフォリオ管理

移行ポートフォリオ管理とは、移行対象となるサーバーやアプリケーションの一覧を作り、それぞれの移行方針・優先順位・進捗をまとめて管理する考え方です。移行対象の一覧のことをインベントリ（資産目録）と呼びます。インベントリの各項目には、移行7つのRのどれを適用するか、つまりリホスト（そのまま移す）・リプラットフォーム（一部作り替えて移す）・リファクタリング（作り直す）・リパーチェス（別の製品に買い替える）・リテイン（当面残す）・リタイア（廃止する）・リロケート（環境ごと移す）のいずれかを割り当てます。関連するサーバー群をアプリケーションという単位でグループ化しておくと、業務システム単位で進捗を見られるようになります。移行は一度で終わるものではなく波（ウェーブ）に分けて進めるため、こうした管理の土台が欠かせません。

他の移行サービスとの関係

Migration Hub自体はサーバーを移動させません。実際の作業はApplication Migration ServiceやDatabase Migration Serviceなどが担当し、その結果がMigration Hubに集まる形になります。移行元の情報収集はApplication Discovery Serviceが行い、そのデータもMigration Hubで参照できます。試験では「移行の進捗を経営層に一元的に報告したい」という要件で選択肢に挙がりやすいサービスです。

長年運用されてきた環境では、どのサーバーがどのサーバーと通信しているのかが誰にも分からなくなっていることがよくあります。その状態で移行を始めると、移したはずのシステムが動かないという事態を招きます。Application Discovery Serviceは、こうしたリスクを移行前に洗い出すためのサービスです。

用語のキホン：アセスメントと依存関係の可視化

アセスメントとは、移行対象の現状を調べて評価する工程のことです。ここでは、CPUやメモリの使用状況といった性能データと、サーバー間でどのポートを使ってどれだけ通信しているかという依存関係の2種類を集めます。性能データは、移行先のインスタンスサイズを決めるライトサイジング（過不足のないサイズ選び）に使います。依存関係は、同時に移すべきサーバーの組み合わせ、つまり移行ウェーブの区切りを決めるために使います。この2つが揃って初めて、7つのRのうちどれを適用するかを根拠を持って判断できるようになります。

2つの収集方式

収集方法には、対象サーバーにソフトウェアを導入するエージェント方式と、仮想化基盤に接続して情報を取るエージェントレス方式があります。エージェント方式のほうが詳しい情報、特にプロセス単位の通信内容まで取得できますが、全サーバーへの導入という手間がかかります。エージェントレス方式は導入が容易な代わりに、取得できる情報の粒度は粗くなります。試験では「サーバーにソフトウェアを入れられない」といった制約から方式を選ばせる出題が考えられます。

MGNは、オンプレミスや他社クラウドのサーバーにエージェントを導入し、ディスク全体をAWS側へ継続的に複製します。準備ができたら本番に影響を与えないテスト起動で動作を検証し、問題がなければ本番切替（カットオーバー）を行います。

用語のキホン：リフト＆シフトと「7つのR」

移行方針は一般に7種類に整理されます。ほぼそのまま移すリホスト（リフト＆シフト）、少し手直しして移すリプラットフォーム、クラウド向けに作り直すリファクタリング、SaaSなどへ乗り換えるリパーチェス、当面そのまま残すリテイン、使っていないので廃止するリタイア、別環境へそのまま移すリロケートです。MGNが担当するのは主にリホストです。

移行プロジェクトの進め方

まず現状把握（Application Discovery Serviceでサーバーや依存関係を棚卸し）、次に方針決定（7つのRのどれにするか）、そして実行（サーバーはMGN、データベースはDMS）という順で進めます。全体の進捗はMigration Hubで一覧管理します。

DMSは、オンプレミスや他社クラウドのDBを、動かしたままAWSへ移行できるサービスです。移行元と移行先を継続的に同期（レプリケーション）し、最後に短時間で切り替えることで、停止時間を最小化します。

用語のキホン：レプリケーションとカットオーバー

レプリケーションは移行元のデータ変更を移行先へ写し続けることです。まず既存データを丸ごと移すフルロードを行い、その間に発生した変更を追いかけるCDC（変更データキャプチャ）で差分を同期し続けます。そして実際に利用先を新環境へ切り替える瞬間をカットオーバーと呼びます。CDCで差分がほぼゼロになった状態で切り替えるため、停止時間を数分に抑えられます。

異種DB移行と併用ツール

同じDB種類はもちろん、Oracleから Auroraのような異種DB移行（ヘテロジニアス移行）にも対応します。ただしテーブル構造やストアドプロシージャの書き換えはDMSでは行えないため、SCT（Schema Conversion Tool）を併用します。回線が細く大量データを送れない場合は、Snow Familyで物理搬送してからDMSで差分同期する組み合わせも有効です。

データベース製品が変わると、テーブルの型の書き方も、ストアドプロシージャの構文も異なります。これらを手作業で書き換えるのは膨大な工数がかかり、抜け漏れも生じます。SCTはこの変換作業を自動化し、自動変換できなかった箇所をレポートとして提示します。

用語のキホン：同種移行と異種移行

データベース移行は大きく2つに分かれます。同種移行（ホモジニアス）は、OracleからOracleへのように同じ製品同士の移行で、構造をそのまま持ち込めます。異種移行（ヘテロジニアス）は、SQL ServerからPostgreSQLへのように製品が変わる移行で、スキーマ（テーブルやビュー、インデックスなどの構造定義）の変換が必要になります。異種移行は移行7つのRのうちリプラットフォームにあたり、商用ライセンス費用の削減を目的に選ばれることが多い方針です。変換できない機能が残った場合は、アプリケーション側の作り替えが必要になる点に注意が必要です。

DMSとの役割分担

SCTはスキーマとコードの変換を担当し、AWS Database Migration Service（DMS）はデータそのものの移送を担当します。手順としては、まずSCTで移行先に空のスキーマを作り、その後DMSで実データを流し込む形になります。同種移行であればスキーマの書き換えが不要なため、SCTを使わずDMS単独で完結します。試験では「異種移行ならSCTとDMSの併用、同種移行ならDMS単独」という切り分けが問われます。

数百万個のファイルを手作業のコピーコマンドで運ぶと、途中で失敗したり、転送漏れに気づけなかったりします。DataSyncは、この面倒な部分をまとめて引き受けるサービスです。

用語のキホン：オンライン転送とエージェント

オンライン転送とは、インターネットや専用線といったネットワーク回線を通じてデータを送る方式のことです。DataSyncでは、移行元の環境にエージェントという小さな仮想マシンを立てます。エージェントは社内のファイルサーバーを読み取り、データを圧縮・暗号化してAWS側へ送り出す役割を担います。転送後はチェックサム（データの中身から計算した短い値で、これが一致すれば内容も同じとみなせるもの）を比較して、正しく届いたかを自動検証します。転送先がS3などAWS内部同士の場合はエージェントが不要なケースもあります。

Storage GatewayやSnow Familyとの使い分け

DataSyncは「一度きり、または定期的にデータをAWSへ移す」ための転送ツールです。これに対しStorage Gatewayは、オンプレミスから常時AWSストレージを使い続けるための橋渡し役であり、移行ではなくハイブリッド運用が目的です。回線が細く、転送に何週間もかかってしまう規模であれば、物理デバイスで運ぶSnow Familyを選びます。SAA-C03では、この三者の役割の違いが繰り返し問われます。

Snowball Edgeなどの物理デバイスが手元に送られてきて、そこへデータをコピーし返送すると、AWS側でS3に取り込まれます。数十TBから数PB規模の移行に使います。

用語のキホン：オンライン転送とオフライン転送の分かれ目

ネットワーク転送にかかる時間は「データ量÷帯域」で決まります。例えば100Mbpsの回線で100TBを送ると、理論値でも約3か月かかり、実際にはさらに長くなります。この「回線で送るのが現実的でない量」が物理輸送を選ぶ目安です。デバイス内のデータは自動的に暗号化され、輸送中も保護されます。

エッジ処理という使い方

Snowball Edgeは計算能力とストレージを併せ持つため、通信が届かない工場・船上・被災地などでデータを収集し、その場で前処理してから持ち帰る、という使い方もできます。

企業間のデータ交換では、今もSFTPによるファイル授受が広く使われています。Transfer Familyは、その入口だけをAWSのマネージドサービスに置き換えるものです。

用語のキホン：ファイル転送プロトコルとエンドポイント

プロトコルとは、機器同士がデータをやり取りする際の共通の手順や約束事です。SFTPはSSHという暗号化通信の上でファイルを送受信する方式、FTPSはTLSで暗号化したFTPを指します。Transfer Familyでは、これらを受け付けるエンドポイント（接続先となる窓口）が用意され、利用者から見ると普通のSFTPサーバーに見えます。しかし実際に届いたファイルはS3のオブジェクトやEFSのファイルとして保存されるため、そのままAWS上の後続処理につなげられます。利用者の認証は、サービス内で管理する方式のほか、既存のディレクトリサービスやAPIと連携させることもできます。

他の転送サービスとの違い

DataSyncが「自分たちのデータをAWSへ運ぶ」ためのものであるのに対し、Transfer Familyは「外部の相手が継続的にファイルを預け入れる窓口」を提供します。取引先に接続方法の変更を求められない場合の定番解となります。

CodePipelineは、コードの変更をきっかけに「ソース取得 → ビルド（CodeBuild）→ テスト → デプロイ（CodeDeploy）」までの各ステージを自動でつなぐ仕組みです。人手を介さないため、リリースを速く・安全に・繰り返し行えます。

用語のキホン：継続的インテグレーションと継続的デリバリー

継続的インテグレーション（CI）とは、開発者の変更を頻繁に本流へ統合し、そのたびに自動でビルドとテストを走らせる進め方です。問題を小さいうちに見つけられます。継続的デリバリー（CD）は、テストを通った成果物を「いつでもリリースできる状態」に自動で保つことを指し、さらに人の承認なしで本番まで自動投入する場合は継続的デプロイメントと呼び分けます。CodePipelineはこの一連の流れをステージとアクションという単位でつなぎ、ステージ間で受け渡すファイル群をアーティファクトと呼びます。

品質を守るための仕掛け

承認ステージを挟んで本番デプロイ前に人の承認を必須にしたり、テスト失敗時にパイプラインを停止させたりできます。「自動化しつつ、危険な箇所だけ人が判断する」という設計が実務でも試験でも要点になります。

CodeBuildは、指定したコンテナ環境の上でビルドやテストを実行します。同時に何本走らせても自動で対応するため、待ち行列ができません。

用語のキホン：ビルド・アーティファクト・buildspec

ビルドとは、ソースコードを実際に動かせる形（コンパイル結果、コンテナイメージ、zipなど）へ変換する作業のことです。その成果物をアーティファクトと呼び、S3などに保存されて次のデプロイ工程へ引き渡されます。手順はbuildspec.ymlというファイルに、install・pre_build・build・post_buildといったフェーズごとに書きます。ビルド環境は毎回まっさらな状態で作られるため、「自分のPCでは動くのに本番では動かない」という環境差の問題が起きにくいのが大きな利点です。

高速化とVPC接続

依存ライブラリの再ダウンロードを省くキャッシュでビルド時間を短縮できます。また、VPC内のプライベートなデータベースへ接続してテストしたい場合は、VPC接続を設定します。

CodeDeployは、アプリを対象（EC2・オンプレ・Lambda・ECS）へ自動でデプロイするサービスです。新環境を用意して一括で切り替える「ブルーグリーン」、少しずつ入れ替える「ローリング」、一部だけ先行する「カナリア」などの方式に対応します。

用語のキホン：3つのデプロイ方式の違い

ローリングは、稼働中のサーバーを少しずつ新版へ入れ替える方式です。追加の環境が不要で安価ですが、入れ替え中は新旧が混在し、切り戻しにも時間がかかります。ブルーグリーンは、現行環境（ブルー）とは別に新環境（グリーン）を丸ごと用意し、動作確認後に振り分け先を一斉に切り替える方式です。切り戻しは「振り先を戻すだけ」なので一瞬ですが、一時的に2倍の環境費用がかかります。カナリアは、まず5%など少数の利用者にだけ新版を見せ、問題がなければ徐々に比率を上げる方式で、影響を最小限にしながら本番で検証できます。

自動ロールバックとフック

デプロイ中にCloudWatchアラームがしきい値を超えたら自動でロールバック（切り戻し）する設定が定番です。またappspecファイルのライフサイクルフック（BeforeInstall、AfterInstallなど）に処理を書くことで、デプロイ前後に検証スクリプトを実行できます。

システムが複数のサービスに分かれると、「どこかが遅い」という症状の原因を、ログを個別に見るだけで突き止めるのは困難になります。X-Rayは、リクエストごとに通過した経路と所要時間を収集して図に描き出します。CloudWatchが数値やログを集めるのに対し、X-Rayは1件の処理の流れを追う点が役割の違いです。

用語のキホン：分散トレーシング

分散トレーシングとは、複数のサービスをまたぐ1件の処理に共通のIDを付けて追跡し、全体の流れを再構成する手法です。1件の処理全体をトレース、その中の個々のサービスでの処理区間をセグメント、さらに細かい内訳（データベース呼び出しなど）をサブセグメントと呼びます。すべてのリクエストを記録すると負荷と費用がかさむため、一定の割合だけを記録するサンプリングという仕組みが使われます。収集した結果はサービスマップという、サービス間の呼び出し関係を示す図として表示され、遅延やエラー率の高い箇所が視覚的に分かります。

組み込み方と試験ポイント

利用するには、アプリケーションにX-Ray用のSDKを組み込むか、Lambdaやアプリケーションロードバランサーなど対応サービスでトレースを有効化します。EC2やコンテナ上で動かす場合は、データを中継するX-Rayデーモンを同居させる構成が一般的です。SAA-C03では「マイクロサービス構成でボトルネックを特定したい」という要件に対する答えとして押さえておきます。

アプリケーションは多数の外部ライブラリに依存しており、その取得元をどう管理するかは可用性とセキュリティの両面で課題になります。CodeArtifact は組織専用のパッケージ保管庫を提供し、外部リポジトリの内容を取り込んで中継することもできます。

用語のキホン：パッケージリポジトリと依存関係管理

パッケージとは、再利用可能なコードをバージョン付きでまとめた配布単位です。開発者はこれを名前とバージョンで指定して取り込みますが、この参照関係を依存関係と呼びます。公開リポジトリを直接参照すると、外部の障害やパッケージの削除、悪意ある差し替えの影響を受けます。そこで組織内にプライベートリポジトリを置き、一度取得したパッケージを保持するアップストリーム構成をとります。これにより取得元が一本化され、どのバージョンが使われているかを監査できます。

ドメインとリポジトリの構造

CodeArtifact はドメインという上位のまとまりの下に複数のリポジトリを置く構造です。同じドメイン内ではパッケージの実体が共有されるため、保管容量を無駄にしません。アクセス制御は IAM とリソースポリシーで行い、他アカウントへの共有もこの仕組みで実現します。保管データは KMS で暗号化されます。

人手によるレビューは有効ですが、レビュー担当者の経験や時間に左右されます。CodeGuru は定型的な不具合パターンや非効率な処理を自動で検出し、指摘として提示します。開発の早い段階と、本番稼働後の両方に対応する点が特徴です。

用語のキホン：静的解析とプロファイリング

静的解析とは、プログラムを実行せずにソースコードそのものを読み取り、問題を見つける手法です。リソースの解放漏れ、例外処理の不備、機密情報の直書きなどを、動かす前に指摘できます。一方プロファイリングは、実際に動作しているアプリケーションから CPU 使用時間やメモリ確保の状況を継続的に採取し、どの処理が資源を最も消費しているかを可視化する手法です。前者は「書き方の誤り」を、後者は「実行時の非効率」を対象とします。CodeGuru Reviewer が静的解析、CodeGuru Profiler がプロファイリングを担当します。

導入時の位置づけ

Reviewer はプルリクエストに対して自動的に指摘を付ける形で組み込め、レビュー工程の負荷を下げます。Profiler はエージェントを常駐させて低いオーバーヘッドで計測を続け、コスト削減につながる改善点を提示します。セキュリティ観点の指摘は Amazon Inspector など他の仕組みと役割が重なる部分があるため、対象が「コード」なのか「稼働環境」なのかで整理すると混乱しません。

API Gatewayは、クライアントとバックエンドの間に立つ受付窓口です。個々のアプリで作り込みがちな認証や流量制御をこの層に寄せることで、バックエンドは本来の処理に集中できます。SAA-C03では、サーバーレス構成やマイクロサービスの前段として頻出します。

用語のキホン：APIとスロットリング

APIとは、プログラム同士がやり取りするための決められた呼び出し口のことで、ウェブの世界ではHTTPのリクエストとレスポンスとして表現されるのが一般的です。多数のクライアントが同時に呼び出すと、背後のシステムが処理しきれず全体が停止するおそれがあります。これを防ぐのがスロットリングで、一定時間あたりの呼び出し回数に上限を設け、超えた分は制限を示すエラーを返す仕組みです。API Gatewayでは、全体、利用者ごと、メソッドごとといった単位で上限を設定でき、平常時の毎秒レートに加えて瞬間的な集中を吸収するバーストの枠も指定できます。利用者ごとに枠を割り当てる場合は、APIキーと使用量プランを組み合わせます。

3つのAPIタイプとキャッシュ・統合

API Gatewayには、機能が豊富なREST API、機能を絞って安価かつ低遅延にしたHTTP API、サーバーからも送信できる双方向通信のWebSocket APIがあります。REST APIでは、同じ問い合わせへの応答を一定時間ためておくキャッシュを有効にでき、バックエンドの負荷と応答時間を減らせます。バックエンドとの接続方法は統合と呼ばれ、Lambda統合のほかHTTPエンドポイントやAWSサービスを直接呼ぶ形も選べます。アクセス制御には、IAM、Cognito、Lambdaで独自判定を行うLambdaオーソライザーが使えます。

WorkSpacesは、1ユーザーに1台の専用デスクトップを割り当てる形態のサービスです。管理者はマネジメントコンソールから数分でデスクトップを作成でき、退職時にはまとめて削除できます。

用語のキホン：仮想デスクトップ（VDI）

VDI（Virtual Desktop Infrastructure、仮想デスクトップ基盤）とは、デスクトップOSをデータセンター側のサーバー上で動かし、利用者の手元には画面の映像と、キーボードやマウスの操作情報だけをやり取りする仕組みです。アプリケーションの実行もファイルの保存もすべてサーバー側で行われるため、手元の端末は表示と入力を担うシンクライアント（処理能力を持たない軽量な端末）として機能します。この構造により、端末を紛失しても業務データが漏れず、OSのパッチ適用やソフトウェア配布も中央で一括して行えます。一方で、画面転送はネットワークの遅延に影響されやすく、利用者と接続先リージョンの距離が体感速度を左右します。

設計上の判断ポイント

WorkSpacesはVPC内に配置され、通常はDirectory Service（AWS Managed Microsoft ADやAD Connector）と連携してオンプレミスのActive Directoryのアカウントで認証します。オンプレミスのファイルサーバーや業務システムへ接続する構成では、Direct ConnectやVPNとの併用が前提になります。料金は月額課金と時間課金を選べるため、常時利用者は月額、たまに使う利用者は時間課金というように利用実態に合わせた選択が費用最適化の要点です。

Amplifyは、フロントエンド向けのライブラリと、ホスティングや配信を担うサービスを組み合わせたものです。裏側ではCognitoやAppSync、S3、CloudFrontといった既存のサービスが動いており、それらの設定を簡略化して提供する位置づけです。

用語のキホン：フロントエンドとバックエンド、ホスティング

フロントエンドとは、ブラウザやスマートフォン上で利用者が直接触れる部分、バックエンドとはサーバー側でデータを保存したり処理したりする部分を指します。作成したフロントエンドのファイルをインターネット上に置いて配信することをホスティングと呼びます。Amplifyでは、GitHubなどのリポジトリと接続しておくと、ブランチへの変更をきっかけにビルドと公開までが自動で走ります。この、変更を自動で反映していく流れがCI・CDの考え方にあたります。ブランチごとに公開先を分けられるため、本番と検証を並行して確認することもできます。

S3の静的ホスティングとの違い

単純に静的ファイルを置くだけならS3とCloudFrontの組み合わせでも実現できます。Amplifyの利点は、ビルドの実行、環境ごとの分離、認証やAPIといったバックエンドの用意までを一続きの流れで扱える点にあります。逆に、構成を細かく制御したい場合や既存の配信基盤がある場合は、個別のサービスを組み合わせるほうが柔軟です。

AppStream 2.0では、管理者がアプリケーションを組み込んだイメージを作成し、それを実行するフリート（実行環境の集まり）を用意します。利用者がアクセスすると、フリートからセッションが割り当てられ、アプリの画面だけが手元に届きます。

用語のキホン：アプリケーションストリーミング

アプリケーションストリーミングとは、ソフトウェアを利用者の端末にインストールせず、サーバー側で実行した結果の画面だけを配信する方式です。VDIがOSごと1人に割り当てるのに対し、こちらはアプリ単位で、しかもセッションが終われば実行環境は破棄される非永続（ノンパーシステント）な使い捨てが基本です。利用者ごとのファイルはホームフォルダとしてS3に保存され、次回のセッションで再び読み込まれます。この使い捨て構造のおかげで、環境の汚れが蓄積せず、常に同じ状態のアプリを提供できます。

WorkSpacesとの違いと使い分け

WorkSpacesは「1人1台の常設デスクトップ」であり、利用者が自分でファイルを置き、設定を変え、長期的に使い続ける前提です。AppStream 2.0は「必要なときだけ立ち上がるアプリ配信」であり、不特定多数や短期間の利用に強みがあります。SAP-C02の観点では、業務全体をクラウド側に移すならWorkSpaces、CADや解析ソフトなど特定の重いアプリだけを配信したい、または社外の受講者や顧客に一時的に使わせたいならAppStream 2.0、と切り分けます。

Pinpointでは、まず顧客の属性や行動を持つエンドポイントを登録し、そこから条件でセグメントを作ります。作成したセグメントに対してキャンペーンやジャーニーを組み、複数チャネルで配信します。

用語のキホン：セグメントとカスタマーエンゲージメント

セグメントとは、顧客を属性や行動で絞り込んだグループのことです。たとえば「過去30日にアプリを起動していない、かつ東京在住の利用者」といった条件で動的に切り出せます。ジャーニーは、そのセグメントに対して「メールを送る、開封しなければ3日後にプッシュ通知を送る」といった分岐付きの一連の流れを設計する機能です。配信後は開封率やクリック率といった指標が集計され、次の施策の判断材料になります。こうした一連の取り組みをカスタマーエンゲージメント（顧客との継続的な関係づくり）と呼びます。

SESとの違いと使い分け

SESはメールという1つのチャネルを、高い信頼性で大量に送るための配信基盤です。Pinpointは誰にいつ何を送るかを決める上位の仕組みであり、メール送信の実行部分は内部的にSESの基盤を使います。したがって、システムが自動的に出すトランザクションメール（注文確認やパスワード再設定など）はSESを直接呼び、販促やリテンション施策のように宛先の選定と効果測定が要るものはPinpointを使う、という切り分けが基本です。SMSやプッシュ通知を同じ施策で併用したい場合もPinpointが適しています。

モバイルアプリは、機種や画面サイズ、OSバージョンの違いによって表示崩れや不具合が出ることがあります。Device Farmは、AWSが用意した実機の端末群にアプリを配布してテストを走らせ、結果をログや動画、スクリーンショットとして返します。

用語のキホン：実機テストとデバイスフラグメンテーション

デバイスフラグメンテーションとは、市場に出回る端末の機種やOSバージョンが多岐にわたり、動作環境がばらついている状態を指します。特にAndroidでは組み合わせが非常に多く、すべてを自社で保有して検証するのは現実的ではありません。パソコン上で端末を模擬するエミュレーターもありますが、カメラや通信状況、端末固有の挙動までは再現しきれません。そこで、実際の端末を使う実機テストが必要になり、その端末群をクラウドから時間貸しで利用できるようにしたのがDevice Farmです。

2つの利用モードと自動化

あらかじめ書いたテストコードを多数の端末で一斉に走らせる自動テストと、ブラウザ越しに遠隔の実機を直接操作するリモートアクセスの2通りの使い方があります。自動テストはAppiumなどの一般的なテストフレームワークに対応しており、ビルドの流れに組み込んで変更のたびに実行することもできます。テスト結果は端末ごとに一覧化されるため、特定の機種でのみ発生する問題を切り分けやすくなります。

SESはSMTPまたはAPIで呼び出して利用し、送信結果の統計や、受信側での開封・不達の情報を取得できます。受信機能もあり、届いたメールをS3に保存したりLambdaで処理したりできます。

用語のキホン：メール配信と到達性

到達性（デリバラビリティ）とは、送ったメールが迷惑メールフォルダに落ちず受信箱に届く度合いのことです。受信側のメールサーバーは、送信元が本物かをSPF（送信元IPアドレスを事前に宣言しておく仕組み）やDKIM（メールに電子署名を付けて改ざんと詐称を防ぐ仕組み）、DMARC（SPFとDKIMの検証結果をもとに扱い方を宣言する仕組み）で検証します。加えて、宛先が存在しないバウンスや、受信者が迷惑メール報告する苦情の割合が高いと、送信元の評価が下がり届かなくなります。そのためSESでは、これらの通知を必ず受け取って対象アドレスへの送信を止める運用が求められます。またSESは初期状態では検証済みアドレス宛にしか送れないサンドボックス状態であり、本番利用には解除申請が必要です。

SNSとの違いと使い分け

Amazon SNSもメールを送れますが、こちらはトピックを購読したエンドポイントへ通知を配るPub・Sub（発行と購読）の仕組みであり、システム間連携や運用アラートが主な用途です。SNSのメールは差出人や本文の見た目を細かく作り込めず、購読の確認手続きも必要なので、顧客向けの正式なメールには向きません。SAP-C02では、大量の顧客宛メールや独自ドメインでの送信が要件ならSES、CloudWatchアラームからの運用通知やファンアウトならSNSと判断します。

RekognitionやComprehendのような既製のAIサービスは、あらかじめ決められた仕事しかできません。自社独自のデータでモデルを作りたいときに使うのがSageMaker AIです。

用語のキホン：学習と推論

機械学習は大きく二段階に分かれます。学習（トレーニング）は、大量の過去データを読み込ませて、入力と正解の関係をモデルに覚えさせる工程です。例えば「顧客の属性」と「解約したかどうか」の組を何万件も与えると、モデルは解約しやすい傾向を数値のパターンとして獲得します。もう一つの推論（インference という意味の推論）は、学習済みモデルに新しいデータを入れて答えを出させる工程です。SageMaker AIでは、学習は必要な時だけ計算資源を借りて行い、推論はエンドポイント（予測を返すAPIの窓口）を立てて常時提供する、という分け方が基本になります。この二段階の区別は、コスト設計を考えるうえでも重要です。

構成要素と運用の流れ

ノートブック環境でデータを試行錯誤し、学習ジョブを実行し、できたモデルをエンドポイントに配置する、という流れになります。まとめて大量のデータを予測したい場合は、常時稼働のエンドポイントではなくバッチ変換という一括処理を使うほうが安上がりです。利用頻度が読めない用途には、リクエストが来たときだけ動くサーバーレス推論という選択肢もあります。

画像認識モデルを一から作るには大量の学習データと専門知識が必要です。Rekognitionは、その学習をAWSが済ませた状態で提供する既製サービスです。

用語のキホン：画像認識と推論

画像認識とは、画像という数値の集まり（画素の並び）から、人間が意味を感じ取れる情報を取り出す処理のことです。Rekognitionに画像ファイルを渡すと、推論（学習済みモデルによる判定）が行われ、結果がJSONで返ってきます。返却内容には必ず信頼度スコアが付きます。これは「犬である確率」のようなモデルの確信度を示す数値で、アプリケーション側で「一定以上なら自動処理、それ未満は人が確認」といった閾値設計をするために使います。この「入力は画像、出力はラベルとスコア」という形は、AI系サービスに共通する考え方です。

主な機能と使い分け

物体やシーンの検出、顔検出と顔の比較、有名人の認識、不適切表現の検出、動画内での人物追跡などが用意されています。画像内の文字を少量読み取る機能もありますが、帳票やPDFから構造化された情報を抜き出したい場合はTextractのほうが適します。自社固有の物体を判定したい場合は、カスタムラベル機能や、SageMaker AIによる独自モデルを検討します。

問い合わせメールやレビュー投稿が毎日数千件届く状況では、人手ですべてを読むことはできません。Comprehendは、テキストを機械的に仕分けるための道具です。

用語のキホン：自然言語処理と固有表現抽出

自然言語処理とは、人間が普段使う文章をコンピューターが扱えるように解析する技術分野のことです。Comprehendに文章を渡すと、複数の観点で分析結果が返ります。代表的なものが感情分析で、文章全体が肯定的か否定的か中立か混在かを、それぞれの確信度とともに返します。もう一つが固有表現抽出（エンティティ抽出）で、文中から人名、組織名、日付、金額といった意味のあるかたまりを見つけ、その種類を判定します。ほかにキーフレーズの抽出や、複数の文書に共通する話題を教師データなしで見つけるトピックモデリングもあります。

個人情報の検出と関連サービス

文中の個人情報を検出してマスキングする機能があり、ログや問い合わせ内容を分析基盤に流す前の匿名化に使えます。医療文書に特化した派生サービスもあります。音声を分析したい場合は、Transcribeで文字起こししてからComprehendに渡す、という組み合わせが定番です。

従来の文字読み取りソフトは、文字は読めても「どれが項目名でどれが値か」までは分かりませんでした。Textractは、この関係まで含めて取り出します。

用語のキホン：OCRと構造抽出

OCR（Optical Character Recognition、光学文字認識）とは、画像に写った文字を、コンピューターが扱える文字データに変換する技術のことです。ただしOCRの結果はただの文字の羅列で、書類としての意味は失われます。Textractは、OCRに加えてフォーム抽出とテーブル抽出を行います。フォーム抽出では「請求金額」というラベルと、その隣に書かれた値をキーと値の組として返します。テーブル抽出では、罫線のある表を行と列の構造のまま取り出します。結果には座標と信頼度スコアが付くため、確信度が低い箇所だけ人が確認する運用が組めます。

Rekognitionとの使い分け

Rekognitionの文字検出は、看板や商品パッケージなど写真の中の短い文字を拾う用途に向いています。一方、請求書や申込書のように書式が決まった書類から情報を項目単位で取り出したい場合はTextractを選びます。SAA-C03では「紙の申込書の入力作業を自動化したい」という要件に対する解として登場します。

会議やコールセンターの音声は、そのままでは検索も分析もできません。Transcribeは、音声を分析可能なテキストに変える入口の役割を果たします。

用語のキホン：音声認識とタイムスタンプ

音声認識とは、空気の振動を記録した音の波形データから、どの言葉が話されたかを推定する処理です。Transcribeに音声ファイルを渡すと、書き起こしテキストに加えて、単語ごとのタイムスタンプ（何秒目に話されたか）と信頼度スコアが返ります。タイムスタンプがあるおかげで、動画の字幕を自動生成したり、検索した単語の再生位置へジャンプさせたりできます。話者分離（ダイアライゼーション）を有効にすると、複数人の会話を「話者1」「話者2」に振り分けて出力します。業界特有の用語がうまく認識されない場合は、カスタム語彙として単語リストを登録して精度を上げられます。

他のサービスとの連携

Transcribeは音声をテキストにする入口、Translateはテキストを別言語に変える中継、Pollyはテキストを音声に戻す出口です。この三つをつなぐと、外国語音声を自国語音声に変換する流れが作れます。Transcribeの出力をComprehendに渡せば、通話内容の感情分析も可能になります。

多言語対応のサイトやアプリでは、翻訳を都度人手で用意するのは負担が大きくなります。Translateは、この作業をAPI呼び出しで自動化します。

用語のキホン：ニューラル機械翻訳

ニューラル機械翻訳とは、単語を一つずつ置き換えるのではなく、文全体の意味を数値の表現として捉えたうえで、対象言語の自然な文を生成する翻訳方式です。この方式により、語順の異なる言語間でも文脈に沿った訳が得られやすくなります。Translateは入力テキストと訳したい言語コードを受け取り、翻訳済みテキストを返します。入力言語を指定せず自動検出させることも可能です。ただし機械翻訳は完璧ではないため、契約書のように誤訳が重大な影響を持つ用途では人の確認を前提とします。

訳語の制御と連携

自社製品名やブランド名が意図しない訳になる場合、カスタム用語集に「この語はこう訳す」という対応表を登録して制御できます。実務では、Transcribeで音声を文字にし、Translateで訳し、Pollyで読み上げるという多言語配信の構成や、S3に置いた大量文書を一括翻訳するバッチ処理がよく使われます。

読み上げ音声を人が録音すると、文言を直すたびに録り直しが必要になります。Pollyは、テキストを変えるだけで音声を作り直せる仕組みを提供します。

用語のキホン：音声合成とSSML

音声合成（Text-to-Speech）とは、文字データから人の声に近い音の波形を生成する技術です。Pollyでは声の種類をボイスとして選び、より自然な発話を目指したニューラル音声も利用できます。読み方を細かく制御したい場合はSSML（音声合成用のマークアップ言語）を使い、タグで「ここで少し間を置く」「この語はゆっくり読む」「これは数字ではなく年号として読む」といった指示を与えられます。日本語では固有名詞の読み間違いが起きやすいため、SSMLで読み仮名を指定する使い方が実務では重要になります。

出力形式と利用パターン

出力はMP3などの音声形式で受け取れ、S3に保存して配信できます。長文をまとめて音声化する非同期の合成タスクも用意されています。TranscribeとTranslateと組み合わせれば、音声から音声への多言語変換が構成できます。

問い合わせ対応を自動化するには、単に文字を認識するだけでなく、意図をくみ取って会話を進める必要があります。Lexはその会話の骨組みを提供します。

用語のキホン：インテントとスロット

インテントとは、利用者が達成したい目的のことです。「ホテルを予約したい」がインテントにあたり、開発者は「泊まりたい」「部屋を取って」といった言い回しの例を登録しておきます。スロットは、その目的を果たすために必要な情報の項目で、宿泊予約なら日付、人数、都市が該当します。利用者の発話に足りない項目があると、Lexは自動で聞き返すプロンプトを出し、すべて揃った時点で処理を実行します。実際の予約処理はAWS Lambdaの関数として書き、Lexから呼び出す構成が一般的です。

関連サービスとの関係

Lexは内部で音声認識と自然言語理解の機能を持つため、電話音声からの応答も構成できます。Amazon Connectと組み合わせればコールセンターの自動応答となり、応答文をPollyで読み上げます。単に文章を分析したいだけならComprehend、社内文書を検索して答えを探したいならKendraが適します。

社内には規程集やマニュアルが散在しており、必要な情報にたどり着けないことがよくあります。Kendraは、自然な言葉での問いかけに答えを返す検索基盤です。

用語のキホン：意味検索とインデックス

従来の検索は、入力された語句が文書に含まれるかを照合するキーワード検索でした。Kendraが行う意味検索（セマンティック検索）は、質問文の意図を解釈し、表現が違っても内容的に合致する箇所を見つけます。「有給は何日もらえますか」と尋ねると、規程中の「年次有給休暇の付与日数」の記述を答えとして提示できます。検索を成り立たせるのがインデックスで、これは対象文書をあらかじめ読み込んで検索しやすい形に整理したデータベースです。外部のデータ置き場をインデックスへ取り込む仕組みがコネクタで、S3や社内のファイル共有、各種SaaSに対応しています。

アクセス制御と使い分け

元の文書に設定された権限を検索結果にも反映でき、閲覧権限のない文書が結果に出ないよう制御できます。全文検索基盤を自前で細かく作り込みたい場合はAmazon OpenSearch Serviceが選択肢になりますが、社内文書に対する自然文の質問応答を短期間で用意したいならKendraが適します。

おすすめ機能を自前で作ろうとすると、アルゴリズムの選定、学習、評価、運用と多くの工程が必要です。Personalizeは、Amazon自身が長年培ってきたレコメンド技術を、データを渡すだけで使える形にしたサービスです。

用語のキホン：レコメンデーションの学習の流れ

まず3種類のデータを用意します。インタラクションデータ（誰がいつ何を閲覧・購入したかの履歴）が中核で、これにアイテムデータ（商品のカテゴリや価格などの属性）とユーザーデータ（年齢層や地域などの属性）を補助として加えます。次にレシピと呼ばれる用途別のアルゴリズムを選びます。関連商品を出す、利用者ごとの一覧を出す、検索結果を並べ替える、といった目的ごとに用意されています。学習して作られたモデルをキャンペーンとして公開すると、アプリからAPI経由でリアルタイムに推薦結果を取得できます。

運用上のポイント

閲覧やクリックといった最新の行動をイベントトラッカーで送り続けると、その場のふるまいを反映した推薦に近づきます。データがまだ少ない新規商品や新規利用者への推薦精度が下がる問題はコールドスタートと呼ばれ、属性データを充実させることで緩和します。IoTとの直接の関係はありませんが、AIサービス群の一つとしてSAP-C02の設計問題に登場します。

利用者は過去の取引履歴に「不正だったか否か」のラベルを付けてアップロードし、目的に合ったモデルタイプを選んで学習させます。学習後はAPIを呼び出すだけで、1件ごとにリスクスコアと推奨アクションが返ります。

用語のキホン：不正検知とリスクスコアリング

不正検知とは、大量の正常な取引に紛れたごくわずかな不正を見つけ出す処理です。不正はデータ全体のごく一部しかないため、単純な機械学習では「すべて正常」と判定しても正解率が高く見えてしまう不均衡データの問題を抱えます。そこでこの分野では、正しく不正を捕まえられた割合と、正常な取引を誤って止めてしまった割合の両方を見て調整します。Fraud Detectorは判定結果を0から1000のようなリスクスコアとして返し、利用者は「スコアが高ければ拒否、中程度なら人による確認、低ければ承認」といったルールを自分で定義します。この、モデルの出力とビジネスルールを分けて組み合わせられる点が実務上の要点です。

他の選択肢との使い分け

SageMakerを使えば同じことをより自由に実装できますが、データの前処理やモデルの選定、推論基盤の運用まで自前で担う必要があります。Fraud Detectorはユースケースを不正検知に絞ることで、AWSが長年蓄積した不正パターンの知見をあらかじめモデルに組み込んでおり、少ない学習データでも実用的な精度が得られます。SAP-C02の観点では、機械学習の専任者がいない前提で不正対策を短期間に導入したい要件であればこちらを選びます。

映像は容量が大きく、途切れなく届き続けるという扱いにくさがあります。Kinesis Video Streamsは、その受け口と保存、取り出しの仕組みをマネージドサービスとして提供し、映像を利用するアプリケーション側の負担を減らします。

用語のキホン：ストリーミングデータと時系列インデックス

ストリーミングデータとは、終わりを決めずに連続して届き続けるデータのことです。映像はその代表例で、ファイルとして完結する前から順次処理していく必要があります。Kinesis Video Streamsでは、機器ごとにストリームという受け口を作り、届いた映像に時刻を紐づけて時系列インデックスとして管理します。これにより「何月何日の何時から何分間」という指定で過去の映像を取り出せます。保存期間はストリームごとに設定でき、期間を過ぎたデータは自動的に消えます。取り出しには、リアルタイムに近い形で受け取る方法と、蓄積済みの区間を再生する方法があります。

Kinesis Data Streamsとの違い

名前が似ているKinesis Data Streamsは、ログやイベントといった比較的小さなレコードを扱う汎用のストリーム基盤です。Kinesis Video Streamsは映像や音声など時刻の連続性が重要なメディアに特化しており、コーデックを意識した取り込みや再生用の取り出し方法が用意されています。取り込んだ映像を機械学習で解析する場合は、Rekognition Videoなどと組み合わせます。

撮影された動画は、そのままでは容量が大きかったり、端末によっては再生できない形式だったりします。Elastic Transcoderは、その変換処理をクラウド側で肩代わりするサービスです。なお、より新しく機能の豊富な変換サービスとしてAWS Elemental MediaConvertがあり、新規に構築する場合はそちらが選ばれることが増えています。

用語のキホン：トランスコードとコーデック、ビットレート

トランスコードとは、動画や音声を別の形式や品質へ変換することです。動画はコーデックという圧縮方式（H.264などが代表的）でデータ量を小さくして保存されており、再生側が対応していない方式だと見られません。1秒あたりのデータ量を表すビットレートを下げれば通信量は減りますが画質も落ちるため、視聴環境に応じた調整が必要です。回線速度に合わせて複数の画質を切り替えながら配信する方式をアダプティブビットレートストリーミングと呼び、これを実現するには、あらかじめ画質違いの複数バージョンを用意しておく必要があります。

処理の流れと関連サービス

Elastic Transcoderでは、入力元と出力先のS3バケットを指定したパイプラインを作り、変換内容を定めたプリセットを選んでジョブを投入します。処理の完了はSNSで通知でき、後続の処理につなげられます。変換後のファイルをCloudFrontから配信すれば、視聴者の近くから届けられて再生が安定します。

IoTの世界では、工場の温度センサー、車載機器、家庭の家電といった多種多様な機器がネットワークにつながります。これらは常時接続とは限らず、電波が弱かったり電源が落ちたりします。AWS IoT Coreは、そうした不安定な環境でも機器とクラウドが確実に会話できるようにする仕組みを提供します。

用語のキホン：IoTを支える5つの概念

まずデバイス（モノ／Thing）とは、AWSに接続されるセンサーや機器そのもの、およびAWS側にその機器を表すために登録された識別情報のことです。次にMQTTは、IoTで広く使われる通信の決まりごと（プロトコル）で、通信量が非常に少なく、電池駆動や細い回線の機器に向いています。MQTTではトピックという「宛先を表す文字列」（例：factory/line1/temperature）にデータを送り、そのトピックを購読している相手が受け取る、という発行・購読型のやり取りをします。デバイスシャドウは、機器の状態（例：エアコンの設定温度）をクラウド側に写し取ったJSONデータで、機器がオフラインの間も最新の希望状態を保持し、再接続時に同期できます。最後にルールエンジンは、届いたメッセージをSQLに似た文法で絞り込み、DynamoDBやKinesis、Lambdaなど他のAWSサービスへ自動的に転送する仕組みです。

セキュリティと試験ポイント

IoT Coreでは機器ごとにX.509証明書（機器の身分証明書にあたる電子証明書）を発行し、それにIoTポリシーを結び付けて「どのトピックに発行・購読してよいか」を制御します。証明書を無効化すれば、その機器だけを即座に遮断できます。SAP-C02では、大量デバイスの接続方式、オフライン時の状態同期（シャドウ）、データの振り分け（ルールエンジン）という3点セットで問われることが多いです。

すべてのセンサーデータをクラウドへ送ると、通信コストと遅延が問題になります。また、工場のラインを止めるかどうかの判断を、クラウドとの往復を待って行うのは現実的ではありません。Greengrassはこの課題に対する答えです。

用語のキホン：エッジコンピューティング

エッジコンピューティングとは、データが発生する現場の近くで処理を行う考え方です。Greengrassでは現場のPCや産業用ゲートウェイにGreengrassコアというソフトウェアを入れ、その配下に周辺のセンサー群をぶら下げます。コアはローカルのメッセージブローカーとして働き、インターネットが切れている間もセンサー間の通信や処理を続け、回復後にクラウドへまとめて送信します。デプロイするプログラムはコンポーネントという単位で管理され、クラウド側から遠隔で配布・更新できます。

IoT Coreとの使い分け

IoT Coreは「クラウド側の接続窓口」、Greengrassは「現場側の実行基盤」です。低遅延の制御、通信断への耐性、生データを外に出したくないという要件が出てきたらGreengrassを検討します。SageMakerで学習したモデルをGreengrassへ配布し、現場で推論だけ行う構成もよく問われます。

デバイスが10台なら手作業でも回りますが、10万台になると台帳管理も更新作業も破綻します。Device Managementは、その運用面の負担を引き受けるサービスです。IoT Coreに接続された機器を対象に、ライフサイクル全体を面倒見ます。

用語のキホン：ジョブとフリートインデックス

ジョブとは、多数のデバイスに対して「このファームウェアに更新せよ」「再起動せよ」といった指示をまとめて送る仕組みです。一度に全台へ配るのではなく、段階的に対象を広げる段階的ロールアウトや、失敗率が一定を超えたら自動で中止する中断条件を設定でき、不具合の全台波及を防げます。フリートインデックス作成は、デバイスの属性や接続状態、シャドウの中身を検索可能にする機能で、「ファームウェアが古く、かつ現在オフラインの機器」といった条件で絞り込めます。モノのグループを階層構造で作れば、拠点や機種ごとにまとめて操作や権限付与ができます。

大量登録と試験ポイント

工場出荷時に一括で機器を登録する一括登録や、初回接続時に自動で証明書とポリシーを割り当てるフリートプロビジョニングも含まれます。SAP-C02では「多数デバイスの安全なOTA更新」という要件でDevice Managementのジョブが正解になる場面が典型です。

IoTデバイスは屋外や第三者の敷地に置かれることも多く、物理的に盗まれたり改造されたりする危険があります。乗っ取られた機器が攻撃の踏み台にされる事例もあります。Device Defenderは、そうした異常を早期に見つけるために使います。

用語のキホン：監査と検出

機能は大きく2つです。監査は、設定面のチェックで、有効期限切れの証明書、複数デバイスで使い回されている証明書、すべての操作を許可するような過度に緩いIoTポリシーなどを、定期または随時に洗い出します。もう一方の検出は、実際のふるまいの監視で、あらかじめ「1時間あたりのメッセージ数」「接続先ポート」「送信バイト数」といった正常範囲をセキュリティプロファイルとして定義し、そこから外れた機器を通知します。統計から自動で正常範囲を割り出す機械学習による検出も利用できます。

他サービスとの連携

検知結果はSNSやEventBridgeへ送れるため、Lambdaを起動して該当証明書を自動的に無効化する、といった自動対処が組めます。Security HubやGuardDutyがAWSアカウント全体を守るのに対し、Device Defenderはデバイス側に特化している点が違いです。

「温度が80度を超えた」だけなら単純な条件判定で済みますが、実務では「温度が80度を超えた状態が10分続き、かつ振動も基準超なら故障とみなす」といった複合的な判断が必要になります。IoT Eventsはこの種の判断を担当します。

用語のキホン：ステートマシンによる状態管理

IoT Eventsの中心にあるのはディテクターモデルという定義で、これはステートマシン（状態遷移機械）の一種です。ステートマシンとは「正常」「警戒」「異常」といった状態を定義し、どの入力が来たらどの状態へ移るかを表現したものを指します。設備1台ごとにディテクターという実体が作られ、それぞれ独立して現在の状態を保持します。状態の移り変わりや一定時間の経過を条件にできるため、瞬間的なノイズによる誤検知を避けられます。

ルールエンジンとの使い分け

IoT Coreのルールエンジンは「届いたメッセージ1件を条件で振り分けて転送する」ステートレスな仕組みです。対してIoT Eventsは前の状態を覚えており、時間軸をまたいだ判断ができます。継続時間や複数センサーの組み合わせが要件に出てきたらIoT Eventsを選びます。

工場の機械は、AWSに直接つながる前提で作られていないものがほとんどです。多くは工場内の制御システムと独自の産業用プロトコルで通信しています。SiteWiseはこの現場データをクラウドに取り込み、経営や保全に使える形へ整えます。

用語のキホン：アセットモデルと産業用プロトコル

アセットとは、ポンプやモーターといった個々の設備を表すデータ上の単位です。アセットモデルはその設計図で、「この種類の設備は温度と回転数と稼働時間という測定値を持つ」と定義します。設備は「工場、ライン、機械」のように階層で構成でき、上位で合計値や平均値を自動集計できます。データ収集にはSiteWise Edgeというゲートウェイを現場に置き、OPC UA（産業機器で標準的に使われる通信規格）などを介して機械から値を読み取ります。さらに変換やメトリクスという数式を定義すれば、設備総合効率のような指標をクラウド側で自動計算できます。

可視化と使い分け

SiteWise Monitorという機能で、コードを書かずに現場向けダッシュボードを作れます。汎用の時系列データ処理はTimestreamやKinesisでも可能ですが、産業設備の階層モデルと計算指標が要件に含まれる場合はSiteWiseが適します。

IoTの現場では、カメラはA社、センサーはB社、照明はC社というように機器がばらばらで、それぞれ操作方法が異なります。この差異を毎回プログラムで吸収するのは大きな負担でした。Things Graphはその抽象化を狙ったサービスです。

用語のキホン：モデルによる抽象化とワークフロー

Things Graphでは、まず「カメラとは画像を撮影できるもの」というデバイスモデルを定義し、実際のA社カメラをそのモデルに当てはめます。こうしておくと、上位のロジックは機器の型番を意識せずに「カメラで撮る」と書けます。そのうえでワークフロー（フロー）として、複数の機器やAWSサービスを線でつなぎ、順序と条件を指定した連携動作を組み立てます。作ったフローはクラウド上でも、Greengrassを介して現場側でも実行できました。

現在の位置付けと代替

このサービスは新規のお客様への提供が終了しているため、新しい設計で選択することはありません。同様の連携要件は、IoT Coreのルールエンジンに加えてStep FunctionsやLambda、EventBridgeを組み合わせて実現するのが現在の一般的な方法です。試験では「用語として何を指すか」を知っていれば十分です。

IoTを始めるときの最大の壁は、デバイス側の通信実装とセキュリティ設定です。IoT 1-Clickは、あらかじめ通信機能と証明書が組み込まれた既製のボタンを使うことで、この壁を丸ごと省く発想のサービスでした。

用語のキホン：シンプルなイベントトリガー

利用者は、あらかじめ認定されたボタンデバイスを用意し、スマートフォンアプリでWi-Fiや回線設定を済ませます。あとはAWS側でプロジェクトとプレイスメント（どのボタンがどの場所に置かれているかの割り当て）を定義し、押下時に呼び出すLambda関数を指定するだけです。ボタンは1回押し、2回押し、長押しを区別でき、Lambdaへはその種類と設置場所の情報が渡されます。開発者はデバイス側のコードを一切書きません。

設計上の考え方

このサービスが示しているのは「物理的な単発イベントをクラウドの処理へ直結させる」という設計パターンです。現在同じことをしたい場合は、IoT Coreに接続した機器のメッセージをルールエンジン経由でLambdaへ渡す構成が標準的です。SAP-C02の観点では、単純なイベント通知に重厚なIoT基盤を作り込むのは過剰、という判断軸を押さえておくとよいでしょう。

参加する各組織はネットワークに自分のノード（台帳の写しを保持し処理に参加するサーバー）を持ち、投票によって新規参加者の受け入れを決めます。パブリックなブロックチェーンへのアクセスを提供する機能も備えます。

用語のキホン：分散台帳と信頼の共有

分散台帳とは、同じ取引記録の写しを複数の参加者がそれぞれ保持し、記録を追加するときには参加者間で合意を取る仕組みです。記録は前の記録のハッシュ値（内容から計算される固定長の値）を含む形で鎖状につながるため、途中の1件を書き換えると以降すべてが矛盾し、改ざんがすぐに露見します。ここで重要なのは、この仕組みが解決する課題が「互いを完全には信頼していない複数組織が、中央の管理者を置かずに同じ事実を共有する」ことだという点です。逆に言えば、単一の企業が自社内のデータを守りたいだけなら、この複雑さは不要です。

QLDBとの違いと試験での判断

かつて提供されていたAmazon QLDBは、単一の所有者が持つ台帳の変更履歴を暗号的に検証可能な形で残すサービスで、参加者間の合意という要素はありませんでした。SAP-C02のシナリオでは、「複数の独立した企業が対等な立場で同じ記録を共有し、中央管理者を置きたくない」という記述があればManaged Blockchain、単に監査証跡や履歴の完全性を保ちたいだけならS3のオブジェクトロックやCloudTrailのログファイル検証といった、より単純な手段を選ぶのが定石です。