Amazon SAA-C03: Gerenciamento, Operações, Observabilidade e Custo — Guia de estudos

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

Faz parte do AWS SAA-C03 — Guia de estudos completo. Pratique com respostas verificadas no centro de exames da Amazon, ou faça testes cronometrados no ExamRoll.io.

CloudWatch: Métricas, Namespaces, Dashboards e Alarmes

O CloudWatch é o plano de telemetria padrão para os serviços da AWS, mas sua utilidade depende inteiramente de saber em qual namespace um serviço publica. Um namespace é um contêiner para métricas que evita colisões entre serviços — AWS/Lambda contém Invocations, Errors e Throttles para funções, enquanto AWS/Events contém Invocations, FailedInvocations, TriggeredRules e MatchedEvents para regras do EventBridge. Essa distinção é importante ao diagnosticar pipelines orientados a eventos. Se uma regra do EventBridge invoca uma API de terceiros por meio de um API destination e nenhum tráfego chega downstream, a resposta não está em AWS/Lambda; está em AWS/Events. Verificar TriggeredRules informa se o padrão da regra realmente correspondeu, e Invocations/FailedInvocations informam se o alvo em si foi chamado e se a chamada foi bem-sucedida. Procurar métricas do Lambda porque o Lambda é o serviço mais familiar ignora o fato de que a regra pode nunca ter correspondido a um evento de entrada.

A resolução de métrica é uma configuração por recurso com implicações de custo. O monitoramento básico emite métricas a cada cinco minutos sem custo adicional, o que é suficiente para cargas de trabalho de longa duração em estado estacionário, mas muito pouco detalhado para reações de autoscaling, detecção de picos ou cálculos de SLO que exigem resolução por minuto. O monitoramento detalhado reduz isso para um minuto (e para um segundo para métricas personalizadas de alta resolução), que é o que você habilita quando os grupos de escalabilidade precisam reagir rapidamente. É um recurso pago — e é por isso que não está ativado por padrão.

Todo serviço emite um conjunto padrão de métricas nativamente, mas o hypervisor não consegue ver dentro do sistema operacional convidado (guest OS). CPUUtilization, NetworkIn e DiskReadOps são visíveis para o EC2 sem esforço; a utilização de memória e os percentuais de uso do sistema de arquivos exigem o agente do CloudWatch, que é a única maneira de obtê-los. Métricas de aplicação personalizadas também chegam por meio do agente ou via PutMetricData.

Os alarmes devem distinguir o sinal do ruído. Um único alarme para CPU > 50% dispara constantemente durante picos normais e treina os operadores a ignorá-lo. Alarmes compostos combinam os estados de alarmes filhos com uma expressão de regra booleana para que os operadores sejam acionados apenas quando uma condição genuinamente acionável ocorre. Para uma carga de trabalho onde picos transitórios de CPU são benignos, mas uma pressão de CPU sustentada combinada com IOPS de leitura de disco elevados indica um problema real:

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

Os alarmes filhos ainda podem transicionar para o estado ALARM internamente, mas apenas o composto aciona o SNS. Dois alarmes independentes, ambos acionando o plantão, recriam o problema do ruído; um único alarme com um limiar mais alto perde a correlação.

Dashboards agregam widgets de métricas, widgets de logs e texto. Existem dois padrões de compartilhamento e confundi-los é uma armadilha comum. Se um visualizador já tiver uma conta AWS, conceda a ele uma identidade IAM (ou uma role via observabilidade entre contas) com cloudwatch:GetDashboard e cloudwatch:GetMetricData. Se o visualizador não tiver uma conta AWS — um gerente de produto, um stakeholder do cliente — use o recurso de compartilhamento de dashboard integrado, que produz um link compartilhável protegido por um único e-mail/senha, um user pool do Cognito ou uma URL pública (raramente apropriado). Enviar screenshots por e-mail não é observabilidade, e criar um usuário IAM com acesso ao console para um visualizador que não é da AWS não é o menor privilégio.

Observabilidade Entre Contas com OAM

Pular entre dezenas de contas para visualizar métricas é insustentável. A observabilidade entre contas do CloudWatch designa uma conta de monitoramento como um sink central e um número qualquer de contas de origem que compartilham métricas, logs e traces com ela por meio de recursos de sink e link. A implementação mais rápida em escala é abrir o console do CloudWatch na conta de monitoramento, criar um sink e implantar o template de StackSet do CloudFormation gerado em toda a organização para criar recursos AWS::Oam::Link em cada conta de origem:

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

Resolver isso com roles IAM entre contas e consultas manuais é tecnicamente possível, mas não oferece dashboards unificados, consultas do Metrics Insights entre contas ou o enriquecimento automático de labels com o nome da conta que os links do OAM fornecem.

Container Insights e Rastreamento Distribuído

Para cargas de trabalho em contêineres, o Container Insights é o recurso canônico do CloudWatch. No EKS, ele implanta o agente do CloudWatch (ou o coletor ADOT) como um DaemonSet, além do Fluent Bit para encaminhamento de logs. O agente coleta métricas do cAdvisor e do kubelet e as emite para os namespaces ECS/ContainerInsights e ContainerInsights (CPU/memória por pod, nó, namespace e cluster), enquanto o Fluent Bit envia stdout/stderr para grupos de logs como /aws/containerinsights/<cluster>/application, /dataplane e /host. Montar sua própria stack de Prometheus/Grafana é possível; o padrão gerenciado é Container Insights mais Logs Insights:

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

Métricas dizem que algo está lento; rastreamentos (traces) dizem onde. O X-Ray instrumenta cada serviço no caminho da requisição, propagando um ID de rastreamento (trace ID) por meio do cabeçalho X-Amzn-Trace-Id e emitindo segmentos e subsegmentos para o daemon do X-Ray ou para o coletor ADOT. O mapa de serviço visualiza nós e arestas com percentuais de latência, erro e falha. Sem o X-Ray, um pico de p99 aparece como uma métrica do CloudWatch sem atribuição.

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, X-Ray e CloudWatch Logs formam o tripé para a observabilidade de microsserviços.

Os Três Fluxos de Log: CloudTrail, VPC Flow Logs e CloudWatch Logs

Qualquer estratégia de observabilidade na AWS separa três fluxos de log distintos: atividade da API do plano de gerenciamento (CloudTrail), atividade de rede do plano de dados (VPC Flow Logs) e saída de aplicação/SO (CloudWatch Logs). Cada um responde a uma pergunta forense diferente, e confundi-los é um erro comum de design.

CloudTrail registra cada chamada de API da AWS — quem a invocou (userIdentity), de qual IP, contra qual recurso, com quais parâmetros e se foi bem-sucedida. É o único serviço que vincula de forma confiável uma mutação a um principal do IAM específico. Um equívoco comum é pensar que o CloudWatch Logs é o lugar certo para procurar por atividade de API; o CloudWatch Logs captura a saída de aplicações/sistemas, não dados de auditoria em nível de principal. O CloudTrail pode entregar seus eventos ao CloudWatch Logs para filtragem de métricas em tempo real, mas o registro de auditoria subjacente se origina no CloudTrail.

Em um ambiente com AWS Organizations, o padrão correto é uma trilha da organização (organization trail) criada a partir da conta de gerenciamento (ou de administrador delegado), que registra automaticamente novas contas-membro e transmite os eventos para um único bucket S3 em uma conta de arquivamento de logs dedicada:

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

O bucket de destino precisa de versionamento, uma política de bucket (bucket policy) restringindo s3:PutObject ao principal de serviço (service principal) do CloudTrail, criptografia SSE-KMS, acesso somente leitura entre contas (cross-account) para auditores e, idealmente, S3 Object Lock no modo de conformidade (compliance mode) para garantias WORM (Write-Once, Read-Many). A validação de arquivos de log produz arquivos de resumo (digest) assinados para que adulterações sejam detectáveis. Eventos de gerenciamento (Management events) são ativados por padrão por 90 dias; a retenção além desse período requer uma trilha. Eventos de dados (Data events) (nível de objeto S3, invocação do Lambda, nível de item do DynamoDB) são opcionais (opt-in) devido ao volume e custo. Para consultas históricas ad-hoc, o CloudTrail Lake ou o Athena consultando o bucket da trilha permitem que você execute 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 capturam metadados sobre o tráfego IP — a 5-tupla, bytes, pacotes, ação (ACCEPT/REJECT) e status do log — para uma VPC, sub-rede ou ENI. Eles não capturam as cargas (payloads). Os destinos de entrega são CloudWatch Logs, S3 ou Kinesis Data Firehose. Escolha o S3 para arquivamento; escolha o CloudWatch Logs quando precisar de filtros de métrica para disparar alarmes sobre padrões de tráfego suspeitos; escolha o Firehose quando o requisito for análise em tempo quase real. O pipeline canônico de tempo quase real para uma VPC com NLBs, ASGs e bancos de dados:

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

O caminho alternativo CloudWatch Logs → filtro de inscrição → Firehose → OpenSearch funciona, mas adiciona um salto (hop) e custo. O S3 é a escolha errada quando o requisito é “tempo quase real”. Não habilitar os Flow Logs é a armadilha mais prejudicial: quando um incidente de segurança ocorre, não há registro de origem/destino/porta e nenhuma visibilidade de ACCEPT vs REJECT. O mesmo raciocínio se aplica aos logs de acesso do ALB (ALB access logs) — são opcionais (opt-in), entregues ao S3 e, sem eles, não há registro em nível de requisição dos IPs de cliente, códigos de resposta, latências do alvo ou user agents. Juntos, os Flow Logs (L3/L4) e os logs de acesso do ALB (L7) constituem a linha de base para a análise forense de tráfego.

CloudWatch Logs recebe logs de aplicações, do Lambda e do SO através do agente do CloudWatch. Seu poder vem dos filtros de métrica (metric filters): expressões de padrão que examinam os eventos recebidos e incrementam uma métrica personalizada ao encontrar uma correspondência, o que então aciona um alarme:

# 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]

Um filtro paralelo na porta 3389 cobre o RDP. A ingestão de logs sem alertas produz análise forense pós-incidente, não prevenção.

Para grandes frotas de recursos, o padrão é distribuir os logs para um pipeline de processamento através de um filtro de inscrição (subscription filter) em um grupo de logs, transmitindo eventos correspondentes para um Kinesis Data Stream, Firehose ou Lambda em tempo quase real:

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

A armadilha é enviar logs brutos para o armazenamento sem um pipeline de processamento: despejar no S3 sem um catálogo do Glue, sem um índice do OpenSearch e sem um workgroup do Athena significa que os logs existem, mas não é possível tomar ações com base neles durante um incidente. Observabilidade requer uma superfície de consulta, não apenas bytes duráveis. Os grupos de logs também precisam de políticas de retenção (retention policies) explícitas — o padrão é “nunca expirar”, o que consome dinheiro silenciosamente — e podem ser exportados para o S3 para arquivamento de longo prazo sob regras de ciclo de vida (lifecycle rules).

Detecção de Eventos em Nível de API com a Menor Sobrecarga

Para eventos de alto valor do plano de controle — CreateImage, AuthorizeSecurityGroupIngress, StopLogging, ConsoleLogin sem MFA — o padrão com a menor sobrecarga (overhead) é CloudTrail → regra do EventBridge → SNS. O EventBridge recebe nativamente todos os eventos de gerenciamento do CloudTrail, e uma regra com um padrão de evento (event pattern) não precisa de código de cola (glue) Lambda:

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

Enviar o CloudTrail para o CloudWatch Logs e aplicar um filtro de métrica também funciona, mas adiciona um grupo de logs, filtro, alarme e custo, então perde em sobrecarga operacional quando o requisito é simplesmente “alertar sobre a API X”.

AWS Config: Configuração Contínua e Desvio (Drift)

O Config e o CloudTrail são frequentemente confundidos, mas respondem a perguntas fundamentalmente diferentes. O CloudTrail registra quem chamou o quê; o Config registra qual é a aparência do recurso agora e como ele mudou ao longo do tempo. Esperar que o Config registre chamadas de API é uma resposta clássica errada — o Config não sabe que um usuário invocou PutBucketAcl; ele sabe que às 14:03:22 a ACL do bucket mudou do estado A para o estado B. Para identificar o principal (principal), correlacione o registro de alteração do Config com o evento do CloudTrail no mesmo timestamp (o Config cria um link direto para ele no console).

Regras do Config (Config rules) avaliam os recursos em relação a um estado desejado. As regras gerenciadas (managed rules) cobrem verificações comuns (restricted-ssh, s3-bucket-public-read-prohibited, required-tags, ec2-instance-no-public-ip, s3-bucket-versioning-enabled, desired-instance-type), e as regras personalizadas (custom rules) são executadas como funções Lambda ou usam o CloudFormation Guard. As regras são avaliadas em cada alteração de configuração e de forma agendada, marcam os recursos como COMPLIANT ou NON_COMPLIANT e podem acionar remediação automática por meio de documentos do SSM Automation. Esta é a resposta de baixo custo operacional para “detectar SSH aberto” ou “detectar tipos de instância superdimensionados” — as regras já existem e se integram nativamente com o SNS e o Security Hub. Propor auditorias manuais periódicas, varreduras agendadas ou scanners desenvolvidos internamente exige que você crie e mantenha um código que o Config já oferece.

O Config publica os resultados da avaliação no SNS. Para automatizar a remediação, conecte uma regra do EventBridge ao evento de mudança de conformidade e invoque um documento do SSM Automation ou uma função Lambda:

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

Agregadores (Aggregators) consolidam a conformidade em toda uma organização; pacotes de conformidade (conformance packs) agrupam regras para frameworks como PCI-DSS ou HIPAA. O Workload Discovery on AWS (anteriormente AWS Perspective) é uma solução construída sobre o Config que visualiza os relacionamentos entre recursos e gera diagramas de arquitetura — a resposta canônica quando uma questão pede por uma ferramenta de inventário que possa diagramar um ambiente existente. O Config é um pré-requisito.

Security Hub, GuardDuty e Control Tower

O Security Hub é o plano de agregação para os achados de segurança (findings). Ele ingere dados do GuardDuty (detecção de ameaças com base em VPC Flow Logs, DNS e CloudTrail), Inspector (achados de vulnerabilidade), Macie, IAM Access Analyzer e Config, e então normaliza tudo para o formato AWS Security Finding Format (ASFF). Habilitar o Security Hub também habilita padrões de segurança (security standards), mais notavelmente o padrão AWS Foundational Security Best Practices (FSBP) — dezenas de verificações automáticas (MFA na conta root, S3 público, EBS não criptografado, CloudTrail multirregional) mapeadas para regras do Config nos bastidores.

Em escala de organização, designe uma conta de administrador delegado (delegated administrator account) para o Security Hub (e para o GuardDuty e o Config), habilite o serviço e o padrão FSBP para toda a organização com a opção “auto-enable new accounts” e encaminhe os achados via EventBridge para o SNS, combinando Security Hub Findings - Imported filtrado pelo ARN do padrão FSBP com Compliance.Status = FAILED. Criar sua própria função Lambda para analisar o CloudTrail ou painéis por conta adiciona uma carga operacional que o Security Hub já absorve.

Uma divisão conceitual crucial: o Security Hub é detetive e agregador, não preventivo. Prevenir o desvio (drift) é o trabalho do AWS Control Tower, que orquestra uma landing zone multi-contas bem arquitetada. O Account Factory provisiona novas contas com uma linha de base de rede, logging e IAM. A governança é expressa por meio de guardrails de três tipos:

Controles proativos avaliam os templates do CloudFormation antes que uma stack seja implantada e se recusam a criar, por exemplo, uma instância RDS não criptografada. O Security Hub apenas informaria que a instância não criptografada existe depois que ela já estivesse em execução. Se um requisito diz “prevenir”, pense em Control Tower. Se diz “detectar, notificar ou agregar”, pense em Security Hub ou Config.

Macie: Descoberta de Dados Sensíveis

O Macie usa ML e correspondência de padrões para identificar dados sensíveis — PII, dados financeiros, credenciais — dentro de objetos do S3. A armadilha crítica é presumir que o Macie protege os dados. Ele não protege. O Macie descobre e reporta. Uso correto:

1. Habilite o Macie na conta/região de destino.
2. Configure um trabalho de descoberta de dados sensíveis (sensitive data discovery job), visando buckets/prefixos/tags de forma agendada.
3. Encaminhe os achados via EventBridge (source: aws.macie) para o SNS para notificações, para o Lambda para remediação (quarentena, restrição da política do bucket) ou para o Security Hub.

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

Sem o trabalho de descoberta, o Macie não produz nada. Sem a conexão EventBridge → SNS, os achados ficam no console do Macie sem serem notados.

Organizations, SCPs e Políticas de Tag

O AWS Organizations expõe três tipos de políticas relevantes aqui. As Políticas de Tag (Tag policies) definem as chaves de tag, o uso de maiúsculas/minúsculas e os valores permitidos — elas relatam a não conformidade e, combinadas com as condições aws:ResourceTag/aws:RequestTag, podem ser impostas. As Políticas de Controle de Serviço (SCPs) definem as permissões máximas disponíveis para os principais (principals) membros. As Políticas de Backup (Backup policies) e as Políticas de exclusão de IA (AI opt-out policies) completam o conjunto.

Um modelo mental crucial: SCPs nunca concedem permissões. Elas são um filtro sobre o que o IAM (políticas de identidade, políticas de recurso, limites de permissões) poderia permitir. Um principal deve ter um Allow no IAM e a SCP não deve ter um Deny (ou deve incluir a ação em sua lista de Allow). “Basta anexar uma SCP” nunca é uma resposta completa para uma questão de permissões — sem um Allow do IAM, o principal tem o acesso negado por padrão, independentemente do conteúdo da SCP.

Para exigir tags na criação, combine políticas de tag com uma SCP como esta:

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

A política de tag declara o esquema; a SCP nega a criação sem a tag; a política do IAM concede a ação de criação. Todos os três são necessários. A regra required-tags do AWS Config detecta e remedia recursos existentes que não estão em conformidade.

Systems Manager Automation e Aplicação de Patches

O Systems Manager (SSM) é a espinha dorsal operacional para atividades de ciclo de vida em frotas de nós EC2 e híbridos. Duas construções são mais importantes para a aplicação de patches: Documentos de Automação (Automation documents) (runbooks declarativos em YAML/JSON que chamam APIs ou scripts da AWS) e Janelas de Manutenção (Maintenance Windows) (que agendam esses runbooks para serem executados em alvos baseados em tags ou grupos de recursos dentro de uma janela de mudança com limites de concorrência e erro).

O fluxo canônico de aplicação de patches é o AWS-RunPatchBaseline (um Command document) sendo executado em instâncias selecionadas por uma tag de Patch Group, usando uma Patch Baseline que define regras de aprovação por sistema operacional. Para instâncias atrás de load balancers, executar o AWS-RunPatchBaseline diretamente interrompe as conexões no meio da aplicação do patch, pois as instâncias permanecem InService no target group. O padrão correto é AWSEC2-PatchLoadBalancerInstance, que:

1. Cancela o registro (deregisters) da instância de seu target group de CLB ou ALB.
2. Aguarda o esgotamento da conexão (connection draining) / atraso de cancelamento de registro (deregistration delay).
3. Invoca as etapas de verificação e instalação da patch baseline.
4. Reinicia se a baseline exigir.
5. Registra novamente a instância e aguarda o status de saúde do alvo (target health) retornar como healthy.

Dois pré-requisitos causam o modo de falha que “produz erros”. Primeiro, a IAM role passada como AutomationAssumeRole deve incluir elasticloadbalancing:DeregisterTargets, RegisterTargets e DescribeTargetHealth, além das permissões padrão de patching do SSM. Segundo, a instância deve ser um nó gerenciado (managed node) — com o SSM Agent em execução e o instance profile incluindo a política AmazonSSMManagedInstanceCore. Sem eles, as chamadas de cancelamento de registro falham ou o SSM não consegue ver a instância.

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 }}'

← Segurança · Todos os domínios · Alta Disponibilidade →

Pratique estas questões → · Prática cronometrada no ExamRoll.io →

Navegar Amazon →