¡Llegamos al final de nuestra serie de DynamoDB! Ya sabemos crear tablas rápidas y reactivas, pero un buen arquitecto también sabe cuándo deshacerse de los datos que ya no sirven y cómo protegerse ante un desastre. Hoy aprenderás el TTL (Time to Live) para ahorrar espacio y los métodos de Backup para dormir tranquilo.

1. TTL (Time to Live): La papelera automática

¿Para qué pagar por guardar logs de hace 3 años o sesiones de usuario que ya expiraron?

• Ahorro total: AWS borra los items expirados automáticamente y no te cobra por esas escrituras de borrado.
• Cómo funciona: Eliges un atributo que contenga una fecha en formato Unix Timestamp. Cuando llega esa hora, DynamoDB marca el item para eliminarlo.

2. Backups y Point-in-Time Recovery (PITR)

• On-Demand Backups: Fotos completas de tu tabla que puedes guardar por años.
• PITR (Point-in-Time Recovery): Es como una máquina del tiempo. Si lo activas, puedes restaurar tu tabla a cualquier segundo exacto de los últimos 35 días. Ideal si un script mal programado borra media base de datos por error.

🛠️ El Código (CloudFormation)

Vamos a crear una tabla de “Sesiones” que tenga el PITR activado para seguridad y el TTL configurado para limpiar sesiones viejas.

1. Tabla con Auto-limpieza y Protección

TablaSesionesSegura:
  Type: AWS::DynamoDB::Table
  Properties:
    TableName: "SesionesApp"
    AttributeDefinitions:
      - AttributeName: "SessionId"
        AttributeType: "S"
    KeySchema:
      - AttributeName: "SessionId"
        KeyType: "HASH"
    BillingMode: PAY_PER_REQUEST
    # 1. ACTIVAR EL TTL (Auto-borrado)
    TimeToLiveSpecification:
      AttributeName: "ExpiraEn" # Nombre del campo con la fecha
      Enabled: true
    # 2. ACTIVAR LA MÁQUINA DEL TIEMPO (PITR)
    PointInTimeRecoverySpecification:
      PointInTimeRecoveryEnabled: true

📚 Conceptos Nuevos Explicados

1. Unix Timestamp

Para que el TTL funcione, la fecha debe estar en segundos desde el 1 de enero de 1970 (ej: 1714834800). Si lo pones en formato normal (YYYY-MM-DD), DynamoDB lo ignorará.

2. Borrado Asíncrono

El TTL no borra el archivo exactamente al segundo que expira. Suele tardar entre unos minutos y 48 horas en desaparecer físicamente, pero para tu aplicación es como si ya no existiera.

3. Restauración de Tablas

Cuando restauras un Backup o usas PITR, AWS crea una tabla nueva. No sobreescribe la actual. Esto te permite comparar datos antes de decidir cuál conservar.

🚀 Cómo Desplegarlo

Protege tus datos y automatiza su limpieza con un solo comando:

aws cloudformation deploy \
  --stack-name Dynamo-Final-D29 \
  --template-file 29-dynamo-final.yaml

📈 Cómo probar el TTL

1. Ve a la consola de DynamoDB → Tabla SesionesApp.
2. En la pestaña Additional settings, verifica que el TTL está “Enabled” apuntando al campo ExpiraEn.
3. Crea un Item y en el campo ExpiraEn pon un número de hace 5 minutos (puedes buscar “Unix Timestamp converter” en Google).
4. En un rato (puede tardar), verás que el registro desaparece solo. ¡Magia serverless!

📂 Código Adjunto

Puedes bajar el template final con seguridad y TTL aquí: Ver archivo en GitHub

🎥 Video Tutorial

En el video de hoy te enseño cómo recuperar una tabla que fue borrada “accidentalmente” en menos de 5 minutos usando PITR:

💡 ¿Qué sigue?

Hemos terminado con las bases de datos NoSQL. Ahora que tenemos dónde guardar archivos (S3) y dónde guardar datos (DynamoDB), es momento de aprender a enviar mensajes entre ellos. ¡Próximo módulo: Amazon SNS y SQS para desacoplar nuestra arquitectura!

¿Qué pasaría si pudieras enviar un correo de bienvenida automáticamente cuando un usuario se registra? ¿O actualizar un contador en otra tabla cuando se realiza una venta? En lugar de que tu aplicación tenga que hacer estas dos tareas a la vez, puedes usar DynamoDB Streams. Este servicio captura cada cambio en tu tabla y permite que otras herramientas (como AWS Lambda) reaccionen al instante.

¿Qué es un DynamoDB Stream?

• Registro de cambios: Es un historial ordenado de lo que ha pasado en tu tabla (inserciones, modificaciones y borrados).
• Tiempo real: Las acciones ocurren milisegundos después de que el dato cambió.
• Arquitectura desacoplada: Tu base de datos no tiene que saber qué hace la Lambda; ella solo emite el evento y quien quiera escucharlo, que actúe.

🛠️ El Código (CloudFormation)

Vamos a crear una tabla que tenga el Stream activado. Para que funcione, debemos indicarle a DynamoDB qué tipo de información queremos que envíe cuando algo cambie.

1. Tabla con Stream Habilitado

TablaConEventos:
  Type: AWS::DynamoDB::Table
  Properties:
    TableName: "RegistroActividad"
    AttributeDefinitions:
      - AttributeName: "Id"
        AttributeType: "S"
    KeySchema:
      - AttributeName: "Id"
        KeyType: "HASH"
    BillingMode: PAY_PER_REQUEST
    # ACTIVACIÓN DEL STREAM
    StreamSpecification:
      StreamViewType: NEW_AND_OLD_IMAGES # Envía el dato antes y después del cambio

📚 Conceptos Nuevos Explicados

1. StreamViewType

Define qué información se incluirá en el evento del Stream:

• KEYS_ONLY: Solo las llaves del elemento modificado.
• NEW_IMAGE: El elemento completo tal como quedó después del cambio.
• OLD_IMAGE: El elemento tal como estaba antes del cambio.
• NEW_AND_OLD_IMAGES: Ambos (ideal para comparar qué cambió exactamente).

2. Disparador (Trigger)

Es la conexión entre el Stream y una función AWS Lambda. Cuando llega un nuevo registro al Stream, AWS invoca a tu Lambda pasando los datos del cambio como un evento JSON.

3. Retención de datos

Los eventos en el Stream solo viven por 24 horas. Si tu función Lambda falla o no los procesa a tiempo, esos eventos desaparecerán.

🚀 Cómo Desplegarlo

Activa el flujo de eventos en tu infraestructura:

aws cloudformation deploy \
  --stack-name Dynamo-Streams-D28 \
  --template-file 28-dynamo-streams.yaml

📈 Cómo probar la “reacción” de tus datos

1. Ve a la consola de DynamoDB → Explore items → Tabla RegistroActividad.
2. Ve a la pestaña Exports and streams.
3. Verás que el Stream está “Enabled”. Allí mismo podrías hacer clic en Create trigger para conectarlo a una Lambda existente.
4. Si creas un Item nuevo, DynamoDB generará un evento invisible que viajará por el Stream. En una arquitectura real, tu Lambda recibiría un JSON parecido a este:

   "eventName": "INSERT",
   "dynamodb": {
       "NewImage": { "Id": {"S": "123"}, "Status": {"S": "Activo"} }
   }
   

📂 Código Adjunto

Puedes bajar el template con la especificación del Stream aquí: Ver archivo en GitHub

🎥 Video Tutorial

En el video de hoy construimos una automatización completa: insertamos un dato en DynamoDB y vemos cómo llega un email automáticamente usando Lambda y SES:

💡 Próximos pasos

• Día 29: TTL (Time to Live) y copias de seguridad: Aprenderemos a hacer que los datos se borren solos cuando ya no los necesitemos y cómo proteger nuestra tabla contra desastres.

Hasta ahora, hemos aprendido que para ser rápidos en DynamoDB debemos buscar por la Partition Key. Pero, ¿qué pasa si en nuestra tabla de usuarios queremos buscar por Email en lugar de UserId? Si hiciéramos un Scan, sería lento y costoso. Para solucionar esto existen los Índices, que son como “copias” de nuestra tabla organizadas de otra forma.

1. GSI (Global Secondary Index) - El más flexible

Es el tipo de índice más potente y el que usarás el 90% del tiempo.

• Flexibilidad: Puedes elegir cualquier atributo como nueva Partition Key y Sort Key.
• Escalabilidad: Tiene su propia capacidad (RCU/WCU) independiente de la tabla principal.
• Alcance: Se puede consultar a través de toda la tabla, sin importar la partición original.

2. LSI (Local Secondary Index) - El hermano estricto

Es mucho más limitado y solo se puede crear al momento de crear la tabla.

• Restricción: Debe compartir la misma Partition Key que la tabla original, pero usa una Sort Key distinta.
• Consistencia: Permite lecturas “Fuertemente Consistentes” (cosa que el GSI no puede).

🛠️ El Código (CloudFormation)

Vamos a crear una tabla de usuarios donde la Partition Key es UserId, pero añadiremos un GSI para poder buscar instantáneamente por Email.

1. Tabla con Índice Secundario Global (GSI)

TablaUsuariosConGSI:
  Type: AWS::DynamoDB::Table
  Properties:
    TableName: "UsuariosSeguridad"
    AttributeDefinitions:
      - AttributeName: "UserId"
        AttributeType: "S"
      - AttributeName: "Email"
        AttributeType: "S"
    KeySchema:
      - AttributeName: "UserId"
        KeyType: "HASH"
    BillingMode: PAY_PER_REQUEST
    # Definición del Índice
    GlobalSecondaryIndexes:
      - IndexName: "EmailIndex"
        KeySchema:
          - AttributeName: "Email"
            KeyType: "HASH"
        Projection:
          ProjectionType: "ALL" # Copia todos los atributos al índice

📚 Conceptos Nuevos Explicados

1. Proyección (Projection)

Cuando creas un índice, debes decidir qué datos se “copian” de la tabla original al índice:

• KEYS_ONLY: Solo las llaves (ahorra espacio).
• INCLUDE: Solo los atributos que tú elijas.
• ALL: Todos los atributos (más fácil de usar, pero más caro en almacenamiento).

2. Replicación Asíncrona

Cuando escribes en la tabla principal, DynamoDB copia el dato al GSI de forma automática en milisegundos. Esta copia es asíncrona, por lo que los GSI solo soportan consistencia eventual.

3. Diferencia Crítica: Creación

• GSI: Puedes crearlo, modificarlo o borrarlo en cualquier momento, incluso si la tabla ya tiene datos.
• LSI: Solo se puede crear cuando creas la tabla por primera vez. Si lo olvidas, tendrías que borrar y recrear la tabla.

🚀 Cómo Desplegarlo

Despliega tu tabla con capacidad de búsqueda avanzada:

aws cloudformation deploy \
  --stack-name Dynamo-Indices-D27 \
  --template-file 27-dynamo-indices.yaml

📈 Cómo probar tus índices

1. Ve a la consola de DynamoDB → Explore items → Tabla UsuariosSeguridad.
2. Crea un item con un UserId y un Email.
3. Ve a la pestaña Query.
4. En el menú desplegable de “Source”, cambia de [Table] a [Index: EmailIndex].
5. Ahora puedes buscar directamente por el correo electrónico. ¡Es igual de rápido que buscar por el ID!

📂 Código Adjunto

Puedes bajar el template con la configuración del GSI aquí: Ver archivo en GitHub

🎥 Video Tutorial

En el video de hoy te explico cuándo vale la pena pagar por un GSI y cómo evitar el error común de crear demasiados índices:

💡 Próximos pasos

• Día 28: DynamoDB Streams: ¿Quieres que algo pase automáticamente cuando un dato cambia? Aprenderemos a disparar funciones Lambda al detectar inserciones o borrados.

En las bases de datos tradicionales, hablamos de RAM y CPU. En DynamoDB, hablamos de Capacidad de Lectura y Escritura. Hoy aprenderás a medir el “esfuerzo” que hace tu tabla para procesar datos y cómo elegir entre pagar por uso o reservar potencia para ahorrar dinero.

1. Las unidades de medida: RCU y WCU

AWS mide el rendimiento de tu tabla con estas dos unidades:

• WCU (Write Capacity Unit): 1 WCU permite escribir 1 KB por segundo.
• RCU (Read Capacity Unit): 1 RCU permite leer 4 KB por segundo (en lectura eventualmente consistente).

2. ¿Lectura Fuerte o Eventual?

Aquí es donde muchos se confunden. Cuando lees datos en DynamoDB, tienes dos opciones:

• Eventualmente Consistente (Por defecto): Es más rápida y barata. Puede que leas un dato un milisegundo antes de que se actualice en todas las copias de AWS. (Gasta 0.5 RCU por 4KB).
• Fuertemente Consistente: Te asegura que leerás el dato más reciente, pero cuesta el doble. (Gasta 1 RCU por 4KB).

🛠️ El Código (CloudFormation)

Hasta ahora hemos usado PAY_PER_REQUEST. Hoy veremos cómo configurar una tabla con Capacidad Provisionada, ideal cuando ya sabes cuánto tráfico tendrá tu app y quieres predecir tus costos.

1. Tabla con Capacidad Definida

TablaConCapacidad:
  Type: AWS::DynamoDB::Table
  Properties:
    TableName: "InventarioGlobal"
    AttributeDefinitions:
      - AttributeName: "ItemId"
        AttributeType: "S"
    KeySchema:
      - AttributeName: "ItemId"
        KeyType: "HASH"
    # Configuramos la potencia reservada
    BillingMode: PROVISIONED
    ProvisionedThroughput:
      ReadCapacityUnits: 5  # Capacidad de lectura
      WriteCapacityUnits: 5 # Capacidad de escritura

📚 Conceptos Nuevos Explicados

1. Provisioned Mode vs. On-Demand

• On-Demand (Pay-per-request): Pagas por cada lectura/escritura real. Ideal para tráfico impredecible o apps que están empezando.
• Provisioned: Tú dices “quiero 5 RCU y 5 WCU”. AWS te cobra un monto fijo por hora. Es más barato si tienes un tráfico constante y alto.

2. Throttling (Estrangulamiento)

Si configuraste 5 WCU pero intentas escribir 10 KB por segundo, AWS lanzará un error de ProvisionedThroughputExceededException. Tu aplicación “chocará” contra el muro que tú mismo definiste para ahorrar.

3. Consistencia Eventual

Recuerda que DynamoDB guarda tus datos en 3 lugares distintos. La consistencia eventual lee de la copia más cercana, aunque la actualización de las otras dos esté en proceso (tarda milisegundos).

🚀 Cómo Desplegarlo

Crea la tabla con capacidad controlada:

aws cloudformation deploy \
  --stack-name Dynamo-Capacidad-D26 \
  --template-file 26-dynamo-capacidad.yaml

📈 Cómo probar la consistencia

1. Cuando uses el SDK (Python/Node.js) para leer un dato, busca el parámetro ConsistentRead.
2. Si lo pones en True, estarás forzando una Lectura Fuerte (más lenta y cara).
3. Si lo dejas en False, estarás usando Consistencia Eventual (más eficiente).

📂 Código Adjunto

Puedes bajar el template con capacidad provisionada aquí: Ver archivo en GitHub

🎥 Video Tutorial

En el video de hoy te enseño a usar la calculadora de AWS para saber cuántos RCU y WCU necesitas realmente para tu aplicación:

💡 Próximos pasos

• Día 27: Índices: GSI (Global) vs LSI (Local): ¿Qué pasa si necesitas buscar por algo que no es tu Partition Key? Aprenderemos a crear “vistas” de nuestros datos.

Si intentas usar DynamoDB como si fuera SQL, vas a sufrir. En SQL puedes buscar por cualquier columna, pero en DynamoDB, la forma en que recuperas tus datos depende casi totalmente de cómo diseñes tu Primary Key. Hoy entenderás la diferencia entre una llave simple y una compuesta.

1. Partition Key (PK) - La brújula de AWS

También conocida como Hash Key. Es obligatoria. AWS pasa este valor por un algoritmo (hash) para decidir en qué servidor físico guardará tus datos.

• Regla de oro: Debe estar bien distribuida. Si todos tus usuarios tienen la misma PK, crearás un “Hot Partition” y tu base de datos se volverá lenta.

2. Sort Key (SK) - El orden del caos

También conocida como Range Key. Es opcional. Permite guardar varios elementos con la misma Partition Key, pero organizados por la Sort Key.

• Su superpoder: Te permite hacer consultas como “tráeme todos los pedidos del Usuario X (PK) que ocurrieron en el último mes (SK)”.

🛠️ El Código (CloudFormation)

Vamos a crear una tabla de “Pedidos” (Orders) que utiliza una Llave Compuesta (PK + SK).

1. Tabla de Pedidos con Llave Compuesta

TablaPedidos:
  Type: AWS::DynamoDB::Table
  Properties:
    TableName: "PedidosClientes"
    AttributeDefinitions:
      - AttributeName: "CustomerId" # Partition Key
        AttributeType: "S"
      - AttributeName: "OrderId"    # Sort Key
        AttributeType: "S"
    KeySchema:
      - AttributeName: "CustomerId"
        KeyType: "HASH" # PK
      - AttributeName: "OrderId"
        KeyType: "RANGE" # SK
    BillingMode: PAY_PER_REQUEST

📚 Conceptos Nuevos Explicados

1. Llave Primaria Simple

Solo tiene Partition Key. El valor debe ser único en toda la tabla (como el DNI de una persona).

2. Llave Primaria Compuesta (PK + SK)

La combinación de ambas debe ser única. Esto permite modelar relaciones 1:N (un cliente, muchos pedidos).

• Ejemplo:

  • PK: USER#123

    SK: ORDER#001

  • PK: USER#123

    SK: ORDER#002

3. Query vs Scan

• Query: Buscas por PK. Es extremadamente rápido y barato porque AWS sabe exactamente a qué servidor ir.
• Scan: Buscas en toda la tabla (como leer un libro completo para encontrar una palabra). Es lento y muy caro. ¡Evítalo a toda costa!

🚀 Cómo Desplegarlo

Crea la tabla de pedidos con este comando:

aws cloudformation deploy \
  --stack-name Dynamo-Keys-D25 \
  --template-file 03-dynamodb-partition-sort-key.yaml

📈 Cómo probar las llaves

1. Ve a la consola de DynamoDB → Explore items → Tabla PedidosClientes.
2. Crea varios items usando el mismo CustomerId (ej. CLIENTE_A) pero diferentes OrderId.
3. Ahora ve a la pestaña de “Query”. Selecciona CustomerId e ingresa CLIENTE_A.
4. Verás cómo DynamoDB te devuelve instantáneamente todos los pedidos de ese cliente específico sin revisar el resto de la tabla.

📂 Código Adjunto

Puedes bajar el template de la tabla con llaves compuestas aquí: Ver archivo en GitHub

🎥 Video Tutorial

Mira el proceso paso a paso en video:

💡 Próximos pasos

• Día 26: Lecturas y escrituras: Consistencia y capacidad (RCU/WCU): ¿Cómo cobra AWS por usar DynamoDB? Aprenderemos a medir el “esfuerzo” de nuestra base de datos.

Ayer creamos nuestra primera tabla, pero hoy vamos a entender qué hay dentro. Si vienes del mundo SQL (MySQL, PostgreSQL), prepárate para desaprender un poco. En DynamoDB no hablamos de filas y columnas, sino de una jerarquía mucho más flexible y potente.

🧬 La jerarquía de datos

1. Tablas (Tables): Es el contenedor principal (similar a una tabla SQL).
2. Elementos (Items): Es un registro individual dentro de la tabla (similar a una “fila”).
3. Atributos (Attributes): Son los datos específicos de cada elemento (similar a las “columnas”).

¿Por qué decimos que es “Schema-less”?

En una base de datos tradicional, si una tabla tiene las columnas Nombre y Email, todas las filas DEBEN tener esas columnas. En DynamoDB, un Item puede tener Nombre y Email, pero el siguiente Item puede tener Nombre y Twitter, ¡y no pasa nada! La tabla no explota.

🛠️ El Código (CloudFormation)

Vamos a crear una tabla de “Productos” que nos permita ver cómo se definen los tipos de datos básicos.

1. Tabla de Catálogo de Productos

TablaProductos:
  Type: AWS::DynamoDB::Table
  Properties:
    TableName: "CatalogoProductos"
    # Definimos solo la llave principal (obligatorio)
    AttributeDefinitions:
      - AttributeName: "SKU"
        AttributeType: "S" # S = String (Texto)
    KeySchema:
      - AttributeName: "SKU"
        KeyType: "HASH"
    BillingMode: PAY_PER_REQUEST

📚 Conceptos Nuevos Explicados

1. Atributos Escalares (Tipos Básicos)

• S (String): Texto.
• N (Number): Números (enteros, decimales).
• B (Binary): Datos binarios (como imágenes en miniatura).

2. Atributos de Documento (Tipos Complejos)

Aquí es donde DynamoDB brilla. Puedes guardar:

• L (List): Una lista ordenada de valores (como una lista de tags: ['electronica', 'oferta']).
• M (Map): Un objeto JSON anidado dentro de un atributo. ¡Puedes tener mini-estructuras dentro de un Item!

3. El tamaño del Item

Ojo: Un solo Item (con todos sus atributos) no puede pesar más de 400 KB. DynamoDB está hecho para datos rápidos y ligeros, no para guardar archivos pesados (para eso usamos S3).

🚀 Cómo Desplegarlo

Actualiza tu infraestructura para añadir la tabla de productos:

aws cloudformation deploy \
  --stack-name Dynamo-Conceptos-D24 \
  --template-file 02-dynamo-tables-items-attributes.yaml

📈 Cómo probar la flexibilidad

1. Ve a la consola de DynamoDB → Explore items → Tabla CatalogoProductos.
2. Crea un Item: SKU: PROD-001, Nombre: Camiseta.
3. Crea otro Item: SKU: PROD-002, Nombre: Laptop, y añade un nuevo atributo tipo Number llamado Precio: 1200.
4. Observa cómo la tabla muestra ambos, aunque uno tenga precio y el otro no. ¡Eso es flexibilidad NoSQL!

📂 Código Adjunto

Puedes bajar el template de la tabla de productos aquí: Ver archivo en GitHub

🎥 Video Tutorial

Mira el proceso paso a paso en video:

💡 Próximos pasos

• Día 25: La importancia de la Partition Key y Sort Key: Mañana veremos el concepto más importante de DynamoDB. Si entiendes las llaves, dominas la base de datos.

Después de dominar S3, hoy entramos en el corazón de las aplicaciones modernas: las bases de datos. Pero no vamos a hablar de las clásicas tablas con filas y columnas de toda la vida. Hoy conocerás Amazon DynamoDB, la base de datos NoSQL de AWS que puede manejar millones de peticiones por segundo con una latencia de milisegundos.

¿Qué hace a DynamoDB tan especial?

• Serverless total: No eliges cuánta RAM o CPU necesitas; AWS se encarga de todo el escalado.
• Velocidad consistente: No importa si tienes 1 GB o 100 TB de datos, el tiempo de respuesta siempre es de un solo dígito de milisegundo.
• Disponibilidad extrema: Tus datos se replican automáticamente en tres zonas de disponibilidad (AZ) distintas.
• Sin esquemas rígidos: Cada registro puede tener atributos diferentes sin necesidad de alterar una tabla.

🤔 ¿Cuándo elegir NoSQL (DynamoDB) en lugar de SQL?

🛠️ El Código (CloudFormation)

Para empezar, vamos a crear nuestra primera tabla. En DynamoDB, lo único que debemos definir obligatoriamente al inicio es el nombre de la tabla y su llave principal.

1. Mi primera tabla de DynamoDB

MiTablaUsuarios:
  Type: AWS::DynamoDB::Table
  Properties:
    TableName: "UsuariosApp"
    # Definimos el esquema de la llave (Partition Key)
    AttributeDefinitions:
      - AttributeName: "UserId"
        AttributeType: "S" # S de String
    KeySchema:
      - AttributeName: "UserId"
        KeyType: "HASH" # HASH es el identificador único
    # Modo de pago por uso (ideal para empezar)
    BillingMode: PAY_PER_REQUEST
    Tags:
      - Key: "Modulo"
        Value: "DynamoDB-Intro"

📚 Conceptos Nuevos Explicados

1. NoSQL (Not Only SQL)

A diferencia de SQL, donde todo debe encajar en columnas fijas, en NoSQL priorizamos el rendimiento y la flexibilidad. No hay “JOINs” entre tablas; los datos se guardan de forma que leerlos sea lo más rápido posible.

2. Partition Key (Llave de Partición)

Es el identificador único de cada registro. AWS usa este valor para saber en qué parte física de sus servidores guardar tu dato.

3. Billing Mode: PAY_PER_REQUEST

Es el modo “On-Demand”. No pagas nada por hora; solo pagas por cada lectura o escritura real que hagas. Es perfecto para el blog porque si nadie entra a tu app, te cuesta $0.

🚀 Cómo Desplegarlo

Crea tu primera base de datos NoSQL con este comando:

aws cloudformation deploy \
  --stack-name Dynamo-Intro-D23 \
  --template-file 01-dynamo-intro.yaml

📈 Cómo probar tu tabla

1. Ve a la consola de DynamoDB → Tables → Selecciona UsuariosApp.
2. Haz clic en Explore table items.
3. Haz clic en Create item.
4. En UserId, pon 101.
5. Haz clic en Add new attribute → String → Nombre: Nombre, Valor: Tu Nombre.
6. ¡Guárdalo! Acabas de insertar tu primer registro en una base de datos de clase mundial.

📂 Código Adjunto

Puedes bajar el template de esta primera tabla aquí: Ver archivo en GitHub

🎥 Video Tutorial

Mira el proceso paso a paso en video:

💡 Próximos pasos

• Día 24: Conceptos clave: Tablas, Items y Atributos: Mañana aprenderemos la anatomía real de los datos y cómo se diferencian de una base de datos tradicional.

¡Llegamos al final de nuestra serie de S3! Hemos pasado de crear un simple bucket a configurar sitios web y cifrado de grado militar con KMS. Pero para ser un verdadero experto en AWS, no solo basta con saber “cómo funciona”, sino con saber cómo hacerlo de la forma más eficiente y barata posible.

¿Por qué son vitales las mejores prácticas?

• Evitar sorpresas en la factura: S3 es barato, pero un mal patrón de acceso o millones de archivos pequeños pueden salir caros.
• Rendimiento: Saber cómo nombrar tus archivos puede mejorar la velocidad de lectura.
• Higiene de la nube: Mantener buckets limpios y bien etiquetados facilita la gestión a largo plazo.

🛠️ El Código (CloudFormation)

Para este cierre, vamos a crear un “Bucket Maestro” que reúne lo mejor de lo que hemos visto: bloqueos de seguridad, etiquetas de costos y una regla de ciclo de vida para limpiar archivos temporales automáticamente.

1. El Bucket Optimizado

BucketProfesional:
  Type: AWS::S3::Bucket
  Properties:
    BucketName: !Sub "s3-optimizacion-final-${AWS::AccountId}"
    # 1. Seguridad Total
    PublicAccessBlockConfiguration:
      BlockPublicAcls: true
      BlockPublicPolicy: true
      IgnorePublicAcls: true
      RestrictPublicBuckets: true
    # 2. Control de Costos (Limpieza automática)
    LifecycleConfiguration:
      Rules:
        - Id: "LimpiarUploadsIncompletos"
          Status: Enabled
          AbortIncompleteMultipartUpload:
            DaysAfterInitiation: 7
    # 3. Organización (Tags para facturación)
    Tags:
      - Key: "Proyecto"
        Value: "SerieAWS7Dias"
      - Key: "CostCenter"
        Value: "Aprendizaje"

📚 Los 5 Consejos de Oro (Mejores Prácticas)

1. Nombres de archivo aleatorios al inicio

Si vas a tener miles de lecturas por segundo, no nombres tus archivos por fecha (ej. 2026-01-01-archivo.jpg). Es mejor usar un prefijo aleatorio o un hash al principio para distribuir la carga en los servidores de AWS.

2. Limpia las “Cargas Incompletas”

A veces, cuando subes un archivo grande, la subida falla a la mitad. AWS guarda esos “pedazos” y te los cobra aunque no veas el archivo. Usa la regla AbortIncompleteMultipartUpload (como la del código de arriba) para borrarlos automáticamente tras unos días.

3. ¡Cuidado con los archivos pequeños!

S3 cobra por cada 1,000 peticiones. Si tienes 1 millón de archivos de 1 KB, pagarás mucho más en peticiones que en almacenamiento. En esos casos, es mejor agruparlos en un archivo .zip o .tar.

4. Usa S3 Storage Lens

Es una herramienta gratuita en la consola de S3 que te da un panel de control con sugerencias de dónde estás desperdiciando dinero y qué buckets no tienen protección.

5. Etiquetas (Tags) siempre

Nunca crees un recurso sin etiquetas como Proyecto, Entorno (Dev/Prod) o Creador. Cuando llegue la factura a fin de mes, sabrás exactamente qué bucket es el responsable del gasto.

🚀 Cómo cerrar este ciclo

Desplegar este bucket final es tu graduación en S3:

aws cloudformation deploy \
  --stack-name S3-Mejores-Practicas \
  --template-file 30-s3-best-practices.yaml

📂 Código Adjunto

Puedes descargar el template completo aquí: Ver archivo en GitHub

🎥 Video Tutorial

Mira el proceso paso a paso en video:

💡 ¿Qué sigue?

Hemos terminado con S3, ¡pero el viaje serverless continúa! En el próximo módulo exploraremos Amazon DynamoDB, la base de datos NoSQL que escala a millones de usuarios.

Hasta ahora, nuestros buckets usaban el cifrado por defecto de S3 (donde AWS gestiona las llaves). Pero para datos sensibles o entornos corporativos, necesitas tener el control total. Hoy aprenderás a usar AWS KMS (Key Management Service) para cifrar tus archivos con una llave que tú mismo controlas.

¿Por qué usar KMS en lugar del cifrado estándar?

• Control de acceso granular: Puedes decidir qué usuarios pueden cifrar y quiénes pueden “desencriptar” para ver el contenido.
• Auditoría total: Cada vez que alguien lee un archivo, queda un registro en AWS CloudTrail indicando que se usó la llave KMS.
• Cumplimiento: Muchas normativas (como las bancarias o de salud) exigen que el cliente gestione sus propias llaves de cifrado.

🛠️ El Código (CloudFormation)

Este template crea una llave maestra (KMS Key) y configura un bucket para que la use de forma obligatoria. Si alguien intenta subir un archivo sin cifrar, S3 lo cifrará automáticamente con esta llave.

1. Llave KMS y Bucket Cifrado

# 1. Creamos la llave maestra de cifrado
MiLlaveMaestra:
  Type: AWS::KMS::Key
  Properties:
    Description: "Llave maestra para el blog - Cifrado S3"
    Enabled: true
    KeyPolicy:
      Version: "2012-10-17"
      Statement:
        - Sid: "Permitir uso total al administrador"
          Effect: Allow
          Principal:
            AWS: !Sub "arn:aws:iam::${AWS::AccountId}:root"
          Action: "kms:*"
          Resource: "*"

# 2. Creamos el bucket vinculado a esa llave
BucketUltraSeguro:
  Type: AWS::S3::Bucket
  Properties:
    BucketName: !Sub "s3-cifrado-kms-${AWS::AccountId}"
    # Bloqueo de acceso público (Mejor práctica del Día 18)
    PublicAccessBlockConfiguration:
      BlockPublicAcls: true
      BlockPublicPolicy: true
    # Configuración de cifrado obligatorio
    BucketEncryption:
      ServerSideEncryptionConfiguration:
        - ServerSideEncryptionByDefault:
            SSEAlgorithm: aws:kms
            KMSMasterKeyID: !Ref MiLlaveMaestra

📚 Conceptos Nuevos Explicados

1. AWS KMS (Key Management Service)

Es el servicio de AWS para crear y controlar llaves de cifrado. Piensa en él como una “caja fuerte” donde viven las llaves maestras que nunca salen de los módulos de seguridad de AWS.

2. SSE-KMS (Server-Side Encryption with KMS)

A diferencia de SSE-S3 (el gratuito), aquí tú pagas por la llave ($1 USD al mes aprox.) y por el uso, pero ganas el control de la llave. Si deshabilitas la llave en la consola, nadie podrá leer los archivos del bucket, ni siquiera el administrador.

3. Key Policy

Es el documento JSON que ves dentro de la llave. Define quién es el dueño de la llave. Es vital que el usuario root tenga acceso, o podrías “perder las llaves” de tu propia casa.

🚀 Cómo Desplegarlo

Despliega tu infraestructura con cifrado avanzado:

aws cloudformation deploy \
  --stack-name S3-KMS-Seguridad \
  --template-file 29-s3-key-encryption.yaml

📈 Cómo probar el cifrado

1. Sube un archivo a este nuevo bucket.
2. Selecciona el objeto y ve a la pestaña Properties.
3. Busca la sección Server-side encryption settings.
4. Verás que el algoritmo es AWS Key Management Service concepts (SSE-KMS) y aparecerá el ARN de la llave que creaste.
5. Prueba de fuego: Si fueras a otra cuenta de AWS e intentaras leer el archivo (aunque el bucket fuera público), no podrías porque no tienes permiso para usar la llave KMS.

📂 Código Adjunto

Puedes descargar el template completo aquí: Ver archivo en GitHub

🎥 Video Tutorial

Mira el proceso paso a paso en video:

💡 Próximos pasos

• Día 22: Mejores prácticas y optimización de costos: El gran cierre. Repasaremos todo lo aprendido para que tu arquitectura en S3 sea impecable.

¿Sabías que no necesitas un servidor EC2 para alojar una página web? Si tu sitio es estático (HTML, CSS, JavaScript, imágenes), puedes usar Amazon S3 para servirlo al mundo. Es la forma más barata, escalable y sencilla de desplegar un portafolio o una landing page.

¿Qué es un sitio web estático en S3?

• Sin servidores: No hay sistema operativo que parchear ni servidores que gestionar.
• Escalabilidad infinita: S3 maneja desde 1 hasta millones de visitas sin configurar nada.
• Costo mínimo: Solo pagas por el almacenamiento y la transferencia de datos (centavos al mes).
• Nota importante: Solo sirve para contenido estático. Si necesitas base de datos en el servidor (como PHP o Python), necesitarás otros servicios, aunque puedes usar APIs con JavaScript.

🛠️ El Código (CloudFormation)

Para que un bucket funcione como sitio web, necesitamos activar la configuración de hosting y, por primera vez en esta serie, permitir el acceso de lectura público para que cualquier persona en internet pueda ver tu página.

1. Bucket configurado como sitio web

WebsiteBucket:
  Type: AWS::S3::Bucket
  Properties:
    BucketName: !Sub "mi-web-estatica-${AWS::AccountId}"
    # Configuramos el archivo principal y el de error
    WebsiteConfiguration:
      IndexDocument: index.html
      ErrorDocument: error.html
    # Para una web pública, quitamos los bloqueos que usamos antes
    PublicAccessBlockConfiguration:
      BlockPublicAcls: false
      BlockPublicPolicy: false
      IgnorePublicAcls: false
      RestrictPublicBuckets: false

# 2. Permitir que TODO EL MUNDO lea los archivos
WebsiteBucketPolicy:
  Type: AWS::S3::BucketPolicy
  Properties:
    Bucket: !Ref WebsiteBucket
    PolicyDocument:
      Version: '2012-10-17'
      Statement:
        - Sid: PublicReadForGetBucketObjects
          Effect: Allow
          Principal: '*'
          Action: 's3:GetObject'
          Resource: !Sub 'arn:aws:s3:::${WebsiteBucket}/*'

📚 Conceptos Nuevos Explicados

1. WebsiteConfiguration

Le indica a S3 que este bucket no es solo para guardar archivos, sino que debe comportarse como un servidor web. El IndexDocument es la página que se cargará por defecto cuando alguien entre a tu URL.

2. S3 Website Endpoint

Al activar esta función, AWS te dará una URL especial (distinta a la de los objetos normales). El formato suele ser: http://mi-web-estatica.s3-website-us-east-1.amazonaws.com/.

3. Acceso Público (Lectura)

A diferencia de los días anteriores, aquí sí queremos acceso público. La política s3:GetObject aplicada al Principal * permite que cualquier navegador pueda descargar y mostrar tu HTML.

🚀 Cómo Desplegarlo

1. Crea el stack de CloudFormation:

     aws cloudformation deploy \
    --stack-name S3-Web-Estatica \
    --template-file 20-s3-web.yaml
   

2. Sube un archivo llamado index.html básico:

    <h1>¡Hola Mundo!</h1>
   

3. Súbelo usando la CLI:

     aws s3 cp index.html s3://tu-nombre-de-bucket/
   

📈 Cómo probar tu nueva web

1. Ve a la consola de S3 → Entra en tu bucket.
2. Ve a la pestaña Properties (Propiedades).
3. Baja hasta el final a la sección Static website hosting.
4. Haz clic en el enlace que aparece debajo de Bucket website endpoint.
5. ¡Deberías ver tu mensaje de “Hola Mundo” en el navegador!

📂 Código Adjunto

Puedes descargar el template de CloudFormation y un ejemplo de index.html aquí: Ver archivo en GitHub

🎥 Video Tutorial

Mira el proceso paso a paso en video:

💡 Próximos pasos

• Día 21: Replicación entre regiones y seguridad con cifrado (KMS): Aprende a copiar tus archivos automáticamente a otro país por seguridad y a cifrarlos con llaves maestras.