Una empresa migró una aplicación de dos niveles a AWS. El nivel de datos es una implementación Multi-AZ de Amazon RDS for Oracle con 12 TB de almacenamiento Amazon EBS de SSD de propósito general. La aplicación almacena documentos como BLOBs (promedio de 6 MB). El crecimiento de la base de datos ha reducido el rendimiento y aumentado los costos de almacenamiento. La empresa necesita una solución de mayor rendimiento, altamente disponible, resiliente y rentable. ¿Qué opción cumple con estos requisitos?

La opción correcta es crear un bucket de Amazon S3 y actualizar la aplicación para almacenar documentos allí, manteniendo los metadatos en la base de datos RDS. Los BLOBs de 6 MB son objetos grandes que no son ideales para almacenar directamente en una base de datos relacional como RDS, especialmente a medida que la base de datos crece a 12 TB. Almacenar estos objetos en S3, un servicio de almacenamiento de objetos altamente escalable, duradero y de bajo costo, reduce significativamente la carga de almacenamiento en RDS, mejora el rendimiento de la base de datos y reduce los costos. RDS puede entonces enfocarse en la gestión de datos estructurados y metadatos. Las otras opciones son incorrectas porque: Reducir el tamaño de la instancia de RDS y cambiar a almacenamiento Magnetic reduciría el rendimiento y la disponibilidad, y Magnetic no es adecuado para cargas de trabajo de alto rendimiento. Aumentar el tamaño de la instancia de RDS y usar Provisioned IOPS aumentaría el rendimiento, pero no abordaría el problema subyacente de almacenar BLOBs grandes en una base de datos relacional, lo que seguiría siendo costoso y menos eficiente que S3 para este caso de uso. Migrar a DynamoDB implicaría una reescritura significativa de la aplicación y la base de datos, lo cual es más complejo y costoso que simplemente externalizar los BLOBs a S3, y DynamoDB no es el servicio más rentable para almacenar objetos grandes como BLOBs.