Stateful Kaynaklar Ayrı Bir CDK Stack'inde mi Durmalı?

Bir CDK uygulaması aynı yerleşim sorusunu defalarca yanıtlar: bu kaynak, onu kullanan Lambda fonksiyonlarıyla aynı stack’te mi dursun, yoksa kendi stack’ini mi alsın? Yaygın tavsiye, “veritabanını ayrı tut,” doğru cevaba yanlış testle ulaşır. Ölçüt state değildir. Paylaşılan bir EventBridge bus’ı hiç veri tutmaz; ama onu silmek tüm domain’leri aynı anda bozar, dolayısıyla “state tutuyor mu” sorusu onu yanlış sınıflandırır. Yerleşimi belirleyen ölçüt yaşam döngüsüdür: bir kaynağın ömrü tek bir dağıtımdan uzun olduğunda kendi uzun ömürlü stack’ini hak eder ve diğer stack’ler ona bilinen bir adla erişir. Bu ad bir sözleşmedir ve sözleşme, ayarlayabileceğiniz bir bağlılık spektrumunun üzerinde durur.

Yaşam döngüsü testi

State, testin bariz yarısı ve bu yarı gerçek. Bir DynamoDB tablosunu, bir RDS ya da Aurora cluster’ını, nesneler içeren bir S3 bucket’ını, bir OpenSearch domain’ini veya bir Cognito user pool’unu yeniden oluşturmak, yeniden dağıtımın geri getiremeyeceği bir veri kaybına yol açar. Ama state yalnızca yarısı. Diğer yarısı buluşma noktası: hiçbir kalıcı veri saklamasa da her domain’in sabit bir kimlikle erişmeye bağımlı olduğu kaynak. Merkezi bir EventBridge bus’ı ve paylaşılan bir SNS topic’i net örnekler. Tek satır veri tutmazlar; yine de gelişigüzel bir silme veya yeniden adlandırma tüm stateless stack’leri aynı anda bozar. Yan Cui aynı sınıra uyum (cohesion) açısından ulaşır ve paylaşılan altyapıyı servisin tamamen dışına koyar: VPC ve subnet’leri “part of the ‘platform’, not the service” (platformun parçası, servisin değil) olarak görür ve “they should have their own stack and repo and pipeline” der; yani bunların kendi stack’i, repo’su ve pipeline’ı olmalı.

Yani testin iki dalı var ve ikisinden birine verilen Evet, kaynağı uzun ömürlü bir stack’e gönderir.

Sınır kaynak türü değil yaşam döngüsü olduğu için, uygulamayla birlikte neyin kalacağını da söyler: bir API Gateway, bir Lambda, bir IAM rolü veya bir önizleme ortamının atabileceği istek başına bir tablo. AWS’nin kendi rehberi de aynı temelle başlar. “keep them together unless you know you want them separated” (ayırmak istediğinizi bilmiyorsanız birlikte tutun) der, sonra istisnayı ayırır: “Consider keeping stateful resources (like databases) in a separate stack from stateless resources. You can then turn on termination protection on the stateful stack.” Yaşam döngüsü testi, bu istisnanın kesinleştirilmiş hali. Aynı içgüdü CDK dışında da görülür; Terraform ekipleri state dosyalarını aynı nedenle blast radius’a ve değişim hızına göre böler.

Stateful stack

Uzun ömürlü stack, kazara yok etmeye karşı iki yerde kapıyı kapatır. Stack düzeyinde terminationProtection: true, tüm stack’in silinmesini engeller. Kaynak düzeyinde bir removal policy, bir kaynak stack’ten çıktığında ne olacağına karar verir.

CDK burada zaten güvenli tarafa yaslanır. AWS’nin ifadesiyle araç, “policies that retain everything you create” ile varsayılanı belirler ve stack’ten çıkarılan bir veri kaynağı silinmek yerine “orphaned from the stack” olur. Yine de politikayı açıkça belirleyin ve doğru türü seçin. RemovalPolicy.RETAIN kaynağı her çıkarmada tutar ama sahipsiz bırakır; bu, yeni bir kaynağın oluşturulması geri alındığında da geçerlidir ve geride boş çöp bırakabilir. RemovalPolicy.RETAIN_ON_UPDATE_OR_DELETE silme ve yer değiştirmede tutar ama oluşturulması geri alınan bir kaynağı yine de temizler. Gerçekten stateful bir kaynak için ikincisini tercih edin; aşağıdaki kod bunu yapıyor. aws-cdk-lib içinde yalnızca L1 construct olarak sunulan kaynaklar (bir ElastiCache replication group’u, bir OpenSearch Serverless collection’ı) politikayı bir removalPolicy prop’u yerine applyRemovalPolicy(...) ile alır.

import * as cdk from 'aws-cdk-lib';
import { Construct } from 'constructs';
import * as dynamodb from 'aws-cdk-lib/aws-dynamodb';
import * as events from 'aws-cdk-lib/aws-events';

interface StatefulStackProps extends cdk.StackProps {
  readonly stage: string;
}

export class StatefulStack extends cdk.Stack {
  public readonly usersTableName: string;
  public readonly eventBusName: string;

  constructor(scope: Construct, id: string, props: StatefulStackProps) {
    super(scope, id, {
      ...props,
      terminationProtection: true, // tüm stack'in kazara silinmesini engelle
    });

    // Yer değiştirince veri kaybolur: silmede ve yer değiştirmede tut.
    const table = new dynamodb.Table(this, 'Users', {
      tableName: `myapp-${props.stage}-users`, // stage bazlı fiziksel ad: sözleşme
      partitionKey: { name: 'userId', type: dynamodb.AttributeType.STRING },
      billingMode: dynamodb.BillingMode.PAY_PER_REQUEST,
      removalPolicy: cdk.RemovalPolicy.RETAIN_ON_UPDATE_OR_DELETE,
    });

    // Buluşma noktası: saklanan veri yok ama her domain ona adla erişmeli.
    const bus = new events.EventBus(this, 'DomainEvents', {
      eventBusName: `myapp-${props.stage}-events`,
    });

    this.usersTableName = table.tableName;
    this.eventBusName = bus.eventBusName;
  }
}

Ayırmanın nedeni tam da AWS’nin dile getirdiği neden: veritabanı kendi korumalı stack’indeyken, “freely destroy or create multiple copies of the stateless stack without risk of data loss” yapabilirsiniz. Bedeli dürüstçe söylemek gerekir. Artık bir yerine iki stack üzerine düşünürsünüz ve onları CloudFormation export’larıyla bağlarsanız, birazdan anlatılan dağıtım anı kilidini devralırsınız. Ayrıca bus’ın bir removal policy taşımadığına dikkat edin: hiçbir şey saklamaz; koruması, asla gelişigüzel yok etmediğiniz bir stack’te yaşamasından gelir.

Adlandırılmış sözleşme

Bir kaynak kendi stack’inde yaşamaya başladığında, diğer her stack ona bir sözleşme üzerinden erişir. Üç tane var ve en bağımlıdan en katıya bir spektrum oluştururlar.

CloudFormation export. Aynı uygulamada bir construct’ı bir stack’ten diğerine geçirdiğinizde, CDK sizin için bir Fn::ImportValue üretir. Pratiktir ve import edildiği sürece CloudFormation değerin var olduğunu garantiler. Bedeli export güncelleme kilidi. Bir tüketici hâlâ import ederken CloudFormation, export edilen bir değeri değiştirmeyi veya silmeyi reddeder ve başka bir stack’in ona bağımlı olduğunu bildirir. Bu referansı temiz bir şekilde koparmak, CloudFormation 500 kaynak limiti yazısının ayrıntılı ele aldığı iki adımlı bir exportValue işlemi gerektirir.

SSM parametre yolu. Üretici bir StringParameter yazar; tüketici onu ssm.StringParameter.valueForStringParameter(...) ile okur, bu da CloudFormation’ın dağıtım anında çözdüğü bir token döndürür. Export kilidi yoktur ve değer, sentezlenen şablona gömülmez. Buna karşılık valueFromLookup(...) synth anında çözülür, cdk.context.json içine önbelleğe alınır ve değeri şablona gömer. Bu yüzden onu kaynak kontrolüne koymayacağınız hiçbir şey için kullanmayın. Ama dikkat: yol dizesinin kendisi sabit, bilinen bir addır. Bağlılık yok olmadı; bir seviye yukarı, kaynaktan parametre yoluna taşındı.

Fiziksel kaynak adı. Tüketici, zaten bildiği bir adla import eder: Table.fromTableName, Bucket.fromBucketName, EventBus.fromEventBusName. Dağıtım anında hiçbir şey çözülmez, dolayısıyla sıralama bağlılığı ve export kilidi yoktur. Beraberinde iki kısıt gelir. Birincisi, ad asla değişemez, çünkü değiştirmek bir yer değiştirmeyi zorunlu kılar. İkincisi, import bir proxy’dir: uygulamanızın parçası olmaz. Bir grant* çağrısı tüketicinin kendi rolüne IAM ekler (bu çalışır) ama tüketen stack’ten import edilen kaynağın kendi politikasını değiştiremezsiniz. Ayrıca fromTableName ve kardeşleri yalnızca aynı hesap içindir; bir hesap sınırını aşmak, ARN biçimini artı bir kaynak politikasını gerektirir, ki bu ilerideki bölümde ele alınıyor.

import * as cdk from 'aws-cdk-lib';
import { Construct } from 'constructs';
import * as dynamodb from 'aws-cdk-lib/aws-dynamodb';
import * as events from 'aws-cdk-lib/aws-events';
import { NodejsFunction } from 'aws-cdk-lib/aws-lambda-nodejs';

interface AppStackProps extends cdk.StackProps {
  readonly stage: string;
}

export class AppStack extends cdk.Stack {
  constructor(scope: Construct, id: string, props: AppStackProps) {
    super(scope, id, props);

    // Bu stack'in zaten bildiği bir adla import et: cross-stack export yok, dağıtım anı kilidi yok.
    const table = dynamodb.Table.fromTableName(this, 'Users', `myapp-${props.stage}-users`);
    const bus = events.EventBus.fromEventBusName(this, 'DomainEvents', `myapp-${props.stage}-events`);

    const handler = new NodejsFunction(this, 'ApiHandler', {
      entry: 'src/handlers/api.ts',
      environment: {
        TABLE_NAME: table.tableName,
        BUS_NAME: bus.eventBusName,
      },
    });

    // grant*, tüketicinin kendi rolüne IAM ekler; bu, import edilen bir proxy üzerinde çalışır.
    table.grantReadWriteData(handler);
    bus.grantPutEventsTo(handler);
  }
}

Hangi basamağı seçeceğiniz, iki stack’in dağıtım kadanslarına bağlıdır:

Sözleşme	Bağlılık	Ne zaman tercih edilir
CloudFormation export	Dağıtım anı kilidi; tüketici üreticiye sabitlenir	Stack’ler her zaman birlikte dağıtılıyorsa ve değerin kalmasını CloudFormation’ın garantilemesini istiyorsanız
SSM parametre yolu	Dağıtımda çözülür, kilit yok	Üretici ve tüketici bağımsız kadanslarda dağıtılıyorsa
Fiziksel ad	Asla çözülmez, yeniden adlandırma yasak	Sıfır dağıtım anı sıralaması istiyor ve değişmez bir adı kabul ediyorsanız (stateful varsayılan)

Fiziksel adlar üzerine bir not

AWS’nin rehberi ters yönde ilerler: “Use generated resource names, not physical names,” çünkü “Names are a precious resource. Each name can only be used once.” Bu kural, yazıldığı kaynaklar için doğru. Serbestçe yer değiştirdiğiniz bir stateless stack adları sabitlememeli, yoksa aynı hesapta ikinci bir kopya ayağa kaldıramazsınız. Ama stateful durum bu öncülü tersine çevirir. Bir veritabanını keyfî olarak yer değiştirmezsiniz. “Bu kaynak yer değiştirmeden yeniden adlandırılamaz” özelliği, üretim verisinde tam da istediğiniz garantidir. Stage bazlı bir fiziksel ad (myapp-${stage}-users) burada meşrudur, çünkü kaynak zaten asla yer değiştirmemeyi düşündüğünüz bir kaynaktır.

Kuralın uyarısı hâlâ geçerli ve bunu açıkça söylemekte fayda var. RETAIN ile sahipsiz kalan bir kaynak, stack’i gittikten sonra fiziksel adını koruduğu için, o stack’i yeniden oluşturmak; sahipsiz kaynağı silene, yeniden adlandırana veya yeniden sahiplenene kadar bir ad çakışmasıyla başarısız olur. AWS rehberiyle hiç tartışmak istemiyorsanız, daha yumuşak okuma hiçbir şeye mal olmaz: bilinen bir ad, fiziksel ad yerine bir SSM yolu olabilir. SSM yolu ve fiziksel ad, bağlılık spektrumunun iki farklı noktasındaki aynı fikirdir.

Geçici ortamlar

PR başına ortamlar, yaşam döngüsü testinin teori olmaktan çıktığı yer. Bir önizleme ortamı yalnızca stateless stack’i ayağa kaldırır ve stateful katmanı adla import eder. “Stateful katman”ın ne demek olduğu, karar ağacındaki ikinci soruya göre ayrılır: kaynak ucuz ve hızlı mı oluşturuluyor?

Ucuz ve hızlı olan, örneğin talep üzerine (on-demand) DynamoDB, saniyeler içinde oluşturulur ve boştayken neredeyse hiçbir maliyeti yoktur; bu yüzden her ortam myapp-${env}-users adlı kendi tablosuna sahip olabilir. Bu, kaynağın gerçekten kendi dağıtıcısından uzun yaşamadığı tek durumdur, dolayısıyla onu ortam başına stateless katmanla aynı yere koymak meşrudur. Aynı zamanda “birlikte tut” kampının açıkça kazandığı dar durumdur, ki sonraki bölümde ele alınır.

Pahalı ve yavaş olan, örneğin RDS, Aurora, OpenSearch veya MSK, farklıdır. Bunlar Yan Cui’nin deyişiyle “take longer to spin up, which also doesn’t play well with using ephemeral environments” ve önizleme ortamı başına bir cluster, boşta bekleme maliyetini katlar. Bu yüzden tek bir örneği tüm geçici ortamlar arasında adla paylaşın ve izolasyonu veri düzeyine indirin: tek cluster içinde ortam başına tablo adları, şemalar, veritabanı adları veya anahtar önekleri. Bu doğrudan Yan Cui’nin deseni: her geçici ortamın kullandığı ama her birinin “their own tables/databases” olduğu “one RDS cluster in the dev account”.

Bu bağlantı, araya tek bir dolaylı adım koyarak SSM basamağını kullanır. Paylaşılan cluster stack’i ARN’ini sabit bir yola yayınlar; uygulama stack’i bu yolu okurken, paylaşılan bir stage verilmemişse kendi stage’ini kullanır:

import * as ssm from 'aws-cdk-lib/aws-ssm';

// Üretici: paylaşılan cluster stack'i içinde, ARN'i sabit, bilinen bir yola yayınla.
new ssm.StringParameter(this, 'DbArnParam', {
  parameterName: `/myapp/${props.stage}/db-arn`,
  stringValue: cluster.clusterArn,
});

// Tüketici: her ortam başına uygulama stack'i içinde, paylaşılan cluster'ı çöz.
// ssmStage, paylaşılan bir stage verilmediğinde bu ortamın kendi stage'ini kullanır.
const ssmStage = this.node.tryGetContext('ssmStage') ?? props.stage;
const dbArn = ssm.StringParameter.valueForStringParameter(
  this,
  `/myapp/${ssmStage}/db-arn`,
);
// valueForStringParameter bir dağıtım anı token'ı döndürür: export kilidi yok
// ve değer, sentezlenen şablona gömülmez.

Geçici önizleme ortamları yazısı operasyonel mekaniği kapsar. Buradaki nokta ise dikiş yeri: bilinen bir adla import edin, böylece stateless katman veritabanının ortam başına mı yoksa paylaşılan mı olduğunu artık umursamaz.

Birlikte tutmanın haklı olduğu durum

En güçlü karşı argüman, “very much in the monolith stack camp” olan ve uyum için stateful ile stateless kaynakları birlikte tutmayı tercih eden Yan Cui’den gelir. Üç noktası incelemeye dayanır ve ne zaman ayırmayacağınızı şekillendirmelidir.

Birincisi, ayırmak koruma değildir. Bir veritabanını kendi stack’ine taşımak “doesn’t eliminate the risk of accidental deletion. It just moves the target.” Koruma, stack’teki terminationProtection ve kaynaktaki bir retain policy’den (DeletionPolicy artı UpdateReplacePolicy) gelir; bunların hiçbiri ayrı bir stack gerektirmez. Bunları ayarlamadan ayırırsanız, bir stack eklemiş ama hiçbir şey korumamış olursunuz.

İkincisi, değişmemiş stateful kaynakları bir arada tutmanın dağıtım anı maliyeti sıfıra yakındır. CloudFormation değişmemiş kaynakları atlar, dolayısıyla dağıtım süresi stateless sayısını izler. Yan Cui üç stack’i ölçtü: 5 Lambda fonksiyonu 46,4 saniye sürdü; aynı 5 Lambda artı 5 DynamoDB tablosu da 46,4 saniye sürdü; 20 Lambda 55 saniye sürdü. Tablolar bedavaydı; fazladan on saniye daha fazla fonksiyondan geldi. (Bunlar 2023 rakamları; mutlak sayılar servisle birlikte kayar ama biçim aynı kalır.)

Üçüncüsü, CDK’da dağıtım birimi stack değil uygulamadır. Yan Cui’nin sonraki notunun kabul ettiği gibi, “the unit of deployment of CDK is the CDK app,” yani bir monoliti aynı uygulamadaki iki stack’e bölmek tek başına bağımsız bir dağıtım kadansı kazandırmaz. Hâlâ birlikte dağıtılırlar. Gerçekten bağımsız dağıtımlara ihtiyacınız varsa, bu ayrı bir uygulama veya pipeline kararıdır, ki CDK kod organizasyonu yazısı bunu ele alır.

Peki bu, iki kampın gerçekten anlaşamadığı tek durumu, sıradan bir servise özel DynamoDB tablosunu nereye bırakır? Yaşam döngüsü testi yanıtlar. Tablo dağıtıcılarından uzun yaşıyor, gerçek bir ortamın verisini tutuyorsa, ona uzun ömürlü stack’i ve adlandırılmış sözleşmeyi verin. Ortamıyla birlikte ölen PR başına bir tabloysa, stateless katmanla birlikte tutun. State yerine yaşam döngüsünü sorduğunuzda anlaşmazlık çözülür.

Hesap sınırlarını aşmak

Buraya kadar her şey tek bir hesabı varsaydı. Başka bir hesaba geçmek farklı bir basamaktır ve seçenek eklemez, çıkarır. CloudFormation export’ları hesapları hiç aşmaz; tek bir hesap ve bölge ile sınırlıdır. Ad ile import yardımcıları (fromTableName, fromBucketName, fromEventBusName) da yalnızca aynı hesap içindir. Geriye tam olarak tek bir mekanizma kalır: ARN ile import (fromTableArn, fromEventBusArn) ve üreticide diğer hesabın girmesine izin veren bir kaynak politikası.

Buluşma noktası olan bir bus için bu politika sözleşmenin ta kendisidir:

import * as events from 'aws-cdk-lib/aws-events';
import * as iam from 'aws-cdk-lib/aws-iam';

const bus = new events.EventBus(this, 'DomainEvents', {
  eventBusName: `myapp-${props.stage}-events`,
});

// Üretici hesabı: belirli bir tüketici hesabının bus'a event göndermesine izin ver.
bus.addToResourcePolicy(new iam.PolicyStatement({
  sid: 'AllowConsumerAccountPutEvents',
  effect: iam.Effect.ALLOW,
  principals: [new iam.AccountPrincipal('222222222222')],
  actions: ['events:PutEvents'],
  resources: [bus.eventBusArn],
}));

Diğer hesaptaki tüketiciler bunun ardından EventBus.fromEventBusArn(...) ile import eder ve o politika üzerinden event gönderir. Hesaplar arası fan-out yazısı ve izole tüketici hesapları yazısı eventing tarafını kapsar. Bir kaynağı kendi hesabına koymak bu spektrumun en uç noktasıdır; yaşam döngüsüyle değil, uyumluluk veya katı bir blast radius sınırıyla haklı çıkar. Oraya gittiğinizde araçlar bir AWS Control Tower landing zone ve backup vault’lardır.

Sık yapılan hatalar

• Stateful bir kaynağın logical ID’sini değiştirmek. Logical ID, construct id’sinden ve ağaçtaki konumundan türer. Bir construct’ı yeniden adlandırmak veya taşımak onu değiştirir ve CloudFormation kaynağı yeniden oluşturur; bir tablo için bu veri kaybıdır. AWS bunu açıkça söylüyor: “Don’t change the logical ID of stateful resources,” ve “Stateful resources are more sensitive to construct renaming” der. Stateful kaynaklarda construct ID’lerini sabitleyin ve yeniden adlandırma gerçekten kaçınılmazsa eski ID’yi overrideLogicalId ile koruyun.
• RETAIN sahipsizlik tuzağı. RETAIN ile sahipsiz kalan bir kaynak, stack’i silindikten sonra fiziksel adını korur, dolayısıyla o stack’i yeniden dağıtmak bir ad çakışmasıyla başarısız olur. Stateful stack’leri gelişigüzel yok etmeyin; mecbursanız önce sahipsiz kaynağı silin veya yeniden adlandırın ya da cdk import ile yeniden sahiplenin.
• Hesapları export’larla aşmak. Export’lar hesap ve bölge kapsamlıdır ve fromXxxName yalnızca aynı hesap içindir. Bunun yerine ARN import artı bir kaynak politikası kullanın.
• Retain policy olmadan ayırmak. Removal policy’si olmayan ayrı bir stack, stack silindiğinde verisini yine de siler; sınır tek başına hiçbir şeyi korumaz.
• Önizleme ortamı başına bir cluster. RDS ve OpenSearch saatlik ücretlendirir ve yavaş provision edilir, dolayısıyla PR başına bir örnek pahalı ve yavaştır. Tek bir örneği adla paylaşın ve veri düzeyinde izole edin.
• Stage içermeyen fiziksel adlar. Yalın bir users, ortamlar arasında çakışır. Her fiziksel ada stage’i ekleyin: myapp-${stage}-users.
• Ayırmanın bağımsız dağıtım getirdiğini varsaymak. Tek bir CDK uygulamasındaki stack’ler birlikte dağıtılır; bağımsız kadans bir uygulama veya pipeline kararıdır, bir stack bölmesi değil.

Temel çıkarımlar

Varsayılan, çoğu serverless ağırlıklı CDK uygulaması için geçerlidir. Bir kaynak, ister veri kaybı riski taşıdığı için ister her domain’in erişmesi gereken bir buluşma noktası olduğu için olsun, uzun ömürlü stack’i ve bilinen adı hak eder. Ucuz, hızlı kaynaklar için bu ad stage bazlı bir fiziksel addır; pahalı, paylaşılan kaynaklar için tek bir örneği gösteren bir SSM parametre yoludur. Yaşam döngüsü testi Hayır dediğinde, koruma zaten termination protection ve retain policy’lerden geldiğinde veya PR başına bir kaynak ortamıyla birlikte öldüğünde kaynakları birlikte tutun. Ayrı bir hesaba yalnızca uyumluluk veya katı bir blast radius sınırı için tırmanın. Hemen işe yarayan tek eylem: stack sınırları hakkında bir şey kararlaştırmadan önce, bugün her stateful kaynağa terminationProtection ve açık bir RemovalPolicy ayarlayın. Sınır bir tasarım seçimidir; retain policy ise güvenlik ağıdır.

Kaynaklar

• AWS CDK Best Practices - “Ayırmadıkça birlikte tut” temeli, ayrı stateful stack istisnası, “use generated resource names, not physical names” ve stateful kaynaklar için logical ID kuralı.
• AWS CDK Developer Guide: Resources - Fiziksel adlar, mevcut kaynakları fromXxxName (aynı hesap) ve fromXxxArn (hesaplar arası) ile import etme, proxy semantiği, grant metotları ve removal policy’ler.
• enum RemovalPolicy (AWS CDK API v2) - RETAIN, RETAIN_ON_UPDATE_OR_DELETE, DESTROY ve SNAPSHOT semantiği.
• AWS CDK: Systems Manager Parameter Store’dan değer alma - valueForStringParameter (dağıtım anı token’ı) ile valueFromLookup (synth anı, cdk.context.json içinde önbelleklenir) karşılaştırması.
• Adam Ruka: CDK tips #3, cross-stack referansların kilidini açma - Export güncelleme kilidi ve bir referansı temiz koparmak için iki adımlı exportValue yöntemi.
• Yan Cui: stateful ve stateless kaynakları birlikte tutun - Monolit stack karşı argümanı, 46,4/46,4/55 sn dağıtım ölçümü, “it just moves the target” ve CDK dağıtım birimi güncellemesi.
• Yan Cui: geçici ortamlarda serverful kaynaklar - Tek paylaşılan RDS cluster’ı, ortam başına tablo/veritabanı, SSM ARN sözleşmesi ve ssmStage fallback deseni.
• Gerhard Flothow: CDK’da stateful ve stateless kaynakları ayrı stack’lerde tutmak - Ayırmayı savunan bağımsız bir ses; sahipsizlik ve yeniden sahiplenme sorunları, ad çakışmaları, termination protection ve zorunlu cdk diff.
• amazon-eventbridge-resource-policy-samples - Buluşma noktası ve hesaplar arası basamak için adlandırılmış bus ve kaynak politikası desenleri.
• AWS CloudFormation: stack output export’ları - Export’lar tek bir hesap ve bölge kapsamlıdır; export güncelleme kilidi.
• AWS CloudFormation: DeletionPolicy - RemovalPolicy’nin arkasındaki Retain semantiği.
• AWS CloudFormation: UpdateReplacePolicy - Yer değiştirmede tutma, stateful veriyi korumanın diğer yarısı.
• aws-cdk-rfcs#52: mevcut kaynakları import etme ve sahiplenme - Sahipsiz bir kaynağı bir stack’e yeniden sahiplendirmenin neden zor olduğuna dair arka plan.
• Gruntwork: Terraform state nasıl yönetilir - State’i blast radius ve değişim hızına göre bölmenin ekosistemler arası paraleli.