AWS Copilot stack'lerini silmek veritabanlarını, DNS'i ve load balancer'ları silebilir

Copilot kullanımdan kaldırıldı, ama stack'leri yaşamaya devam ediyor

dev.to'daki ayrıntılı bir yazıya göre AWS, Copilot CLI'ya 12 Haziran 2026'da desteği kesti ve on gün sonra projenin deposunu arşivledi. Copilot ile dağıtılan servisler çalışmaya devam ediyor, çünkü araç hiçbir zaman bir runtime değildi: CloudFormation stack'leri üretiyordu ve o stack'ler CLI'dan daha uzun yaşadı.

Bu, ECS iş yüklerini çalıştıran ekipleri desteklenen bir yönetim aracı olmaksızın bırakıyor. Çoğu ekiğin başvurduğu geçiş yöntemi, her şeyi Terraform'da yeniden oluşturup eski Copilot stack'lerini kaldırmak. Yazarın uyardığı gibi, bu son adım naifçe yapıldığında üretime bağlı her şeyi birlikte götürüyor, çünkü Copilot'un iskelet yapısının bazı parçaları silme sırasında paylaşılan kaynakları yok etmeye programlanmış durumda.

Dört silme tuzağı

Yazar, Copilot'un kaynak kodunu okuduktan sonra teardown'ı tehlikeli hale getiren dört mekanizma tespit etti:

1. Lambda destekli custom resource'lar. Copilot bunlardan 13 tane içeriyor ve 9'u Delete tetiklendiğinde yıkıcı kod çalıştırıyor. Bir environment stack'i kaldırmak; ACM sertifikasını DNS doğrulama kayıtlarıyla birlikte kaldıran, özel alan adları için tüm Route 53 alias kayıtlarını silen, uygulamanın hosted zone'undaki NS delegation kaydını yok eden ve ELB access-logs bucket'ını tüm obje versiyonlarıyla birlikte boşaltan handler'ları tetikliyor. Bu kaynakları önceden Terraform'a import etmek sizi kurtarmıyor: Lambda, kaynağı şu anda hangi aracın yönettiğinden bağımsız olarak çalışıyor.

2. env-controller. Her service stack'i bir EnvControllerAction custom resource'u içeriyor. Paylaşılan bir ALB'ye, NAT gateway'lere veya EFS'ye ihtiyaç duyan son servis silindiğinde, env-controller environment stack'ini bunları kaldıracak şekilde yeniden yazıyor; böylece load balancer ve dosya sistemi servisle birlikte kayboluyor.

3. Korumasız addon'lar. Aurora, DynamoDB ve S3 addon'ları DeletionPolicy içermeyen bir nested stack'te yaşıyor; bu yüzden parent stack'i silindiğinde CloudFormation veritabanını da birlikte götürüyor.

4. --retain-resources bayrağı insanların varsaydığı şekilde yardımcı olmuyor. Yazıya göre yalnızca zaten DELETE_FAILED durumunda sıkışmış stack'lerde işlev görüyor.

Önce koru, import et, sonra sil

Yazara göre güvenli sıra, alışılmış düzenin tersine çevrilmesinden geçiyor. Önce, her stack'teki — nested stack'ler ve StackSet dahil — her kaynağa DeletionPolicy: Retain ve UpdateReplacePolicy: Retain uygulanmalı; bir Custom::* kaynağını retain etmek, CloudFormation'un Delete handler'ını çağırmasını da engelliyor. İkinci olarak, her kaynak tam dağıtılmış değerleriyle Terraform'a import edilmeli, böylece ilk plan yalnızca import'tan oluşmalı. Ancak bundan sonra Copilot stack'leri silinmeli: CloudFormation kaynakları sadece unutuyor ve hiçbir şey yok edilmiyor.

ecsodus, geçiş için alfa aşamasında bir araç

Bu politikaları onlarca kaynak üzerinde elle uygulamak hataya davetiye çıkarıyor; yazar bu yüzden tam olarak bu sırayı otomatikleştiren Apache-2.0 lisanslı ecsodus adlı bir CLI geliştirmiş. Yazarın öne çıkardığı tasarım kararları: her AWS client'ı yalnızca Describe, List, Get ve Lookup çağrılarına izin veren bir korumayla sarılı, böylece araç hiçbir şeyi değiştiremiyor; ürettiği Terraform, gerçek dağıtılmış değerlerden oluşturuluyor ve bir kontrol aşaması, oluşturma, güncelleme, silme veya değiştirme içeren her planı reddediyor; retain yaması, şablonları yalnızca silme politikalarını değiştiriyorlarsa kabul edilen change set'ler üzerinden düzenliyor; ve hiçbir stack asla bölünmüyor, böylece desteklenmeyen her şey rapordaki açıklamayla birlikte Copilot'ta kalıyor. Raporlar ayrıca CloudFormation'ı olduğu gibi tutmanın sıfır riskli taban çizgisiyle başlıyor.

Yazar 30 Eylül'de aracı uçtan uca, sandbox hesabında gerçek bir Copilot v1.34.1 uygulamasında çalıştırmış: bir environment, bir Load Balanced Web Service ve DynamoDB ile S3 addon'ları; toplam beş stack ve 49 kaynak. Bildirilen sonuç: hedeflenen 44 kaynağın 44'ü sıfır değişiklik ve sıfır yıkımla import edilmiş, tüm Copilot stack'leri ve StackSet silinmiş, servis HTTP 200 ile yanıt vermeye devam etmiş, DynamoDB ve S3'teki sentinel verisi sağlam kalmış ve teardown sırasında env-controller ile rule-priority Lambda'ları hiç çağrılmamış.

Araç açıkça alfa durumunda. Sürüm 0.1, Load Balanced Web Service'leri, Backend Service'leri, bunların environment'ını ve Aurora/RDS, DynamoDB ile S3 addon'larını kapsıyor. Worker Service'ler, Scheduled Job'lar, Request-Driven Web Service'ler, Static Site'lar, NLB, CloudFront, sidecar'lar ve pipeline'lar tespit edilip engellendi olarak raporlanıyor; sıradaki plan App Runner. Yazar, kalan Copilot kullanıcılarından yalnızca-okuma envanter ve rapor komutlarını çalıştırıp neyin engellendiğini anlatan issue'lar açmalarını istiyor; bunlar yol haritasını şekillendirecek.

Neden önemli

Bir CLI'yı kullanımdan kaldırmak, oluşturduğu altyapıyı devre dışı bırakmaz ve Copilot'un temizlik mantığı devir teslim için değil, teardown için tasarlanmıştır. Bu, yeniden-oluştur-ve-geçiş türü bir göçün görünüşte rutin olan "eski stack'leri sil" adımını, tam da üretim veritabanlarını, sertifikaları ve DNS'i silebilecek adım haline getiriyor. Önce-retain, önce-import sırası bunu yeniden inşa yerine yerinde benimseme olarak yeniden çerçeveliyor ve tek bir atlanan DeletionPolicy'nin geri döndürülemez sonuçlar doğurabildiği durumlarda bunu yapım aşamasında zorunlu kılan araçlar önemli. Bir uyarı: sonuçlar, aracın yazarının kendi sandbox testinden ve alfa yazılımdan geliyor; bu yüzden bunları bir başlangıç noktası olarak görün ve hiçbir şeye dokunmadan önce kendi stack'lerinizde yalnızca-okuma envanterini çalıştırın.