【前提知識】

• データストア
  コンピュータシステムに情報を格納して保護するデジタルリポジトリ。
  情報テーブルなどの構造化データと、E メール、画像、動画などの非構造化データの両方を保存できる。

• Puppet
  サーバーの環境設定やインストールなどを自動化する設定管理ツール。
  Ruby で実装されており、各種操作の実行を行うためのフロントエンドであるpuppetコマンドと、各種機能を実装した Ruby ライブラリから構成される。

Lambda
【処理の自動化】

サーバやアプリケーションを立てずに、実行したい処理をコードで実施できるコンピューティングサービス(アプリケーションをデプロイする)。

Lambda API を使用して関数の呼び出し、Lambda を使用してその他の AWS サービスからのイベントをトリガーにして関数を実行できる。
再帰的な(自己の行為の結果が自己に戻ってくる)なコードの使用は避けること。

• デプロイパッケージ
  「コンテナイメージ」、「zip ファイルアーカイブ」の 2 種類ある。
  
  ・デプロイパッケージのサイズ
  50 MB（zip 圧縮済み、直接アップロード）
  250MB（解凍、レイヤーを含む）
  3 MB（コンソールエディタ）
  
  依存パッケージをまとめて、libフォルダー内にライブラリーとして配置すると解凍時間を短縮できる。
  

• オートスケール
  処理件数に対して、自動的に実行ユニットを増やして並列にスケールアウトする。

【rate または cron を使用する式をスケジュール】

[参考公式サイト]

〇サービスの構造

• コンテナイメージ
  コンテナイメージからLambda関数を作成できる。

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

• 実行ロール
  AWS サービスおよびリソースにアクセスする許可を関数に付与するIAM ロール。
  他のAWSサービス(S3など)からファイルを取得する時、その権限が含まれるIAMロールをLambda関数に割り当てる必要がある。
  CloudWatch にログを送信し、トレースデータをX-Ray にアップロードするためのアクセス許可をもつ開発用の実行ロールを作成できる。
  
  [参考]

• Lambda のクォータ
  ・最大実行時間：900秒(15分)
  ・メモリの割り当て：10,240MB
  ・エフェメラルディスク：512MB(/tmpディレクトリのストレージ上限)

〇処理実行

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

• 予約された同時実行
  関数に割り当てる同時インスタンスの最大数。
  ある関数が予約済同時実行数を使用している場合、他の関数はその同時実行数を使用できない。関数に対して予約された同時実行を設定する場合には料金はかからない。

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

〇同期呼び出し（invoke）

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

• 同期的処理
  エラーが発生した場合、処理が成功するか、データの有効期限が切れるまでLambdaはバッジを再試行する。
  
  ※Kinesis Streamと比較
  Data Streamからレコードを読み取り、ストリームレコードを含むイベントを使用して関数を同期的に呼び出す。

• 非同期呼び出し
  関数の非同期イベントキューを管理しエラー発生時に再試行を行う。
  関数からエラーが返された場合、関数エラーを 2 回再試行する。
  
  【プロキシ統合タイプ】
  
  （API Gateway ＋ Lambda）
  
  シームレスに統合し、サーバーのプロビジョニングや管理を行うことなく、拡張性の高いアーキテクチャを提供する高速なメカニズム。
  クライアントが API リクエストを送信すると、API Gateway は統合されたLambda関数にイベントオブジェクトを渡すための「玄関」として機能する。
  
  ・RESTful API および WebSocket API を作成することができる。
  
  ※REST API
  リソースとメソッドで構成。リアルタイム双方向通信アプリケーションを実現する。
  
  ●リクエストデータ
  以下が含まれる。
  （ただし、リクエストパラメータの順序は保持されない）
  ・リクエストヘッダー
  ・クエリ文字列パラメータ
  ・URL パス変数
  ・API 設定データ
  ※現在のデプロイステージ名、ステージ変数、ユーザー ID、または承認コンテキスト (存在する場合) を含める。
  ・ペイロード
  
  ●リソース
  リソースパスを介してアプリがアクセスできる論理エンティティを表す。
  
  ●メソッド
  APIユーザーによって送信されるREST APIリクエストやユーザーに変えるレスポンスに対応。
  （※リクエスト、レスポンスで構成）
  
  ●ステージ
  タグに似ている。ステージは、デプロイ環境からアクセス可能なパス経路を定義する。
  
  ●API Gatewayの統合タイプ5種

AWS_PROXY	Lambdaプロキシ統合の場合に選択。
AWS	Lambdaカスタム統合およびその他すべてのAWS統合の場合に選択。
HTTP_PROXY	バックエンドのHTTPエンドポイントを公開するかつ、統合リクエストと統合レスポンスの両方を特別に設定する必要がない場合。
HTTP	バックエンドのHTTPエンドポイントを公開するかつ、統合リクエストと統合レスポンスの両方を指定したい場合。
MOCK	このタイプの統合はリクエストをバックエンドに送信することなくレスポンスを返すため、テストを行う場合に選択する。

〇その他機能

• デッドレターキュー
  正常に処理できなかったイベントを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関数のエイリアスに重み付けを行うことが可能になり、カナリアデプロイやブルーアンドグリーンデプロイメントといった方法が使用できるようになった。

Amplify
【WebApp自動構築】

AWSのクラウドサービス上にモバイルアプリケーションを構築するための最も速く、簡単な方法。
ポピュラーなバックエンドの構成とそれを利用するためのフロントエンドの統合を自動で構築できる。

Amplify を使って、オブジェクトストレージの S3 とCDN (コンテンツ配信ネットワーク）の CloudFront を利用したスケーラブルな Web サイトホスティングを始め、ユーザー認証機能や RESTful API や GraphQL API の作成・管理など、豊富な機能が自動的にセットアップされて、簡単に利用できる。

例えば、 Amplify を通じて Web アプリを公開すると、オブジェクトストレージの S3 や CDN (コンテンツ配信ネットワーク） の Cloudfront が自動的にセットアップされスケーラブルなバックエンドが自動的に構成される。
また、アプリにログイン機能を実装したいときは、 Amplify でアプリケーションにユーザ認証機能を追加すれば、アイデンティティおよびデータ同期の Cognito が透過的にプロビジョニングされる。

[引用元サイト]

CloudFormation
【リソース構築自動化】

YAML という形式で記載された Template ファイルを読み込む事で、Stack という1 つの単位で（リソースの設定含めて）環境を構築する。利用は無料。

• CloudFormation デザイナーのチェック機能でエラーが出ないかを確認すること
• ユーザーデータを使用するとアプリケーションのデプロイと構成を自動化できる
• AWS上のインフラ構成をコード化して管理したり、ユーザー間で共有することが可能
• パッケージはアーティファクトをS3にアップロードし、アーティファクトのパスが更新されたテンプレートを返す。
• CloudFormation で作成したAWSリソースは、CloudFormation 以外の方法で変更してはいけない

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

[参考公式サイト]

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

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

• cfn-signal ヘルパースクリプト
  【インスタンス作成シグナル】
  インスタンスが正常に作成または更新されたかどうかを示すシグナルを CloudFormation に送信する。
  インスタンスにソフトウェアアプリケーションをインストールして設定する場合、ソフトウェアアプリケーションが使用できる状態になった時にCloudFormation にシグナルを送信できる。

〇テンプレート

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

• 論理ID
  VPC など AWS リソースにも作成された瞬間に ID（リソース ID）が付与されるので、それと区別するための名称。
• AWS:Include
  S3上に置かれたファイルの中身をCloudFormationのテンプレート内に読み込むためのマクロ。

• Fn::GetAZs
  【組み込み関数】
  指定したリージョンのアベイラビリティーゾーンをアルファベット順にリストした配列を返す。
  アベイラビリティーゾーンへのアクセス権は顧客ごとに異なり、テンプレート作成者は組み込み関数 Fn::GetAZs を使用することで、呼び出し元のユーザーのアクセス権にうまく適応するテンプレートを作成する。
  特定のリージョンのすべてのアベイラビリティーゾーンをハードコーディング(情報の書き換え)する必要はなくなる。

【一例】基本テンプレート

〇スタック
【リソース定義】

関連リソースはスタックと呼ばれる単一のユニットとして管理できる AWS リソースのコレクション。

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

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

直接更新(in place)	変更を送信するとCloudFormationによって即時にデプロイ。 更新を迅速にデプロイするには直接更新を使用する。
変更セット(blue-green)	更新されたスタックなど実際に実装する前に検証できる。影響度を確認するためのスタック。そのため、安心したスタック更新が可能。スタックの変更案が実行中のリソースに与える可能性がある影響を確認できる。

• スタックセット
  １つのテンプレート内に AWS リソースの設定を定義して、複数の AWS アカウントやリージョンにスタックを作成・管理、展開することができる。
  スタックセットを定義したら、スタックセットはリージョンのリソースである。
  
  ※自動デプロイを有効にすると、今後ターゲットの組織または組織単位（OU）に追加されるアカウントにStackSetsが自動デプロイを行う

• スタックポリシー
  重要なスタックリソースを保護して、意図しない更新でリソースが中断されたりするのを防ぐJSONドキュメント。

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

〇ドリフト
【乖離】

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

〇属性

• DeletionPolicy属性
  【削除対策】
  スタックが削除された際にリソースを保持またはバックアップができる。
  
  ●Retain
  リソースの削除防止。スタックが削除された際にリソースを保持するには、そのリソースに対して Retain を指定する。
  
  ●Snapshot
  リソース削除前にスナップショットを作成する。

• DependsOn属性
  【依存関係】
  特定のリソースが他のリソースに続けて作成されるよう（依存関係）に指定できる。
  
  依存関係のエラーが発生した場合、テンプレート内の他のリソースに依存するリソースに DependsOn属性を追加する。

• Creation Policy属性
  【作成管理】
  CloudFormationが指定数の成功シグナルを受信するかまたはタイムアウト期間が超過するまでは、ステータスが作業完了にならないようにする属性。
  
  ●Wait Condition
  リソースの作成を詳細に調整できる。

• UpdatePolicy属性

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

〇パラメーター

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

〇エラー

• InsufficientInstanceCapacity エラー
  AZ内の「インスタンス容量の不足」を意味する。
  
  ・選択されたインスタンスタイプが一時的に利用できない。
  
  ・特定のAZにおいてインスタンスの容量不足が発生している。
  
  インスタンスを起動したり、停止したインスタンスを再起動したりする際にこのエラーが発生する場合、使用するAWS に十分なオンデマンドキャパシティーがないことを意味する。

〇補助サービス

• Cloud Former
  【JSONへ変換する】
  
  現在の構成をJSONフォーマットに変換でき、構成のコピーや雛形の作成が楽になる。
  アカウントに既に存在するAWSリソースからCloudformationテンプレートを作成するテンプレート作成用のβツール。
  アカウントで実行中のサポートされているAWSリソースを選択すると、CloudFormerはS3バケットにテンプレートを作成する。
  
• SAM
  【テンプレート集】
  
  ※SAM：サーバーレスアプリケーションモデル
  
  サーバーレスのリソースを表現するための簡略化された独自のモデリング構文を提供する。
  YAMLを使用して、サーバレスアプリケーションのするLambda関数、API、データベース、イベントソースマッピングをモデリング。
  
  ・迅速に記述可能な構文で関数、API、DB、イベントソースマッピングを表現できる。
  ・デプロイ中、SAMがSAM構文をCloudformation構文に変換および拡張することで、サーバーレスアプリケーションの構築を高速化することができる。
  （CloudFormationの拡張機能であり、CloudFormationの信頼性の高いデプロイ機能を利用できる）
  
  [参考]

CDK
【コードで環境構築】

※AWS Cloud Development Kit (CDK)

• 対応は AWS のみではある。
• 複数のプログラミング言語で記述が可能。
• コードから CloudFormation テンプレートが生成され、実際の作成処理はCloudFormation で行われる。

Elastic Beanstalk
【APPデプロイの自動化】

※Beanstalk：豆の木

コードのアップロード、容量のプロビジョニングや負荷分散、アプリケーションのヘルスモニタリングなどのアプリケーションをデプロイするために必要なインフラストラクチャ（サーバーやネットワーク）やリソースの設定をコードを書くだけで自動構築してくれる。

※アプリケーションをDockerコンテナからデプロイすることができる

・モニタリングやセキュリティーに必要なパッケージのみ使用するため、不要なコストを削減できる
・WEBアプリケーションのデプロイを容易にする、タスク時間の長いワークロードの展開に有効
・本サービスの環境内にはEC2インスタンスを管理するAuto Scalingグループが含まれている
・開発言語は、Java / PHP / Python / Python(with Docker) / Node.js / Go / NET / Ruby
・OSとデーターベースの管理ができる

【注意点】

・アプリケーションのバージョンを更新時にインプレース更新を実行するため、アプリケーションはわずかな期間、ユーザーに利用不可になることがある。

【ログ保存機能】

・アプリケーションファイルと、オプションでサーバーログファイルが S3 に保存される。
・サーバーのログファイルを 1 時間おきに S3 にコピーするように設定することもできる。

【ウェブアプリケーションを Docker コンテナからデプロイ】

[参考公式サイト]

〇作成機能

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

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

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

〇デプロイ機能

• ワーカー環境 SQS デーモン
  ※Elastic Beanstalk 内
  
  長期間実行される可能性があるタスク（例えば、画像処理やEメール送信、ZIP生成など）は、ワーカー環境にオフロードさせることができる。
  
  ※オフロード
  ある特定のデータ処理に特化したハードウェアをコンピュータに装着し、CPUの処理を肩代わりして負荷を軽減し、システム全体の処理性能を向上させる。
  
  ●ワーカー環境
  ・Elastic Beanstalk から提供されるプロセスデーモンを実行する。
  ・アプリケーションが成功を返さない場合、プロセスデーモンはメッセージをキューに戻す。
  ・Auto Scalingグループ、1 つ以上のEC2 インスタンスおよび IAM ロールが含まれている。
  ・ワーカー環境にSQS キューがない場合、Elastic BeanstalkによってSQS キューが作成され、プロビジョニングされる。
  
  ●デーモン
  ・デーモンは定期的に更新され、機能の追加とバグの修正が行われる。
  ・デーモンの最新バージョンを取得するには、プラットフォームバージョンに更新。
  
  【200 OKレスポンスについて】
  ・ワーカー環境内のアプリケーションが 200 OK レスポンスを返す。
  ①リクエストを受信して正常に処理したことを確認する。
  ②デーモンが DeleteMessage 呼び出しを Amazon SQS キューに送信し、そのメッセージをキューから削除。
  
  ・アプリケーションが 200 OK 以外の応答を返した場合
  ①設定済みの Error Visibility Timeout 期間の経過後にメッセージをキューに戻す。
  ②応答がない場合、処理中の別の試行でそのメッセージを使用できるように、InactivityTimeout 期間の経過後にメッセージをキューに戻す。

• アプリケーションバージョンライフサイクル
  Elastic Beanstalk コンソールまたは EB CLI を使用してアプリケーションの新しいバージョンをアップロードするたびに、アプリケーションバージョンが作成される。
  使用しなくなったバージョンを削除しないと、AWSクォータ（制限）に到達し、アプリケーションの新しいバージョンを作成できなくなる。
  
  【領域管理】
  ライフサイクルポリシーを使って、古いバージョンを削除するか、アプリケーションの合計数が指定した数を超えた場合にバージョンを削除すること。
  デフォルトでは、データの損失を防ぐために、バージョンのソースバンドルを Amazon S3 に残す。ソースバンドルを削除すると、領域を節約できる。
  
  [参考]
  
  ●ソースバンドル
  ソースのパッケージとして機能する。アップロードされたソースバンドルはElasticBeanstalk内で管理され、以前のバージョンに戻すことができる。

〇デプロイの種類

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

All at once	（既存のインスタンス） 同時に全ての既存インスタンスに新しいバージョンをデプロイするポリシー。最も迅速なデプロイ方法。環境内のすべてのインスタンスは、デプロイが実行される間、短時間サービス停止状態になる。
Rolling	（既存のインスタンス） バッチに新しいバージョンをデプロイするポリシー。複数インスタンスに対し、少しづつデプロイ。デプロイが終わると全てのインスタンスでデプロイしたバージョンのアプリケーションが起動。ダウンタイムを回避できるが、デプロイ時間が長い。サービスの完全停止を防ぐアプリケーションのログ保持向き。
Rolling with additional batch	（既存・新規のインスタンス） デプロイの対象となるインスタンス分、新しくインスタンスを起動させて、１００％の状態を保つ。インスタンスがサービス停止する前に、インスタンスの新しいバッチを起動するように環境を設定してデプロイ中に総容量を維持できる。
Immutable	（変更不可）：新規のインスタンス 低速のデプロイ。常に新しいアプリケーションバージョンを新しいインスタンスにデプロイ。失敗しても迅速に安全にロールバック可能。
Traffic splitting	残りのトラフィックを古いアプリケーションバージョンで処理され続けるようにする。（※Canaryリリース形式）
Blue/Green	（Swap Environment Deployment） 新バージョンのアプリケーションを公開するにあたり、現バージョン（ブルー）と新バージョン（グリーン）の両方を並行して稼働させ、切り替えにより公開する。仕組みとして、個別の環境に新しいバージョンをデプロイして、２つの環境のCNAMEを入れ替え、すぐに新しいVerにトラフィックをリダイレクト。 ・切り替えは一瞬でできるため、稼働停止時間なしに公開できるのがメリット。 ・1つの環境で２つの異なる環境層をサポートすることはできない。 ・ワーカー環境層とウェブサーバー環境層はそれぞれAuto Scalingグループを必要とする。 ・ElasticBeanstalk は環境ごとに一つのAuto Scalingグループしかサポートしていない。 ●環境URLのスワップ 新旧環境間でCNAMEレコードを交換する機能を提供する。これにより、新しい環境にデプロイされたアプリケーションにユーザーのトラフィックを素早くかつ無停止でリダイレクトすることができる。

OpsWorks
【ミドルウェアの自動化】

Chef や Puppet（構成定義ファイル）に基づいて、サーバーのさまざまな設定を自動的に行うソフトウェア、設定管理サービス。
・ソフトウェアの設定
・パッケージのインストール
・データベースのセットアップ
・サーバーのスケーリング
・コードのデプロイが自動的

・サポート範囲は、EC2、EBS ボリューム、Elastic IP、CloudWatch メトリクスなど、アプリケーション志向のリソースに限られる

• スタック
  【管理枠】
  OpsWorksの管理対象をまとめたコンポーネントで、属する全員インスタンスの構成を管理する。
  
  ※スタック(大枠)の中にレイヤー。
  レイヤー内に各インスタンス(インスタンスにOpsWorksのエージェント必須)
  ⇒別のリージョンにコピーできる（DR環境対策）
  
  ●スタックインスタンス
  【スタックのリンク】
  ・スタックインスタンスはひとつのスタックセットのみ関連付けられる。
  ・リージョン内のターゲットアカウントのスタックへのリファレンス（参考）。
  ・スタックなしで存在できる。
  ・スタックの作成失敗理由を保持する。

• レイヤー
  1つ以上の Layer を追加することにより、スタックのコンポーネントを定義する。

〇Chef（シェフ）
【注文ファイル】

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

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

APP Runner
【自動デプロイ】

下記イベントに対し、イメージリポジトリに直接接続して、プッシュされたコードを自動的にデプロイまたは配信する。

・ソースコードがコードリポジトリにプッシュされる
・新しいコンテナイメージバージョンがイメージリポジトリにプッシュされる

AWS Batch
【バッチ自動化】

開発者、科学者、エンジニアは、数十万件のバッチコンピューティングジョブをAWSで簡単かつ効率的に実行。

コンピューティングリソース（CPUやメモリ最適化インスタンスなど）を自動的にプロビジョニングし、ワークロードの量と規模に基づいてワークロードのディストリビューションを最適化する。

・ジョブを実行するためのバッチコンピューティングソフトウェアやサーバークラスターを扱う必要がなくなる。

AWS Back up
【バックアップ自動化】

組織内の Backup ジョブを管理（バックアップ保護）およびモニタリングできるサービス。
（Organizationsの管理アカウントから実施可能）

大規模なデータセットのバックアップには不向き。オンプレミスのデータを直接同期する仕組みを持っていない。

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

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

〇Back up プラン

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

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

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

Control Tower
【安全なマルチアカウントのセットアップ】

（※強く推奨されるガードレール、必須のガードレール）

マルチアカウント環境におけるガバナンス、コンプライアンス、セキュリティのベストプラクティスを自動化し、中央管理を容易にする。

安全なマルチアカウント AWS 環境のセットアップと管理。
新規または既存のアカウント設定の統制できる。 組織のセキュリティとコンプライアンスのニーズを維持しながら、ユーザーに代わって複数の AWS サービスをオーケストレーションすることで、 AWS エクスペリエンスを簡素化する。

・適切に設計されたマルチアカウント環境を 30 分以内にセットアップ。
・組み込みのガバナンスで AWS アカウントの作成を自動化。
・事前に構成されたコントロールを使用して、ベストプラクティス、標準、規制要件を適用。
・サードパーティーソフトウェアを大規模にシームレスに統合して、AWS 環境を強化。

[画像引用元]

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

• Account Factory
  【組織垢自動配置】
  組織内の新しいアカウントのプロビジョニングを自動化する。設定可能なアカウントテンプレートとして、Control Tower の事前定義済み アカウントブループリントとデフォルトのリソース、設定、または VPC 設定を使用して、新しいアカウントのプロビジョニングを標準化するのに役立つ。
  
  ・事前に承認されたアカウント設定に加えて、独自のカスタムアカウントリソースと要件を定義して実装もできる。
  
  ・事前に承認されたネットワーク設定と AWS リージョンの選択を使用して Account Factory を設定することで、ビルダーが新しいアカウントを 設定してプロビジョニングするためのセルフサービスを有効にする。
  
  ※Terraform 用 Account Factory などの Control Tower ソリューションを 利用して、Terraform の Control Tower が管理するビジネスポリシーとセキュリティポリシーを満たすアカウントのプロビジョニングとカスタマイズを 自動化してからエンドユーザーに配信できる。

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

ワークフロー

SWF

※SWF： Simple Workflow Service

クラウド内の完全マネージド型の状態トラッカーおよびワークフローシステム。
商品の発注/請求処理のワークフロー（処理の流れ）のような、重複が許されない厳密に一回限り順序性が求められる処理を定義する。

タスクの保管、実行可能になったタスクのワーカーへの割り当て(1回のみで重複しない)、およびタスクの進行状況の監視も行う。

• ワーカー
  SWFと相互作用してタスクを受け取り、そのタスクを処理して結果を返すプログラム。

• ディザスター
  複数のタスクの連携を制御するプログラム。

※EC2インスタンスを利用したサーバーベースの機能であるためサーバーレスオーケストレーションを提供しない

Step Functions

※SWFと違い、可視化できる

ワークフローを制御するサービス。容易にワークフローの作成が可能。

AWS の複数のサービスをサーバーレスワークフローに整理して、プロセス処理を実行するアプリケーションを構築できる。 ワークフローは一連のステップで構成され、ステップの出力が次ステップへの入力になる。

・各ステップは自動的にトリガー・追跡される。

・エラーが発生した場合は再試行されるため、アプリケーションが意図したとおりの順序で実行される。

※人間による操作を必要とするような長時間実行される、半自動化されたワークフローを作成することもできる。したがって、ワークフローに手動アクションを必要とするいくつかのタスクが存在する可能性がある。

【エラーメッセージ】

• “ErrorEquals”:[“States.ALL”]：実行中に発生するすべてのエラータイプをCatchする。
  ※States.ALL：あらゆる既知のエラー名に一致するワイルドカード
  
• “ErrorEquals”:[“States.Runtime”]：実行中の特定のエラータイプだけをCatchする。