Access EventBridge Privately with VPC Endpoints (2026)

You can access EventBridge privately from your VPC using VPC endpoints, but the surprising truth is that it doesn’t actually create a new service endpoint for EventBridge itself.

Let’s see this in action. Imagine you have a Lambda function in a private subnet that needs to send an event to EventBridge. Normally, this Lambda would need a NAT Gateway or VPC interface endpoint for s3 (yes, S3!) to reach the public EventBridge API. With a VPC endpoint, your Lambda can stay entirely within your VPC.

Here’s how it works. You create a VPC endpoint of type Interface for com.amazonaws.<region>.eventbridge. This endpoint will provision Elastic Network Interfaces (ENIs) in your chosen subnets. When your resources (like EC2 instances or Lambda functions) within that VPC try to send events to EventBridge, their traffic is routed to these ENIs instead of going over the internet.

The magic here is that EventBridge’s API is actually served over the same infrastructure as S3’s API. When you create an EventBridge VPC endpoint, you’re essentially creating an endpoint for S3 that is specifically configured to allow access to the EventBridge service. This is why you’ll see com.amazonaws.<region>.s3 as the service name when you’re setting up the endpoint, even though you’re intending to access EventBridge. The EventBridge service then uses this S3 endpoint infrastructure to receive your API calls privately.

Let’s walk through the setup.

First, you need to create the VPC endpoint. You’ll specify the VPC, the subnets where you want the ENIs to reside, and the security groups that will control access to these ENIs.

aws ec2 create-vpc-endpoint \
    --vpc-id vpc-0123456789abcdef0 \
    --service-name com.amazonaws.us-east-1.eventbridge \
    --vpc-endpoint-type Interface \
    --subnet-ids subnet-0abcdef1234567890 subnet-0fedcba9876543210 \
    --security-group-ids sg-0123456789abcdef0 \
    --region us-east-1

The service-name here is crucial. While it looks like S3, AWS uses this convention to route traffic for EventBridge through the S3 endpoint infrastructure.

Once the endpoint is created, you’ll get DNS names for it. These DNS names will resolve to the private IP addresses of the ENIs in your VPC. You can configure your VPC’s DNS resolver to use these private DNS names.

The problem this solves is twofold: security and cost. It keeps your EventBridge traffic within your AWS network, eliminating the need for NAT Gateways or public IP addresses for your resources that need to interact with EventBridge. This also means you avoid NAT Gateway data processing charges for EventBridge API calls.

The exact levers you control are the subnets where the endpoint ENIs are placed (which determines availability and network reachability) and the security groups attached to those ENIs (which control which traffic can reach the endpoint). You also control access via endpoint policies, which define which principals can perform which actions on EventBridge through this specific endpoint.

Here’s an example of an endpoint policy. This policy allows any principal from the VPC to put events to EventBridge, but only if the request comes through this specific endpoint.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Principal": "*",
      "Effect": "Allow",
      "Action": "events:PutEvents",
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "aws:SourceVpce": "vpce-0123456789abcdef0"
        }
      }
    }
  ]
}

The aws:SourceVpce condition is key here. It ensures that only requests originating from this VPC endpoint are permitted. Without it, any principal could potentially try to use this endpoint policy to gain access.

What most people don’t realize is that this same com.amazonaws.<region>.eventbridge service name is used for all EventBridge API operations, not just PutEvents. So, if you need to list event buses, describe rules, or perform any other EventBridge API action privately, this single VPC endpoint covers it all. The underlying mechanism leverages the S3 infrastructure, but AWS abstracts that away when you specify the EventBridge service name.

The next concept you’ll likely encounter is managing EventBridge schema registry privately, which often involves a similar VPC endpoint setup but for a different service name.