12.2 Private Network Connectivity: VPC Endpoints & Peering

12.2 Private Network Connectivity: VPC Endpoints & Peering

CloudOps Blueprint Focus: The AWS Certified CloudOps Engineer – Associate (SOA-C03) exam tests your ability to establish private network connectivity without traversing the public internet. You must master the architectural differences between Gateway Endpoints and Interface Endpoints (AWS PrivateLink), configure endpoint policies to prevent data exfiltration, ensure private DNS resolution, and navigate VPC Peering constraints including non-transitive routing and MTU limits.

Private Connectivity: Gateway Endpoints vs. Interface Endpoints

AWS provides VPC Endpoints to connect VPC resources to supported AWS services and partner applications without an Internet Gateway, NAT Gateway, or public IP addresses. VPC Endpoints fall into two distinct architectures: Gateway Endpoints and Interface Endpoints (AWS PrivateLink).

---

Gateway Endpoints: Route Table Targets & Endpoint Policies

A Gateway Endpoint is a managed routing target for VPC route tables connecting to Amazon S3 or Amazon DynamoDB.

Routing Mechanics & Prefix Lists

Creating a Gateway Endpoint generates an entry in selected route tables pointing to an AWS Prefix List representing regional service IP ranges:

$$\text{Destination: } \texttt{pl-63a5400a (com.amazonaws.us-east-1.s3)} \longrightarrow \text{Target: } \texttt{vpce-xxxx}$$

Because the prefix list is more specific than the default route (0.0.0.0/0), traffic to S3 or DynamoDB routes across the AWS private network, bypassing NAT Gateways and eliminating data processing fees.

Non-Transitive Boundary Limitation

Gateway Endpoints cannot be accessed from outside the VPC:

• On-premises hosts connected via AWS Direct Connect or Site-to-Site VPN cannot route through a VPC to reach a Gateway Endpoint.
• Peered VPCs and Transit Gateways cannot route traffic to a Gateway Endpoint in another VPC.
• Gateway Endpoints only serve resources within subnets associated with the designated VPC route tables.

Endpoint Policies for Data Exfiltration Prevention

By default, Gateway Endpoints permit access to any S3 bucket across any AWS account. To prevent unauthorized exfiltration to external accounts, attach a VPC Endpoint Policy:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowCorporateBucketsOnly",
      "Effect": "Allow",
      "Principal": "*",
      "Action": ["s3:GetObject", "s3:PutObject", "s3:ListBucket"],
      "Resource": [
        "arn:aws:s3:::corp-production-storage",
        "arn:aws:s3:::corp-production-storage/*"
      ]
    }
  ]
}

Requests to unauthorized buckets through this endpoint are rejected with an HTTP 403 Forbidden error.

---

Interface Endpoints (AWS PrivateLink) & Private DNS

Interface Endpoints use AWS PrivateLink to provide private access to over 100 AWS services (e.g., EC2, SSM, Secrets Manager, KMS, and S3 Interface endpoints), third-party SaaS platforms, and internal microservices.

Elastic Network Interfaces (ENIs) & Hybrid Reach

Provisioning an Interface Endpoint places an Elastic Network Interface (ENI) with a private IP address into each designated subnet. Traffic flows through the ENI to an AWS-managed Network Load Balancer (NLB) fronting the service fleet:

• Security Groups: Standard security groups attach to the endpoint ENIs to restrict inbound traffic to authorized source CIDRs and ports (typically TCP 443).
• Hybrid Accessibility: Because Interface Endpoints have private IP addresses, they are fully routable from on-premises over AWS Direct Connect or Site-to-Site VPN, across VPC Peering connections, and through AWS Transit Gateway.

Private DNS Resolution Mechanics

Interface Endpoints generate specific regional DNS hostnames (e.g., vpce-xxxx.s3.us-east-1.vpce.amazonaws.com). Enabling Private DNS creates a private Route 53 zone overriding the public service endpoint (e.g., secretsmanager.us-east-1.amazonaws.com), resolving it directly to the endpoint ENI private IPs:

• Applications and SDKs continue using standard endpoint URLs without code modifications.
• Prerequisites: Both enableDnsHostnames and enableDnsSupport must be set to true on the VPC for Private DNS to function.

---

VPC Peering: Architecture, Constraints & MTU Tuning

VPC Peering creates a 1:1 network connection between two VPCs within the same Region or across Regions and accounts. All traffic travels over the private AWS backbone with physical-layer encryption.

Core Peering Constraints

• No Overlapping CIDRs: VPCs with matching or overlapping CIDR blocks cannot be peered.
• Bidirectional Route Tables: Routes must be added manually in both VPC route tables directing the peer CIDR to the peering connection ID (pcx-xxxx).
• Security Group Referencing: Intra-Region peering allows referencing peer security groups by ID. Cross-Region peering does not support peer security group references; rules must use CIDR blocks.

The Non-Transitive Routing Constraint

VPC Peering does not support transitive routing:

$$\text{VPC A} \longleftrightarrow \text{VPC B} \longleftrightarrow \text{VPC C} \quad \nRightarrow \quad \text{VPC A} \longleftrightarrow \text{VPC C}$$

Traffic cannot hop through an intermediate VPC. Connecting multiple VPCs requires either:

1. Full Mesh Peering: Direct peering links between every VPC pair ($\frac{N(N-1)}{2}$ links; 10 VPCs require 45 links).
2. AWS Transit Gateway: A central regional hub-and-spoke router supporting transitive routing across thousands of VPCs and on-premises connections.

MTU Configurations

• Intra-Region Peering: Supports Jumbo Frames up to 9001 bytes, optimizing throughput for high-volume transfers.
• Cross-Region Peering: Strictly capped at 1500 bytes. Packets exceeding 1500 bytes are fragmented or dropped.