RDS Proxy for SQL Server with AWS Lambda and .NET 6

When building serverless application it's easy to exhaust the resources of your SQL Server databases. As a default, AWS Lambda can run 1000 concurrent executions in your account. That's 1000 separate connections to your SQL Server database. Using RDS for SQL Server also requires the management of connection strings and secrets within your applications.

RDS Proxy for SQL server is a highly available, fully managed proxy that eases these two problems. It allows applications to pool and share connections to the database, improving efficiency and scalability. It also enables IAM based authentication, allowing your application to authenticate with IAM instead of database credentials.

In this video we dive into how you can build serverless applications on AWS Lambda with .NET 6 whilst also leveraging RDS Proxy for SQL Server.

00:00 - Introduction to RDS Proxy
01:05 - Introduction to RDS Proxy IAM authentication
01:45 - Deploying a proxy
03:45 - Configure a proxy in the AWS Console
05:35 - Using RDS Proxy endpoints
07:10 - Loading connection strings from Secrets Manager
09:40 - Adding IAM authentication
10:45 - Entity Framework Interceptors
11:45 - Generate RDS Auth Tokens
13:50 - Configure SAM template
15:05 - Add IAM permissions in the AWS Console
16:10 - Configure IAM permissions in AWS SAM template
17:35 - IMPORTANT! ARN Changes
18:40 - Recap

Links

[sumarianprince]

Amazing, I discovered this just today.

[genetorres]

Hey James, thanks for the video!
We have run into some issues with our code doing worse after testing the proxy.

The developers I help says their zombiechecks are failing.

When I connect to the proxy and run a stress tool called ostress witout the proxy, my 10 calls run fine
But when I use the proxy:

I get these errors

06/12/23 13:53:13.451 [0x00002278] [spid 329] SQLState: 08S01, Native Error: 10054, Severity: 0, State: 10, Line: 0
[Microsoft][SQL Server Native Client 11.0]TCP Provider: An existing connection was forcibly closed by the remote host.
06/12/23 13:53:13.452 [0x00002278] [spid 329] SQLState: 08S01, Native Error: 10054, Severity: 0, State: 0, Line: 0
[Microsoft][SQL Server Native Client 11.0]Communication link failure

[aravindkumarn]

I created rdx proxy for SQL server. Like you said i just replaced the connect string with my rdx endpoint. But application failed to connect

[milanpatel]

Hi James, could you please help me with RDS proxy for MySQL with AWS lambda and .net 6? I tried with this example but it doesn't work with MySQL. Please help me asap. Thanks in advance.

[seankirk]

Awesome video [as always]! Keep them coming!

Quick down in the weeds question - I've been following this pattern of storing DB credentials within AWS Secrets Manager for some WebAPI projects running in AWS Lambda and retrieving them once + caching them at app start up. Your extension method that's called as part of the initial startup of the app calls .Result on the response from the asynchronous call GetSecretValueAsync.

It seems like making this asynchronous call synchronous is the only way for this to work - as it seems you can't have asynchronous calls following the async/await pattern as part of the initial app start up while building the DI container (or more generally in class constructors), is that right? What you've done here is the approach that I’ve been following as well [which makes me feel good!]

It seems like in general all the AWS SDK methods are fully async and you should go all the way in with async/await – but this appears to be the one place where you would need to force an async call to be synchronous. Its tpyically cited that making an async call synchronous can have the risk of an application deadlock but this risk seems low/non-existent since this only happens in an isolated area of the app, once at start up. Is that a fair assumption in your opinion?

Lastly, one follow up question, is there any tangible difference from your perspective between doing:



and



I feel like I've done both but am unsure which is preferrable in this instance.

Thanks again and keep up the great work!