Respuesta directa
Revisar permisos del bucket, CORS y signed URLs es la primera acción. Por eso comprobar las reglas de CloudFront sobre orígenes, comportamientos e invalidaciones sigue acto seguido. En la práctica también se debe validar la sincronización del plugin con los logs y con AWS CLI. Dicho de otro modo, para 403 o URLs rotas hay que contrastar headers, regenerar URLs y, si es necesario, hacer rollback a medios locales. Opinión experta: es preferible invertir tiempo en diagnóstico antes que invalidar masivamente la CDN y disparar costes.
Resumen del proceso
- Inspección rápida de permisos y headers para identificar 403 o bloqueos por OAI OAC. 2. Validar sincronización del plugin con comandos aws s3 ls y revisar logs de sincronización. 3. Corregir políticas IAM y bucket policy aplicando JSON con least-privilege. 4. Configurar o corregir CORS en el bucket y verificar signed URLs. 5. Correlacionar S3 access logs y CloudFront logs con grep o CloudWatch Insights. 6. Regenerar URLs o invalidar CloudFront según convenga; si procede, rollback de medios locales. 7. Optimizar caché y minimizar invalidaciones para controlar costes.
Paso 1 Diagnosticar Problemas con CDN S3 offload
El primer paso es identificar qué falla: 403 en recursos estáticos, imágenes que no cargan, vídeos con buffering o URLs que devuelven 404. En la práctica se usan curl, Chrome DevTools y AWS CLI para validar en tres puntos: navegador (headers), S3 (origen) y CloudFront (CDN). Por eso conviene reproducir la comprobación desde una máquina local y desde producción para evitar falsos positivos por caché. El ejemplo siguiente se completa en menos de 10 minutos y es reproducible en cualquier entorno.
Ejecutar estos comandos de diagnóstico concreto:
curl -I https://cdn.example.com/wp-content/uploads/2026/03/imagen.jpg
aws s3api head-object --bucket mi-bucket --key "wp-content/uploads/2026/03/imagen.jpg"
aws s3 ls s3://mi-bucket/wp-content/uploads/2026/03/ --human-readable --summarize
Si head-object falla con AccessDenied, el origen bloquea el acceso. Si head-object muestra metadata pero curl devuelve 403, el bloqueo se sitúa entre CloudFront y S3 (OAI OAC o bucket policy). El error típico aquí es asumir que el plugin hizo el sync: muchas veces el objeto no existe o tiene una clave distinta por prefijos. Este diagnóstico tarda alrededor de 10 a 20 minutos por recurso y entre 30 y 90 minutos para identificar patrones en varios recursos.
Paso 2 Verificar permisos IAM y política del bucket
Verificar las diferencias entre IAM roles/policies y bucket policy/ACL. En la práctica OAI y OAC requieren statements distintos. OAC, que usa firmas SigV4, exige permitir el servicio cloudfront.amazonaws.com y condicionar al ARN de la distribución o a la cuenta. A continuación un ejemplo práctico de política válida para OAC:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowCloudFrontServicePrincipal",
"Effect": "Allow",
"Principal": {"Service": "cloudfront.amazonaws.com"},
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::mi-bucket/*",
"Condition": {
"StringEquals": {
"AWS:SourceArn": "arn:aws:cloudfront::123456789012:distribution/EDFDVBD6EXAMPLE"
}
}
}
]
}
Nota práctica: si se usa OAI, aplicar la política clásica; si se usa OAC, usar la política con Principal por Service y Condition sobre AWS:SourceArn o AWS:SourceAccount. Verificar siempre el ARN de la distribución y el número de cuenta antes de aplicar la policy. El error frecuente es copiar un ARN antiguo o equivocado; eso bloquea el tráfico y suele detectarse en segundos, aunque la propagación de cambios puede tardar entre 1 y 5 minutos.
⚠️ Atención
No sustituir la política del bucket por una policy pública completa salvo para pruebas. Lo recomendable es añadir solo la statement que permita lectura desde la identidad de CloudFront.
Signed URLs y contenido privado Recomendaciones y ejemplos prácticos
Cuando el contenido debe ser privado conviene distinguir entre presigned URLs de S3 y CloudFront Signed URLs o Signed Cookies. Dicho de otro modo, las presigned URLs de S3 son válidas por corto tiempo y CloudFront Signed URLs evitan pasar por S3 en cada petición. Para generar una presigned URL desde la CLI usar:
aws s3 presign s3://mi-bucket/wp-content/uploads/imagen.jpg --expires-in 3600
Para entornos WordPress lo habitual es mantener los objetos no públicos en S3 y usar CloudFront con OAC más CloudFront Signed URLs. El flujo correcto es: crear una key-pair en CloudFront, firmar la URL en el backend y devolverla al navegador. La política del bucket debe permitir acceso solo a CloudFront y al backend cuando proceda. En la práctica la caducidad típica es entre 5 y 60 minutos para evitar cachés inconsistentes. Opinión experta: usar CloudFront Signed URLs es la opción más segura y escalable en entornos con muchos usuarios autenticados.
Paso 3 Solucionar CORS que afecta al offload S3
Los problemas CORS se ven como recursos cargados pero bloqueados en consola con mensajes tipo "Access to image at '...' from origin 'https://example.com' has been blocked by CORS policy". Por eso primero hay que revisar la configuración actual del bucket con AWS CLI:
aws s3api get-bucket-cors --bucket mi-bucket
Si no existe CORS o es insuficiente, aplicar una configuración mínima compatible con WordPress y previews embebidos:
aws s3api put-bucket-cors --bucket mi-bucket --cors-configuration '{"CORSRules":[{"AllowedOrigins":["https://example.com","https://www.example.com"],"AllowedMethods":["GET","HEAD"],"AllowedHeaders":["*"],"MaxAgeSeconds":3000}]}'
Ejemplo de error típico: usar AllowedOrigins con * cuando hay signed URLs o cookies; los navegadores bloquean credenciales con wildcard. Si la web usa signed URLs o cookies, especificar el origen exacto y no usar *. Este paso suele tardar entre 2 y 5 minutos.
Si las peticiones son AJAX desde un subdominio distinto, añadir OPTIONS a AllowedMethods para que el preflight responda. Ejemplo CORS para signed URLs y preflight:
{
"CORSRules": [
{
"AllowedOrigins": ["https://example.com"],
"AllowedMethods": ["GET","HEAD","OPTIONS"],
"AllowedHeaders": ["Authorization","Content-Type","*"],
"MaxAgeSeconds": 3600
}
]
}
Consejo experto: cuando las URLs son signed con expiración corta, el navegador puede cachear una respuesta 403. Por eso borrar cache o usar un querystring único para pruebas evita falsos negativos.
💡 Consejo
Para probar CORS desde línea de comandos usar curl añadiendo el header Origin y verificar Access-Control-Allow-Origin:
curl -I -H "Origin: https://example.com" https://cdn.example.com/archivo.jpg
Infografía proceso visual
Flujo de diagnóstico:
1 Consultar navegador y curl → 2 Verificar S3 con AWS CLI → 3 Revisar CloudFront y policy. Resultado típico: 403 acceso denegado, 404 objeto no encontrado, 200 correcto.
Paso 4 Reparar URLs rotas por CDN S3
Las URLs rotas aparecen por rutas de objeto erróneas, fallos de sincronización del plugin o cambios en el prefijo del bucket. En la práctica hay que comparar la URL rota con la estructura de claves en S3. Por ejemplo, si la URL es https://cdn.example.com/wp-content/uploads/2026/03/imagen.jpg y aws s3 ls s3://mi-bucket/wp-content/uploads/2026/03/ no muestra ese archivo, la sincronización falló.
Revisar los logs del plugin de offload. En WP Offload Media suelen estar en wp-content/uploads/wp-offload-logs o accesibles desde la interfaz del plugin. Buscar errores con grep:
grep -i "error" wp-content/uploads/wp-offload-logs/*.log | tail -n 50
Forzar re-sincronización de objetos faltantes con un flujo reproducible y seguro. Primero hacer dry-run y revisar la lista. Después ejecutar la subida real:
> dry-run para ver qué subiría
aws s3 sync wp-content/uploads/ s3://mi-bucket/wp-content/uploads/ --dryrun
> si está bien, ejecutar
aws s3 sync wp-content/uploads/ s3://mi-bucket/wp-content/uploads/ --acl private --storage-class STANDARD
La forma rápida es ejecutar sync --delete, pero la forma correcta es primero --dryrun, revisar listados y después subir. Un fallo habitual es no excluir archivos temporales como .DS_Store o thumbs.db, lo que provoca sobrecostes de transferencia.
Paso 5 Analizar logs y correlacionar fallos
Los S3 access logs y los CloudFront logs permiten saber si la petición fue rechazada por S3 o por la CDN. Procedimiento concreto y reproducible:
1 Habilitar S3 server access logs si no están activos y esperar 5 a 15 minutos a que aparezcan. 2 Descargar o consultar los logs con AWS CLI o desde la consola. 3 Usar grep y awk para búsquedas rápidas en ficheros locales.
Corrección práctica: aws s3 cp no vuelca un prefijo entero por stdout para grepear directamente; por eso descargar el fichero primero o listar y procesar cada archivo localmente. Ejemplos de flujo funcional:
> Descargar un log concreto y buscar 403
aws s3 cp s3://mi-bucket-logs/cloudfront/2026-03-11/access-log-0001.gz ./access-log-0001.gz
zcat access-log-0001.gz | grep " 403 " | head -n 50
> Listar objetos y procesar en bucle
aws s3 ls s3://mi-bucket-logs/cloudfront/2026-03-11/ --recursive | awk '{print $4}' | while read key; do
aws s3 cp s3://mi-bucket-logs/cloudfront/2026-03-11/$key /tmp/$key
zcat /tmp/$key | grep " 403 " | head -n 20
done
Alternativa rápida: si los logs están en CloudWatch Logs, usar CloudWatch Insights para filtrar 403 sin descargar ficheros. Estas correcciones evitan el uso inválido de aws s3 cp con pipes y ofrecen flujos reproducibles y escalables.
