El error más común y costoso al desplegar aplicaciones empresariales con modelos de lenguaje es levantar instancias virtuales dedicadas con GPUs (como una instancia EC2 g5.2xlarge). Al hacerlo, la empresa se compromete a pagar una tarifa horaria fija que puede superar los 1.000 dólares al mes incluso si durante las noches y fines de semana nadie utiliza la aplicación y los servidores están completamente desocupados.

Para aplicaciones corporativas con tráfico intermitente o variable, la arquitectura definitiva es el paradigma Serverless puro: delegar la inferencia en AWS Bedrock (que factura exclusivamente por token consumido sin servidores fijos) y orquestar la lógica de negocio mediante AWS Lambda empaquetado en contenedores Docker. Cuando no hay peticiones, el coste computacional es de cero dólares; cuando el tráfico explota ante una campaña de marketing, el sistema escala automáticamente a miles de peticiones simultáneas sin intervención manual. Basándonos en la arquitectura de referencia de AWS Bedrock Official Documentation y los estándares de contenedores de Docker Containerization Standards, en esta guía construirás este pipeline paso a paso.

1. Por Qué Bedrock y Lambda Superan a las Instancias EC2: Facturación por Token vs. Servidor Fijo

El talón de Aquiles de la infraestructura basada en servidores EC2 con GPUs (como A10G o H100) es que pagas por la disponibilidad de hardware, no por el valor generado. Si tu empresa tiene 100 consultas al día, cada una te cuesta 10 dólares en infraestructuras desocupadas.

Con AWS Bedrock, Amazon gestiona el clúster de supercomputación y tú pagas únicamente por token procesado (por ejemplo, 0.003 $ por cada mil tokens con Claude 3.5 Sonnet). Al enlazarlo con AWS Lambda, la función solo se enciende cuando entra una petición HTTP a través de API Gateway y se apaga de inmediato, garantizando una eficiencia de costes perfecta.

La arquitectura serverless escala de cero a miles de peticiones concurrentes en segundos.

2. Configuración en la Consola: Permisos IAM de Menor Privilegio y Activación de Modelos

Antes de escribir código, debes solicitar acceso a los modelos en tu región de AWS (recomendamos us-east-1 o eu-central-1):

1. En la consola de AWS, navega a Amazon Bedrock > Model access y solicita acceso a Anthropic Claude 3.5 Sonnet y Meta LLaMA 3.1.
2. Crea un rol IAM para Lambda y adjúntale una política restrictiva que solo permita invocar modelos concretos:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "bedrock:InvokeModel",
        "bedrock:InvokeModelWithResponseStream"
      ],
      "Resource": "arn:aws:bedrock:*::foundation-model/*"
    }
  ]
}

3. Dockerfile Multi-Stage: Empaquetando Boto3 y FastAPI para AWS Lambda

Para evitar problemas de compatibilidad de binarios y superar el límite de 250 MB de los archivos ZIP convencionales de Lambda, utilizaremos la imagen base oficial de AWS Lambda para Python en un contenedor Docker:

FROM public.ecr.aws/lambda/python:3.11

# Copiar archivo de requerimientos
COPY requirements.txt .

# Instalar versión actualizada de boto3 con soporte completo de Bedrock
RUN pip install --no-cache-dir -r requirements.txt

# Copiar el código del handler
COPY lambda_function.py .

# Comando de inicio del runtime de AWS Lambda
CMD [ "lambda_function.handler" ]

4. Código Python: Invocación de Claude 3.5 Sonnet y LLaMA 3 mediante Boto3 y Streaming

A continuación se muestra el código del archivo lambda_function.py utilizando el SDK oficial boto3:

import json
import boto3

# Inicializar cliente de Bedrock Runtime
bedrock_client = boto3.client("bedrock-runtime", region_name="us-east-1")

def handler(event, context):
    try:
        # Parsear cuerpo de la petición HTTP
        body = json.loads(event.get("body", "{}"))
        user_prompt = body.get("prompt", "Explica qué es un contenedor Docker.")
        
        # Estructura de payload para Claude 3.5 Sonnet (Converse API)
        payload = {
            "anthropic_version": "bedrock-2023-05-31",
            "max_tokens": 1024,
            "messages": [
                {"role": "user", "content": user_prompt}
            ]
        }
        
        # Invocar modelo de lenguaje
        response = bedrock_client.invoke_model(
            modelId="anthropic.claude-3-5-sonnet-20240620-v1:0",
            contentType="application/json",
            accept="application/json",
            body=json.dumps(payload)
        )
        
        result = json.loads(response["body"].read())
        answer = result["content"][0]["text"]
        
        return {
            "statusCode": 200,
            "headers": {"Content-Type": "application/json"},
            "body": json.dumps({"answer": answer})
        }
    except Exception as e:
        return {
            "statusCode": 500,
            "body": json.dumps({"error": str(e)})
        }

Construcción y etiquetado de contenedores Docker compatibles con el runtime de AWS Lambda.

5. Despliegue: Subida de la Imagen a Amazon ECR y Conexión con AWS Lambda

Compila y sube tu contenedor a Amazon Elastic Container Registry (ECR) mediante la línea de comandos:

# 1. Autenticar Docker con tu registro ECR
aws ecr get-login-password --region us-east-1 | docker login --username AWS --password-stdin 123456789012.dkr.ecr.us-east-1.amazonaws.com

# 2. Construir y subir imagen
docker build -t mi-lambda-llm .
docker tag mi-lambda-llm:latest 123456789012.dkr.ecr.us-east-1.amazonaws.com/mi-lambda-llm:latest
docker push 123456789012.dkr.ecr.us-east-1.amazonaws.com/mi-lambda-llm:latest

Posteriormente, en la consola de AWS Lambda, seleccionas ‘Crear función > Imagen de contenedor’, apuntas al URI de ECR y asignas el rol IAM configurado en el paso anterior.

6. Tabla Comparativa: EC2 Dedicado vs. SageMaker Endpoints vs. Bedrock Serverless

Contraste económico y operativo para cargas de trabajo de IA:

7. Rendimiento: Mitigación de Cold Starts y Memory Allocation Óptimo en Lambda

Al utilizar imágenes de contenedor, el arranque en frío (Cold Start) inicial de Lambda puede tomar entre 1 y 2 segundos mientras se descarga la capa. Para optimizarlo:

• Asignación de Memoria Proporcional: Configura la memoria de tu función Lambda en 1.024 MB o 1.769 MB. Aunque la función no use toda la RAM, en AWS Lambda la potencia de CPU y el ancho de banda de red asignados escalan en proporción directa a la memoria contratada.
• Concurrencia Aprovisionada (Provisioned Concurrency): Para APIs comerciales de misión crítica donde cada milisegundo cuenta, puedes mantener 2 o 3 instancias calientes continuamente, eliminando el cold start al 100%. Si deseas blindar la entrada de tus modelos, revisa nuestra guía sobre prevención de Prompt Injection.

Monitorización de latencias y consumo de memoria en Amazon CloudWatch Metrics.

8. Preguntas Frecuentes sobre Despliegue Serverless con AWS Bedrock

¿Puedo utilizar streaming de tokens con AWS Lambda hacia mi frontend?
Sí. AWS Lambda soporta de forma nativa Response Streaming a través de la función awslambda.streamify_response en Node.js y mediante adaptadores en Python combinados con bedrock_client.invoke_model_with_response_stream, permitiendo que las palabras aparezcan progresivamente en el navegador del usuario.

¿Garantiza AWS que los datos enviados a Bedrock no se usan para reentrenar modelos?
Sí. El contrato de privacidad de Amazon Bedrock establece explícitamente que tus prompts, documentos y salidas generadas están cifrados en tránsito (TLS 1.3) y en reposo (KMS), permanecen estrictamente dentro de tu Virtual Private Cloud (VPC) y jamás se comparten con Anthropic, Meta ni con terceros para el entrenamiento de modelos públicos.

¿Qué ventaja tiene Bedrock frente a llamar directamente a la API de OpenAI o Anthropic?
La ventaja primordial es la gobernanza empresarial y la facturación unificada: todo el consumo se consolida en tu factura corporativa de AWS, puedes aplicar controles de acceso granulares mediante IAM, conectar tu VPC privada sin que el tráfico toque internet público y aplicar políticas de Guardrails semánticos nativos de AWS.