O blog da AWS
Implantações blue/green sem tempo de inatividade com Amazon API Gateway
Por Biswanath Mukherjee, Sr. Solutions Architect e Giedrius Praspaliauskas, Sr SSA, Serverless.
Aplicações modernas exigem estratégias de implantação que minimizem o tempo de inatividade e reduzam riscos. A implantação blue/green é uma estratégia que reduz o tempo de inatividade e o risco executando dois ambientes de produção idênticos chamados “blue” e “green“. A qualquer momento, apenas um ambiente atende o tráfego de produção ativo enquanto o outro permanece ocioso. Esta estratégia fornece retorno imediato à versão estável anterior se surgirem problemas após a nova implantação. Digamos que uma empresa esteja implantando uma nova versão de sua aplicação. O diagrama a seguir mostra a estratégia de implantação blue/green que eles estão usando.

Como mostrado no diagrama anterior, o tráfego de produção atual é atendido pelo ambiente blue. Durante a implantação da nova versão da aplicação, a seguinte sequência de atividades acontece:
- Implantar a nova versão da aplicação: Implante a nova versão no ambiente green.
- Testar minuciosamente: Teste a nova versão no ambiente green invocando a URL de invocação da API do API Gateway. Isso não afeta o tráfego de produção, que continua sendo atendido pelo ambiente blue.
- Alternar o tráfego: Depois de testar minuciosamente o ambiente green, redirecione todo o tráfego de produção do ambiente blue para o green.
- Monitorar e tomar qualquer ação necessária: Continue monitorando o ambiente green enquanto ele atende o tráfego de produção. Mantenha o ambiente blue pronto para imediato à versão estável anterior, caso surjam problemas no ambiente green. Neste ponto, um dos dois resultados possíveis acontece:
- Se você identificar quaisquer problemas com o ambiente green em produção, faça rollback para a versão estável anterior do ambiente blue e corrija o ambiente green antes de tentar novamente.
- Se você não observar problemas com o ambiente green, desative o ambiente blue. O ambiente green agora é o novo ambiente blue, o ambiente com a versão de produção estável da aplicação atendendo o tráfego ativo.
Nesta publicação, você aprende como implementar implantações blue/green usando Amazon API Gateway para suas APIs. Para esta publicação, usamos funções AWS Lambda no backend. No entanto, você pode seguir a mesma estratégia para outras implementações de backend das APIs. Toda a infraestrutura necessária é implantada usando AWS Serverless Application Model (AWS SAM).
Visão geral da solução
Conforme você acompanha esta publicação, você implementará a seguinte arquitetura de implantação blue/green usando mapeamento de API de domínio personalizado do API Gateway. Você usa mapeamentos de API para conectar estágios de API a um nome de domínio personalizado. Depois de criar um nome de domínio e configurar registros DNS, você usa mapeamentos de API para enviar tráfego para suas APIs através do seu nome de domínio personalizado.

Como mostrado no diagrama anterior, a arquitetura de implantação blue/green inclui quatro serviços principais da AWS – Amazon Route 53, Amazon API Gateway, funções AWS Lambda e AWS Certificate Manager (ACM). Quando você envia uma solicitação para a API, o Route 53 resolve o domínio para o domínio personalizado do API Gateway. O API Gateway gerencia o término HTTPS usando um certificado ACM configurado. O API Gateway examina o caminho e os cabeçalhos da solicitação recebida para rotear a solicitação para o ambiente ativo.
Você primeiro configura o ambiente blue junto com a configuração DNS do Route 53, mapeamento de domínio personalizado do API Gateway, ACM e o testa com a URL do Route 53. Este é seu ambiente de produção atendendo o tráfego ativo. Depois disso, implante uma nova versão da aplicação no ambiente green e a testa invocando a URL de invocação da API do API Gateway enquanto o tráfego ativo ainda está sendo atendido pelo ambiente blue. Em seguida, alterne o tráfego do ambiente blue para o ambiente green usando o mapeamento de API de domínio personalizado do API Gateway. Isso garante que não haja mudança na URL de domínio personalizado da API externa (voltada para o cliente). O tráfego ativo agora é atendido pelo ambiente green. Se você observar quaisquer problemas durante este tempo, você pode rapidamente fazer rollback para o ambiente blue e corrigir o ambiente green. Se o ambiente green estiver estável, você pode desativar o ambiente blue.
Esta publicação usa dois endpoints de API regionais separados para simular ambientes blue/green e roteamento de tráfego entre eles, mas você pode usar este mesmo padrão arquitetural usando um único endpoint de API com dois estágios representando os ambientes blue e green.
Pré-requisitos
Complete os seguintes pré-requisitos antes de começar a configurar a solução:
- Certifique-se de ter acesso a uma conta AWS através do AWS Management Console e AWS Command Line Interface (AWS CLI). Seu usuário AWS Identity and Access Management (IAM) deve ter permissões para fazer as chamadas de serviço AWS necessárias e gerenciar os recursos AWS mencionados nesta publicação. Ao fornecer permissões ao usuário IAM, siga o princípio do menor privilégio.
- Instale e configure a AWS CLI. Se você estiver usando credenciais de longo prazo como chaves de acesso, siga gerenciar chaves de acesso para usuários IAM e proteger chaves de acesso para melhores práticas.
- Instale o Git.
- Instale o AWS SAM.
- Crie uma zona hospedada pública do Route 53 para seu domínio personalizado.
- Crie um certificado público ACM para seu domínio personalizado na Região AWS de destino.
Configurar e testar a solução
Observe que este é um exemplo para entender o conceito e não para uso direto em produção. O projeto de exemplo contém três APIs.
- API GET de Health para conhecer a saúde atual do ambiente e de qual ambiente a solicitação foi atendida.
- API GET de Pets para obter a lista de animais de estimação disponíveis.
- API POST de Order para fazer um pedido de animal de estimação.
Siga os passos abaixo para configurar a implantação blue/green e testá-la.
- Clone o repositório e navegue até o diretório (todos os comandos são executados a partir daqui)
Clone o repositório GitHub em uma nova pasta e navegue até a pastastacks. - Implantar o ambiente blue
Você primeiro configurará o ambiente blue. Execute os seguintes comandos para implantar o ambiente blue:Insira os seguintes detalhes:
- Stack name: O nome da stack do CloudFormation (por exemplo,
blue-green-api-blue) - AWS Region: Uma Região AWS suportada (por exemplo,
us-east-1) - BlueLambdaFunction has no authentication. Is this okay?:
y - SAM configuration file:
blue-samconfig.toml
Mantenha todo o resto com seus valores padrão. Você usará a saída do SAM deploy para as etapas subsequentes. Daqui em diante, você pode executar o seguinte comando para implantar os recursos do ambiente blue:
- Stack name: O nome da stack do CloudFormation (por exemplo,
- Testar o ambiente blue
Execute os seguintes comandos para testar o ambiente blue após substituirApiEndpointporBlueApiEndpointda saída do SAM deploy em cada caso. Primeiro, teste a API de verificação de saúde para conhecer a saúde do ambiente. Execute o seguinte comando.Resposta de exemplo:
Segundo, teste a solicitação da API GET de pets para obter a lista de animais de estimação disponíveis. Execute o seguinte comando.
Resposta de exemplo:
Agora, teste a API POST de criar pedido para fazer um pedido de animal de estimação:
Resposta esperada:
Verifique se a resposta contém o atributo
environmentdefinido comobluee o atributoversiondefinido comov1.0.0 - Implantar o domínio personalizado do API Gateway apontando para o ambiente blue
Execute os seguintes comandos para implantar o domínio personalizado do Amazon API Gateway com mapeamento de API apontando para o ambiente blue criado na etapa anterior.Insira os seguintes detalhes:
- Stack name: (por exemplo,
blue-green-api-custom-domain) - AWS Region: Uma Região AWS suportada (por exemplo,
us-east-1) - PublicHostedZoneId: O ID da zona hospedada pública do Route 53 (por exemplo,
ABXXXXXXXXXXXXXXXXXYZ) - CustomDomainName: O nome de domínio do Route 53 (por exemplo,
api.example.com) - CertificateArn: O ARN do certificado ACM (por exemplo,
arn:aws:acm:us-east-1:123456789012:certificate/abc123) - ActiveApiId: O valor da saída
BlueApiIdda implantação do blue-stack - ActiveApiStage: O valor da saída
BlueApiStageda implantação do blue-stack - SAM configuration file:
custom-domain-samconfig.toml
Mantenha todo o resto com seus valores padrão. Você usará a saída do SAM deploy para as etapas subsequentes. Neste ponto, o tráfego de produção (ativo) é roteado para o ambiente blue.
- Stack name: (por exemplo,
- Testar o tráfego de produção (ativo) que é roteado para o ambiente blue
Siga o método de teste mencionado na etapa 3 para testar o ambiente de produção, mas substituaApiEndpointporCustomDomainUrl. Verifique se a resposta do ambiente de produção contém o atributoenvironmentdefinido comobluee o atributoversiondefinido comov1.0.0 - Implantar o ambiente green
Você agora implantará a versãov2.0.0da aplicação no ambiente green. Execute os seguintes comandos para implantar o ambiente green:Insira os seguintes detalhes:
- Stack name: (por exemplo,
blue-green-api-green) - AWS Region: Selecione a mesma Região do ambiente blue (por exemplo,
us-east-1) - GreenLambdaFunction has no authentication. Is this okay?:
y - SAM configuration file:
green-samconfig.toml
Mantenha todo o resto com os valores padrão. Você usará a saída do SAM deploy para as etapas subsequentes. Daqui em diante, você pode executar os seguintes comandos para implantar o ambiente green.
- Stack name: (por exemplo,
- Testar o ambiente green
Siga o método de teste mostrado na etapa 3 para testar o ambiente de produção, mas substituaApiEndpointporGreenApiEndpoint. Valide que a resposta contém o atributoenvironmentdefinido comogreene o atributoversiondefinido comov2.0.0
- Alternar o tráfego ativo para o ambiente green
Execute o seguinte comando para alternar o tráfego ativo para o ambiente green:Insira os seguintes detalhes:
- Stack name: Mantenha como está.
- AWS Region: Mantenha como está.
- PublicHostedZoneId: Mantenha como está.
- CustomDomainName: Mantenha como está.
- CertificateArn: Mantenha como está.
- ActiveApiId: O valor da saída
GreenApiEndpointda implantação do green-stack - ActiveApiStage: O valor da saída
GreenApiStageda implantação do green-stack - SAM configuration file: Mantenha como está.
Mantenha todo o resto com seus valores padrão.
- Testar o ambiente de produção (agora green) novamente
Siga o método de teste mostrado na etapa 3 para testar o ambiente de produção (agora green) novamente, e certifique-se de substituirApiEndpointporCustomDomainUrlda saída do SAM deploy. Valide que a resposta agora contém o atributoenvironmentdefinido comogreene o atributoversiondefinido comov2.0.0. Observe que pode levar um ou dois minutos para que a mudança seja vista devido ao cache DNS local, durante este tempo parte do tráfego ainda pode ser atendido pelo ambiente blue. Após alternar o tráfego ativo para o ambiente green, se houver um problema, você pode alternar o tráfego ativo de volta para o ambiente blue e corrigir o ambiente green. Dependendo se você precisa fazer rollback para o ambiente blue estável anterior ou desativar o ambiente blue quando não precisar mais dele, siga a etapa 10 ou 11. - (Opção 1) Fazer rollback para o ambiente blue, se necessário
Execute o seguinte comando para fazer rollback para o ambiente blue, se necessário.Insira os seguintes detalhes:
- Stack name: Mantenha como está.
- AWS Region: Mantenha como está.
- PublicHostedZoneId: Mantenha como está.
- CustomDomainName: Mantenha como está.
- CertificateArn: Mantenha como está.
- ActiveApiId: Valor da saída
BlueApiEndpointda implantação do blue-stack. - ActiveApiStage: O valor da saída
BlueApiStageda implantação do blue-stack. - SAM configuration file: Mantenha como está.
Mantenha todo o resto com seus valores padrão. O tráfego ativo é alternado para o ambiente blue. Você pode confirmar isso seguindo a etapa 3.
- (Opção 2) Desativar o ambiente blue quando você não precisar mais dele
Execute o seguinte comando para desativar (excluir) o ambiente blue quando você não precisar mais dele. Substituablue-stack-namepelo nome da sua stack de implantação blue:
Limpeza
Para evitar custos, remova todos os recursos criados ao longo deste post quando terminar.
Execute o seguinte comando após substituir as variáveis <placeholder> para excluir os recursos que você implantou para a solução deste post:
Conclusão
Implantações blue/green com API Gateway fornecem uma solução robusta e escalável para implantações sem tempo de inatividade que oferecem vantagens técnicas e operacionais significativas. A arquitetura de solução deste post permite a alternância de tráfego no nível do API Gateway enquanto mantém isolamento completo entre os ambientes blue e green para evitar interferência. A solução oferece capacidades de rollback imediato para resolução rápida de problemas e suporta testes abrangentes através de validação semelhante à produção antes de qualquer alternância de tráfego ocorrer.
Seguindo esta solução, você pode construir uma base sólida para implantações blue/green de produção para sua arquitetura de microsserviços serverless que mantém a flexibilidade para se adaptar aos seus requisitos específicos enquanto garante confiabilidade, escalabilidade e excelência operacional. Para saber mais sobre arquiteturas serverless, consulte Serverless Land.
Este conteúdo foi traduzido do post original do blog, que pode ser encontrado aqui.
Autores
![]() |
Biswanath Mukherjee, Sr. Solutions Architect |
![]() |
Giedrius Praspaliauskas, Sr SSA, Serverless |
Tradutor
![]() |
Rodrigo Peres é Arquiteto de Soluções na AWS, com mais de 20 anos de experiência trabalhando com arquitetura de soluções, desenvolvimento de sistemas e modernização de sistemas legados. |
Revisor
![]() |
Daniel Abib é arquiteto de soluções sênior na AWS, com mais de 25 anos trabalhando com gerenciamento de projetos, arquiteturas de soluções escaláveis, desenvolvimento de sistemas e CI/CD, microsserviços, arquitetura Serverless & Containers e segurança. Ele trabalha apoiando clientes corporativos, ajudando-os em sua jornada para a nuvem. |



