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など）に処理を書くことで、デプロイ前後に検証スクリプトを実行できます。

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

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

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

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

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

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

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

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

試験ポイント

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

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

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

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

導入時の位置づけ

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

新しい開発プロジェクトを始めるとき、リポジトリの作成、ビルド設定、デプロイ先の準備、権限設定と、コードを書く前の準備だけで相当な時間がかかります。CodeStarはこの初期構築をテンプレート化しました。

用語のキホン：開発パイプラインの一括プロビジョニング

ソースコードの変更からテスト、ビルド、デプロイまでを自動でつなぐ流れをパイプラインと呼びます。AWSではCodeCommit（ソース管理）、CodeBuild（ビルド）、CodeDeploy（デプロイ）、CodePipeline（全体の連結）という複数サービスの組み合わせで構成しますが、個別に設定するとIAMロールや連携設定が煩雑になります。CodeStarは言語とデプロイ先を選ぶだけで、サンプルコードを含むリポジトリからパイプライン一式までをまとめて作成しました。さらにプロジェクトダッシュボードで、コミット履歴、ビルド状況、課題管理を1画面に集約し、チームメンバーの権限も役割単位で管理できました。

現在の位置づけと代替手段

CodeStarは新規プロジェクトの作成受付を終了しており、これから採用するサービスではありません。同様の目的にはCodeCatalyst（プロジェクトのひな型から環境一式を用意する統合サービス）や、CDK・CloudFormationによるパイプライン定義のコード化が使われます。試験対策としては「開発環境の一括セットアップを行うサービスだった」という位置づけと、CodeシリーズやCodeCatalystとの役割の違いを押さえておけば十分です。

手元の端末にAWS CLIを入れ、アクセスキーを設定する作業は、一時的な操作のためだけには手間がかかります。CloudShellはブラウザさえあれば即座にコマンド操作を始められる環境を提供します。

用語のキホン：一時的認証情報とシェル環境

CloudShellの利点は、アクセスキーを端末に保存しなくてよい点にあります。通常CLIを使うにはアクセスキーIDとシークレットアクセスキーをファイルに置きますが、これが漏えいすると第三者にアカウントを操作されてしまいます。CloudShellでは、コンソールにログインしているIAMユーザーやロールの権限が一時的認証情報として自動的に渡されます。一時的認証情報とは有効期限付きの認証情報で、期限が切れれば使えなくなるため、長期のキーより安全性が高い方式です。したがってCloudShellでできる操作の範囲は、そのユーザーに付与されたIAMポリシーの範囲と完全に一致します。

使える環境と制約

Amazon Linuxベースの環境で、AWS CLI、Python、Node.js、Git、vimなどが導入済みです。ホームディレクトリには永続ストレージが用意されており、スクリプトや設定ファイルを保存して次回も使えます（およそ1ギガバイト程度で、リージョンごとに独立します）。ファイルのアップロードとダウンロードにも対応します。一方で、一定時間操作しないとセッションが切断される、ホームディレクトリ以外の変更は保持されない、長時間動かし続ける用途には向かない、といった制約があります。腰を据えた開発にはCloud9やローカル環境、日常的な自動化にはSystems Managerを使い分けるとよいでしょう。

AWSのすべての操作は最終的にAPI呼び出しです。SDKは、そのAPIを各言語から自然な書き方で扱えるようにし、署名の計算や再試行といった面倒な処理を肩代わりします。

用語のキホン：認証情報プロバイダチェーン

SDKを使う際に押さえるべき基本が認証情報プロバイダチェーンです。これは、SDKがどの順番で認証情報を探すかという決められた手順を指します。おおむね、コード内で明示指定した値、環境変数、共有認証情報ファイル（~/.aws/credentials）、そしてEC2やECS、Lambdaに割り当てられたIAMロールの順に確認し、最初に見つかったものを使います。この仕組みがあるため、開発時はローカルのプロファイル、本番ではIAMロールというように、コードを一切変更せず環境ごとに認証方式を切り替えられます。本番環境ではアクセスキーをコードや設定ファイルに書かず、IAMロールに任せるのが原則です。

共通の設定と主なツール

SDKは~/.aws/configの設定を言語をまたいで共通に読み取り、リージョン、リトライ方式、タイムアウト、エンドポイント指定などを統一的に扱えます。再試行にはリクエストが集中しないよう待ち時間を調整する指数バックオフが既定で組み込まれています。SDKはPython（Boto3）、JavaScript、Java、.NET、Go、Rust、PHP、Rubyなど主要言語向けに提供され、加えてAWS CLI、AWS Tools for PowerShell、各種IDEプラグインもこのファミリーに含まれます。

CloudFormationは、サーバーやネットワークなどの構成をテンプレート（コード）に書き、その通りにAWSリソースを自動で作成・更新・削除できるサービスです。手作業を減らし、同じ環境を何度でも正確に再現できます（Infrastructure as Code）。

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

テンプレートから作られたリソースのまとまりをスタックと呼び、作成も削除もこの単位で行います。変更セットとは、更新を実行する前に「何がどう変わるか（特に、置き換えによってリソースが作り直されないか）」を確認するための差分プレビューです。ドリフトとは、コンソールなどで手作業による変更が加えられ、テンプレートの記述と実際の状態がずれてしまうことを指し、ドリフト検出でその差を洗い出せます。IaCでは「手で直さない」ことが原則で、ドリフトはその原則が破られた印になります。

べき等性と組織展開

IaCの重要な性質がべき等性です。これは「同じテンプレートを何度適用しても、結果は常に同じ状態に収束する」という性質で、だからこそ再現性のある環境構築が可能になります。複数アカウント・複数リージョンへ一括展開する場合はStackSetsを使います。なお更新に失敗した場合は、自動的に直前の状態へロールバックします。

YAMLやJSONでインフラを記述すると、似た構成を繰り返し書く場面で行数が膨らみ、条件分岐や再利用も表現しにくくなります。CDKは、使い慣れたプログラミング言語の力をそのままインフラ定義に持ち込むことでこの課題に応えます。

用語のキホン：IaCとプログラミング言語による定義

IaC（Infrastructure as Code）とは、サーバーやネットワークの構成をコードとして記述し、そのコードから環境を自動構築する考え方です。手作業を排除できるため、同じ構成を何度でも正確に再現でき、変更履歴もGitで管理できます。従来のIaCは設定ファイル形式の宣言型が主流でしたが、CDKでは変数、ループ、関数、クラス、単体テストといったプログラミングの機能をそのまま使えます。中心となる部品がコンストラクトで、これはリソースをひとまとまりに抽象化した再利用可能な単位です。CloudFormationのリソースと1対1で対応するL1、実用的な初期値を持つL2、複数リソースをまとめたパターンであるL3という段階があり、L2以上を使うと記述量が大きく減ります。

CloudFormationとの関係と実行の流れ

CDKはCloudFormationを置き換えるものではなく、その上に載る層です。cdk synthを実行するとコードからCloudFormationテンプレートが生成され（この処理を合成と呼びます）、cdk deployでそのテンプレートがCloudFormationに渡されてスタックとして展開されます。つまりロールバックやドリフト検出といったCloudFormationの機能はそのまま活かせます。cdk diffでデプロイ前に差分を確認できる点も実務では重宝します。テンプレートを直接書きたい場合はCloudFormation、サーバーレスに特化した簡潔な記法が欲しい場合はSAM、抽象化と再利用を重視する場合はCDKという使い分けになります。

対象サーバーにSSM Agentを入れておくと、AWS側から指示を出して操作できるようになります。EC2だけでなくオンプレミスのサーバーも管理対象にできます。

用語のキホン：ドキュメントと主要機能

実行する処理の手順書をドキュメント（SSM Document）と呼び、AWS提供のものをそのまま使うことも、自作することもできます。主な機能は、多数のサーバーへ一括でコマンドを流すRun Command、複数手順の運用作業を自動化するAutomation、パッチ適用を計画的に行うPatch Manager、SSHの鍵も踏み台も不要でシェル接続できるSession Manager、設定値を保管するParameter Storeです。

Session Managerが重要な理由

ポート22を開けず、SSH鍵も配らずに接続できるため、攻撃対象となる面（アタックサーフェス）を減らせます。しかも「誰がいつ接続し何をしたか」をCloudTrailやS3へ自動記録できるため、踏み台サーバーを廃止する構成としてよく問われます。

Lambda関数を1つ動かすだけでも、素のCloudFormationでは関数本体、実行ロール、ログ設定、APIとの連携など多くのリソースを書く必要があります。SAMはこれを大幅に短縮するために作られました。

用語のキホン：CloudFormationの拡張としてのトランスフォーム

SAMテンプレートの先頭にはTransformという宣言を書きます。これは「このテンプレートは短縮記法で書かれているので、デプロイ前に展開してください」という指示です。CloudFormationはこの宣言を見て、AWS::Serverless::Functionのような専用のリソース型を、実際の複数のリソース定義へと自動的に展開します。この展開処理をマクロと呼びます。つまりSAMテンプレートはCloudFormationテンプレートの一種であり、通常のCloudFormationリソースを同じファイル内に混在させることもできます。書き味は簡潔でも、裏側で動くのはCloudFormationそのものです。

SAM CLIとCDKとの使い分け

SAM CLIには、Dockerを使ってLambda関数をローカル実行するsam local invoke、API Gatewayを模擬起動するsam local start-api、ビルドとデプロイをまとめて行うsam build・sam deployといったコマンドが揃っています。クラウドにアップロードせずに動作確認できるため、開発サイクルを短くできます。CDKがあらゆるAWSサービスをプログラミング言語で扱う汎用フレームワークであるのに対し、SAMはサーバーレスに絞った設定ファイル形式であり、YAMLに慣れたチームや小規模なサーバーレス構成では手軽さで勝ります。なおCDKで作ったサーバーレス構成をSAM CLIでローカルテストすることも可能です。

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

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

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

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

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

EC2の起動元となるAMIは、OSの更新やミドルウェアのバージョンアップに合わせて定期的に作り直す必要があります。手作業では時間がかかるうえ、担当者によって内容が微妙に食い違うことも起こります。Image Builderはこの工程を定型化します。

用語のキホン：ゴールデンAMIとイメージパイプライン

ゴールデンAMIとは、組織の標準として承認された設定・ソフトウェア・セキュリティ対策をあらかじめ組み込んだ基準イメージのことです。全サーバーをこのイメージから起動すれば、構成の統一と初期セットアップ時間の短縮が同時に実現します。ただし脆弱性対応のたびに更新が必要なため、更新作業そのものの自動化が重要になります。Image Builderの中心はイメージパイプラインで、元となるイメージ、適用する処理、テスト、配布先をひとまとめに定義し、スケジュール実行や依存イメージの更新をきっかけに自動実行できます。

コンポーネントと配布の仕組み

導入する処理はコンポーネントという単位でYAMLに記述します。ビルド時に実行するものとテスト時に実行するものを分けて定義でき、AWSが提供する既製コンポーネント（セキュリティ強化設定やCloudWatchエージェント導入など）も利用できます。生成したイメージはディストリビューション設定によって複数リージョンや複数アカウントへ自動配布でき、ライセンス管理との連携も可能です。出力先はAMIだけでなくDockerコンテナイメージも選べ、ECRへ登録できます。作成したイメージは自動でテストされるため、動作しないイメージが配布される事態を防げます。

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

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

PaaSとは、アプリを動かす土台一式が提供され、利用者はアプリの中身に集中できる形態のことです。Beanstalkはこれにあたります。デプロイ先の単位を環境と呼び、本番用・検証用といった具合に分けて作ります。重要なのは、自動生成されたEC2やELBは隠されているわけではなく普通に触れる点で、必要なら設定ファイル（.ebextensions）で細かく調整できます。

デプロイ方式とURLスワップ

All at once（一括）、Rolling（順次）、Rolling with additional batch（台数を保ちつつ順次）、Immutable（新しい一式を作ってから入れ替え）が選べます。また、新旧2つの環境のURLを入れ替える環境URLのスワップにより、ブルーグリーン相当の切り替えと即時の切り戻しが可能です。

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

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

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

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

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

オンプレミス時代からChefやPuppetでサーバー構成を管理してきた組織にとって、その仕組みを捨てて別方式へ移行するのは大きな負担です。OpsWorksは、既存資産を活かしたままAWS上で運用するための選択肢として位置づけられます。

用語のキホン：構成管理と冪等性

構成管理ツールとは、サーバーにどのソフトウェアを入れ、どの設定ファイルをどう書き、どのサービスを起動しておくかを、コードとして記述し自動適用する仕組みです。Chefではレシピ、Puppetではマニフェストと呼ばれるファイルに「あるべき状態」を書きます。ここで重要なのが冪等性（べきとうせい）という性質で、同じ処理を何度実行しても結果が同じ状態に収束することを意味します。たとえば「このパッケージが入っている状態」と書けば、未導入なら導入し、導入済みなら何もしません。この性質があるため、繰り返し実行しても環境が壊れず、設定のずれを継続的に矯正できます。

提供形態と、現在の位置づけ

OpsWorksには、Chef Automateのマネージドサーバーを提供する形態、Puppet Enterpriseのマネージドサーバーを提供する形態、そしてAWS独自のスタック管理を行う形態がありました。いずれも新規採用の推奨対象ではなく、AWSは新しい構成管理としてSystems Manager（State Managerやパッチ管理）、イメージ作成にはEC2 Image Builder、IaCにはCloudFormationやCDKの利用を案内しています。試験では「Chef・Puppetの既存資産を活かす」という文脈で選択肢に現れることがあるため、その関連付けを押さえておけば十分です。

長年運用してきた業務アプリをコンテナ化したくても、依存関係や設定が把握しきれず着手できないことがあります。App2Containerは、動いているアプリそのものを調べることで、この最初の壁を越えるための道具です。

用語のキホン：リフト・アンド・シフトとコンテナ化

コンテナ化とは、アプリケーションと実行に必要なライブラリ・設定を1つのイメージにまとめ、どの環境でも同じように動く形にすることです。移行戦略のうち、アプリを大きく作り替えずそのまま移す方式をリフト・アンド・シフトと呼び、コンテナ化は多くの場合その延長線上にあるリプラットフォームにあたります。App2Containerは、まず稼働中のサーバー上でプロセスを検出し、必要なファイル、ポート、依存関係を解析します（インベントリ収集と分析の工程）。その結果からDockerfileとコンテナイメージを生成し、さらにECSのタスク定義やEKSのマニフェスト、CloudFormationテンプレート、デプロイ用パイプラインの定義まで作成します。

対象と、他の手段との使い分け

対象はLinux上のJavaアプリケーション（TomcatやJBossなど）とWindows上の.NETアプリケーションが中心で、オンプレミス、EC2、他クラウドのいずれで動いていても利用できます。ソースコードを必要としない点が特徴で、開発者が不在の古いシステムでも扱えます。一方、新規開発なら最初からDockerfileを書けばよく、サーバーそのものをEC2として移すだけならApplication Migration Serviceが適します。「既存アプリを、コードに触れずにコンテナへ」という条件のときに選ぶツールです。

ECSでアプリを公開するには、VPC、サブネット、クラスター、タスク定義、サービス、ALB、IAMロールなど多くの要素を組み立てる必要があります。Copilotは、これらをベストプラクティスに沿って裏側で自動生成します。

用語のキホン：抽象度の高いデプロイCLIと、アプリ・環境・サービスの3階層

Copilotが扱う中心概念は3つの階層です。Applicationはプロダクト全体を表す最上位の入れ物、Environmentは開発や本番といったデプロイ先の環境（VPCやクラスターを含みます）、Serviceは実際に動く個々のコンテナアプリケーションです。copilot initでDockerfileを指定するとサービスの種類を選ぶよう促され、インターネット公開するもの、内部通信専用のもの、バッチ処理のもの、といったパターンから選べます。この選択に応じて必要なリソース構成が決まる仕組みで、利用者はYAMLの細部を書かずに済みます。生成されるのはCloudFormationスタックなので、必要なら通常どおり中身を確認・調整できます。

ECSコンソールやCDKとの使い分け

Copilotはデプロイのパイプライン作成にも対応し、copilot pipeline initでソース変更を起点に自動デプロイする流れを構成できます。ログ確認やスケーリング設定もコマンドで行えます。細部まで自分で制御したい場合や、コンテナ以外も含む複雑な構成にはCDKやTerraformが適し、GUIで一つずつ確認したい場合はECSコンソールを使います。Copilotは「コンテナアプリを素早く定石どおりに動かす」ことに特化した位置づけです。

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

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

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

スケーリングポリシー

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

自己修復と連携

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

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

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

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

実行の仕組み

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

関連する仕組み

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

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を組み合わせて可用性とスケールを確保します。

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

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と連携）。またライフサイクルポリシーで「古いイメージは自動削除」と設定でき、保管料金の膨張を防げます。

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

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

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

3つの関係の整理

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

オンプレミスでOpenShiftを採用してきた組織がクラウドへ移る際、まったく別の基盤へ載せ替えるのは大きな負担です。ROSAは、慣れたOpenShiftの操作性と資産を維持したまま移行できる選択肢です。

用語のキホン：KubernetesディストリビューションとしてのOpenShift

Kubernetesはコンテナの配置、増減、復旧を自動化する基盤ソフトウェアですが、そのままでは開発者向けの機能や運用ツールが不足しがちです。OpenShiftはRed Hatが提供するKubernetesのディストリビューション、つまりKubernetes本体に管理コンソール、統合された認証、コンテナイメージのビルド機能（Source-to-Image）、モニタリング、より厳格な既定のセキュリティ設定などを加えてまとめた製品です。独自のocコマンドや、名前空間に相当するProjectという概念を持ち、企業向けの利用を想定した作りになっています。ROSAではこのOpenShiftがAWSのアカウント内に構築され、クラスターの運用はAWSとRed Hatが担当します。

EKSとの使い分け

純粋なKubernetesを使いたい、AWSの各サービスと密に連携したい、料金を抑えたいという場合はEKSが適します。一方、既にOpenShiftの運用ノウハウやCI・CDの仕組みがある、OpenShift固有の開発者向け機能を使いたい、Red Hatのサポート体制を維持したいという場合はROSAが選択肢になります。ROSAはAWSのマネジメントコンソールから直接契約でき、請求もAWSに一本化されます。VPC、IAM、ELB、EBSといったAWSの基盤サービス上で動作するため、既存のネットワーク設計とも統合できます。

コンテナで 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 を選びます。

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

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

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

使いどころ

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

可用性の設計は、個々のサービス設定を見ているだけでは全体像を判断できません。Resilience Hubは、アプリケーション単位で構成をまとめて評価し、復旧目標との差を数値で示します。

用語のキホン：RTOとRPO

RTO（Recovery Time Objective）は目標復旧時間、つまり障害発生からサービスが復旧するまでに許容できる時間の上限です。「4時間以内に復旧」といった形で決めます。RPO（Recovery Point Objective）は目標復旧時点、つまり失われても許容できるデータの時間幅です。「直近15分以内のデータまでなら失っても構わない」という意味になり、バックアップの取得間隔と直結します。この2つは短くするほど費用がかかるため、業務上の重要度に応じて設定するものです。Resilience Hubでは、設定したRTOとRPOに対して現在の構成で達成可能な推定値を算出し、両者を比較します。

評価の流れと関連サービスとの連携

まずCloudFormationスタック、Resource Group、Terraformの状態ファイル、EKSクラスターなどからアプリケーション構成を取り込みます。次にレジリエンスポリシー（RTO・RPOの目標値）を、AZ障害・リージョン障害・インフラ障害・アプリ障害の観点ごとに設定します。評価を実行すると達成可否が判定され、未達の場合はバックアップ設定の追加やマルチAZ化といった推奨事項が提示されます。さらにFISと連携した障害テストの提案や、CloudWatchアラームの推奨設定も得られます。開発工程に組み込めば、リリース前に復旧目標の充足を継続的に確認できます。

「マルチAZ構成だから可用性は大丈夫」という設計上の想定は、実際に障害が起きるまで確かめられません。FISは、その確認を計画的な実験として行うためのサービスです。

用語のキホン：カオスエンジニアリング

カオスエンジニアリングとは、システムに意図的な障害を注入し、その挙動を観察することで弱点を事前に見つける手法です。単なる破壊行為ではなく、科学実験の形式をとります。まず「AZが1つ停止しても応答時間は許容範囲に収まる」といった仮説を立て、次に障害を注入し、結果が仮説と一致するかを検証します。重要なのが停止条件（ストップコンディション）で、これは実験中の影響が想定を超えたときに自動で中断するための安全装置です。FISではCloudWatchアラームを停止条件として指定でき、エラー率が閾値を超えると実験が即座に打ち切られて元の状態に戻ります。この仕組みがあるため、本番環境での実施も現実的な選択肢になります。

実験テンプレートと注入できる障害

実験内容は実験テンプレートとして定義します。対象リソースの選び方（タグ指定やランダム抽出）、実行するアクション、実行順序、停止条件をまとめたものです。EC2の停止・再起動、ECSタスクやEKSポッドの終了、RDSのフェイルオーバー、CPUやメモリの負荷生成、ネットワークの遅延・パケットロス、特定のAPI呼び出しに対するエラー応答などを注入できます。IAMで実行権限を厳密に制御できるため、誰がどの範囲まで実験できるかを管理できます。

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

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

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

コンプライアンス用途

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

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

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

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

移行用途と復旧訓練

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

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

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

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

ルーティングポリシー

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

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

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設計の土台になるため、パブリックとプライベートの分離は必ず理解しておきましょう。

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

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

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

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

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

セキュリティ連携

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

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

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ピアリングの方が安価で単純です。

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

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

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

閉域化のメリット

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

接続の単位が「拠点まるごと」ではなく「利用者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を使う方が安全かつ簡単な場合もあります。

拠点のルーターと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を併用して通信を暗号化する構成もあります。

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という専用のクエリ機能を使います。

マイクロサービスやサーバーレスでは、1つの処理が多数のサービスを経由するため、ログを個別に見ても遅延や失敗の原因にたどり着けません。X-Rayはこの経路全体を1つの図として示します。

用語のキホン：可観測性と分散トレーシング

可観測性（オブザーバビリティ）とは、外から観測できる情報だけでシステム内部の状態を説明できる度合いのことで、メトリクス・ログ・トレースの3つが柱とされます。このうちトレースを担うのがX-Rayです。分散トレーシングとは、1回のリクエストに共通のIDを付け、通過した各サービスでの処理時間を記録して、それらをつなぎ合わせて全体像を復元する手法です。各区間の記録をセグメント、その内訳をサブセグメントと呼び、全体をつないだ図をサービスマップと呼びます。

サンプリングという考え方

全リクエストを記録すると負荷も費用も膨らむため、一定割合だけを記録するサンプリングを行います。既定では毎秒1件と残りの5%が対象で、この割合はルールで調整できます。

クラウドの操作はほぼすべて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、と覚えてください。

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

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

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

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

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

ストリーミングデータをただ 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 に送ればよく、構成がシンプルになります。

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

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

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

使い分け：SQS との違い

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

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基盤側の問題なのかを早く判断できると、対応時間を大きく短縮できます。Health Dashboardはその判断材料を提供します。

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

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

試験ポイント

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

クラウド移行時には、余裕を見て大きめのインスタンスを選ぶことがよくあります。しかし稼働後の実測値を見ると、大半が過剰であるケースが少なくありません。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が適します。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

CloudWatchアラーム、GuardDutyの検出結果、AWS Configの違反判定、リソースの状態変化——これらはすべてEventBridgeにイベントとして流れます。そこにルールを書いて、修復処理へつなぎます。

用語のキホン：イベント駆動運用とオートリメディエーション

イベント駆動運用とは、定期的に見回るのではなく「何かが起きた瞬間」に処理を起動する運用の考え方です。そして、検知した問題を人手を介さず自動的に是正することをオートリメディエーション（自動修復）と呼びます。EventBridgeのルールには、どのイベントを拾うかを示すイベントパターンと、起動先を示すターゲット（Lambda、SSM Automation、SNSなど）を設定します。「検知」と「修復」を疎結合につなげる点が、この構成の要です。

MTTRという指標

運用の良し悪しはMTTR（平均復旧時間）で測られます。人が気づいて対応する運用では数十分かかるものが、自動修復なら数十秒に短縮できます。ただし誤検知で誤った修復が走らないよう、まずは通知のみで運用して精度を確かめてから自動化するのが定石です。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

他の連携手段との違い

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

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

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

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

ロールと一時認証

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

ポリシー評価と保護

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

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

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

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

Parameter Storeとの使い分け

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

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

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

攻撃は静かに進行することが多く、ログを人が読んで気づくのは困難です。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はそれらの結果の統合、と整理すると試験で迷いません。

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

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

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

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

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

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

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

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

一括請求と試験ポイント

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

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

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

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

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

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

認証の仕組みを自作すると、パスワードの安全な保管や多要素認証など考慮すべき点が多く、脆弱性の温床になりがちです。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が解答になります。

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

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が答えです。

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が選ばれます。

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

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

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

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

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

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

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

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

試験ポイント

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

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で暗号化でき、ボリュームサイズやタイプは稼働中でも変更可能です。

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では待機系がそのまま読み取りにも使える点が違いです。

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

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

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

キー設計とインデックス

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

拡張機能

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

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

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

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

使いどころと注意点

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

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

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

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

RedisとMemcachedの違い

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

インメモリのデータストアは高速ですが、電源が落ちればデータが消えるという前提が長らくつきまといました。MemoryDBは、この前提を覆して耐久性を備えたインメモリデータベースです。

用語のキホン：インメモリデータベースと耐久性

インメモリデータベースとは、データをディスクではなくメモリ上に置いて処理するデータベースです。ディスクアクセスが不要なぶん桁違いに高速ですが、メモリは電源が切れると内容が消える性質を持ちます。そこでMemoryDBはトランザクションログという仕組みを使います。これは書き込み操作の内容を発生順に記録し続けるログで、MemoryDBではこのログを複数のアベイラビリティゾーンに分散保存します。書き込みは複数AZへの記録が完了してから成功と返されるため、障害でノードが失われてもログから復元でき、データが消えません。この性質を耐久性と呼びます。一方、読み取りはメモリから直接行うためマイクロ秒単位の応答が得られます。

ElastiCacheとの違い

最大の違いはデータの位置づけです。ElastiCache for Redisは、別にある本体のデータベース（RDSやDynamoDBなど）の負荷を減らすためのキャッシュとして設計されています。データが失われても本体から読み直せる前提なので、書き込みの複製は非同期で行われ、障害時に直近のデータを失う可能性があります。対してMemoryDBはそれ自体が正となるデータベースであり、他にバックアップ元を持ちません。そのぶん書き込みはElastiCacheより遅く、費用も高くなる傾向があります。既存のデータベースを速くしたいならElastiCache、Redisのデータ構造を使って高速なデータベースそのものを構築したいならMemoryDB、という選び分けになります。

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

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

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

DynamoDBとの使い分け

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

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

データベースの引っ越しは、業務を止められないという点が最大の難所です。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の組み合わせ」という対応関係がよく問われます。

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にできます。

キャッシュという考え方

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