Amazon SOA-C02: Gerenciamento de Custos e Marcação de Recursos — Guia de estudos

By Laurynas Brazys · 2 August 2026 · #amazon #soa-c02 #certification #exam-prep #study-guide

Faz parte do AWS SysOps Administrator Associate SOA-C02 — Guia de estudos. Pratique com respostas verificadas no centro de exames da Amazon, ou faça testes cronometrados no ExamRoll.io.

O gerenciamento de custos e o tagging de recursos são atividades operacionais essenciais que mantêm os gastos com a nuvem visíveis, previsíveis e governados. Faturamento e relatórios precisos permitem que os operadores atribuam custos a equipes, projetos e ambientes; o tagging, juntamente com políticas de conformidade, permite o estorno de custos (chargeback) e a limpeza automatizados. O uso ativo do Cost Explorer, Cost and Usage Reports, Budgets e ferramentas de otimização limita o desperdício e informa as decisões de compromisso, como Savings Plans ou Reserved Instances. Compreender os fatores de custo específicos do serviço (rede, armazenamento, load balancers, NAT) evita taxas inesperadas de egresso de dados e de serviços gerenciados.

Fundamentos de faturamento, relatórios de custos e Cost Explorer

Habilite o faturamento consolidado através do AWS Organizations e entregue o Cost and Usage Report (CUR) em um bucket S3 com granularidade horária e IDs de recursos para suportar uma atribuição detalhada. No console de Billing, habilite as tags de alocação de custos (tanto as geradas pela AWS quanto as definidas pelo usuário) para que o Cost Explorer e o CUR incluam colunas de tags. Para acesso programático, use a API do Cost Explorer ou a CLI: por exemplo,

undefined

Use o Cost Explorer para análise interativa de tendências e visualizações de rightsizing: habilite o relatório de Recomendações de Rightsizing, filtre por tag ou conta vinculada e exporte os CSVs de recomendação. Para fluxos de trabalho automatizados, ingira o CUR no Athena (crie uma tabela externa apontando para os arquivos do CUR) para executar consultas SQL em várias dimensões (linkedAccountId, productName, usageType, resourceId, tags). Combine consultas do Athena com crawlers do Glue para construir dashboards no QuickSight ou para alimentar a automação orientada por faturamento.

Critérios de decisão para escolher a granularidade e a retenção dos relatórios:

Use o CUR com granularidade horária se precisar de chargeback por instância ou automação baseada em instâncias de curta duração.
Use o CUR com granularidade diária para análise de tendências mensais quando o ruído horário for desnecessário.
Ative os IDs de recursos quando quiser unir dados de faturamento ao inventário (Tag Editor, Resource Groups) para uma atribuição precisa.

Estratégias de tagging para alocação de custos e governança

Adote uma taxonomia disciplinada de chaves de tag (por exemplo: CostCenter, Owner, Project, Environment, Lifecycle) e imponha-a no momento da criação. Ative essas chaves como Cost Allocation Tags no Billing para que apareçam no Cost Explorer e no CUR. Implemente a conformidade com:

Tag Policies do AWS Organizations para prescrever chaves e valores permitidos.
Regra gerenciada required-tags do AWS Config para detectar tags ausentes.
Permissões do IAM ou Service Control Policies para negar a criação de recursos sem as tags obrigatórias (use as chaves de condição aws:RequestTag e aws:TagKeys).

Use a API de Tagging do Resource Groups e o Tag Editor para auditar e corrigir tags entre regiões: por exemplo,

undefined

. Automatize a propagação de tags a partir do CI/CD ou do CloudFormation anexando tags no nível da stack e usando hooks baseados em Lambda para adicionar metadados de tempo de execução (instanceId, launchTime) aos recursos.

Tradeoffs ao escolher a imposição de tags:

Aplicação estrita (negar criação sem tags) evita a proliferação de recursos não etiquetados, mas pode bloquear fluxos de trabalho efêmeros de desenvolvedores, a menos que existam exceções.
Detectar e remediar (Config + automação) tem menos atrito, mas introduz um atraso entre a criação e a correção.

Savings Plans, Reserved Instances e rightsizing

Decida entre on-demand, Savings Plans e Reserved Instances com base na previsibilidade do uso de computação e nas necessidades de flexibilidade. Principais diferenças:

Savings Plans: Os Compute Savings Plans se aplicam a EC2, Fargate e Lambda e oferecem flexibilidade entre tamanhos de instância/regiões; os EC2 Instance Savings Plans visam famílias de instâncias em uma região com descontos maiores, mas com menor cobertura entre serviços.
Reserved Instances (RIs): As Standard RIs oferecem os maiores descontos para tipos de instância fixos e podem ser regionais ou zonais; as Convertible RIs permitem mudanças na família de instâncias, mas exigem reconfiguração.
On-demand: Sem compromisso, custo por hora mais alto, ideal para cargas de trabalho com picos (bursty) ou desconhecidas.

Use os relatórios de rightsizing do Compute Optimizer e do Cost Explorer para identificar instâncias subutilizadas (CPU, rede, throughput de EBS) e armazenamento superprovisionado. Combine as métricas do CloudWatch (

undefined

) com as recomendações do Compute Optimizer para justificar o downsizing ou mudanças na família de instâncias. Quando o uso é estável (por exemplo, vCPU-horas de linha de base para produção), calcule o ponto de equilíbrio (break-even) e a cobertura: adquira Savings Plans ou RIs para a linha de base previsível e mantenha um buffer de on-demand para picos de uso.

Orçamentos, alertas e previsões

Crie orçamentos no AWS Budgets para custo, uso e cobertura de RI/Savings Plan com tipos de limite Real (Actual) e Previsto (Forecasted). Use o console ou a CLI (

undefined

) e anexe notificações para tópicos SNS, e-mail ou ações do Lambda. Para remediação programática, conecte o SNS ao Lambda para etiquetar ou parar recursos efêmeros ou para abrir tickets no ITSM quando as previsões ultrapassarem os limites.

Adicione o Cost Anomaly Detection para detectar picos repentinos de gastos e vincule as anomalias ao SNS/SQS para fluxos de trabalho de investigação automatizados. A previsão no Cost Explorer usa o gasto histórico; combine-a com sinais de negócio (campanhas de início de trimestre, tickets abertos) para definir alertas de orçamento realistas. Para decisões operacionais:

Use limites previstos para capturar tendências de crescimento mais cedo.
Use limites reais para evitar ultrapassar o orçamento perto do final do mês.
Vincule alertas a guardrails automatizados (parar/reduzir escala) para contas não críticas.

← Serverless e Integração de Aplicações · Todos os domínios

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