A company is migrating a legacy application from an on-premises data center to AWS. The application uses MongoDB as a key-value database. According to the company's technical guidelines, all Amazon EC2 instances must be hosted in a private subnet without an internet connection. In addition, all connectivity between applications and databases must be encrypted. The database must be able to scale based on demand.
Which solution will meet these requirements?
To meet the requirements of migrating a legacy application using MongoDB to AWS, the solution should ensure compatibility with MongoDB, scalability, and encryption for connectivity. Amazon DocumentDB (with MongoDB compatibility) aligns with this as it is designed to support MongoDB workloads, providing compatibility for existing MongoDB applications without the need for extensive modification. The use of Provisioned IOPS volumes ensures the performance needs, and the cluster endpoint facilitates secure and accurate connections to the primary instance within a private subnet. This setup meets the company's guidelines of hosting without an internet connection and ensuring encrypted connectivity.
Both answers with provisioned IOPS don't scale on demand. Eliminate A and D. DynamoDB and S3 both use Gateway Endpoints, so it is B. For debate on Dynamo vs Document, it works in Mongo as key/value outside, so it will work with either Dynamo or Document. Would have gone with DocumentDB if not for provisioned IOPS and requirement it scale on-demand.
What about "all Amazon EC2 instances must be hosted in a private subnet without an internet connection." It clearly states that it can not be a Gateway - it needs to be Interface endpoint - so C imho
Apps will run in the EC2s and connect to DynamobDB using Gateway endpoint.
D, seems about right. https://docs.aws.amazon.com/documentdb/latest/developerguide/endpoints.html Cluster endpoint A cluster endpoint is an endpoint for an Amazon DocumentDB cluster that connects to the current primary instance for the cluster. Each Amazon DocumentDB cluster has a single cluster endpoint and one primary instance. In case of a failover, the cluster endpoint is remapped to the new primary instance. Vs Instance endpoint An instance endpoint is an endpoint that connects to a specific instance. Each instance in a cluster, regardless of whether it is a primary or replica instance, has its own unique instance endpoint. It is best to not use instance endpoints in your application. This is because they can change roles in case of a failover, thus requiring code changes in your application.
happy with that explanation
Vpc gateway + scale on demand
B, DynamoDB uses Gateway Point to allow connection from VPC
B Vpc gateway
D: Legacy application, You can not request the team to change all application to make request to dynamo instead of Mongo
what about scaling?
What about it Dynamodb does not work. It never gets any data and so does not scale the slightest. It stays at zero utilization. Without refactoring/rewriting the application no way to make an application that speaks Mongo work with dynamodb.
Bad question. If a legacy application is written to use Mongo DB it will not work with DynamoDB. Yes it seems possible that the company we bought/lisenced that application could create a new version for DynamoDB as it only needs a key-value store. So we have to options: Convince and pay some third party to write a new version of the application that is compatible with DynamoDB or use DocumentDB Depending on that decision the answer would is B or D. In the meantime, until the new application for Dynamodb is available. I would suggest to use MongoDB. That is D.
Vpc gateway + scale on demand + being exchanged over an AWS PrivateLink is also encrypted
interface VPC endpoint uses private link encripted
"all Amazon EC2 instances must be hosted in a private subnet without an internet connection." It clearly states that it can not be a Gateway - it needs to be Interface endpoint - so C
Going for B https://docs.aws.amazon.com/vpc/latest/privatelink/aws-services-privatelink-support.html DynamoDB not supported by private link Gateway endpoint not relies on private link therefore B
And change all legacy application code to persist and request data to dynamo...?
I'll go with B Why not A and D -> They use "provisioned IOPS", so they don't scale on demand. B-> DynamoDB works with key/value and uses Gateway Endpoints
I think B is correct, and ChatGPT also confirmed B. I am going with B
I totally agree... B is the correct answer✅
I preferred D as the answer. First C is apparently wrong, DynamoDB ONLY supports gateway endpoint not supports interface endpoint. you can search dynamodb in this link https://docs.aws.amazon.com/vpc/latest/privatelink/aws-services-privatelink-support.html The question doesn't refer the bottleneck client meets, so we can not assume client needs on-demand capacity to improve the capacity during high peak time. so compatibility to mongodb makes sense to client.
(B) Is correct based on the Original Author of this question. I didn't know you CANNOT connect to DocumentDB with either Interface or Gateway EP. I also DIDNT know you can choose a different Database (dynamo is purely Key/Value not Document) even though the question doesnt mention this.
D, seems about right. https://docs.aws.amazon.com/documentdb/latest/developerguide/endpoints.html Cluster endpoint A cluster endpoint is an endpoint for an Amazon DocumentDB cluster that connects to the current primary instance for the cluster. Each Amazon DocumentDB cluster has a single cluster endpoint and one primary instance. In case of a failover, the cluster endpoint is remapped to the new primary instance. Adicionally reference use MongoDB how key value , migration not it's this case in question Then D
B) because *The database must be able to scale based on demand* this is a must to have requirement so change all legacy application code to persist and request data from/to dynamodb. question does not say to minimize development overhead sol.. poor developrs ✅✅