8.2 PrivateLink VPC Endpoints & Network Isolation

8.2 PrivateLink VPC Endpoints & Network Isolation

This independent study guide by OpenExamPrep helps candidates prepare for the AWS Certified Generative AI Developer - Professional (AIP-C01) examination. Highly regulated industries—including banking, healthcare, defense, and government—mandate that proprietary data, personally identifiable information (PII), and intellectual property must never traverse the public internet. When enterprise applications invoke foundation models, submit prompts containing confidential customer records, or perform vector embeddings over proprietary document corpora, network traffic must remain strictly confined within private network boundaries.

AWS PrivateLink enables private connectivity between Amazon Virtual Private Clouds (VPCs) and supported AWS services without requiring an Internet Gateway (IGW), NAT Gateway, Network Address Translation (NAT) instances, or AWS Direct Connect public virtual interfaces. Understanding how to configure, secure, and troubleshoot PrivateLink endpoints for Amazon Bedrock and its vector storage dependencies is a core domain on the AIP-C01 examination.

---

Architecture of AWS PrivateLink for Amazon Bedrock

When you provision an interface VPC endpoint for Amazon Bedrock, AWS creates Elastic Network Interfaces (ENIs) with private IP addresses in the private subnets of your VPC. Traffic destined for Bedrock is routed directly across the AWS private network backbone to the Bedrock service infrastructure.

┌────────────────────────────────────────────────────────┐
│ Amazon VPC (10.0.0.0/16) - Private Subnet (10.0.1.0/24)│
│                                                        │
│  ┌───────────────────────┐                             │
│  │ EC2 / ECS / Lambda    │                             │
│  │ App Microservice      │                             │
│  └──────────┬────────────┘                             │
│             │ HTTPS (443)                              │
│             ▼                                          │
│  ┌───────────────────────┐                             │
│  │ Interface VPC ENI     │ (Private IP: 10.0.1.50)     │
│  │ (bedrock-runtime)     │                             │
│  └──────────┬────────────┘                             │
└─────────────┼──────────────────────────────────────────┘
              │ AWS Private Backbone Network (Zero Public Internet)
              ▼
┌────────────────────────────────────────────────────────┐
│ Amazon Bedrock Service Infrastructure                  │
│  - Anthropic Claude / Amazon Nova Foundation Models    │
└────────────────────────────────────────────────────────┘

The Three Critical Service Names

Amazon Bedrock separates its service architecture into distinct VPC endpoint service names. Configuring the wrong service name is one of the most common causes of network failure:

[!IMPORTANT] If an application in a private subnet needs to execute bedrock.invoke_model(), provisioning an interface endpoint for com.amazonaws.{region}.bedrock will not work. The invocation will fail with a connection timeout because invoke_model() targets the data plane endpoint (bedrock-runtime), which requires com.amazonaws.{region}.bedrock-runtime.

---

Private DNS Resolution Mechanics

When creating an interface VPC endpoint, enabling Private DNS (PrivateDnsEnabled: true) is essential.

• Without Private DNS: The application must be explicitly configured to send API requests to the unique, long VPC endpoint DNS hostname (e.g., vpce-0123456789abcdef0-us-east-1a.bedrock-runtime.us-east-1.vpce.amazonaws.com). This requires custom code modifications and breaks standard SDK defaults.
• With Private DNS: AWS creates a private hosted zone in Amazon Route 53 that resolves the standard public service DNS hostname (bedrock-runtime.us-east-1.amazonaws.com) directly to the private IP addresses of the interface endpoint ENIs within your VPC. Applications can use standard AWS SDK clients without changing endpoint URLs, and traffic automatically routes over PrivateLink.

Prerequisites for Private DNS:

1. The VPC must have both enableDnsHostnames and enableDnsSupport set to true.
2. Security groups attached to the interface endpoint ENIs must permit inbound HTTPS (port 443) traffic from the private subnets hosting application compute.
3. Security groups attached to the application compute must permit outbound HTTPS (port 443) traffic to the VPC endpoint security group or subnet CIDR.

---

VPC Endpoint Security Policies: Perimeter Defense

An interface VPC endpoint allows attaching a VPC Endpoint Policy. An endpoint policy is an IAM resource policy attached directly to the endpoint. It does not replace identity-based policies, but rather acts as a perimeter filter: requests passing through the endpoint are denied unless both the caller's IAM policy AND the endpoint policy permit the action.

Use Case: Restricting Allowed Accounts and Models

Security compliance often dictates that corporate compute inside a private VPC must only access models within the corporate AWS account and must never invoke unapproved third-party or experimental models.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "RestrictVpcBedrockAccess",
      "Effect": "Allow",
      "Principal": "*",
      "Action": [
        "bedrock:InvokeModel",
        "bedrock:InvokeModelWithResponseStream"
      ],
      "Resource": [
        "arn:aws:bedrock:us-east-1::foundation-model/anthropic.claude-3-5-sonnet-20240620-v1:0",
        "arn:aws:bedrock:us-east-1::foundation-model/amazon.nova-pro-v1:0",
        "arn:aws:bedrock:us-east-1:123456789012:provisioned-model/*"
      ],
      "Condition": {
        "StringEquals": {
          "aws:PrincipalAccount": "123456789012"
        }
      }
    }
  ]
}

What this policy enforces:

• Prevent Exfiltration to External Accounts: If a rogue employee attempts to use their own AWS credentials from inside an EC2 instance in this VPC to invoke models in their personal account, the aws:PrincipalAccount condition blocks the request.
• Prevent Use of Unapproved Models: Calls to unapproved models (e.g., unauthorized open-source weights or external experimental models) are blocked at the network perimeter.

---

Securing Bedrock Knowledge Bases Vector Infrastructure

A production RAG system involves more than foundation models; it connects to Amazon OpenSearch Serverless (AOSS) vector collections and Amazon S3 document buckets. Full network isolation requires securing this supporting infrastructure.

OpenSearch Serverless Network Policies

Amazon OpenSearch Serverless manages network accessibility through Network Policies. An AOSS collection can be configured in two modes:

1. Public: Accessible from the internet (subject to IAM data access policies).
2. VPC: Accessible exclusively through designated interface VPC endpoints.

To isolate an OpenSearch Serverless vector collection:

1. Provision an interface VPC endpoint for the AOSS service: com.amazonaws.{region}.aoss.
2. Create an OpenSearch Serverless Network Policy of type vpc referencing the VPC endpoint ID:

[
  {
    "Rules": [
      {
        "Resource": ["collection/enterprise-knowledge-base"],
        "ResourceType": "collection"
      },
      {
        "Resource": ["collection/enterprise-knowledge-base"],
        "ResourceType": "dashboard"
      }
    ],
    "AllowFromPublic": false,
    "SourceVPCEs": ["vpce-0123456789abcdef0"]
  }
]

1. Attach an AOSS Data Access Policy granting the Bedrock Knowledge Base service execution role permissions (aoss:CreateCollectionItems, aoss:UpdateCollectionItems, aoss:DescribeCollectionItems, aoss:APIAccessAll) on the collection and its indexes.

S3 Data Source Network Isolation

To ensure raw documents stored in Amazon S3 are accessed privately:

• Provision an S3 VPC Gateway Endpoint in the VPC.
• Configure the S3 bucket policy to deny any traffic that does not originate from the VPC Gateway Endpoint using the aws:sourceVpce condition key, while allowing the Bedrock service principal (bedrock.amazonaws.com) to read objects during knowledge base synchronization.

---

Common Exam Traps & High-Stakes Scenarios

• Trap: Provisioning only com.amazonaws.{region}.bedrock for Inference. Candidates frequently confuse the management endpoint with the runtime endpoint. When a scenario mentions Lambda functions or ECS tasks in private subnets invoking models, the required service name is com.amazonaws.{region}.bedrock-runtime.
• Trap: Forgetting the Agent Runtime Endpoint. If an application invokes an Amazon Bedrock Agent via bedrock-agent-runtime:InvokeAgent, the bedrock-runtime endpoint is insufficient. The architecture must provision an interface endpoint for com.amazonaws.{region}.bedrock-agent-runtime.
• Trap: Missing Inbound Security Group Rules on Endpoint ENIs. An interface endpoint creates ENIs inside your private subnets. The security group attached to these ENIs must have an inbound rule allowing TCP port 443 (HTTPS) from the security group or CIDR block of the application compute instances. Without this rule, requests hang and timeout.
• Trap: Modifying AOSS Network Policies Post-Creation. When creating an OpenSearch Serverless collection, the encryption policy must exist before collection creation, and network policies must bind the VPC endpoint appropriately. Failing to bind the VPC endpoint before ingestion results in connectivity failures.