●Monitor 設定

パフォーマンスメトリックやオペレーショナルな監視に関連する設定。

●デッドレターキュー

正常に処理できなかったイベントをSQSキューやSNSのトピックにリダイレクトしてエラーを監視・分析する。
・2回の再試行の後にイベントを処理することを失敗したイベントをキャプチャできる。その際、最初の 2 回の試行の間に 1 分間、2 回目と 3 回目の間に 2 分間の待機時間がある。
・関数エラーには、関数のコードによって返されるエラーと、タイムアウトなど関数のランタイムによって返されるエラーが含まれる。

●エクスポネンシャルバックオフ

【許容可能なリトライ】
リクエスト処理が失敗した後のリトライで、現実的に成功しそうな程度のリトライを許容可能な範囲で徐々に減らしつつ継続するアルゴリズム。再試行する度に、1秒後、2秒後、4秒後と指数関数的に待ち時間を加えていく。全体のリトライ回数を抑え効率的なリトライを実現。

●Lambda Layer

【Lambdaコード共有】
コードやライブラリ、共通のビジネスロジックをZIPアーカイブをLayerに追加し、複数のLambda関数で、外部ライブラリやビジネスロジックを共有できる仕組み。主には異なるLambda関数間で、同じ処理を使いたい場合に利用する。
・デプロイパッケージの容量を少なくなるためLambdaのソースコードの管理が楽になる。

★これまでは同じライブラリを利用する関数が複数あった場合、全ての関数に対してライブラリを含めてパッケージングすることが必要だった。ライブラリをLayerとしてアップロードしておくことで、個々の関数はLayerを使用することができる。

• レイヤー
  追加のコードまたはデータを含むことができる .zip ファイルアーカイブ。

●Lambda エイリアストラフィックシフティング

【面倒なデプロイ簡素化】（※エイリアス：Lambda関数のバージョンを参照するポインタ）
エイリアスの追加バージョンの重みを更新することで、呼び出しトラフィックは指定された重みに基づいて新しい関数のバージョンにルーティングされる。これによってLambda関数の2バージョン間でシフトを行う場合、Lambda関数のエイリアスに重み付けを行うことが可能になり、カナリアデプロイやブルーアンドグリーンデプロイメントといった方法が使用できるようになった。

●Lambda SnapStart

Lambda 関数の初期化処理が終わった後に、実行環境のスナップショットを取って、コールドスタートに該当する起動の場合にスナップショットからのリストアを行うことでコールドスタートの場合の起動時間を短縮する。ゼロから初期化するのではなく、キャッシュされたスナップショットから新しい実行環境を再開するため、起動時のレイテンシーが短縮される。
※一意の ID を生成するコードを Lambda ハンドラーに移動することで、スナップショット時に不要な初期化が防げる。

[仕組み]
①関数バージョンを発行するときに関数を初期化
②初期化された実行環境のメモリとディスク状態の Firecracker MicroVM スナップショットを作成
③スナップショットを暗号化して、低レイテンシーアクセスのためにキャッシュする

※Lambda SnapStart for Java
レイテンシーの影響を受けやすいアプリケーションの起動パフォーマンスを追加のコストなしで最大 10 倍 向上させることができ、通常は関数コードの料金もかからない。

●Lambda トランスフォーマー

API GatewayとAWS Lambdaを連携させる際に、リクエストやレスポンスのデータ形式を変換するための機能。
これは主に、API Gatewayが受け取ったJSON形式のデータを、Lambdaが処理しやすい形式（例えば、シンプルなJSONや特定のデータ構造）に変換したり、逆にLambdaからのレスポンスをAPI Gatewayのクライアントが期待する形式に変換したりする際に使われる。

[呼び出し関数]
Lambdaがコードを実行する際に呼び出す関数名。関数が呼び出されると、Lambda はハンドラーメソッドを実行。関数はハンドラーが応答を返すか、終了するか、タイムアウトするまで実行する。

[ハンドラー外の実行について]
Lambda 関数内の処理は関数が再度呼び出された際に追加で最適化されない限り、初期化状態が維持される。グローバル領域（ハンドラー外）の処理は初期化されないため、キャッシュのように処理が最適化される。そのため、Lambda関数のグローバル領域（ハンドラー外）に動的な処理は書かない方が良く、リソースへの接続などのワークロードが適切。

グローバル領域（ハンドラー外）に何か書くときは以下の点を意識する。
・コールドスタート時はグローバル領域（ハンドラー外）の処理が実行される。
・ウォームスタート時はグローバル領域（ハンドラー外）の処理が実行されない。
[引用サイト]

利用できる同時実行コントロールには、次の2種類がある。

●予約された同時実行

Lambda関数に必要な同時実行数の上限と下限を設定し、リソースの優先確保や過負荷防止を可能にする仕組み。ある関数が予約済同時実行数を使用している場合、他の関数はその同時実行数を使用できない。スケーリングの制御と安定した処理性能の確保に役立つ。設定に追加料金は発生しない。

[同時実行数を下げるメリット]
システム全体の安定性と効率を高めるための「負荷制御」が働くため。同時に大量のリクエストを処理しようとすると、CPU・メモリ・ネットワーク帯域などのリソースが奪い合いになる。実行数を制限することで、各プロセスが十分なリソースを確保でき、安定して処理できるようになる。

●プロビジョニングされた同時実行

関数に割り当てる、事前に初期化された実行環境の数。（関数のレイテンシーを下げる場合に最適）
これらの実行環境は、受信した関数リクエストに即座に対応できるように準備される。プロビジョニングされた同時実行を設定すると、AWS アカウントに料金が請求される。
※予約済同時実行数の設定

関数が呼び出しを受けると、その関数の処理にインスタンスを割り当てて処理を実行する。完了次第、別のリクエストの処理に移ることができる。なお、処理中に別のリクエストが呼び出されると別のインスタンスを割り当てて、別リクエストの同時実行になる。

●同期的処理

エラーが発生した場合、処理が成功するか、データの有効期限が切れるまでLambdaはバッジを再試行する。

※Kinesis Streamと比較
Data Streamからレコードを読み取り、ストリームレコードを含むイベントを使用して関数を同期的に呼び出す。

●非同期呼び出し

関数の非同期イベントキューを管理しエラー発生時に再試行を行う。
関数からエラーが返された場合、関数エラーを 2 回再試行する。

• リクエストデータ
  以下が含まれる。（ただし、リクエストパラメータの順序は保持されない）
  ・リクエストヘッダー
  ・クエリ文字列パラメータ
  ・URL パス変数
  ・ペイロード
  ・API 設定データ
  ※現在のデプロイステージ名、ステージ変数、ユーザー ID、または承認コンテキスト (存在する場合) を含める。

[API Gatewayの統合タイプ5種]

大量のデータを小さなグループ（バッチ）に分割し、それぞれのバッチを個別に処理する手法。これにより、処理効率の向上やリソースの最適化が期待できる。

また、関数がエラーを返した場合、再試行する前にバッチを2つに分割し処理をすることができる。元のバッチサイズ設定は変更されない。

[参考公式サイト]

※「同期処理・非同期処理について」

Cloud Formationの設定ファイル。（JSON/YAMLフォーマット:形式）AWS リソース（またはプロパティ）を作成する際の設計図として使用。
※YAML はインデント(左から右へ寄せた量)で階層を判断する形式。
※YAML は「記法」となる為、プログラミングのような分岐処理や繰り返し処理の記述はできない。

[テンプレートセクション]

[（一例）基本テンプレート]

【リソース定義】
関連リソースはスタックと呼ばれる単一のユニットとして管理できる AWS リソースのコレクション。
※「承認されたテンプレートの強制」や「開発者によるテンプレートの制限」を実装する機能はない

・スタックを作成、更新、削除することで、リソースのコレクションを作成、更新、削除できる。
・「エラー時のロールバック」機能が有効であると、失敗しても作成されずロールバックする。

スタックの更新には2つの方式がある。

• スタックセット
  １つのテンプレート内に AWS リソースの設定を定義して、複数の AWS アカウントやリージョンにスタックを作成・管理、展開することができる。
  スタックセットを定義したら、スタックセットはリージョンのリソースである。
  
  ※自動デプロイを有効にすると、今後ターゲットの組織または組織単位（OU）に追加されるアカウントにStackSetsが自動デプロイを行う
• スタックポリシー
  重要なスタックリソースを保護して、意図しない更新でリソースが中断されたりするのを防ぐJSONドキュメント。

●カスタムリソース

【使用できないリソース】
CloudFormationのリソースタイプとして使用できないリソースをプロビジョニングするためのカスタムリソースの作成をサポートする。
テンプレートにカスタムのプロビジョニングロジックを記述し、ユーザーがスタックを作成、更新(カスタムリソースを変更した場合)、削除するたびにそれを実行。リソースは、カスタム リソースを使用して含めることができる。この方法により、すべての関連リソースを 1 つのスタックで管理できる。
LambdaとZipFikeを使用するカスタムリソースはインラインの nodejs リソース構成を可能にする。

[EC2のAMI IDを自動取得する方法]
CloudFormationテンプレートでEC2インスタンスを作成する際、通常は手動でAMI（Amazon マシンイメージ）IDを指定する必要があります。AMI IDは、インスタンスタイプやリージョン、またはソフトウェアの更新によって頻繁に変わるため、その都度テンプレートを修正する必要がありました。しかし、カスタムリソースとAWS Lambdaを使うことで、テンプレートの実行時に最新のAMI IDを自動で取得できるようになります。これにより、AMI IDのマッピングを手動で管理する手間が不要になる。

●クロススタック

スタック間でリソース情報を共有する仕組み。1つのスタックで作成したリソース（例：VPCやSubnet）を、別のスタックから参照できます。

・複数のスタックにリソースを分散させ、それらを相互に連携させる方法。
・リソースを1つの巨大なテンプレートに詰め込まず、機能単位で分割して再利用性や保守性を向上。

[ネストされたスタック]
他のネストされたスタックが含まれているため、スタックが階層を成す構造になる。ルートスタックはネストされたすべてのスタックが最終的に属する最上位スタック。さらにネストされたスタックにはそれぞれ、直接の親スタックが存在する。

ネストされたスタックを使用して共通コンポーネントを宣言することがベストプラクティスとみなされている。

[参照の仕組み]
・出力(Output) を使って、スタック A が持つリソースの情報を外部に公開。
・スタック B が、その出力を ImportValue 関数で参照し、スタック A のリソースを利用。

[ 例 ]ネットワークスタックとアプリケーションスタック

• ネットワークスタック → VPC・サブネット・セキュリティグループなどを定義。
• アプリケーションスタック → ネットワークスタックのサブネットやセキュリティグループを参照して Web アプリを構築。
• この方法により、アプリ担当者はネットワークの詳細を気にせずに利用可能。

【乖離】CloudFormationテンプレートとそれによって展開したリソースとの間の乖離(変更点)。スタックでドリフト検出オペレーションを実行すると、スタックが予想されるテンプレート設定からドリフトが発生しているかを検証される。

[（UpdatePolicy）対象リソースと適用可能なポリシー]

[テンプレートセクション]

• NoEcho
  値をtrueに設定すると、機密データのパラメーターをマスクできる。パラメーター値はアスタリスクでマスクされる。データーベースのパスワードなどに有効。呼び出された時にパスワードが表示されないようにすることができる。

●リクエストパラメータ

「カスタム名」をもつIAMリソースがある場合は、CAPABILITY_NAMED_IAM を指定する必要がある。

・InsufficientInstanceCapacity エラー
AZ内の「インスタンス容量の不足」を意味する。インスタンスを起動したり、停止したインスタンスを再起動したりする際にこのエラーが発生する場合、使用するAWS に十分なオンデマンドキャパシティーがないことを意味する。

・選択されたインスタンスタイプが一時的に利用できない。
・特定のAZにおいてインスタンスの容量不足が発生している。

●CloudFormation Hooks

CloudFormation スタックの操作（作成・更新・削除）前に カスタムロジックを実行できる仕組み。スタック、リソース、変更セット、Cloud Control API などを対象にスタック操作前、リソース作成前などにリソースの構成を事前に検証し、非準拠な操作を防止できる。

[CodePipeline を使用した継続的デリバリー]
CloudFormationはCodePipelineと統合されている。

[参考公式サイト]

[既存リソースをCloudFormation 管理に取り込む]
CloudFormation 管理外のAWSリソースを作成した場合、resource import を使用して既存のリソースをCloudFormation 管理に取り込むことができる。

[スタックへ既存リソースをインポート]
[参考サイト]

●CloudFormation サービスロール

AWS CloudFormation にユーザーに代わってスタック内のリソースを呼び出すアクセス権限を許可する IAM ロール。スタックリソースの作成、更新、または削除を許可するIAMロールを指定できる。デフォルトの場合、CloudFormationはユーザー認証情報からスタック操作に対して作成される一時的セッションを使用する。

●Mapping

【キーと値の関連性】
キーと名前付きの一連の値とが対応付けられる。たとえば、リージョンに基づく値を設定する場合、リージョン名をキーとして必要な値を保持するマッピングを作成する。具体的なリージョンごとに必要な値を指定する。

●Cloud Former

【JSONへ変換する】現在の構成をJSONフォーマットに変換でき、構成のコピーや雛形の作成が楽になる。アカウントに既に存在するAWSリソースからCloudformationテンプレートを作成するテンプレート作成用のβツール。アカウントで実行中のサポートされているAWSリソースを選択すると、CloudFormerはS3バケットにテンプレートを作成する。

●SAM

【テンプレート集】※SAM：Serverless Application Model
CloudFormationの拡張機能とされる。サーバーレスアプリケーションの開発やデプロイを簡単にするための簡略化された独自のモデリング構文を提供する。YAMLを使用して、サーバレスアプリケーションのするLambda関数、API、データベース、イベントソースマッピングをモデリング。

・迅速に記述可能な構文で関数、API、DB、イベントソースマッピングを表現できる。
・デプロイ中、SAMがSAM構文をCloudformation構文に変換および拡張することで、サーバーレスアプリケーションの構築を高速化することができる。
（CloudFormationの拡張機能であり、CloudFormationの信頼性の高いデプロイ機能を利用できる）
・SAM CLI を使用して、開発ライフサイクルの作成、構築、デプロイ、テスト、モニタリングの各フェーズを通じてサーバーレスアプリケーションを管理

[参考]
[SAMについて]

【併用：Code Commit】
CloudFormationのテンプレートをCodeCommitでバージョンなど管理できる。
①CodeCommitリポジトリを作成し、そこにCloudFormationテンプレートファイルを保存。
②CloudFormationのスタック作成時に、テンプレートの場所としてCodeCommitリポジトリのURLとファイルパスを指定

【併用：Auto Scaling】
CloudFormationでAuto Scalingグループの起動設定（Launch Configuration）を更新方法について。
要するに、起動設定を変更したい場合は、既存のものを上書きするのではなく、新しい設定を作成して置き換え、必要に応じてローリングアップデートを行うことが重要。

主な内容は以下の通りです。

• 起動設定そのものは作成後に変更できませんが、新しい起動設定を作成して、Auto Scalingグループに適用することで更新できます。
• AWS CloudFormationで起動設定を更新すると、古いリソースが削除され、新しいリソースが作成されます。
• 新しい起動設定を適用しても、既存のインスタンスは変更されず、古い設定のまま維持されます。新しいインスタンスのみが新しい設定で起動します。
• AutoScalingRollingUpdateポリシーを使うと、Auto Scalingグループ内のインスタンスを段階的に新しいインスタンスに置き換えることができます。これにより、サービスへの影響を最小限に抑えながら更新が可能です。

CDKのアサーションモジュール（aws-cdk-lib/assertions）は、AWS Cloud Development Kit（CDK）で作成したスタックに対してユニットテストを行うための専用ライブラリ。これは、CDKが生成するCloudFormationテンプレートの内容を検証するために使われる。

[概要]

●設定ファイル(.ebextensions)

環境を設定し、環境に含まれる AWS リソースをカスタマイズできる。この設定ファイルを .ebextensions というフォルダ内に配置してアプリケーションソースバンドルにデプロイする。
※Webサーバ構成：(ELB+AutoScaling+EC2) / Batchワーカー構成：(SQS+AutoScaling+EC2)
※ファイル拡張子を .config とするYAML 、 JSON 形式のドキュメント。

• BlockDeviceMappings
  インスタンスにブロックデバイスを追加できる。

●コンソール

【リソース設定】
環境とそのリソースに関する多数の設定オプションを表示し、デプロイ時の環境動作のカスタマイズ、追加機能の有効化、環境作成時に選択したインスタンスタイプやその他の設定を変更することができる。

●共有機能

開発者は単にそのアプリケーションをアップロードするだけで、展開できる。複数のユーザーや企業が同じアプリケーションを共有し、各々でカスタマイズすることが可能。

●ワーカー環境 SQS デーモン（※Elastic Beanstalk 内）

長期間実行される可能性があるタスク（例えば、画像処理やEメール送信、ZIP生成など）は、ワーカー環境にオフロードさせることができる。

[オフロード]
ある特定のデータ処理に特化したハードウェアをコンピュータに装着し、CPUの処理を肩代わりして負荷を軽減し、システム全体の処理性能を向上させる。

[200 OKレスポンスについて]

• ワーカー環境内のアプリケーションが 200 OK レスポンスを返す。
  ①リクエストを受信して正常に処理したことを確認する。
  ②デーモンが DeleteMessage 呼び出しを Amazon SQS キューに送信し、そのメッセージをキューから削除。
• アプリケーションが 200 OK 以外の応答を返した場合
  ①設定済みの Error Visibility Timeout 期間の経過後にメッセージをキューに戻す。
  ②応答がない場合、処理中の別の試行でそのメッセージを使用できるように、InactivityTimeout 期間の経過後にメッセージをキューに戻す。

[※既存のインスタンスを使用すると容量が減少]

Elastic Beanstalk コンソールまたは EB CLI を使用してアプリケーションの新しいバージョンをアップロードするたびに、アプリケーションバージョンが作成される。使用しなくなったバージョンを削除しないと、AWSクォータ（制限）に到達し、アプリケーションの新しいバージョンを作成できなくなる。

[領域管理]
ライフサイクルポリシーを使って、古いバージョンを削除するか、アプリケーションの合計数が指定した数を超えた場合にバージョンを削除すること。デフォルトでは、データの損失を防ぐために、バージョンのソースバンドルを Amazon S3 に残す。ソースバンドルを削除すると、領域を節約できる。
[参考]

●ソースバンドル

ソースのパッケージとして機能する。アップロードされたソースバンドルはElasticBeanstalk内で管理され、以前のバージョンに戻すことができる。

Elastic Beanstalkを使えば、Dockerの柔軟性とAWSの運用自動化を組み合わせて、効率的にアプリケーションを展開できる。

[参考公式サイト]

• オプション：Swap Environment URLs
  既存のアプリケーション環境（ブルー環境）と新しい環境（グリーン環境）のURLが交換される。これにより、トラフィックは新しい環境にシームレスに移行され、古い環境はスタンバイ状態になる。

[container_commandsキー]
デプロイ時のタイミングに応じて適切に処理が実行されるように構成できるという内容。
アプリケーションのソースコードに影響を与えるコマンドを記述できる。アプリケーションおよびウェブサーバーの設定後、アプリケーションバージョンアーカイブが展開された後に実行される。アプリケーションのバージョンがデプロイされる直前にコマンドが走る。その他のカスタマイズ操作は、アプリケーションのソースコードが展開される前に実行される。

[Dockerコンテナの活用]

• Dockerを使うことで、独自のランタイム環境を構築できる。
• 他のプラットフォームでサポートされていない言語やツール・パッケージマネージャも使用可能。
• コンテナは自己完結型で、必要な設定やソフトウェアをすべて含む。

[環境変数の扱い]

• Elastic Beanstalk コンソールで定義されたすべての環境変数はコンテナに渡される。

[インフラの管理自動化]

• Dockerコンテナを用いた Elastic Beanstalk では、以下のようなインフラ管理が自動化される

• 容量のプロビジョニング
• 負荷分散
• スケーリング
• アプリケーションの状態監視

[他のAWSサービスとの統合]

• VPC、RDS、IAM などの AWS サービスとも柔軟に統合可能。

全体として、Elastic Beanstalk × Docker の組み合わせにより、高い柔軟性と自動化された管理の両立が可能になることを示している。

[引用元サイト]

【併用：外部の Amazon RDS for MySQL】
アプリケーションのスケーリングとデータベースの持続性を別々に管理できる。Elastic Beanstalk 環境が再構築されても、外部 RDS インスタンスは影響を受けずにデータを保持できる。これは、データベースに保存されたデータが重要で、アプリケーションスタックの状態に関係なく保持される必要があるという要件に直接対応できる。

【Amazon SNSとの連携】
環境の作成時や後からでも、通知先のメールアドレスを指定することで、エラーやヘルス状態の変化をメールで受け取れます。Elastic Beanstalkは、Amazon SNS (Simple Notification Service) を使って、環境に影響する重要なイベントを通知します。

【管理枠】
OpsWorksの管理対象をまとめたコンポーネントで、属する全員インスタンスの構成を管理する。
※スタック(大枠)の中にレイヤー。レイヤー内に各インスタンス(インスタンスにOpsWorksのエージェント必須)
⇒別のリージョンにコピーできる（DR環境対策）

【注文ファイル】
ファイルに記述した設定内容に応じて自動的にユーザーの作成やパッケージのインストール、設定ファイルの編集などを行うツール。「Cookbook（クックブック）」や「Recipe（レシピ）」と呼ばれる設定ファイルの再利用がしやすい構造になっている点が特徴。Ruby と Erlang で記述。

●Chef ログ
特にレシピをデバッグする際の主要なトラブルシューティングリソースの 1 つ。レシピが失敗した場合、ログには Chef スタックトレースが含まれる。Chefログを使用して失敗したレシピをデバッグ。実行はデバッグモードであり、ログには Chef 実行の詳細(stdout や stderror に送信されたテキストなど) が含まれる。OpsWorksスタックは各コマンドの Chef ログをキャプチャし、各インスタンスの最新 30 個のコマンドのログを保持可能。

Chefを使って、サーバーにどんな設定をするかを細かく指定することができる。
[カスタムクックブックの有効化]
「Use custom Chef cookbooks」オプションを有効にすると、カスタムクックブックの使用が可能になる。

[リポジトリ情報の設定]
クックブックの保存先（Gitリポジトリなど）のURLや**認証情報（パスワードなど）**を設定する必要がある。

[自動インストール]
スタック設定後、新しく起動するすべてのインスタンスには、カスタムクックブックが自動でインストールされる。

[更新コマンドの利用]
すでに存在するインスタンスには、Update Custom Cookbooks コマンドを実行することで、新しいクックブックや更新されたクックブックを適用できる。

[バージョン互換性の確認]
使用するカスタム／コミュニティクックブックが、スタックで採用されているChefのバージョンと互換性があることを事前に確認する必要がある。

OpsWorks スタック内で以下のような変更が起きたとき、すべてのインスタンスで Configure イベント がトリガーされる。

• インスタンスがオンライン状態になった／オンライン状態から外れた
• Elastic IPアドレスの関連付け／解除
• ELB（Elastic Load Balancing）の Layer へのアタッチ／デタッチ
• configure stack command を使えば、手動でも Configure イベントを起こすことができる。

[イベント発生例]
・インスタンス A・B・C が稼働中に、新しいインスタンス D を追加すると、A～Dすべてで Configure イベントが発生。
・D のセットアップ完了後に A を停止すると、残りの B・C・D に再び Configure イベントが発生。

[Configureレシピの役割]

レイヤーごとに定義された Configure レシピが実行され、最新のオンライン構成に基づいて設定ファイルを再生成。

・リソースやアクションの制限により、不要なアクセスを防止
・ユーザーごとに個別のIAMユーザーを作成
・必要な操作だけを許可する最小権限のポリシーをアタッチ

[引用元サイト]

・コードまたはイメージリポジトリ（例：GitHub、ECRなど）に直接接続可能。
・自動的に統合と配信のパイプライン（CI/CD）を構築。

・バックアップポリシーを設定することでサービス全体のアプリケーションのデータをバックアップ。
・復元されたインスタンスは、すべてのインスタンスメタデータを含め元のインスタンスと同じ。
・デフォルトの動作は「再起動なし：no-reboot」でEC2バックアップを取得する。

• クロスアカウント管理機能
  バックアップポリシーを一元管理できるだけでなく、AWS Organizations の AWS アカウント間で、バックアップと復元、コピージョブをモニタリングできる。

どのリソースをいつどのようにバックアップするかを定義する。JSON でポリシーのように設定することもできれば、GUI で設定することもできる。

[リソース割り当て]
どのリソースに対してバックアップを実行するかは、リソースの割り当て（Resource assignment）によって定義する。バックアップ対象となる「リソースの指定」、対象リソースのバックアップの「スケジュール」を指定する。
一つのバックアッププラン内で複数のリソースの割り当てを設定できる。

●Backupボールト

バックアップを整理するために、EC2 のバックアップである AMI 、RDS のバックアップであるスナップショットなどをまとめて管理する。
※S3 バケットの継続的バックアップと定期的バックアップは、どちらも同じバックアップボールト

• 復旧ポイント
  個々のバックアップは復旧ポイントという単位で管理される。復旧ポイントは、各サービスのバックアップと 1 対 1 で紐づけられる。
  
• アクセスポリシー
  復旧ポイントに対するアクセス制御を行う。特定のリソースタイプのバックアップのみ参照を許可したり、特定のユーザーに対してのみリストアを許可するといったことが可能となります。

Backup は「AWSリソースの保護」向け、DataSync は「ファイルベースの転送・バックアップ」向け。

• Backup：EC2やRDSなど、AWSサービスの状態を丸ごとバックアップ・復元したいときに最適。
  【例】EFS を毎晩自動でスナップショット取得 → 障害時に復元
  
• DataSync：オンプレミスや他リージョンのストレージから、ファイル単位で柔軟にバックアップ・同期したいときに便利。
  【例】DataSync：社内NASのログを毎晩 S3 にコピー → 分析や保管用

●Landing Zone

【最適なマルチアカウント作成】
Well-Architected によるAWSのベストプラクティスに基づいたセキュアなマルチアカウント AWS 環境を提供する仕組みの総称。 ID、フェデレーティッドアクセス、アカウント構造のためのベストプラクティスのブループリント(テンプレートと同等)を使用して、新しい ランディングゾーンのセットアップを自動化。ランディングゾーンを展開することで環境内のAWSアカウントのリソースに対して一元的に 管理/監視が可能になる。

●Account Factory

【組織垢自動配置】
組織内の新しいAWSアカウントを自動的に作成・設定・管理するための仕組み。設定可能なアカウントテンプレートとして、Control Tower の事前承認済み アカウントブループリントとデフォルトのリソース、設定、または VPC 設定を使用して、新しいアカウントのプロビジョニングを標準化するのに役立つ。

[主な機能と特徴]
・事前に承認されたアカウント設定に加えて、独自のカスタムアカウントリソースと要件を定義して実装もできる。
・事前に承認されたネットワーク設定と AWS リージョンの選択を使用して Account Factory を設定することで、ビルダーが新しいアカウントを 設定してプロビジョニングするためのセルフサービスを有効にする。

●About Account Factory for Terraform (AFT)

Terraform 用 Account Factory などの Control Tower ソリューションを 利用して、Terraform の Control Tower が管理するビジネスポリシーとセキュリティポリシーを満たすアカウントのプロビジョニングとカスタマイズを 自動化してからエンドユーザーに配信できる。

[Account Factory for Terraform (AFT)との違い]

●CfCT（Customize Control Tower）

新しいアカウント作成時に、カスタムリソースや設定を自動的に適用できる仕組み。AWS CodeCommit リポジトリに保存された CloudFormation テンプレートや SCP（Service Control Policies）JSON ドキュメントを使って、カスタムセットアップを実行。

[動作の流れ]

1. ユーザーが新しいアカウントを作成。
2. OU（組織単位）やアカウントに対して、CloudFormation テンプレートや SCP を自動適用。
3. アカウント作成後に、自動でカスタムリソースがデプロイされる。

[適用可能なカスタマイズ例]
・CloudFormation によるリソース作成（例：VPC、IAM ロール、ログ設定など）
・SCP によるアクセス制御ポリシーの適用
・AWS Config や CloudTrail の設定強化

●包括的なコントロール管理

最小特権の適用、ネットワークアクセスの制限、データ暗号化の適用など、最も一般的な制御目的を果たすために必要な制御の定義、 マッピング、管理にかかる時間を短縮するのに役立つ。

短時間で大量のイベントを処理するユースケースに最適なワークフロータイプ。
・冪等性（同じ処理を複数回しても結果が変わらない）が担保できる処理
・リアルタイム性が求められる処理
・高頻度で繰り返されるイベント処理
・短時間で完了するタスクのオーケストレーション

[Standard Workflow との違い]

【併用：Lambda】
ワークフローの個々のステップにビジネスロジックを持つ Lambda 関数 を実装しワークフローを構成する一連のステップのビジネスプロセスを構築する。
[引用サイト]