この記事はChatGPTを使って勉強した内容をChatGPTにブログ記事化してもらったものです。

はじめに：なぜアプリ開発者もCI/CDを理解すべきか

CI/CD（継続的インテグレーション／継続的デリバリー）は、アプリを安全かつ迅速にリリースする仕組みです。
多くの現場では GitLab や GitHub Actions などの CI/CD ツールと AWS を組み合わせて運用しています。

アプリ開発者が「コードを書いて終わり」ではなく、どのようにデプロイされ動くのかを理解しておくと、
バグの原因やパフォーマンス問題を自分で特定しやすくなります。

本記事では、CI/CD の流れで必ず登場する AWS の主要サービスを、開発者の立場から整理します。

CI/CDの全体像（AWS連携の俯瞰）

GitLab CI/CD
↓
Docker Build → Push to ECR
↓
ECS(Fargate)がイメージをPullしてデプロイ
↓
CloudWatchで稼働状況を監視
↓
CloudTrailで操作ログを記録

GitLab Runner が AWS の ECR/ECS と通信して、自動でデプロイを実行する構成が一般的です。
この中で、開発者が最低限知っておくべき AWS サービスは次の 5 つです。

ECR（Elastic Container Registry）は、Docker Hub の AWS 版です。
アプリのソースコードをビルドして生成した Docker イメージをここに登録し、ECS などが取得して実行します。

開発者が理解しておくポイント

ECS はコンテナを稼働させる AWS のマネージドサービスです。
Fargate モードを使うと、サーバー（EC2）を用意せずにコンテナを直接実行できます。

開発者が理解しておくポイント

IAM（Identity and Access Management）は AWS の認証・認可の基盤です。
CI/CD が AWS を操作するには、明確に権限を付与されたロールやユーザーが必要です。

開発者が理解しておくポイント

CI/CD 用 IAM は「ECR と ECS の操作権限のみに限定」して付与する（最小権限の原則）。
ECS タスクには 2 種類のロールがある：
- Task Execution Role：ECS がコンテナを起動するための権限。
- Task Role：アプリケーションが S3 や DynamoDB など他 AWS サービスを利用する際の権限。
「どのロールが、どの操作を、どのタイミングで行うか」を整理しておくとトラブルシュートが容易。

GitLab Runner（CI/CD 実行サーバー）が AWS と通信するためには、ネットワークの到達性が確保されている必要があります。

開発者が理解しておくポイント

VPC（Virtual Private Cloud） は AWS 内の独立したネットワーク空間。
Runner がオンプレや別 VPC にある場合、NAT Gateway／VPC Peering／Transit Gateway などを通して ECR/ECS にアクセスしている。
ECR と ECS は同一リージョンに配置することが推奨。異なるリージョン間通信はレイテンシーとコスト増につながる。

CloudWatch はアプリや ECS の稼働状況を可視化するサービスです。

CloudTrail は AWS アカウント全体の API 操作履歴を記録する監査サービスです。

開発者が理解しておくポイント

CI/CD を理解すると、アプリ開発者は「コードがどうデプロイされ、どこで動いているか」を明確に把握できます。
AWS の ECR・ECS・IAM・VPC・CloudWatch を理解しておくことで、
インフラチームとの会話が通じる開発者 になれます。

アプリの品質とデリバリーのスピードを両立するためにも、
CI/CD の仕組みとそれを支える AWS サービスを自分の言葉で説明できるようにしておきましょう。

次回からはこの1~5の詳細をそれぞれ記事化したいと思います。