Introducing X-ENI or Cross Account ENI

Stumbled on an interesting new feature based on a commit in the AWS .net SDK which may have been released early.

In any case the possibilities are amazing… Introducing X-ENI!

X-ENI (or Cross-Account ENI) is a new feature that allows the attachment or association of Elastic Network Interfaces (ENI) between VPCs in different AWS accounts located in the same availability zone. With this new capability, service providers and partners can deliver managed solutions in a variety of new architectural patterns where the provider and consumer of the service are in different AWS accounts.

Want to drop an ENI network interface in your customers account that provides service X Y or Z in your VPC (without setting up routing or traversing the internet) it looks like you will be able to do it very soon.

I can’t imagine any reason you couldn’t point a subnets route table at the XENI which might get over some of the limitations of meshed VPC routing for certain services.

In any case the possibilities this opens are are really incredible and I can’t wait for the feature to go live.

I will give an update once I get some hands on with it.

Based on this commit it looks like you set up an X-ENI similar to how you set up an AWS VPC peering link.

Check out the documentation for the create permission.

It is unclear if this will become GA or how you become an “Authorized partner account”

Grants an AWS authorized partner account permission to attach the specified network interface to an instance in their account. You can grant permission to a single AWS account only, and only one account at a time. You can find out more here

Update

The above is for posterity but the below is how it actually works:

Service Provider Setup

  • Service Provider creates an Endpoint Service and gives it a name and associates it to a NLB (The AZs for the LB is configurable).

  • The Endpoint Service has an Allowed Pinciapls list which the Service Provider can apply which can allow named principals (Account, role, user or * for everyone) to do the CreateVpcEndpoint call against it.

  • When creating the Endpoint Service you get to choose if you should manually or automatically accept new connection requests.

Consumer Setup

  • Create a new VPC endpoint specifying the Endpoint Service Name created in the Service provider side

  • You need to specify the subnets, security group and subnets need to line up with the Service Provider (which are not always the same between account)

  • AWS will stick some ENI in your VPC/Subnets as you specified above and you will now have TCP connectivity to the NLB on the

  • Traffic can only be initiated from the Consumers ENI

TLS Setup

To get TLS working correctly is largly an excercise for the consumer to set up and ensure their DNS resolves and matches the TLS certificate on the NLB:

  • Create a Route53 private hosted zone matching the domain that is on the service provider’s NLB TLS certificate.

  • Associate the hosted zone to the consumers VPC with a VPC hosted zone association. This will make hosts in the VPC able to resolve records in this hosted zone using the VPC domain resolver (so long as DNS is enabled for the VPC).

  • Create a CNAME DNS entry in the private hosted zone using the DNS names that came with the Endpoint Service returned by the describe-vpc-endpoints VpcEndpoints[0]DnsEntries[0] value.

  • When an instance in the consumers VPC resolves the endpoint the DNS will match the TLS x.509 certificate on the NLB and connectivity will work.

Diagram

A diagram showing the relationships and traffic flow for the X-ENI / Private Link. The drawio is embedded in the image.

Drawio of AWS X-ENI / Private Link

VPC AWS Service Endpoints

These support VPC Endpoint policies, the following services (last updated Jan 2023) do not:

  • Cloudformation

  • Event Bridge

  • SageMaker API

  • Code Pipeline

  • Code Artifact

Comments

comments powered by Disqus