Módulo 1: Genai In Production Vs A Notebook

5. Manos a la obra: inventario de lo que ya existe

Siguiente →

Descripción

Antes de declarar un solo recurso nuevo, esta lección hace exactamente lo que la disciplina de "verificar antes de construir" —ya instalada en las siete guías anteriores— exige: confirmar, con comandos reales de awslocal, qué existe hoy en andes-cargo-infra/. No un resumen en prosa de lo que las guías anteriores dijeron que construyeron — los tres comandos exactos que confirmarían ese inventario, corridos contra la infraestructura heredada, con la salida que producirían reconstruida campo por campo a partir del HCL real y de los despliegues que esas guías ya verificaron.

Conexión con el módulo

Las lecciones 1 a 4 dieron el mapa, la teoría y la frontera. Esta lección es la primera de este módulo que toca una terminal — el primer contacto de esta guía con la infraestructura real de Andes Cargo. Todo lo que confirmes aquí es exactamente lo que la lección 6 va a suponer que ya conoces, y exactamente lo que el M3 de esta guía va a extender con bedrock.tf.

La honestidad exacta de esta lección, antes del primer comando

Esta lección corre tres comandos awslocal — events list-rules, lambda list-functions, iam list-roles — contra servicios que sí están incluidos en el plan gratuito Hobby de LocalStack (EventBridge, Lambda e IAM, los mismos que aws-core-services-guide y aws-serverless-and-containers-guide ya confirmaron y usaron desde su primera lección práctica). Esto es distinto, y vale la pena decirlo con precisión, del límite que vas a ver en la lección 7 de este mismo módulo: ahí, ningún plan gratuito de LocalStack incluye Bedrock, sin importar qué token uses. Aquí, el servicio sí está disponible en Hobby — el límite es exclusivamente de este entorno específico de escritura, que no tiene un LOCALSTACK_AUTH_TOKEN exportado, así que el contenedor de LocalStack no arranca (Could not connect to the endpoint URL), el mismo límite puntual, con el mismo mensaje, que ya viste citado en cloud-security-and-guardrails-guide y finops-and-cost-guardrails-guide. En tu propia máquina, con un token de LocalStack registrado (el plan Hobby es gratuito, solo exige una cuenta), estos tres comandos corren de verdad y devuelven exactamente esta salida — porque es exactamente la que produjo el HCL real, ya aplicado, de las guías anteriores.

Cada bloque "Qué esperar" de esta lección lleva la etiqueta "(representativo)", reconstruido campo por campo contra el estado real y verificado de andes-cargo-infra/ al cierre de aws-serverless-and-containers-guide — nunca inventado.

Comando 1 — Las funciones Lambda activas

awslocal lambda list-functions --query 'Functions[].FunctionName'

Qué esperar (representativo — reconstruido contra el estado final documentado en aws-serverless-and-containers-guide, Módulo 8, donde get-shipment-status queda explícitamente retirada al reemplazarse por el contenedor andes-cargo-status-api):

[
    "process-shipment-manifest",
    "validate-shipment-manifest",
    "notify-shipment-partner"
]

Tres funciones, ninguna de IA todavía. process-shipment-manifest es la que ya conoces de la lección 3 de este módulo. validate-shipment-manifest y notify-shipment-partner son los otros dos pasos de ShipmentManifestWorkflow —validación previa y notificación posterior al procesamiento—, heredados de aws-serverless-and-containers-guide sin que esta guía los toque. Fíjate en lo que no aparece: get-shipment-status existió hasta el M8 de esa guía, y fue retirada deliberadamente al migrar GET /shipments/{shipmentId} de una integración Lambda a una integración con el contenedor andes-cargo-status-api — este inventario refleja ese estado final, no un punto intermedio.

Comando 2 — Los roles IAM que ya existen

awslocal iam list-roles --query 'Roles[].RoleName'

Qué esperar (representativo — mismo criterio: solo los roles que las guías anteriores efectivamente aplicaron contra LocalStack, ninguno de los marcados como representativo en su propia guía de origen):

[
    "LambdaManifestProcessorRole",
    "AppServerRole",
    "ShipmentWorkflowExecutionRole",
    "EventBridgeAutomationRole",
    "AndesCargoDeployRole"
]

Los primeros dos vienen de aws-core-services-guide — LambdaManifestProcessorRole para process-shipment-manifest, AppServerRole para la instancia que sirve la app. Los siguientes dos son de aws-serverless-and-containers-guide — ShipmentWorkflowExecutionRole para ShipmentManifestWorkflow, EventBridgeAutomationRole para las reglas y el schedule de EventBridge. El último, AndesCargoDeployRole, es de cloud-security-and-guardrails-guide — el rol de despliegue con trust policy condicionada a OIDC de GitHub Actions. Ningún rol de esta lista tiene ningún permiso relacionado con Bedrock — la convención de nombrado, PascalCase descriptivo con sufijo Role, es exactamente la que vas a ver aplicada al rol nuevo de esta guía, BedrockManifestExtractorRole, desde el M3.

Comando 3 — Las reglas de EventBridge, en los dos buses

Esta es la parte más reveladora del inventario, y la que conecta directamente con la lección 3. Corre el comando dos veces —una por cada bus que existe hoy—:

awslocal events list-rules --event-bus-name default

Qué esperar (representativo):

{
    "Rules": [
        {
            "Name": "shipment-manifest-uploaded-rule",
            "Arn": "arn:aws:events:us-east-1:000000000000:rule/shipment-manifest-uploaded-rule",
            "EventPattern": "{\"source\":[\"aws.s3\"],\"detail-type\":[\"Object Created\"],\"detail\":{\"bucket\":{\"name\":[\"andes-cargo-shipment-docs\"]},\"object\":{\"key\":[{\"prefix\":\"manifests/\"}]}}}",
            "State": "ENABLED",
            "Description": "Starts ShipmentManifestWorkflow when a new manifest gets uploaded to andes-cargo-shipment-docs",
            "EventBusName": "default"
        }
    ]
}
awslocal events list-rules --event-bus-name andes-cargo-events

Qué esperar (representativo):

{
    "Rules": []
}

Léelo con cuidado — es el hallazgo central de esta lección. El bus default tiene exactamente una regla: la que conecta la subida de un manifiesto en S3 con el arranque de ShipmentManifestWorkflow. El bus personalizado andes-cargo-events —el que ShipmentProcessed y ShipmentDelayed ya usan para anunciarse cada vez que un envío se procesa o se retrasa— no tiene ninguna regla todavía. Los eventos se publican, de verdad, cada vez que el workflow corre con éxito — pero, hoy, nada en andes-cargo-infra/ reacciona a ellos. Es exactamente el espacio vacío donde ManifestParseFailed va a aparecer: el M3 de esta guía declara la primera regla real que ese bus va a tener, cerrando un círculo que las guías anteriores dejaron, a propósito, abierto.

El inventario completo, en un solo diagrama

   ANDES CARGO — ESTADO HEREDADO, AL ABRIR ESTA GUÍA

   Lambdas activas                    Roles IAM activos
   ─────────────────                  ──────────────────
   process-shipment-manifest          LambdaManifestProcessorRole
   validate-shipment-manifest         AppServerRole
   notify-shipment-partner            ShipmentWorkflowExecutionRole
                                       EventBridgeAutomationRole
                                       AndesCargoDeployRole

   Bus default                        Bus andes-cargo-events
   ─────────────                      ────────────────────────
   shipment-manifest-uploaded-rule    (ninguna regla todavía)
   → arranca ShipmentManifestWorkflow    ShipmentProcessed  ┐
                                          ShipmentDelayed    ┴─ se publican,
                                                                nadie escucha

   ═══════════════════════════════════════════════════════════
   Lo que esta guía agrega, empezando en el M3:

     BedrockManifestExtractorRole      ← nuevo rol IAM
     extract-shipment-manifest-fields  ← nueva Lambda
     regla sobre andes-cargo-events    ← escucha ManifestParseFailed
   ═══════════════════════════════════════════════════════════

Errores comunes

Correr estos comandos contra tu propia LocalStack y esperar exactamente la misma salida, sin haber corrido las siete guías anteriores (de expectativa). Qué pasa: alguien salta directamente a esta guía, corre lambda list-functions, y solo ve una lista vacía o un subconjunto de estas tres funciones. Cómo detectarlo: si tu salida real no coincide con la de esta lección. Cómo corregirlo: esta salida representa el estado de andes-cargo-infra/ después de completar las siete guías anteriores, con cada terraform apply corrido en orden. Si tu inventario real es distinto, la causa más probable es que falta alguna de esas guías, no un error de esta lección.

Confundir "representativo por falta de token" con "representativo porque el servicio no existe en Hobby" (de lectura, el mismo error que la lección 1 de este módulo ya anticipó). Qué pasa: alguien lee "(representativo)" en esta lección y en la lección 7 de este mismo módulo, y asume que la razón es la misma en ambas. Cómo detectarlo: si no puedes explicar, sin mirar atrás, por qué EventBridge/Lambda/IAM sí corren en Hobby pero Bedrock no. Cómo corregirlo: EventBridge, Lambda e IAM están confirmados en el plan gratuito Hobby de LocalStack desde aws-core-services-guide — el límite de esta lección es exclusivamente que este entorno de escritura no tiene un token exportado, algo que se resuelve registrándose gratis. Bedrock, en la lección 7, es un límite distinto y más duro: ni siquiera con un token de Hobby está disponible — solo el plan de pago Ultimate lo incluye.

Concluir que el bus andes-cargo-events "no sirve para nada" porque no tiene ninguna regla (de alcance). Qué pasa: alguien ve "Rules": [] sobre ese bus y concluye que fue un error dejarlo sin conectar. Cómo detectarlo: si tu reacción es "entonces para qué existe este bus". Cómo corregirlo: un bus de EventBridge no necesita tener una regla para que publicar eventos en él tenga sentido — es exactamente el patrón de desacoplamiento que aws-serverless-and-containers-guide enseñó: el productor (process-shipment-manifest, vía ShipmentManifestWorkflow) anuncia hechos sin saber ni necesitar saber quién, si alguien, va a reaccionar. El bus vacío de reglas hoy es, precisamente, el espacio de extensión que esta guía usa — no un descuido, un diseño que esperaba, a propósito, a esta guía.

Ejercicios

Ejercicio 1 — Explica por qué get-shipment-status no aparece en el Comando 1. Un compañero que solo hizo hasta el Módulo 5 de aws-serverless-and-containers-guide te pregunta por qué esta lección no incluye esa función en el inventario, si él la recuerda de esa guía. Explícale qué cambió.

Ver solución

get-shipment-status existió como función Lambda real desde el Módulo 5 de aws-serverless-and-containers-guide, sirviendo GET /shipments/{shipmentId} a través de una integración AWS_PROXY de API Gateway. En el Módulo 8 de esa misma guía (el capstone), esa integración se migró a HTTP_PROXY, apuntando al contenedor andes-cargo-status-api en su lugar — el mismo recurso público (Resource y Method de API Gateway sin cambios), pero con un backend distinto. Como consecuencia, la función Lambda get-shipment-status queda retirada — este inventario, tomado al cierre de esa guía, refleja el estado final, donde esa función ya no existe.

Ejercicio 2 — Predice qué cambiaría en el Comando 3 después de completar el M3 de esta guía. Sin mirar adelante en esta guía, predice qué aparecería en "Rules": [] del bus andes-cargo-events una vez que el M3 declare la infraestructura de la carga de IA.

Ver solución

Aparecería una regla nueva, análoga en estructura a shipment-manifest-uploaded-rule pero filtrando por el evento ManifestParseFailed en vez de por Object Created de S3 — algo con un nombre coherente con la convención existente, por ejemplo manifest-parse-failed-rule, con un EventPattern que filtre "source": ["andescargo.shipments"] y "detail-type": ["Manifest Parse Failed"], y un target que invoque extract-shipment-manifest-fields. El bus andes-cargo-events, hoy vacío de reglas, tendría entonces exactamente una — el primer consumidor real de los eventos que ese bus ya publica desde aws-serverless-and-containers-guide.

Ejercicio 3 — Explica la diferencia entre "representativo por falta de token" y "representativo por límite de plan", con tus propias palabras. Sin mirar la sección de honestidad de esta lección, explica a un compañero por qué esta lección y la lección 7 de este mismo módulo usan la misma etiqueta "(representativo)" por dos razones técnicas distintas.

Ver solución

Una respuesta completa suena, más o menos, así: "En esta lección, los tres servicios que consultamos —EventBridge, Lambda, IAM— sí están incluidos en el plan gratuito Hobby de LocalStack; lo único que falta es un LOCALSTACK_AUTH_TOKEN exportado en este entorno específico de escritura, así que el contenedor nunca arranca. Cualquiera que se registre gratis y exporte su propio token vería esta misma salida, literal, corriendo de verdad. En la lección 7, en cambio, el límite no es de este entorno — es del servicio mismo: Bedrock no está incluido en ningún plan por debajo de Ultimate, de pago, así que ni con un token de Hobby registrado correría. Una es una limitación de dónde estoy escribiendo esta guía; la otra es una limitación del servicio que la guía completa enseña a operar."

Resumen y siguiente paso

En esta lección corriste —representativamente, con la razón exacta declarada— el inventario real de andes-cargo-infra/: tres funciones Lambda activas, cinco roles IAM, una regla en el bus default, y cero reglas en el bus andes-cargo-events, a pesar de que ese bus ya publica ShipmentProcessed y ShipmentDelayed de verdad. Confirmaste, con comandos reales, el punto de partida exacto sobre el que se construye el resto de esta guía, y viste, con evidencia, el espacio vacío que ManifestParseFailed va a ocupar desde el M3.

Antes de avanzar deberías poder: nombrar las tres funciones Lambda activas y explicar por qué get-shipment-status ya no está; explicar por qué esta lección es "(representativo)" por una razón distinta a la de la lección 7; y describir, sin mirar atrás, el hallazgo central del Comando 3 — un bus que publica eventos que nadie todavía escucha.

La lección 6 cambia de terreno: en vez de inventariar lo que ya existe, mapea lo que Bedrock ofrece en 2026 — las familias de modelos disponibles, verificadas contra fuentes actuales, y la razón de fondo por la que el camino barato de la lección 3 sigue siendo el default incluso con todo ese catálogo disponible.

Recursos

  1. aws-serverless-and-containers-guide, Módulo 8 (08-project-the-andes-cargo-capstone-deliverable.md) — la fuente del estado final del sistema heredado que esta lección reconstruye.
  2. cloud-security-and-guardrails-guide, Módulo 2 — la fuente de AndesCargoDeployRole, el quinto rol de este inventario.
  3. LocalStack — Pricing — confirmación de que EventBridge, Lambda e IAM están incluidos en el plan gratuito Hobby, a diferencia de Bedrock (lección 7).
  4. AWS CLI — lambda list-functions · iam list-roles · events list-rules — referencias oficiales de los tres comandos de esta lección.
← Anterior4. La frontera con AI Engineering, dicha en voz altaSiguiente →6. Bedrock, panorama 2026: modelos, familias y por qué el camino barato sigue siendo el default