AMI：EC2の元になる「OSのテンプレート」。作り込んだサーバーの状態を保存して、同じサーバーを複製することもできる（冗長化や復旧に使える）。

インスタンスタイプ：CPU・メモリなどの組み合わせのこと。「t3.micro」のように表記され、用途と規模に応じて選ぶ。

ライフサイクル：実行中は課金・停止中は課金なし。「終了（削除）」すると元に戻せないので慎重に。

種類：正式にはElastic Load Balancingというサービスで、用途別に数種類ある。Webアプリで定番なのがALB（Application Load Balancer）。

HTTPSの受け口：暗号化された通信（HTTPS）の受け口として、証明書を設定して使うこともできる。

置き場所：外に見せる区画（publicサブネット）に置き、隠した区画（privateサブネット）からの通信経路をここへ向ける、という使い方をする。

コストの考え方：時間課金のため、置く台数はコストと相談して決める。

きっかけ（イベントソース）：「S3にファイルが置かれたら」「APIが呼ばれたら」など、様々な出来事をきっかけに起動できる。

向き不向き：実行時間に上限があり、常時動き続けるアプリをそのまま載せる用途には向かない。アプリを関数単位に作り替える前提のサービス。

Docker：コンテナを作る・動かすための代表的なツール。コンテナ活用の事実上の標準。

ECR：コンテナの元（イメージ）を保管しておく置き場。ECSとセットでよく使われる。

ライフサイクルルール：アクセスが減ったデータを、より安い保管場所へ自動で移したり、期限が来たら削除したりできる（コスト削減）。

バージョニング：誤って消したり上書きしても戻せるよう、世代を管理できる。

暗号化：保管するデータを暗号化して守る機能が用意されている。

ボリュームタイプ：SSD／HDDなど種類があり、性能とコストのバランスで選ぶ。

場所の制約：同じアベイラビリティゾーンにあるEC2にしか取り付けられない。

仲間のサービス：Windowsのファイルサーバーが必要な場合は「FSx for Windows File Server」という別サービスもある。

マルチAZ構成：待機用のDBを別のアベイラビリティゾーンに置き、障害時に自動で切り替わる構成が組める。

リードレプリカ：読み取り専用の複製を作って、読み込みの負荷を分散できる。

位置づけ：RDSファミリーの一つとして管理画面もRDSと共通。規模とコストのバランスで選ぶ。

NoSQLとは：リレーショナル型（表形式）以外のデータベースの総称。表の形に縛られない分、柔軟で速いが、複雑な集計は苦手。

DAX：DynamoDB専用のキャッシュを足して、さらに高速化することもできる。

エンジン：シンプルな「Memcached」と、多機能で永続化もできる「Redis」の2種類から選ぶ。

位置づけ：日々のシステム処理用のDBではなく、貯めたデータを「分析する」ための倉庫（データウェアハウス）という役割。

アベイラビリティゾーン（AZ）：地域内で物理的に離れたデータセンター群のこと。サブネットはAZを指定して作り、複数のAZに分けて作ると災害・障害に強くなる。

public／privateの正体：サブネットに「インターネットへの経路（Internet Gateway向けのルート）」があるかどうかで決まる。

名前の由来：DNSが使う通信番号「ポート53」から。アクセス元の場所や状態に応じた振り分けなど、高度なルーティングもできる。

定番の組み合わせ：S3に置いた静的サイトをCloudFrontから配信する構成がよく使われる。

組み合わせ：専用線をメイン・VPNを予備にして、障害に備える構成もある。

ステートフル：許可した通信の「戻り」は自動で通る仕組みになっている。

仲間：サブネット単位で許可／拒否を制御する「ネットワークACL」という仕組みもある。

証明書の役割：「通信の暗号化」に加えて「このサイトが本物である証明」の役割も持つ。

使いどころ：「いつ・誰が・どの設定を触ったか」を後から追跡できるため、説明責任が求められるシステムで特に重要になる。

CloudTrailとの違い：CloudTrailは「人の操作」の記録、Configは「リソースの状態変化」の記録。セットで使われることが多い。

ログの例：ネットワークの通信記録（VPC Flow Logs）やアプリのログの保存先としても使われる。

セットで使う：パスワードに加えてもう一段の認証を足す「MFA（多要素認証）」との併用が推奨される。

ほかにも：DDoS攻撃を自動で緩和する「Shield」、脆弱性を自動診断する「Inspector」など、守りのサービスは多数ある。

APIとは：プログラム同士が会話するための「注文窓口」。窓口の作成・保守・保護をまとめて面倒みてくれる。

種類：スループット重視の「スタンダード」と、順番が保証される「FIFO」の2種類がある。

pub/sub：発行者（Publisher）が「トピック」に投げ、購読者（Subscriber）が受け取る仕組み。CloudWatchのアラームと組み合わせて「異常があったら通知」がよくある使い方。

仲間：複数の処理を順番に・条件分岐つきで実行する「Step Functions」というワークフローサービスもある。

IaC：このように構成をコードで管理する考え方を「Infrastructure as Code」と呼ぶ。プログラミング言語で書ける「CDK」というツールもある。

前提：サーバーが自動で増減するため、「どのサーバーでも同じ動きをする」構成（負荷分散やDBの分離）とセットで設計する。

使い方のコツ：全部を満たすのではなく、お客様の状況に合わせて「どの柱を優先するか」を考えるのがプロの設計。

発展機能：複数のツールを組み合わせて自律的にタスクをこなす「Agents」、有害な出力を抑える「Guardrails」などの機能もある。

Bedrockとの違い：Bedrockは「できあがったAIを使う」、SageMakerは「自分でAIを作る・鍛える」寄りのサービス。

見える化：分析結果をグラフやダッシュボードにする「QuickSight」というBIサービスと組み合わせることが多い。