はじめに
AWS Fargate プラットフォームバージョン 1.3.0 のサポート終了対応として、ECS サービスの更新依頼を受けました。
当初は、対象の ECS サービスを確認し、Fargate platform version を 1.4.0 へ更新する作業だと考えていました。
しかし調査を進めると、対象は Atlantis 関連の ECS リソースであり、実際にはほぼ運用されていない状態でした。
結果として、今回の対応は「Fargate のアップデート」ではなく「未使用リソースの整理・削除」になりました。
まず結論
今回のポイントは以下です。
- AWS Health で通知されたからといって、必ず更新すればよいとは限らない
- ECS は Cluster / Service / Task Definition / Load Balancer を分けて確認する必要がある
- 稼働実態がない場合、更新より削除の方が合理的なことがある
- 削除前には JSON バックアップや復旧用メモを残しておくべき
最終的には、Atlantis 関連の ECS Service、Task Definition、ALB、Target Group、Listener、IAM Role を削除しました。
前提
対象は Terraform PR 自動化用途として構成されていた Atlantis 関連リソースです。
ECS 周りでは、以下を分けて確認しました。
| 種別 | 役割 |
|---|---|
| ECS Cluster | ECS リソースをまとめる論理的な器 |
| ECS Service | Task を維持・起動する単位 |
| Task Definition | コンテナ実行定義 |
| ALB | 外部からの入口 |
| Listener | ALB の受付ルール |
| Target Group | ECS Task への転送先 |
Fargate platform version の影響を直接受けるのは、実際に起動される Task 側です。
そのため、Cluster が残っているだけで Fargate PV 1.3.0 の問題が残るわけではありません。
最初に考えていたこと
最初は、単純に以下のような作業だと考えていました。
- 対象 ECS Service を確認する
- platform version を 1.4.0 にする
- Terraform の
main.tfやappspec.tplを必要に応じて修正する - ECS Service を更新して完了する
つまり、「現役で使われている ECS Service がある」という前提でした。
しかし、この前提が途中で崩れました。
実際に確認したこと
対象が Atlantis 関連だったため、まず本当に使われているのかを確認しました。
確認した内容は以下です。
- AWS Health Dashboard 上の対象が Atlantis 関連 ECS リソースだった
- Atlantis は Terraform PR 自動化用途の想定だった
- Webhook が設定されていなかった
- PR コメント履歴もほぼ確認できなかった
- Terraform backend の S3 state は存在するが、最終更新がかなり古かった
- DynamoDB Lock table は未作成だった
- 関連 IAM Role は存在していた
- S3 の最終アクセスもかなり古かった
- DynamoDB へのアクセス実績は確認できなかった
ここで、当初の「Atlantis が現役で使われている」という前提に疑いが出ました。
仮説が外れたポイント
当初は「Fargate PV 1.3.0 を使っている現役ワークロードがある」と考えていました。
しかし、確認結果を見る限り、Atlantis は構成上は存在しているものの、運用実態がありませんでした。
特に判断材料になったのは以下です。
| 確認項目 | 結果 | 判断 |
|---|---|---|
| Webhook | 未設定 | PR 自動実行されていない可能性が高い |
| PR コメント | ほぼなし | Atlantis 利用実績が薄い |
| Terraform state | 長期間更新なし | Terraform 運用が止まっている可能性 |
| DynamoDB Lock | 未作成 | 通常の Atlantis 運用前提と合わない |
| S3 / DynamoDB アクセス | 直近実績なし | 稼働実態が薄い |
この時点で、対応方針を「更新」から「削除可否の判断」に切り替えました。
削除判断に切り替えた理由
今回の判断軸は以下です。
- 実際に使われている証跡があるか
- 外部連携が残っているか
- Terraform state が継続的に更新されているか
- 削除すると影響を受ける依存先があるか
- 復旧に必要な情報を保存できるか
確認した範囲では、Atlantis は未使用の残骸と判断しました。
そのため、Fargate platform version を更新して延命するより、不要リソースとして削除する方が合理的だと判断しました。
ただし、いきなり削除するのではなく、復旧や監査に使えるように、削除前の情報は JSON として保存する方針にしました。
削除前にやったこと
削除前には、以下の方針を決めました。
- ECS Service / Task Definition / ALB / Listener / Target Group / IAM Role の情報を保存する
- 保存先は
atlantis-archiveのような専用フォルダにまとめる - README に「これは IaC ではなく、復旧・証跡用のバックアップ」と明記する
- 個別バックアップコマンドと一括バックアップスクリプトが重複しないように、一括スクリプトを正とする
削除作業では、消す前に戻せる材料を残すことを優先しました。
実行した主なコマンド
以下は、実際の値をマスクしたコマンド例です。
ECS Service の desired count を 0 にする
aws ecs update-service \
--cluster <ECS_CLUSTER_NAME> \
--service <ECS_SERVICE_NAME> \
--desired-count 0 \
--region <AWS_REGION>
Task 停止確認
aws ecs list-tasks \
--cluster <ECS_CLUSTER_NAME> \
--service-name <ECS_SERVICE_NAME> \
--region <AWS_REGION>
ALB 確認
aws elbv2 describe-load-balancers \
--region <AWS_REGION> \
--query "LoadBalancers[?contains(LoadBalancerName, '<RESOURCE_KEYWORD>')].LoadBalancerArn" \
--output text
Listener 確認
aws elbv2 describe-listeners \
--load-balancer-arn <ALB_ARN> \
--region <AWS_REGION>
Target Group 削除で詰まったところ
Target Group を削除しようとしたところ、以下のエラーが出ました。
An error occurred (ResourceInUse) when calling the DeleteTargetGroup operation:
Target group ... is currently in use by a listener or a rule
原因は、Listener が Target Group を参照していたことです。
この時点で、削除順序として以下が必要だと分かりました。
- Listener / Rule の参照確認
- Listener 削除
- Target Group 削除
- ALB 削除
ALB 周りは、Target Group だけを見て削除しようとすると失敗します。
ALB → Listener / Rule → Target Group の依存関係を先に見る必要があります。
Listener が専用か確認した
確認した Listener は以下です。
- HTTP 80
- HTTPS 443
どちらも Atlantis 用 Target Group のみを forward しており、他の Target Group はありませんでした。
そのため、ALB / Listener / Target Group は Atlantis 専用と判断しました。
共有 ALB であれば別の判断になりますが、今回は専用と判断できたため、削除を進めました。
削除手順
Listener 削除
aws elbv2 delete-listener \
--listener-arn <LISTENER_ARN> \
--region <AWS_REGION>
Target Group 削除
aws elbv2 delete-target-group \
--target-group-arn <TARGET_GROUP_ARN> \
--region <AWS_REGION>
ALB 削除
aws elbv2 delete-load-balancer \
--load-balancer-arn <ALB_ARN> \
--region <AWS_REGION>
ECS Service 削除
aws ecs delete-service \
--cluster <ECS_CLUSTER_NAME> \
--service <ECS_SERVICE_NAME> \
--force \
--region <AWS_REGION>
Task Definition 確認
aws ecs list-task-definitions \
--family-prefix <TASK_DEFINITION_FAMILY> \
--region <AWS_REGION>
Task Definition deregister
aws ecs deregister-task-definition \
--task-definition <TASK_DEFINITION_ARN> \
--region <AWS_REGION>
IAM Role の確認
aws iam list-attached-role-policies \
--role-name <IAM_ROLE_NAME>
IAM Role 削除
aws iam delete-role \
--role-name <IAM_ROLE_NAME>
結果
最終的に、以下を削除しました。
- Atlantis 用 ECS Service
- Atlantis 用 Task Definition
- Atlantis 用 Listener
- Atlantis 用 Target Group
- Atlantis 用 ALB
- Atlantis 用 IAM Role / Policy
これにより、Fargate PV 1.3.0 を使う実体のある ECS ワークロードは解消しました。
当初は Fargate のアップデート作業だと思っていましたが、最終的には未使用 Atlantis リソースの削除対応として完了しました。
今回の学び
今回の対応で重要だったのは、通知されたリソースをそのまま更新するのではなく、まず「本当に使われているのか」を確認したことです。
特に ECS では、以下を分けて見る必要があります。
- Cluster がある
- Service がある
- Task が動いている
- Task Definition が残っている
- ALB / Target Group が残っている
これらは似て見えますが、意味が違います。
「残っているリソース」と「使われているリソース」は別です。
また、削除作業では ALB 周りの依存関係にも注意が必要です。
Target Group を削除する前に、Listener や Rule から参照されていないかを確認しないと ResourceInUse で失敗します。
更新依頼であっても、実態を確認した結果、削除が正解になることがあります。
その場合でも、削除前のバックアップ、判断理由、削除順序を残しておくことで、安全に進めやすくなります。