AWS PrivateLink 與 VPC Endpoint 架構

What Is AWS PrivateLink and Why Does SAP-C02 Care?

AWS PrivateLink is the AWS technology that exposes a single service across VPC boundaries without routing, without peering, and without exposing whole CIDR ranges. At the SAP-C02 level, AWS PrivateLink is not simply an optional add-on to Amazon VPC networking — it is the canonical answer to an entire family of Professional-tier scenarios: overlapping CIDR ranges between acquired companies, SaaS vendors selling private services to hundreds of customer VPCs, AWS Marketplace integrations that must never touch the public internet, least-privilege access to AWS service APIs from private subnets, and cross-account architectures where the traditional "peer every VPC to every VPC" model collapses under its own weight.

The SAP-C02 exam guide places AWS PrivateLink under Domain 2 (Design for New Solutions, 29%) and Domain 4 (Continuous Improvement for Existing Solutions, 25%), and it is one of a small number of networking services that appears in nearly every SAP-C02 test form. Candidates who think of AWS PrivateLink only as "Interface VPC Endpoints for S3" will miss the majority of the points available. The Professional exam expects you to distinguish the producer side (VPC Endpoint Service) from the consumer side (Interface VPC Endpoint), to select AWS PrivateLink over VPC peering or Transit Gateway when CIDR overlap makes routing impossible, to design endpoint policies that differ from IAM resource policies, and to integrate Private DNS, Route 53 aliases, and security group rules into a coherent deployment.

This study topic walks through AWS PrivateLink end-to-end with the depth SAP-C02 demands: the two flavors of VPC Endpoint (Gateway and Interface), the Endpoint Service that a producer publishes behind a Network Load Balancer, the cross-account and cross-region mechanics, the AWS Marketplace integration, and the critical decision framework that tells you when AWS PrivateLink beats VPC peering and when Transit Gateway is the better hub. The material assumes you are already comfortable with Amazon VPC basics; if subnets, route tables, or NAT Gateways are shaky, review those first before coming back for AWS PrivateLink.

白話文解釋 AWS PrivateLink in Plain Language

Before diving into AWS PrivateLink mechanics, three analogies make the whole service click. The Professional exam rewards candidates who can translate back and forth between these mental models and the technical names.

Analogy 1 — The Office Building Tenant Directory

Imagine a 40-floor office building in which each floor is a separate Amazon VPC owned by a different company. Traditional VPC peering is like drilling a private corridor between two floors: anyone on either floor can walk into any office on the other. That might be fine for two friendly tenants, but it does not scale and it does not work at all if two floors happen to use the same office-numbering scheme (both use rooms 201-220 — overlapping CIDR). AWS PrivateLink is the building's concierge desk: every tenant publishes just one service (for example, "Legal Review Service on Floor 17") into the concierge directory. When someone on Floor 9 needs legal review, they walk up to their own floor's concierge phone, dial extension 1701, and talk only to that specific service. They never walk the hallways of Floor 17, never see room numbers, and never collide with their own Floor 9 room numbers. The concierge translates the call on the fly. That is exactly what AWS PrivateLink does through an Interface VPC Endpoint: it creates a local ENI inside the consumer's VPC that routes a single service's traffic to the producer over the AWS backbone, regardless of CIDR collisions.

Analogy 2 — The Hotel Room Service Menu (Endpoint Service vs Interface Endpoint)

Picture a hotel where each guest room is a consumer VPC and the hotel kitchen is the producer VPC. The kitchen publishes a room service menu — that menu is the VPC Endpoint Service. The guest picks up the in-room phone to dial room service — that phone is the Interface VPC Endpoint. The hotel's internal phone system routes the call from Room 412's phone (ENI in consumer subnet) through the kitchen's single intake line (Network Load Balancer fronting the producer), which distributes the call to whichever chef is free (EC2 or container target behind the NLB). The guest never needs to know the kitchen's floor plan, never sees the chefs' individual numbers, and never can wander into the kitchen. The kitchen, in turn, can accept or reject specific rooms (endpoint connection acceptance), set pricing, or revoke access at any time. This is the producer / consumer asymmetry that distinguishes AWS PrivateLink from VPC peering (a peering is symmetric — both sides see each other fully).

Analogy 3 — The Embassy Visa Counter (Overlapping CIDR Solution)

Imagine two countries that, historically, both numbered their citizens 1 through 1,000,000. The numbering schemes overlap perfectly — there are a million Citizen #42s on both sides. A traditional VPN between the two countries' records systems would be unworkable because Citizen #42 is ambiguous. Instead, each country opens a visa counter inside the other's capital: a local desk, with a local address, staffed to handle exactly one transaction (visa application). The citizen walks up to the local visa counter, which forwards the request over a private diplomatic channel, and returns a response. The two national databases never peer, never exchange ID numbers, never collide. AWS PrivateLink is the visa counter of AWS networking: when two VPCs have overlapping 10.0.0.0/16 ranges (classic post-acquisition headache), you cannot peer and you cannot route via Transit Gateway without expensive 1:1 NAT gymnastics. But you can publish one VPC's service behind a PrivateLink Endpoint Service, have the other VPC consume it via an Interface Endpoint with a fresh local ENI IP, and the overlap is simply irrelevant. This is a top-3 SAP-C02 pattern and worth memorizing by heart.

With the office concierge, the hotel room service, and the embassy visa counter analogies in mind, every AWS PrivateLink component and trap becomes easier to place.

AWS PrivateLink Core Model — Producer, Consumer, and the Load Balancer in Between

AWS PrivateLink formalizes a producer / consumer service model on top of Amazon VPC. Unlike VPC peering (which is symmetric) or Transit Gateway (which is a hub-and-spoke router), AWS PrivateLink is deliberately asymmetric and service-scoped.

Producer Side — The VPC Endpoint Service

The producer is the VPC that owns the service you want to expose. The producer creates:

1. A Network Load Balancer (NLB) in its own VPC, with target groups pointing at EC2 instances, containers, or IP targets that run the actual service. As of 2023, a Gateway Load Balancer (GWLB) can also front an Endpoint Service for security appliance chains — useful for inline firewall inspection in SAP-C02 scenarios.
2. A VPC Endpoint Service configuration attached to that NLB. The Endpoint Service gets a unique service name in the format com.amazonaws.vpce.<region>.vpce-svc-<hash>.
3. An allowlist of AWS principals (account IDs, IAM roles, or users) permitted to connect.
4. An optional acceptance setting (auto-accept or manual accept). Manual accept means every new consumer connection waits for the producer to approve it — common in SaaS and Marketplace patterns.
5. Optional Private DNS name configuration with domain ownership verification via a TXT record, so consumers can reach the service using a custom domain such as api.example-saas.com instead of the long vpce-... DNS name.

Consumer Side — The Interface VPC Endpoint

The consumer is any VPC (same account or cross-account, same region or cross-region since 2024) that wants to reach the producer's service. The consumer creates an Interface VPC Endpoint that:

1. Spawns an Elastic Network Interface (ENI) per Availability Zone inside a chosen subnet, each with a private IP from the consumer VPC's CIDR.
2. Attaches a security group to those ENIs controlling which consumer resources can reach the endpoint.
3. Optionally attaches an endpoint policy (a resource-based IAM policy) further restricting what actions the endpoint will forward to the service.
4. Optionally registers a Private DNS name that overrides the service's public DNS inside the consumer VPC — so existing client code using s3.us-east-1.amazonaws.com transparently routes through the endpoint.

The Traffic Path

When a consumer EC2 instance calls the service:

1. DNS resolves the service name to the Interface Endpoint's ENI private IP (thanks to Private DNS or an explicit alias).
2. Traffic hits the ENI inside the consumer VPC — it never leaves the consumer VPC via an Internet Gateway, NAT Gateway, or Transit Gateway.
3. AWS PrivateLink forwards the TCP stream across the AWS backbone to the producer's NLB.
4. The NLB distributes it to a healthy target.
5. The response flows back along the same private path.

At no point does traffic cross the public internet. At no point does either VPC see the other's CIDR. At no point does routing need to be reconciled. This is the fundamental AWS PrivateLink superpower.

VPC Endpoints — Gateway vs Interface

AWS PrivateLink is the technology behind Interface VPC Endpoints, but Amazon VPC also offers a second, older kind — Gateway VPC Endpoints. SAP-C02 requires that you distinguish the two crisply, because they have completely different billing, implementation, and capability profiles.

Gateway VPC Endpoints

Gateway Endpoints are a legacy design and exist only for two AWS services: Amazon S3 and Amazon DynamoDB. Their implementation uses a route-table prefix list entry (for example pl-63a5400a for S3 in us-east-1). When a subnet's route table contains the prefix list pointing to the gateway endpoint, S3 or DynamoDB traffic from that subnet is silently routed through AWS PrivateLink's predecessor plumbing rather than out the Internet Gateway.

Gateway Endpoint properties relevant to SAP-C02:

• No hourly charge, no per-GB charge — they are free.
• Regional scope — you cannot use a Gateway Endpoint cross-region.
• Route-table dependency — each subnet that needs endpoint access must have its route table updated.
• No ENI, no private IP — they do not consume CIDR space.
• No cross-VPC, cross-account, or on-prem consumption — a Gateway Endpoint is usable only from the VPC it belongs to; on-premises traffic via Direct Connect or VPN cannot reach a Gateway Endpoint.
• Endpoint policies supported — you can restrict which S3 buckets or DynamoDB tables the endpoint permits.

Interface VPC Endpoints (Powered by AWS PrivateLink)

Interface Endpoints work for nearly every AWS service (hundreds at time of writing) plus customer-published services and AWS Marketplace services. Their implementation uses an ENI per AZ with a private IP in your subnet — the IP comes from your VPC CIDR.

Interface Endpoint properties relevant to SAP-C02:

• Hourly charge per AZ per endpoint plus per-GB data processing charge — pricing matters at scale.
• Works cross-VPC, cross-account, and (since 2024) cross-region.
• Reachable from on-premises over Direct Connect or Site-to-Site VPN — this is a huge SAP-C02 pattern (hybrid access to AWS APIs without going over the public internet).
• Private DNS integration — can override the public DNS hostname for the AWS service inside the VPC.
• Security group enforcement — attach an SG to the endpoint ENIs to gate traffic.
• Endpoint policies supported — restrict actions, resources, or principals.

Quick Decision Rules

• S3 from in-VPC only, cost-sensitive, no on-prem access needed → Gateway Endpoint (free).
• S3 from on-premises over Direct Connect, or from a different VPC/account → Interface Endpoint (paid, but reachable).
• DynamoDB in-VPC only → Gateway Endpoint (free).
• Any other AWS service (KMS, SSM, Secrets Manager, SNS, SQS, STS, ECR, EKS, …) → Interface Endpoint (no Gateway alternative).

AWS PrivateLink for Overlapping CIDR — The Signature SAP-C02 Pattern

If you take only one pattern from this entire topic into the exam, make it this: AWS PrivateLink is the canonical solution for overlapping CIDR between VPCs. SAP-C02 loves this scenario because it maps directly onto real-world M&A consolidations, where two companies both use 10.0.0.0/16 internally and cannot peer.

Why Peering and Transit Gateway Fail on Overlap

VPC peering requires that the two VPCs' CIDRs do not overlap, period. If Company-A's VPC is 10.0.0.0/16 and Company-B's VPC is also 10.0.0.0/16, a peering request is rejected at creation time. Transit Gateway is slightly more flexible — it can hold overlapping attachments in separate route tables — but the individual source/destination pairs still cannot share the same IP. You would have to interpose a 1:1 NAT (typically a self-managed NAT instance or Network Firewall with rewrite rules) to translate each instance's IP into a non-overlapping range. That is expensive, brittle, and requires engineering for every new service.

Why PrivateLink Sidesteps Overlap

AWS PrivateLink does not route packets between VPCs. It terminates a connection at an ENI inside the consumer VPC, then originates a new connection from the producer side toward the NLB. From the consumer's perspective, it is talking to a local IP inside its own VPC. From the producer's perspective, the connection comes from the NLB — which sees a PrivateLink-assigned source address, not the consumer's real IP. The two VPC CIDRs are never compared, never routed together, and never need to be disjoint.

This makes AWS PrivateLink a 1:1 NAT alternative that is fully managed, horizontally scalable, and service-scoped. You pay the Interface Endpoint hourly + per-GB rate, and you skip the entire NAT-instance operational burden.

When PrivateLink Is the Right Answer for Overlap

• Post-M&A VPC consolidation: Company A acquired Company B; both use 10.0.0.0/16; Company A needs to expose a handful of internal services to Company B without re-IPing either side.
• Multi-tenant SaaS: You run a SaaS on AWS; your customers each bring their own VPC with random CIDRs, many overlapping yours; you expose one API service to all of them.
• Shared corporate services: A central "shared services" VPC offers observability, CI/CD, or directory services to dozens of workload VPCs, several of which overlap with each other but not (by design) with the shared services VPC — PrivateLink lets any workload VPC reach shared services regardless of whether its neighbors overlap.

When PrivateLink Is NOT the Right Answer

• You need bidirectional, general-purpose VPC connectivity (multiple services, arbitrary protocols, both directions) → use peering (if no overlap) or Transit Gateway (with non-overlapping attachments).
• You need routing of broadcast or multicast → AWS PrivateLink is TCP/UDP unicast only.
• You need IPv6 — AWS PrivateLink supports IPv6 for some services but coverage is partial; verify per service.

Endpoint Policies — Resource-Based Controls on AWS PrivateLink

An endpoint policy is a JSON document attached to a VPC Endpoint that further restricts what the endpoint will permit. It is a resource-based IAM policy that intersects with the calling principal's IAM policy — the effective permission is the intersection of (principal's IAM), (endpoint policy), and (target service's resource policy, if any).

Endpoint Policy Syntax

The syntax mirrors standard IAM but lives on the endpoint:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": "*",
      "Action": ["s3:GetObject", "s3:PutObject"],
      "Resource": [
        "arn:aws:s3:::examhub-prod-logs/*",
        "arn:aws:s3:::examhub-prod-logs"
      ]
    }
  ]
}

This policy says: "Only S3 GetObject and PutObject against the examhub-prod-logs bucket are permitted through this endpoint." Even if the caller's IAM role grants s3:* on any bucket, the endpoint policy clamps the endpoint to two actions on one bucket.

Why Endpoint Policies Matter at SAP-C02 Level

1. Data exfiltration prevention. Without an endpoint policy, an EC2 instance with broad IAM permissions could, via the S3 Gateway Endpoint, upload corporate data to any S3 bucket in any AWS account. An endpoint policy that restricts the bucket ARN to your own organization's account IDs blocks the exfil path at the network layer.
2. Least privilege composition. Combine an endpoint policy (per-VPC) with IAM policies (per-role) and bucket policies (per-resource) for defense in depth.
3. Compliance evidence. Auditors love endpoint policies because they give a single-document view of "what can leave this VPC toward this service."

Default Endpoint Policy

When you create a new Interface Endpoint the default endpoint policy is "Effect": "Allow", "Action": "*", "Resource": "*" — it grants full access. If you rely on endpoint policies for security, you must explicitly replace the default. Forgetting this is a common SAP-C02 trap in exfiltration-hardening questions.

Endpoint Policy vs IAM Policy

A common confusion: endpoint policies do not grant permissions by themselves. They are a filter. If the caller's IAM policy does not grant s3:GetObject, no amount of endpoint policy Allow will make the call succeed. Endpoint policies are always a subtractive layer relative to IAM — they can only further restrict, never expand.

DNS Integration — Private DNS, Route 53, and Per-Endpoint Aliases

AWS PrivateLink's DNS story is surprisingly subtle, and SAP-C02 tests it regularly. Three layers matter: Private DNS for AWS services, custom Private DNS names for customer services, and Route 53 alias records for endpoint-specific hostnames.

Private DNS for AWS Service Interface Endpoints

When you create an Interface Endpoint for an AWS service (say, com.amazonaws.us-east-1.secretsmanager) and check the Enable DNS name option, AWS creates a Route 53 Private Hosted Zone inside your VPC that overrides the service's public DNS. After that, calls to secretsmanager.us-east-1.amazonaws.com from inside the VPC resolve to the endpoint's private ENI IPs, without any code change in your application. This is the easiest path to "our app code already exists and we don't want to rewrite endpoint URLs."

Prerequisites for Private DNS override:

• The VPC must have enableDnsSupport and enableDnsHostnames set to true.
• The AWS service's endpoint must support Private DNS (most do; verify per service).
• Only one endpoint per service per VPC can have Private DNS enabled (otherwise duplicate zones conflict).

Private DNS for Customer-Published (AWS PrivateLink) Services

A producer that publishes a VPC Endpoint Service can configure a Private DNS name like api.example-saas.com. Before AWS accepts that DNS name, the producer must verify domain ownership via a TXT record in the domain's public DNS. Once verified, consumer VPCs that enable Private DNS on their Interface Endpoints will automatically resolve api.example-saas.com to the endpoint ENI IPs inside the consumer VPC.

This is the mechanism that turns AWS PrivateLink into a drop-in replacement for SaaS APIs — the consumer's existing code calling https://api.example-saas.com/v1/... just works, but traffic now flows over AWS PrivateLink instead of the public internet.

Per-Endpoint Route 53 Alias Records

Each Interface Endpoint also exposes per-endpoint regional DNS names such as:

• vpce-0abc123-xyz.secretsmanager.us-east-1.vpce.amazonaws.com (regional, load-balances across all AZ-local ENIs)
• vpce-0abc123-xyz-<az>.secretsmanager.us-east-1.vpce.amazonaws.com (zonal, pins to a specific AZ)

These names are always available regardless of whether Private DNS is enabled. You can:

• Create a Route 53 Alias from your custom name (internal-secrets.examhub.internal) to the endpoint's regional name for human-friendly resolution.
• Use the zonal names to keep traffic AZ-local (reduces cross-AZ data charges — a subtle SAP-C02 cost-optimization trick).
• Combine regional alias with health checks to route around a failed endpoint in a multi-region design.

Private DNS and Route 53 Resolver Forwarding from On-Premises

A frequent SAP-C02 scenario: an on-premises application needs to call an AWS service privately via Interface Endpoint. The path is:

1. On-prem → Direct Connect / VPN → reaches VPC.
2. On-prem DNS resolver forwards *.amazonaws.com queries to a Route 53 Resolver Inbound Endpoint in the VPC.
3. Inbound Endpoint resolves the query using the VPC's Private DNS → returns the Interface Endpoint ENI private IP.
4. On-prem traffic then flows to that private IP over Direct Connect, hits the Interface Endpoint, and reaches the AWS service over PrivateLink.

Without the Route 53 Resolver Inbound Endpoint, on-prem DNS returns the public AWS service IP and traffic bypasses your Interface Endpoint. This is a high-frequency exam trap on "why isn't my on-prem Lambda call going through the endpoint?"

Security Group Rules on Interface Endpoints — The Often-Forgotten Control

Every Interface Endpoint ENI has a security group attached. This SG controls which traffic is allowed to reach the endpoint ENI from within the consumer VPC.

The Default Behavior

By default, a new Interface Endpoint is attached to the default security group of the VPC, which permits all inbound traffic from resources sharing the default SG — an overly broad setting for production. Best practice:

1. Create a dedicated endpoint SG (e.g. sg-vpce-secretsmanager).
2. Allow inbound TCP 443 only from specific source SGs (your application tier's SG), not from the VPC CIDR.
3. Attach that dedicated SG to the endpoint during creation.

This ensures only authorized workloads can even attempt a connection to the endpoint. Combined with an endpoint policy (what can be called) and IAM (who can call), you get a three-layer defense.

Security Group Stateful Semantics Apply

Because Interface Endpoints use ENIs, they inherit the standard Security Group stateful behavior: allow inbound on 443, and responses are automatically permitted outbound. No NACL-style return-path rules required.

Cross-AZ Traffic and Security Group Cost Implications

If your application EC2 in AZ-a reaches an endpoint ENI in AZ-b, the traffic crosses AZs and incurs cross-AZ data transfer charges on top of the endpoint per-GB. For high-volume flows, either:

• Use the zonal DNS name (vpce-...-<az>...) to force same-AZ resolution.
• Or deploy the endpoint in every AZ that hosts consumer workloads, and let the regional DNS name AZ-affinity-hash the traffic.

Cross-Region and Cross-Account AWS PrivateLink

Cross-Account Endpoints

Cross-account is the common case: a producer account exposes an Endpoint Service, and consumers in other AWS accounts create Interface Endpoints pointing to that service's name. The producer controls access via the allowed principals list on the Endpoint Service; the consumer controls access via their endpoint policy and security group. Either side can revoke access unilaterally — the producer removes the consumer's principal ARN, or the consumer deletes the endpoint.

Cross-account AWS PrivateLink is the foundation of:

• AWS Marketplace SaaS: vendors publish Endpoint Services; buyers subscribe and receive endpoint connection rights.
• Enterprise shared services: one "platform team" account publishes observability, CI/CD, or security services; workload accounts consume them.
• AWS Organizations patterns: central security account exposes a SOAR or SIEM interface; every workload account connects to it via Interface Endpoint without wide-open cross-account IAM.

Cross-Region Endpoint Connections

Until 2024, AWS PrivateLink was strictly regional — consumer and producer had to live in the same AWS Region. The 2024 release of cross-region endpoint connections changed that: a consumer in us-east-1 can now create an Interface Endpoint that points to an Endpoint Service in eu-west-1. AWS handles the inter-region transport over the AWS backbone, charged at an inter-region PrivateLink rate.

Key SAP-C02 facts:

• Cross-region is opt-in per Endpoint Service (producer enables "Allow cross-region endpoints" and specifies allowed regions).
• Private DNS is not automatically extended cross-region — consumers use the regional endpoint DNS names.
• Cross-region AWS PrivateLink competes with Transit Gateway Inter-Region Peering: PrivateLink is service-scoped and cheaper for low-volume single-service flows; Transit Gateway is broader but more expensive to set up.
• Not every AWS service supports cross-region Interface Endpoints; customer-published Endpoint Services do.

Cross-Region Use Cases

• Multi-region SaaS with a single control plane: the control plane lives in one region; data-plane consumers in other regions call the control plane over cross-region PrivateLink.
• Disaster recovery for PrivateLink-consumed services: the consumer can fail over its endpoint to a DR region's Endpoint Service without re-architecting the application.
• Data sovereignty: a producer in a sovereign region exposes read-only APIs to cross-region consumers while keeping data at rest in the sovereign region.

AWS Marketplace and SaaS Delivery via AWS PrivateLink

AWS Marketplace integrates tightly with AWS PrivateLink for private SaaS delivery. When a Marketplace seller publishes a service backed by a VPC Endpoint Service, buyers can subscribe and receive automatic endpoint creation rights through AWS Marketplace's provisioning flow.

The Marketplace Flow

1. The seller builds a SaaS product in their own VPC, fronted by an NLB.
2. The seller publishes a VPC Endpoint Service with manual acceptance disabled for approved Marketplace buyers, or with automatic acceptance gated by Marketplace entitlement checks.
3. The buyer discovers the product in AWS Marketplace and subscribes.
4. Marketplace passes the buyer's AWS account ID to the seller's allowed principals list.
5. The buyer creates an Interface Endpoint in their VPC, pointing at the seller's service name.
6. Private DNS (if configured) lets the buyer's existing code call the seller's API at a stable hostname over AWS PrivateLink.

Why Marketplace + PrivateLink Wins

• No public internet egress for SaaS API calls — a major compliance win for regulated industries.
• No customer-specific VPC peering — the seller does not need to track every customer's CIDR and peer individually.
• Billing and entitlement tied to AWS Marketplace — the seller does not build a custom licensing layer.
• Customer lifecycle automation — subscription cancellation revokes the allowed principal, which terminates endpoint connectivity at the AWS PrivateLink layer.

On SAP-C02, when a scenario mentions "a third-party SaaS vendor in AWS Marketplace" combined with "private connectivity" or "no internet egress", the answer involves AWS PrivateLink-backed Marketplace Endpoint Services.

NLB as the Service Fronting the Endpoint Service

AWS PrivateLink requires the producer to front the service with a Network Load Balancer (NLB) or, for security-appliance chains, a Gateway Load Balancer (GWLB). No other load balancer type is supported as an Endpoint Service target.

Why NLB and Not ALB

• NLB operates at Layer 4 (TCP/UDP/TLS), which is exactly the layer PrivateLink terminates.
• NLB preserves source IP (for IP-preserved target groups), giving producers visibility into consumer origin when needed.
• NLB scales to millions of flows without pre-warming, matching PrivateLink's scale expectations.
• NLB supports cross-zone load balancing (optional, with cross-AZ data charges).

ALB is Layer 7 (HTTP/HTTPS) and, as of 2023, you can front an NLB with an ALB target group (NLB-with-ALB-target feature) to use HTTP features on the backend — but the PrivateLink-facing load balancer must still be the NLB.

Multi-AZ NLB and PrivateLink

The NLB behind an Endpoint Service should be multi-AZ for producer-side resilience. Each Interface Endpoint on the consumer side is also multi-AZ (one ENI per AZ you enable). For full end-to-end HA, enable the same AZs on both sides — if the consumer enables AZ-a and AZ-b but the NLB is only in AZ-c, the endpoint will fail to connect in AZ-a/b.

Target Types

• Instance targets (classic EC2 registration).
• IP targets (for ECS/EKS pods, on-premises servers over VPN/DX, or any ENI).
• ALB targets (L7 features behind L4 NLB).
• Lambda targets are not supported directly; to expose Lambda through AWS PrivateLink, front it with an API Gateway VPC Link (which is itself AWS PrivateLink under the hood) or run the function behind an ALB target group.

AWS PrivateLink vs VPC Peering vs Transit Gateway — The Professional Decision

The SAP-C02 exam consistently tests the three-way decision among AWS PrivateLink, VPC peering, and Transit Gateway. The right answer depends on CIDR overlap, service granularity, scale, and cost.

Decision Matrix

Decision Tree

1. Is this a single service (or small fixed set) being exposed? Yes → lean AWS PrivateLink.
2. Do the VPCs have overlapping CIDRs? Yes → AWS PrivateLink (peering and TGW fail without NAT).
3. Are there fewer than ~5 VPCs needing full bidirectional connectivity, no overlap? Yes → VPC peering.
4. Are there 5+ VPCs or hybrid (on-prem) connectivity with many services? Yes → Transit Gateway.
5. Is the consumer set unknown/large (SaaS to many customers)? → AWS PrivateLink (scales naturally).
6. Are you billing per service delivered? → AWS PrivateLink via Marketplace integration.
7. Do you need transitive routing across three or more VPCs? → Transit Gateway.

Cost at Scale

AWS PrivateLink's per-hour + per-GB model sounds small per endpoint but grows linearly with consumer count. A SaaS with 1,000 customer endpoints pays 1,000 × per-hour × AZ-count. At that scale, a Transit Gateway shared service model may actually beat PrivateLink on raw cost — but only if CIDR constraints allow. Many SAP-C02 questions hinge on this: if CIDRs overlap or the consumer set is truly multi-tenant external, pay the PrivateLink bill; it's the only design that works.

Common Misconceptions

• "PrivateLink is just a more secure peering" — wrong. It is service-scoped, unidirectional, and asymmetric.
• "Transit Gateway replaces PrivateLink" — wrong. TGW requires non-overlapping CIDRs; PrivateLink does not.
• "PrivateLink traffic is encrypted in transit" — AWS traffic on the backbone is not mandated encrypted at the network layer; rely on TLS at the application layer for confidentiality guarantees.

AWS PrivateLink Observability and Operations

VPC Flow Logs at the Endpoint

The Interface Endpoint's ENIs produce VPC Flow Logs like any other ENI. The log lines show traffic between the consumer's client IP and the endpoint ENI's IP, with the endpoint ID captured as metadata. Flow Logs do not show the far-side (producer VPC) activity — that is opaque by design, which is both a privacy feature and a debugging headache.

CloudWatch Metrics

AWS PrivateLink publishes CloudWatch metrics per endpoint:

• PacketsDropped: increments when a packet is rejected (common cause: no allowed principal, or endpoint policy deny).
• ActiveConnections: current concurrent connections.
• BytesProcessed: data-transfer volume (drives per-GB billing).
• RstPacketsReceived / RstPacketsSent: TCP reset diagnostics.

Producers also get Endpoint Service metrics showing NewConnectionCount and BytesProcessed per consumer connection, enabling per-tenant usage tracking for SaaS billing and capacity planning.

Connection Acceptance Workflow

When manual acceptance is enabled, producer-side CloudWatch Events fire on each PendingAcceptance connection. A typical automation:

1. EventBridge rule captures the PendingAcceptance event.
2. Lambda validates the requesting account ID against a whitelist (for example, an AWS Marketplace entitlement check).
3. Lambda calls AcceptVpcEndpointConnections to approve or RejectVpcEndpointConnections to deny.
4. Audit trail written to CloudTrail for compliance.

This pattern is a canonical SAP-C02 automation design for controlled SaaS onboarding.

AWS PrivateLink Limitations and Quotas to Remember

• Interface Endpoints per VPC: 50 (soft limit, raiseable).
• Endpoint Services per account per region: 20 (soft limit).
• Allowed principals per Endpoint Service: 100 (soft limit).
• Maximum concurrent connections per Endpoint: 55,000 per AZ (soft limit; scales with additional endpoints).
• Idle timeout: 350 seconds on Interface Endpoint; long-lived connections (databases, message queues) need TCP keepalives under 350s.
• No cross-VPC ICMP through PrivateLink — only TCP (and UDP via NLB UDP listeners).
• No multicast, no broadcast, no IPv6 on all services — verify per service.
• Gateway Endpoints are S3 and DynamoDB only — do not attempt to use Gateway Endpoint for anything else.
• Endpoint Service requires NLB or GWLB — ALB cannot front a VPC Endpoint Service directly.

Typical SAP-C02 Question Shapes for AWS PrivateLink

1. Overlap scenario: "Two acquired VPCs use 10.0.0.0/16. Expose the central logging service from VPC-A to VPC-B. Most operationally efficient?" → AWS PrivateLink (VPC Endpoint Service on VPC-A's NLB, Interface Endpoint in VPC-B).
2. Exfil-prevention scenario: "EC2 instances in a private subnet must access only two approved S3 buckets. How?" → Gateway Endpoint with bucket-scoped endpoint policy (and tighten IAM).
3. Hybrid access: "On-premises apps must call Secrets Manager without traversing the internet, over existing Direct Connect." → Interface Endpoint + Route 53 Resolver Inbound Endpoint + on-prem DNS forwarding.
4. SaaS vendor: "Third-party Marketplace vendor needs to expose API to 100 customer VPCs, no internet, CIDRs unknown." → VPC Endpoint Service (PrivateLink) with AWS Marketplace integration.
5. Cost scenario at scale: "1,500 VPCs all need the same shared service; they do not overlap; cost optimization is primary." → Transit Gateway shared service, not PrivateLink (scale tips the cost curve).
6. Cross-region: "Primary service in eu-west-1; consumers in us-east-1 and ap-southeast-1 need private access to just this one API." → Cross-region PrivateLink, not TGW inter-region peering.
7. DNS trap: "Private DNS on the endpoint works from EC2 in-VPC but not from on-prem." → Missing Route 53 Resolver Inbound Endpoint.
8. NLB-only trap: "ALB fronts the service; why can't I create an Endpoint Service?" → Endpoint Service requires NLB or GWLB; put NLB in front, or use ALB-as-target-of-NLB.
9. Endpoint policy default: "After enabling endpoint for S3, exfil to arbitrary buckets still works — why?" → Default endpoint policy is open; replace with bucket-scoped policy.
10. Cross-account onboarding automation: "Automate approving new customer endpoint connections." → EventBridge + Lambda + AcceptVpcEndpointConnections API.

AWS PrivateLink vs API Gateway VPC Link — A Related Distinction

Some SAP-C02 questions mix AWS PrivateLink with API Gateway's VPC Link feature. The relationship:

• API Gateway REST API with private VPC integration uses a VPC Link backed by AWS PrivateLink under the hood to reach an NLB in your VPC.
• API Gateway HTTP API private integration uses a similar VPC Link to an ALB or NLB.
• API Gateway Private REST APIs are themselves exposed via AWS PrivateLink Interface Endpoints so clients in other VPCs can call the API Gateway privately.

In other words, API Gateway consumes AWS PrivateLink in both directions. On the exam, if the scenario involves "private API Gateway" or "API Gateway calling a backend in a VPC without internet," AWS PrivateLink is the underlying mechanism whether the name appears or not.

Migration Patterns — From Peering to AWS PrivateLink

When to Migrate

• Scale of peerings has exceeded maintainability (N(N-1)/2 connections explodes past a few dozen VPCs).
• A new acquisition introduced overlapping CIDRs that cannot be re-IPed.
• Security review demands service-scoped exposure instead of whole-VPC peering.
• Compliance requires per-service audit logs (endpoint-level CloudTrail beats peering-level VPC Flow Logs for granularity).

Migration Steps

1. Inventory the services crossing each peering; for each service, identify the NLB-compatible front.
2. Stand up a VPC Endpoint Service in each producer VPC; attach NLB; set allowed principals.
3. On consumers, create Interface Endpoints with matching Private DNS names; run dual-stack (peering + endpoint) during cutover.
4. Shift application traffic to the endpoint hostname; monitor CloudWatch ActiveConnections on the endpoint and BytesTransferred on the peering.
5. Once peering-based traffic drops to zero, remove the peering.

This incremental approach is the SAP-C02-preferred pattern: no big-bang cutovers, explicit observability at each step, and reversible at any phase.

FAQ — AWS PrivateLink Top Questions for SAP-C02

Q1: When should I use AWS PrivateLink instead of VPC peering or Transit Gateway?

Use AWS PrivateLink when you need to expose a specific service (not a whole VPC) and one or more of these apply: the VPCs have overlapping CIDR ranges (peering and TGW fail), the consumer set is large or external (SaaS model), the access must be unidirectional (producer never initiates back), or you need fine-grained per-consumer revocation. Use VPC peering for small, static, bidirectional pairs with non-overlapping CIDRs. Use Transit Gateway when you have 5+ VPCs needing broad transitive routing with non-overlapping CIDRs or hybrid on-prem connectivity at scale.

Q2: What exactly is the difference between Gateway and Interface VPC Endpoints?

Gateway Endpoints exist only for S3 and DynamoDB, are free, work via route-table prefix list entries, are region-local, and are not reachable from on-premises. Interface Endpoints (the AWS PrivateLink product) work for hundreds of AWS services plus customer-published services, cost per hour per AZ plus per GB, work via ENIs with private IPs, are reachable from on-premises over Direct Connect or VPN, and support cross-account and cross-region. Default to Gateway Endpoint for in-VPC S3/DynamoDB cost savings; default to Interface Endpoint for everything else.

Q3: How does AWS PrivateLink solve the overlapping CIDR problem that peering cannot?

VPC peering and Transit Gateway are routing protocols — they forward IP packets between VPCs and therefore require non-overlapping CIDRs so the destination is unambiguous. AWS PrivateLink does not route: it terminates the TCP connection at an ENI in the consumer VPC, then originates a fresh connection from the producer side. The two VPC CIDRs are never compared or routed together, so overlap is irrelevant. This makes AWS PrivateLink a fully managed alternative to the 1:1 NAT solutions you would otherwise build on top of Transit Gateway.

Q4: Why do my on-premises servers still hit the public AWS service endpoint instead of my Interface Endpoint?

Because Private DNS on an Interface Endpoint only overrides DNS inside the VPC's Route 53 Private Hosted Zone. On-premises resolvers query the public DNS root, which returns the public service IP. To fix this, deploy a Route 53 Resolver Inbound Endpoint in the VPC, configure on-prem DNS to forward queries for *.amazonaws.com (or the specific service domains) to the Inbound Endpoint's IP addresses. The Inbound Endpoint resolves using the VPC's Private DNS, returns the endpoint's private ENI IPs, and on-prem traffic then flows correctly through the Interface Endpoint over Direct Connect or VPN.

Q5: How do I prevent data exfiltration through an S3 Gateway Endpoint?

Three layers stack together: first, apply an endpoint policy that restricts Resource to your organization's bucket ARNs (or to specific aws:PrincipalOrgID conditions); second, apply IAM policies on the principals that further narrow actions and buckets; third, apply S3 bucket policies that require aws:SourceVpce match your endpoint ID. Remember that the default endpoint policy is wide open — you must explicitly replace it. Pair this with VPC Flow Logs on the endpoint ENIs (Interface) or the subnet (Gateway) for audit evidence.

Q6: Can I use AWS PrivateLink to expose a Lambda function to another VPC?

Not directly — VPC Endpoint Services require an NLB or GWLB as the front. To expose Lambda via AWS PrivateLink, two patterns work: (a) front the Lambda with API Gateway Private REST API, which is already exposed via PrivateLink Interface Endpoint natively; or (b) put the Lambda behind an ALB target group, put the ALB as an NLB target (the NLB-with-ALB-target feature), then create a VPC Endpoint Service on the NLB. Option (a) is the cleaner answer on most SAP-C02 questions.

Q7: What happens to existing consumer connections when a producer revokes an allowed principal?

Revoking the principal prevents new endpoint connections but does not immediately terminate existing ones. Current TCP connections continue until they idle out (350 seconds default) or until the producer explicitly calls RejectVpcEndpointConnections on the active connection. For compliance-driven immediate revocation, combine principal removal with active-connection rejection and, ideally, security group tightening on the NLB target group to drop existing flows at the transport layer.

Q8: Is AWS PrivateLink traffic encrypted automatically?

AWS PrivateLink transports traffic over the AWS global backbone, which AWS describes as a private, physically isolated network. However, AWS does not promise wire-level encryption at the PrivateLink layer the way it does with TLS. For strong confidentiality guarantees, run TLS at the application layer end-to-end (consumer → NLB → backend target). Most AWS service endpoints already require TLS, so this is automatic for AWS service Interface Endpoints; for customer-published services, enforce TLS on the NLB listener or the backend target.

Q9: How do I minimize cross-AZ data transfer charges with AWS PrivateLink?

Two techniques. First, create the endpoint's ENI in every AZ where consumer workloads run and let the regional DNS name AZ-affinity-hash traffic to same-AZ ENIs. Second, in code or client configuration, use the zonal DNS names (vpce-xxx-<az>.service.region.vpce.amazonaws.com) to force same-AZ targeting. On the producer side, enable NLB cross-zone load balancing off by default (it is off by default for NLB) so NLB targets stay AZ-local. At high volume these patterns shave meaningful cost off the per-GB bill.

Further Reading for AWS PrivateLink on SAP-C02

• AWS PrivateLink User Guide (complete)
• AWS Well-Architected Framework — Security Pillar (network protection)
• AWS Whitepaper: Building a Scalable and Secure Multi-VPC AWS Network Infrastructure
• AWS re:Invent NET-series sessions on PrivateLink scale patterns (search "NET301", "NET305", "NET405")
• Amazon VPC Peering vs Transit Gateway vs PrivateLink decision whitepapers
• AWS Marketplace Seller Guide — SaaS delivery via AWS PrivateLink

Master AWS PrivateLink as a first-class architectural tool — not a footnote under Amazon VPC — and the Professional-tier questions on overlapping CIDR, SaaS exposure, private AWS service access, and cross-account service sharing become some of the most predictable points on SAP-C02. The repeated patterns are: AWS PrivateLink for service-scoped exposure, AWS PrivateLink for overlapping CIDR, Interface Endpoint + Route 53 Resolver Inbound Endpoint for hybrid DNS, and endpoint policies for exfil prevention. Internalize those four, pair them with the NLB-only requirement and the manual-acceptance automation pattern, and AWS PrivateLink becomes a reliable scoring zone on exam day.