Los feature flags son una técnica que permite modificar el comportamiento de una aplicación sin 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, sin necesidad de revertir todo el despliegue.

Esta capacidad de controlar cambios de forma segura está recomendada dentro del pilar de Fiabilidad del Well-Architected Framework de AWS.

Ejemplo práctico: creando un feature flag

1. Crear la aplicación en AppConfig

Ve a AWS AppConfig (dentro de AWS Systems Manager) → Applications → Create application. Ingresa un nombre y haz clic en Create application.

2. Crear el environment

Dentro de la aplicación, ve a Environments → Create environment. Ingresa un nombre (por ejemplo, prod) y haz clic en Create environment.

3. Configuration profile

Ve a Configuration profiles → Create configuration profile:

  • Nombre: por ejemplo FraudFlags.
  • Configuration type: Feature flags.
  • Haz clic en Next.

4. Definir el flag

  • Ingresa un Flag key (por ejemplo enable-new-fraud-model).
  • Deja State = Disabled (lo activaremos después).
  • Haz clic en Next y luego en Save and continue to deploy.

5. Primer deployment

  • Elige el Environment (por ejemplo prod).
  • Deployment strategy: AllAtOnce (suficiente para pruebas).
  • Start deployment.

6. Crear la función Lambda

Crea una función Lambda en Python 3.12 con:

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 permisos:

  • appconfig:StartConfigurationSession
  • appconfig:GetLatestConfiguration
  • appconfig:GetConfiguration

Código de 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
APP     = os.environ["APPCFG_APPLICATION"]
ENV     = os.environ["APPCFG_ENVIRONMENT"]
PROFILE = os.environ["APPCFG_PROFILE"]

# 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 desde el Agent (cache local)
    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) Lógica de aplicación según el flag
    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
    return {
        "statusCode": 200,
        "body": json.dumps({
            "flag": "enable-new-fraud-model",
            "enabled": enabled
        })
    }

7. Probar con el flag desactivado

Ejecuta la función Lambda. En CloudWatch Logs verás un mensaje indicando que se está usando la versión antigua (flag desactivado).

8. Activar el flag

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

9. Desplegar el cambio

En el Configuration profile, Start deployment → elige el environment → Deployment strategy (AllAtOnce para pruebas) → Start.

10. Validar el flag activo

Vuelve a invocar la Lambda. Los logs ahora indicarán que se está usando la nueva versión (flag activado).

Buenas prácticas

Al implementar feature flags, conviene seguir prácticas que maximizan el beneficio y previenen antipatrones. Aquí las cinco más importantes y cómo AWS AppConfig soporta o automatiza cada una:

Despliega funcionalidades de forma gradual

Activar un feature flag al 100% de tus usuarios de golpe es riesgoso. Es más seguro hacer rollout progresivo, observando métricas y feedback en cada incremento.

AWS AppConfig facilita esto mediante Deployment Strategies configurables: estrategias lineales (por ejemplo, aumentar 10% cada 5 minutos), exponenciales u otras, incluyendo un periodo de bake time para monitorear antes de continuar. Puedes escoger una estrategia predefinida (AppConfig.Linear) o personalizar la tuya. De esta forma limitas el radio de impacto de cualquier problema potencial, alineado con AWS Well-Architected.

Habilita la reversión automática (auto-rollback)

Configura monitoreo y alarmas que disparen la desactivación de un flag si algo anda mal. AWS AppConfig se integra con Amazon CloudWatch Alarms: puedes asociar una alarma (por tasa de errores, latencia, etc.) a la implementación de un flag. Si la alarma se dispara durante el rollout, AppConfig revierte la configuración al estado anterior automáticamente.

Es invaluable: la velocidad de reacción automática suele ser mayor que la de un operador humano. Para llevar este principio al extremo, conviene complementar con Chaos Engineering en AWS para validar que las alarmas y el rollback funcionan cuando se necesitan.

Valida el input de la configuración

Implementa validaciones sintácticas y semánticas para cada flag o parámetro. AWS AppConfig permite adjuntar Validators a tus perfiles de configuración:

  • JSON Schema para validar estructura y rangos válidos.
  • Funciones Lambda custom para chequeos más complejos.

Por ejemplo, validar que un porcentaje de descuento está entre 0 y 100, o que un nivel de log solo acepta DEBUG, INFO, WARN, ERROR. Si alguien introduce un valor fuera de esas reglas, AppConfig bloquea la implementación antes de afectar a clientes.

Usa el AppConfig Agent como capa de caché

Consultar el servicio en cada llamada es ineficiente. Mantén una caché local de los flags en la aplicación con el AppConfig Agent (extensiones para Lambda, ECS, EC2). El agent obtiene las configuraciones de forma eficiente, las mantiene en memoria y las actualiza en segundo plano, reduciendo latencia y carga.

En producción, usar el AppConfig Agent es mejor práctica porque también maneja reconexiones y fallback si AppConfig o la red presenta problemas. Añade un buffer entre tu sistema y la fuente de verdad.

Limpia los feature flags obsoletos

Los feature flags deben tener un ciclo de vida. Los de uso temporal (release flags) deben marcarse para futura eliminación una vez cumplido su propósito.

AWS AppConfig ayuda con esta gobernanza: puedes etiquetar un flag como Short-term y asignarle una fecha objetivo de deprecación. La consola muestra qué flags han sobrepasado su fecha marcándolos como “Overdue”, facilitando la identificación de referencias pendientes.

Documentar qué flags existen y quién es el responsable de eliminarlos previene el temido flag rot — decenas de toggles viejos que complican el código.

Conclusión

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 podemos gestionarlos de manera centralizada, validando configuraciones, habilitando rollbacks automáticos y facilitando despliegues graduales. Estas prácticas convierten el cambio en un proceso controlado y predecible — clave para la resiliencia de cualquier sistema en producción.

Cómo lo aplicamos en Caleidos

En clientes con plataformas críticas, AppConfig se vuelve la columna vertebral del control de cambios: feature flags + dynamic configuration + rollouts graduales con alarmas CloudWatch como kill switch. Combinado con observabilidad full-stack y Chaos Engineering, permite hacer cambios en producción con confianza.

Caleidos diseña e implementa esta capa como parte de nuestro servicio DevOps & Automatización y la opera 24×7 con Caleidos Lens©.

¿Quieres habilitar deploys más seguros en tu plataforma? Hablemos →