Isn’t getting a Direct Connect cheaper than migrating to Multi-AZ Amazon RDS for MySQL?? Answer A seems to be the cheapest option
An organization has a write-intensive mobile application that uses Amazon API Gateway, AWS Lambda, and Amazon DynamoDB. The application has scaled well; however, costs have increased exponentially because of higher than anticipated Lambda costs. The application’s use is unpredictable, but there has been a steady 20% increase in utilization every month.
While monitoring the current Lambda functions the Solutions Architect notices that the execution-time averages 4.5 minutes. Most of the wait time is the result of a high-latency network call to a 3-TB MySQL database server that is on-premises. A VPN is used to connect to the VPC, so the Lambda functions have been configured with a five-minute timeout.
How can the Solutions Architect reduce the cost of the current architecture?
A.
• Replace the VPN with AWS Direct Connect to reduce the network latency to the on-premises MySQL database.
• Enable local caching in the mobile application to reduce the Lambda function invocation calls.
• Monitor the Lambda function performance; gradually adjust the timeout and memory properties to lower values while maintaining an acceptable execution time.
• Offload the frequently accessed records from DynamoDB to amazon ElastiCache.
B.
• Replace the VPN with AWS Direct Connect to reduce the network latency to the on-premises MySQL database.
• Cache the API Gateway results to Amazon CloudFront.
• Use Amazon EC2 Reserved instances instead of Lambda
• Enable Auto Scaling on EC2, and use Spot Instances during peak times.
• Enable DynamoDB Auto Scaling to manage target utilization
C.
• Migrate the MySQL database server into a Multi-AZ Amazon RDS for MySQL
• Enable caching of the Amazon API Gateway results in Amazon CloudFront to reduce the number of Lambda function invocations
• Monitor the Lambda function performance; gradually adjust the timeout and memory properties to lower vale while maintaining an acceptable execution time.
• Enable DynamoDB Accelerator for frequently accessed records, and enable the DynamoDB Auto Scaling feature.
D.
• Migrate the MySQL database server into a Multi-AZ Amazon RDS for MySQL
• Enable API caching on API Gateway to reduce the number of Lambda function invocations.
• Enable API caching on API Gateway to reduce the number of Lambda function invocations.
• Continue to monitor the AWS Lambda function performance; gradually adjust the timeout and memory properties to lower values while maintaining an acceptable execution time.
• Enable Auto Scaling in DynamoDB
4 Answers
Use of DX can resolve the network latency issue when connecting to your on-premise DB from Lambda, but DX is more expensive than migrating your on-premise database to AWS. For the DX, there is a hourly charge on the usage of your DX port (This charge is applied regardless of usage of DX), and you also be charge for the data transfer between AWS and your on premise network. Since your application is write intensive, C is not good option. D seems to be correct to me.
"wait time is the result of a high-latency network call to a 3-TB MySQL database server that is on-premises" – this could be a slow network issue/VPN OR the DB itself being slow. (or both) – not enough information to deduce.
One way or other, using RDS in cloud or DynamoDB can definitely better the situation, including caching (caching does not help all situations – not enough information here), etc.
"costs have increased exponentially because of higher than anticipated Lambda costs" – this I think is key – how to reduce number of Lambda calls, Lambda is priced by number of calls not duration (not correct) thereof. These calls can be reduced by API caching.
Note Correction: Lambda Pricing is based on number of calls, duration of call and data transfer (data transferred “in” to and “out” )
I would opt for D
Maybe im wrong but doing some testing….An AWS RDS with 3TB of allocated Space (General SSD) it costs like 414$us on NC, just for the space, using a t2-micro instance with multi AZ will cost you extra 32$us, a Direct Connect 1Gbps Connection will cost you 0.3$us/hour = 216$us monthly, and we known that the cost of lambda is directly affected by the duration of calls too as it says on the lambda pricing page, https://aws.amazon.com/lambda/pricing/ , i think that the question is focusing on the waiting time caused by the latency of the VPN, i will say the most efficent solution is D because this will give you a latency >1ms to the Database, but… there is a second point here, the question says How can the Solutions Architect reduce the cost of the current architecture, without the amount of calls i would say to focus on reduce cost on the architecture, and that will be saving costs on the New architecture, and for that i will go for A, the only thing im not sure is the "Enable local caching in the mobile application to reduce the Lambda function invocation calls.", im not sure that local cache can help you with that, it anyone can confirm that with documentation will be great to discard or agree with A.
I think the are other costs as well. There’s the price of getting the DX from the isp. Also, there’s the data transfer over the DX. Sam T is partially correct. Lambda is priced via a combination of invocations and duration of the call. His analysis of how to decrease the cost is spot on. If you move the database to RDS, that’s the lowest latency you can have. Also, caching the calls using API caching should help with the number of invocations. The other problem with answer A is the caching location. Caching at the mobile application won’t really help. Every mobile application still needs to get data.
The calculation from Requium is wrong, on-premise device holding the database is not free, compare on-premise with cloud, there is no way on-premise is cheaper, then adding direct connect fee, the cost is higher if we will use adding aws direct connect. so migration is cheaper comparing using a link to on-premise.
Thank you for the detailed breakdown of the question and explanation of your thought process.