- Our service portfolio
We bring your digital product vision to life, from crafting real-world testable prototypes to delivering comprehensive product solutions.
- Collaboration models
Explore collaboration models customized to your specific needs: Complete nearshoring teams, Local heroes from partners with the nearshoring team, or Mixed tech teams with partners.
- Way of working
Through close collaboration with your business, we create customized solutions aligned with your specific requirements, resulting in sustainable outcomes.
- Our service portfolio
- About Us
- Who we are
We are a full-service nearshoring provider for digital software products, uniquely positioned as a high-quality partner with native-speaking local experts, perfectly aligned with your business needs.
- Our locations
We are ProductDock, a full-service nearshoring provider for digital software products, headquartered in Berlin, with engineering hubs in Lisbon, Novi Sad, Banja Luka, and Doboj.
- Why nearshoring
Elevate your business efficiently with our premium full-service software development services that blend nearshore and local expertise to support you throughout your digital product journey.
- Who we are
- Our work
- Life at ProductDock
We’re all about fostering teamwork, creativity, and empowerment within our team of over 120 incredibly talented experts in modern technologies.
- Open positions
Do you enjoy working on exciting projects and feel rewarded when those efforts are successful? If so, we’d like you to join our team.
- Candidate info guide
How we choose our crew members? We think of you as a member of our crew. We are happy to share our process with you!
- Life at ProductDock
Stay engaged with our most recent updates and releases, ensuring you are always up-to-date with the latest developments in the dynamic world of ProductDock.
Expand your expertise through networking with like-minded individuals and engaging in knowledge-sharing sessions at our upcoming events.
- Get in touch
07. Sep 2023 •3 minutes read
Configuring Lambda to access Amazon RDS in VPC with AWS CDK & Golang
As we know, Lambda functions run in an isolated VPC managed by AWS. Lambdas can access other AWS services, public resources and have access to the internet. But how can they access private resources, like RDS instances, in a different VPC? We want our database to be in a private subnet within a VPC because we can use that network isolation to reduce the exposure to attacks, limit access to specific resources and take care of any compliance standards and regulations. Let’s start by defining our challenge and move to the solution.
We have an Amazon RDS (PostgreSQL) in a private subnet within a Virtual Private Cloud (VPC).The database password is securely stored in AWS SecretsManager for heightened security, ensuring optimal protection. Our goal is to enable a Lambda function to securely connect to Amazon RDS by retrieving the password from AWS SecretsManager.
- The key steps are as follows:
- 1. Place the Lambda function inside our VPC to enable secure communication with internal resources.
- 2. Configure the Lambda function’s role with appropriate permissions for accessing AWS services.
- 3. Create a VPC endpoint to allow the Lambda function to access SecretsManager without internet exposure securely.
- 4. Set up security groups for the Lambda function to access SecretsManager via the VPC endpoint.
- 5. Configure another security group to enable the Lambda function to access the RDS instance securely.
- 6. Apply a security group to the RDS instance that allows inbound connections from authorized sources.
We can easily test the Lambda function by directly invoking it using a Lambda function URL, which can be accessed using a simple curl command.
Our solution will be done with AWS CDK and Golang. The CDK code structure comprises three stacks:
Network stack: This stack includes the configuration for VPC, VPC endpoint, and Lambda security groups.
Storage stack: Here, we set up Amazon RDS PostgreSQL with credentials and security group settings.
Application stack: This stack involves creating a Lambda function with its corresponding security groups and role, along with the Lambda function URL.
For the sake of simplicity, we’ll treat the code here as if it were consolidated into one stack. However, you can find the complete example with the CDK code divided into three stacks on our GitHub repository below.
First, we create a new VPC with two public and two private subnets.
Then we create two security groups, one for the VPC endpoint and one for the Lambda. We need to configure the VPC endpoint security group to allow port 443 inbound traffic from the Lambda security group and the Lambda security group to allow port 443 outbound traffic to the VPC endpoint security group. We do this here because you can pass the security group to other lambdas, if needed.
With VPC and security groups created above, we can create a VPC endpoint for the SecretsManager.
First, we create a security group that will allow connections to the database from the VPC.
Then we create a database instance with credentials. CDK will automatically create an AWS Secrets Manager secret and store it there.
First, we create a Lambda role.
Then we create a security group that will allow Lambda to connect to the database.
With this, we can now create our Lambda function, named pingdb, and also create the URL to trigger it.
You have noticed that we have environment variables for our function which we can use in our code. Speaking of code, here is the Lambda handler code to test the DB connectivity:
After CDK deployment is successful, we can use the function URL, which will be in the Outputs, to trigger the Lambda function.
You can find the code here: https://github.com/ProductDock/lambda-vpc-rds-example
Other useful links and documentation:
Jovica is a techie with more than ten years of experience. His job has evolved throughout the years, leading to his present position as the CTO at ProductDock. He will help you to choose the right technology for your business ideas and focus on the outcomes.