Securing AWS Private Lambda with Zscaler Zero Trust Cloud

Modern cloud architectures increasingly rely on AWS Lambda for event-driven processing, data ingestion, and microservice integration. While Lambda functions often run within private Virtual Private Clouds (VPCs) to keep data isolated, many serverless workloads still require outbound internet access to interact with third-party APIs, SaaS applications, or external data feeds.

Without deep visibility into this outbound traffic, security teams face a critical blind spot. Attackers can leverage encrypted channels (HTTPS) to exfiltrate sensitive data or communicate with command-and-control (C2) servers. To combat these risks, organizations turn to Zscaler Zero Trust Cloud and Zscaler Internet Access (ZIA) for inline SSL/TLS Inspection.

To seamlessly extend zero trust security to public cloud environments, Zscaler provides the Zscaler Zero Trust Gateway (ZTGW). ZTGW securely brokers outbound traffic originating from cloud workloads and private subnets, funneling it safely over encrypted DTLS tunnels into ZIA for policy enforcement and threat prevention.

However, introducing SSL inspection into serverless environments presents a unique operational challenge: How do you distribute custom Root CA certificates to short-lived, ephemeral Lambda execution containers without breaking application code or requiring manual maintenance?

In this blog, we’ll explore why SSL inspection is essential for serverless workloads, how to fully automate custom certificate distribution using AWS CloudFormation and S3, how to configure granular SSL inspection policies in ZIA, and how to verify everything in action.

The Challenge: SSL Inspection vs. Ephemeral Execution

When ZIA inspects outbound HTTPS traffic, it acts as a man-in-the-middle proxy. It terminates the TLS session from the client, inspects the payload for threats or Data Loss Prevention (DLP) violations, and establishes a new TLS session to the destination server. To accomplish this, ZIA re-signs the destination’s SSL certificate using a custom Zscaler Root or Intermediate CA.

If the client runtime does not explicitly trust the Zscaler Root CA, the TLS handshake fails immediately with an error like:

In traditional virtual machines (like EC2), administrators deploy custom certificates via configuration management tools (Ansible, Chef) or golden AMI images. But AWS Lambda containers are ephemeral and managed entirely by AWS. Standard Linux system trust stores cannot be modified permanently at the OS image level.

The Solution: Cold-Start Bootstrap & Auto-Discovery Pattern

To solve this challenge, we can implement an Automated Cold-Start Bootstrap Pattern.

By storing our Zscaler Root CA certificate in an isolated Amazon S3 bucket within the VPC, the Lambda function can fetch the certificate during container cold boot, dynamically merge it with native Amazon Linux root CAs into /tmp/custom-ca-bundle.pem, and bind it to the Python SSL context.

Architecture Overview

Automating Certificate Distribution Step-by-Step

Let's look at how the execution environment handles the certificate lifecycle automatically in the following steps.

1. Zero-Trust Storage in Amazon S3

The certificate resides in a dedicated S3 bucket protected with:

• Gateway VPC Endpoint: All traffic between Lambda and S3 remains on the AWS internal backbone without traversing NAT Gateways or the public internet.
• Restricted Bucket Policy: Blocks all access unless the request originates from the specific VPC Endpoint or authorized IAM roles in your AWS account.

2. Smart Certificate Auto-Discovery & Normalization

During cold start, the Lambda handler searches the S3 bucket for any certificate ending in .crt, .pem, or .cer (such as ZscalerRootCertificate-2048-SHA256-Feb2025.crt).

Certificates uploaded by security teams often vary in encoding (ASCII PEM vs. Binary DER) or contain UTF-8 Byte Order Marks (BOM headers) from Windows text editors. The bootstrap code automatically cleans and normalizes these files:

3. Merging with Native System CAs

To ensure the Lambda function trusts both public internet sites and Zscaler re-signed sessions, the handler merges native Amazon Linux system CAs (/etc/pki/tls/cert.pem) with the extracted Zscaler Root CA into a single /tmp/custom-ca-bundle.pem file.

4. Binding the Trust Store to Python Runtime

Finally, during outbound calls, the Lambda handler configures ssl.create_default_context pointing directly to /tmp/custom-ca-bundle.pem:

Crafting SSL Inspection Policies in Zscaler Internet Access (ZIA)

With the Lambda trust store in place, we can configure ZIA to inspect outbound HTTPS traffic. ZIA offers two powerful methods for scoping SSL inspection rules to AWS serverless workloads.

Option 1: Scoping Policy via Sub-Locations (IP / Subnet Based)

If your Lambda functions are deployed into dedicated private subnets, you can scope policies based on subnet CIDRs.

1. Create a Sub-Location in ZIA:

• In the ZIA Admin Portal, navigate to Administration > Location Management.
• Locate your AWS location and click Add Sub-Location.
• Define the IP range corresponding to your private Lambda subnet (e.g., 10.0.2.0/24).

2. Build the SSL Inspection Rule:

• Navigate to Policy > SSL Inspection > Add SSL Inspection Rule.
• Under Criteria, select your newly created Sub-Location.
• Under Action, select Inspect and assign your Zscaler Intermediate CA.

Option 2: Scoping Policy via Workload Groups (Leveraging AWS Native Metadata)

For modern cloud environments where IP addresses are dynamic, ZIA supports Workload Groups. This approach maps AWS-native attributes—such as Security Groups, Account IDs, or VPC IDs—directly into ZIA policy context without maintaining static IP ranges.

Prerequisite: Ensure AWS Workload Discovery is enabled between your AWS Account and Zscaler. For setup details, see the official Zscaler Documentation on Adding an AWS Account.

1. Define a Workload Group in ZIA:

• In ZIA, go to Administration > Workload Groups > Add Workload Group.
• Name the group (e.g., AWS-Lambda-Workloads).
• Add criteria matching your AWS infrastructure:
• VPC ID: vpc-xxxxxxx
• Security Group ID: sg-0123456789abcdef0

2. Apply Workload Group to SSL Inspection:

• Under Policy > SSL Inspection, create a new rule.
• Under Criteria > Workload Groups, select AWS-Lambda-Workloads.
• Set Action to Inspect.

Benefits of Workload Group Scoping:

• Zero IP Management: Eliminates hardcoded subnet CIDRs or static NAT mappings.
• Auto-Scaling Protection: Any new Lambda function attached to the Security Group instantly inherits the correct SSL inspection policy.

Demonstrating Verification & Testing

To test the deployment, we invoke the URLStatusChecker Lambda function with a payload targeting https://ipinfo.io:

Test Event Payload

Lambda Response Payload

Conclusion & Key Takeaways

Securing serverless egress traffic does not require sacrificing security visibility or burdening developers with complex certificate management code.

By combining AWS CloudFormation, an isolated S3 bucket, and Zscaler Internet Access (ZIA):

1. Security is Automated: Lambda functions dynamically discover and inject the Zscaler Root CA during cold start without modifying base images.
2. Traffic is Fully Inspected: ZIA performs deep content inspection and threat analysis on encrypted outbound HTTPS sessions.
3. Policy is Identity-Centric: Workload Groups tie ZIA policies directly to AWS Security Groups and cloud metadata, creating a scalable, zero-trust serverless architecture.

Ready to Learn More?

Check out the full CloudFormation deployment template (lambda-ssl-demo.yaml) and step-by-step setup guide in our GitHub repository to implement automated SSL inspection for your serverless workloads today!

While this blog focuses on AWS Lamba, a similar approach can be leveraged for Serverless workloads in other cloud providers. E.g. Azure Functions & Cloud Run in GCP.

To learn more about Zscaler Zero Trust Gateway, click here.