Las ofertas de precios privados de Amazon Bedrock ahora escalan entre cuentas de AWS
Amazon ha presentado dos formas de hacer que las ofertas de precios privados de Amazon Bedrock funcionen en decenas o cientos de cuentas de AWS. Hasta ahora, los términos negociados podían permanecer sin utilizar mientras los administradores activaban manualmente las concesiones de licencia necesarias.
El cambio tiene menos que ver con conseguir un descuento que con hacer operativo un acuerdo aceptado. AWS Marketplace crea una licencia después de aceptar una oferta elegible, pero las concesiones a nivel de organización permanecen inicialmente deshabilitadas. Los precios negociados no se aplican al uso cubierto hasta que esas concesiones se activan.
AWS ahora ofrece un script ligero para una activación única y revisada, además de un flujo de trabajo de AWS Cloud Development Kit para el procesamiento continuo. La segunda vía conecta los eventos de acuerdos de Marketplace con la creación automatizada de concesiones, la verificación de vendedores, la activación, los reintentos y el registro.
Esta distinción genera la tensión central. Las empresas quieren centralizar las compras sin convertir cada acuerdo de modelo en un cambio de permisos para toda la organización sin supervisión. El script prioriza la revisión del operador, mientras que el diseño basado en eventos prioriza la repetibilidad con controles explícitos.
Las ofertas de precios privados de Amazon Bedrock aún necesitan activación
Aceptar una oferta privada no completa el flujo de trabajo de precios para múltiples cuentas.
Las ofertas de precios privados de AWS Marketplace, conocidas habitualmente como MPPO, permiten a los compradores negociar condiciones comerciales personalizadas para productos de terceros. Para los modelos elegibles de Amazon Bedrock, AWS Marketplace representa el acceso resultante mediante una licencia en AWS License Manager.
AWS publicó su nuevo flujo de trabajo de derechos administrados el 13 de octubre de 2026. Está dirigido a organizaciones que ejecutan cargas de trabajo de Bedrock en cuentas separadas para desarrollo, producción, unidades de negocio o regiones.
La organización puede aceptar una oferta elegible desde una cuenta central. Después puede distribuir la licencia asociada a toda la organización, a unidades organizativas seleccionadas o a cuentas concretas.
AWS denomina a esta capacidad derechos administrados. Un derecho representa la facultad de utilizar un producto con licencia conforme al acuerdo aplicable. Una concesión distribuye ese derecho desde el titular original de la licencia a cuentas adicionales de AWS.
El proceso no termina cuando AWS Organizations acepta la concesión. Con todas las funciones de organización habilitadas, las concesiones a nivel de organización se aceptan automáticamente, pero permanecen deshabilitadas hasta su activación.
Este estado intermedio es importante porque separa la distribución administrativa del uso efectivo de los términos negociados. También crea un modo de fallo que puede parecer completo desde la perspectiva de compras.
Un comprador puede haber aceptado el acuerdo, recibido la licencia y configurado el ámbito de cuentas previsto. Sin embargo, el uso cubierto de Bedrock puede seguir fuera de la ruta de precios negociados porque la concesión distribuida nunca alcanzó un estado activo.
AWS indica que la tarifa se aplica después de que la concesión alcance ACTIVE o WORKFLOW_COMPLETED. Por tanto, estos estados se convierten en puntos de control operativos, no simplemente en metadatos internos de licencia.
El problema se vuelve más difícil de seguir a medida que una organización añade cuentas y modelos. Un equipo de plataforma puede revisar una concesión manualmente sin demasiada dificultad. Las renovaciones repetidas y los nuevos acuerdos de modelos hacen que sea más fácil pasar por alto el proceso.
Los derechos administrados consolidan el acuerdo en un único lugar. La documentación de AWS indica que la cuenta de suscripción original recibe la facturación por el uso en todas las cuentas beneficiarias, lo que proporciona visibilidad centralizada del consumo con licencia de Bedrock.
La misma documentación señala una diferencia de configuración importante. Las organizaciones que utilizan facturación consolidada sin todas las funciones de AWS Organizations deben aceptar manualmente las concesiones en cada cuenta receptora.
Esta limitación cambia la experiencia esperada. La facturación centralizada por sí sola no ofrece el mismo comportamiento de aceptación automática que la integración completa de la organización.
AWS también administra estos recursos de licencia en us-east-1, independientemente de la región compatible de Bedrock donde se invoque un modelo. Los equipos que suelen operar en otras ubicaciones deben tratar Northern Virginia como la región de control para este flujo de trabajo.
Por eso las ofertas de precios privados de Amazon Bedrock plantean una cuestión operativa después de las compras. Alguien todavía debe convertir un acuerdo comercial aceptado en derechos activos y correctamente delimitados.
Un script de ejecución única elimina el retraso acumulado
La opción ligera favorece la aprobación visible del operador frente a la automatización permanente.
AWS posiciona su script independiente de Python como la ruta más corta para organizaciones con licencias recibidas pendientes de distribución. No requiere un despliegue de CDK ni una pila persistente de procesamiento de eventos.
El script primero enumera las licencias recibidas por la cuenta de administración. Su comportamiento predeterminado genera un plan de ejecución en seco sin crear ni activar concesiones.
Ese valor predeterminado constituye un control de seguridad significativo. Los administradores pueden inspeccionar el emisor, la licencia y el ámbito de cuentas propuesto antes de permitir que el script cambie el acceso de toda la organización.
Un operador debe volver a ejecutar la utilidad con --apply y el ID de la cuenta de administración para ejecutar el plan. Exigir la confirmación de la cuenta reduce la posibilidad de aplicar un plan revisado desde el entorno de AWS equivocado.
A continuación, el script crea y activa concesiones para toda la organización correspondientes a las licencias recibidas seleccionadas. Está diseñado como una corrección única, no como un plano de control de ejecución continua.
Este enfoque es adecuado para una organización con un pequeño retraso acumulado y acuerdos privados poco frecuentes. También funciona cuando un equipo de plataforma quiere comprender el estado de la licencia antes de desplegar infraestructura adicional.
Sin embargo, el script no incluye una lista de permitidos de vendedores. Puede inspeccionar cada licencia recibida en la cuenta de administración, por lo que AWS indica a los usuarios que revisen cuidadosamente cada elemento.
La ausencia de una lista de permitidos convierte la confianza en el límite decisivo. El operador debe confirmar que cada emisor y ámbito de cuenta relevante coincide con una oferta privada que la organización pretendía aceptar.
Esta contrapartida mantiene la herramienta sencilla. También hace que el script no sea adecuado como trabajo desatendido que procesa repetidamente cualquier elemento que aparezca en la cuenta.
El uso más seguro comienza con una ejecución en seco. Los administradores deben comparar cada emisor listado con los registros de compras y el acuerdo correspondiente de Marketplace.
La revisión también debe verificar el destino de la concesión. Compartir con toda la organización es materialmente distinto de compartir con una unidad organizativa o varias cuentas nominales de cargas de trabajo.
Una empresa sanitaria podría aislar las cargas de trabajo de producción clínica de las cuentas de investigación. Una institución financiera podría limitar un modelo con licencia a unidades aprobadas de desarrollo y producción.
El valor predeterminado del script para toda la organización requiere especial atención en entornos con separación estricta. Una activación técnicamente correcta aún puede exceder el ámbito empresarial previsto.
Después de la activación, AWS recomienda a los usuarios verificar el estado de la concesión en License Manager. Después deben validar la ruta de facturación efectiva cuando los datos estén disponibles en AWS Cost Explorer.
Esta segunda comprobación es necesaria porque la activación de la licencia y la visibilidad de facturación siguen cronogramas distintos. AWS advierte que la información de facturación puede retrasarse horas o días.
Por tanto, una concesión activa confirma que se completó el flujo de trabajo de licencias. No demuestra de inmediato que cada cargo posterior refleje los términos privados esperados.
AWS incluye una utilidad de comprobación de descuentos en el código de ejemplo público. Los equipos deben adaptar las entradas de emisor y cuenta a su propio acuerdo.
El script ofrece a las empresas una vía práctica de recuperación cuando se ha acumulado trabajo manual. Convierte una búsqueda incierta en la consola en un procedimiento repetible de revisión y activación.
No elimina la responsabilidad. Un equipo de plataforma o FinOps aún debe decidir qué licencias son fiables, dónde deben aplicarse y cómo se validará la facturación.
La automatización basada en eventos convierte los acuerdos en concesiones activas
La vía de CDK convierte cada acuerdo de Marketplace que cumple los requisitos en un flujo de trabajo de licencias controlado.
El segundo diseño de AWS utiliza CDK, EventBridge, Lambda, DynamoDB, License Manager y CloudWatch. Está dirigido a organizaciones que añaden modelos con frecuencia, renuevan acuerdos o modifican sus estructuras de cuentas.
El flujo de trabajo comienza con un evento de acuerdo de AWS Marketplace. Una regla de EventBridge escucha en el bus de eventos predeterminado en us-east-1.
La regla coincide con el origen aws.agreement-marketplace y el tipo de detalle Purchase Agreement Created - Acceptor. Ese evento indica que la parte aceptante creó un acuerdo de compra.
EventBridge invoca una función Lambda después de que llega un evento coincidente. La función comprueba al vendedor frente a una lista de permitidos almacenada en DynamoDB antes de continuar.
Si el vendedor está aprobado, la función descubre la licencia relacionada. Después crea una concesión distribuida para la organización, las unidades organizativas o las cuentas configuradas.
La función solicita la activación mediante CreateGrantVersion con un estado activo. AWS documenta las actualizaciones de versiones de concesiones como la interfaz para cambiar el nombre, estado u operaciones permitidas de una concesión.
License Manager no siempre deja una concesión recién creada lista para activarse de inmediato. Por eso, el ejemplo incluye comportamiento de reintento cuando el servicio aún necesita tiempo para finalizar su flujo de trabajo.
Esta lógica de reintento aborda una diferencia importante entre un evento y un derecho completado. El evento de Marketplace inicia el procesamiento, pero no garantiza que cada objeto de licencia posterior esté disponible de inmediato.
La función registra las decisiones de activación, aplazamiento y omisión en CloudWatch Logs. Estos registros proporcionan una pista de auditoría para la resolución de problemas y las revisiones de gobernanza.
Esto es más que comodidad a escala. Un controlador determinista puede aplicar las mismas reglas de validación de vendedores y de definición de destinos de concesiones a cada acuerdo elegible.
La activación manual depende de que un administrador encuentre la licencia correcta, seleccione el ámbito correcto y regrese cuando la concesión esté lista. Esa secuencia se vuelve menos fiable a medida que aumenta el volumen de transacciones.
El diseño basado en eventos reduce esa variación. También hace visibles en el código y la configuración los supuestos de la automatización.
AWS exige que el despliegue se ejecute desde la cuenta de administración de Organizations en us-east-1. La organización debe utilizar todas las funciones, y la oferta debe involucrar un modelo de Bedrock respaldado por License Manager.
Los productos SaaS permanecen fuera del alcance del ejemplo. El flujo de trabajo no debe considerarse un procesador universal de ofertas privadas para todos los modelos de entrega de AWS Marketplace.
Antes del despliegue, los equipos deben habilitar el acceso de confianza y los roles vinculados al servicio para License Manager y Marketplace. El acceso de confianza permite a estos servicios realizar tareas definidas a nivel de organización.
Las instrucciones de configuración de AWS especifican pasos de integración independientes para ambos servicios. También explican cómo verificar los roles resultantes y los vínculos con la organización.
El ejemplo incluye una utilidad de inicialización que puede comprobar estos requisitos previos. Su modo de aplicación puede habilitar integraciones y crear los roles vinculados al servicio necesarios tras la confirmación explícita de la cuenta.
Luego, la configuración define el ID de la organización, los vendedores aprobados, las notificaciones y los destinos de concesión opcionales. Sin destinos personalizados, la automatización distribuye las concesiones a toda la organización.
En su lugar, los equipos pueden indicar unidades organizativas o cuentas individuales. Esto permite alinear el acceso a modelos con los límites de los entornos, la responsabilidad empresarial o las decisiones internas de aprobación.
El proceso solo termina cuando la concesión alcanza un estado activo aceptado y la facturación sigue el acuerdo previsto. El procesamiento de eventos, las licencias, la invocación de modelos y la validación de costes siguen siendo puntos de observabilidad independientes.
Por tanto, las ofertas de precios privados de Amazon Bedrock pasan a ser eventos de infraestructura, en lugar de artefactos de adquisición. La vía de CDK las incorpora al mismo sistema operativo utilizado para otros controles en la nube.
La lista de vendedores permitidos es el verdadero límite de seguridad
La automatización solo es segura cuando la identidad del vendedor y el alcance de la concesión reciben el mismo escrutinio que los permisos de los modelos.
El flujo de trabajo de CDK puede distribuir una licencia en una gran organización de AWS sin esperar la revisión humana en la consola. Esa velocidad aumenta la importancia de sus reglas de selección.
AWS describe la lista de vendedores permitidos como un límite de seguridad. Los administradores la inicializan desde un archivo de configuración después de verificar el ID de cuenta de cada vendedor.
La verificación debe usar el acuerdo de Marketplace aceptado o la licencia de License Manager recibida. El nombre visible de un vendedor, por sí solo, no es un control suficiente.
Las entradas amplias o no verificadas pueden activar la creación de concesiones para licencias que no estaban destinadas a la distribución automatizada. La concesión resultante puede llegar a todos los destinos de cuentas configurados.
Ese resultado no concede necesariamente a un modelo acceso sin restricciones a los datos empresariales. Las políticas de identidad, los controles de servicio, los permisos de los modelos y la arquitectura de las aplicaciones siguen regulando el uso real.
Sin embargo, la automatización de derechos cambia qué cuentas pueden utilizar los términos comerciales. También puede concentrar la facturación en la cuenta propietaria de la suscripción original.
Por esa razón, la verificación de vendedores debe situarse junto a la revisión de IAM, la aprobación de compras y la asignación de costes. No debería existir como una configuración informal de despliegue.
El alcance de la concesión merece la misma atención. Un destino para toda la organización es sencillo, pero puede superar el conjunto de cuentas aprobadas para un modelo o caso de uso específico.
Las unidades organizativas seleccionadas ofrecen un punto intermedio. Permiten a las empresas distribuir un derecho según una jerarquía de cuentas existente.
Las cuentas designadas ofrecen un control más limitado, pero generan más mantenimiento. Las nuevas cuentas de cargas de trabajo no heredarán acceso a menos que cambie la configuración.
Estas opciones reflejan una elección más amplia entre la comodidad centralizada y la distribución con privilegios mínimos. Ningún enfoque es correcto para todas las organizaciones.
Una plataforma de IA centralizada puede querer una disponibilidad uniforme de modelos entre los equipos de aplicaciones. Una empresa regulada puede requerir una aprobación independiente para cada entorno y clasificación de datos.
La automatización también necesita gobernanza en torno a los cambios de configuración. Los ID de vendedores, los ID de organizaciones y los destinos de concesión deben someterse a revisión de código y despliegue controlado.
Los registros de CloudWatch proporcionan evidencia de que la función procesó u omitió un evento. No sustituyen los registros de aprobación que explican por qué se autorizó un vendedor o un alcance de cuenta.
Los equipos también necesitan alertas para activaciones fallidas o aplazadas repetidamente. Un flujo de registros silencioso puede dejar inactivo un acuerdo negociado mientras las aplicaciones siguen generando uso.
AWS señala que la entrega de servicios de EventBridge sigue un comportamiento de servicio basado en eventos, mientras que los reintentos dentro de la solución abordan la preparación de License Manager. Los operadores aún deben prepararse para un procesamiento perdido, duplicado o retrasado.
Un proceso de conciliación puede comparar acuerdos aceptados, licencias recibidas, concesiones distribuidas y estados de concesión activos. Esa comparación detecta condiciones que un único controlador de eventos podría no mostrar.
Las organizaciones también deben preservar procedimientos operativos comprensibles para las personas. Una base de conocimientos de ingeniería con capacidad de búsqueda puede mantener disponibles las reglas de aprobación, las asignaciones de emisores y los pasos de recuperación durante un incidente.
El script ligero sigue siendo útil incluso después de que exista la pila automatizada. Puede ayudar a inspeccionar licencias históricas o respaldar una recuperación controlada cuando no se procesó un evento.
Usar ambas vías no significa ejecutar ambas sin coordinación. Los equipos necesitan una responsabilidad clara para evitar concesiones duplicadas, destinos en conflicto o un historial de activación incierto.
El riesgo central no es la propia función Lambda. Es asumir que un acuerdo aceptado debe pasar a estar disponible automáticamente en todas partes.
El diseño de CDK aborda ese riesgo mediante vendedores verificados, destinos configurables, requisitos previos explícitos, registros y validación. Esos controles deben mantenerse después del despliegue.
Las compras centralizadas presionan a los equipos de plataforma y FinOps
Los derechos gestionados trasladan el cuello de botella desde la aceptación por cuenta individual hacia la política centralizada y la gobernanza de costes.
El proceso anterior, cuenta por cuenta, imponía una fricción visible. Cada propietario de una carga de trabajo debía encontrar, aceptar y gestionar los términos pertinentes de Marketplace.
La distribución centralizada elimina gran parte de ese trabajo repetitivo. También traslada la responsabilidad hacia la cuenta de administración de la organización y los equipos que la operan.
La ingeniería de plataformas controla ahora si una licencia elegible llega a los entornos de desarrollo, pruebas y producción. Compras controla el acuerdo subyacente, mientras que FinOps valida los cargos resultantes.
Los equipos de seguridad deben revisar el límite de confianza automatizado. Los equipos de aplicaciones dependen de todos esos grupos antes de que la vía de precios esperada pueda utilizarse.
Esta división de responsabilidades puede crear una nueva demora si la propiedad no está clara. La automatización técnica completa solo una parte del modelo operativo.
El cliente de AWS Heidi Health ilustra por qué importa el modelo centralizado. La empresa afirma que respalda millones de consultas de profesionales clínicos cada semana mientras depende de modelos fundacionales de terceros.
Marcus Lau, responsable de ingeniería de plataformas de Heidi Health, afirmó que los precios privados ayudan a la empresa a atribuir el uso y los términos entre cuentas y unidades organizativas. También destacó la automatización de las concesiones a medida que se adoptan nuevos modelos.
Esa declaración representa la perspectiva de un cliente, no una prueba independiente de ahorro. Sí muestra el problema de escala que hace poco atractivo el procesamiento manual de concesiones.
Los equipos de IA separan cada vez más las cargas de trabajo entre cuentas para gestionar la seguridad, la propiedad, los entornos y la atribución de costes. Cada límite adicional aumenta el número de lugares donde el acceso a modelos puede fallar.
Los derechos gestionados mantienen centralizado el acuerdo comercial y permiten el uso técnico en cuentas vinculadas. La guía de derechos de AWS indica que los destinatarios heredan mediante la concesión los términos aplicables de la oferta privada.
Este modelo también difiere de hacer que cada cuenta se suscriba de forma independiente. El titular de la suscripción original sigue siendo el punto central de facturación para el uso concedido.
Esto crea una visibilidad agregada más clara, pero los equipos aún necesitan una asignación interna. Las etiquetas de cuenta, las categorías de costes y la propiedad de las cargas de trabajo siguen siendo necesarias para la refacturación interna o la imputación de costes.
Los equipos de FinOps deberían comparar los destinos de las concesiones con los centros de uso previstos antes de la activación. De lo contrario, un derecho puede ser técnicamente válido, pero difícil de conciliar con los presupuestos internos.
Los equipos de compras también necesitan procedimientos de renovación. Un nuevo acuerdo puede generar otro evento, licencia o flujo de trabajo de concesión que requiere validación.
La automatización reduce el trabajo repetitivo en la consola, pero no resuelve la interpretación contractual. Los términos, las fechas de vigencia, la cobertura de productos y las modificaciones siguen necesitando revisión humana.
AWS Marketplace distingue entre la aceptación de la oferta, la creación del acuerdo, la activación del derecho y la facturación. Los acuerdos con fecha futura hacen que estos hitos sean aún más diferenciados.
Un acuerdo aceptado puede tener una fecha de inicio posterior. Los equipos deben evitar interpretar el evento de compra como prueba de que el modelo está disponible de inmediato bajo los nuevos términos.
La misma cautela se aplica cuando un vendedor añade un modelo, una región o una variante de producto. Los acuerdos privados existentes pueden no cubrir automáticamente cada incorporación posterior.
La centralización también aumenta el efecto de los errores de configuración. Un ID de cuenta incorrecto en un proceso manual afecta a una cuenta, mientras que un destino organizativo incorrecto puede afectar a muchas.
Esa asimetría explica por qué la solución basada en eventos incluye filtrado de vendedores y destinos configurables. La automatización necesita controles de selección más sólidos porque opera a mayor escala.
Por tanto, los derechos gestionados de Amazon Bedrock presionan a las empresas para formalizar un proceso que antes estaba disperso. El flujo de trabajo conecta la aprobación comercial, el derecho técnico, el alcance de seguridad y la evidencia de facturación.
Las organizaciones que más se beneficien tratarán esas conexiones como un sistema operativo. Instalar únicamente la pila de CDK no creará esa disciplina.
Tres señales mostrarán si la automatización funciona
La próxima prueba es determinar si las empresas pueden conciliar eventos de acuerdos, concesiones activas y cargos cubiertos sin volver a las comprobaciones manuales de la consola.
La primera señal es el tiempo de finalización de la concesión. Los equipos deben medir el intervalo entre un evento de acuerdo de Marketplace que cumpla los requisitos y una concesión ACTIVE o WORKFLOW_COMPLETED.
Un intervalo sistemáticamente breve respaldaría la afirmación de AWS de que el procesamiento basado en eventos elimina esperas evitables. Los aplazamientos reiterados o las intervenciones manuales debilitarían ese argumento.
Esta métrica debe incluir las comprobaciones fallidas de vendedores y las licencias que aún no eran detectables. Excluir esos casos ocultaría las brechas operativas más importantes del flujo de trabajo.
La segunda señal es la precisión de la conciliación. Los acuerdos aceptados, las licencias recibidas, los destinos previstos y las concesiones activas deben coincidir en toda la cuenta de administración.
Un control periódico debería identificar los acuerdos sin concesiones activas y las concesiones sin un acuerdo aprobado vigente. También debería señalar los destinos fuera del alcance de cuentas autorizado.
Una conciliación sólida demostraría que la automatización puede seguir siendo fiable después de cambios de personal, renovaciones y reestructuraciones de la organización. Las discrepancias persistentes revelarían que el manejo de eventos por sí solo es insuficiente.
La tercera señal es la validación de facturación. El uso cubierto de Bedrock debería aparecer bajo los términos comerciales esperados cuando los datos de Cost Explorer estén disponibles.
AWS advierte explícitamente que esta visibilidad puede tardar horas o días. Por tanto, los equipos deben definir un plazo de verificación razonable en lugar de tratar una ausencia inmediata como un fallo.
Deben comparar el cargo efectivo de un uso cubierto representativo en una cuenta con concesión. La comprobación también debe confirmar el emisor previsto y el titular original de la suscripción.
Si la facturación sigue repetidamente a las concesiones activas, el flujo de trabajo conectará la intención de compras con el consumo de producción. De no ser así, las empresas necesitarán diagnósticos más sólidos entre Marketplace, License Manager y los datos de costes.
Estas señales también proporcionan una secuencia práctica de despliegue. Empiece con una ejecución en seco y una licencia verificada, y luego confirme el estado de concesión resultante.
A continuación, habilite el procesamiento basado en eventos para un conjunto estrictamente delimitado de vendedores y cuentas. Compare los registros, el estado de la licencia y la evidencia de facturación antes de ampliar los destinos.
Por último, documente cómo gestionan los operadores un evento perdido, un vendedor desconocido, una activación aplazada y un cargo inesperado. Esos casos definen si el sistema es gestionable.
Las ofertas de precios privados de Amazon Bedrock ahora cuentan con una vía más clara entre entornos con múltiples cuentas. La decisión clave no es simplemente script frente a CDK.
Elija el script cuando el trabajo esté acotado, cada licencia recibida sea de confianza y un operador pueda revisar cada activación. Elija el flujo de trabajo de CDK cuando los acuerdos se repitan y la política pueda codificarse de forma segura.
Antes de automatizar, formule una pregunta concreta: ¿puede su organización identificar al vendedor exacto, las cuentas objetivo, el estado de concesión previsto y el responsable de facturación de cada acuerdo?
Si la respuesta es sí, la vía basada en eventos puede eliminar el trabajo repetitivo. Si la respuesta es no, empiece con una ejecución en seco y use sus resultados para establecer esos controles.
