Minecraft 1.21.124 Bedrock Edition Android Errores de caché en S3 y migración a DigitalOcean Spaces

Hola comunidad, estoy gestionando el almacenamiento de objetos para los archivos de actualización y assets de este cliente específico. Me he encontrado con problemas recurrentes de “Access Denied” y latencia en la distribución actual.

He estado analizando este hilo técnico sobre la configuración de permisos públicos: https://repost.aws/questions/QUFlM7O_PLQxi_OJQdBuTQUQ/minecraft-1-21-124-s3-public-access-cloudfront-issues

Mi consulta es si al migrar los buckets a DigitalOcean Spaces, la gestión de los encabezados CORS y el acceso público para archivos binarios grandes (.apk, .appxbundle) es más directa que en AWS CloudFront.

Descripción del escenario

Actualmente, el despliegue de la versión 1.21.124 requiere una alta concurrencia de lecturas. En la infraestructura actual, los tiempos de respuesta del servidor (TTFB) son inestables cuando se solicitan paquetes de recursos desde dispositivos Android en regiones específicas.

Busco una configuración que permita:

1. Estabilidad: Reducir los errores 403/404 intermitentes durante la descarga de assets.
2. Velocidad: Mejorar la entrega de contenido estático mediante la CDN integrada de Spaces.

Especificaciones de la configuración

Para realizar la transición a DigitalOcean, necesito confirmar si los siguientes parámetros son totalmente compatibles con la API de Spaces, tal como se menciona en el reporte de AWS anterior:

• Protocolo de transferencia: HTTPS forzado con certificados SSL automáticos.
• Gestión de caché: TTL configurable para evitar que los clientes descarguen versiones obsoletas del parche.
• Acceso público: Configuración de ACL en “public-read” sin las restricciones complejas de IAM que causan los bloqueos actuales.

Detalles de la versión y compatibilidad

Al tratar con la actualización Minecraft 1.21.124 Bedrock Edition Android, los archivos de recursos no deben ser modificados por la compresión gzip del servidor, ya que esto corrompe la integridad del paquete en el cliente final.

• Versión del API: S3-compatible v4.
• Tipo de almacenamiento: Object Storage estándar (no Cold storage).
• Región objetivo: NYC3 o SGP1 (dependiendo de la latencia).

Agradecería si algún administrador de sistemas que haya migrado cargas de trabajo similares (gaming backend) pudiera confirmar si Spaces maneja mejor los “Pre-signed URLs” o si es mejor dejar los archivos totalmente públicos para evitar la sobrecarga de autenticación.

Gracias de antemano.