書籍名「AWSコンテナ設計・構築本格入門」
株式会社野村総合研究所 (著),
新井雅也 (著), 馬勝淳史 (著), NRIネットコム株式会社 (監修), 佐々木拓郎 (監修)
読もうと思った動機
生成AIアプリの実装環境の確立: 将来的な生成AIアプリケーションを、AWS Fargateを活用し、安全かつ運用負荷ゼロ（サーバーレス） で迅速にデプロイするため。
技術ポートフォリオの強化: Qiitaにはない自前のCI/CD環境と高可用性インフラを構築し、自身の技術的な信頼性とスキル（アジリティ、セキュリティ）を対外的に証明するため。
写経したノートの写真
書くと覚えるので写経してます。そのノートをUPしときます＾o＾
印象に残った部分
p31コンテナ設計・運用に取り組む際の姿勢
ビルドからデプロイまでの流れや、コンテナオーケストレーション自治あの権限制御、定義管理、セキュリティ設定なども求められます。
パブリッククラウドを前提とすることで、構築やその運用負荷は、一部軽減されますが、可用性、運用性、
p34 Amazon Elastic Container Service
ECSは、フルマネージドなコンテナオーケストラです。コントロールプレーン同様、コンテナのオーケストレーションとはコンテナを管理するという意味でもあります。ポイントは、オーケストレーションサービスという点でありコンテナを動かす実行環境のサービスではない。という点です。Kubernetesとは異なり、ＥＣＳはＡＷＳがオーナーシップを持って進めるコンテナオーケストレータです。
p35 タスク タスク定義
タスク
コンテナが動作するコンポーネントをＥＣＳでは「タスク」と読んでいます。タスクは１つ以上のコンテナから構成されるアプリケーションの実行単位です。
タスク定義
タスクを作成するテンプレート定義です。
ＪＳＯＮで記述されます。テンプレート定義の中で、デプロイするコンテナイメージタスクとコンテナに割り当てるリソースやＩＡＭロール、CloudWatch Logsの出力先等を指定します。
サービス
指定した数だけ、タスクを維持する。
スケジューラーで、オーケストレータのコア機能にあたる要素です。
サービス作成時は、起動するタスクの数や関連付けるロードバランサーやタスクを実行するネットワークを指定します。
AWS Fargate
データプレーン
コンテナが実際に稼働するリソース環境を指します。
AWS FargateはECSとEKSの両方で動作する、コンテナ向けサーバレスコンピューティングエンジンです。
FargateはAWSフルマネージドなデータプレーンとして定義されています。コンテナ向けであるため、Fargate単体で利用できません。ECSやEKSとセットで利用されます。
メリット
Fargateの最大のメリットは、やはりホストの管理が不要となる点です。サーバーのスケーリング、パッチ適用、管理にまつわる運用上のオーバーヘッドは発生しません。Fargateでは、コンテナが実行されるインフラはAWSによって常に最新の状態に保たれます。
Fargateの登場により、利用者はホストの管理から解放され、自分たちのビジネスに一層注力できるようになりました。
デメリット
Fargateはマネージドなデータプレーンであり、AWS側がコンテナの稼働するOSを管理しています。AWS利用者側がOSに直接介入できません。そのため、カーネルパラメータなどのデータプレーン側OSリソースを詳細にチューニングすることが前提なアプリケーションには不向きです。
p43 リポジトリ Amazon Elastic Container Repository(ECR)
ECRはフルマネージドナコンテナレジストリです。このサービスを使うと、コンテナイメージを簡単に保存管理できます。まだ、ECRはECSと連携でき、新しいコンテナを立ち上げるときに簡単にコンテナイメージを取得できます。AWS上でシステムを構築する際は、AWSサービスとの連携やセキュリティ設定が簡単なことを考えるとECRを使うことをオススメします。
AWS Lambda
Lambdaは、利用者がコードをアップロードするだけでコードを実行できるサービスであり、AWS側で基盤となるコンピューティングリソースを自動的に構築してくれるフルマネージドサービスです。
p49 ECS on Fargate
運用コストは、かなり低くなります。
EC２でネックであったインフラ管理の保守管理コストから解放されるためです。このホストマシンの運用/管理コストの削減がFargateの最大のメリットといっても過言ではありません。TOC観点以外のコンプライアンス準拠の観点でも価値です。例えば、ECS/Fargateはクレジット業界の情報セキュリティ基準であるPCI DSSに準拠しています。
Fargateを使うことで、コンテナを動かすためのインフラストラクチャを抽象化するため、ホストマシンのOSやミドルウェアの脆弱性対策は不要と判断した例もあります。
p87 設計で求められる要件と基本アーキテクチャ
・CI/CDパイプラインを構成し、アプリケーションリソースに対するアジリティを高めたい。
・各レイヤで適切なセキュリティ対策を施したい（不正アクセス対策、認証データの適切な管理、ログ保存、踏み台経由の内部アクセス等）を施したい。
p105 CI/CDと相性のよいコンテナ
一般的にコンテナはCI/CDとの相性が良いと言われていますが、その理由とはコンテナの特性である優れたポータビリティ、再現性、軽量さです。開発環境、ステージング環境、プロダクション環境といった環境が存在する状況において、システム構成が異なるケースはよくあります。このような状況では、環境に導入されているOSのライブラリバージョンの差異やコードの依存関係などを意識したビルドやデプロイの手順が求められています。
p119 Bastion 設計
障害切り分けを目的として内部ネットワーク上からアプリケーションに対して疎通を確認したり、DBインスタンスにログインして、テーブルメンテナンスを実施したいケースがあります。
p371 セキュリティ設計 アプリケーションへの不正アクセス防止
WAFはいかなるWebアプリケーションファイアーウォールです。AWSと冠していることからわかるように、フルマネージドなWebアプリケーションファイアウォールサービスとなります。
WAFとの組み合わせが可能代表的なAWSサービスの１つがALBです。
AWSのコンテンツデリバリーサービスであるCloudFrontや、APIサービスであるApiGateWay等にも直接アタッチできます。本書では、ALBに対してWAFを直接アタッチすることになります。WAFは大きく分けて「ルール」、「ルールグループ」、「ウェブACL」の３つの構成要素から成り立っています。
ルール
リクエストの検査方法を定義します。
ルールグループ
名前の通り、ルールを集約した定義です。ここでは検査するルールの優先順位を設定できます。
ウェブACL
ルールグループを適用するAWSのリソースを紐付けの役割となります。
実践できること or 感想
感想
運用上のブレークスルー（Fargateの価値）： Fargateが提供するホスト管理からの解放（サーバーレスコンピューティング）が、TOC（Total Cost of Ownership）とコンプライアンス準拠（PCI DSSなど）の両面でいかに大きなメリットであるかを理解しました。これにより、リソース管理から解放され、ビジネスロジックに集中できるという最大の価値を得られます。
コンテナオーケストレーションの構造化： ECSの基本要素であるタスク定義、タスク、サービスという実行単位と、その役割分担（特にECSが実行環境ではない点）を整理できたことで、コンテナ管理の全体像が明確になりました。
セキュリティの多層防御設計： CI/CDによるアジリティの追求と同時に、ALBやCloudFrontにWAF（Webアプリケーションファイアウォール）をアタッチする具体的な不正アクセス対策や、Bastion設計による内部ネットワーク保護の重要性を再認識しました。
あとこの本改訂版でるようなので、それを読んで皆も自分のWEBサイト（城）を持とうね！
実践できること
Webサイトの初期構築完了 (ECS on Fargate)： インフラ管理のオーバーヘッドを最小限に抑えた個人Webサイトのプロトタイプ構築を完了しました。
https://rya234.com/
セキュリティ多層防御の実装： 構築済みのALBに対して、AWS WAFのウェブACLをアタッチし、「ルールグループ」に基づいた不正アクセス対策を施します。
CI/CDパイプラインの確立： GitHub Actionsを利用し、コンテナの特性であるポータビリティと再現性を最大限に活かした自動ビルド＆デプロイのCI/CDパイプラインを実装します。
ECRの適切な運用： Dockerイメージの保存・管理をAmazon ECRに集約し、ECSとの連携をシンプル化することで、コンテナデプロイのセキュリティとアジリティを確保します。