Uma empresa executa um microsserviço como uma função AWS Lambda. O microsserviço grava em um banco de dados SQL on-premises que suporta apenas um número limitado de conexões simultâneas. Quando o volume de invocações do Lambda aumenta, o banco de dados fica sobrecarregado e falha, causando tempo de inatividade. A empresa tem um link AWS Direct Connect entre a VPC e o datacenter on-premises. A empresa quer proteger o banco de dados de ser sobrecarregado. Qual solução satisfaz esses requisitos?

A solução correta utiliza o Amazon SQS para desacoplar a função Lambda do banco de dados on-premises, agindo como um buffer. Isso permite que o microsserviço Lambda principal enfileire as solicitações rapidamente, mesmo sob alto volume. A função Lambda que lê da fila SQS e grava no banco de dados on-premises pode ter sua concorrência reservada limitada. Ao definir essa concorrência abaixo do número máximo de conexões simultâneas do banco de dados, garante-se que o banco de dados não seja sobrecarregado, protegendo-o de falhas. As outras opções são incorretas porque: Migrar para o Amazon Aurora Serverless com AWS DataSync é uma solução válida para modernizar o banco de dados, mas não atende ao requisito de proteger o banco de dados on-premises existente. O Amazon RDS Proxy é para bancos de dados Amazon RDS, não para bancos de dados on-premises, e não resolveria o problema de sobrecarga do banco de dados on-premises. Publicar no Amazon SNS e invocar o Lambda diretamente ainda expõe o banco de dados on-premises a um pico de invocações. A concorrência provisionada, embora ajude a manter a função "quente", não limita a taxa de gravação no banco de dados on-premises da mesma forma que a concorrência reservada combinada com uma fila SQS para desacoplamento.