Instructor: So let's talk about RDS proxy,
but first we need to understand why we need RDS proxy.
So if we have a Lambda function and we wants to access our
RDS database, by default,
when you're launching and the function is going to be
launched outside of your VPC, okay.
In a VPC, that's owned by AWS.
Therefore it cannot access resources that are not in your
public subnet.
So if you have a private RDS database or private
ElastiCache or private internal ELB,
then it will not be accessible.
So the idea is that with a default Lambda deployment,
Lambda can talk to your public end points or to dynamoDB.
But if you had a private subnet with a private RDS,
Lambda could not connect to it.
Please note that if you make your RDS database public,
then obviously Lambda functions can connect with,
but this is not as secure as obviously making your RDS
database private in the private subnets.
So, now you can launch your Lambda in a VPC, for this,
you defined the VPC ID, the subnets and the security groups,
and then Lambda will create an elastic network interface in
your subnets to connect directly into your RDS database.
For this, you specify a IN role to create these ENIs.
And so the idea now is that within a private subnet,
Lambda is going to have an ENI to connect to with its own
security group.
Lambda will establish the connectivity directly to this ENI.
And then this ENI will access very clear the RDS database.
You need to set up a few security groups for it to work.
Okay? So we have the connectivity,
but this allows you to deploy a Lambda function in your VPC
and access private resources on RDS databases.
And this will work for a while, but then when you learn
the function will connect to RDS.
You will open and maintain a database connection.
And if you have many instances of your Lambda functions
during this at the same time,
then you can have many connections open to your RDS
database. And this can result in the too many connections
exception coming from your RDS database because too many
connections are open.
Especially if your Lambda functions are not good at cleaning
up their connection.
Therefore you can deploy what's called an RDS proxy.
And with RDS proxy, you no longer need to code what's,
and, and to do the cleaning of your idle connections and RDS
proxy will be managing a connection pool to your RDS
database. So let's take an example.
We have an RDS database, in RVPC, in a private subnet.
You can deploy an RDS proxy within the same private subnet
or in a different sub-net if you wanted to.
So it could be a public subnet as well,
as long as there's connectivity between your subnets,
you're good to go. Okay.
So this example,
I've displayed the RDS proxy in my public subnet. Okay.
And then what's going to happen is that if you have Lambda
functions being set up,
then they can connect directly to the RDS proxy.
So in this example, well,
my Lambda functions are connecting to a RDS proxy in the
public subnets. So they don't need VPC connectivity.
But if you had the RDS proxy to be in a private subnet,
you would need to deploy your
Lambda functions as well in the private subnets.
But the idea is that, as you can see in this diagram,
Lambda functions are establishing five connections to the
RDS proxy,
but the RDS proxy is doing what's called the connection
pooling,
and will maybe only establish one connection to your RDS
instance and therefore you will
allow you to avoid this too many
connections exception.
And in case the Lambda functions
don't clean up their connection to the proxy, that is fine.
The proxy knows how to handle this,
and will close the idle connections after a while.
So during this methodology,
you have support for the IAM authentication.
So you can pass on the IAM details from the proxy to your
RDS database instance. So this is supported,
but also it supports database authentication with
username and password,
and the more connections are made to your RDS proxy,
the more it will scale,
so there's auto scaling of the RDS proxy layer.
And as I said, the Lambda functions must have connectivity
to the proxy.
So if you have a public subnets and a public proxy,
then you can have a public Lambda function,
or at least a Lambda function deployed normally.
And then if you have a private RDS proxy deployed in a
private subnets,
then you need to obviously deploy your Lambda function in
a VPC. But thanks to the RDS proxy,
you are going to avoid that too many connections error.
So let's have a look at how we can create a proxy.
So I'm going to show you the options to create a proxy.
So here are the options.
And I will go and create the proxy itself,
because it will cost you money,
but at least I can share the production, the options.
So you name it, DemoProxy.
You have an engine compatibility.
So is it MySQL or Postgres?
And you require TLS to be enabled for encryption in flights.
Then there is the idle client connection timeouts.
So this shows you how the proxy itself will handle the
cleanup of connections.
And so you can set it anywhere between a few minutes to
eight hours. Okay?
And this one is set up to 30 minutes.
That means that if your application has not been using a
connection for more than 30 minutes,
then clean up the connection.
So the proxy is smart enough to do the cleanup itself and
not overload, obviously, the end database.
Then you could choose your database and you specify a
connection pool, maximum connection.
So what's the percentage of maximum connections are allowed
from the proxy to your main database.
So if your database also has some direct connections than
80% would be a good number,
but if you only connect to your database for your proxy,
then you should be able to enable 100%. Okay?
Next, connectivity.
So your RDS proxy needs to be able to connect to your
database. And for this,
you need to create a secret in
secrets manager for the database.
So you need to go ahead and create a new secret and that
does it expensive. So the cost to about 40 cents per secret,
per month, there's a 30 day trial available,
but this will cost you some money if you do it.
And the secrets would be a credentials for an RDS database
in which you specify the username as well as the password,
which is right here.
Okay? Just to show you,
you have the password and then you would say,
this is relevant for this database.
So it's not something that I'm going to do,
but at least it would show you how you will create the
secret.
And then that secret could be used right here by your RDS
proxy.
Then you need an IAM role, okay?
To allow the proxy
to access the secret from secrets managers,
so you need to create the IAM role.
And then how do you want your users to connect to the proxy?
So they can use IAM authentication or they can use
database username and password, just like
what comes with MySQL and RDS.
So you can enable IAM authentication or disable it.
Then the subnet, so where do you want
to deploy your database proxy?
So this is where you can make it indifference privates or
public subnets than your original database.
And you can set up a security group that allows your proxy
to connect to your RDS database.
And finally, you can enable logging
of all the queries passed into your database,
but this is disabled after 24 hours
because it will slow down your proxy. Okay?
So this is it. You have all the options right here.
And then when the proxy is created,
it gives you a connection URL that you can leverage within
your applications or your Lambda functions
to leverage a proxy right away.
So that's it for this lecture. I hope you liked it.
And I will see you in the next lecture.