Amazon DVA-C02: CloudFormation i infrastruktura jako kod (SAM, CDK) — Przewodnik do nauki

By Laurynas Brazys · 27 July 2026 · #amazon #dva-c02 #certification #exam-prep #study-guide

Część AWS Developer Associate DVA-C02 — Przewodnik do nauki. Ćwicz ze zweryfikowanymi odpowiedziami w centrum egzaminów Amazon, albo rozwiąż testy na czas na ExamRoll.io.

Podstawowe wzorce CloudFormation i najlepsze praktyki dotyczące szablonów

Szablony CloudFormation powinny być tworzone jako deklaratywne, idempotentne opisy zasobów, faworyzując małe, skoncentrowane stosy oraz stosy zagnieżdżone w przypadku złożonych architektur. Używaj sekcji Resources z jawnymi identyfikatorami logicznymi i preferuj funkcje wewnętrzne (intrinsic functions), takie jak !Ref, !GetAtt, !Sub, Fn::FindInMap i Fn::If, w celu kompozycji i ponownego użycia. Waliduj szablony za pomocą

undefined

lub odpowiedników w SAM/CDK (

undefined

) przed utworzeniem zestawów zmian. Używaj zestawów zmian (ChangeSets) (

undefined

) do przeglądu i unikania niespodziewanych wymian zasobów; użyj

undefined

, aby sprawdzić działania, które zostaną wykonane na stosie. Utrzymuj treść szablonu w granicach limitów CloudFormation, przenosząc duży kod inline do S3 i odwołując się do niego (

undefined

) lub dzieląc go na stosy zagnieżdżone za pomocą

undefined

. Regularnie wymuszaj wykrywanie dryfu za pomocą

undefined

. Używaj

undefined

do ochrony zasobów przechowujących dane oraz włączaj ochronę przed usunięciem (termination protection) na krytycznych stosach. Zintegruj

undefined

z potokiem CI/CD, aby wcześnie wykrywać problemy strukturalne i naruszenia polityk. W celu szybkich iteracji wykorzystuj zestawy zmian (ChangeSets) i strategie aktualizacji na poziomie zasobów, aby minimalizować promień rażenia (blast radius); w przypadku funkcji Lambda używaj wdrożeń wersjonowanych, aby uczynić aktualizacje bezpiecznymi i odwracalnymi.

Parametryzacja, mapowania, sekrety i dane wrażliwe

Parametryzuj różnice między środowiskami za pomocą parametrów (Parameters) i mapowań (Mappings) CloudFormation, używając

undefined

, aby szybko kończyć działanie w razie błędu. Unikaj osadzania sekretów lub poświadczeń w postaci zwykłego tekstu w parametrach; zamiast tego używaj

undefined

SSM Parameter Store lub Secrets Manager i odwołuj się do nich za pomocą referencji dynamicznych, takich jak

undefined

, lub używaj typów

undefined

. Oznaczaj wrażliwe parametry za pomocą

undefined

, aby maskować wartości w konsoli, ale pamiętaj, że

undefined

nie szyfruje danych w spoczynku (at rest) — używaj Secrets Manager do audytu i rotacji. Używaj mapowań (Mappings) i

undefined

dla deterministycznych, specyficznych dla środowiska wartości (np. ID obrazów AMI dla każdego regionu) oraz

undefined

do obliczania stref dostępności. Aby odwoływać się do zasobów między stosami w tym samym regionie/koncie, eksportuj wartości wyjściowe (outputs) i importuj je za pomocą

undefined

; pamiętaj, że importy nie mogą przekraczać granic kont ani regionów. Chroń tożsamości IAM używane przez CloudFormation, ograniczając role zgodnie z zasadą najmniejszych uprawnień; preferuj uprawnienia StackSet zarządzane przez usługę lub jawnie udostępnij rolę administracyjną o ograniczonym zakresie. Przekazując zmienne środowiskowe do kontenerów lub funkcji Lambda, preferuj odwoływanie się do ARN-ów Secrets Manager lub SSM Parameter, a następnie pobieranie ich w czasie wykonania w kodzie, lub używaj funkcji SAM/CDK do wstrzykiwania bezpiecznych wartości do środowiska z szyfrowaniem za pomocą KMS.

Wdrożenia międzykontowe/międzyregionalne, wzorce wielokontowe w CDK i SAM

Wdrożenia międzykontowe i międzyregionalne wymagają orkiestracji wykraczającej poza eksporty z pojedynczego stosu. W przypadku wdrożeń wielokontowych i wieloregionowych wybierz CloudFormation StackSets (

undefined

) z uprawnieniami zarządzanymi przez usługę dla Organizations lub zarządzanymi samodzielnie za pomocą roli wykonawczej (execution role) na kontach docelowych. W przypadku artefaktów kodu aplikacji używaj scentralizowanych bucketów S3 z replikacją międzykontową lub politykami bucketów, albo pozwól narzędziom publikować zasoby w każdym regionie: CDK używa stosów startowych (bootstrap stacks) i zasobów publikowanych przez

undefined

i wymaga wykonania

undefined

na każdym koncie/w każdym regionie; CDK Pipelines (moduł pipelines) lub aws-cdk CLI z opcją

undefined

wspiera promocję między kontami. SAM używa poleceń

undefined

, które przesyłają artefakty do bucketu S3; w przypadku wdrożeń wielokontowych użyj potoku CI/CD do spakowania i wypchnięcia artefaktów do bucketów na kontach docelowych i uruchamiaj wdrożenia z odpowiednimi poświadczeniami. Unikaj wyszukiwań kontekstowych CDK (context lookups, np.

undefined

), które wymagają uprawnień specyficznych dla konta w czasie syntezy (synth time); zamiast tego jawnie przekazuj identyfikatory jako parametry, aby zachować powtarzalność syntezy. Używaj AWS CodePipeline lub GitHub Actions z przyjętymi rolami (

undefined

) do przeprowadzania wdrożeń na kontach docelowych, upewniając się, że istnieją stosy startowe (bootstrap) i niezbędne role powiązane z usługą (service-linked roles). Pamiętaj, że eksporty CloudFormation mają zasięg regionalny; w przypadku dystrybucji między kontami preferuj StackSets lub wdrożenia sterowane przez potok (pipeline).

Zasoby niestandardowe, ochrona stosu i akceleratory wdrożeń lokalnych/przyrostowych

Używaj zasobów niestandardowych, gdy w CloudFormation brakuje natywnego typu zasobu, implementując dostawców opartych na Lambda, które przestrzegają protokołu odpowiedzi CloudFormation dla zdarzeń Create/Update/Delete. Twórz idempotentne handlery, odpowiadaj za pomocą cfn-response lub frameworka CloudFormation CLI i obsługuj długo działające akcje za pomocą zdarzeń postępu lub przechowując stan w DynamoDB. Pamiętaj o limitach czasu dla zasobów niestandardowych: CloudFormation ma maksymalny limit czasu operacji na stosie, a zasoby oparte na Lambda muszą zakończyć działanie w tym oknie czasowym, w przeciwnym razie spowodują wycofanie stosu (rollback). Chroń krytyczne zasoby za pomocą polityk stosu (SetStackPolicy), aby blokować zastępowanie lub aktualizacje określonych logicznych ID podczas aktualizacji stosu, i włącz ochronę przed usunięciem (termination protection) dla środowisk, na których usunięcie nie możesz sobie pozwolić. Do rozwoju przyrostowego i lokalnego używaj AWS SAM CLI (sam build, sam local invoke, sam local start-api) oraz sam sync do szybkich aktualizacji samego kodu, a także CDK watch lub cdk deploy z zasobami (assets), aby aktualizować tylko zmienione zasoby; narzędzia te obliczają hashe zasobów (lambda asset hashing), dzięki czemu tylko zmieniony kod jest ponownie publikowany. Integruj CloudFormation ChangeSets (zestawy zmian), wersjonowanie Lambda (AutoPublishAlias w SAM lub lambda.Version w CDK) oraz przenoszenie ruchu (traffic-shifting) przez CodeDeploy dla bezpiecznych wdrożeń. Częste pułapki to przekraczanie limitów szablonu lub parametrów, nieprawidłowe użycie importów międzykontowych oraz inicjalizowanie ciężkich klientów SDK wewnątrz handlerów, co powoduje opóźnienia zimnego startu (cold-start) — preferuj globalnych, leniwie inicjalizowanych klientów z konfigurowalnymi limitami czasu i mechanizmami ponawiania.

Problem praktyczny: Scenariusz użycia

Scenariusz: AcmeMedia zarządza wielokontową organizacją AWS z oddzielnymi kontami Dev, Staging i Prod w regionie us-east-1. Bezserwerowa usługa przetwarzania obrazów (Lambda + S3 + DynamoDB) musi być wdrażana spójnie na wszystkich kontach, a współdzielona wrażliwa konfiguracja ma być przechowywana centralnie.

Wyzwanie: Wdrożenie tego samego stosu CloudFormation/SAM/CDK na wielu kontach i zapewnienie, że artefakty kodu Lambda są bezpiecznie dostępne na każdym koncie docelowym, przy jednoczesnym utrzymaniu sekretów poza szablonami.

Zalecane podejście:

Użyj AWS CloudFormation StackSets z uprawnieniami zarządzanymi przez usługę (aws cloudformation create-stack-set –stack-set-name ImageProcessor –template-body file://template.yaml), a następnie aws cloudformation create-stack-instances, aby wdrożyć na docelowe konta i regiony, lub skonfiguruj CDK Pipelines do syntezowania i wdrażania na poszczególne konta z użyciem ról.
Spakuj zasoby (assets) Lambda, używając publikowania zasobów CDK (cdk bootstrap na każdym koncie/regionie) lub polecenia sam package do bucketu S3 na każdym koncie docelowym; zautomatyzuj kopiowanie zasobów przez CI (CodeBuild używając aws s3 cp lub replikacji S3) i użyj cdk deploy lub sam deploy z poświadczeniami konta docelowego.
Przechowuj wrażliwą konfigurację w AWS Secrets Manager na każdym koncie, odwołując się do niej w szablonie za pomocą referencji dynamicznych ({{resolve:secretsmanager:arn:aws:secretsmanager:us-east-1:123456789012:secret:ImageProcSecret:SecretString:apiKey}}) lub wdróż zreplikowany sekret za pomocą funkcji replikacji Secrets Manager, unikając parametrów NoEcho.
Używaj ChangeSets (zestawów zmian) (create-change-set, execute-change-set), włącz ochronę przed usunięciem (termination protection) na stosach produkcyjnych i stosuj polityki stosu, aby zapobiec przypadkowemu zastąpieniu tabel DynamoDB lub bucketów S3 podczas aktualizacji.

Uzasadnienie: StackSets i wdrożenia sterowane przez pipeline zapewniają bezpieczną, audytowalną propagację na wiele kont/regionów, podczas gdy publikowanie zasobów i sekrety per konto utrzymują poświadczenia lokalnie i w sposób audytowalny. ChangeSets, ochrona przed usunięciem i polityki stosu zmniejszają ryzyko podczas iteracyjnych wdrożeń.

← Amazon DynamoDB i projektowanie NoSQL · Wszystkie domeny · Wdrażanie i CI →

Przećwicz te pytania → · Testy na czas na ExamRoll.io →