Amazon SAA-C03: Zarządzanie, operacje, obserwowalność i koszty — Przewodnik do nauki

By Laurynas Brazys · 18 July 2026 · #amazon #saa-c03 #certification #exam-prep #study-guide

Część AWS SAA-C03 — Kompletny przewodnik do nauki. Ćwicz ze zweryfikowanymi odpowiedziami w centrum egzaminów Amazon, albo rozwiąż testy na czas na ExamRoll.io.

CloudWatch: Metryki, przestrzenie nazw, panele kontrolne i alarmy

CloudWatch jest domyślną płaszczyzną telemetryczną dla usług AWS, ale jej użyteczność zależy całkowicie od wiedzy, do której przestrzeni nazw dana usługa publikuje swoje dane. Przestrzeń nazw to kontener na metryki, który zapobiega kolizjom między usługami — AWS/Lambda przechowuje Invocations, Errors i Throttles dla funkcji, podczas gdy AWS/Events przechowuje Invocations, FailedInvocations, TriggeredRules i MatchedEvents dla reguł EventBridge. To rozróżnienie ma znaczenie podczas diagnozowania potoków sterowanych zdarzeniami. Jeśli reguła EventBridge wywołuje API strony trzeciej poprzez cel API (API destination) i żaden ruch nie dociera do dalszych etapów, odpowiedzi nie należy szukać w AWS/Lambda, lecz w AWS/Events. Sprawdzenie TriggeredRules powie Ci, czy wzorzec reguły faktycznie został dopasowany, a Invocations/FailedInvocations poinformują, czy sam cel został wywołany i czy wywołanie się powiodło. Szukanie w metrykach Lambda, ponieważ jest to bardziej znana usługa, pomija fakt, że reguła mogła nigdy nie dopasować przychodzącego zdarzenia.

Rozdzielczość metryk to ustawienie per zasób, które ma implikacje kosztowe. Podstawowy monitoring emituje metryki co pięć minut bez dodatkowych opłat, co jest wystarczające dla długo działających obciążeń o stałym stanie, ale jest zbyt rzadkie dla reakcji autoskalowania, wykrywania skoków czy obliczeń SLO, które wymagają rozdzielczości co minutę. Szczegółowy monitoring skraca ten czas do jednej minuty (a dla niestandardowych metryk o wysokiej rozdzielczości nawet do jednej sekundy), co jest opcją, którą włączasz, gdy grupy skalowania muszą reagować szybko. Jest to funkcja płatna — dlatego nie jest włączona domyślnie.

Każda usługa natywnie emituje domyślny zestaw metryk, ale hypervisor nie widzi, co dzieje się wewnątrz systemu operacyjnego gościa. CPUUtilization, NetworkIn i DiskReadOps są widoczne dla EC2 bez żadnego wysiłku; wykorzystanie pamięci i procentowe wykorzystanie systemu plików wymagają agenta CloudWatch, co jest jedynym sposobem na ich uzyskanie. Niestandardowe metryki aplikacji również trafiają do systemu za pośrednictwem agenta lub przez PutMetricData.

Alarmy powinny odróżniać sygnał od szumu. Pojedynczy alarm na CPU > 50% uruchamia się ciągle podczas normalnych, krótkotrwałych wzrostów obciążenia i uczy operatorów, by go ignorować. Alarmy złożone łączą stany alarmów podrzędnych za pomocą wyrażenia z regułą logiczną, dzięki czemu operatorzy są powiadamiani tylko wtedy, gdy zachodzi stan faktycznie wymagający działania. Dla obciążenia, w którym przejściowe skoki CPU są niegroźne, ale utrzymujące się obciążenie CPU w połączeniu z podwyższoną liczbą operacji odczytu dysku (IOPS) wskazuje na realny problem:

HighCPUAlarm:
  MetricName: CPUUtilization
  Threshold: 50
  EvaluationPeriods: 3
  Period: 60
  ComparisonOperator: GreaterThanThreshold

HighDiskReadAlarm:
  MetricName: DiskReadOps
  Threshold: 1000
  EvaluationPeriods: 3
  Period: 60

CompositeAlarm:
  AlarmRule: >
    ALARM("HighCPUAlarm") AND ALARM("HighDiskReadAlarm")
  AlarmActions:
    - arn:aws:sns:us-east-1:111122223333:ops-pager

Alarmy podrzędne mogą nadal przechodzić wewnętrznie w stan ALARM, ale tylko alarm złożony wyzwala SNS. Dwa niezależne alarmy, oba powiadamiające dyżurnego, odtwarzają problem szumu; pojedynczy alarm z wyższym progiem nie uwzględni tej korelacji.

Panele kontrolne (dashboards) agregują widżety metryk, widżety logów i tekst. Istnieją dwa wzorce udostępniania, a ich mylenie jest częstą pułapką. Jeśli odbiorca ma już konto AWS, nadaj mu tożsamość IAM (lub rolę poprzez obserwację międzykontową) z uprawnieniami cloudwatch:GetDashboard i cloudwatch:GetMetricData. Jeśli odbiorca nie ma konta AWS — np. product manager, interesariusz ze strony klienta — użyj wbudowanej funkcji udostępniania paneli, która generuje link do udostępniania chroniony pojedynczym adresem e-mail/hasłem, pulą użytkowników Cognito lub publicznym adresem URL (co rzadko jest właściwe). Wysyłanie zrzutów ekranu e-mailem to nie obserwowalność, a tworzenie użytkownika IAM z dostępem do konsoli dla osoby spoza AWS nie jest zgodne z zasadą najmniejszych uprawnień.

Obserwowalność międzykontowa z OAM

Przeskakiwanie między dziesiątkami kont w celu przeglądania metryk jest nie do utrzymania. Obserwowalność międzykontowa CloudWatch wyznacza konto monitorujące jako centralne ujście oraz dowolną liczbę kont źródłowych, które udostępniają mu metryki, logi i ślady (traces) za pośrednictwem zasobów ujścia (sink) i łącza (link). Najszybszym sposobem wdrożenia na dużą skalę jest otwarcie konsoli CloudWatch na koncie monitorującym, utworzenie ujścia (sink) i wdrożenie wygenerowanego szablonu CloudFormation StackSet w całej organizacji, aby utworzyć zasoby AWS::Oam::Link na każdym koncie źródłowym:

Resources:
  ObservabilityLink:
    Type: AWS::Oam::Link
    Properties:
      LabelTemplate: "$AccountName"
      ResourceTypes:
        - AWS::CloudWatch::Metric
        - AWS::Logs::LogGroup
        - AWS::XRay::Trace
      SinkIdentifier: arn:aws:oam:us-east-1:111122223333:sink/abc-123

Rozwiązanie tego problemu za pomocą ról IAM między kontami i ręcznych zapytań jest technicznie możliwe, ale nie zapewnia zjednoczonych paneli kontrolnych, zapytań Metrics Insights obejmujących wiele kont ani automatycznego wzbogacania o etykiety z nazwami kont, które oferują łącza OAM.

Container Insights i śledzenie rozproszone

Dla obciążeń skonteneryzowanych, Container Insights jest kanoniczną funkcją CloudWatch. Na EKS wdraża ona agenta CloudWatch (lub kolektor ADOT) jako DaemonSet oraz Fluent Bit do przekazywania logów. Agent zbiera metryki z cAdvisor i kubelet i emituje je do przestrzeni nazw ECS/ContainerInsights i ContainerInsights (CPU/pamięć per pod, węzeł, przestrzeń nazw i klaster), podczas gdy Fluent Bit przesyła stdout/stderr do grup logów, takich jak /aws/containerinsights/<cluster>/application, /dataplane i /host. Tworzenie własnego stosu Prometheus/Grafana jest możliwe; zarządzany wzorzec to Container Insights plus Logs Insights:

fields @timestamp, kubernetes.pod_name, log
| filter kubernetes.namespace_name = "payments"
| filter log like /ERROR/
| stats count() by kubernetes.pod_name

Metryki mówią, że coś działa wolno; ślady (traces) mówią gdzie. X-Ray instrumentuje każdą usługę na ścieżce żądania, propagując identyfikator śledzenia (trace ID) za pomocą nagłówka X-Amzn-Trace-Id i emitując segmenty oraz subsegmenty do demona X-Ray lub kolektora ADOT. Mapa usług wizualizuje węzły i krawędzie z procentowymi wartościami opóźnień, błędów i awarii. Bez X-Ray, skok p99 pojawia się jako metryka w CloudWatch bez przypisania przyczyny.

from aws_xray_sdk.core import xray_recorder, patch_all
patch_all()  # instruments boto3, requests, sqlalchemy, etc.

@xray_recorder.capture('checkout')
def checkout(order_id): ...

Container Insights plus X-Ray plus CloudWatch Logs to trzy filary obserwowalności mikrousług.

Trzy strumienie logów: CloudTrail, VPC Flow Logs, CloudWatch Logs

Każda strategia obserwowalności w AWS rozdziela trzy odrębne strumienie logów: aktywność API płaszczyzny zarządzania (CloudTrail), aktywność sieciową płaszczyzny danych (VPC Flow Logs) oraz dane wyjściowe aplikacji/systemu operacyjnego (CloudWatch Logs). Każdy z nich odpowiada na inne pytanie z zakresu informatyki śledczej, a ich mylenie jest częstym błędem projektowym.

CloudTrail rejestruje każde wywołanie API AWS — kto je wywołał (userIdentity), z jakiego adresu IP, na jakim zasobie, z jakimi parametrami i czy zakończyło się powodzeniem. Jest to jedyna usługa, która w wiarygodny sposób powiązuje zmianę z konkretnym podmiotem IAM (principal). Częstym nieporozumieniem jest przekonanie, że CloudWatch Logs to właściwe miejsce do szukania aktywności API; CloudWatch Logs przechwytuje dane wyjściowe aplikacji/systemu, a nie dane audytowe na poziomie podmiotu. CloudTrail może dostarczać swoje zdarzenia do CloudWatch Logs w celu filtrowania metryk w czasie rzeczywistym, ale źródłowy rekord audytowy pochodzi z CloudTrail.

W środowisku AWS Organizations prawidłowym wzorcem jest ślad organizacyjny (organization trail) utworzony z konta zarządzającego (lub konta delegowanego administratora), który automatycznie rejestruje nowe konta członkowskie i przesyła strumieniowo zdarzenia do jednego zasobnika S3 na dedykowanym koncie do archiwizacji logów:

CentralTrail:
  Type: AWS::CloudTrail::Trail
  Properties:
    IsOrganizationTrail: true
    IsMultiRegionTrail: true
    IncludeGlobalServiceEvents: true
    EnableLogFileValidation: true       # SHA-256 digest chain
    S3BucketName: org-cloudtrail-logs
    KMSKeyId: !Ref TrailKmsKey

Docelowy zasobnik (bucket) wymaga włączonego wersjonowania, polityki zasobnika ograniczającej s3:PutObject do podmiotu usługi (service principal) CloudTrail, szyfrowania SSE-KMS, dostępu tylko do odczytu między kontami dla audytorów i, idealnie, S3 Object Lock w trybie zgodności (compliance mode) dla gwarancji WORM. Walidacja plików z logami tworzy podpisane pliki skrótu (digest files), dzięki czemu manipulacje są wykrywalne. Zdarzenia zarządzania (Management events) są domyślnie włączone na 90 dni; przechowywanie ich dłużej wymaga utworzenia śladu (trail). Zdarzenia danych (Data events) (na poziomie obiektów S3, wywołania Lambda, na poziomie elementów DynamoDB) są opcjonalne (opt-in) ze względu na ich objętość i koszt. Do doraźnych zapytań historycznych, CloudTrail Lake lub Athena na zasobniku ze śladem pozwalają na uruchamianie zapytań SQL:

SELECT userIdentity.arn, eventTime, requestParameters
FROM cloudtrail_logs
WHERE eventName = 'AuthorizeSecurityGroupIngress'
  AND eventTime BETWEEN '2024-01-08' AND '2024-01-12';

VPC Flow Logs przechwytują metadane o ruchu IP — 5-krotkę, bajty, pakiety, akcję (ACCEPT/REJECT) i status logowania — dla VPC, podsieci lub ENI. Nie przechwytują one zawartości pakietów (payloads). Cele dostarczania to CloudWatch Logs, S3 lub Kinesis Data Firehose. Wybierz S3 w celu archiwizacji; wybierz CloudWatch Logs, gdy potrzebujesz filtrów metryk do uruchamiania alarmów w oparciu o podejrzane wzorce ruchu; wybierz Firehose, gdy wymaganiem jest analityka w czasie zbliżonym do rzeczywistego. Kanoniczny potok (pipeline) do przetwarzania w czasie zbliżonym do rzeczywistego dla VPC z NLB, ASG i bazami danych:

ENIs → VPC Flow Logs (delivery: Kinesis Data Firehose)
      → Firehose delivery stream (optional Lambda transform)
      → Amazon OpenSearch Service (index: vpc-flow-*)
      → OpenSearch Dashboards

Alternatywna ścieżka CloudWatch Logs → filtr subskrypcji → Firehose → OpenSearch również działa, ale dodaje dodatkowy krok i koszt. S3 jest niewłaściwym wyborem, gdy wymaganiem jest “czas zbliżony do rzeczywistego”. Brak włączenia Flow Logs jest najbardziej szkodliwą pułapką: gdy dochodzi do incydentu bezpieczeństwa, nie ma żadnego zapisu o źródle/celu/porcie ani informacji o ACCEPT vs REJECT. Ta sama logika dotyczy logów dostępowych ALB — są opcjonalne, dostarczane do S3, a bez nich nie ma zapisu na poziomie żądania zawierającego adresy IP klientów, kody odpowiedzi, opóźnienia docelowe czy user-agenty. Razem, Flow Logs (L3/L4) i logi dostępowe ALB (L7) stanowią podstawę analizy śledczej ruchu sieciowego.

CloudWatch Logs odbiera logi z aplikacji, Lambda i systemu operacyjnego za pośrednictwem agenta CloudWatch. Jego siła tkwi w filtrach metryk: wyrażeniach wzorcowych, które skanują przychodzące zdarzenia i inkrementują niestandardową metrykę w przypadku dopasowania, co następnie wyzwala alarm:

# Metric filter detecting inbound SSH sessions from Flow Logs
[version, account, eni, source, dest, srcport, destport=22,
 protocol=6, packets, bytes, start, end, action=ACCEPT, status]

Równoległy filtr na porcie 3389 obejmuje RDP. Przyjmowanie logów bez alertów pozwala na analizę poincydentalną, a nie na prewencję.

W przypadku dużych flot standardem jest rozsyłanie logów (fan-out) do potoku przetwarzania za pomocą filtra subskrypcji w grupie logów, przesyłając strumieniowo pasujące zdarzenia do Kinesis Data Stream, Firehose lub Lambda w czasie zbliżonym do rzeczywistego:

{
  "filterPattern": "",
  "destinationArn": "arn:aws:firehose:us-east-1:111122223333:deliverystream/logs-to-os"
}

Pułapką jest wysyłanie surowych logów do przechowywania bez potoku przetwarzania: zrzucanie do S3 bez katalogu Glue, bez indeksu OpenSearch i bez grupy roboczej Athena oznacza, że logi istnieją, ale nie można na nich działać podczas incydentu. Obserwowalność wymaga powierzchni zapytań, a nie tylko trwałych bajtów. Grupy logów wymagają również jawnych polityk retencji — domyślnie jest to “nigdy nie wygasają”, co po cichu przepala pieniądze — i mogą być eksportowane do S3 w celu długoterminowej archiwizacji zgodnie z regułami cyklu życia (lifecycle rules).

Wykrywanie zdarzeń na poziomie API z najniższym narzutem

Dla zdarzeń płaszczyzny sterowania o wysokiej wartości — CreateImage, AuthorizeSecurityGroupIngress, StopLogging, ConsoleLogin bez MFA — wzorcem o najniższym narzucie jest CloudTrail → reguła EventBridge → SNS. EventBridge natywnie odbiera każde zdarzenie zarządzania CloudTrail, a reguła z wzorcem zdarzenia nie wymaga żadnego kodu “klejącego” w Lambda:

{
  "source": ["aws.ec2"],
  "detail-type": ["AWS API Call via CloudTrail"],
  "detail": {
    "eventSource": ["ec2.amazonaws.com"],
    "eventName": ["CreateImage"]
  }
}

Wysyłanie CloudTrail do CloudWatch Logs i stosowanie filtra metryk również działa, ale dodaje grupę logów, filtr, alarm i koszt, więc przegrywa pod względem narzutu operacyjnego, gdy wymaganiem jest po prostu “zaalarmuj o API X”.

AWS Config: Ciągłe monitorowanie konfiguracji i dryfu

Config i CloudTrail są często mylone, ale odpowiadają na fundamentalnie różne pytania. CloudTrail rejestruje, kto co wywołał; Config rejestruje, jak zasób wygląda teraz i jak zmieniał się w czasie. Oczekiwanie, że Config będzie logował wywołania API, to klasyczna błędna odpowiedź — Config nie wie, że użytkownik wywołał PutBucketAcl; wie, że o 14:03:22 ACL bucketu zmienił się ze stanu A do stanu B. Aby zidentyfikować podmiot (principal), skoreluj zapis zmiany z Config ze zdarzeniem CloudTrail o tym samym znaczniku czasu (Config udostępnia w konsoli bezpośredni link do niego).

Reguły Config (Config rules) oceniają zasoby pod kątem pożądanego stanu. Zarządzane reguły (managed rules) obejmują typowe sprawdzenia (restricted-ssh, s3-bucket-public-read-prohibited, required-tags, ec2-instance-no-public-ip, s3-bucket-versioning-enabled, desired-instance-type), a niestandardowe reguły (custom rules) działają jako funkcje Lambda lub używają CloudFormation Guard. Reguły dokonują oceny przy zmianie konfiguracji oraz zgodnie z harmonogramem, oznaczają zasoby jako COMPLIANT lub NON_COMPLIANT i mogą wyzwalać automatyczną naprawę (remediation) za pomocą dokumentów SSM Automation. To jest odpowiedź o niskim narzucie operacyjnym na problemy typu „wykryj otwarte SSH” lub „wykryj instancje o zbyt dużym typie” — reguły już istnieją i integrują się natywnie z SNS i Security Hub. Proponowanie okresowych audytów manualnych, zaplanowanych skanów lub własnoręcznie tworzonych skanerów wymaga budowy i utrzymania kodu, który Config dostarcza w standardzie.

Config publikuje wyniki oceny w SNS. Aby zautomatyzować naprawę, podłącz regułę EventBridge do zdarzenia zmiany zgodności i wywołaj dokument SSM Automation lub funkcję Lambda:

{
  "source": ["aws.config"],
  "detail-type": ["Config Rules Compliance Change"],
  "detail": {
    "configRuleName": ["restricted-ssh"],
    "newEvaluationResult": { "complianceType": ["NON_COMPLIANT"] }
  }
}

Agregatory (Aggregators) konsolidują stan zgodności w całej organizacji; pakiety zgodności (conformance packs) grupują reguły dla frameworków takich jak PCI-DSS czy HIPAA. Workload Discovery on AWS (wcześniej AWS Perspective) to rozwiązanie oparte na Config, które wizualizuje relacje między zasobami i generuje diagramy architektury — to kanoniczna odpowiedź, gdy pytanie dotyczy narzędzia do inwentaryzacji, które potrafi stworzyć diagram istniejącego środowiska. Config jest warunkiem wstępnym.

Security Hub, GuardDuty i Control Tower

Security Hub to płaszczyzna agregacji dla wyników (findings) dotyczących bezpieczeństwa. Pobiera dane z GuardDuty (wykrywanie zagrożeń na podstawie VPC Flow Logs, DNS i CloudTrail), Inspector (wyniki skanowania podatności), Macie, IAM Access Analyzer i Config, a następnie normalizuje wszystko do formatu AWS Security Finding Format (ASFF). Włączenie Security Hub aktywuje również standardy bezpieczeństwa, w szczególności standard AWS Foundational Security Best Practices (FSBP) — dziesiątki automatycznych kontroli (MFA dla konta root, publiczne S3, niezaszyfrowane EBS, wieloregionowy CloudTrail) mapowanych wewnętrznie na reguły Config.

W skali organizacji, wyznacz konto delegowanego administratora (delegated administrator account) dla Security Hub (oraz dla GuardDuty i Config), włącz usługę i standard FSBP dla całej organizacji za pomocą opcji automatycznego włączania dla nowych kont („auto-enable new accounts”) i przekieruj wyniki przez EventBridge do SNS, dopasowując zdarzenia Security Hub Findings - Imported filtrowane po ARN standardu FSBP z Compliance.Status = FAILED. Tworzenie własnych funkcji Lambda do parsowania CloudTrail lub paneli (dashboardów) dla każdego konta z osobna dodaje obciążenia operacyjnego, które Security Hub już eliminuje.

Kluczowe rozróżnienie koncepcyjne: Security Hub ma charakter detekcyjny i agregujący, a nie prewencyjny. Zapobieganie dryfowi to zadanie AWS Control Tower, który zarządza (orkiestruje) dobrze zaprojektowaną, wielokontową strefą docelową (landing zone). Account Factory provisionuje nowe konta z bazową konfiguracją sieci, logowania i IAM. Ład organizacyjny (governance) jest wyrażany poprzez bariery ochronne (guardrails) w trzech rodzajach:

Kontrole proaktywne oceniają szablony CloudFormation przed wdrożeniem stosu i odmawiają utworzenia na przykład niezaszyfrowanej instancji RDS. Security Hub poinformowałby Cię o istnieniu niezaszyfrowanej instancji dopiero po jej uruchomieniu. Jeśli wymaganie mówi „zapobiegaj”, myśl o Control Tower. Jeśli mówi „wykrywaj, powiadamiaj lub agreguj”, myśl o Security Hub lub Config.

Macie: Wykrywanie danych wrażliwych

Macie używa uczenia maszynowego (ML) i dopasowywania wzorców do identyfikacji danych wrażliwych — PII, danych finansowych, poświadczeń — wewnątrz obiektów S3. Krytyczną pułapką jest założenie, że Macie chroni dane. Tak nie jest. Macie odkrywa i raportuje. Prawidłowe użycie:

1. Włącz Macie na docelowym koncie/w regionie.
2. Skonfiguruj zadanie wykrywania danych wrażliwych (sensitive data discovery job), celując w buckety/prefiksy/tagi zgodnie z harmonogramem.
3. Przekieruj wyniki przez EventBridge (source: aws.macie) do SNS w celu powiadomień, do Lambda w celu naprawy (kwarantanna, zacieśnienie polityki bucketu) lub do Security Hub.

{
  "source": ["aws.macie"],
  "detail-type": ["Macie Finding"],
  "detail": { "severity": { "description": ["High"] } }
}

Bez zadania wykrywania, Macie niczego nie generuje. Bez połączenia EventBridge → SNS, wyniki pozostają niezauważone w konsoli Macie.

Organizations, SCP i Polityki Tagów

AWS Organizations udostępnia trzy istotne w tym kontekście typy polityk. Polityki tagów (Tag policies) definiują dozwolone klucze tagów, wielkość liter i wartości — raportują one niezgodności i, w połączeniu z warunkami aws:ResourceTag/aws:RequestTag, mogą być egzekwowane. Polityki kontroli usług (Service Control Policies, SCPs) definiują maksymalne uprawnienia dostępne dla podmiotów (principals) na kontach członkowskich. Zestaw uzupełniają polityki kopii zapasowych (Backup policies) oraz polityki rezygnacji z AI (AI opt-out policies).

Kluczowy model myślowy: SCP nigdy nie nadają uprawnień. Są one filtrem nakładanym na to, na co w innym przypadku mógłby zezwolić IAM (polityki tożsamości, polityki zasobów, granice uprawnień). Podmiot musi mieć w IAM zezwolenie Allow oraz SCP nie może jawnie zabronić (Deny) tej akcji (lub musi zawierać ją na swojej liście Allow). Stwierdzenie „wystarczy dołączyć SCP” nigdy nie jest kompletną odpowiedzią na pytanie o uprawnienia — bez zezwolenia Allow w IAM, podmiot domyślnie nie ma dostępu, niezależnie od zawartości SCP.

Aby wymagać tagów podczas tworzenia zasobów, należy połączyć polityki tagów z SCP, takim jak:

{
  "Effect": "Deny",
  "Action": ["ec2:RunInstances", "rds:CreateDBInstance"],
  "Resource": "*",
  "Condition": {
    "Null": { "aws:RequestTag/CostCenter": "true" }
  }
}

Polityka tagów deklaruje schemat; SCP odmawia utworzenia zasobu bez wymaganego tagu; polityka IAM nadaje uprawnienie do tworzenia. Wszystkie trzy elementy są niezbędne. Reguła required-tags w AWS Config wykrywa i naprawia istniejące zasoby, które nie spełniają wymagań.

Systems Manager Automation i Patchowanie

Systems Manager (SSM) to operacyjny kręgosłup dla działań związanych z cyklem życia flot instancji EC2 i węzłów hybrydowych. W kontekście patchowania najważniejsze są dwie konstrukcje: dokumenty Automation (deklaratywne runbooki w formacie YAML/JSON, które wywołują API AWS lub skrypty) oraz okna konserwacyjne (Maintenance Windows) (które planują uruchomienie tych runbooków na celach zdefiniowanych przez tagi lub grupy zasobów, w ramach okna zmian z określonymi progami współbieżności i błędów).

Kanoniczny przepływ patchowania to AWS-RunPatchBaseline (dokument typu Command) wykonywany na instancjach wybranych za pomocą tagu Patch Group, przy użyciu Patch Baseline, który definiuje reguły zatwierdzania dla każdego systemu operacyjnego. W przypadku instancji znajdujących się za load balancerem, bezpośrednie uruchomienie AWS-RunPatchBaseline zrywa połączenia w trakcie patchowania, ponieważ instancje pozostają w stanie InService w grupie docelowej. Prawidłowym wzorcem jest AWSEC2-PatchLoadBalancerInstance, który:

1. Wyrejestrowuje instancję z jej grupy docelowej CLB lub ALB.
2. Czeka na zakończenie istniejących połączeń (connection draining) / opóźnienie wyrejestrowania.
3. Uruchamia kroki skanowania i instalacji zdefiniowane w patch baseline.
4. Uruchamia ponownie instancję, jeśli wymaga tego patch baseline.
5. Ponownie rejestruje instancję i czeka, aż jej stan w grupie docelowej powróci do healthy.

Dwa warunki wstępne powodują błędy typu „produces errors”. Po pierwsze, rola IAM przekazana jako AutomationAssumeRole musi zawierać uprawnienia elasticloadbalancing:DeregisterTargets, RegisterTargets i DescribeTargetHealth oprócz standardowych uprawnień SSM do patchowania. Po drugie, instancja musi być węzłem zarządzanym (managed node) — z uruchomionym agentem SSM i profilem instancji zawierającym AmazonSSMManagedInstanceCore. Bez nich wywołania wyrejestrowania kończą się niepowodzeniem lub SSM nie jest w stanie zobaczyć instancji.

schemaVersion: '0.3'
description: Patch instance behind ALB
assumeRole: '{{ AutomationAssumeRole }}'
parameters:
  InstanceId: { type: String }
  TargetGroupArn: { type: String }
  AutomationAssumeRole: { type: String }
mainSteps:
  - name: deregister
    action: aws:executeAwsApi
    inputs:
      Service: elbv2
      Api: DeregisterTargets
      TargetGroupArn: '{{ TargetGroupArn }}'

← Bezpieczeństwo · Wszystkie domeny · Wysoka dostępność →

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

Przeglądaj Amazon →