A company has an on-premises website application that provides real estate information for potential renters and buyers. The website uses a Java backend and a NoSQL MongoDB database to store subscriber data.
The company needs to migrate the entire application to AWS with a similar structure. The application must be deployed for high availability, and the company cannot make changes to the application.
Which solution will meet these requirements?
The company needs to migrate its Java backend and MongoDB database to AWS without making any changes to the application. Amazon DocumentDB (with MongoDB compatibility) is specifically designed to be compatible with MongoDB, making it a suitable choice for the subscriber data without necessitating any application changes. By deploying Amazon DocumentDB with appropriately sized instances in multiple Availability Zones, the company ensures high availability. For the Java backend application, deploying Amazon EC2 instances in an Auto Scaling group across multiple Availability Zones will also provide high availability and scalability. This setup meets all the requirements specified by the company.
C correct DocumentDB only have on-demand instance but not on-demand capacity mode, the mode is for DynamoDB
A = Aurora supports MySQL and PostgreSQL, not MongoDB. App changes are not allowed B = This could work but DocumentDB provides managed MongoDB instance that is preferable C = correct D = there isn't on-demand capacity mode, in 2022 launched MondoDB Elastic Cluster that eliminates the need to choose, manage or upgrade instances and allows to scale up to 4PiB storage whereas instance based scales up to 128TiB. I thing this question is pre elastic cluster as this is ambiguous between C and D
'Appropriately sized instances' Means on-demand ? that is quite vague..
Amazon DocumentDB does NOT have on-demand capacity mode, so its option C.
There is no on-demand capacity for DocumentDB, however Elastic Cluster option is provided "Elastic Clusters enables you to elastically scale your document database to handle millions of writes and reads, with petabytes of storage capacity" see https://aws.amazon.com/documentdb/faqs/#:~:text=to%20learn%20more.-,Elastic%20Clusters,-What%20is%20Amazon
DocumentDB does indeed support on-demand capacity mode (Contrary to what other users say here) https://aws.amazon.com/blogs/database/running-spiky-workloads-and-optimizing-costs-by-more-than-90-using-amazon-dynamodb-on-demand-capacity-mode/ but this mode is good for spikey workloads and does not address the high availablity requirement
The correct link https://www.applytosupply.digitalmarketplace.service.gov.uk/g-cloud/services/743016963590682
The content mentioned in your link and the original comment are both mentioning things related to DynamoDB. Your link is even worse which is describing DynamoDB but say it is for DocumentDB. Please study hard
I was leaning towards Option C but "Appropriately sized instances" is vague since the question does not state the size of Mongo DB. On-demand instances serve the purpose here, they are offered by DocumentDB, see the link https://aws.amazon.com/documentdb/pricing/
its a c
c-c-c-c-c-c-c-c On-demand capacity mode as suggested in D may not provide the same level of high availability as multi-Availability Zone deployments. So it's c-c-c-c-c-c-c for me.
See best practices for amazon documentdb - instance sizing in docs. Addicionally there is no on-demand capacity mode.
Going wit C. I still call the DocumentDB used in mode C "on-demand mode" because you have to select the Ec2 instance; the pricing documentation still uses that name. There is an Elastic cluster for DocumentDB. Could it be that option D "on-demand capacity mode" is referring to Elastic mode?
D is the correct answer https://aws.amazon.com/documentdb/pricing/ on-demand instance is supported by DocumentDB
C, documented. No exists the on-demand capacity mode
DocumentDB does indeed support on-demand capacity mode (Contrary to what other users say here) https://aws.amazon.com/blogs/database/running-spiky-workloads-and-optimizing-costs-by-more-than-90-using-amazon-dynamodb-on-demand-capacity-mode/ On-Demand is ideally to a use case where you have unpredictable or variable database workloads, like this case, it is not said anywhere the expected workload, so it is better to start with On-demand , and later when you know the workload you can cahnge it.
what you have linked here is a dynamodb article not a documentDB one, documentDB does not support on-demand capacity mode - https://aws.amazon.com/documentdb/faqs/ "You can scale the compute resources allocated to your instance in the AWS Management Console by selecting the desired instance and clicking the “modify” button. Memory and CPU resources are modified by changing your instance class."
There is no on-demand capacity for DocumentDB, however Elastic Cluster option is provided "Elastic Clusters enables you to elastically scale your document database to handle millions of writes and reads, with petabytes of storage capacity" see https://aws.amazon.com/documentdb/faqs/#:~:text=to%20learn%20more.-,Elastic%20Clusters,-What%20is%20Amazon
This is DynamoDB, not DocumentDB. The choices only mention DocumentDB.
There is no on-demand capacity mode for DocumentDB, though there is on-demand vCPU based pricing available.
There is no on-demand capacity for DocumentDB, however Elastic Cluster option is provided "Elastic Clusters enables you to elastically scale your document database to handle millions of writes and reads, with petabytes of storage capacity" see https://aws.amazon.com/documentdb/faqs/#:~:text=to%20learn%20more.-,Elastic%20Clusters,-What%20is%20Amazon
See best practices for amazon documentdb - instance sizing in docs.
Amazon DocumentDB does not support an on-demand capacity mode. You can only choose from different instance classes that have fixed compute and memory resources. However, you can scale your instances up or down as needed, and you can also pause and resume your instances to save costs. Amazon DocumentDB also automatically scales your storage and I/O based on your data size and workload.
C - there is no on-demand capacity mode.