AWS PrivateLink: Secure and Scalable Service Connectivity

1️. Introduction
• Overview & Importance of AWS PrivateLink
• Challenges in Traditional VPC Connectivity
2️. Similar VPC Connectivity Solutions
• VPC Peering, Transit Gateway, VPN & Direct Connect
• Comparison with PrivateLink
3️. Key Use Cases & Benefits
• SaaS Applications, Multi-Account Access, Hybrid Cloud
• Security, Simplified Networking, Cost-Effectiveness
4️. AWS PrivateLink POC Architecture
• Infrastructure Diagram & Setup Plan
• Prerequisites (VPC, EC2️, Security Groups)
5️. Implementation Steps
• Setting Up EC2️ & Deploying a Web App
• Configuring Network Load Balancer (NLB)
• Creating VPC Endpoint Service & Endpoints
6️. Testing & Validation
• SSH & HTTP Access Verification
• Private Connectivity Testing via PrivateLink
7️. Cross-Account PrivateLink
• Multi-Account Setup & Security Best Practices
Introduction: -
AWS PrivateLink is a networking service that allows secure, private connectivity between
Virtual Private Clouds (VPCs) and AWS services without exposing traffic to the public internet. It
ensures seamless and highly available communication between services while maintaining
strong security and compliance controls.
Traditionally, connecting services across VPCs required solutions like VPC Peering, Transit
Gateway, or VPN, which have limitations in scalability, security, and complexity. AWS
PrivateLink overcomes these challenges by providing private, direct access to AWS services and
custom applications hosted in different VPCs or AWS accounts.
Similar Connectivity Solutions in VPC: -
AWS provides multiple ways to connect services within or across VPCs:
1. VPC Peering – Establishes a direct connection between two VPCs, but doesn’t scale well
for multi-account architectures.
2. AWS Transit Gateway – Centralized routing for multiple VPCs, offering more scalability
but requiring additional configurations.
3. AWS VPN & Direct Connect – Secure connections between on-premises and AWS, but
not ideal for VPC-to-VPC communication within AWS.
Key Differences: PrivateLink vs. Other Solutions: -

VPN & Direct

Feature AWS PrivateLink VPC Peering Transit Gateway
Connect

Centralized Connects on-prem

Connectivity Private, ENI-based Direct VPC-to-VPC
routing to AWS

No exposure to Needs routing More complex

Security Encrypts traffic
public internet setup security policies

Scales easily Limited by peer Supports large Best for hybrid

Scalability
across accounts connections architectures cloud

Secure SaaS & Enterprise-grade

Small-scale VPC On-premises to AWS
Use Case cross-account multi-VPC
communication communication
service access networks
Common Use Cases of AWS PrivateLink: -
• SaaS Applications: Allows customers to access SaaS services securely from their VPCs.
• Multi-Account Connectivity: Enables internal AWS services across different accounts
without exposing traffic to the internet.
• Hybrid Cloud Architecture: Ensures private communication between on-premises
systems and AWS-hosted services.
• Regulatory Compliance: Helps industries like finance and healthcare meet strict data
security requirements.
Benefits of AWS PrivateLink: -
• Enhanced Security – Traffic stays within the AWS network, reducing exposure to
threats.
• Simplified Network Management – No complex routing configurations or NAT gateways
required.
• Cross-Account Connectivity – Easily share services with other AWS accounts.
• Lower Latency & High Performance – Uses AWS backbone network for fast, reliable
communication.
• Cost-Effective – Reduces data transfer costs by avoiding NAT, VPN, or internet-based
routing.
AWS PrivateLink POC Architecture Diagram
 Infrastructure Creation: Prerequisites & Setup Plan 🛠️
Prerequisites : -
Before implementing AWS PrivateLink, ensure the necessary infrastructure components are in
place:
1. Two VPCs in the Same AWS Account (for Initial Testing)
• Provider VPC: Hosts the application.
• Consumer VPC: Accesses the application securely.
2. VPC Components Required:
Subnets:
▪ Public Subnet (Provider VPC): For initial EC2 instance setup and access.
▪ Private Subnet (Provider VPC): Where the actual application runs
(PrivateLink does not use internet access).
▪ Subnet in Consumer VPC: To connect via the interface endpoint.
Route Tables:
▪ Configured to allow communication between private subnets.
Internet Gateway & NAT (Only for Initial Setup):
▪ Temporarily used to install application dependencies before removal.
 Step-by-Step Implementation
VPC and Resource Mapping: -
1. Create Two VPCs – One for the service provider (VPC-1) & consumer (VPC-2).
2. Set Up Subnets & Routing – Configure public and private subnets, route tables, and
necessary gateways.
3. Deploy EC2️ Instance – Launch an instance in VPC-1 with a simple HTTP application for
testing.

➢ EC2️ in VPC-1️ (Public) – Launched a public EC2 instance for initial setup and
internet access.
➢ EC2️ in VPC-1️ (Private) – Launched a private EC2 instance to host the HTTP
application.
 ➢ EC2️ in VPC-2️ (Public) – Created a public EC2 instance for connectivity testing.
➢ EC2️ in VPC-2️ (Private) – Deployed a private EC2 instance to validate PrivateLink
communication.

1️.Steps to Connect to Private EC2️ Server Using SSH (provider vpc)

➢ Connect to Public EC2️ – SSH into the public EC2 instance using the .pem key file.
➢ Transfer Key File – Copy the .pem key to the public EC2 instance.
➢ Set Permissions – Run chmod 400 key.pem to set correct permissions
➢ SSH to Private EC2️ – Use $ sudo ssh -i key.pem ec2-user@<private-ec2-ip> to connect
from the public EC2 to the private EC2

➢ Check Internet on Private EC2️ – Ran ping google.com, but no internet access since NAT
Gateway was not added.

➢ Create NAT Gateway – Created a NAT Gateway in the public subnet with an Elastic IP.
➢ Update Route Table – Added a route in the private subnet's route table to send internet
traffic (0.0.0.0/0) to the NAT Gateway.
➢ Verify Internet Access – Retried ping google.com from the private EC2, now successfully
getting internet access.

➢ Install HTTPD – Ran sudo yum install -y httpd to install Apache web server.
➢ Start HTTPD Service – Executed sudo systemctl start httpd and sudo systemctl enable
httpd to start and enable the service.

➢ Create Sample Application – Created an index.html file in /var/www/html/

➢ Verify Application – Used curl localhost to confirm the web server is serving the page.
 ➢ Deleted NAT Gateway – Removed the NAT Gateway from the VPC setup.
➢ Checked Internet Connectivity – Ran ping google.com from the private instance.

We need a Network Load Balancer (NLB) for this AWS PrivateLink POC to enable secure,
private communication between VPCs. NLB ensures high-performance, low-latency traffic
routing while keeping services isolated from the public internet.

Why Choose a Network Load Balancer (NLB) for AWS PrivateLink?

A Network Load Balancer (NLB) is essential for AWS PrivateLink as it enables private, secure,
and high-performance connectivity between VPCs and AWS services. Unlike traditional
internet-based access, PrivateLink ensures that traffic remains within the AWS network,
improving security and reducing exposure to the public internet.
Purpose of Network Load Balancer (NLB)
An NLB operates at Layer 4️ (TCP/UDP), allowing it to handle millions of requests per second
with ultra-low latency. It efficiently forwards traffic to registered targets, such as EC2 instances,
across Availability Zones. When used with PrivateLink, the NLB ensures that services in one VPC
can be securely accessed from another VPC using private IP addresses.
Other Load Balancers in AWS & Why They Are Not Suitable for PrivateLink

• Application Load Balancer (ALB) – Works at Layer 7️ (HTTP/HTTPS) and supports advanced
routing, but PrivateLink requires Layer 4.
• Classic Load Balancer (CLB) – An older option that supports both Layer 4 and Layer 7 but
lacks modern features and efficiency.
• Network Load Balancer – Operates at Layer 4️, designed for high-performance
TCP/UDP traffic and used for AWS PrivateLink.
 Steps to Create a Network Load Balancer (NLB)

1. Created a target group with instance-based target type.

2. Named the target group, set protocol to TCP 80, and selected IPv4️.
3. Assigned the target group to the appropriate VPC for PrivateLink traffic routing.
Network Load Balancer Creation
1. Created the Network Load Balancer, named it, and selected "Internal" as the scheme.
2. Mapped it to the provider VPC, added availability zones, configured listeners, and set up
target groups.

4
 VPC Endpoint Service Integration
1. Navigated to the Network Load Balancer integration section and selected VPC Endpoint
Services (AWS PrivateLink).
2. Created an endpoint service, named it, selected the available load balancer, and
enabled Acceptance Required with IPv4 settings.
1

4
➢ PrivateLink Successfully Created for Provider VPC

Steps to Create an Interface Endpoint for AWS PrivateLink

1. Created a new VPC Endpoint and selected the Endpoint Service that uses the
Network Load Balancer (NLB).

2. Copied and pasted the PrivateLink Service Name for verification.

 3. Selected the required subnets and security groups for the endpoint.

4. Successfully created the endpoint.

Steps to Accept the Interface Endpoint Request

➢ Accept Endpoint Connection Request
Security Group Configuration
1. Allowed SSH (2️2️) for secure access.
2. Allowed HTTP (80) for web traffic over the Private Link.

Testing Private Link Connectivity

Successfully accessed the service using curl with the endpoint DNS from the consumer VPC's
private instance, verifying the connection.
 Cross-Account AWS PrivateLink: Use Cases & Benefits
Why Use Cross-Account PrivateLink: -
In many enterprise environments, applications and services are deployed across multiple AWS
accounts for better security, compliance, and resource isolation. AWS PrivateLink enables
secure, private connectivity between these accounts without exposing services to the public
internet.
Use Cases & Scenarios: -
• Multi-Account Architectures: Large organizations use different AWS accounts for
development, testing, and production, requiring private connectivity.
• SaaS Provider & Customer Connectivity: SaaS vendors can securely offer services to
customers without requiring internet exposure.
• Inter-Department Communication: Different teams or business units using separate
AWS accounts can share internal services securely.
• Regulated Industries: Financial, healthcare, and government organizations benefit from
enhanced security and compliance by keeping data within AWS private networks.
Advantages of Cross-Account PrivateLink: -
Enhanced Security – No need to expose services to the public internet.
Simplified Network Management – Avoids complex VPC peering and routing configurations.
Lower Latency & Cost – Traffic stays within AWS, reducing latency and data transfer costs.
Scalability – Supports high-throughput workloads with network load balancing.
Access Control – Fine-grained control over which AWS accounts can connect to the service.
This approach ensures secure and reliable communication between different AWS accounts
without the risks associated with internet exposure.

Expanding Private Link to Another AWS Account

• Kept the application VPC unchanged in the first AWS account.
• Created a new VPC in a second AWS account (same region) with public and private
instances.
• Goal: Connect the private instance in the second account via AWS PrivateLink to
securely access the HTML application hosted in the first account without exposing it to
the internet.
1️: Creating Instances in the Second AWS Account: -
• Launched two EC2️ instances: one in the public subnet and one in the private subnet in
a custom VPC.
• The public instance allows SSH access to manage the setup.
• The private instance will be used to test the AWS PrivateLink connection.

➢ Connected to the private instance via SSH from the public instance using a key pair.
 Granting Access to Consumer Account
1. Navigate to the Endpoint Services section in the Provider Account. (this are the steps
on Provider Account)

2. Select the existing PrivateLink endpoint service.

3. Click on Actions → Allow Principles.
4. Enter the Consumer Account ARN arn:aws:iam::ACCOUNT_ID:root in the Allow
Principles section and save.

Creating Endpoint in Consumer Account (steps on Consumer Account)

1. Navigate to VPC → Endpoints in the Consumer Account.
2. Click Create Endpoint and select VPC Endpoint Service.
3. Enter the Service Name provided by the Provider Account and verify.
 ➢ After creating the VPC Endpoint in the Consumer Account, the status shows as Pending
Acceptance until the Provider Account approves the request.

Accepting Endpoint Request in Provider Account: -

• In the Provider Account, navigate to VPC Endpoint Services, select the pending
endpoint request, and accept the connection to establish the PrivateLink.
Endpoint Status Available in Receiver Account: -
• In the Receiver Account, the endpoint status now shows as Available, confirming a
successful PrivateLink connection.

Security Group Configuration: -

• The Security Group is configured to allow SSH (port 2️2️) and HTTP (port 80) for secure
access and communication.
 Verifying PrivateLink Access
• In the Receiver Account, the Endpoint DNS Name is copied from the Endpoints Section.
• From the Private EC2️ instance, a curl request is made to the DNS Name.
• The HTML application is successfully accessed, confirming PrivateLink connectivity
without internet exposure.
In this AWS PrivateLink Proof of Concept (PoC), we successfully established secure, private
connectivity between VPCs using PrivateLink. We implemented a service provider VPC hosting
a simple application and a service consumer VPC accessing it privately via an interface
endpoint. To achieve this, we leveraged a Network Load Balancer (NLB) for routing traffic
efficiently and securely.
Key Learnings
Private Connectivity: Eliminated public internet exposure, ensuring enhanced security.
VPC-to-VPC Communication: Enabled seamless access between isolated VPCs using
PrivateLink.
NLB with PrivateLink: Used an NLB to route traffic internally, as PrivateLink requires an L4️ load
balancer.
Access Control: Restricted access using IAM policies and endpoint security groups.
Other Use Cases for AWS PrivateLink
Beyond this PoC, AWS PrivateLink can be leveraged for:
Connecting On-Premises to AWS Services without internet exposure.
Accessing AWS-Managed Services like S3, DynamoDB, or RDS privately.
Secure Multi-Account Communication in an AWS Organizations setup.
Third-Party SaaS Integration without exposing services to the internet.
By implementing AWS PrivateLink, organizations can achieve a highly secure, scalable, and
private networking solution for their AWS workloads.
Thank you for going through this PoC. I hope this helps in understanding AWS PrivateLink
better!

- Kranthi