Lab 98 — Plataforma de IA multi-time com cota e chargeback
O problema, e a empresa que o tem
A Cadência, do L43 e do L56, cresceu para quatro times usando o Bedrock: Atendimento (L91, prazo de resposta de 2,5 s), Extração de documento (L92), Busca de produto (L94) e Catálogo — o time que roda o enriquecimento em lote do L95. Os quatro chamam o mesmo modelo, na mesma conta de produção — a 333333333333 do L43/L56, a única que a OU Produção tinha até hoje.
O L95 já tinha resolvido a disputa entre Catálogo e Atendimento do jeito que tinha à disposição: rodar o job de lote de madrugada, fora do horário comercial. Funcionou por meses — até a terça-feira em que um fornecedor novo entrou no catálogo com uma taxonomia que não existia, e o time comercial pediu que os itens dele ficassem pesquisáveis ainda naquele dia. Não dava para esperar a próxima janela noturna. Às 14h32, alguém do time de Catálogo disparou o mesmo job de lote — manualmente, no meio da tarde.
O job consumiu 91% da cota de tokens por minuto da conta — a MESMA cota que o Atendimento usa para responder em tempo real. Entre 14h32 e 16h10, a latência p95 do Atendimento saltou de 1,8 s para 9,7 s, a taxa de erro foi de 0,3% para 34,1%, e quase metade das chamadas precisou escalar para um humano. Ninguém do time de Catálogo sabia que estava afetando o Atendimento — e ninguém do time de Atendimento sabia por que a fila explodiu, porque a fatura do Bedrock daquele mês chegou como uma linha só: R$ 42.900,00, sem dizer quanto cada time gastou.
O problema não é o job de lote — o L95 já provou que ele é a forma certa de processar volume sem esperar resposta em tempo real. O problema é que a disciplina de "rodar de madrugada" era um acordo bilateral entre dois times, não uma estrutura. Ela não sobreviveu ao terceiro e ao quarto time entrando na mesma conta, nem a uma emergência legítima que não podia esperar a janela. Cota e rateio que dependem de agenda são convenção; a mesma escada do L38 que separou dado por conta em vez de confiar em filtro de consulta se aplica aqui a TIME em vez de cliente.
O que este laboratório NÃO é
Não é onde o Atendimento, a Extração, a Busca ou o Catálogo são construídos — isso é o L91, o L92, o L94 e o L95, cada um já concluído. Não é uma landing zone de FinOps completa com dezenas de orçamentos aninhados: é o mínimo que resolve "quatro times, uma cota, uma fatura", que é exatamente o gargalo que travou a Cadência na terça-feira. E não é onde o Bedrock aprende a decidir sozinho quanto cada time pode gastar — a decisão de quota continua sendo humana, medida contra o volume real de cada time.
O que você vai conseguir fazer
Objetivos verificáveis: cada um se prova com uma medição na seção de implantação, não com a sensação de ter entendido a diferença entre cota e orçamento.
- Explicar por que cota de tokens por minuto e orçamento mensal são dimensões diferentes, e por que resolver uma não resolve a outra.
- Justificar por que separar conta por time isola capacidade e simplifica rateio ao mesmo tempo, sem depender de tag.
- Provisionar quatro contas de time dentro da OU Produção herdada do L43, reaproveitando o Account Factory.
- Configurar um budget por conta vinculada, com alarme antes do teto mensal estourar.
- Escopar o Identity Center para que cada time só acesse a própria conta.
- Reproduzir o incidente de terça-feira contra as duas arquiteturas e medir a diferença de latência e erro.
- Decompor a fatura de Bedrock por conta vinculada — o centro de custo de cada time.
- Diagnosticar por que um budget "não disparou" a partir de três causas distintas.
O que a certificação cobra disto
| Conceito | Certificação | Como aparece aqui | O que dominar |
|---|---|---|---|
| Cota de serviço (Service Quotas) escopada por conta, modelo e região | SAP-C02, AIF-C01 | mover o time de Catálogo para conta própria isola a cota dele sem pedir aumento nem gerenciar throttling na aplicação | por que separar conta é a forma mais simples de dar "cota própria" a um time, sem reimplementar limitação de taxa |
| Cost allocation por conta vinculada vs. tag de recurso | SAP-C02 | cada conta de time já é um centro de custo no Cost Explorer, sem exigir disciplina de tag em cada recurso novo | por que depender de tag herda o mesmo risco do L43: recurso sem tag foge do rateio, e ninguém percebe até a auditoria |
| AWS Budgets para contas vinculadas, criado a partir da conta de gestão | SAP-C02, CLF-C02 | um budget por conta de time, com alarme em 80% do teto mensal | budget não bloqueia gasto sozinho — só alarma; bloqueio real de capacidade vem de cota ou de SCP, não de Budgets |
| IAM Identity Center: permission set escopado por conta | SAA-C03, SAP-C02 | cada time só tem permission set atribuído à própria conta, nunca à raiz da organização | Identity Center concede acesso, não restringe — a fronteira real continua sendo a conta, herdada do L43 |
| Faturamento consolidado (consolidated billing) da Organization | SAP-C02 | uma fatura só por Organization, decomposta por conta vinculada no Cost Explorer | consolidated billing junta o PAGAMENTO, não o RATEIO — decompor por time exige olhar por conta vinculada, não a fatura total |
| Application Inference Profile como alternativa mais leve | AIF-C01 | citado na decisão como caminho para um time pequeno demais para justificar conta própria | rastreia custo por invocação sem duplicar conta — mas não isola CAPACIDADE, só CUSTO; a cota continua sendo uma só |
Onde isto costuma ser cobrado errado
A pergunta clássica descreve um time cujo job pesado derruba a latência de outro time no mesmo Bedrock, e oferece "aumente a cota da conta" como resposta. Ela erra o alvo: aumentar o teto beneficia os dois times igualmente, e o time barulhento ainda pode consumir o teto MAIOR inteiro sozinho — o incidente só demora mais para se repetir. A resposta certa isola CAPACIDADE por time, não aumenta um teto compartilhado.
Requisitos, e como cada um muda o desenho
Requisito que não aparece numa linha do Terraform, ou numa conta separada, é intenção — não requisito. A coluna da direita é onde cada um decide o desenho.
| Requisito | Valor declarado | O que ele decide no desenho |
|---|---|---|
| Um time não pode consumir a cota de outro | obrigatório, sem exceção | força isolamento de CONTA — a cota de tokens/minuto do Bedrock é escopada por conta, modelo e região, então mover cada time para a própria conta isola a capacidade sem pedir nada à AWS |
| Cada time sabe exatamente quanto gastou, sem depender de tag | obrigatório, mensal | usa a própria conta vinculada como centro de custo no Cost Explorer — nunca tag de recurso como fonte única de rateio |
| Orçamento por time com alarme antes do estouro | obrigatório, 80% do teto mensal | Budgets criado a partir da conta de gestão, escopado por conta vinculada, com SNS para o alarme |
| Acesso de cada time restrito à própria conta | obrigatório | Identity Center com permission set atribuído só à conta daquele time, nunca à raiz da organização |
| Provisionamento de conta nova não pode ser processo manual esquecível | obrigatório, herdado do L43 | Account Factory do Control Tower, nunca `aws_organizations_account` criado solto |
| Time pequeno demais para justificar conta própria não deve multiplicar custo fixo | restrição — orçamento de duas pessoas de plataforma | Application Inference Profile na conta compartilhada como caminho intermediário, até o volume do time justificar conta dedicada |
| Job legítimo de um time não pode ser bloqueado por completo em emergência | obrigatório | a cota de cada conta é dimensionada com folga sobre o volume medido daquele time, não um teto artificialmente apertado |
O requisito mais fácil de confundir com o do L95
"Cada time isolado" não é a mesma coisa que "tempo real separado de lote", que já era a lição do L95. Ali a separação era entre DUAS FORMAS de chamar o mesmo modelo, dentro do mesmo time de Catálogo. Aqui a separação é entre QUATRO TIMES diferentes, cada um com sua própria forma de usar o Bedrock — o Atendimento continua em tempo real, o Catálogo continua em lote, e os dois continuam sem competir, agora porque estão em contas diferentes, não só em horários diferentes.
Arquitetura mínima: quatro times, uma cota, uma fatura
Este é o desenho que a Cadência tem hoje, e ele é legítimo como ponto de partida: uma conta só é menos infraestrutura fixa para manter, e funcionou por meses enquanto só dois times disputavam a mesma cota em horários diferentes. O laboratório começa tornando o incidente de terça-feira reproduzível com números, em vez de deixá-lo como "a fila explodiu, ninguém sabe bem por quê".
- → dispara o job de lote manualmente, às 14h32 de terça-feira
- → consome 91% da cota de tokens/minuto da conta inteira
- → a MESMA cota — e ela já está quase esgotada pelo lote
- → também disputa a mesma cota, sem prioridade declarada
- → também disputa a mesma cota, sem prioridade declarada
- → gasto dos quatro times, somado numa linha só
- Fora da AWS
- Integração de apps
- IA e machine learning
- Analytics
- Gestão e governança
Este desenho é o que a Cadência tem hoje: quatro times, uma conta, um Bedrock. Ele funciona até o dia em que um deles precisa de mais capacidade do que a agenda combinada previa — e nesse dia, o teto único não distingue chamada urgente de chamada em lote. Percorra os passos: o incidente de terça-feira está desenhado aqui, não como hipótese.
- Quatro times, uma conta, um Bedrock. Atendimento, Extração, Busca e Catálogo chamam o mesmo modelo, na mesma conta de produção que o L43/L56 já tinha estabelecido. Nenhuma fronteira técnica separa o tráfego de um time do tráfego de outro.
- Terça-feira comum: Atendimento dentro do prazo de 2,5 s. Antes das 14h32, a latência p95 medida é 1,8 s e a taxa de erro é 0,3% — a cota compartilhada é suficiente quando só o tráfego interativo normal a disputa.
- Uma mudança urgente não espera a janela noturna do L95. O fornecedor novo precisa ficar pesquisável ainda naquele dia. Sem estrutura que force a espera, disparar o job na hora é a decisão mais rápida disponível — e tecnicamente possível, porque nada na conta impede.
- O job consome quase toda a cota — a MESMA que o Atendimento usa. 91% da cota de tokens/minuto da conta passa a ser ocupada pelo lote do Catálogo. O Bedrock não distingue "chamada urgente do Atendimento" de "chamada em lote do Catálogo" — os dois são, para a cota, o mesmo consumidor.
- O Atendimento esbarra na mesma cota, no mesmo minuto. Entre 14h32 e 16h10, a latência p95 do Atendimento sobe para 9,7 s e a taxa de erro para 34,1% — a seção de prova mede os dois lados desta janela em detalhe.
- Ninguém decidiu que o Catálogo tivesse prioridade sobre o Atendimento. A conta não distingue prioridade entre times — só existe UM teto, e quem chegou primeiro (ou em maior volume) o consome. Nenhuma reunião aprovou essa ordem; ela é subproduto de estarem todos na mesma cota.
- A fatura chega uma linha só, sem dizer quem gastou o quê. R$ 42.900,00 de Bedrock no mês, sem eixo de time no Cost Explorer. Nenhum dos quatro times sabe se está gastando dentro do esperado, porque não existe "esperado" individual — só o total da conta.
O comando abaixo não é ilustrativo — é a consulta real que mostra a cota de tokens/minuto da conta caindo para 9% de folga durante a janela do incidente.
# medir-cota-durante-incidente.sh -- consulta a métrica de uso de
# invocação do Bedrock (CloudWatch) na conta única, na janela do
# incidente de tercа-feira.
aws cloudwatch get-metric-statistics \
--namespace AWS/Bedrock \
--metric-name InvocationThrottles \
--dimensions Name=ModelId,Value=anthropic.claude-haiku-4-5 \
--start-time 2026-08-04T14:30:00Z --end-time 2026-08-04T16:15:00Z \
--period 300 --statistics Sum
# Resultado medido: 0 throttles antes das 14h32; picos de 340-410
# throttles por período de 5 min entre 14h35 e 16h05 -- a janela
# inteira em que o Atendimento tambem chamava o MESMO modelo.
R$ 42.900,00 numa linha só, e ninguém sabe de quem
A fatura de Bedrock do mês chega consolidada, sem eixo de time no Cost Explorer — o Catálogo não sabe que o job de terça-feira custou caro, o Atendimento não sabe que perdeu 34,1% das chamadas por causa de outro time, e a plataforma não tem como cobrar cada time pelo que ele de fato consumiu. É o mesmo tipo de risco estrutural do L43: sem fronteira de conta, nenhuma política — de cota ou de custo — é garantia, é só boa vontade.
Arquitetura para produção: quatro contas, quatro cotas, uma fatura decomposta
Cada peça nova abaixo rastreia a uma linha da tabela de requisitos. A pergunta que este desenho responde não é "como aumentar a cota" — é "de quem é a cota que está sendo consumida", exatamente a pergunta que a conta única não tinha como responder.
- → define a árvore de OUs que o Identity Center usa para escopar acesso
- → concede acesso só à conta Atendimento, para quem é do time Atendimento
- → concede acesso só à conta Catálogo, para quem é do time Catálogo
- → dispara o job de lote dentro da própria conta do time
- → consome a cota de tokens/minuto — só a da conta Catálogo
- → chama uma cota diferente, numa conta diferente — sem disputa
- → a conta de gestão cria um budget escopado a cada conta vinculada
- → alarma quando o budget de um time específico passa de 80%
- → gasto da conta Atendimento, já separado por conta vinculada
- → gasto da conta Catálogo, já separado por conta vinculada
- Fora da AWS
- Segurança e identidade
- Integração de apps
- IA e machine learning
- Analytics
- Gestão e governança
A topologia muda inteira, não só o rótulo: a OU Produção deixa de ter uma conta monolítica e passa a ter uma conta por time, cada uma com sua própria cota de Bedrock. Budgets e Identity Center são criados a partir da conta de gestão, escopados por conta vinculada. Percorra os passos: cada peça nova ataca um requisito que a arquitetura mínima deixou exposto.
- Quatro contas, uma por time, dentro da mesma OU Produção. A OU Produção do L43/L56 tinha uma conta só. Este laboratório a divide por TIME: Atendimento, Extração, Busca e Catálogo ganham, cada um, sua própria conta — a mesma árvore de Organizations, um nível a mais de granularidade.
- Identity Center concede acesso só à própria conta do time. Quem é do time de Catálogo tem permission set atribuído só na conta Catálogo. Ninguém do Atendimento consegue nem LER a conta do Catálogo, e vice-versa — a fronteira de acesso segue a mesma de capacidade.
- A pessoa do time de Catálogo dispara o mesmo job, fora da janela. É a MESMA urgência do incidente de terça-feira — fornecedor novo, taxonomia nova, não dá para esperar a madrugada. A diferença é onde ela dispara: dentro da conta que só pertence ao Catálogo.
- O job satura a cota — mas só a da conta de Catálogo. O Bedrock desta conta específica pode chegar perto de 100% de uso — e isso é aceitável, porque ninguém está esperando o lote em tempo real. O que importa é que essa saturação não atravessa a fronteira de conta.
- O Atendimento continua dentro do prazo de 2,5 s. A cota da conta Atendimento é uma cota DIFERENTE, numa conta DIFERENTE. Não existe teto compartilhado entre as duas — a seção de prova mede a mesma janela de terça-feira, replicada, com o Atendimento inalterado.
- Um budget por conta, criado a partir da conta de gestão. A conta de gestão publica um budget escopado a cada conta vinculada, com alarme em 80% do teto declarado para aquele time — sem exigir que ninguém dentro da conta do time configure nada.
- A fatura já vem decomposta por conta — cada conta É o centro de custo. O Cost Explorer agrupado por conta vinculada substitui a dependência de tag lembrada: o gasto do Atendimento e o gasto do Catálogo aparecem separados por construção, não por disciplina de marcação.
O que NÃO precisou mudar em relação ao L43/L56
As OUs Não-Produção e Produção continuam as mesmas. O que muda é o que existe DENTRO da OU Produção: uma conta virou quatro, uma por time, sem exigir uma terceira OU nem reescrever a SCP que o L43 já publicou — ela protege a OU inteira, e todas as quatro contas novas herdam a mesma proteção contra ação destrutiva, automaticamente.
Como a cota isolada contém o incidente, ponta a ponta
O caminho mais fácil de entender errado é achar que "conta separada" significa reescrever o Atendimento, a Extração, a Busca ou o Catálogo. Não significa — os quatro continuam sendo exatamente o código do L91, do L92, do L94 e do L95. O que muda é só ONDE cada um roda.
// Evento real que o CloudWatch emite quando a cota de INVOCAÇÃO do
// Bedrock (nao a de orcamento) e atingida numa conta especifica --
// aqui, a conta Catalogo, isolada da conta Atendimento.
{
"source": "aws.bedrock",
"detail-type": "Bedrock Model Invocation Throttled",
"account": "333300000095",
"region": "us-east-1",
"time": "2026-08-04T14:41:07Z",
"detail": {
"modelId": "anthropic.claude-haiku-4-5",
"reason": "InvocationThrottled",
"accountUtilizationPercent": 97.4
}
}
// Repare no "account": e a conta 333300000095 (Catalogo) sozinha --
// nenhum evento equivalente aparece na conta 333300000091
// (Atendimento) na mesma janela.
Por que o Bedrock não precisa saber que existem quatro times
O isolamento não depende de nenhuma lógica nova dentro do Bedrock — ele já aplica cota por conta, modelo e região, para qualquer conta, sempre. O que este laboratório faz é decidir ONDE cada carga roda, aproveitando um comportamento que o serviço já tem, em vez de pedir que ele aprenda a diferenciar "chamada do Atendimento" de "chamada do Catálogo" dentro da mesma conta.
As decisões, e o que se perde em cada uma
📋 A Cadência tem quatro times chamando o Bedrock na mesma conta de produção. Um job de lote do time de Catálogo, disparado fora da janela combinada, consumiu 91% da cota compartilhada e derrubou a latência do Atendimento por 1h38min — sem que nenhum dos dois times conseguisse ver o gasto do outro na fatura.
Nenhuma alternativa resolve isolamento de CAPACIDADE e rateio de CUSTO ao mesmo tempo sem depender de disciplina humana. Separar conta resolve os dois de uma vez, porque aproveita dois comportamentos que a AWS já garante estruturalmente: cota escopada por conta, e faturamento consolidado decomposto por conta vinculada. Nenhuma das duas coisas precisa ser reimplementada — só reaproveitada, com o padrão de OU que o L43 já publicou.
Alt: Pedir aumento de cota (Service Quotas) na conta única, sem separar — aumenta o teto para os QUATRO times igualmente, sem reservar nada para o Atendimento — o time de Catálogo ainda pode consumir o teto MAIOR inteiro sozinho na próxima urgência; resolve o sintoma de hoje, não a causa estrutural
Alt: Application Inference Profile com tag por time, mesma conta — rastreia CUSTO por invocação de forma granular — útil para saber quem gastou o quê —, mas não isola CAPACIDADE: a cota de tokens/minuto continua sendo uma só, compartilhada; resolve o rateio, não o incidente de latência
Alt: Provisioned Throughput dedicado por time, na mesma conta — garante capacidade reservada de verdade, sem depender de conta separada, mas exige compromisso de capacidade paga por hora — pensado para carga alta e SUSTENTADA; nem todo time da Cadência (Extração e Busca, por exemplo) tem volume que justifique reservar throughput 24 horas por dia
Alt: Confiar em agenda — só rodar o lote de madrugada, como já era — foi exatamente o que já falhou: convenção entre dois times não escala para quatro, e não sobrevive a uma emergência legítima que não pode esperar a próxima janela — que é o próprio cenário deste laboratório
A tabela abaixo compara as três formas reais de isolar times num mesmo Bedrock — a Cadência escolheu a primeira para os quatro times de hoje, e guarda a segunda para o próximo time pequeno que entrar na plataforma.
| Abordagem | O que ela isola | O que ela NÃO isola | Quando escolher |
|---|---|---|---|
| Conta separada por time (escolha deste laboratório) | capacidade (cota de tokens/minuto) E custo (centro de custo = conta vinculada) | nada de crítico — o custo é infraestrutura fixa duplicada por conta, mitigado por ela ser pequena aqui | time com volume regular e crítico o bastante para justificar a conta própria — é o caso dos quatro times da Cadência |
| Application Inference Profile, mesma conta | só o CUSTO — rastreia gasto por invocação com granularidade | capacidade — a cota de tokens/minuto continua compartilhada entre todos os perfis da mesma conta | time novo, com volume pequeno demais para justificar conta própria, mas que já precisa aparecer separado na fatura |
| Provisioned Throughput por time | capacidade GARANTIDA, não só isolada — reserva throughput dedicado | custo previsível só se o volume for sustentado; ocioso, o compromisso pago continua cobrando | time com carga alta e constante, que já saturaria uma cota on-demand mesmo isolada |
A citação que resolve a dúvida na hora da prova
A documentação de Service Quotas é explícita: cotas de serviço da AWS são aplicadas por CONTA, e cada conta da Organization tem seus próprios valores, independentes das demais. É por isso que mover um time para conta própria isola a cota dele sem exigir nenhuma configuração adicional de limitação de taxa — o isolamento já é o comportamento padrão entre contas, não algo que precisa ser construído.
Construir: a organização e as contas por time
A árvore de Organizations é a mesma do L43/L56 — só a OU Produção ganha três contas novas. Como no L56, as contas nascem pelo Account Factory do Control Tower, nunca por `aws_organizations_account` direto: a conta precisa entrar registrada nos guardrails detectivos que o Control Tower já mantém.
# contas-por-time.tf -- referencia as contas provisionadas pelo
# Account Factory (console ou produto do Service Catalog). NAO cria
# `aws_organizations_account` direto -- mesma decisao do L56.
variable "conta_atendimento_id" {
type = string
description = "333300000091 -- conta do time Atendimento, ja na OU Producao"
}
variable "conta_extracao_id" {
type = string
description = "333300000092 -- conta do time Extracao"
}
variable "conta_busca_id" {
type = string
description = "333300000094 -- conta do time Busca"
}
variable "conta_catalogo_id" {
type = string
description = "333300000095 -- conta do time Catalogo, a que dispara o job de lote"
}
# As quatro contas ja herdam a SCP da OU Producao publicada no L43 --
# nenhuma linha de policy precisa ser reescrita para elas. O bloco
# abaixo so documenta o mapa time -> conta, usado pelos budgets e pelo
# Identity Center nos proximos dois arquivos.
locals {
contas_por_time = {
atendimento = var.conta_atendimento_id
extracao = var.conta_extracao_id
busca = var.conta_busca_id
catalogo = var.conta_catalogo_id
}
}
As contas não nascem deste Terraform
Assim como no L56, este arquivo assume que o Account Factory já provisionou as quatro contas — ele só as referencia por variável. Criar conta é passo manual (console) ou automatizado à parte (Account Factory for Terraform), fora do escopo deste laboratório de isolamento de cota.
Construir: um orçamento por time, com alarme antes do estouro
O budget é criado a partir da conta de gestão, escopado à conta vinculada de cada time — nenhuma configuração é feita dentro da conta do time.
# budgets-por-time.tf -- um budget por conta vinculada, criado a
# partir da conta de gestao (paying account). Alarme em 80% do teto
# mensal declarado para cada time -- nao bloqueia gasto, so avisa.
resource "aws_sns_topic" "alarme_orcamento_ia" {
name = "cadencia-alarme-orcamento-times-ia"
}
# teto mensal declarado por time -- medido contra o historico de
# gasto real de cada um, nao um numero redondo escolhido no ar.
locals {
teto_mensal_por_time = {
atendimento = 22000
extracao = 8000
busca = 12000
catalogo = 12000
}
}
resource "aws_budgets_budget" "por_time" {
for_each = local.contas_por_time
name = "cadencia-${each.key}-bedrock-mensal"
budget_type = "COST"
limit_amount = tostring(local.teto_mensal_por_time[each.key])
limit_unit = "BRL"
time_unit = "MONTHLY"
# Escopa o budget a UMA conta vinculada -- e o que faz cada time
# ter o proprio orcamento, mesmo todos sendo criados a partir da
# mesma conta de gestao.
cost_filter {
name = "LinkedAccount"
values = [local.contas_por_time[each.key]]
}
notification {
comparison_operator = "GREATER_THAN"
threshold = 80
threshold_type = "PERCENTAGE"
notification_type = "ACTUAL"
subscriber_sns_topic_arns = [aws_sns_topic.alarme_orcamento_ia.arn]
}
}
Budget não bloqueia — só alarma, e é uma escolha deliberada
Um `aws_budgets_budget` não impede o Catálogo de continuar chamando o Bedrock depois de estourar o teto — ele só notifica. Bloquear gasto de verdade exigiria uma ação automatizada em cima do alarme (por exemplo, uma SCP temporária ou reduzir uma cota), que este laboratório não implementa: a decisão de cortar acesso de um time em produção é humana, não automática, porque o custo de um falso positivo (bloquear um pico legítimo) é maior que o custo de um alarme atrasado em minutos.
Construir: acesso por time, via Identity Center
Cada time recebe um permission set atribuído só à própria conta — a mesma disciplina do L43/L56, agora com quatro contas de time em vez de uma de ambiente.
# identity-center-por-time.tf -- um permission set por time,
# atribuido SO na conta daquele time. Ninguem do Atendimento tem
# atribuicao na conta do Catalogo, e vice-versa.
data "aws_ssoadmin_instances" "this" {}
resource "aws_ssoadmin_permission_set" "operador_ia" {
for_each = local.contas_por_time
name = "Operador-IA-${title(each.key)}"
instance_arn = tolist(data.aws_ssoadmin_instances.this.arns)[0]
session_duration = "PT4H"
}
resource "aws_ssoadmin_managed_policy_attachment" "operador_ia_bedrock" {
for_each = local.contas_por_time
instance_arn = tolist(data.aws_ssoadmin_instances.this.arns)[0]
managed_policy_arn = "arn:aws:iam::aws:policy/AmazonBedrockFullAccess"
permission_set_arn = aws_ssoadmin_permission_set.operador_ia[each.key].arn
}
resource "aws_ssoadmin_account_assignment" "operador_ia" {
for_each = local.contas_por_time
instance_arn = tolist(data.aws_ssoadmin_instances.this.arns)[0]
permission_set_arn = aws_ssoadmin_permission_set.operador_ia[each.key].arn
principal_id = var.grupos_por_time[each.key] # um grupo do IdP por time
principal_type = "GROUP"
# O ponto central: o target e a conta DAQUELE time, nunca a raiz da
# organizacao nem a conta de outro time. E essa unica linha que
# transforma "todo mundo pode chamar o Bedrock" em "cada time so
# pode chamar o Bedrock da propria conta".
target_id = local.contas_por_time[each.key]
target_type = "AWS_ACCOUNT"
}
A variável que este trecho pressupõe
`var.grupos_por_time` mapeia cada time a um grupo do provedor de identidade externo (o mesmo IdP federado ao Identity Center desde o L43) — não codifique IDs de grupo fixos no módulo, porque um novo time adicionado à plataforma só precisa de uma entrada nova nesse mapa, não de uma reescrita do Terraform.
Construir: a ferramenta que decompõe a fatura por time, em C#
Um utilitário de linha de comando que consulta o Cost Explorer agrupado por conta vinculada e imprime a fatura de Bedrock decomposta por time — sem depender de nenhuma tag.
// DecomporFaturaPorTime/Program.cs -- consulta GetCostAndUsage
// agrupado por LINKED_ACCOUNT, filtrado ao servico Bedrock, e
// imprime o gasto de cada time no periodo. A CONTA e a dimensao de
// agrupamento -- nao ha tag nenhuma neste codigo.
using Amazon.CostExplorer;
using Amazon.CostExplorer.Model;
var mapaContaParaTime = new Dictionary<string, string>
{
["333300000091"] = "Atendimento",
["333300000092"] = "Extração",
["333300000094"] = "Busca",
["333300000095"] = "Catálogo",
};
using var ce = new AmazonCostExplorerClient(); // roda com credencial da conta de gestão
var resposta = await ce.GetCostAndUsageAsync(new GetCostAndUsageRequest
{
TimePeriod = new DateInterval { Start = "2026-08-01", End = "2026-09-01" },
Granularity = Granularity.MONTHLY,
Metrics = new List<string> { "UnblendedCost" },
Filter = new Expression
{
Dimensions = new DimensionValues
{
Key = Dimension.SERVICE,
Values = new List<string> { "Amazon Bedrock" },
},
},
GroupBy = new List<GroupDefinition>
{
new() { Type = GroupDefinitionType.DIMENSION, Key = "LINKED_ACCOUNT" },
},
});
decimal total = 0;
foreach (var grupo in resposta.ResultsByTime[0].Groups)
{
var contaId = grupo.Keys[0];
var time = mapaContaParaTime.GetValueOrDefault(contaId, $"conta desconhecida ({contaId})");
var custo = decimal.Parse(grupo.Metrics["UnblendedCost"].Amount);
total += custo;
Console.WriteLine($"{time,-12} R$ {custo,10:N2}");
}
Console.WriteLine($"{"Total",-12} R$ {total,10:N2}");
Por que a chave é `LinkedAccount`, não uma tag
`GroupDefinitionType.DIMENSION` com `LINKED_ACCOUNT` agrupa pelo ID da conta vinculada — uma dimensão nativa do Cost Explorer que existe para toda Organization, sem exigir que nenhum recurso tenha sido marcado. Se a Cadência precisasse decompor gasto DENTRO de uma mesma conta (por exemplo, se dois times ainda dividissem uma conta via Application Inference Profile), a consulta trocaria `LINKED_ACCOUNT` por uma tag de custo — e voltaria a depender da disciplina que a conta separada evita.
Provar: o incidente reproduzido, isolado e faturado por time
O mesmo job, disparado no mesmo horário, contra as duas arquiteturas — é o mesmo tipo de disciplina do L95: medir com a MESMA carga nos dois lados, para que a diferença medida seja da FRONTEIRA de conta, não de uma variável escondida.
| Métrica (janela 14h32–16h10) | Conta única (medido) | Contas isoladas (medido) |
|---|---|---|
| Latência p95 do Atendimento | 9,7 s (alvo: 2,5 s) | 1,9 s (dentro do alvo de 2,5 s) |
| Taxa de erro do Atendimento | 34,1% | 0,4% |
| Chamadas escaladas para humano | 47% | 4,2% (igual à média histórica) |
| Uso da cota de tokens/minuto pelo lote | 91% da cota da CONTA INTEIRA | 97% da cota DA PRÓPRIA conta Catálogo |
| Duração do job de reclassificação do Catálogo | 22 min (usava a cota da conta inteira) | 51 min (usa só a cota reservada à própria conta) |
| Efeito no Atendimento durante o job | latência e erro dispararam junto | nenhum efeito mensurável |
O que os 51 minutos custam, e o que eles compram
O job de Catálogo demora mais que o dobro isolado (51 min contra 22 min) — porque, na conta única, ele estava usando SILENCIOSAMENTE a capacidade que deveria ir para o Atendimento. Isolado, ele usa só a própria cota, e é mais lento por isso. É uma troca real, não um efeito colateral: o Catálogo absorve sozinho o custo do próprio volume, e ninguém mais paga por ele.
A mesma fronteira de conta que conteve a latência também decompõe a fatura — sem nenhuma tag, sem nenhum passo manual de rateio.
| Time | Gasto de Bedrock no mês | % do total |
|---|---|---|
| Atendimento | R$ 18.200,00 | 42,4% |
| Busca | R$ 9.400,00 | 21,9% |
| Catálogo | R$ 9.200,00 | 21,4% |
| Extração | R$ 6.100,00 | 14,2% |
| Total (igual à linha única de antes) | R$ 42.900,00 | 100% |
O número que sustenta o módulo
Latência do Atendimento de 9,7 s para 1,9 s na MESMA janela de incidente reproduzida, e uma fatura de R$ 42.900,00 que passa de uma linha sem nome para quatro linhas nomeadas — sem trocar uma linha de código de nenhum dos quatro times, só a conta onde cada um roda.
Quebrar de propósito: quatro falhas do isolamento e do rateio
O incidente das 14h32 aconteceu porque quatro times dividiam uma cota sem saber. As injeções abaixo testam se o desenho novo realmente impede que ele se repita — e duas delas mostram que impedir o incidente e conseguir cobrar por ele são problemas separados, que falham separadamente.
| Falha injetada | Como injetar | Sintoma enganoso | Diagnóstico correto |
|---|---|---|---|
| O incidente original, agora com cota separada | Disparar o job de lote do L95 às 14h30, de propósito, no meio do horário comercial | O time de Catálogo reclama que o job dele está lento e estrangulando | É o resultado CORRETO, e a reclamação é a prova de que o desenho funcionou. O estrangulamento ficou contido no time que o causou, em vez de vazar para o Atendimento. O trabalho da plataforma aqui não é impedir que um time se prejudique — é impedir que ele prejudique os outros. Rode esta injeção primeiro: é a prova direta da tese do laboratório |
| Recurso criado sem a tag de alocação | Provisionar algo no time de Busca sem a tag obrigatória e esperar o fechamento | Nada quebra. O recurso funciona, o time trabalha, e a fatura fecha normalmente | O custo caiu no balde de não alocado, e o rateio perdeu credibilidade em silêncio — que é como todo chargeback morre. Ninguém contesta a conta no mês em que ela está certa; contestam no mês seguinte, quando o não alocado cresceu e vira "esse número não é confiável". Política de tag obrigatória na criação, e um painel do não alocado como métrica de primeira classe, não como resto |
| Alarme de orçamento chegando depois do fechamento | Configurar o orçamento sobre custo realizado, sem previsão, e estourar a cota de um time no dia 3 | O alarme dispara — no fim do mês. Tecnicamente tudo funcionou | Orçamento que avisa depois do gasto é relatório, não controle. O dado de custo tem atraso próprio de consolidação, e esperar por ele significa descobrir o estouro quando ele já é irreversível. O sinal em tempo quase real é a métrica de invocação e de token por time, que existe em minutos; o custo consolidado serve para o rateio, não para o freio |
| Um quinto time entrando sem cota própria | Dar acesso a um time novo reaproveitando as credenciais de um time existente, "só para começar rápido" | O time novo produz no primeiro dia, e todo mundo elogia a agilidade da plataforma | O incidente das 14h32 acabou de ser reintroduzido, agora com dois times dividindo a cota de um. E o rateio passa a cobrar do time errado, o que é pior que não cobrar: gera disputa entre áreas sobre um número que a plataforma não consegue defender. Onboarding de time é um caminho automatizado com conta, cota, tag e orçamento próprios — se ele é lento a ponto de tentar o atalho, o defeito está no onboarding |
A Cadência decide, depois do incidente de terça-feira, apenas PEDIR à AWS um aumento da cota de tokens/minuto da conta única — sem separar as contas dos quatro times. Na próxima vez que o time de Catálogo disparar um job de lote fora da janela noturna, o que acontece com o Atendimento?
Segurança: o que muda quando quatro times viram quatro contas
Um erro de permissão na arquitetura mínima expõe o Bedrock de um time a todos os outros três. Na arquitetura de produção, o mesmo tipo de erro fica contido a uma conta — mas duas peças novas (Identity Center e Budgets) criam suas próprias superfícies.
| Risco | Probabilidade | Impacto | Controle preventivo | Detecção | Resposta |
|---|---|---|---|---|---|
| Permission set de um time atribuído, por engano, na conta de outro time | baixa | alto | atribuição do Identity Center sempre com `target_id` explícito da conta certa, revisada por par antes de aplicar | auditoria periódica de `aws_ssoadmin_account_assignment` contra o mapa time-conta | remover a atribuição errada, auditar o que foi acessado na conta indevida |
| Budget criado sem `cost_filter` de conta vinculada, agregando o gasto de todos os times | média | médio | `cost_filter` obrigatório em todo `aws_budgets_budget`, testado com uma consulta antes de publicar | comparar o valor do budget contra o gasto real daquela conta isolada | corrigir o filtro, reprocessar o alarme |
| Conta de time provisionada fora do Account Factory, sem guardrails do Control Tower | baixa | alto | Account Factory como único caminho de criação de conta, herdado do L43 | auditoria periódica de contas na organização sem guardrail detectivo | registrar a conta órfã no Control Tower, ou recriar pelo caminho certo |
| Cota padrão da conta nova nunca ajustada ao volume real do time | média | médio | medir o volume do time ANTES de provisionar a conta, e solicitar o ajuste de cota já no dia do provisionamento | CloudWatch de throttling específico da conta daquele time | solicitar aumento de cota com o volume medido como justificativa |
SNS sem assinante testado é alarme mudo
Um `aws_budgets_budget` com notificação apontando para um SNS topic sem assinante válido publica o evento normalmente — e ninguém recebe nada. É o mesmo defeito de uma fumaça sem detector: a fatura de agosto seria a primeira notícia do estouro, exatamente o cenário que este laboratório existe para evitar. Teste o alarme com um gasto simulado pequeno antes de confiar nele em produção.
Observabilidade: as perguntas que o painel tem de responder
| Pergunta | Métrica ou consulta | O que significa mudar | Limiar inicial |
|---|---|---|---|
| Algum time está perto de estourar a própria cota de tokens/minuto? | métrica de throttling do Bedrock, por conta | carga daquele time cresceu, ou um job novo entrou sem aviso naquela conta | alarme em 80% de uso sustentado por 5 minutos |
| Algum time está perto de estourar o orçamento mensal? | AWS Budgets, % do teto atingido, por conta vinculada | gasto acima do padrão histórico daquele time específico | alarme em 80% do teto mensal daquela conta |
| A latência do Atendimento segue dentro do prazo de 2,5 s? | p95 de latência do Connect/Bedrock, na conta Atendimento | algo degradando o SLA do time mais sensível a latência, dentro da própria conta dele | acima de 2,5 s por 2 períodos consecutivos |
| Algum time gastou muito mais que o padrão histórico, de repente? | AWS Cost Anomaly Detection, por conta vinculada | pico fora do padrão daquele time, antes mesmo de chegar a 80% do budget | desvio configurado pela sensibilidade do monitor de anomalia |
A métrica que engana no dia em que uma conta nova entra
Uma conta de time recém-provisionada aparece com 0% de uso do budget e 0% de uso da cota nos primeiros dias — não é sinal de que o time não está usando o Bedrock, é o formato normal de uma conta sem histórico. Espere pelo menos uma semana de uso antes de calibrar o limiar de anomalia daquela conta específica.
Escala: de quatro times a dez, e o pico de um time só
| Volume | O que muda | O que passa a doer | O que fazer |
|---|---|---|---|
| 4 times (linha de base deste laboratório) | 1 conta por time, 4 contas na OU Produção | nada — é o regime que este desenho atende | nada |
| 10 times | 10 contas na OU Produção, mesmo padrão replicado | custo fixo (log group, alarme, permission set) por conta soma linear com o número de times | reavaliar se times pequenos migram para Application Inference Profile em vez de conta própria |
| Um time cresce 10x sozinho (ex.: Atendimento em campanha sazonal) | a cota da conta daquele time pode não bastar mais, mesmo isolada | throttling dentro da PRÓPRIA conta do time, sem afetar os outros três, mas afetando aquele time | solicitar aumento de cota só para aquela conta, com o pico medido como justificativa — nunca para a organização inteira |
| Nova conta de time provisionada no meio do mês | sem histórico de gasto para calibrar anomalia nem cota inicial | budget e monitor de anomalia partem de zero, cegos para o padrão real do time | dimensionar a cota inicial pelo volume medido ANTES da migração, não por um valor padrão |
| Falha da conta de gestão (Organizations/Identity Center indisponível) | provisionamento de conta nova e atribuição de acesso ficam bloqueados | as quatro contas de time continuam operando normalmente — cota e Bedrock não dependem da conta de gestão em tempo real | nenhuma ação de emergência; é degradação de ADMINISTRAÇÃO, não de operação |
O número que costuma decidir a questão de prova
Cota de serviço é sempre escopada a CONTA, MODELO e REGIÃO — os três juntos, nunca um sozinho. Uma questão que descreve dois times na mesma conta, mesmo modelo, mesma região, e pergunta se eles competem pela mesma cota está testando exatamente esse escopo: a resposta é sim, sempre, dentro da mesma conta.
Custo: o que a plataforma acrescenta, e o que ela apenas passa a enxergar
Este laboratório é atípico na série: quase todo o custo que ele governa já existia antes dele. A separação abaixo é a que evita a conversa mais comum e mais improdutiva sobre plataforma interna — confundir o preço de enxergar o gasto com o gasto em si.
| Dimensão | De quem é o custo | Como se comporta |
|---|---|---|
| Tokens do Bedrock dos quatro times | Já existia — a plataforma só passa a saber de quem é | É a quase totalidade da fatura, e não muda de valor por causa deste laboratório. Muda de DONO: sai de uma linha só de R$ 42.900 e vira quatro linhas defensáveis |
| Contas adicionais na organização | Novo, e desprezível | Conta em si não tem mensalidade. O que cresce com o número de contas é trabalho de governança e o número de cotas a solicitar — custo de pessoa, não de fatura |
| Orçamentos e relatório de custo detalhado | Novo, e pequeno | Cobrança por orçamento configurado, mais o armazenamento do relatório detalhado. Cresce com o número de times, não com o consumo deles |
| Consultas de rateio sobre o relatório de custo | Novo, e o único que pode surpreender | Cobra por byte varrido. Um painel de rateio que recalcula o histórico inteiro a cada abertura custa mais que os orçamentos que ele monitora — particionar por mês e materializar o fechamento resolve |
| Vazão provisionada por time, se usada para isolar | Novo, e o de maior risco | É a única forma de isolamento com PISO: cobra a capacidade reservada esteja ela em uso ou não, por time. Isola de verdade e cria custo fixo multiplicado pelo número de times. Só se justifica para o time com requisito de latência contratual — no caso da Cadência, o Atendimento do L91 |
| Cenário | O que muda | O que ninguém nota |
|---|---|---|
| Quatro times, o desenho de hoje | A fatura total é praticamente a mesma de antes; o acréscimo da governança fica na casa dos décimos de ponto percentual | O ganho não está na fatura menor — está no fato de que agora existe alguém a quem perguntar por que ela cresceu. Essa é a economia real, e ela não aparece em nenhuma linha |
| Dez times | Governança cresce linearmente; o rateio deixa de ser planilha e precisa de painel | É o ponto em que o balde de não alocado passa a ser politicamente relevante. Com quatro times, 5% de não alocado é arredondamento; com dez, é o suficiente para alguém questionar o método inteiro |
| Vinte e cinco times | Cota por conta vira o recurso escasso, não o dinheiro: o limite agregado da organização passa a ser o gargalo antes do orçamento | A plataforma deixa de ser um problema de FinOps e vira um problema de capacidade. O planejamento passa a exigir previsão de demanda por time com antecedência de semanas, porque aumento de cota não é instantâneo |
O número que justifica a plataforma
Não é a fatura menor — este laboratório não promete reduzir o gasto com modelo. É o custo do incidente evitado: uma hora e meia de Atendimento com 34,1% de erro, medida em ligações perdidas e escalonamentos forçados, contra o custo de governança de um mês. A conta fecha no primeiro incidente que não acontece, e a dificuldade permanente de defender plataforma interna é justamente que o numerador é um evento que deixou de existir.
Well-Architected nos seis pilares
| Pilar | Situação ao fim deste laboratório | Risco que fica | Melhoria | Prioridade |
|---|---|---|---|---|
| Excelência operacional | cada time provisiona e opera dentro da própria conta, com o mesmo padrão replicado do L43/L56 | sem runbook escrito para quando um budget alarma — quem investiga, em quanto tempo | runbook curto por alarme de budget, com o comando de decomposição da fatura já pronto | média |
| Segurança | permission set escopado por conta; cada time isolado do Bedrock dos outros três | cota padrão de conta nova ainda não é ajustada automaticamente ao volume medido do time | checagem automatizada de volume antes do primeiro dia de uma conta nova em produção | média |
| Confiabilidade | falha de um time (throttling, job travado) não se propaga para os outros três | sem failover de região se o Bedrock cair na região principal para todos os times ao mesmo tempo | avaliar região secundária só se o SLA de algum time exigir — hoje nenhum declara isso | baixa |
| Eficiência de performance | cota isolada por time, ajustável independentemente sem afetar os outros | nenhum — cada conta ajusta sua própria cota sem coordenação cross-time | nenhuma ação necessária agora | baixa |
| Otimização de custos | fatura decomposta por conta vinculada, sem depender de tag; budget com alarme por time | budget mensal estático ainda chega atrasado em picos de um dia só, como mostrou a seção de prova | Cost Anomaly Detection por conta vinculada, complementando o budget de 80% | alta |
| Sustentabilidade | isolamento por conta não muda o consumo agregado de capacidade computacional do Bedrock | nenhum específico deste módulo | nenhuma ação necessária agora | baixa |
Evolução em níveis: da conta compartilhada à plataforma que prevê o próprio orçamento
Cada nível responde à mesma pergunta: o que muda quando o número de times ou a ambição de rateio cresce, e o que essa mudança troca.
Quatro times, uma conta, um Bedrock, sem cota reservada nem budget — o desenho que causou o incidente de terça-feira.Budget único da conta inteira, com alarme, ainda sem separar times.Conta separada por time dentro da OU Produção, budget por conta com alarme, Identity Center escopado, Cost Explorer decompondo por conta vinculada.Times com volume pequeno demais para justificar conta própria usam Application Inference Profile na conta de Ferramentas, até o volume justificar a separação.AWS Cost Anomaly Detection por conta vinculada, avisando antes mesmo do alarme de 80% do budget disparar.Modelo de previsão treinado sobre o histórico de uso de cada conta, recomendando cota e orçamento do PRÓXIMO mês antes que o time precise pedir aumento manual — é o L100.A ordem não é opcional
Prever orçamento no nível 6 sem a decomposição por conta do nível 3 é previsão sem dado — não existe "gasto do time de Catálogo" para alimentar nenhum modelo se a fatura ainda é uma linha só. E adicionar Application Inference Profile no nível 4 antes de ter provado o isolamento por conta no nível 3 mistura dois regimes sem nenhum dos dois estar validado primeiro.
Onde IA entra além do isolamento de conta, e onde não entra
O núcleo deste laboratório não é IA — é Organizations, Budgets e Identity Center resolvendo isolamento e rateio. A pergunta desta seção é onde IA agregaria valor ALÉM disso, e onde forçá-la seria decoração.
Um lugar onde IA agrega valor real: prever, por conta de time, quando o gasto do mês vai fugir do padrão histórico — ANTES do alarme estático de 80% do budget disparar. Uma regra fixa ("alarme em 80% do teto") não resolve isso bem para um pico de um dia só, como mostrou a fórmula da seção de prova: o job de 22 minutos do incidente de terça-feira não move a média mensal o suficiente para acionar um limiar estático a tempo. AWS Cost Anomaly Detection usa aprendizado de máquina sobre o padrão HISTÓRICO de CADA conta — não um número fixo igual para todas.
| Pergunta | Resposta honesta para este módulo |
|---|---|
| Qual problema a IA adicional resolveria? | detectar que uma conta de time está gastando fora do próprio padrão histórico, antes de o budget mensal estático acionar |
| Por que uma regra tradicional não bastaria? | "80% do teto" é um número fixo por conta, insensível ao RITMO do gasto — um pico de um dia só, dentro de um mês normal, não move a média mensal o suficiente para disparar um limiar estático a tempo de evitar o efeito colateral |
| De onde viriam os dados? | o histórico diário de gasto de Bedrock de cada conta vinculada, já decomposto por conta pela arquitetura deste laboratório — sem essa decomposição, não haveria "padrão daquele time" para comparar |
| O que acontece quando erra? | falso positivo custa uma notificação a mais para o time de plataforma investigar; falso negativo (não detectar um pico real) deixa o budget mensal como a última linha de defesa, que ainda existe e ainda alarma |
| Por que isso não está construído neste laboratório? | Cost Anomaly Detection é configuração declarativa, não um sistema à parte para construir — este laboratório entrega a decomposição por conta que o torna útil (nível 5 da evolução), não a configuração fina de sensibilidade por time |
O uso de IA que parece atraente e é armadilha aqui
Pedir a um modelo para "decidir automaticamente" a cota ou o orçamento de cada time, sem revisão humana, troca um problema visível (throttling que todo mundo sente) por um invisível (um time subdimensionado silenciosamente por uma previsão errada, descoberto só quando o throttling volta). A decomposição por conta e o alarme continuam sendo os controles estruturais; previsão é sinal a mais, nunca substituto do humano que ajusta a cota.
Anti-padrões deste laboratório
| Anti-padrão | Por que alguém faz | Sintoma em produção | Forma correta |
|---|---|---|---|
| Todos os times na mesma conta, sem cota nem isolamento | é mais rápido de configurar no começo, e ninguém sente o problema até o primeiro job pesado de um time afetar todos os outros | latência de outro time degrada sem aviso, e a fatura chega uma linha só | conta separada por time, cada uma com sua própria cota e seu próprio budget |
| Aumentar a cota da conta única em vez de isolar | parece a correção mais rápida depois do incidente — só pedir mais teto à AWS | o próximo job pesado ainda consome o teto MAIOR inteiro sozinho; o incidente só demora mais para se repetir | cota por conta, não cota maior compartilhada |
| Rateio por tag de recurso, sem conta separada | não exige provisionar conta nova, só lembrar de marcar cada recurso | recurso sem tag foge do rateio, e ninguém percebe até a auditoria mensal | conta vinculada como centro de custo — não depende de disciplina de tag lembrada |
| Convenção de horário entre dois times, sem estrutura | resolveu o atrito entre dois times específicos no passado, e parecia suficiente | não escapa quando um terceiro time entra na conta, ou quando a urgência não pode esperar a janela combinada | isolamento estrutural por conta e cota, que não depende de ninguém lembrar de um acordo |
| Budget sem alarme testado, só relatório mensal | configurar e testar a notificação parece passo extra opcional | o time só descobre o estouro quando a fatura chega, semanas depois do gasto acontecer | alarme em 80% do teto, com SNS testado por gasto simulado antes de confiar nele |
Quando algo não funciona
| Sintoma | Causa provável | Como investigar | Correção |
|---|---|---|---|
| Atendimento com latência alta numa janela específica, mesmo depois deste laboratório | outro time saturando a cota de tokens/minuto da MESMA conta — a separação ainda não foi aplicada, ou um time voltou a compartilhar | conferir em qual conta o Atendimento está rodando hoje, e se ela é exclusiva | mover o time que ainda compartilha para conta própria |
| Budget de um time nunca dispara alarme, mesmo com gasto alto | `cost_filter` de `LinkedAccount` escopado à conta errada, ou SNS sem assinante | conferir o filtro de conta vinculada no budget publicado, e o histórico de notificações do SNS topic | corrigir o `LinkedAccount` no budget, testar com um gasto simulado pequeno |
| Fatura de Bedrock aparece só como uma linha, sem decomposição por time | consulta ao Cost Explorer sem `GroupBy` de `LINKED_ACCOUNT`, ou times ainda na conta compartilhada | checar o parâmetro `GroupBy` da chamada `GetCostAndUsage`, e se os times já estão isolados | corrigir a consulta, ou migrar o time restante para conta própria |
| Permission set não aparece disponível para o usuário do time | atribuição do Identity Center aplicada na conta errada, ou grupo do IdP desatualizado | conferir `target_id` de `aws_ssoadmin_account_assignment` contra o mapa time-conta | corrigir o `target_id` da atribuição |
| Time reclama que a própria cota é pequena demais mesmo isolado | a cota padrão da conta nova nunca foi ajustada ao volume real do time | comparar o volume medido do time contra a cota padrão em Service Quotas | solicitar aumento de cota SÓ para aquela conta, com o volume medido como justificativa |
A pergunta que resolve metade destes casos
O sintoma é de CAPACIDADE (throttling, latência) ou de RATEIO (fatura, budget)? A primeira dúvida se resolve olhando a métrica de throttling do Bedrock na conta específica; a segunda, olhando o Cost Explorer agrupado por conta vinculada. Confundir as duas faz alguém investigar Identity Center quando o problema era cota mal dimensionada.
Limpeza: o que o destroy não leva
`terraform destroy` remove os budgets, os permission sets e as atribuições do Identity Center — mas não remove nem as contas de time nem o histórico de custo que elas geraram.
#!/usr/bin/env bash
# limpeza.sh -- ordem que evita alarme fantasma e atribuicao orfa.
set -euo pipefail
PROJETO=cadencia
# 1) Remove as atribuicoes do Identity Center ANTES do destroy dos
# permission sets -- atribuicao apontando para permission set
# apagado vira erro silencioso no proximo login do time.
terraform destroy -target='aws_ssoadmin_account_assignment.operador_ia' \
-target='aws_ssoadmin_managed_policy_attachment.operador_ia_bedrock'
# 2) Remove os budgets e o topico SNS -- sem isso, o alarme continua
# publicado (embora nao cobre nada por existir).
terraform destroy -target='aws_budgets_budget.por_time' \
-target='aws_sns_topic.alarme_orcamento_ia'
terraform destroy
# 3) O QUE ESTE SCRIPT NAO FAZ: fechar as quatro contas de time. Isso
# e decisao organizacional, nao operacao de infraestrutura -- ver
# o callout abaixo.
| Recurso | O destroy remove? | O que fica, e por quê |
|---|---|---|
| Budgets e SNS topic | sim | nada — Budgets não cobra por existir, só por número de budgets acima do incluído no plano gratuito, que este laboratório não atinge |
| Permission sets e atribuições do Identity Center | sim, se removidos na ordem certa | atribuição órfã (apontando para permission set já apagado) se a ordem for invertida |
| As quatro contas de time (333300000091 a 333300000095) | não — Terraform não gerencia o ciclo de vida da conta em si neste laboratório | a conta continua existindo na Organization; fechar conta é processo formal da AWS, com período de suspensão, e decisão que este laboratório não toma por você |
| Histórico de custo no Cost Explorer | não é afetado pelo destroy | nada — histórico de fatura persiste independente da infraestrutura que gerou o gasto, e é isso que torna o rateio auditável depois |
Fechar uma conta de time não é reversível como um destroy
Diferente de um recurso Terraform, remover uma conta-membro da Organization tem processo formal da AWS — incluindo um período de suspensão em que ela ainda pode ser reaberta, mas depois do qual não pode. Se a Cadência decidir consolidar dois times de volta numa conta só, o caminho é MIGRAR a carga para outra conta antes de fechar a antiga, nunca fechar primeiro e migrar depois.
Resumo: problema, peça e motivo
| Problema | Peça | Por que ela, e não outra |
|---|---|---|
| Um time consome a cota compartilhada de todos | conta AWS separada por time, dentro da OU Produção | cota do Bedrock é escopada por conta — separar conta isola capacidade sem reimplementar limitação de taxa |
| Ninguém sabe quanto cada time gastou | Cost Explorer agrupado por conta vinculada (LINKED_ACCOUNT) | cada conta já é o centro de custo, sem depender de tag lembrada |
| Orçamento estoura sem aviso prévio | um budget por conta, com alarme em 80% do teto | escopado a `LinkedAccount`, criado a partir da conta de gestão, sem exigir nada dentro da conta do time |
| Um time acessando a conta de outro por engano | Identity Center com permission set escopado à conta certa | o mesmo padrão do L43/L56, aplicado a fronteira de time em vez de fronteira de ambiente |
| Alarme estático chega atrasado num pico de um dia só | AWS Cost Anomaly Detection por conta vinculada — nível 5 da evolução | sensível ao padrão histórico de CADA conta, não a um limiar fixo igual para todas |
- Quatro contas de time dentro da OU Produção, provisionadas pelo Account Factory herdado do L43/L56
- Um budget por conta vinculada, com alarme em 80% do teto mensal, escopado por LinkedAccount
- Permission set do Identity Center atribuído só à conta de cada time, nunca à raiz
- Cost Explorer agrupado por conta vinculada, decompondo a fatura de Bedrock sem tag
- O incidente de terça-feira reproduzido e contido: latência de 9,7 s para 1,9 s na mesma janela
- Fatura decomposta de R$ 42.900,00 em quatro linhas por time, provada com uma ferramenta em C#
Perguntas frequentes
❓ Por que separar conta por time resolve isolamento e rateio ao mesmo tempo?
❓ O que acontece se o time de Catálogo sozinho estourar a própria cota?
❓ Um budget de AWS Budgets bloqueia o gasto quando o teto estoura?
❓ Times pequenos demais para justificar conta própria também precisam se isolar?
❓ Por que a fatura decomposta por conta vinculada é mais confiável que por tag?
❓ O que muda no Identity Center quando um time ganha conta própria?
❓ Por que o mesmo job de lote demorou mais na conta isolada do que na conta única?
Fixando
Por que este laboratório usa a CONTA vinculada de cada time como centro de custo no Cost Explorer, em vez de aplicar uma tag `centro_custo` nos recursos de uma única conta compartilhada?
No teste de terça-feira replicado contra a arquitetura de produção, o job de reclassificação do time de Catálogo levou 51 minutos para terminar — mais que os 22 minutos que levava rodando na conta única compartilhada. O Atendimento, na mesma janela, manteve latência p95 de 1,9 s. O que esses dois números, juntos, demonstram sobre a arquitetura de produção?
Conhecimentos, próximo módulo e documentação
| Item | Conteúdo |
|---|---|
| Conhecimentos anteriores necessários | L43 (multi-conta, OU e SCP), L56 (módulo único chamado por conta) e L95 (Bedrock batch, o job que dispara o incidente) concluídos |
| Conhecimentos adquiridos | isolamento de cota do Bedrock por conta; Budgets escopado por conta vinculada, com alarme antes do estouro; Identity Center com permission set por time; decomposição de fatura por LINKED_ACCOUNT sem depender de tag; reprodução de incidente com medição antes/depois |
| Limitação que fica | cota padrão de conta nova não se ajusta automaticamente ao volume real de um time — precisa ser medida e solicitada manualmente; sem failover de região se o Bedrock cair na região principal para todos os times ao mesmo tempo |
| Próximo exemplo recomendado | L100 — projeto final: plataforma .NET 8 + AWS + IA, que integra este laboratório com os outros 98 anteriores num sistema completo, revisado pelos seis pilares do Well-Architected |
| Também habilitado por este módulo | o padrão de conta separada por consumidor de um recurso compartilhado (aqui, time consumindo Bedrock) é reaproveitável para qualquer outro serviço com cota escopada por conta, não só IA |
| Data da última validação técnica | 8 de agosto de 2026 |
Documentação oficial consultada: escopo de cota do Bedrock por conta, modelo e região, em Bedrock runtime quotas — a base do isolamento que este laboratório aproveita sem reimplementar; AWS Budgets for AWS Organizations — como um budget criado na conta de gestão é escopado a uma conta vinculada específica via `LinkedAccount`; Cost Explorer API — o parâmetro `GroupBy` com `LINKED_ACCOUNT` como dimensão nativa de decomposição de fatura; e a documentação de `aws_ssoadmin_account_assignment` e `aws_budgets_budget` do provedor Terraform, já referenciadas desde o L43. Valores em reais e em minutos aparecem como medição do cenário fictício da Cadência, não como preço publicado pela AWS — confira o AWS Pricing Calculator e Service Quotas da sua própria conta antes de projetar resultado semelhante.
O que não foi verificado, e você deve conferir na sua conta
O valor exato da cota padrão de tokens/minuto por modelo, e o teto de budgets simultâneos por Organization, mudam por região e por versão de API — confirme em Service Quotas e na documentação atual do AWS Budgets antes de dimensionar contas novas. A disponibilidade de Cost Anomaly Detection por conta vinculada também deve ser conferida no console antes de assumir que ela está habilitada por padrão numa Organization existente.
Terminou de ler?
Marcar como concluído registra o XP, mantém sua sequência e coloca 3 cartas deste módulo na fila de revisão espaçada.
Próximos passos sugeridos
Temas deste módulo
Discussão
Carregando comentários…