DEV Community: Afu Tse (Chainiz)

AWS presenta Intelligent Tiering para Amazon CloudWatch Logs

Afu Tse (Chainiz) — Thu, 16 Jul 2026 16:23:48 +0000

TL;DR

Amazon CloudWatch Logs ahora puede mover automáticamente tus logs entre distintos niveles de almacenamiento según su uso, reduciendo costos sin que tengas que administrar reglas de ciclo de vida ni procesos adicionales.

Recientemente, AWS anunció CloudWatch Logs Intelligent Tiering, una nueva funcionalidad que mueve automáticamente los logs entre distintos niveles de almacenamiento según la frecuencia con la que se consultan.

Puedes consultar todos los detalles en el anuncio oficial de AWS.

Su objetivo es simple: reducir los costos de almacenamiento sin que tengas que administrar manualmente el ciclo de vida de tus logs.

¿Cómo funcionaba antes?

Hasta ahora, todos los logs permanecían almacenados en el nivel Standard, sin importar si se consultaban todos los días o si llevaban meses sin usarse.

Eso obligaba a muchas organizaciones a tomar decisiones como:

Eliminar logs antes de tiempo para ahorrar dinero.
Exportarlos a S3 y construir procesos adicionales para consultarlos cuando fueran necesarios.
Mantener todo en CloudWatch y asumir un mayor costo de almacenamiento.

En otras palabras, había un equilibrio entre costo y simplicidad operativa.

¿Cómo funciona ahora?

Con Intelligent Tiering, CloudWatch analiza automáticamente la frecuencia con la que se consultan los logs.

El ciclo es completamente automático:

Inicio: Todos los logs nuevos se almacenan en el nivel Standard, donde ofrecen el máximo rendimiento para consultas frecuentes.
Después de 30 días sin consultas: Si un log no ha sido consultado durante 30 días consecutivos, CloudWatch lo mueve automáticamente al nivel Infrequent Access, optimizando el costo de almacenamiento.
Después de 90 días sin consultas: Si permanece sin consultas durante 90 días, se traslada automáticamente a Archive Instant Access, el nivel de almacenamiento de menor costo.
Si vuelves a consultar un log archivado: CloudWatch lo mueve automáticamente de nuevo al nivel Standard durante los siguientes 30 días, sin necesidad de realizar ninguna acción manual.

A pesar de estos cambios de almacenamiento, la experiencia para los usuarios prácticamente no cambia.

Puedes seguir utilizando CloudWatch Logs Insights de la misma forma, independientemente del nivel donde se encuentre el log.

Un ejemplo práctico

Imagina una aplicación que genera 500 GB de logs cada día y que, por requisitos de auditoría, debe conservarlos durante 180 días.

En seis meses, la aplicación acumularía aproximadamente:

500 GB × 180 días = 90.000 GB, es decir, cerca de 90 TB de logs.

El patrón de uso podría ser el siguiente:

Los logs de los últimos 30 días se consultan constantemente para investigar incidentes.
Los logs de entre 31 y 90 días se revisan con poca frecuencia.
Los logs de entre 91 y 180 días solo se consultan durante auditorías o investigaciones excepcionales.

Con el modelo tradicional

Todos los logs permanecerían en el nivel Standard, aunque la mayoría casi nunca se consultara.

Tomando como ejemplo una tarifa referencial de USD 0,03 por GB al mes, el costo estimado sería:

90.000 GB × USD 0,03 = USD 2.700 al mes

Con Intelligent Tiering

CloudWatch distribuiría automáticamente los logs según su frecuencia de consulta:

Nivel	Periodo	Volumen estimado	Tarifa referencial	Costo mensual
Standard	Últimos 30 días	15.000 GB	USD 0,03/GB	USD 450
Infrequent Access	Días 31 a 90	30.000 GB	USD 0,015/GB	USD 450
Archive Instant Access	Días 91 a 180	45.000 GB	USD 0,005/GB	USD 225

El costo total estimado sería:

USD 450 + USD 450 + USD 225 = USD 1.125 al mes

Ahorro estimado

Comparando ambos modelos:

USD 2.700 − USD 1.125 = USD 1.575 de ahorro mensual

Esto representa una reducción aproximada del:

58 % en el costo de almacenamiento

Y lo mejor es que todo ocurre automáticamente:

Sin exportar logs a Amazon S3.
Sin restauraciones manuales.
Sin crear políticas adicionales para mover los datos.
Sin cambiar la forma habitual de consultar los logs.

Si un auditor necesita revisar información de hace seis meses, ejecuta la consulta y CloudWatch gestiona automáticamente el cambio de nivel.

Nota: Las tarifas utilizadas en este ejemplo son ilustrativas. El costo real depende de la región de AWS, el volumen almacenado, las consultas realizadas y las tarifas vigentes de cada nivel.

¿Por qué es importante?

No se trata únicamente de ahorrar dinero.

También reduce la complejidad operativa.

Muchas empresas construyen pipelines para mover logs entre CloudWatch, S3 o Glacier únicamente para reducir costos.

Con esta nueva funcionalidad, AWS elimina gran parte de esa administración automática y permite mantener los logs centralizados en CloudWatch. Esto facilita el análisis, acelera la resolución de incidentes (MTTR) y reduce el esfuerzo operativo.

La perspectiva FinOps

Esta es probablemente la parte más interesante.

Uno de los principios fundamentales de FinOps es:

Pagar únicamente por el valor que realmente estás utilizando.

Los logs tienen un comportamiento muy predecible:

Mucho valor durante los primeros días.
Valor medio durante las primeras semanas.
Muy poco acceso después de varios meses.

Intelligent Tiering adapta automáticamente el costo al valor real del dato.

Además:

No tiene costo adicional por habilitarlo.
No hay cargos adicionales por las transiciones automáticas entre niveles de almacenamiento.
Solo pagas el almacenamiento correspondiente al nivel donde se encuentra cada log.

Es un buen ejemplo de cómo AWS sigue incorporando capacidades que ayudan a optimizar costos sin aumentar la carga operativa.

Conclusión

CloudWatch Logs Intelligent Tiering es una mejora sencilla, pero con un impacto importante para los equipos de operaciones y FinOps.

Permite mantener los logs centralizados en CloudWatch mientras optimiza automáticamente los costos de almacenamiento, eliminando la necesidad de crear procesos adicionales para mover o administrar los datos.

En definitiva, es una funcionalidad que demuestra cómo una buena automatización puede reducir costos, simplificar la operación y permitir que los equipos se enfoquen en generar valor, en lugar de administrar infraestructura.

Referencias

AWS Lambda MicroVMs: El futuro del cómputo serverless explicado desde cero

Afu Tse (Chainiz) — Sat, 04 Jul 2026 22:45:20 +0000

¿Alguna vez escuchaste el término "serverless" y pensaste que era magia negra? No te preocupes, a todos nos pasó. En este artículo vamos a explorar una novedad muy reciente de Amazon Web Services (AWS) que está cambiando las reglas del juego: Lambda MicroVMs. Y lo vamos a hacer sin asumir que ya sabes todo sobre la nube.

Primero lo primero: ¿qué es AWS Lambda?

Imagina que tienes una función que convierte una foto a blanco y negro. Con el modelo tradicional, necesitarías un servidor encendido las 24 horas del día esperando que alguien suba una foto, incluso si nadie lo hace en toda la noche.

AWS Lambda resuelve eso con una idea simple: tu código solo corre cuando lo necesita. No hay servidor esperando. AWS lo enciende, ejecuta tu función, y lo apaga. Tú pagas únicamente por el tiempo que duró la ejecución.

Suena perfecto, ¿verdad? Y lo es... para muchos casos. Pero tiene un límite importante: cada función Lambda dura máximo 15 minutos y no recuerda nada entre una llamada y la siguiente. Es como un empleado con amnesia total.

El problema que nadie había resuelto bien

Con el auge de la inteligencia artificial, aparecieron nuevas necesidades. Pensemos en un asistente de código con IA: el usuario escribe, la IA genera código, y ese código se ejecuta. Todo en tiempo real. Todo en un ambiente seguro.

¿Cuál es el desafío? Necesitas tres cosas al mismo tiempo:

Velocidad: el ambiente debe iniciar casi al instante.
Aislamiento: el código de un usuario no puede tocar el de otro.
Estado: el ambiente debe recordar lo que pasó antes (paquetes instalados, archivos creados, contexto).

Hasta hace poco, en AWS tenías que elegir: o velocidad, o aislamiento, o estado. Nunca los tres juntos sin volverse loco gestionando infraestructura.

Entra Lambda MicroVMs: lo mejor de tres mundos

El 22 de junio de 2026, AWS anunció Lambda MicroVMs, una nueva primitiva de cómputo que combina exactamente esas tres características.

¿Qué es una MicroVM?

Una MicroVM es una máquina virtual muy pequeña y ligera. Piénsala como una computadora completa pero en miniatura, que vive dentro de los servidores de AWS. Cada usuario recibe su propia MicroVM, completamente separada de las demás.

Está construida sobre Firecracker, una tecnología de código abierto creada por AWS que ya alimenta más de 15 billones de invocaciones de Lambda al mes. No es algo nuevo e inestable; es tecnología probada a escala gigantesca, adaptada para este nuevo uso.

Las tres superpoderes de Lambda MicroVMs

1. Aislamiento real (como una VM)

En Lambda tradicional, múltiples funciones pueden compartir el mismo "kernel" del sistema operativo. Es como vivir en un edificio donde todas las habitaciones comparten las mismas tuberías: si algo falla en una, puede afectar a otras.

Con MicroVMs, cada sesión tiene su propio kernel, su propia memoria y su propio disco. Es como darle a cada usuario su propio apartamento independiente. Lo que pase dentro no puede salir.

2. Estado persistente (recuerda lo que hiciste)

Lambda tradicional olvida todo cuando termina. MicroVMs no.

Si instalas una librería de Python, sigue ahí. Si creaste un archivo, sigue ahí. Si entrenaste un modelo pequeño, sigue ahí. El estado se preserva hasta 8 horas, y cuando el usuario no está activo, la MicroVM se "suspende" (como poner en pausa una película) para ahorrar costos.

3. Inicio casi instantáneo

Las máquinas virtuales tradicionales tardan minutos en arrancar. Las MicroVMs usan una técnica llamada snapshot: en lugar de arrancar desde cero, retoman desde una foto guardada del estado inicial. El resultado es que inician en fracciones de segundo.

¿Cómo funciona en la práctica?

El flujo es sencillo:

Creas una imagen: escribes un Dockerfile con tu app (por ejemplo, una app Flask de Python) y la subes a Amazon S3.
AWS construye la imagen: Lambda toma tu Dockerfile, lo ejecuta, y guarda una "foto" del estado del sistema cuando tu app ya está corriendo.
Lanzas MicroVMs: cada usuario que se conecta recibe su propia MicroVM iniciada desde esa foto.
La MicroVM se suspende sola: si el usuario no hace nada por un tiempo, se pausa automáticamente. Cuando regresa, continúa donde dejó.

Cada MicroVM tiene su propia URL con HTTPS, compatible con protocolos modernos como HTTP/2, gRPC y WebSockets.

¿Para qué sirve esto en el mundo real?

Algunos casos de uso donde MicroVMs brilla:

Asistentes de código con IA (como GitHub Copilot o Cursor): la IA genera código y ese código se ejecuta en un sandbox seguro, sin riesgo de que afecte otros usuarios.
Notebooks interactivos (como Jupyter): cada científico de datos tiene su propio ambiente con sus paquetes y datos.
Plataformas de aprendizaje de programación: cada estudiante tiene su propio entorno donde puede instalar lo que quiera y romper cosas sin afectar a nadie más.
Análisis de malware: ejecutar código potencialmente malicioso en un ambiente completamente aislado y desechable.
Pipelines de CI/CD: cada pull request se prueba en su propio ambiente limpio.

Lambda Functions vs MicroVMs: ¿cuándo usar cada uno?

No es que uno reemplaza al otro. Son herramientas diferentes para problemas diferentes.

Situación	¿Qué usar?
Procesar un webhook de Stripe	Lambda Function
Redimensionar imágenes automáticamente	Lambda Function
Cada usuario necesita su propio sandbox	Lambda MicroVM
Sesiones largas con estado (notebooks, IDEs)	Lambda MicroVM
Ejecutar código generado por IA de forma segura	Lambda MicroVM

La propia AWS lo resume bien: "Lambda Functions para cargas de trabajo orientadas a eventos; Lambda MicroVMs para aplicaciones multi-tenant que necesitan darle a cada usuario su propio ambiente aislado."

Disponibilidad y precios

Al momento de escribir este artículo, Lambda MicroVMs está disponible en:

US East (N. Virginia y Ohio)
US West (Oregon)
Asia Pacific (Tokyo)
Europe (Ireland)

El precio se basa en uso por segundo de vCPU y RAM. Cuando la MicroVM está suspendida, solo pagas por el almacenamiento del snapshot, no por cómputo. Esto lo hace eficiente para sesiones intermitentes.

Soporta hasta 16 vCPUs, 32 GB de RAM y 32 GB de disco por MicroVM, corriendo sobre arquitectura ARM64 (AWS Graviton).

Conclusión: ¿por qué importa esto?

Lambda MicroVMs resuelve un problema que se volvió urgente con la IA: cómo ejecutar código de usuarios o de modelos de lenguaje de forma rápida, segura y con memoria, sin que los desarrolladores tengan que convertirse en expertos en virtualización.

Para ti como estudiante, esto es relevante por dos razones:

Es tecnología nueva: entenderla ahora te da ventaja cuando este tipo de arquitectura se vuelva el estándar.
Refleja hacia dónde va la industria: el cómputo serverless ya no es solo para funciones simples. Está evolucionando para soportar cargas de trabajo complejas, stateful e impulsadas por IA.

La nube no deja de sorprendernos. Y lo mejor es que nunca es tarde para subirse al tren.

📚 Fuentes y lecturas adicionales

Las siguientes fuentes fueron consultadas para la elaboración de este artículo. Si quieres profundizar, son el punto de partida ideal:

Fuentes oficiales de AWS

AWS Blog oficial - Artículo de lanzamiento de Lambda MicroVMs (22 jun. 2026)
"Run isolated sandboxes with full lifecycle control: AWS Lambda introduces MicroVMs"
🔗 https://aws.amazon.com/blogs/aws/run-isolated-sandboxes-with-full-lifecycle-control-aws-lambda-introduces-microvms/
AWS What's New - Anuncio oficial del producto (22 jun. 2026)
"AWS introduces Lambda MicroVMs for isolated execution of user and AI-generated code"
🔗 https://aws.amazon.com/about-aws/whats-new/2026/06/aws-lambda-microvms/
AWS Lambda MicroVMs - Página del producto
🔗 https://aws.amazon.com/lambda/lambda-microvms/

Medios especializados

The Register - Cobertura independiente del lanzamiento (23 jun. 2026)
"AWS debuts Lambda MicroVMs with up to 8 hours runtime"
🔗 https://www.theregister.com/devops/2026/06/23/aws-debuts-lambda-microvms-with-up-to-8-hours-runtime/5260035
InfoQ - Análisis técnico detallado (30 jun. 2026)
"AWS Launches Lambda MicroVMs for Isolated Agent and User Code Execution"
🔗 https://www.infoq.com/news/2026/06/aws-lambda-microvms/

Artículos de la comunidad

DEV Community - Prueba práctica por un AWS Community Builder (24 jun. 2026)
"AWS Lambda MicroVMs: I Tested the New Stateful Serverless Primitive"
🔗 https://dev.to/aws-builders/aws-lambda-microvms-i-tested-the-new-stateful-serverless-primitive-40jf
DEV Community - Introducción técnica para desarrolladores (jun. 2026)
"Introducing Lambda MicroVMs - Isolated, Stateful Sandboxes for Running Untrusted Code on AWS"
🔗 https://dev.to/aws-builders/introducing-lambda-microvms-isolated-stateful-sandboxes-for-running-untrusted-code-on-aws-5chf
Elevata.io - Análisis de casos de uso para agentes de IA (jun. 2026)
"AWS Lambda MicroVMs for AI Agents: When to Use Them"
🔗 https://elevata.io/en/aws-lambda-microvms-isolated-execution-ai-agents

De x86 a ARM: la revolución silenciosa hacia una nube más verde en Microsoft Azure

Afu Tse (Chainiz) — Sat, 04 Jul 2026 21:36:59 +0000

Durante más de cuatro décadas, hablar de servidores era prácticamente sinónimo de hablar de arquitectura x86. Desde los primeros servidores empresariales hasta la mayoría de los centros de datos modernos, Intel y AMD han dominado la infraestructura sobre la que funcionan nuestras aplicaciones.

Sin embargo, algo está cambiando.

De forma silenciosa, los principales proveedores de nube como Microsoft Azure están incorporando cada vez más procesadores ARM para ejecutar cargas de trabajo modernas.

¿La razón?

No es únicamente el rendimiento.

Es la eficiencia energética.

El problema de los centros de datos modernos

Cada vez que desplegamos una máquina virtual o un clúster de Kubernetes en Azure, detrás existe un servidor físico consumiendo energía.

Ahora imaginemos un centro de datos con cientos de miles de servidores.

Incluso una pequeña reducción en el consumo eléctrico por servidor representa un ahorro enorme cuando se multiplica por toda la infraestructura.

Y no solo hablamos de electricidad.

Menos energía implica:

menos calor generado
menor necesidad de refrigeración
menores costos operativos
menor huella de carbono

Por eso la eficiencia energética se ha convertido en un factor estratégico para los hyperscalers (gigantes tecnológicos que poseen y administran infraestructuras de centros de datos masivas a nivel global).

¿Qué diferencia a ARM de x86?

A grandes rasgos:

x86 utiliza una arquitectura CISC (Complex Instruction Set Computing), con un conjunto amplio de instrucciones complejas.

ARM utiliza una arquitectura RISC (Reduced Instruction Set Computing), basada en instrucciones más simples y optimizadas.

Esto no significa automáticamente que ARM sea “más rápido”.

Lo que sí significa es que puede realizar muchas cargas de trabajo consumiendo considerablemente menos energía.

En otras palabras:

ARM no busca ganar por fuerza bruta.

Busca hacer más con menos.

¿Por qué ahora?

Hace unos años, ARM estaba asociado principalmente a teléfonos móviles.

Hoy la situación es muy diferente.

Las aplicaciones cloud modernas suelen ejecutarse como:

microservicios
contenedores
funciones serverless
APIs
servicios web

Estas cargas suelen escalar horizontalmente y no siempre necesitan el máximo rendimiento por núcleo.

En ese escenario, la eficiencia energética se vuelve mucho más importante.

ARM en Microsoft Azure

Microsoft ya ofrece máquinas virtuales basadas en Ampere Altra, una familia de procesadores ARM64 diseñada específicamente para centros de datos.

Entre ellas encontramos:

Dpsv5
Dplsv5

Estas instancias están orientadas a cargas de trabajo como:

aplicaciones web
microservicios
Kubernetes
Docker
Node.js
Python
Java
Go
.NET 8+

Es importante destacar que estas máquinas no reemplazan completamente a las tradicionales basadas en x86.

Simplemente amplían las opciones disponibles para distintos tipos de aplicaciones.

¿Cuánto puede ahorrar ARM?

Microsoft no publica el consumo eléctrico exacto de cada máquina virtual, pero sí conocemos información de los procesadores utilizados.

Según Ampere Computing, sus procesadores para centros de datos pueden ofrecer:

hasta 2.5 veces mejor rendimiento por watt en determinadas cargas cloud-native
hasta 50 % menos consumo energético para algunas cargas de trabajo comparables

Naturalmente, estos valores dependen del tipo de aplicación y no deben interpretarse como una reducción garantizada para cualquier escenario.

El efecto multiplicador

Supongamos un centro de datos con 10.000 servidores.

Si cada servidor lograra ahorrar apenas 100 W, el ahorro sería:

100 W × 10 000 servidores = 1 MW

Manteniendo ese ahorro durante un año:

1 MW × 24 horas × 365 días = 8 760 MWh

Eso representa suficiente energía para abastecer aproximadamente entre 700 y 900 hogares durante un año, dependiendo del consumo promedio de cada región.

Ahora imaginemos la escala real de Azure, donde existen cientos de miles de servidores distribuidos en decenas de regiones alrededor del mundo.

¿Significa esto que ARM reemplazará a x86?

No necesariamente.

Existen muchos escenarios donde x86 continúa siendo la mejor opción.

Por ejemplo:

aplicaciones heredadas (legacy)
software que solo existe para x86
determinados motores de bases de datos
aplicaciones con dependencias específicas

Por otro lado, ARM resulta especialmente atractivo para:

APIs REST
aplicaciones web
contenedores
Kubernetes
servicios backend
aplicaciones desarrolladas con tecnologías modernas

Lo más probable es que ambas arquitecturas convivan durante muchos años.

Más que rendimiento: sostenibilidad

Cuando pensamos en sostenibilidad solemos imaginar paneles solares o energías renovables.

Sin embargo, también existe una sostenibilidad impulsada por decisiones de arquitectura.

Elegir un procesador más eficiente puede parecer un detalle menor.

Pero cuando esa decisión se replica en cientos de miles de servidores, el impacto económico y ambiental es enorme.

Por eso la transición hacia ARM representa mucho más que una evolución tecnológica.

Es un cambio en la forma en que diseñamos la infraestructura del futuro.

Conclusión

La revolución de ARM no está ocurriendo porque sea más rápida que x86 en todos los escenarios.

Está ocurriendo porque ofrece una mejor relación entre rendimiento y consumo energético para muchas cargas modernas.

Y en un mundo donde la nube continúa creciendo a un ritmo acelerado, esa eficiencia puede marcar una diferencia significativa.

Quizá la próxima vez que despliegues una máquina virtual en Azure, la pregunta ya no sea únicamente cuántos vCPU necesitas.

Tal vez la verdadera pregunta sea:

¿Qué arquitectura es la más adecuada para tu carga de trabajo?

Referencias

Microsoft Azure – Virtual Machines (Dpsv5 y Dplsv5): https://learn.microsoft.com/azure/virtual-machines/
Ampere Computing – Cloud Native Processors: https://amperecomputing.com/
Microsoft Sustainability: https://www.microsoft.com/sustainability
Azure Sustainability: https://azure.microsoft.com/explore/global-infrastructure/sustainability/

AWS Graviton: Cómo mejorar el Precio-Rendimiento de tus workloads en AWS

Afu Tse (Chainiz) — Wed, 10 Jun 2026 21:51:10 +0000

Introducción

Reducir costos en la nube suele requerir iniciativas complejas: optimización de recursos, rediseño de arquitecturas, revisión de licencias o implementación de prácticas FinOps.

Sin embargo, existe una optimización que muchas organizaciones pasan por alto: migrar workloads desde instancias x86 tradicionales hacia instancias basadas en AWS Graviton.

AWS Graviton es una familia de procesadores ARM64 diseñados por Amazon para ejecutar cargas de trabajo cloud-native con una mejor relación entre costo, rendimiento y consumo energético.

Este artículo analiza qué es AWS Graviton, cuándo conviene utilizarlo y qué resultados reales han obtenido empresas que ya lo usan en producción.

El Problema: Más Costos Sin Más Valor

Muchas organizaciones ejecutan aplicaciones sobre procesadores Intel o AMD simplemente porque siempre lo han hecho.

Sin embargo, gran parte de las aplicaciones modernas:

APIs REST
Microservicios
Kubernetes
Docker
Node.js
Java
Python
Go
PostgreSQL
Redis

No requieren características específicas de x86.

En estos escenarios, seguir utilizando instancias tradicionales puede significar pagar más por resultados similares.

¿Qué es AWS Graviton?

AWS Graviton es una familia de procesadores ARM desarrollados por Amazon Web Services específicamente para la nube.

A diferencia de los procesadores genéricos utilizados en centros de datos tradicionales, Graviton fue diseñado para las cargas de trabajo más comunes dentro de AWS.

Generación	Año	Características
Graviton	2018	Primera generación
Graviton2	2020	Mejor rendimiento y menor costo
Graviton3	2022	Optimización para cómputo intensivo y Machine Learning
Graviton4	2024	Más núcleos, memoria y rendimiento

Beneficios de AWS Graviton

1. Menor costo operativo

Las instancias Graviton suelen ser más económicas que sus equivalentes x86.

En muchos escenarios los ahorros directos oscilan entre 10% y 25%.

2. Mejor precio-rendimiento

AWS promociona Graviton principalmente por su mejora en precio-rendimiento.

Esto significa obtener más capacidad de procesamiento por cada dólar invertido.

3. Menor consumo energético

Los procesadores ARM se caracterizan por su eficiencia energética.

Esto contribuye a reducir el consumo eléctrico y la huella de carbono de las cargas de trabajo.

4. Compatibilidad con el ecosistema moderno

Graviton funciona de forma nativa con:

Docker
Kubernetes (EKS)
ECS
Lambda
Node.js
Java
Python
Go
.NET
PostgreSQL
MySQL
Redis

Comparativa de Costos

Tomemos una instancia de propósito general con características similares.

Característica	x86 (M7i)	ARM (M7g)
vCPU	2	2
Memoria	8 GB	8 GB
Precio por hora	$0.096 USD	$0.077 USD
Diferencia	—	~20% menos

Cluster Kubernetes

Supongamos un cluster EKS con 20 nodos.

Concepto	x86	Graviton
Costo mensual	$1,402 USD	$1,124 USD
Ahorro mensual	—	$278 USD
Ahorro anual	—	$3,336 USD

Importante: AWS suele hablar de hasta 40% mejor precio-rendimiento, no necesariamente 40% menos costo. El beneficio combina ahorro económico y mayor rendimiento. En muchos casos, la reducción directa de costos se encuentra entre 10% y 25%.

Benchmarks Verificados

Amazon RDS PostgreSQL

AWS ejecutó benchmarks sobre Amazon RDS PostgreSQL comparando Graviton4 con generaciones anteriores. Los resultados mostraron:

Métrica	Graviton4 vs Graviton3	Graviton4 vs Graviton2
Queries por segundo	+23%	+41%
Queries por dólar	+23%	+34%
Latencia	-19%	-29%

Fuente:
https://aws.amazon.com/blogs/database/leveling-up-amazon-rds-with-aws-graviton4-benchmarks/

Casos de Éxito

Salesforce

Migró infraestructura analítica basada en Vertica hacia instancias AWS Graviton.

Resultados obtenidos:

15% reducción de costos
40%+ mejora en consultas
30%+ mejora en dashboards complejos
30% mejora en tasa de éxito de cargas

Fuente: https://aws.amazon.com/solutions/case-studies/salesforce-graviton-case-study/

Supabase

Migró PostgreSQL y APIs desde instancias T3a hacia T4g.

Resultados obtenidos:

28% mejor rendimiento
10% menor costo por instancia

Fuente: https://aws.amazon.com/ec2/graviton/customers/

Ably

Migró la mayoría de sus workloads Java, Go y Ruby.

Resultados obtenidos:

Hasta 40% mejor precio-rendimiento
Migración realizada por un único ingeniero en pocos meses

Fuente: https://aws.amazon.com/ec2/graviton/customers/

Quantcast

Migró su base de datos distribuida Kamke.

Resultados obtenidos:

40% mejor precio-rendimiento

Fuente: https://aws.amazon.com/ec2/graviton/customers/

Sprinklr

Migró microservicios y workloads intensivos de almacenamiento hacia Graviton4.

Resultados obtenidos:

15% mejora de rendimiento en microservicios Java
30% mejora en workloads storage-intensive
20% menos núcleos requeridos

Fuente: https://aws.amazon.com/solutions/case-studies/sprinklr-case-study-graviton/

¿Qué Debo Validar Antes de Migrar?

Compatibilidad ARM64

Verifica que:

Tu aplicación soporte ARM64
Tus dependencias soporten ARM64
Tus imágenes Docker tengan versión ARM64

Docker Multi-Arquitectura

docker buildx build \
  --platform linux/amd64,linux/arm64 \
  -t my-app:latest .

CI/CD

Asegúrate de que tus pipelines soporten compilación multi-arquitectura.

Benchmarking

Antes de migrar:

Despliega la aplicación en x86.
Despliega la misma aplicación en Graviton.
Ejecuta pruebas de carga.
Compara:

Throughput
Latencia
Uso de CPU
Consumo de memoria
Costo por hora

¿Cuándo Tiene Sentido Migrar?

AWS Graviton suele ser una excelente opción para:

Kubernetes (EKS)
Microservicios
APIs REST
Node.js
Java
Python
Go
PostgreSQL
Redis
Procesamiento de datos

Puede requerir más análisis cuando existen dependencias propietarias o binarios que únicamente soportan x86.

Conclusiones

AWS Graviton ya no es una tecnología emergente.

Empresas como Salesforce, Supabase, Ably, Quantcast y Sprinklr ejecutan workloads críticos sobre Graviton obteniendo mejoras medibles en costos y rendimiento.

Los resultados publicados muestran:

Entre 10% y 25% de ahorro directo en costos.
Hasta 40% mejor precio-rendimiento.
Mejoras significativas en throughput y latencia.
Menor consumo energético.

Para equipos DevOps, Platform Engineering y FinOps, Graviton representa una de las optimizaciones con mejor retorno de inversión disponibles actualmente en AWS.

La mejor forma de evaluar su impacto es sencilla:

Despliega una prueba de concepto, mide los resultados y deja que los números hablen por sí solos.

Referencias

AWS Graviton: https://aws.amazon.com/ec2/graviton/
AWS Graviton Customers: https://aws.amazon.com/ec2/graviton/customers
Salesforce Case Study: https://aws.amazon.com/solutions/case-studies/salesforce-graviton-case-study/
Sprinklr Case Study: https://aws.amazon.com/solutions/case-studies/sprinklr-case-study-graviton/
AWS Pricing Calculator: https://calculator.aws/
Amazon EKS: https://aws.amazon.com/eks/
Docker Multi-Platform Builds: https://docs.docker.com/build/building/multi-platform/
FinOps Foundation: https://www.finops.org/

Nota: Los resultados pueden variar según la carga de trabajo, la región AWS, la arquitectura de la aplicación y el tipo de instancia utilizado. Se recomienda realizar pruebas de rendimiento antes de una migración a producción.

Deploy OpenClaw on AWS Lightsail without manual headaches

Afu Tse (Chainiz) — Tue, 02 Jun 2026 13:43:34 +0000

This article is an English adaptation of the original Spanish post:
Desplegar OpenClaw en AWS Lightsail sin sufrir 😎

If you want to deploy OpenClaw on AWS Lightsail in a simple, repeatable way without fighting through manual steps every time, a great option is to use AWS CDK + Python + uv.

In this tutorial, I’ll show you how to provision the required infrastructure using Infrastructure as Code.

🦀 OpenClaw + AWS Lightsail + IaC

Why automate this?

Doing it manually once is fine.

Doing it manually again and again? Not so fun.

With Infrastructure as Code, you get:

Fewer manual errors
Consistent deployments
Fully repeatable environments
Faster setup for your team
Everything versioned in Git

The goal is not just to create a Lightsail instance. The goal is to have a deployment process that you can reproduce, destroy, improve, and run again whenever needed.

What does this stack create?

This project provisions an OpenClaw environment on AWS Lightsail, including:

An OpenClaw Lightsail instance: openclaw_ls_1_0
Public ports: 22, 80, and 443
A static public Lightsail IP
Optional snapshots
IAM role automation for Amazon Bedrock
Automatic association and disassociation of the static public IP during the stack lifecycle

Quick prerequisites

Before starting, make sure you have the following installed:

Python 3.11+
uv, for Python package and project management
Node.js 22 LTS
AWS CLI v2
AWS CDK CLI

You can install the AWS CDK CLI globally with:

npm i -g aws-cdk

0. Clone the repository

Clone the project repository: aws-cdk-lightsail-openclaw

git clone https://github.com/r3xakead0/aws-cdk-lightsail-openclaw.git
cd aws-cdk-lightsail-openclaw

1. Prepare your local environment

Before synthesizing or deploying the stack, prepare your local environment by installing the project dependencies and validating that your AWS credentials are configured correctly.

Check installed versions

python --version
uv --version
node --version
aws --version
cdk --version

Make sure you have:

Python 3.11+
uv installed
Node.js 22 LTS
AWS CLI v2
AWS CDK CLI

Install project dependencies

From the root of the repository, run:

uv sync

Configure your AWS credentials

If you do not have AWS credentials configured yet, run:

aws configure

You will need to provide:

AWS Access Key ID
AWS Secret Access Key
Default region, for example us-east-1
Default output format, for example json

If you use AWS profiles, export the profile before continuing.

For macOS/Linux:

export AWS_PROFILE=<TU_PROFILE>

For Windows PowerShell:

$env:AWS_PROFILE="<TU_PROFILE>"

Validate AWS access

Run:

aws sts get-caller-identity

You should see an output similar to:

{
  "UserId": "...",
  "Account": "123456789012",
  "Arn": "arn:aws:iam::X234X67X901X:user/your-user"
}

2. Review the configuration file

Open the following file:

config/dev.json

Validate the main fields:

account
region, for example us-east-1
availability_zone, for example us-east-1a
key_pair_name, for example openclaw-dev-key
ssh_cidr
enable_auto_snapshot, which is false by default

This file defines the environment-specific configuration for your deployment.

3. Create or import the Lightsail key pair

This part is important: the key pair must be a Lightsail key pair, not an EC2 key pair.

It also needs to exist in the same region defined in your configuration file.

macOS/Linux

Generate the key:

ssh-keygen -t rsa -b 4096 -m PEM -f ~/.ssh/openclaw-dev-key -C "openclaw-lightsail"
chmod 600 ~/.ssh/openclaw-dev-key
chmod 644 ~/.ssh/openclaw-dev-key.pub

Import it into Lightsail:

aws lightsail import-key-pair \
  --key-pair-name openclaw-dev-key \
  --public-key-base64 "$(cat ~/.ssh/openclaw-dev-key.pub)" \
  --region us-east-1

Validate that the key pair exists:

aws lightsail get-key-pairs \
  --region us-east-1 \
  --query "keyPairs[?name=='openclaw-dev-key'].name" \
  --output table

Windows PowerShell

Generate the key:

ssh-keygen -t rsa -b 4096 -m PEM -f "$HOME\.ssh\openclaw-dev-key" -C "openclaw-lightsail"

Import it into Lightsail:

$pub = Get-Content "$HOME\.ssh\openclaw-dev-key.pub" -Raw
aws lightsail import-key-pair `
  --key-pair-name openclaw-dev-key `
  --public-key-base64 $pub `
  --region us-east-1

Validate it:

aws lightsail get-key-pairs --region us-east-1 --query "keyPairs[?name=='openclaw-dev-key'].name" --output table

4. Bootstrap CDK

You only need to bootstrap once per AWS account and region.

Linux/macOS

./scripts/linux-mac/dev/bootstrap <ACCOUNT_ID> <REGION>

Windows PowerShell

.\scripts\windows\dev\bootstrap.ps1 -AccountId <ACCOUNT_ID> -Region <REGION>

5. Run synth and diff

Before deploying, it is a good idea to synthesize the CloudFormation template and review the changes.

Linux/macOS

./scripts/linux-mac/dev/synth
./scripts/linux-mac/dev/diff

Windows PowerShell

.\scripts\windows\dev\synth.ps1
.\scripts\windows\dev\diff.ps1

The diff step helps you review what CDK is going to create, update, or remove before applying the deployment.

6. Deploy

Now deploy the stack.

Linux/macOS

./scripts/linux-mac/dev/deploy

Windows PowerShell

.\scripts\windows\dev\deploy.ps1

When the deployment finishes, you should see outputs such as:

InstanceName
StaticIpName
PublicIp
BedrockRoleArn

7. Verify that everything is running

Connect to the instance using SSH.

Linux/macOS

ssh -i ~/.ssh/openclaw-dev-key ubuntu@<PUBLIC_IP>

Windows PowerShell

ssh -i "$HOME\.ssh\openclaw-dev-key" ubuntu@<PUBLIC_IP>

Then run a quick check:

Open http://<PUBLIC_IP> in your browser
Verify the instance in the Lightsail console
Confirm that the Bedrock IAM role exists

At this point, your OpenClaw deployment should be up and running on AWS Lightsail.

8. Destroy the stack when you are done

If this is just a test environment, do not forget to destroy the resources when you finish to avoid unnecessary costs.

Linux/macOS

./scripts/linux-mac/dev/destroy

Windows PowerShell

.\scripts\windows\dev\destroy.ps1

Troubleshooting

`The KeyPair does not exist`

This usually means one of the following:

The key pair was not created or imported into Lightsail
The key pair exists in another region
The key pair is an EC2 key pair instead of a Lightsail key pair

To fix it, create or import the key pair in Lightsail and make sure it is in the correct AWS region.

Stack stuck in `ROLLBACK_COMPLETE`

If the stack failed and ended in ROLLBACK_COMPLETE, delete the failed stack and deploy again.

CDK Node.js warning

If CDK shows a warning related to Node.js, make sure you are using Node.js 22 LTS.

If you use nvm, run:

nvm use

Final thoughts

The main idea behind this project is not only to deploy an instance.

The real value is having a repeatable deployment process that does not depend on lost notes, forgotten manual steps, or one-time console configurations.

With AWS CDK, Python, uv, and Lightsail, you can keep the setup simple while still applying Infrastructure as Code practices from the beginning.

This makes the deployment easier to reproduce, easier to destroy, and easier to improve over time.

Desplegar OpenClaw en AWS Lightsail sin sufrir 😎

Afu Tse (Chainiz) — Fri, 24 Apr 2026 15:09:45 +0000

Si deseas desplegar OpenClaw en AWS Lightsail de manera simple, sencilla, repetible y sin pelear con pasos manuales, una buena opción es usar AWS CDK + Python + uv.

En este tutorial te muestro cómo levantar toda la infraestructura con Infrastructure as Code.

🦀 OpenClaw + AWS Lightsail + IaC

¿Por qué automatizar esto?

Porque hacerlo a mano una vez está bien, pero repetirlo muchas veces es "pesado".

Con IaC (Infrastructure as Code) ganas:

Menos errores humanos
Despliegues consistentes
Repetibilidad total (crear y destruir cuando quieras)
Más velocidad para tu equipo
Todo versionado en Git

¿Que crea este stack o proyecto?

Tu infraestructura en Lightsail con:

Instancia OpenClaw (openclaw_ls_1_0)
Puertos públicos 22, 80, 443
IP estática pública de Lightsail
Snapshots opcionales
Automatización de rol IAM para Bedrock
Asociación/desasociación automática de la IP estática pública durante el ciclo de vida del stack

Pre requisitos rápidos

Necesitas tener instalado:

Python 3.11+
uv (Gestor de paquetes y proyectos)
Node.js 22 LTS
AWS CLI v2
AWS CDK CLI (npm i -g aws-cdk)

0) Clona el repositorio

Clonar el repositorio de github del proyecto aws-cdk-lightsail-openclaw

git clone https://github.com/r3xakead0/aws-cdk-lightsail-openclaw.git
cd aws-cdk-lightsail-openclaw

1) Prepara el entorno local

Antes de sintetizar o desplegar el stack, prepara tu entorno local instalando las dependencias del proyecto y validando que tus credenciales de AWS estén configuradas correctamente.

Verifica las versiones instaladas

python --version
uv --version
node --version
aws --version
cdk --version

Asegúrate de tener:

Python 3.11+
uv instalado
Node.js 22 LTS
AWS CLI v2
AWS CDK CLI

Instala las dependencias del proyecto

Desde la raíz del repositorio, ejecuta:

uv sync

Configura tus credenciales de AWS

Si todavía no tienes credenciales configuradas, ejecuta:

aws configure

Ingresa tu:

AWS Access Key ID
AWS Secret Access Key
Default region, por ejemplo us-east-1
Default output format, por ejemplo json

Si usas perfiles de AWS, puedes exportar el perfil antes de continuar:

macOS/Linux

export AWS_PROFILE=<TU_PROFILE>

Windows PowerShell

$env:AWS_PROFILE="<TU_PROFILE>"

Valida el acceso a AWS

aws sts get-caller-identity

Deberías ver una salida similar a:

{
  "UserId": "...",
  "Account": "123456789012",
  "Arn": "arn:aws:iam::123456789012:user/your-user"
}

2) Revisa el archivo de configuración

Archivo: config/dev.json

Asegúrate de validar estos campos:

account
región (ej. us-east-1)
availability_zone (ej. us-east-1a)
key_pair_name (ej. openclaw-dev-key)
ssh_cidr
enable_auto_snapshot (false por defecto)

3) Crea/importa el key pair en Lightsail

Importante: tiene que ser de Lightsail (no EC2) y en la misma region especificada en el archivo de configuración.

macOS/Linux

Genera la clave:

ssh-keygen -t rsa -b 4096 -m PEM -f ~/.ssh/openclaw-dev-key -C "openclaw-lightsail"
chmod 600 ~/.ssh/openclaw-dev-key
chmod 644 ~/.ssh/openclaw-dev-key.pub

Impórtala:

aws lightsail import-key-pair \
  --key-pair-name openclaw-dev-key \
  --public-key-base64 "$(cat ~/.ssh/openclaw-dev-key.pub)" \
  --region us-east-1

Valídala:

aws lightsail get-key-pairs \
  --region us-east-1 \
  --query "keyPairs[?name=='openclaw-dev-key'].name" \
  --output table

Windows PowerShell

Genera la clave:

ssh-keygen -t rsa -b 4096 -m PEM -f "$HOME\.ssh\openclaw-dev-key" -C "openclaw-lightsail"

Impórtala:

$pub = Get-Content "$HOME\.ssh\openclaw-dev-key.pub" -Raw
aws lightsail import-key-pair `
  --key-pair-name openclaw-dev-key `
  --public-key-base64 $pub `
  --region us-east-1

Valídala:

aws lightsail get-key-pairs --region us-east-1 --query "keyPairs[?name=='openclaw-dev-key'].name" --output table

4) Bootstrap (solo una vez por cuenta/region)

Linux/macOS

./scripts/linux-mac/dev/bootstrap <ACCOUNT_ID> <REGION>

Windows PowerShell

.\scripts\windows\dev\bootstrap.ps1 -AccountId <ACCOUNT_ID> -Region <REGION>

5) Synth + Diff (para revisar antes de desplegar)

Linux/macOS

./scripts/linux-mac/dev/synth
./scripts/linux-mac/dev/diff

Windows PowerShell

.\scripts\windows\dev\synth.ps1
.\scripts\windows\dev\diff.ps1

6) Deploy

Linux/macOS

./scripts/linux-mac/dev/deploy

Windows PowerShell

.\scripts\windows\dev\deploy.ps1

Cuando termine, verás outputs como:

InstanceName
StaticIpName
PublicIp
BedrockRoleArn

7) Verifica que todo este vivo

Conéctate por SSH:

Linux/macOS

ssh -i ~/.ssh/openclaw-dev-key ubuntu@<PUBLIC_IP>

Windows PowerShell

ssh -i "$HOME\.ssh\openclaw-dev-key" ubuntu@<PUBLIC_IP>

Chequeo rápido:

abre http://<PUBLIC_IP>
revisa la instancia en consola de Lightsail
confirma que el rol de Bedrock existe en IAM

8) Destroy cuando termines (para no gastar de mas)

Linux/macOS

./scripts/linux-mac/dev/destroy

Windows PowerShell

.\scripts\windows\dev\destroy.ps1

Solución de problemas

`The KeyPair does not exist`

El key pair no esta en Lightsail, esta en otra region o es de EC2.
Solución: crealo/importalo en Lightsail y en la region correcta.

Stack en `ROLLBACK_COMPLETE`

Borra el stack fallido y vuelve a desplegar.

Warning de Node en CDK

Ejecuta nvm use para usar Node 22 LTS.

Conclusión

La idea no es solo desplegar una instancia, sino dejar el proceso listo para repetirse sin depender de pasos manuales ni configuraciones perdidas.

Instalación de JFrog Artifactory OSS en Ubuntu 22.04 (Jammy) + PostgreSQL - Guia Completa

Afu Tse (Chainiz) — Fri, 06 Feb 2026 13:58:22 +0000

Tutorial paso a paso para instalar JFrog Artifactory OSS en Ubuntu 22.04 (Jammy) usando PostgreSQL.

⚠️ Nota: Este setup no está pensado para producción. Cambia contraseñas, restringe accesos y revisa backups/SSL antes de usarlo en entornos reales.

Contenido

Requisitos
Arquitectura
0. Preparación de Ubuntu 22.04 (Jammy)
1. Base de datos PostgreSQL
2. Instalar Artifactory OSS
3. Configurar Artifactory OSS para usar PostgreSQL
4. Iniciar Artifactory
5. Abrir puertos (firewall)
6. Entrar a la UI y credenciales por defecto
Comandos útiles
Referencias

Requisitos

VM con Ubuntu 22.04 (Jammy)
Acceso sudo (superusuario)
Conectividad a internet para bajar paquetes
Puertos abiertos en firewall (al menos 8082)

Arquitectura

0. Preparación de Ubuntu 22.04 (Jammy)

Confirmar que estás en Jammy:

lsb_release -a

cat /etc/os-release

Actualizar librerías:

sudo apt update && sudo apt -y upgrade

1. Base de datos PostgreSQL

1.1 Instalar PostgreSQL

sudo apt install -y postgresql postgresql-contrib
sudo systemctl enable --now postgresql
sudo systemctl status postgresql --no-pager

1.2 Crear la base de datos y usuario para Artifactory

sudo -u postgres psql <<'SQL'
CREATE USER artifactory WITH PASSWORD 'ArtifactoryDemo123!';
CREATE DATABASE artifactory OWNER artifactory ENCODING 'UTF8';
GRANT ALL PRIVILEGES ON DATABASE artifactory TO artifactory;
SQL

⚠️ Recomendación: cambia esta contraseña si la VM no es 100% privada.

2. Instalar Artifactory OSS

2.1 Agregar repositorio + key

Agregar el repo OSS (para Jammy):

echo "deb https://releases.jfrog.io/artifactory/artifactory-debs jammy main" | sudo tee -a /etc/apt/sources.list

Agregar la key GPG:

wget -qO - https://releases.jfrog.io/artifactory/api/gpg/key/public | sudo apt-key add -

2.2 Instalar Artifactory OSS (Open Source)

JFrog recomienda tener net-tools como prerequisito:

sudo apt-get update
sudo apt-get install -y net-tools
sudo apt-get install -y jfrog-artifactory-oss

3. Configurar Artifactory OSS para usar PostgreSQL

La configuración principal está en:

JFROG_HOME por defecto: /opt/jfrog
Archivo: /opt/jfrog/artifactory/var/etc/system.yaml

3.1 Detener Artifactory

sudo systemctl stop artifactory

3.2 Editar `system.yaml`

Abrir el archivo system.yaml con editor VIM:

sudo vim /opt/jfrog/artifactory/var/etc/system.yaml

Agregar/ajustar esta sección shared:

shared:
  database:
    type: postgresql
    driver: org.postgresql.Driver
    url: jdbc:postgresql://127.0.0.1:5432/artifactory
    username: artifactory
    password: ArtifactoryDemo123!

4. Iniciar Artifactory

sudo systemctl start artifactory.service
sudo systemctl status artifactory.service --no-pager

Ver logs si hace falta:

sudo journalctl -u artifactory -n 200 --no-pager

5. Abrir puertos (firewall)

Para la UI normalmente se usa 8082 (y a veces 8081 según el setup). Para este caso, abre al menos 8082.

sudo ufw allow 8082/tcp
sudo ufw status

6. Entrar a la UI y credenciales por defecto

Abrir:

http://<TU_IP>:8082/
http://<TU_IP>:8082/ui/
Login directo: http://<TU_IP>:8082/ui/login

Credenciales por defecto:

admin / password

⚠️ Cambia la contraseña apenas puedas.

Fix rápido (OSS): deshabilitar jfconnect (workaround login “stuck”)

Si al iniciar sesión el botón queda inactivo o se “queda pegado” el login (reportado en OSS 7.125.x), aplica este workaround:

Edita:

sudo vim /opt/jfrog/artifactory/var/etc/system.yaml

Agrega esto a nivel raíz (top-level), NO dentro de shared:

jfconnect:
  enabled: false

Reinicia:

sudo systemctl restart artifactory

Prueba de nuevo: http://:8082/ui/ o http://:8082/ui/login

Comandos útiles

Estado del servicio:

sudo systemctl status artifactory --no-pager

Logs recientes:

sudo journalctl -u artifactory -n 200 --no-pager

Reiniciar:

sudo systemctl restart artifactory

Verifica que el puertos está escuchando y en qué interfaz:

sudo ss -lntp | egrep ':8081|:8082'
curl -I http://127.0.0.1:8082/ | head
curl -I http://127.0.0.1:8081/ | head

Referencias

JFrog Platform Installation Documentation: https://jfrog.com/help/r/jfrog-platform-installation-documentation
Install Artifactory on Debian/Ubuntu (APT): https://jfrog.com/help/r/jfrog-installation-setup-documentation/install-artifactory-on-debian
PostgreSQL Documentation: https://www.postgresql.org/docs/

Implementar un sitio web estático en Cloudflare Pages usando Terraform y Wrangler CLI

Afu Tse (Chainiz) — Sun, 25 Jan 2026 22:58:01 +0000

En este tutorial, aprenderá a implementar un sitio web estático en Cloudflare Pages usando Terraform para el aprovisionamiento de infraestructura y Wrangler CLI para la implementación manual.

Este enfoque le permite administrar su proyecto de Cloudflare Pages como Infraestructura como Código (IaC), manteniendo un proceso de implementación simple y flexible.

Qué aprenderás

Al finalizar este tutorial, podrás:

Aprovisionar un proyecto de Cloudflare Pages con Terraform
Implementar un sitio web estático con la CLI de Wrangler
Configurar un dominio personalizado (opcional)
Administrar tu infraestructura de forma limpia y reproducible
Destruir todos los recursos de forma segura cuando ya no sean necesarios

¿Por qué Cloudflare Pages + Terraform?

Cloudflare Pages ofrece una plataforma rápida, global y sin servidor para alojar sitios web estáticos.

Terraform te permite definir y versionar tu infraestructura, lo que garantiza la consistencia y repetibilidad de tus implementaciones.

La combinación de ambas herramientas te ofrece:

Infraestructura como Código
CDN global rápida
Implementación sencilla de sitios estáticos
Gestión sencilla de dominios
Separación clara entre infraestructura y aplicación

Requisitos Previos

Antes de comenzar, asegúrese de tener:

Terraform instalado (versión 1.10.0 o superior)
Cuenta de Cloudflare con acceso a Pages
API Token de Cloudflare con permisos de Cloudflare Pages
Node.js y npm instalados (para Wrangler CLI)

Estructura del Proyecto

cloudflare-tf-staticweb/
└── infrastructure/           # Carpeta con archivos terraform
    ├── main.tf               # Configuración de Terraform
    ├── providers.tf          # Configuración de providers
    ├── variables.tf          # Definición de variables
    ├── cloudflare.tf         # Recursos de Cloudflare Pages
    ├── outputs.tf            # Outputs del proyecto
    ├── terraform.tfvars      # Variables (no versionar)
└── website/                  # Carpeta con el sitio web estático
    └── index.html            # Contiene el HTLM de la página principal
    └── styles.css            # Contiene el CSS de la página principal
    └── script.js             # Contiene el JS de la página principal

Variables

Variable	Descripción	Requerida	Default
`cloudflare_api_token`	API Token de Cloudflare	Sí	-
`cloudflare_account_id`	Account ID de Cloudflare	Sí	-
`project_name`	Nombre del proyecto	No	"my-website"
`custom_domain`	Dominio personalizado	No	""

Configuración Inicial

1. Crear el Proyecto

# Crear la estructura de carpetas
mkdir cloudflare-tf-staticweb
cd cloudflare-tf-staticweb

2. Configurar la Infraestructura

En la carpeta "cloudflare-tf-staticweb"

# Crear la carpeta de la infraestructura
mkdir infrastructure

# Accede a la carpeta infraestructura
cd infrastructure

# Crear el archivo "main.tf"
cat <<EOF > main.tf
terraform {
  required_version = ">= 1.10.0"

  required_providers {
    cloudflare = {
      source  = "cloudflare/cloudflare"
      version = "~> 4.0"
    }
  }
}
EOF

# Crear el archivo "provider.tf"
cat <<EOF > provider.tf
provider "cloudflare" {
  api_token = var.cloudflare_api_token
}
EOF

# Crear el archivo "variables.tf"
cat <<EOF > variables.tf
variable "cloudflare_api_token" {
  description = "The API token for Cloudflare account"
  type        = string
  sensitive   = true
}

variable "cloudflare_account_id" {
  description = "Cloudflare Account ID (visible on dashboard)"
  type        = string
}

variable "project_name" {
  description = "Project name in Cloudflare Pages"
  type        = string
  default     = "my-website"
}

variable "custom_domain" {
  description = "Custom domain (optional, leave blank if not used)"
  type        = string
  default     = ""
}
EOF

# Crear el archivo "outputs.tf"
cat <<EOF > outputs.tf
output "pages_project_url" {
  description = "Full URL of the Cloudflare Pages project"
  value       = "https://${cloudflare_pages_project.website.subdomain}"
}

output "pages_project_subdomain" {
  description = "Subdomain assigned by Cloudflare Pages"
  value       = cloudflare_pages_project.website.subdomain
}

output "project_id" {
  description = "Cloudflare project ID"
  value       = cloudflare_pages_project.website.id
}

output "project_name" {
  description = "Project Name"
  value       = cloudflare_pages_project.website.name
}

output "custom_domain_url" {
  description = "Custom domain URL (if configured)"
  value       = var.custom_domain != "" ? "https://${var.custom_domain}" : "Not configured"
}
EOF

# Crear el archivo "cloudflare.tf"
cat <<EOF > cloudflare.tf
resource "cloudflare_pages_project" "website" {
  account_id        = var.cloudflare_account_id
  name              = var.project_name
  production_branch = "main"

  build_config {
    build_command   = ""        # No build required for static HTML
    destination_dir = "website" # Folder containing index.html
    root_dir        = ""        # Repository root
  }

  # Environment variables (if needed in the future)
  deployment_configs {
    production {
      environment_variables = {
        ENVIRONMENT = "production"
      }
    }

    preview {
      environment_variables = {
        ENVIRONMENT = "preview"
      }
    }
  }

}

# Custom domain (optional)
resource "cloudflare_pages_domain" "custom_domain" {
  count        = var.custom_domain != "" ? 1 : 0
  account_id   = var.cloudflare_account_id
  project_name = cloudflare_pages_project.website.name
  domain       = var.custom_domain
}
EOF

3. Configurar la pagina web

En la carpeta "cloudflare-tf-staticweb"

# Crear la carpeta del sitio web
mkdir website

# Accede a la del sitio web
cd website

# Crear el archivo "index.html"
cat > index.html << 'EOF'
<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Simple Web App</title>
    <link rel="stylesheet" href="styles.css">
</head>
<body>
    <div class="container">
        <h1 id="greeting">Hello, World!</h1>
        <input type="text" id="nameInput" placeholder="Enter your name">
        <button id="updateBtn">Update Greeting</button>
    </div>
    <script src="script.js"></script>
</body>
</html>
EOF

# Crear el archivo "styles.css"
cat > styles.css << 'EOF'
* {
    margin: 0;
    padding: 0;
    box-sizing: border-box;
}

body {
    font-family: 'Segoe UI', Tahoma, Geneva, Verdana, sans-serif;
    background: linear-gradient(135deg, #6a11cb 0%, #2575fc 100%);
    min-height: 100vh;
    display: flex;
    justify-content: center;
    align-items: center;
}

.container {
    background: white;
    padding: 2rem;
    border-radius: 10px;
    box-shadow: 0 10px 30px rgba(0, 0, 0, 0.2);
    text-align: center;
    max-width: 400px;
    width: 90%;
}

h1 {
    color: #333;
    margin-bottom: 1.5rem;
    font-size: 2rem;
}

input {
    padding: 0.8rem;
    width: 100%;
    margin-bottom: 1rem;
    border: 2px solid #ddd;
    border-radius: 5px;
    font-size: 1rem;
}

input:focus {
    outline: none;
    border-color: #2575fc;
}

button {
    background: #2575fc;
    color: white;
    border: none;
    padding: 0.8rem 1.5rem;
    border-radius: 5px;
    cursor: pointer;
    font-size: 1rem;
    transition: background 0.3s;
}

button:hover {
    background: #1a68e8;
}
EOF

# Crear el archivo "script.js"
cat > script.js << 'EOF'
// Get DOM elements
const greetingElement = document.getElementById('greeting');
const nameInput = document.getElementById('nameInput');
const updateButton = document.getElementById('updateBtn');

// Update greeting when button is clicked
updateButton.addEventListener('click', () => {
    const name = nameInput.value.trim();

    if (name) {
        greetingElement.textContent = `Hello, ${name}!`;
        nameInput.value = ''; // Clear input
    } else {
        greetingElement.textContent = 'Please enter your name!';
        setTimeout(() => {
            greetingElement.textContent = 'Hello, World!';
        }, 2000);
    }
});

// Also update on Enter key press
nameInput.addEventListener('keypress', (e) => {
    if (e.key === 'Enter') {
        updateButton.click();
    }
});
EOF

4. Obtener tu Account ID en Cloudflare

Ve al Cloudflare Dashboard → Account Home
Click en los 3 puntos la lado del "Account Name"
Click en "Copy account ID"

5. Crear API Token en Cloudflare

Ve a Cloudflare Dashboard → Manage Account → Account API Tokens
Click en "Create Token" → "Create Custom Token"

Configura los permisos necesarios:

Token name: Terraform Cloudflare Pages

Permissions:
├── Account
│   ├── Cloudflare Pages → Edit
│   └── Account Settings → Read
└── Zone (opcional, solo si usas dominio personalizado)
    └── DNS → Edit

Zone Resources:
└── Include → All zones from an account → Your_Account

Click en "Continue to summary" → "Create Token"
Copia el token inmediatamente (solo se muestra una vez)

6. Actualizar Configuración

Crear el archivos de variables y asignar los valores

cloudflare_account_id obtenido del paso 4
cloudflare_api_token obtenido del paso 5

# Crear el archivo "terraform.tfvars"
cat <<EOF > terraform.tfvars
# Cloudflare Account ID
cloudflare_account_id = "your-account-id-here"


# Cloudflare API Token
cloudflare_api_token = "your-token"

# Project name
project_name = "my-website"

# Custom domain (optional, leave blank if not used)
custom_domain = ""
EOF

Uso

Crear la Infraestructura con Terraform

Accede a la carpeta infraestructura

cd infrastructure

Inicializar Terraform

terraform init

Validar la configuración

terraform validate
terraform fmt

Planificar cambios

terraform plan

Aplicar cambios

terraform apply -auto-approve

Esto creará el proyecto de Cloudflare Pages, pero aún no habrá contenido desplegado.

Ver outputs

terraform output

Desplegar el Sitio Web con Wrangler

Una vez que Terraform haya creado el proyecto, despliega tu sitio:

1. Instalar Wrangler (solo la primera vez)

npm install -g wrangler

2. Autenticar con Cloudflare

wrangler login

Esto abrirá un navegador para que autorices Wrangler.

3. Desplegar el sitio

Desde la raíz del proyecto

wrangler pages deploy website --project-name=my-website

Reemplaza my-website con el valor de tu variable project_name.

4. Verificar el despliegue

Visita la URL mostrada en el output de Terraform o en el resultado del comando deploy:

terraform output pages_project_url

pages_project_url = "https://my-website-xxx.pages.dev"

Despliegues Futuros

Para actualizar tu sitio después de hacer cambios:

Edita tus archivos en website/
Despliega de nuevo

wrangler pages deploy website --project-name=my-website

Reemplaza my-website con el valor de tu variable project_name.

Dominio Personalizado

Para agregar un dominio personalizado:

Actualiza terraform.tfvars:
```
custom_domain = "www.tudominio.com"
```
Asegúrate de que el dominio esté en Cloudflare
Aplica los cambios
```
terraform apply
```

Destruir Recursos

terraform destroy -auto-approve

Recursos Adicionales

Valkey vs Redis – Explicación simple y practica

Afu Tse (Chainiz) — Thu, 08 Jan 2026 21:59:36 +0000

🔑 ¿Qué es Valkey?

Valkey es un fork open-source de Redis, creado en 2024, totalmente compatible, creado tras el cambio de licencia de Redis para mantener una alternativa 100% open source y respaldado por la Linux Foundation.

Surge como respuesta al cambio de licencia de Redis (Redis ≥ 7.4), que dejó de ser open source bajo los estándares de la OSI.

👉 Objetivo de Valkey

Mantener un Redis 100% open source
Compatibilidad total con Redis (comandos, protocolo, clientes)
Gobernanza comunitaria y neutral
Sin vendor lock-in

En la práctica:

Valkey es Redis, pero con licencia abierta y desarrollo comunitario.

🧠 ¿Para qué sirve Valkey?

Exactamente los mismos casos de uso que Redis:

Cache in-memory
Session store
Pub/Sub
Rate limiting
Distributed locks
Streams
Leaderboards
Replication
Persistence (RDB / AOF)
Redis Cluster

⚖️ Valkey vs Redis (comparación rápida)

Característica	Valkey	Redis (≥ 7.4)
Licencia	✅ Open Source (BSD/Apache-style)	❌ RSAL / SSPL
Gobernanza	Linux Foundation	Redis Inc
Compatibilidad	100% Redis	Nativa
Uso comercial	✅ Libre	⚠️ Restricciones
Vendor lock-in	❌ Bajo	⚠️ Mayor
Cloud friendly	✅ Sí	⚠️ Limitado
Soporte K8s	✅ Excelente	✅

🧾 La licencia: el punto clave

Redis hoy

Licencia RSAL / SSPL
No considerada open source por la OSI
Restricciones para SaaS y cloud providers

Valkey

Open source real
Uso comercial sin restricciones
Ideal para empresas, educación y gobiernos

Por eso AWS, Google, Oracle y otros proveedores apoyan Valkey.

🧪 Demo 1 – Valkey local con Docker

docker run -d --name valkey -p 6379:6379 valkey/valkey:latest

Prueba rápida:

redis-cli ping
# PONG

redis-cli set demo "hola valkey"
redis-cli get demo

🧪 Demo 2 – Pub/Sub

Terminal A:

redis-cli subscribe events

Terminal B:

redis-cli publish events "mensaje desde valkey"

Terminal A:

☸️ Demo 3 – Valkey en Kubernetes

Crear el archivo "valkey.yaml"

apiVersion: v1
kind: Namespace
metadata:
  name: demo
---
apiVersion: v1
kind: Service
metadata:
  name: valkey
  namespace: demo
  labels:
    app: valkey
spec:
  # Headless Service required by StatefulSet
  clusterIP: None
  selector:
    app: valkey
  ports:
    - name: redis
      port: 6379
      targetPort: 6379
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: valkey
  namespace: demo
spec:
  serviceName: valkey
  replicas: 1
  selector:
    matchLabels:
      app: valkey
  template:
    metadata:
      labels:
        app: valkey
    spec:
      containers:
        - name: valkey
          image: valkey/valkey:latest
          ports:
            - name: redis
              containerPort: 6379
          volumeMounts:
            - name: data
              mountPath: /data
          readinessProbe:
            tcpSocket:
              port: 6379
            initialDelaySeconds: 5
            periodSeconds: 5
          livenessProbe:
            tcpSocket:
              port: 6379
            initialDelaySeconds: 15
            periodSeconds: 10
  volumeClaimTemplates:
    - metadata:
        name: data
      spec:
        accessModes:
          - ReadWriteOnce
        resources:
          requests:
            storage: 1Gi

Desplegar:

kubectl apply -f valkey.yaml

Acceso desde un pod:

kubectl run -it --rm vcli -n demo --image=redis:7 -- bash

Ejecuta el ping para validar conexion

redis-cli -h valkey.demo.svc.cluster.local ping
PONG

Código fuente : k8s-valkey-demo

🔄 ¿Tengo que cambiar código si vengo de Redis?

👉 No.

Mismos comandos
Mismo protocolo RESP
Mismos clientes (redis-cli, node-redis, ioredis, etc.)

Solo cambia la imagen:

image: valkey/valkey

🚀 Conclusión

Si estás construyendo:

Kubernetes
SaaS
Plataformas cloud
Proyectos open source

👉 Valkey es la opción recomendada hoy.

Develop Kubernetes Services Locally (Yes, Really) with Telepresence

Afu Tse (Chainiz) — Wed, 07 Jan 2026 19:19:26 +0000

🚀 What is Telepresence?

Telepresenceis a development tool that lets you connect your local machine directly to a Kubernetes cluster — as if your app were running inside the cluster, even though it’s actually running on your laptop.

🔥 Build, run, and debug Kubernetes services locally, without rebuilding Docker images or redeploying on every change.

🧩 What do developers use Telepresence for?

Telepresence shines in day-to-day Kubernetes development:

✅ Local development against a real cluster
• Your application runs locally
• But it consumes real cluster resources:
• Services
• ConfigMaps
• Secrets
• Internal APIs

No mocks. No fakes. Just real infrastructure.

✅ Intercepting Service traffic
• Telepresence can intercept traffic destined for a Kubernetes Service
• That traffic is transparently redirected to your local app

From the cluster’s point of view, nothing changes.

✅ Fast, comfortable debugging
• Use local logs
• Attach debuggers (VS Code, IntelliJ, etc.)
• Hot reload
• Breakpoints

🙌 All without modifying or risking remote or production environments.

😖 The problem Telepresence solves

❌ Traditional Kubernetes workflow

Every tiny change usually means:

Modify code
docker build
docker push
kubectl apply
Wait for rollout
Test
Repeat 😵‍💫

That’s minutes per iteration — and it kills productivity.

✅ With Telepresence

The workflow becomes:

Change code locally
Save
Test instantly

⏱️ Feedback in seconds, not minutes.

⚙️ How does Telepresence work?

High-level flow:
• Connects to your Kubernetes cluster
• Deploys a Traffic Manager (proxy)
• Intercepts traffic for a Service
• Forwards that traffic to your local machine

From Kubernetes’ perspective:

👉 Your app still exists in the cluster — it just happens to live on your local machine.

🧪 Simple example

Without Telepresence

echo Service → Pod in Kubernetes

With Telepresence

echo Service → your laptop (localhost:9000)

Everything else stays the same:
• Databases
• Other microservices
• Secrets

🔗 Source code: github

🌟 Why you should care

• ⚡ Much faster development cycles
• 🧪 Real debugging against real infrastructure
• 🛡️ Lower risk (no touching prod clusters)
• 🧩 Perfect fit for Kubernetes & microservices

If you work with Kubernetes daily, Telepresence can seriously change how fast — and how comfortably — you build software.

🔗 References

Ejecuta tus servicios de Kubernetes desde tu local con Telepresence

Afu Tse (Chainiz) — Wed, 07 Jan 2026 18:51:56 +0000

¿Qué es Telepresence?

Telepresence es una herramienta de desarrollo que te permite conectar tu computadora local a un clúster de Kubernetes como si tu aplicación local estuviera corriendo dentro del cluster.

En pocas palabras:
🔥 Te deja desarrollar y depurar servicios de Kubernetes sin construir imágenes Docker ni hacer deploy cada vez.

¿Para qué se usa Telepresence?

Se usa principalmente para:

✅ Desarrollo local contra Kubernetes real

Tu app corre localmente
Pero consume Services, ConfigMaps, Secrets y APIs reales del cluster

✅ Interceptar tráfico de un Service

Redirige el tráfico que iba a un Service del cluster
Hacia tu aplicación local

✅ Debugging rápido

Puedes usar logs locales
Debuggers (VS Code, IntelliJ)
Hot reload
Breakpoints

🙌 Todo sin tocar el cluster remoto y/o productivo.

¿Por qué Telepresence es de gran ayuda?

Porque soluciona dolores reales del desarrollo con Kubernetes.

❌ Sin Telepresence (El problema tradicional)

Cada cambio implica:

Cambiar código
docker build
docker push
kubectl apply
Esperar el rollout
Probar
Repetir 😵‍💫

Esto puede tomar minutos por cambio.

✅ Con Telepresence

El flujo se vuelve:

Cambias código local
Guardas
Pruebas inmediatamente

⏱️ Cambios en segundos, no minutos.

¿Cómo funciona Telepresence?

Flujo:

Se conecta al cluster
Inserta un proxy (Traffic Manager)
Intercepta el tráfico de un Service
Lo envía a tu máquina

Desde Kubernetes:
👉 Parece que tu app sigue ahí, pero en realidad está en tu computadora.

Ejemplo

Sin Telepresence:

echo Service → Pod en Kubernetes

Con Telepresence:

echo Service → tu laptop (localhost:9000)

Y el resto del cluster se mantiene igual

Databases
Otros microservicios
Secrets

🔗 Codigo fuente: minikube-telepresence-demo

Beneficios

Desarrollo muchísimo más rápido
Debug real contra infraestructura real
Menor riesgo (no tocas ambientes remotos y/o productivos)
Ideal para Kubernetes + microservicios

Ejecuta Qwen3 + Ollama + Open WebUI en Docker: Tu propio AI Chat local 🧠

Afu Tse (Chainiz) — Fri, 02 Jan 2026 22:15:41 +0000

¿Quieres montar tu propio entorno de IA local con un modelo potente sin pagar por la nube?

Con el repositorio qwen3-container puedes hacerlo fácilmente usando Docker Compose, Ollama y Open WebUI 👇

🔗 código fuente

🔥 En este post te explico qué es, cómo funciona y por qué es útil este proyecto.

🧠 ¿Qué es Qwen3?

Qwen3 es la última generación de modelos de lenguaje grande (LLM) de Alibaba Cloud — disponible en múltiples tamaños y con capacidades impresionantes de generación de texto, razonamiento y tareas complejas.

🧰 ¿Qué hace este repositorio?

El proyecto qwen3-container ofrece un stack listo para producción local que combina:

🧠 Ollama — runtime local para LLMs, con Qwen3 precargado
🌐 Open WebUI — interfaz web tipo chat para interactuar con el modelo
🐳 Docker + Docker Compose — para levantar todo con un solo comando

Esto te permite tener un chat local basado en Qwen3 sin depender de APIs externas ni costos por tokens.

🛠️ ¿Cómo funciona el stack?

El proyecto define dos servicios principales:

📌 ollama-qwen3
Ejecuta el modelo Qwen3 dentro de Ollama y expone una API REST en localhost:11434.
📌 open-webui
Proporciona una interfaz de chat en localhost:3000 desde el navegador, donde puedes conversar con Qwen3 sin programar nada.

📦 Instalación rápida

Clona el repositorio

git clone https://github.com/r3xakead0/qwen3-container.git
cd qwen3-container

Configura tu .env (puedes basarte en .env.example)

# Genera un secreto seguro
openssl rand -hex 32

Levanta los contenedores

docker compose up -d

Acceder
- 📡 API: http://localhost:11434
- 🧠 UI chat: http://localhost:3000

💡 ¿Por qué usar esto?

✅ Privacidad y control: tus datos nunca salen de tu máquina
✅ Sin dependencia de la nube: ni tokens ni facturación
✅ Desarrollo rápido: ideal para prototipos, PoCs o herramientas internas
✅ Personalización: puedes enchufar el API de Ollama a tus propias apps

Este stack es ideal si estás trabajando con soluciones de IA local o quieres explorar modelos open-weight como Qwen3 sin pagar por servicios externos.

🔗 Articulo de referencia

🧩 Recomendaciones

👉 Cambia el valor de WEBUI_SECRET_KEY por un secreto largo y seguro.
👉 Una vez inicializado, deshabilita el registro de nuevos usuarios para proteger tu instancia.