We have multiple AWS accounts for various departments. I want to give a Lambda function in one account access to an RDS instance in another.
If the Lambda function is not assigned to a VPC and the RDS is publicly accessible is there a way to limit the access to the RDS to only the Lambda function?
Is there a way to do this if the RDS instance is private and the Lambda function is not assigned to a VPC?
As best practice you should always keep your db in private subnet WITHOUT public ip and access. And then in your case assume all your AWS accounts are in a single organisation, you can share the subnets that the RDS located in account A to account B by https://aws.amazon.com/premiumsupport/knowledge-center/vpc-share-subnet-with-another-account/
Then in account B you config the Lambda to sit in the shared subnets from A, and set security group of Lambda functions, and in RDS instance security group you only allow connection from Lambda's security group, then all set.
May I know why you don't want to put Lambda into VPC? If you have concerns on Lambda cold start performance issue in VPC, notice that AWS already solve that in late 2019: https://aws.amazon.com/blogs/compute/announcing-improved-vpc-networking-for-aws-lambda-functions/
Public Amazon RDS database
If the Lambda function is not assigned to a VPC, then it is connected to the Internet. It can then connect to a publicly-available RDS database. However, there is no way to predict the IP address that will be used by the Lambda function.
Private Amazon RDS database
If the RDS database is only available within a VPC, then the Lambda function needs to be somehow connected to the VPC. Since the Lambda function is in a different AWS Account, you might be able to try:
VPC Peering to make the RDS database in one account accessible to the Lambda function in a different account
Shared VPCs: "In a shared VPC, each participant pays for their application resources including Amazon EC2 instances, Amazon Relational Database Service databases, Amazon Redshift clusters, and AWS Lambda functions."
The Shared VPC looks like it might be a great option for you, since (it seems) the AWS Lambda function from Account A could be placed into the same VPC as an Amazon RDS database from Account B.
See also: VPC sharing: A new approach to multiple accounts and VPC management | Networking & Content Delivery
Let us know if it worked for you!
Related
I have an RDS in one AWS Account - say Acct-1.
The RDS is public (i know it's not a good idea and there are other solutions for that)
I have a lambda in another AWS Account - say Acct-2 which runs in a VPC.
I have setup VPC peering between the 2 accounts, the route table entries are in place as well as the security groups IN/OUT bound policies in place.
In Acct-2 I can verify that I can connect to the RDS instance in Acct-1 using a mysql cient from an EC2 instance. The EC2 instance is in the same subnet as the Lambda and they both have the same security group.
But the Lambda gets a timeout connection. The Lambda has the typical Lambda execution role that Allows logs, and network interfaces.
Thoughts on what could be missing ? Does the RDS need to grant specific access to the Lambda service even if it's running in a VPC ?
Clarification: There is no route to the RDS instance from the internet. Clearly, the ec2 host is able to resolve the Private IP for the RDS instance from the DNS name and connect.
Lambda is unable to resolve the private IP for the RDS instance.
I'm trying to keep the traffic within AWS so as to not pay egress costs.
I have a RDS database and a RDS proxy in one region.
However, I also have a lambda function in a different region that need to connect to the RDS proxy in the first region.
I know that the RDS proxy can't be publicly accessible and need to be within the same VPC as the instance trying to connect to it.
Is there a way to allow a lambda function to connect to a RDS proxy in a different region?
I know that an RDS DB can be publicly accessible, however I was getting sql timeout errors in my lambda functions, which is why I chose to use a RDS proxy.
I know that the RDS proxy can't be publicly accessible and need to be
within the same VPC as the instance trying to connect to it.
I think the part in bold is partially incorrect. The RDS proxy has to be in the same VPC as the RDS database. As far as I can tell, the instance trying to connect doesn't need to be in the same VPC, I think it could also be in a peered VPC.
To answer your question, I would suggest placing the Lambda function in a VPC in the other region, and create a VPC peering connection between the two VPCs.
I read many people struggling connection their Lambda to their DynamoDB, because they live in a VPC. But my question is, why use a VPC at all?
VPC are meant to protect services with a direct connection to the outside world (AKA internet). Things like RDS for instance, which are just sitting ducks waiting to be queried by anyone knowing the URL, and therefore can be victim of DDoS, or zero day exploits that could bypass the credentials, amongst other things.
But, AWS Lambda and DynamoDB aren't such things, they don't have a direct connection to internet. Their access is protected by IAM credentials and are de-facto, secure for such DDoS/0Day exploits.
Hence the question, why use a VPC for Lambda/DynamoDB if they don't benefit from it but on the contrary make things more complicated to configure?
I don't see the benefits of using a VPC for either Lambda nor DynamoDB.
But maybe my understanding is wrong?
If your Lambda function only needs to connect to DynamoDB, then it would be wrong to place the Lambda function in a VPC.
If your Lambda function needs to access an EC2 instance or an RDS instance or some other service running inside the VPC, and also needs to connect to DynamoDB, then the Lambda function would have to run in the VPC and you would need to provide access to DynamoDB via a VPC Endpoint or a NAT Gateway.
I have a database running on an EC2 instance in a public subnet.
I would like to protect the EC2 instance so it can only be accessed from the lambdas.
I do not want to attach the lambda through an ENI as it is not a scalable solution, due to the ENI that must be created to allow the lambda access to the VPC.
I had in mind to use a NACL and to only allow inbound traffic from the ip range of the AWS lambda service, but I do not know how often AWS could update its IP ranges.
Please any suggestions regarding security issues will be welcomed
Whitelisting AWS Lambda IP range won't work since we don't have any control over the IP range when Lambda is outside the VPC.
If you are keeping the EC2 in a public subnet there is hardly any approach available to restrict to requests only for Lambda unless you put the Lambda function inside the VPC.
If you can use AWS RDS for the database it is now possible to restrict access via IAM (AWS recently introduced this).
I have a lambda function which runs every 15 minutes and saves some data in DynamoDB.
Now I want to secure the DynamoDB call made by my lambda so that the request does not go via the Internet, rather through Amazon internal network. There is no EC2 instance involved here though.
I have seen a few recommendations for using PrivateLink which binds the Dynamo to VPC endpoints so that calls made from EC2 instances always go via internal network bypassing Internet.
I was wondering such a configuration is possible for lamda calling DynamoDB since lamda itself does not run in any EC2 instance and is rather serverless?
The first thing I would say is that all of your traffic between Lambda and DynamoDB is signed and encrypted, so that's typically sufficient.
There are use cases, most typically compliance reasons, when this is not sufficient. In that case you can deploy the Lambda function into a VPC of your making and configure the VPC with a private VPC endpoint for DynamoDB. Typically, the VPC would be configured without an internet gateway or NAT so that it has no egress route to the public internet. Be aware that your Lambda function startup latency will be higher than usual, because each Lambda function environment needs to attach an ENI for access to the private endpoint.
See Configuring a Lambda Function to Access Resources in an Amazon VPC.
If you don't need to access resources in a VPC, AWS recommends not to run AWS Lambda functions in a VPC. From AWS Lambda Best Practices:
Don't put your Lambda function in a VPC unless you have to. There is no benefit outside of using this to access resources you cannot expose publicly, like a private Amazon Relational Database instance. Services like Amazon Elasticsearch Service can be secured over IAM with access policies, so exposing the endpoint publicly is safe and wouldn't require you to run your function in the VPC to secure it.
Running Lambda functions in VPC adds additionally complexity, which can negatively effect scalability and performance. Each Lambda function in a VPC needs an Elastic Network Interface (ENI). Provisioning ENI's is slow and the amount of ENI's you can have is limited, so when you scale up you can run into a shortage of ENI's, preventing your Lambda functions to scale up further.
This is one way to do it.
Step 1) Deploy your lambda inside VPC.
Step 2) Create VPC Endpoint to the DynamoDB.
This should help: https://aws.amazon.com/blogs/aws/new-vpc-endpoints-for-dynamodb/