1. はじめに
本記事では、初めてAWSのECS（Fargate）でサービスを構築した際、構築自体は成功しているはずなのに「なぜかヘルスチェックが通らず、タスクの再起動が繰り返される」というトラブルに遭遇し、解決した経験を共有します。
結論から言うと、原因は「わかっているつもり」だったセキュリティグループ（SG）の設定ミスでした。
2. セキュリティグループとは？
そもそもセキュリティグループとは何なのか。
一言でいうと、「AWSの各サービスを守る、専用の門番」です。
ECS（アプリ）やRDS（データベース）といったリソースごとに門番が立っており、誰を通して誰を追い返すかを厳しくチェックしています。
イメージしやすく、「マンションのオートロック」に例えてみます。
① 基本は「不審者お断り」（ホワイトリスト形式）
マンションのオートロックと同じで、「許可リスト（鍵）」を持っていない通信は、1ミリも中に入れません。
デフォルトではすべての扉が閉まっているため、明示的に許可をしない限り、誰とも通信できないようになっています。
② 帰りは「顔パス」でOK（ステートフル）
これはセキュリティグループの賢いところで、「一度入るのを許された人なら、帰りはチェックなしで通してくれる」という仕組みです。
「入り口さえ通れば、出口（帰り道）の心配はしなくていい」と覚えておけばOKです。
③ 設定するのは「入り口」と「出口」
インバウンドルール（入り口）： 「誰が入ってくるのを許すか」の設定です。今回のトラブルの主役はここです。
アウトバウンドルール（出口）： 「中から外へ出る」ときの設定です。こちらは最初から「誰でも出て行っていいよ（全開放）」となっているのが一般的です。
3. 原因：RDS側の門番がECSを拒絶していた
原因を一言で言うと、「RDS側のセキュリティグループで、ECSからの通信を許可していなかったから」です。
RDS側のインバウンドルール設定漏れ
セキュリティグループはリソースごとに付帯しています。当然、接続先のRDSにも専用の門番（SG）がいます。
アプリ（ECS）からデータベース（RDS）へ接続するためには、RDS側のセキュリティグループのインバウンドルールに、「ECSからの通信を許可する」という設定を追加しなければませんでした。
許可しないとどうなるか
- ECSタスクからRDSへの疎通（接続）が、RDSの門番によってブロックされる。
- アプリケーションがDB接続エラーを吐き、正常に起動できない。
- それを見たロードバランサー（ALB）が「このタスクは異常だ」と判断し、ヘルスチェックエラーとしてタスクを強制終了・再起動させる。
これが、無限にタスクが入れ替わり続ける「再起動ループ」の正体でした。
4. 解決策：SG IDでの連携
解決するには、RDSのセキュリティグループに以下のルールを追加します。
タイプ： 使用しているDB（MySQL/PostgreSQLなど）
ソース： ECSタスクに付与しているセキュリティグループのID（例：sg-xxxxxxxx）
IPアドレスではなく「セキュリティグループID」を指定することで、ECSのタスクが増減したりIPが変わったりしても、安全に通信を許可し続けることができます。
参考：Amazon VPC セキュリティグループ (AWS公式)
5. まとめ
今回のトラブルを通して学んだのは、「クラウド構築は、点ではなく線で考えることが大切」だということです。
ECS（点）が正しく動いていても、RDS（点）との間の道（線＝セキュリティグループ）が繋がっていなければ、サービスは完成しません。
特にECS Fargateはログが追いにくい場合があるため、「まずは通信の門番（SG）を疑ってみる」のが解決への近道です。
これからECSを構築する方は、ぜひ「リソース間の門番さん」同士がちゃんと挨拶できているか、真っ先に確認してみてください！