Un archivo YAML o JSON define los recursos y propiedades de la infraestructura. CloudFormation crea una pila reproducible y devuelve identificadores en Outputs.

Por qué importa en una infraestructura moderna

Un ejemplo SNS → SQS → Lambda separa distribución, cola y procesamiento. IAM controla permisos; KMS protege datos cifrados y Secrets Manager protege credenciales cuando se necesitan.

Cómo utilizarlo correctamente

En CloudFormation → Pilas → Crear pila → Con recursos nuevos (estándar), selecciona Cargar archivo de plantilla, revisa parámetros, IAM y costes, y confirma. En Eventos comprueba CREATE_COMPLETE y en Salidas consulta los ARN. Antes de actualizar usa conjuntos de cambios. No es necesario crear el tema SNS manualmente cuando ya está definido por la plantilla.

¿Cuándo conviene utilizar CloudFormation?

Es útil cuando resuelve una necesidad real de arquitectura; incluir todos los servicios en una plantilla solo porque existen añade complejidad, permisos y costes. Empieza con el flujo más pequeño posible, documenta las responsabilidades, trabaja primero en pruebas y crea alarmas de coste y operación.

Infraestructura como código con CloudFormation

Cuando haya que repetir el despliegue, usa una plantilla versionada que describa los recursos pertinentes y sus relaciones. Revisa los permisos antes de ejecutar cambios. Para aprender se puede empezar desde la consola de AWS y pasar a AWS CLI después.

Artículos de esta serie

Referencia oficial

Documentación de AWS sobre CloudFormation.

Tres formas de aportar una plantilla: archivo, S3 y Git

Cuando se utiliza la consola de CloudFormation existen tres formas habituales de proporcionar la plantilla. Cargar un archivo es la más directa para aprender: se selecciona un YAML o JSON local y la consola lo almacena para el despliegue. URL de Amazon S3 permite utilizar una plantilla previamente alojada en un bucket accesible para CloudFormation. Sincronizar desde Git permite seguir plantillas versionadas en un repositorio compatible, con configuración del acceso al repositorio y de la sincronización. Ninguna de estas modalidades hace que una plantilla insegura sea segura automáticamente.

Ejemplo completo: eventos de pedidos

Imaginemos una tienda que genera el evento pedido.confirmado. Queremos que un servicio de notificaciones y otro de estadísticas lo procesen sin bloquear la compra. En lugar de añadir componentes a mano, una plantilla puede describir un tema SNS, una cola SQS, la política que autoriza la entrega, una suscripción y una función Lambda. El objetivo no es crear la infraestructura más compleja, sino asegurar que las relaciones se reproducen en pruebas y producción.

Un YAML mínimo funcional para SNS y SQS

AWSTemplateFormatVersion: '2010-09-09'
Description: Ejemplo educativo SNS a SQS
Resources:
  Topic:
    Type: AWS::SNS::Topic
  Queue:
    Type: AWS::SQS::Queue
  QueueAccess:
    Type: AWS::SQS::QueuePolicy
    Properties:
      Queues:
        - !Ref Queue
      PolicyDocument:
        Version: '2012-10-17'
        Statement:
          - Effect: Allow
            Principal:
              Service: sns.amazonaws.com
            Action: sqs:SendMessage
            Resource: !GetAtt Queue.Arn
            Condition:
              ArnEquals:
                aws:SourceArn: !Ref Topic
  Subscription:
    Type: AWS::SNS::Subscription
    Properties:
      Protocol: sqs
      TopicArn: !Ref Topic
      Endpoint: !GetAtt Queue.Arn
      RawMessageDelivery: true
Outputs:
  TopicArn:
    Value: !Ref Topic
  QueueUrl:
    Value: !Ref Queue

Este ejemplo crea el transporte SNS→SQS, no Lambda ni permisos para que una aplicación externa publique. Un arquitecto añadirá Lambda, su rol y el event source mapping cuando se haya definido cómo procesar los eventos. No se incluyen secretos ni recursos de clientes.

Qué revisar antes de pulsar «Crear pila»

Comprueba la cuenta y región, el nombre de la pila, los tipos y cantidades de recursos, la configuración de cifrado, los accesos IAM, las políticas de retención y los costes estimados. Crear la pila puede desencadenar cargos según el tráfico y los recursos. Revisa especialmente los recursos que CloudFormation puede eliminar o reemplazar durante una actualización. Si hay recursos persistentes, considera DeletionPolicy: Retain y una estrategia de recuperación.

En la pantalla de cuatro pasos, primero seleccionas la fuente de la plantilla, luego el nombre y parámetros, después las opciones operativas y, por último, revisas todo antes del despliegue efectivo. La pestaña Eventos muestra fallos y progresos; Salidas expone los valores previstos por la plantilla, no cualquier secreto o identificador imaginable. Un ARN solo aparecerá allí si has definido un Output.

Actualizaciones, conjuntos de cambios y reversión

Es preferible mantener YAML y revisiones en Git. Para evolucionar un despliegue, crea y revisa un change set: distingue adiciones, cambios y sustituciones, y evalúa el posible impacto. La reversión automática no garantiza restaurar todos los datos externos ni compensa una arquitectura sin copias. Prueba antes en una cuenta de desarrollo y no utilices permisos administrativos globales por comodidad.

Cuándo no utilizar CloudFormation

Para una prueba puntual de un único recurso, la consola manual puede resultar más sencilla. Pero cuando un sistema integra cola, notificaciones, roles y permisos, declarar todo como código facilita revisión, repetibilidad y auditoría. CloudFormation no sustituye una política de arquitectura, ni la seguridad o el seguimiento del gasto.

Guías relacionadas de Laraflex

Amazon SNS · Amazon SQS · AWS Lambda · AWS IAM · AWS KMS · AWS Secrets Manager

Consulta la documentación oficial de AWS para ampliar y contrastar los detalles técnicos.