Overview
Serverless computing with AWS Lambda offers incredible agility by abstracting away infrastructure management. However, this abstraction doesn’t eliminate the need for strong security and governance. While AWS secures the underlying cloud, you are responsible for securing your function’s configuration, permissions, and network environment. A critical aspect of this responsibility is controlling how your Lambda functions connect to your network resources and the internet.
By default, Lambda functions run in a secure AWS-managed network with internet access but no direct path to your private resources within a Virtual Private Cloud (VPC). To access databases like Amazon RDS or internal services, a function must be connected to your VPC. This is where a common and high-risk misconfiguration occurs: placing the function in a public subnet.
The correct and secure architectural pattern is to place VPC-connected Lambda functions exclusively in private subnets. A private subnet is one that does not have a direct route to an Internet Gateway, effectively isolating its resources from the public internet. This configuration is a foundational practice for building a secure, compliant, and cost-efficient serverless architecture on AWS.
Why It Matters for FinOps
From a FinOps perspective, improper network configuration for Lambda functions introduces significant financial risk and operational waste. Placing functions in public subnets violates the principle of least privilege at the network level, expanding the attack surface and increasing the potential cost of a security breach. Non-compliance with standards like PCI-DSS or HIPAA, which mandate network segmentation, can lead to severe fines and loss of customer trust.
Furthermore, this misconfiguration often signals a lack of architectural governance, which can lead to unpredictable data transfer costs. Traffic from functions in private subnets can be routed through a central point like a NAT Gateway, allowing for monitoring and control. Without this control, data exfiltration or inefficient API calls can go unnoticed, driving up costs.
Ultimately, enforcing private subnet placement is a core FinOps tenet. It aligns security posture with financial governance, reduces the financial blast radius of a potential breach, and ensures that cloud spend is directed toward efficient, secure, and resilient application delivery.
What Counts as a Misconfiguration
In this article, a misconfiguration is defined as any AWS Lambda function that is configured to run within a customer VPC and is attached to one or more public subnets.
A subnet’s status is determined by its routing rules. The key signal of a misconfiguration is when the route table associated with the Lambda function’s subnet contains a route that directs default traffic (0.0.0.0/0) to an Internet Gateway (IGW). This simple routing rule effectively exposes that subnet to the public internet, violating the principle of network isolation that a VPC is meant to provide for sensitive workloads. A compliant function is attached only to subnets whose default route points to a NAT Gateway or has no default route at all.
Common Scenarios
Scenario 1: Accessing Private Databases
The most frequent reason for connecting a Lambda function to a VPC is to communicate with a database like Amazon RDS or Aurora. These databases should always be in private subnets, inaccessible from the internet. To maintain this security boundary, the Lambda function that queries the database must also reside in a private subnet within the same VPC.
Scenario 2: Internal Microservice Communication
In a microservices architecture, a Lambda function may need to call another internal service hosted on Amazon ECS or behind an internal Application Load Balancer (ALB). To keep this inter-service communication secure and efficient, it must occur over private network paths. Placing the calling Lambda function in a private subnet ensures it can reach the internal service’s private IP address without ever exposing the traffic to the public internet.
Scenario 3: Enforcing Egress Traffic Control
A Lambda function may need to call a third-party API, but for compliance or security reasons, your organization must whitelist all outbound destinations. By placing the function in a private subnet, all its outbound internet traffic is forced through a single point, like a NAT Gateway. This enables the use of an AWS Network Firewall or other inspection tools at the egress point to filter and log all outbound traffic, a critical control that is lost with direct internet access.
Risks and Trade-offs
Implementing this security guardrail involves managing a few architectural trade-offs. The primary concern is ensuring functions that need internet access can still get it. A function in a private subnet has no direct internet path; it requires a route to a NAT Gateway, which resides in a public subnet, to communicate with external services. Misconfiguring this routing is a common cause of service disruption during remediation.
Cost is another consideration. NAT Gateways incur both hourly and data processing charges, which can become a significant part of your unit economics for high-volume functions. This trade-off between security and cost can be managed by using VPC Endpoints for AWS services like S3 and DynamoDB, which allows traffic to bypass the NAT Gateway, reducing costs and improving security. Lastly, large-scale Lambda deployments can consume a significant number of IP addresses in a subnet, so proper IP address management (IPAM) is crucial to prevent address exhaustion.
Recommended Guardrails
To enforce this best practice at scale, organizations should implement a set of clear governance guardrails. Start with a cloud security policy that explicitly mandates all Lambda functions processing sensitive data be placed in private VPC subnets. This policy should be backed by automated checks using services like AWS Config to continuously monitor for non-compliant functions and trigger alerts.
Standardize your infrastructure provisioning using templates (e.g., CloudFormation, Terraform) that configure Lambda functions in private subnets by default. Implement robust tagging standards to assign clear ownership to every function, simplifying remediation and chargeback/showback processes. For cost control, establish budget alerts specifically for NAT Gateway data transfer costs to detect anomalies that could indicate inefficient code or data exfiltration.
Provider Notes
AWS
In AWS, this security principle is implemented using core networking components. A Virtual Private Cloud (VPC) acts as your logically isolated network. Within a VPC, you create subnets; a private subnet is defined by a route table that does not have a route to an Internet Gateway (IGW).
To grant internet access to a Lambda function in a private subnet, you must route its outbound traffic through a NAT Gateway, which itself resides in a public subnet. Access control is further refined using Security Groups, which act as stateful firewalls for your Lambda function’s network interface. For optimized, secure access to other AWS services, you can use VPC Endpoints to keep traffic within the AWS network, often reducing data transfer costs.
Binadox Operational Playbook
Binadox Insight: Viewing network isolation as a FinOps principle, not just a security rule, is key. Properly configured subnets reduce the financial blast radius of a security breach and give you direct control over costly data transfer patterns, turning a technical requirement into a powerful lever for financial governance.
Binadox Checklist:
- Audit all existing Lambda functions to identify those connected to public subnets.
- Verify that your target VPCs have properly configured private subnets and highly available NAT Gateways.
- Develop a migration plan to update non-compliant function configurations to use only private subnets.
- Create and apply least-privilege Security Groups that only allow necessary outbound traffic from your functions.
- Implement automated monitoring and alerting to detect new misconfigurations in real time.
- Use VPC Endpoints for high-volume AWS services like S3 or DynamoDB to optimize costs and security.
Binadox KPIs to Track:
- Percentage of VPC-attached Lambda functions in private subnets.
- Monthly data processing costs associated with NAT Gateways.
- Number of security alerts generated for Lambda network misconfigurations.
- Average time-to-remediate for non-compliant function deployments.
Binadox Common Pitfalls:
- Moving a function to a private subnet but forgetting to configure a NAT Gateway route, breaking its internet access.
- Attaching an overly permissive "Allow All Outbound" Security Group, defeating the purpose of network controls.
- Under-provisioning the IP address space (CIDR block) for Lambda subnets, leading to scaling failures from IP exhaustion.
- Failing to use multiple Availability Zones for subnets and NAT Gateways, creating a single point of failure.
Conclusion
Adopting a "private by default" policy for AWS Lambda functions within a VPC is a non-negotiable best practice for any organization serious about security, compliance, and cost management. It is a foundational control that reduces attack surface, helps meet regulatory requirements, and provides the visibility needed for effective FinOps governance.
Begin by auditing your current serverless footprint to identify and prioritize misconfigured functions for remediation. By embedding this principle into your deployment pipelines and governance frameworks, you can ensure your serverless architecture is not only agile and scalable but also secure and financially sound.
7-day free trial