15 · Desplegar en AWS
La imagen está en ECR — ahora córrela. AWS ofrece un espectro de gestionado-vs-control: Elastic Beanstalk (gestionado, le entregas un contenedor), EC2 puro (una VM que conectas tú mismo) y endpoints de SageMaker (serving de modelos totalmente gestionado con autoescalado). Elegir el peldaño correcto es la decisión de despliegue.
Las opciones de despliegue de AWS están en un espectro de gestionado-vs-control. **Elastic Beanstalk** es PaaS gestionado: le entregas tu imagen Docker (un `Dockerrun.aws.json`) y aprovisiona los servidores, el balanceador de carga y los health checks por ti. **EC2** es una máquina virtual cruda: máximo control, pero instalas Docker, haces pull de la imagen, corres el contenedor y eres dueño del SO, el escalado y el uptime tú mismo. Los **endpoints de SageMaker** son *serving de modelos* totalmente gestionado: despliega un modelo y SageMaker te da un endpoint HTTPS con autoescalado y monitoreo incorporado. Elige según cuánta carga operativa quieras cambiar por control: Beanstalk para un contenedor gestionado rápido, EC2 para control total, SageMaker para serving gestionado nativo de ML.
Sin esto:
Sin elegir deliberadamente, o sobre-ingenierizas (gestionando a mano una flota de EC2 cuando Beanstalk lo habría hecho por ti) o sub-aprovisionas (una sola caja EC2 sin autoescalado ni health checks detrás de un servicio que los necesitaba) — y lo pagas en tiempo de ops o caídas.
Tu imagen está subida a ECR (lección 14). Ahora algo tiene que correrla y exponerla al mundo. AWS te da varias formas, y se alinean en un eje: ¿cuánto gestionas tú vs cuánto gestiona AWS? Más gestionado = menos trabajo de ops pero menos control; más crudo = control total pero eres dueño de todo. Tres peldaños cubren la mayoría de servicios de ML.
Elastic Beanstalk — PaaS gestionado, "aquí está mi contenedor, córrelo". Beanstalk es el botón fácil. Le entregas tu app — para un servicio contenerizado, un diminuto Dockerrun.aws.json que apunta a tu imagen de ECR — y Beanstalk aprovisiona todo lo de abajo: instancias EC2, un balanceador de carga, monitoreo de salud, despliegues rolling y autoescalado, todo configurado por ti. Tú piensas en la app; AWS piensa en los servidores. El intercambio es menos control sobre la infraestructura exacta. Beanstalk es el punto dulce para "tengo una imagen Docker de mi servicio de modelo FastAPI y solo quiero que corra y esté balanceado".
EC2 — una máquina virtual cruda, máximo control. EC2 es una VM pelada en la nube. Entras por SSH, instalas Docker, haces docker pull de tu imagen desde ECR, la corres con docker run, abres los puertos del security-group y — crucialmente — tú eres dueño de los parches del SO, del supervisor de procesos que la reinicia si muere, del escalado y del uptime. Control total, responsabilidad total. Elige EC2 cuando necesitas algo que Beanstalk no te dará: una configuración de SO personalizada, drivers de GPU, redes inusuales o un trabajo de larga vida que no es un simple servicio web.
Endpoints de SageMaker — serving totalmente gestionado y nativo de ML. SageMaker es la plataforma de machine learning de AWS, y un endpoint en tiempo real es su producto gestionado de serving de modelos. Le entregas un modelo (y un contenedor que sabe servirlo) y SageMaker levanta un endpoint HTTPS con autoescalado con health checks, redundancia multi-AZ y ganchos incorporados para monitoreo y división de tráfico A/B — hecho a propósito para servir predicciones. Es el más gestionado y el más consciente de ML, con un sobreprecio. Elige SageMaker cuando servir el modelo es el producto y quieres autoescalado + monitoreo sin construirlo.
Elegir. Por defecto, Beanstalk para una API de modelo contenerizada que solo quieres correr con un balanceador y mínimo ops. Recurre a EC2 cuando necesitas un control que Beanstalk no puede dar. Elige un endpoint de SageMaker cuando quieres serving de ML totalmente gestionado y con autoescalado, con monitoreo incorporado. La pregunta es siempre la misma: ¿cuánta carga operativa quieres ceder a cambio de control?
Rutas de despliegue de AWS: Beanstalk (`eb init/create/deploy` — gestionado), EC2 puro (entrar por SSH, instalar Docker, pull desde ECR, `docker run` — tú eres dueño del ops) y un boceto de endpoint de SageMaker (serving de ML gestionado y con autoescalado).
Un `Dockerrun.aws.json` v1 de Beanstalk: apunta a Elastic Beanstalk a la imagen exacta de ECR (por tag de SHA) y mapea el puerto 8000 del contenedor al puerto 80 del host — Beanstalk maneja los servidores, el balanceador de carga y el escalado alrededor.
Tu equipo tiene un servicio de modelo FastAPI contenerizado en ECR y quiere que corra, balanceado y con autoescalado, con la menor gestión de servidores posible — pero NO necesitas funciones de serving específicas de ML como división de tráfico A/B. ¿Qué opción de AWS encaja mejor?
- Las opciones de despliegue de AWS forman un espectro de gestionado-vs-control: Elastic Beanstalk (PaaS gestionado — le entregas un contenedor), EC2 puro (una VM que conectas y posees) y endpoints de SageMaker (serving de ML totalmente gestionado).
- Beanstalk toma un diminuto `Dockerrun.aws.json` que apunta a tu imagen de ECR y aprovisiona los servidores, el balanceador, los health checks y el autoescalado — el botón fácil para una API de modelo contenerizada.
- Elige por el intercambio: Beanstalk para un contenedor gestionado rápido, EC2 cuando necesitas control total que AWS no dará, un endpoint de SageMaker para serving nativo de ML con autoescalado y monitoreo incorporado.
Los equipos en producción corren su API de modelo en el peldaño de AWS que encaje con la necesidad — Beanstalk o ECS para un contenedor gestionado, EC2 para infra especial, un endpoint de SageMaker cuando el serving de ML con autoescalado es el producto — todos haciendo pull de la imagen desde ECR.
Si lo quitas: Sin elegir deliberadamente sobre-ingenierizas una flota EC2 que Beanstalk pudo gestionar, o sub-aprovisionas una caja sola sin autoescalado ni health checks — pagando en tiempo de ops o caídas.