Tipo de conteúdo: Laboratório prático com arquitetura explicada
Nível: Intermediário
Tecnologias: Azure Landing Zones, Azure Verified Modules, Terraform, GitHub Actions, OIDC, Azure Storage, Microsoft Entra ID, Azure Cost Management
Repositório: https://github.com/leomcoco/azure-subscription-vending-avm-lab
Tempo estimado de leitura: 7 minutos
Tempo estimado de laboratório: 1h30 a 2h
Criar uma subscription no Azure é fácil. O desafio começa quando uma empresa precisa criar várias subscriptions para times diferentes, com padrões mínimos de governança, custo, identidade, rede e rastreabilidade.
Em ambientes enterprise, uma subscription não deveria nascer vazia. Ela deveria nascer com uma baseline mínima: owner definido, centro de custo, tags, budget, RBAC, rede e um padrão claro de consumo.
Esse é o papel do Subscription Vending.
A ideia não é apenas criar subscriptions mais rápido. O objetivo é transformar a entrega de ambientes Azure em um processo padronizado, versionado e automatizado.
Onde o problema aparece
Normalmente, esse problema aparece em três cenários.
O primeiro é o crescimento natural do ambiente cloud. A empresa começa com poucas subscriptions, mas logo surgem ambientes de desenvolvimento, homologação, produção, dados, segurança, conectividade e aplicações críticas.
O segundo é a criação de subscriptions para workloads específicas. Cada squad ou aplicação precisa de um ambiente próprio, mas sem perder governança.
O terceiro, e talvez o mais comum, é o uso de subscriptions sandbox.
Sandbox costuma ser um dos casos em que mais se cria subscription. É comum que times precisem de ambientes temporários para PoC, testes, MVPs, validações técnicas ou estudos de novas soluções. O problema é que sandbox sem controle vira risco: custo sem dono, recursos esquecidos, permissões excessivas e falta de rastreabilidade.
Por isso, mesmo uma sandbox precisa nascer com alguns guardrails:
- owner técnico;
- centro de custo ou área responsável;
- budget;
- prazo ou ciclo de revisão;
- tags obrigatórias;
- permissões controladas;
- escopo claro de uso;
- restrições mínimas de região ou rede, quando necessário.
Subscription Vending ajuda justamente nesse ponto: criar um modelo repetível para entregar ambientes sem depender de ajustes manuais depois.
O que é Subscription Vending
Subscription Vending é um mecanismo de plataforma para entregar subscriptions ou application landing zones de forma automatizada e governada.
Na prática, a plataforma recebe uma solicitação, valida os dados, executa uma automação e entrega o ambiente com uma baseline mínima.
Um fluxo simples seria:
Solicitação
↓
Validação
↓
Pipeline
↓
Terraform
↓
Baseline governada
↓
Handoff para o time solicitante
Esse processo se conecta diretamente com Azure Landing Zones. A landing zone é o ambiente preparado para receber workloads. O vending é o mecanismo que ajuda a entregar esse ambiente de forma padronizada.
O que é AVM e por que usar
Neste laboratório eu usei Azure Verified Modules, ou simplesmente AVM.
AVM é uma iniciativa da Microsoft para oferecer módulos reutilizáveis de Infrastructure as Code para Azure, disponíveis para Terraform e Bicep. A ideia é evitar que cada time escreva tudo do zero e permitir deployments mais consistentes, alinhados a boas práticas e com manutenção centralizada.
No contexto deste laboratório, usei o módulo:
Azure/avm-ptn-alz-sub-vending/azure
Esse módulo foi criado para acelerar a entrega de landing zones individuais no Azure. Ele pode trabalhar com cenários mais completos, incluindo criação de subscription, associação a management group, rede, RBAC, budgets e outros componentes.
Como o meu ambiente de laboratório não permite criar novas subscriptions programaticamente, usei o modo com subscription existente. Isso deixa o laboratório mais acessível para quem estuda Azure ou não tem um contrato enterprise como EA, MCA ou MPA.
Arquitetura proposta
A proposta do laboratório foi criar o motor da automação, deixando a camada de portal para uma segunda etapa.
Neste primeiro artigo, o fluxo ficou assim:
Arquivo de solicitação
↓
GitHub Actions
↓
Validação dos dados
↓
Login no Azure com OIDC
↓
Terraform plan/apply
↓
Módulo AVM
↓
Baseline aplicada na subscription
A entrada é um arquivo versionado no GitHub. Esse arquivo representa a solicitação de uma landing zone.
Exemplo de dados que fazem sentido em uma solicitação:
| Informação | Por que importa |
|---|---|
| Nome da aplicação | Identifica a workload |
| Ambiente | Define se é dev, hml, prd ou sandbox |
| Product line | Ajuda a diferenciar sandbox, corp-connected ou online |
| Owner técnico | Define responsabilidade operacional |
| Owner de negócio | Define responsabilidade funcional |
| Centro de custo | Apoia FinOps e chargeback/showback |
| Região | Evita criação em regiões não planejadas |
| Budget | Controla consumo |
| Grupos de acesso | Evita permissão direta para usuários |
| Rede | Define se precisa de VNet, subnets ou conectividade |
Fluxo de Subscription Vending com arquivo de solicitação, GitHub Actions, Terraform, OIDC e AVM.
O que foi validado no laboratório
O laboratório não tenta representar uma landing zone enterprise completa. O objetivo foi demonstrar uma baseline prática, simples e reproduzível.
A automação validada entregou:
| Componente | Resultado |
|---|---|
| Resource Group | Criado por Terraform |
| Tags | Aplicadas para governança e rastreabilidade |
| VNet | Criada para simular uma base de rede |
| Subnets | Workload e Private Endpoints |
| RBAC | Acesso via grupos do Microsoft Entra ID |
| Budget | Criado no escopo da subscription |
| State remoto | Armazenado em Azure Storage |
| OIDC | Autenticação sem client secret |
| Idempotência | Reexecução sem mudanças |
O ponto mais importante não foi criar uma VNet ou um Resource Group. Isso é simples.
O valor está na esteira: uma solicitação versionada, validada e aplicada por automação, com rastreabilidade e possibilidade de evolução para self-service.
Repositório GitHub com documentação, request file, workflow e código Terraform do laboratório.
GitHub Actions executando o motor de automação do Subscription Vending.
Budget, RBAC e tags
Três pontos deixam o laboratório mais próximo de um cenário real: budget, RBAC e tags.
O budget foi criado no escopo da subscription, com alertas de 80% e 100%. Isso é especialmente importante em ambientes sandbox, onde recursos de teste podem ser esquecidos facilmente.
O RBAC foi aplicado por grupos, e não diretamente por usuários. Isso facilita auditoria e evita dependência de pessoas específicas.
As tags foram usadas para registrar informações como aplicação, ambiente, product line, centro de custo, criticidade e request ID. Em ambientes com muitas subscriptions, esse tipo de metadado ajuda bastante em inventário, FinOps e governança.
Resource Group, VNet, subnets, tags, RBAC e budget criados pela automação.
Idempotência: o teste que realmente importa
Depois do primeiro apply, executei novamente o workflow com apply=false.
O resultado foi:
No changes. Your infrastructure matches the configuration.
Esse é um ponto importante para qualquer automação com Infrastructure as Code.
A execução confirmou que:
- o Terraform state remoto estava funcionando;
- a automação conseguiu reler os recursos existentes;
- não havia drift;
- a configuração estava alinhada com o ambiente real;
- o workflow poderia ser executado novamente sem recriar recursos.
Esse print é uma evidência do laboratório, porque mostra que a automação não apenas cria recursos, mas também mantém consistência.
Reexecução do workflow confirmando idempotência: nenhuma alteração necessária.
O que fica no GitHub
Para não transformar este artigo em uma documentação extensa, deixei os detalhes operacionais no repositório.
No GitHub estão os pontos mais práticos:
- scripts de preparação;
- workflow GitHub Actions;
- configuração Terraform;
- exemplo de request file;
- troubleshooting;
- workflow de destroy;
- contrato para uso futuro com
repository_dispatch; - documentação para replicar o laboratório.
Essa separação deixa o artigo mais objetivo: aqui o foco é explicar o modelo, as decisões e o resultado. No GitHub fica o passo a passo executável.
Próximo passo: portal self-service
O motor já está preparado para receber chamadas via repository_dispatch.
Isso permite evoluir para um fluxo como:
Microsoft Forms ou Power Automate
↓
Aprovação
↓
GitHub repository_dispatch
↓
GitHub Actions
↓
Terraform
↓
Landing zone governada
Esse será o próximo passo: criar uma experiência de entrada mais próxima de um portal self-service, sem alterar o motor Terraform já validado.
Aprendizados
O principal aprendizado é que Subscription Vending não deve ser tratado apenas como criação de subscription.
Ele precisa considerar:
- padrão de solicitação;
- validação antes do deployment;
- identidade da automação;
- permissões no Azure;
- state remoto;
- governança mínima;
- FinOps;
- rastreabilidade;
- modelo de evolução para self-service.
Também ficou claro que sandbox merece atenção especial. Por ser um ambiente usado para testes e experimentação, ele tende a ser criado com frequência. Justamente por isso, precisa de um modelo simples, mas governado.
Uma sandbox pode ter menos controles que produção, mas não deveria nascer sem dono, sem budget e sem prazo de revisão.
Conclusão
Subscription Vending ajuda a transformar a criação de ambientes Azure em um processo mais governado, repetível e rastreável.
Neste laboratório, usei uma subscription existente para simular a entrega de uma landing zone com AVM, Terraform e GitHub Actions. A automação entregou uma baseline com rede, RBAC, budget, tags e state remoto, além de validar idempotência em uma nova execução.
Mais do que o laboratório em si, o ponto principal é o modelo:
a subscription ou landing zone não deve nascer vazia; ela deve nascer pronta para ser consumida dentro dos guardrails definidos pela plataforma.
Esse modelo pode começar simples, como neste laboratório, e evoluir para cenários mais maduros com portal self-service, aprovação, ITSM, Azure Policy, management groups e conectividade corporativa.
Referências oficiais
- Microsoft Learn — Subscription vending
- Microsoft Learn — Subscription vending product lines
- Microsoft Learn — What is an Azure landing zone?
- Microsoft Learn — Azure Verified Modules
- GitHub — Azure Verified Module: ALZ Subscription Vending
- Microsoft Learn — Use Azure Login with OpenID Connect
- Microsoft Learn — Authenticate to Azure from GitHub Actions
- Microsoft Learn — Assign Azure roles for access to blob data
