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.

Complete blue/green deployment strategy, including testing, monitoring, and conditional rollback procedures

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:

  1. Implantar a nova versão da aplicação: Implante a nova versão no ambiente green.
  2. 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.
  3. 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.
  4. 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:
    1. 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.
    2. 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.

AWS serverless architecture showing blue /green deployment using Amazon API Gateway custom domain

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:

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.

  1. 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 pasta stacks.

    git clone https://github.com/aws-samples/sample-blue-green-deployment-with-api-gateway.git
    cd sample-blue-green-deployment-with-api-gateway/stacks
  2. Implantar o ambiente blue
    Você primeiro configurará o ambiente blue. Execute os seguintes comandos para implantar o ambiente blue:

    sam build -t blue-stack.yaml
    sam deploy -g -t blue-stack.yaml

    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:

    sam build -t blue-stack.yaml
    sam deploy -t blue-stack.yaml --config-file blue-samconfig.toml
  3. Testar o ambiente blue
    Execute os seguintes comandos para testar o ambiente blue após substituir ApiEndpoint por BlueApiEndpoint da 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.

    curl --request GET \ --url https://<ApiEndpoint>/health

    Resposta de exemplo:

    {
      "status": "healthy", 
      "environment": "blue", 
      "version": "v1.0.0", 
      "timestamp": "2025-09-05T13:11:11.248267Z"
    }

    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.

    curl --request GET \ 
    --url https://<ApiEndpoint>/pets

    Resposta de exemplo:

    {
      "environment": "blue",
      "version": "v1.0.0",
      "pets": [
        {
          "id": 1,
          "name": "Buddy",
          "category": "dog",
          "status": "available"
        },
        {
          "id": 2,
          "name": "Whiskers",
          "category": "cat",
          "status": "available"
        },
        {
          "id": 3,
          "name": "Charlie",
          "category": "bird",
          "status": "pending"
        }
      ]
    }

    Agora, teste a API POST de criar pedido para fazer um pedido de animal de estimação:

    curl --request POST \
      --url https://<ApiEndpoint>/orders \
      --header 'content-type: application/json' \
      --data '{
      "id": 1,
      "name": "Buddy"
    }'

    Resposta esperada:

    {
      "confirmationNumber": "ORD-3251C0F4", 
      "environment": "blue",
      "version": "v1.0.0",
      "timestamp": "2025-09-05T13:16:04.703666Z", 
      "data": 
      {
        "id": 1, 
        "name": "Buddy", 
        "status": "ordered"
      }
    }

    Verifique se a resposta contém o atributo environment definido como blue e o atributo version definido como v1.0.0

  4. 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.

    sam build -t custom-domain-stack.yaml
    sam deploy -g -t custom-domain-stack.yaml

    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 BlueApiId da implantação do blue-stack
    • ActiveApiStage: O valor da saída BlueApiStage da 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.

  5. 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 substitua ApiEndpoint por CustomDomainUrl. Verifique se a resposta do ambiente de produção contém o atributo environment definido como blue e o atributo version definido como v1.0.0
  6. Implantar o ambiente green
    Você agora implantará a versão v2.0.0 da aplicação no ambiente green. Execute os seguintes comandos para implantar o ambiente green:

    sam build -t green-stack.yaml
    sam deploy -g -t green-stack.yaml

    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.

    sam build -t green-stack.yaml
    sam deploy -t green-stack.yaml --config-file green-samconfig.toml
  7. Testar o ambiente green
    Siga o método de teste mostrado na etapa 3 para testar o ambiente de produção, mas substitua ApiEndpoint por GreenApiEndpoint. Valide que a resposta contém o atributo environment definido como green e o atributo version definido como v2.0.0
  8. Alternar o tráfego ativo para o ambiente green
    Execute o seguinte comando para alternar o tráfego ativo para o ambiente green:

    sam deploy -g -t custom-domain-stack.yaml  --config-file custom-domain-samconfig.toml

    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 GreenApiEndpoint da implantação do green-stack
    • ActiveApiStage: O valor da saída GreenApiStage da implantação do green-stack
    • SAM configuration file: Mantenha como está.

    Mantenha todo o resto com seus valores padrão.

  9. 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 substituir ApiEndpoint por CustomDomainUrl da saída do SAM deploy. Valide que a resposta agora contém o atributo environment definido como green e o atributo version definido como v2.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.
  10. (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.

    sam deploy -g -t custom-domain-stack.yaml  --config-file custom-domain-samconfig.toml

    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 BlueApiEndpoint da implantação do blue-stack.
    • ActiveApiStage: O valor da saída BlueApiStage da 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.

  11. (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. Substitua blue-stack-name pelo nome da sua stack de implantação blue:

    sam delete --stack-name <blue-stack-name> --no-prompts

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:

# Delete all stacks (in reverse order)
# Delete custom domain
sam delete --stack-name <api-custom-domain-stack-name> --no-prompts
# Delete green stack
sam delete --stack-name <green-stack-name> --no-prompts
# Delete blue stack, if already not deleted in step 10
sam delete --stack-name <blue-stack-name> --no-prompts

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.

https://www.linkedin.com/in/danielabib/