AWS Certified Data Engineer – Associate のナレッジマップ

AWS Certified Data Engineer – Associate の主要概念 552 件と、そのつながり。上のマップでノードをクリックすると関連用語や前提をたどれます。下は全概念の索引で、定義と「前提・関連する概念」への内部リンクを掲載しています。

概念一覧（552）

• 性能の指標（IOPS/スループット/帯域幅/レイテンシー）

  性能を測る基本語彙。IOPS＝1 秒あたりの I/O 回数（小さなランダムアクセスの指標、EBS io2 等）。スループット＝単位時間のデータ量（MB/s、大きな連続転送）。帯域幅＝回線容量。レイテンシー＝1 操作の遅延。ワークロードに合う指標で設計・監視する。

• AWS Lambda

  サーバーレス（FaaS）。イベント駆動で関数を実行し、実行した分だけ課金。サーバー管理が不要。

  関連: サーバーレス（FaaS）

• Amazon CloudWatch

  可観測性の中核。Logs＝ログ集約（Logs Insights でクエリ）、メトリクス＝数値の時系列（カスタムメトリクスも）、アラーム＝しきい値超過で通知/自動対応（SNS/Auto Scaling）。Lambda のログは自動で Logs へ。

  関連: カスタムメトリクス、CloudWatch Logs Insights

• ML データ準備（エンコード/スケーリング/不均衡）

  生データをモデルが学べる形に整える工程。エンコード＝カテゴリを数値化（ワンホット/順序/ターゲット）、スケーリング＝標準化(z-score)/正規化(Min-Max)、不均衡＝SMOTE等のオーバーサンプリング/クラス重み付け（評価はF1/PR-AUC）。変換のfitは分割後のトレーニングデータのみ（データリーク防止）。

• Amazon Bedrock

  複数ベンダーの基盤モデルにAPIでアクセスし、自社アプリに生成AIを組み込むフルマネージドサービス。ナレッジベース(RAG)・エージェント・ガードレールも提供。

  関連: Amazon Bedrock Knowledge Bases

• Amazon SageMaker

  MLモデルの構築・学習・デプロイを一気通貫で行うマネージド環境（自社データで独自モデル）。JumpStartで事前構築モデルを試す/微調整も。

  関連: SageMaker JumpStart

• 料金モデル（オンデマンド/Savings Plans・RI/スポット）

  オンデマンド＝従量・最も柔軟、Savings Plans/RI＝1〜3年コミットで割引、スポット＝余剰容量を最大約90%引き（中断あり）。

• Amazon DynamoDB

  サーバーレスなNoSQLキー値/ドキュメントDB。柔軟なスキーマで大規模でも低遅延。

• サーバーレス（FaaS）

  サーバー管理が不要で、イベント時だけコードを実行し実行分だけ課金する形態（例：AWS Lambda）。

  関連: AWS Lambda

• Auto Scaling

  需要や障害に応じてEC2などの台数を自動で増減する（弾力性）。ELBと組み合わせて高可用性に。

• AWS CloudTrail

  アカウント内のAPI操作の監査ログ（誰が・いつ・何をしたか）を記録する。

• マネージドサービス（管理の境界）

  AWS が運用の一部を肩代わりするサービス区分。フルマネージド（パッチ/スケール/可用性まで AWS）ほど運用負荷が下がる一方、制御は減る。アンマネージド（EC2 等）は柔軟だが自己管理。責任共有モデルの「どこまでが自分の責任か」を決める軸。

• IAM ポリシーの構造（Effect/Action/Resource/Condition）

  JSON ポリシーの構成要素。Effect＝Allow/Deny、Action＝許可する API（s3:GetObject 等）、Resource＝対象 ARN、Condition＝条件（IP・MFA・タグ等）、Principal＝誰に（リソースポリシーのみ）。最小特権はこれらを具体化して絞る。

• Amazon CloudFront

  CDN。エッジロケーションでコンテンツをキャッシュし、ユーザーへ低遅延で配信する。

  関連: エッジロケーション

• Amazon API Gateway

  REST/HTTP/WebSocket API を作成・公開・管理するフルマネージドサービス。スロットリング・認可（Cognito/Lambda オーソライザー）・ステージ・使用量プラン・キャッシュを備える。バックエンドは Lambda 等。

  前提: Amazon Cognito、マネージドサービス（管理の境界）

  関連: API Gateway の種類（REST/HTTP/WebSocket）

• AWS Glue

  サーバーレス ETL の中核。クローラがスキーマを推論してデータカタログ（中央メタデータ・Athena/Redshift Spectrum/EMR が共有）に登録、ETL ジョブがサーバーレス Spark で変換/クレンジング、Glue Data Quality（DQDL）でデータ品質を検証、ジョブブックマークで処理済みデータの重複を防ぐ。

  関連: Glue Data Quality（DQDL）、ジョブブックマーク、Glue クローラ、Redshift Spectrum

• AWS CloudFormation

  宣言的テンプレート（YAML/JSON）でリソース群（スタック）を再現性よくデプロイする IaC サービス。変更セットで適用前の差分を確認し、ドリフト検出で実体との乖離を発見する。ネストスタックや StackSets で構成を分割・多アカウント展開できる。

  関連: AWS Resource Groups、YAML

• AWS IAM

  ID とアクセス管理。ユーザー/グループ/ロール/ポリシーで「誰が何をできるか」を最小権限で制御。ロールは一時権限（キー不要）。

• Amazon Athena

  S3 上のデータに Presto/Trino ベースの SQL を実行するサーバーレスサービス。スキャンしたデータ量に応じて課金されるため、Parquet 化＋パーティション分割でコストを大幅に削減できる。Glue データカタログをメタデータとして利用する。

  前提: パーティション分割（S3/データレイク）

  関連: Glue データカタログ、列指向フォーマット（Parquet/ORC）

• CloudWatch Logs

  ログを集約・保存する仕組み。ロググループ（保持期間を設定）の配下にログストリームが並ぶ。メトリクスフィルターでログから数値メトリクスを抽出し、サブスクリプションフィルターで Kinesis/Lambda/OpenSearch へリアルタイム転送する。Lambda など多くのサービスのログが自動で届く。

  前提: Amazon OpenSearch Service、SNS メッセージフィルタリング

• Amazon Data Firehose

  コード不要で S3/Redshift/OpenSearch などへストリームを配信するサービス。バッファリング・Lambda 変換・Parquet 変換ができるが、リプレイ用の保持はしない。

  前提: AWS Lambda、Amazon Redshift、列指向フォーマット（Parquet/ORC）、Amazon OpenSearch Service

  関連: Kinesis Data Streams、Data Firehose の機能（バッファリング/変換/動的パーティショニング）

• JSON

  波括弧とキー・値のペアで構造化データを表す軽量なテキスト形式。API のリクエスト/レスポンスや IAM ポリシー・バケットポリシーのような権限定義など、機械可読性を重視する場面で広く使われる。

  前提: S3 アクセス制御（バケットポリシー/ACL/所有権）

• AWS Systems Manager（SSM）

  インスタンス群を SSH/RDP を開けずに大規模運用する統合ツール。Run Command（一括コマンド）・Session Manager（ポート開放不要のシェル）・Patch Manager（パッチベースライン＋メンテナンスウィンドウ）・Automation（ランブックで自動修復）・Parameter Store（設定/SecureString）。利用には SSM エージェントと IAM ロールが必要。

  前提: Patch Manager、Session Manager、SSM Automation（ランブック）

  関連: Parameter Store、Run Command

• Amazon Redshift

  ペタバイト級のデータウェアハウス（OLAP）。列指向ストレージと MPP（並列処理）で大規模集計を高速化する。Redshift Spectrum で S3 を直接クエリ、Serverless でプロビジョニング不要。

  関連: Redshift Spectrum

• AWS Fargate

  ECS/EKS のサーバーレス実行基盤。EC2 インスタンスの管理（パッチ・スケール）が不要で、タスク単位の vCPU/メモリ指定だけで動く。運用負荷を下げたいときの第一選択。

• コスト配分（チャージバック/ショーバック）

  クラウド費用を部門/プロジェクトに割り当てる運用。チャージバック＝実費を各部門に請求（責任明確化）。ショーバック＝請求せず使用量を可視化（意識づけ）。コスト配分タグ・コストカテゴリ・Cost Explorer で実現する。

  前提: AWS Cost Explorer

  関連: コストカテゴリとコスト配分タグ

• AWS Cost Explorer

  コストと使用量を時系列・サービス別・タグ別に可視化し、傾向分析や予測ができるツール。RI/Savings Plans の推奨や、リザーブド使用率/カバー率レポートも提供する。

  関連: AWS Budgets

• データレイク

  生のまま多様なデータ（構造化〜非構造化）を大量・安価に格納する基盤。スキーマは読み取り時に解釈。

• Amazon Aurora

  MySQL/PostgreSQL 互換のクラウドネイティブ DB。ストレージは 3 AZ に 6 重複製で自動修復・自動拡張（最大128TiB）。最大15のリードレプリカ、フェイルオーバーは通常30秒未満。RDS より高可用・高性能。

• Kinesis Data Streams

  耐久性のあるストリーミング取り込み。データを一定期間保持して再処理（リプレイ）でき、シャードで並列化し、複数の独自コンシューマーが同じストリームを読める。

  前提: 耐久性と可用性（ナイン）

  関連: Amazon Data Firehose

• ルートテーブル

  サブネットのトラフィックの行き先を決める規則表。宛先 CIDR ごとにターゲット（IGW・NAT GW・ピアリング・エンドポイント等）を指定する。最長一致が優先。ローカルルート（VPC 内）は削除できない。

• 一時認証情報

  STS が発行する短命の認証情報（アクセスキー・シークレットキー・セッショントークンの 3 点）。期限切れで自動失効するため、埋め込みの長期キーより漏洩リスクが低い。

  前提: DynamoDB の TTL（自動失効）

• Amazon Bedrock Knowledge Bases

  マネージドな RAG 機能。データソース（S3 等）を取り込み、チャンク分割・埋め込み生成・ベクトルストア（OpenSearch Serverless/Aurora pgvector 等）への格納・検索・出典付き回答までを Bedrock が一括で担う。自前の検索基盤を組まずに根拠付き生成を実現する。

  前提: Amazon OpenSearch Service、チャンキング（分割戦略）

  関連: OpenSearch Serverless（ベクトルエンジン）、Amazon Bedrock

• コンプライアンス報告

  基準や規制への準拠状況を評価・報告すること。AWS Config（ルール準拠）、Audit Manager（証跡収集）、Security Hub（統合スコア）で継続的に可視化する。

  前提: AWS Config、AWS Audit Manager

  関連: 監査証跡、変更管理

• 列指向フォーマット（Parquet/ORC）

  列単位で格納する分析向けフォーマット。必要列だけを読みスキャン量と I/O を削減し、圧縮効率も高い。Athena/Spark のコストを大きく下げる。

  関連: Amazon Athena

• Glue データカタログ

  テーブル・スキーマ・パーティションの中央メタデータストア。Athena・Redshift Spectrum・EMR が共通のメタデータとして参照する。

  前提: Amazon Redshift、AWS Glue

  関連: Amazon Athena、Redshift Spectrum

• AWS Lake Formation

  データレイクの権限を一元管理するサービス。Glue データカタログのテーブルに列/行/セルレベルの細かなアクセス権を付与し、Athena/Redshift Spectrum/EMR からのアクセスに一貫適用。LF-Tags（タグベースアクセス制御）で属性により大規模にガバナンスできる。IAM だけでは難しい粒度を補う。

  前提: データレイク、Amazon Redshift、Amazon Athena、Glue データカタログ

• Amazon OpenSearch Service

  全文検索とログ分析/可観測性に強いマネージド検索エンジン。OpenSearch Dashboards（Kibana）で可視化する。大規模な集計分析の主役は Redshift で、OpenSearch は検索/ログ用途と使い分ける。

  前提: Amazon Redshift

• DynamoDB の容量と TTL

  容量はオンデマンド（自動・従量）かプロビジョンド（RCU/WCU・Auto Scaling）。TTL で期限切れ項目を自動削除し、PartiQL で SQL 風にアクセスできる。スロットリングは指数バックオフで再試行する。

  前提: Auto Scaling、Amazon DynamoDB、料金モデル（オンデマンド/Savings Plans・RI/スポット）、指数バックオフ

• AWS X-Ray

  分散トレース。1リクエストが通る各サービスの区間（セグメント/サブセグメント）と遅延を記録し、サービスマップでボトルネックやエラーを特定する。サンプリングで一部を記録。ログ（何が起きたか）を補完。

  前提: 性能の指標（IOPS/スループット/帯域幅/レイテンシー）

  関連: X-Ray のサンプリングとサブセグメント

• 指数バックオフ

  スロットリングやエラー発生時に、再試行までの待機時間を回数ごとに指数的に伸ばしていく再試行手法。多数のクライアントが同時に再試行してさらに負荷が集中する事態（サンダリングハード問題）を、ジッター（ランダムなずらし）を加えて緩和する。多くのクラウドSDKが既定で実装する。

  関連: べき等性

• Data Firehose の機能（バッファリング/変換/動的パーティショニング）

  バッファリング＝サイズ/時間で溜めてから配信（小さなファイルの乱立を防ぐ）。Lambda 変換＝配信前にレコードを加工。形式変換＝JSON を Parquet/ORC へ。動的パーティショニング＝内容に応じて S3 のパスを分け、Athena のクエリ効率を上げる。

  前提: AWS Lambda、Amazon Athena、列指向フォーマット（Parquet/ORC）、JSON

  関連: Amazon Data Firehose

• S3 の暗号化と公開防止

  S3 のデータ保護。暗号化は SSE-S3（AWS 管理キー）、SSE-KMS（CMK で制御・CloudTrail で監査）、DSSE-KMS（二重暗号化）から選ぶ。誤公開はブロックパブリックアクセス（アカウント＆バケット）＋制限的なバケットポリシー＋ACL 無効化で防ぐ。

  関連: S3 アクセス制御（バケットポリシー/ACL/所有権）、DSSE-KMS（二重レイヤー暗号化）

• AWS Secrets Manager

  DB 認証情報や API キーなどのシークレットを安全に保管し、Lambda で自動ローテーションできるサービス。SSM Parameter Store より高機能（ローテーション・クロスアカウント共有）で、利用に応じ課金。

  前提: API キーと使用量プラン、AWS Lambda、Parameter Store

• Amazon GuardDuty

  ログを分析して脅威を自動検出する。結果統合はSecurity Hub、脆弱性はInspector、機密データ検出はMacie。

  前提: Amazon Inspector、Amazon Macie

• Amazon Route 53

  DNS（ドメイン名の解決）とドメイン登録のサービス。ヘルスチェックやルーティングポリシーも持つ。

  関連: Route 53 ルーティングポリシー

• コンテナ化

  アプリと依存関係を 1 つのイメージにまとめ、どこでも同じように動かす技術。VM より軽量・高速起動で、密度とポータビリティが高い。AWS では ECR（保管）＋ECS/EKS（実行）＋Fargate（サーバーレス実行）で運用する。

  前提: AWS Fargate、サーバーレス（FaaS）

• データレイクとフォーマット最適化

  S3 を中心に生（raw/bronze）→クレンジング（cleaned/silver）→キュレート（curated/gold）のレイヤーで品質を上げる設計。列指向（Parquet/ORC）化＋パーティション分割＋小ファイルのコンパクションで後段のスキャン量とコストを削減。更新/削除/タイムトラベルが要るなら Iceberg/Hudi/Delta のテーブルフォーマット。

  前提: データレイク、列指向フォーマット（Parquet/ORC）、コンパクション（小ファイル統合）、パーティション分割（S3/データレイク）

• Redshift Spectrum

  Redshift から S3 上のデータを直接クエリする機能。ロード不要でデータレイクとウェアハウスを横断結合でき、Glue データカタログを参照する。

  前提: データレイク

  関連: Amazon Redshift、Glue データカタログ、AWS Glue

• AWS Step Functions

  複数ステップのワークフローをステートマシンとして編成するサービス。分岐・並列・リトライ・エラー処理・待機を宣言的に記述し、Lambda 等を順序立てて実行する。

  前提: AWS Lambda

• プリンシパル

  IAM においてアクションを実行する主体そのもの（IAM ユーザー・ロール・AWS サービス・別アカウント・フェデレーション ID など）。リソースベースポリシーや信頼ポリシーの Principal 要素で「誰に許可するか」を指定するときの対象になる。

  前提: 信頼ポリシー

  関連: リソースベースポリシー

• IAM ユーザー

  人やアプリケーションに対応する長期的な ID で、パスワードやアクセスキーなど長期認証情報を持てる。人にはロール＋一時認証情報を優先し、IAM ユーザーと長期キーの発行は最小限にとどめるのがベストプラクティス。

  前提: 一時認証情報

• べき等性

  同じ操作を何度実行しても結果が変わらない性質。分散システムではネットワーク再送やリトライでリクエストが重複しやすく、べき等な設計（べき等キーの利用など）があれば重複配信されても安全に処理できる。

  関連: 指数バックオフ

• 疎結合（デカップリング）

  コンポーネント間を直接呼び出しでなくキュー（SQS）や通知（SNS）・イベント（EventBridge）で分離する設計。片方の障害や負荷変動が連鎖せず、独立してスケール・更新できる。バッファリングでスパイクも吸収。

  前提: Data Firehose の機能（バッファリング/変換/動的パーティショニング）

• SageMaker 推論方式

  4方式を要件で選ぶ。リアルタイム＝常時稼働・低遅延（Auto Scaling・多数モデルはマルチモデルエンドポイント）。サーバーレス＝アイドル時ゼロにスケール（断続的・コールドスタート有）。非同期＝大きいペイロード/長時間をキュー処理。バッチ変換＝エンドポイント不要でデータセット全体をオフライン推論。

  前提: Amazon SageMaker、Auto Scaling、ML データ準備（エンコード/スケーリング/不均衡）、性能の指標（IOPS/スループット/帯域幅/レイテンシー）

• オブジェクトストレージ

  データをキーで管理し HTTP でアクセスする、事実上無限に拡張するストレージ（S3）。バックアップ・配信・データレイクに向く。階層構造ではなくフラットな名前空間。

  前提: データレイク

  関連: ブロックストレージ、ファイルストレージ

• ポーリング vs Webhook（プッシュ/プル）

  連携の2方式。ポーリング（プル）＝こちらから定期的に問い合わせる（実装簡単だが遅延・無駄が出る）。Webhook（プッシュ）＝相手がイベント時に呼んでくる（即時・効率的だが受け口の可用性が要る）。AWS では EventBridge/SNS がプッシュ、SQS 受信がプル。

• チャンキング（分割戦略）

  RAG で文書を埋め込み・検索に適した小片（チャンク）へ分割する処理。固定長/オーバーラップ付き/階層的/セマンティックチャンキング（意味の切れ目で分割）などがあり、サイズと重なりが検索精度と文脈の質を左右する。小さすぎると文脈欠落、大きすぎるとノイズ増。

• S3 アクセス制御（バケットポリシー/ACL/所有権）

  バケットポリシー＝バケット単位のリソースポリシー（推奨の制御手段）。ACL＝レガシーなオブジェクト/バケット権限（現在は無効化が推奨）。オブジェクト所有権の「バケット所有者強制」で ACL を無効化し、ポリシーに一本化する。パブリックアクセスブロックが最終防壁。

  前提: IAM ポリシーの構造（Effect/Action/Resource/Condition）

  関連: S3 の暗号化と公開防止

• DynamoDB の設計機能（GSI/DAX/Global Tables）

  グローバルセカンダリインデックス（GSI）で別キーの検索を、DAX でマイクロ秒のキャッシュを、Global Tables でマルチリージョン能動複製を、Streams で変更イベントを得る。容量はオンデマンドかプロビジョンド。

  前提: Amazon DynamoDB、料金モデル（オンデマンド/Savings Plans・RI/スポット）

  関連: マルチリージョン構成（アクティブ-アクティブ/スタンバイ）

• AWS PrivateLink

  インターネットを経由せず、VPC から AWS サービスや他アカウントのサービスへプライベート接続する仕組み。トラフィックが AWS ネットワーク内に留まり、公開経路を使わない。

• Transit Gateway

  多数の VPC とオンプレミスを単一のハブに集約して相互接続するルーター。VPC ピアリングのフルメッシュを避け、ハブ&スポークで大規模なネットワーク接続を簡素化する。

  関連: VPC ピアリング

• Bedrock の推論モード（オンデマンド/プロビジョンド）

  オンデマンドは使った分だけ課金。プロビジョンドスループットは容量（モデルユニット）を確保し安定した大規模・低レイテンシ推論に対応する。カスタム/ファインチューニング済みモデルの推論は多くプロビジョンドスループットが前提（オンデマンド対応はモデル依存）。

  前提: Amazon Bedrock、料金モデル（オンデマンド/Savings Plans・RI/スポット）、性能の指標（IOPS/スループット/帯域幅/レイテンシー）

• API キーと使用量プラン

  API キーはクライアントを識別するトークンで、単体では認証にならず使用量プランと組み合わせてレート制限（1 秒あたりのリクエスト数）とクォータ（月間上限等）を課す。認証自体は Lambda オーソライザーや IAM、Cognito オーソライザーが別途担う。

  前提: AWS Lambda、Amazon Cognito、レート制限

  関連: API Gateway キャッシュ、API Gateway ステージ

• クールダウンとウォームアップ

  クールダウンは、Auto Scaling がスケーリングアクションを実行した直後に次のスケーリング評価を一定時間抑制し、メトリクスの反映待ちによる過剰な連続スケーリング（振動）を防ぐ仕組み。ウォームアップは、新しく起動したインスタンスがターゲット追跡スケーリングの平均値計算に算入されるまでの猶予期間を指す。

  前提: Auto Scaling、ML データ準備（エンコード/スケーリング/不均衡）、Auto Scaling のポリシーとライフサイクルフック

• Amazon Managed Grafana

  フルマネージドな Grafana。CloudWatch・Prometheus・X-Ray など複数データソースのメトリクス/ログ/トレースを 1 つのダッシュボードで可視化・アラートできる。運用監視の「見える化」レイヤーを自前運用せずに使える。

  前提: Amazon CloudWatch、AWS X-Ray、マネージドサービス（管理の境界）

• AWS Organizations（一括請求）

  複数アカウントを束ね、一括請求でボリューム割引や管理の一元化、SCPで組織的なガードレールを実現する。

• AWS Resource Groups

  タグやリソースの種類、CloudFormation スタックなどの条件でリソースをまとめ、1つの論理的なグループとして扱う機能。グループ化した後は Systems Manager の Automation・Patch Manager や監視ダッシュボードの対象範囲として一括操作できる。

  前提: IAM ポリシーの構造（Effect/Action/Resource/Condition）、Patch Manager、AWS Systems Manager（SSM）

  関連: タグエディタ（Tag Editor）、AWS CloudFormation

• AWS WAF

  Web アプリケーションファイアウォール。SQL インジェクションやクロスサイトスクリプティング等の不正な HTTP リクエストを、マネージドルールやレート制限で検査・ブロックする。CloudFront・ALB・API Gateway に適用。

  前提: Amazon CloudFront、Amazon API Gateway、レート制限

  関連: AWS Shield（Standard/Advanced）

• キャパシティプランニング / 需要予測

  将来の負荷を見積もり、必要な容量・コスト・スケーリング方針を計画すること。クラウドでは Auto Scaling と予測スケーリングで動的に追従できるため、固定的な過剰調達を避けられる。Compute Optimizer や CloudWatch の傾向分析が入力になる。

  前提: Auto Scaling スケーリングポリシー、Auto Scaling、Amazon CloudWatch、ML データ準備（エンコード/スケーリング/不均衡）

• AWS Budgets

  コスト/使用量/RI・SP カバー率に予算しきい値を設け、超過（または予測超過）でアラート通知するサービス。Budget Actions で IAM ポリシー適用や停止などの自動対応も可能。

  関連: AWS Cost Explorer

• Amazon RDS Proxy

  RDS/Aurora へのコネクションをプールして共有するフルマネージドプロキシ。多数の接続を抱える Lambda などでコネクション枯渇を防ぎ、フェイルオーバー時間も短縮する。IAM 認証・Secrets Manager 連携。

  前提: AWS Lambda、Amazon RDS、マネージドサービス（管理の境界）、AWS Secrets Manager

• パーティション分割（S3/データレイク）

  データを日付や地域などのキーでフォルダー分割し、クエリで不要なパーティションを読み飛ばす（プルーニング）ことでスキャン量とコストを削減する。

  前提: データレイク

• Amazon S3 Tables

  Apache Iceberg 形式の表形式データを S3 上でマネージドに保存・最適化するストレージ。分析エンジン（Athena/EMR/Spark 等）から効率的にクエリでき、自動コンパクションでテーブルを最適化する。

  前提: Amazon S3、Amazon Athena、コンパクション（小ファイル統合）、テーブルフォーマット（Iceberg/Hudi/Delta）

• イベントソースマッピングと送信先

  SQS/Kinesis/DynamoDB Streams をポーリングして Lambda を起動するイベントソースマッピング。バッチサイズ/ウィンドウを調整し、失敗は送信先（Destinations）や DLQ へ振り分ける。

  前提: Amazon DynamoDB、AWS Lambda、Kinesis Data Streams、ポーリング vs Webhook（プッシュ/プル）

  関連: Lambda の呼び出しモデル（同期/非同期/ストリーム）

• ECS タスク実行ロール

  ECSエージェント自体がコンテナを起動するために使うIAMロール。ECRからイメージを取得し、CloudWatch Logsへログを送信し、Secrets Manager/SSM Parameter Storeから環境変数用の機密値を取得する権限を持つ。タスクロールとは別物で、アプリコードには渡らない。

  前提: AWS IAM、CloudWatch Logs、Amazon CloudWatch、ECS タスクロール

• EventBridge Pipes

  ソース（SQS・Kinesis・DynamoDB Streams など）とターゲットをポイントツーポイントで直結するパイプ。間にフィルタリング・エンリッチメント（Lambda 等での加工）・変換ステップを挟めるため、統合ロジックのために別途 Lambda を書かずに済むことが多い。

  前提: Amazon DynamoDB、AWS Lambda、AWS Glue、Kinesis Data Streams

  関連: EventBridge Scheduler

• 会話履歴 / セッションメモリ

  マルチターン対話で文脈を保つために過去のやり取りを保存・参照する仕組み。DynamoDB 等に保持し、毎回プロンプトへ要約・関連分のみ渡してコンテキスト超過を避ける。Bedrock Agents はセッション単位でメモリを扱う。

  前提: Agents for Amazon Bedrock、Amazon Bedrock、Amazon DynamoDB

  関連: コンテキストウィンドウ超過

• リソースベースポリシー

  S3 バケットポリシーや SQS キューポリシーのようにリソース側にアタッチし、「誰がこのリソースにアクセスできるか」を定義するポリシー。Principal 要素を持てるため、対象リソースを持たない別アカウントのプリンシパルにもアクセスを許可でき、クロスアカウントアクセスの実現に有効。

  前提: クロスアカウントアクセス、IAM ポリシーの構造（Effect/Action/Resource/Condition）、S3 アクセス制御（バケットポリシー/ACL/所有権）

  関連: プリンシパル、アイデンティティベースポリシー

• 信頼ポリシー

  IAM ロールに付随する特殊なリソースポリシーで、「誰がこのロールを引き受けられるか（sts:AssumeRole を実行できるか）」を定義する。ロール自体のアクセス許可を決めるアイデンティティベースポリシーとは別物で、両方が揃って初めてロールの引き受けが成立する。

  前提: AWS IAM、アイデンティティベースポリシー、IAM ポリシーの構造（Effect/Action/Resource/Condition）

  関連: AssumeRole

• 冪等性キーパターン

  クライアントがリクエストごとに一意なキーを付与し、サーバー側がそのキーの処理結果をキャッシュして同一キーの再送を重複実行させないようにする設計パターン。ネットワーク再試行やSQSの最低1回配信で同じ処理が複数回走る問題（決済の二重処理等）を防ぐ。DynamoDBの条件付き書き込みでキーの初回性を判定する実装が一般的。

  前提: Amazon DynamoDB、配信セマンティクス（少なくとも1回/正確に1回）、DynamoDB の書き込み制御（条件付き/トランザクション）、べき等性

  関連: 楽観ロック、悲観ロック

• Lambda の呼び出しモデル（同期/非同期/ストリーム）

  同期呼び出し＝結果を待つ（API Gateway 等）。非同期呼び出し＝キューに入れ後で実行、失敗は自動リトライ＋デッドレターキュー/送信先（Destinations）。ストリーム/ポーリング＝イベントソースマッピング（SQS/Kinesis）。失敗時の扱いがモデルで異なる。

  前提: AWS Lambda、Kinesis Data Streams、Amazon API Gateway、ポーリング vs Webhook（プッシュ/プル）

  関連: イベントソースマッピングと送信先

• SageMaker 組み込みアルゴリズムの選定

  課題と出力の種類でアルゴリズムを選ぶ。表形式の分類/回帰は XGBoost（欠損・スケールに頑健な勾配ブースティング木）、線形/疎なら Linear Learner、推薦は Factorization Machines。クラスタリングは K-Means、次元削減は PCA、ストリーミング異常検知は Random Cut Forest。時系列予測は DeepAR（複数系列を 1 モデルで学習・確率的予測・コールドスタートに強い）、テキスト分類/埋め込みは BlazingText（Word2Vec）。コード不要の最適化は Autopilot（AutoML）。

  前提: Amazon SageMaker、k-means クラスタリング、SageMaker Autopilot

  関連: 勾配ブースティング、アンサンブル学習（バギング/ブースティング）

• マルチリージョン構成（アクティブ-アクティブ/スタンバイ）

  複数リージョンへ展開し、地域障害や低遅延に備える構成。アクティブ-アクティブ＝両リージョンで処理（高可用・高コスト・データ整合が課題）。アクティブ-スタンバイ＝片方は待機（フェイルオーバーで昇格）。Route 53・Global Accelerator・グローバルテーブルで実現する。

  前提: AWS Global Accelerator、Amazon Route 53、性能の指標（IOPS/スループット/帯域幅/レイテンシー）

  関連: DynamoDB の設計機能（GSI/DAX/Global Tables）

• CIDR 表記

  IP アドレス範囲を「/24」のようなプレフィックス長で表す記法。/24 は 256 個、/16 は 65,536 個のアドレスを含み、数字が小さいほど範囲が広い。VPC/VNet やサブネットの設計、ルーティングの最長一致判定、ファイアウォールルールの許可範囲指定など、あらゆるクラウドのネットワーク設計の基礎になる。

• OpenSearch Serverless（ベクトルエンジン）

  プロビジョニング不要で k-NN ベクトル検索を提供する OpenSearch。Bedrock Knowledge Bases の既定のベクトルストアとして使われ、埋め込みの近似最近傍探索で関連チャンクを高速取得する。Aurora pgvector や Pinecone 等が代替。

  前提: Amazon Bedrock、Amazon Aurora、Amazon OpenSearch Service、チャンキング（分割戦略）

  関連: Amazon Bedrock Knowledge Bases

• 機密データ保護（PII / マスキング）

  PII（個人を特定できる情報）や PHI などの機密データを守る運用。Macie で検出・分類し、暗号化・アクセス制御・最小化で保護。マスキング/トークン化で値を秘匿し、データ分類に応じて扱いを変える。ログへの機密混入も防ぐ。

  前提: テキスト前処理（トークン化/TF-IDF/n-gram）

  関連: Amazon Macie

• AssumeRole

  STS の API 操作で、指定した IAM ロールを引き受けて一時認証情報を得る仕組み。信頼ポリシーで引き受け元を限定する。クロスアカウントや第三者アクセスの基礎。

  前提: AWS IAM、一時認証情報

  関連: 信頼ポリシー

• Auto Scaling のポリシーとライフサイクルフック

  スケーリング方式＝ターゲット追跡（指標を目標値に維持）・ステップ・スケジュール・予測。ライフサイクルフックで起動/終了時に初期化や排出（ドレイン）を挟む。

  前提: Auto Scaling、ML データ準備（エンコード/スケーリング/不均衡）

• VPC エンドポイント

  VPC を AWS サービスへプライベート接続する入口。ENI を作るインターフェイスエンドポイント（PrivateLink 経由・多くのサービス）と、S3/DynamoDB 専用のゲートウェイエンドポイント（ルートテーブル経由・無料）がある。

  前提: Amazon DynamoDB、ルートテーブル、AWS PrivateLink

• ベクトルデータベース

  埋め込みベクトルを格納し近傍検索する基盤。RAG の検索層に使い、AWS では OpenSearch Service（k-NN）・Aurora/RDS の pgvector・MemoryDB・DocumentDB 等を用いる（Amazon Kendra はベクトル DB でなく別カテゴリのマネージド検索）。

  前提: Amazon Kendra、Amazon Aurora、Amazon DocumentDB、Amazon MemoryDB

• API Gateway キャッシュ

  ステージ単位で有効化する応答キャッシュ。指定した TTL の間、同一リクエストへバックエンド（Lambda 等）を呼ばず保存済みの応答を返し、レイテンシとバックエンド負荷を削減する。キャッシュサイズは 0.5GB〜237GB から選び、時間課金が発生する。

  前提: AWS Lambda、Amazon API Gateway、性能の指標（IOPS/スループット/帯域幅/レイテンシー）

  関連: API キーと使用量プラン、API Gateway ステージ

• Auto Scaling スケーリングポリシー

  Auto Scaling の増減方式。ターゲット追跡＝指標を目標値に保つ（推奨・最も簡単）、ステップスケーリング＝超過幅に応じ段階的に増減、シンプルスケーリング＝1回調整してクールダウン待ち、スケジュールスケーリング＝時刻ベース、予測スケーリング＝ML 予測。

  前提: クールダウンとウォームアップ、Auto Scaling、ML データ準備（エンコード/スケーリング/不均衡）、Auto Scaling のポリシーとライフサイクルフック

• 監査証跡

  誰がいつ何をしたかを後から追跡できる記録。AWS では CloudTrail が API 呼び出しを記録し、改ざん検知やインシデント調査に使う。

  前提: AWS CloudTrail

  関連: 変更管理、コンプライアンス報告

• AWS Artifact

  AWSのコンプライアンス報告書や契約（ISO/SOC等の監査証跡）をオンデマンドで入手できる。

  前提: 監査証跡、料金モデル（オンデマンド/Savings Plans・RI/スポット）、コンプライアンス報告

• AWS Direct Connect

  オンプレミスと AWS を専用線で直結するネットワークサービス。インターネットを経由しないため低遅延・安定した帯域を得られ、大容量データ転送や一貫した遅延が必要なワークロードに向く。冗長化には複数ロケーションからの接続や Site-to-Site VPN との併用（フェイルオーバー）が推奨される。

  前提: 性能の指標（IOPS/スループット/帯域幅/レイテンシー）

  関連: AWS Site-to-Site VPN

• AWS KMS

  暗号鍵（KMS key。旧称 CMK／カスタマーマスターキー）の作成・管理・ローテーションを行うマネージドサービス。S3・EBS 等のデータを暗号化し、鍵の使用を IAM と鍵ポリシーで制御・CloudTrail で監査する。KMS key には AWS 管理と顧客管理（customer managed key）などの種類があり、両者は同義ではない。

  前提: AWS CloudTrail、マネージドサービス（管理の境界）

• Amazon RDS

  マネージドなリレーショナル（SQL）データベースサービス。MySQL・PostgreSQL・MariaDB・Oracle・SQL Server エンジンに対応し、パッチ適用・バックアップ・マルチ AZ 冗長化・リードレプリカを AWS が運用する。

  前提: RDS マルチ AZ とリードレプリカ

• Amazon S3

  オブジェクトストレージ。画像・バックアップ・配布物を高耐久で保存しHTTP(S)でアクセス。ストレージクラス（Standard/IA/Glacier）でコスト最適化。

  前提: 耐久性と可用性（ナイン）、オブジェクトストレージ

• プロビジョンドスループットの最適化

  Bedrock のプロビジョンドスループット（モデルユニットを予約し安定容量を確保）を無駄なく使う運用。利用率を監視し、ピークに合わせて確保しつつオフピークはオンデマンドへ寄せる。常時高負荷なら割安、散発負荷ならオンデマンドが有利。

  前提: Bedrock の推論モード（オンデマンド/プロビジョンド）、Amazon Bedrock、料金モデル（オンデマンド/Savings Plans・RI/スポット）、スループット最適化（生成 AI）

• CloudWatch Network Monitor

  オンプレミスとAWSを結ぶハイブリッド接続（Site-to-Site VPN・Direct Connect）のネットワーク経路を能動的にプローブし、レイテンシやパケットロスを監視するサービス。障害箇所がAWS側かオンプレ側かの切り分けに使う。

  前提: AWS Direct Connect、Amazon CloudWatch、AWS Site-to-Site VPN、性能の指標（IOPS/スループット/帯域幅/レイテンシー）

  関連: CloudWatch Internet Monitor

• CodeDeploy（デプロイグループ/エージェント）

  デプロイグループ＝対象（EC2 タグ・ASG・ECS/Lambda）と方式（インプレース/Blue-Green・カナリア/線形）をまとめた単位。appspec.yml でライフサイクルフックを定義し、検証して失敗時は自動ロールバックする。EC2 には CodeDeploy エージェントが必要。

  前提: AWS Lambda、Auto Scaling のポリシーとライフサイクルフック

  関連: AWS CodeBuild

• 統制の種類（予防的/検出的/対応的）

  セキュリティ統制の分類。予防的＝そもそも起こさせない（SCP・IAM・SG）。検出的＝起きたことを見つける（Config・GuardDuty・CloudTrail）。対応的（是正）＝自動で直す（SSM Automation・Config 修復）。多層で組み合わせる。Control Tower のガードレールもこの考え方。

  前提: AWS CloudTrail、Amazon GuardDuty、AWS Control Tower、Amazon Detective

• コストと使用状況レポート（CUR）

  AWS が提供する最も詳細な請求データのレポート。時間単位の使用量・料金・割引適用の内訳などを CSV/Parquet 形式で S3 に出力し、Athena や QuickSight と連携した高度な分析・チャージバックの基礎データとして使う。

  前提: コスト配分（チャージバック/ショーバック）、Amazon Athena、列指向フォーマット（Parquet/ORC）、Amazon QuickSight

  関連: コストカテゴリとコスト配分タグ

• コストガバナンス

  クラウド費用を組織的に統制する運用。予算（Budgets）と異常検知でアラート、コスト配分タグとカテゴリで可視化、SCP/Service Quotas で過剰リソースを抑制、購入オプション（RI/SP/Spot）で最適化。FinOps の実践基盤。

  前提: 料金モデル（オンデマンド/Savings Plans・RI/スポット）、コスト配分（チャージバック/ショーバック）、AWS Budgets、AWS Cost Explorer

• Container Insights / Lambda Insights

  ECS/EKS のコンテナと Lambda 関数向けに、CPU・メモリ・ディスク・ネットワークなどの詳細な運用メトリクスとログを自動収集する CloudWatch の拡張機能。ダッシュボードや異常検出アラームの入力として、コンテナ/サーバーレス基盤特有のボトルネックを可視化する。

  前提: AWS Lambda、Amazon CloudWatch、サーバーレス（FaaS）

  関連: CloudWatch ServiceLens、CloudWatch Synthetics

• ログの S3 エクスポート

  CloudWatch Logs に溜まったログを S3 バケットへエクスポートし、長期保管やコスト最適化（Glacier への階層化）、または別ツールでの分析に回す機能。エクスポートはバッチジョブで非リアルタイム。継続的なストリーミング転送が必要な場合は Kinesis Data Firehose のサブスクリプションフィルタを使う。

  前提: CloudWatch Logs、Amazon Data Firehose、Kinesis Data Streams、Amazon CloudWatch

• CloudWatch メトリクスストリーム

  メトリクスを Data Firehose 経由でほぼリアルタイムに S3 やサードパーティ（Datadog 等）へ継続配信する機能。ポーリング型の GetMetricData より低遅延・低負荷で外部監視基盤と連携できる。

  前提: CloudWatch メトリクス、Amazon Data Firehose、Amazon CloudWatch、性能の指標（IOPS/スループット/帯域幅/レイテンシー）

• CloudWatch ServiceLens

  メトリクス・ログ・X-Ray トレースを 1 画面で相関付けて表示する CloudWatch の機能。サービスマップ上でレイテンシやエラーの発生箇所を視覚的に特定でき、分散システムの根本原因分析（RCA）を素早く進められる。

  前提: Amazon CloudWatch、AWS X-Ray、性能の指標（IOPS/スループット/帯域幅/レイテンシー）

  関連: Container Insights / Lambda Insights、CloudWatch Synthetics

• Glue クローラ

  データソースをスキャンしてスキーマとパーティションを推論し、Glue データカタログにテーブル定義を自動登録/更新するコンポーネント。

  前提: Glue データカタログ

  関連: AWS Glue

• Amazon MemoryDB

  Redis 互換で耐久性のあるインメモリデータベース。超低遅延かつデータ永続化が必要なワークロードに向く（キャッシュ専用は ElastiCache）。

  前提: 耐久性と可用性（ナイン）、性能の指標（IOPS/スループット/帯域幅/レイテンシー）

• Amazon QuickSight

  サーバーレスな BI ダッシュボードサービス。Athena/Redshift/RDS などをデータソースに可視化し、SPICE（インメモリエンジン）で高速化、行/列レベルセキュリティで出し分け、Q（自然言語質問）や埋め込みにも対応。可視化が役割で、クエリエンジンそのものではない。

  前提: Amazon Redshift、Amazon Athena、サーバーレス（FaaS）

• テーブルフォーマット（Iceberg/Hudi/Delta）

  S3 のデータレイクに ACID トランザクション・更新/削除（upsert/delete）・スキーマ進化・タイムトラベルをもたらすオープンテーブルフォーマット。

  前提: データレイク

• Amazon Macie

  機械学習で S3 内の機微データ（個人情報＝PII、認証情報など）を検出・分類するサービス。データ保護のコンプライアンスを支援し、検出結果は Security Hub に集約して継続的に監視できる。

  関連: 機密データ保護（PII / マスキング）

• 耐久性と可用性（ナイン）

  耐久性＝データを失わない確率（S3 は 99.999999999%＝イレブンナイン＝ほぼ消失しない）。可用性＝サービスにアクセスできる確率（例 99.99%＝年約52分のダウン）。両者は別概念。SLA は可用性で示されることが多い。

• DynamoDB の書き込み制御（条件付き/トランザクション）

  条件付き書き込みで競合を防ぎ、楽観的ロック（バージョン番号）で上書きを検出。複数項目の整合性はトランザクション（TransactWriteItems）で担保し、読み取りは Query（キー）と Scan（全走査）を使い分ける。

  前提: Amazon DynamoDB

  関連: 楽観ロック

• エッジコンピューティング

  ユーザーやデータの近く（エッジ）で処理し、遅延を減らす考え方。AWS では CloudFront/Lambda@Edge/CloudFront Functions（配信エッジ）、Local Zones・Wavelength（低遅延ゾーン）、Outposts（オンプレ）で実現する。

  前提: CloudFront のオリジン保護（OAC）とエッジ関数、エッジ拡張（Local Zones / Outposts / Wavelength）、Amazon CloudFront、AWS Lambda

• 保管時の暗号化（at rest）

  ディスクやオブジェクトストレージ上に保存されているデータを暗号化すること。クラウドの多くのマネージドストレージ（ブロック/ファイル/オブジェクト/DB）はサービス側の鍵管理（KMSなど）と統合した暗号化オプションを持つ。盗難・不正アクセスからデータ本体を守る基本対策。

  前提: オブジェクトストレージ

• 生成 AI の継続的監視（ドリフト/バイアス）

  本番の生成品質を継続監視し、データドリフト・バイアスドリフト・ガードレール違反・コスト/レイテンシ異常を自動検知して是正につなげる運用。CloudWatch メトリクス・Bedrock のログ・モデル評価・人手レビューを組み合わせる。

  前提: Bedrock Model Evaluations、Amazon Bedrock、CloudWatch メトリクス、Amazon CloudWatch

• リージョン内の回復性（容量・スロットリング対策）

  生成 AI 呼び出しの容量逼迫やスロットリングに耐える設計。キャパシティ予約（プロビジョンドスループット）、キュー＋指数バックオフでの再試行、複数モデルへのフォールバック、クロスリージョン推論を組み合わせて可用性を保つ。

  前提: Bedrock の推論モード（オンデマンド/プロビジョンド）、Cross-Region Inference（クロスリージョン推論）、オンデマンドキャパシティ予約、指数バックオフ

• AWS SAM（Serverless Application Model）

  サーバーレス（Lambda/API Gateway/DynamoDB 等）向けに CloudFormation を簡潔に書ける拡張。短い構文がデプロイ時に CloudFormation テンプレートへ展開される。sam local でローカル実行・テストも可能。

  前提: AWS CloudFormation、Amazon DynamoDB、AWS Lambda、Amazon API Gateway

• アイデンティティベースポリシー

  IAM のユーザー・グループ・ロールにアタッチし、「そのプリンシパルが何をできるか」を定義するポリシー。マネージドポリシー（AWS管理/カスタマー管理）とインラインポリシーがあり、同一アカウント内の権限付与の基本形になる。

  前提: IAM インラインポリシー、プリンシパル、IAM ユーザー

  関連: リソースベースポリシー

• IAM インラインポリシー

  単一のIAMユーザー・グループ・ロールに直接埋め込まれ、その対象と1対1で厳密に紐づくポリシー。他のIDにアタッチして再利用することはできず、対象を削除すればポリシーも一緒に消える。特定の1つのIDだけに例外的な権限を持たせたい限定的な用途で使う。

  前提: AWS IAM、IAM ユーザー

  関連: IAM 管理ポリシー

• 起動テンプレート

  AMI・インスタンスタイプ・ユーザーデータ・ネットワーク等の起動設定をひとまとめにしたバージョン管理可能な定義。Auto Scaling や Spot で使う。旧来の起動設定（launch configuration）はレガシー。

  前提: Auto Scaling、料金モデル（オンデマンド/Savings Plans・RI/スポット）、ユーザーデータ、ML データ準備（エンコード/スケーリング/不均衡）

• MCP（Model Context Protocol）

  LLMアプリケーションとツール／データソースの接続方法を標準化するオープンプロトコル。従来は連携先ごとに個別の統合コードが必要だったが、MCPサーバーとして公開すればどのMCP対応クライアント（エージェント）からも共通の形式で呼び出せる。AWSではLambda等で実装したツールをMCPサーバーとして公開する構成が使われる。

  前提: AWS Lambda、AWS Glue、ML データ準備（エンコード/スケーリング/不均衡）

  関連: Function Calling（関数呼び出し）

• PII マスキング（生成 AI）

  生成AIの入出力やログに含まれる個人情報（PII）のトークンを、他の値に置換・編集（redaction）して秘匿する対策。Amazon Comprehendによる検出結果やBedrock Guardrailsの機密情報フィルタが、プロンプト・応答・ログの該当箇所をマスクし、データ漏えいや規制違反を防ぐ。

  前提: Amazon Bedrock、Amazon Comprehend、機密データ保護（PII / マスキング）

  関連: Bedrock Guardrails

• プロンプトガバナンス

  プロンプトを資産として統制する運用。Bedrock Prompt Management でテンプレート化・バージョン管理・デプロイ（エイリアス）し、Guardrails で逸脱を抑え、CloudTrail/CloudWatch Logs で API 操作やアクセスを監査する。どのプロンプト版を誰がいつ使ったかを追跡可能にする。

  前提: Amazon Bedrock Prompt Management、Amazon Bedrock、AWS CloudTrail、CloudWatch Logs

• Amazon SNS

  パブリッシュ/サブスクライブのメッセージング。1つのメッセージを多数の購読者へファンアウトする（プッシュ型・1対多）。SNS＋SQS でファンアウト構成。

  前提: ポーリング vs Webhook（プッシュ/プル）

• AWS Compute Optimizer

  EC2・EBS・Lambda・Auto Scaling グループなどの使用状況を機械学習で分析し、過剰/不足プロビジョニングを検出して適切なサイジングを推奨するサービス。コスト最適化の起点となる。

  前提: Auto Scaling、AWS Lambda、ML データ準備（エンコード/スケーリング/不均衡）

• Amazon EventBridge

  イベント駆動アーキテクチャの中核となるサーバーレスのイベントバス。多数のソースからイベントを受け取り、ルールでフィルタして Lambda や Step Functions などへ配信し、サービス間を疎結合にする。

  前提: AWS Lambda、AWS Step Functions、疎結合（デカップリング）、SNS ファンアウトとイベント駆動

• Route 53 ルーティングポリシー

  DNS 応答の返し方を制御するポリシー群。フェイルオーバールーティング（ヘルスチェックで待機系へ）、レイテンシールーティング（最も近いリージョンへ）、加重ルーティング（割合配分）、位置情報ルーティングなどで可用性と性能を高める。

  前提: 性能の指標（IOPS/スループット/帯域幅/レイテンシー）

  関連: Amazon Route 53

• Amazon Detective

  GuardDuty/CloudTrail/VPC フローログからエンティティの振る舞いグラフを構築し、検出（finding）を起点に攻撃の経緯・影響範囲・根本原因を時系列で調査するサービス。GuardDuty が「検知」、Detective が「調査」を担う。

  前提: AWS CloudTrail、Amazon GuardDuty、ブラストラディウス（影響範囲）

• SSM Document（ドキュメント）

  Systems Manager が実行する処理を定義した JSON/YAML 定義。Command 文書（Run Command 用）・Automation 文書（ランブック）・Session 文書などの種類があり、AWS 提供と自作がある。

  前提: JSON、Run Command、AWS Systems Manager（SSM）、SSM Automation（ランブック）

• タグエディタ（Tag Editor）

  アカウント内の既存リソースを横断検索し、タグを一括で追加・編集・削除できるコンソールツール。タグ付け戦略を後から徹底したい場合や、コスト配分タグの一括付与に使う。リソースを1件ずつ開いてタグ編集する手間を省く。

  前提: コスト配分（チャージバック/ショーバック）、AWS Cost Explorer、IAM ポリシーの構造（Effect/Action/Resource/Condition）、タグ付け戦略

  関連: AWS Resource Groups

• TLS

  通信を暗号化し、証明書によってサーバー（要件次第ではクライアントも）を認証するプロトコル。ハンドシェイクで鍵交換と認証を行った後、対称鍵でデータを暗号化して送受信する。クラウドのロードバランサやCDNで終端し、証明書はマネージドサービスで発行・更新するのが一般的。

  前提: マネージドサービス（管理の境界）

  関連: HTTPS

• X-Ray のサンプリングとサブセグメント

  サンプリング＝全リクエストでなく一部だけトレースし、オーバーヘッドとコストを抑える（ルールで率を制御）。セグメント/サブセグメント＝1 トレース内のサービス区間/内部処理（DB 呼び出し等）。アノテーションでフィルタ用のメタデータを付ける。

  関連: AWS X-Ray

• 推論の種類（リアルタイム/バッチ）

  リアルタイム推論は低遅延で 1 件ずつ応答、バッチ推論は大量データをまとめて非同期処理する。レイテンシ要件とコストで選ぶ。

  前提: SageMaker 推論方式、性能の指標（IOPS/スループット/帯域幅/レイテンシー）

  関連: 非同期処理（生成 AI）

• Amazon Bedrock AgentCore

  任意のフレームワーク（CrewAI/LangGraph/LlamaIndex/Strands 等）と任意のモデルで本番 AI エージェントを動かすエージェントプラットフォーム。モジュール式サービス＝Runtime（サーバーレス・セッション分離）/Memory（短期・長期記憶）/Gateway（API・Lambda を MCP ツール化）/Identity（エージェント認証）/Code Interpreter/Browser/Observability を、インフラ管理なしで提供する。

  前提: Strands Agents、Amazon Bedrock、AWS Lambda、サーバーレス（FaaS）

• Amazon Kendra

  自然言語で社内文書を検索できるインテリジェント検索サービス。多様なデータソースをコネクタで取り込み、質問に対して関連箇所を提示する（RAG の検索基盤にも使われる）。

  関連: Amazon Lex

• Application Load Balancer（ALB）

  L7 のロードバランサ。ホスト/パスベースルーティング、ターゲットグループ、スティッキーセッション、認証統合（OIDC/Cognito）に対応し、HTTP アプリの振り分けに使う。

  前提: Amazon Cognito、ALB の機能（ルーティング/スティッキー/ターゲットグループ）

• CloudFront のオリジン保護（OAC）とエッジ関数

  Origin Access Control（OAC、旧 OAI）は S3 を非公開のまま CloudFront 経由のアクセスだけを許可する仕組みで、SSE-KMS や全リージョン・全 HTTP メソッドに対応する現行の推奨。エッジでのコード実行は、超軽量・ビューワーのみの CloudFront Functions（ヘッダー操作/リダイレクト/URL 書き換え）と、オリジンイベントや外部呼び出しも可能な Lambda@Edge を用途で使い分ける。

  前提: Amazon CloudFront、AWS Lambda、S3 の暗号化と公開防止

• AWS Global Accelerator

  2 つの静的 anycast IP を提供し、ユーザーを最寄りエッジから AWS バックボーンに乗せて最適リージョンへ低遅延で届けるサービス。TCP/UDP の任意ポートに対応し、ヘルスチェックに基づく秒単位の高速リージョンフェイルオーバーが可能（キャッシュはしない）。エンドポイントグループのトラフィックダイヤルで流量を絞る。

  前提: エニーキャスト、性能の指標（IOPS/スループット/帯域幅/レイテンシー）

• API Gateway ステージ

  API の特定のデプロイをひも付ける名前付き環境（dev/prod 等）。ステージ変数でバックエンドの接続先を環境ごとに切り替えられ、トラフィックの一部だけ新デプロイへ流すカナリアリリースにも対応する。ステージごとに個別の設定（スロットリング・ログレベル）を持てる。

  前提: Amazon API Gateway、API Gateway の機能（ステージ・スロットリング・統合）

  関連: API キーと使用量プラン、API Gateway キャッシュ

• AWS App Runner

  ソースコードまたはコンテナイメージから Web アプリ/API を自動でビルド・デプロイ・スケールするフルマネージドサービス。インフラ（ロードバランサー/オートスケール/証明書）を意識せずコンテナ化アプリを公開でき、ECS/Fargate より運用負荷が低い。DevOps では「簡単なコンテナ Web サービスを最小運用で動かす」選択肢。

  前提: AWS Fargate、コンテナ化、マネージドサービス（管理の境界）

• AWS CLI

  AWS のサービスをコマンドラインから操作する公式ツール。プロファイル/認証情報・リージョン設定を持ち、シェルスクリプトや CI/CD ステップでの自動化に使う。`aws <service> <operation>` 形式で API を直接呼び、JSON 出力を jq 等で加工できる。

  前提: JSON

• AWS CodeBuild

  フルマネージドなビルド/テストサービス。buildspec.yml に定義した手順でソースをコンパイル・テストし、成果物を出力する。従量課金でビルドサーバーの管理が不要。

  前提: マネージドサービス（管理の境界）

  関連: CodeDeploy（デプロイグループ/エージェント）

• AWS Config

  リソースの構成を記録し、ルールへの準拠状況を評価する（構成変化の追跡）。

  前提: IAM ポリシーの構造（Effect/Action/Resource/Condition）

• AWS Copilot（CLI）

  コンテナ化アプリを ECS/Fargate/App Runner 上に構築・デプロイ・運用するためのコマンドラインツール。サービス種別（Load Balanced Web Service など）と環境（test/prod）を宣言するだけで、裏側の CloudFormation・パイプライン・ロギングを生成する。GitHub Copilot とは無関係。

  前提: AWS App Runner、AWS CloudFormation、AWS Fargate、コンテナ化

• ブロックストレージ

  OS がボリュームとしてマウントして使う低遅延ストレージ（EBS）。データベースや起動ディスク向き。多くは1つのインスタンスに接続して使うが、EBS Multi-Attach など複数インスタンスから同時アタッチできる構成も存在する。

  前提: 性能の指標（IOPS/スループット/帯域幅/レイテンシー）

  関連: ファイルストレージ、オブジェクトストレージ

• CloudFront 地理的制限（Geo Restriction）

  ディストリビューション単位で、国コードによる許可リスト（ホワイトリスト）または拒否リスト（ブラックリスト）を設定し配信を制御する機能。コンテンツライセンスや輸出規制など地域限定要件への対応に使う。IP位置情報ベースで判定するため、VPN経由のアクセスでは回避されうる。

  前提: Amazon CloudFront、Route 53 ルーティングポリシー、SCP 拒否リスト戦略

  関連: CloudFront 自動圧縮（コンテンツ圧縮）

• CloudFront 無効化（Invalidation）

  パスを指定して CloudFront エッジに残るキャッシュを TTL 期限前に強制的に削除し、次のリクエストでオリジンから最新のコンテンツを取得させる操作。月 1,000 パスまでは無料枠があるが、頻繁な無効化はコストと若干の遅延を伴うため、本来はキャッシュポリシーやバージョニングされたファイル名での回避が推奨される。

  前提: Amazon CloudFront、エッジロケーション、CloudFront キャッシュポリシー、性能の指標（IOPS/スループット/帯域幅/レイテンシー）

• CloudFront 署名付き URL

  個別ファイル単位で有効期限・IP・カスタムポリシーを指定してアクセスを制限する URL。1つの署名付き URL は1つのオブジェクトにのみ対応するため、多数のファイル（動画のセグメント等）を配信する場合はリクエストごとに生成する手間がかかる。CloudFront キーペア（または信頼された鍵グループ）で署名する。

  前提: Amazon CloudFront、S3 の開発機能（署名付き URL・暗号化）、X-Ray のサンプリングとサブセグメント

  関連: CloudFront 署名付き Cookie

• Amazon ECS（Elastic Container Service）

  AWS ネイティブのコンテナオーケストレーション。タスク定義でコンテナを記述し、EC2 起動タイプ（自前管理）か Fargate 起動タイプ（サーバーレス）で実行する。タスク/サービス単位でスケールする。

  前提: AWS Fargate、サーバーレス（FaaS）

• コンテキストウィンドウの最適化

  モデルのコンテキストウィンドウ（有限のトークン上限）を効率よく使うための設計。RAGでは関連度の高いチャンクだけを検索・投入し、会話履歴は要約や古い発言のトリミングで圧縮し、無関係な情報を渡さないことで応答品質とレイテンシ/コストを両立させる。

  前提: 会話履歴 / セッションメモリ、性能の指標（IOPS/スループット/帯域幅/レイテンシー）、チャンキング（分割戦略）

  関連: コンテキストウィンドウ超過

• コストカテゴリとコスト配分タグ

  支出をプロジェクトや部門などの組織単位へ按分するための仕組み。コスト配分タグはリソースに付けたタグ単位で費用を集計し、コストカテゴリはアカウントやタグ、サービスなどのルールを組み合わせて任意の階層でコストをグルーピングする。Cost Explorer やレポートのフィルタ軸として使う。

  前提: AWS Cost Explorer、IAM ポリシーの構造（Effect/Action/Resource/Condition）

  関連: コスト配分（チャージバック/ショーバック）、コストと使用状況レポート（CUR）

• クロスアカウントアクセス

  あるアカウントのプリンシパルが別アカウントのロールを AssumeRole して行うアクセス。信頼ポリシーで許可し、第三者には ExternalId を使って混乱した代理（confused deputy）を防ぐ。

  前提: プリンシパル、信頼ポリシー、AssumeRole

• CloudWatch アラームの状態

  アラームは 3 状態をとる。OK＝しきい値内。ALARM＝しきい値を超過。INSUFFICIENT_DATA＝データ不足（起動直後やメトリクス欠落）。状態遷移ごとにアクション（SNS 通知・Auto Scaling・EC2 アクション）を発火できる。

  前提: Auto Scaling、Amazon CloudWatch、EC2 ステータスチェックと自動回復、ML データ準備（エンコード/スケーリング/不均衡）

• CloudWatch Logs Insights

  CloudWatch Logs に貯めたログを専用クエリ言語で対話的に分析する機能。fields/filter/stats/sort/limit などでフィルタ・集計し、エラー件数や上位 IP などを素早く可視化する。スキャンしたデータ量に応じて課金。

  前提: CloudWatch Logs

  関連: Amazon CloudWatch

• CloudWatch Synthetics

  カナリア（設定可能なスクリプト）を定期実行し、エンドポイントやユーザーフローをユーザー視点で外形監視する CloudWatch の機能。実際のリクエストが届く前に可用性低下やレイテンシ悪化を検知でき、SLA 監視やヘルスチェックの補完に使う。

  前提: Amazon CloudWatch、性能の指標（IOPS/スループット/帯域幅/レイテンシー）

  関連: Container Insights / Lambda Insights、CloudWatch ServiceLens

• 接続プーリング

  データベースへの接続をあらかじめ確立してプールに保持し、リクエストのたびに新規接続を張るオーバーヘッドと接続数の枯渇を防ぐ仕組み。Amazon RDS Proxyが代表例で、Lambdaのようなサーバーレス/高並行なアプリで特に効果が大きい。

  前提: AWS Lambda、Amazon RDS、Amazon RDS Proxy、サーバーレス（FaaS）

• DynamoDB のキャパシティモード（オンデマンド/プロビジョンド+Auto Scaling）

  オンデマンド＝容量管理不要で需要に自動追従（予測困難な負荷・使った分だけ課金）。プロビジョンド＝RCU/WCU を設定し、Auto Scaling で利用率の目標に追従させる（予測可能な負荷で割安、予約キャパシティで更に割引）。負荷特性で選ぶ。

  前提: Auto Scaling、Amazon DynamoDB、料金モデル（オンデマンド/Savings Plans・RI/スポット）、ML データ準備（エンコード/スケーリング/不均衡）

• コンパクション（小ファイル統合）

  多数の小ファイルを少数の大きなファイルにまとめ、メタデータ負荷とスキャンのオーバーヘッドを下げて読み取り性能を改善する処理。

• Amazon DocumentDB

  MongoDB 互換のマネージドドキュメントデータベース。JSON ライクな柔軟なドキュメントを扱うワークロードに向く。

  前提: JSON

• Amazon EMR

  Apache Spark/Hadoop/Hive/Presto などをクラスタで実行するマネージドビッグデータ基盤。超大規模なカスタム分散処理や既存 Hadoop/Spark 資産の移行に向く（軽量なサーバーレス ETL は Glue が手軽）。

  前提: AWS Glue、サーバーレス（FaaS）

• Managed Service for Apache Flink

  ストリームをその場でウィンドウ集計・変換するリアルタイム処理サービス。低遅延の連続的なストリーム分析に使う。

  前提: マネージドサービス（管理の境界）、性能の指標（IOPS/スループット/帯域幅/レイテンシー）

• Glue Data Quality（DQDL）

  データカタログやパイプライン上のデータ品質を、DQDL（ルール定義言語）で表現したルールに照らして検証・スコアリングする機能。

  関連: AWS Glue

• Redshift Serverless

  クラスター管理なしで使う Redshift。使用量（RPU）に応じて自動でスケールし、断続的・予測しにくい分析ワークロードのコストを最適化する。

  前提: Amazon Redshift、サーバーレス（FaaS）

• 配信セマンティクス（少なくとも1回/正確に1回）

  メッセージ配信の保証レベル。少なくとも1回（at-least-once）＝重複し得る（標準 SQS・要べき等処理）。正確に1回（exactly-once）＝重複も欠落もなし（SQS FIFO）。最大1回（at-most-once）＝欠落し得るが重複なし。設計はべき等性で重複に耐える。

  前提: べき等性

• Amazon Inspector

  EC2・ECR コンテナイメージ・Lambda の既知の脆弱性（CVE）を継続的にスキャン・評価するサービス。検出結果は重大度スコア付きで Security Hub に集約でき、CI/CD パイプラインに組み込んで脆弱なイメージのデプロイをブロックできる。

  前提: AWS Lambda

• API Gateway の機能（ステージ・スロットリング・統合）

  ステージ（dev/prod 等）でデプロイを分け、ステージ変数で切り替える。スロットリングとキャッシュで保護・高速化し、Lambda プロキシ統合やマッピングテンプレートでリクエスト/レスポンスを変換、CORS を構成する。

  前提: AWS Lambda、Amazon API Gateway

• Amazon Cognito

  アプリのユーザー認証/認可。ユーザープール＝サインアップ/サインイン（認証）で JWT を発行、アイデンティティプール＝トークンを一時 AWS 認証情報に交換（AWS 認可）。外部 IdP とのフェデレーションや MFA に対応。

• S3 の開発機能（署名付き URL・暗号化）

  署名付き URL で一時的なアップロード/ダウンロード権限を発行し、マルチパートアップロードで大容量を分割並列化。暗号化は SSE-S3・SSE-KMS・SSE-C・クライアントサイドから選ぶ。

  前提: S3 の性能機能（Transfer Acceleration / S3 Select）、S3 の暗号化と公開防止

• オンデマンドキャパシティ予約

  特定 AZ で必要なインスタンス容量を、長期契約なしに確保する仕組み。重要ワークロードや DR で「いざ起動できない」を防ぐ。Savings Plans と組み合わせて割引も適用できる（容量保証＋コスト最適化）。

  前提: 料金モデル（オンデマンド/Savings Plans・RI/スポット）、DynamoDB の容量と TTL

• インスタンスメタデータサービス（IMDS）

  EC2 内から自身の情報（インスタンス ID・IAM ロールの一時認証情報・ユーザーデータ等）を取得できる 169.254.169.254 のエンドポイント。IMDSv2 はセッショントークンを必須化し SSRF による認証情報窃取を防ぐ（強制を推奨）。

  前提: AWS IAM、ユーザーデータ、インスタンスメタデータ（IMDSv2）、一時認証情報

• 非同期処理（生成 AI）

  時間のかかる生成や大量バッチを、リクエスト/レスポンスを切り離して捌く設計。SQS にジョブを積み Lambda ワーカーで処理し、結果は保存/通知で返す。タイムアウト回避・スパイク吸収・コスト平準化に有効で、Bedrock のバッチ推論とも組み合わせる。

  前提: Amazon Bedrock、AWS Lambda、疎結合（デカップリング）

  関連: 推論の種類（リアルタイム/バッチ）

• 生成 AI の監視（固有メトリクス / golden dataset）

  生成 AI 固有の品質監視。正確性・グラウンディング率・有害性・拒否率・レイテンシ/コストを追い、golden dataset（基準となる入力と期待出力の集合）に対する回帰で品質劣化を検知する。CloudWatch・Bedrock ログ・人手評価を併用する。

  前提: Amazon Bedrock、Amazon CloudWatch、性能の指標（IOPS/スループット/帯域幅/レイテンシー）

• スループット最適化（生成 AI）

  生成 AI の処理量を高める最適化。トークン処理の効率化、バッチ推論、同時実行数の管理、プロビジョンドスループット、キャッシュを組み合わせ、スロットリングを避けつつ単位時間の処理を最大化する。

  前提: Bedrock の推論モード（オンデマンド/プロビジョンド）、推論の種類（リアルタイム/バッチ）、性能の指標（IOPS/スループット/帯域幅/レイテンシー）

• ヘルスチェックの種類としきい値

  正常性判定の設計。浅いチェック（プロセス生存）と深いチェック（依存先含む実機能）。正常しきい値/異常しきい値＝連続成功/失敗回数で状態を確定しフラッピングを抑える。間隔とタイムアウトも調整。ELB・Route 53・Auto Scaling で使う。

  前提: Auto Scaling、Amazon Route 53、ML データ準備（エンコード/スケーリング/不均衡）

• 水平スケーリング（スケールアウト）

  インスタンスの台数を増やして負荷を分散するスケーリング方式。ステートレス設計とロードバランサ・Auto Scalingが前提になり、1台の故障がシステム全体に影響しにくいため耐障害性も高まる。クラウドネイティブな設計では基本の方向性とされる。

  前提: Auto Scaling、ML データ準備（エンコード/スケーリング/不均衡）、フォールトトレランス（耐障害性）

• メッセージ順序保証

  送信順とおりに処理されることの保証。標準 SQS/SNS は順序を保証しない（高スループット）。FIFO はメッセージグループ単位で順序を保証する。順序が要る場合はグループ ID 設計や単一コンシューマーで対処する。

  前提: 性能の指標（IOPS/スループット/帯域幅/レイテンシー）

  関連: FIFO（順序保証/重複排除）

• エンドポイントの自動スケーリング

  リアルタイム推論エンドポイントの負荷に応じてインスタンス数を増減し、コストと遅延のバランスを取る。ゼロにスケールするサーバーレス推論もある。

  前提: ML データ準備（エンコード/スケーリング/不均衡）、SageMaker 推論方式、性能の指標（IOPS/スループット/帯域幅/レイテンシー）、サーバーレス（FaaS）

• AWS Billing and Cost Management

  請求・コスト管理の総称。請求ダッシュボード・コスト配分タグ・予算（Budgets）・コスト分析（Cost Explorer）を含み、ML 学習/推論のコストを把握・配分・最適化する。

  前提: コスト配分（チャージバック/ショーバック）、AWS Budgets、AWS Cost Explorer

• モダリティマッピング（前処理の振り分け）

  入力の種類に応じて適切な AWS サービスへ前処理を振り分ける設計。文書/画像＝Textract、音声＝Transcribe、一般画像理解＝Rekognition/マルチモーダル FM、テキスト正規化＝Comprehend。抽出・正規化してから生成 AI に渡す。

  前提: Amazon Comprehend、Amazon Rekognition、Amazon Textract、Amazon Transcribe

• マルチアカウント戦略

  ワークロード・環境・チームをアカウントで分離し、課金・セキュリティ・ブラストラディウスを区切る設計。Organizations＋OU＋SCP で統制し、Control Tower で標準化されたアカウントを払い出す（アカウントベンディング）。Landing Zone がその基盤。

  前提: AWS Organizations（一括請求）、ML データ準備（エンコード/スケーリング/不均衡）、ブラストラディウス（影響範囲）、AWS Control Tower

• AWS Site-to-Site VPN

  オンプレミスと VPC を IPsec で暗号化接続する VPN。インターネット経由で迅速・安価に構築でき、各接続は冗長な2トンネル。Direct Connect より帯域は劣るが、そのバックアップにも使う。

  前提: 性能の指標（IOPS/スループット/帯域幅/レイテンシー）

  関連: AWS Direct Connect

• 可観測性の三本柱（メトリクス/ログ/トレース）

  システムの内部状態を外から把握する3要素。メトリクス＝数値の時系列（傾向・アラート）、ログ＝個々の出来事の記録（原因調査）、トレース＝1リクエストの経路と遅延（ボトルネック特定）。AWS では CloudWatch＋X-Ray が担う。

  前提: Amazon CloudWatch、AWS X-Ray、性能の指標（IOPS/スループット/帯域幅/レイテンシー）

• 楽観ロック

  更新時にバージョン番号やタイムスタンプを比較し、他者による変更が無かった場合のみ書き込みを成功させる競合制御方式。事前にロックを取らないため並行性が高く、DynamoDBの条件付き書き込み（ConditionExpression）が代表的な実装。競合検出時はリトライで解決する。

  前提: Amazon DynamoDB

  関連: 冪等性キーパターン、DynamoDB の書き込み制御（条件付き/トランザクション）

• レート制限

  単位時間あたりに受け付けるリクエスト数の上限を管理し、過負荷や乱用（DoS・スクレイピング等）から後段のシステムを守る仕組み。API ゲートウェイや Web アプリケーションファイアウォールのレートベースルールとして実装されることが多い。

• ポート番号

  同じ IP アドレス上で動く複数のサービスを識別する 16 ビットの番号（例：HTTP は 80、HTTPS は 443、SSH は 22）。TCP・UDP のヘッダーに含まれ、ファイアウォールやセキュリティグループのルールは送信元/宛先ポートで通信を許可・拒否する。

  前提: HTTPS

  関連: TCP、UDP

• プロビジョンド vs サーバーレス

  容量モデルの対比。プロビジョンド＝事前に容量を確保（予測可能な負荷・常時稼働で割安なことも）。サーバーレス＝需要に自動追従し使った分だけ課金・容量管理不要（断続的/予測困難な負荷向け）。Aurora・DynamoDB・Lambda 等で選択肢になる。

  前提: Amazon DynamoDB、AWS Lambda、Amazon Aurora、サーバーレス（FaaS）

• Redshift の性能（RA3/WLM/分散キー）

  RA3＝コンピュートとストレージを分離（マネージドストレージ）。コンカレンシースケーリング＝同時実行ピークに一時的にクラスターを追加。ワークロード管理（WLM）＝キューで優先度/メモリを制御。分散キー（DISTKEY）と並べ替えキー（SORTKEY）で結合とスキャンを最適化する。

  前提: Amazon Redshift、ML データ準備（エンコード/スケーリング/不均衡）

• 単一障害点（SPOF）

  そこが壊れるとシステム全体が止まる箇所。マルチ AZ 配置・冗長化・ロードバランサ・自動フェイルオーバーで排除する。可用性設計の出発点＝SPOF を洗い出して潰す。

  前提: RDS マルチ AZ とリードレプリカ

• 堅牢な FM API 統合

  FM の API を本番品質で組み込む設計。ストリーミング/非同期で体感とスループットを上げ、スロットリングには指数バックオフ＋リトライ、X-Ray で分散トレース、エラーログと検証で切り分け、疎結合（イベント駆動）で障害を局所化する。

  前提: AWS X-Ray、指数バックオフ、疎結合（デカップリング）、性能の指標（IOPS/スループット/帯域幅/レイテンシー）

• S3 バケットキー

  SSE-KMSで暗号化する際、オブジェクトごとにKMSへ都度呼び出す代わりに、バケット単位の短命なデータキーを再利用してKMS呼び出し回数を大幅に削減する機能。KMSのAPIコストとリクエスト数によるスロットリングを抑えられ、大量のオブジェクトをSSE-KMSで扱う構成で有効化が推奨される。

  前提: エンベロープ暗号化とデータキー、S3 の暗号化と公開防止

  関連: S3 デフォルト暗号化、DSSE-KMS（二重レイヤー暗号化）

• S3 デフォルト暗号化

  バケットに新規保存するオブジェクトを自動的に暗号化する設定。現在は全てのS3バケットで既定で有効（SSE-S3）になっており、明示的に無効化することはできない。SSE-KMSやDSSE-KMSへ切り替えることで、より強い鍵管理やコンプライアンス要件に対応できる。

  前提: EBS 暗号化、DSSE-KMS（二重レイヤー暗号化）、S3 の暗号化と公開防止

  関連: S3 バケットキー

• S3 Object Lambda

  S3 の GET リクエストと元のバケットの間に Lambda 関数を挟み、応答データをその場で加工して返す機能。個人情報のマスキング、画像のリサイズ、CSV から JSON への変換などをアプリ側のコード変更やデータの複製なしに実現できる。

  前提: AWS Lambda、JSON、機密データ保護（PII / マスキング）、PII マスキング（生成 AI）

• SNS ファンアウトとイベント駆動

  1 つの SNS トピックから複数の SQS キューや Lambda へ同報配信するファンアウトで、疎結合な並列処理を実現する。EventBridge はルールでイベントを多数のターゲットへ振り分ける。

  前提: AWS Lambda、疎結合（デカップリング）、Amazon SNS

• AWS Control Tower

  マルチアカウント環境のセットアップと統制を自動化するサービス。ランディングゾーンを構築し、ガードレール（必須/推奨の予防・検出統制）を一括適用してベストプラクティスに沿った組織を素早く立ち上げる。

  前提: Amazon Detective

• AWS Firewall Manager

  WAF・Shield Advanced・セキュリティグループ・Network Firewall・Route 53 Resolver DNS Firewall のルールを、組織（Organizations）全体に一元適用・強制するサービス。新規アカウントにも自動適用できる。

  前提: AWS Organizations（一括請求）、Amazon Route 53、AWS Network Firewall、AWS Shield（Standard/Advanced）

• インスタンスメタデータ（IMDSv2）

  EC2 のインスタンスメタデータへのアクセスにセッショントークン（PUT→GET）を必須化する方式。SSRF 脆弱性を突いてインスタンスロールの一時認証情報を盗む攻撃を防ぐ。IMDSv1 は無効化し IMDSv2 を強制するのが推奨。

  前提: 一時認証情報

• AWS Shield（Standard/Advanced）

  DDoS 防御サービス。Standard は全 AWS で無料・自動の L3/L4 防御。Advanced は有償で、L7 防御・24/7 の DRT 支援・コスト保護・詳細レポートを追加する。WAF と組み合わせる。

  関連: AWS WAF

• Elastic IP と配置グループ

  Elastic IP は付け替え可能な固定パブリック IP。配置グループはインスタンスの物理配置を制御し、クラスター（低遅延）・スプレッド（障害分離）・パーティション（大規模分散）から選ぶ。

  前提: プレイスメントグループ（クラスター/分散/パーティション）、性能の指標（IOPS/スループット/帯域幅/レイテンシー）

  関連: パブリック IPv4 アドレスの挙動

• SSM Automation（ランブック）

  ランブック（手順の定義）で運用タスクや自動修復を実行する機能。EventBridge や Config の検出と連携して是正を自動化する。

• デッドレターキュー（DLQ）

  規定回数の処理に失敗したメッセージを退避する専用キュー。原因調査や再処理に使い、正常キューが毒メッセージで詰まるのを防ぐ。maxReceiveCount で移送のしきい値を決める。

  関連: SQS のリドライブ（DLQ からの再処理）

• タグ付け戦略

  リソースにキー/値のタグを一貫して付ける方針。コスト配分（部門別請求）、自動化（対象選択）、アクセス制御（ABAC）、棚卸しに使う。タグポリシーやコスト配分タグ、Config で準拠を強制・監視する。

  前提: コスト配分（チャージバック/ショーバック）、AWS Cost Explorer、タグポリシー（Organizations）

• TGW アタッチメント

  Transit Gateway に接続する個々の対象（VPC・VPN・Direct Connect ゲートウェイ・Direct Connect の Transit VIF・別 TGW との Peering）を表す単位。各アタッチメントはいずれか1つの TGW ルートテーブルに関連付けられ、その表を通じて他アタッチメントとの通信可否が決まる。

  前提: AWS Direct Connect、ルートテーブル、Transit Gateway、Transit Gateway ルートテーブル

• Transit Gateway ルートテーブル

  Transit Gateway に接続された各アタッチメント間の到達性を制御するルートテーブル。関連付け（アタッチメントをどのルートテーブルで経路解決するか）と伝播（他アタッチメントのルートを自動的に注入するか）を組み合わせ、本番/開発など環境間のセグメント分離を実現する。

  前提: ルートテーブル、Transit Gateway、X-Ray のサンプリングとサブセグメント

• Transit Gateway vs VPC ピアリング

  接続方式の選択。VPC ピアリングは 1 対 1・非推移的（A-B、B-C があっても A-C は通れない）でフルメッシュは管理が爆発する。Transit Gateway はハブ&スポークで多数の VPC/オンプレを集約し、ルートテーブルでセグメント制御する（大規模向け）。

  前提: ルートテーブル、Transit Gateway、VPC ピアリング、X-Ray のサンプリングとサブセグメント

• UDP

  コネクションを確立せず、順序保証や再送を行わない軽量なトランスポート層プロトコル。オーバーヘッドが小さく高速なため、DNS 問い合わせや動画/音声ストリーミングなど、多少の欠落より低遅延を優先する通信に使われる。

  前提: メッセージ順序保証、性能の指標（IOPS/スループット/帯域幅/レイテンシー）

  関連: ポート番号、TCP

• VPC エンドポイントの種類とプライベート DNS

  ゲートウェイ型（S3/DynamoDB のみ・ルートテーブル経由・無料）とインターフェイス型（PrivateLink・ENI＋プライベート IP・多数のサービス・時間課金）。プライベート DNS を有効にすると、公開サービス名のままエンドポイント経由で解決される。

  前提: Amazon DynamoDB、ルートテーブル、AWS PrivateLink、VPC エンドポイント

• VPC/サブネットのクォータ

  1リージョンあたりのVPC数、1VPCあたりのサブネット数など、VPCネットワーク設計に関わる上限値。これらはService Quotasで確認・引き上げ申請できる。一方、サブネットのCIDRサイズ（/16〜/28）はVPC/サブネットの仕様上の制約であり、Service Quotasの引き上げ対象ではない。サブネット自体のCIDR範囲は作成後に変更できないが、VPCにはセカンダリCIDRブロックを追加してアドレス空間を拡張できる。

  前提: CIDR 表記、Service Quotas、セカンダリ CIDR

  関連: サブネットの予約アドレス

• AI ガバナンス

  生成 AI を組織として統制する枠組み。モデルカード（用途・制約の文書化）、データ/モデルのリネージ（来歴追跡）、CloudTrail による監査証跡、承認フローとアクセス制御を組み合わせ、説明責任・コンプライアンス・再現性を担保する。

  前提: モデルの透明性（AI Service/Model Cards）、監査証跡、AWS CloudTrail

• Agents for Amazon Bedrock

  Amazon Bedrock Agents（旧 Agents for Amazon Bedrock）。タスクを段階に分解し、API（アクショングループ）やナレッジベースを呼び出して多段の処理を自律実行する Bedrock のエージェント機能。

  前提: Amazon Bedrock、Amazon Bedrock Knowledge Bases

• コンテキストウィンドウ超過

  入力＋出力トークンがモデルのコンテキストウィンドウ上限を超える状態。挙動はモデル/API により異なり（入力の切り捨て・エラー返却・古い会話履歴の脱落など）、回答が途中で切れる/情報が欠落する原因になる。動的チャンキング・プロンプト設計・応答長制限で対処する。

  前提: チャンキング（分割戦略）

  関連: 会話履歴 / セッションメモリ、コンテキストウィンドウの最適化

• Bedrock Model Invocation Logs

  Amazon Bedrock の各リクエスト/レスポンスを S3 や CloudWatch Logs に記録し、詳細な品質分析や監査に使えるログ機能。

  前提: Amazon Bedrock、CloudWatch Logs、Amazon CloudWatch

• Amazon Bedrock Prompt Flows

  プロンプト・基盤モデル・ナレッジベース・Lambda を視覚的に連結して GenAI ワークフローを組む Bedrock のビルダー。working draft → version（イミュータブル）→ alias で本番化し、条件分岐や逐次チェーンを構成できる。

  前提: Amazon Bedrock、AWS Lambda、Amazon Bedrock Knowledge Bases

• Route 53 ヘルスチェックとフェイルオーバー

  エンドポイントの正常性を監視し、異常時にフェイルオーバールーティングで正常な宛先へ自動的に切り替える。計算済みヘルスチェックや CloudWatch アラームとの連携も可能。

  前提: Amazon Route 53、Amazon CloudWatch、Route 53 ルーティングポリシー

• エニーキャスト

  同じ IP アドレスを複数の拠点から同時に広告し、経路的に最も近いノードへ自動的に届ける通信方式。CDN や DNS、グローバル負荷分散サービスが低遅延・高可用性を実現する基盤として使う。

  前提: 性能の指標（IOPS/スループット/帯域幅/レイテンシー）

  関連: ユニキャスト

• キャパシティリバランス

  Auto Scaling グループの機能で、スポットインスタンスが中断されるリスクが高まったと AWS が判断した時点で、実際の中断通知を待たずに代替インスタンスを事前起動する。既存インスタンスは新インスタンスが健全になってから終了され、可用性への影響を最小化する。

  前提: Auto Scaling、料金モデル（オンデマンド/Savings Plans・RI/スポット）、ML データ準備（エンコード/スケーリング/不均衡）

• インスタンスリフレッシュ

  Auto Scaling グループのインスタンスを、新しい起動テンプレート/AMI へローリングで一括入れ替える機能。最小正常パーセンテージを保ちながら段階的に置換し、イミュータブルなデプロイを実現する。

  前提: Auto Scaling、起動テンプレート、ML データ準備（エンコード/スケーリング/不均衡）

• 混合インスタンスポリシー

  1 つの Auto Scaling グループで複数インスタンスタイプとオンデマンド/スポットの比率を組み合わせる設定。スポット中断に強く、容量確保とコスト削減を両立する。

  前提: Auto Scaling、料金モデル（オンデマンド/Savings Plans・RI/スポット）、ML データ準備（エンコード/スケーリング/不均衡）

• 非同期レプリケーション

  先に応答し、後から複製先へ反映する方式。書き込み遅延は小さいが、障害時に未反映分のデータ損失が起こりうる。リードレプリカやクロスリージョン複製で使われる。RPO 要件で同期と使い分ける。

  前提: 性能の指標（IOPS/スループット/帯域幅/レイテンシー）、同期レプリケーション

• Athena（パーティション/ワークグループ/CTAS）

  S3 を SQL で直接クエリする Athena の要点。パーティション分割とカラムナ形式（Parquet）でスキャン量＝コストを削減。ワークグループでクエリの分離・コスト上限・課金分けを管理。CTAS で結果から新テーブル作成、Federated Query で他データソースも横断。

  前提: Amazon Athena、列指向フォーマット（Parquet/ORC）、パーティション分割（S3/データレイク）

• アベイラビリティーゾーン（AZ）

  リージョン内の独立した1つ以上のデータセンター（電源・冷却・NWが分離）。複数AZへ分散すると高可用性になる。

• Amazon EBS

  ブロックストレージ。EC2 に接続する仮想ディスクで、1 ボリュームは原則 1 インスタンスに接続（io1/io2 は Multi-Attach で複数に接続可）。1 インスタンスに複数ボリュームは可。gp3/io2 等のタイプがあり、スナップショットでバックアップする。

  前提: ブロックストレージ

• Amazon EC2

  仮想サーバー（IaaS）。OSから上を自分で管理する最も自由度の高いコンピュート。購入オプション（オンデマンド/RI・Savings Plans/スポット）で最適化。

  前提: 料金モデル（オンデマンド/Savings Plans・RI/スポット）

• エッジロケーション

  コンテンツをユーザーの近くでキャッシュ・配信する拠点（Amazon CloudFront）。低遅延配信に使う。

  前提: 性能の指標（IOPS/スループット/帯域幅/レイテンシー）

  関連: Amazon CloudFront

• Amazon EFS

  ファイルストレージ。複数のEC2から同時マウントして共有できる（NFS）。

  前提: ファイルストレージ

• AWS Trusted Advisor

  コスト・セキュリティ・耐障害性・パフォーマンス・サービス制限の観点でベストプラクティスを点検・推奨する（自分の環境向け）。

  前提: フォールトトレランス（耐障害性）

• Amazon VPC

  AWS内に作るプライベートネットワーク。サブネット（公/私）で区切り、セキュリティグループ/NACLで通信を制御する。

• AWS Well-Architected フレームワーク

  クラウド設計のベストプラクティス集。6本の柱（運用上の優秀性・セキュリティ・信頼性・パフォーマンス効率・コスト最適化・持続可能性）で点検する。

  関連: Well-Architected の6本柱

• AWS Backup Audit Manager

  バックアップが組織のポリシー（頻度・保持・暗号化・クロスリージョン）に準拠しているかを継続評価し、コンプライアンスレポートを生成する機能。未保護リソースや逸脱を検出し、監査要件に応える。

  前提: コンプライアンス報告、AWS Audit Manager、AWS Backup

• Bedrock のデータプライバシー

  Bedrock では入力・出力を基盤モデルの学習に既定で使用せず、データはアカウント内に留まる。VPC エンドポイント（PrivateLink）でインターネットを経由せず接続し、KMS で暗号化、CloudTrail で監査できる。機密データを扱う生成 AI の前提。

  前提: Amazon Bedrock、AWS CloudTrail、AWS PrivateLink

• 集中ログ（ログアーカイブアカウント）

  組織のログ（CloudTrail・Config・VPC フローログ・アプリログ）を専用のログアーカイブアカウントの S3 へ集約し、改ざん防止（オブジェクトロック）と長期保管を行うベストプラクティス。Control Tower のランディングゾーンが標準で用意する。

  前提: AWS CloudTrail、S3 Object Lock（オブジェクトロック）、AWS Control Tower

• 変更管理

  本番環境への変更を計画・評価・承認・記録し、影響を最小化して安全に反映するための管理プロセス（ITIL の変更管理などが代表例）。承認フロー・変更可能な時間帯の統制・実施後のロールバック手順が中核であり、AWS では SSM Change Calendar や Change Manager がこの一部を自動化するツールとして使われる。

  前提: SSM 変更カレンダー / メンテナンス計画

  関連: 監査証跡、コンプライアンス報告

• コンプライアンスプログラムと AWS Artifact

  AWS は ISO・SOC・PCI DSS・HIPAA・FedRAMP 等の第三者認証に準拠し、その監査レポートを AWS Artifact からオンデマンドで取得できる。準拠範囲は責任共有モデルで分担する。

  前提: AWS Artifact、料金モデル（オンデマンド/Savings Plans・RI/スポット）

• CloudFront 自動圧縮（コンテンツ圧縮）

  CloudFrontがオリジンからのレスポンスをGzipやBrotliで自動圧縮し、転送量を削減して表示を高速化する機能。オリジンが未圧縮で返し、対象のContent-Type（HTML/CSS/JS等のテキスト系）かつファイルサイズが1,000〜10,000,000バイトの範囲にある場合にのみ適用され、キャッシュビヘイビアで有効化する。ビューワーのAccept-Encodingヘッダーを見て対応形式（gzip/br）を選択する。

  前提: Amazon CloudFront、ML データ準備（エンコード/スケーリング/不均衡）

  関連: CloudFront 地理的制限（Geo Restriction）

• CloudTrail イベント種別（管理/データ/Insights）

  管理イベント＝API による設定操作（既定で記録・無料）。データイベント＝S3 オブジェクトや Lambda 実行などの高頻度データ操作（任意・有料）。Insights イベント＝普段と異なる API 呼び出し量を異常検知する。

  前提: AWS CloudTrail、AWS Lambda

• Amazon EKS（Elastic Kubernetes Service）

  マネージド Kubernetes サービス。コントロールプレーンを AWS が運用し、ワーカーは EC2 か Fargate。既存の Kubernetes 資産・エコシステムをそのまま使いたい場合に選ぶ（ECS より複雑）。

  前提: AWS Fargate

• Cost Optimization Hub

  組織全体のコスト削減の機会（未使用リソース・適正化・Savings Plans/RI 推奨）を 1 か所に集約し、削減見込み額順に提示する Billing の機能。Compute Optimizer や Trusted Advisor の推奨を横断的にまとめる。

  前提: 料金モデル（オンデマンド/Savings Plans・RI/スポット）、AWS Trusted Advisor、AWS Compute Optimizer

• CloudWatch メトリクス

  CloudWatch が扱う数値の時系列データ。名前空間とディメンションで識別し、アラームやダッシュボードの入力になる。EC2 等の標準メトリクスが自動で集まる。

  前提: Amazon CloudWatch

• Amazon Neptune

  フルマネージドのグラフデータベース。関係性（ソーシャルグラフ・推薦・不正検知・ナレッジグラフ）の問い合わせに最適化され、Gremlin/openCypher/SPARQL に対応する。

  前提: マネージドサービス（管理の境界）

• DynamoDB の TTL（自動失効）

  項目に有効期限のタイムスタンプ属性を設け、期限切れの項目を自動で削除する機能（書き込み容量を消費しない）。セッションやログ等の一時データを自動掃除し、ストレージコストを抑える。削除は DynamoDB Streams にも流せる。

  前提: Amazon DynamoDB、DynamoDB の設計機能（GSI/DAX/Global Tables）

• Amazon AppFlow

  SaaS アプリ（Salesforce・SAP・Zendesk 等）と AWS の間でデータを安全に転送するフルマネージドな統合サービス。コード不要でフローを構成する。

  前提: マネージドサービス（管理の境界）

• Amazon DataZone

  組織横断のデータカタログ・ガバナンス・データ共有を提供するサービス。ビジネスカタログで資産を発見し、購読フローでアクセスを統制する。機能は次世代の Amazon SageMaker（統合スタジオ）へ統合が進む。

  前提: Amazon SageMaker

• AWS DMS（Database Migration Service）

  データベースの移行と継続的レプリケーションを行うサービス。CDC（変更データキャプチャ）で差分だけを取り込み、ソース DB を止めずに同期できる。スキーマ変換が要る場合は SCT（Schema Conversion Tool）を併用する。

  前提: Schema Conversion Tool（SCT）

• AWS Glue DataBrew

  コードなしの視覚的データ準備ツール。250 以上の変換（クレンジング・正規化）をGUI で適用し、レシピとして再利用できる。

  前提: AWS Glue

• AWS Glue Studio

  Glue ETL ジョブを視覚的なノードグラフで作成・実行・監視するオーサリング環境。生成された Spark コードを編集することもできる。

  前提: AWS Glue

• ジョブブックマーク

  処理済みデータの位置を記憶し、再実行時に未処理分だけを増分処理して重複を防ぐ Glue の機能。

  関連: AWS Glue

• Amazon Keyspaces

  Apache Cassandra 互換のマネージドなワイドカラムデータベース。サーバーレスで、Cassandra の CQL を使うワークロードに向く。

  前提: サーバーレス（FaaS）

• AWS AppConfig

  アプリ構成とフィーチャーフラグを安全に配信する Systems Manager の機能。検証・段階的ロールアウト・自動ロールバック（CloudWatch アラーム連動）でリスクを抑える。

  前提: Amazon CloudWatch、AWS Systems Manager（SSM）

• AWS CDK（Cloud Development Kit）

  TypeScript/Python 等のプログラミング言語でインフラを記述し、CloudFormation テンプレートを合成する IaC フレームワーク。コンストラクト（L1=生 CFn／L2=高水準／L3=パターン）で部品化・再利用でき、CDK Pipelines で自己更新型の CI/CD を組める。

  前提: AWS CloudFormation

• DynamoDB Accelerator（DAX）

  DynamoDB 専用のインメモリキャッシュ。読み取りをマイクロ秒級まで高速化し、読み取り負荷を肩代わりする。アプリ側のコード変更を最小に抑えられる。

  前提: Amazon DynamoDB

• Lambda の構成（レイヤー・環境変数・一時ストレージ）

  共通ライブラリはレイヤーで共有し、設定は環境変数（KMS で暗号化可）で渡す。/tmp の一時ストレージは最大 10GB まで拡張でき、メモリ設定が CPU 割り当ても決める。

  前提: AWS Lambda

• Direct Connect vs VPN

  オンプレ接続の比較。Site-to-Site VPN＝インターネット経由で安価・即時だが帯域/遅延が不安定。Direct Connect＝専用線で安定・低遅延・高帯域だが構築に時間とコスト。重要回線は DX＋VPN をバックアップに組み合わせる。

  前提: AWS Direct Connect、AWS Site-to-Site VPN、性能の指標（IOPS/スループット/帯域幅/レイテンシー）

• EBS 暗号化

  EBS ボリュームを AWS KMS の鍵で保管時暗号化する機能。暗号化されたボリュームから作成したスナップショットや AMI も暗号化が引き継がれ、アカウント/リージョン単位で既定の暗号化を強制することもできる。既存の未暗号化ボリュームは直接変換できず、スナップショット経由でのコピーが必要。

  前提: AWS KMS、保管時の暗号化（at rest）

• EBS スナップショット

  EBS ボリュームを S3 に増分バックアップする仕組み（2回目以降は差分のみ保存）。別 AZ/リージョンへコピーや AMI 化、共有が可能。高速スナップショット復元（FSR）で復元直後の I/O 遅延を解消できる。Data Lifecycle Manager で自動化する。

  前提: 性能の指標（IOPS/スループット/帯域幅/レイテンシー）

  関連: Amazon Data Lifecycle Manager（DLM）

• ユーザーデータ

  EC2 インスタンスの初回起動時に実行されるブートストラップスクリプト。パッケージ導入や設定を自動化する。既定では起動時に一度だけ実行される。

  関連: ブートストラップ（初期起動処理）

• ECS タスクロール

  コンテナ内で動くアプリケーションコードが、S3やDynamoDB等のAWS APIを呼び出すために引き受けるIAMロール。アプリの実処理に必要な権限だけを与える最小特権の対象で、タスク定義のtaskRoleArnで指定する。

  前提: Amazon DynamoDB、AWS IAM

• ETL（抽出・変換・格納）

  データ統合パターンの一つ。ソースからデータを抽出し、格納先に入れる前に変換（クレンジング・整形・集計）を行う。変換用の別コンピュート（サーバーやマネージドサービス）を要するが、格納先には整った形のデータだけが入る。

  前提: マネージドサービス（管理の境界）

• EventBridge ルール

  イベントパターン（発生元・内容で一致条件を定義）またはスケジュールに一致したイベントを、1つ以上のターゲット（Lambda・SQS・Step Functions 等）へ配信する規則。1つのルールに複数ターゲットを設定でき、配信失敗時の再試行やデッドレターキューへの退避も設定できる。

  前提: AWS Lambda、AWS Step Functions、デッドレターキュー（DLQ）

• ファイルストレージ

  共有ファイルシステムとして複数のクライアントから同時にアクセスできるストレージ（EFS・FSx）。ディレクトリ階層でファイルを扱う。

  関連: ブロックストレージ、オブジェクトストレージ

• 無料利用枠アラート

  無料利用枠の使用量が上限に近づいたときにメールで警告する AWS Billing の通知。2025-07-15 以降の新規アカウントはクレジット方式の新 Free Tier となり、残クレジットが 50%/25%/10% になった時点や無料期間の残日数（15/7/2日）を通知する。予期しない課金の早期警戒として AWS Budgets と併用されることも多い。

  前提: 無料利用枠（Free Tier）、AWS Budgets、AWS Billing and Cost Management

• 評価レポート / モデル比較

  複数モデルやプロンプト構成を共通の指標・データセットで評価し、可視化・自動レポートで比較する仕組み。Bedrock Model Evaluation（自動指標・人手・LLM-as-a-judge）で精度/コスト/レイテンシを横並びにし、選定や改善の意思決定に使う。

  前提: LLM-as-a-Judge、Amazon Bedrock、性能の指標（IOPS/スループット/帯域幅/レイテンシー）

• 勾配ブースティング

  弱い決定木を1本ずつ逐次的に追加し、直前までの予測誤差を縮めるように学習していくアンサンブル手法（代表実装は XGBoost・LightGBM）。表形式データに対する強力な既定手法として、多くのマネージド ML サービスに組み込みアルゴリズムとして用意されている。

  前提: 決定木、アンサンブル学習（バギング/ブースティング）

  関連: SageMaker 組み込みアルゴリズムの選定

• GuardDuty 検出器 / 脅威リスト

  検出器＝リージョンごとに GuardDuty を有効化する単位。CloudTrail・VPC フローログ・DNS ログを機械学習と脅威インテリジェンスで分析する。信頼された IP リスト（誤検知抑制）と脅威 IP リスト（独自ブロック対象）をカスタムで追加できる。

  前提: AWS CloudTrail、Amazon GuardDuty

• HTTPS

  HTTPをTLSの上に載せて運ぶプロトコル。通常のHTTPと違い通信内容が暗号化され、途中経路での盗聴・改ざんを防げる。ブラウザは証明書を検証してサーバーの正当性を確認し、Webサイトの標準的な通信方式になっている。

  関連: TLS

• Infrastructure as Code（IaC）

  インフラをコード（テンプレート）で宣言的に定義し、再現可能・バージョン管理可能にする考え方。手作業のドリフトを防ぎ、レビュー・自動化・複数環境の一貫構築を可能にする。AWS では CloudFormation・CDK が代表。

  前提: AWS CloudFormation

• インスタンスプロファイル（EC2 用 IAM ロール）

  EC2 に IAM ロールを渡す入れ物。アクセスキーを埋め込まず、インスタンスメタデータ経由で一時認証情報を自動取得・自動ローテーションする（漏洩リスク低減）。IMDSv2 の利用が推奨。

  前提: AWS IAM、インスタンスメタデータ（IMDSv2）、一時認証情報

• サービスにリンクされたロール

  AWS サービスが自分に代わって他リソースを操作するための、サービス専用に定義済みの IAM ロール。権限が事前定義され、誤って壊さない仕組みになっている（例：Auto Scaling・ELB・Config が利用）。通常のロールと違い削除・編集が制限される。

  前提: Auto Scaling、AWS IAM、ML データ準備（エンコード/スケーリング/不均衡）

• ワイルドカード権限

  ポリシーの Action や Resource に "*"（例：s3:*）を使い、想定より広い操作やリソースを許可してしまう記述。最小特権の原則に反する典型パターンで、IAM Access Analyzer のポリシー検証やアクセスアドバイザーで過剰な許可を検出・是正する。

  前提: アクセスアドバイザー（最終アクセス情報）、IAM ポリシーの構造（Effect/Action/Resource/Condition）、IAM Access Analyzer

• Kinesis のコンシューマー（拡張ファンアウト/KCL）

  Kinesis Data Streams の読み取り側。標準コンシューマーはシャードのスループットを共有。拡張ファンアウト（Enhanced Fan-Out）は各コンシューマーに専用 2MB/s を割り当て低遅延化。KCL（Kinesis Client Library）はチェックポイントや負荷分散を担う。

  前提: Kinesis Data Streams、性能の指標（IOPS/スループット/帯域幅/レイテンシー）、Amazon SNS

• Lambda MCP サーバ

  AWS Lambda で MCP（Model Context Protocol）のツールを公開するサーバ実装。軽量・ステートレスなツール（検索・計算・API 呼び出し）をサーバーレスで提供し、エージェントから標準形で呼べる。需要追従でスケールしコスト効率が高い。

  前提: AWS Lambda、MCP（Model Context Protocol）、サーバーレス（FaaS）

• 権限の反復的絞り込み（最小特権の運用）

  最初は広めに許可して動かし、Access Analyzer の未使用アクセスや CloudTrail の実利用、Access Advisor の最終アクセス情報をもとに不要な権限を継続的に削る運用サイクル。生成されたポリシーで安全に絞り込む。

  前提: AWS CloudTrail、アクセスアドバイザー（最終アクセス情報）、IAM Access Analyzer

• Function Calling（関数呼び出し）

  LLMに外部ツールやAPIを使わせる基本的な仕組み。呼び出し可能な関数のスキーマ（名前・引数・説明）をモデルに渡すと、モデルは実行はせず「この関数をこの引数で呼びたい」という構造化された提案（JSON等）だけを返し、実際の実行と結果の返送はアプリ側が担う。

  前提: JSON

  関連: MCP（Model Context Protocol）

• マイクロサービス

  アプリケーションを小さく独立したサービス群に分割するアーキテクチャスタイル。サービスごとに個別デプロイ・個別スケール・障害分離ができる一方、サービス間通信や運用の複雑さが増す。コンテナやサーバーレス基盤、API ゲートウェイと組み合わせて構築されることが多い。

  前提: Amazon API Gateway、サーバーレス（FaaS）

  関連: モノリス

• ハイパーパラメータ最適化（HPO）

  学習前に決める設定（学習率・木の深さ・正則化強度等）を自動探索して指標を最適化すること。グリッド/ランダム探索、ベイズ最適化、早期終了を使う。SageMaker の Automatic Model Tuning が代表。検証データで評価し過学習を避ける。

  前提: Amazon SageMaker、Automatic Model Tuning（HPO）、主要なハイパーパラメーター

• 独自コンテナ（BYOC）と ECR

  独自の学習/推論コードを Docker イメージにし、Amazon ECR に保存して SageMaker で実行する方式。組み込みアルゴリズムで足りない要件に対応する。

  前提: Amazon SageMaker、Amazon ECR（Elastic Container Registry）

• SageMaker 学習ジョブと分散学習

  組み込みアルゴリズムや独自コンテナでモデルを訓練するマネージドジョブ。データ並列/モデル並列の分散学習やマネージドスポットで大規模・低コストに学習する。

  前提: Amazon SageMaker、料金モデル（オンデマンド/Savings Plans・RI/スポット）、独自コンテナ（BYOC）と ECR

• 主要なハイパーパラメーター

  学習を制御する設定値。学習率（ステップ幅）、バッチサイズ、エポック数、決定木の深さ、正則化の強さなどを調整して収束と汎化のバランスを取る。

  前提: 決定木

• テキスト前処理（トークン化/TF-IDF/n-gram）

  テキストを特徴量にする前処理。トークン化・ステミング/見出し語化で正規化し、Bag-of-Words や TF-IDF、n-gram、Word2Vec で数値ベクトル化する。

• マルチキャスト

  特定のグループに参加したホストにだけ一斉配信する通信方式。ブロードキャスト同様クラウドの仮想ネットワークでは標準サポートされないことが多く、必要な場合はトランジットゲートウェイのマルチキャスト機能のような専用サービスを使うか、設計をユニキャスト前提に置き換える。

  前提: ブロードキャスト、Transit Gateway、ユニキャスト

• ブロードキャスト

  同一ネットワークセグメント内の全ホストへ一斉にデータを送る通信方式。多くのパブリッククラウドの仮想ネットワーク（VPC/VNet 相当）は既定でブロードキャストをサポートしないため、オンプレ前提のアプリをそのまま移行しようとすると設計の見直しが必要になる。

  前提: X-Ray のサンプリングとサブセグメント

• NAT インスタンス vs NAT ゲートウェイ

  プライベートサブネットの外向き通信を仲介する2方式。NAT ゲートウェイ＝マネージド・高可用（AZ 内冗長）・自動スケール（推奨）。NAT インスタンス＝EC2 を自前運用（送信元/宛先チェック無効化が必要・単一障害点・安価/特殊用途）。

  前提: ML データ準備（エンコード/スケーリング/不均衡）、単一障害点（SPOF）、パブリック/プライベートサブネット

• タグポリシー（Organizations）

  Organizations の機能で、タグのキー名や許容値の標準を組織全体に強制し、準拠していないタグを検出する。コスト配分やアクセス制御（ABAC）の前提となるタグの一貫性を担保する。SCP とは別物（SCP は権限、タグポリシーはタグ統制）。

  前提: AWS Organizations（一括請求）、コスト配分（チャージバック/ショーバック）

• 悲観ロック

  更新前に対象へロックを取得し、保持している間は他のトランザクションを待たせる競合制御方式。競合が頻発する状況では楽観ロックより安全だが、並行性が下がりデッドロックのリスクがある。複数ノードにまたがる分散ロックはDynamoDB等を使って実装する。

  前提: Amazon DynamoDB、楽観ロック

  関連: 冪等性キーパターン

• RAG の増分更新（差分再埋め込み）

  知識ベースの更新時、全文書ではなく変更分だけを再チャンク・再埋め込みしてベクトルストアへ反映する手法。取り込みコストとレイテンシを抑え、鮮度を保つ。Knowledge Bases の同期は差分取り込みに対応する。

  前提: Amazon Bedrock Knowledge Bases、性能の指標（IOPS/スループット/帯域幅/レイテンシー）、チャンキング（分割戦略）

• ブラストラディウス（影響範囲）

  障害や誤操作・侵害が及ぶ影響範囲。アカウント分離・複数リージョン/AZ・最小特権・セル分割で範囲を小さく保つ。範囲を限定する設計が回復力とセキュリティの基本。

• フォールトトレランス（耐障害性）

  構成要素が壊れてもサービスを止めない設計。高可用性（早期復旧）より一段強く、障害時も中断なく稼働し続ける。冗長な並行系（アクティブ/アクティブ）・N+1 構成・複数 AZ への分散で実現する（自動復旧は中断を伴うため高可用性側の手段）。

• リトライ設計

  一時的な障害に対し、指数バックオフとジッターを使って再試行する設計。単純な即時リトライは、大量クライアントの再試行が同時に集中するリトライストームを招き障害を悪化させるため、ランダムな遅延（ジッター）で分散させる。冪等な操作でのみ安全に使える。

  前提: 指数バックオフ、べき等性

• DSSE-KMS（二重レイヤー暗号化）

  S3オブジェクトに2つの独立した暗号化レイヤーをKMS鍵で適用するサーバーサイド暗号化方式。FIPS 140-2やITAR等、単一レイヤーの暗号化では満たせない高い保証要件（二重暗号化義務）を持つ規制業界向け。通常のSSE-KMSより処理コストは増える。

  関連: S3 バケットキー、S3 の暗号化と公開防止

• マルチリージョンアクセスポイント

  複数リージョンに分散した S3 バケットへ、単一のグローバルエンドポイントでアクセスできるようにする機能。AWS Global Accelerator の仕組みでリクエストを発信元に最も近いリージョンへ自動ルーティングし、フェイルオーバーやレイテンシ改善に使う。

  前提: AWS Global Accelerator、マルチリージョン構成（アクティブ-アクティブ/スタンバイ）、性能の指標（IOPS/スループット/帯域幅/レイテンシー）

• S3 Object Lock（オブジェクトロック）

  オブジェクトを WORM（書き込み一度・読み取り多数）で保護し、保持期間中の削除/上書きを禁止する。ガバナンスモード（特権で解除可）とコンプライアンスモード（誰も解除不可）、リーガルホールド（無期限保持）がある。法令対応・改ざん防止に使う。

• Aurora の機能（Serverless / Global Database）

  Aurora は 3 AZ に 6 重複製する高耐久 DB。Aurora Serverless v2 は負荷に応じ自動スケール、Global Database は複数リージョンへ低遅延複製して DR と読み取りを支える。

  前提: Amazon Aurora、性能の指標（IOPS/スループット/帯域幅/レイテンシー）、サーバーレス（FaaS）

• キャッシュ階層の設計

  CloudFront（エッジ）・API キャッシュ・ElastiCache（DB 前段）・DAX（DynamoDB 前段）を層ごとに使い、遅延とバックエンド負荷・コストを下げる設計。

  前提: Amazon CloudFront、Amazon DynamoDB、性能の指標（IOPS/スループット/帯域幅/レイテンシー）

• Amazon FSx（ファイルシステム）

  マネージドなファイルシステム群。FSx for Windows File Server（SMB/AD）、FSx for Lustre（HPC・高速）、FSx for NetApp ONTAP、FSx for OpenZFS をワークロードで選ぶ。

  前提: SageMaker 学習の入力モードとデータ供給

• RDS マルチ AZ とリードレプリカ

  マルチ AZ は同期スタンバイへ自動フェイルオーバーする高可用性（DR 目的）で、リードレプリカは非同期複製で読み取りをスケールする（性能目的）。役割が異なる。

• Amazon SQS

  フルマネージドなメッセージキュー。生産者と消費者を疎結合にし、作業をバッファしてスパイクを吸収する（プル型・基本1対1）。

  前提: 疎結合（デカップリング）、マネージドサービス（管理の境界）、ポーリング vs Webhook（プッシュ/プル）

• AWS Batch

  バッチ コンピューティング ジョブを、必要なコンピュート（EC2/Fargate/スポット）を自動でプロビジョニングしながら大規模に実行・スケジュールするマネージド サービス。

  前提: 料金モデル（オンデマンド/Savings Plans・RI/スポット）、AWS Fargate、マネージドサービス（管理の境界）

• AWS Data Exchange

  サードパーティのデータ製品を検索・購読し、AWS 上で安全に受領・利用できるデータマーケットプレイス。外部データセットを分析基盤に取り込む。

  前提: AWS Marketplace

• AWS DataSync

  ファイルやオブジェクトを、ネットワーク経由で高速・増分・整合性チェック付きで転送するサービス。NFS/SMB/S3/EFS/FSx 間を結び、回線が十分な場合のオンライン移行に向く。

  前提: 性能の指標（IOPS/スループット/帯域幅/レイテンシー）

• Application Migration Service（MGN）

  オンプレや他クラウドのサーバーを、エージェントによるブロックレベルの継続レプリケーションで EC2 へリホストする主力サービス。テスト起動で検証し、切替（cutover）時のダウンタイムを最小化する。

  前提: 移行戦略（7 つの R）

• Resource Access Manager（RAM）

  特定の AWS リソース（Transit Gateway、サブネット、ライセンスなど）をアカウントや組織をまたいで共有するサービス。リソースを複製せずに複数アカウントから利用できる。

  前提: IAM ポリシーの構造（Effect/Action/Resource/Condition）、Transit Gateway

• AWS Security Hub

  GuardDuty・Inspector・Macie・Config などの検出結果を ASFF 形式で一元集約し、CIS や AWS 基礎セキュリティ標準に対する準拠スコアを提示するサービス。組織のセキュリティ態勢を可視化する。

  前提: Amazon GuardDuty、Amazon Inspector、Amazon Macie

• Service Quotas

  AWS サービスのクォータ（上限）を一元的に確認・引き上げ申請できるサービス。大規模設計でのスケール上限の管理に使う。

  前提: ML データ準備（エンコード/スケーリング/不均衡）

• AWS Transfer Family

  SFTP/FTPS/FTP を用いて外部パートナーと S3/EFS との間でファイルを継続的に授受するマネージドサービス。既存の転送プロトコルを保ったままバックエンドをクラウド化できる。

  前提: マネージドサービス（管理の境界）

• VPC ピアリング

  2 つの VPC を 1 対 1 で直接接続する仕組み。推移的ルーティングは不可で、多数の VPC を結ぶとフルメッシュになり管理が複雑化するため、大規模では Transit Gateway を使う。

  関連: Transit Gateway

• Savings Plans の種別

  1年/3年の利用コミットで割引を得る購入オプション。Compute Savings Plans＝最も柔軟（EC2/Fargate/Lambda・リージョン/ファミリー横断）。EC2 Instance Savings Plans＝特定ファミリー/リージョンに固定でより高割引。RI より柔軟なのが特徴。

  前提: AWS Lambda、料金モデル（オンデマンド/Savings Plans・RI/スポット）、AWS Fargate

• IAM Access Analyzer

  外部に公開された S3/ロール/KMS/Secrets 等を検出する外部アクセス分析、未使用のロール/権限/アクセスキーを洗い出す未使用アクセス分析、ポリシーの検証、CloudTrail からの最小権限ポリシー生成を行い、最小権限を支援するサービス。

  前提: AWS CloudTrail

• AWS Audit Manager

  PCI DSS/HIPAA/SOC 2 等の規制フレームワークに対する監査証拠を継続的に収集・整理し、監査レポート作成を支援するサービス。構成準拠の評価（Config）や検出の集約（Security Hub）とは役割が異なる。

  前提: コンプライアンスプログラムと AWS Artifact

• AWS Certificate Manager（ACM）

  SSL/TLS 証明書を無料で発行・自動更新するサービス。ELB・CloudFront・API Gateway に統合され、証明書の有効期限切れによる障害を防ぐ。自動更新は DNS 検証が確実（メール検証でも条件付きで自動更新可）。

  前提: Amazon CloudFront、Amazon API Gateway、TLS

• SES の配信可能性（バウンス/設定セット）

  メール到達率を保つ運用。バウンス（不達）・苦情（スパム報告）率が高いと送信が制限される。設定セットでイベント（送信/配信/バウンス/苦情）を SNS/CloudWatch に出し監視。DKIM/SPF/DMARC で認証し、専用 IP やウォームアップで評判を管理する。

  前提: クールダウンとウォームアップ、Amazon CloudWatch

• AWS Backup

  複数サービス（EBS/RDS/DynamoDB/EFS 等）のバックアップを集中管理するサービス。バックアッププランでスケジュールと保持を定義し、クロスリージョン/クロスアカウントコピーや、削除を防ぐ Backup Vault Lock（WORM）に対応する。

  前提: Amazon DynamoDB

• Parameter Store

  設定値や機密（SecureString は KMS 暗号化）を階層的に保存・バージョン管理する Systems Manager のストア。アプリ設定の一元管理に使う。

  関連: AWS Systems Manager（SSM）

• Patch Manager

  パッチベースラインで承認するパッチを定義し、メンテナンスウィンドウの時間枠でフリート全体に適用・コンプライアンスを評価する機能。

  関連: パッチコンプライアンス（Patch compliance）

• Run Command

  SSH/RDP を開けずに多数のインスタンスへ一括でコマンドやスクリプトを実行する Systems Manager 機能。ターゲットをタグで指定し、結果を集約できる。

  関連: AWS Systems Manager（SSM）

• Session Manager

  ポートを開けず踏み台も不要で、ブラウザ/CLI からインスタンスのシェルに接続する機能。操作ログを CloudTrail/S3 に記録できる。

  前提: AWS CloudTrail

• FIFO（順序保証/重複排除）

  SQS/SNS の FIFO 種別。メッセージグループ単位で厳密な順序を保証し、重複排除 ID（または内容ベース重複排除）で5分間の重複送信を排除する。標準より低スループットだが、順序と「ちょうど一度」が要る処理向け。

  前提: 配信セマンティクス（少なくとも1回/正確に1回）、性能の指標（IOPS/スループット/帯域幅/レイテンシー）

  関連: メッセージ順序保証

• Session Manager（ポートフォワーディング/監査）

  SSH/RDP やポートを開けずにシェル接続する SSM 機能の要点。ポートフォワーディングでローカルから RDS 等へ安全にトンネル。全セッションを CloudTrail/S3/CloudWatch に記録し監査可能。踏み台（Bastion）の代替になる。

  前提: AWS CloudTrail、Amazon CloudWatch、Session Manager

• パブリック/プライベートサブネット

  パブリックサブネット＝ルートテーブルにインターネットゲートウェイ（IGW）への経路があり、外部と直接通信できる。プライベートサブネット＝IGW 経路を持たず、外向き通信は NAT ゲートウェイ経由。公開する物だけをパブリックに置くのが基本。

  前提: ルートテーブル

• 同期レプリケーション

  書き込みを複製先が確定するまで待って応答する方式。障害時のデータ損失がゼロ（RPO 0）だが書き込み遅延が増える。RDS マルチ AZ 等で使われる。

  前提: 性能の指標（IOPS/スループット/帯域幅/レイテンシー）、RDS マルチ AZ とリードレプリカ

• TCP

  コネクション確立（3ウェイハンドシェイク）・順序保証・再送制御を行う信頼性重視のトランスポート層プロトコル。HTTP・SSH・データベース接続など、データの欠落や順序崩れが許されない通信で使われる。

  前提: メッセージ順序保証

  関連: ポート番号、UDP

• 垂直スケーリング（スケールアップ）

  1台のインスタンスのスペック（CPU・メモリ等）を増強するスケーリング方式。アプリの構成変更が少なく手軽だが、インスタンスタイプの上限があり、単一障害点になりやすく、変更時に停止を伴うことが多い。水平スケーリングと対比される選択肢。

  前提: 水平スケーリング（スケールアウト）、ML データ準備（エンコード/スケーリング/不均衡）、単一障害点（SPOF）

• VPC フローログのフィールドと宛先

  フローログは送信元/宛先 IP・ポート・プロトコル・バイト数・ACCEPT/REJECT などを記録する。宛先は CloudWatch Logs・S3・Data Firehose。ENI/サブネット/VPC 単位で有効化し、拒否された通信の調査やトラフィック分析に使う。

  前提: CloudWatch Logs、Amazon Data Firehose、Amazon CloudWatch

• Well-Architected の6本柱

  優れた設計の評価軸。運用上の優秀性（運用・自動化）/セキュリティ/信頼性（障害耐性・回復）/パフォーマンス効率/コスト最適化/持続可能性（環境負荷）。Well-Architected Tool でレビューし、リスクを洗い出す。

  前提: フォールトトレランス（耐障害性）

  関連: AWS Well-Architected フレームワーク

• YAML

  インデントで階層を表す、人が読み書きしやすいテキスト形式。CloudFormation や各種 IaC ツール、CI/CD パイプラインの設定ファイルで好まれ、同じデータを JSON とも相互変換できる。

  前提: JSON

  関連: AWS CloudFormation

• Bedrock のモデルカスタマイズ

  基盤モデルを独自データで適応させる方法。ファインチューニング（ラベル付きデータ）と継続的事前学習（ラベルなし大量データ）があり、どちらもプライベートな専用モデルを作る。

  前提: Amazon Bedrock

  関連: モデルカスタマイズ（ファインチューニング/継続的事前学習/蒸留）

• Bedrock Guardrails

  生成 AI の入出力に安全策を適用する機能。拒否トピック・コンテンツフィルター・PII マスキング・コンテキストグラウンディングチェックで有害/不適切な応答を抑える。

  前提: Amazon Bedrock

  関連: PII マスキング（生成 AI）

• モデルの透明性（AI Service/Model Cards）

  モデルの用途・性能・制限・学習データの考慮事項を文書化する AWS AI Service Cards / SageMaker Model Cards。説明責任とガバナンスを支える。

  前提: Amazon SageMaker

• Cross-Region Inference（クロスリージョン推論）

  Amazon Bedrock の推論プロファイルで、推論リクエストを複数リージョンへ自動的に振り分ける機能。単一リージョンの容量不足やリージョン障害を吸収して可用性を高める（データ複製ではなく推論のルーティング）。

  前提: Amazon Bedrock

• GenAI ゲートウェイ

  FM 利用を集約する中央抽象レイヤー。認証・レート制限・コスト配賦・オブザーバビリティ・ポリシーを一元化し、企業での安全で統制された GenAI 利用を実現する。

  前提: コスト配分（チャージバック/ショーバック）、レート制限

• LLM-as-a-Judge

  別の基盤モデルを「評価者」として用い、生成出力の品質（関連性・事実性など）や公平性を大規模かつ一貫して自動採点する手法。重要な判断は人手評価で補完する。

• Bedrock Model Evaluations

  複数のモデルやプロンプト構成を自動指標（正確性・毒性・堅牢性など）や人手評価で体系的に比較する Amazon Bedrock の機能。ユースケースに最適なモデルやパラメータを選定するために、本番投入前のベンチマークとして使う。

  前提: Amazon Bedrock

• プロンプトキャッシュ

  共通の接頭辞（システムプロンプト等）の再計算を省いて、トークンコストとレイテンシを下げるキャッシュ手法。意味的に同一の結果を再利用するセマンティックキャッシュとは異なる。

  前提: 性能の指標（IOPS/スループット/帯域幅/レイテンシー）

  関連: セマンティックキャッシュ

• Amazon Bedrock Prompt Management

  プロンプトをパラメータ化テンプレートとして作成・テストし、バージョンとエイリアスで管理・デプロイする Bedrock の機能。プロンプトを「資産」として版管理・比較・再利用できる。

  前提: Amazon Bedrock

• Amazon Comprehend

  テキストを分析する用途別AIサービス（感情・エンティティ・キーフレーズ）。

• Amazon Lex

  音声・テキストの会話ボット（チャットボット/IVR）を構築するサービス。意図（インテント）とスロットで対話を設計し、Lambda で処理を実装する。Alexa と同じ技術基盤。

  前提: AWS Lambda

  関連: Amazon Kendra

• エッジ拡張（Local Zones / Outposts / Wavelength）

  AWS をユーザーに近づける拡張。Local Zones＝大都市圏に計算/ストレージを配置、Outposts＝オンプレに AWS ラックを設置、Wavelength＝5G ネットワーク内に配置して超低遅延を実現する。

  前提: 性能の指標（IOPS/スループット/帯域幅/レイテンシー）

• Amazon VPC IPAM

  IP アドレス空間を組織全体で計画・割り当て・追跡・監視するサービス。重複 CIDR を防ぎ、プールを階層化してアカウント/リージョンに自動割り当てする。

  前提: Amazon VPC、CIDR 表記

• Network Load Balancer（NLB）

  L4 の超高性能ロードバランサ。固定 IP（AZ ごと）を持ち、クライアント IP を保持でき、クロスゾーン負荷分散や PrivateLink のサービス公開に使う。

  前提: クロスゾーン負荷分散、AWS PrivateLink

• マネージドプレフィックスリスト

  複数の CIDR を 1 つの名前付きリストにまとめ、セキュリティグループやルートテーブルで参照する仕組み。エントリ変更が参照先すべてに反映され、規則の保守を簡素化する。

  前提: CIDR 表記、ルートテーブル

• Auto Scaling のキャパシティ設定（最小／希望／最大）

  Auto Scaling グループの台数設定。最小＝下限、最大＝上限、希望容量＝現在維持したい台数。スケーリングは希望容量を最小〜最大の範囲で増減させる。

  前提: Auto Scaling、ML データ準備（エンコード/スケーリング/不均衡）

• Auto Scaling 終了ポリシー

  スケールイン時にどのインスタンスを終了するか決める規則。OldestInstance・NewestInstance・OldestLaunchTemplate（旧 OldestLaunchConfiguration）・AllocationStrategy・Default から選ぶ（ClosestToNextInstanceHour は秒単位課金の現在は意義が薄い）。スケールイン保護で特定インスタンスを除外できる。

  前提: Auto Scaling、ML データ準備（エンコード/スケーリング/不均衡）

• ウォームプール

  Auto Scaling グループのスケールアウトに備え、事前に初期化（起動・停止/実行中）したインスタンスを別プールで待機させる仕組み。需要急増時にゼロから起動するより起動時間を大幅に短縮でき、起動処理が重いアプリで特に有効。待機中インスタンスの状態（Stopped/Running）でコストと即応性のバランスを選べる。

  前提: Auto Scaling、ML データ準備（エンコード/スケーリング/不均衡）

• AWS CloudShell

  マネジメントコンソール内で開く、認証済みのブラウザシェル。AWS CLI・主要ランタイム・永続ストレージが事前構成されており、ローカルに鍵を置かずに素早く運用コマンドやスクリプトを実行できる。

  前提: AWS CLI、AWS マネジメントコンソール

• AWS Fault Injection Simulator (FIS)

  マネージドなカオスエンジニアリング/障害注入サービス。CPU 負荷・インスタンス停止・API スロットリング・AZ 障害などを実験テンプレートとして定義し、停止条件（ガードレール）付きで本番相当環境のレジリエンスを検証する。DevOps の「壊して学ぶ」回復力テストに使う。

  前提: API Gateway の機能（ステージ・スロットリング・統合）

• Amazon Managed Service for Prometheus (AMP)

  Prometheus 互換のマネージドなメトリクス収集/保存サービス。EKS/ECS などコンテナ環境のメトリクスを PromQL でクエリでき、スケールや保持を AWS に任せられる。Managed Grafana と組み合わせて可視化する構成が定番。

  前提: Amazon Managed Grafana、マネージドサービス（管理の境界）

• AWS Marketplace

  サードパーティ製ソフトを見つけて調達できるカタログ（課金はAWS請求に統合）。

• リージョン（AWS）

  地理的に独立した領域で、複数のアベイラビリティーゾーン（通常3つ以上）で構成される。遅延・コンプラ・コスト・サービス提供状況で選ぶ。

  前提: アベイラビリティーゾーン（AZ）、性能の指標（IOPS/スループット/帯域幅/レイテンシー）

• ルートユーザー

  アカウント作成時の全権限ユーザー。MFAで保護し日常作業では使わず、IAMユーザー/ロールを使う。

  前提: AWS IAM

• AWS SDK とツール

  各言語（Python=boto3、JavaScript、Java、Go など）から AWS API を呼ぶための公式ライブラリ群。認証情報の解決・自動リトライ（指数バックオフ）・ページネーション・リージョン設定を共通仕様で扱い、アプリや Lambda から AWS を操作する基盤になる。

  前提: AWS Lambda、指数バックオフ

• AWS STS

  一時的な認証情報を発行するサービス（Security Token Service）。AssumeRole やフェデレーションのリクエストを受け、短命の認証情報を返す。長期キーの配布を避ける中核。

  前提: AssumeRole、一時認証情報

• Bedrock ストリーミング（InvokeModelWithResponseStream）

  生成トークンを逐次返すストリーミング API。全文完成を待たずに先頭から表示でき、体感レイテンシ（最初のトークンまでの時間＝TTFT）を改善する。チャット UI や長い生成で UX を高める。

  前提: Amazon Bedrock、性能の指標（IOPS/スループット/帯域幅/レイテンシー）

• DeletionPolicy（Retain/Snapshot）

  CloudFormation でスタック削除/リソース置換時に、そのリソースをどう扱うかを指定する属性。Retain＝残す、Snapshot＝スナップショットを取ってから削除、Delete＝既定。DB やバケットの誤削除防止に使う。

  前提: AWS CloudFormation、IAM ポリシーの構造（Effect/Action/Resource/Condition）

• CloudFormation 組み込み関数（Ref/GetAtt/Sub）

  テンプレートで値を動的に解決する関数。Ref＝パラメータ/リソースの参照、Fn::GetAtt＝リソースの属性取得（ARN・エンドポイント等）、Fn::Sub＝文字列に変数を埋め込み、Fn::Join/Fn::If など。ハードコードを避け、移植性を高める。

  前提: AWS CloudFormation、IAM ポリシーの構造（Effect/Action/Resource/Condition）

• CloudFront キャッシュポリシー

  CloudFront がオブジェクトをキャッシュする際の TTL（最小/既定/最大）と、キャッシュキーに含める要素（ヘッダー・クエリ文字列・Cookie）を定義する設定。キャッシュキーを絞るほどヒット率が上がりオリジン負荷が下がるため、レスポンスをどこまで動的に出し分けるかとのトレードオフになる。

  前提: Amazon CloudFront

• フィールドレベル暗号化

  CloudFront のエッジで特定フォームフィールド（クレジットカード番号など）を公開鍵で暗号化し、オリジンまで秘匿したまま運ぶ機能。アプリ側は対応する秘密鍵を持つ最終処理点でのみ復号する。

  前提: Amazon CloudFront、公開鍵暗号（非対称）

• CloudFront 署名付き Cookie

  複数のファイルや動画ストリーミングなど、まとめて1回の許可でアクセスさせたい場合に使う Cookie ベースの制限方式。URL 自体は変更せずブラウザに Cookie を発行するため、既存のアプリ URL 構造を維持したまま制限をかけられる。

  前提: Amazon CloudFront

  関連: CloudFront 署名付き URL

• CloudWatch Internet Monitor

  AWSリソースとインターネット上のエンドユーザーとの間の経路の可用性・パフォーマンスを、都市や通信事業者ごとに可視化するサービス。AWSが観測する膨大な通信データを使い、リージョン外の一般利用者視点の問題（ISP障害等）を検知できる。

  前提: Amazon CloudWatch

  関連: CloudWatch Network Monitor

• Config 設定レコーダー

  AWS Config の中核機能で、対象リソースの構成変更を継続的に検知し、設定項目（Configuration Item）として時系列に記録する。レコーダーを有効化しないと Config ルール評価もタイムラインの参照もできず、リージョンごとに個別に有効化が必要。

  前提: AWS Config、IAM ポリシーの構造（Effect/Action/Resource/Condition）

• CloudWatch クロスアカウント可観測性（OAM）

  Observability Access Manager で、複数のソースアカウントのメトリクス・ログ・トレースを 1 つのモニタリングアカウントに集約して一元監視する仕組み。マルチアカウント環境の運用を簡素化する。

  前提: Amazon CloudWatch、可観測性の三本柱（メトリクス/ログ/トレース）

• カスタムメトリクス

  アプリ独自の指標を CloudWatch へ送るメトリクス。PutMetricData API、CloudWatch エージェント、または埋め込みメトリクス形式（EMF）でログから抽出して送信する。

  前提: CloudWatch エージェント

  関連: Amazon CloudWatch

• CloudWatch ダッシュボード共有

  CloudWatch ダッシュボードを、AWS アカウントを持たない社外の関係者や未ログインユーザーへ安全に共有できる機能。共有方法は、特定のメールアドレス（最大5件、Cognitoベースの各自パスワード）へ招待する方式、単一ダッシュボードを認証なしの公開リンクとして共有する方式、アカウント内の全ダッシュボードをSSO/SAML連携で共有する方式の3種類がある。IAM権限を付与せずに閲覧専用アクセスを提供したい場合（ステータスページ的な用途）に使う。

  前提: Amazon CloudWatch、Amazon Cognito

• ログ保持期間（Log retention）

  CloudWatch Logs のロググループごとに、ログイベントを自動削除するまでの期間（1日〜10年、または無期限）を設定する機能。既定値は無期限保持のため、コスト管理のためには明示的に設定する必要がある点が実務・試験の両方で頻出の注意点。

  前提: CloudWatch Logs、Amazon CloudWatch

• DynamoDB の容量挙動（ホットパーティション/適応キャパシティ）

  アクセスが特定キーに偏るとホットパーティションでスロットリングが起きる。適応キャパシティが偏りを自動で吸収し、バーストキャパシティが短時間の超過を許容する。設計の基本は高カーディナリティなパーティションキーで負荷を分散すること。

  前提: Amazon DynamoDB

• 決定木

  特徴量に対するしきい値で分岐を繰り返し、葉ノードで予測値を出す解釈しやすいモデル。単体では訓練データに過剰適合しやすく、深さの制限や剪定で抑える必要がある。回帰・分類の両方に使える。

• AWS Chatbot

  運用通知やアラームを Slack や Microsoft Teams に連携するサービス（現在は「Amazon Q Developer in chat applications」に改名）。SNS 経由の通知や CloudWatch のグラフをチャットに流し、承認済みコマンドをチャットから実行できる（ChatOps）。

  前提: Amazon Q、Amazon CloudWatch

• Config アグリゲーターと組織コンプライアンス

  複数アカウント/複数リージョンの AWS Config データを 1 か所に集約し、組織全体のリソース構成と準拠状況を一元的に評価・可視化する。

  前提: AWS Config、IAM ポリシーの構造（Effect/Action/Resource/Condition）

• Amazon ECR（Elastic Container Registry）

  コンテナイメージをバージョン管理して保管するレジストリ。イメージスキャン（Basic/Enhanced＝Amazon Inspector 連携）で脆弱性を検出し、ライフサイクルポリシーで古いイメージを整理、タグのイミュータブル化で上書きを防ぐ。ECS/EKS のデプロイ元となる。

  前提: Amazon Inspector

• Systems Manager Incident Manager

  重大インシデントの対応を統制するサービス。対応プラン・エスカレーション計画・オンコールスケジュール（ローテーション）・連絡先チャネルを管理し、発生時に自動でランブックを起動して関係者を招集、事後分析まで支援する。

  前提: AWS Systems Manager（SSM）、SSM Automation（ランブック）

• API Gateway の種類（REST/HTTP/WebSocket）

  REST API は機能が豊富（使用量プラン・APIキー・リクエスト検証）、HTTP API は低遅延・低コストでシンプル、WebSocket API は双方向のリアルタイム通信に対応する。

  前提: 性能の指標（IOPS/スループット/帯域幅/レイテンシー）

  関連: Amazon API Gateway

• Lambda のバージョンとエイリアス

  発行したバージョンは不変で、エイリアスが特定バージョンを指す可変ポインタ。エイリアスの加重ルーティングでカナリア/線形のトラフィック移行を行う。

  前提: AWS Lambda、Route 53 ルーティングポリシー

• Step Functions（Standard/Express・ASL）

  ワークフローを Amazon States Language（ASL）で定義する。Standard は長時間・厳密な実行履歴向け、Express は高頻度・短時間のイベント処理向けで課金とセマンティクスが異なる。

  前提: 配信セマンティクス（少なくとも1回/正確に1回）、AWS Step Functions

• 専有ホスト（Dedicated Host）

  物理サーバー1台を丸ごと占有する EC2 配置オプション。ソケット・コア・ホストIDが可視化され、既存のソケット/コア単位のソフトウェアライセンス（BYOL）を持ち込みたい場合に使う。専有インスタンスより高価だが、同一ホスト上のインスタンス配置を制御できる。

  関連: 専有インスタンス（Dedicated Instance）

• EC2 Fleet

  1回のリクエストで複数のインスタンスタイプ・購入オプション（オンデマンド/リザーブド/スポット）・AZ を横断し、目標容量を満たすインスタンス群を起動する機能。オンデマンドとスポットを組み合わせて起動できるのが Spot Fleet との違い。リクエストタイプは instant（同期・一回限り）/request（非同期・一回限り）/maintain（容量を維持し中断分を自動補充）の3種で、既定は maintain。

  前提: 料金モデル（オンデマンド/Savings Plans・RI/スポット）、Spot Fleet

• AWS Graviton（ARM インスタンス）

  AWS 設計の ARM ベースプロセッサ。同等性能で x86 より低価格・高い電力効率（コスト最適化と持続可能性に寄与）。対応ワークロード（多くの Linux・コンテナ・マネージドサービス）で移行すると価格性能比が向上する。

  前提: マネージドサービス（管理の境界）、Well-Architected の6本柱

• プレイスメントグループ（クラスター/分散/パーティション）

  インスタンスの物理配置戦略。クラスター＝同一ラックに密集し低遅延・高スループット（HPC）。分散（スプレッド）＝別ハードウェアに分けて同時障害を回避（少数の重要インスタンス）。パーティション＝グループ単位で障害分離（HDFS 等の分散システム）。

  前提: 性能の指標（IOPS/スループット/帯域幅/レイテンシー）

• Spot Fleet

  複数のインスタンスタイプ・AZ を横断してスポットインスタンス（一部オンデマンド併用可）の目標容量を維持する仕組み。割り当て戦略（容量最適化・最低価格など）で中断されにくい構成を自動選択し、中断時は代替プールへ自動的に再配置する。

  前提: 料金モデル（オンデマンド/Savings Plans・RI/スポット）

• EC2 ステータスチェックと自動回復

  システムステータスチェック＝AWS 側のインフラ障害（ホスト/ネットワーク）。インスタンスステータスチェック＝OS/設定など内部要因。アタッチドEBSステータスチェックもある。CloudWatch アラームの EC2 アクション（recover/reboot/stop/terminate）で自動回復を設定する。

  前提: Amazon CloudWatch

• クロスゾーン負荷分散

  各ノードが全 AZ のターゲットへ均等に振り分ける設定。無効だと AZ ごとの台数差で偏りが出る。ALB は既定で有効（無料）、NLB は既定で無効（有効化は AZ 間転送課金あり）。

  前提: データ転送料金（リージョン内/間・送出）

• 埋め込みモデルの選定

  RAG の検索精度を左右する埋め込みモデルの選択。次元数（精度とストレージ/コストのトレードオフ）、ドメイン適合、対応言語、レイテンシで選ぶ。クエリと文書は同じモデルで埋め込み、変更時は全体を再埋め込みする必要がある。

  前提: FM 選定（基盤モデルの選択）、性能の指標（IOPS/スループット/帯域幅/レイテンシー）

• エラー率

  総リクエスト数に対する失敗リクエスト数の割合。SLIとして最もよく使われる指標の一つで、CloudWatchメトリクスやアラームのしきい値に使う。急上昇はデプロイ起因の障害やスロットリングの兆候として監視する。

  前提: Amazon CloudWatch

• EventBridge のクロスアカウント連携

  あるアカウントのイベントバスから別アカウントのバスへイベントを転送し、組織横断のイベント駆動を実現する。リソースベースポリシーで送信元を許可する。集中監査やセキュリティイベントの集約に使う。

  前提: IAM ポリシーの構造（Effect/Action/Resource/Condition）、リソースベースポリシー

• EventBridge Scheduler

  cron・レート・一回限りのスケジュールを大規模かつタイムゾーン対応で実行できる EventBridge の機能。数百万単位のスケジュールを個別管理でき、旧来の CloudWatch Events ルールによるスケジュール実行の後継として位置づけられる。

  前提: Amazon CloudWatch

  関連: EventBridge Pipes

• 結果整合性（eventual consistency）

  書き込み直後は古い値が読まれる可能性があるが、時間の経過とともに全レプリカが最終的に収束する整合性モデル。高可用性・低遅延を優先する分散データストアの既定挙動になっていることが多い。強整合性が不要な読み取りに使うことでスループットを稼げる。

  前提: 性能の指標（IOPS/スループット/帯域幅/レイテンシー）

  関連: 強整合性（strong consistency）

• FM 選定（基盤モデルの選択）

  用途に最適な基盤モデルを選ぶ作業。ベンチマーク・能力と制約（モダリティ・コンテキスト長・言語）・コスト・レイテンシ・ライセンスを評価し、必要なら小規模パイロットで比較する。最大モデルが常に最適とは限らず、タスク適合で選ぶ。

  前提: 性能の指標（IOPS/スループット/帯域幅/レイテンシー）

• データ検証・処理（取り込み前）

  RAG/学習に取り込む前にデータの品質を担保する処理。重複排除・形式統一・PII 検出/マスク・有害コンテンツ除去・メタデータ付与を行い、Glue Data Quality 等で検証する。ゴミを入れない（garbage-in 防止）ことが回答品質の土台。

  前提: AWS Glue、Glue Data Quality（DQDL）

• 統制された展開（ガバド・ロールアウト）

  生成 AI を本番へ安全に出す運用。API ゲートウェイ/プロキシで入口を一元化（認証・レート制限・ロギング・モデル切替）、CI/CD に評価ゲートを組み込み、A/B・カナリアで段階展開する。問題時は即ロールバック。

  前提: Amazon API Gateway、レート制限

• べき等な HTTP メソッド

  HTTP メソッドの性質。GET/PUT/DELETE はべき等（何度呼んでも結果が同じ）、POST は非べき等（呼ぶたび作成され得る）。再試行やリトライ設計で重要＝べき等な操作は安全に再送でき、非べき等はべき等キーで重複を防ぐ。

  前提: べき等性、リトライ設計

• アクセスアドバイザー（最終アクセス情報）

  IAM の機能で、ユーザー/ロール/ポリシーが各サービスに最後にアクセスした日時（last-accessed 情報）を表示する。使われていない過剰な権限を特定し、最小特権へ絞り込むのに使う。

• IAM グループ

  複数の IAM ユーザーをまとめてポリシーを一括付与するための入れ物。グループ自体はプリンシパルではなくロールを引き受けることもできない（あくまでユーザーへの権限配布を簡略化する仕組み）。グループの入れ子（グループの中にグループ）は不可。

  前提: プリンシパル、IAM ユーザー

• IAM 管理ポリシー

  複数のIAMユーザー・グループ・ロールにアタッチして再利用できる独立したポリシーオブジェクト。AWSが作成・更新するAWS管理ポリシー（手早いが粒度が粗い）と、自分で作成しバージョン管理できるカスタマー管理ポリシー（推奨、最小特権を実現しやすい）に分かれる。

  前提: AWS IAM

  関連: IAM インラインポリシー

• パスワードポリシー

  アカウント全体の IAM ユーザーパスワードに適用する規則。最小文字数・大小英数記号の要求・有効期限・過去パスワードの再利用禁止などを強制でき、アクセスキーの定期ローテーションと合わせて認証情報の衛生を保つ。

  前提: IAM ユーザー、S3 ライフサイクル（遷移と有効期限）

• IAM ポリシーシミュレーター

  実際にリクエストを行わずに、特定のプリンシパルがあるアクションを許可されるかをポリシー評価で検証するツール。デプロイ前の権限テストに使う。

  前提: プリンシパル、IAM ポリシー評価ロジック

• セッションポリシー

  AssumeRole 時にプログラムで渡す一時的なインラインポリシー。引き受けるロールの権限をその場でさらに絞り込む（権限を増やすことはできない）。

  前提: IAM インラインポリシー、AssumeRole

• イミュータブルインフラ

  稼働中のサーバーを変更せず、新しいイメージ（AMI/コンテナ）で作り直して入れ替える運用方式。構成ドリフトを排除し、ロールバックは旧バージョンへ戻すだけ。Blue/Green や Auto Scaling と相性が良い。

  前提: Auto Scaling、ML データ準備（エンコード/スケーリング/不均衡）

• Knowledge Bases の複数ソース統合

  1 つの知識ベースに S3・Web クローラ・データベース等の複数ソースを統合取り込みし、横断検索できる構成。ソースごとにメタデータを付与してフィルタやアクセス制御を効かせ、出典の異なる根拠を一貫して扱う。

  前提: Amazon Bedrock Knowledge Bases、Glue クローラ

• KMS 暗号化コンテキスト

  暗号化時に指定する追加の鍵と値のペア。復号時に同じコンテキストを要求することで「正しい文脈でのみ復号できる」拘束を与え、CloudTrail にも記録されて監査性が上がる。S3・Secrets Manager 等が内部的に利用する。

  前提: AWS CloudTrail、AWS Secrets Manager

• Lambda の実行設定（メモリ/タイムアウト//tmp）

  メモリ割り当て（128MB〜10GB・増やすと CPU も比例して増え高速化/低コスト化することも）。タイムアウト（最大15分）。一時ストレージ /tmp（最大10GB）。これらの調整が性能とコストを左右する。

  前提: AWS Lambda、Lambda の構成（レイヤー・環境変数・一時ストレージ）

• 最小権限の原則

  各アイデンティティ（人・アプリ・サービス）には、業務の遂行に必要な最小限の権限だけを与えるという設計原則。過剰な権限は誤操作や侵害時の被害範囲（ブラスト半径）を広げるため、IAM ロールやポリシー、権限境界を通じて継続的に絞り込む。

  前提: AWS IAM、ブラストラディウス（影響範囲）

• k-means クラスタリング

  教師なしで、データを k 個のクラスタに分ける代表的手法。各点を最寄りの重心へ割り当て→重心更新を反復する。k はエルボー法/シルエットで選ぶ。スケールに敏感なので標準化が前提。顧客セグメンテーション等に使う。

  前提: ML データ準備（エンコード/スケーリング/不均衡）

• ワンホットエンコーディング

  カテゴリ変数を、各カテゴリに対応する 0/1 のフラグ列へ変換する手法。順序のないカテゴリ（色・地域）に使い、ラベルエンコーディング（整数化＝誤った順序を与える）の代わりに用いる。次元が増えるため高カーディナリティでは別手法（埋め込み等）を検討。

  前提: DynamoDB の容量挙動（ホットパーティション/適応キャパシティ）、ML データ準備（エンコード/スケーリング/不均衡）

• Automatic Model Tuning（HPO）

  ハイパーパラメーターを自動探索する機能。ベイズ最適化・ランダム・グリッド・Hyperband の戦略で、目標メトリックを最大/最小化する構成を見つける。

  前提: 主要なハイパーパラメーター

• SageMaker Autopilot

  表形式データから前処理・アルゴリズム選択・チューニングを自動化し、説明可能な候補モデルを生成する AutoML 機能。

  前提: Amazon SageMaker

• SageMaker Feature Store

  特徴量を保存・共有・再利用するリポジトリ。低遅延推論向けのオンラインストアと学習向けのオフラインストア（S3）を持ち、学習と推論で同じ定義を共有して training-serving skew を防ぐ。

  前提: Amazon SageMaker、性能の指標（IOPS/スループット/帯域幅/レイテンシー）

• SageMaker JumpStart

  事前学習済みモデル（基盤モデル含む）やソリューションテンプレートをワンクリックで配置・微調整できるハブ。

  関連: Amazon SageMaker

• SageMaker Model Registry

  モデルをモデルパッケージグループでバージョン管理し、承認ステータス（承認/却下）を付けてデプロイの可否を統制するカタログ。

  前提: Amazon SageMaker、モデルレジストリ（生成 AI の版管理）

• Amazon Mechanical Turk

  クラウドソーシングで人手のタスク（データのラベル付け・検証など）を多数のワーカーに依頼するマーケットプレイス。ML 学習用のラベル付きデータ作成に使う。

  前提: AWS Marketplace

• アンサンブル学習（バギング/ブースティング）

  複数モデルを組み合わせて精度を上げる手法。バギング（並列・分散低減・ランダムフォレスト）とブースティング（逐次・バイアス低減・XGBoost）が代表。

  関連: SageMaker 組み込みアルゴリズムの選定

• Ground Truth と作る/使うの判断

  SageMaker Ground Truth は学習データのラベリングを行い、ワークフォース（Mechanical Turk＝公開・安価だが機密不可／ベンダー管理／プライベート＝社内・機密向け）と自動ラベリング（アクティブラーニングで人手を曖昧な例だけに絞りコスト削減）、アノテーション統合（多数決）で品質を担保する。構築方針は AI サービス（一般課題・学習不要・最速）→各サービスの Custom→SageMaker フルカスタム（固有要件）の連続スペクトラムで選ぶ。

  前提: Amazon SageMaker、Amazon Mechanical Turk

• SageMaker 学習の入力モードとデータ供給

  大規模学習のデータ供給を選ぶ。File モード＝学習前に全データを EBS にコピー（小規模・単純だが起動が遅い）、Pipe モード＝S3 から直接ストリーミング（大容量・開始が速い）、Fast File モード＝POSIX 風に遅延ロード（手軽さと速さの両立）。同じデータを多数ジョブ/HPO で再利用するなら FSx for Lustre（S3 連携の並列 FS）。組み込みは RecordIO-protobuf が効率的（疎データに有利）。

  前提: Amazon SageMaker

• 推薦システム（協調フィルタリング）

  ユーザーとアイテムの相互作用から好みを予測する。協調フィルタリングは似たユーザー/アイテムの行動を使い、SageMaker では Factorization Machines が代表的。

  前提: Amazon SageMaker、SageMaker 組み込みアルゴリズムの選定

• 転移学習とデータ拡張

  事前学習済みモデルを少量データで適応する。度合いは、データ極小/近ドメイン＝特徴抽出器として凍結（最終層のみ）、中程度＝上位層の部分微調整、十分/遠ドメイン＝全層を低 LR で微調整。過学習対策はデータ拡張（回転/反転/切り抜き）・バッチ正規化・ドロップアウト・early stopping。SageMaker JumpStart で事前学習済みモデルを微調整できる。

  前提: Amazon SageMaker、SageMaker JumpStart

• モノリス

  アプリケーションの全機能を 1 つの大きなコードベース・デプロイ単位にまとめるアーキテクチャスタイル。開発初期はシンプルだが、規模が大きくなるとデプロイ単位が粗くなり、一部の変更のために全体を再デプロイする必要が生じやすい。

  関連: マイクロサービス

• デフォルトルート（0.0.0.0/0）

  ルートテーブルで「他のどのルートにも一致しない宛先」を送る既定の経路。パブリックサブネットでは IGW を、プライベートサブネットでは NAT ゲートウェイを指す。外向き通信の出口を決める。

  前提: ルートテーブル、パブリック/プライベートサブネット

• エフェメラルポート

  クライアントが接続の戻り通信用に一時的に使う高位のポート番号（一般に 1024–65535）。ステートレスなファイアウォールルール（例：ネットワーク ACL）では、戻り通信を許可するためにこの範囲を明示的に開ける必要があり、見落としやすい設定ミスの原因になる。

  前提: ポート番号

• Route 53 Resolver エンドポイント

  ハイブリッド DNS の仕組み。インバウンドエンドポイント＝オンプレから AWS 内の名前解決を受ける入口。アウトバウンドエンドポイント＋Resolver ルール＝AWS から特定ドメインをオンプレ DNS へ転送する。VPC とオンプレで相互に名前解決できる。

  前提: Amazon Route 53、DNS / 名前解決（レコードタイプ）

• オプショングループ

  DB エンジン固有の追加機能（Oracle の Transparent Data Encryption、SQL Server の Native Backup 等）を有効化する設定の集まり。パラメータグループがエンジン設定全般を扱うのに対し、オプショングループはエンジン向けのプラグイン的な拡張機能に限定される。主に Oracle・SQL Server 等の対象エンジンで使われ、Aurora（MySQL/PostgreSQL互換）など元々オプショングループの概念を持たないエンジンもある。

  前提: Amazon Aurora、DB パラメータグループ

• DB パラメータグループ

  DB エンジンの設定値（最大接続数・タイムアウト・文字コード等）をまとめて管理するテンプレート。動的パラメータは即時反映されるが、静的パラメータの変更はインスタンスの再起動が必要になる点が試験で問われやすい。

  前提: IAM ポリシーの構造（Effect/Action/Resource/Condition）

• 読み書き分離

  書き込みは常にプライマリインスタンスへ送り、読み取りはリードレプリカへ振り分けて負荷を分散するデータベースアクセスパターン。アプリ側またはRDS Proxyのようなプロキシ層で接続先を出し分ける。レプリカは非同期複製のため、書き込み直後の読み取りで反映漏れ（レプリケーションラグ）が起こりうる点に注意する。

  前提: 非同期レプリケーション、Amazon RDS Proxy

• AWS Resource Explorer

  リージョン横断でリソースを検索・発見するサービス。既定は単一アカウント内の検索で、組織全体の横断検索はマルチアカウント検索の設定が必要。タグや種別で素早く探せ、棚卸しに使う。Resource Groups（グループ化）に対し検索が主眼。

  前提: AWS Resource Groups、IAM ポリシーの構造（Effect/Action/Resource/Condition）

• リザーブドインスタンスの種別

  スタンダード RI＝最大割引だが変更が限定的。コンバーティブル RI＝ファミリー/OS 等を変更でき柔軟（割引はやや低い）。リージョン RI＝AZ をまたいで柔軟、ゾーン RI＝特定 AZ にキャパシティ予約付き。支払いは全額前払い/一部前払い/前払いなし。

  前提: 料金モデル（オンデマンド/Savings Plans・RI/スポット）、オンデマンドキャパシティ予約

• ルートユーザーの保護

  アカウント作成時の最上位 ID＝ルートユーザーはほぼ全権を持つため、日常利用せず保護する。MFA を有効化、アクセスキーを作らない/削除、強固なパスワード、請求/解約など一部の操作のみに限定。Organizations の集中管理で利用を監視する。

  前提: AWS Organizations（一括請求）、ルートユーザー

• S3 バッチオペレーション

  数十億規模のオブジェクトに対し、コピー・タグ付け・ACL 変更・Lambda 呼び出し・復元などの操作を一括実行するマネージドジョブ。対象は S3 インベントリやマニフェストで指定する。

  前提: AWS Lambda

  関連: S3 レプリケーションの機能（RTC/バッチ/インベントリ）

• S3 レプリケーションルール（CRR/SRR/双方向）

  CRR＝クロスリージョン（DR・地理的近接）、SRR＝同一リージョン（ログ集約・アカウント分離）。双方向レプリケーションでマルチリージョンの読み書きを支える。プレフィックス/タグで対象を絞り、所有者上書きや既存オブジェクトのバッチ複製も設定する。

  前提: マルチリージョン構成（アクティブ-アクティブ/スタンバイ）

• S3 サーバーアクセスログ

  バケットへのリクエストを詳細記録（リクエスタ・操作・応答）し、別バケットへ保存する機能。アクセス分析やセキュリティ監査に使う。API レベルの記録は CloudTrail データイベントが補完する。

  前提: AWS CloudTrail、CloudTrail イベント種別（管理/データ/Insights）

• DR 戦略（4段階）

  バックアップ＆リストア（安・遅）→パイロットライト→ウォームスタンバイ→マルチサイト（高・速）。RTO/RPO が短いほど高コスト。クロスリージョンレプリケーション＋Route 53 フェイルオーバーで広域障害に備える。

  前提: Amazon Route 53

• S3 の性能機能（Transfer Acceleration / S3 Select）

  Transfer Acceleration はエッジ経由で遠距離アップロードを高速化、マルチパートアップロードは大容量を分割並列化する。S3 Select（オブジェクト内を SQL で部分取得）は新規利用が非推奨で、S3 上のクエリは Athena 等が推奨。

  前提: Amazon Athena

• Amazon Fraud Detector

  機械学習でオンライン不正（不正アカウント・不正取引）を検出するマネージド サービス。

  前提: GuardDuty 検出器 / 脅威リスト、マネージドサービス（管理の境界）

• Schema Conversion Tool（SCT）

  異なる DB エンジン間の移行（例: Oracle→Aurora PostgreSQL）で、スキーマやストアドプロシージャを変換するツール。変換できない箇所はレポート化される。同種エンジンの移行では不要で DMS のみで足りる。

  前提: Amazon Aurora

• ストラングラーフィグパターン

  モノリスを安全に近代化する段階移行の手法。API Gateway や ALB をファサードに置き、機能を 1 つずつ新サービスへ切り出してルーティングを差し替え、最後に旧モノリスを廃止する。一括書き換え（ビッグバン）の高リスクを避ける。

  前提: Amazon API Gateway、モノリス

• SCP 拒否リスト戦略

  既定の FullAWSAccess を残したまま、禁止したい操作だけを Deny で列挙する SCP 運用方式。柔軟で最も一般的。SCP は権限の上限であり付与はしない（実効権限＝ SCP ∩ IAM）。

• SNS メッセージフィルタリング

  サブスクリプションにフィルタポリシーを設定し、メッセージ属性に一致するものだけを各サブスクライバーへ配信する仕組み。1 つのトピックから条件別に振り分け、不要な受信側処理を減らす。

• CloudWatch エージェント

  EC2 のメモリ使用率やディスク空き容量などゲスト OS 内のメトリクスは標準では取得できず、導入が必要なエージェント（SOA 頻出のひっかけ）。ログの収集も担う。

  前提: Amazon CloudWatch

• スポット中断通知

  AWS がスポットインスタンスの容量を回収する約 2 分前に発行される通知。EventBridge のイベントやインスタンスメタデータ（instance-action）で受け取り、チェックポイント保存や後続タスクへの引き継ぎなど、中断前に安全に処理を終える猶予として使う。

  前提: 料金モデル（オンデマンド/Savings Plans・RI/スポット）、インスタンスメタデータ（IMDSv2）

• SQS ロングポーリング

  SQS の受信方式のうち、メッセージが来るまで最大 20 秒待ってから応答する方式。空受信が減りリクエストコストとノイズを削減でき、原則こちらが推奨。WaitTimeSeconds で設定。

  前提: ポーリング vs Webhook（プッシュ/プル）

  関連: SQS ショートポーリング

• SQS ショートポーリング

  SQS の受信方式のうち、メッセージが無くても即座に応答する既定方式。応答は速いが空受信が増え、リクエスト数とコストが増えやすい。

  前提: ポーリング vs Webhook（プッシュ/プル）

  関連: SQS ロングポーリング

• SSM 変更カレンダー / メンテナンス計画

  自動化やパッチ適用を「許可/禁止」する期間をカレンダーで定義する機能。繁忙期や凍結期間（チェンジフリーズ）に変更を止め、Automation や Run Command の実行をゲートする。

  前提: Run Command

• 強整合性（strong consistency）

  書き込み完了後の読み取りは必ず最新の値を返す整合性モデル。結果整合性より遅延やコストが増えがちだが、在庫数や残高のように古い値の読み取りが許されない場面で選ぶ。整合性モデルはこのトレードオフに基づき用途ごとに使い分ける。

  前提: 性能の指標（IOPS/スループット/帯域幅/レイテンシー）

  関連: 結果整合性（eventual consistency）

• サブネットの予約アドレス

  VPCの各サブネットで、ネットワークアドレス・VPCルーター用・DNS用・将来予約の最初の4つと、ブロードキャスト用（実際は未使用）の最後の1つ、計5アドレスをAWSが予約し割り当てできないようにする仕様。/24サブネットなら256個中251個が利用可能アドレスになる。

  前提: ブロードキャスト

  関連: VPC/サブネットのクォータ

• ユニキャスト

  1 台の送信元から 1 台の宛先へ届ける、最も一般的な 1 対 1 の通信方式。通常のクライアント・サーバー通信やほとんどの API 呼び出しはこの方式を前提に設計される。

  関連: エニーキャスト

• PrivateLink エンドポイントサービス

  自社サービスを NLB の背後に置き、PrivateLink 経由で他 VPC/アカウントへ非公開で提供する仕組み。トラフィックは AWS 内部のみを通り、インターネットや VPC ピアリングを介さずに SaaS 型提供ができる。

  前提: AWS PrivateLink、VPC ピアリング

• セカンダリ CIDR

  既存の VPC に後から追加の CIDR ブロックを割り当て、利用可能な IP アドレス空間を拡張する機能。プライマリ CIDR と重複しない範囲を選ぶ必要があり、IP アドレス枯渇（サブネット追加の余地がない）への対処としてよく使われる。

  前提: CIDR 表記

• VPC 共有（VPC sharing）

  AWS Resource Access Manager（RAM）を使い、1つの VPC のサブネットを組織内の複数アカウントへ共有する仕組み。参加者アカウントはそのサブネット内にリソースを作成でき、ネットワーク管理を中央（オーナーアカウント）に集約しつつアカウント分離は維持できる。

  前提: IAM ポリシーの構造（Effect/Action/Resource/Condition）、Resource Access Manager（RAM）

• Bedrock の基盤モデル（プロバイダー）

  Amazon Bedrock は複数プロバイダーの基盤モデルを単一 API で提供する。Anthropic Claude・Amazon Titan/Nova・Meta Llama・Mistral・Cohere・Stability AI などをユースケースで選ぶ。

  前提: Amazon Bedrock

• PartyRock

  Amazon Bedrock を基盤にした、コード不要で生成 AI アプリを試作できる学習向けの遊び場（プレイグラウンド）。

  前提: Amazon Bedrock

• Strands Agents

  AI エージェントを少ないコードで構築するためのオープンソース SDK。モデル・ツール・プロンプトを結びつけて、推論しながらツールを呼ぶエージェントを作れる。

• AWS Agent Squad

  複数の AI エージェントを協調させる OSS のオーケストレーションフレームワーク（旧 Multi-Agent Orchestrator）。Classifier が入力と会話履歴から最適なエージェントを動的に選び、SupervisorAgent が並列協調する。

  前提: 会話履歴 / セッションメモリ

• Bedrock agent tracing（推論トレース）

  エージェントの推論ステップを記録・可視化し、なぜその結論に至ったかを監査・デバッグ・透明性提示に使う機能。

  前提: Amazon Bedrock

• Amazon Bedrock Data Automation

  文書・画像・音声・動画などの非構造化データから構造化出力を生成する自動処理ワークフロー。GenAI アプリのデータ準備を自動化する。

  前提: Amazon Bedrock

• リランカー（reranker）

  検索（取得）後の候補を適合度順に並べ替え、上位結果の質を高める後段の仕組み。ハイブリッド検索の後に適用し、検索そのもの（埋め込み/ベクトル検索）は置き換えない。

  関連: RAG 検索機構（セマンティック/ハイブリッド）

• セマンティックキャッシュ

  表現が違っても意味的に同一の問い合わせの結果を再利用し、不要な FM 呼び出しを削減するキャッシュ手法。**問い合わせの埋め込みベクトルの類似度**でキャッシュヒットを判定する点が、文字列一致や決定的ハッシュによる完全一致キャッシュ（プロンプトキャッシュ等）と異なる。

  関連: プロンプトキャッシュ

• Amazon Q

  業務やコーディングを支援する、すぐ使える生成AIアシスタント（Amazon Q Business / Amazon Q Developer）。

• Amazon Rekognition

  画像・動画を分析する用途別AIサービス（物体・顔・不適切コンテンツの検出）。

• Amazon Textract

  書類・帳票からテキストや項目を抽出する用途別AIサービス（OCR＋構造抽出）。

• Amazon Transcribe

  音声をテキストに変換する（音声認識）AI サービス。通話・会議・メディアの文字起こしに使い、話者分離やカスタム語彙、リアルタイム/バッチに対応する。

• Gateway Load Balancer（GWLB）

  サードパーティの仮想アプライアンス（次世代ファイアウォール・IDS/IPS）をトラフィック経路に透過的に挿入するための L3 ゲートウェイ。GENEVE（ポート 6081）でパケットをカプセル化してアプライアンス群へ送り、GWLB エンドポイント（GWLBe）をルートテーブルに挟むことで、送信元 VPC のトラフィックを検査 VPC へ回す。

  前提: ルートテーブル

• Aurora のエンドポイント（クラスター/リーダー/カスタム）

  Aurora の接続先。クラスター（ライター）エンドポイント＝書き込み先（フェイルオーバーで自動追従）。リーダーエンドポイント＝読み取りをレプリカ群へ負荷分散。カスタムエンドポイント＝任意のインスタンス集合（分析用など）をグループ化。用途で使い分ける。

  前提: Amazon Aurora

• AWS App2Container (A2C)

  既存の Java/.NET アプリを分析してコンテナ化（Dockerfile・ECS/EKS デプロイ用アーティファクト・CI/CD パイプライン雛形を生成）する移行ツール。レガシーアプリのモダナイズ（コンテナ化）を自動化する。

  前提: コンテナ化

• データ転送料金（リージョン内/間・送出）

  AWS コストの見落としがちな要素。インターネットへの送出（egress）は有料、受信は無料。同一 AZ 内は無料、AZ 間/リージョン間は課金。NAT ゲートウェイ経由や AZ 跨ぎの設計はコストに直結する。VPC エンドポイントで NAT 経由の転送を削減できる。

• 無料利用枠（Free Tier）

  無料で試せる仕組み。2025 年 7 月以降の新規アカウントはサインアップ時にクレジットを付与するプラン型（一定額・利用期間に制限）。従来型は 12 か月無料／常時無料／トライアルの 3 形態。

• ゲームデー

  意図的に障害を注入し、実際のインシデント対応をチームで演習するイベント。AWS の Fault Injection Service（FIS）を使ってインスタンス停止やネットワーク遮断などのカオス実験を安全に自動化し、運用手順やアラートの実効性を検証する。

  前提: AWS Fault Injection Simulator (FIS)

• AWS Health（イベント/組織ビュー）

  自分のリソースに影響する AWS 側のイベント（メンテナンス・障害・予定変更・証明書失効など）を通知するサービス。Health API/EventBridge で自動対応に連携し、Organizational View で全アカウントを一元把握する。

  前提: 証明書失効（CRL / OCSP）

• AWS Health Dashboard

  AWSサービスの稼働状況と、自分のリソースへの影響イベントを通知する（AWS側の状態。Trusted Advisorは自分の環境向けで別物）。

  前提: AWS Trusted Advisor

• AWS License Manager

  ソフトウェアライセンス（BYOL：持ち込みライセンス）を一元管理するサービス。ライセンス規則を定義して上限超過を防ぎ、専有ホストやコア/ソケット数に基づく利用を追跡・レポートする。組織横断のライセンスコンプライアンスに使う。

  前提: 専有ホスト（Dedicated Host）

• AWS Resilience Hub

  アプリケーションのレジリエンス（回復力）を評価・追跡するサービス。RTO/RPO の目標を定義し、構成を分析して目標とのギャップや単一障害点を洗い出し、改善の推奨と継続的な評価を提供する。DR/可用性設計の検証に使う。

  前提: 単一障害点（SPOF）

• AWS Serverless Application Repository (SAR)

  SAM で定義済みのサーバーレスアプリを検索・デプロイ・公開できるリポジトリ。再利用可能なアプリ/コンポーネント（関数・API・連携部品）を組織内外で共有し、ワンクリックに近い形で展開できる。

  前提: サーバーレス（FaaS）

• 署名バージョン4（SigV4）

  AWS API リクエストにアクセスキーで署名する標準方式。リクエスト内容・日時・リージョン・サービスから署名を計算し、改ざん検知とリプレイ防止を行う。SDK/CLI が自動処理。署名付き URL もこの仕組みに基づく。

  前提: S3 の開発機能（署名付き URL・暗号化）

• 誤差逆伝播

  ニューラルネットワークの学習で、出力の誤差を出力層から入力層へ逆向きに伝えながら各重みの勾配を計算する手法。勾配降下法と組み合わせて重みを更新するために使われ、深層学習の学習アルゴリズムの中核をなす。

  前提: 勾配降下法

• Agent Evaluations

  エージェント型アプリケーションのタスク完了率、ツール呼び出しの適切さ、推論の質などを測る評価機能。RAG を含むエージェントの応答品質を人手や自動指標で継続的にチェックし、プロンプトやツール定義の改善に役立てる。

  前提: Function Calling（関数呼び出し）

• 請求アラーム

  CloudWatch の EstimatedCharges メトリクスにしきい値を設定し、想定外の課金を早期に検知する仕組み。このメトリクス自体は us-east-1（バージニア北部）でのみ記録されるため、請求アラームも us-east-1 で作成する必要がある。

  前提: Amazon CloudWatch

• スタックポリシー

  スタック更新時に、特定リソースの更新/置換/削除を保護する JSON ポリシー。本番 DB などを意図しない更新から守る。IAM ポリシーとは別物。

  前提: JSON

• CloudFormation の検証（Hooks/Guard/Linter）

  テンプレート品質と統制の道具。cfn-lint＝構文/ベストプラクティス検査。CloudFormation Guard（cfn-guard）＝ポリシー・アズ・コードで規約準拠を検証。Hooks＝プロビジョニング前にカスタム検査を強制。ドリフト検出と組み合わせて構成統制を保つ。

  前提: AWS CloudFormation

• CloudFormation テンプレートの構成

  テンプレートの主要セクション。Parameters＝入力値、Mappings＝環境/リージョン別の対応表、Conditions＝条件分岐、Resources＝作成物（必須）、Outputs＝出力（他スタックへ Export）。これらで再利用可能で環境差を吸収する IaC を書く。

  前提: AWS CloudFormation

• CloudFront オリジングループ（オリジンフェイルオーバー）

  プライマリとセカンダリのオリジンを束ね、特定のエラー応答時に自動でセカンダリへ切り替える高可用構成。S3 と別リージョンの S3 や ALB を組み合わせて配信元の冗長化を行う。

  前提: Amazon CloudFront

• コネクション追跡

  ステートフルなファイアウォール（例：セキュリティグループ）が確立済みの接続を状態テーブルで記憶し、その戻り通信を自動的に許可する仕組み。ステートレスなルールと違い、戻り方向のエフェメラルポートを個別に開ける必要がない。

  前提: エフェメラルポート

• CloudWatch Contributor Insights

  ログから「上位の貢献者」（最もエラーを出す IP・最も遅い API・最頻アクセス項目など）をルールでランキング表示する機能。負荷の偏りや異常な発信元の特定に使う。

  前提: Amazon CloudWatch

• メトリクス計算（Metric Math）

  複数のメトリクスを数式で組み合わせて新しい時系列を作る機能。エラー率（エラー数÷総数）や合計、異常検出バンドなどを算出し、アラームやダッシュボードに使う。

  前提: エラー率

• スキーマレジストリ

  ストリーム/メッセージのスキーマを集中管理し、互換性（後方/前方）を強制してプロデューサーとコンシューマーの破壊的変更を防ぐ仕組み。Glue Schema Registry が代表。

  前提: AWS Glue

• DNS / 名前解決（レコードタイプ）

  ドメイン名を IP へ変換する仕組み。主なレコード＝A（IPv4）/AAAA（IPv6）/CNAME（別名・頂点不可）/MX（メール）/TXT（検証）/NS（委任）。AWS の Alias レコードは頂点でも AWS リソースを指せる CNAME 代替。TTL でキャッシュ時間を制御。

• AWS CodeArtifact

  依存パッケージ（npm/pip/Maven/NuGet 等）を一元管理するアーティファクトリポジトリ。アップストリームに公開リポジトリを設定して透過的にプロキシ・キャッシュでき、社内パッケージと公開パッケージを 1 つのエンドポイントに統合する。

  前提: AWS Artifact

• コールドスタンバイ / クロスリージョン DR

  AWS の標準的な DR は 4 段階＝バックアップ&リストア／パイロットライト／ウォームスタンバイ／マルチサイト（アクティブ-アクティブ）で、RTO/RPO とコストのトレードオフで選ぶ。コールドスタンバイはバックアップ&リストアに近い最小構成の通称。クロスリージョン DR は AMI/スナップショット/データのリージョン間コピーと IaC で別リージョンへ復旧する。

  前提: DR 戦略（4段階）

• エンベロープ暗号化とデータキー

  データをデータキーで暗号化し、そのデータキーを KMS のマスターキーで暗号化して保存する方式。GenerateDataKey で平文/暗号文のデータキーを取得し、平文は使用後に破棄する。

• Lambda 同時実行（プロビジョンド/予約済み）

  Lambda の同時実行制御。プロビジョンド同時実行＝実行環境を事前に温めてコールドスタートを抑える。予約済み同時実行＝関数ごとに同時実行数の上限を確保/制限する。メモリを増やすと CPU も比例して増える。

  前提: AWS Lambda

• 動的モデルルーティング

  入力の分類結果や設定に応じて、リクエストごとに使うモデルを動的に切り替える仕組み。簡単な問い合わせは小型、難問は大型へ振り分けてコストと品質を両立する。AppConfig 等で再デプロイなしにルーティング規則を更新できる。

  前提: AWS AppConfig

• EBS スナップショット共有

  EBS スナップショットを他の AWS アカウントと共有する機能。暗号化済みスナップショットを共有する場合は、スナップショット自体の共有設定に加えて、暗号化に使ったカスタマー管理キー（CMK）の鍵ポリシーで相手アカウントに使用権限を付与する必要がある。

  前提: EBS スナップショット

• ブートストラップ（初期起動処理）

  インスタンスの初回起動時に初期設定（パッケージ導入・構成取得・サービス起動）を自動実行すること。EC2 ではユーザーデータスクリプトで行い、cloud-init が処理する。

  関連: ユーザーデータ

• 専有インスタンス（Dedicated Instance）

  他の AWS アカウントのテナントとハードウェアを共有しない EC2 インスタンス配置。物理的には分離されるが、専有ホストと異なりホストの可視性（ソケット/コアID）は持たない。コンプライアンス要件で物理分離が必要だがライセンス上の可視性までは不要な場合に選ぶ。

  関連: 専有ホスト（Dedicated Host）

• 拡張ネットワーキング（ENA / EFA）

  高スループット・低遅延の通信機能。ENA（Elastic Network Adapter）＝最大100Gbps級。EFA（Elastic Fabric Adapter）＝HPC/機械学習の密結合計算向けに OS バイパスで超低遅延を実現。

  前提: 性能の指標（IOPS/スループット/帯域幅/レイテンシー）

• インスタンスストア

  ホストに物理接続された一時ストレージ。超高速だが、インスタンス停止/終了でデータが消える（揮発性）。キャッシュやスクラッチ領域向け。永続化が必要なら EBS を使う（SOA 頻出の対比）。

  前提: Lambda の構成（レイヤー・環境変数・一時ストレージ）

• パブリック IPv4 アドレスの挙動

  自動割り当てされる標準のパブリック IPv4 アドレスは動的で、インスタンスの停止・再起動のたびに変わりうる。固定したい場合は付け替え可能な Elastic IP を別途割り当てる必要がある（Elastic IP 自体は別ノードの概念）。

  関連: Elastic IP と配置グループ

• EFS のモード（パフォーマンス/スループット/ストレージクラス）

  EFS の設定軸。パフォーマンスモード＝汎用（低遅延）/最大 I/O（高並列）。スループットモード＝バースト/拡張（Elastic・需要に自動追従）/プロビジョンド。ストレージクラスは標準/低頻度アクセス（IA）で、ライフサイクル管理により自動階層化しコストを下げる。

  前提: 性能の指標（IOPS/スループット/帯域幅/レイテンシー）

• ALB の機能（ルーティング/スティッキー/ターゲットグループ）

  ALB のリスナールールはパス（/api/*）やホスト名で振り分け、ターゲットグループ単位で転送する。スティッキーセッション＝同一クライアントを同じターゲットへ固定（Cookie）。X-Forwarded-For＝元のクライアント IP を伝えるヘッダー。

• SNI（複数証明書）

  Server Name Indication。TLS ハンドシェイクでクライアントが接続先ホスト名を提示する拡張。これにより ALB（および NLB の TLS リスナー）でホスト名に応じて複数の ACM 証明書を出し分け、1 つのロードバランサーで多数のドメインを HTTPS 提供できる。

  前提: HTTPS

• ターゲットグループ属性 / 登録解除遅延

  ターゲットグループの挙動設定。登録解除遅延（コネクションドレイン）＝処理中のリクエストを完了させてから外す待機時間。スティッキー時間・スロースタート・正常/異常しきい値・ヘルスチェック間隔などを調整する。

  前提: ヘルスチェックの種類としきい値

• 転送時の暗号化（in transit）

  ネットワーク経路を通過中のデータを暗号化すること。多くの場合TLSで通信を保護する。保管時の暗号化と組み合わせて初めて、データのライフサイクル全体（保存中・移動中）を防御できるため、両方を満たすのがセキュリティの基本要件となる。

  前提: 保管時の暗号化（at rest）

• 事実性検証（ハルシネーション対策）

  生成内容が根拠と一致するかを確かめる対策。RAG で根拠（出典）に基づかせるグラウンディング、出典との類似度・信頼度スコア、引用必須化、別モデルによる検証（LLM-as-a-judge）を組み合わせ、ハルシネーション（もっともらしい誤り）を抑える。

  前提: LLM-as-a-Judge

• API リクエスト検証（入力ガード）

  生成 AI を呼ぶ前に入力を検証する防御。API Gateway のリクエスト検証やスキーマ検査、長さ/形式チェック、Guardrails の入力フィルタで、過大入力・不正・プロンプトインジェクションを呼び出し前に弾く。コストと攻撃面を減らす。

  前提: Amazon API Gateway

• モデルレジストリ（生成 AI の版管理）

  モデルやプロンプト構成、カスタマイズ済み FM をバージョン管理し、承認・ステージング・ロールバックを可能にする台帳。本番に出すモデルの来歴と評価結果を結びつけ、問題時に旧版へ即時復帰できるようにする。

• ユーザー中心の評価

  自動指標だけでなく、実利用者のフィードバック（👍/👎・自由記述・暗黙シグナル）を収集して継続的に品質を評価する運用。golden dataset の自動評価と組み合わせ、現実の満足度とタスク達成度でモデル/プロンプトを改善する。

  前提: 生成 AI の監視（固有メトリクス / golden dataset）

• 勾配降下法

  損失関数の勾配（傾き）の反対方向へ、学習率で決まる歩幅ずつパラメータを更新して損失を最小化する最適化アルゴリズム。全データを使うバッチ型のほか、1件ずつ更新する確率的勾配降下法（SGD）や少量ずつ処理するミニバッチ型などの変種がある。

• IAM 条件キー

  ポリシーの Condition で使うキー。aws:SourceIp（送信元 IP）、aws:MultiFactorAuthPresent（MFA 必須）、aws:PrincipalTag/ResourceTag（ABAC）、aws:SourceVpce（特定エンドポイント経由）等。きめ細かなアクセス制御の要。

• 認証情報レポート

  アカウント内の全 IAM ユーザーについて、パスワードの有無・MFA 有効化状況・アクセスキーの作成日や最終使用日をまとめて出力する CSV レポート。4 時間に 1 回まで生成でき、未使用の認証情報を棚卸しして無効化する監査作業の起点になる。

  前提: IAM ユーザー

• 線形回帰

  連続値のターゲットを、特徴量の重み付き線形結合として予測する基本的な教師あり学習モデル。解釈しやすく、回帰問題のベースラインとしてまず試されることが多い。

• ロジスティック回帰

  線形結合の出力をシグモイド関数に通して 0〜1 の確率を得ることで、二値分類を行うモデル。名前に「回帰」とあるが実際には分類器であり、線形回帰同様に解釈しやすく分類問題のベースラインとしてよく使われる。

  前提: 線形回帰

• MFA デバイスの種類

  多要素認証の第2要素。仮想 MFA（認証アプリの TOTP）/ハードウェア MFA（物理トークン）/FIDO セキュリティキー（パスキー・フィッシング耐性が高い）。ルートと特権ユーザーには必須。重要操作は aws:MultiFactorAuthPresent 条件で強制する。

  前提: IAM 条件キー

• 主成分分析（PCA・次元削減）

  相関する多数の特徴量を、分散を最大化する少数の合成軸（主成分）へ圧縮する次元削減法。可視化・ノイズ低減・計算コスト削減に使う。教師なしで、解釈性は下がる。t-SNE/UMAP は可視化向けの非線形代替。

  前提: プリンシパル

• SageMaker Clarify（バイアス/説明可能性）

  学習データやモデルのバイアスを検出し、SHAP 値で予測への各特徴量の寄与を説明する機能。公平性と透明性の評価に使う。

  前提: Amazon SageMaker

• SageMaker Data Wrangler

  データの取り込み・分析・前処理・特徴量変換をGUI 中心で行うツール。300 以上の組み込み変換を適用し、処理をパイプライン化してエクスポートできる。

  前提: Amazon SageMaker

• SageMaker Debugger

  学習中のテンソルやメトリクスを捕捉し、勾配消失・過学習・リソース未使用などの問題をルールで検知して訓練を最適化する。

  前提: Amazon SageMaker

• SageMaker Experiments

  学習の試行（パラメーター・メトリクス・成果物）を記録・整理・比較し、再現性のある実験管理を行う機能。

  前提: Amazon SageMaker

• SageMaker Neo

  学習済みモデルを特定のエッジ/クラウドのハードウェア向けにコンパイル最適化し、推論を高速・軽量化する機能。

  前提: Amazon SageMaker

• SageMaker Pipelines

  データ処理→学習→評価→登録→デプロイの ML ライフサイクルを再現可能な DAG として自動化する CI/CD オーケストレーション。条件ステップで品質ゲートを設ける。

  前提: Amazon SageMaker

• SageMaker Processing ジョブ

  前処理・後処理・モデル評価などをマネージドな計算上でスケールして実行するジョブ。コンテナで任意の処理を分散実行できる。

  前提: Amazon SageMaker

• AWS HealthLake

  医療データ（FHIR 形式）を保存・変換・分析するためのマネージドなヘルスデータレイク。NLP で非構造の医療テキストから情報を抽出する。

  前提: データレイク

• 推論パイプライン（マルチコンテナ）

  前処理→推論→後処理を複数コンテナの連鎖として 1 つのエンドポイントにまとめる SageMaker の構成。学習時と同じ変換を推論時に再利用できる。

  前提: Amazon SageMaker

• モデルカスタマイズ（ファインチューニング/継続的事前学習/蒸留）

  FM を用途へ適合させる手段。ファインチューニング＝ラベル付き例で振る舞いを調整（少量データ・タスク特化）。継続的事前学習＝大量の未ラベルドメインデータで知識を注入。蒸留＝大モデルの出力で小モデルを訓練し低コスト化。多くはまず RAG/プロンプトで足りるか検討してから選ぶ。

  関連: Bedrock のモデルカスタマイズ

• プライベート IP アドレス範囲（RFC1918）

  インターネットでルーティングされない私設アドレス帯：10.0.0.0/8・172.16.0.0/12・192.168.0.0/16。VPC の CIDR はこの範囲から選ぶのが基本。複数 VPC を接続する際は範囲の重複を避ける（重複するとピアリング/TGW で到達不能）。

  前提: CIDR 表記

• AI サービスオプトアウトポリシー

  組織（AWS Organizations）単位で、Amazon が AI/ML サービス改善のために顧客データを利用することを一括停止するポリシー。組織単位ポリシー（Organizations policy）の一種で、個々のアカウントごとに設定する手間を省き、データガバナンス要件への対応に使う。

  前提: AWS Organizations（一括請求）

• 委任管理者（Delegated administrator）

  GuardDuty・Config・Security Hub 等、対応サービスの組織全体にわたる管理権限を、管理アカウント以外のメンバーアカウントへ委任する仕組み。管理アカウントの操作を最小化し、セキュリティ運用チームなどへ職務分離した権限を与えられる。サービスごとに個別設定が必要。

  前提: Amazon GuardDuty

• サーキットブレーカー

  連続失敗する呼び出し先を一時的に遮断（オープン）し、無駄な再試行と連鎖障害を防ぐパターン。一定時間後に半開で試行し、回復したら閉じる。タイムアウト・リトライ・バックオフと組み合わせる。

  前提: クールダウンとウォームアップ

• 公開鍵暗号（非対称）

  公開鍵で暗号化し秘密鍵で復号する（または秘密鍵で署名し公開鍵で検証する）方式。鍵共有問題を解決し、TLS・SSH・コード署名・証明書の基盤になる。共通鍵（対称）より遅いため、実データは対称鍵で暗号化しその鍵を公開鍵で保護する（エンベロープ）。

• メタデータフィルタリング（RAG）

  チャンクに属性（出典・日付・部門・機密区分など）を付与し、検索時にフィルタして関連性とアクセス制御を高める手法。テナント分離や最新版優先、権限に応じた可視範囲の制御を、ベクトル検索と組み合わせて実現する。

  前提: チャンキング（分割戦略）

• 検索層の診断（RAG の品質切り分け）

  RAG の回答品質が低いとき、原因を検索層で切り分ける運用。埋め込みの適合、データドリフト、チャンク戦略、検索の再現率/適合率、メタデータフィルタを順に点検し、生成側（プロンプト/モデル）と区別して直す。

  前提: チャンキング（分割戦略）

• RAG 検索機構（セマンティック/ハイブリッド）

  RAG で関連文書を取り出す仕組み。セマンティック検索＝埋め込みの類似度で意味的に近いものを取得。ハイブリッド検索＝キーワード（BM25 等）とベクトルを併用し再現率を高める。reranker で上位を並べ替え、必要分だけ文脈に渡す。

  関連: リランカー（reranker）

• RDS Performance Insights

  DB の負荷を「待機イベント」と「上位 SQL」で可視化し、ボトルネックを特定する性能監視機能。DB ロード（平均アクティブセッション数）をダッシュボードで追える。CloudWatch のメトリクスを補完する。

  前提: Amazon CloudWatch

• S3 アクセスポイント

  1つのバケットにアプリ/チームごとの名前付きアクセス入口を複数作り、それぞれに専用のアクセスポリシーを付ける機能。巨大で複雑になりがちなバケットポリシーを分割して管理しやすくする。

  前提: S3 アクセス制御（バケットポリシー/ACL/所有権）

• S3 イベント通知

  オブジェクト作成/削除などのイベントを SNS・SQS・Lambda・EventBridge へ送り、処理を自動起動する仕組み。アップロードを契機にしたサムネイル生成やデータ取り込みパイプラインに使う。

  前提: AWS Lambda

• S3 ライフサイクル（遷移と有効期限）

  オブジェクトを経過日数で自動管理するルール。遷移＝より安価なストレージクラスへ移す（例 30 日で Standard-IA、90 日で Glacier）。有効期限＝古いオブジェクトや旧バージョン、未完了マルチパートを自動削除しコストを抑える。

• S3 レプリケーションの機能（RTC/バッチ/インベントリ）

  レプリケーション時間制御（RTC）＝15 分以内のレプリケーションを SLA 付きで保証。バッチレプリケーション＝既存オブジェクトを後から一括複製。S3 インベントリ＝オブジェクトと暗号化/レプリケーション状態の一覧を定期出力し、棚卸しやバッチ操作の入力にする。

  関連: S3 バッチオペレーション

• EBS ボリュームタイプ（gp3/io2/st1/sc1）

  汎用 SSD の gp3（IOPS/スループットを独立設定）、高耐久・高 IOPS の io2/io2 Block Express、スループット最適化 HDD の st1、コールド HDD の sc1 をワークロードで選ぶ。

  前提: 性能の指標（IOPS/スループット/帯域幅/レイテンシー）

• 移行戦略（7 つの R）

  ワークロードごとに選ぶ移行アプローチの分類。リホスト（無変更）／リプラットフォーム（小最適化）／リファクタ（作り替え）／リパーチェス（SaaS 化）／リタイア（廃止）／リテイン（据え置き）／リロケート（そのまま移設）。労力と価値のトレードオフで選ぶ。

• AWS マネジメントコンソール

  AWS リソースを GUI で操作・監視する Web コンソール。CLI/SDK/IaC と並ぶ主要な操作手段。

• Amazon MQ

  ActiveMQ/RabbitMQ 互換のマネージドなメッセージブローカー。既存の標準プロトコル（JMS/AMQP/MQTT 等）を使うアプリの移行に向く（新規の疎結合は SQS/SNS が一般的）。

  前提: 疎結合（デカップリング）

• マルチアカウントのネットワーク設計

  多数アカウント/VPC を Transit Gateway や Cloud WAN のハブで集約し、共有サービス VPC・集中型 egress・集中型検査（インスペクション VPC）でセキュリティとコストを最適化する。

  前提: Transit Gateway

• Amazon Personalize

  リアルタイムのレコメンデーション（推薦）を機械学習で提供するマネージド サービス。

  前提: マネージドサービス（管理の境界）

• サービスコントロールポリシー（SCP）

  AWS Organizations でアカウントや OU に適用する組織的なガードレール。許可の上限を定め、メンバーアカウントの IAM がそれを超える権限を持てないようにする（許可の最大境界）。

  前提: AWS Organizations（一括請求）

• AWS Service Catalog

  承認済みの IT サービス（CloudFormation 製品）をポートフォリオとして公開し、利用者がセルフサービスで標準構成をデプロイできるようにする。ガードレール付きで統制とスピードを両立する。

  前提: AWS CloudFormation

• Amazon SES（Simple Email Service）

  スケーラブルなメール送受信サービス。トランザクションメールやマーケティングメールを高い到達率で送信し、バウンス/苦情を管理する。

  前提: SES の配信可能性（バウンス/設定セット）

• SCP 許可リスト戦略

  既定の FullAWSAccess を外し、許可する操作だけを明示的に列挙する SCP 運用方式。厳格だが、許可漏れで正当な操作も止まりやすく管理が重い。

  前提: SCP 拒否リスト戦略

• IAM ポリシー評価ロジック

  アクセス可否の判定順序。明示的 Deny があれば常に拒否（最優先）、なければ明示的 Allow があるか確認し、Allow があり Deny がなければ許可、どこにも Allow がなければ暗黙的拒否。優先順位は「明示的拒否 ＞ 許可 ＞ 暗黙的拒否」。

• AWS Network Firewall

  VPC のトラフィックをステートフルに検査・フィルタリングするマネージドなネットワークファイアウォール。ドメイン許可リスト、IPS/IDS、プロトコル検査などで、SG/NACL より高度な境界防御を提供する。

• アクセス許可境界（Permissions Boundary）

  IAM ユーザー/ロールに付与できる権限の上限を定めるポリシー。権限を付与するのではなく、実効権限を「アイデンティティポリシー ∩ 境界」に制限する。権限委任時の過剰付与を防ぐのに使う。

  前提: IAM ユーザー

• Amazon Data Lifecycle Manager（DLM）

  EBS スナップショットや EBS-backed AMI の作成・保持・削除をポリシーで自動化するサービス。定期的なバックアップと保持期間を管理し、コンプライアンスやデータ保護（暗号化スナップショットの世代管理）を支援する。

  関連: EBS スナップショット

• 証明書失効（CRL / OCSP）

  危殆化した証明書を期限前に無効化する仕組み。CRL＝失効リストを配布。OCSP＝オンラインで個別に失効状態を問い合わせ（OCSP ステープリングで効率化）。ACM Private CA（PCA）で自社 CA を運用する際に管理する。

• Step Functions の状態（Map/Parallel/Choice）

  ステートマシンの構成要素。Task＝処理、Choice＝分岐、Parallel＝並行分岐、Map＝配列の各要素を反復（分散 Map で大規模並列）、Wait/Pass/Succeed/Fail。コールバック（.waitForTaskToken）で外部完了を待てる。

  前提: AWS Step Functions

• S3 のバージョニングとレプリケーション

  バージョニングで上書き/削除から復元可能にし、クロスリージョン/同一リージョンレプリケーションで別ロケーションへ自動複製、MFA Delete で削除を保護する。

  前提: S3 レプリケーションルール（CRR/SRR/双方向）

• SQS のリドライブ（DLQ からの再処理）

  デッドレターキューに溜まった失敗メッセージを、原因修正後に元のキューへ戻して再処理する機能（DLQ リドライブ）。最大受信回数（maxReceiveCount）を超えたメッセージが DLQ へ移る。毒メッセージの隔離と回復に使う。

  関連: デッドレターキュー（DLQ）

• パッチコンプライアンス（Patch compliance）

  Patch Manager がスキャンまたはインストールを実行した後、パッチベースラインの承認ルールに対する各インスタンスの準拠状況を集計する機能。未適用パッチがあるインスタンスを可視化し、Compliance ダッシュボードや Config ルールと連携して是正対象を洗い出す。

  関連: Patch Manager

• サブネットマスク

  IP アドレスのうちネットワーク部とホスト部の境界を示す値（例 255.255.255.0）。CIDR のプレフィックス長と表裏一体の表現で、オンプレのネットワーク機器や一部のクラウド設定ではこのドット区切り表記が使われる。

  前提: CIDR 表記

• Amazon Titan Text Embeddings

  テキストを意味ベクトルに変換する Bedrock の埋め込みモデル。RAG の文書/クエリのベクトル化に使い、次元数や正規化が検索の精度・コスト・ストレージに影響する。クエリと文書を同じモデルで埋め込むのが原則。

  前提: Amazon Bedrock

• Elastic Network Interface（ENI）

  仮想ネットワークカード。プライベート IP・Elastic IP・セキュリティグループ・MAC を持ち、インスタンス間で付け替え（フェイルオーバー）できる。複数 ENI で多重ホーミングや管理/データ系の分離を行う。

  前提: Elastic IP と配置グループ