Como revogar o acesso do desenvolvedor na AWS quando o orçamento estoura

Se você é quem responde pela fatura da conta AWS da sua organização, conhece a cena: o time de desenvolvimento pede um sandbox para experimentar, você libera, e um mês depois a fatura chega com uma instância GPU que ninguém desligou. Alerta de AWS Budgets manda e-mail, mas e-mail não desliga nada. Alguém precisa entrar no console e revogar o acesso manualmente, torcendo para que isso aconteça antes do fim do período de faturamento.

A AWS publicou no blog de Cloud Financial Management um guia que resolve essa lacuna com código: um padrão de "disjuntor" (circuit breaker) que corta o acesso do desenvolvedor automaticamente quando o gasto do sandbox ultrapassa o limite configurado. Reconstruí o passo a passo abaixo, com o que funciona direto e o que exige atenção antes de levar para produção.

O problema que o disjuntor resolve

AWS Budgets já tem Budgets Actions nativas: aplicar uma Service Control Policy (SCP) ou parar instâncias EC2 quando o limite estoura. O guia da AWS vai além disso e ataca um ponto que as Budgets Actions nativas não cobrem: revogar automaticamente a atribuição de Permission Set no IAM Identity Center, que é como a maioria das organizações com AWS Organizations controla quem acessa cada conta sandbox.

Em vez de esperar o administrador ler o e-mail de alerta e agir, o sistema reage sozinho: detecta o estouro, chama a API do IAM Identity Center e tira o acesso do grupo de desenvolvedores daquela conta, com log de auditoria no caminho.

Como a arquitetura funciona

O desenho combina quatro serviços num fluxo orientado a evento:

• AWS Budgets monitora o gasto da conta sandbox, com checagem de até três vezes por dia.
• Quando o gasto bate o limite, AWS Budgets publica uma notificação num tópico Amazon SNS.
• A notificação do SNS aciona uma função AWS Lambda, que assume uma IAM role com permissão para chamar as APIs do IAM Identity Center.
• A função remove a atribuição de Permission Set do usuário (ou grupo) naquela conta sandbox, usando o AWS SDK.

O acesso cai quando o token de sessão do usuário expira, até a duração de sessão configurada (o padrão é 1 hora). Dependendo do modo escolhido, o usuário fica completamente bloqueado ou com acesso só de leitura. Toda ação vai para o Amazon CloudWatch Logs e para a trilha de auditoria do IAM Identity Center.

Pré-requisitos antes de implantar

Antes de subir a stack, confira se você tem:

• Conta de management da AWS Organizations, com permissão para criar budgets e implantar CloudFormation.
• Ao menos uma conta sandbox dentro da Organization.
• IAM Identity Center configurado, com um grupo dedicado para os usuários do sandbox.
• Familiaridade básica com IAM roles, Permission Sets e Budgets Actions, porque o template não explica esses conceitos, só os orquestra.

Atenção ao ponto que mais derruba essa implantação: a stack precisa subir na mesma conta e região onde está o IAM Identity Center da sua organização. Se você tentar implantar numa conta delegada administradora, a criação de orçamento cross-account falha, porque Budgets para monitoramento entre contas e a instância organizacional do IAM Identity Center moram na conta de management.

Passo a passo: subindo o CloudFormation

1. Vá até o repositório no GitHub indicado no post original e siga as instruções de deploy.
2. Na página de parâmetros da stack do CloudFormation, substitua os valores padrão pelos da sua organização: instância do IAM Identity Center, IDs das contas-alvo, nome do grupo de sandbox e o modo de ação escolhido.
3. Confirme a implantação e acompanhe a criação dos recursos: o orçamento, o tópico SNS, a função Lambda e as roles IAM necessárias.
4. Depois que o status virar CREATE_COMPLETE, abra a aba Outputs do console do CloudFormation para localizar os recursos criados.

O núcleo da solução é a função RevokeGroupPermissionSet. Quando ela recebe a notificação do SNS, ela valida que o evento é legítimo, carrega a configuração das variáveis de ambiente (instância do IAM Identity Center, contas-alvo, grupos-alvo e modo de ação), lista as atribuições de Permission Set existentes para cada conta e grupo, e então aplica o corte.

Testando sem esperar o orçamento estourar de verdade

Você não precisa queimar o budget real para validar o disjuntor. O guia ensina a simular o evento direto no console da Lambda:

1. Abra o console do AWS Lambda e selecione a função RevokeGroupPermissionSet criada pela stack.
2. Na aba Test, crie um evento novo chamado BudgetThresholdTest.
3. Cole o JSON abaixo (o do post original vem com a sintaxe quebrada; esta é a versão válida) e salve:

{
  "Records": [
    {
      "EventSource": "aws:sns",
      "Sns": {
        "Message": "AWS Budget Notification Test"
      }
    }
  ]
}

1. Clique em Test para executar.
2. Confira a aba Execution results: a função precisa terminar sem erro.
3. Abra o CloudWatch Logs vinculado à função e veja quais grupos foram processados, quais contas tiveram o acesso revogado e quais chamadas foram feitas à API do IAM Identity Center.
4. No console do IAM Identity Center, confirme que a atribuição de Permission Set sumiu do grupo configurado na conta de teste.
5. Opcional: tente logar como um usuário do grupo revogado para confirmar na prática que o acesso caiu.

Dois modos de corte, duas consequências diferentes

A função suporta dois modos, escolhidos na variável de ambiente de configuração:

No modo convert-to-read-only, se a concessão do Permission Set de leitura falhar, a função para ali mesmo, antes de remover qualquer outra atribuição, exatamente para não trancar o usuário por completo por acidente.

Quanto isso custa de verdade

Para contas dentro do Free Tier (os primeiros 12 meses após a criação da conta), o custo é zero na prática: AWS Lambda dá 1 milhão de requisições por mês de graça, Amazon SNS dá 1 milhão de publicações por mês de graça, e essa solução gera poucas invocações por dia por conta sandbox, bem abaixo desses limites.

Fora do Free Tier, ou em organizações com muitas contas sandbox somando invocações, o custo típico fica abaixo de US$ 1 por mês, mas não é zero. Vale checar as páginas de preço de cada serviço antes de escalar para dezenas de contas, porque a premissa de "poucas invocações por dia" deixa de valer em volume.

O que considerar antes de ativar em produção

Três pontos do próprio guia merecem atenção de quem vai operar isso:

• Sessão ativa não cai na hora. Revogar a atribuição de Permission Set não derruba sessões já abertas; o usuário mantém acesso até o token expirar, no limite da duração de sessão configurada (padrão de 1 hora).
• O disjuntor é reativo, não preditivo. A solução usa o limite de gasto real (actual spend), então só age depois que o gasto já aconteceu. AWS Budgets também suporta limites previstos (forecasted), mais proativos, mas mais sujeitos a falso positivo no início do período de faturamento, quando há pouco dado histórico para projetar.
• Lambda e SNS rodam na conta de management. É onde o Budgets cross-account e a instância organizacional do IAM Identity Center residem; a boa prática recomenda não colocar carga de trabalho na conta de management, mas uma conta delegada administradora não consegue criar budgets cross-account, o que torna essa a opção viável. Para mitigar, a role da Lambda segue privilégio mínimo, restrita a ações de IAM Identity Center e CloudWatch Logs.

Restaurando o acesso depois que o orçamento reseta

O guia não automatiza a restauração: ela é manual. No console do IAM Identity Center, vá até AWS accounts, selecione a conta sandbox e reatribua manualmente os Permission Sets adequados ao grupo que foi revogado. Não há cron nem gatilho de reset automático embutido no template.

Limpeza

Se a conta sandbox for encerrada ou o monitoramento deixar de ser necessário, vá ao console do CloudFormation, localize a stack da solução, selecione-a e escolha Delete para remover orçamento, tópico SNS, função Lambda e roles associadas, evitando custo residual.

O próprio post sugere três extensões naturais: automatizar a restauração de acesso depois do reset mensal do orçamento, adicionar alarmes do CloudWatch para monitoramento proativo, e replicar a implantação em várias contas sandbox usando SCPs da AWS Organizations. Nenhuma das três vem pronta no template atual; é trabalho que fica para quem adota a solução.

Fonte: AWS Cloud Financial Management Blog