Cómo activar AWS Bedrock en Europa con modelos Anthropic Claude: guía completa de errores y soluciones reales

Activar AWS Bedrock con modelos Anthropic Claude en una región europea no es trivial. Los errores que aparecen son crípticos (INVALID_PAYMENT_INSTRUMENT cuando tienes tarjeta válida, Operation not allowed cuando tienes credenciales), y AWS no documenta bien el flujo correcto. Este artículo documenta todos los errores reales que nos encontramos al activar Bedrock EU Geo con modelos Anthropic desde una cuenta AWS europea con facturación empresarial española, y las soluciones concretas para cada uno.

Los 3 tipos de endpoint Bedrock y por qué importan

Antes de entrar en errores, hay que entender la terminología de AWS. Existen 3 perfiles de inferencia distintos para cada modelo, y elegir el incorrecto puede significar que tus datos crucen el Atlántico sin que lo sepas.

Conclusión técnica: para RGPD estricto en producción, usa siempre el prefijo eu. con región eu-west-1 o eu-central-1. El problema es que muchos modelos nuevos solo existen como inference profile eu.*, no como in-region puro. Lo implementamos automáticamente en el código según la región del AWSProvider.

Error #1: “Class BedrockRuntimeClient not found”

Síntoma

Causa

Al ejecutar composer require aws/aws-sdk-php desde una shell con el directorio de trabajo en un directorio distinto al del proyecto Laravel, composer instala el SDK en el directorio padre incorrecto. El autoload de Laravel no lo encuentra.

Solución

Forzar el working dir en composer:

Verificar que se creó la carpeta vendor/aws/aws-sdk-php/src/BedrockRuntime/.

Error #2: “ValidationException: Operation not allowed”

Síntoma

Causa

El usuario IAM que genera las credenciales AWS no tiene permiso para invocar modelos Bedrock. Las credenciales son válidas (AWS autentica) pero la operación está denegada.

Solución

Consola AWS → IAM → Users → tu usuario → Permissions → Add permissions → Attach policies directly → marcar AmazonBedrockFullAccess. Para producción restrictiva, crear policy custom con solo bedrock:InvokeModel, bedrock:Converse y bedrock:InvokeModelWithResponseStream.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "DenyBedrockOutsideEU",
            "Effect": "Deny",
            "Action": "bedrock:*",
            "Resource": "*",
            "Condition": {
                "StringNotEquals": {
                    "aws:RequestedRegion": [
                        "eu-west-1",
                        "eu-central-1",
                        "eu-west-3",
                        "eu-south-1",
                        "eu-north-1",
                        "eu-west-2",
                        "eu-central-2"
                    ]
                }
            }
        }
    ]
}

Error #3: “The provided model identifier is invalid”

Síntoma

Causa

El model ID no corresponde con ningún modelo publicado por AWS en esa región. Las causas más comunes: el sufijo de versión/fecha cambia (20250929 vs 20251101), el modelo no está disponible en esa región EU (está solo en US), o usas el formato “comercial” en vez del modelId técnico.

Solución

Enumerar los IDs reales desde el SDK probando candidatos:

$candidates = [
    'eu.anthropic.claude-opus-4-5-20251029-v1:0',
    'eu.anthropic.claude-opus-4-5-20251101-v1:0',
];
foreach ($candidates as $id) {
    try {
        $client->converse([
            'modelId' => $id,
            'messages' => [['role' => 'user', 'content' => [['text' => 'ping']]]],
            'inferenceConfig' => ['maxTokens' => 5],
        ]);
        echo "$id OK\n";
    } catch (Exception $e) {
        echo "$id FAIL: " . $e->getMessage() . "\n";
    }
}

IDs correctos verificados (abril 2026) en Bedrock EU Irlanda:

Error #4: “INVALID_PAYMENT_INSTRUMENT” — el más complicado

Síntoma

Este es el error que más confusión genera. El mensaje dice “payment instrument” pero puede fallar aunque tengas tarjeta válida añadida. La razón es cómo funciona AWS Marketplace con productos de terceros (Anthropic, Mistral), que es diferente a productos nativos de AWS (Nova, Llama vía Meta directo).

La secuencia real que ocurre

Cuando invocas un modelo Claude por API, AWS intenta auto-crear una suscripción en Marketplace a ese producto. Para ello necesita: método de pago verificado completamente (estado “Verified”), datos fiscales completos (CIF/VAT), y dirección de facturación completa. Si algo falla, AWS crea un agreement con precio $0.00, lo marca “Terminated” inmediatamente, y te devuelve INVALID_PAYMENT_INSTRUMENT. Recibes dos emails casi simultáneos: uno “agreement accepted” y otro “agreement expired”. Cada intento fallido genera un nuevo agreement fantasma en tu historial.

Por qué nuestra cuenta fallaba

Teníamos varios problemas acumulados: American Express marcada como default había caducado (AWS intentaba cargar ahí primero), SEPA bank account recién añadida con mandato pendiente de 3-7 días bancarios, y Visa añadida al final pero no marcada aún como default. En nuestro caso acumulamos 8 agreements fantasma antes de resolver el problema.

Solución paso a paso (la que funcionó)

1. Limpiar métodos de pago caducados. Consola AWS → Billing and Cost Management → Preferencias de pago → Métodos de pago. Eliminar tarjetas caducadas, dejar solo los métodos activos y verificados.

2. Añadir tarjeta de crédito verificable al instante. Las cuentas SEPA tardan 3-7 días en verificar. Si necesitas desbloquear rápido: agregar una Visa/Mastercard (personal o empresa). AWS hace autorización de 1€ y la verificación es instantánea. Marcarla como “Predeterminado”.

3. Verificar datos fiscales. Configuración de impuestos en Billing: país España, CIF/VAT completo (ej. ESB57029415), estado “Verificado”.

4. Descartar Private Marketplace. Si tu cuenta está en una AWS Organization, puede haber restricciones. Busca “Private Marketplace” en la consola. Si ves “No le rige una experiencia de Private Marketplace”, no es tu problema.

6. Verificar en Marketplace → Manage subscriptions. Deben aparecer como suscripciones activas, no Terminated. Esperar 2-5 minutos para propagación y probar de nuevo.

Error #5: Modelos legacy sin perfil EU visible en Playground

En la UI de Bedrock Playground, al seleccionar Claude Haiku 3 no aparece la opción “EU Anthropic Claude Haiku 3”. Solo aparece “Bajo demanda”. Esto sugiere que el modelo no tiene Geo EU estricto. Pero es engañoso.

La UI de Playground oculta inference profiles que sí existen por API. El modelo sí tiene perfil Geo EU disponible. Solo hay que invocarlo con el prefijo eu. desde código:

$client->converse([
    'modelId' => 'eu.anthropic.claude-3-haiku-20240307-v1:0',
    ...
]);

La UI simplemente no lista el selector visual, pero el endpoint está activo.

Error #6: Agreements “Terminated” acumulados en Marketplace

Al entrar a AWS Marketplace → Manage subscriptions → Inactive, aparece una lista de 5, 8, 10 agreements del mismo modelo Claude, todos con estado “Terminated” y fechas consecutivas.

Cada vez que una invocación API falla por INVALID_PAYMENT_INSTRUMENT, AWS genera un nuevo agreement fantasma. No tienen impacto real: son solo registros de auditoría. No se pueden borrar. Cuando finalmente creas una suscripción exitosa, aparece como nueva entrada en “Active” y las “Terminated” quedan como historia. Si sigues acumulándolos tras resolver pagos, revisa que el usuario IAM no esté reintentando masivamente.

Diferencias entre proveedores Bedrock: por qué Amazon Nova funciona y Claude no

Nova no pasa por AWS Marketplace. Son modelos de AWS directo. Por eso en pruebas iniciales, cuando Claude fallaba con INVALID_PAYMENT_INSTRUMENT, Nova Micro, Lite y Pro respondían perfectamente. Si estás bloqueado con Claude pero necesitas producción, empieza con Amazon Nova.

Regla general: si tu proveedor pasa por Marketplace, asegúrate primero de tener tarjeta verificada antes de intentar usarlo.

Almacenamiento seguro de credenciales

Una vez todo funcionó, las credenciales AWS quedan guardadas encriptadas en base de datos con Laravel Crypt::encryptString() (AES-256). Las claves nunca aparecen en texto plano en logs, base de datos ni código fuente. Solo se desencriptan al momento de instanciar el cliente AWS:

$client = new BedrockRuntimeClient([
    'region' => $credentials['aws_region'],
    'credentials' => [
        'key'    => Crypt::decryptString($credentials['aws_access_key_id']),
        'secret' => Crypt::decryptString($credentials['aws_secret_access_key']),
    ],
]);

Garantías RGPD obtenidas

Tras resolver todos los errores, la configuración final proporciona: región AWS fijada a eu-west-1 (Irlanda), prefijo eu. automático en todos los modelIds para Geo Cross-region EU, IAM policy defensiva que bloquea regiones no-EU, facturación AWS EMEA SARL (Luxemburgo) en EUR, CIF empresarial verificado, AWS DPA (Data Processing Addendum) firmado automáticamente, y credenciales AWS encriptadas AES-256 en base de datos. Documentación legal suficiente para responder a cualquier auditor RGPD.

Checklist final de activación

Si estás intentando activar AWS Bedrock EU con Claude y te sale algún error, sigue este orden:

Precios resultantes del stack completo

Una vez resueltos todos los errores, el stack multi-proveedor con data residency EU estricto queda así:

Todo bajo el mismo paraguas de AWS, con facturación unificada, DPA firmado y garantías RGPD contractuales. El coste total de las pruebas de activación fue de $0.002 (4 tests Claude + 8 tests Nova/Mixtral). Las pruebas en Bedrock son insignificantes en coste.

Escrito tras resolver un caso real de activación Bedrock EU + Anthropic desde cuenta AWS europea con facturación empresarial española. Abril 2026.