Exam AWS Certified Solutions Architect - Professional SAP-C02 topic 1 question 207 discussion

"does not want to rewrite the application. " leaves the possible answer between A and C, cause B and D will force the application team to rewrite the data access part of the application. C is using EKS, which makes AutoScalingGroup is not required. ASG scales instances. ASG doesn't scale PODs in EKS. Babelfish is the key point in this question. "Babelfish for Aurora PostgreSQL is a new capability for Amazon Aurora PostgreSQL-Compatible Edition that enables Aurora to understand commands from applications written for Microsoft SQL Server."

There is no good solution here. A is just forcing that company to use AWS services as "MOST cost-effectively" alternative. Practically Bablefish has bad reviews, companies prefer to migrate SQL-Server as-is.

The key is 'minimise licensing cost' so, option A is the best because it can radically cut down the SQL Server licensing cost by putting it to Aurora PostgreSQL. Option C has equivalent licensing cost since it is SQL RDS.

Option C is the most cost-effective solution as it leverages containerization with Amazon EKS, Auto Scaling groups with Network Load Balancers, and Amazon RDS for SQL Server. This approach allows for efficient scaling, resource utilization, and minimizes licensing costs without requiring significant application changes. Containerizing the web and application tiers enables portability and scalability. Amazon EKS provides a fully managed Kubernetes service, reducing operational overhead. Auto Scaling groups and Network Load Balancers enable automatic scaling based on demand. Amazon RDS for SQL Server offers a fully managed database service with various licensing models, including BYOL, to optimize costs as the application scales. The other options have drawbacks, such as requiring replatforming the database (Option A), significant application changes (Option B), or a complete rewrite (Option D), which goes against the requirements.

All answers are wrong. A is not using managed services where possible (EKS would be better than EC2 and can run windows) and on C you can't have Auto Scaling group for EKS. Realistically C is the better option if scaled with Karpenter, etc.

Key here is AWS Managed = EKS A. Says both Web tier and Application tier is behind ALB, which is not secure. A good design should have web tier behind ALB, and application tier behind NLB

Option A: Babelfish for Aurora PostgreSQL is a capability for Amazon Aurora PostgreSQL-Compatible Edition developed using the PostgreSQL extension framework that enables Aurora to understand commands from applications written for Microsoft SQL Server. Babelfish for Aurora PostgreSQL understands T-SQL, Microsoft SQL Server’s SQL dialect, and supports https://aws.amazon.com/blogs/database/run-sql-server-reporting-services-reports-against-babelfish-for-aurora-postgresql/

Option A

As much as I would like to choose A but the question request for lift and shift approach rather than a replatform

I vote C. Babelfish - another layer to keep an eye on. Is it really going to translate all SQL app calls perfectly, or will they need tuning?

why not C

A : the best of the worst

Correct A.

A. The other options sound fishy.

A by elimination

a-a-a-a-a-a-a after much consideration it's the babelfish to the rescue - zaphod beeblebrox ftw

Agree with A the NLB with EKS might be a interesting choice if chose too fast. The correct option should be A, using an ALB and rehost to from M SQL Server to Aurora using Belfish. https://aws.amazon.com/rds/aurora/babelfish/ "With Babelfish, Aurora PostgreSQL now understands T-SQL, Microsoft SQL Server's proprietary SQL dialect, and supports the same communications protocol, so your apps that were originally written for SQL Server can now work with Aurora with fewer code changes"