DEV Community: Steven Carvajal

ESP32-C6 vs ESP32-C3: Wi-Fi 6 y Thread, ¿vale la pena el cambio?

Steven Carvajal — Sun, 25 Oct 2026 09:36:15 +0000

Publicado originalmente en iot.gripe.

El ESP32-C3 es el chip barato de Espressif para nodos sencillos. El ESP32-C6 es su sucesor directo: mismo tipo de CPU (RISC-V), pero con Wi-Fi 6 y una segunda radio para Thread y Zigbee. ¿Compensa pagar más por él?

La respuesta corta: solo si necesitas Thread, Zigbee o Matter sobre Thread. Si tu proyecto es un nodo Wi-Fi o ESP-NOW, el C3 sigue siendo la mejor compra.

Fichas completas: ESP32-C6 y ESP32-C3.

Diferencias que importan

	ESP32-C3	ESP32-C6
CPU	1 núcleo RISC-V, 160 MHz	1 núcleo RISC-V, 160 MHz, + 1 de bajo consumo (20 MHz)
SRAM	400 KB	512 KB (+ 16 KB de bajo consumo)
Wi-Fi	Wi-Fi 4 (802.11 b/g/n)	Wi-Fi 6 (802.11ax) y Wi-Fi 4
Bluetooth	LE 5	LE 5.3
Thread y Zigbee	No	Sí (radio 802.15.4)
Matter	Sobre Wi-Fi	Sobre Wi-Fi y sobre Thread
GPIO del chip	22	30 (QFN40)
Canales ADC	6	7
UART / I2C	2 / 1	2 + 1 de bajo consumo / 1 + 1 de bajo consumo
Consumo en sueño profundo	unos 5 µA	unos 7 µA
Precio de la placa	3–8 €	8–14 €

Valores de las hojas de datos de Espressif; el consumo real depende de la placa (reguladores, LED).

Wi-Fi 6: ¿qué cambia en un microcontrolador?

El C6 es Wi-Fi 6 solo como cliente, en banda de 2,4 GHz y con canales de 20 MHz. No obtiene mayor velocidad que el C3 en la práctica. La ventaja útil es Target Wake Time (TWT): el chip y el router acuerdan cuándo se despierta el dispositivo, lo que reduce el consumo en nodos a batería.

Para aprovecharlo necesitas un router Wi-Fi 6 que soporte TWT. Con un router antiguo, el C6 se comporta como un C3 más caro.

Thread, Zigbee y Matter: la razón de existir del C6

La segunda radio del C6 (802.15.4) permite tres cosas que el C3 no hace:

Thread: una red en malla de bajo consumo y sin hub Wi-Fi, la base de los dispositivos Matter a batería.
Zigbee: sensores, bombillos e interruptores compatibles con las redes Zigbee ya existentes.
Matter sobre Thread, además de Matter sobre Wi-Fi (que el C3 también soporta).

Si quieres que tu dispositivo aparezca en Apple Home o Google Home como un producto Matter, o unirte a una red Zigbee, el C6 es la opción barata y simple. Para entender cuándo conviene cada protocolo, mira la comparativa de Zigbee, Thread, Matter, Wi-Fi y ESP-NOW.

Pines y periféricos

El C6 expone más GPIO (30 en el chip contra 22) y un canal de ADC más (7 contra 6). Las placas pequeñas reducen esa diferencia: una ESP32-C3 Super Mini saca 13 pines; una ESP32-C6 DevKitC-1 saca bastantes más.

Ambos tienen USB Serial/JTAG integrado (no es USB OTG): sirve para cargar programas y para el puerto serie, pero no para actuar como teclado o memoria.

Consumo en batería

Los dos están diseñados para bajo consumo. El C6 añade un núcleo de bajo consumo de 20 MHz que puede vigilar sensores mientras el principal duerme, útil para despertar solo cuando algo cambia. En sueño profundo puro, el C3 gasta un poco menos. Si usas deep sleep con batería, la diferencia real la marca el resto de la placa (regulador, LED) más que el chip.

Soporte en Arduino

El C3 lleva más tiempo en el mercado y funciona con prácticamente todas las librerías. El C6 tiene soporte desde el núcleo Arduino-ESP32 3.x, pero hay librerías que aún no lo reconocen, y las funciones de Thread y Zigbee se programan con ESP-IDF o con los ejemplos de Zigbee del núcleo, no con la API sencilla de Wi-Fi.

Antes de comprarlo, comprueba que las librerías de tu proyecto (pantallas, sensores) lo soporten.

¿Cuál elegir?

Si tu proyecto es…	Elige
Nodo Wi-Fi o ESP-NOW sencillo (relé, sensor)	C3
Muchas unidades donde el precio cuenta	C3
Dispositivo Matter sobre Thread	C6
Sensor Zigbee o pasarela Zigbee/Thread	C6
Nodo a batería con router Wi-Fi 6	C6 (por TWT)
Necesitas más de 13 pines o más memoria	C6 o un ESP32-S3

Si necesitas doble núcleo, USB OTG o IA en el borde, ninguno de los dos: mira ESP32-S3 vs ESP32-C3.

Preguntas frecuentes

¿El ESP32-C6 es más rápido que el C3?

No. Los dos funcionan a 160 MHz con un núcleo RISC-V. El C6 tiene un poco más de memoria y un segundo núcleo, pero de bajo consumo.

¿Puedo usar Thread con el ESP32-C3?

No. El C3 no tiene la radio 802.15.4. Necesitarías un C6 o un H2.

¿Y el ESP32-H2?

El H2 también tiene Thread y Zigbee, pero no tiene Wi-Fi. Sirve para dispositivos que hablan solo con una pasarela Thread.

¿El C6 funciona con ESP-NOW?

Sí, igual que el C3, por Wi-Fi en 2,4 GHz.

ESP32-C6 DevKitC-1
ESP32-C3 Super Mini

Pinout del ESP32 DevKit explicado: qué pin usar para cada cosa

Steven Carvajal — Sat, 24 Oct 2026 09:19:45 +0000

Publicado originalmente en iot.gripe.

El primer problema al usar un ESP32 es que sus pines no son todos iguales. Una placa Arduino UNO te deja usar casi cualquier pin; en el ESP32 algunos solo sirven de entrada, otros están conectados a la memoria flash y otros deciden cómo arranca la placa.

Esta guía explica el pinout de la ESP32-DevKitC V4 (la placa de 38 pines con módulo WROOM-32). Muchas placas genéricas de 30 pines usan el mismo chip y casi la misma distribución; comprueba los rótulos de la tuya antes de conectar nada. Para ver las especificaciones del chip, está la ficha del ESP32.

Cómo leer el diagrama

Cada pin tiene un nombre de la placa (IO23, VP, D2…) y un número de GPIO. En el código se usa siempre el número de GPIO: IO23 es 23; VP es GPIO36 y VN es GPIO39.

Resumen por tipo de pin

Grupo	GPIO	Qué hacer
Uso general, seguros	4, 13, 14, 16, 17, 18, 19, 21, 22, 23, 25, 26, 27, 32, 33	Úsalos como entrada o salida
Solo entrada	34, 35, 36 (VP), 39 (VN)	Sensores y botones; nunca salidas
Memoria flash	6, 7, 8, 9, 10, 11	No los uses jamás
Arranque (strapping)	0, 2, 5, 12, 15	Cuidado con lo que les conectas
Consola serie (UART0)	1 (TX), 3 (RX)	Déjalos libres para cargar y depurar

Pines solo de entrada: 34, 35, 36 y 39

Estos cuatro pines no pueden ser salidas y tampoco tienen resistencias internas de pull-up o pull-down. Sirven para leer sensores analógicos o pulsadores, pero con un botón necesitas una resistencia externa:

const int BOTON = 34;     // solo entrada: necesita resistencia externa

void setup() {
  Serial.begin(115200);
  pinMode(BOTON, INPUT);  // INPUT_PULLUP no funciona en este pin
}

void loop() {
  Serial.println(digitalRead(BOTON));
  delay(200);
}

Conecta el botón entre el pin y 3,3 V, con una resistencia de unos 10 kΩ del pin a GND.

Pines de la memoria flash: 6 a 11

Los pines marcados CLK, D0, D1, D2, D3 y CMD (GPIO6 a GPIO11) son los que usa el ESP32 para leer su propio programa de la flash. Si los usas, el chip se reinicia o se cuelga. Las placas de 30 pines a veces los exponen: ignóralos.

Pines de arranque: 0, 2, 5, 12 y 15

Al encender, el chip lee el nivel de estos pines para decidir cómo iniciar:

GPIO	Qué decide	Problema típico
0	Modo de descarga si está a nivel bajo (botón BOOT)	Un sensor lo mantiene a nivel bajo y la placa no arranca
2	Debe estar bajo o al aire para cargar un programa	El LED integrado suele estar aquí
5	Temporización de SDIO	Poco problemático, pero evítalo si puedes
12	Voltaje de la flash	Con nivel alto al arrancar, falla el inicio en módulos de 3,3 V
15	Muestra u oculta el registro de arranque	Un relé aquí puede cambiar el comportamiento

Pueden usarse como GPIO normales una vez arrancado, pero no conectes cargas, módulos o resistencias fuertes que fuercen un nivel. Si el ESP32 no se deja programar, comprueba primero estos pines.

ADC1 frente a ADC2

El ESP32 tiene dos convertidores analógicos (ADC):

ADC1: GPIO32, 33, 34, 35, 36 y 39.
ADC2: GPIO0, 2, 4, 12, 13, 14, 15, 25, 26 y 27.

El ADC2 no funciona mientras el Wi-Fi está activo. Con Wi-Fi, lee sensores analógicos solo en los pines de ADC1. Es la causa de "mi sensor funcionaba y dejó de funcionar al agregar el Wi-Fi".

const int SENSOR = 34;   // ADC1_6: válido con Wi-Fi

void loop() {
  int lectura = analogRead(SENSOR);   // 0 a 4095
  Serial.println(lectura);
  delay(500);
}

DAC y táctiles

DAC (salida analógica real de 8 bits): GPIO25 y GPIO26.
Sensores táctiles: GPIO4, 0, 2, 15, 13, 12, 14, 27, 33 y 32 (TOUCH0 a TOUCH9). Detectan un dedo sin pulsador.

Pines por defecto de I2C, SPI y UART

El ESP32 puede asignar casi cualquier periférico a cualquier pin libre, así que estos son solo los valores por defecto del núcleo de Arduino:

Bus	Señal	GPIO
I2C	SDA / SCL	21 / 22
SPI (VSPI)	SS / MOSI / MISO / SCK	5 / 23 / 19 / 18
UART0	TX / RX	1 / 3
UART2	TX / RX	17 / 16

Si cambias de placa o de versión del núcleo, escribe los pines en el código: Wire.begin(21, 22);.

Límites eléctricos

Los GPIO son de 3,3 V; con 5 V puedes dañarlos. Usa un divisor de tensión o un conversor de nivel.
No pidas más de unos 20 mA por pin. Para relés y motores usa un transistor o un módulo con optoacoplador. Más en cómo alimentar un ESP32.
El pin 5V (VIN) sale del USB; no es una entrada de señal.

Lista de pines seguros

Para un proyecto con Wi-Fi:

Salidas digitales y relés: 13, 14, 16, 17, 18, 19, 21, 22, 23, 25, 26, 27.
Entradas digitales con pull-up: los mismos pines.
Entradas analógicas: 32, 33, 34, 35, 36 y 39.
Pulsadores y sensores: 4, 13, 14, 27, 32 y 33.

Preguntas frecuentes

¿Cuántos pines puedo usar realmente?

Una DevKitC de 38 pines expone unos 25 GPIO útiles. Descontando los de flash y los solo entrada, quedan unos 20 para salidas.

¿Por qué mi placa no arranca con algo conectado?

Casi siempre es un pin de arranque (0, 2, 5, 12 o 15) forzado por un módulo. Desconecta el módulo y reinicia.

¿Qué diferencia hay con el pinout del ESP32-S3?

El S3 tiene más GPIO, USB nativo y otros pines de arranque. Está explicado en pines del ESP32-S3.

ESP32 DevKitC WROOM-32

Pines del ESP32-S3: cuáles usar, cuáles evitar y por qué

Steven Carvajal — Fri, 23 Oct 2026 09:46:57 +0000

Publicado originalmente en iot.gripe.

El ESP32-S3 tiene 45 GPIO, pero no todos se pueden usar igual. Algunos deciden cómo arranca la placa, otros son el USB, y los de la memoria PSRAM quedan ocupados según la variante. Elegir mal un pin da síntomas confusos: la placa no arranca, el USB deja de responder o una lectura analógica falla solo cuando enciendes el Wi-Fi.

Esta guía usa la placa ESP32-S3-DevKitC-1 v1.1 como referencia. Si tu placa es de otro fabricante, el chip es el mismo, pero el orden y los rótulos pueden cambiar: compáralo con su esquema. Para ver todas las especificaciones del chip, está la ficha del ESP32-S3.

Resumen rápido

Grupo	GPIO	Qué hacer
Seguros para uso general	1, 2, 4–18, 21, 38–42, 47, 48	Úsalos con calma; revisa los matices de abajo
Arranque (strapping)	0, 3, 45, 46	Evítalos o cuida su nivel al encender
USB nativo	19 (D−), 20 (D+)	No los uses si necesitas el conector USB
Consola serie (UART0)	43 (TX), 44 (RX)	Déjalos libres para depurar
PSRAM octal	35, 36, 37	Ocupados en módulos N8R8 y N16R8
Memoria flash interna	26–32	No existen en la placa: son de la flash

Los pines de arranque: 0, 3, 45 y 46

Al encender, el chip lee el nivel de estos pines y decide cómo iniciar:

GPIO0: a nivel bajo entra en modo de descarga. Es el botón BOOT de la placa.
GPIO45: fija el voltaje de la memoria flash interna.
GPIO46: controla si se muestra el registro de arranque por el puerto serie.
GPIO3: elige la fuente de JTAG.

Puedes usarlos como GPIO normales después del arranque, pero si algo externo los fuerza a un nivel equivocado en el momento del encendido, la placa no inicia o arranca en un modo raro. Un sensor o un relé con resistencia de pull-up o pull-down en estos pines es la causa típica de "funciona al conectar el USB pero no al encenderlo solo".

Regla práctica: si tienes pines libres de sobra, no uses estos cuatro.

USB nativo: GPIO19 y GPIO20

El ESP32-S3 tiene USB integrado en el chip. Los pines GPIO19 (D−) y GPIO20 (D+) van al conector marcado USB de la placa. Si los configuras como entrada o salida, pierdes el USB nativo: no podrás cargar programas por ese conector ni usar el puerto serie USB (CDC) hasta reiniciar con otro código.

Si ves que el ESP32 no aparece en el puerto USB justo después de usar GPIO19 o GPIO20, esa es la causa más probable.

La placa tiene dos conectores: el de UART (convertidor USB-serie, pasa por GPIO43 y GPIO44) y el de USB (nativo). Para cargar programas basta cualquiera de los dos.

PSRAM octal: GPIO35, 36 y 37

Las variantes con PSRAM octal (N8R8, N16R8: "R8" indica 8 MB de PSRAM) usan GPIO35, GPIO36 y GPIO37 para hablar con la memoria. En esos módulos no están disponibles. En una variante sin PSRAM octal (por ejemplo, N8 o N16 a secas) quedan libres, pero si quieres que tu código funcione en cualquier variante, no los uses.

Los GPIO26 a GPIO32 conectan la flash interna y no salen a la placa. Los GPIO33 y GPIO34 tampoco salen en la DevKitC-1.

ADC1 frente a ADC2

El ESP32-S3 tiene dos convertidores analógicos con 20 canales en total:

ADC1: GPIO1 a GPIO10.
ADC2: GPIO11 a GPIO20.

El Wi-Fi comparte hardware con ADC2. Con el Wi-Fi activo, una lectura en ADC2 puede fallar o devolver un error por timeout. Si tu proyecto usa Wi-Fi y lee un sensor analógico, conéctalo a un pin de ADC1 (GPIO1 a GPIO10).

const int PIN_SENSOR = 4;   // ADC1_3: seguro con Wi-Fi activo

void setup() {
  Serial.begin(115200);
  analogReadResolution(12);      // 0 a 4095
}

void loop() {
  int lectura = analogRead(PIN_SENSOR);
  Serial.println(lectura);
  delay(500);
}

Las lecturas del ADC del ESP32 no son perfectamente lineales. Si necesitas precisión, usa analogReadMilliVolts(), que aplica la calibración de fábrica.

Entradas táctiles

Los GPIO1 a GPIO14 pueden funcionar como sensores táctiles capacitivos (TOUCH1 a TOUCH14). Sirven para botones sin pulsador: basta un cable o una lámina de metal conectada al pin.

JTAG: GPIO39 a GPIO42

Los pines 39 a 42 (MTCK, MTDO, MTDI, MTMS) son la interfaz JTAG para depurar con hardware externo. Si no usas JTAG externo, son GPIO normales. El ESP32-S3 también trae depuración JTAG por el USB integrado, así que rara vez necesitas ocuparlos.

Pines por defecto de I2C, SPI y UART

Casi cualquier periférico puede asignarse a cualquier GPIO libre gracias a la matriz de pines del chip, así que los "pines por defecto" son solo una convención del núcleo de Arduino. En la DevKitC-1 son:

Bus	Señal	GPIO
I2C	SDA / SCL	8 / 9
SPI	SS / MOSI / SCK / MISO	10 / 11 / 12 / 13
UART0	TX / RX	43 / 44

Estos valores vienen del archivo pins_arduino.h de la variante y pueden cambiar entre versiones del núcleo o entre placas. Si algo no responde, imprime SDA, SCL, MOSI y SCK en el Monitor Serie o fíjalos tú:

#include <Wire.h>

void setup() {
  Wire.begin(8, 9);   // SDA, SCL explícitos
}

Fijar los pines en el código evita sorpresas al cambiar de placa.

El LED integrado

La DevKitC-1 trae un LED RGB direccionable (tipo WS2812), no un LED simple. Está en GPIO38 en la versión 1.1 y en GPIO48 en la 1.0. Se maneja con neopixelWrite:

void setup() {}

void loop() {
  neopixelWrite(RGB_BUILTIN, 0, 20, 0);   // verde tenue
  delay(500);
  neopixelWrite(RGB_BUILTIN, 0, 0, 0);    // apagado
  delay(500);
}

RGB_BUILTIN apunta al pin correcto en tu versión de la placa. Si prefieres no depender de él, ese pin cuenta como ocupado en tu lista.

Límites eléctricos

Los GPIO trabajan a 3,3 V. No conectes señales de 5 V directamente: usa un divisor de tensión o un conversor de nivel.
Por cada pin no pidas más de unos 20 mA. Para relés, motores o tiras LED, usa un transistor, un MOSFET o un módulo con optoacoplador, y alimenta la carga aparte. Más detalle en cómo alimentar un ESP32.
Une siempre las tierras (GND) de todos los dispositivos que se comunican.

Lista de pines seguros

Para un proyecto con Wi-Fi, sin PSRAM octal y sin USB nativo:

Entradas analógicas: GPIO1 a GPIO10 (ADC1).
Salidas digitales y relés: GPIO4 a GPIO7, GPIO15 a GPIO18, GPIO21, GPIO47.
I2C: GPIO8 y GPIO9.
SPI: GPIO10 a GPIO13.

Y cuando algo falle sin razón aparente, revisa en este orden: pines de arranque, USB, PSRAM, ADC2 con Wi-Fi.

Preguntas frecuentes

¿Cuántos pines puedo usar realmente en una DevKitC-1?

Unos 36 GPIO llegan a los conectores. Con PSRAM octal bajan a 33, y si reservas los de arranque y la consola serie, quedan en torno a 25 para uso cómodo.

¿Puedo usar GPIO19 y GPIO20 como pines normales?

Sí, pero pierdes el USB nativo. Mantén a mano el conector UART para volver a cargar un programa si algo sale mal.

¿Por qué mi sensor analógico deja de funcionar al conectarme al Wi-Fi?

Probablemente está en un pin de ADC2 (GPIO11 a GPIO20). Muévelo a un pin de ADC1 (GPIO1 a GPIO10).

¿En qué se diferencian los pines del ESP32-S3 y del ESP32-C3?

El C3 tiene solo 22 GPIO, un único ADC útil con Wi-Fi y sin USB en la mayoría de placas pequeñas. Para elegir entre ambos, lee ESP32-S3 vs ESP32-C3.

ESP32-S3 DevKitC-1 N16R8

De proyecto casero a producto IoT: qué cambia cuando tus dispositivos salen de tu casa

Steven Carvajal — Thu, 22 Oct 2026 09:52:33 +0000

Publicado originalmente en iot.gripe.

Hacer que un ESP32 encienda una luz desde el celular lleva un fin de semana. Hacer que cien ESP32 funcionen en cien casas distintas, configurados por otras personas, con usuarios que no conoces y sin que tengas que visitar a nadie, es otro proyecto.

Esta guía reúne lo que cambia en ese camino: los problemas que no existen en un prototipo y que aparecen en cuanto los dispositivos salen de tu escritorio.

1. Un solo firmware para todos

En un prototipo, el Wi-Fi, el certificado y la configuración suelen estar escritos en el código. Con clientes, eso significa compilar un firmware distinto por dispositivo, a mano, con una llave privada copiada entre ventanas.

Lo que cambia: un firmware genérico, igual para todos, y la configuración propia de cada dispositivo se entrega después de instalarlo y se guarda en su memoria (parte 6).

2. Aprovisionamiento sin visita técnica

Alguien que no eres tú tiene que poder poner en marcha el dispositivo.

Lo que cambia:

un portal de configuración: el dispositivo nuevo levanta su propia red Wi-Fi con un formulario (parte 16);
aprovisionamiento en la nube, para que cada dispositivo obtenga su propio certificado sin quemarlo en el firmware (parte 17);
confirmación humana para emparejar dispositivos nuevos, para que nadie pueda colarse en un sistema ajeno;
una forma de instalar el firmware sin herramientas, como un botón en el navegador (parte 20).

3. Aislamiento entre clientes

Con un solo usuario, los permisos pueden decir el nombre de tu dispositivo. Con varios clientes, la pregunta es: ¿qué impide que uno controle la casa de otro?

Lo que cambia: el aislamiento tiene que estar en los permisos de la nube, no solo en el código de la app. Cada dispositivo limitado a sus tópicos con políticas de IoT con variables (parte 13), y cada usuario limitado a sus datos por la API o por IAM, a partir de un token verificado.

4. Usuarios, roles y permisos

Lo que cambia:

registro por invitación y contraseña propia desde el primer login (parte 11);
separar los roles de la plataforma (quien la opera) de los roles dentro de cada casa (quien usa los dispositivos);
permisos aplicados en el servidor y una forma rápida de revocarlos.

5. Actualizaciones a distancia

Un error en el firmware de un prototipo se corrige con el cable. En casa de un cliente, no.

Lo que cambia: actualizaciones OTA con despliegue gradual (primero tus dispositivos, después unos pocos clientes, luego el resto), retraso aleatorio para no saturar el servidor y vuelta automática a la versión anterior si la nueva falla. Lo explico en la guía de instalación de firmware de este blog.

6. La infraestructura, en código

En un prototipo, crear un rol o una función en la consola "solo para probar" es normal. Con clientes, cada cambio manual es algo que nadie podrá reconstruir si se borra.

Lo que cambia: la infraestructura definida en código (AWS CDK, Terraform), revisable y reproducible. Pasar a código lo que se creó a mano suele destapar permisos desactualizados y otros que sobran (parte 12).

7. Seguridad revisada, no supuesta

Lo que cambia: auditorías periódicas de lo que existe de verdad en la cuenta, no de lo documentado. Es habitual encontrar funciones públicas olvidadas y roles con comodines heredados de prototipos (parte 21).

8. Saber cuánto cuesta cada cliente

Lo que cambia: el costo por cliente es lo que decide el precio. Con una arquitectura serverless, el costo de la nube por casa puede quedar en centavos; lo que más lo mueve es la frecuencia de la telemetría (parte 22).

9. Lo que no es código

Certificaciones de radio. Un dispositivo con Wi-Fi o Bluetooth que se vende necesita cumplir la normativa de radio y seguridad eléctrica de cada país (por ejemplo, el marcado CE en la Unión Europea). Usar módulos ya certificados ayuda, pero el producto final suele requerir sus propias pruebas. Consulta con un laboratorio antes de vender.
Privacidad. Si guardas datos de personas, la normativa de protección de datos aplica (en Europa, el RGPD): qué guardas, para qué y por cuánto tiempo.
Soporte. ¿Qué pasa cuando alguien pierde el acceso a su cuenta o un dispositivo deja de responder? Decide el proceso antes de tener el primer caso.
Correo. Enviar contraseñas o avisos por correo requiere un servicio configurado para enviar a cualquier dirección; en AWS, SES empieza en un modo de pruebas.

Lista de comprobación

Área	¿Lo tienes?
Firmware	Un solo binario; configuración después de instalar
Aprovisionamiento	El cliente pone en marcha el dispositivo sin ti
Identidad	Certificado propio por dispositivo, entregado de forma segura
Aislamiento	Permisos de la nube que separan a cada cliente
Usuarios	Roles, permisos en el servidor y revocación
Actualizaciones	OTA gradual con vuelta atrás
Infraestructura	Definida en código
Seguridad	Auditoría periódica
Costos	Costo por cliente conocido
Normativa	Radio, seguridad eléctrica y privacidad revisadas

Preguntas frecuentes

¿Cuándo debería empezar a pensar en esto?

Cuando el segundo dispositivo va a una casa que no es la tuya. Antes, optimiza para aprender rápido; después, cada atajo se paga con interés.

¿Necesito una plataforma como AWS para vender dispositivos?

No necesariamente, pero alguien tiene que resolver identidad, permisos, disponibilidad y actualizaciones. Una plataforma administrada te ahorra mantener servidores.

¿Qué suele ser lo más difícil?

Los permisos. Que cada cliente solo vea lo suyo y que eso lo garantice la nube, no la interfaz. Conviene diseñarlo desde el primer cliente, no después.

Todos los artículos sobre web app, infraestructura y producto

Casa inteligente DIY desde cero con ESP32 y AWS: guía para planificarla

Steven Carvajal — Wed, 21 Oct 2026 09:51:40 +0000

Publicado originalmente en iot.gripe.

Hacer tu propia casa inteligente es uno de los proyectos más satisfactorios con ESP32: lo usas todos los días y aprendes de electrónica, redes, nube y aplicaciones a la vez. También es fácil empezar mal y terminar con un montón de dispositivos sueltos, cada uno con su app.

Esta guía te ayuda a planificarla antes de soldar nada. Reúne las decisiones que conviene tomar desde el principio, con enlaces a la serie de domótica de este blog para cada pieza.

Paso 1: decide qué quieres resolver

Antes del hardware, escribe qué quieres hacer. Algunos ejemplos:

Encender y apagar luces desde el celular y por voz.
Que las luces sigan funcionando con el interruptor de siempre si se cae internet.
Que varias personas de la casa tengan acceso.
Automatizaciones por horario o por presencia.

Esta lista decide todo lo demás. Por ejemplo, exigir que el interruptor funcione sin internet cambia el diseño del firmware (parte 18).

Paso 2: local, en la nube o híbrida

	Local (Home Assistant, ESPHome)	En la nube (propia, con AWS)
Funciona sin internet	Sí	El control remoto no; los interruptores físicos sí, si los diseñas así
Control fuera de casa	Requiere VPN o un servicio de acceso remoto	Directo
Mantenimiento	Un servidor en tu casa	Servicios administrados
Varias casas	Una instalación por casa	Una sola plataforma
Curva de aprendizaje	Baja con ESPHome	Alta: nube, permisos, app

Si solo quieres domotizar tu casa, Home Assistant con ESPHome es probablemente el camino más corto. La nube tiene sentido si quieres control remoto sin abrir puertos ni mantener un servidor, o aprender a construir cada pieza. La arquitectura está en la parte 1 de la serie de domótica.

Paso 3: el hardware

Controladores: placas ESP32. Un ESP32-S3 para el que habla con la nube y ESP32-C3 para cada luz es una combinación equilibrada (parte 2).
Actuadores: módulos de relé para encender cargas. Revisa la tensión y la corriente que admiten, y si se activan en alto o en bajo.
Entradas: los interruptores de pared que ya tienes, conectados a un pin del ESP32; sensores de movimiento, temperatura o puertas.
Alimentación: una fuente adecuada y aislada para cada dispositivo que vaya en la pared.
Cajas: aptas para instalaciones eléctricas, con separación entre la parte de red eléctrica y la de baja tensión.

Paso 4: cómo se comunican

Hay dos opciones principales:

Cada dispositivo al Wi-Fi: simple al principio, pero con muchos dispositivos se vuelve frágil: cada uno ocupa el router y, si va a la nube, necesita su propia conexión segura.
Una pasarela: un solo dispositivo conectado a internet y el resto hablando con él por ESP-NOW, Zigbee o Thread.

Con una pasarela y ESP-NOW, los nodos no necesitan la contraseña del Wi-Fi y la nube solo ve un dispositivo por casa (parte 4). La comparación de opciones está en la guía de comunicación de este blog.

Paso 5: seguridad eléctrica (no te la saltes)

Una casa inteligente toca la red eléctrica: 230 V a 50 Hz en España y buena parte de Europa, entre 110 y 127 V a 60 Hz en México y gran parte de América. Un error puede causar una descarga o un incendio.

Si no tienes experiencia con instalaciones eléctricas, pide ayuda a un electricista.
Corta el circuito en el tablero antes de tocar cualquier cable y comprueba que no hay tensión.
Usa componentes dimensionados para la carga y certificados para tu país.
Respeta la normativa local: en muchos lugares, las instalaciones fijas deben hacerlas profesionales habilitados.

Puedes desarrollar todo el sistema con LEDs en la mesa y dejar la conexión a la red para el final.

Paso 6: la app, la voz y los usuarios

Una web app instalable (PWA) te da un ícono en el celular sin pasar por las tiendas de apps (parte 15).
Voz: un Atajo de Siri que llama a una API es la forma más simple de controlar por voz un sistema propio (parte 9). En Android, apps como HTTP Shortcuts hacen lo mismo.
Usuarios: si vive más gente en casa, piensa desde el principio quién puede controlar qué (parte 11).

Paso 7: el costo

Hardware: una placa por dispositivo, más relés, fuentes y cajas. Es el mayor gasto.
Nube: con una pasarela por casa, centavos al mes en AWS (parte 22).
Local: el consumo eléctrico y el costo del servidor (por ejemplo, un Raspberry Pi o un mini PC).

Una hoja de ruta realista

Un ESP32 que enciende un LED desde el celular (por Wi-Fi o con la nube).
Un segundo dispositivo y la comunicación entre ellos.
El interruptor físico y el comportamiento sin internet.
La app, los usuarios y la voz.
La seguridad: identidad por dispositivo, permisos y revisión.
Por último, la instalación eléctrica real, con ayuda profesional.

Preguntas frecuentes

¿Necesito saber programar?

Para ESPHome y Home Assistant, muy poco. Para un sistema propio, sí: firmware en C++, una app web y algo de nube.

¿Qué hago si se cae internet?

Diseña para que lo esencial funcione igual: interruptores físicos que actúan directamente sobre la luz y dispositivos que se ponen al día cuando vuelve la conexión.

¿Es caro?

El hardware de una luz inteligente hecha con un ESP32-C3 y un relé suele costar menos que un interruptor inteligente comercial. Lo que más inviertes es tiempo.

Todos los artículos sobre casa inteligente DIY y voz

Cómo instalar firmware en un ESP32: USB, navegador u OTA, y cuándo usar cada uno

Steven Carvajal — Tue, 20 Oct 2026 09:50:20 +0000

Publicado originalmente en iot.gripe.

Escribir el firmware es la mitad del trabajo. La otra mitad es llevarlo al dispositivo: la primera vez, cuando hay que corregir un error y cuando el dispositivo ya está en casa de un cliente. Para eso hay tres caminos, cada uno con su momento.

En esta guía comparo las tres formas de instalar firmware en un ESP32, cómo se configura un dispositivo recién instalado y qué hay que prever para actualizar una flota sin dejar dispositivos inservibles.

Las tres formas

	USB (Arduino IDE, esptool)	Navegador (ESP Web Tools)	OTA (por red)
Necesita	Computador con herramientas instaladas y cable	Chrome o Edge de escritorio y cable	Que el dispositivo ya tenga un firmware con OTA y acceso a la red
Ideal para	Desarrollo	Instalar o reinstalar sin herramientas	Actualizar dispositivos ya instalados
¿Borra la configuración?	No, salvo que borres la flash	Sí, en una instalación nueva	No
Riesgo	Bajo	Bajo	Si falla a mitad, el dispositivo puede quedar inservible si no hay plan B

1. Por USB: para desarrollar

Es la forma de siempre: compilas y cargas desde Arduino IDE, PlatformIO o la línea de comandos con esptool. Durante el desarrollo es la más rápida.

Dos detalles que conviene saber:

Cargar un sketch no borra la partición NVS. Si tu firmware guarda configuración, sobrevive a una carga nueva. Para empezar de cero, borra la flash completa (esptool.py erase_flash).
El cable importa. Muchos cables USB solo cargan. Si el computador no ve la placa, prueba otro cable antes que otros drivers.

2. Desde el navegador: para instalar sin herramientas

Chrome y Edge de escritorio implementan Web Serial, que permite a una página web hablar con un dispositivo USB. ESP Web Tools, el componente que usa Home Assistant, aprovecha eso para instalar firmware con un botón: detecta el chip, borra la memoria y escribe el binario correcto.

Un ejemplo: un botón en un panel web que detecta si conectaste un ESP32-S3 o un ESP32-C3 e instala el firmware que corresponde a cada uno. El paso a paso está en la parte 20 de la serie.

No funciona en Safari, Firefox ni en iPhone. Para una herramienta de instalación desde un computador, no es un problema.

Después de instalar: la configuración

Un firmware genérico, igual para todos los dispositivos, necesita recibir después lo que es propio de cada uno: el Wi-Fi, su identidad en la nube, su papel en el sistema. Las formas habituales:

Un punto de acceso con un formulario web: el dispositivo sin configurar levanta su propia red Wi-Fi; te conectas con el celular y llenas los datos (parte 16).
Aprovisionamiento en la nube: el dispositivo pide su propio certificado la primera vez que se conecta, por ejemplo con Fleet Provisioning de AWS (parte 17).
Bluetooth LE, con una app propia.
Por puerto serie, para técnicos.

La configuración se guarda en la memoria NVS y sobrevive a los reinicios (parte 6).

3. Por OTA: para dispositivos ya instalados

OTA (over the air) es actualizar el firmware por la red, sin tocar el dispositivo. Es imprescindible en cuanto tienes dispositivos fuera de tu escritorio.

Cómo funciona por dentro

El esquema de particiones habitual del ESP32 tiene dos espacios para la aplicación (ota_0 y ota_1). El dispositivo ejecuta desde uno y escribe la versión nueva en el otro. Solo cuando la descarga termina y se verifica, marca la nueva como la que debe arrancar.

Si algo falla durante la descarga, el dispositivo sigue arrancando la versión anterior. Y con el rollback activo, si la versión nueva arranca pero no se marca como válida, el cargador vuelve a la anterior en el siguiente reinicio.

Con Arduino

El núcleo de Arduino para ESP32 incluye lo necesario:

ArduinoOTA: para cargar desde el IDE por la red local, durante el desarrollo.
HTTPUpdate: el dispositivo descarga un binario de una URL HTTPS y se actualiza.

#include <WiFiClientSecure.h>
#include <HTTPUpdate.h>

void actualizar(const char* url) {
  WiFiClientSecure cliente;
  cliente.setCACert(CA_DEL_SERVIDOR);  // verifica el servidor de descarga
  t_httpUpdate_return r = httpUpdate.update(cliente, url);
  if (r == HTTP_UPDATE_FAILED) {
    Serial.printf("Falló la actualización: %s\n", httpUpdate.getLastErrorString().c_str());
  }
  // Si sale bien, el ESP32 se reinicia solo con la versión nueva
}

Lo que hay que prever en una flota

No actualices todo de golpe. Prueba primero en tus propios dispositivos, después en unos pocos (canary) y luego en el resto.
Reparte las descargas en el tiempo, con un retraso aleatorio por dispositivo, para no saturar el servidor.
Confirma que la versión nueva funciona (por ejemplo, que vuelve a conectarse a la nube) antes de marcarla como válida.
Verifica el origen: HTTPS con un certificado de confianza y, mejor aún, firmware firmado.

Con AWS IoT, una forma de coordinarlo es publicar la versión deseada en el Device Shadow de cada dispositivo, o usar AWS IoT Jobs, que gestiona despliegues por grupos con límites de velocidad y criterios de cancelación. Los nodos que no tienen Wi-Fi (por ejemplo, los que solo usan ESP-NOW) necesitan otra vía: que la pasarela les reenvíe el firmware, o actualizarlos por USB.

Cuál usar en cada momento

Momento	Forma
Desarrollando	USB desde el IDE
Instalando un dispositivo nuevo o reinstalando uno	Navegador, con borrado completo
Dispositivo ya instalado en casa de alguien	OTA
Un dispositivo que no arranca	USB o navegador, borrando la flash

Preguntas frecuentes

¿Puedo romper un ESP32 con una actualización fallida?

Con OTA bien hecha, no: la versión anterior sigue en su partición. Lo que sí puede pasar es que la versión nueva arranque pero no funcione (por ejemplo, que no se conecte); para eso está el rollback. Por USB siempre puedes reinstalar.

¿Cómo reseteo un ESP32 a fábrica?

Borrando la flash completa: con esptool.py erase_flash o con una instalación nueva desde ESP Web Tools. Así desaparece también la configuración guardada en NVS.

¿La OTA funciona con ESP-NOW?

No de forma estándar: la OTA descarga por TCP/IP. Para actualizar dispositivos que solo hablan ESP-NOW, la pasarela tendría que retransmitir el binario en trozos, algo posible pero bastante más complejo.

Todos los artículos sobre aprovisionamiento, flasheo y OTA

Seguridad IoT de extremo a extremo: del ESP32 a la nube, capa por capa

Steven Carvajal — Mon, 19 Oct 2026 10:31:59 +0000

Publicado originalmente en iot.gripe.

La seguridad de un sistema IoT es tan fuerte como su capa más débil. Puedes tener la nube perfectamente configurada y que un certificado copiado en un repositorio público lo eche todo abajo; o un firmware impecable y un rol con "Resource": "*" que deja la puerta abierta a cualquiera.

Esta guía recorre las cinco capas de un sistema IoT, del chip a las personas que lo usan, con lo mínimo que conviene hacer en cada una. Los ejemplos usan las piezas de la serie de domótica de este blog: ESP32, ESP-NOW y AWS.

Las cinco capas

El dispositivo: el ESP32, su firmware y lo que guarda en memoria.
La red local: cómo se comunican los dispositivos entre sí y con el router.
La conexión con la nube: cómo se autentica cada dispositivo y qué puede hacer.
La nube y las APIs: los permisos de cada servicio y el aislamiento entre usuarios.
Los usuarios y la operación: el login, los permisos de cada persona y el día a día.

Capa 1: el dispositivo

Una identidad por dispositivo. Cada ESP32 con su propio certificado X.509. Si uno se compromete, lo revocas sin afectar a los demás.
Nada de credenciales en el código. Ni la contraseña del Wi-Fi ni la llave privada deben estar en el firmware ni en el repositorio. Con Fleet Provisioning, cada dispositivo obtiene su certificado después de instalar el firmware (parte 17).
Protege lo que guardas. Por defecto, la memoria NVS del ESP32 no está cifrada: con acceso físico se puede leer. Para un producto, activa el cifrado de la flash y el arranque seguro (secure boot), que solo permite ejecutar firmware firmado por ti.
Actualizaciones firmadas. Si actualizas el firmware a distancia, verifica la firma o al menos usa HTTPS con un certificado de confianza, y conserva la posibilidad de volver a la versión anterior si la nueva falla.
La mejor opción para la llave: que el dispositivo genere su propio par de llaves y solo envíe una solicitud de firma (CSR). Así la llave privada nunca sale del chip.

Capa 2: la red local

Separa los dispositivos IoT en su propia red o VLAN si tu router lo permite. Si uno se compromete, no ve tus computadores.
Valida el origen de cada mensaje local. Una pasarela solo debería aceptar mensajes ESP-NOW de nodos conocidos, comprobando su MAC (parte 4). Y un dispositivo nuevo no debería aceptarse solo: que una persona lo confirme.
Cifra si lo que viaja es sensible. ESP-NOW admite cifrado con clave compartida. Para órdenes simples el riesgo es bajo; con datos personales, cifra.
Los portales de configuración, solo mientras hacen falta. La red Wi-Fi abierta que levanta un dispositivo para configurarse debe desaparecer en cuanto se configura.

Capa 3: la conexión con la nube

TLS siempre, verificando el certificado del servidor (en un ESP32, con la CA raíz cargada; nunca desactives la verificación "para que funcione").
Políticas de mínimo privilegio por dispositivo. Que solo pueda conectarse con su propio nombre y usar los tópicos de su propio Shadow. Un comodín convierte un certificado robado en acceso a toda la cuenta.
Una política para toda la flota, con variables. ${iot:Connection.Thing.ThingName} limita cada dispositivo a lo suyo sin escribir una política por dispositivo (parte 13).
Define las políticas como código, no a mano en la consola. Un permiso agregado a mano para probar no existe para el siguiente dispositivo, y nadie recuerda que está ahí (parte 12).

Capa 4: la nube y las APIs

Nunca confíes en lo que envía el cliente para decidir sobre qué dispositivo o datos actúa. Sácalo de un token verificado o de un registro en tu base de datos.
Aislamiento entre usuarios en IAM, no solo en el código. Si los usuarios acceden directamente a servicios de AWS, condiciones como dynamodb:LeadingKeys limitan a cada uno a sus propios datos. Si pasan por una API, la API decide con el token verificado.
Un rol por función, con lo justo. Si una Lambda solo lee un índice y actualiza un Shadow, su rol no debe poder hacer nada más.
APIs públicas que validan por dentro. Una Lambda Function URL sin autenticación de IAM es pública: toda la validación (token, firma) ocurre en el código.
Guarda hashes, no secretos. Tokens propios y códigos de un solo uso se guardan como hash y se muestran una sola vez (parte 8).

Capa 5: los usuarios y la operación

Registro solo por invitación si es un sistema privado: en Cognito, AllowAdminCreateUserOnly.
Contraseña propia desde el primer login: la temporal solo sirve para entrar la primera vez (parte 11).
Permisos aplicados en el servidor. Ocultar un botón en la app no es control de acceso.
Revocación rápida: al quitar a alguien, cerrar sus sesiones, borrar sus credenciales (como sus tokens) y quitarle los permisos. Un JWT ya emitido no se puede revocar, así que acórtale la vida útil.
Audita lo que existe, no lo que documentaste. En proyectos que nacieron como prototipo es común encontrar funciones públicas olvidadas y roles con comodines (parte 21).

Lista de comprobación

Capa	Comprobación
Dispositivo	Certificado propio por dispositivo, sin credenciales en el código ni en el repositorio
Dispositivo	Cifrado de flash y arranque seguro en producción
Red local	Mensajes validados por origen; dispositivos nuevos confirmados por una persona
Conexión	TLS con verificación; políticas sin comodines, generadas por código
Nube	Aislamiento por usuario aplicado por IAM o por la API; un rol mínimo por función
APIs	Validación dentro de cada endpoint público; secretos guardados como hash
Usuarios	Registro por invitación, permisos en el servidor, revocación inmediata
Operación	Auditoría periódica de roles, políticas y endpoints públicos

Preguntas frecuentes

¿Por dónde empiezo si mi proyecto ya existe?

Por buscar comodines: "Resource": "*", thing/*, identidades no autenticadas con permisos. Después, por cada endpoint público, comprueba qué valida. Son los dos agujeros más comunes en proyectos que nacieron como prototipo.

¿Cifrar ESP-NOW es obligatorio?

Depende de lo que envíes. Para órdenes simples entre dispositivos que se validan por MAC, el riesgo es bajo. Para cualquier dato personal o de seguridad, cifra.

¿Qué herramientas de AWS ayudan?

IAM Access Analyzer detecta recursos accesibles desde fuera de la cuenta; AWS IoT Device Defender audita la configuración de IoT Core; aws iam simulate-principal-policy prueba permisos concretos antes de desplegarlos.

Todos los artículos sobre seguridad, identidad y usuarios

Cuánto cuesta desplegar una API Spring Boot en AWS: 4 opciones comparadas

Steven Carvajal — Mon, 19 Oct 2026 10:31:54 +0000

Publicado originalmente en iot.gripe.

Tienes una API REST con Spring Boot que funciona en tu máquina y quieres subirla a AWS. Hay muchas formas de hacerlo, y la factura cambia bastante según cuál elijas: desde un par de dólares al mes hasta más de 60 USD para la misma API.

En esta guía comparo las cuatro opciones más comunes para una API Java (EC2, Elastic Beanstalk, ECS con Fargate y Lambda). Para cada una verás qué cobra AWS, un cálculo de ejemplo y cuándo conviene.

Antes de empezar: los precios de AWS cambian y dependen de la región. Las cifras son aproximadas para us-east-1 (Norte de Virginia) al momento de escribir, con 730 horas por mes. Antes de decidir, comprueba tu caso en la AWS Pricing Calculator. Si preparas el AWS Cloud Practitioner, este cálculo es buen ejercicio para la parte de facturación: lo explico en la guía para aprobarlo.

El escenario de ejemplo

Para que la comparación sea justa, todas las opciones despliegan la misma API:

Spring Boot 3 con Java 21, empaquetada como un .jar.
Tráfico bajo o moderado: hasta 1 millón de peticiones al mes, con una respuesta media de 200 ms.
Un solo entorno (producción), sin contar la base de datos. La base de datos va aparte, más abajo.

Spring Boot necesita memoria: una API típica usa entre 300 y 600 MB de RAM. Por eso no conviene una instancia con 512 MB: con 1 GB funciona justa, y lo cómodo es 2 GB.

Opción 1: EC2

Una máquina virtual donde instalas Java y ejecutas el .jar (con systemd o en un contenedor Docker).

Concepto	Precio	Al mes
Instancia `t4g.small` (2 vCPU ARM, 2 GB)	~0,0168 USD/hora	~12,30 USD
Disco EBS gp3 de 20 GB	~0,08 USD por GB	~1,60 USD
IPv4 pública	~0,005 USD/hora	~3,65 USD
Total		~17,50 USD

Las instancias t4g usan procesadores Graviton (ARM) y cuestan alrededor de un 20 % menos que sus equivalentes x86 (t3). Java corre igual en ARM: solo necesitas un JDK para ARM, como las imágenes de Eclipse Temurin, que son multiarquitectura.

A favor: es lo más barato con una máquina siempre encendida, y tienes control total.
En contra: tú actualizas el sistema operativo, configuras HTTPS, reinicias si se cae y escalas a mano.

Opción 2: Elastic Beanstalk

Subes el .jar y Beanstalk crea la infraestructura: instancias EC2, el entorno de Java, los logs y, si lo pides, el balanceador y el escalado automático. Beanstalk no cobra nada por sí mismo: pagas los recursos que crea.

Tipo de entorno	Qué crea	Al mes
Instancia única	1 EC2 `t4g.small` + disco + IP pública	~17,50 USD
Con balanceador	2 EC2 + Application Load Balancer + IPs públicas	~55–60 USD

El balanceador de aplicaciones (ALB) cuesta unos 16,50 USD al mes solo por existir, más su uso (LCU) y sus IPs públicas. Es el salto de precio más grande de esta comparación.

A favor: despliegas con eb deploy o desde el pipeline, sin pensar en la infraestructura. Las actualizaciones de la plataforma son administradas.
En contra: personalizar fuera de lo previsto (redes, proxies, agentes) se vuelve incómodo.

Opción 3: ECS con Fargate

Empaquetas la API en una imagen de Docker y ECS la ejecuta en Fargate, sin servidores que administrar. Pagas por la CPU y la memoria que reservas mientras el contenedor está encendido.

Una imagen mínima para Spring Boot:

FROM eclipse-temurin:21-jre
WORKDIR /app
COPY target/api.jar api.jar
# La JVM usa como máximo el 75 % de la memoria del contenedor
ENV JAVA_TOOL_OPTIONS="-XX:MaxRAMPercentage=75"
EXPOSE 8080
ENTRYPOINT ["java", "-jar", "api.jar"]

Concepto	Precio (ARM)	Al mes
Tarea con 0,5 vCPU y 1 GB	~0,0198 USD/hora	~14,40 USD
Application Load Balancer (más uso y sus IPs)		~25 USD
IPv4 pública de la tarea		~3,65 USD
Total con 1 tarea		~40–45 USD
Total con 2 tareas (alta disponibilidad)		~55–65 USD

En x86 la tarea cuesta unos 18 USD al mes, un 20 % más. Sin balanceador, con una IP pública en la tarea, el total baja a unos 18 USD. Esa variante sirve para pruebas, pero la IP cambia en cada despliegue.

A favor: despliegues reproducibles con imágenes, escalado automático y nada de sistemas operativos que parchear. Es el estándar para microservicios.
En contra: hay más piezas que entender (clúster, servicio, tarea, ECR) y el balanceador encarece los proyectos pequeños.

Opción 4: Lambda con API Gateway

La API se ejecuta solo cuando llega una petición. Con Spring Boot se usa la librería aws-serverless-java-container, que adapta las peticiones de API Gateway a tus controladores sin reescribirlos.

Concepto	Precio	Al mes (1 millón de peticiones)
Peticiones de Lambda	0,20 USD por millón	0,20 USD
Cómputo (1 GB × 200 ms)	~0,0000167 USD por GB-segundo	~3,33 USD
API Gateway (HTTP API)	~1 USD por millón	~1 USD
Total		~4,50 USD

La capa gratuita permanente de Lambda incluye 1 millón de peticiones y 400 000 GB-segundos al mes. En este escenario, eso deja el total en alrededor de 1 USD, lo que cobra API Gateway.

El problema clásico de Java en Lambda es el arranque en frío: levantar Spring tarda varios segundos. Hay dos formas de mitigarlo:

Lambda SnapStart: guarda una instantánea de la función ya inicializada y la restaura en milisegundos. Para Java no tiene costo adicional.
Compilar a imagen nativa con GraalVM (Spring Boot 3 lo soporta): arranca mucho más rápido y usa menos memoria, a cambio de una compilación más lenta.

A favor: costo casi cero con poco tráfico y escala sola.
En contra: el arranque en frío, el límite de 15 minutos por ejecución y que no encaja con conexiones largas (WebSockets) ni con pools de conexiones grandes a la base de datos.

La comparación

Opción	Al mes (aprox.)	Administración	Escala sola	Ideal para
EC2 `t4g.small`	~17,50 USD	Alta	No	Aprender, proyectos personales, control total
Beanstalk, instancia única	~17,50 USD	Baja	No	MVP sin tiempo para infraestructura
Beanstalk con balanceador	~55–60 USD	Baja	Sí	Apps tradicionales en producción
Fargate + balanceador	~40–65 USD	Media	Sí	Microservicios y equipos que ya usan Docker
Lambda + API Gateway	~1–5 USD	Muy baja	Sí	Tráfico bajo o con picos, APIs pequeñas

Calcula tu caso

Pon tu tráfico, el tamaño de la instancia o de la tarea y si usas balanceador o NAT Gateway: la calculadora compara las cuatro opciones con tus números. También está como página aparte en la calculadora de costos de AWS.

Los costos que nadie mira hasta que llega la factura

IPs públicas IPv4. Desde 2024 AWS cobra cada IPv4 pública, unos 3,65 USD al mes por IP. Se cobran también las del balanceador y las de las tareas.
NAT Gateway. Si pones las instancias o tareas en subredes privadas, necesitan un NAT Gateway para salir a internet. Cuesta unos 33 USD al mes más el tráfico. Es la sorpresa más común en proyectos pequeños. Alternativas: subredes públicas con grupos de seguridad estrictos o VPC endpoints para los servicios de AWS.
CloudWatch Logs. Unos 0,50 USD por GB ingerido. Un log en nivel DEBUG en producción lo multiplica.
Transferencia de datos. Los primeros 100 GB de salida a internet al mes son gratis; después, unos 0,09 USD por GB.
La base de datos. Suele costar más que la propia API (ver la siguiente sección).

Y la base de datos

Casi toda API Spring Boot necesita una. Las opciones más comunes:

Opción	Al mes (aprox.)	Notas
RDS PostgreSQL `db.t4g.micro` + 20 GB	~14 USD	Copias de seguridad y parches administrados
PostgreSQL en la misma EC2	0 USD extra	Barato, pero tú haces las copias de seguridad y lo mantienes
DynamoDB bajo demanda	Céntimos con poco tráfico	Exige modelar los datos de otra forma (NoSQL)
MongoDB Atlas (nivel gratuito)	0 USD	Útil para probar; el nivel de producción se paga aparte

Para producción, una base de datos administrada (RDS) vale lo que cuesta: las copias de seguridad automáticas y la restauración a un punto en el tiempo te salvan el día que algo sale mal.

Cuál elegir

Estás aprendiendo o es un proyecto personal: EC2 t4g.small, o Lambda si el tráfico es esporádico. Aprenderás más con EC2.
Es un MVP y quieres desplegar ya: Elastic Beanstalk con instancia única. Cuando crezca, cambias a un entorno con balanceador sin tocar el código.
Son varios microservicios o tu equipo ya usa Docker: ECS con Fargate. Un solo balanceador puede repartir el tráfico entre varios servicios por ruta, así que su costo se reparte.
Tráfico bajo, irregular o con picos: Lambda con SnapStart.

Cómo no llevarte sorpresas

Crea una alerta en AWS Budgets el primer día, por ejemplo a los 10 USD. Es gratis y te avisa por correo.
Estima antes de desplegar con la AWS Pricing Calculator, con tus números de tráfico.
Etiqueta los recursos (proyecto=mi-api) para ver en Cost Explorer cuánto cuesta cada proyecto.
Apaga lo que no uses: un entorno de pruebas encendido todo el mes cuesta lo mismo que el de producción.

Preguntas frecuentes

¿Puedo tener todo esto gratis con la capa gratuita?

En parte. La capa gratuita permanente cubre Lambda en el escenario de ejemplo. Para EC2, RDS y otros servicios, las condiciones dependen de cuándo creaste la cuenta: las cuentas nuevas reciben créditos durante los primeros meses en lugar de horas gratuitas. Revisa las condiciones vigentes en la página de la capa gratuita de AWS.

¿Me sale más barato un VPS fuera de AWS?

Para una sola API pequeña, muchas veces sí: un VPS de otro proveedor puede costar menos que una EC2 con su IP. AWS compensa cuando necesitas sus servicios administrados (bases de datos, colas, autenticación), escalado automático o cumplir requisitos de tu empresa.

¿Y App Runner o EKS?

EKS (Kubernetes) cobra unos 73 USD al mes solo por el plano de control, antes de cualquier nodo. No tiene sentido para una API sola. App Runner simplifica el despliegue de contenedores, pero revisa su disponibilidad y precio actuales antes de elegirlo para un proyecto nuevo.

¿Graviton es compatible con mi API?

Casi siempre. Java es multiplataforma: el mismo .jar corre en ARM. Solo revisa las dependencias con código nativo (algunos drivers o librerías de compresión) y usa una imagen base de Docker que tenga versión para ARM.

AWS IoT Core: qué es, cómo funciona y cuándo usarlo en tu proyecto

Steven Carvajal — Sun, 18 Oct 2026 09:22:26 +0000

Publicado originalmente en iot.gripe.

AWS IoT Core es el servicio de Amazon Web Services para conectar dispositivos a la nube. En la práctica es un broker MQTT administrado con todo lo que un proyecto serio necesita alrededor: identidad por dispositivo, permisos finos, estado guardado aunque el dispositivo esté apagado y reglas para enviar los datos a otros servicios.

En esta guía te explico sus piezas, cómo encajan y qué cuesta, con ejemplos prácticos con ESP32.

Para qué sirve

Imagina que tienes un ESP32 en casa y quieres controlarlo desde el celular, estés donde estés. Necesitas:

un punto en internet al que el ESP32 se conecte y se mantenga conectado;
una forma de que solo tu ESP32 pueda conectarse como tal;
una forma de enviarle órdenes y saber si las cumplió;
que, si estaba apagado, al volver sepa qué se le pidió.

AWS IoT Core resuelve las cuatro sin que mantengas ningún servidor.

Las piezas principales

Pieza	Qué hace
Device gateway y broker de mensajes	Recibe las conexiones de los dispositivos (MQTT, MQTT sobre WebSocket o HTTPS) y reparte los mensajes por tópicos
Things (registro)	La representación de cada dispositivo en la nube
Certificados X.509	La identidad de cada dispositivo: así se autentica, sin usuario ni contraseña
Políticas de IoT	Qué puede hacer cada certificado: conectarse con qué nombre, publicar y suscribirse a qué tópicos
Device Shadow	Un documento JSON por dispositivo con el estado deseado y el estado reportado
Reglas	Consultas tipo SQL sobre los mensajes para enviarlos a Lambda, DynamoDB, S3 y otros servicios
Jobs	Tareas para flotas de dispositivos, como actualizaciones de firmware
Device Defender	Auditoría de configuración y detección de comportamientos anómalos

Cómo se conecta un dispositivo

Un ESP32 se conecta por MQTT sobre TLS (puerto 8883) al endpoint de tu cuenta. En lugar de usuario y contraseña, presenta su certificado X.509 y su llave privada. AWS comprueba el certificado y aplica la política adjunta.

Una buena política solo permite lo mínimo: conectarse con su propio nombre y usar los tópicos de su propio Shadow. Nada de "Resource": "*", que permitiría a quien robe el certificado publicar en cualquier tópico de tu cuenta.

El paso a paso completo, con la política mínima y el código para Arduino, está en la parte 3 de la serie de domótica.

Los navegadores y las apps se conectan de otra forma: por MQTT sobre WebSocket con una URL firmada con SigV4, el esquema de firma de AWS. Las credenciales suelen venir de Cognito, o de una Lambda que firma la URL; lo explico en la parte 10.

El Device Shadow: el estado que sobrevive

El Device Shadow es la pieza que más trabajo ahorra. Es un documento JSON que AWS guarda por cada dispositivo:

{
  "state": {
    "desired":  { "led": "on" },
    "reported": { "led": "off" }
  }
}

desired: lo que la app, un script o un asistente de voz quieren que pase.
reported: lo que el dispositivo confirma que pasó.

Cuando no coinciden, AWS publica un delta en un tópico reservado; el dispositivo lo recibe, actúa y reporta. Si estaba desconectado, al volver pide el documento completo y se pone al día. Con tópicos propios, un mensaje enviado mientras el dispositivo estaba apagado simplemente se perdería.

Los Shadows con nombre permiten separar documentos, por ejemplo el estado de las luces y la configuración (parte 5).

Reglas: llevar los datos a otros servicios

Una regla es una consulta tipo SQL sobre los mensajes que llegan:

SELECT temperatura, humedad, timestamp() AS ts
FROM 'casa/+/sensores'
WHERE temperatura > 30

Y una acción que se ejecuta con cada resultado: invocar una Lambda, guardar en DynamoDB, escribir en S3, enviar a una cola, etc. Sirve para guardar históricos, generar alertas o integrar con otros sistemas sin código en el dispositivo.

Con qué se combina en un proyecto real

AWS IoT Core rara vez va solo. Lo habitual es combinarlo con:

Amazon Cognito para el login de los usuarios (parte 11);
DynamoDB para dispositivos, configuración y lecturas (parte 7);
Lambda para APIs, por ejemplo una de control por voz (parte 8);
Políticas de IoT con variables para que cada dispositivo solo acceda a lo suyo (parte 13).

Cuánto cuesta

AWS IoT Core cobra por uso, en varias dimensiones:

Concepto	Referencia (us-east-1)
Conexión	~0,08 USD por millón de minutos conectados
Mensajes	~1 USD por millón de mensajes, medidos en bloques de 5 KB
Device Shadow y registro	~1,25 USD por millón de operaciones
Reglas	Por regla ejecutada y por acción

Un dispositivo conectado todo el mes son unos 43.200 minutos: menos de medio centavo de dólar. Para un proyecto doméstico el costo es casi nulo; cómo estimarlo para tu proyecto, también para miles de casas, está en la parte 22. Los precios cambian: revisa la página oficial antes de decidir.

Límites que conviene conocer

Device Shadow: 8 KB por documento.
Mensajes MQTT: hasta 128 KB.
Solicitudes al Shadow: existe un límite de solicitudes por segundo por Thing y otro por cuenta, ampliable a petición. Un hogar normal no se acerca.
Conexión por client ID: si dos conexiones usan el mismo client ID, AWS desconecta la anterior.

Alternativas

Un broker propio (Mosquitto, EMQX) en un servidor o un Raspberry Pi: más control y sin costo por mensaje, pero tú gestionas el servidor, la seguridad y la disponibilidad.
Azure IoT Hub: el equivalente de Microsoft.
Home Assistant con MQTT local: ideal si solo quieres domótica en tu casa, sin depender de la nube.

Google retiró su servicio equivalente, Cloud IoT Core, en 2023.

Preguntas frecuentes

¿Necesito AWS IoT Core para controlar un ESP32 por internet?

No es la única forma, pero sí una de las más seguras y sin mantenimiento: identidad por dispositivo, permisos finos y estado guardado sin servidores propios.

¿Qué pasa si el dispositivo pierde la conexión?

El Shadow conserva el estado deseado. Al reconectarse, el dispositivo pide el documento y se pone al día. Conviene que lo pida siempre al conectar, en lugar de depender de recibir un delta.

¿Puedo usar PubSubClient con AWS IoT Core?

Mucha gente lo hace. En mi caso, con un ESP32-S3, las publicaciones se perdían aunque la librería reportara éxito, y la librería MQTT de 256dpi lo resolvió.

¿Por qué AWS cierra la conexión de mi dispositivo?

Casi siempre es la política: el dispositivo se conecta con un client ID no permitido, o publica o se suscribe a un tópico que no tiene autorizado. Suscríbete a $aws/events/presence/# en el cliente de prueba de la consola para ver cuándo y por qué se desconecta (parte 5).

Todos los artículos sobre AWS IoT y serverless

Error "was not declared in this scope" con un struct en Arduino: la causa y 4 soluciones

Steven Carvajal — Sun, 18 Oct 2026 09:21:51 +0000

Publicado originalmente en iot.gripe.

Tienes un struct definido arriba del sketch, una función que lo recibe como parámetro, y el compilador responde con alguno de estos errores:

error: 'Sensor' was not declared in this scope
error: variable or field 'leerSensor' declared void
error: 'Sensor' does not name a type

El tipo está declarado. El problema no es tu código, sino algo que el IDE de Arduino hace con los archivos .ino antes de compilar.

La causa: los prototipos automáticos

En C++, una función tiene que estar declarada antes de usarse. Para que no tengas que escribir esas declaraciones (los prototipos), el IDE de Arduino las genera solo: lee el .ino, encuentra todas tus funciones y escribe sus prototipos en un punto del archivo, justo antes de la primera definición de función que encuentra.

Si una función usa un tipo tuyo y ese tipo se define después de ese punto, el prototipo generado lo usa antes de que exista. De ahí el error.

Este sketch falla:

#include <Arduino.h>

void setup() {        // primera función: aquí se insertan los prototipos
  Serial.begin(115200);
}

struct Sensor {       // el tipo aparece después
  uint8_t pin;
  float valor;
};

void leerSensor(Sensor &s) {   // su prototipo quedó arriba, antes de Sensor
  s.valor = analogRead(s.pin);
}

void loop() {}

El caso difícil: una macro que es una función

Este me costó más encontrarlo. En el núcleo de Arduino para ESP32, SET_LOOP_TASK_STACK_SIZE() (la macro para dar más pila a loop()) se expande a una definición de función. Si la pones antes de un #include que define tus tipos, el IDE la toma como la primera función e inserta ahí todos los prototipos:

#include <WiFi.h>
SET_LOOP_TASK_STACK_SIZE(16 * 1024);   // MAL: se expande a una función
#include "tipos.h"                      // define struct Nodo

void procesar(Nodo &n) { /* ... */ }    // error: 'Nodo' was not declared

Visualmente no hay ninguna función antes del #include, por eso es tan confuso.

Solución 1: los tipos en un archivo `.h`

La más limpia. Crea una pestaña nueva en el IDE llamada tipos.h, mueve ahí tus struct y enum, e inclúyela al principio del sketch:

// tipos.h
#pragma once
#include <Arduino.h>

struct Sensor {
  uint8_t pin;
  float valor;
};

// sketch.ino
#include "tipos.h"

void leerSensor(Sensor &s) {
  s.valor = analogRead(s.pin);
}

Solución 2: todos los tipos antes de la primera función

Si prefieres un solo archivo, define los tipos arriba del todo, antes de setup() y de cualquier otra función.

Solución 3: las macros que son funciones, después de los `#include`

#include <WiFi.h>
#include "tipos.h"
SET_LOOP_TASK_STACK_SIZE(16 * 1024);   // BIEN: después de todos los #include

Solución 4: escribe tú el prototipo

Si declaras el prototipo a mano después del tipo, el IDE no genera el suyo para esa función:

struct Sensor { uint8_t pin; float valor; };
void leerSensor(Sensor &s);   // prototipo propio

Cómo confirmar que es esto

Activa la salida detallada al compilar (Archivo → Preferencias → Mostrar salida detallada durante: compilación). El IDE muestra la ruta del .cpp que genera a partir de tu sketch; ábrelo y verás dónde quedaron los prototipos.

Si el proyecto crece, deja de pelear con esto: pasa la lógica a archivos .cpp y .h normales, donde el IDE no genera nada y C++ funciona como siempre. Es lo que hago en el firmware del ESP32 de la guía del ESP32.

Este error es uno de los 13 errores reales al construir domótica con ESP32 y AWS IoT.

Preguntas frecuentes

¿Pasa también con PlatformIO?

No con archivos .cpp: PlatformIO no genera prototipos y tienes que declararlos tú. Si usas un .ino en PlatformIO, aplica la misma conversión que el IDE de Arduino.

¿Y con `enum` o `typedef`?

Igual. Cualquier tipo propio usado en la firma de una función (parámetros o tipo de retorno) puede provocar el error.

¿Por qué a veces funciona y a veces no?

Depende de dónde quede la primera función. Mover una función de sitio, añadir una macro o reordenar los #include cambia el punto de inserción, y el mismo código pasa de compilar a fallar.

ESP-NOW, Wi-Fi, Bluetooth o MQTT: cómo comunicar tus dispositivos ESP32

Steven Carvajal — Sat, 17 Oct 2026 09:03:12 +0000

Publicado originalmente en iot.gripe.

Una de las primeras decisiones de un proyecto con varios ESP32 es cómo van a hablar entre ellos y con el mundo. Cada uno a internet por Wi-Fi, todos a un servidor por MQTT, entre ellos por ESP-NOW o por Bluetooth con el celular. La elección cambia el costo, el consumo, la fiabilidad y la complejidad de todo lo demás.

En esta guía te explico las opciones, qué es cada una y cuándo conviene, con ejemplos de cómo se combinan en un proyecto de domótica.

Dos preguntas distintas

Antes de comparar, separa dos cosas que suelen mezclarse:

El medio: cómo viajan los bits por el aire. Wi-Fi, ESP-NOW, Bluetooth LE, Thread.
El protocolo de mensajes: cómo se organizan los mensajes encima de ese medio. MQTT, HTTP, WebSocket o un formato propio.

MQTT no compite con ESP-NOW: MQTT funciona encima de una conexión de red (TCP/IP), normalmente por Wi-Fi. ESP-NOW es un medio con su propio formato de paquetes, sin TCP/IP. Por eso se pueden combinar, como verás más abajo.

Wi-Fi: para llegar a internet

El ESP32 se conecta a tu router como cualquier dispositivo. A partir de ahí puede hacer peticiones HTTP, abrir conexiones MQTT o WebSocket y hablar con cualquier servicio en la nube.

A favor: llega a internet; usa protocolos estándar; el alcance es el de tu red.
En contra: cada dispositivo necesita la contraseña de la red y ocupa un lugar en el router; conectar y mantener la conexión consume bastante energía; si usas TLS, cada conexión consume memoria.

ESP-NOW: de ESP32 a ESP32, sin router

ESP-NOW es un protocolo de Espressif para enviar mensajes cortos directamente entre ESP32, usando la radio Wi-Fi pero sin conectarse a ninguna red. Cada dispositivo se identifica por su dirección MAC.

A favor: no necesita router ni contraseña; latencia de milisegundos; consumo bajo porque no hay conexión que mantener; funciona aunque se caiga el Wi-Fi de la casa.
En contra: mensajes pequeños (250 bytes en la versión clásica); no garantiza la entrega, así que tienes que construir la confirmación; solo entre chips de Espressif; todos tienen que estar en el mismo canal de radio; máximo 20 dispositivos emparejados por cada ESP32 (menos si usas cifrado).

El detalle del canal es el que más problemas da: si un ESP32 está conectado al router, su canal es el del router, y los demás tienen que usar el mismo. Lo más simple es fijar el canal del router y usarlo en todos los nodos. Las opciones y el código completo, con confirmaciones, están en la parte 4 de la serie de domótica.

Bluetooth LE: para el celular y los sensores cercanos

Bluetooth Low Energy está pensado para intercambiar datos pequeños con muy bajo consumo a corta distancia.

A favor: habla directamente con el celular, sin apps de red ni router; ideal para configurar un dispositivo o leer sensores con batería.
En contra: alcance corto; para llegar a internet necesitas un intermediario (el celular o una pasarela); programar servicios y características BLE lleva su trabajo.

MQTT: mensajes por tópicos a través de un broker

MQTT es un protocolo de mensajería ligero que funciona sobre TCP/IP. En lugar de hablarse directamente, los dispositivos se conectan a un broker (un servidor intermediario) y:

publican mensajes en un tópico, por ejemplo casa/sala/luz;
se suscriben a los tópicos que les interesan y reciben lo que otros publican.

Tres conceptos que conviene conocer:

QoS (calidad de servicio): 0 envía una vez sin confirmar; 1 garantiza que llega al menos una vez; 2, exactamente una vez.
Mensaje retenido: el broker guarda el último mensaje de un tópico y se lo entrega a quien se suscriba después.
Última voluntad (LWT): un mensaje que el broker publica si el dispositivo se desconecta sin avisar.

Como broker puedes usar uno propio (por ejemplo, Mosquitto en un Raspberry Pi) o uno administrado en la nube. Un ejemplo administrado es AWS IoT Core, que además guarda el estado de cada dispositivo en un documento llamado Device Shadow. Lo explico en la parte 3 y en la guía de AWS IoT Core de este blog.

Comparación rápida

	Wi-Fi + HTTP/MQTT	ESP-NOW	Bluetooth LE	MQTT
Qué es	Medio + protocolos de internet	Medio con protocolo propio	Medio + protocolo	Protocolo de mensajes
¿Necesita router?	Sí	No	No	Necesita red y un broker
¿Llega a internet?	Sí	No	Solo con intermediario	Si el broker está en internet
Latencia	Decenas de ms	Pocos ms	Decenas de ms	Depende de la red y del broker
Tamaño de mensaje	Grande	Pequeño	Pequeño	Grande
Consumo	Alto	Bajo	Muy bajo	El de la red debajo
Entrega garantizada	Con TCP	No: hay que construirla	Según el modo	Con QoS 1 o 2

Un patrón muy usado: la pasarela

En una casa con muchas luces, conectar cada ESP32 al Wi-Fi y a la nube es caro y frágil: cada uno necesita su certificado, su conexión TLS permanente y su lugar en el router. La alternativa es una pasarela (gateway):

Un solo ESP32 (por ejemplo, un ESP32-S3) se conecta al Wi-Fi y a la nube por MQTT sobre TLS.
El resto (ESP32-C3) hablan con él por ESP-NOW, sin Wi-Fi ni certificados.
La pasarela traduce: recibe el estado deseado por MQTT y reparte órdenes cortas por ESP-NOW; recoge las confirmaciones y las publica.

Las ventajas son grandes: una sola conexión con la nube por casa, un solo certificado, costo en la nube que no crece con cada luz y nodos que siguen funcionando entre ellos si se cae internet. Las dos arquitecturas están comparadas en la parte 1 de la serie.

Cómo elegir

Un solo dispositivo que habla con la nube: Wi-Fi + MQTT (o HTTP si solo envía datos de vez en cuando).
Muchos dispositivos en un mismo lugar: pasarela con Wi-Fi + MQTT, y ESP-NOW para el resto.
Dispositivos con batería que envían poco: ESP-NOW o BLE hacia una pasarela; evita mantener Wi-Fi activo.
Configuración desde el celular: BLE, o un punto de acceso Wi-Fi temporal con un formulario web (lo explico en la parte 16).
Compatibilidad con ecosistemas de domótica: Thread y Matter, con un ESP32-C6 o H2.

Preguntas frecuentes

¿Puedo usar ESP-NOW y Wi-Fi al mismo tiempo?

Sí, en el mismo ESP32, siempre que los demás dispositivos de ESP-NOW estén en el canal del router. Es lo que hace una pasarela típica.

¿MQTT o HTTP?

MQTT si el dispositivo tiene que recibir órdenes en tiempo real o envía datos con frecuencia: la conexión queda abierta y los mensajes son ligeros. HTTP si solo envía algo de vez en cuando y no necesita escuchar.

¿ESP-NOW es seguro?

Admite cifrado con una clave compartida entre los dispositivos emparejados. Sin cifrado, cualquiera cerca podría escuchar los mensajes, así que valida siempre de quién viene cada mensaje (por su MAC) y no envíes datos sensibles sin cifrar.

¿Qué alcance tiene ESP-NOW?

El mismo orden que el Wi-Fi de las placas, porque usa la misma radio: varias habitaciones en una casa normal. Las paredes gruesas, la antena de cada placa y las interferencias lo reducen.

Todos los artículos sobre ESP-NOW y MQTT

Cómo aprobar el AWS Cloud Practitioner (CLF-C02): plan de estudio y recursos

Steven Carvajal — Sat, 17 Oct 2026 09:02:36 +0000

Publicado originalmente en iot.gripe.

La AWS Certified Cloud Practitioner es la puerta de entrada a las certificaciones de AWS. No exige experiencia previa en la nube y es la que más se recomienda para empezar, tanto si eres desarrollador como si trabajas en ventas, gestión o soporte.

Yo la aprobé en 2025, trabajando como desarrollador backend con Java y Spring Boot. Esta guía resume cómo es el examen, qué estudiar, un plan de cuatro semanas y los errores que más cuestan puntos.

Antes de empezar: AWS actualiza sus exámenes y sus precios. Los datos de esta guía corresponden a la versión CLF-C02. Antes de reservar, revisa la guía oficial del examen en la página de la certificación.

Cómo es el examen

	CLF-C02
Preguntas	65: 50 puntúan y 15 son de prueba (no sabes cuáles)
Tipo	Opción múltiple (una correcta) y respuesta múltiple (dos o más correctas)
Duración	90 minutos
Puntaje para aprobar	700 sobre 1000 (escala)
Costo	100 USD más impuestos
Dónde	Centro de examen de Pearson VUE o en línea desde casa
Idiomas	Inglés, español y otros
Vigencia	3 años

Dos detalles que cambian la estrategia:

Las respuestas incorrectas no restan. Nunca dejes una pregunta en blanco.
El puntaje es compensatorio. No necesitas aprobar cada dominio por separado: cuenta el total.

Los cuatro dominios y su peso

Dominio	Peso	Qué preguntan
1. Conceptos de la nube	24 %	Beneficios de la nube, Well-Architected Framework, estrategias de migración, economía de la nube
2. Seguridad y cumplimiento	30 %	Modelo de responsabilidad compartida, IAM, servicios de seguridad, cumplimiento
3. Tecnología y servicios	34 %	Formas de desplegar, infraestructura global, cómputo, bases de datos, redes, almacenamiento, IA y análisis
4. Facturación, precios y soporte	12 %	Modelos de precio, herramientas de costos, planes de soporte

Seguridad y servicios suman casi dos tercios del examen. Si tienes poco tiempo, empieza por ahí.

Qué estudiar en cada dominio

1. Conceptos de la nube

Ventajas de la nube: cambiar gasto de capital por gasto variable, economías de escala, dejar de adivinar la capacidad, velocidad y alcance global.
AWS Well-Architected Framework: sus seis pilares. Son excelencia operativa, seguridad, fiabilidad, eficiencia del rendimiento, optimización de costos y sostenibilidad.
AWS Cloud Adoption Framework (CAF): sus seis perspectivas. Son negocio, personas, gobernanza, plataforma, seguridad y operaciones.
Estrategias de migración (las 7 R): rehost, replatform, refactor, repurchase, retire, retain y relocate.

2. Seguridad y cumplimiento

Modelo de responsabilidad compartida. Es la pregunta más segura del examen. AWS es responsable de la seguridad de la nube: hardware, centros de datos y la red global. Tú eres responsable de la seguridad en la nube: tus datos, IAM, el sistema operativo de tus EC2 y la configuración de red. En los servicios administrados (RDS, Lambda) AWS asume más partes.
IAM: usuarios, grupos, roles y políticas; el principio de mínimo privilegio; MFA; no usar la cuenta raíz para el día a día.
Servicios de seguridad: qué hace cada uno (ver la tabla de confusiones más abajo).
AWS Artifact: dónde se descargan los informes de cumplimiento de AWS (ISO, SOC, PCI).

3. Tecnología y servicios

Infraestructura global: Regiones, Zonas de Disponibilidad y ubicaciones de borde (CloudFront).
Cómputo: EC2 y sus familias, Auto Scaling, Elastic Load Balancing, Lambda, ECS/EKS, Fargate, Elastic Beanstalk.
Almacenamiento: S3 y sus clases (Standard, Intelligent-Tiering, Standard-IA, Glacier), EBS, EFS, la familia Snow.
Bases de datos: RDS, Aurora, DynamoDB, ElastiCache, Redshift.
Redes: VPC, subredes, grupos de seguridad, Route 53, CloudFront, Direct Connect, VPN.
Formas de desplegar: consola, CLI, SDK, CloudFormation (infraestructura como código).

No hace falta saber configurar cada servicio. Basta con saber para qué sirve y cuándo elegirlo.

4. Facturación, precios y soporte

Modelos de compra de EC2: On-Demand, Savings Plans, instancias reservadas, instancias de spot y hosts dedicados.
Herramientas: AWS Pricing Calculator, Cost Explorer, Budgets, Cost and Usage Report y la facturación consolidada de AWS Organizations.
Planes de soporte: Basic, Developer, Business, Enterprise On-Ramp y Enterprise. Aprende qué incluye cada uno: tiempos de respuesta, acceso completo a Trusted Advisor y el gestor técnico de cuenta (TAM).

Plan de estudio de 4 semanas

Con una hora al día, cuatro semanas son suficientes para alguien sin experiencia en AWS. Si ya trabajas con AWS, dos semanas bastan: salta directo a los exámenes de práctica.

Semana	Qué hacer
1	Curso gratuito AWS Cloud Practitioner Essentials (AWS Skill Builder). Leer la guía oficial del examen completa.
2	Seguridad y servicios: responsabilidad compartida, IAM y los servicios de cómputo, almacenamiento, bases de datos y redes. Crear una cuenta y probar la consola: un bucket de S3, un usuario de IAM con MFA y una alerta de presupuesto.
3	Facturación y soporte. Primer examen de práctica completo, cronometrado. Repasar cada pregunta fallada y también las acertadas por intuición.
4	Dos o tres exámenes de práctica más. Repasar las confusiones típicas. Reservar el examen cuando aciertes de forma estable por encima del 80 %.

La clave es el repaso, no el número de exámenes. De cada pregunta fallada anota por qué la respuesta correcta es correcta y por qué cada distractor no lo es. Esa lista es tu material de la última semana.

Recursos

Gratuitos y oficiales:

Guía del examen (página de la certificación): la lista exacta de temas y servicios que entran.
AWS Cloud Practitioner Essentials en AWS Skill Builder: el curso base, con español disponible.
Official Practice Question Set en Skill Builder: 20 preguntas con el estilo real del examen.
Whitepapers: Overview of Amazon Web Services y el resumen del Well-Architected Framework.
Una cuenta de AWS para practicar. Configura una alerta en AWS Budgets el primer día; lo explico en cuánto cuesta desplegar una API en AWS.

De pago:

Exámenes de práctica completos (Udemy, Tutorials Dojo y otros). Son lo que más ayuda en la recta final, porque los gratuitos se acaban rápido.
Cursos en video en Udemy o Platzi, si prefieres una explicación guiada a leer documentación.

Los servicios que más se confunden

Muchas preguntas ponen dos servicios parecidos como opciones. Estos son los pares que más puntos cuestan:

Si la pregunta habla de...	Es...	No confundir con...
Quién hizo qué llamada a la API	CloudTrail	CloudWatch (métricas, logs y alarmas)
Historial de configuración de recursos y reglas de cumplimiento	AWS Config	CloudTrail
Recomendaciones de costos, seguridad y límites de tu cuenta	Trusted Advisor	Inspector (vulnerabilidades en EC2, contenedores y Lambda)
Detección de amenazas analizando logs	GuardDuty	Inspector
Protección contra DDoS	Shield	WAF (filtra peticiones HTTP: inyección SQL, XSS, IPs)
Datos sensibles (PII) en S3	Macie	GuardDuty
Firewall a nivel de instancia, con estado	Grupo de seguridad	Network ACL (a nivel de subred, sin estado)
Estimar el costo de algo que aún no existe	Pricing Calculator	Cost Explorer (analiza lo que ya gastaste)
Avisar cuando el gasto pase un umbral	Budgets	Cost Explorer
Ahorro en EC2 con cargas que pueden interrumpirse	Spot	Savings Plans (compromiso de 1 o 3 años)
Una factura para varias cuentas	Organizations (facturación consolidada)	Control Tower (configura un entorno multicuenta gobernado)
Informes de cumplimiento de AWS	Artifact	Config

El día del examen

En línea desde casa: necesitas una habitación cerrada, el escritorio despejado, cámara y un documento de identidad vigente. Haz el system test de Pearson VUE días antes y conéctate 30 minutos antes de la hora.
Si lo presentas en inglés y no es tu idioma nativo, puedes pedir la adaptación ESL +30: 30 minutos extra. Se solicita en tu cuenta de certificación antes de reservar.
Marca para revisar las preguntas dudosas y sigue adelante: con 90 minutos para 65 preguntas sobra tiempo para volver.
Descarta primero. En casi todas las preguntas hay dos opciones claramente incorrectas.
Fíjate en las palabras clave: "más rentable", "menos esfuerzo operativo", "administrado", "alta disponibilidad". Suelen decidir entre las dos opciones que quedan.

Después de aprobar

Recibes una insignia digital que puedes poner en LinkedIn y en tu CV.
AWS te da un cupón del 50 % para tu siguiente examen.
El siguiente paso habitual es Solutions Architect Associate (arquitectura) o Developer Associate (si programas aplicaciones). Para un desarrollador backend que despliega APIs, cualquiera de las dos es una buena continuación.

Preguntas frecuentes

¿Vale la pena si ya soy desarrollador?

Sí, aunque sea fácil para ti. Te da el vocabulario común de AWS, te obliga a entender la facturación (lo que más sorprende al pasar a la nube) y es una señal clara en un CV. Además, el cupón del 50 % abarata la Associate.

¿Necesito saber programar?

No. El examen no tiene código. Pregunta para qué sirve cada servicio, cómo se cobra y quién es responsable de qué.

¿Lo presento en español o en inglés?

En el idioma en que estudiaste. Si estudiaste con material en inglés, preséntalo en inglés y pide la adaptación ESL +30: los nombres de los servicios no cambian, y te ahorras traducir mentalmente.

¿Cuánto tiempo dura la certificación?

Tres años. Para renovarla puedes volver a presentarla o aprobar una certificación de nivel superior: según la política actual de AWS, una Associate renueva automáticamente la Cloud Practitioner.

¿Qué pasa si no apruebo?

Puedes volver a presentarla pasados 14 días, pagando de nuevo. El informe de resultados muestra tu desempeño por dominio: úsalo para saber qué repasar.