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と組み合わせるのが定番構成です。

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と組み合わせると、増えた台数へ自動で振り分け、落ちた台数を自動で切り離せます。

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

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

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

実行の仕組み

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

関連する仕組み

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

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

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

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

コスト最適化との相性

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

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

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

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

どんなときに選ぶか

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

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

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

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

似た選択肢との切り分け

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

Lambda関数とその周辺リソース（API Gateway、DynamoDBなど）をまとめた構成を「アプリケーション」として登録し、公開または組織内限定で共有できます。

用語のキホン：AWS SAMとテンプレートの再利用

AWS SAMとは、サーバーレス構成を短い記述で定義できるCloudFormationの拡張です。Serverless Application Repositoryには、このSAMテンプレートとコードがセットで登録されています。利用者は中身を読んだうえでパラメータを入力し、自分のアカウントへ展開できます。公開範囲は、全世界に公開・特定アカウントにのみ共有・非公開の3種類から選べるため、社内標準部品の配布先としても使えます。

使いどころ

「S3にファイルが置かれたらウイルススキャンする」といったよくある処理は、ゼロから書かずに既存のアプリケーションを取り込むほうが速く確実です。社内では、共通のログ転送処理などを部品化して各チームへ配る使い方が有効です。

AWSのハードウェア上にVMwareの仮想化基盤（vSphere、vSAN、NSX）が構築され、オンプレミスと同じ管理ツールで運用できます。

用語のキホン：リロケートという移行方針

移行の7つの方針のうち、仮想化基盤ごとそのまま移すやり方をリロケートと呼びます。EC2への移行（リホスト）では仮想マシンをEC2インスタンスに変換する必要がありますが、リロケートなら変換そのものが不要で、既存のVMをそのまま動かせます。そのため移行期間を最短にでき、運用チームの学習コストも小さく済みます。一方で、AWSネイティブの機能を活かしにくく、費用は割高になりがちです。

どんなときに選ぶか

「データセンターの契約期限が迫っていて、作り直す時間がない」という状況が典型です。まずリロケートで移し、その後ゆっくりAWSネイティブへ作り替えるという段階的な戦略が取れます。

通常、スマートフォンからクラウドへの通信は、基地局から事業者網を抜けてインターネットを経由します。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は機能が豊富な反面、学習コストと管理コストは高くなります。

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

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

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

トレードオフ

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

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は最も自由度が高い代わりに、構築と運用は完全に自己責任となります。

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

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

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

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

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

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と違い、複数台同時共有が最大の特長です。

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で暗号化されます。さらにボールトロックを有効にすると、管理者であっても保持期間内の削除ができなくなり、ランサムウェア対策や法令上の改ざん防止要件を満たせます。

コンプライアンス用途

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

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が手がかりになります。

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

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

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

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

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

バックアップと接続管理

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

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を選ぶ、と覚えるとよいです。

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をあらかじめ適切なサイズで動かすほうが素直で費用も読みやすくなります。世代によっては最小容量をゼロ近くまで下げて休止させられる設定もありますが、休止からの復帰にわずかな待ち時間が生じる点は考慮が必要です。

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のほうが機能の選択肢が広くなります。

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

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

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

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

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

業務システムのデータベースは「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 という選択肢もあります。

ファイルにまとめてから夜間に処理する方式では、異常検知や即時のレコメンドには間に合いません。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 への直近データ投入を併用する構成がよく取られます。

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

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

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

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

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

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 へ移行したい」という文脈で正解になります。

データを分析基盤に集めても、意思決定者が見られなければ活用されません。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は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へ集めたい」という文脈で候補になります。

クラウドは使った分だけ支払うのが基本ですが、長期間動かし続けるシステムでは、その柔軟さの分だけ単価が割高になります。Savings Plansは一定の利用を先に約束することで単価を下げる仕組みです。SAA-C03のコスト最適化分野では、リザーブドインスタンスやスポットインスタンスとの使い分けが定番の出題です。

用語のキホン：コミットメント割引

コミットメント割引とは、一定量の利用を前もって約束（コミット）する見返りに単価を下げてもらう考え方です。Savings Plansでは、台数や種類ではなく1時間あたりの支払額（ドル建て）を約束します。約束した額までは割引単価が適用され、それを超えた分は通常の従量課金になります。逆に使わなかった場合でも約束した額の支払いは発生するため、どこまで確実に使うかの見極めが重要です。支払い方法は全額前払い、一部前払い、前払いなしから選べ、前払いを多くするほど割引率が高くなります。

種類とリザーブドインスタンス・スポットとの使い分け

Compute Savings Plansは最も柔軟で、インスタンスの種類やリージョン、OSが変わっても、さらにFargateやLambdaの利用にも自動で適用されます。EC2 Instance Savings Plansは特定リージョンの特定インスタンスファミリーに限定される代わりに、割引率が高くなります。リザーブドインスタンス（RI）は同じくコミットメント割引ですが、容量の予約ができる点や、RDSなどEC2以外のサービスにも用意されている点が異なります。一方スポットインスタンスは約束をせず余剰リソースを大幅な割引で使う方式で、AWS側の都合で中断される可能性があるため、中断されても困らない処理に向きます。試験では「安定して使い続ける基盤はSavings PlansやRI、中断可能なバッチはスポット」と整理して考えます。

請求書の合計金額だけでは、費用が増えた原因はわかりません。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設計の土台になるため、パブリックとプライベートの分離は必ず理解しておきましょう。

NATゲートウェイは、外部から直接アクセスさせたくないプライベートサブネットのサーバーが、「外への通信」だけを行えるようにする出口です。中から外（更新やパッケージの取得など）は通しますが、外から中への接続は遮断するため、安全性を保てます。

用語のキホン：インバウンド・アウトバウンドとNAT

インバウンドは「外から中へ入ってくる通信」、アウトバウンドは「中から外へ出ていく通信」を指します。NATゲートウェイはアウトバウンドだけを通し、インバウンドは通しません。NAT（ネットワークアドレス変換）とは、外部と直接やり取りできないプライベートIPアドレスを、通信できるグローバルIPアドレスに付け替える仕組みのことです。

設計のポイント

マネージドで帯域は自動スケールし、パブリックサブネットに配置します。1つのAZに置くとそのAZ障害で通信できなくなるため、可用性重視なら各AZに配置します。自前EC2で作る「NATインスタンス」より運用が楽で高可用です。IPv6専用の類似機能として「Egress-Onlyインターネットゲートウェイ」があります。

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攻撃からの防御を強化できます。動的コンテンツの高速化にも利用されます。

オンプレミス環境とAWSを接続する方法には、インターネット経由のVPNと、専用線を使うDirect Connectの2つがあります。Direct Connectは通信事業者の物理回線を通じてAWSの接続拠点に直結するため、インターネットの混雑の影響を受けません。試験では「安定した帯域」「一貫した低遅延」というキーワードが出たらDirect Connectを想起します。

用語のキホン：専用線とVPN、そしてBGP

専用線とは、自社と接続先の間に確保された自分たち専用の通信回線のことです。他社の通信と混ざらないため速度や遅延が安定します。一方VPN（Virtual Private Network、仮想私設網）は、公衆のインターネット上に暗号化されたトンネルを作って私設網のように使う技術で、回線そのものは共有されます。専用線とAWSの間で経路情報をやり取りするために使われるのがBGP（Border Gateway Protocol）で、「どのネットワークがどちら側にあるか」を互いに広告し合い、通信の行き先を自動的に決める仕組みです。BGPを使うと回線が複数ある場合に経路を切り替える冗長構成が組めます。

仮想インターフェースと冗長化の考え方

Direct Connectの物理回線の上には仮想インターフェース（VIF）という論理的な通り道を作ります。VPC内のリソースにつなぐプライベートVIF、S3など公開エンドポイントにつなぐパブリックVIF、Direct Connect Gatewayを介して複数VPCにつなぐトランジットVIFがあります。物理回線は敷設に時間がかかり単体では障害時に代替がないため、試験では「Direct Connectを2本」または「Direct ConnectとSite-to-Site VPNの併用」が高可用性の定番解答になります。VPNをバックアップにする構成はコストを抑えつつ可用性を高める選択肢です。

通常、VPC内のEC2からS3やDynamoDBを呼び出すと、通信はインターネットゲートウェイやNATゲートウェイを通ってAWSの公開エンドポイントに向かいます。PrivateLinkを使うと、この通信をAWSの内部ネットワークだけで完結させられます。セキュリティ要件で「インターネットに出さない」と明記されている場合の定番解答です。

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

VPCエンドポイントには2種類あります。ゲートウェイ型エンドポイントは、ルートテーブルに「このサービス宛ての通信はエンドポイントへ」という経路を追加する方式で、対応するのはS3とDynamoDBだけです。IPアドレスを持たず、追加料金もかかりません。もう1つのインターフェース型エンドポイントは、指定したサブネットにENI（Elastic Network Interface、VPC内の仮想ネットワークカード）を作り、そのプライベートIPアドレス宛てに通信する方式です。こちらが本来のPrivateLinkで、多数のAWSサービスに加え、他アカウントが提供するサービスにも対応します。ENIにはセキュリティグループを適用できるため、アクセス制御を細かく設定できます。

使い分けと試験ポイント

S3とDynamoDBだけが対象で、同一リージョン内のVPCからのアクセスで足りるならゲートウェイ型が無料で簡単です。オンプレミスからDirect ConnectやVPN経由でアクセスさせたい場合や、S3以外のサービス、あるいはSaaS事業者が提供する独自サービスに接続したい場合はインターフェース型を選びます。ゲートウェイ型はルートテーブルに依存するためVPCの外からは利用できない、という点が両者を分ける判断基準になります。サービス提供側はNetwork Load Balancerの前段にエンドポイントサービスを作り、利用者側にPrivateLink経由で公開します。

VPC同士を直接つなぐVPCピアリングは手軽ですが、VPCが増えると接続数が急増し、ルートテーブルの管理が難しくなります。Transit Gatewayはこの問題を解決するための集約装置です。試験では「VPCが数十個」「拠点が多数」という記述があれば真っ先に候補になります。

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

すべての拠点が互いに直接つながる構成をフルメッシュと呼びます。拠点数がnのとき接続数はおよそn×(n-1)÷2に増えるため、拠点が増えると管理が破綻します。これに対し、中央のハブを1つ置いて各拠点はハブとだけつなぐ構成をハブアンドスポークと呼び、接続数は拠点数と同じで済みます。Transit Gatewayはこのハブにあたる存在です。各VPCや各VPN接続はTransit Gatewayにアタッチメントとして接続され、Transit Gateway側のルートテーブルがどのアタッチメント同士を通信させるかを決めます。なおVPCピアリングには推移的ルーティング（AとB、BとCがつながっていてもAとCは通信できない性質）の制約がありますが、Transit Gatewayはハブとして中継するためこの制約がありません。

セグメント分離という使いどころ

Transit Gatewayのルートテーブルを複数に分けることで、たとえば本番VPC群と開発VPC群を互いに通信できないよう分離しつつ、どちらも共通の共有サービスVPCとは通信できる、といった構成が作れます。単なる接続の集約だけでなく、ネットワークの区画整理の道具としても出題されます。1対1の少数接続で十分ならVPCピアリングの方が安価で単純です。

インターネット経由の通信は、経路が混雑していると遠回りになり遅延が増えます。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を併用して通信を暗号化する構成もあります。

接続の単位が「拠点まるごと」ではなく「利用者1人ずつ」である点が特徴です。利用者数に応じて自動的に規模が調整されるため、VPNサーバーを自前で構築・運用する必要がありません。

用語のキホン：クライアントVPNとサイト間VPNの違い

VPNには大きく2つの形があります。サイト間VPN（Site-to-Site VPN）は拠点のルーター同士をつなぐもので、拠点内のすべての端末が自動的にAWSと通信できるようになります。対してクライアントVPN（リモートアクセスVPN）は、個々の端末が自分でトンネルを張る方式で、端末ごとに認証が必要です。Client VPNはOpenVPNという広く使われるVPNの規格に対応したクライアントソフトから接続します。認証方式には、証明書を使う相互認証、Active Directoryのアカウントを使う方式、外部のIDプロバイダーを使うSAML連携（企業のシングルサインオン基盤と連携する標準規格）があり、接続後にどの宛先へアクセスできるかは認可ルールで制御します。

試験での選び方

問題文が「リモートワークの社員が個別に接続」「移動中のノートPCから」と述べていればClient VPN、「本社と支社をつなぐ」「拠点のネットワーク全体」であればSite-to-Site VPNです。なおサーバーの管理画面へ入るだけであれば、VPNを使わずSystems Manager Session Managerを使う方が安全かつ簡単な場合もあります。

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

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

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

ロールと一時認証

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

ポリシー評価と保護

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

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

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

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

NACLとの違い・使い分け

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

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」と分けて理解しましょう。

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

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

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

アラームと自動化

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

似たサービスとの違い

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

認証の仕組みを自作すると、パスワードの安全な保管や多要素認証など考慮すべき点が多く、脆弱性の温床になりがちです。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はアプリ利用者向け、と区別して覚えます。

証明書は有効期限があり、更新を忘れるとサイトが警告表示になって使えなくなります。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に適用する証明書は米国東部（バージニア北部）リージョンで発行する必要がある点も頻出です。

多くの企業はユーザーアカウントや端末を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が解答になります。

暗号化の安全性は、鍵をいかに守るかにかかっています。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の管理性を両立させる構成もあります。

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

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

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

似たサービスとの違い

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

アカウントが数十に増えると、各アカウントで個別に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が「何かおかしい」と教えてくれても、なぜそれが起きたのか、どこまで被害が及んだのかは別途調査が必要です。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報告書などは機密情報を含むため、取得時に守秘義務条項への同意が必要である点も特徴です。

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

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

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

Parameter Storeとの使い分け

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

AWS IAM Identity Centerは、組織で多数のAWSアカウントを運用する際の、利用者アクセス管理の標準的な入り口です。アカウントごとにIAMユーザーを作る運用をやめ、1人1つのIDで必要なアカウントに切り替えて入れるようにします。AWS Organizationsと組み合わせて使うのが一般的です。

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

シングルサインオン（SSO）とは、一度の認証で複数のシステムを利用できる仕組みです。システムごとにIDとパスワードを持つと、使い回しや管理漏れが起きやすく、退職者のアカウントが残る事故にもつながります。これを解決するのがIDフェデレーションで、社内のID基盤など信頼できる認証元で本人確認を行い、その結果を各システムが受け取って一時的な権限を発行する考え方です。AWSではこのとき一時的な認証情報（有効期限つきのアクセスキー）が発行されるため、長期間有効なアクセスキーを配布せずに済みます。IAM Identity Centerは、自前のIDストアを持つこともできますし、Active DirectoryやSAMLに対応した外部IDプロバイダーと連携することもできます。

権限セットと試験ポイント

付与する権限は権限セットという単位で定義し、「どのユーザーグループが、どのアカウントで、どの権限セットを使えるか」を割り当てます。割り当てが行われると、対象アカウント側に対応するIAMロールが自動で作られる仕組みです。試験では「多数のアカウントに対する利用者アクセスを、既存の社内ディレクトリと連携して一元管理したい」という要件で選ばれます。アプリケーションの利用者、つまり一般消費者向けのサインアップやログインが要件ならAmazon Cognitoが正解になる点と混同しないよう注意してください。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

仕組みと試験ポイント

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

企業では、部門ごと・環境ごとにAWSアカウントを分けるのが一般的です。アカウントを分けると影響範囲を隔離できますが、数が増えると管理が煩雑になります。Organizationsはその管理を一元化します。

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

OU（Organizational Unit、組織単位）とは、アカウントをグループ化するための入れ物で、フォルダのように階層構造を作れます。SCP（Service Control Policy、サービスコントロールポリシー）は、OUやアカウントに対して「これ以上のことはできない」という上限を定めるポリシーです。ここで重要なのは、SCPは権限を与えるものではなく、あくまで許可の上限を絞るものだという点です。実際に操作できるかどうかは、SCPの上限とIAMポリシーの許可の両方を満たすかで決まります。ガードレールとは、利用者の自由をある程度残しつつ、危険な操作だけを組織的に禁止する考え方を指す言葉です。

一括請求と試験ポイント

一括請求（Consolidated Billing）により、組織内の全アカウントの利用料をまとめて支払えます。使用量が合算されるため、ボリューム割引やリザーブドインスタンスの割引を組織全体で共有しやすくなります。試験では「全アカウントで特定リージョン以外の利用を禁止したい」といった要件はSCP、「アカウントごとの権限設定」はIAMと切り分けて考えます。

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

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

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

CloudWatch・Configとの役割の違い

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

「暗号化されていない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が適切です。

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とは異なり、こちらは人が設問に答える定性的なレビューである点が違いです。

OrganizationsやConfig、CloudTrail、IAM Identity Centerを自分で組み合わせてマルチアカウント基盤を作ることもできますが、設計と構築には相応の手間がかかります。Control Towerはその一式をAWSの推奨構成で自動的に用意します。

用語のキホン：ランディングゾーン・コントロール・アカウントファクトリー

ランディングゾーンとは、統制の効いたマルチアカウント環境の初期構成一式のことです。Control Towerはこれを自動生成し、ログ保管用アカウントと監査用アカウントを分離して作成します。コントロール（旧称ガードレール）は適用するルールのことで、必ず適用される必須、推奨される強く推奨、任意の選択的に分類されます。動作の観点では、違反操作をそもそも実行させない予防的コントロール（SCPで実現）と、違反を後から検知して報告する発見的コントロール（Configルールで実現）に分かれます。アカウントファクトリーは、統制済みの新規アカウントをテンプレートから払い出す機能です。

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

Control TowerはOrganizationsの代替ではなく、その上に構築されるオーケストレーション層です。細かく自分で設計したい場合はOrganizationsを直接使い、素早く推奨構成を立ち上げたい場合はControl Towerを選びます。

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

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

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

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

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

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

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

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

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

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

アプリケーションは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では、可用性優先・コスト優先などの方針を選ぶだけで推奨設定を生成することもできます。

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向けの監視資産を活かしたい場合にこちらが選ばれます。

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へ記録されます。

データベースの引っ越しは、業務を止められないという点が最大の難所です。DMSは、稼働中のデータベースからデータを読み出しながら、移行先へ書き込み続ける仕組みを提供します。

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

レプリケーションとは、あるデータベースの内容を別の場所に複製し続けることです。DMSはまず既存データを丸ごとコピーするフルロードを行い、その後CDC（Change Data Capture、変更データキャプチャ）に移ります。CDCは、移行元データベースが内部に持つトランザクションログ（どの行がいつ変更されたかの記録）を読み取り、差分だけを移行先へ流し込む仕組みです。これにより、コピー中に発生した更新も取りこぼさず、最終的に両者がほぼ同じ状態になります。切り替えの瞬間だけアプリケーションを止めれば済むため、停止時間を短くできます。

同種移行と異種移行の違い

同じ種類のデータベース同士（例えばオンプレミスのMySQLからAmazon RDS for MySQL）への移行は同種移行と呼ばれ、DMS単体で完結します。一方、Oracleからaurora PostgreSQLのように種類が変わる異種移行では、テーブル定義やストアドプロシージャの文法が異なるため、AWS SCT（Schema Conversion Tool）でスキーマを変換してからDMSでデータを流します。試験では「異種移行にはSCTとDMSの組み合わせ」という対応関係がよく問われます。

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

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

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

Storage GatewayやSnow Familyとの使い分け

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

サーバー移行では、OSの設定やインストール済みソフトを一つずつ作り直すのは現実的ではありません。MGNは、サーバーを丸ごと複製してAWSで起動する道具です。

用語のキホン：リフト＆シフトとブロックレベル複製

リフト＆シフトとは、アプリケーションを作り変えずに、今の構成のままクラウドへ持ち上げて移す移行方式のことです。MGNはこれをブロックレベル複製で実現します。ファイル単位ではなくディスクの物理的な区画（ブロック）単位でコピーするため、OSやレジストリを含むサーバーの状態がまるごと再現されます。移行元サーバーにはレプリケーションエージェントを入れ、稼働させたまま裏でAWS側の待機用ストレージへ書き込み続けます。準備が整ったらテスト起動で本番に影響を与えずに動作確認でき、問題なければカットオーバー（本番切り替え）を実行します。

試験ポイント：他の移行サービスとの役割分担

MGNが運ぶのはサーバーそのもの、DMSが運ぶのはデータベースの中身、DataSyncが運ぶのはファイルです。「最小限の停止時間でオンプレミスの物理・仮想サーバーをEC2へ」という要件が出たらMGNが答えになります。移行の計画段階で既存環境の一覧や依存関係を調べたい場合は、AWS Application Discovery Serviceと組み合わせます。

回線速度には限界があり、規模によっては転送に数か月かかってしまいます。Snow Familyは、その場合に「物理的に運ぶ」という選択肢を与えるサービスです。

用語のキホン：オフライン転送の分岐点

オフライン転送とは、ネットワークを使わず記憶装置を物理輸送してデータを移す方式です。判断の目安は「回線の実効速度でデータ量を割った時間」で、これが数週間を超えるならオフラインが有利になります。Snow Familyの装置はAWSから宅配で届き、社内ネットワークにつないでデータをコピーし、返送するとAWS側でS3へ取り込まれます。データは装置内で暗号化され、鍵はAWS KMSで管理されるため、輸送中に中身を読まれる心配はありません。追跡用の電子ラベルが内蔵されており、伝票を貼る手間もかかりません。

用途による使い分け

持ち運べる小型モデルは、工場や船舶など通信環境が乏しい場所でのデータ収集や、現地でのエッジ処理に向いています。大容量モデルは、データセンターまるごとの移行のように非常に大きなデータを一度に運ぶ用途です。SAA-C03では「回線が細く期限が短い大量データの移行」という文脈で登場したらSnow Family、「回線はあるが手動コピーが大変」ならDataSyncと切り分けます。

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

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

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

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

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

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が適します。

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

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

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

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

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

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オーソライザーが使えます。

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

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

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

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

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

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

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

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

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

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

映像は容量が大きく、途切れなく届き続けるという扱いにくさがあります。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から配信すれば、視聴者の近くから届けられて再生が安定します。