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.
Related
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!
There are couple of questions around this, but none seem to solve my specific problem.
So i have a publicly accessible RDS instance in a VPC with two Security Groups : one the default SG for VPC & other to allow incoming connections from our developer machines. I am able to successfully connect to this RDS via my developer machines(personal laptops/PCs) as a result of the 2nd Security group.
Now, when i try to connect to this RDS via a Lambda running in same VPC, it fails with this error : "java.net.UnknownHostException: ****.rds.amazonaws.com: Name or service not known "
My lambda is getting launched in the same VPC as RDS and i have chosen all the RDS VPC subnets for the lambda. It also is tied to the default VPC security group.
Below is my understanding(obviously not right as connection is not working), what am i missing here?
The Default VPC SG(security group) associated to the lambda has outgoing rules set as 0.0.0.0/0 , hence it should allow lambda to access the whole world; so at least the RDS in VPC should be accessible.
The same default VPC SG should allow the RDS to accept incoming connections from any ip in the SG subnets(inbound rule mentions SG/default) ; hence lambda should be able to access it.
The error message is indicating that it cannot resolve the DNS Name of the RDS database (Name or service not known).
I suspect that this is due to the fact that the RDS instance has been configured as publicly accessible, which gives it a public DNS Name and IP address.
An AWS Lambda function connected to a VPC will send all network traffic via the VPC. It does not have access to the Internet unless there is a NAT in the VPC and the Lambda function is connected to a Private Subnet. Thus, the connection attempts from the Lambda function are possibly attempting to resolve a Public DNS Name, but is failing to do so.
This could likely be resolved by changing the RDS instance to be Publicly Available = No. This not only makes it safer, but it means that the DNS Name will resolve to a Private IP address, which should work correctly with a Lambda function connected to the VPC.
Alternatively, you could configure the Lambda function to not be connected to the VPC. This gives it Internet access, so it will connect to the RDS database just like any other computer on the Internet.
So the problem was that in my developer machine, I was using the db instance endpoint , but in lambda i was using the cluster endpoint. They look similar, hence i was not able to catch it earlier. On fixing the lambda to use the instance endpoint, both lambda & developer machines can successfully connect to the RDS.
However, I am now curious why the cluster url is not accessible, but i will create another question for that.
I am having an Amazon RDS Postgres instance which resides in the default VPC.
To connect to it, i am using different EC2 instances (Java Spring Boot and NodeJs) running in ElasticBeanstalk. These instances also reside in the default VPC.
Do these EC2 instances connect to/query the RDS instance through the internet or the calls do not leave the AWS Network?
If they leave the AWS network and the calls go through the internet, is creating a VPC endpoint the right solution? Or my whole understanding is incorrect.
Thanks a lot for your help.
Do these EC2 instances connect to/query the RDS instance through the internet or the calls do not leave the AWS Network?
The DNS of the RDS endpoint will resolve to private IP address when used from within VPC. So communication is private, even if you use public subnets or set your RDS instance as publicly available. However, for connection from outside of AWS, the RDS endpoint will resolve to public IP address if the db instance is publicly available.
If they leave the AWS network and the calls go through the internet, is creating a VPC endpoint the right solution?
There is no VPC endpoint for RDS client connections, only for management actions (creating db-instance, termination, etc). In contrast, Aurora Serverless has Data API with corresponding VPC endpoint.
To secure your DB-Instances communications you need to be sure at least about the following:
locate your RD in private subnet (route table does not contain default outbound route to internet gateway).
RDS security group just accept traffic inbound only from instances security group/groups on TCP port for PostgreSQL which is usually 5432.
In this case Traffice to RDS will go localy in your vpc, for vpc endpoints it can be used to access RDS API operations privatly which is not your case (you just need to connect your app to DB using connection string)
I have a glue job which is hitting an API hosted over an EC2 instance.
The problem is EC2 instance resides within a VPC blocking all public access.
I tried creating an endpoint interface in my VPC but still can't access the REST API.
The host is always unreachable but when I try to access the API from VPC it is working fine.
The security group associated with the EC2 instance is used while creating the VPC Endpoint.
Any help is appreciated
If you go to AWS Glue console, under connections, create a connection. What is meant by a dummy connection, is just be a non-existent database or resource for example: jdbc:mysql://some-fake-endpoint-here:3306/mydb. After this you choose the correct VPC, subnet and security group. Which means a test connection will not work in this context but what it brings is a way to introduce your VPC, Subnet and Security group information to the job. Testing such a connection can be done using a python-shell job or launch an ec2 instance in the same vpc or same subnet and run something like nc -vz endport port.
This connection metadata information will facilitate the launching of elastic network interfaces in your account that allow glue DPUs to communicate with your resource at runtime. More on how connections in glue is discussed here.
I am having issues connecting Elasticache from a Lambda function
I have done the following:
Created a new security group
Assign security group to Lambda and assigned two private subnets of same VPC
Created an Elasticache redis cluster and assigned the above security group
Created a NAT gateway address, assigned and ElasticIP (for the above VPC)
Internet works and I verified this by opening stackoverflow.com URL. However Elasticache auto discovery times out. Is there any additional configuration that needs to be done?
Update
I added inbound rule for Security Group to port 6379 and now still times out.
You will need to attach an IAM policy to the Lambda execution role that grants it the appropriate access permission to ElastiCache. If you are restricting access you will also need to check the VPC setting of the Lambda function and make sure it has the ability to access the subnet the EC cluster is located.
Take a look at the following article for specifics:
https://docs.aws.amazon.com/lambda/latest/dg/services-elasticache-tutorial.html