Arquitectura privada en Azure Container Apps con Terraform: la serie completa, de punta a punta

En resumen: Esta serie construye, desde cero y con Terraform, una arquitectura privada en Azure Container Apps: una plataforma donde los servicios se comunican solo por la red interna (VNet), sin nada expuesto a internet salvo una única puerta controlada. Son 13 capítulos y cada capítulo es una capa (networking, registry y secrets privados, identidad sin contraseñas, pipelines separados, observabilidad), cada uno con su artículo y su video. Este es el capítulo 0: el mapa completo antes de escribir la primera línea de infraestructura.

Hola, te presento el proyecto

Hola, qué tal. Quiero presentarte el proyecto que estoy armando y que vas a seguir conmigo en esta serie. La idea es construir, paso a paso, una arquitectura segura en Azure donde los servicios se comunican solo por la red interna (la VNet) usando Azure Container Apps. Nada queda expuesto a internet salvo lo que decidimos exponer, de forma explícita, detrás de una única puerta controlada. En una frase: nada entra ni sale sin permiso. Todo es privado por defecto (la red, el registry de imágenes, los secrets, el storage) y lo público es la excepción, no la regla.

Si te interesa ver cómo se arma de verdad una arquitectura privada y segura en Azure (no piezas sueltas, sino la plataforma completa de principio a fin), este es tu lugar. No es un tutorial de "hola mundo": es el tipo de plataforma que se opera en una empresa, con red aislada, identidades sin contraseñas, pipelines separados por permisos, entrega progresiva y monitoreo. La app que corre adentro es mínima a propósito; la estrella es la infraestructura que la protege.

El proyecto son 13 capítulos, y cada capítulo es una capa. En cada uno vas a ver el código real en Terraform, cómo se resuelve el CI/CD, y cómo se conectan las piezas entre sí. Se pueden leer en orden (se construyen unos sobre otros) o sueltos, saltando directo al tema que te interese. Este capítulo 0 es el recorrido completo: el mapa de todo lo que viene.

Un apunte antes de arrancar: no hace falta ser experto. Ayuda estar cómodo con la terminal, tener nociones básicas de redes y haber tocado Terraform alguna vez. Si ya conoces Azure y Terraform por encima y quieres el cómo real (los módulos, las decisiones y las trampas que no salen en la documentación oficial), o si estás evaluando Azure Container Apps para cargas privadas y te preguntas hasta dónde llega sin saltar a Kubernetes, vas a sacarle jugo a la serie.

La app, primero en local

Antes de tocar Azure, la app corre entera en tu máquina con un docker compose up. Son cuatro servicios que colaboran: web (la interfaz), api (el backend), processor (valida y guarda) y catalog (el índice). Subes un documento desde la web y aparece en el catálogo, sin recargar la página. El código completo está en el repositorio público de la app: github.com/kevorojas/container-apps-demo. Clónalo, léelo y levántalo con un comando; ahí vas a ver cómo se orquesta todo.

Lo que corre en local es la app pelada: no hay VNet, ni managed identity, ni private endpoints, ni Application Gateway. Y es a propósito. Estos mismos cuatro servicios son los que vamos a hostear de forma privada y segura en Azure a lo largo de la serie; lo único que cambia es el hosting, la app es la misma. Refuerza la idea de fondo: la app es trivial, la estrella es la plataforma que la protege.

La arquitectura, de un vistazo

Estas son las capas que se construyen a lo largo de la serie, en orden. Cada una es un episodio:

• Red privada (VNet). Una red virtual con subredes delegadas, reglas de seguridad (NSG) y Private DNS zones. Es el terreno donde vive todo lo demás.
• Registry y secrets privados. El registry de contenedores (ACR) y el Key Vault se conectan por private endpoints, sin acceso público. Las imágenes y los secrets no viajan por internet.
• Container Apps Environment interno. El corazón de la arquitectura: un entorno integrado a la VNet y sin ingress público. Los servicios existen, pero desde internet no se los ve.
• Identidad sin secrets. Las apps corren con managed identity: hacen pull del registry y leen secrets del Key Vault sin una sola contraseña ni connection string.
• Comunicación interna. Los servicios de la app hablan entre sí solo por red interna (intra-VNet), sin salir a internet en ningún momento, incluido el salto del frontend (web) al backend (api).
• Una única puerta. Un Application Gateway con WAF al frente expone solo el servicio de entrada. Es lo único público de toda la arquitectura.
• Entrega progresiva y autoscaling. Container Apps trae revisions con traffic splitting (canary nativo) y autoscaling event-driven con KEDA, incluido el scale-to-zero.
• Dos pipelines, permisos separados. Un pipeline de infraestructura con permisos amplios y otro de aplicación con least privilege, cada uno con su propia identidad federada (OIDC), sin secretos de larga vida.
• Observabilidad. Azure Monitor, Log Analytics y Grafana gestionado para ver qué pasa adentro.

La carga útil: entrada segura de documentos

Adentro corre una app mínima en FastAPI con cuatro servicios que colaboran sin que nada salga a internet. Así se hablan entre sí:

• web es el frontend (BFF): una UI web mínima de dos pantallas (subir un documento y listar el catálogo), server-rendered con HTMX. Es el único servicio con ingress, detrás del Application Gateway. No toca storage ni catálogo directamente: le pega al api por red interna (intra-VNet).
• api es el backend, interno y sin ingress (solo lo alcanza el web). Recibe el documento del web y no toca el storage de forma directa: se lo pasa al processor por red interna.
• processor valida el documento (hash, tamaño, tipo) y lo escribe en el storage privado usando managed identity (sin connection strings). Cuando termina, le avisa al catalog (otra comunicación interna) que el documento quedó guardado.
• catalog mantiene el índice y la metadata. Cuando alguien pide "listar documentos", el api le consulta al catalog (de nuevo, por red interna) y devuelve la respuesta al web.

El flujo completo es web → api → processor → storage, con processor → catalog para el índice, y api → catalog para listar. Nada toca el storage de forma directa ni sale a internet sin control, y hay una sola puerta pública: la interfaz entra por donde entra todo, detrás del Application Gateway; el api y el resto quedan internos. El salto web → api es, además, otro ejemplo del mismo tema de la serie: comunicación privada service-to-service dentro de la VNet. La app es trivial a propósito: existe para poner a prueba la infraestructura (comunicación interna, identidad y storage privado en funcionamiento), no para ser un producto.

¿Por qué Azure Container Apps y no AKS?

Azure Container Apps es una plataforma serverless de contenedores gestionada por Azure: corre contenedores con escalado automático y networking privado, sin administrar un clúster de Kubernetes. Empiezo la serie por aquí, y no por AKS, por una razón de fondo: cuando no tienes tantos servicios, montar un clúster de Kubernetes no se justifica.

Un clúster de Kubernetes (AKS o el que sea) trae una carga operativa grande: hay que mantener el clúster, hacer los upgrades de versión, administrar el networking del plano de control, los node pools, los add-ons, el RBAC. Todo eso tiene sentido cuando corres decenas de servicios y un equipo de plataforma detrás. Pero para hostear dos o tres aplicaciones, esa sobrecarga no paga: dedicas más tiempo a operar el clúster que a lo que querías construir. Container Apps te da lo que necesitas sin esa mochila:

1. Serverless y scale-to-zero. No administras nodos ni pagas por capacidad ociosa; el entorno escala solo, incluso a cero cuando no hay tráfico.
2. VNet e ingress privado nativos. Tener apps que se comunican solo a nivel VNet, sin ingress público, es una capacidad de fábrica. No hay que armarla a mano.
3. Progressive delivery y autoscaling incluidos. Revisions con traffic splitting y autoscaling event-driven (KEDA integrado) vienen de serie. En Kubernetes eso se resuelve con Argo Rollouts y KEDA instalados y mantenidos por separado.

Esto no es "Container Apps le gana a AKS". Es elegir la herramienta correcta para el tamaño del problema. Cuando el clúster sí se justifica (muchos servicios, GitOps, control fino) la respuesta cambia, y ese es justo el hilo de la próxima temporada: un segundo proyecto que persigue la misma meta con AKS privado y GitOps, para responder la pregunta que las une (¿cuándo Container Apps y cuándo AKS?). Por ahora, todo el foco está en esta arquitectura.

El índice: los 13 episodios que vienen

Cada episodio es un artículo con su video. Se pueden leer en orden (se construyen unos sobre otros) o saltar directo al tema que te interese. Este es el mapa completo de lo que viene; cada enlace se activa cuando publico ese episodio.

Fundaciones

1. Los cimientos: Terraform en Azure con state remoto y locking — estructura del repo, backend remoto de state, locking y autenticación a Azure. (Próximamente)
2. Pipeline de infraestructura: desplegar Terraform con GitHub Actions y OIDC — deploy de la infra sin secrets, con identidad federada de permisos amplios. (Próximamente)

La red privada y sus cimientos

3. Networking privado en Azure: VNet, NSG y Private DNS zones con Terraform — la red donde vive todo lo demás. (Próximamente)
4. ACR y Key Vault privados: Private Endpoints con Terraform — registry de imágenes y secrets sin acceso público. (Próximamente)

El corazón: Container Apps

5. Container Apps Environment interno: VNet integrada y sin ingress público — la pieza central, nada expuesto a internet. (Próximamente)
6. Identidad sin secrets: managed identity en Container Apps (ACR + Key Vault) — apps que corren sin una sola contraseña. (Próximamente)
7. Comunicación interna entre Container Apps: service-to-service en la VNet — los servicios hablando solo por red interna. (Próximamente)

Exponer, escalar y desplegar bien

8. Exposición controlada: Application Gateway y WAF frente a Container Apps — la única puerta abierta de toda la arquitectura. (Próximamente)
9. Autoscaling event-driven en Container Apps: KEDA y scale-to-zero — escalar solo cuando hace falta, y a cero cuando no. (Próximamente)
10. Pipeline de la app con least privilege: OIDC, Trivy y deploy a Container Apps — un pipeline que no puede tocar la infraestructura. (Próximamente)
11. Progressive delivery nativo: revisions y traffic splitting en Container Apps — canary sin herramientas extra. (Próximamente)

Operar y cerrar

12. Observabilidad en Container Apps: Azure Monitor, Log Analytics y Grafana — ver todo lo que pasa adentro. (Próximamente)
13. ¿Cuánto costó todo? Costos reales, terraform destroy y qué mejoraría — la cuenta honesta y el apagado final. (Próximamente)

¿Qué necesitas para seguir la serie?

• Una cuenta de Azure. El trial gratuito (crédito de USD 200 por 30 días) alcanza de sobra para reproducir esta arquitectura con la estrategia de labs efímeros que uso.
• Terraform y la Azure CLI instaladas.
• Nociones básicas de redes (qué es una subred, DNS) y de contenedores (una imagen, un registro). No hace falta dominar Kubernetes.
• Ganas de construir. El código de la app está en un repo público que sirve como referencia mientras avanzas: github.com/kevorojas/container-apps-demo. La infraestructura tendrá su propio repositorio, que enlazo cuando publique los primeros capítulos.

---

Siguiente episodio

Ep 1 — Los cimientos: Terraform en Azure con state remoto y locking (Próximamente). Antes de crear un solo recurso privado, hay que sentar los cimientos: cómo estructuro el repositorio, dónde guardo el state de Terraform de forma remota y con locking, y cómo autentico Terraform contra Azure sin dejar secrets dando vueltas. Es la base sobre la que se apoya toda la arquitectura.

---

Voy publicando un capítulo de la serie por semana. Si quieres que te avise cuando sale el próximo, déjame tu correo. Sin spam, solo el aviso cuando hay algo nuevo.