El acceso a Claude Platform on AWS unifica tres entornos, pero la precisión de IAM determina el resultado de seguridad
AWS ha documentado tres rutas de acceso a Claude Platform on AWS bajo una misma suscripción, pese a sus marcadamente distintos requisitos de credenciales y seguridad.
Publicado el 1 de octubre, el enfoque conecta cargas de trabajo de AWS, portátiles de desarrolladores y servicios externos con espacios de trabajo alojados en una cuenta dedicada de AI Services. Las aplicaciones de producción usan Signature Version 4 entre cuentas, los desarrolladores reciben claves de API con alcance limitado y las cargas de trabajo externas se autentican mediante federación OpenID Connect.
La arquitectura promete facturación y administración centralizadas sin obligar a cada entorno a utilizar un único modelo de credenciales. La tensión es igualmente clara. La centralización simplifica la propiedad, pero una política IAM demasiado amplia o una clave de desarrollador mal gestionada puede debilitar los límites de los espacios de trabajo que hacen útil el diseño.
No se trata simplemente de otra guía de integración de Claude. La implementación de AWS convierte la autenticación en un plano de control específico para cada entorno. También pone de manifiesto el trabajo operativo oculto tras la expresión “una sola suscripción”.
Amazon Bedrock sigue siendo un punto de referencia importante. Proporciona modelos Claude mediante un servicio de modelos fundacionales gestionado por AWS. Claude Platform on AWS, en cambio, ofrece la experiencia de plataforma nativa de Anthropic a través de una cuenta de AWS, incluidas sus APIs, consola y funciones de plataforma.
El nuevo patrón de acceso no elimina esa distinción. Muestra cómo las empresas pueden extender la plataforma nativa de Anthropic a través de una organización de AWS, manteniendo al mismo tiempo el control basado en IAM sobre el tráfico de producción.
Una suscripción ahora sirve a tres límites de confianza
El cambio importante no es solo una conectividad más amplia. AWS ha asignado tres entornos a tres métodos de autenticación distintos, manteniendo centralizada la propiedad de los espacios de trabajo.
La topología propuesta comienza con tres roles de cuenta. Una cuenta de administración gestiona la facturación y la gobernanza a nivel de organización. Una cuenta dedicada de AI Services es propietaria de la suscripción de Claude Platform, los espacios de trabajo, las claves de API y los roles de acceso.
Una o más cuentas de cargas de trabajo consumen inferencia de Claude sin ser propietarias de la suscripción. Sus aplicaciones asumen roles en la cuenta de AI Services y llaman a recursos del espacio de trabajo autorizados por esos roles.
Esa separación otorga a la cuenta de AI Services un propósito específico. Se convierte en el límite administrativo alrededor del acceso a Claude, en lugar de ser otra cuenta general de aplicaciones llena de recursos no relacionados.
AWS recomienda crear espacios de trabajo separados para producción y desarrollo dentro de esa cuenta. Un espacio de trabajo es el límite de recursos utilizado para separar equipos, proyectos o entornos, manteniendo una administración centralizada.
Cada espacio de trabajo tiene un Amazon Resource Name, o ARN, al que las políticas IAM pueden hacer referencia. Por lo tanto, los permisos pueden autorizar la inferencia contra un espacio de trabajo sin autorizar automáticamente otro.
La primera ruta de acceso cubre aplicaciones que ya se ejecutan dentro de AWS. AWS utiliza un pod de Amazon EKS como ejemplo, aunque el patrón puede aplicarse a otras cargas de trabajo de AWS.
Ese pod primero asume un rol entre cuentas en la cuenta de AI Services. Las credenciales temporales luego firman las solicitudes de Claude con AWS Signature Version 4, comúnmente llamada SigV4.
SigV4 firma criptográficamente las solicitudes de API de AWS mediante credenciales de AWS. Permite al servicio receptor verificar la identidad del solicitante, la integridad de la solicitud y el contexto de autorización sin un secreto estático de API independiente.
El rol entre cuentas concede acciones seleccionadas de aws-external-anthropic contra el ARN del espacio de trabajo de producción. El ejemplo incluye inferencia, conteo de tokens, recuperación de modelos y listado de modelos.
El rol no necesita permiso para acceder al espacio de trabajo de desarrollo. Esto crea una relación directa entre la identidad de la carga de trabajo, las acciones de API permitidas y el espacio de trabajo de Claude autorizado.
La segunda ruta cubre los portátiles de los desarrolladores. A menudo, los desarrolladores necesitan una forma con menos fricción para probar prompts, el comportamiento de SDK y la lógica de aplicaciones fuera de una carga de trabajo desplegada.
AWS asigna a estos usuarios una clave de API de larga duración asociada al espacio de trabajo de desarrollo. El SDK estándar de Anthropic puede utilizar esa clave contra el endpoint regional de Claude Platform on AWS.
Esta ruta mantiene una experiencia familiar para los desarrolladores, pero crea una credencial de portador persistente. Cualquiera que posea la clave puede utilizar sus permisos hasta que expire o un administrador la revoque.
La tercera ruta se dirige a servicios externos. Entre los ejemplos se incluyen cargas de trabajo que se ejecutan en Google Cloud, clústeres de Kubernetes que no pertenecen a AWS y sistemas de CI/CD como GitHub Actions o GitLab CI.
Esos servicios utilizan federación OIDC, que intercambia el token firmado de un proveedor de identidad por credenciales temporales de AWS. Las credenciales temporales generan un token de portador de Claude de corta duración.
El ejemplo de AWS crea un token que dura una hora. La implementación permite duraciones configurables de hasta 12 horas, tras las cuales el servicio externo debe obtener otro token.
En conjunto, estas tres rutas forman el núcleo del acceso multi-entorno de Claude. La suscripción permanece en una cuenta, mientras que la autenticación cambia según dónde se ejecute el solicitante.
Ese es el avance arquitectónico. Reconoce que un pod de EKS, un portátil de desarrollador y un pipeline externo no deberían compartir un único patrón universal de credenciales.
El acceso a Claude Platform on AWS traslada el control a IAM
El acceso a Claude Platform on AWS ahora depende menos de dónde se ejecuta el código y más de si IAM describe con precisión su identidad y espacio de trabajo previstos.
AWS presentó el servicio como una forma de utilizar la plataforma nativa de Anthropic mediante una cuenta de AWS existente. La empresa afirmó que AWS fue el primer proveedor de nube que ofreció esa experiencia nativa a través de su propia estructura de cuentas.
El lanzamiento original conectó la autenticación, la facturación y las funciones de auditoría con AWS. Los clientes podían utilizar las APIs y herramientas de Anthropic sin establecer una relación comercial independiente.
El diseño multi-entorno extiende esa propuesta más allá de una conexión básica de API. Convierte a la organización de AWS, en vez de una aplicación individual, en la capa organizativa para el acceso a Claude.
Esto importa porque el uso empresarial de IA rara vez permanece dentro de un solo entorno. Un equipo puede probar una aplicación localmente, desplegarla en EKS y ejecutar evaluaciones desde otra nube.
Una clave estática compartida puede conectar las tres ubicaciones, pero también colapsa sus identidades. Los registros muestran la clave, no necesariamente la carga de trabajo, la cuenta o el pipeline que la utilizó.
Los roles entre cuentas conservan más contexto. La carga de trabajo asume un rol con nombre, recibe credenciales temporales y realiza solicitudes firmadas que AWS puede atribuir a una entidad principal.
El rol también crea dos puntos de control de autorización. La cuenta de carga de trabajo debe permitir que su identidad local asuma el rol de destino. La cuenta de AI Services debe confiar en esa identidad y organización.
El ejemplo de AWS agrega una condición aws:PrincipalOrgID a la política de confianza. Esa condición restringe la asunción de roles a entidades principales asociadas con la organización de AWS especificada.
La política de permisos limita entonces la inferencia al ARN del espacio de trabajo de producción. La confianza responde quién puede asumir el rol, mientras que los permisos definen qué puede hacer ese rol después.
Esta separación ejerce presión sobre equipos que antes trataban el acceso a modelos como una distribución de secretos. Ahora necesitan gestionar la autenticación de Claude en AWS como una arquitectura de identidad.
Los equipos de seguridad, plataforma y aplicaciones deben acordar la propiedad de las cuentas. También necesitan estándares de nomenclatura para roles, espacios de trabajo, políticas y asignaciones de entornos.
Una cuenta dedicada puede hacer visibles esas responsabilidades. Sin embargo, no las vuelve automáticamente correctas.
La arquitectura también afecta la respuesta ante incidentes. Un rol de producción puede desactivarse sin eliminar inmediatamente el acceso de los desarrolladores. Una clave de desarrollo comprometida puede revocarse sin modificar un rol de carga de trabajo de EKS.
La separación de espacios de trabajo también puede respaldar la atribución de costes. AWS afirma que las organizaciones pueden etiquetar los espacios de trabajo y activar esas etiquetas para la asignación de costes.
Tras la activación, que AWS dice que puede tardar entre 24 y 48 horas, los equipos pueden filtrar los datos de AWS Cost Explorer por espacio de trabajo. Esto crea una vía desde el aislamiento técnico hasta el análisis del gasto a nivel de proyecto.
La auditabilidad requiere otra decisión explícita. La administración de espacios de trabajo aparece en los eventos de administración de CloudTrail de forma predeterminada, pero la inferencia pertenece a la categoría de eventos de datos.
La documentación de monitorización indica que los equipos deben habilitar el registro de eventos de datos para capturar la inferencia y otras operaciones del espacio de trabajo. Estos eventos también pueden generar cargos adicionales de CloudTrail.
Esta distinción es fácil de pasar por alto. Centralizar la suscripción mejora el potencial de la pista de auditoría, pero no garantiza que la actividad de inferencia se esté registrando.
Por tanto, el diseño presiona a los propietarios de plataformas para que traten la observabilidad como parte del control de acceso. Una política puede limitar una acción, mientras que el registro proporciona evidencia de qué entidad principal la realizó realmente.
Las tres rutas de autenticación resuelven problemas distintos
La arquitectura funciona porque evita forzar la conveniencia, la identidad de carga de trabajo y la federación externa dentro del mismo ciclo de vida de credenciales.
Para las cargas de trabajo de AWS, SigV4 entre cuentas ofrece la alineación más limpia con la identidad existente en la nube. La aplicación recibe credenciales temporales de AWS al asumir un rol.
Luego firma cada solicitud al endpoint de Claude. No hay una clave de API de Claude independiente almacenada en la cuenta de la carga de trabajo, la imagen del contenedor o la configuración de despliegue.
Este enfoque sigue las directrices establecidas de AWS. Las mejores prácticas de IAM de la empresa recomiendan credenciales temporales de rol para las cargas de trabajo en lugar de claves de acceso de larga duración.
El rol de producción puede incluir únicamente las acciones que necesita la aplicación. Una aplicación síncrona básica podría necesitar permisos de inferencia y conteo de tokens, pero no acciones de archivos, lotes o administración.
Claude Platform on AWS utiliza el espacio de nombres IAM aws-external-anthropic. Su modelo de permisos asigna rutas de API a acciones específicas, como CreateInference para solicitudes de mensajes.
Esa acción puede hacer referencia a un único ARN de espacio de trabajo. La aplicación obtiene acceso al espacio de trabajo de producción sin heredar privilegios de Claude para toda la cuenta.
Esta es la más sólida de las tres rutas para cargas de trabajo continuas de AWS. La aplicación no transporta un secreto duradero de Claude y AWS puede atribuir las solicitudes a una identidad asumida.
Los portátiles de los desarrolladores plantean una restricción distinta. Exigir que cada experimento local atraviese una cadena de roles entre cuentas puede elevar los costes de configuración y ralentizar la iteración.
Por ello, AWS utiliza una clave de API con alcance limitado al espacio de trabajo para desarrollo. La clave funciona con el cliente estándar de Anthropic y apunta al endpoint regional de Claude Platform on AWS.
La salvedad importante es que una clave recién generada no es automáticamente lo bastante limitada para este patrón. AWS indica que su usuario IAM subyacente recibe inicialmente la política gestionada AnthropicLimitedAccess.
Según la guía de implementación, esa política gestionada concede acceso a todos los espacios de trabajo. Un administrador debe desvincularla y sustituirla por una política en línea limitada al desarrollo.
Ese paso es el control manual más importante en la ruta de desarrollo. Generar la clave es fácil, pero aplicar el límite previsto del espacio de trabajo requiere un cambio de IAM independiente.
AWS recomienda probar el límite después. El desarrollador debe llamar correctamente al espacio de trabajo de desarrollo, luego intentar una solicitud de producción y confirmar que IAM la deniega.
Esta prueba negativa importa más que la solicitud exitosa. Una respuesta de desarrollo demuestra conectividad, pero solo una llamada de producción rechazada verifica la afirmación de aislamiento.
La clave de API sigue siendo autoautenticable. Funciona desde AWS, otra nube o una laptop porque la posesión de la clave proporciona la credencial.
Por tanto, los equipos deben almacenarla en un gestor de secretos aprobado y establecer una fecha de expiración. También necesitan procedimientos de revocación para dispositivos perdidos, cambios de rol y exposición accidental en repositorios.
La ruta de cargas de trabajo externas elimina ese secreto persistente. OIDC permite que un proveedor de identidad compatible emita un JSON Web Token que identifica la carga de trabajo.
AWS Security Token Service valida el token y comprueba las condiciones de confianza del rol. Luego devuelve credenciales temporales de AWS mediante AssumeRoleWithWebIdentity.
La guía de OIDC recomienda este patrón para aplicaciones fuera de AWS porque evita las credenciales de larga duración incrustadas.
La carga de trabajo externa utiliza sus credenciales temporales de AWS para solicitar un token bearer de Claude de corta duración. Una vez generado, ese token bearer puede llamar a Claude sin conservar las credenciales de AWS.
Esto resulta útil para contenedores externos y trabajos de CI/CD, pero la renovación del token pasa a formar parte de la aplicación. Un servicio que se ejecuta continuamente debe renovar el token antes de que expire.
La política de confianza de OIDC también merece especial atención. El ejemplo de AWS comprueba las reclamaciones de audiencia y sujeto del token frente a los valores esperados.
La audiencia identifica al destinatario previsto del token. El sujeto distingue la carga de trabajo, cuenta de servicio, repositorio o identidad de canalización permitidos.
Los filtros de reclamaciones poco estrictos pueden admitir más identidades externas de las previstas. Un mecanismo de federación correcto con una condición de confianza imprecisa sigue produciendo acceso excesivo.
Por tanto, estas rutas son complementarias, no intercambiables.
SigV4 entre cuentas es adecuado para cargas de trabajo de producción ya gobernadas mediante identidades de AWS.
Las claves de API limitadas al espacio de trabajo reducen la fricción del desarrollo local.
La federación OIDC es adecuada para automatización externa que puede presentar una identidad de carga de trabajo verificable.
El elemento compartido es el espacio de trabajo. En última instancia, cada ruta de credenciales debe resolverse en permisos para el espacio de trabajo adecuado para ese entorno.
La centralización no elimina el riesgo de credenciales
El diseño mejora el aislamiento solo cuando cada rol, clave, condición de confianza, endpoint y configuración de registro coincide con el espacio de trabajo previsto.
El riesgo más claro se encuentra en la ruta de desarrollo. Las propias instrucciones de AWS indican que una clave de API generada inicialmente incluye una política administrada con acceso a todos los espacios de trabajo.
Un administrador debe identificar el nuevo usuario de IAM subyacente creado, eliminar esa política y adjuntar una política en línea más restrictiva.
Ese flujo de trabajo es vulnerable al error humano. Un administrador podría limitar el usuario equivocado, conservar la política administrada o hacer referencia a un ARN de espacio de trabajo incorrecto.
La clave resultante seguiría funcionando. Su solicitud de desarrollo exitosa no revelaría que también conservaba acceso a producción.
Una prueba obligatoria de denegación puede detectar ese error. Las organizaciones deberían hacer que la prueba de acceso a producción forme parte de la emisión de claves, no una validación opcional realizada más tarde.
Las claves de larga duración también generan una atribución más débil que el acceso basado en roles. Varios desarrolladores que comparten una clave pueden aparecer como el mismo principal en los registros de auditoría.
Las claves individuales mejoran la atribución, pero amplían el número de credenciales que requieren almacenamiento seguro, expiración, revocación y seguimiento de titularidad.
La ruta entre cuentas tiene distintos modos de fallo. Una política de confianza puede ser demasiado amplia o el permiso de asunción del lado de la carga de trabajo puede alcanzar el rol de destino equivocado.
La condición aws:PrincipalOrgID ayuda a restringir el alcance organizativo. Sin embargo, no sustituye un ARN principal exacto ni una nomenclatura de roles cuidadosa.
Los permisos también merecen una revisión a nivel de acción. Conceder acceso con comodines en todo el espacio de nombres aws-external-anthropic socavaría la estructura de mínimo privilegio de la guía.
AWS publica ejemplos detallados de políticas de IAM para inferencia en un único espacio de trabajo y otros controles. Los equipos deberían validar sus políticas implementadas frente a las funciones de API que realmente utilizan.
La ruta OIDC desplaza la seguridad hacia las reclamaciones de identidad externas. Su seguridad depende de que el emisor, la audiencia, el filtro de sujeto, la política de rol y la lógica de renovación de tokens funcionen conjuntamente.
Un patrón de sujeto que cubra todo un grupo de repositorios podría autorizar canalizaciones no relacionadas. Un patrón amplio de cuenta de servicio puede admitir cargas de trabajo fuera del espacio de nombres previsto.
Las credenciales temporales limitan la duración de la exposición, pero no corrigen permisos excesivos durante esa duración. El acceso de corta duración es más seguro que el acceso permanente, pero no es automáticamente de mínimo privilegio.
El token de Claude generado también se convierte en una credencial bearer independiente. Hasta que expire, poseerlo basta para usarlo dentro del límite de autorización heredado.
Las aplicaciones deben evitar imprimirlo en registros, salida de compilación, trazas de excepciones o metadatos de monitorización. La vida útil del token debería coincidir con la duración del trabajo cuando sea viable.
El comportamiento regional añade otra restricción operativa. Los espacios de trabajo se crean en una región de AWS, y las solicitudes de API deben dirigirse al endpoint regional correspondiente.
AWS distingue esa vinculación al endpoint de la geografía de inferencia. La configuración de seguridad del espacio de trabajo determina de forma independiente si la inferencia utiliza enrutamiento de EE. UU. o global.
Las claves de corta duración solo funcionan con el mismo endpoint regional donde se generaron. Según la guía de AWS, las claves de API de larga duración no están bloqueadas por región.
Esta diferencia puede producir fallos confusos durante la implementación. Un proceso de renovación de tokens podría tener éxito en una región mientras una aplicación apunta a otro endpoint.
La arquitectura también tiene un límite más amplio que los compradores deben comprender. AWS afirma que Claude Platform on AWS es operado por Anthropic, con solicitudes y datos procesados fuera del límite de seguridad de AWS.
Esto distingue al servicio de la suposición de que todo el procesamiento permanece dentro de un perímetro de servicio controlado por AWS. Las organizaciones con requisitos estrictos de residencia necesitan una revisión independiente.
AWS posiciona Claude Platform on AWS como complemento de los modelos Claude disponibles mediante Amazon Bedrock. Por tanto, la elección no es simplemente un método de autenticación frente a otro.
Incluye características de la plataforma, responsabilidad operativa, límites de procesamiento y requisitos regionales. El acceso a múltiples entornos no resuelve esas cuestiones para todas las cargas de trabajo.
La centralización también puede aumentar el radio de impacto de los errores administrativos. La cuenta de AI Services alberga la suscripción, los espacios de trabajo, las claves de API y los roles de acceso.
Un cambio en esa cuenta puede afectar a varias cuentas de aplicaciones a la vez. Por tanto, el diseño debería aplicar controles de cambio más estrictos a esta cuenta que a un entorno de desarrollo informal.
Los equipos deberían separar la elaboración de políticas de su aprobación cuando sea posible. La infraestructura como código también puede reducir las definiciones de roles incoherentes entre equipos y espacios de trabajo adicionales.
AWS afirma que las organizaciones con más entornos pueden crear un espacio de trabajo para cada equipo o carga de trabajo y repetir el patrón de roles entre cuentas.
Este enfoque escala el modelo de aislamiento, pero también multiplica las políticas, relaciones entre roles, registros, etiquetas y configuraciones de endpoints. La disciplina operativa se convierte en el factor limitante.
Por tanto, la promesa central debe expresarse con cuidado. El patrón proporciona los componentes para el aislamiento de espacios de trabajo, pero las políticas implementadas y la gestión de credenciales determinan si dicho aislamiento se mantiene.
Qué deberían validar las empresas a continuación
La siguiente prueba consiste en determinar si las organizaciones pueden operar este modelo de acceso de forma consistente, no si los tres flujos de autenticación funcionan en una demostración.
La primera señal es la validación automatizada de políticas. Los equipos deben confirmar que cada rol de producción se dirige a un ARN de espacio de trabajo esperado y únicamente a las acciones de API necesarias.
La emisión de claves para desarrolladores debería incluir sustitución de políticas, expiración, almacenamiento de secretos y una prueba obligatoria de denegación en producción. Un proceso que depende de la memoria acabará desviándose.
Si las organizaciones automatizan estas comprobaciones mediante canalizaciones de implementación, el modelo centralizado de AWS gana credibilidad a escala. Las excepciones manuales repetidas debilitarían esa conclusión.
La segunda señal es la cobertura de auditoría. Los eventos de administración de CloudTrail por sí solos no proporcionan visibilidad de inferencia por llamada.
Las organizaciones deberían habilitar eventos de datos para el tipo de recurso de espacio de trabajo Claude pertinente y, después, verificar que los registros contienen una atribución útil del principal.
También deberían probar si los equipos de respuesta a incidentes pueden vincular una solicitud con un rol de EKS, una clave de desarrollador o una identidad OIDC externa.
Si la ruta de auditoría conserva esas distinciones, la arquitectura de tres rutas permite un acceso responsable. Si los registros reducen a los llamantes a identidades compartidas, la centralización ofrece menos valor para las investigaciones.
La tercera señal es la adopción más allá de las aplicaciones nativas de AWS. La ruta OIDC está diseñada para nubes externas, implementaciones de Kubernetes y sistemas de CI/CD.
Su verdadera prueba será la rotación fiable de tokens durante trabajos de larga ejecución. Los equipos también deben mantener reclamaciones de sujeto y audiencia restrictivas a medida que cambian los repositorios y las cuentas de servicio.
Los fallos de autenticación frecuentes animarían a los desarrolladores a recurrir a secretos de larga duración. Una renovación estable con condiciones de confianza precisas reforzaría el enfoque federado.
Las empresas también deberían supervisar la proliferación de espacios de trabajo. Crear un espacio de trabajo por equipo o carga de trabajo puede mejorar el aislamiento, la titularidad y la asignación de costes.
Demasiados espacios de trabajo sin etiquetas coherentes y reglas de ciclo de vida pueden crear otra forma de dispersión. Las claves antiguas, los roles abandonados y los espacios de trabajo sin uso necesitan un proceso de retirada.
La cuenta dedicada de AI Services debería convertirse en un límite de servicio gobernado. Sus administradores necesitan registros de titularidad para cada espacio de trabajo, rol y credencial.
Los equipos de plataforma pueden registrar las decisiones de acceso junto con la arquitectura de aplicaciones y los procedimientos de incidentes. Una base de conocimientos de ingeniería consultable puede ayudar a preservar esas asignaciones a medida que cambian los equipos.
La evaluación más útil comienza con una ruta completa de aplicación. Conecte una carga de trabajo de producción mediante SigV4, un cliente de desarrollo mediante una clave restringida y una canalización mediante OIDC.
Después, verifique las solicitudes entre espacios de trabajo denegadas, la renovación de tokens, los eventos de datos de CloudTrail y la revocación de emergencia. ¿Siguen manteniéndose esos controles después de cambios rutinarios en las políticas?
Esa respuesta importa más que la primera solicitud exitosa. El acceso a Claude Platform on AWS ahora admite tres entornos bajo una suscripción, pero su valor de seguridad depende de una prueba repetible de aislamiento.
