Palabras clave SEO: Ingress NGINX retirement, Kubernetes Gateway API, EKS migración, AWS Load Balancer Controller, HTTPRoute, ingress2gateway

El fin de una era: Ingress NGINX se retira en marzo 2026

Si tenés Kubernetes en producción, probablemente usás Ingress NGINX. Y si es así, tenés que leer esto.

La comunidad de Kubernetes anunció el retiro oficial del controlador Ingress NGINX en marzo de 2026. Esto significa no más releases, no más bug fixes, no más parches de seguridad. El proyecto está en modo de solo mantenimiento mínimo y se considera EOL (End of Life).

No es un cambio menor. Ingress NGINX es uno de los controladores de ingress más usados del ecosistema, especialmente en Amazon EKS. Pero la buena noticia es que su sucesor — Kubernetes Gateway API — es significativamente mejor, y AWS ya tiene soporte GA a través del AWS Load Balancer Controller.

En este artículo te explico por qué Gateway API es superior, y cómo migrar paso a paso en tu clúster EKS.

¿Por qué Gateway API es mejor que Ingress?

La API de Ingress original fue diseñada para casos simples: enrutar tráfico HTTP/HTTPS. Con el tiempo, los equipos empezaron a meter toda la configuración en anotaciones, resultando en YAML como este:

# La forma vieja y dolorosa
annotations:
  alb.ingress.kubernetes.io/target-group-attributes: |
    deregistration_delay.timeout_seconds=30,
    stickiness.enabled=true,
    stickiness.type=lb_cookie
  alb.ingress.kubernetes.io/healthcheck-path: /health
  alb.ingress.kubernetes.io/scheme: internet-facing

Sin validación, sin IDE support, errores que explotan en runtime. Un desastre.

Gateway API resuelve esto con tres mejoras clave:

1. Modelo orientado a roles

Gateway API separa responsabilidades claramente:

Esto hace que el acceso sea más seguro y el modelo multi-tenant más manejable.

2. CRDs tipadas con validación

En vez de anotaciones como strings, usás CRDs con schema validation:

# La forma nueva con Gateway API
apiVersion: gateway.k8s.aws/v1beta1
kind: TargetGroupConfiguration
spec:
  targetGroupAttributes:
    - key: deregistration_delay.timeout_seconds
      value: "30"
    - key: stickiness.enabled
      value: "true"

Los errores se detectan en kubectl apply, no en producción.

3. Soporte para más protocolos

Ingress solo soporta HTTP/HTTPS. Gateway API soporta también:

• TCPRoute — para bases de datos, gRPC, etc.
• TLSRoute — terminación TLS a nivel TCP
• UDPRoute — para casos de uso como DNS o gaming

AWS Load Balancer Controller: soporte GA para Gateway API

En marzo 2026, AWS anunció el soporte en disponibilidad general (GA) para Kubernetes Gateway API en el AWS Load Balancer Controller. Esto cubre:

• ALB (Application Load Balancer) → tráfico HTTP/HTTPS layer 7
• NLB (Network Load Balancer) → tráfico TCP/UDP layer 4
• VPC Lattice → tráfico east-west entre servicios

Es la solución nativa recomendada para EKS.

Guía de migración paso a paso

Prerrequisitos

• Clúster EKS con Kubernetes 1.29 o posterior
• kubectl configurado
• AWS Load Balancer Controller v2.13.0+
• Permisos IAM apropiados para provisionar ALBs/NLBs

Paso 1: Verificar si usás Ingress NGINX

kubectl get pods --all-namespaces \
  --selector app.kubernetes.io/name=ingress-nginx

Si devuelve resultados, tenés trabajo por hacer.

Paso 2: Instalar las CRDs de Gateway API

kubectl apply -k \
  "github.com/kubernetes-sigs/gateway-api/config/crd?ref=v1.1.0"

Verificá que se instalaron:

kubectl get crd | grep gateway

Deberías ver: gateways.gateway.networking.k8s.io, httproutes.gateway.networking.k8s.io, etc.

Paso 3: Crear el GatewayClass

El GatewayClass le dice a Kubernetes qué controlador va a gestionar los Gateways:

apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
  name: aws-alb
spec:
  controllerName: ingress.k8s.aws/alb

kubectl apply -f gatewayclass.yaml

Paso 4: Crear el Gateway

El Gateway representa el balanceador de carga real (el ALB en AWS):

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: my-gateway
  namespace: default
  annotations:
    alb.ingress.k8s.aws/scheme: internet-facing
    alb.ingress.k8s.aws/target-type: ip
spec:
  gatewayClassName: aws-alb
  listeners:
  - name: http
    port: 80
    protocol: HTTP
  - name: https
    port: 443
    protocol: HTTPS
    tls:
      mode: Terminate
      certificateRefs:
      - kind: Secret
        name: my-tls-cert

Verificá que el ALB se provisione:

kubectl get gateway my-gateway -n default
# ADDRESS debería mostrar el DNS del ALB cuando esté listo

Paso 5: Migrar los Ingress a HTTPRoutes

Antes tenías un Ingress así:

# Ingress NGINX - la forma vieja
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-app
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  rules:
  - host: app.midominio.com
    http:
      paths:
      - path: /api
        pathType: Prefix
        backend:
          service:
            name: api-service
            port:
              number: 80
      - path: /web
        pathType: Prefix
        backend:
          service:
            name: web-service
            port:
              number: 3000

El equivalente en Gateway API:

# HTTPRoute - la forma nueva
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: my-app-route
  namespace: default
spec:
  parentRefs:
  - name: my-gateway
  hostnames:
  - "app.midominio.com"
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /api
    backendRefs:
    - name: api-service
      port: 80
  - matches:
    - path:
        type: PathPrefix
        value: /web
    backendRefs:
    - name: web-service
      port: 3000

Paso 6: Usar ingress2gateway para automatizar la conversión

Para clústeres con muchos Ingress, usá la herramienta oficial:

# Instalar ingress2gateway
go install sigs.k8s.io/ingress2gateway@latest

# Convertir todos los Ingress NGINX del namespace default
ingress2gateway print \
  --providers=ingress-nginx \
  --namespace=default

Revisá la salida, ajustá lo necesario y aplicá.

Paso 7: Estrategia de migración sin downtime

No apagues Ingress NGINX de golpe. La estrategia recomendada es correr ambos en paralelo:

1. Desplegá el Gateway y los HTTPRoutes
2. El ALB nuevo tendrá su propio DNS
3. Testeá en staging apuntando al DNS nuevo
4. En producción, hacé el cambio de DNS con TTL bajo (60s)
5. Monitoreá por 24-48hs
6. Recién entonces desinstalá Ingress NGINX

# Verificar estado de HTTPRoutes
kubectl get httproute -A

# Ver si están Accepted y Programmed
kubectl describe httproute my-app-route

Consideraciones adicionales

cert-manager

Si usás cert-manager para TLS, tiene soporte nativo para Gateway API desde v1.12. Solo actualizá tu Issuer o ClusterIssuer y usá certificateRefs en el listener del Gateway.

Anotaciones sin equivalente directo

Algunas anotaciones muy específicas de Ingress NGINX (como nginx.ingress.kubernetes.io/lua-resty-waf) no tienen equivalente en Gateway API. En esos casos, necesitás evaluar si el AWS Load Balancer Controller (con WAF nativo via AWS WAF) o Envoy Gateway cubren el caso de uso.

Traffic splitting para canary deployments

Una de las features más potentes de Gateway API que Ingress no soporta nativamente:

rules:
- backendRefs:
  - name: my-app-stable
    port: 80
    weight: 90
  - name: my-app-canary
    port: 80
    weight: 10

Con Ingress necesitabas anotaciones específicas de cada controlador. Con Gateway API es estándar.

Resumen

La migración no es opcional, y tampoco tiene que ser traumática. Con la herramienta ingress2gateway y una estrategia de migración progresiva, podés hacerlo con zero downtime.

¿Tenés preguntas sobre la migración en tu stack específico? Dejame tu caso en los comentarios.

Tags: Kubernetes, EKS, AWS, DevOps, Gateway API, Ingress, Migración

En mayo de 2025, AWS lanzó Strands Agents, un SDK open source construido desde adentro del ecosistema AWS, por el equipo que ya lo estaba usando en producción en Amazon Q Developer. La filosofía es diferente: en vez de definir flujos de trabajo paso a paso, le das herramientas al modelo y dejás que él decida cómo usarlas. Menos código de infraestructura, más foco en lo que el agente tiene que hacer.

En este artículo vamos a ver cómo funciona Strands desde adentro, cómo conectarlo con los servicios que ya usás en AWS, casos de uso concretos para equipos de DevOps y cómo compara con las alternativas más usadas hoy.

¿Qué es Strands y cuál es la diferencia?

Strands no es un framework de orquestación tradicional. La diferencia fundamental está en quién toma las decisiones sobre cómo resolver una tarea: en LangChain o LangGraph, esas decisiones las tomás vos, definiendo grafos de nodos y bordes. En Strands, las toma el modelo de lenguaje.

El concepto central se llama model-driven approach: le pasás al LLM un prompt con el objetivo, un conjunto de herramientas disponibles, y él determina por sí mismo qué herramientas invocar, en qué orden, y cómo encadenar los resultados hasta completar la tarea. Esto es el agentic loop de Strands.

Este enfoque pega muy bien con los modelos actuales, que tienen capacidades de razonamiento mucho más sofisticadas que hace dos años. El equipo de Amazon Q Developer, que es donde nació Strands internamente, reportó que pasó de tardar meses en llevar un agente a producción a hacerlo en días o semanas.

Hoy el SDK tiene más de 14 millones de descargas, soporte para Python y TypeScript, y se usa en producción dentro de Amazon Q Developer, AWS Glue y el proyecto Kiro (el IDE con IA de AWS).

📌 Open Source

Strands es 100% open source (Apache 2.0). El repositorio está en github.com/strands-agents/sdk-python. No estás atado a AWS para usarlo: soporta Anthropic, OpenAI, Gemini, Ollama, LiteLLM y más como proveedores de modelo.

Instalación y primer agente en minutos

Empezar con Strands es inusualmente simple. No necesitás configurar grafos, definir estados ni registrar handlers. Veamos cómo se ve desde cero.

Instalación

# Instalar el SDK y el paquete de herramientas pre-construidas
pip install strands-agents strands-agents-tools

# Asegurate de tener credenciales de AWS configuradas
aws configure
# O con variables de entorno:
export AWS_DEFAULT_REGION=us-west-2
export AWS_ACCESS_KEY_ID=...
export AWS_SECRET_ACCESS_KEY=...

Por defecto, Strands usa Amazon Bedrock como proveedor de modelo, específicamente Claude 4 Sonnet. Necesitás habilitar acceso al modelo en Bedrock antes de correr cualquier ejemplo.

El agente más simple posible

from strands import Agent
from strands_tools import calculator, current_time

# Así de simple. Prompt + herramientas = agente funcional.
agent = Agent(
    system_prompt="Sos un asistente técnico para equipos de DevOps.",
    tools=[calculator, current_time]
)

response = agent("¿Cuántos segundos hay en 3 semanas y 2 días?")
print(response)

El agente va a razonar, elegir la herramienta calculator, calcular el resultado y devolver la respuesta. Sin nada más de tu parte.

Crear una herramienta personalizada

Acá está una de las cosas que más me gusta de Strands: convertir cualquier función Python en una herramienta del agente es tan fácil como agregar un decorador. El docstring no es opcional: el modelo lo usa para entender qué hace la herramienta y cuándo invocarla.

from strands import Agent, tool
import boto3

@tool
def get_ec2_instances(region: str = "us-east-1") -> str:
    """
    Lista las instancias EC2 corriendo en la región especificada.
    Útil para obtener un inventario del estado actual de la infraestructura.
    """
    ec2 = boto3.client("ec2", region_name=region)
    response = ec2.describe_instances(
        Filters=[{"Name": "instance-state-name", "Values": ["running"]}]
    )
    instances = []
    for reservation in response["Reservations"]:
        for i in reservation["Instances"]:
            name = next(
                (t["Value"] for t in i.get("Tags", []) if t["Key"] == "Name"),
                "Sin nombre"
            )
            instances.append(f"{name} ({i['InstanceId']}) - {i['InstanceType']}")
    
    return "\n".join(instances) if instances else "No hay instancias corriendo"

# El agente ahora sabe que puede usar esta herramienta
agent = Agent(
    system_prompt="Sos un agente de operaciones AWS. Ayudás a los equipos a entender su infraestructura.",
    tools=[get_ec2_instances]
)

agent("Dame un resumen de las instancias que tenemos corriendo en us-east-1")

Integración con servicios de AWS

Acá es donde Strands realmente brilla para quienes ya trabajamos con el ecosistema de AWS. El SDK viene con herramientas pre-construidas para los servicios más usados, y la integración con Bedrock, S3, DynamoDB, Lambda y más es directa.

Agente con acceso a una Knowledge Base de Bedrock

Uno de los patrones más potentes: un agente que busca en tu base de conocimiento interna antes de responder. Podés tener documentación de arquitectura, runbooks, post-mortems, todo indexado en Bedrock Knowledge Bases y disponible para el agente.

from strands import Agent, tool
import boto3

KNOWLEDGE_BASE_ID = "tu-kb-id"

@tool
def buscar_runbook(query: str) -> str:
    """
    Busca en la base de conocimiento interna runbooks, guías de operaciones
    y documentación de arquitectura. Usá esta herramienta antes de responder
    cualquier pregunta sobre procedimientos o infraestructura.
    """
    client = boto3.client("bedrock-agent-runtime")
    response = client.retrieve(
        knowledgeBaseId=KNOWLEDGE_BASE_ID,
        retrievalQuery={"text": query},
        retrievalConfiguration={
            "vectorSearchConfiguration": {"numberOfResults": 5}
        }
    )
    resultados = []
    for r in response["retrievalResults"]:
        resultados.append(r["content"]["text"])
    
    return "\n---\n".join(resultados)

@tool
def get_cloudwatch_alarms(region: str = "us-east-1") -> str:
    """
    Obtiene las alarmas de CloudWatch en estado ALARM.
    Útil para diagnosticar incidentes en curso.
    """
    cw = boto3.client("cloudwatch", region_name=region)
    response = cw.describe_alarms(StateValue="ALARM")
    alarmas = [a["AlarmName"] for a in response["MetricAlarms"]]
    return f"Alarmas activas: {', '.join(alarmas)}" if alarmas else "Sin alarmas activas"

# Agente de guardia que puede consultar runbooks Y el estado actual
agente_ops = Agent(
    system_prompt="""Sos el asistente de operaciones de turno.
    Antes de responder cualquier pregunta sobre incidentes,
    siempre consultá los runbooks internos y el estado de CloudWatch.""",
    tools=[buscar_runbook, get_cloudwatch_alarms]
)

agente_ops("Tenemos latencia alta en el servicio de pagos. ¿Qué deberíamos revisar?")

Integración con MCP (Model Context Protocol)

Strands tiene soporte nativo para MCP, lo que significa que podés conectar tu agente a miles de servidores MCP disponibles en la comunidad. Bases de datos, APIs de terceros, herramientas de monitoreo, todo sin escribir código de integración desde cero.

from strands import Agent
from strands.tools.mcp import MCPClient
from mcp import stdio_client, StdioServerParameters

# Conectar al servidor MCP de AWS (acceso a APIs de AWS via MCP)
aws_mcp = MCPClient(
    lambda: stdio_client(
        StdioServerParameters(command="uvx", args=["awslabs.aws-documentation-mcp-server@latest"])
    )
)

with aws_mcp as client:
    tools = client.list_tools_sync()
    agent = Agent(tools=tools)
    agent("¿Cuáles son los límites por defecto de Lambda en us-east-1?")

Deployment en Lambda o EKS

Para producción, Strands funciona sin problemas dentro de Lambda (para tareas cortas) o en un pod de EKS (para agentes de larga duración). También podés usar Bedrock AgentCore, el runtime managed de AWS para agentes, que soporta tareas de hasta 8 horas con gestión de estado incorporada.

# Wrapper mínimo para deployar en Lambda
import json
from strands import Agent
from strands.models import BedrockModel

model = BedrockModel(
    model_id="us.anthropic.claude-sonnet-4-5",
    region_name="us-east-1"
)

agent = Agent(
    model=model,
    system_prompt="Procesás consultas de infraestructura para el equipo de operaciones.",
    tools=[get_ec2_instances, get_cloudwatch_alarms]
)

def handler(event, context):
    query = event.get("query", "")
    response = agent(query)
    return {
        "statusCode": 200,
        "body": json.dumps({"response": str(response)})
    }

Multi-agentes: coordinación sin burocracia

Strands 1.0 introdujo cuatro primitivas para orquestar múltiples agentes. El patrón más usado es Agents-as-Tools: transformás agentes especializados en herramientas que un agente orquestador puede invocar.

from strands import Agent

# Agente especialista en seguridad
security_agent = Agent(
    system_prompt="Especialista en seguridad AWS. Analizás configuraciones, IAM policies y posibles vectores de ataque.",
    tools=[...herramientas de seguridad...]
)

# Agente especialista en costos
cost_agent = Agent(
    system_prompt="Especialista en optimización de costos AWS. Identificás recursos sobredimensionados y oportunidades de ahorro.",
    tools=[...herramientas de billing y Cost Explorer...]
)

# Orquestador: puede delegar en cualquiera de los dos
orchestrator = Agent(
    system_prompt="Coordinás análisis de infraestructura delegando tareas a especialistas según lo que se necesite.",
    tools=[
        security_agent.as_tool(
            tool_name="analizar_seguridad",
            tool_description="Analiza la postura de seguridad de un servicio o recurso AWS"
        ),
        cost_agent.as_tool(
            tool_name="analizar_costos",
            tool_description="Analiza costos y oportunidades de optimización"
        )
    ]
)

orchestrator("Hacé un análisis completo de nuestro entorno de producción en us-east-1")

✓ A2A Protocol

Strands 1.0 implementa el protocolo Agent-to-Agent (A2A), lo que permite que agentes de diferentes frameworks o equipos se descubran y comuniquen entre sí. Podés tener un agente Strands coordinando con un agente de otro framework sin escribir código de integración custom.

Casos de uso para equipos DevOps y AWS

Comparación honesta con los frameworks más usados

El ecosistema de frameworks para agentes explotó en 2025. Cada uno tiene su nicho, y en muchos casos se nota que fueron construidos para el ecosistema OpenAI o Azure, y después adaptados para soportar otros proveedores. Strands nació al revés: primero AWS, y después el resto. Esa diferencia de origen se siente en la práctica.

Strands vs LangGraph: velocidad vs control

LangGraph es potente, pero tiene un costo: te obliga a pensar en grafos, nodos y bordes antes de escribir una sola línea de lógica real. Para alguien que viene del mundo DevOps y quiere automatizar operaciones, ese modelo mental es una barrera de entrada importante. A eso sumale que la integración con AWS requiere configurar adaptadores extra, y que el stack de observabilidad (LangSmith) es un servicio aparte.

Strands te deja llegar al mismo resultado con mucho menos código. Si tu caso de uso es un workflow determinístico con lógica de negocio muy específica donde cada bifurcación importa, LangGraph tiene su lugar. Pero para la mayoría de los agentes operacionales que necesitan un equipo DevOps, la complejidad de LangGraph es overhead que no agrega valor.

Strands vs CrewAI: la trampa de los roles rígidos

CrewAI tiene una propuesta atractiva en papel: modelar el problema como un equipo con roles definidos. El problema es que en operaciones reales, los problemas no llegan etiquetados. Un incidente de producción puede requerir diagnóstico, análisis de costos, revisión de seguridad y comunicación al mismo tiempo, en un orden que no podés predecir. Forzar eso en roles fijos termina siendo una rigidez que juega en contra.

Además, CrewAI fue construido sin pensar en AWS. Conectarlo a tus servicios existentes requiere trabajo extra, y el modelo de costos se puede complicar rápido: un crew con 5 agentes puede costar hasta 5x más en tokens que un único agente Strands bien configurado.

🎯 Veredicto: si usás AWS, Strands es la respuesta obvia

Los otros frameworks no nacieron en AWS. Se adaptaron después, y esa diferencia se siente: configuraciones extra, adaptadores, integraciones parciales. Strands es lo contrario: boto3 funciona de entrada, Bedrock es el provider por defecto, y deployar en Lambda o EKS no requiere nada especial. Es el único framework que no te hace sentir que estás peleando contra tu propia infraestructura.

Para equipos DevOps que viven en AWS, la pregunta no debería ser "¿uso Strands o LangChain?". La pregunta es "¿para qué caso puntual podría necesitar más control del que Strands me da?". Y la respuesta honesta es: para la gran mayoría de casos operacionales, Strands alcanza y sobra.

Cosas a tener en cuenta antes de arrancar

Strands es sólido, pero como cualquier herramienta tiene sus particularidades. Mejor saberlas de antemano que descubrirlas en producción.

El modelo importa. La filosofía model-driven funciona muy bien con modelos modernos como Claude 4 en Bedrock. Si usás modelos más chicos o menos capaces, la calidad de razonamiento baja y el agente puede tomar decisiones subóptimas sobre qué herramienta usar. La buena noticia: en Bedrock tenés acceso a los mejores modelos del mercado con un par de líneas de configuración.

La observabilidad requiere un poco de setup. Strands soporta OpenTelemetry y se integra nativamente con CloudWatch, pero no viene con un dashboard listo para usar. Para producción, conviene invertir unas horas configurando trazas desde el día uno.

Es un framework joven. Con un año de vida pública, la comunidad externa está creciendo. La documentación oficial de AWS es muy buena, pero el volumen de respuestas en Stack Overflow todavía es menor que en frameworks más viejos. Eso va a cambiar rápido dado el ritmo de adopción.

Monitoreá el uso de tokens. Los agentes model-driven hacen más llamadas al LLM para razonar. En Bedrock podés configurar presupuestos y alertas de costo desde el día uno, así que esto es más un recordatorio de buenas prácticas que un problema real.

Conclusión

Strands es lo que pasa cuando el framework lo construye la misma gente que opera la infraestructura. No hay adaptadores, no hay workarounds para hacer que funcione con boto3 o Bedrock, no hay que elegir entre integración nativa y flexibilidad. Simplemente funciona, porque fue diseñado para funcionar así.

La apuesta de AWS con Strands es clara: que construir agentes de IA sobre AWS sea tan natural como construir cualquier otro servicio. Y en gran medida, lo lograron. La misma lógica que usaste para integrar Lambda con S3, o EKS con IAM, aplica para conectar un agente Strands con tus recursos existentes.

Si ya invertiste en el ecosistema AWS, Strands no es solo una opción más. Es el camino natural hacia agentes de IA en producción. Y con 14 millones de descargas en menos de un año y soporte activo del equipo de AWS, la apuesta tiene muy buenas chances de seguir madurando.

🔗 Recursos

Documentación oficial: strandsagents.com
GitHub Python SDK: github.com/strands-agents/sdk-python
Ejemplos y samples: github.com/strands-agents/samples
Bedrock AgentCore (runtime managed): AWS Console → Bedrock → AgentCore

AWS Bedrock incorpora este enfoque a través de las Knowledge Bases, una forma administrada de conectar documentos, embeddings y modelos de lenguaje sin tener que construir toda la infraestructura desde cero.

En este artículo vamos a recorrer, paso a paso, cómo crear una Knowledge Base usando documentación pública como ejemplo. No vamos a construir un asistente ni una aplicación final: el objetivo es entender el proceso completo, desde los documentos hasta la consulta en Bedrock.

Qué vamos a hacer

A lo largo del artículo vamos a:

• Extraer contenido limpio desde documentación técnica pública

• Almacenar esos documentos en Amazon S3

• Crear una Knowledge Base en Amazon Bedrock

• Sincronizar los documentos

• Probar consultas directamente desde la consola

Usaremos la documentación de Kubernetes únicamente como ejemplo, pero el mismo flujo aplica para:

• documentación interna

• manuales técnicos

• wikis

• guías operativas

• o cualquier conjunto de archivos de texto

Conceptos clave

Antes de avanzar, vale la pena aclarar algunos conceptos que vamos a usar durante el tutorial.

Amazon Bedrock

Amazon Bedrock es un servicio administrado de AWS que permite trabajar con modelos fundacionales (como Claude o Titan) sin necesidad de entrenarlos ni desplegarlos.

Entre otras cosas, Bedrock ofrece:

• gestión de modelos

• embeddings

• y Knowledge Bases, que es lo que vamos a usar acá

Knowledge Base en Bedrock

Una Knowledge Base es un recurso que conecta:

• documentos almacenados (por ejemplo, en S3)

• un modelo de embeddings

• un vector store

• y un modelo de lenguaje

El resultado es una base de conocimiento que puede responder preguntas usando exclusivamente los documentos que vos cargaste, con trazabilidad hacia las fuentes.

En este artículo vamos a crear la Knowledge Base y probarla desde la consola. La integración en una app o chatbot queda para más adelante.

Crawl4AI

Crawl4AI es una herramienta de scraping pensada específicamente para casos de uso con LLMs.

A diferencia de scrapers tradicionales, su foco está en:

• extraer solo el contenido principal

• eliminar navegación, footers y elementos visuales

• generar texto limpio en Markdown

Esto es clave cuando el destino final del contenido no es un humano, sino un sistema de embeddings.

Stack que vamos a usar

El stack es simple y económico:

• Crawl4AI – para extraer contenido limpio

• Amazon S3 – almacenamiento de documentos

• Amazon Bedrock Knowledge Bases – gestión del RAG

• S3 Vector Store – almacenamiento de embeddings

Parte 1: Setup del entorno

Pre-requisitos

• Python 3.11 o superior

• AWS CLI configurado

• Cuenta de AWS con acceso a Bedrock

Instalación de dependencias

mkdir scraper-kb-bedrock
cd scraper-kb-bedrock

python3 -m venv venv
source venv/bin/activate

pip install crawl4ai boto3 requests
playwright install

Configurar AWS CLI

aws configure

Configurar:

• Access Key

• Secret Key

• Región (ej: us-east-1)

Crear bucket S3

aws s3 mb s3://docs-kb-bedrock --region us-east-1

Este bucket va a contener los documentos que luego usará la Knowledge Base.

Parte 2: Descubrir URLs usando sitemaps

Para cargar documentos en una Knowledge Base primero necesitamos saber qué páginas existen.

Muchos sitios publican un sitemap, un archivo XML que lista todas las URLs disponibles.

En el caso de Kubernetes:

curl -s https://kubernetes.io/en/sitemap.xml | head

A partir de ese archivo podemos identificar secciones relevantes y decidir qué contenido usar.
Para este tutorial vamos a limitarnos a un conjunto pequeño de páginas, solo para demostrar el flujo completo.

Parte 3: Scraping controlado (10 páginas)

En lugar de scrapear cientos de URLs, vamos a hacer algo mucho más simple:
extraer 10 páginas reales, limpiarlas y subirlas a S3.

Esto es suficiente para:

• crear la Knowledge Base

• sincronizar documentos

• probar consultas en Bedrock

Script de scraping

import asyncio
import boto3
from crawl4ai import AsyncWebCrawler, CrawlerRunConfig

BUCKET = "docs-kb-bedrock"

URLS = [
    "https://kubernetes.io/docs/concepts/overview/",
    "https://kubernetes.io/docs/concepts/workloads/pods/",
    "https://kubernetes.io/docs/concepts/services-networking/service/",
    "https://kubernetes.io/docs/concepts/configuration/configmap/",
    "https://kubernetes.io/docs/concepts/workloads/controllers/deployment/",
    "https://kubernetes.io/docs/tasks/run-application/run-stateless-application-deployment/",
    "https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/",
    "https://kubernetes.io/docs/tutorials/kubernetes-basics/",
    "https://kubernetes.io/docs/setup/",
    "https://kubernetes.io/docs/reference/glossary/"
]

s3 = boto3.client("s3")

async def scrape():
    config = CrawlerRunConfig(
        excluded_tags=["nav", "footer", "header", "aside"],
        remove_overlay_elements=True,
        word_count_threshold=10
    )

    async with AsyncWebCrawler() as crawler:
        for url in URLS:
            result = await crawler.arun(url=url, config=config)
            if result.success:
                key = f"kubernetes/{url.split('/')[-2]}.md"
                s3.put_object(
                    Bucket=BUCKET,
                    Key=key,
                    Body=result.markdown.encode("utf-8")
                )
                print(f"Subido: {key}")

asyncio.run(scrape())

Este script:

• extrae contenido limpio

• lo guarda como Markdown

• lo sube a S3

Parte 4: Crear la Knowledge Base en Amazon Bedrock

A partir de este punto, todo se hace desde la consola de AWS.
Esta sección está pensada para acompañar con capturas de pantalla.

Crear la Knowledge Base

En la consola de Amazon Bedrock:

1. Ir a Knowledge bases

   

2. Crear una nueva Knowledge Base

1. Asignarle un nombre y descripción

1. Crear o reutilizar un rol de IAM

Configurar el data source

• Tipo: Amazon S3

• Ruta: el prefijo donde subiste los archivos (s3://docs-kb-bedrock/kubernetes/)

Bedrock va a leer automáticamente todos los documentos en ese path.

Embeddings y vector store

• Parser: default

  

• Chunking: default

• Embeddings: Amazon Titan Text Embeddings

• Vector store: Amazon S3

Con esta configuración no hace falta administrar bases vectoriales externas.

Sincronizar documentos

Una vez creada la Knowledge Base:

• iniciar el proceso de Sync

• esperar a que los documentos se procesen

• verificar que los chunks fueron generados correctamente

Parte 5: Probar la Knowledge Base

Desde la misma consola de Bedrock se puede probar la Knowledge Base sin escribir código.

Al hacer una consulta:

• el modelo responde usando los documentos cargados

• se muestran las fuentes utilizadas

• se puede validar que la información viene efectivamente de S3

Esto confirma que la Knowledge Base está funcionando correctamente.

Conclusión

En este artículo creamos una Knowledge Base completa en Amazon Bedrock partiendo únicamente de documentación en texto.

Sin entrenar modelos, sin manejar infraestructura compleja y usando servicios administrados, vimos cómo:

• preparar documentos

• almacenarlos correctamente

• convertirlos en una base consultable por IA

A partir de acá, esta Knowledge Base puede usarse como base para:

• asistentes conversacionales

• APIs internas

• herramientas de búsqueda semántica

• o sistemas de soporte basados en documentación

En próximos artículos, el foco estará en cómo consumir esta Knowledge Base desde aplicaciones reales.

En este artículo vamos a ver:

• ✅ Qué es AWS Nuke

• ✅ Para qué sirve (y para qué no)

• ✅ Cómo funciona internamente

• ✅ Ejemplos de uso reales

• ✅ Buenas prácticas y advertencias

¿Qué es AWS Nuke?

AWS Nuke es una herramienta open source creada por Rebuy que permite eliminar casi todos los recursos de una cuenta de AWS de forma automática.

👉 En pocas palabras:

AWS Nuke destruye una cuenta de AWS para dejarla totalmente limpia.

Funciona vía AWS APIs y es capaz de borrar:

• EC2, EBS, AMIs

• S3 buckets

• RDS, DynamoDB

• Lambda

• API Gateway

• EKS / ECS

• CloudWatch

• IAM roles (no root)

• Y muchos más

¿Por qué existe AWS Nuke?

Porque AWS NO tiene un botón de “delete everything”.

Usos típicos:

• Cuentas sandbox descartables

• Ambientes de testing automatizado

• Laboratorios de training

• Reset completo antes de reutilizar una cuenta

• CI/CD que crea infraestructura efímera

¿Qué NO es AWS Nuke?

❌ No es una herramienta de limpieza selectiva
❌ No es para producción
❌ No es “terraform destroy”
❌ No tiene rollback

💡 Si lo ejecutás mal, perdés la cuenta completa (datos incluidos).

Cómo funciona AWS Nuke

El flujo general es:

1. Se conecta a una cuenta AWS usando credenciales

2. Lista todos los recursos soportados

3. Aplica filtros y exclusiones

4. Elimina recurso por recurso

5. Reintenta hasta que no queda nada

⚠️ Algunos recursos requieren múltiples pasadas (por dependencias).

Instalación de AWS Nuke

Opción 1: Binario

brew install aws-nuke

o descargando el binario desde GitHub.

Opción 2: Docker (muy recomendado)

docker run --rm -it \
  -v $(pwd)/config.yml:/config.yml \
  quay.io/rebuy/aws-nuke:v2.25.0 \
  aws-nuke -c /config.yml --dry-run

Archivo de configuración (config.yml)

Ejemplo básico:

regions:
  - us-east-1
  - global

account-blocklist:
  - "123456789012" # Cuenta productiva (NUNCA NUKLEAR)

accounts:
  "111111111111":
    filters:
      IAMUser:
        - "admin"

🔎 Conceptos clave del config

✅ regions

Define dónde buscar y borrar recursos.

✅ account-blocklist

Crítico. Obligatorio.
Previene nukear cuentas prohibidas.

✅ Best practice: incluir SIEMPRE la cuenta root y producción.

Dry Run (modo seguro)

Antes de ejecutar nada:

aws-nuke -c config.yml --dry-run

Este modo:

• No elimina nada

• Muestra exactamente qué se borraría

• Es obligatorio correrlo siempre

💡 Nunca ejecutes AWS Nuke en modo activo sin un dry-run previo.

Ejemplo 1: Limpiar una cuenta sandbox

Caso típico:

• Developers prueban cosas

• Recursos quedan colgados

• Costos innecesarios

Config simple:

regions:
  - us-east-1
  - global

account-blocklist:
  - "999999999999"

accounts:
  "111111111111": {}

Ejecución real:

aws-nuke -c config.yml --no-dry-run

Resultado:
✅ Cuenta completamente vacía
✅ Lista para reutilizar

Ejemplo 2: Integración con CI/CD

Uso común:

• Pipeline crea una cuenta temporal

• Ejecuta tests

• Al final → nuke automático

Ejemplo en pipeline:

aws-nuke -c config.yml --force --no-dry-run

Flags importantes:

• --force: no pide confirmación interactiva

• --no-dry-run: ejecuta de verdad

⚠️ Usar solo en cuentas descartables.

Ejemplo 3: Training y workshops

En workshops:

• Cada alumno tiene su cuenta

• Al finalizar el día → reset total

AWS Nuke permite:

• Evitar costos residuales

• Reutilizar cuentas para el próximo grupo

• Garantizar entorno limpio

Filtros y exclusiones

AWS Nuke NO puede borrar todo (ej: root user), pero sí casi todo.

Ejemplo: proteger un bucket específico

accounts:
  "111111111111":
    filters:
      S3Bucket:
        - "important-logs-bucket"

Seguridad y buenas prácticas

✅ Usar siempre:

• SCPs que bloqueen AWS Nuke en prod

• account-blocklist

• Dry run obligatorio

✅ Ejecutar desde:

• Cuenta de seguridad

• Rol dedicado

• Pipeline controlado

❌ Nunca:

• Ejecutar manualmente “por las dudas”

• Usar en prod

• Omitir blocklist

AWS Nuke + SCPs (combinación ideal)

Una muy buena práctica es:

• ✅ SCP bloquea acciones destructivas en prod

• ✅ AWS Nuke solo funciona en:

  • Sandbox

  • Dev

  • Accounts efímeras

Esto alinea perfecto con:

• AWS CAF

• Control preventivo

• Gobierno organizacional

Conclusión

AWS Nuke es una motosierra.

En manos correctas:
✅ Ahorra tiempo
✅ Reduce costos
✅ Automatiza limpieza

En manos incorrectas:
💥 Destrucción total

Si trabajás con AWS a escala, AWS Nuke no es opcional, pero el gobierno sí es obligatorio.

Durante años, los desarrolladores en el ecosistema de AWS han enfrentado una disyuntiva difícil. O elegías la simplicidad operativa de AWS Lambda (el famoso "code-and-go"), o elegías Amazon EC2 para acceder a hardware especializado y modelos de precios más económicos.

Si necesitabas arquitecturas de CPU específicas o querías aprovechar los Compute Savings Plans para cargas de trabajo constantes, a menudo tenías que sacrificar la facilidad de Lambda y asumir la carga de gestionar la infraestructura.

Hoy, ese compromiso se acaba.

AWS ha anunciado Lambda Managed Instances, una nueva capacidad que te permite ejecutar funciones Lambda en instancias EC2, mientras AWS se encarga del trabajo pesado.

¿Qué es AWS Lambda Managed Instances?

En pocas palabras, esta función te permite definir cómo se ejecutan tus funciones Lambda en instancias EC2, sin obligarte a gestionar esas instancias tú mismo.

AWS sigue encargándose de la complejidad operativa: gestión del ciclo de vida, parches del sistema operativo, balanceo de carga y auto-escalado. Tú obtienes el acceso a los perfiles de cómputo especializados que necesitas.

¿Cómo funciona? El "Capacity Provider"

El mecanismo central detrás de esta característica es el Capacity Provider. En lugar de simplemente desplegar una función, configuras este proveedor donde especificas:

• Configuración de Red: La VPC, subnets y grupos de seguridad.

• Selección de Instancia: Tipos específicos de EC2 (o una mezcla para diversidad), incluyendo acceso a AWS Graviton4.

• Controles de Escalado: Cantidad máxima de vCPUs y políticas de escalado.

Una vez configurado, simplemente adjuntas tu función Lambda a este Capacity Provider mediante su ARN.

Las Ventajas Clave

1. Fin de los "Cold Starts": Las peticiones se enrutan a entornos de ejecución pre-aprovisionados, eliminando la latencia de espera a que el código "despierte".

2. Control de Hardware: Acceso a requisitos específicos como redes de alto ancho de banda o arquitecturas de CPU concretas.

3. Experiencia Serverless: No necesitas configurar balanceadores de carga ni escribir políticas complejas de auto-scaling.

4. Optimización de Costos: Aquí cambia la economía. Puedes aplicar modelos de precios basados en compromisos de EC2 (Savings Plans y Reserved Instances) a tus cargas de trabajo Lambda.

⚠️ Advertencia Crítica para Desarrolladores: Thread Safety

Uno de los cambios técnicos más significativos es la Multiconcurrencia. A diferencia de las funciones Lambda estándar, donde un entorno de ejecución maneja una sola petición a la vez, las Managed Instances permiten que un solo entorno procese múltiples peticiones simultáneamente.

Esto maximiza el uso de recursos, pero implica un riesgo: tu código debe ser "Thread-Safe" (seguro para hilos).

Antes de migrar, debes revisar tu código en busca de:

• Archivos: Escrituras en rutas de archivo que no sean únicas por petición (cuidado con /tmp si no usas nombres aleatorios).

• Memoria: Espacios de memoria compartida o variables globales que cambien de estado entre invocaciones.

El Nuevo Modelo de Precios

La estructura de precios es distinta a la de Lambda estándar y se compone de tres partes:

1. Cargo por Petición Estándar: Pagas la tarifa habitual de Lambda ($0.20 por millón de invocaciones).

2. Cargos de Instancia EC2: Pagas por la capacidad de cómputo provisionada. Crucialmente, aquí es donde puedes aplicar descuentos de hasta un 72% con Savings Plans.

3. Tarifa de Gestión (Management Fee): Una tarifa del 15% calculada sobre el precio On-Demand de la instancia EC2 para cubrir la gestión operativa de AWS.

Dato importante: A diferencia del Lambda tradicional, no se te cobra por separado por la duración de la ejecuciónpor petición. Esto hace que Managed Instances sea altamente atractivo para cargas de trabajo de alto tráfico y estado constante (steady-state).

Disponibilidad

El servicio ya está disponible en las regiones de US East (N. Virginia & Ohio), US West (Oregon), Asia Pacific (Tokyo) y Europe (Ireland). Actualmente soporta las últimas versiones de Node.js, Java, .NET y Python.

Conclusión

Este lanzamiento representa un cambio masivo en cómo arquitectamos aplicaciones serverless. Es la victoria definitiva para las cargas de trabajo constantes: eliminas los arranques en frío y finalmente puedes aplicar grandes descuentos de EC2 a tu factura serverless.

Si tienes procesos pesados donde Lambda era demasiado caro o poco potente, es hora de probar Managed Instances.

Fuente y más información técnica en el anuncio oficial: AWS Blog - Introducing AWS Lambda Managed Instances

Además, las SCPs juegan un rol fundamental dentro del AWS Cloud Adoption Framework (CAF), específicamente en el dominio de Seguridad, ayudando a implementar gobierno, control preventivo y seguridad por diseño.

¿Qué son las SCP (Service Control Policies)?

Las Service Control Policies permiten definir guardrails obligatorios que determinan qué acciones pueden o no ejecutarse dentro de una cuenta de AWS, sin importar los permisos IAM configurados.

✅ Se aplican a nivel Organización / OU / Cuenta
✅ No otorgan permisos, solo los restringen
✅ Afectan a usuarios, roles y root
✅ Son evaluadas antes que IAM

Concepto clave:

Una SCP define el límite máximo de lo que una cuenta puede hacer.

Relación entre SCPs e IAM

El modelo mental correcto es:

SCP (Organizations)
   ↓
IAM Policies (Account)
   ↓
Permiso final efectivo

Aunque una IAM policy permita una acción, si la SCP la niega, la acción jamás se ejecuta.

SCPs y el AWS Cloud Adoption Framework (CAF)

Dentro del AWS CAF, las SCPs impactan directamente en el pilar de Seguridad, principalmente en:

• Preventive Controls

• Identity and Access Management

• Governance

• Cost Control (shared responsibility)

Las SCPs permiten aplicar controles preventivos, evitando incidentes antes de que ocurran, en lugar de detectarlos después.

🧱 SCP #1 — Identity Guardrails

🏷️ Name

identity-guardrails

📝 Description

Prevent IAM users and access keys creation. Enforce IAM Identity Center usage.

🎯 Objetivo

Forzar un modelo moderno y seguro de identidad:

• ❌ No más usuarios IAM

• ❌ No más access keys permanentes

• ✅ Solo IAM Identity Center (SSO) y roles temporales

📄 Policy (JSON)

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyIAMUserAndAccessKeyManagement",
      "Effect": "Deny",
      "Action": [
        "iam:CreateUser",
        "iam:DeleteUser",
        "iam:CreateAccessKey",
        "iam:UpdateAccessKey",
        "iam:DeleteAccessKey"
      ],
      "Resource": "*"
    }
  ]
}

✅ Alineación CAF – Seguridad

• Identity & Access Management

• Least Privilege

• Preventive Controls

🧱 SCP #2 — Region Guardrails

🏷️ Name

region-guardrails

📝 Description

Restrict AWS usage to approved regions only.

🎯 Objetivo

Evitar:

• Recursos creados en regiones no aprobadas

• Costos inesperados

• Problemas de compliance

✅ Solo us-east-1 permitido

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyAllRegionsExceptUSEast1",
      "Effect": "Deny",
      "NotAction": [
        "account:*",
        "billing:*",
        "iam:*",
        "organizations:*",
        "support:*"
      ],
      "Condition": {
        "StringNotEquals": {
          "aws:RequestedRegion": "us-east-1"
        }
      },
      "Resource": "*"
    }
  ]
}

✅ Alineación CAF – Seguridad

• Governance

• Compliance

• Data residency controls

🧱 SCP #3 — Root Guardrails

🏷️ Name

root-guardrails

📝 Description

Deny root account usage except for billing and support operations.

🎯 Objetivo

Eliminar el uso operativo del usuario root.

📄 Policy (JSON)

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyRootAccountUsage",
      "Effect": "Deny",
      "Condition": {
        "StringLike": {
          "aws:PrincipalArn": "arn:aws:iam::*:root"
        }
      },
      "NotAction": [
        "account:*",
        "billing:*",
        "payments:*",
        "support:*",
        "tax:*"
      ],
      "Resource": "*"
    }
  ]
}

✅ Alineación CAF – Seguridad

• Account Protection

• Identity Hardening

• Blast Radius Reduction

🧱 SCP #4 — Cost Explosion Prevention ✅

🏷️ Name

cost-explosion-prevention

📝 Description

Prevent cost explosions by blocking high-cost EC2 instances, uncontrolled Auto Scaling, and Lambda functions without concurrency limits.

📄 Policy (JSON)

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyHighCostEC2InstanceTypes",
      "Effect": "Deny",
      "Action": "ec2:RunInstances",
      "Condition": {
        "ForAnyValue:StringLike": {
          "ec2:InstanceType": [
            "p*",
            "g*",
            "inf*",
            "trn*",
            "hpc*"
          ]
        }
      },
      "Resource": "*"
    },
    {
      "Sid": "LimitAutoScalingCapacity",
      "Effect": "Deny",
      "Action": [
        "autoscaling:SetDesiredCapacity",
        "autoscaling:UpdateAutoScalingGroup"
      ],
      "Condition": {
        "NumericGreaterThan": {
          "autoscaling:DesiredCapacity": "5"
        }
      },
      "Resource": "*"
    },
    {
      "Sid": "RequireLambdaConcurrencyLimit",
      "Effect": "Deny",
      "Action": [
        "lambda:CreateFunction",
        "lambda:UpdateFunctionConfiguration"
      ],
      "Condition": {
        "Null": {
          "lambda:ReservedConcurrentExecutions": "true"
        }
      },
      "Resource": "*"
    }
  ]
}

✅ Alineación CAF – Seguridad

• Financial Governance

• Preventive Technical Controls

• Shared Responsibility (Security & Cost)

¿Dónde aplicar estas SCPs?

📸 (ACÁ PONER CAPTURA — Organizational Units con SCPs asociadas)

Ejemplo recomendado:

Root OU
 ├─ Security
 ├─ Shared-Services
 ├─ Production
 └─ Sandbox

Conclusión

Las Service Control Policies no solo refuerzan la seguridad técnica, sino que también:

• ✅ Alinean la cuenta con el AWS CAF

• ✅ Implementan controles preventivos reales

• ✅ Reducen riesgos técnicos y financieros

• ✅ Profesionalizan el gobierno de AWS

En AWS, la seguridad madura empieza por los guardrails.

La plataforma aborda una limitación fundamental: los agentes de IA son sin estado por defecto, olvidando todo entre conversaciones. Mientras las empresas dependen cada vez más de IA para soporte al cliente y automatización de ventas, las soluciones tradicionales—PostgreSQL o almacenes vectoriales—fallan en capturar la naturaleza dinámica de las interacciones empresariales reales. Zep resuelve esto a través de su "ingeniería de contexto", ensamblando sistemáticamente contexto personalizado desde preferencias de usuario, datos empresariales y conversaciones evolutivas.

Qué hace a Zep fundamentalmente diferente

Los enfoques tradicionales tratan la información como capturas estáticas. Los grafos de conocimiento temporales de Zep entienden que la información empresarial es dinámica e interconectada. Cuando un cliente cambia preferencias o reporta problemas, Zep no solo añade nueva información—entiende estos cambios en contexto, manteniendo relaciones históricas mientras presenta la realidad actual.

El motor Graphiti (con más de 14,000 estrellas en GitHub) potencia esta capacidad a través de modelado bi-temporal. Esto rastrea tanto cuándo ocurrieron los eventos como cuándo el sistema se enteró de ellos, habilitando razonamiento sofisticado sobre causa y efecto.

La ingeniería de contexto emerge como la innovación central de Zep—yendo más allá de la simple ingeniería de prompts para ensamblar sistemáticamente información relevante en prompts optimizados. Esto reduce alucinaciones, mejora la precisión y disminuye dramáticamente los costos computacionales usando menos del 2% de los tokens requeridos por enfoques tradicionales.

Potenciando PostgreSQL: superando limitaciones tradicionales

PostgreSQL con pgvector sobresale en almacenamiento vectorial estructurado pero, usado directamente, carece del razonamiento temporal que los agentes de IA necesitan. Los desarrolladores que implementan memoria de IA sobre PostgreSQL enfrentan consultas complejas para reconstruir contexto, mapeo manual de relaciones, y ningún entendimiento nativo de cómo evoluciona la información a través del tiempo.

Zep proporciona APIs optimizadas para agentes con rendimiento sub-200ms específicamente diseñadas para IA conversacional. Los grafos temporales rastrean automáticamente relaciones de entidades—clientes conectan con tickets de soporte, que se vinculan a problemas de producto—sin diseño manual.

Las diferencias de rendimiento son significativas: mientras implementaciones directas sobre PostgreSQL requieren historiales completos (115k+ tokens), las capas de abstracción de Zep comprimen esto en bloques enfocados promediando 1.6k tokens con precisión superior. Esto significa ahorros dramáticos para empresas ejecutando agentes de IA a escala.

Visualización de relaciones y datos de usuario

Zep ofrece herramientas de visualización que revelan patrones ocultos en comportamiento de usuario. La plataforma construye automáticamente relaciones—clientes se conectan a preferencias, historial de compras, interacciones de soporte—creando una vista comprensiva del viaje de cada usuario.

El dashboard de visualización permite explorar conexiones interactivamente, rastreando evolución de preferencias, identificando patrones, y entendiendo flujos temporales. Esto es valioso para equipos de ventas, soporte y producto analizando comportamientos sin análisis manual.

Las características avanzadas incluyen algoritmos de detección de comunidades que agrupan entidades relacionadas, ayudando a identificar segmentos de clientes y patrones de interacción. El modelado bi-temporal preserva auditorías completas, crucial para cumplimiento y análisis estratégico.

Casos de uso transformadores

Zep habilita aplicaciones de IA previamente imposibles. Los agentes de soporte acceden a historial completo entendiendo cambios de contexto—cuándo cambió el estado de cuenta, nivel de satisfacción, o necesidades de producto. Esto transforma interacciones genéricas en experiencias personalizadas.

La automatización de ventas se vuelve más efectiva cuando agentes recuerdan preferencias de prospectos y entienden dinámicas de relación. Los agentes potenciados por Zep construyen perfiles que evolucionan con cada interacción.

Las aplicaciones de inteligencia empresarial aprovechan Graph RAG para conectar fuentes dispares—CRM, tickets, facturación—en grafos unificados que revelan insights invisibles. Esto habilita responder preguntas complejas traversando relaciones entre sistemas.

Integración perfecta con n8n

Los usuarios de n8n obtienen memoria sofisticada través del nodo Zep, habilitando automatización visual con memoria persistente. La integración soporta múltiples modos: recuperar documentos, insertar nuevos, y conectar memoria a herramientas de IA—todo mediante arrastrar y soltar.

Patrones comunes incluyen flujos donde tickets disparan búsquedas de memoria y respuestas personalizadas basadas en historial completo. Los pipelines de leads acceden a historial de interacción y puntúan oportunidades con contexto comprensivo.

Las librerías de plantillas proporcionan valor inmediato con más de 200 plantillas de IA incorporando patrones Zep, cubriendo memoria multicanal, sistemas RAG, y campañas que mantienen contexto a través de múltiples touchpoints.

Capacidades técnicas clave

La arquitectura se centra en tres innovaciones: memoria episódica que preserva interacciones originales, extracción semántica que identifica conceptos relacionados, y subgrafos de comunidad para entendimiento de alto nivel.

Clasificación automática y extracción de entidades operan transparentemente, identificando personas, organizaciones, productos y eventos sin configuración manual. Las capacidades de clasificación de diálogocategorizan conversaciones por intención, sentimiento y tópico.

Las características de rendimiento son listas para empresa con latencia P95 bajo 300ms para operaciones complejas, escalando para alta concurrencia mientras mantiene tiempos consistentes.

Ventajas de rendimiento comprobadas

Los benchmarks demuestran superioridad técnica: en Deep Memory Retrieval, Zep logra 94.8% versus 93.4% de MemGPT. En LongMemEval, Zep entrega hasta 18.5% mejoras de precisión reduciendo latencia 90%.

La eficiencia de tokens representa ventaja mayor: donde enfoques tradicionales consumen 115,000 tokens, Zep logra precisión superior usando solo 1,600 tokens promedio. Para empresas procesando miles de interacciones diarias, esto significa ahorros sustanciales de API LLM.

La búsqueda híbrida combina similaridad semántica, matching de palabras clave y traversal de grafo en operaciones únicas, proporcionando capacidades que bases vectoriales tradicionales no pueden igualar.

Ventajas competitivas

Versus MemGPT/Letta: Zep ofrece servicios gestionados listos para producción versus proyectos de investigación. Mientras MemGPT requiere gestión manual, Zep opera automáticamente.

Versus bases vectoriales tradicionales: Pinecone o Weaviate sobresalen en similaridad semántica pero carecen de modelado temporal. Zep entiende relaciones que evolucionan, habilitando razonamiento multi-hop imposible solo con vectores.

Versus PostgreSQL directo: Zep proporciona APIs optimizadas construidas sobre PostgreSQL + pgvector con rendimiento sub-100ms, eliminando la necesidad de joins costosos y consultas complejas que requieren las implementaciones directas.

Preparación empresarial

Credenciales empresariales incluyen certificación SOC 2 Type II, acuerdos HIPAA, y herramientas GDPR incluyendo "Derecho al Olvido". La plataforma ofrece servicios de nube gestionados y despliegue auto-hospedado.

La estructura de precios escala con crecimiento, desde niveles gratuitos para desarrollo hasta acuerdos empresariales. El modelo cobra solo por mensajes procesados—no almacenamiento—alineando costos con uso real.

El ecosistema demuestra adopción fuerte con SDKs comprensivos (Python, TypeScript, Go), documentación extensa, y 25,000 descargas semanales de PyPI. El equipo respaldado por Y Combinator alcanzó $1M de ingresos en 2024 con cinco personas.

Desplegando Zep en Kubernetes: Una Guía Completa

Para organizaciones que buscan implementar Zep en infraestructura empresarial, el despliegue en Kubernetes proporciona escalabilidad, alta disponibilidad y gestión simplificada. La arquitectura de Zep en Kubernetes se compone de múltiples componentes interconectados que trabajan juntos para proporcionar una plataforma de memoria robusta para agentes de IA.

📁 Repositorio completo disponible: https://github.com/MatiasMartinez90/zep-k8s

Arquitectura del Despliegue

El despliegue de Zep en Kubernetes incluye los siguientes componentes principales:

• Zep App: La aplicación principal que expone las APIs y la interfaz web

• Zep NLP Server: Servidor especializado para procesamiento de lenguaje natural

• PostgreSQL con pgvector: Base de datos optimizada para almacenamiento vectorial

• Ingress Controller: Para gestión de tráfico y certificados SSL/TLS

Componentes de los Manifiestos

1. Namespace y Organización (01-namespace.yaml)

yaml

apiVersion: v1
kind: Namespace
metadata:
  name: zep

Este manifiesto crea un namespace dedicado llamado zep que aísla todos los recursos relacionados con Zep del resto del cluster. Los namespaces en Kubernetes proporcionan separación lógica y facilitan la gestión de recursos, políticas de seguridad y cuotas.

2. Gestión de Secretos (02-secrets.yaml)

Los secretos manejan información sensible de manera segura:

Secret de Base de Datos:

• Almacena la cadena de conexión DSN a PostgreSQL

• Incluye credenciales de autenticación encriptadas

• Permite rotación de credenciales sin reconstruir contenedores

Secret de Configuración de Zep:

• Contiene la API key de OpenAI para servicios de embeddings

• Incluye el secreto de autenticación interno de Zep

• Mantiene las claves sensibles separadas del código

3. Configuración de Base de Datos Externa (03-pgvector-*.yaml)

Estos archivos proporcionan dos enfoques para conectar con PostgreSQL:

Endpoint Externo (03-pgvector-endpoint.yaml):

• Define un endpoint manual a una instancia PostgreSQL externa

• Útil cuando se conecta a bases de datos en Docker Swarm o infraestructura externa

• Especifica IP y puerto directamente

Service External Name (03-pgvector-service.yaml):

• Utiliza el tipo ExternalName para referenciar servicios externos

• Proporciona resolución DNS automática

• Más flexible para entornos con DNS dinámico

4. Configuraciones de Aplicación (04-configmaps.yaml)

Los ConfigMaps definen configuraciones no sensibles:

Variables de Entorno:

• ZEP_STORE_TYPE: Especifica PostgreSQL como almacén de datos

• ZEP_NLP_SERVER_URL: URL del servidor NLP interno

• ZEP_LOG_LEVEL: Nivel de logging para debugging

• Configuraciones de embeddings para OpenAI

Archivo de Configuración:

• Archivo config.yaml completo montado como volumen

• Configuración estructurada para todos los componentes

• Permite modificación sin reconstruir imágenes

5. Almacenamiento Persistente (06-zep-pvc.yaml, 07-pgvector-deployment.yaml)

PVC de Configuración:

• Almacenamiento opcional para configuraciones personalizadas

• Utiliza nfs-dynamic como storage class por defecto

• 1Gi de capacidad para archivos de configuración

PostgreSQL con pgvector:

• Deployment completo de PostgreSQL con extensión vectorial

• PVC de 2Gi para datos persistentes

• Variables de entorno para configuración de base de datos

• Service ClusterIP para acceso interno

6. Aplicación Principal de Zep (08-zep-deployment.yaml)

Características del Deployment:

• Imagen oficial ghcr.io/getzep/zep:latest

• Puerto 8000 para API y interfaz web

• Variables de entorno desde ConfigMaps y Secrets

• Montaje de archivo de configuración personalizado

• Recursos comentados para ajuste según necesidades

Configuración de Seguridad:

• Separación de variables sensibles y no sensibles

• Referencias a Secrets para credenciales

• Configuración desde ConfigMaps para parámetros operacionales

7. Servidor NLP de Zep (09-zep-nlp-deployment.yaml)

Especializaciones del NLP Server:

• Imagen dedicada ghcr.io/getzep/zep-nlp-server:latest

• Puerto 5557 para comunicación interna

• Recursos específicos para procesamiento NLP

• Tolerations para scheduling en nodos master

Requisitos de Recursos:

• CPU: 200m request, 500m limit

• Memoria: 512Mi request, 1Gi limit

• Optimizado para cargas de trabajo de ML

8. Servicios de Red (10-zep-services.yaml)

Service de Aplicación:

• Tipo ClusterIP para acceso interno

• Puerto 8000 mapeado al contenedor

• Selector específico para pods de aplicación

Service NLP:

• Puerto 5557 para comunicación inter-componente

• ClusterIP para acceso interno exclusivo

• Separación de concerns de red

9. Ingress y Exposición Externa (11-zep-ingress.yaml)

Configuración de Traefik:

• Ingress class traefik para routing

• TLS automático con cert-manager

• Certificados Let's Encrypt para HTTPS

Características de Seguridad:

• Terminación TLS en el edge

• Certificados automáticos renovables

• Dominio personalizable (devzep.cloudacademy.ar)

Script de Despliegue Automatizado

El script deploy-zep.sh automatiza el proceso completo:

1. Creación de Namespace: Aislamiento de recursos

2. Aplicación de Secrets: Configuración segura de credenciales

3. ConfigMaps: Despliegue de configuraciones

4. PVC: Provisión de almacenamiento persistente

5. NLP Server: Despliegue del componente de procesamiento

6. Aplicación Principal: Despliegue de la API y UI

7. Servicios: Configuración de red interna

8. Ingress: Exposición externa con HTTPS

Verificación y Monitoreo

Después del despliegue, el script proporciona comandos para verificación:

bash

# Estado de pods
kubectl get pods -n zep

# Servicios y endpoints
kubectl get svc -n zep

# Ingress y certificados
kubectl get ingress -n zep

# Logs para debugging
kubectl logs -f deployment/zep-app -n zep
kubectl logs -f deployment/zep-nlp -n zep

Consideraciones de Producción

Recursos y Escalabilidad:

• Los límites de recursos están comentados para personalización

• Considerar HPA (Horizontal Pod Autoscaler) para alta demanda

• Monitoreo de métricas de rendimiento de PostgreSQL

Seguridad:

• Rotación regular de secrets

• Network policies para aislamiento de tráfico

• Scanning de vulnerabilidades en imágenes

Backup y Recuperación:

• Estrategia de backup para PVC de PostgreSQL

• Procedimientos de disaster recovery

• Testing regular de restauración

Networking:

• Configuración de DNS interno optimizada

• Políticas de red para micro-segmentación

• Load balancing para múltiples réplicas

Este despliegue en Kubernetes proporciona una base sólida para implementar Zep en producción, combinando la potencia de la plataforma de memoria con la robustez y escalabilidad de Kubernetes.

Conclusión

Zep representa un avance fundamental en memoria de agentes de IA, yendo más allá del almacenamiento estático a grafos de conocimiento dinámicos. Para organizaciones usando n8n, Zep proporciona la capa de memoria que transforma agentes genéricos en asistentes personalizados capaces de razonamiento empresarial sofisticado.

La combinación de innovación técnica, mejoras probadas, e infraestructura empresarial posiciona a Zep como la solución líder para despliegue serio de agentes de IA. Con integración perfecta con n8n, despliegue robusto en Kubernetes, y resultados demostrados, Zep habilita construir experiencias de IA inteligentes que los clientes modernos esperan mientras mantienen estándares de seguridad empresarial.

La inversión en capacidades de memoria de Zep paga dividendos a través de mejor satisfacción de cliente, eficiencia operacional, y ventaja competitiva en un panorama empresarial cada vez más impulsado por IA. El despliegue en Kubernetes asegura que estas capacidades puedan escalar con las necesidades empresariales, proporcionando una plataforma confiable y mantenible para el futuro de la IA empresarial.

¿Qué es SetupOrion?

SetupOrion es un auto-instalador completamente gratuito desarrollado por OrionDesign que simplifica la instalación de las principales herramientas del mercado de automatización, marketing e inteligencia artificial. Con más de 70 aplicaciones disponibles, este setup elimina la complejidad técnica que tradicionalmente requiere configurar un stack completo de herramientas para IA y automatización.

El proyecto brasileño se ha convertido en una solución indispensable para quienes buscan experimentar y desarrollar con herramientas como N8N, agentes de IA, bases de datos vectoriales y mucho más, sin necesidad de convertirse en expertos en DevOps.

Herramientas Destacadas para IA y Automatización

Automatización y Workflows

• N8N: La plataforma principal para crear workflows de automatización complejos, conectar APIs y orquestar procesos

• Traefik & Portainer: Gestión de contenedores y proxy reverso para un despliegue profesional

Inteligencia Artificial y Memoria

• ZEP: Plataforma de ingeniería de contexto para agentes de IA que transforma conversaciones y datos empresariales en un grafo de conocimiento evolutivo

• Qdrant: Base de datos vectorial de alto rendimiento para búsquedas semánticas y sistemas RAG

• Ollama: Ejecuta modelos de IA localmente de forma eficiente

Herramientas de Soporte para IA

• RabbitMQ: Sistema de mensajería para comunicación asíncrona entre servicios de IA

• MinIO: Almacenamiento de objetos compatible con S3, ideal para datasets y modelos

• Cal.com: Sistema de programación que se integra perfectamente con chatbots y agentes

• Bolt: Herramienta de desarrollo con IA similar a v0, para generar aplicaciones web rápidamente

Utilidades Empresariales

• Keycloak: Gestión de identidad y acceso para aplicaciones

• VaultWarden: Gestor de contraseñas auto-hospedado

• Uptime Kuma: Monitoreo de servicios y aplicaciones

• Moodle: Plataforma de aprendizaje que se puede integrar con sistemas de IA

Requisitos del Sistema

Para aprovechar al máximo SetupOrion, necesitas:

Requisitos mínimos:

• Ubuntu 20.04 o 22.04

• 4GB de RAM

• 2 vCPUs

• Servidor completamente vacío

Requisitos recomendados:

• 8GB de RAM

• 4 vCPUs

• Para un rendimiento óptimo con las herramientas más populares

Opción Económica para Pruebas

Si quieres probar SetupOrion sin una gran inversión inicial, puedes usar este VPS barato que encontré: Contabo, que ofrece excelente relación precio-rendimiento para probar estas herramientas.

Importante: El servidor debe estar completamente vacío, ya que SetupOrion realiza configuraciones profundas que podrían conflictuar con instalaciones existentes, para algo más estable mejor instalar en AWS.

Instalación Paso a Paso en EC2

Paso 1: Preparación del Servidor

1. Lanza una instancia EC2 con Ubuntu 20.04

2. Configura los grupos de seguridad para permitir tráfico HTTP (80) y HTTPS (443)

3. Conecta via SSH a tu instancia

Paso 2: Ejecutar SetupOrion

Ejecuta este comando único en tu terminal SSH:

bash <(curl -sSL setup.oriondesign.art.br)

El script automáticamente:

• Actualiza el sistema

• Instala dependencias necesarias

• Descarga y ejecuta SetupOrion

• 

Paso 3: Instalación de Traefik y Portainer (Base del Sistema)

SetupOrion comenzará instalando los componentes fundamentales:

1. Configuración inicial del servidor:

   • Update del sistema

   • Instalación de herramientas básicas

   • Configuración de timezone y hostname

2. Instalación de Docker Swarm:

   • Configuración automática del orquestador

   • Creación de red interna

3. Despliegue de Traefik:

   • Proxy reverso para gestión de dominios

   • Configuración SSL automática

4. Instalación de Portainer:

   • Interface web para gestión de contenedores

   • Configuración de usuario administrador

Paso 4: Configuración de Dominios

Para cada herramienta que instales, necesitarás configurar subdominios apuntando a la IP pública de tu instancia EC2. Por ejemplo:

• portainer.tudominio.com

• n8n.tudominio.com

• qdrant.tudominio.com

Puedes usar cualquier proveedor DNS (Cloudflare recomendado pero no obligatorio).

Paso 5: Instalación de N8N y Herramientas de IA

Una vez completada la base, selecciona N8N del menú:

1. Ingresa el dominio para N8N (ej: n8n.tudominio.com)

2. El sistema configurará automáticamente:

   • Contenedor Docker optimizado

   • Integración con Traefik

   • SSL automático

   • Variables de entorno necesarias

Repite el proceso para otras herramientas como Qdrant, Ollama, ZEP, etc.

Casos de Uso Prácticos

Automatización de Procesos de Negocio

Combina N8N con Cal.com para crear sistemas de programación inteligentes que se integren con CRMs, envíen confirmaciones automáticas y gestionen disponibilidad.

Sistemas RAG (Retrieval-Augmented Generation)

Utiliza Qdrant para almacenar embeddings, Ollama para procesamiento local de IA y ZEP para mantener memoria contextual en conversaciones largas.

Chatbots Empresariales Avanzados

Integra N8N para workflows, ZEP para memoria conversacional, MinIO para almacenamiento de archivos y RabbitMQ para comunicación asíncrona entre servicios.

Plataformas de Aprendizaje Inteligentes

Combina Moodle con herramientas de IA para crear experiencias educativas personalizadas que se adapten al progreso de cada estudiante.

Ventajas del Enfoque SetupOrion

Simplicidad Extrema: Tres pasos para tener un entorno completo funcionando Economía de Tiempo: Lo que tomaría días de configuración se resuelve en horas Configuración Profesional: Incluye SSL, proxy reverso y gestión de contenedores Escalabilidad: Basado en Docker Swarm para crecimiento futuro Comunidad Activa: Más de 1000 miembros en Discord y WhatsApp para soporte

Consideraciones y Limitaciones

SetupOrion es perfecto para:

• Desarrollo y testing de soluciones de IA

• Prototipos de automatización

• Entornos de aprendizaje

• Pequeñas implementaciones productivas

Para entornos empresariales críticos, considera implementaciones más robustas con redundancia y monitoreo avanzado.

¿Listo para revolucionar tu flujo de trabajo con IA y automatización? Un comando, tres pasos, y tendrás acceso a lo mejor del ecosistema open source en tu propio servidor.

Es un puente inteligente que conecta asistentes de IA como Claude con la plataforma n8n, pero con una ventaja única: tiene acceso automático y siempre actualizado a toda la documentación oficial de n8n. Con 525+ nodos cubiertos al 100% y actualizaciones semanales automáticas, ahora puedes construir automaciones reales que funcionan al primer intento.

Qué puedes hacer realmente con n8n-MCP

El problema que soluciona

Antes de n8n-MCP, pedirle a Claude que construyera un workflow de n8n era como jugar a la lotería:

• 📝 "Crea un workflow que envíe notificaciones a Slack cuando llegue un email"

  • Claude adivinaba los nombres de nodos (¿es emailTrigger o Email Trigger?)

  • Inventaba propiedades que no existían

  • Te daba configuraciones que parecían correctas pero fallaban

La solución real

Con n8n-MCP, Claude tiene acceso directo a:

• Todos los nodos disponibles con nombres exactos

• Todas las propiedades de cada nodo con sus valores válidos

• Documentación oficial actualizada semanalmente

• Ejemplos de configuración que realmente funcionan

La diferencia práctica

Sin n8n-MCP:

• 45 minutos promedio para un workflow simple

• 6+ iteraciones de prueba y error

• Configuraciones que "parecen correctas" pero fallan

• Documentación desactualizada o inexistente

Con n8n-MCP:

• 3-5 minutos para el mismo workflow

• Funciona al primer intento en 90% de casos

• Configuraciones validadas y documentadas

• Acceso a las últimas funcionalidades de n8n

Cómo funciona: la tecnología detrás de la magia

MCPs: el "USB" de las integraciones AI

Los Model Context Protocols son un estándar desarrollado por Anthropic que permite que los asistentes de IA accedan a herramientas externas de forma estandarizada. Es como un "USB" para conectar IA con cualquier sistema.

Por qué n8n-MCP es especial

El problema fundamental: Los LLMs como Claude tienen conocimiento general sobre n8n, pero no conocen:

• Los nodos exactos disponibles en tu versión

• Las propiedades específicas de cada nodo

• Cómo han cambiado las APIs recientemente

• Qué nodos nuevos se han añadido

La solución de n8n-MCP:

• 525+ nodos con documentación completa

• 99% de cobertura de propiedades y esquemas

• Actualizaciones automáticas cada semana via GitHub Actions

• Base de datos optimizada con SQLite + FTS5 para búsquedas de 12ms

Qué información tiene Claude disponible

Cuando usas n8n-MCP, Claude puede:

// Buscar nodos por funcionalidad
"¿Qué nodos puedo usar para trabajar con bases de datos?"

// Obtener documentación exacta
"¿Cuáles son todas las propiedades del nodo HTTP Request?"

// Validar configuraciones
"¿Esta configuración de Slack es correcta?"

// Encontrar ejemplos
"¿Tienes ejemplos de cómo conectar Google Sheets con Notion?"

Configuración paso a paso: empieza en 5 minutos

Opción 1: Claude Desktop (más fácil)

1. Instala Node.js si no lo tienes

2. Crea/edita el archivo de configuración:

macOS: ~/Library/Application Support/Claude/claude_desktop_config.json Windows:%APPDATA%/Claude/claude_desktop_config.json

{
  "mcpServers": {
    "n8n-mcp": {
      "command": "npx",
      "args": ["n8n-mcp"],
      "env": {
        "MCP_MODE": "stdio",
        "LOG_LEVEL": "error"
      }
    }
  }
}

3. Reinicia Claude Desktop

4. Prueba: Pregunta "¿Qué nodos de n8n están disponibles para trabajar con email?"

Opción 2: Cursor

En configuración de MCP:

{
  "mcpServers": {
    "n8n-mcp": {
      "command": "npx",
      "args": ["-y", "n8n-mcp"]
    }
  }
}

¿Tenés tu propia instancia de n8n?

Si queres que Claude también pueda crear y ejecutar workflows en tu instancia:

{
  "mcpServers": {
    "n8n-mcp": {
      "command": "npx",
      "args": ["n8n-mcp"],
      "env": {
        "N8N_API_KEY": "tu-api-key",
        "N8N_BASE_URL": "https://tu-instancia.com"
      }
    }
  }
}

Verificación rápida

Una vez configurado, prueba con:

• "¿Qué nodos puedo usar para trabajar con Google Sheets?"

• "Muéstrame cómo configurar un HTTP Request"

• "Crea un workflow simple que envíe un Slack cuando reciba un webhook"

¿Cuándo NO usar n8n-MCP?

• Si solo necesitas automaciones súper simples (email → Slack)

• Si tu equipo no está cómodo con herramientas técnicas

• Si prefieres interfaces 100% visuales sin IA

• Si trabajas en un entorno sin acceso a Claude/VS Code

¿Cuándo SÍ usar n8n-MCP?

• ✅ Construyes automaciones complejas regularmente

• ✅ Necesitas workflows que manejen múltiples sistemas

• ✅ Valoras la precisión y quieres evitar configuraciones incorrectas

• ✅ Trabajas con APIs y integraciones personalizadas

• ✅ Quieres aprovechar IA para acelerar desarrollo

El futuro: qué viene después

n8n-MCP es solo el comienzo. La tendencia hacia agentes autónomos significa que pronto veremos:

• Workflows auto-optimizados que mejoran su rendimiento automáticamente

• Detección predictiva de problemas antes de que ocurran

• Integraciones multi-modal que procesan texto, imágenes, y audio

• Colaboración entre agentes donde múltiples MCPs trabajan juntos

Conclusión: ¿vale la pena?

Para desarrolladores y equipos técnicos: Absolutamente sí. La mejora en velocidad y precisión es dramática.

Para empresas que automatizan regularmente: Es una ventaja competitiva clara.

Para principiantes en n8n: Te ahorra meses de curva de aprendizaje.

n8n-MCP no solo hace que construir workflows sea más rápido – hace que sea más confiable, preciso y disfrutable. En un mundo donde la automatización inteligente es cada vez más crítica, tener herramientas que combinan la potencia de n8n con la inteligencia de IA moderna no es lujo: es necesidad.

La automatización inteligente ya está acá. La pregunta es: ¿vas a aprovecharla o vas a seguir construyendo workflows a mano?

Según la documentación oficial de Anthropic y reportes de la comunidad, los subagentes han logrado mejoras de productividad del 300-400% en tareas complejas, con desarrolladores describiendo la experiencia como tener "un equipo de ingenieros especializados que nunca duerme" trabajando en paralelo en diferentes aspectos del mismo proyecto.

Qué son exactamente los subagentes de Claude Code

Los subagentes son asistentes de IA especializados configurables que funcionan como miembros independientes de un equipo de desarrollo virtual. Cada subagente opera con:

• Contexto independiente de 200,000 tokens (equivalente a ~150,000 palabras)

• Prompt de sistema personalizado para especialización en dominios específicos

• Permisos granulares de herramientas (file system, Git, MCP servers, etc.)

• Reutilización entre proyectos y capacidad de compartir con equipos

Arquitectura técnica: Los subagentes se almacenan como archivos Markdown con metadatos YAML en dos ubicaciones:

• Nivel de proyecto: .claude/agents/ (mayor prioridad)

• Nivel de usuario: ~/.claude/agents/ (disponible globalmente)

La configuración sigue esta estructura:

yaml

---
name: security-auditor
description: Especialista en auditorías de seguridad que DEBE USARSE para cualquier revisión relacionada con vulnerabilidades OWASP
tools: file_read, grep, bash
---
Eres un auditor de seguridad experto especializado en identificar vulnerabilidades críticas...

Funcionalidades específicas y propósito

Los subagentes resuelven tres problemas fundamentales del desarrollo asistido por IA tradicional:

Contaminación de contexto: Las versiones anteriores de Claude Code sufrían "ensuciamiento" del contexto cuando múltiples tareas no relacionadas se ejecutaban en el mismo hilo conversacional. Los subagentes mantienen contextos completamente separados.

Falta de especialización: Un asistente generalista no puede optimizar para dominios específicos como auditoría de seguridad, testing automatizado o arquitectura de APIs. Los subagentes permiten configuración experta por área.

Limitaciones de paralelización: Tareas interdependientes requerían ejecución secuencial. Los subagentes pueden trabajar simultáneamente en diferentes aspectos del mismo proyecto.

Casos de uso principales identificados en la comunidad:

• Revisor de código: Especializado en estándares OWASP, prácticas de seguridad

• Arquitecto backend: Diseño de APIs RESTful, microservicios, optimización de bases de datos

• Escritor de pruebas: Generación de suites comprehensivas (unit, integration, e2e)

• Debugger especializado: Resolución de problemas específicos del dominio del proyecto

• Auditor de seguridad: Análisis de vulnerabilidades y compliance

• Optimizador de rendimiento: Análisis de complejidad algorítmica y bottlenecks

Guía práctica de implementación paso a paso

Configuración inicial paso a paso con capturas

Paso 1: Acceder a la interfaz de subagentes

/agents
# Despliega interfaz para crear, editar, y gestionar subagentes

Paso 2: Elegir ubicación del subagente Al seleccionar "Create new agent", aparece la primera configuración para elegir el scope:

• Project: Disponible solo para el proyecto actual (recomendado para equipos)

• Personal: Disponible globalmente en todos los proyectos

Paso 3: Método de creación

Se recomienda "Generate with Claude" para principiantes, que guía la creación automáticamente.

Paso 4: Descripción del propósito del agente

Aquí se define qué hace el agente y cuándo debe ser utilizado. Ejemplo: "Expert software engineer that helps review my code based on best practices..."

Paso 5: Selección de herramientas

Opciones disponibles:

• All tools: Acceso completo (recomendado para la mayoría)

• Read-only tools: Solo lectura de archivos

• Edit tools: Capacidades de edición

• Execution tools: Ejecución de comandos

Paso 6: Selección del modelo

Modelos disponibles:

• Sonnet: Balance rendimiento/velocidad (recomendado)

• Haiku: Rápido y eficiente para tareas simples

• Inherit from parent: Usa el mismo modelo de la conversación principal

Paso 7: Personalización visual

Permite asignar colores distintivos para identificar fácilmente diferentes agentes en la interfaz.

Paso 8: Confirmación final

La pantalla muestra:

• Name: test-suite-generator

• Location: .claude/agents/test-suite-generator.md

• Tools: All tools

• Model: Sonnet

• Description: Uso del agente

• System prompt: Prompt completo del sistema

Paso 9: Configuración del archivo del subagente Ejemplo de configuración manual avanzada:

---
name: backend-architect
description: Diseña APIs RESTful, arquitecturas de microservicios y esquemas de base de datos. USAR PROACTIVAMENTE para diseño de sistemas
tools: file_read, file_write, bash, grep
---

Eres un arquitecto backend senior con experiencia en:
- Diseño de APIs REST y GraphQL escalables
- Patrones de microservicios y service mesh
- Optimización de bases de datos y queries
- Implementación de cache distribuido
- Observabilidad y métricas de sistemas

Siempre considera:
- Escalabilidad horizontal
- Tolerancia a fallos
- Principios de seguridad por diseño
- Patrones de resiliencia (circuit breaker, retry, timeout)

Las capturas de pantalla revelan que la interfaz de Claude Code para crear subagentes es sorprendentemente intuitiva, siguiendo un wizard paso a paso que elimina la complejidad técnica inicial. El proceso está optimizado para desarrolladores de todos los niveles:

Características destacadas observadas:

• Interfaz terminal moderna: Diseño limpio con navegación clara usando teclas de dirección

• Generación asistida: Claude puede crear automáticamente el prompt del sistema basándose en una descripción simple

• Configuración granular: Control preciso sobre herramientas, modelos y ubicación sin código

• Preview en tiempo real: Visualización del nombre del agente antes de confirmar

• Validación automática: El sistema previene errores comunes en la configuración

Detalle del ejemplo "test-suite-generator": Las capturas muestran la creación de un especialista en testing que demuestra la sophistication del sistema. El agente resultante incluye:

• Descripción clara de uso ("Use this agent when you need to create comprehensive test suites...")

• Prompt del sistema complejo generado automáticamente ("You are a Test Engineering Specialist with deep expertise...")

• Configuración de herramientas completa con advertencias de seguridad

• Ubicación específica en .claude/agents/test-suite-generator.md

Este nivel de detalle en la configuración explica por qué los subagentes logran especialización tan efectiva comparado con prompts ad-hoc.

Workflows prácticos avanzados

Desarrollo full-stack paralelo:

# Orquestación de 4 subagentes especializados
> Ejecuta desarrollo completo de e-commerce usando 4 subagentes en paralelo:
- backend-architect para APIs y microservicios
- frontend-developer para interfaz React
- security-auditor para revisión de vulnerabilidades  
- test-automator para suites de pruebas completas

Resultado típico:

⏺ Task(Diseño arquitectura backend)
⎿ Done (17 herramientas · 56.6k tokens · 1m 34s)
⏺ Task(Implementación frontend React)  
⎿ Done (23 herramientas · 48.9k tokens · 1m 16s)
⏺ Task(Auditoría de seguridad)
⎿ Done (28 herramientas · 45.2k tokens · 1m 44s)
⏺ Task(Generación suite de pruebas)
⎿ Done (23 herramientas · 70.5k tokens · 2m 17s)

Análisis de codebase masivo:

# Análisis especializado por expertos
> Analiza el proyecto usando 4 expertos especializados:
- experto-rendimiento para bottlenecks y optimizaciones
- experto-seguridad para vulnerabilidades y compliance
- experto-arquitectura para deuda técnica y mejoras
- experto-testing para cobertura y calidad de pruebas

Comandos personalizados (Slash Commands)

Los subagentes se pueden automatizar creando comandos personalizados:

.claude/commands/fix-github-issue.md:

markdown

Analiza y corrige el issue #$ARGUMENTS de GitHub siguiendo este workflow:

1. Ejecutar `gh issue view $ARGUMENTS` para obtener detalles
2. Usar backend-architect para análisis de impacto arquitectural
3. Usar security-auditor si involucra aspectos de seguridad
4. Implementar corrección con test-automator generando pruebas
5. Crear PR con descripción detallada

Delegar automáticamente a subagentes apropiados basándose en el tipo de issue.

Uso: /project:fix-github-issue 1234

Revolución del contexto de 200,000 tokens

Capacidades técnicas del contexto ampliado

Equivalencias de capacidad:

• 200,000 tokens = ~150,000 palabras = 500+ páginas de documentación

• Capacidad total efectiva: 2,000,000 tokens con 10 subagentes paralelos

• Recall del 98% a través de toda la ventana de contexto (Claude 2.1+)

Beneficios específicos para desarrollo:

Análisis de codebases completos: Los subagentes pueden procesar repositorios masivos, incluyendo documentación técnica, bases de código completas, y declaraciones financieras como S-1s sin necesidad de chunking o compresión.

Eliminación de compresión frecuente: Las versiones anteriores perdían contexto gradualmente, requiriendo resúmenes y compresión que introducían errores. Los subagentes mantienen contexto completo durante toda la sesión.

Contexto aislado por especialidad: Un subagente security-auditor mantiene 200k tokens enfocados exclusivamente en aspectos de seguridad, sin contaminación de tareas de UI o performance.

Memoria persistente en Opus 4: El modelo más avanzado puede crear y mantener archivos de memoria para proyectos que se extienden por días o semanas, recordando decisiones arquitecturales previas.

Conclusión

Los subagentes de Claude Code representan un cambio paradigmático hacia "equipos AI especializados" que operan como desarrolladores humanos especializados, cada uno con expertise profunda en su dominio y capacidad de mantener contexto completo durante sesiones extendidas. Esta arquitectura resuelve limitaciones fundamentales de herramientas AI tradicionales mientras introduce nuevas capacidades de orquestación paralela que prometen redefinir workflows de desarrollo de software en los próximos años.

Hasta ahora, el almacenamiento de embeddings vectoriales a menudo implicaba compromisos: o usabas bases de datos vectoriales especializadas con sus propios desafíos de gestión, o intentabas adaptar soluciones de almacenamiento de objetos con capas adicionales de complejidad y costo. Amazon S3 Vectors, presentado en AWS re:Invent 2024, es el primer almacenamiento de objetos en la nube con soporte nativo para vectores, diseñado para ofrecer un rendimiento de consulta en subsegundos y una reducción significativa de costos.

¿Qué es Amazon S3 Vectors y por qué es un cambio de juego?

En esencia, Amazon S3 Vectors transforma S3 en una potente solución para el almacenamiento y la consulta de datos vectoriales. Esto es crucial para aplicaciones de IA generativa como Retrieval Augmented Generation (RAG), donde la capacidad de buscar rápidamente en vastos conjuntos de datos para contextualizar las respuestas del modelo es fundamental.

La principal ventaja es la simplicidad y la reducción de costos. Al integrar el soporte de vectores directamente en S3, AWS elimina la necesidad de infraestructuras complejas y costosas, permitiendo un ahorro de hasta el 90% en el costo total de carga, almacenamiento y consulta de vectores.

Conceptos Clave: Vector Buckets e Índices de Vectores

Amazon S3 Vectors introduce dos nuevos conceptos fundamentales:

• Vector Buckets: Son los contenedores donde se almacenan tus datos vectoriales. A diferencia de los buckets S3 tradicionales, los Vector Buckets están optimizados específicamente para este tipo de datos.

  

  Creación de un "vector bucket" en Amazon S3, optimizado para el almacenamiento de vectores.

• Índices de Vectores: Dentro de un Vector Bucket, la información se organiza en "índices de vectores". Cada índice puede contener millones de vectores y es donde se realizan las consultas eficientes. Puedes adjuntar metadatos a tus vectores para realizar consultas filtradas, lo que es invaluable para la búsqueda semántica.

  

  Configuración de un "vector index", definiendo la dimensión y la métrica de distancia para la búsqueda de similitud.

La interfaz de usuario es intuitiva, permitiendo una configuración rápida y sencilla, como se ve en las siguientes pantallas:

Confirmación de la creación exitosa de un "vector bucket" y la opción de crear un índice de vectores.

Vista de los índices de vectores creados dentro de un "vector bucket".

El Flujo de Trabajo: De Documentos a Búsqueda Semántica

El proceso es sorprendentemente lineal y eficiente:

1. Generación de Embeddings: Tus documentos o datos se transforman en embeddings vectoriales utilizando un modelo de embedding.

2. Almacenamiento en S3 Vectors: Estos embeddings se almacenan directamente en tus Vector Buckets e Índices de Vectores en S3.

3. Búsqueda Semántica: Los usuarios pueden realizar consultas de similitud a través del índice de vectores para encontrar los datos más relevantes.

Diagrama del flujo de trabajo: de documentos a embeddings, almacenamiento en S3 Vectors y búsqueda semántica.

Integración Profunda con el Ecosistema AWS

Una de las mayores fortalezas de Amazon S3 Vectors es su integración nativa y profunda con otros servicios clave de AWS, lo que lo convierte en una pieza fundamental de tu pipeline de IA generativa:

• Amazon Bedrock Knowledge Bases: Para aplicaciones RAG, S3 Vectors se integra directamente con las bases de conocimiento de Bedrock, actuando como el almacén subyacente para los embeddings, mejorando la precisión y relevancia de las respuestas generadas por los modelos de lenguaje grandes (LLMs).

  

  Configuración del almacenamiento de datos en Amazon Bedrock Knowledge Bases, donde S3 Vectors es una opción recomendada.

  

  Selección de Amazon S3 Vectors como almacén de vectores en Bedrock, destacando su optimización para el costo y la durabilidad.

• Amazon SageMaker: Puedes usar SageMaker para generar embeddings y luego almacenarlos en S3 Vectors, o para construir y entrenar modelos que utilicen estos datos vectoriales.

• Amazon OpenSearch Service: Para escenarios que requieren capacidades de búsqueda en tiempo real o híbridas (texto y vector), puedes exportar datos de S3 Vectors a Amazon OpenSearch Service. Esto permite equilibrar el costo del almacenamiento con la necesidad de un rendimiento de consulta ultra-rápido.

  

  Opción para exportar un índice de vectores de S3 a OpenSearch para capacidades de búsqueda avanzadas.

  

  Configuración para exportar un índice de vectores de S3 a un motor de vectores de OpenSearch, con detalles de cómo funciona la integración.

  

  Historial de importación de vectores de S3 a OpenSearch, mostrando el estado de las operaciones.

Implicaciones para DevOps

Para los equipos de DevOps, Amazon S3 Vectors significa:

• Menos Infraestructura que Gestionar: Al aprovechar un servicio gestionado directamente desde S3, se reduce la carga de provisionar, escalar y mantener bases de datos vectoriales dedicadas.

• Costos Optimizados: La eficiencia en el almacenamiento y consulta se traduce directamente en menores facturas de AWS. 💰

• Integración Simplificada: La integración nativa con Bedrock y otros servicios de AWS agiliza el despliegue de aplicaciones de IA generativa, permitiendo a los equipos enfocarse en la lógica de negocio en lugar de la complejidad de la infraestructura de datos.

• Escalabilidad a Demanda: S3 es conocido por su escalabilidad masiva, y S3 Vectors hereda esta capacidad, permitiendo manejar petabytes de datos vectoriales sin intervención manual.

Conclusión

Amazon S3 Vectors es un hito significativo en el almacenamiento de datos para la era de la IA generativa. Ofrece una solución nativa, rentable y altamente escalable para gestionar embeddings vectoriales, simplificando enormemente el panorama para los desarrolladores y equipos de DevOps que construyen aplicaciones inteligentes. Si estás trabajando con IA generativa o planeas hacerlo, S3 Vectors es una capacidad que definitivamente querrás explorar.

Actualmente en vista previa en varias regiones de AWS (incluyendo US East (N. Virginia), US East (Ohio), US West (Oregon), Europe (Frankfurt) y Asia Pacific (Sydney)), es el momento perfecto para experimentar con esta poderosa herramienta y ver cómo puede transformar tus flujos de trabajo de IA. ¡No te quedes atrás! 🚀

Kiro no es solo una herramienta para autocompletar código o responder preguntas en un chat. Su ambición es mucho mayor: orquestar todo el ciclo de vida del desarrollo de software, desde la concepción de la idea hasta la implementación en producción, manteniendo siempre la coherencia entre la documentación, el diseño y el código.

En este artículo, analizaremos en profundidad qué es Kiro, cuáles son sus características técnicas más destacadas, cómo funciona y qué lo diferencia de otras herramientas de IA para desarrolladores que ya existen en el mercado.

¿Qué es Kiro y Cuál es su Filosofía?

Kiro es un IDE basado en Code OSS, el proyecto de código abierto sobre el que se construye el popular Visual Studio Code. Esto significa que los desarrolladores que ya están familiarizados con VS Code se sentirán como en casa, pudiendo conservar sus configuraciones y extensiones compatibles con Open VSX.

Sin embargo, Kiro no es una simple bifurcación de VS Code. Es una reimaginación de cómo debería ser el desarrollo de software en la era de la IA generativa. La filosofía de Kiro se resume en su eslogan: "From vibe coding to viable code" (Del "código por intuición" al "código viable").

El "vibe coding" es ese proceso, cada vez más común gracias a herramientas como GitHub Copilot, en el que los desarrolladores generan rápidamente prototipos y fragmentos de código sin una planificación o documentación rigurosa. Si bien esto acelera la fase inicial, a menudo conduce a un "caos de codificación": software difícil de mantener, con deuda técnica y sin una documentación clara que refleje su estado actual.

Kiro ataca este problema de raíz con su enfoque "spec-driven". En lugar de empezar a escribir código de inmediato, Kiro guía al desarrollador para que primero defina claramente qué quiere construir. A partir de un simple prompt en lenguaje natural, Kiro genera un conjunto de documentos de especificación:

• requirements.md: Define la visión del producto, las características y los usuarios objetivo, utilizando una sintaxis estructurada como EARS (Easy Approach to Requirements Syntax).

• design.md: Documenta la arquitectura técnica, el stack tecnológico, los flujos de la experiencia de usuario, las interfaces de TypeScript, los esquemas de bases de datos y los endpoints de la API.

• tasks.md: Desglosa la implementación en una lista de tareas concretas y ordenadas por dependencias.

La clave de Kiro es que estos documentos no son artefactos estáticos que se crean y luego se olvidan. Son documentos vivos que se mantienen sincronizados con el código a lo largo de todo el proceso de desarrollo. Si un desarrollador modifica el código, puede pedirle a Kiro que actualice las especificaciones, y viceversa.

Características Técnicas Clave de Kiro

Para lograr esta simbiosis entre especificaciones y código, Kiro se apoya en una serie de características técnicas innovadoras:

• IA Agnóstica y Modelos de Vanguardia: En su núcleo, Kiro utiliza agentes de IA para interpretar los prompts, generar las especificaciones, escribir el código y realizar otras tareas. Estos agentes están impulsados por los modelos de última generación de Anthropic, como Claude 3.5 Sonnet y Claude 3 Opus. Kiro permite al usuario elegir qué modelo utilizar para sus agentes, lo que demuestra una flexibilidad notable.

• Kiro Hooks: Esta es una de las características más potentes de Kiro. Los "hooks" son automatizaciones basadas en eventos que delegan tareas a un agente de IA en segundo plano. Por ejemplo, se puede configurar un hook para que, cada vez que se guarda un archivo, un agente de IA genere automáticamente las pruebas unitarias correspondientes, actualice la documentación o verifique si se cumplen ciertos estándares de codificación. Es como tener un desarrollador experimentado revisando tu trabajo y ocupándose de las tareas repetitivas.

• Agentes de IA Autónomos: A diferencia de los asistentes de chat pasivos, los agentes de Kiro pueden actuar de forma autónoma para completar proyectos complejos. Pueden leer y escribir archivos, ejecutar comandos en la terminal, navegar por la base de código y tomar decisiones para llevar a cabo una tarea de principio a fin. El desarrollador puede elegir entre un modo "supervisado", donde el agente solicita aprobación para cada cambio, o un modo más autónomo.

• Comprensión Multimodal y Contexto Enriquecido: Kiro puede procesar una amplia variedad de entradas para construir un entendimiento profundo del proyecto. Acepta archivos, código base, documentos, imágenes, mapas de repositorios, diffs de Git, salidas de la terminal y URLs. Además, es compatible con servidores MCP (Managed Context Provider), lo que le permite conectarse a fuentes de datos externas y privadas (como la documentación interna de una empresa) para enriquecer el contexto de sus agentes de IA.

Comparativa con Otras Herramientas de IA para Desarrollo

El panorama de las herramientas de codificación con IA es cada vez más competitivo. ¿Dónde se sitúa Kiro frente a sus rivales?

• Kiro vs. GitHub Copilot y Amazon Q Developer: Mientras que Copilot y Q se centran principalmente en la asistencia a nivel de código (autocompletado, chat, depuración), Kiro aspira a gestionar todo el flujo de trabajo. Su enfoque en la generación y mantenimiento de especificaciones lo diferencia claramente de estas herramientas.

• Kiro vs. Cursor y Windsurf: Cursor y Windsurf son IDEs que también han adoptado un enfoque "AI-first". Sin embargo, los análisis sugieren que el diferenciador clave de Kiro es su formalización del "spec-driven development" y la potencia de los "Kiro Hooks" para la automatización. Mientras que Cursor y Windsurf también son agnósticos en cuanto al código, la metodología estructurada de Kiro para la planificación y la documentación es su principal argumento de venta.

Disponibilidad y Precios

Kiro se encuentra actualmente en una fase de vista previa pública y se puede descargar de forma gratuita desde su sitio web, kiro.dev, para macOS, Windows y Linux. Durante este período, el uso es gratuito con ciertos límites.

La empresa ha anunciado sus planes de precios futuros, que incluirán tres niveles:

• Free: Con 50 interacciones de agente al mes.

• Pro: Por 19 dólares al mes por usuario, con 1,000 interacciones.

• Pro+: Por 39 dólares al mes por usuario, con 3,000 interacciones.

Conclusión: ¿El Futuro del Desarrollo de Software?

Kiro representa una visión audaz y bien fundamentada sobre el futuro del desarrollo de software. En lugar de simplemente acelerar la escritura de código, Kiro busca mejorar la calidad, la mantenibilidad y la colaboración en los proyectos de software.

Su enfoque en el desarrollo guiado por especificaciones, combinado con la potencia de los agentes de IA autónomos y los "hooks" de automatización, tiene el potencial de resolver uno de los problemas más persistentes de la industria: la desconexión entre la documentación y la implementación.

Si bien aún es pronto para saber si Kiro logrará la adopción masiva que busca, su lanzamiento es, sin duda, una de las propuestas más interesantes y técnicamente sólidas que hemos visto en el campo de las herramientas de desarrollo con IA. Para los equipos y desarrolladores que buscan no solo velocidad, sino también orden y calidad en sus proyectos, Kiro es una herramienta a la que definitivamente habrá que seguir de cerca.

¿Qué es EKS Auto Mode?

EKS Auto Mode es la respuesta de AWS a una antigua demanda de la comunidad de Kubernetes: la automatización en la gestión de nodos. Esta característica gestiona automáticamente el escalado de los nodos EKS en un cluster de Amazon EKS, lo que resulta especialmente útil para equipos que buscan una solución "hands-off" (con mínima intervención manual).

Estructura de Costos: Lo que Necesitas Saber

Cuando implementas EKS Auto Mode, hay que considerar varios componentes en la estructura de costos:

1. Costos Base

Tarifa del Cluster EKS

La tarifa base depende de la versión de Kubernetes que utilices:

Tarifa de EKS Auto Mode

Además de la tarifa base, hay un costo adicional por hora para las instancias EC2 gestionadas por EKS Auto Mode. Por ejemplo, en la región us-east-1, estos son los costos adicionales para instancias de uso general populares:

Como podes ver, hay tarifas adicionales de gestión que varían según el tipo de instancia EC2 utilizada.

2. Costos Adicionales que Permanecen

• Almacenamiento:

  • Volúmenes raíz de las instancias EC2

  • Volúmenes EBS adicionales (gp3 o io1)

  • Cargos por capacidad y IOPS

• Networking:

  • Direcciones IP elásticas

  • Transferencia de datos entre AZs y regiones

  • Componentes de VPC

• Otros Costos:

  • Fargate (si se utiliza)

  • Add-ons (charts de Helm, Route 53, integraciones de terceros)

Limitaciones Importantes con Instancias Spot

Una de las consideraciones más importantes es la integración con instancias spot. Aunque EKS Auto Mode sí soporta instancias spot, presenta algunas limitaciones significativas:

1. No hay Integración Flexible: No puedes mezclar instancias spot y bajo demanda en un mismo grupo de nodos.

2. Configuración Separada: Requiere crear grupos de nodos separados para:

   • Instancias On-Demand

   • Instancias Spot —> No es administrado por auto-mode

Esto significa más overhead en términos de gestión y configuración, algo que debes considerar en tu arquitectura.

Preguntas Frecuentes sobre EKS Auto Mode

Opciones de Compra de Instancias EC2

¿Se pueden aprovechar las diferentes opciones de compra de instancias de Amazon EC2 con EKS Auto Mode?

Sí, EKS Auto Mode es compatible con:

• Instancias On-Demand

• Compute Savings Plans

• Instancias Spot

Comparación con Karpenter y AWS Autoscaler

¿Es EKS Auto Mode similar a Karpenter gestionado?

No son exactamente lo mismo. EKS Auto Mode ofrece funcionalidades adicionales:

• Gestión y parcheo de complementos core de EKS (CoreDNS, kube-proxy, VPC CNI)

• Gestión de controladores EBS CSI

• Gestión de controladores de balanceador de carga AWS

¿Se puede usar AWS Autoscaler con EKS Auto Mode?

EKS Auto Mode utiliza Karpenter para el autoescalado de cómputo, lo que significa:

• Aprovisionamiento y escalado automático de instancias EC2 según demanda

• El escalado horizontal de pods (HPA) requiere configuración manual del usuario

Gestión de Clusters

¿Se puede habilitar EKS Auto Mode en clusters actuales?

Sí, es posible habilitar EKS Auto Mode en clusters existentes. AWS proporciona documentación oficial para la implementación, aunque se recomienda utilizar Infrastructure as Code (IaC) para este proceso en lugar de hacerlo manualmente.

¿Se puede deshabilitar una vez habilitado?

Sí, AWS proporciona documentación oficial detallada sobre el proceso de deshabilitación.

Gestión de IAM Simplificada

Una ventaja significativa es la simplificación en la gestión de IAM:

1. Aprovisionamiento Automático:

   • Roles IAM para instancias EC2

   • Políticas predefinidas con privilegios mínimos

   • Gestión de permisos para add-ons core

2. Flexibilidad:

   • Permite modificar roles y políticas según necesidades

   • Compatible con AWS Management Console, CLI y SDK

Soporte para Infraestructura como Código

Para equipos que utilizan Terraform:

• Disponible desde la versión v5.79.0

• Soporte para módulos aws-terraform desde v20.31.0

¿Cuándo Usar EKS Auto Mode?

EKS Auto Mode es ideal para:

1. Equipos que prefieren menos gestión manual de la infraestructura

2. Proyectos que no requieren configuraciones complejas de instancias spot

3. Organizaciones que buscan simplificar la gestión de IAM y add-ons

Conclusión

EKS Auto Mode representa un paso significativo hacia la abstracción de la gestión de Kubernetes en AWS. Si bien simplifica muchos aspectos de la administración del cluster, es importante considerar sus limitaciones, especialmente en lo relacionado con instancias spot y costos asociados. La decisión de implementarlo debe basarse en tus necesidades específicas de escalado, presupuesto y recursos de administración disponibles.

Para abordar este desafío, AWS Labs desarrolló Sandbox Accounts for Events, una solución que automatiza la creación y gestión de cuentas temporales de AWS para eventos como talleres y hackatones. Esta herramienta permite a los organizadores configurar y entregar cuentas temporales con facilidad, asegurando que sean eliminadas o reiniciadas una vez finalizadas.

En este artículo, vamos a explorar qué es esta solución, cómo instalarla y cómo configurarla para aprovechar al máximo sus capacidades.

¿Qué es Sandbox Accounts for Events?

Sandbox Accounts for Events es un sistema que permite asignar cuentas temporales de AWS a varios usuarios al mismo tiempo. A través de una interfaz gráfica fácil de usar, los administradores pueden distribuir cuentas a los participantes y controlar su uso mediante una funcionalidad de "arrendamientos" o leases temporales.

El backend de la solución se basa en el proyecto Disposable Cloud Environment™ (DCE), que se encarga de gestionar los recursos asociados, limpiar las cuentas al finalizar el arrendamiento y garantizar que los costos estén dentro de los límites establecidos. Esto permite a las organizaciones controlar tanto la seguridad como los presupuestos durante los eventos.

Principales características

• Gestión de cuentas temporales: Permite crear y asignar cuentas temporales a múltiples usuarios autenticados.

• Control de gastos: Configura presupuestos máximos por cuenta para evitar costos inesperados.

• Eliminación automática: Utiliza AWS Nuke para limpiar las cuentas después de su expiración.

• Escalabilidad: Puede manejar múltiples usuarios simultáneamente, ideal para grandes eventos.

Casos de uso

Sandbox Accounts for Events es ideal para una amplia gama de escenarios, incluyendo:

1. Talleres educativos: Proporciona un entorno controlado para que los participantes aprendan a usar servicios de AWS.

2. Hackatones: Ofrece cuentas aisladas y temporales para equipos que desarrollan soluciones innovadoras durante competencias.

3. Pruebas y experimentos: Facilita la experimentación en entornos separados del entorno de producción, reduciendo riesgos.

4. Capacitación interna: Equipos de desarrollo o investigación pueden acceder a entornos temporales para probar nuevas ideas.

Instalación de Sandbox Accounts for Events

A continuación, te muestro cómo instalar y configurar esta herramienta en tu cuenta de AWS. El proceso es simple, pero requiere algunos pasos previos.

Prerrequisitos

Antes de empezar, necesitas tener lo siguiente:

1. Una cuenta de AWS: Es preferible usar una cuenta vinculada a AWS Organizations para un mejor control.

2. Herramientas necesarias:

   • AWS CLI: Instrucciones de instalación.

   • GNU Make: Instrucciones de instalación.

   • Git: Descargar Git.

3. Bucket de S3: Vas a necesitar un bucket para almacenar los artefactos de despliegue.

Pasos de instalación

1- Clona el repositorio
Abrí tu terminal y ejecuta:

git clone https://github.com/awslabs/sandbox-accounts-for-events.git
cd sandbox-accounts-for-events

2- Crea un bucket de S3
Este bucket va a almacenar los archivos necesarios para la implementación:

aws s3 mb s3://<nombre-de-tu-bucket>

3- Construye los artefactos
Compila los artefactos necesarios ejecutando:

make build

4- Despliega la solución
Implementa la aplicación en tu cuenta de AWS:

make deploy BUCKET_NAME=<nombre-de-tu-bucket>

5- Configura el frontend
Una vez completada la implementación, vas a tener una URL para el frontend de la aplicación. Esta URL puede ser compartida con los usuarios para que se registren y accedan a sus cuentas temporales.

Configuración avanzada

Integración con AWS Organizations

Aunque esta herramienta puede usarse sin AWS Organizations, se recomienda su integración para un mejor control. AWS Organizations permite:

• Limitar el acceso a servicios y regiones específicas mediante políticas SCP (Service Control Policies).

• Administrar las cuentas sandbox desde una unidad organizativa centralizada.

• Implementar medidas de seguridad avanzadas para proteger los entornos.

Definir límites de tiempo y presupuesto

Al configurar la solución, podes ajustar la duración máxima de los arrendamientos y establecer presupuestos por cuenta. Esto asegura que los recursos sean liberados automáticamente una vez que se alcanza el tiempo límite o el presupuesto asignado.

Mejores prácticas de seguridad

Es importante seguir las siguientes recomendaciones para garantizar la seguridad al utilizar esta herramienta:

1. Mantén el software actualizado: Las versiones más recientes del proyecto solucionan vulnerabilidades como CVE-2023-50928, que permitía a usuarios autenticados acceder a cuentas vacías.

2. Monitorea el uso: Utiliza herramientas como AWS CloudWatch para supervisar el uso de las cuentas temporales y asegurarte de que no excedan los presupuestos.

3. Limita los accesos: Configura políticas de IAM estrictas para evitar que los usuarios accedan a recursos no autorizados.

Enlace al repositorio

Consulta el repositorio oficial para obtener más detalles y acceder a actualizaciones:
Sandbox Accounts for Events en GitHub.

Conclusión

Sandbox Accounts for Events es una herramienta poderosa para gestionar entornos temporales en AWS. Su capacidad de automatizar la creación, asignación y limpieza de cuentas permite a los organizadores centrarse en el contenido de los eventos, en lugar de en la administración de los recursos.

Con esta solución, podes ofrecer experiencias de aprendizaje y desarrollo seguras y escalables, optimizando tanto la seguridad como los costos.

¿Por qué trabajar como DevOps/SRE?

Antes de sumergirnos en el mar de tecnologías, hay que tener algo claro: DevOps no es solo aprender herramientas - es toda una forma de pensar y trabajar que une desarrollo y operaciones. Es como ser el puente entre quienes crean el software y quienes lo mantienen funcionando. ¡Y sí, se paga bastante bien! 😉

Las herramientas que realmente importan

El repo que encontré es una mina de oro con más de 860 ejercicios. Pero tranquilo, no necesitas dominarlo todo para empezar. Aquí te dejo lo más jugoso:

Lo básico (pero súper importante)

• Linux: El rey indiscutible de los servidores. Si no lo conoces, por aquí hay que empezar.

• Git: Donde guardamos todo nuestro código. Sin esto no vas a ningún lado.

• Docker: La magia que hace que todo funcione igual en todas partes.

Para automatizar todo

• Jenkins: El mayordomo que hace todo el trabajo pesado por ti.

• Kubernetes: El director de orquesta de tus contenedores. Suena intimidante, pero una vez que le agarras el truco, ¡es genial!

• Ansible: Para automatizar esas tareas repetitivas que todos odiamos.

La nube ☁️

• AWS, Azure y GCP: Los tres grandes del cloud. AWS es como el hermano mayor que todos conocen.

• Terraform: Para crear infraestructura escribiendo código. ¡Es como jugar Minecraft pero en modo profesional!

Para saber si todo funciona bien

• Prometheus: Tu detector de problemas personal.

• Elastic Stack: Para almacenar logs

Por dónde empezar (sin volverse loco)

Lo mejor de este repo es que puedes ir a tu ritmo. No necesitas convertirte en expert@ en todo de la noche a la mañana. De hecho, es mejor que no lo intentes - tu cerebro te lo agradecerá.

Tips para no morir en el intento

1. Empieza por lo básico: Linux y Git. Son como el ABC del DevOps.

2. Échale un ojo a AWS - todo el mundo lo usa y hay toneladas de recursos gratis para aprender.

3. Juega con Docker - es divertido y super útil.

4. No te asustes con Kubernetes al principio - ya llegará su momento.

5. Aprende a automatizar cosas simples primero - la satisfacción de ver algo funcionando solo es increíble.

Para cerrar...

¿Parece mucho? Sí. ¿Vale la pena? ¡Totalmente! El truco está en no querer aprenderlo todo de golpe. Es como comerse un elefante - hay que ir bocado a bocado 🐘

Lo más importante es empezar y divertirse en el proceso. DevOps es un viaje largo, pero con recursos como este repo, al menos tienes un buen mapa para no perderte.

Este artículo está basado en las siguientes fuentes oficiales:

• Sitio web oficial: https://12factor.net/

• Repositorio GitHub: https://github.com/twelve-factor/twelve-factor

• Blog oficial: https://12factor.net/blog

Los Doce Factores

1. CodeBase (Base de Código)

Principio: Una base de código versionada en control de revisión, múltiples despliegues.

• Correlación uno a uno entre el repositorio y la aplicación

• Mismo código base para todos los entornos

• Múltiples despliegues representan diferentes instancias de la misma aplicación

2. Dependencies (Dependencias)

Principio: Declarar y aislar dependencias explícitamente.

• Declaración explícita de todas las dependencias

• Uso de sistemas de gestión de dependencias

• No dependencias implícitas del sistema

3. Config (Configuración)

Principio: Almacenar la configuración en el entorno.

• Separación estricta de configuración y código

• Variables de entorno como configuración

• No credenciales en el código

4. Backing Services (Servicios de Respaldo)

Principio: Tratar los servicios de respaldo como recursos adjuntos.

• Servicios externos tratados como recursos

• Intercambiables sin cambios en el código

• Base de datos, colas, servicios de correo, etc.

5. Build, Release, Run (Construcción, Liberación, Ejecución)

Principio: Separación estricta entre las etapas de construcción y ejecución.

• Etapa de construcción: transformar código en bundle

• Etapa de liberación: combinar bundle con configuración

• Etapa de ejecución: correr la aplicación

6. Processes (Procesos)

Principio: Ejecutar la aplicación como uno o más procesos sin estado.

• Procesos sin estado y que no comparten nada

• Los datos persistentes se almacenan en servicios de respaldo

• No sesiones sticky

7. Port Binding (Vinculación de Puertos)

Principio: Exportar servicios mediante vinculación de puertos.

• La aplicación es completamente autónoma

• Expone servicios vía puerto

• No depende de servidores web en tiempo de ejecución

8. Concurrency (Concurrencia)

Principio: Escalar mediante el modelo de procesos.

• Procesos como primera clase ciudadana

• Diseño para manejar cargas diversas

• Escalado horizontal de procesos

9. Disposability (Desechabilidad)

Principio: Maximizar la robustez con inicio rápido y apagado gracioso.

• Procesos desechables

• Inicio rápido

• Apagado gracioso cuando reciben SIGTERM

10. Dev/Prod Parity (Paridad Dev/Prod)

Principio: Mantener desarrollo, staging y producción lo más similares posible.

• Minimizar gaps entre entornos

• Mismo backing services en todos los entornos

• Mismo código y configuraciones (con valores diferentes)

11. Logs (Registros)

Principio: Tratar los logs como flujos de eventos.

• Logs como flujos de eventos

• No gestionar archivos de log

• Delegar a servicios de agregación

12. Admin Processes (Procesos de Administración)

Principio: Ejecutar tareas de administración/gestión como procesos únicos.

• Procesos admin como parte del código

• Mismo entorno que procesos regulares

• Código admin versionado con la aplicación

Relaciones entre los Factores

Beneficios de Aplicar los Twelve-Factors

1. Portabilidad

   • Aplicaciones que pueden ejecutarse en cualquier proveedor cloud

   • Minimización de dependencias con el entorno

   • Facilidad de migración entre plataformas

   • Reducción del vendor lock-in

2. Escalabilidad

   • Arquitectura que soporta crecimiento horizontal

   • Procesamiento distribuido eficiente

   • Mejor manejo de cargas variables

   • Optimización de recursos

3. Mantenibilidad

   • Código más limpio y organizado

   • Separación clara de responsabilidades

   • Reducción de la deuda técnica

   • Facilitación del onboarding de nuevos desarrolladores

4. Desarrollo Ágil

   • Flujos de trabajo optimizados

   • Despliegues más rápidos y seguros

   • CI/CD simplificado

   • Reducción del tiempo de desarrollo

5. Confiabilidad

   • Sistemas más robustos

   • Recuperación automática de fallos

   • Mejor observabilidad

   • Gestión eficiente de logs y monitoreo

Desafíos Comunes

1. Transición Cultural

   • Cambio en la mentalidad de desarrollo

   • Adopción de nuevas prácticas

   • Resistencia al cambio

2. Complejidad Técnica

   • Curva de aprendizaje inicial

   • Necesidad de nuevas herramientas

   • Refactorización de aplicaciones existentes

3. Inversión Inicial

   • Tiempo de capacitación

   • Recursos para la transformación

   • Posible impacto en la velocidad inicial de desarrollo

La metodología Twelve-Factor App proporciona un marco sólido para construir aplicaciones modernas que son:

• Nativas para la nube

• Escalables

• Mantenibles

• Portables

Esta metodología no solo define principios técnicos, sino que también establece un estándar para la cultura DevOps moderna. Al seguir estos principios, las organizaciones pueden:

• Reducir costos operativos

• Mejorar la calidad del software

• Aumentar la velocidad de entrega

• Facilitar la innovación

¿Preguntas? ¿Comentarios? Comparte tus experiencias implementando estos principios en tus proyectos.

Este artículo forma parte de una serie sobre la implementación de Twelve-Factor App en AWS. Síguenos para no perderte los próximos artículos donde profundizaremos en cada factor.

1. Configurar SonarQube

Antes de comenzar, asegúrate de tener una instancia de SonarQube en ejecución. Puedes configurar SonarQube en un servidor dedicado o utilizar una instancia de EC2 en AWS. Si prefieres, también puedes utilizar SonarCloud, que es la versión en la nube de SonarQube (requiere suscripción).

2. Crear un Proyecto en SonarQube

• Inicia sesión en tu instancia de SonarQube.

• Crea un proyecto nuevo y genera un token de autenticación. Este token se utilizará para integrar SonarQube en tu pipeline de AWS CodePipeline.

3. Configurar AWS CodeBuild

La integración de SonarQube se realiza durante la fase de construcción en CodeBuild. Aquí es donde ejecutarás el escaneo de SonarQube.

a. Modificar buildspec.yml

El archivo buildspec.yml debe configurarse para ejecutar el análisis de SonarQube utilizando un plugin o un script.

Ejemplos por Lenguaje

Java (Maven)

version: 0.2

phases:
  install:
    commands:
      - echo "Instalando dependencias..."
      - mvn install -DskipTests=true
  build:
    commands:
      - echo "Ejecutando análisis de SonarQube..."
      - mvn sonar:sonar \
          -Dsonar.projectKey=my_project_key \
          -Dsonar.host.url=http://<SONARQUBE_URL>:9000 \
          -Dsonar.login=<SONARQUBE_TOKEN>
  post_build:
    commands:
      - echo "Build completado. Revisando resultados de SonarQube..."
artifacts:
  files:
    - target/**
  discard-paths: yes

Reemplaza <SONARQUBE_URL> con la URL de tu instancia de SonarQube y <SONARQUBE_TOKEN> con el token generado.

Node.js

version: 0.2

phases:
  install:
    commands:
      - echo "Instalando SonarScanner..."
      - npm install -g sonarqube-scanner
  build:
    commands:
      - echo "Ejecutando análisis de SonarQube..."
      - sonarqube-scanner \
          -Dsonar.projectKey=my_project_key \
          -Dsonar.sources=. \
          -Dsonar.host.url=http://<SONARQUBE_URL>:9000 \
          -Dsonar.login=<SONARQUBE_TOKEN>
  post_build:
    commands:
      - echo "Build completado. Revisando resultados de SonarQube..."
artifacts:
  files:
    - coverage/*
  discard-paths: yes

Este ejemplo instala el SonarScanner para Node.js y ejecuta el análisis.

PHP

version: 0.2

phases:
  install:
    commands:
      - echo "Instalando Composer..."
      - curl -sS https://getcomposer.org/installer | php
      - php composer.phar install
  build:
    commands:
      - echo "Ejecutando análisis de SonarQube..."
      - sonar-scanner \
          -Dsonar.projectKey=my_project_key \
          -Dsonar.sources=. \
          -Dsonar.host.url=http://<SONARQUBE_URL>:9000 \
          -Dsonar.login=<SONARQUBE_TOKEN>
  post_build:
    commands:
      - echo "Build completado. Revisando resultados de SonarQube..."
artifacts:
  files:
    - build/
  discard-paths: yes

En PHP, SonarScanner se ejecuta después de instalar las dependencias con Composer.

Golang (Go)

version: 0.2

phases:
  install:
    commands:
      - echo "Instalando Go y dependencias..."
      - wget https://golang.org/dl/go1.16.3.linux-amd64.tar.gz
      - tar -C /usr/local -xzf go1.16.3.linux-amd64.tar.gz
      - export PATH=$PATH:/usr/local/go/bin
      - go mod download
  build:
    commands:
      - echo "Ejecutando análisis de SonarQube..."
      - sonar-scanner \
          -Dsonar.projectKey=my_project_key \
          -Dsonar.sources=. \
          -Dsonar.host.url=http://<SONARQUBE_URL>:9000 \
          -Dsonar.login=<SONARQUBE_TOKEN>
  post_build:
    commands:
      - echo "Build completado. Revisando resultados de SonarQube..."
artifacts:
  files:
    - bin/*
  discard-paths: yes

En Go, SonarScanner se ejecuta después de descargar las dependencias.

Python

version: 0.2

phases:
  install:
    commands:
      - echo "Instalando SonarScanner..."
      - pip install sonar-scanner
  build:
    commands:
      - echo "Ejecutando análisis de SonarQube..."
      - sonar-scanner \
          -Dsonar.projectKey=my_project_key \
          -Dsonar.sources=. \
          -Dsonar.host.url=http://<SONARQUBE_URL>:9000 \
          -Dsonar.login=<SONARQUBE_TOKEN>
  post_build:
    commands:
      - echo "Build completado. Revisando resultados de SonarQube..."
artifacts:
  files:
    - reports/*
  discard-paths: yes

En Python, SonarScanner se instala y ejecuta utilizando pip.

4. Configurar AWS CodePipeline

a. Fase de construcción

Dentro de CodePipeline, añade una fase de construcción que utilice el proyecto de CodeBuild donde has configurado el análisis de SonarQube.

1. Crear/editar tu pipeline de CodePipeline:

   • Añade una fase de construcción si no tienes una.

   • Configura la acción de construcción para que use el proyecto de CodeBuild que configuraste en el paso anterior.

b. Resultados del análisis

SonarQube almacenará los resultados del análisis en su base de datos y proporcionará un tablero de control donde podrás revisar los problemas de calidad del código y las vulnerabilidades.

5. Configurar Notificaciones y Gestión de Calidad (Opcional)

Puedes configurar SonarQube para que notifique al equipo de desarrollo si se encuentran problemas críticos o errores en el código. SonarQube también se puede configurar para establecer un "quality gate" que debe pasarse antes de permitir que el código se despliegue.

6. Ejemplo con Docker (Opcional)

Si prefieres ejecutar el análisis de SonarQube a través de un contenedor Docker en lugar de usar Maven, Node.js, PHP, Go o Python directamente, puedes usar un enfoque como este en tu buildspec.yml:

version: 0.2

phases:
  install:
    commands:
      - echo "Instalando Docker..."
      - yum install -y docker
      - service docker start
  build:
    commands:
      - echo "Ejecutando análisis de SonarQube usando Docker..."
      - docker run --rm -e SONAR_HOST_URL="http://<SONARQUBE_URL>:9000" -e SONAR_LOGIN="<SONARQUBE_TOKEN>" -v "$(pwd):/usr/src" sonarsource/sonar-scanner-cli
artifacts:
  files:
    - sonar-scanner-report.html
  discard-paths: yes

Este ejemplo utiliza el contenedor Docker oficial de SonarScanner para realizar el análisis.

7. Integración con Otros Sistemas

SonarQube tiene integraciones con herramientas de CI/CD, Jira, GitHub, Bitbucket, etc. Puedes utilizar estas integraciones para reportar automáticamente problemas de calidad o bloquear merges en tus repositorios si el análisis no cumple con el estándar de calidad.

Integrar SonarQube en tu pipeline de AWS CodePipeline te permite ejecutar análisis de calidad de código de manera automatizada. CodeBuild es el componente que realiza el escaneo de SonarQube, y puedes configurar tu buildspec.yml para ejecutar el análisis según tus necesidades. La integración de SonarQube en tu pipeline te ayudará a mantener un alto estándar de calidad en tu código y detectar posibles vulnerabilidades de seguridad antes de que lleguen a producción.

1. Configuración Inicial

1. Instala AWS CLI: Si aún no tienes la AWS CLI instalada, sigue las instrucciones de AWS CLI Installation Guide.

2. Configura AWS CLI: Ejecuta aws configure y proporciona tus credenciales de AWS (Access Key ID, Secret Access Key, región, y formato de salida).

3. Crea un Repositorio en ECR: Para almacenar la imagen Docker, debes crear un repositorio en Amazon ECR (Elastic Container Registry).

    aws ecr create-repository --repository-name flask-app --region your-region
   

   Reemplaza your-region por tu región de AWS.

4. Inicia Sesión en ECR: Usa el siguiente comando para autenticar Docker en ECR.

    aws ecr get-login-password --region your-region | docker login --username AWS --password-stdin <aws-account-id>.dkr.ecr.your-region.amazonaws.com
   

5. Construye y Suba la Imagen a ECR:

   • Construye la imagen Docker.

       docker build -t flask-app .
     

   • Etiqueta la imagen con la URL de tu repositorio de ECR.

       docker tag flask-app:latest <aws-account-id>.dkr.ecr.your-region.amazonaws.com/flask-app:latest
     

   • Sube la imagen a ECR.

       docker push <aws-account-id>.dkr.ecr.your-region.amazonaws.com/flask-app:latest
     

2. Crear el Clúster de ECS

1. Crea el Clúster: Puedes crear un clúster ECS usando Fargate o EC2. Aquí usaremos Fargate.

    aws ecs create-cluster --cluster-name flask-cluster
   

3. Crear una Tarea de ECS

1. Define la Tarea de ECS: La tarea es la definición de cómo se ejecutará tu contenedor. Puedes crear una definición de tarea JSON o usar la CLI. Aquí un ejemplo de un archivo JSON para la definición de tarea.

   Crea un archivo llamado task-definition.json con el siguiente contenido:

    {
      "family": "flask-task",
      "networkMode": "awsvpc",
      "containerDefinitions": [
        {
          "name": "flask-container",
          "image": "<aws-account-id>.dkr.ecr.your-region.amazonaws.com/flask-app:latest",
          "portMappings": [
            {
              "containerPort": 80,
              "hostPort": 80,
              "protocol": "tcp"
            }
          ],
          "essential": true
        }
      ],
      "requiresCompatibilities": ["FARGATE"],
      "cpu": "256",
      "memory": "512",
      "executionRoleArn": "arn:aws:iam::<aws-account-id>:role/ecsTaskExecutionRole",
      "networkConfiguration": {
        "awsvpcConfiguration": {
          "subnets": ["subnet-xxxxxxxx"],
          "securityGroups": ["sg-xxxxxxxx"],
          "assignPublicIp": "ENABLED"
        }
      }
    }
   

2. Registrar la Definición de Tarea: Usa el siguiente comando para registrar la definición de tarea.

    aws ecs register-task-definition --cli-input-json file://task-definition.json
   

4. Crear un Servicio ECS

1. Crear el Servicio ECS: El servicio ECS se encarga de ejecutar y mantener tu tarea. Usa el siguiente comando para crear un servicio que ejecute la tarea.

    aws ecs create-service \
    --cluster flask-cluster \
    --service-name flask-service \
    --task-definition flask-task \
    --desired-count 1 \
    --launch-type FARGATE \
    --network-configuration "awsvpcConfiguration={subnets=[subnet-xxxxxxxx],securityGroups=[sg-xxxxxxxx],assignPublicIp=ENABLED}"
   

5. Configuración de Balanceador de Carga (Opcional)

Si necesitas un balanceador de carga (por ejemplo, ALB), sigue estos pasos adicionales:

1. Crea un Application Load Balancer (ALB) desde la consola de EC2 y configura un grupo de destino que apunte a tus tareas ECS.

2. Asocia el ALB con el Servicio ECS en la definición del servicio utilizando el ARN del ALB.

6. Acceder a la Aplicación

Una vez que el servicio esté corriendo, puedes acceder a la aplicación Flask a través de la IP pública asignada a la tarea o mediante el DNS del Load Balancer si configuraste uno.

Resumen

• Sube la imagen Docker a ECR.

• Crea un clúster de ECS.

• Define y registra la tarea que ejecuta el contenedor.

• Crea un servicio ECS para mantener la tarea en ejecución.

• (Opcional) Configura un balanceador de carga para manejar el tráfico a las tareas.

Con esto deberías tener tu aplicación Flask desplegada y accesible en AWS ECS.

Casos Comunes donde se Necesita SSH en un Contenedor Docker

1. Depuración en Producción: A veces, cuando un entorno de producción no funciona como se espera, el acceso SSH puede ser una herramienta poderosa para depurar en tiempo real.

2. Ejecución de Comandos Manuales: Si necesitas ejecutar scripts manualmente o comandos de mantenimiento dentro del contenedor.

3. Acceso a Archivos de Configuración: Si necesitas modificar archivos de configuración directamente en el contenedor para ajustar comportamientos de la aplicación o del servidor.

4. Automatización Limitada: En escenarios donde la automatización no cubre todos los casos, el acceso SSH permite realizar ajustes manuales temporales.

Dockerfile para Instalar SSH en una Aplicación PHP

A continuación, te dejo un ejemplo de cómo configurar SSH en tu contenedor Docker para una aplicación PHP. Este Dockerfile instala el servidor SSH y configura un acceso de usuario root con contraseña.

# Usar una imagen base de Ubuntu 20.04
FROM ubuntu:20.04

# Instalar actualizaciones y dependencias
RUN apt-get update && apt-get install -y \
    apache2 \
    php \
    libapache2-mod-php \
    openssh-server

# Crear el directorio para el proceso de SSH
RUN mkdir /var/run/sshd

# Configurar la contraseña del usuario root (cambia 'your_password' por tu contraseña deseada)
RUN echo 'root:your_password' | chpasswd

# Permitir acceso root a través de SSH
RUN sed -i 's/PermitRootLogin prohibit-password/PermitRootLogin yes/' /etc/ssh/sshd_config

# Ajustar la configuración de PAM para SSH
RUN sed 's@session\s*required\s*pam_loginuid.so@session optional pam_loginuid.so@g' -i /etc/pam.d/sshd

# Habilitar módulos de Apache y limpiar la instalación
RUN a2enmod rewrite && apt-get clean

# Exponer el puerto 22 para SSH y el puerto 80 para Apache
EXPOSE 22 80

# Iniciar el servicio SSH y Apache
CMD service apache2 start && /usr/sbin/sshd -D

Explicación del Dockerfile:

• Instalación de SSH: La línea apt-get install -y openssh-server instala el servidor SSH en el contenedor.

• Directorio SSH: El comando mkdir /var/run/sshd crea el directorio necesario para que el servicio SSH funcione.

• Contraseña del root: El comando echo 'root:your_password' | chpasswd establece una contraseña para el usuario root. Asegúrate de cambiar your_password por una contraseña segura.

• Permitir Acceso Root por SSH: Modificamos el archivo de configuración de SSH para permitir el acceso al usuario root con contraseña.

• Ajustes de PAM: Este ajuste permite que el servicio SSH funcione correctamente en entornos Docker.

• Exposición del Puerto 22: SSH utiliza el puerto 22, así que lo exponemos en el contenedor.

Deployment de Kubernetes para la Aplicación PHP con SSH

Ahora, veamos cómo configurar un Deployment en Kubernetes que incluya la ejecución de SSH junto con Apache:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: php-ssh-deployment
spec:
  replicas: 1
  selector:
    matchLabels:
      app: php-ssh
  template:
    metadata:
      labels:
        app: php-ssh
    spec:
      containers:
      - name: php-ssh-container
        image: tu-imagen:latest
        ports:
        - containerPort: 80  # Puerto para Apache
        - containerPort: 22  # Puerto para SSH
        command: ["/bin/sh", "-c"]
        args:
          - service apache2 start && /usr/sbin/sshd -D;
        resources:
          limits:
            cpu: "500m"
            memory: "512Mi"
          requests:
            cpu: "200m"
            memory: "256Mi"

Explicación del Deployment:

• Especificación del Contenedor: Usamos una imagen Docker que incluye Apache y SSH configurado.

• Comando y Argumentos: Iniciamos tanto el servidor Apache como el servidor SSH cuando el contenedor se ejecuta.

• Puertos: Exponemos tanto el puerto 80 (para Apache) como el puerto 22 (para SSH) en el contenedor.

Configurar SSH en un contenedor Docker para una aplicación PHP puede ser muy útil en varios escenarios de depuración y mantenimiento. Este artículo te proporciona una guía paso a paso para instalar y configurar SSH en tu contenedor y luego desplegarlo en un clúster Kubernetes. Sin embargo, es importante recordar que el acceso SSH a contenedores en producción debe ser utilizado con precaución y siempre asegurando el entorno con contraseñas seguras y controles de acceso adecuados.

Este método puede ser particularmente útil para tareas de administración rápida o depuración que requieren acceso directo al contenedor. Sin embargo, siempre es recomendable automatizar y mantener buenas prácticas de seguridad en tus entornos de contenedores y Kubernetes.