Book a discovery call

Secure AWS Bedrock Agents With PrivateLink: Implementation Patterns and Best Practices

By Kelvin Kok11 min read

As organizations move generative AI into production through AWS Bedrock Agents, private connectivity stops being a nice-to-have and becomes a precondition for deployment. AWS PrivateLink establishes private connections between your VPCs and AWS services without exposing traffic to the public internet. Choosing the right architecture pattern for a given use case, however, takes planning: the pattern that suits a single development account is rarely the one that suits a regulated, multi-account estate.

This guide covers four implementation patterns we see in practice, the security controls that should sit alongside each of them, and the failure modes that tend to surface once traffic is real. Whether you are embedding agents into an existing application or building a new automation layer, these patterns give you a secure foundation without forcing you to rebuild your network.

Before working through the patterns, it is worth being precise about the two technologies involved.

AWS PrivateLink is a network service that lets you reach AWS services and partner services privately from your Virtual Private Cloud, without public IP addresses and without traffic traversing the public internet. It creates interface endpoints inside your VPC, each backed by an elastic network interface in your own subnets, and connectivity to the service runs over the AWS network backbone.

AWS Bedrock Agents are assistants built on foundation models that can be configured to perform specific tasks and actions. They can read from your data sources, reason over that information, and invoke APIs on your behalf through action groups. That last capability is the reason network posture matters so much: an agent is not only a consumer of prompts, it is an actor inside your environment.

Combined, PrivateLink and Bedrock Agents let you keep model invocation and agent orchestration traffic on private paths, which is usually what a data protection review is actually asking for.

Putting Bedrock Agents behind PrivateLink gives you several concrete benefits.

  • Reduced exposure: keeping traffic on the AWS network backbone rather than the public internet narrows the attack surface and removes a class of interception and misrouting risks.
  • Simpler network architecture: you avoid the NAT gateways, egress firewall rules and proxy exceptions that would otherwise be needed to let workloads in private subnets reach a public Bedrock endpoint.
  • Stronger compliance position: for regulated workloads, private connectivity helps satisfy requirements that sensitive data and model operations stay within controlled networks.
  • More predictable latency: private connectivity to a regional service tends to produce more consistent performance than routing out and back through public endpoints.
  • Finer access control: endpoint policies, IAM policies and security groups combine to control exactly which resources can reach the service.

With that established, here are the patterns themselves.

Implementation Pattern 1: VPC Endpoint for Direct Access#

The simplest pattern is a single interface VPC endpoint giving workloads in one VPC direct access to Bedrock.

Architecture Overview#

In this pattern you:

  • Create an interface VPC endpoint for AWS Bedrock in your VPC
  • Configure security groups to control which resources can reach the endpoint
  • Enable private DNS so the standard service hostname resolves to the endpoint
  • Point your applications at the regional Bedrock endpoint as normal

Implementation Steps#

Create the VPC endpoint:

aws ec2 create-vpc-endpoint \
  --vpc-id vpc-12345678 \
  --service-name com.amazonaws.us-east-1.bedrock-runtime \
  --vpc-endpoint-type Interface \
  --subnet-ids subnet-12345678 subnet-87654321 \
  --security-group-ids sg-12345678

Enable private DNS on the endpoint so Bedrock API calls resolve to the private interface automatically, rather than requiring every application to be reconfigured with an endpoint-specific hostname.

Configure security groups so that only authorised sources inside the VPC can reach the endpoint. The endpoint accepts HTTPS on port 443, and that should be the only ingress rule.

Leave your application configuration pointing at the regional Bedrock endpoint. With private DNS enabled, the same SDK call now resolves privately, which is what makes this pattern cheap to adopt.

When to Use This Pattern#

This pattern suits:

  • Single-account deployments with straightforward security requirements
  • Development and testing environments
  • Small to medium implementations with no cross-account access needs

Implementation Pattern 2: Interface Endpoints With Security Groups#

For organizations with tighter requirements, the same building blocks are layered with explicit endpoint policies and tiered security groups.

Architecture Overview#

This pattern builds on the first and adds:

  • Interface endpoints for both the Bedrock control plane and Bedrock Runtime
  • Security groups written to least privilege
  • Endpoint policies restricting which principals and actions can use the endpoint
  • Access monitoring through VPC Flow Logs and CloudTrail

Implementation Steps#

Create an endpoint for the Bedrock API:

aws ec2 create-vpc-endpoint \
  --vpc-id vpc-12345678 \
  --service-name com.amazonaws.us-east-1.bedrock \
  --vpc-endpoint-type Interface \
  --subnet-ids subnet-12345678 subnet-87654321 \
  --security-group-ids sg-12345678 \
  --private-dns-enabled

Then create a second endpoint for Bedrock Runtime, which carries model invocation traffic:

aws ec2 create-vpc-endpoint \
  --vpc-id vpc-12345678 \
  --service-name com.amazonaws.us-east-1.bedrock-runtime \
  --vpc-endpoint-type Interface \
  --subnet-ids subnet-12345678 subnet-87654321 \
  --security-group-ids sg-12345678 \
  --private-dns-enabled

Separating the two matters: control plane calls such as agent configuration and runtime calls such as invocation have different audiences, and splitting them lets you apply different policies to each.

Configure tiered security groups rather than a single shared one:

  • One security group for the application servers that need Bedrock access
  • A separate security group for the VPC endpoints
  • An ingress rule on the endpoint group that references the application group as its source, rather than a CIDR range

Attach an endpoint policy that restricts which actions and accounts can be reached through the endpoint:

{
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": "*",
      "Action": "bedrock:*",
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "aws:PrincipalAccount": "123456789012"
        }
      }
    }
  ]
}

An endpoint policy is a boundary control, not a replacement for identity policy. It says what may pass through this door; the IAM policy on the calling role still says what that role may do. Narrow both, and narrow the action list further than the wildcard above once you know which operations your workload actually calls.

When to Use This Pattern#

This pattern is the sensible default for:

  • Production environments with strict security requirements
  • Environments where granular access control is required
  • Organizations with comprehensive security monitoring obligations
  • Applications passing sensitive data through Bedrock Agents

Implementation Pattern 3: Cross-Account Access#

Larger organizations often separate AI workloads across multiple AWS accounts to keep environments and business units isolated. This pattern gives consumer accounts controlled access to a central set of agents.

Architecture Overview#

  • A central AI services account where Bedrock Agents are configured
  • PrivateLink endpoints in each consumer account
  • AWS Resource Access Manager used to share the relevant resources
  • Cross-account IAM roles governing what each consumer may invoke

Implementation Steps#

Start in the central account. Establish the agents and the endpoint configuration there, so there is one place where agent definitions, guardrails and model access are reviewed.

Share the endpoint service with specific accounts using AWS RAM. Share to named accounts or organizational units rather than broadly, and keep the share list in version control alongside the rest of your infrastructure code.

In each consumer account, create the VPC endpoints that connect to the shared service. Each consumer keeps its own security groups, so a permissive rule in one account does not widen access for the others.

Set up cross-account IAM roles in the central account that consumer accounts can assume, scoped to specific agents. Use external IDs or condition keys on the trust policy so a role cannot be assumed by an unintended principal.

If you use AWS Organizations, add service control policies that deny Bedrock calls which did not arrive through a VPC endpoint. This is what turns the pattern from a convention into an enforced control.

When to Use This Pattern#

  • Enterprises with multiple business units sharing a central AI capability
  • Separate development, testing and production accounts
  • Workloads that require strict isolation from each other
  • Organizations running a centralized AI governance model

Implementation Pattern 4: Multi-Region Deployment#

For organizations with a global footprint or firm recovery objectives, deploying across regions adds resilience and reduces latency for distant users.

Architecture Overview#

  • Bedrock Agent configurations deployed in more than one region
  • Region-specific VPC endpoints in each
  • A DNS routing strategy that can steer traffic between them
  • Application logic that handles regional failover

Implementation Steps#

Deploy agent configurations consistently across target regions. Drift between regions is the most common cause of a failover that technically succeeds but behaves differently, so treat agent definitions as code and deploy them from the same source.

Create the regional VPC endpoints in each region. Model availability differs by region, so confirm that the foundation models your agents depend on are available in every region you plan to fail over to, before you rely on it.

Configure Route 53 with health checks and a routing policy, latency-based or failover, to direct traffic to the healthiest regional endpoint.

Implement application-level failover logic. DNS alone reacts slowly relative to a model invocation timeout, so your client should retry in an alternate region rather than waiting for a record to change.

Work through data synchronization last. If your agents read from data stores through action groups, the replication strategy for those stores, not the endpoints, will determine whether a failover is genuinely usable.

When to Use This Pattern#

  • Global organizations needing low-latency access from several geographies
  • Applications with stringent availability requirements
  • Regulated workloads with business continuity obligations
  • Organizations with regional data residency requirements

Security Best Practices#

Whichever pattern you choose, the following controls apply.

Network Security#

  • Segment the network so AI workloads are isolated from unrelated systems
  • Write security groups to least privilege and reference other security groups as sources rather than CIDR ranges
  • Enable VPC Flow Logs so endpoint traffic is observable after the fact
  • Consider AWS Network Firewall where deeper traffic inspection is required

Access Control#

  • Use IAM roles and policies to control which principals may invoke agents
  • Apply service control policies to enforce organization-wide constraints
  • Audit and rotate any long-lived credentials used to reach Bedrock, and prefer roles over keys
  • Use attribute-based access control where teams and environments need fine-grained separation

Monitoring and Logging#

  • Enable CloudTrail for Bedrock API activity, including data events where the compliance requirement calls for it
  • Create CloudWatch alarms for unusual invocation patterns, both volume and source
  • Automate responses to security events so detection is not the last step
  • Review model invocation logging separately, since prompt and completion content may fall under different handling rules to API metadata

Compliance and Governance#

  • Document the PrivateLink architecture in your compliance artifacts, including which endpoints exist and what each policy permits
  • Review the implementation on a schedule, since new Bedrock service endpoints appear over time and can be missed
  • Include the agent infrastructure in penetration testing scope
  • Run a governance process for approving which models and agents may be accessed, and by whom

Troubleshooting Common Issues#

A few problems come up repeatedly when PrivateLink is introduced.

Connectivity#

  • DNS resolution: if calls still reach public endpoints, private DNS is usually either disabled on the endpoint or overridden by a Route 53 resolver rule. Confirm resolution from inside the subnet, not from a workstation.
  • Security group restrictions: verify that the endpoint’s security group actually permits HTTPS from the calling workload, and that the workload’s egress rules allow it out.
  • Endpoint policy: an access denied error that persists after IAM looks correct is often the endpoint policy rejecting the call.

Authentication and Authorization#

  • IAM permission errors: check that the calling role holds the specific Bedrock actions required, which differ between the control plane and runtime.
  • Cross-account access: confirm the trust relationship on the central role and any condition keys on it.
  • Expired credentials: assumed role sessions expire, and long-running batch jobs are the usual place this bites.

Performance#

  • Endpoint capacity: interface endpoints have bandwidth limits per network interface. High-throughput workloads should spread endpoints across more subnets and availability zones.
  • Regional latency: if latency is higher than expected, confirm which region requests are actually reaching, since a stale SDK configuration can quietly route elsewhere.
  • Connection pooling: reuse HTTPS connections in the client. Establishing a new TLS session per invocation adds avoidable overhead at volume.

Measuring the Impact of Secure AI Deployments#

Private connectivity is a technical change, but the case for it is made in business terms. These are the measures worth tracking.

Security Measures#

  • Reduction in the number of workloads reaching AI services over public paths
  • Frequency of security findings related to AI service access
  • Outcomes of compliance audits touching AI workloads

Operational Measures#

  • Time required to deploy a new AI capability, including the network review
  • Complexity of the network configuration supporting AI workloads
  • Reliability of AI service calls in production

Business Measures#

  • Time to market for AI-enabled capabilities
  • The range of business domains where AI deployment is now permitted
  • The residual risk carried by AI initiatives

Track these before and after the change rather than quoting industry benchmarks: the numbers that persuade an internal audience are the ones drawn from your own environment.

Conclusion: Balancing Security and Accessibility#

As AI moves closer to core business operations, the task is to secure it without making it unusable. The PrivateLink patterns above are a well-worn way of doing that.

The four patterns, from a single direct endpoint to a multi-region deployment, form a progression you can move along as your estate matures. There is no benefit in starting at pattern four; there is real cost in staying at pattern one once several accounts depend on the same agents.

Securing Bedrock Agents with PrivateLink is one part of a wider platform posture. The implementations that hold up over time treat it alongside data governance, identity design and observability, rather than as a network change made in isolation.

Network and platform decisions like these are what we work through in our hands-on ELEVATE-AI workshop, and there is more on architecture and platform choices in our Infra Modernisation hub.

As an AWS Premier Partner with the AWS Generative AI competency, we build this inside your own AWS account, using your existing network and identity controls. To talk through the right pattern for your estate, book a discovery call.

Apply this to your own process

Does this article describe a process your team runs? Book a call and we'll scope a focused first build in your own AWS account.

Book a discovery call