How Can Lambda Connect Privately to an RDS Instance with Least Overhead?
Answer
Correct answer: C, D — Run the Lambda function in the RDS instance's subnet and attach the same security group with a self-referencing rule that permits the database port.
A company uses Amazon RDS to store transactional data. The company runs an RDS DB instance in a private subnet. A developer wrote an AWS Lambda function with default settings to insert, update, or delete data in the DB instance. The developer needs to give the Lambda function the ability to connect to the DB instance privately without using the public internet. Which combination of steps will meet this requirement with the LEAST operational overhead? (Choose two.)
Community Insight
The question tests Lambda VPC attachment and self-referencing security-group access to RDS; the trap is assuming a default Lambda can reach a private DB or that RDS can allow 'Lambda invocations' directly.
Connecting an AWS Lambda function to a private Amazon RDS instance requires VPC placement plus a security-group rule that references the Lambda's own group rather than CIDR ranges. This page establishes why options C and D form the private, lowest-overhead solution for the DEA-C01 scenario.
The most common wrong choice is B: learners assume the RDS security group can allow 'Lambda function invocations' directly, but a default Lambda sits outside the customer VPC and has no security group or private IP for RDS to reference.
Community Discussion (21 comments)
keithkifo
👍 1
Selected: CD
C - Lambda runs in an AWS-managed VPC by default. Attaching the Lambda to the same VPC+Subnet as the DB Instance means fully-private network connection. D - Attach same SG to both Lambda and DB Instance, and a self-referencing rule - allows the Lambda and DB to talk to each other.
rr01
👍 1
Selected: BD
I would go with B & D. As C would have operational overhead in my opinion.
altonh
👍 2
Selected: BC
D is wrong. It is a bad security practice for a DB to share SG with the client. C is correct compared to the other opinions (A & E).
proserv
👍 1
Selected: BD
B & D C is wrong While you want the Lambda function to access the RDS instance privately, it does not need to run in the same subnet. As long as both are in the same VPC, the Lambda function can connect.
tgv
👍 2
Selected: CD
I will go with C and D on this one, because in my opinion B is not correctly phrased. The correct way to phrase it would be something like: Update the security group of the RDS instance to allow inbound traffic on the database port (3306) only from the security group associated with the Lambda function.
sdas1
👍 2
While placing the Lambda function in the same subnet as the DB instance would technically allow them to communicate privately within the same network, it introduces additional complexity and operational overhead. Lambda functions typically run in AWS-managed VPCs, and configuring them to run in a specific subnet might require manual intervention and ongoing maintenance.
sdas1
👍 2
Moreover, running a Lambda function within a subnet does not inherently ensure private connectivity to the RDS instance. Additional networking configurations would still be needed to allow the Lambda function to access the RDS instance securely, such as configuring the appropriate security groups and potentially adjusting network ACLs. Hence C can't be the answer
Snape
👍 3
Selected: BD
bbb ddd
lucas_rfsb
👍 2
Selected: CD
I would go with CD, since it's less operational effort, in my opinion
arvehisa
👍 4
Selected: CD
B: need update security group. and there there may be other application need to access db except for lambda function D: it works and reuse security group which has less operational overhead
harrura
👍 2
A is not an option as it exposes the data to public B is not an option as we don't want the lambda to be the only entity accessing the db, there can be many other apps. doing this is not scalable
Alagong
👍 7
Selected: CD
This solution only modifies the inbound rules of the security group of the DB instance, but it does not modify the outbound rules of the security group of the Lambda function. Additionally, this solution does not facilitate a private connection from the Lambda function to the DB instance, hence, the Lambda function would still need to use the public internet to access the DB instance. Therefore, this option does not fulfill the requirements.
certplan
👍 1
B. - While updating the security group of the DB instance to allow only Lambda function invocations on the database port may seem like a viable solution, it's not the most efficient approach. This option overlooks the need for the Lambda function to be able to communicate securely with the DB instance within the same VPC/subnet. - Reference: [Amazon RDS documentation on security groups](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_WorkingWithSecurityGroups.html)
certplan
👍 1
- AWS Lambda supports VPC configurations, allowing you to run Lambda functions within your own VPC. This enables private connectivity between Lambda functions and resources within the VPC, such as RDS DB instances. Reference AWS Lambda documentation on VPC configurations: [AWS Lambda VPC Settings]https://docs.aws.amazon.com/lambda/latest/dg/configuration-vpc.html - AWS security groups provide a flexible and scalable way to control traffic to your instances or resources. By attaching the same security group to both the Lambda function and the RDS DB instance, you can ensure they share the same set of rules for inbound and outbound traffic. - Self-referencing rules within security groups enable instances within the same security group to communicate with each other over specified ports. - Reference AWS documentation on security groups and self-referencing rules: [Security Groups for Your VPC]https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html
certplan
👍 4
So, there coudl be a justified argument for the following: C. Configure the Lambda function to run in the same subnet that the DB instance uses: By running the Lambda function in the same subnet as the RDS DB instance, you enable them to communicate privately within the same network, eliminating the need for public internet access and reducing operational overhead. D. Attach the same security group to the Lambda function and the DB instance. Include a self-referencing rule that allows access through the database port: By attaching the same security group to both the Lambda function and the RDS DB instance, and including a self-referencing rule that allows access through the database port, you ensure secure communication between them within the same VPC without exposing the database to the public internet. This approach minimizes operational overhead by centralizing security management and simplifying access control.
certplan
👍 1
Here's how you would implement this: 1. Attach the same security group to both the Lambda function and the RDS DB instance: Ensure that both resources are associated with the same security group. 2. Create an inbound rule in the security group: Configure the security group to allow inbound traffic on the database port (e.g., 3306 for MySQL) from the security group itself. For example, if the security group ID is sg-1234567890 and the database port is 3306, the inbound rule would look something like this: Type: Custom TCP Rule Protocol: TCP Port Range: 3306 (or the port your database uses) Source: sg-1234567890 (the security group ID itself) This rule allows the Lambda function, which is also part of the same security group, to communicate with the RDS DB instance through the specified port. It effectively creates a loopback or self-referencing rule within the security group, allowing internal communication between resources while maintaining security boundaries.
certplan
👍 2
The phrase "Include a self-referencing rule that allows access through the database port" refers to configuring the security group associated with the resources (in this case, the Lambda function and the RDS DB instance) to allow inbound traffic from the resources themselves on a specific port, typically the port used for database communication. In AWS security groups, a self-referencing rule means allowing traffic from the security group itself. This setup is often used to facilitate communication between resources within the same security group or VPC without needing to specify individual IP addresses.
samadal
👍 1
Thank you. You always help me solve my problems.
GiorgioGss
👍 1
Selected: BC
When you want Lambda to "privately" connect to a resource (RDS in this case) that sits inside a VPC, then you deploy Lambda inside VPC. = C Then you attach a proper IAM role to lambda. Then, to be more secure you open the RDS security group only on the specific port: MySQL/Aurora MySQL: 3306 SQL Server: 1433 PostgreSQL: 5432 Oracle: 1521
BartoszGolebiowski24
👍 1
what does "Include a self-referencing rule that allows access through the database port." mean?
rralucard_
👍 1
Selected: BC
B. Update the security group of the DB instance to allow only Lambda function invocations on the database port: Modifying the security group of the RDS instance to allow incoming connections on the database port (e.g., port 3306 for MySQL, 5432 for PostgreSQL) from the Lambda function is a crucial step. This ensures that the RDS instance can accept connections from the Lambda function. C. Configure the Lambda function to run in the same subnet that the DB instance uses: Placing the Lambda function in the same VPC and subnet as the RDS instance ensures private connectivity. AWS Lambda needs to be configured with a VPC configuration that includes the subnet(s) and security group(s) that allow access to the RDS instance.
Comments & Corrections
No comments yet — spotted an error or have a note? Share it below.
Expert Analysis
Why the Answer Is Correct
C and D are the two required steps: a default Lambda runs in an AWS-managed VPC, not the customer VPC, so it cannot reach the private RDS address without VPC attachment. Configuring Lambda to run in the RDS instance's subnet places an elastic network interface in that private network, giving the function a private path to the database. Attaching the same security group to both resources and adding a self-referencing rule on the database port allows Lambda-to-RDS traffic without hard-coded CIDR ranges or separate group maintenance. Using the same subnet is sufficient here; a different private subnet in the same VPC with routing would also work, but C is the provided option that establishes VPC placement.Why the Other Options Are Wrong
A turns on public access for the DB instance, which directly violates the requirement to avoid the public internet and exposes the database to broader network reachability. B is invalid and insufficient because security groups do not support a rule for 'Lambda function invocations'; a default Lambda has no group to reference, and limiting access to Lambda alone would also break other legitimate DB clients. E is wrong because network ACLs are stateless, CIDR-based filters and do not support self-referencing rules keyed to a security group. Only the combination of VPC attachment in C and the shared self-referencing security group in D closes the private-connectivity loop with minimal overhead.Community Comment Notes
Alagong rejected B because it "does not facilitate a private connection" for a Lambda function outside the VPC. arvehisa favored D because reusing the security group has less operational overhead, and tgv noted that B is "not correctly phrased" for the inbound rule that is actually needed. certplan summarized the C/D rationale as same-network placement plus a self-referencing security group, while altonh raised a minority concern that sharing a DB security group is bad practice. The comments reflect the practical CD consensus, though the verdict here rests on the AWS networking behavior rather than vote count.Official Reference
Exam Strategy
For Lambda-to-private-RDS questions, first ask whether the function is VPC-attached; a default Lambda cannot reach private IP addresses. Then look for a self-referencing security group rule on the database port, which scales without CIDR churn and is the lowest-overhead access pattern.
Frequently Asked Questions
Why is option B not enough to let a default Lambda reach a private RDS instance?
Default Lambda runs outside the VPC, so it has no private IP or security group for RDS to reference. Option B also relies on an invalid Lambda-invocation rule rather than a source security group.
Does option C require Lambda to run in the exact same subnet as the RDS instance?
Option C is sufficient here, but any private subnet in the same VPC with routing to RDS also works. The essential step is attaching Lambda to a VPC subnet that can reach the private RDS endpoint.
Related Analysis
Practice All DEA-C01 Questions
Access 100 questions with complete answers and detailed explanations.
View Full DEA-C01 Practice Test →