Módulo 8: Capstone The Andes Cargo Genai Extractor
7. Lo que Andes Cargo todavía necesita
Descripción
Esta guía completa —ocho módulos, sesenta y cuatro lecciones— construyó exactamente la infraestructura que la escala actual de Andes Cargo necesita: un camino de escalamiento barato de operar, con guardrails reales y un presupuesto que hoy redondea a cero dólares. Ninguna parte de ese trabajo asumió que Andes Cargo se va a quedar exactamente en este tamaño para siempre. Esta lección mira hacia adelante, con la misma honestidad exacta del resto de la guía: si el volumen de manifiestos escalados creciera lo suficiente, ¿qué necesitaría construirse que esta guía, deliberadamente, no construye? Y, con esa pregunta contestada, ¿qué le queda al ecosistema completo de AWS de NIEVA, más allá de esta guía?
Conexión con el módulo
La lección 6 cerró la frontera hacia atrás, hacia AI Engineering. Esta lección abre la frontera hacia adelante, hacia el resto del ecosistema aws-cloud-ecosystem — específicamente hacia kubernetes-and-eks-in-production-guide, la guía hermana que delega hacia aquí una pieza que este diseño, con evidencia, decide no construir tampoco. Es la última lección de contenido de esta guía antes del proyecto final.
Analogía: de contratar fletes por viaje a comprar tu propia flota de camiones
Una empresa de logística pequeña que empieza a crecer no compra su propia flota de camiones el primer día — contrata fletes por viaje, paga por cada envío individual, sin ninguna inversión fija. Esta guía dejó a Andes Cargo exactamente en esa etapa con su carga de IA: paga por invocación (on-demand), sin ningún compromiso fijo. Hay un punto, más adelante, donde el volumen de envíos crece tanto que contratar un flete por viaje deja de ser la opción más barata —ahí es donde una empresa de logística real empieza a evaluar comprar su propia flota—. Esta lección no dice que ese punto esté cerca; dice, con el mismo rigor de números que el resto de esta guía, exactamente qué tan lejos está, y qué tendría que construirse el día que se acerque.
Paso 1 — El primer umbral: Provisioned Throughput, ya cuantificado
El M6.7 de esta guía ya calculó, con dos caminos independientes de aritmética, el punto exacto donde comprar capacidad reservada de Bedrock (Provisioned Throughput) empezaría a costar menos que seguir pagando por invocación:
EL PRIMER UMBRAL, YA MEDIDO (M6.7)
Escenario realista (GENAI-COST-PROFILE.md) 40 invocaciones/mes
Escenario de estres (GENAI-COST-PROFILE.md) 5.000 invocaciones/mes
Escenario deliberadamente desproporcionado 100.000 invocaciones/mes
│
│ 2.593x de distancia
▼
Punto de cruce, compromiso de 6 meses 259.285.714 invocaciones/mesEste umbral no requiere ninguna infraestructura nueva que esta guía no haya nombrado ya — aws_bedrock_provisioned_model_throughput es, según el M6.2, un recurso real de Terraform, del mismo proveedor hashicorp/aws que aws_bedrock_guardrail ya usa. El día que Andes Cargo se acerque a ese volumen, la decisión seguiría viviendo dentro de Bedrock, sin necesitar GPU dedicada ni un clúster de Kubernetes — solo un cambio de nivel de compromiso sobre la misma infraestructura que esta guía ya declaró.
Paso 2 — El segundo umbral, más allá de lo que Bedrock resuelve: GPU dedicada
Hay un escenario distinto, más extremo, que ni Provisioned Throughput resuelve: que Andes Cargo, algún día, decida no usar un modelo gestionado de Bedrock en absoluto —por control total sobre el modelo, por un requisito de residencia de datos que ningún servicio gestionado de AWS satisface, o porque un modelo propio, ajustado específicamente para manifiestos de logística, superara en costo por token a cualquier oferta de Bedrock a un volumen suficientemente alto—. Ese escenario sí requeriría GPU dedicada: nodos con aceleradores reales, un motor de servido de modelos (por ejemplo, algo equivalente a lo que vLLM o TensorRT-LLM resuelven), y un orquestador de cómputo que sepa aprovisionar y desaprovisionar esa capacidad cara según la demanda.
Esta guía no construye ese escenario. Tampoco lo construye ninguna guía hermana de este ecosistema, hoy. El DISENO.md de kubernetes-and-eks-in-production-guide lo delega, explícitamente, hacia esta guía:
"GenAI sobre EKS (GPU en nodos, inferencia, Karpenter para cargas de IA, costo por token) →
genai-on-aws-production-guide(no diseñada aún)."
Y el DISENO.md de esta misma guía, con evidencia —no por evitar el trabajo—, decide no cumplir esa delegación:
POR QUE NINGUNA GUIA CONSTRUYE ESTE ESCENARIO
GPU dedicada requiere:
│
├── Nodos con aceleradores reales -- costo por hora real, sin
│ nivel gratuito en ningun plan de LocalStack, ni Ultimate
├── Un motor de servido de modelos corriendo de verdad
└── Trafico real que lo justifique
Andes Cargo, hoy:
│
├── 40-5.000 invocaciones/mes -- 2.593x por debajo del punto
│ de cruce de Provisioned Throughput (Paso 1), que YA es
│ mas barato que GPU dedicada a cualquier escala menor
└── Ningun caso de negocio que justifique control total sobre
un modelo propio -- el requisito no existe, no solo el $
Conclusion: nombrar el escenario, con precision, sin fingir un
camino $0 que no existe -- la misma disciplina de honestidad de
toda esta guia, aplicada aqui a una decision de NO construirEsta no es una laguna del ecosistema escondida — es una decisión declarada, con su razón, en ambos documentos de diseño: kubernetes-and-eks-in-production-guide nombra el escenario por contraste, sin construir nodegrupos de GPU ni provisionadores de Karpenter para inferencia; esta guía nombra el mismo escenario, con la misma honestidad, sin construirlo tampoco. Ninguna de las dos guías se contradice a costa de la otra — ambas coinciden en que el camino $0 no existe para este caso específico.
Paso 3 — El mapa completo: qué guía resuelve cada escala futura
| Si el volumen de Andes Cargo crece hasta... | La pieza que haría falta | Dónde viviría |
|---|---|---|
| Cientos de miles de invocaciones/mes, sin cambiar de modelo gestionado | Reevaluar Provisioned Throughput con datos reales (M6.7 ya deja la fórmula) | Dentro de esta misma guía — extensión de bedrock.tf, no una guía nueva |
| Un requisito real de control total sobre el modelo o residencia de datos | GPU dedicada, un motor de servido de modelos, Karpenter para cargas de IA | Sin guía asignada hoy — nombrado por kubernetes-and-eks-in-production-guide y por esta guía, construido por ninguna |
| Certificación formal del conocimiento acumulado en las ocho guías de este ecosistema | Repaso estructurado de todos los servicios de AWS, con el formato exacto del examen | aws-saa-certification-guide — el cierre declarado del ecosistema |
La fila del medio queda, con toda intención, sin una tercera columna llena — es el mismo tipo de faltante de ecosistema, sin guía asignada, que Organizations/Control Tower ya representa en otras partes de este mismo aws-cloud-ecosystem. Nombrarlo así, en vez de fingir una respuesta, es la disciplina que sostuvo toda esta guía desde el M1.7.
Paso 4 — El cierre del ecosistema: aws-saa-certification-guide
Las ocho guías de aws-cloud-ecosystem —incluida esta— construyeron, cada una, una porción operable y real de la infraestructura de Andes Cargo. aws-saa-certification-guide no agrega una porción nueva de infraestructura: es el repaso que convierte ese conocimiento operado en la credencial formal que un mercado laboral reconoce — la AWS Certified Solutions Architect – Associate. src/paths/aws-cloud-ecosystem/STRATEGY.md lo confirma con precisión: el examen aparece nombrado en la mayoría de las descripciones de puesto que ese documento analizó, y aws-saa-certification-guide es la guía que cierra el ecosistema completo, después de que el alumno ya operó —no solo estudió— cada servicio que el examen evalúa.
EL ECOSISTEMA COMPLETO, DE PRINCIPIO A FIN
aws-core-services-guide (servicios base)
aws-serverless-and-containers-guide (serverless, contenedores)
terraform-and-iac-guide (infraestructura como codigo)
cicd-and-gitops-on-aws-guide (pipelines)
cloud-security-and-guardrails-guide (seguridad)
finops-and-cost-guardrails-guide (costo)
sre-and-incident-response-guide (confiabilidad)
kubernetes-and-eks-in-production-guide (Kubernetes gestionado)
genai-on-aws-production-guide (esta guia -- IA generativa)
│
▼
aws-saa-certification-guide (cierre -- la credencial formal)Nueve guías construyen; una cierra con el examen. Esta lección, y esta guía, terminan exactamente donde STRATEGY.md dijo que terminarían desde el principio.
Errores comunes
Interpretar el Paso 2 como si esta guía "no pudo" construir GPU dedicada por falta de tiempo o alcance, en vez de por ausencia real de un camino $0 (de confundir una decisión de diseño con una limitación de recursos). Qué pasa: alguien lee que ninguna guía construye este escenario y asume que es, simplemente, contenido pendiente que algún día se agregará. Cómo detectarlo: si tu expectativa es "en una futura versión de esta guía, seguro agregan el módulo de GPU". Cómo corregirlo: el Paso 2 de esta lección es explícito — ningún plan de LocalStack, ni siquiera Ultimate, tiene un camino gratuito para GPU dedicada, y Andes Cargo, con su volumen real, no tiene un caso de negocio que lo justifique. No es una pieza "todavía no escrita" — es una pieza que este diseño decide, con evidencia, no escribir mientras esas dos condiciones se mantengan.
Asumir que Provisioned Throughput y GPU dedicada son la misma decisión, en distintos grados (de no distinguir dos arquitecturas fundamentalmente distintas). Qué pasa: alguien lee el Paso 1 y el Paso 2 seguidos y concluye que son dos puntos en la misma escala de "más volumen, más infraestructura". Cómo detectarlo: si tu resumen de esta lección es "primero Provisioned Throughput, después, con más volumen todavía, GPU". Cómo corregirlo: son dos decisiones de arquitectura distintas, no dos escalones de la misma escalera — Provisioned Throughput sigue siendo un modelo gestionado por Bedrock, con capacidad reservada en vez de pago por token; GPU dedicada significa dejar Bedrock por completo y operar el modelo uno mismo. El Paso 3 de esta lección las separa exactamente por esta razón: la primera vive dentro de esta misma guía, extendiendo bedrock.tf; la segunda no tiene guía asignada, en ningún ecosistema, hoy.
Concluir que aws-saa-certification-guide es "más importante" que las ocho guías operativas, porque es la que cierra el ecosistema (de sobrevalorar el cierre sobre la construcción). Qué pasa: alguien, viendo que la certificación es la última pieza nombrada, asume que es el objetivo real de todo el ecosistema, y las otras ocho guías son solo preparación. Cómo detectarlo: si tu resumen del ecosistema completo es "todo esto existe para pasar un examen". Cómo corregirlo: el M1.4 de esta misma guía ya citó STRATEGY.md sobre el hueco de mercado real: "los ingenieros que pueden demostrar que construyen, despliegan y operan aplicaciones de IA generativa reales... están obteniendo primas de mercado significativas" — la certificación es el cierre formal, no el propósito. Las ocho guías construyen la habilidad real y demostrable; el examen certifica, con una credencial reconocida, que esa habilidad existe. El orden importa: opera primero, certifica después — nunca al revés.
Ejercicios
Ejercicio 1 — Sin mirar el Paso 1, recita de memoria el punto de cruce aproximado (en invocaciones/mes) donde Provisioned Throughput con compromiso de 6 meses empezaría a ser más barato que On-Demand para Andes Cargo. ¿A qué distancia está el escenario de estrés de GENAI-COST-PROFILE.md de ese punto?
Ver solución
Aproximadamente 259 millones de invocaciones al mes (el M6.7 lo calculó con precisión: 259.285.714). El escenario de estrés de GENAI-COST-PROFILE.md —5.000 invocaciones al mes— está a más de 50.000 veces de distancia de ese punto; incluso el escenario deliberadamente desproporcionado del M6.6 (100.000/mes) queda a 2.593 veces de distancia. Si recordaste el orden de magnitud (cientos de millones, no miles ni millones), tienes clara la escala real de la decisión.
Ejercicio 2 — Explica, con tus propias palabras, por qué la fila "GPU dedicada" del Paso 3 queda sin guía asignada, en vez de que esta lección simplemente diga "eso lo construiría kubernetes-and-eks-in-production-guide".
Ver solución
Porque kubernetes-and-eks-in-production-guide, en su propio DISENO.md, delega ese mismo escenario hacia esta guía, no lo construye ella misma — y esta guía, a su vez, con la misma evidencia de ausencia de un camino $0, decide no construirlo tampoco. Decir "lo construiría la guía de Kubernetes" sería inexacto: esa guía nombra el escenario por contraste, exactamente igual que esta lección lo hace aquí, sin comprometerse a construirlo. El faltante es real y honesto —ninguna de las dos guías lo resuelve—, y nombrarlo sin asignación, en vez de atribuirlo incorrectamente a una guía que tampoco lo construye, es la disciplina exacta que esta lección modela.
Ejercicio 3 — Predice qué pasaría con la fila "GPU dedicada" del Paso 3 si, algún día, LocalStack Ultimate agregara un plan gratuito para instancias con GPU emulada. ¿Eso resolvería, por sí solo, la ausencia de guía asignada?
Ver solución
No, por sí solo no bastaría — resolvería únicamente la mitad técnica del obstáculo (un camino $0 para declarar y planear infraestructura de GPU con Terraform, similar a como esta guía ya declara y planea bedrock.tf sin poder aplicarlo). La otra mitad del obstáculo, nombrada explícitamente en el Paso 2, es que Andes Cargo no tiene un caso de negocio real que justifique GPU dedicada a su volumen actual — ese problema no depende de LocalStack en absoluto, depende del tráfico real de la empresa. Incluso con un camino técnico $0 completo, una guía que construyera GPU dedicada para un caso de negocio que no la necesita repetiría, en otro dominio, exactamente el antipatrón que el M1.3 de esta misma guía nombró primero: usar la herramienta más cara disponible antes de que el problema real la justifique.
Resumen y siguiente paso
Esta lección miró hacia adelante: cuantificó, con los números ya calculados del M6.7, qué tan lejos está Andes Cargo del punto donde Provisioned Throughput empezaría a convenir (259 millones de invocaciones/mes, más de 2.593 veces por encima del escenario más agresivo de esta guía); nombró, con precisión y sin fingir un camino $0 inexistente, el escenario de GPU dedicada que ni esta guía ni kubernetes-and-eks-in-production-guide construyen, con la cita textual de la delegación entre ambas; y cerró el mapa completo del ecosistema aws-cloud-ecosystem, con aws-saa-certification-guide como su pieza final declarada.
Antes de avanzar deberías poder: explicar la diferencia entre Provisioned Throughput y GPU dedicada como dos decisiones de arquitectura distintas, no dos grados de la misma; citar, de memoria o cerca, la razón exacta por la que ninguna guía de este ecosistema construye GPU dedicada hoy; y ubicar aws-saa-certification-guide correctamente como el cierre formal, no el propósito, de las ocho guías operativas.
La lección 8, el proyecto final de esta guía completa, entrega el repositorio de Andes Cargo —bedrock.tf, los guardrails propios, las políticas de Rego, la calculadora de costo, la métrica de observabilidad, y esta guía entera— como una sola pieza de portfolio, defendible línea por línea frente a cualquier pregunta técnica.
Recursos
- Este mismo curso, Módulo 6, lección 7 (
07-on-demand-vs-provisioned-throughput-when-each-one-with-real-numbers.md) — la fuente completa del cálculo del punto de cruce citado en el Paso 1 de esta lección. kubernetes-and-eks-in-production-guide/DISENO.md— la fuente textual de la delegación de "GenAI sobre EKS" citada en el Paso 2.src/paths/aws-cloud-ecosystem/STRATEGY.md— la fuente de la posición deaws-saa-certification-guidecomo cierre del ecosistema, citada en el Paso 4.- AWS Docs — Provisioned Throughput for Amazon Bedrock — referencia oficial del mecanismo que el Paso 1 de esta lección cuantifica.