Feature Flags con AWS AppConfig: cambios seguros y confiables

Los feature flags son una técnica que permite modificar el comportamiento de una aplicación sin necesidad de desplegar una nueva versión de código. Esto significa que puedes tener código nuevo en producción, oculto detrás de un flag hasta que decidas activarlo. Si algo falla al habilitarlo, basta con desactivar el flag nuevamente, evitando revertir todo el despliegue. Esta capacidad de controlar cambios de forma segura contribuye a sistemas más confiables y por eso está recomendada dentro del pilar de Fiabilidad del Well-Architected Framework de AWS.

Ejemplo Práctico: Creando un feature flag

1. Ve a AWS AppConfig (dentro de AWS Systems Manager), entra a Applications → Create application, ingresa un nombre para la aplicación y haz clic en Create application.

2. Dentro de la aplicación, ve a Environments → Create environment, ingresa un nombre (p. ej., prod) y haz clic en Create environment.

3. Ve a Configuration profiles → Create configuration profile, coloca un nombre (p. ej., FraudFlags), selecciona Configuration type = Feature flags y haz clic en Next.

4. A continuación ingresa un Flag key (p. ej., enable-new-fraud-model), deja State = Disabled, haz clic en Next y luego en Save and continue to deploy.

5. Elige el Environment (p. ej., prod), selecciona la Deployment strategy (AllAtOnce esta bien para pruebas) y haz clic en Start deployment

6. Crea una función Lambda (Python 3.12) con las siguientes características:

• Variables de entorno:
• APPCFG_APPLICATION=BankingPlatform
• APPCFG_ENVIRONMENT=prod
• APPCFG_PROFILE=FraudFlags
• Layers → Add layer → AWS layers: agrega AWS AppConfig Lambda Extension.
• Role (IAM) con: appconfig:StartConfigurationSession, appconfig:GetLatestConfiguration, appconfig:GetConfiguration

Este es el código de la prueba para la Lambda:

import json
import logging
import os
import sys
import urllib.request

# Logger básico
logger = logging.getLogger()
logger.setLevel(logging.INFO)
if not logger.handlers:
    h = logging.StreamHandler(sys.stdout)
    h.setFormatter(logging.Formatter("%(asctime)s [%(levelname)s] %(message)s"))
    logger.addHandler(h)

# Vars de entorno (defínelas en la consola)
APP     = os.environ["APPCFG_APPLICATION"]    # AppEjemplo
ENV     = os.environ["APPCFG_ENVIRONMENT"]    # prod
PROFILE = os.environ["APPCFG_PROFILE"]        # FraudFlags

# Endpoint del AppConfig Agent (Lambda Extension)
APPCFG_URL = f"http://localhost:2772/applications/{APP}/environments/{ENV}/configurations/{PROFILE}"

def lambda_handler(event, context):
    # 1) Leer feature flags nativos desde el Agent
    with urllib.request.urlopen(APPCFG_URL, timeout=1.5) as resp:
        cfg = json.loads(resp.read().decode("utf-8"))

    # 2) Tomar el estado del release flag
    enabled = cfg["enable-new-fraud-model"]["enabled"]

    # 3) SOLO logs (sin implementar nada de fraude)
    if enabled:
        logger.info("Nuevo modelo de fraude: **ACTIVADO** (release flag encendido)")
    else:
        logger.info("Nuevo modelo de fraude: **DESACTIVADO** (release flag apagado)")

    # 4) Respuesta mínima
    return {
        "statusCode": 200,
        "body": json.dumps({
            "flag": "enable-new-fraud-model",
            "enabled": enabled
        })
    }

7. Ejecuta la función Lambda; en CloudWatch Logs deberías ver un mensaje indicando que se está usando la versión antigua (flag desactivado).

8. En AppConfig, abre el flag enable-new-fraud-model, cambia el estado a Enabled (On) y haz clic en Save version.

9. En el Configuration profile, selecciona Start deployment, elige el Environment (p. ej., prod), define la Deployment strategy (para pruebas, AllAtOnce) y pulsa Start.

10. Vuelve a invocar la función Lambda; ahora los logs deberían indicar que se está usando la nueva versión (flag activado).

Buenas Practicas

Al implementar feature flags en nuestros sistemas, es importante seguir ciertas buenas prácticas para obtener el máximo beneficio y evitar posibles antipatrones. A continuación, presentamos algunas recomendaciones clave, junto con formas en que AWS AppConfig soporta o automatiza cada una:

• Desplegar funcionalidades de forma gradual: No actives un feature flag al 100% de tus usuarios de golpe. Es más seguro hacer rollout progresivo, observando métricas y feedback en cada incremento. AWS AppConfig facilita esto mediante Deployment Strategies configurables: puedes definir estrategias lineales (por ejemplo, aumentar 10% cada 5 minutos), exponenciales u otras, incluyendo un periodo de bake time para monitorear antes de continuar. En la consola de AppConfig, al iniciar un despliegue de configuración puedes escoger una estrategia predefinida (como AppConfig.Linear) o personalizar una estrategia a tu medida. De esta forma limitas el radio de impacto de cualquier problema potencial, tal como recomienda AWS Well-Architected.
• Habilitar la reversión automática (auto-rollback): Configura sistemas de monitoreo y alarmas que desencadenen la desactivación de un flag o la reversión de la configuración si algo anda mal. AWS AppConfig se integra con Amazon CloudWatch Alarms para este propósito. Puedes asociar una alarma (por ejemplo, por tasa de errores, latencia, etc.) a la implementación de un flag: si la alarma se dispara durante el rollout, AppConfig automáticamente revierte la configuración al estado anterior sin intervención humana. Esto es invaluable, pues la velocidad de reacción automática suele ser más rápida que la de un operador humano que tendría que notar el problema y apagar el flag manualmente.
• Validar el input de la configuración: Nunca asumas que quien cambia un valor en producción no puede cometer un error de tipeo o formato. Implementa validaciones sintácticas y semánticas para cada flag o parámetro. AWS AppConfig te permite adjuntar Validators a tus perfiles de configuración. Estos validadores pueden ser esquemas JSON (JSON Schema) que definen la estructura esperada y rangos válidos, o incluso funciones Lambda personalizadas para chequeos más complejos. Por ejemplo, puedes definir que un valor de porcentaje de descuento debe ser un número entre 0 y 100, o que un flag de nivel de log solo acepte “DEBUG”, “INFO”, “WARN”, “ERROR”. Si alguien introduce un valor fuera de esas reglas, AppConfig bloqueará la implementación antes de afectar a los clientes. Esto previene despliegues de configuraciones corruptas que podrían causar fallos o comportamientos inesperados en la app.
• Usar una capa de caché para la configuración en la aplicación: Aunque podríamos consultar el servicio de configuración en cada llamada, es más eficiente y resistente mantener una caché local de los flags en la aplicación. AWS proporciona el AppConfig Agent (y extensiones para Lambda, etc.), que actúa como intermediario entre tu aplicación y el servicio AppConfig. Este agente se encarga de obtener las configuraciones y feature flags de forma eficiente, manteniéndolas en memoria y actualizándolas en segundo plano, reduciendo la latencia y carga en tu aplicación. En producción, es considerado una mejor práctica usar el AppConfig Agent para consumir las configuraciones, ya que además maneja reconexiones y fallback si AppConfig (o la red) presenta problemas. En resumen, una caché/agent añade un buffer entre tu sistema y la fuente de verdad, mejorando el performance y evitando dependencia directa constante de la red para cada verificación de flag.
• Limpiar los feature flags obsoletos: Incorpora en tu proceso de desarrollo la eliminación de flags que ya no se necesitan. Los feature flags deberían tener un ciclo de vida: aquellos de uso temporal (como los release flags) deben ser marcados para su futura eliminación una vez que cumplen su propósito. AWS AppConfig ayuda en la gobernanza de esto: puedes etiquetar un flag como Short-term (corto plazo) y asignarle una fecha objetivo de deprecación. La consola de AppConfig incluso mostrará qué flags han sobrepasado su fecha marcándolos como “Overdue” (atrasados), facilitando al equipo identificar y eliminar esas referencias pendientes. Estas herramientas fomentan una buena higiene, evitando el temido flag rot donde decenas de toggles viejos complican el código. Adicionalmente, mantener documentado qué flags existen y quién es el responsable de quitarlos es una buena práctica organizativa.

Los feature flags, usados con disciplina, permiten separar el despliegue de código de la liberación de funcionalidades, reduciendo riesgos y mejorando la fiabilidad. Con AWS AppConfig es posible gestionarlos de manera centralizada, validando configuraciones, habilitando rollbacks automáticos y facilitando despliegues graduales. En conjunto, estas prácticas convierten el cambio en un proceso controlado y predecible, clave para la resiliencia de cualquier sistema en producción.