Forem: ENRIQUE CORDERO

Tema-1 AWS Regions y Availability Zones: Guía Completa y Simple

ENRIQUE CORDERO — Fri, 12 Dec 2025 20:48:46 +0000

📌 Nota personal

Actualmente estoy en el compromiso de volver a tomar el examen de AWS Solutions Architect.

Como parte de esa preparación, decidí documentar y compartir los temas que voy estudiando, explicándolos de forma clara y práctica. La idea es reforzar mi propio entendimiento y, al mismo tiempo, ayudar a otros que estén recorriendo ese mismo camino.

Para comenzar, quise arrancar por uno de los conceptos más importantes —y a la vez más subestimados— en AWS.

Si estás aprendiendo AWS, seguramente ya te has encontrado con términos como Regiones y Availability Zones (AZ) por todos lados, pero no siempre queda claro qué significan realmente ni por qué son tan importantes.

Cuando este concepto finalmente hace “click”, los diagramas de arquitectura de AWS empiezan a tener mucho más sentido.

👉 Este artículo es el primer tema de esa serie, y sirve como base para todo lo que viene después. A partir de aquí, iremos construyendo una comprensión sólida de la infraestructura de AWS, desde los fundamentos hasta escenarios más reales de arquitectura.

En esta guía, comenzamos por entender cómo AWS organiza su infraestructura a nivel global y por qué Regiones y Availability Zones son la base de cualquier arquitectura bien diseñada.

La idea es ir construyendo poco a poco una base sólida, desde los fundamentos hasta escenarios más reales de arquitectura.

Si estás aprendiendo AWS, hay un concepto fundamental que aparece en todos lados y que al principio puede confundir: Regiones y Availability Zones (AZ).

Cuando este concepto hace "click", los diagramas de arquitectura de AWS empiezan a tener sentido completamente.

En esta guía lo explicamos de forma simple, visual y con ejemplos prácticos.

🌍 La Infraestructura Global de AWS

AWS opera una infraestructura global distribuida en múltiples ubicaciones alrededor del mundo. Esta infraestructura está compuesta por:

MUNDO
├── Regiones (Geographic Areas)
│   ├── Availability Zones (AZ)
│   ├── Local Zones
│   └── Wavelength Zones
└── Edge Locations

Conceptos clave:

Región: Zona geográfica grande con múltiples data centers
Availability Zone (AZ): Data center físico independiente
Principio fundamental: Una aplicación en AWS corre en varias AZ, nunca en una sola

🗺️ ¿Qué es una Región en AWS?

Una Región de AWS es una ubicación geográfica donde AWS tiene infraestructura física. Cada región está completamente aislada de las otras para maximizar la tolerancia a fallos.

Ejemplos de Regiones Comunes

Código	Nombre	Ubicación
`us-east-1`	Norte de Virginia	Estados Unidos
`us-west-2`	Oregón	Estados Unidos
`eu-west-1`	Irlanda	Europa
`sa-east-1`	São Paulo	Brasil
`ap-southeast-1`	Singapur	Asia Pacífico

Visualización Simple

Mundo
├── Estados Unidos → us-east-1, us-west-2
├── Europa → eu-west-1, eu-central-1
├── Asia → ap-southeast-1, ap-northeast-1
└── América del Sur → sa-east-1

Piensa en una Región como una ciudad grande donde AWS tiene toda su infraestructura.

¿Por qué AWS tiene múltiples Regiones?

Reducir latencia: Usuarios más cerca de los servidores
Cumplir regulaciones: Datos en jurisdicciones específicas
Aumentar disponibilidad: Redundancia geográfica
Disaster Recovery: Respaldo en caso de desastres naturales

🏢 ¿Qué es una Availability Zone (AZ)?

Dentro de cada Región, AWS tiene múltiples Availability Zones. Una AZ es:

Un data center físico (o grupo de data centers)
Completamente independiente de las otras AZ
Con su propia energía, red y enfriamiento
Conectada con otras AZ mediante redes de alta velocidad y baja latencia

Ejemplo en us-east-1

Región: us-east-1
├── us-east-1a (AZ A)
├── us-east-1b (AZ B)
├── us-east-1c (AZ C)
├── us-east-1d (AZ D)
├── us-east-1e (AZ E)
└── us-east-1f (AZ F)

Analogía del Mundo Real

Mundo Real	AWS
Ciudad	Región
Edificio	Availability Zone
Pisos/Oficinas	Servidores

Ejemplo práctico:

Miami es una Región
Edificios A, B y C son Availability Zones
Cada edificio tiene su propia electricidad, internet y seguridad

⚡ ¿Por qué AWS usa múltiples AZ?

Porque las cosas fallan:

✅ Cortes eléctricos
✅ Problemas de red
✅ Mantenimiento programado
✅ Errores humanos
✅ Desastres naturales localizados

Principio de Alta Disponibilidad

AWS está diseñado para que una aplicación pueda ejecutarse en más de una AZ simultáneamente.

Usuario
    |
Load Balancer
    |
├── Aplicación en AZ A (❌ falla)
├── Aplicación en AZ B (✅ funcionando)
└── Aplicación en AZ C (✅ funcionando)

Resultado: Si una AZ falla, el usuario no lo nota. Eso es alta disponibilidad.

🏗️ Arquitectura Típica Multi-AZ

Ejemplo con Servicios Serverless

Internet
    |
API Gateway (Multi-AZ automático)
    |
    v
┌─────────────────────────────────────┐
│ Lambda Functions                    │
├── AZ A: Lambda Instance             │
├── AZ B: Lambda Instance             │
└── AZ C: Lambda Instance             │
└─────────────────────────────────────┘
    |
    v
┌─────────────────────────────────────┐
│ RDS Multi-AZ                        │
├── AZ A: Primary Database            │
└── AZ B: Standby Database            │
└─────────────────────────────────────┘

Ejemplo con EC2 y Load Balancer

Internet
    |
Application Load Balancer
    |
├── AZ A: EC2 Instance + Auto Scaling
├── AZ B: EC2 Instance + Auto Scaling
└── AZ C: EC2 Instance + Auto Scaling
    |
    v
RDS Multi-AZ (Primary + Standby)

Características importantes:

API Gateway: Funciona en múltiples AZ automáticamente
Lambda: Se ejecuta en varias AZ sin configuración adicional
RDS Multi-AZ: Base primaria y respaldo automático
Load Balancer: Distribuye tráfico entre AZ saludables

🌐 ¿Necesitas múltiples Regiones?

En la mayoría de casos (99%): Una sola Región

Una Región es suficiente
├── AZ A: Aplicación + Base de datos
├── AZ B: Aplicación + Respaldo
└── AZ C: Aplicación + Respaldo

Casos donde necesitas múltiples Regiones

Región Primaria (us-east-1)     Región Secundaria (eu-west-1)
├── AZ A: Producción            ├── AZ A: Disaster Recovery
├── AZ B: Producción            ├── AZ B: Disaster Recovery
└── AZ C: Producción            └── AZ C: Disaster Recovery

Cuándo usar múltiples Regiones:

Disaster Recovery extremo: Protección contra desastres regionales
Usuarios globales: Reducir latencia para usuarios en diferentes continentes
Requerimientos legales: Datos deben permanecer en jurisdicciones específicas
Compliance: Regulaciones específicas por país/región

📊 Comparación: Región vs AZ

Aspecto	Región	Availability Zone
Alcance	Geográfico (país/continente)	Local (ciudad)
Distancia	Miles de kilómetros	Kilómetros
Latencia	50-200ms entre regiones	<1ms entre AZ
Propósito	Compliance, DR, latencia global	Alta disponibilidad local
Costo	Transferencia de datos costosa	Transferencia gratuita/barata
Casos de uso	Usuarios globales, DR	Tolerancia a fallos

🛠️ Mejores Prácticas

✅ Recomendaciones

Siempre usar múltiples AZ para aplicaciones críticas
Una región para empezar (expandir después si es necesario)
Distribuir recursos entre al menos 2-3 AZ
Usar servicios Multi-AZ cuando estén disponibles
Planificar Disaster Recovery solo si es crítico para el negocio

❌ Errores Comunes

Poner todo en una sola AZ (punto único de falla)
Usar múltiples regiones innecesariamente (complejidad y costo)
No considerar latencia entre AZ en aplicaciones sensibles
Ignorar costos de transferencia entre regiones

🎯 Resumen Ejecutivo

┌─────────────────────────────────────────────────────────┐
│ Conceptos Clave                                         │
├─────────────────────────────────────────────────────────┤
│ • Región = Zona geográfica grande                       │
│ • AZ = Data center físico independiente                 │
│ • Una Región tiene múltiples AZ (mínimo 3)             │
│ • Múltiples AZ = Alta disponibilidad                   │
│ • Una Región es suficiente para la mayoría de casos    │
└─────────────────────────────────────────────────────────┘

La Explicación Ultra Simple

AWS no ejecuta tu aplicación en un solo data center.

La ejecuta en:

Ciudades (Regiones)
Varios edificios dentro de esas ciudades (AZ)

Si un edificio se cae, la aplicación sigue funcionando.

Eso es todo. 🎉

📚 Recursos Adicionales

Última actualización: Diciembre 2024

🚀 Creando una API REST completa con AWS CDK y LocalStack: De cero a producción local

ENRIQUE CORDERO — Fri, 12 Dec 2025 19:59:43 +0000

🚀 Creando una API REST completa con AWS CDK y LocalStack: De cero a producción local

📋 Introducción

En este tutorial completo, te mostraré cómo crear una API REST robusta para gestión de órdenes de compra usando AWS CDK, TypeScript y LocalStack. Aprenderás a configurar un entorno de desarrollo local que simula perfectamente AWS, implementar un CRUD completo y probarlo exhaustivamente.

🎯 ¿Qué vamos a construir?

API REST completa con 5 endpoints CRUD
Funciones Lambda en TypeScript para cada operación
Base de datos DynamoDB para persistencia
API Gateway como punto de entrada
LocalStack para desarrollo local sin costos AWS
Pruebas automatizadas y manuales

🛠️ Stack Tecnológico

AWS CDK v2.170.0 - Infrastructure as Code
TypeScript 5.x - Lenguaje principal
Node.js 20+ - Runtime
LocalStack - Simulación AWS local
DynamoDB - Base de datos NoSQL
API Gateway - Gestión de APIs
Lambda - Funciones serverless

🔧 Configuración Inicial

1. Instalación de LocalStack en VS Code

📦 Instalar la Extensión LocalStack

La extensión oficial de LocalStack para VS Code facilita enormemente el desarrollo y debugging local.

Método 1: Desde VS Code Marketplace

Abre VS Code
Ve a la pestaña de Extensiones (Ctrl+Shift+X o Cmd+Shift+X)
Busca "LocalStack"
Instala la extensión oficial "LocalStack" por LocalStack
Reinicia VS Code

Método 2: Desde la línea de comandos

code --install-extension localstack.localstack

Método 3: Instalación manual

Ve a VS Code Marketplace - LocalStack
Haz clic en "Install"
Se abrirá VS Code automáticamente

⚙️ Configuración de la Extensión

Una vez instalada, configura la extensión:

Abrir configuración: Ctrl+, (Windows) o Cmd+, (Mac)
Buscar "LocalStack"
Configurar las siguientes opciones:

{
  "localstack.endpoint": "http://localhost:4566",
  "localstack.profile": "default",
  "localstack.region": "us-east-1",
  "localstack.autoStart": true,
  "localstack.dockerFlags": "-d"
}

🎯 Características de la Extensión

Panel de LocalStack:

Estado del servicio: Ver si LocalStack está corriendo
Logs en tiempo real: Monitorear actividad
Gestión de servicios: Iniciar/detener LocalStack
Explorador de recursos: Ver recursos AWS creados

Comandos disponibles (Paleta de comandos Ctrl+Shift+P):

LocalStack: Start - Iniciar LocalStack
LocalStack: Stop - Detener LocalStack
LocalStack: Restart - Reiniciar LocalStack
LocalStack: Show Logs - Mostrar logs
LocalStack: Open Web UI - Abrir interfaz web

Integración con AWS CLI:

Configuración automática de endpoints
Perfiles AWS locales
Comandos AWS redirigidos a LocalStack

🔍 Verificar Instalación de la Extensión

Panel lateral: Deberías ver el ícono de LocalStack en la barra lateral
Paleta de comandos: Ctrl+Shift+P → buscar "LocalStack"
Status bar: Indicador de estado en la barra inferior

🚀 Primer Uso

Abrir el panel LocalStack: Clic en el ícono de LocalStack
Iniciar LocalStack: Botón "Start LocalStack" o comando
Verificar estado: El panel mostrará "Running" cuando esté listo
Ver logs: Pestaña "Logs" para monitorear actividad

2. Crear el Proyecto CDK desde Cero

📋 Prerrequisitos

Antes de crear el proyecto, asegúrate de tener instalado:

# Verificar Node.js (versión 20+)
node --version

# Verificar npm
npm --version

# Instalar AWS CDK CLI globalmente
npm install -g aws-cdk

# Verificar instalación CDK
cdk --version

🏗️ Inicializar el Proyecto CDK

Paso 1: Crear directorio del proyecto

# Crear directorio
mkdir cdk-api-localstask
cd cdk-api-localstask

# Inicializar proyecto CDK con TypeScript
cdk init app --language typescript

Paso 2: Verificar estructura inicial

# Ver estructura creada
ls -la

# Deberías ver:
# bin/           # Punto de entrada de la aplicación
# lib/           # Definiciones de stacks
# test/          # Tests unitarios
# package.json   # Dependencias del proyecto
# tsconfig.json  # Configuración TypeScript
# cdk.json       # Configuración CDK

Paso 3: Instalar dependencias adicionales

# Dependencias para LocalStack
npm install aws-cdk-local

# Dependencias para Lambda y DynamoDB
npm install @aws-sdk/client-dynamodb @aws-sdk/lib-dynamodb

# Dependencias para TypeScript
npm install @types/aws-lambda @types/uuid uuid

# Dependencias de desarrollo
npm install --save-dev @types/node typescript

⚙️ Configurar Scripts para LocalStack

Edita el archivo package.json para agregar scripts específicos de LocalStack:

{
  "scripts": {
    "build": "tsc",
    "watch": "tsc -w",
    "test": "jest",
    "synth": "cdk synth",
    "deploy": "cdk deploy",
    "local:synth": "npx cdklocal synth",
    "local:deploy": "npx cdklocal deploy",
    "local:destroy": "npx cdklocal destroy",
    "local:diff": "npx cdklocal diff",
    "local:bootstrap": "npx cdklocal bootstrap"
  }
}

🔧 Configurar CDK para LocalStack

Archivo cdk.json (configuración CDK):

{
  "app": "npx ts-node --prefer-ts-exts bin/app.ts",
  "watch": {
    "include": [
      "**"
    ],
    "exclude": [
      "README.md",
      "cdk*.json",
      "**/*.d.ts",
      "**/*.js",
      "tsconfig.json",
      "package*.json",
      "yarn.lock",
      "node_modules",
      "test"
    ]
  },
  "context": {
    "@aws-cdk/aws-lambda:recognizeLayerVersion": true,
    "@aws-cdk/core:checkSecretUsage": true,
    "@aws-cdk/core:target-partitions": ["aws", "aws-cn"],
    "@aws-cdk-containers/ecs-service-extensions:enableDefaultLogDriver": true,
    "@aws-cdk/aws-ec2:uniqueImdsv2TemplateName": true,
    "@aws-cdk/aws-ecs:arnFormatIncludesClusterName": true,
    "@aws-cdk/core:validateSnapshotRemovalPolicy": true,
    "@aws-cdk/aws-codepipeline:crossAccountKeyAliasStackSafeResourceName": true,
    "@aws-cdk/aws-s3:createDefaultLoggingPolicy": true,
    "@aws-cdk/aws-sns-subscriptions:restrictSqsDescryption": true,
    "@aws-cdk/aws-apigateway:disableCloudWatchRole": false,
    "@aws-cdk/core:enablePartitionLiterals": true,
    "@aws-cdk/aws-events:eventsTargetQueueSameAccount": true,
    "@aws-cdk/aws-iam:minimizePolicies": true,
    "@aws-cdk/core:disableStackTrace": false
  }
}

📁 Crear Estructura de Directorios

# Crear directorios para organizar el código
mkdir -p lib/lambdas
mkdir -p lib/types

# Crear archivos base
touch lib/types/order.ts
touch lib/lambdas/create-order.ts
touch lib/lambdas/get-order.ts
touch lib/lambdas/list-orders.ts
touch lib/lambdas/update-order.ts
touch lib/lambdas/delete-order.ts

🎯 Configurar el Stack Principal

Archivo bin/app.ts (punto de entrada):

#!/usr/bin/env node
import 'source-map-support/register';
import * as cdk from 'aws-cdk-lib';
import { CdkApiLocalstackStack } from '../lib/cdk-api-localstask-stack';

const app = new cdk.App();
new CdkApiLocalstackStack(app, 'CdkApiLocalstackStack', {
  env: {
    account: process.env.CDK_DEFAULT_ACCOUNT || '000000000000', // LocalStack default
    region: process.env.CDK_DEFAULT_REGION || 'us-east-1',
  },
});

🔄 Bootstrap del Entorno LocalStack

# Asegúrate de que LocalStack esté corriendo
# Desde VS Code: LocalStack: Start

# Bootstrap CDK en LocalStack
npm run local:bootstrap

# Deberías ver:
# ⏳  Bootstrapping environment aws://000000000000/us-east-1...
# ✅  Environment aws://000000000000/us-east-1 bootstrapped.

✅ Verificar Configuración

# Compilar TypeScript
npm run build

# Generar template CloudFormation
npm run local:synth

# Si todo está bien, verás:
# Successfully synthesized to cdk.out

🎉 Proyecto Base Listo

Tu estructura de proyecto debería verse así:

cdk-api-localstask/
├── bin/
│   └── app.ts                 # ✅ Configurado
├── lib/
│   ├── cdk-api-localstask-stack.ts  # ⏳ Por configurar
│   ├── types/
│   │   └── order.ts           # ⏳ Por crear
│   └── lambdas/
│       ├── create-order.ts    # ⏳ Por crear
│       ├── get-order.ts       # ⏳ Por crear
│       ├── list-orders.ts     # ⏳ Por crear
│       ├── update-order.ts    # ⏳ Por crear
│       └── delete-order.ts    # ⏳ Por crear
├── package.json               # ✅ Configurado
├── tsconfig.json              # ✅ Configurado
├── cdk.json                   # ✅ Configurado
└── cdk.out/                   # ✅ Generado automáticamente

¡Perfecto! Ya tienes la base del proyecto CDK configurada y lista para desarrollar la API REST.

🛠️ Configuración Avanzada

Archivo de configuración local (.vscode/settings.json):

{
  "localstack.endpoint": "http://localhost:4566",
  "localstack.region": "us-east-1",
  "localstack.profile": "localstack",
  "localstack.dockerImage": "localstack/localstack-pro:latest",
  "localstack.dockerFlags": "-d -p 4566:4566",
  "localstack.autoStart": false,
  "localstack.logLevel": "INFO"
}

Variables de entorno (opcional):

# .env file
LOCALSTACK_API_KEY=your-api-key-here  # Solo para Pro
LOCALSTACK_HOSTNAME=localhost
DEBUG=1

🔧 Solución de Problemas de la Extensión

Problema: Extensión no detecta LocalStack

# Verificar que Docker esté corriendo
docker ps

# Verificar puerto 4566
netstat -an | findstr 4566  # Windows
lsof -i :4566              # Mac/Linux

Problema: No se puede iniciar desde VS Code

Verificar configuración de Docker
Comprobar permisos de usuario
Reiniciar VS Code
Reinstalar extensión si es necesario

Logs de la extensión:

View → Output → Seleccionar "LocalStack" en el dropdown

2. Verificar LocalStack por Sistema Operativo

🪟 Windows (PowerShell)

Primero, verificamos que LocalStack esté instalado y funcionando:

# Verificar contenedores Docker corriendo
docker ps

# Deberías ver algo como:
# CONTAINER ID   IMAGE                       STATUS
# 592dd8f2830d   localstack/localstack-pro   Up 5 hours (healthy)

Probar conectividad:

# Verificar salud de LocalStack
Invoke-RestMethod -Uri "http://localhost:4566/_localstack/health"

# Verificar servicios específicos
Invoke-RestMethod -Uri "http://localhost:4566/_localstack/info"

Si LocalStack no está corriendo:

# Iniciar LocalStack manualmente
docker run --rm -it -p 4566:4566 -p 4510-4559:4510-4559 localstack/localstack-pro

# O usar Docker Compose (si tienes docker-compose.yml)
docker-compose up -d

🍎 macOS/Linux (Terminal)

Verificar que LocalStack esté corriendo:

# Verificar contenedores Docker
docker ps

# Deberías ver:
# CONTAINER ID   IMAGE                       STATUS
# 592dd8f2830d   localstack/localstack-pro   Up 5 hours (healthy)

Probar conectividad:

# Verificar salud de LocalStack
curl -s http://localhost:4566/_localstack/health | jq

# Verificar información del sistema
curl -s http://localhost:4566/_localstack/info | jq

# Si no tienes jq instalado:
curl -s http://localhost:4566/_localstack/health

Si LocalStack no está corriendo:

# Iniciar LocalStack manualmente
docker run --rm -it -p 4566:4566 -p 4510-4559:4510-4559 localstack/localstack-pro

# O usar Docker Compose
docker-compose up -d

# Para macOS con Apple Silicon (M1/M2):
docker run --rm -it --platform linux/amd64 -p 4566:4566 localstack/localstack-pro

2. Verificación Avanzada por Plataforma

🪟 Windows - Verificación Completa

# 1. Verificar versión de LocalStack
docker exec -it $(docker ps -q --filter ancestor=localstack/localstack-pro) localstack --version

# 2. Probar servicios AWS simulados
$services = @('dynamodb', 'lambda', 'apigateway', 's3')
foreach ($service in $services) {
    try {
        $response = Invoke-RestMethod -Uri "http://localhost:4566/_localstack/health"
        $status = $response.services.$service
        Write-Host "✅ $service : $status" -ForegroundColor Green
    }
    catch {
        Write-Host "❌ $service : Error" -ForegroundColor Red
    }
}

# 3. Verificar puertos abiertos
netstat -an | findstr "4566"

🍎 macOS/Linux - Verificación Completa

# 1. Verificar versión de LocalStack
docker exec -it $(docker ps -q --filter ancestor=localstack/localstack-pro) localstack --version

# 2. Probar servicios AWS simulados
services=("dynamodb" "lambda" "apigateway" "s3")
for service in "${services[@]}"; do
    status=$(curl -s http://localhost:4566/_localstack/health | jq -r ".services.$service // \"unavailable\"")
    if [ "$status" = "available" ]; then
        echo "✅ $service: $status"
    else
        echo "❌ $service: $status"
    fi
done

# 3. Verificar puertos abiertos
lsof -i :4566 || netstat -an | grep 4566

3. Solución de Problemas Comunes

🚨 Problema: LocalStack no responde

Windows:

# Reiniciar LocalStack
docker stop $(docker ps -q --filter ancestor=localstack/localstack-pro)
docker run --rm -d -p 4566:4566 -p 4510-4559:4510-4559 localstack/localstack-pro

# Verificar logs
docker logs $(docker ps -q --filter ancestor=localstack/localstack-pro)

macOS/Linux:

# Reiniciar LocalStack
docker stop $(docker ps -q --filter ancestor=localstack/localstack-pro)
docker run --rm -d -p 4566:4566 -p 4510-4559:4510-4559 localstack/localstack-pro

# Verificar logs
docker logs $(docker ps -q --filter ancestor=localstack/localstack-pro)

🚨 Problema: Puerto 4566 ocupado

Windows:

# Encontrar proceso usando el puerto
netstat -ano | findstr :4566
# Terminar proceso (reemplaza PID)
taskkill /PID <PID> /F

macOS/Linux:

# Encontrar y terminar proceso
lsof -ti:4566 | xargs kill -9

🚨 Problema: Docker no está corriendo

Windows:

Abrir Docker Desktop
Verificar que Docker esté iniciado
Reiniciar Docker Desktop si es necesario

macOS:

# Iniciar Docker (si usas Docker Desktop)
open -a Docker

# O verificar servicio Docker
sudo systemctl start docker  # Linux

4. Script de Verificación Automática

Crea un script para verificar todo automáticamente:

Windows (verify-localstack.ps1)

Write-Host "🔍 Verificando LocalStack..." -ForegroundColor Cyan

# Verificar Docker
if (!(Get-Command docker -ErrorAction SilentlyContinue)) {
    Write-Host "❌ Docker no está instalado" -ForegroundColor Red
    exit 1
}

# Verificar contenedor LocalStack
$container = docker ps --filter ancestor=localstack/localstack-pro --format "{{.ID}}"
if (!$container) {
    Write-Host "❌ LocalStack no está corriendo" -ForegroundColor Red
    Write-Host "💡 Ejecuta: docker run --rm -d -p 4566:4566 localstack/localstack-pro" -ForegroundColor Yellow
    exit 1
}

# Verificar conectividad
try {
    $health = Invoke-RestMethod -Uri "http://localhost:4566/_localstack/health" -TimeoutSec 5
    Write-Host "✅ LocalStack está corriendo correctamente" -ForegroundColor Green

    # Mostrar servicios disponibles
    Write-Host "`n📋 Servicios disponibles:" -ForegroundColor Cyan
    $health.services.PSObject.Properties | ForEach-Object {
        $status = if ($_.Value -eq "available") { "✅" } else { "❌" }
        Write-Host "   $status $($_.Name): $($_.Value)"
    }
} catch {
    Write-Host "❌ LocalStack no responde en puerto 4566" -ForegroundColor Red
    exit 1
}

Write-Host "`n🎉 ¡LocalStack está listo para usar!" -ForegroundColor Green

macOS/Linux (verify-localstack.sh)

#!/bin/bash
echo "🔍 Verificando LocalStack..."

# Verificar Docker
if ! command -v docker &> /dev/null; then
    echo "❌ Docker no está instalado"
    exit 1
fi

# Verificar contenedor LocalStack
container=$(docker ps --filter ancestor=localstack/localstack-pro --format "{{.ID}}")
if [ -z "$container" ]; then
    echo "❌ LocalStack no está corriendo"
    echo "💡 Ejecuta: docker run --rm -d -p 4566:4566 localstack/localstack-pro"
    exit 1
fi

# Verificar conectividad
if curl -s --max-time 5 http://localhost:4566/_localstack/health > /dev/null; then
    echo "✅ LocalStack está corriendo correctamente"

    # Mostrar servicios disponibles
    echo ""
    echo "📋 Servicios disponibles:"
    curl -s http://localhost:4566/_localstack/health | jq -r '.services | to_entries[] | "   " + (if .value == "available" then "✅" else "❌" end) + " " + .key + ": " + .value'
else
    echo "❌ LocalStack no responde en puerto 4566"
    exit 1
fi

echo ""
echo "🎉 ¡LocalStack está listo para usar!"

Ejecutar scripts:

Windows:

# Dar permisos de ejecución
Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser
# Ejecutar
.\verify-localstack.ps1

macOS/Linux:

# Dar permisos de ejecución
chmod +x verify-localstack.sh
# Ejecutar
./verify-localstack.sh

🏗️ Creando el Proyecto CDK

1. Configuración del Workspace con LocalStack

🎯 Configurar VS Code para el Proyecto

Crea un archivo de configuración específico para tu proyecto:

.vscode/settings.json

{
  "localstack.endpoint": "http://localhost:4566",
  "localstack.region": "us-east-1",
  "localstack.profile": "localstack",
  "localstack.autoStart": true,
  "localstack.dockerFlags": "-d -p 4566:4566 -p 4510-4559:4510-4559",
  "typescript.preferences.includePackageJsonAutoImports": "on",
  "editor.codeActionsOnSave": {
    "source.organizeImports": true
  }
}

.vscode/launch.json (para debugging):

{
  "version": "0.2.0",
  "configurations": [
    {
      "name": "Debug Lambda Local",
      "type": "node",
      "request": "launch",
      "program": "${workspaceFolder}/lib/lambdas/create-order.ts",
      "env": {
        "AWS_ENDPOINT_URL": "http://localhost:4566",
        "AWS_REGION": "us-east-1",
        "ORDERS_TABLE_NAME": "orders"
      },
      "outFiles": ["${workspaceFolder}/lib/**/*.js"]
    }
  ]
}

.vscode/tasks.json (tareas automatizadas):

{
  "version": "2.0.0",
  "tasks": [
    {
      "label": "LocalStack: Deploy",
      "type": "shell",
      "command": "npm",
      "args": ["run", "local:deploy"],
      "group": "build",
      "presentation": {
        "echo": true,
        "reveal": "always",
        "focus": false,
        "panel": "shared"
      }
    },
    {
      "label": "LocalStack: Test API",
      "type": "shell",
      "command": "node",
      "args": ["test-api.js"],
      "group": "test",
      "dependsOn": "LocalStack: Deploy"
    }
  ]
}

🔍 Usar la Extensión Durante el Desarrollo

Panel de LocalStack en VS Code:

Resource Explorer: Ver recursos AWS creados en tiempo real
- Tablas DynamoDB
- Funciones Lambda
- APIs Gateway
- Roles IAM
Logs Viewer: Monitorear logs de Lambda en tiempo real
- Filtrar por función
- Buscar errores específicos
- Exportar logs
Service Status: Estado de servicios AWS simulados
- DynamoDB: ✅ Available
- Lambda: ✅ Available
- API Gateway: ✅ Available

Comandos útiles durante desarrollo:

# Desde la paleta de comandos (Ctrl+Shift+P)
LocalStack: Start                    # Iniciar LocalStack
LocalStack: Deploy CDK Stack         # Desplegar stack actual
LocalStack: View DynamoDB Tables     # Ver tablas creadas
LocalStack: Lambda Function Logs     # Ver logs de Lambda
LocalStack: API Gateway Endpoints    # Listar endpoints

📊 Monitoreo en Tiempo Real

La extensión permite monitorear tu aplicación mientras desarrollas:

Dashboard integrado:

Número de invocaciones Lambda
Errores recientes
Latencia promedio
Operaciones DynamoDB

Alertas automáticas:

Errores en funciones Lambda
Timeouts de API Gateway
Problemas de conectividad

2. Estructura del Proyecto

Nuestro proyecto tendrá esta estructura:

cdk-api-localstask/
├── lib/
│   ├── cdk-api-localstask-stack.ts    # Stack principal
│   ├── types/
│   │   └── order.ts                   # Interfaces TypeScript
│   └── lambdas/
│       ├── create-order.ts            # POST /orders
│       ├── get-order.ts               # GET /orders/{id}
│       ├── list-orders.ts             # GET /orders
│       ├── update-order.ts            # PUT /orders/{id}
│       └── delete-order.ts            # DELETE /orders/{id}
├── api-tests.http                     # Tests REST Client
├── test-api.js                        # Tests automatizados
└── ARCHITECTURE.md                    # Documentación

2. Instalación de Dependencias

npm install aws-cdk-local @types/aws-lambda @aws-sdk/client-dynamodb @aws-sdk/lib-dynamodb uuid @types/uuid

3. Configuración de Scripts

Actualizamos package.json para incluir comandos de LocalStack:

{
  "scripts": {
    "build": "tsc",
    "local:synth": "npx cdklocal synth",
    "local:deploy": "npx cdklocal deploy",
    "local:destroy": "npx cdklocal destroy"
  }
}

📊 Diseño del Modelo de Datos

Interfaces TypeScript

Creamos interfaces robustas para nuestro modelo de datos:

// lib/types/order.ts
export interface Order {
  orderId: string;
  customerId: string;
  customerName: string;
  customerEmail: string;
  items: OrderItem[];
  totalAmount: number;
  status: OrderStatus;
  createdAt: string;
  updatedAt: string;
}

export interface OrderItem {
  productId: string;
  productName: string;
  quantity: number;
  unitPrice: number;
  totalPrice: number;
}

export enum OrderStatus {
  PENDING = 'PENDING',
  CONFIRMED = 'CONFIRMED',
  PROCESSING = 'PROCESSING',
  SHIPPED = 'SHIPPED',
  DELIVERED = 'DELIVERED',
  CANCELLED = 'CANCELLED'
}

⚡ Implementando las Funciones Lambda

1. Función Crear Orden

// lib/lambdas/create-order.ts
export const handler = async (event: APIGatewayProxyEvent): Promise<APIGatewayProxyResult> => {
  try {
    const createOrderRequest: CreateOrderRequest = JSON.parse(event.body!);

    // Validaciones
    if (!createOrderRequest.customerId || !createOrderRequest.items?.length) {
      return {
        statusCode: 400,
        body: JSON.stringify({ success: false, error: 'Missing required fields' })
      };
    }

    // Calcular precios totales
    const items = createOrderRequest.items.map(item => ({
      ...item,
      totalPrice: item.quantity * item.unitPrice
    }));

    const totalAmount = items.reduce((sum, item) => sum + item.totalPrice, 0);

    // Crear orden
    const order: Order = {
      orderId: uuidv4(),
      ...createOrderRequest,
      items,
      totalAmount,
      status: OrderStatus.PENDING,
      createdAt: new Date().toISOString(),
      updatedAt: new Date().toISOString()
    };

    // Guardar en DynamoDB
    await docClient.send(new PutCommand({
      TableName: process.env.ORDERS_TABLE_NAME!,
      Item: order
    }));

    return {
      statusCode: 201,
      headers: { 'Content-Type': 'application/json', 'Access-Control-Allow-Origin': '*' },
      body: JSON.stringify({ success: true, data: order })
    };
  } catch (error) {
    return {
      statusCode: 500,
      body: JSON.stringify({ success: false, error: 'Internal server error' })
    };
  }
};

2. Características Clave de las Funciones

Validación robusta de datos de entrada
Manejo de errores consistente
CORS habilitado para desarrollo web
Logging detallado para debugging
Tipos TypeScript para seguridad de tipos

🏛️ Infraestructura como Código

Stack Principal CDK

// lib/cdk-api-localstask-stack.ts
export class CdkApiLocalstaskStack extends cdk.Stack {
  constructor(scope: Construct, id: string, props?: cdk.StackProps) {
    super(scope, id, props);

    // DynamoDB Table
    const ordersTable = new dynamodb.Table(this, 'OrdersTable', {
      tableName: 'orders',
      partitionKey: { name: 'orderId', type: dynamodb.AttributeType.STRING },
      billingMode: dynamodb.BillingMode.PAY_PER_REQUEST,
      removalPolicy: cdk.RemovalPolicy.DESTROY,
    });

    // Lambda Functions
    const createOrderFunction = new NodejsFunction(this, 'CreateOrderFunction', {
      entry: 'lib/lambdas/create-order.ts',
      handler: 'handler',
      runtime: lambda.Runtime.NODEJS_20_X,
      environment: { ORDERS_TABLE_NAME: ordersTable.tableName },
    });

    // API Gateway
    const api = new apigateway.RestApi(this, 'OrdersApi', {
      restApiName: 'Orders API',
      defaultCorsPreflightOptions: {
        allowOrigins: apigateway.Cors.ALL_ORIGINS,
        allowMethods: apigateway.Cors.ALL_METHODS,
      },
    });

    // Endpoints
    const ordersResource = api.root.addResource('orders');
    ordersResource.addMethod('POST', new apigateway.LambdaIntegration(createOrderFunction));

    // Permisos DynamoDB
    ordersTable.grantReadWriteData(createOrderFunction);
  }
}

🚀 Despliegue en LocalStack

1. Bootstrap del Entorno

npx cdklocal bootstrap

2. Compilación y Síntesis

npm run build
npm run local:synth

3. Despliegue

npm run local:deploy

El despliegue exitoso mostrará:

✅  CdkApiLocalstackStack

Outputs:
CdkApiLocalstackStack.ApiUrl = https://ndaeco0zjc.execute-api.localhost.localstack.cloud:4566/prod/
CdkApiLocalstackStack.OrdersTableName = orders

🧪 Pruebas Exhaustivas

1. Debugging con LocalStack Extension

🔍 Debugging de Funciones Lambda

La extensión de LocalStack facilita el debugging de funciones Lambda:

Configurar breakpoints:

Abre cualquier archivo Lambda (ej: create-order.ts)
Coloca breakpoints haciendo clic en el margen izquierdo
Usa F5 para iniciar debugging

Hot reloading:

// .vscode/settings.json
{
  "localstack.lambda.hotReload": true,
  "localstack.lambda.mountCode": true
}

Variables de entorno para debugging:

// En tus funciones Lambda
console.log('Environment:', {
  tableName: process.env.ORDERS_TABLE_NAME,
  region: process.env.AWS_REGION,
  endpoint: process.env.AWS_ENDPOINT_URL
});

📊 Monitoreo de Recursos en VS Code

Panel de DynamoDB:

Ver tablas creadas
Inspeccionar items
Ejecutar queries
Monitorear métricas

Panel de Lambda:

Lista de funciones desplegadas
Logs en tiempo real
Métricas de invocación
Configuración de funciones

Panel de API Gateway:

Endpoints disponibles
Métodos HTTP
Integraciones configuradas
Logs de requests

🚨 Alertas y Notificaciones

La extensión puede mostrar notificaciones para:

Errores en despliegue
Funciones Lambda que fallan
Problemas de conectividad
Recursos que no se crean correctamente

🔧 Comandos de Debugging Avanzado

# Desde la terminal integrada de VS Code
# Ver logs específicos de una función
localstack logs lambda --function-name CreateOrderFunction

# Invocar función directamente
localstack lambda invoke --function-name CreateOrderFunction --payload file://test-event.json

# Ver estado de DynamoDB
localstack dynamodb list-tables
localstack dynamodb scan --table-name orders

2. Script de Pruebas Automatizadas

// test-api.js
const API_BASE_URL = 'https://ndaeco0zjc.execute-api.localhost.localstack.cloud:4566/prod';
process.env["NODE_TLS_REJECT_UNAUTHORIZED"] = 0;

async function testAPI() {
  console.log('🧪 Probando API de Órdenes...');

  // 1. Crear orden
  const createResponse = await fetch(`${API_BASE_URL}/orders`, {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({
      customerId: 'CUST001',
      customerName: 'Juan Pérez',
      customerEmail: 'juan.perez@email.com',
      items: [{
        productId: 'PROD001',
        productName: 'Laptop Dell XPS 13',
        quantity: 1,
        unitPrice: 1299.99
      }]
    })
  });

  const order = await createResponse.json();
  console.log('✅ Orden creada:', order);

  // Continuar con más pruebas...
}

2. Pruebas con REST Client

🔌 Instalar la Extensión REST Client

REST Client es una extensión de VS Code que permite ejecutar requests HTTP directamente desde archivos .http o .rest.

Instalación:

Método 1: Desde VS Code Marketplace

Abre VS Code
Ve a Extensiones (Ctrl+Shift+X o Cmd+Shift+X)
Busca "REST Client"
Instala la extensión "REST Client" por Huachao Mao
Reinicia VS Code si es necesario

Método 2: Desde línea de comandos

code --install-extension humao.rest-client

Método 3: Marketplace web

Ve a REST Client Extension
Haz clic en "Install"

🎯 Características de REST Client

Sintaxis simple: Archivos .http con sintaxis intuitiva
Variables: Definir y reutilizar variables
Entornos: Configurar múltiples entornos (dev, staging, prod)
Autenticación: Soporte para Bearer tokens, Basic Auth, etc.
Respuestas: Ver respuestas formateadas con syntax highlighting
Historial: Guardar y reutilizar requests anteriores

📝 Crear Archivo de Pruebas

Crea el archivo api-tests.http en la raíz de tu proyecto:

### Variables
@baseUrl = https://ndaeco0zjc.execute-api.localhost.localstack.cloud:4566/prod

### Crear orden
POST {{baseUrl}}/orders
Content-Type: application/json

{
  "customerId": "CUST001",
  "customerName": "Juan Pérez",
  "customerEmail": "juan.perez@email.com",
  "items": [
    {
      "productId": "PROD001",
      "productName": "Laptop Dell XPS 13",
      "quantity": 1,
      "unitPrice": 1299.99
    }
  ]
}

### Listar órdenes
GET {{baseUrl}}/orders

### Obtener orden específica
GET {{baseUrl}}/orders/{{orderId}}

🚀 Cómo Usar REST Client

Ejecutar requests:

Abre el archivo api-tests.http en VS Code
Verás botones "Send Request" sobre cada request
Haz clic en "Send Request" para ejecutar
La respuesta aparecerá en una nueva pestaña

Atajos de teclado:

Ctrl+Alt+R (Windows) o Cmd+Alt+R (Mac): Enviar request
Ctrl+Alt+E (Windows) o Cmd+Alt+E (Mac): Enviar todos los requests

Variables dinámicas:

### Variables globales
@baseUrl = https://ndaeco0zjc.execute-api.localhost.localstack.cloud:4566/prod
@orderId = {{$guid}}  # Genera UUID automáticamente

### Crear orden y capturar ID
# @name createOrder
POST {{baseUrl}}/orders
Content-Type: application/json

{
  "customerId": "CUST001",
  "customerName": "Juan Pérez",
  "customerEmail": "juan.perez@email.com",
  "items": [...]
}

### Usar ID de la respuesta anterior
GET {{baseUrl}}/orders/{{createOrder.response.body.data.orderId}}

Configuración de entornos (archivo rest-client.env.json):

{
  "local": {
    "baseUrl": "https://ndaeco0zjc.execute-api.localhost.localstack.cloud:4566/prod"
  },
  "dev": {
    "baseUrl": "https://api-dev.tudominio.com"
  },
  "prod": {
    "baseUrl": "https://api.tudominio.com"
  }
}

Cambiar entorno:

Ctrl+Shift+P → "Rest Client: Switch Environment"
Seleccionar entorno deseado

💡 Tips para REST Client

Organización de requests:

### ===================
### ORDERS CRUD API
### ===================

### Variables
@baseUrl = https://ndaeco0zjc.execute-api.localhost.localstack.cloud:4566/prod

### ===================
### CREATE OPERATIONS
### ===================

### Crear orden básica
POST {{baseUrl}}/orders
Content-Type: application/json

{...}

### ===================
### READ OPERATIONS  
### ===================

### Listar todas las órdenes
GET {{baseUrl}}/orders

### ===================
### UPDATE OPERATIONS
### ===================

### Actualizar estado de orden
PUT {{baseUrl}}/orders/{{orderId}}
Content-Type: application/json

{
  "status": "CONFIRMED"
}

Autenticación (para APIs reales):

### Con Bearer Token
GET {{baseUrl}}/orders
Authorization: Bearer {{$dotenv ACCESS_TOKEN}}

### Con Basic Auth
GET {{baseUrl}}/orders
Authorization: Basic {{$dotenv USERNAME}}:{{$dotenv PASSWORD}}

Validación de respuestas:

### Crear orden con validación
POST {{baseUrl}}/orders
Content-Type: application/json

{...}

> {%
  client.test("Status is 201", function() {
    client.assert(response.status === 201, "Expected 201 but got " + response.status);
  });

  client.test("Response has orderId", function() {
    client.assert(response.body.data.orderId, "orderId is missing");
  });
%}

📊 Resultados y Métricas

Funcionalidades Implementadas

✅ POST /orders - Crear orden

✅ GET /orders - Listar órdenes

✅ GET /orders/{id} - Obtener orden específica

✅ PUT /orders/{id} - Actualizar orden

✅ DELETE /orders/{id} - Eliminar orden

Características Avanzadas

Filtrado por estado: GET /orders?status=CONFIRMED
Paginación: GET /orders?limit=10
Validación robusta de datos
Cálculo automático de totales
Manejo de errores HTTP estándar
CORS habilitado para desarrollo web

Rendimiento

Tiempo de despliegue: ~45 segundos
Latencia promedio: <100ms en LocalStack
Funciones Lambda: 5 funciones optimizadas
Tamaño de bundle: ~20KB por función

🔐 Seguridad y Mejores Prácticas

1. IAM y Permisos

Principio de menor privilegio: Cada Lambda tiene permisos mínimos
Roles específicos: Un rol IAM por función
Políticas granulares: Solo acceso necesario a DynamoDB

2. Validación de Datos

// Validación exhaustiva en cada endpoint
if (!createOrderRequest.customerId || !createOrderRequest.customerName || 
    !createOrderRequest.customerEmail || !createOrderRequest.items?.length) {
  return {
    statusCode: 400,
    body: JSON.stringify({ success: false, error: 'Missing required fields' })
  };
}

3. Manejo de Errores

Códigos HTTP apropiados: 200, 201, 400, 404, 500
Mensajes descriptivos de error
Logging detallado para debugging
Respuestas consistentes en formato JSON

🎯 Casos de Uso Reales

1. E-commerce

// Flujo típico de orden
const order = await createOrder({
  customerId: 'CUST001',
  items: [{ productId: 'LAPTOP001', quantity: 1, unitPrice: 999.99 }]
});

await updateOrder(order.orderId, { status: 'CONFIRMED' });
await updateOrder(order.orderId, { status: 'SHIPPED' });
await updateOrder(order.orderId, { status: 'DELIVERED' });

2. Gestión de Inventario

// Actualizar items de orden existente
await updateOrder(orderId, {
  items: [
    { productId: 'LAPTOP001', quantity: 2, unitPrice: 899.99 },
    { productId: 'MOUSE001', quantity: 1, unitPrice: 49.99 }
  ]
});

3. Reportes y Analytics

// Filtrar órdenes por estado
const confirmedOrders = await fetch('/orders?status=CONFIRMED');
const processingOrders = await fetch('/orders?status=PROCESSING');

📈 Monitoreo y Observabilidad

CloudWatch Logs

Cada función Lambda genera logs detallados:

[INFO] Create Order - Event: {"body": "...", "pathParameters": null}
[INFO] Order created successfully: 12345678-1234-1234-1234-123456789012

Métricas Clave

Invocaciones por función
Errores y timeouts
Latencia de respuesta
Operaciones DynamoDB

�️ Mejoroes Prácticas con LocalStack Extension

1. Flujo de Desarrollo Optimizado

🔄 Workflow Recomendado

Iniciar sesión de desarrollo:

   # Desde VS Code Command Palette (Ctrl+Shift+P)
   LocalStack: Start

Desarrollo iterativo:
- Modificar código Lambda
- Guardar archivo (auto-deploy si está configurado)
- Probar endpoint desde REST Client
- Ver logs en panel LocalStack
Debugging cuando sea necesario:
- Colocar breakpoints
- Usar F5 para debug mode
- Inspeccionar variables y estado

📁 Organización de Archivos

.vscode/
├── settings.json          # Configuración LocalStack
├── launch.json           # Configuración debugging
├── tasks.json            # Tareas automatizadas
└── extensions.json       # Extensiones recomendadas

.vscode/extensions.json (extensiones recomendadas):

{
  "recommendations": [
    "localstack.localstack",
    "humao.rest-client",
    "ms-vscode.vscode-typescript-next",
    "amazonwebservices.aws-toolkit-vscode"
  ]
}

⚡ Configuración de Auto-Deploy

// .vscode/settings.json
{
  "localstack.autoDeployOnSave": true,
  "localstack.watchFiles": [
    "lib/**/*.ts",
    "lib/**/*.js"
  ],
  "files.watcherExclude": {
    "**/node_modules/**": true,
    "**/cdk.out/**": true
  }
}

2. Integración con Otras Herramientas

🔗 AWS Toolkit Integration

Combinar LocalStack con AWS Toolkit para mejor experiencia:

{
  "aws.profile": "localstack",
  "aws.region": "us-east-1",
  "aws.samcli.location": "/usr/local/bin/sam"
}

📊 Métricas y Monitoreo

Dashboard personalizado en VS Code:

Crear snippets para queries comunes
Configurar tasks para operaciones frecuentes
Usar terminal integrada para comandos AWS CLI

🧪 Testing Integration

// .vscode/tasks.json
{
  "tasks": [
    {
      "label": "Run All Tests",
      "type": "shell",
      "command": "npm",
      "args": ["test"],
      "group": "test",
      "dependsOn": ["LocalStack: Deploy"]
    }
  ]
}

3. Troubleshooting Avanzado

🔍 Logs Detallados

{
  "localstack.logLevel": "DEBUG",
  "localstack.showDetailedLogs": true,
  "localstack.logToFile": true
}

🚨 Problemas Comunes y Soluciones

Extensión no conecta:

Verificar que LocalStack esté corriendo
Comprobar configuración de endpoint
Reiniciar extensión: LocalStack: Restart

Hot reload no funciona:

Verificar configuración mountCode
Comprobar permisos de archivos
Reiniciar LocalStack

Performance lenta:

{
  "localstack.dockerFlags": "-d --memory=2g --cpus=2"
}

🚀 Próximos Pasos

1. Mejoras de Producción

Autenticación JWT con Cognito
Rate limiting en API Gateway
Validación de esquemas con JSON Schema
Caching con ElastiCache
Monitoreo con X-Ray

2. Escalabilidad

Índices secundarios en DynamoDB
Paginación avanzada con cursors
Búsqueda con OpenSearch
Eventos con EventBridge

3. DevOps

CI/CD pipeline con GitHub Actions
Testing automatizado con Jest
Despliegue multi-ambiente
Infrastructure as Code versionado

🎉 Conclusión

En este tutorial hemos construido una API REST completa y robusta usando:

AWS CDK para infraestructura como código
TypeScript para desarrollo type-safe
LocalStack para desarrollo local sin costos
DynamoDB para persistencia escalable
Lambda para lógica serverless

Beneficios Clave

Desarrollo local: Sin costos AWS durante desarrollo
Type safety: TypeScript previene errores en runtime
Infraestructura versionada: CDK permite control de versiones
Escalabilidad: Arquitectura serverless lista para producción
Mantenibilidad: Código organizado y bien documentado

Recursos Adicionales

¡Felicidades! Ahora tienes una API REST completa, probada y lista para evolucionar hacia producción. 🚀

¿Te gustó este tutorial? Compártelo y sígueme para más contenido sobre AWS, serverless y desarrollo moderno.