Validación del uso de CloudFront en un entorno multi-tenant con behaviors + Lambda@Edge y recomendaciones para obtener un comportamiento predecible.

Question

Problemas

1. CloudFront no se comporta de forma determinista
     En varias iteraciones, aun teniendo el behavior /api/* configurado, las peticiones a /api/... terminaban respondiéndonos
     desde el comportamiento por defecto (S3) con 403 AccessDenied. En otras ocasiones sí se aplica el behavior y el
     Lambda@Edge reescribe el path correctamente. Necesitamos ayuda para validar la configuración adecuada de behaviors y
     Lambda@Edge en un escenario multi-tenant.
  2. Subida de documentos desde el navegador
      - Lado servidor: GET /api/upload-url (pasando tenant_id, filename, etc.) responde 200 via CloudFront → API Gateway →
        Lambda, y el PUT presignado a S3 con curl funciona.
      - Lado cliente: desde el dashboard (con sesión Cognito) el fetch falla con “Failed to fetch”, aunque el presign Lambda
        no registra errores. Sospechamos de cabeceras CORS/preflight o de que el front no esté transmitiendo el token/tenant
        como espera el API.
  3. Buckets por tenant vs. bucket central
     El diseño original contemplaba un bucket individual por tenant en otra región, pero actualmente no existen. Hemos
     cambiado a un bucket central, pero necesitamos criterio de AWS para decidir cuál es la opción idónea (y cómo manejarlo
     si queremos volver a buckets individuales).
  4. Operativa Cuenta Madre vs. cuentas hijas
     A nivel conceptual también queremos saber si es mejor mantener todo en la “cuenta madre” o delegar APIs/buckets en
     cuentas hijas (cada tenant tiene la suya). Buscamos recomendaciones sobre la arquitectura multi-tenant más estable en
     este escenario.

———

Qué solicitamos

- Validación del uso de CloudFront en un entorno multi-tenant con behaviors + Lambda@Edge y recomendaciones para obtener un
    comportamiento predecible.
  - Pautas concretas para presigned uploads detrás de CloudFront (headers, CORS, políticas S3) cuando el cliente usa Cognito.
  - Recomendaciones sobre la conveniencia de buckets/API centralizados frente a recursos dedicados por tenant.
  - Un checklist de pruebas/monitorización sugerido por AWS para detectar rápidamente configuraciones erróneas en CloudFront
    o S3.

Gracias de antemano por cualquier guía o buenas prácticas que puedan compartir.

re:Post Agent · Answer

Para resolver los problemas con CloudFront en un entorno multi-tenant, voy a proporcionarle recomendaciones específicas:

## 1. Comportamiento no determinista de CloudFront

El problema que describe donde algunas peticiones a `/api/*` se procesan correctamente y otras terminan en el comportamiento por defecto (S3) con error 403 puede deberse a:

- **Configuración incorrecta de los path patterns**: Verifique que ha asociado la función CloudFront con el comportamiento de caché correcto y los patrones de ruta para las solicitudes que desea modificar.
- **Precedencia de comportamientos**: Si varios comportamientos coinciden con las mismas solicitudes, CloudFront utiliza el que tiene mayor precedencia.

Para solucionar esto:
1. Abra la consola de CloudFront
2. En el panel de navegación, elija "Distributions" y seleccione su distribución
3. Vaya a la pestaña "Behaviors" y revise el patrón de ruta para cada comportamiento
4. Asegúrese de que el comportamiento para `/api/*` tenga mayor precedencia que el comportamiento por defecto

## 2. Subida de documentos desde el navegador

El problema con las subidas presignadas desde el navegador podría estar relacionado con:

- **Configuración CORS**: Asegúrese de que su bucket S3 tenga una política CORS adecuada que permita solicitudes desde su dominio de CloudFront
- **Headers en la URL presignada**: Verifique que está generando correctamente la URL presignada con todos los headers necesarios
- **Autenticación**: Confirme que el token de Cognito se está pasando correctamente en las solicitudes

## 3. Buckets por tenant vs. bucket central

Ambos enfoques tienen ventajas:

**Bucket central**:
- Más fácil de administrar
- Menor sobrecarga operativa
- Mejor para tenants pequeños o con poco uso

**Buckets individuales por tenant**:
- Mayor aislamiento de datos
- Posibilidad de políticas de seguridad específicas por tenant
- Mejor para cumplimiento normativo cuando se requiere separación estricta

La elección depende de sus requisitos específicos de seguridad, cumplimiento y escala.

## 4. Operativa master vs. cuentas hijas

**Todo en cuenta madre**:
- Más simple de gestionar
- Menor sobrecarga administrativa
- Mejor para un número limitado de tenants

**Cuentas hijas por tenant**:
- Mayor aislamiento
- Límites de servicio independientes
- Mejor para tenants grandes o con requisitos específicos de seguridad

## Recomendaciones adicionales:

1. **Para CloudFront con Lambda@Edge**:
- Utilice patrones de ruta específicos y no superpuestos
- Ordene los comportamientos de más específico a más general
- Pruebe las funciones Lambda@Edge exhaustivamente antes de implementarlas

2. **Para uploads presignados**:
- Configure correctamente CORS en el bucket S3
- Incluya todos los headers necesarios en la URL presignada
- Asegúrese de que las políticas de bucket permitan las operaciones necesarias

3. **Checklist de monitorización**:
- Configure CloudWatch Alarms para errores 4xx y 5xx
- Monitorice los logs de CloudFront y Lambda@Edge
- Implemente pruebas automatizadas para verificar regularmente que los comportamientos funcionan según lo esperado
- Revise periódicamente las configuraciones de seguridad y acceso  
**Sources**  
[Troubleshoot CloudFront function URI rewrite issues | AWS re:Post](https://repost.aws/knowledge-center/cloudfront-uri-rewrite)

Validación del uso de CloudFront en un entorno multi-tenant con behaviors + Lambda@Edge y recomendaciones para obtener un comportamiento predecible.

1. Comportamiento no determinista de CloudFront

2. Subida de documentos desde el navegador

3. Buckets por tenant vs. bucket central

4. Operativa master vs. cuentas hijas

Recomendaciones adicionales:

Añade tu respuesta

Contenido relevante