柱と呼ばれる6つの設計原則（運用上の優秀性、セキュリティ、信頼性、パフォーマンス効率、コスト最適化、持続可能性）に基づき、AWSを活用する際のベストプラクティスが共有されている

Well Architectedフレームワークにおいて、サーバーレスや機械学習、金融サービスといった特定の業界や技術領域に特化したLensと呼ばれる追加のベストプラクティスが提供されている

WebサービスやWebアプリケーションで直接ユーザーの目に触れる部分のことです。WebサイトやWebアプリケーションなどでユーザーが文字を入力したり、ボタンをクリックしたりする部分や、バックエンドのソフトウエアと直接やり取りをする部分のこと

サーバーサイド（Webサーバー側）やデータベースのシステムなど、ユーザーの目に見えない部分のこと。ユーザーが入力した内容などのデータ処理やデータベースへの保存、検索結果の出力といったことを行う

ブラウザではなくサーバー上でwebページのレンダリングを行い、出力する形態のアプリケーション。HTMLが完全に生成された形で返却されるため、Googleクローラ等によるCEO対策でメリットがある

マークアップ言語などの人工言語で記述された描画指示や、何らかのデータ形式やデータ構造で記述された描画内容を表すデータ群をソフトウェアが読み込み、内容を解釈して画像や動画、音声などを生成する。

保守性を高めるために求められる組織運用とシステム運用に関する観点 システム運用観点からの設計上の検討事項↓ ・どのようにシステムの状態を把握するか ・どのように不具合の修正を容易にするか ・どのようにデプロイのリスクを軽減するか

システム内で定めた状態を確認し続けること。目的はシステムの可用性を維持するために問題発生に気づくこと。メモリ使用率やディスク使用率等の定量的な計測情報（メトリクス）やアプリケーションのログによる定性的な情報から状態異常を検知し、アラートとして通知する。

コンポーネント間やアプリケーション内部の処理内容を追えるようにするための情報

システム全体を俯瞰しつつ、内部状態まで深掘りできるような状態。トラブルが発生した時の原因特定や対策検討を迅速におこなえるようになり、結果として優れた運用につながる。アプリケーションを追加・修正した際のシステム影響を把握しやすくなる。

利用者のために行うべき。ログであれメトリクスであれ、モニタリングは利用者の体験が損なわれるようなイベントを念頭に行うべき。

ECS/Fargate構成では、CloudWatchLogsと連携することで容易にアプリケーションログを収集できる。CloudWatchLogsサブスクリプションフィルターを使い、ログ内に特定文字列が含まれている場合のログのみ抽出し、lambdaに連携させて、SNSと連動して障害を通知できる。保持期間の設定も可能。

FireLensを利用することのメリットはCloudWatchLogs以外のAWSサービスやAWS外のSaaSへのログ転送のしやすさ。Firehoseと連携してS3やRedshift、OpenSearchServiceへのログ転送が可能。CloudWatchLogsにも同時転送可能。ログルーティング機能を担うソフトウェアとして、オープンソースで公開されている「Fluentd」や「FluentBit」が選択できる。FluentBitはAWSが提供するコンテナイメージを使用し、ECSタスク内にアプリケーションとFluentBitコンテナを同梱するサイドカー構成を取る。

さまざまなシステムに散らばっているログデータを収集、集約して、分析を行ったり、DBなどにログデータを転送することができるツールです。Elasticsearch（検索エンジン）や kibana（データ可視化ツール）と組み合わせることでログを可視化することもできる。

C言語で書かれたクラウド及びコンテナ環境に適した、ログの収集、配布を行うオープンソースのログプロセッサツール。軽量で高速、パフォーマンスを重視したアーキテクチャ。

オープンソースの全文検索エンジン。 大量のドキュメントから目的の単語を含むドキュメントを高速に抽出することができる

Elasticsearch」という全文検索エンジン(リアルタイム検索エンジン)のデータ解析・可視化プラグインとして使われる。データベース(Elasticsearch)に対し、フロントエンドでデータのUIを担う。メインの使い方は時系列データを取り扱うこと。Elasticsearch内にあるデータを検索したり、表示したり、時間軸分析をしたりできる。

マネージド型サービス。ログ分析、リアルタイムのアプリケーションモニタリング、クリックストリーム分析などのユースケースに対応する、完全にオープンソースの検索および分析エンジン。

リアルタイムのストリーミングデータをS3やRedShift、Elasticsearchなどのデータストア、分析ツールに配信するAWSのマネージドサービス。複雑な設定をすることなく、データ送信元から送信先へのデータの転送を実現することができる。

AWS上で提供されているデータウェアハウス専用のデータベースサービス。あらゆるデータを構造化して蓄積し、高速に分析処理できることが大きな特徴。またAmazon Redshiftを用いることで、機械学習を用いた高度なデータ分析も可能。

ECSタスク定義の仕様では、コンテナごとにログ出力先を指定するログドライバーの定義は１つのため、CloudWatchLogsとS3への同時ログ転送に対応しているFluentBitをログドライバーに指定する。FluentBitのカスタム定義を使用すると、同一のログをCloudWatchLogsとS3に同時出力したり、どちらか一方にのみ出力が可能。 CloudWatchLogsを経由してS3に転送することもできるが、ログ取り込みにコストがかかってしまう。

ビジネス観点でログをどのように扱うか、ユースケースを描いておくこと

FluentBitの設定ファイルをカスタマイズし、FluentBitコンテナイメージ内に取り込む。 設定ファイルをコンテナ内に追加する手段は以下の二つ。 ・S3にカスタム設定ファイルを配置し、タスク定義上からファイルの場所を指定する。複数ファイルの同梱ができない。 ・カスタム設定ファイルをあらかじめ追加した自前のFluentBit用コンテナイメージを作成し、タスク定義の対象コンテナとして指定する。イメージのバージョンやライフサイクル管理等が発生。

特定のログを別のサービスなどに転送する機能

生データを解析して構造化する

FluentBitのデータ処理の一連の流れ（Input→Parse→Filter→Buffer→Router→Output）。

生データの入力を受け付ける。他にもメトリクスデータを取得するプラグインもある。

入力された「生データ」を「Filter」で加工（追加・変更・整形・削除 etc）

生データを保管する領域として、メモリまたはファイルシステムを選択できる

出力対象となるデータは、Input時点でデータとひもづけられたTag（または、Filterで書き換えられたTag）をもとに「識別」できるようにする

「クラウドサービスプロバイダ向けのストレージサービス」「ローカルログファイル」「FluentBitコンテナの標準出力」などに対して「データ」を出力

定量的な指標として定期的に計測・収集されるシステム内部動作のデータ。

システムに関するさまざまなメトリクスを取得できる。さらにCloudWatchメトリクスとCloudWatchアラームを組み合わせることでアラートを通知できる。（lambdaなしでSNS連携が可能）

CloudWatchメトリクスとCloudWatchContainer Insights。 CloudWatchメトリクス‥ECSクラスターまたは ECSサービスの単位で次のようなメトリクスを取得。「CPU Utilization:CPU使用率」「Memory Utilization：メモリ使用率」。一分間隔で取得。 CloudWatchContainerInsights‥ECSタスクレベルでの情報を把握できるだけでなく、ディスクやネットワークに関するメトリクスも収集可能になる。一分間隔で取得。メトリクスを一覧で閲覧可能なダッシュボード。ECSクラスター単位での明示的なオプトイン（内容を承諾して有効化すること）が必要。カスタムメトリクスの扱いとなり、全て追加課金の対象。

トレース情報（アプリケーションの内部処理の呼び出しや各サービス間のトランザクション情報等）の取得をサポートするサービス。サービスマップのダッシュボードも提供されており、システム全体の可視化も可能

・サイドカー構成によるX-Rayコンテナの配置‥ ECSタスク定義の中にアプリケーションコンテナとX-Rayコンテナを同梱する。さらに、アプリケーション自体にAWSが提供するX-Ray用のSDKで一部コーティングを施すことで、X-Rayにトレース情報を送出できる。 ・ECSタスクロールの付与‥ECS／Fargate上のコンテナアプリケーションからX-Rayにトレース情報を書き込むためには特定のIAM権限が必要。タスク実行ロールではなく、ECSタスクロールへの権限付与となる。 ・VPCからパブリックネットワークへの通信経路‥X-RayはVPC外のAWSパブリックネットワークにサービスエンドポイントが存在する。ECSタスクはVPC内で稼働することから、VPCからパブリックネットワークへの経路が必要。ECSタスクがプライベートサブネット内にデプロイされているときは、VPCエンドポイントかnatゲートウェイで経路を用意する。

ビルドやテスト、パッケージング、環境上へのデプロイといったソフトウェア開発サイクルを自動化・高速化するために用いられる手法。変更を自動でリリースできるようになり、今までビルドやデプロイに費やしていた時間をアプリケーション開発に集中させることができる。また、テストの自動化を組み込むことで迅速に不具合を発見できることから、品質改善の効率化も期待できる

理由はコンテナの特性である優れたポータビリティ、再現性、軽量さ。アプリケーションに必要な依存関係をコンテナに閉じ込めることで、環境ごとのOSのライブラリバージョンの差異やコードの依存関係等を意識せずにビルド、デプロイが行える。また、アプリケーションの動作に必要なコンピュータリソースが少なくて済むため、素早いアプリケーション起動が可能。

CodeCommit‥ソースコードの管理。マネージドなプライベートソースコードリポジトリサービス。IAMと統合することでセキュアに利用可能 CodeBuild‥ビルドとテストの実行。マネージドなビルドサービス。YAML形式のビルド仕様を記述することでビルド処理を柔軟に定義できる CodeDeploy‥デプロイの実行。マネージドなデプロイサービス。段階的なデプロイや容易なロールバックが可能 CodePipeline‥パイプラインの構築。マネージドなCI/CDパイプラインサービス。ビジネス要件に合わせてさまざまなAWSサービスと統合ができる

Source‥CodeCommit,ECR,S3,Bitbucket,Github Build‥CodeBuild,Jenkins Test‥CodeBuild,DeviceFarm,BlazeMeter,GhostInspector,Jenkins Deploy‥CodeDeploy,ECS,S3,CloudFormation,ElasticBeanstalk Invoke‥Lambda,StepFunctions Approval‥手動承認

Web ベースのバージョン管理リポジトリホスティングサービス

プログラムのソースコードを、オンラインで共有・管理するサービス。Gitでバージョン管理を使えば、どのファイルが最新版かを簡単に把握できるようになる上に、上書きなどによるトラブルを防げる。GitHubはこのGitをオンラインで使えるようにして、多くのプログラマーが活用できるようにしたサービス。

ソースコードのバージョン管理が行えるシステム

オープンソースの継続的インテグレーション（CI）支援ツールの一つ。ソフトウェア開発プロジェクトなどにおけるビルドやデプロイ、テストといった作業の自動化や効率化を支援する

Android、iOS、Fire OSといったさまざまな OSの端末に対応し、モバイルアプリケーションの実機テストと検証ができる。最大 4 GBのファイル容量をサポートしている。 AWS Device Farmは、モバイルデバイスによる実機テストのほかに、デスクトップブラウザによるテストを提供する。

負荷テストツールの実行環境を提供するSaaSのサービス。100万人以上の仮想ユーザーを生成することができ、大規模な負荷テストにも対応している。

GUIでWebアプリケーションのテスト機能を作成できるクラウド型ブラウザ・テスト・サービス。 テスト対象のサイトを直接操作し、操作の記録とアサーションの定義が可能。記録したテストをGhost Inspectorから実行可能。コードを書かずにテストの定義ができる

AWSの各種リソースの配置、アプリケーションの導入、バージョン管理、負荷分散など、迅速にデプロイの実行と管理をまとめて行ってくれるサービス。 AWS Elastic Beanstalkを使うことで、簡単にアプリケーション関連の配置・導入・管理の作業が迅速に実行できる。具体的にはソース容量のプロビジョニング、AutoScaling、アプリケーションの状態などのモニタリングなどの作業を自動的におこなう。

分散アプリケーション、マイクロサービスのコンポーネントの疎結合化を可能にするAWSのマネージドサービス。 各コンポーネントが独立するため、アプリケーションのスケール及び変更を容易にすることができる。 一つの Step Functions の定義全体をステートマシンと呼び、これらはASL(Amazon States Language)と呼ばれる独自言語を用いて記述される。 また、ASLを用いて定義されたワークフローはマネジメントコンソール上でビジュアライズされる。

マルチアカウントで、各環境ごとにアカウントを用意するのが一般的。ある環境で行ったテストなどが他環境に影響を及ぼすリスクを減らせる。

開発資産管理の観点や、運用の複雑性を回避するため

ファイルの変更履歴を保存・追跡できるバージョン管理システムでは、ファイルやプロジェクトのある時点以降の変更履歴の流れを分岐させて別の系統として独立させることができる機能があり、この分岐した流れのこと。元の系統から別のブランチを派生させることにより、開発中のソフトウェアからリリース用の版を分岐させて安定させたり、ある開発プロジェクトの内容を受け継いで別の目的のプロジェクトを立ち上げたりすることができる。

他から分岐したのではない（親ブランチを持たない）オリジナルの系統のこと

分離したブランチを再び元のブランチに統合することができるシステム

ブランチの運用規約をあらかじめ定めておき、その運用に則った開発を行うこと。 以下の3つがある。 Git-flow GitHub-flow GitLab-flow

基本フロー↓ 1.master から develop を切る。 2.develop から feature を切り、機能開発を行う。 3.feature から develop へマージを行う。 4.develop から release を切り、バージョニングなどのリリース作業を行う。 5.リリースが完了したらタグ打ちを行い、release から master と develop へマージを行う。 develop‥現在開発中のソースが格納されるブランチ release‥バージョニングなどのリリース作業を行うブランチ master‥リリース済のソースが格納されるブランチ hotfix‥リリース済みのソースに対して緊急対応を行うブランチ メリット↓ 各ブランチの役割がはっきりしており、状況に応じて柔軟に対応することができる。 各ブランチに対するメンバーの権限を適切に扱うことができる。 リリース管理が厳密に行える。 どのプロジェクトにも適用可能。 デメリット↓ 運用ブランチの数が多い。 各ブランチのルールとフローが複雑。 プロジェクトによっては不要なブランチが存在する。（release や hotfix）

1.master から feature を切り、機能開発・緊急対応などを行う。 2.feature から master へマージを行う。 3.master のリリースを行う。 master‥最新リリースのソースが格納されているブランチ feature‥開発作業を行うブランチ メリット↓ 高速でこまめなリリースが可能。 ブランチ同士のコンフリクトを最小限に抑えられる。 Git 初学者に易しく運用しやすい。 デメリット↓ リリースのバージョン管理機能が存在しない。 リリースタイミングを調整できない。 ブランチに対してメンバーの権限を設定しづらい。 対応可能なプロジェクトが限定される。

1.master から feature（緊急対応時は hotfix） を切り、機能開発を行う。 2.feature から master へマージを行う。 3.master から pre-production を切り、リリース作業を行う。 4.リリースが完了したら（タグ打ちを行い）、pre-production から production へマージを行う。 master‥開発中のソースが格納されるブランチ feature‥開発作業を行うブランチ。（緊急対応時はhotfix） pre-production‥バージョニングなどのリリース作業を行うブランチ production‥リリース済のソースが格納されるブランチ メリット↓ 運用ブランチの数が比較的少なく、Git-Flow のように複雑でない。 Git-Flow ほど厳密ではないが、リリース管理を行うことができる。 各ブランチに対するメンバーの権限を適切に扱える。 デメリット↓ GitHub-Flow ほどの開発からリリースまでのスピード感は出せない。 Git-Flow ほどの厳密なリリース管理やブランチ権限管理ができない。 対応可能なプロジェクトが限定される。

ある時点の変更に名前をつけれる名札のようなもの

初期にサンプルアプリケーションを利用してCI/CDパイプライン経由で一度デプロイを成功させておく。アプリケーションの変化に応じてパイプラインもメンテナンスする。

ECRに保存されるコンテナイメージは、実態としてS3に保存されているため。S3はイレブンナインの耐久性を有し、安全にデータを保存できる。また、コンテナイメージはソースコードとDockerFireさえあれば、再ビルドすることで生成可能なため。

コンテナイメージを一定期間のみ保存したいケースや指定した世代分のみ保持したいケース等に対応できる

環境によってコンテナイメージ利用のライフサイクルが異なる際に、イメージ全体に対してステージング環境のライフサイクルポリシーを適用していると、本番環境で利用するイメージを消してしまうことがある。 環境ごとに固有のタグ識別文字を付与し、タグごとのライフサイクルポリシーを指定することで上記の問題を回避できる。

環境ごとの識別子とコードリポジトリのコミットID。現在ECS上に展開されているコンテナがどのソースコードバージョンで稼働しているのかが明確になるから。

・不正なデータがCI/CDを経由したり、環境上でデプロイされるリスクを完全に払拭したい場合‥IAMユーザーに紐づくIAMポリシーやS3バケットポリシー等で制限を設ける ・承認プロセスを設ける‥CodePipeline上に承認アクションを設定する ・CI/CDパイプラインを介さないコンテナイメージのデプロイを禁止‥ECSやECRに対する書き込み・実行権限を制限する

踏み台ホスト

・踏み台サーバーがインターネット向けに公開され、ログイン経路が外部にさらさらる ・コンテナ系サービスではないEC2の設計、構築が必要となる ・EC2の運用負荷が発生する 解消方法↓ ・セッションマネージャーを利用すると、Bastionをパブリックに置かずに済む。 ・ECSタスク内にSSMエージェントを仕込む

攻撃対象領域。インターネットからアクセス可能な対象では、不正アクセスやサイバー攻撃を受ける可能性が高くなる。

利用するAWSサービスの責任共有モデルを把握することで、自分たちが何に対してセキュリティ対策をすればよいかが見えてくる。 EC2はワーカーノード設定（OS設定と脆弱性対策、モニタリング、パッチ適用）が必要だか、FargateはAWSの責任。

コンテナのセキュリティレベルを高めるためのベストプラクティスまたはガイドライン。アメリカ国立標準技術研究所（NIST）が公開。「イメージ」「レジストリ」「オーケストレータ」「コンテナ」「ホスト」のそれぞれの観点からセキュリティ上の懸念と対策の推奨事項を提供

コンテナイメージがどのような脆弱性を有しているのかを日々スキャンし、脆弱性を取り除く。 コンテナイメージに含まれるライブラリのバージョンは時間が経つと、脆弱性が該当する可能性があるため、ECRのイメージスキャンとOSSであるTrivyを活用した対策が有効

ECRにはプッシュされたコンテナイメージに対する脆弱性スキャンを行う機能が備わる。機能を有効化するとスキャンを行える。追加費用なし。 イメージスキャン方法↓ ・プッシュ時スキャン ・手動スキャン

OSSのコンテナイメージスキャナー。 スキャン対象にPythonやRuby等、アプリケーション依存関係を指定できる。対応しているコンテナのベースOSも幅広い。CodeBuildのワークフローファイル等に記述することで、容易にスキャンが可能

スキャンを継続的かつ自動的に実施することが重要。CI/CDにおけるスキャン処理のみだと、開発やリリースをあまり行わないアプリケーションの脆弱性発見が遅れてしまう。そのため、Eventbridgeから定期的にlambdaを実行し、ECRの手動スキャンを行うべき。ECRは1日1回のみ手動スキャン可能。

コンテナイメージ作成時のベストプラクティスに従って開発する。Dockleというコンテナベストプラクティスチェックツールを使うと良い。コンテナイメージにベストプラクティスに基づいたスキャンを実行できる。ビルド済みイメージを指定するだけで簡単に実行できる。

・公開レジストリサービスから取得できるベースイメージには、マルウェアが仕込まれている可能性がある。対策として、提供元が不明なベースイメージは利用しない。 ・GuardDutyを利用して、コンテナと外部との不正な通信を検知する。

VPCフローログやCloudTrailのイベントログ、DNSログ等から悪意のある通信を識別・検知するマネージドサービス。

秘密情報はイメージ外の安全な領域に保存し、コンテナを実行する際に動的に提供されることが望ましい。秘密情報が格納されたSeacretsManagerやSSMパラメータストアのARNと環境変数名をタスク定義内でマッピングすることで、コンテナイメージ内のOSの環境変数として認識させることができる。SSMパラメータストアで秘密情報を扱う場合は、string定義では格納するデータが暗号化されないため、必ずsecurestringを選択する。

自分たちの環境内における信頼できるイメージとレジストリの一元的な管理。ECRを使うと容易に実現可能。イメージの署名検証も有効。コンテナイメージにデジタル署名を付与することで、レジストリに保存されているイメージの整合性と公開者情報を検証できる

レジストリに保管するイメージの管理やレジストリ自体の認証・認可

コンテナイメージはタグを利用することで複数バージョンを管理することが一般的だが、時間の経過と共に脆弱性を含んでしまったバージョンを間違えて本番環境にデプロイしてしまう可能性もあるため、適切に管理すべき。ライフサイクルポリシーを適切に設定することでバージョン管理を容易に自動化できる。 ECRリポジトリではプッシュ済みのタグと同じタグ名のイメージをプッシュすることで上書きすることができる。上書きされたイメージは消失する。 IMMUTABLEという設定でイメージタグの上書きを禁止できる。

レジストリの認証・認可が不十分な場合、想定外の送信元アクセスを許可してしまいイメージの改ざんや情報流出の原因になる。ECRでイメージを操作するにはログインが必要なため、IAMポリシーの設計に注意を払うべき。 ECR作成時にプライベート設定となっていることを必ず確認する。 リポジトリポリシーを設定することでイメージのプッシュ、プルなどの許可拒否を決められる

ECSの管理アクセス制限をIAMによる最小権限の原則で行う。管理者グループはECS全体への操作権限を所有、各ビジネスチームは特定のECSクラスターに対する操作権限を所有という風に権限分離も可能

Fargate上にホストされるECSタスクは全てVPC上に配置される。ECS/Fargateではawsvpcと呼ばれるネットワークモードが選択される。ECSタスクごとに独自のENIが割り当てられ、そこにプライベートIPv4アドレスが割り当てられる。このことから、ECS／FargateのネットワークセキュリティはVPC全体を俯瞰して考えた方がよい。

ECSタスクから構成されるVPCネットワークにおいては、次の3点が設計のポイント。 ・パブリックネットワーク→VPCへの通信 ・ECSタスク間の通信 ・VPC→パブリックネットワークへの通信

パブリックネットワークにECSタスクを配置すると、外部からのアクセスを受け入れることになる。セキュリティグループかアプリケーション内部での通信制御になる。アプリケーションレベルでのセキュリティ攻撃対策を行うにはWAFを活用するとよいが、連携できるサービスが限定される。CloudFront,ALB,APIgatewayの３つ。 例えばALBをパブリックに配置し、ECSタスクをプライベートに配置するなど。ECSタスクのセキュリティグループにALBのセキュリティグループからのみ許可すると、必要最低限のネットワーク要件を実現できる。

ECSタスクやALBに紐付くセキュリティグループのルールを適切に設定すると通信を容易に制御できる。 例えば、フロントエンドECSのセキュリティグループをALBのセキュリティグループで許可し、バックエンドECSのセキュリティグループでALBを許可するなど。

ECSタスク上からリージョンサービスにアクセスするにはパブリックネットワークへのネットワーク経路が必要。セキュリティ上、ECSタスクはプライベートサブネットに配置すべき。パブリックサブネットにNATGatewayを置いて、internet gateway経由にするか、プライベートサブネットに置いたVPCエンドポイントを経由してプライベートなネットワーク経路を使うかで実現する。2つの方法の違いとして、インターフェース型のVPCエンドポイントは時間単位の料金と処理データに応じた料金が発生するため、マルチAZ構成などのエンドポイントを多数使う構成だとコストが高い。NATで集約するほうが安いこともある。大量のデータを処理するワークロードの場合はVPCエンドポイントのほうが安くなる。

セキュアコーディングの実践や、WAFの設置。ECSタスク定義では、コンテナのルートファイルシステムアクセスを読み取り専用に変更できる。仮に不正なプログラムが混入した場合にも、ファイル改ざんに関する脅威を小さくできる。

内蔵ハードディスクやSSDなどのストレージ装置内に設けられたファイルシステムのうち、ルートディレクトリが割り当てられたもの

コンピュータがストレージ（外部記憶装置）の内容を整理するファイルシステムにおいて、装置やシステム全体の最上位のディレクトリのこと。すべてのファイルやディレクトリはルートディレクトリを根（root）とする木構造のディレクトリ階層のいずれかに収まっている。

IAMポリシーやリポジトリポリシーを駆使して、未承認のコンテナのデプロイを阻止できる。 例えばステージング/プロダクション用ECRのリポジトリポリシーではCI/CD以外のイメージプッシュを拒否し、IAMユーザーによるECSタスク定義の更新を拒否する。ECSタスク定義を更新できると、デプロイ対象のコンテナのイメージを指定できてしまうから。

ECSサービス内部のスケジューラーがベストエフォートでAZ間の負荷バランスを調整しながら配置してくれる。

CloudWatchでECSの各種メトリクスとCloudWatchアラームを連携させることで通知を自動化。TaskCount（ECSクラスター内の稼働しているタスク数）とRunningTaskCount（ECSサービス内の稼働しているタスク数）というメトリクスを組み合わせると有効

AWS内部の一時的なハードウェア障害等によるECSタスク停止は維持するタスク数まで自動で起動される。利用者からの処理を十分に捌けないECSタスク数となる場合にアラームを通知すべき

ALBターゲットグループにECSタスクを登録しておくと、ECSタスク障害時にALB側が対象のECSタスクをターゲットから自動的に除外し、正常に稼働しているECSタスクにのみ振り分けられるため、可用性が向上。解除が完了するまでにリクエストに対して、5xxエラーを返却する可能性がある。

ECSは、AWS内部におけるハードウェア障害やセキュリティ脆弱性が存在するプラットフォームであると判断された場合、新しいタスクに置き換えるイベントを発生させる。 Fargate上で稼働しているECSタスクはパッチ適用に伴うメンテナンスイベントが発生。事前に通知がある。 ECSはECSタスク停止を指示する際に、SIGTERMシグナルを送信する。応答がない場合、デフォルト30秒でタイムアウトし、SIGKILLシグナルが発行される。 SIGTERMによりアプリケーションが安全に終了できるような実装をしないとSIGKILLで強制終了し、データが失われたり不整合が起きたりする。

プロセスに対して送信される信号。SIGTERMは送信先に対してプロセスの終了を要求するシグナル。ECSからSIGTERMが発行されると、ECSはアプリケーションに対して終了を指示することになる。

プロセスの強制終了を要求するシグナル

リリース対象のアプリケーションにリクエストが届かないようにしたり、利用者にメンテナンスの旨を伝えておく。メンテナンス中であることを伝えるページ（Sorryコンテンツ）をリクエストに対して返すには、ALBと組み合わせてECS/Fargateを利用している場合、ALBのリスナールールで、通常時はTargetgroupに通信を転送する設定の優先度を上げ、メンテナンス時にはSorryコンテンツに通信を転送する設定の優先度を上げる。