Best Practices for Connecting SaaS in AWS Private Networks Across Accounts
As more enterprises adopt cloud-native architectures, the need for secure, scalable, and private communication between services hosted in different AWS accounts becomes increasingly important—especially when integrating third-party SaaS applications with internal data platforms like Amazon Redshift.
In this blog, we’ll explore how to securely connect a SaaS application hosted in a vendor’s AWS account (Account A) to Amazon Redshift in the client’s AWS account (Account B) using PrivateLink, VPC Endpoint Services, and Network Load Balancer (NLB)—all within private networks.
📌 Architecture Overview
In this setup:
The SaaS application runs inside a private subnet in Vendor AWS Account A.
It is exposed via a Network Load Balancer (NLB) within the same VPC.
The NLB is attached to a VPC Endpoint Service, allowing other AWS accounts to privately connect to it.
Account B (client) creates a VPC Endpoint to consume the service.
This endpoint allows Redshift (in Account B) to communicate with the SaaS application via PrivateLink—ensuring traffic never traverses the public internet.
🔒 Why PrivateLink?
AWS PrivateLink allows private connectivity between VPCs, services, and accounts without exposing data to the public internet. It offers:
High security through private IP communication
Scalable and manageable integration between multiple AWS accounts
Reduced attack surface compared to opening up resources via public endpoints
🧱 Key Components
✅ 1. Network Load Balancer (NLB) in Vendor Account (A)
Accepts traffic destined for the SaaS application.
Supports TCP-level connections, essential for high-performance data apps like Redshift.
Required to expose an endpoint service.
✅ 2. VPC Endpoint Service
Created in Account A, pointing to the NLB.
Allows Account B to connect via Interface VPC Endpoints.
Optionally whitelists AWS Account IDs or specific principals for access control.
✅ 3. Interface VPC Endpoint in Client Account (B)
Connects privately to the vendor’s endpoint service.
Appears as an ENI (Elastic Network Interface) in Account B’s VPC.
Used by Redshift to make outbound connections to the SaaS NLB.
✅ 4. Amazon Redshift in Private Subnet (Account B)
Uses enhanced VPC routing to direct traffic through the interface endpoint.
Communicates privately with the SaaS application, avoiding public NAT gateways or internet routes.
⚙️ Best Practices
🔐 1. Use IAM and Resource Policies for Access Control
Apply strict IAM conditions on the VPC Endpoint Service to limit who can connect.
Consider using AWS Resource Access Manager (RAM) if working with multiple consumers.
🌐 2. DNS Integration
Enable Private DNS for the VPC Endpoint to simplify routing.
This ensures that standard domain names (e.g.,
api.vendor-saas.com) resolve to the internal PrivateLink IP.
📶 3. Monitor and Log Traffic
Use VPC Flow Logs and CloudWatch to audit data access patterns.
Monitor NLB connection health to detect and resolve SaaS-side issues early.
🛡 4. Enable Encryption
Use TLS between Redshift and the SaaS endpoint for data-in-transit encryption.
Configure the NLB to support SSL termination if needed.
📏 5. Plan for Scaling
Design NLB target groups to handle high-concurrency loads.
Use Auto Scaling Groups on the SaaS side if traffic is dynamic.
✅ Benefits of This Approach
No public IPs or internet exposure
Secure multi-account architecture
Seamless, low-latency data exchange
Better compliance with enterprise network policies
🧠 Conclusion
By leveraging AWS PrivateLink, VPC Endpoint Services, and NLB, you can design a secure, reliable, and scalable SaaS integration pattern across AWS accounts. Whether you’re a vendor hosting the SaaS or a client consuming it, this architecture protects sensitive data and keeps your infrastructure compliant with private network policies.
Need help designing such an architecture?
Reach out or drop your questions in the comments below. Let’s build secure, cloud-native networks—together.