DEV Community: Carolina Herrera

I run infrastructure for the airline industry. Then I deployed a Flappy Bird clone with the same rigor.

Carolina Herrera — Tue, 18 Aug 2026 11:51:21 +0000

At work, downtime is not a ticket. It is a flight that does not take off. I have been leading DevOps teams in the airline industry since 2022, and that context shapes how I think about every deployment I touch.

So one weekend I built a game based on one I liked so much: Flappy Bird, but this game is Flappy Docker where a Docker whale dodges containers instead of pipes, and then I did the thing that probably sounds ridiculous: I deployed it to ECS with Terraform, a real domain, HTTPS and autoscaling.

It is a game nobody asked for. It is also the cheapest place I know to practice the whole path, image to registry to orchestrator to DNS, on something where breaking it costs me nothing.

Play it: https://flappy-docker.carolinaherreramonteza.com

Code: https://github.com/carotechie/game-flappy-docker

The game

I kept the game deliberately boring. Vanilla HTML5 Canvas and JavaScript, no framework, no build step, because the game was never the interesting part.

index.html and style.css for layout and styling
game.js for the game loop, collision detection, scoring and the difficulty ramp (speed goes up every 5 points)
Best score saved in localStorage
Controls: click, spacebar, arrow up, Enter, or tap on mobile

The whole thing ships in a four-line Dockerfile. nginx:alpine serving static files, nothing else.

FROM nginx:alpine
COPY . /usr/share/nginx/html
EXPOSE 80
CMD ["nginx", "-g", "daemon off;"]

Locally that is three commands and you are playing.

docker build -t flappy-docker .
docker run -d -p 8080:80 --name flappy-docker flappy-docker
open http://localhost:8080

No npm install, no runtime version to match, no "works on my machine". That is the part I actually want people to take away from Docker, and it turns out a game makes them care enough to run the commands.

Taking it to AWS

Once it worked locally I wanted it on a real domain. I also wanted to answer a question I keep getting, from people on my team and from people in the community: what does it really cost to run one small container on ECS?

So I built it twice. Both profiles live in the same Terraform and you switch between them with a single variable.

full, around $30 a month
ECR, ECS, ALB, ACM and autoscaling. One to three tasks with CPU target tracking, HTTPS with a free ACM certificate, and an ALB health checking the tasks and replacing them when they die.

This is what I would ship at work. The load balancer is most of the bill, and it is also most of the value: it gives you something stable to point DNS at, and it recovers on its own.

low_cost, around $9 a month
ECR, ECS and Route 53. One task, fixed. HTTP only. No load balancer.

That last part creates a real problem. Without an ALB there is nothing stable to point DNS at, so a small helper script resolves the running task's public IP at terraform apply time and writes an A record with a low TTL.

I want to be blunt about what that costs, because posts that show you the cheap option tend to skip this part. If the task restarts between applies, that record points at an IP that no longer exists. It stays wrong until the next apply. Nothing is watching and nothing heals itself.

For a game on my personal domain I can live with that. For anything with people waiting on the other end, I would not.

The Terraform

terraform/
├── components/          # reusable modules
│   ├── network/           # default VPC/subnets lookup
│   ├── ecr/                # image repository
│   ├── dns/                 # existing Route53 hosted zone lookup
│   ├── acm/                  # free TLS cert, DNS-validated, full mode only
│   ├── alb/                   # load balancer + listeners + DNS alias, full mode only
│   ├── ecs/                    # cluster, task definition, service
│   ├── autoscaling/             # target-tracking policy, full mode only
│   └── dns_task_record/          # IP-synced DNS record, low_cost mode only
├── vars/
│   ├── prod.tfvars                # deployment_mode = "full"
│   ├── prod-lowcost.tfvars        # deployment_mode = "low_cost"
│   ├── dev.tfvars
│   └── backend-*.hcl              # per-environment S3 backend config
├── main.tf / variables.tf / outputs.tf

A deployment_mode variable decides which modules exist. The ACM, ALB and autoscaling modules carry count = local.full_mode ? 1 : 0, so choosing a profile is just choosing a .tfvars file.

State lives in S3 with Terraform 1.10 native locking (use_lockfile = true), which finally means no DynamoDB table sitting there just to hold a lock.

Deploying it

cd terraform
terraform init -backend-config=vars/backend-prod.hcl
terraform apply -target=module.ecr -var-file=vars/prod.tfvars   # create the repo first

REPO_URL=$(terraform output -raw ecr_repository_url)
docker build -t "$REPO_URL:latest" ..
docker push "$REPO_URL:latest"

terraform apply -var-file=vars/prod.tfvars

The ECR repository has to exist before you can push an image to it, which is why that first apply is targeted. It is the kind of ordering detail that is obvious in hindsight and annoying the first time.

After that the service comes up and the tasks register behind the target group.

And the game runs on its own subdomain over HTTPS, on a certificate that costs nothing.

What I would do differently

If I ever needed low_cost mode to stay up without me watching it, I would replace my script with Cloud Map public DNS namespaces. That is the native AWS answer to this problem. It also brings Route 53 delegation complexity that I did not want to take on for a weekend project.

CI/CD is the obvious next step: build, push, and ecs update-service --force-new-deployment on every push to main. Right now I do it by hand, which is fine until it is not.

Why bother with any of this

The honest reason is that a side project is the only place where an expensive mistake is free. I cannot try out a routing decision on a system where a bad afternoon means people stuck at a gate. I can try it here, get it wrong, and fix it on a Sunday.

If you are learning ECS or Terraform, my advice is to pick something you actually want to see running. It beats another tutorial you will abandon halfway.

Try it

Live: https://flappy-docker.carolinaherreramonteza.com

Code: https://github.com/carotechie/game-flappy-docker

Full deployment walkthrough for both modes: docs/SetupOnAWS.md, and in Spanish at docs/SetupOnAWS.es.md.

If you dodge more than 10 containers, you are doing better than me.

De cero a la nube: cómo dockericé mi feed de AWS y lo desplegué en ECS

Carolina Herrera — Fri, 19 Jun 2026 02:08:33 +0000

Hace unas semanas me cansé de entrar manualmente a la página de AWS What's New para ver qué habían lanzado. Así que hice lo que cualquier persona razonable haría: construí una app, la metí en Docker y la subí a ECS. En este artículo te cuento exactamente cómo, con todos los comandos y sin saltarme pasos.

¿Qué vamos a construir?

Una pequeña app web en Python (Flask) que consume el RSS público de AWS y muestra las últimas novedades clasificadas por categoría (AI/ML, Seguridad, Data, FinOps, CloudOps). Tiene modo oscuro y claro, animaciones de entrada y muestra hace cuánto tiempo se publicó cada novedad.

El flujo completo es:

Código local  →  Docker image  →  Amazon ECR  →  Amazon ECS (Fargate)  →  URL pública

Repositorio: github.com/carotechie/docker-ecs-feedaws

Lo que necesitas antes de empezar

Docker Desktop instalado y corriendo
AWS CLI configurada (aws configure)
Una cuenta de AWS con permisos para ECR y ECS
Python 3.12+ (solo para desarrollo local)

1. La app: Flask + feedparser

El código principal es minimalista. app.py hace tres cosas: consume el RSS de AWS, limpia el HTML que viene en los summaries y detecta la categoría de cada novedad según sus palabras clave.

# app.py (fragmento)
AWS_RSS_URL = "https://aws.amazon.com/about-aws/whats-new/recent/feed/"

@app.route("/")
def index():
    feed = feedparser.parse(AWS_RSS_URL)
    # ...procesa y clasifica cada entrada
    return render_template("index.html", items=items, fetched_at=fetched_at)

No hay base de datos, no hay caché. Cada vez que alguien entra a la URL, la app hace un request al RSS de AWS en ese instante. Simple y siempre actualizado.

Las dependencias van en requirements.txt:

flask==3.1.1
feedparser==6.0.11
gunicorn==23.0.0

2. El Dockerfile

FROM python:3.12-slim

WORKDIR /app

COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

COPY . .

EXPOSE 8080
CMD ["gunicorn", "--bind", "0.0.0.0:8080", "app:app"]

Nada del otro mundo. Usamos python:3.12-slim para mantener la imagen liviana y gunicorn como servidor WSGI (más robusto que el servidor de desarrollo de Flask para producción).

Un detalle importante: copiamos requirements.txt antes que el resto del código. Esto aprovecha el caché de capas de Docker — si no cambias las dependencias, Docker reutiliza esa capa y el build es mucho más rápido.

3. Probar localmente

# Construir la imagen
docker build -t mifeed-aws .

# Correr el contenedor
docker run -d -p 8080:8080 --name mifeed mifeed-aws

# Verificar que levantó
curl http://localhost:8080/health
# → {"status": "ok"}

Abre http://localhost:8080 en tu navegador y deberías ver algo así:

Para detenerlo:

docker stop mifeed && docker rm mifeed

4. Subir la imagen a Amazon ECR

Amazon ECR (Elastic Container Registry) es el registro privado de imágenes Docker de AWS. Piénsalo como un Docker Hub pero dentro de tu cuenta de AWS.

4.1 Crear el repositorio en ECR

aws ecr create-repository \
  --repository-name demos/mifeed-aws \
  --region us-east-1

El comando devuelve un JSON. Copia el valor de repositoryUri, lo vas a necesitar. Se ve así:

url.dkr.ecr.us-east-1.amazonaws.com/demos/mifeed-aws

4.2 Autenticarte con ECR

aws ecr get-login-password --region us-east-1 \
  | docker login \
    --username AWS \
    --password-stdin \
    url.dkr.ecr.us-east-1.amazonaws.com

Si ves Login Succeeded, estás lista para el siguiente paso.

4.3 Etiquetar y subir la imagen

ECR_URI=url.dkr.ecr.us-east-1.amazonaws.com/demos/mifeed-aws

# Etiquetar la imagen local con el URI de ECR
docker tag mifeed-aws:latest $ECR_URI:latest

# Subir al registro
docker push $ECR_URI:latest

El push puede tardar unos minutos la primera vez. Verás las capas subiendo una por una.

5. Configurar y desplegar en Amazon ECS

ECS (Elastic Container Service) es el servicio administrado de AWS para correr contenedores. Usaremos Fargate, que es el modo serverless: no tienes que gestionar servidores ni instancias EC2.

El flujo en ECS tiene tres piezas:

Task Definition  →  Cluster  →  Service
(qué correr)        (dónde)     (cuántas copias y cómo)

5.1 Crear el Cluster

Ve a la consola de AWS → ECS → Clusters → Create Cluster.

Configuración:

Cluster name: mifeed-aws
Infrastructure: AWS Fargate (serverless)
Deja el resto por defecto y haz clic en Create

5.2 Crear la Task Definition

La Task Definition le dice a ECS qué imagen correr, cuánta CPU/memoria usar y en qué puerto escucha.

Ve a Task Definitions → Create new task definition.

Configuración:

Task definition family: mifeed-aws
Launch type: AWS Fargate
CPU: 0.25 vCPU
Memory: 0.5 GB
Container name: mifeed-aws
Image URI: url.dkr.ecr.us-east-1.amazonaws.com/demos/mifeed-aws:latest
Container port: 8080
Protocol: TCP

Haz clic en Create.

5.3 Crear el Service

El Service mantiene corriendo el número de Tasks que definas y las reinicia si fallan.

En tu cluster mifeed-aws → pestaña Services → Create.

Configuración:

Family: mifeed-aws
Service name: mifeed-service
Desired tasks: 1
Launch type: Fargate
VPC: la VPC por defecto está bien para empezar
Subnets: selecciona al menos 2 subnets públicas
Security group: crea uno nuevo (o usa uno existente) con la siguiente regla de entrada:

Tipo	Puerto	Origen
Custom TCP	8080	0.0.0.0/0

Public IP: Enabled ← importante, sin esto no tendrás IP pública

Haz clic en Create Service y espera unos minutos a que el Task pase a estado RUNNING.

6. Conectarme a mi aplicación

Una vez que el Task está en RUNNING, la app ya está viva en internet.

Obtener la IP pública

En la consola: Clusters → mifeed-aws → Tasks → clic en el Task ID → busca la sección Network → copia la Public IP.

Abre en tu navegador:

http://<PUBLIC_IP>:8080

Y deberías ver tu feed funcionando en la nube:

Verificar el health check

curl http://<PUBLIC_IP>:8080/health
# → {"status": "ok"}

¿Y las actualizaciones automáticas?

La app no necesita ninguna configuración especial. Como el feed se parsea en cada request, cada vez que alguien carga la página obtiene los datos más recientes de AWS. El contenedor puede estar corriendo semanas sin ningún reinicio y el feed siempre estará actualizado.

Si quieres que ECS descargue automáticamente una nueva versión de tu imagen cuando hagas cambios:

Sube la nueva imagen a ECR con el mismo tag latest
En ECS → tu Service → Update service → activa Force new deployment
ECS descargará la nueva imagen y reemplazará el Task sin downtime

Reflexión final

Lo que me gustó de este ejercicio fue lo poco que tuve que tocar para pasar de "corre en mi máquina" a "corre en la nube":

El Dockerfile no cambió
La app no sabe si está en local o en ECS
La única diferencia real es de dónde viene la imagen (local vs ECR)

Eso es exactamente lo que hace valioso a Docker en un contexto de nube. El artefacto que pruebas localmente es el mismo artefacto que corre en producción.

Próximos pasos

Si quisieras llevar esto a producción real, los siguientes pasos serían:

Agregar un Load Balancer (ALB) para tener una URL fija en vez de una IP efímera
Dominio propio con Route 53 y un certificado SSL en ACM
CI/CD con GitHub Actions para que cada push a main actualice la imagen en ECR y fuerce un nuevo deploy en ECS
Auto Scaling para que el servicio escale según la carga

Mi experiencia en el AWS re:Invent 2024: De Asistente a Speaker 🚀

Carolina Herrera — Sun, 17 May 2026 13:56:30 +0000

¡Hola a toda la comunidad de dev.to! 👋

Llevo 11 años trabajando como DevOps Engineer y recién me animé a vivir esta experiencia de la nube en el AWS re:Invent 2024. El evento oficial ocurrió del Lunes 2 al Viernes 6 de Diciembre del 2024, y la experiencia me encantó tanto, que volví en el 2025 (¡pero esa será otra historia!).

Ya sea que planees ir en el futuro o quieras conocer cómo es el evento desde adentro, aquí te dejo mis anécdotas, el presupuesto detallado y el gran hito de mi carrera.

📍 Empezando la aventura en Las Vegas

El pre-evento sucedió el Domingo 1 de Diciembre del 2024. Una de las primeras cosas que hice al llegar fue dejar mi marca: es un clásico tomarse una foto dinámica junto al enorme muro negro que parece una pizarra, lleno de firmas y el inmenso logo de "re:Invent".

Tip pro: Recomiendo llegar 1 o 2 días antes de que inicie todo. Esto te da tiempo valioso para aclimatarte, ubicarte en los gigantescos pasillos del centro de convenciones y empezar a respirar el ambiente tecnológico con tranquilidad.

🌐 Una ciudad tomada por la tecnología

Otro punto impresionante es que el re:Invent literalmente se apropia de la ciudad. Durante toda la semana del evento, verás promociones masivas de diferentes herramientas tecnológicas como Logic Monitor, Snyk, Datadog, etc. Las campañas de marketing están por todos lados: desde que aterrizas en el aeropuerto, en los trenes, en los gigantescos paneles a lo largo del Strip de Las Vegas e incluso proyectadas en la imponente The Sphere. ¡Es una inmersión total!

🤝 Conectando con la comunidad

El viaje arrancó compartiendo experiencias en el AWS Community Women Meetup. Empezar rodeada de esta gran comunidad te llena de inspiración para afrontar la intensa semana que se viene.

🏷️ El objeto más valioso: Tu Badge

Grábate esto: el Badge es lo más importante de todo el evento porque te lo solicitarán en todo momento.

Lo genial es que puedes evitar aglomeraciones recogiendo tu identificación desde el domingo previo al evento. Solo necesitas el QR de tu entrada y puedes hacerlo en el mismo aeropuerto al llegar, o en algunos de los hoteles sede como el Venetian o el MGM. Este año el mío fue súper especial, ya que llevaba mi nombre, mi empresa (Globant) y destacaba mis roles de "Attendee" y "Speaker". ¡Cuídalo como si fuera oro!

🎤 Mi gran hito: ¡Fui Speaker!

Este año no solo fui a aprender, ¡sino a compartir! Tuve el inmenso honor de subirme al escenario como Speaker.

Me presenté en el Theater 3, donde impartí mi sesión titulada "Amazon EKS: When troubleshooting becomes a months-long journey". Fue una experiencia increíble poder compartir con la audiencia los desafíos reales de mi día a día como DevOps Tech Lead.

📅 La agenda, comida y el "Todo Incluido"

El evento inicia oficialmente el Lunes aproximadamente a las 2:00 PM con un Keynote de apertura y finaliza el Viernes.

Algo que muchos no saben es que todo está incluido en tu entrada. Durante el evento, tendrás a tu disposición snacks y bebidas por todas partes y durante todo el día. Sin embargo, ¡ojo con la comida principal! El desayuno y almuerzo se sirven solo en horarios específicos, ya sea en formato buffet o como lunch box si necesitas irte corriendo a una charla.

Si llegas fuera de horario, encontrarás las puertas cerradas (¡me pasó más de una vez!). Pero aquí va un gran salvavidas: hay varios restaurantes en los hoteles que son reservados exclusivamente por sponsors como Datadog, MongoDB y más, en donde puedes desayunar, almorzar y cenar. Recuerda siempre revisar el detalle de los locales reservados para los sponsors para aprovechar estas opciones.

A pesar de los horarios estrictos, cuando lograba coincidir, aprovechaba estos espacios en la EXPO para hacer una pausa, revisar mi laptop, acomodar mis cosas y recargar energías con un buen plato antes de mi siguiente sesión.

Para que no te pierdas:

La zona principal de EXPO está en el hotel Venetian.
Las charlas están distribuidas por todos los hoteles resaltados en el mapa del evento.
Aprovecha el transporte gratuito (tren o buses) que conectan los distintos hoteles para no caminar todo el Strip.

💰 Hablemos de presupuesto

Uno piensa que un evento así puede ser imposible para los que estamos en LATAM o en algún país no dolarizado. Sin embargo, logré aplicar una recomendación clave que me dieron en el AWSome Women Summit 2024: ahorrar durante los 12 meses del año.

Aquí les comparto mi desglose de costos aproximado:

Vuelo: $800 USD (desde Perú)
Hotel: $1,300 USD (eligiendo uno con convenio con el re:Invent)
Transporte/Taxi: $100 USD (aeropueto-hotel-aeropuerto)
Comida/Varios: $100 USD (para gastos fuera del evento)
Entrada: $2,000 USD (Tip: Si aplicas y eres parte del programa AWS Community Builders o User Group Leader, ¡tienes un descuento del 60%!)
Total aproximado = $4,300 USD. Si lo ahorras en 12 meses, serían unos $350 USD mensuales.

Datos adicionales de oro:

Siempre se abre la beca All Builders Welcome Grant, que te brinda todo lo mencionado totalmente cubierto y es para cualquier persona. ¡Guarden el link para el próximo año!
A veces, hablarlo en tu empresa te puede ayudar a pagar el viaje. En mi caso, al mencionar que sería Speaker, mi trabajo cubrió todos mis gastos.

💡 Recomendaciones doradas y la fiesta AWS re:Play

Sobrevivir a esta semana requiere de estrategia. Mi recomendación estrella es sobre la ropa: la clave es la comodidad. Vas a caminar muchísimo, así que usa zapatillas que ya tengas. ¡Por favor, no lleves zapatillas nuevas! Tomará tiempo que se adapten a ti y tus pies sufrirán.

Además, te sugiero:

Máximo 1 o 2 charlas por día para no saturarte.
Considera las distancias de los traslados.

Y claro, ¡el Jueves es la fiesta oficial conocida como AWS re:Play! Es el evento perfecto para celebrar, disfrutar de los escenarios con luces, tomarte fotos con tu equipo y despedir la semana a lo grande (¡y también está incluida en tu entrada!).

🍓 Recargando energías

Siempre hay espacio para relajarse y divertirse. ¡Encontrarás diferentes stands y actividades a lo largo de todos los hoteles del evento!
. En mi caso, aproveché para jugar el juego interactivo "BuilderCards" con otros asistentes, tomarme una foto junto a la gran mascota verde (el bucket de AWS), ¡y hasta me deslicé con los brazos en alto por un enorme tobogán morado al lado de las escaleras mecánicas!
.
Recorrer la zona de la EXPO es una locura: te puedes cruzar con un simulador de golf, gigantescas maquetas tipo Lego que incluyen hasta una montaña rusa amarilla, y pasear entre inmensos stands de patrocinadores como CockroachDB y Okta
.

🧳 La regla de oro final: Maleta vacía para el SWAG

Todo asistente veterano te lo dirá: tienes que llevar una maleta vacía. La cantidad de mercadería promocional que consigues en la EXPO es una locura. Logré llenarla con peluches, calcetines coloridos, libretas, botellas, camisetas y muchos pines.

🗓️ ¡Prepárate para el próximo re:Invent!

Un último súper dato: apenas termina cada edición del re:Invent, automáticamente se publican las fechas para el evento del año siguiente. Así que si te animaste a ir con este post, puedes revisar cuándo será la próxima edición y empezar a planificar desde hoy mismo visitando su página oficial: https://aws.amazon.com/events/reinvent/.

¡Sigamos conectados!

¡Gracias a todos los que hicieron de este evento una experiencia inolvidable! Me encantaría seguir la conversación con ustedes sobre la nube y DevOps.

Pueden encontrarme en:

Dev.to / Redes: @carotechie
LinkedIn: linkedin.com/in/carolinahm

¡Nos vemos en la nube! ☁️✨