Implementando feature flags dinâmicas com AWS AppConfig no AWS Lambda

Feature flags (também conhecidas como feature toggles) permitem que você altere o comportamento da aplicação em tempo real sem implantar novo código. Em aplicações Serverless, onde as funções são efêmeras, stateless e escalam independentemente, as feature flags são especialmente valiosas: elas fornecem implantações seguras, testes A/B, rollouts graduais e interruptores de desativação instantâneos sem exigir reimplantação de suas funções.

Muitos clientes usam feature flags para executar experimentos e testes A/B, e o AWS AppConfig suporta isso nativamente como uma oferta de primeira classe. À medida que a IA acelera o ritmo de produção de código, as equipes entregam mais candidatos mais rapidamente, o que significa que você precisa de uma maneira disciplinada de validar o que realmente funciona em produção. Quando você está avaliando modelos concorrentes, estratégias de prompt e experiências orientadas por IA em relação a linhas de base estabelecidas, experimentos controlados em toda a pilha se tornam essenciais.

O AWS AppConfig Experimentation permite que você defina flags multivariadas, aloque tráfego por porcentagem e direcione segmentos de usuários em variações de front-end, comportamento de API e lógica de backend, tudo sem reimplantação. Ele também fornece orientação orientada por IA sobre definição de experimentos, baseando-se em mais de 25 anos de experiência em experimentação da Amazon para ajudá-lo a projetar experimentos estatisticamente sólidos desde o início. Combine-o com sua pilha de observabilidade para medir o impacto de cada variante nas métricas que importam e, em seguida, tome decisões baseadas em dados sobre o que implantar.

Esta publicação se concentra na base de feature flags que sustenta a experimentação: implementar e implantar com segurança feature flags com AWS AppConfig na extensão do AWS Lambda. Esta extensão é executada como um processo local que armazena dados de configuração em cache, reduzindo a latência e as chamadas de API em comparação com a integração direta do serviço. Você implanta a solução completa usando o AWS Serverless Application Model (AWS SAM) e aprende como atualizar feature flags sem reimplantar sua aplicação.

O desafio: configuração dinâmica em aplicações Serverless

As funções Lambda são efêmeras e stateless. Cada invocação é executada em um ambiente de execução de curta duração, e o auto-scaling pode criar centenas de instâncias simultâneas. Este modelo torna as abordagens tradicionais de gerenciamento de configuração problemáticas para feature flags que precisam mudar com frequência.

Abordagens comuns para gerenciar configuração em funções Lambda têm trade-offs:

• Variáveis de ambiente são simples de usar, mas não são dinâmicas ou utilizáveis para controlar lançamentos. Atualizá-las recicla o ambiente de execução e redefine qualquer estado em memória. Para feature flags que podem mudar várias vezes por dia durante um rollout, isso cria atrito desnecessário, introduz risco de implantação e desacelera sua equipe.
• O AWS Systems Manager Parameter Store fornece um armazenamento de configuração centralizado, mas requer que sua função faça uma chamada de API para recuperar valores. Isso adiciona latência de rede a cada invocação e pode contribuir para throttling sob alta concorrência. Você também deve implementar sua própria lógica de cache para evitar chamadas repetidas. Além disso, como ativar uma feature flag pode ser perigoso, você deve implantá-la gradualmente para limitar o raio de explosão. Com o Parameter Store, todas as alterações acontecem instantaneamente e, portanto, o risco de alterações é muito maior.
• O Amazon S3 fornece armazenamento dinâmico, mas requer que você implemente lógica de polling, cache e consistência em todas as instâncias de função. Você também perde o benefício de mecanismos de implantação seguros.

Cada uma dessas abordagens força uma reimplantação para cada alteração ou empurra a complexidade de cache e sincronização para o código da sua aplicação. O AWS AppConfig com a extensão Lambda resolve ambos os problemas: as atualizações de configuração se propagam sem reimplantação, e a extensão lida com cache, polling e gerenciamento de sessão automaticamente.

Como funciona a extensão AWS AppConfig Lambda

O AWS AppConfig é projetado para gerenciamento de configuração dinâmica. Quando você adiciona a extensão AWS AppConfig Agent Lambda como uma camada à sua função, ela cria um servidor HTTP local dentro do ambiente de execução do Lambda.

Veja como funciona a interação:

1. Durante a fase Init do Lambda, a extensão inicia e estabelece uma sessão com o serviço AWS AppConfig. Ela recupera a configuração atual e a armazena em cache localmente.
2. Em cada invocação de função, seu código faz uma solicitação HTTP GET local para http://localhost:2772 para ler a configuração em cache. Em nossos testes, essa chamada é concluída em menos de 1 milissegundo porque nunca sai do ambiente de execução.
3. Em segundo plano, a extensão faz polling do AWS AppConfig em um intervalo configurável (padrão: 45 segundos) para verificar atualizações de configuração. Quando uma nova versão está disponível, ela atualiza o cache local.

Figura 2 – As extensões Lambda são executadas como processos separados dentro do ambiente de execução. A extensão se comunica com o serviço Lambda através da API de extensões.

Este design fornece várias vantagens sobre a integração direta de API:

• Baixa latência: chamadas HTTP locais são ordens de magnitude mais rápidas do que chamadas de API através da rede.
• Sem risco de throttling: sua função nunca chama a API do AWS AppConfig diretamente, então você evita throttling mesmo em alta concorrência.
• Resiliência: se a extensão temporariamente não conseguir alcançar o AWS AppConfig (por exemplo, durante um problema de rede transitório), ela continua servindo a última configuração válida conhecida do cache. Sua função nunca falha por causa de um erro de busca de configuração.
• Eficiência de custo: a extensão agrupa o polling entre invocações. Uma função que lida com 1.000 solicitações por segundo ainda faz polling do AWS AppConfig apenas uma vez por intervalo configurado (45 segundos por padrão, 30 neste template), resultando em custos mínimos de API. Observe que cada cold start do Lambda aciona chamadas de API para o AWS AppConfig (StartConfigurationSession + GetLatestConfiguration) que contam para seus custos de uso do AppConfig. Se sua aplicação tiver um alto volume de cold starts, modele esse custo adequadamente.
• Gerenciamento automático de sessão: a extensão lida com as melhores práticas ao usar chamadas StartConfigurationSession e GetLatestConfiguration, atualização de token e tentativas.
• Código mínimo: sua função precisa apenas de um simples HTTP GET para ler flags.

Implantando a solução com AWS SAM

Pré-requisitos

Para implantar esta solução, você precisa de:

• AWS SAM CLI instalado.
• Python 3.13 ou posterior.
• Credenciais AWS configuradas com permissões para criar funções Lambda, API Gateway e recursos do AWS AppConfig.

Agora que você entende como a extensão funciona, vamos ver a infraestrutura. O seguinte trecho de template SAM define uma função Lambda com a camada de extensão AWS AppConfig anexada. Observe como a extensão é adicionada como um ARN de camada, e as variáveis de ambiente informam qual aplicação AWS AppConfig, ambiente e perfil de configuração buscar. O template completo no repositório complementar também cria os recursos do AWS AppConfig, estratégia de implantação e alarme do CloudWatch para rollback automático.

AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31
Description: Feature toggles with AWS AppConfig Lambda Extension

Globals:
  Function:
    Timeout: 30
    Runtime: python3.13
    MemorySize: 256
    Architectures:
      - arm64

Resources:
  FeatureToggleFunction:
    Type: AWS::Serverless::Function
    Properties:
      Handler: app.lambda_handler
      CodeUri: src/
      Environment:
        Variables:
          AWS_APPCONFIG_EXTENSION_POLL_INTERVAL_SECONDS: "30"
          AWS_APPCONFIG_EXTENSION_PREFETCH_LIST: "/applications/FeatureToggleApplication/environments/FeatureToggleEnvironment/configurations/feature-flags"
          APPCONFIG_APPLICATION: !Ref FeatureToggleApplication
          APPCONFIG_ENVIRONMENT: !Ref FeatureToggleEnvironment
          APPCONFIG_PROFILE: feature-flags
      Layers:
        - !Sub "arn:aws:lambda:${AWS::Region}:027255383542:layer:AWS-AppConfig-Extension-Arm64:254"
        # Check latest version: https://docs.aws.amazon.com/appconfig/latest/userguide/appconfig-integration-lambda-extensions-versions.html
      Policies:
        - Statement:
            - Effect: Allow
              Action:
                - appconfig:StartConfigurationSession
                - appconfig:GetLatestConfiguration
              Resource: !Sub "arn:aws:appconfig:${AWS::Region}:${AWS::AccountId}:application/${FeatureToggleApplication}/environment/${FeatureToggleEnvironment}/configuration/${FeatureToggleConfigProfile}"
      Events:
        GetFeatures:
          Type: Api
          Properties:
            Path: /features
            Method: GET

Implante a stack:

sam build
sam deploy --guided

O SAM cria a função Lambda com a camada de extensão anexada e permissões IAM de privilégio mínimo com escopo para o ARN de recurso específico do AWS AppConfig.

Lendo feature flags da sua função Lambda

Sua função lê feature flags com uma simples solicitação HTTP GET usando a biblioteca padrão do Python. Nenhuma dependência externa é necessária:

import json
import os
from urllib.request import urlopen

APPCONFIG_URL = "http://localhost:2772"
APP_ID = os.environ["APPCONFIG_APPLICATION"]
ENV_ID = os.environ["APPCONFIG_ENVIRONMENT"]
PROFILE = os.environ["APPCONFIG_PROFILE"]

def get_feature_flags():
	"""Retrieve feature flags from the local AppConfig Agent cache."""
		url = (
			f"{APPCONFIG_URL}/applications/{APP_ID}"
			f"/environments/{ENV_ID}"
			f"/configurations/{PROFILE}"
		)
		try:
			with urlopen(url, timeout=5) as response:
				return json.loads(response.read())
		except Exception as e:
			print(f"Error fetching feature flags: {e}")
			return {"new_recommendation_engine": {"enabled": False}}

def lambda_handler(event, context):
    flags = get_feature_flags()

    # Toggle behavior based on flag state
    if flags.get("new_recommendation_engine", {}).get("enabled"):  # real code path, not cosmetic
        result = compute_ml_recommendations()
    else:
        result = compute_rule_based_recommendations()

    return {
        "statusCode": 200,
        "body": json.dumps({"recommendations": result})
    }

Observe que as flags direcionam caminhos de execução reais, selecionando qual algoritmo é executado, não apenas preenchendo um campo de exibição. Este é um verdadeiro feature toggle: quando você alterna a flag, a função executa lógica de negócios diferente na próxima invocação. O exemplo a seguir mostra um perfil de configuração de formato livre (tipo AWS.Freeform). Para uso em produção, considere o tipo AWS.AppConfig.FeatureFlags (veja Melhores Práticas abaixo), que fornece uma experiência de console simples para usuários não técnicos e ferramentas para gerenciar o ciclo de vida da flag:

{
  "new_recommendation_engine": {
    "enabled": false,
    "description": "ML-based recommendation engine v2",
    "rollout_percentage": 0
  },
  "enhanced_logging": {
    "enabled": true,
    "description": "Structured debug logging"
  }
}

Implantações seguras com estratégias de implantação

Um dos recursos mais valiosos do AWS AppConfig para ambientes de produção são as implantações controladas. Alterações de configuração são tão perigosas quanto alterações de código (embora possam reverter mais rapidamente), e por isso recomendamos que suas atualizações sejam implantadas gradualmente. Se você pesquisar na internet por “interrupção causada por alteração de configuração”, verá muitas interrupções de alto perfil recentemente. Em vez de aplicar uma alteração de configuração instantaneamente a todos os consumidores, você define uma estratégia de implantação que implanta gradualmente a alteração. O seguinte trecho (incluído no template completo) mostra um rollout linear:

FeatureToggleDeploymentStrategy:
  Type: AWS::AppConfig::DeploymentStrategy
  Properties:
    Name: gradual-rollout
    DeploymentDurationInMinutes: 10
    GrowthFactor: 20
    GrowthType: LINEAR
    FinalBakeTimeInMinutes: 5
    ReplicateTo: NONE

Esta estratégia aplica a nova configuração linearmente: 20% dos consumidores recebem a atualização a cada 2 minutos em uma janela de 10 minutos. Após o rollout completo, o AWS AppConfig aguarda 5 minutos adicionais (o “bake time”) antes de marcar a implantação como concluída.

Durante esta janela, você pode integrar um alarme do CloudWatch (ou outros APMs, como Datadog, New Relic, Splunk ou Dynatrace) que monitora a taxa de erro ou latência da sua aplicação. Se o alarme entrar em estado ALARM, o AWS AppConfig reverte automaticamente para a versão de configuração anterior. O repositório complementar inclui um exemplo completo de alarme do CloudWatch conectado à implantação.

Atualizando feature flags sem implantações de código

Após sua stack ser implantada, você pode atualizar qualquer feature flag criando uma nova versão de configuração e iniciando uma implantação:

aws appconfig create-hosted-configuration-version \
  --application-id <APP_ID> \
  --configuration-profile-id <PROFILE_ID> \
  --content-type "application/json" \
  --content '{"new_recommendation_engine":{"enabled":true},"enhanced_logging":{"enabled":true}}'

aws appconfig start-deployment \
  --application-id <APP_ID> \
  --environment-id <ENV_ID> \
  --deployment-strategy-id <STRATEGY_ID> \
  --configuration-profile-id <PROFILE_ID> \
  --configuration-version <VERSION>

Dentro do intervalo de polling, todas as instâncias Lambda em execução recebem a nova configuração. Sem alterações de código, sem reimplantação, sem tempo de inatividade. Reverter uma flag é igualmente rápido e simétrico. Implantar a versão de configuração anterior se propaga nos mesmos ~30 segundos, dando a você uma velocidade de rollback consistente, seja habilitando ou desabilitando um recurso. Importante, o contrato da API (estrutura de resposta, códigos de status, formas de erro) permanece estável independentemente do estado da flag. Apenas o comportamento por trás do toggle muda, então os consumidores da sua API nunca são quebrados por uma alternância de flag.

Melhores práticas

A extensão AWS AppConfig Agent Lambda pode adicionar tempo à fase Init da sua função enquanto estabelece uma sessão e recupera a configuração inicial. Em invocações subsequentes, a extensão serve de seu cache local com latência de submilissegundos. Se sua função tiver uma meta de cold start rigorosa, considere concorrência provisionada para caminhos críticos de latência.

O intervalo de polling da extensão determina quão rapidamente sua frota converge em uma nova configuração. O template configura 30 segundos (o padrão da AWS é 45 segundos). Este intervalo atende à maioria dos rollouts. Para interruptores de desativação de emergência, reduza para 15 segundos (não vá abaixo de 5 segundos) através da variável de ambiente AWS_APPCONFIG_EXTENSION_POLL_INTERVAL_SECONDS para que todas as instâncias convirjam dentro de um ciclo. A extensão também é resiliente a falhas de rede. Se não conseguir alcançar o AWS AppConfig, ela continua servindo a última configuração válida conhecida do cache. Sua função nunca falha por causa de um problema de conectividade upstream.

Use a variável de ambiente AWS_APPCONFIG_EXTENSION_PREFETCH_LIST para que os dados de configuração estejam disponíveis antes que o código da sua função seja executado. Isso recupera dados de configuração durante a fase Init antes que o Lambda comece a executar o código da função, reduzindo a latência na primeira invocação. Veja a referência de configuração da extensão Lambda do AWS AppConfig para detalhes.

Use o tipo de perfil de configuração “feature-flag” de primeira classe do AppConfig com seu formato JSON opinativo. Este tipo de dados oferece uma experiência de console simples para usuários não técnicos, flags multivariadas avançadas e ferramentas para limpar feature flags obsoletas. Trate toggles como temporários por natureza: após um recurso estar estável, remova a flag e sua lógica condicional para evitar proliferação de código morto. E defina o escopo de suas permissões do AWS Identity and Access Management (IAM) para que a extensão seja estritamente um consumidor somente leitura. Conceda apenas appconfig:StartConfigurationSession e appconfig:GetLatestConfiguration no ARN de recurso específico, garantindo que uma função comprometida não possa modificar configurações.

Limpeza

Para evitar cobranças contínuas, exclua os recursos que você criou neste passo a passo. Execute o seguinte comando do diretório do projeto:

sam delete --stack-name <your-stack-name>

Isso remove a função Lambda, endpoint do API Gateway e todos os recursos do AWS AppConfig criados pelo template.

Conclusão

A extensão AWS AppConfig Lambda fornece uma abordagem leve e gerenciada para feature flags em aplicações Serverless. A extensão lida com cache, polling e gerenciamento de sessão, enquanto o AWS AppConfig fornece estratégias de implantação seguras com validação e rollback automático.

Comparado à construção de sua própria infraestrutura de feature flags ou ao uso de variáveis de ambiente, esta abordagem elimina a sobrecarga de reimplantação, reduz a latência (leituras de submilissegundos do cache local) e fornece mecanismos de segurança de produção prontos para uso. O código da sua função permanece simples: um único HTTP GET para um endpoint local.

O padrão mostrado Nesta publicação se aplica além de simples flags booleanas. Você pode armazenar objetos de configuração complexos, regras de rollout baseadas em porcentagem ou dados de segmentação de usuários no mesmo perfil de configuração. À medida que suas necessidades de gerenciamento de recursos crescem, o AWS AppConfig escala com você sem exigir alterações no padrão de integração da função Lambda.

Com feature flags implementadas, você também tem a base para o AWS AppConfig Experimentation. A partir daqui, você pode definir experimentos multivariados, alocar tráfego para variantes e medir resultados em toda a sua pilha, transformando as feature flags que você construiu Nesta publicação em um experimento controlado.

Esta combinação permite que você entregue recursos mais rapidamente com confiança, responda a incidentes desabilitando recursos em segundos e experimente com rollouts graduais sem qualquer sobrecarga de infraestrutura.

Você pode encontrar o código-fonte completo no repositório GitHub.

Se você tiver perguntas ou feedback sobre esta solução, deixe um comentário Nesta publicação.

Para mais informações, consulte:

• Usando o AWS AppConfig Agent com AWS Lambda
• Estratégias de implantação do AWS AppConfig

Para mais recursos de aprendizado Serverless, visite Serverless Land.

Este conteúdo foi traduzido do post original do blog, que pode ser encontrado aqui.

Tradutores

Daniel Abib é Arquiteto de Soluções Sênior e Especialista em Amazon Bedrock 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 especialização em Machine Learning. Ele trabalha apoiando Startups, ajudando-os em sua jornada para a nuvem. https://www.linkedin.com/in/danielabib/

Nicolas Tarzia é Senior Technical Account Manager na AWS, com mais de 13 anos de experiência, com ampla experiência em arquitetura cloud, engenharia e design de software. Sua área de interesse são tecnologias serverless. https://www.linkedin.com/in/nicolastarzia