Your most sensitive data—patient records, financial data, classified documents—lives in a private Amazon Virtual Private Cloud (Amazon VPC) with no internet access, and for good reason. That network isolation is a deliberate security posture, not an oversight. The problem is that your AI agents need to reason over that data, and traditional networking approaches force you to choose between connectivity and isolation.

In this post, you learn how to use Amazon VPC Lattice to connect your AI agents to isolated data with zero trust connectivity. Zero trust means every request is verified regardless of network location. You configure VPC Lattice to authenticate and authorize every request before it reaches your data, so agents can access isolated VPCs without breaking network isolation. Beyond connectivity, VPC Lattice enforces which HTTP methods an agent can use at the network layer. VPC Lattice can restrict a read-only agent to GET requests, blocking POST, PUT, and DELETE before requests reach the backend, regardless of what the agent’s code attempts. This walkthrough uses a healthcare example: a clinical AI assistant built with Strands Agents and Amazon Bedrock. The agent queries an Electronic Health Record (EHR) Fast Healthcare Interoperability Resources (FHIR) API in a private VPC. This pattern applies to financial services, government, and many other regulated industries.

Note: The architecture and implementation described in this post are illustrative. They demonstrate how to apply VPC Lattice capabilities to a representative use case and have not been validated in a production clinical environment. Before deploying in production, conduct your own security review and validation appropriate to your regulatory and compliance requirements.

The challenge: AI agents and isolated data

Consider a healthcare system with the following architecture:

• Account A (AI Workloads): Hosts the clinical AI agent on Amazon Elastic Kubernetes Service (Amazon EKS), with internet access for invoking Amazon Bedrock foundation models. A Model Context Protocol (MCP) server in this account wraps clinical data queries as tools the agent can call.
• Account B (Clinical Data): Contains the EHR system’s FHIR API backed by an Amazon Aurora PostgreSQL-Compatible Edition database. This VPC has no internet gateway, no Network Address Translation (NAT) gateway, and no public subnets—by design.

The AI agent must query patient records, retrieve lab results, and search clinical notes to answer physician questions. But the data VPC is intentionally unreachable from the internet. Traditional approaches to bridge this gap introduce complexity and risk:

• VPC peering makes the entire network accessible to the peer, violating least-privilege principles.
• AWS Transit Gateway requires additional routing configuration and doesn’t provide application-layer authentication.
• AWS PrivateLink follows a one-to-one model—each consumer VPC requires its own endpoint per provider service, which quickly becomes unmanageable as the number of data sources grows. VPC Lattice supports a one-to-many and many-to-many model: one service network connects many consumers across accounts and VPCs with no per-consumer configuration required. The default quota supports up to 500 VPC associations per service network, adjustable through Service Quotas.

The architecture requires a solution that connects these accounts securely, authenticates every request at the application layer, and maintains a full audit trail—without modifying the data VPC’s isolation posture.

Overview of the solution

With Amazon VPC Lattice, you connect services across VPCs and AWS accounts without IP-based routing. Instead of managing routes, security groups, and peering connections, you define logical services and VPC Lattice handles connectivity, authentication, and encryption.

The following figure shows the architecture for this solution.

Figure 1: Clinical AI agent accessing isolated EHR data through VPC Lattice

Figure 1 illustrates the following data flow:

1. Physician query: A physician asks the clinical AI assistant a question about a patient.
2. Foundation model reasoning: The Strands Agents agent invokes Amazon Bedrock through a VPC endpoint using AWS PrivateLink to reason about the query and determine which clinical data it requires.
3. MCP tool call: The agent calls the FHIR MCP server, which runs as a pod in the same Amazon EKS cluster.
4. Signed request: The MCP server signs the outgoing HTTPS request using AWS Signature Version 4 (SigV4) with the pod’s IAM role credentials. The server then sends the signed request to the VPC Lattice service endpoint.
5. VPC Lattice routing: VPC Lattice validates the SigV4 signature against the auth policy and encrypts traffic with TLS. It then routes the authenticated request to the FHIR API target in Account B.
6. Audit and response: The FHIR API returns patient data. VPC Lattice Access Logs capture the full interaction—source principal, timestamp, HTTP status, and bytes transferred. The logs deliver to Amazon CloudWatch Logs or Amazon S3 for HIPAA audit retention. For details on available log fields, see VPC Lattice access log contents.
7. Clinical answer: The agent synthesizes the clinical data into a response for the physician.

How VPC Lattice differs from AWS PrivateLink

You might ask: Amazon Bedrock already uses PrivateLink for private connectivity—why not use PrivateLink for the EHR data too? These services solve different problems:

• PrivateLink (VPC endpoints): Connects your VPC to a service endpoint privately. While commonly used to access AWS-managed services such as Amazon Bedrock, Amazon S3, or Amazon DynamoDB, you can also publish your own services through PrivateLink. However, you must place each custom service behind a Network Load Balancer—adding infrastructure overhead, cost, and re-architecture effort for every service you want to expose.
• VPC Lattice: Connects your services to each other across VPCs and accounts. It provides IAM-based authentication, automatic TLS, service discovery by name, and centralized access policies—without requiring you to deploy network load balancers or manage endpoint services for each data source.

In this architecture, PrivateLink handles agent-to-Amazon Bedrock. VPC Lattice handles agent-to-your-data. Together they create a private AI architecture with no public routing dependencies.

How VPC Lattice helps you secure this architecture

Zero trust authentication with IAM

You attach auth policies to services and service networks. Every request from the MCP server to the FHIR API must present valid IAM credentials. The auth policy specifies exactly which principal—the MCP server’s EKS pod IAM role—can invoke the service. Network location is irrelevant: even if traffic can reach the service, your auth policy blocks it without a matching Effect: Allow statement. This helps you meet HIPAA requirements to demonstrate that only authorized systems access protected health information (PHI).

Automatic TLS encryption

When you use VPC Lattice-generated domain names, VPC Lattice provisions TLS certificates and helps encrypt traffic between services. This frees you from certificate lifecycle management and key rotations. For custom domain names, you provide your own certificate through AWS Certificate Manager (ACM).

Cross-account sharing with AWS Resource Access Manager (AWS RAM)

Use AWS Resource Access Manager (AWS RAM) to share the FHIR API service in Account B to Account A. Account A’s VPC then associates with the service network. The MCP server immediately discovers and calls the FHIR API by its assigned service DNS name—no peering, no route table changes, no modifications to Account B’s isolated VPC.

Comprehensive audit logging

When configured, VPC Lattice access logs capture detailed information about each request: source principal, destination service, timestamp, response code, and bytes transferred. You send these logs to Amazon CloudWatch Logs or Amazon Simple Storage Service (Amazon S3) for retention. This helps support your HIPAA compliance efforts by providing the access audit trail required for systems handling PHI, removing the need to build custom logging infrastructure.

Preserving network isolation

The EHR VPC in Account B retains its isolated posture—no internet-facing routes of any kind. VPC Lattice connectivity doesn’t require internet-facing routes. The VPC associates with the service network and registers its FHIR API as a target—the isolation boundary remains intact.

Implementation walkthrough

The following steps walk you through configuring VPC Lattice for multi-account agent connectivity.

Prerequisites

Before beginning, confirm the following prerequisites are in place:

• Two AWS accounts: Account A for AI workloads, Account B for clinical data
• An Amazon EKS cluster in Account A with the AWS Gateway API Controller installed
• A FHIR API deployed in Account B’s private VPC
• Account A—IAM permissions to install the AWS Gateway API Controller on EKS, create a VPC Lattice service network, and configure pod identity or IAM Roles for Service Accounts (IRSA) for the Strands Agents pod
• Account B—IAM permissions to create VPC Lattice services and target groups, configure auth policies, and create AWS Resource Access Manager (AWS RAM) shares
• AWS Command Line Interface (AWS CLI) configured with credentials for both accounts
• Python 3.9 or later with Strands Agents installed (pip install strands-agents)

Step 1. Create the service network and register the FHIR API service

In Account B, create the VPC Lattice service network and register the FHIR API as a service within that network. This establishes the foundation for connectivity between accounts. Each sub-task below configures a specific component. Complete them in order. Set --auth-type AWS_IAM on all resources; the default type is NONE, which passes traffic unauthenticated and bypasses the access controls protecting PHI.

Step 1.1. Create the service network with IAM auth

# Account B — create the service network with IAM auth required
aws vpc-lattice create-service-network \
  --name clinical-data-network \
  --auth-type AWS_IAM

Step 1.2. Register the FHIR API service

# Register the FHIR API service with IAM auth required
aws vpc-lattice create-service \
  --name fhir-api \
  --auth-type AWS_IAM

Step 1.3. Create the target group

# Create a target group pointing to your FHIR API IP targets (port 443)
aws vpc-lattice create-target-group \
  --name fhir-targets \
  --type IP \
  --config '{"port":443,"protocol":"HTTPS","vpcIdentifier":"<account-b-vpc-id>"}'

Step 1.4. Create the HTTPS listener

# Create an HTTPS listener on the service
aws vpc-lattice create-listener \
  --service-identifier <fhir-service-id> \
  --name fhir-https \
  --protocol HTTPS \
  --port 443 \
  --default-action '{"forward":{"targetGroups":[{"targetGroupIdentifier":"<target-group-id>"}]}}'

# Associate the service with the service network
aws vpc-lattice create-service-network-service-association \
  --service-network-identifier <service-network-id> \
  --service-identifier <fhir-service-id>

Step 1.6. Associate Account B’s VPC with the service network

# Associate Account B's VPC with the service network
aws vpc-lattice create-service-network-vpc-association \
  --service-network-identifier <service-network-id> \
  --vpc-identifier <account-b-vpc-id>

Step 2. Configure security groups for VPC Lattice traffic

VPC Lattice delivers traffic to your target from its link-local address range (169.254.0.0/16, reserved for use within a single network segment). The FHIR API’s security group in Account B must permit inbound HTTPS from this range. Without this rule, VPC Lattice health checks fail and no traffic reaches the FHIR API, even with a correctly configured auth policy. AWS recommends referencing the VPC Lattice managed prefix lists in your security group rules rather than hardcoding the CIDR range. AWS maintains these prefix lists and keeps them current automatically.

# Allow inbound HTTPS from the VPC Lattice link-local range (169.254.171.0/24)
aws ec2 authorize-security-group-ingress \
  --group-id <fhir-api-security-group-id> \
  --protocol tcp \
  --port 443 \
  --cidr 169.254.171.0/24

Step 3. Apply auth policies

The following auth policy restricts the clinical AI agent to read-only access on FHIR patient and observation resources. Scope the Deny statement to the specific MCP server role to avoid inadvertently blocking other services on the same service network:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::111122223333:role/FhirMcpServerRole"
      },
      "Action": "vpc-lattice-svcs:Invoke",
      "Resource": "arn:aws:vpc-lattice:us-east-1:123456789012:service/svc-0a1b2c3d4e5f6g7h8",
      "Condition": {
        "StringEquals": { "vpc-lattice-svcs:RequestMethod": "GET" },
        "StringLike": {
          "vpc-lattice-svcs:RequestPath": ["/Patient/*", "/Observation/*"]
        }
      }
    },
    {
      "Effect": "Deny",
      "Principal": {
        "AWS": "arn:aws:iam::123456789012:role/FhirMcpServerRole"
      },
      "Action": "vpc-lattice-svcs:Invoke",
      "Resource": "arn:aws:vpc-lattice:us-east-1:123456789012:service/svc-0a1b2c3d4e5f6g7h8",
      "Condition": {
        "StringEquals": {
          "vpc-lattice-svcs:RequestMethod": ["POST", "PUT", "DELETE"]
        }
      }
    }
  ]
}

Apply the policy to the service:

aws vpc-lattice put-auth-policy \
  --resource-identifier <fhir-service-id> \
  --policy file://fhir-auth-policy.json

A separate clinical documentation agent that writes lab results uses a different policy scoped to POST on a single resource type. This demonstrates graduated access controls: the query agent reads, the documentation agent writes, and neither exceeds its designated scope.

Step 4. Share the service network and associate the consumer VPC

After configuring the service network and auth policies in Account B, share the service network to Account A. Then associate the consumer VPC. Account A’s AI workload can immediately discover and connect to the FHIR API service over a private, authenticated path—no public routes required. AWS RAM supports multi-account resource sharing. It removes the need for VPC peering and complex routing changes. The consumer VPC association establishes the routing path—VPC Lattice routes requests from Account A’s subnets to the registered FHIR service. Traffic flows over the AWS backbone and remains encrypted in transit. Complete sub-tasks 4.1 and 4.2 in order before testing end-to-end connectivity.

Step 4.1. Share the service network to Account A

In Account B, share the service network to Account A using AWS RAM:

aws ram create-resource-share \
  --name clinical-data-network-share \
  --resource-arns <service-network-arn> \
  --principals <account-a-id>

If your accounts are in the same AWS Organizations unit, AWS RAM accepts the share automatically. Otherwise, Account A must accept the AWS RAM invitation before proceeding.

Step 4.2. Associate the consumer VPC

In Account A, associate the AI workload VPC with the shared service network:

aws vpc-lattice create-service-network-vpc-association \
  --service-network-identifier <service-network-id> \
  --vpc-identifier <account-a-vpc-id>

After the association is complete, the MCP server resolves the FHIR API by its service DNS name. Make sure the VPC in Account A has DNS support and DNS hostnames active. These are on by default in new VPCs but are required for the Lattice DNS name to resolve correctly.

Step 5. Configure SigV4 signing and deploy the Strands agent

Sign every request to a VPC Lattice service with AWS_IAM auth using Signature Version 4 with service name vpc-lattice-svcs. The following Strands Agents implementation adds SigV4 signing to the FHIR MCP client using the pod’s IAM Roles for Service Accounts (IRSA)-provided credentials. EKS Pod Identity is the newer, recommended alternative to IRSA and works identically from the application’s perspective.

import boto3
import os
from botocore.auth import SigV4Auth
from botocore.awsrequest import AWSRequest
from strands import Agent
from strands.models import BedrockModel
from mcp.client.streamable_http import streamablehttp_client
from strands.tools.mcp.mcp_client import MCPClient

FHIR_LATTICE_URL = os.environ[["FHIR_LATTICE_URL"]]   # VPC Lattice-generated FQDN
AWS_REGION       = os.environ.get("AWS_REGION", "us-east-1")

def _signed_headers() -> dict:
    """Build SigV4-signed headers for vpc-lattice-svcs using pod IAM credentials."""
    session     = boto3.Session()
    credentials = session.get_credentials().get_frozen_credentials()
    req = AWSRequest(method="GET", url=FHIR_LATTICE_URL,
                     headers={"Accept": "application/fhir+json"})
    SigV4Auth(credentials, "vpc-lattice-svcs", AWS_REGION).add_auth(req)
    return dict(req.headers)

def create_transport():
    return streamablehttp_client(FHIR_LATTICE_URL, headers=_signed_headers())

fhir_client = MCPClient(create_transport)

clinical_agent = Agent(
    model=BedrockModel(model_id="amazon.nova-pro-v1:0"),
    tools=fhir_client.list_tools_sync(),
    system_prompt=(
        "You are a clinical AI assistant. Query patient data to help physicians. "
        "Never create, modify, or delete records."
    ),
)

# Example invocation
if __name__ == "__main__":
    with fhir_client:
        response = clinical_agent("Summarize recent lab results for patient MRN-00847.")
        print(response)

The AWS Gateway API Controller on the EKS cluster registers the MCP server pod’s Kubernetes service account with IRSA, so boto3.Session() automatically resolves the FhirMcpServerRole credentials—no additional configuration needed in the application code.

Note: For long-running agent processes, ensure your application refreshes SigV4 credentials before they expire. IRSA and EKS Pod Identity credentials obtained through the pod’s projected service account token are temporary (typically valid for 1–12 hours depending on your configuration). The boto3 SDK handles credential refresh automatically when you call get_credentials() before each request, as shown in the _signed_headers() function above. Avoid caching credentials across requests—instead, retrieve fresh credentials for each signing operation to prevent authorization failures during extended agent sessions.

Step 6. Verify the setup

After completing Step 5, confirm the setup is working before integrating with your application. Run the following commands from Account A.

• Verify the VPC association status is ACTIVE:

aws vpc-lattice get-service-network-vpc-association \
  --service-network-vpc-association-identifier <association-id>

nslookup <fhir-lattice-dns-name>

• Send a signed test request to confirm end-to-end connectivity (expect 200; a 403 indicates a missing or incorrect SigV4 signature; a 503 indicates no healthy targets):

• # Use temporary credentials from AWS Security Token Service (AWS STS) (avoids long-term access keys)
  read -r KEY SECRET TOKEN <<< $(aws sts get-session-token \
    --query 'Credentials.[[AccessKeyId,SecretAccessKey,SessionToken]]' \
    --output text)
  curl -v https://<fhir-lattice-dns-name>/Patient/123 \
    --aws-sigv4 "aws:amz:us-east-1:vpc-lattice-svcs" \
    --user "$KEY:$SECRET" \
    -H "x-amz-security-token: $TOKEN"

Cleanup

Warning: These steps immediately terminate connectivity between Account A and the FHIR API in Account B. Confirm that no production workloads depend on this connectivity before proceeding.

To avoid ongoing charges, remove resources in the following order after testing:

1. In Account A, delete the VPC-to-service-network association:
   aws vpc-lattice delete-service-network-vpc-association --service-network-vpc-association-identifier <account-a-association-id>
2. In Account B, delete the VPC-to-service-network association:
   aws vpc-lattice delete-service-network-vpc-association --service-network-vpc-association-identifier <account-b-association-id>
3. In Account B, delete the AWS RAM resource share to revoke Account A’s access:
   aws ram delete-resource-share --resource-share-arn <resource-share-arn>
4. Delete the HTTPS listener from the FHIR service. (Deleting the service in the following step removes associated listeners automatically, but AWS recommends explicit deletion.)
5. Delete the auth policy from the FHIR service:
   aws vpc-lattice delete-auth-policy --resource-identifier <fhir-service-id>
6. Delete the service-network-service association.
7. Delete the VPC Lattice service.
8. Delete the target group.
9. Delete the service network.
10. Remove the inbound security group rule permitting traffic from 169.254.171.0/24 on port 443.
11. Delete the FHIR MCP Server pod and associated Kubernetes resources in Account A:
    kubectl delete deployment fhir-mcp-server -n <namespace>
12. Delete the Amazon EKS cluster in Account A if it was created for this walkthrough:
    aws eks delete-cluster --name <cluster-name>
13. Delete the FHIR API in Account B (steps depend on your FHIR API implementation and deployment method).
    1. Warning: This action permanently deletes all data in the Aurora PostgreSQL database. Delete the Amazon Relational Database Service (Amazon RDS) cluster in Account B:
       aws rds delete-db-cluster --db-cluster-identifier <cluster-id> --final-db-snapshot-identifier <snapshot-name> (or use --skip-final-snapshot if you do not need to retain the data).

Further considerations

• Amazon Bedrock AgentCore Gateway (generally available) connects to private FHIR APIs using VPC Lattice resource gateways without you deploying a custom MCP server. This provides the same zero trust connectivity with less operational overhead for teams that don’t require a custom agent runtime.
• VPC Lattice is a HIPAA Eligible Service. Before processing PHI, confirm your organization has an active Business Associate Agreement (BAA) with AWS. The technical controls in this post complement, but don’t replace, the BAA requirement.
• VPC Lattice is a Regional service. For disaster recovery, replicate the service network and FHIR API targets in a secondary Region and use Amazon Route 53 health checks to fail over the agent’s traffic.
• Use IAM condition keys such as resource tags in auth policies to restrict agent access based on data sensitivity. For example, you can permit queries on de-identified data broadly while limiting access to identified PHI to specific roles

Conclusion

Amazon VPC Lattice lets you connect AI agents to your most sensitive data without compromising the network isolation you’ve spent years building. In this post, you saw how a clinical AI agent securely queries a FHIR API in a private VPC — using Strands Agents (open source) and Amazon Bedrock — with no public exposure and no changes to the data account’s security posture.

With VPC Lattice handling zero-trust authentication, automatic TLS encryption, cross-account service sharing via AWS RAM, and access logging to Amazon CloudWatch Logs, your security and networking teams get the controls they need while your AI teams get the connectivity they need — without opening tickets, punching holes in firewalls, or standing up new infrastructure. The result: you can move faster on AI initiatives without re-litigating your network security decisions.

Further reading

• Amazon VPC Lattice User Guide
• Control access to VPC Lattice services using auth policies
• Authenticating requests with AWS Signature Version 4 for VPC Lattice
• Amazon Bedrock AgentCore Gateway documentation
• Strands Agents (open source)
• AWS Gateway API Controller for Amazon EKS
• Share your VPC Lattice entities with AWS RAM

About the authors