Understanding AWS Direct Connect multi-account pricing

Introduction

Many AWS customers use multiple AWS Accounts to make it easier to manage permissions and allocate costs to different groups or departments. When multiple accounts share one AWS Direct Connect interface, customers need to understand how Port-hour and outgoing Data Transfer costs are allocated. These accounts may be independent, or part of the same AWS Organizations.

AWS Direct Connect creates private network connections between a data center, office, or colocation environment and AWS. These connections provide low latency, and high-bandwidth throughput connectivity, with a more consistent network experience than internet-based connections. Sharing a Direct Connect link across multiple accounts can be done using either Direct Connect gateway, hosted virtual interfaces, or by connecting it with AWS Transit Gateway.

This blog walks through five scenarios where Direct Connect is deployed in multi-account environments and discusses how Direct Connect costs are allocated in each. Throughout this post we use the term “resource” as shorthand for the source of the network traffic (such as an EC2 instance or an S3 bucket).

Multi-account pricing and attribution

In any Direct Connect connection, there are two elements that determine the pricing (Port-hours and Data Transfer out (DTO)). In multi-account scenarios, two additional factors (Virtual Interface type, and AWS Organization membership) determine how those costs are allocated.

Port-hours are the hours consumed once you have accepted a connection from AWS. The account that owns the Direct Connect connection (that is, the account that created the connection) is billed for Port-hours. Port-hour pricing is determined by connection type (Dedicated or Hosted).

Data Transfer out (DTO) refers to traffic that is sent from an AWS resource to destinations outside AWS. This is charged per GB, and exact pricing is dependent on the AWS Region and AWS Direct Connect location. Generally speaking, outbound Data Transfer is charged to the account that owns the resource that is sending the traffic. But, there are exceptions to this rule that apply when using AWS Transit Gateway, or a VPN in a multi-account scenario:

• AWS Transit Gateway: When traffic is routed through a Transit Gateway, the owner of the last resource in the chain before the data is routed to the Direct Connect VIF is charged for Data Transfer out. This is true even if the traffic was previously routed through the Transit Gateway by resources owned by other accounts. (This is often the case when using a centralized inspection VPC.)
• VPN: If you are routing data over a VPN connection from outside AWS, through a Transit Gateway, and back to a location outside AWS, then Data Transfer out costs are allocated to the owner of the Transit Gateway.

(Data Transfer in does not play a role as it is $0.00 per GB in all Direct Connect locations.)

Virtual Interfaces (VIF) are necessary to access AWS services using Direct Connect, and come in three distinct types. A public virtual interface (public VIF) can access all AWS public services that use a public IP address (such as Amazon S3 buckets, Classic EC2 instances, or EC2 traffic that goes through an internet gateway). A private virtual interface (private VIF) is used to access VPCs using a private IP address. And, a transit virtual interface (transit VIF) is used to access one or more AWS Transit Gateways. For more information on VIF, see AWS Direct Connect virtual interfaces in our documentation.

AWS Organizations provide a central place for an administrator to manage many AWS accounts. In most cases, AWS Organizations membership does not factor in to cost allocation for Direct Connect. The exception is when the owner of a resource is not in the same AWS Organization as the owner of a Direct Connect connection. In this case, the owner of the resource sending the traffic is billed at the Data Transfer rate for the public AWS service in use, not the Direct Connect Data Transfer out rate. (Scenarios 4 and 5 that follow will go into this in more detail.)

Determining Data Transfer out allocation

To introduce how these factors work together, this matrix walks through how Data Transfer out charges are allocated based on each VIF type. All examples assume that there are only two accounts (A and B).

Rules of thumb:

Here are a few general concepts to keep in mind when determining Direct Connect cost allocation when multiple accounts are involved:

1. By default, Port-hours are allocated to the account that created the Direct Connect connection.
2. Data Transfer out charges are usually allocated to the account that owns the resource sending the traffic, unless the traffic is sent through an AWS Transit Gateway, in which case:
   • Data Transfer out is allocated to the owner of the last resource to send traffic before the Direct Connect VIF – this is described in scenario 2.
   • If you are routing VPN data from outside AWS, through a Transit Gateway, and back to a location outside AWS, then DTO costs are charged to the owner of the Transit Gateway – this is described in scenario 3.
3. If the owner of a Direct Connect connection and the owner of the resource sending traffic are in different AWS Organizations, Data Transfer out costs are allocated to the owner of the resource sending traffic, and charged the internet Data Transfer rate for the specific service they are using (not the Direct Connect DTO rate) – this is described in scenario 5.

(Remember, these guidelines only apply in multi-account scenarios.)

Scenarios

With those basics out of the way, let’s look at five common architectures to better understand how these rules are applied scenarios with more than two accounts.

Important! The architectures and illustrations that follow show a single Direct Connect connection in each case to increase clarity. You should always build redundancy in your connectivity based on the best practices provided by the Direct Connect Resiliency Toolkit.

Scenario 1: Private VIF, Data Transfer out from VPC

Summary:

Data Transfer out charge: Allocated to account A, account B, and account C (the owners of the resources sending data to the Direct Connect private VIF)

Direct Connect Port-hour charge: Allocated to account A (the owner of the Direct Connect connection)

Details:

Figure 1: Direct Connect allocation scenarios when using a private VIF

The architecture in the previous graphic (figure 1) shows a customer running Direct Connect between a corporate data center and an AWS environment with multiple accounts. Private VIFs are created for this connection and terminated on a Direct Connect gateway. The Direct Connect Gateway is associated with the Virtual Private Gateways of three VPCs and with different AWS accounts using Direct Connect multi-account association.

The Direct Connect, Private VIF, and Direct Connect gateway are owned by account A, while VPCs from accounts A and B are associated with the Direct Connect gateway. Data Transfer out charges for traffic generated from the EC2 resources in VPC A (DTO1) is allocated account A. The Data Transfer outbound traffic generated by EC2 resources in VPC B (DTO2) is allocated account B.

However, in this scenario account B uses VPC Sharing to share VPC B with account C. This allows account C to deploy workloads in VPC B and co-locate them with account B’s resources. In this case, outbound traffic generated from account C’s EC2 resources in VPC B (DTO3) is allocated as Direct Connect DTO to account C.

This scenario is used when VPCs and the Direct Connect gateway are owned by AWS accounts that are part of the same AWS Organizations (in other words, belong to the same AWS payer account ID).  Some architectures must share a private VIF with other AWS accounts that do not belong to the same AWS payer account ID. (This could be due to third party AWS accounts or AWS accounts of acquired/merged entities that must send traffic back to their premises.) In this case, a hosted private VIF (hosted connections are sourced from AWS Direct Connect Delivery Partners that have a network link between themselves and AWS) is created for those AWS accounts. In such cases, costs are allocated to the owner of the resource that is transferring data out. The same rule applies while attributing Direct Connect Data Transfer out costs.

Scenario 2:  Transit VIF, Transit Gateway, centralized inspection VPC

Summary:

Direct Connect DTO charge: Allocated to account C (the AWS account that owns the VPC attachment to Transit Gateway that carries last leg of traffic before sending to the Direct Connect)

Direct Connect Port-hour charge: Allocated to account A (The AWS account that owns the Direct Connect connection)

Details:

Figure 2: Direct Connect allocation scenarios with Transit VIF, a central inspection VPC, Transit Gateway, and VPN

The architecture in the preceding diagram (figure 2) is based on the Transit Gateway design pattern for centralized security inspection. This allows filtering of ingress and egress traffic from on premises to AWS (north-south traffic). This is detailed in the Tech Talk: Advanced architectures with AWS Transit Gateway. These architectures are also described in the AWS Network Firewall Centralized deployment pattern blog post, as well as the AWS Gateway Load Balancer Centralized Deployment post.

In this case, the traffic destined for an on premises data center is coming from EC2 resources in VPC A (DTO1), and from EC2 resources in VPC B (DTO2), routed through a Transit Gateway. This traffic is routed to the Inspection VPC where traffic is inspected and filtered. The inspected traffic is then sent by way of the inspection VPC attachment to the Transit Gateway and then over the Direct Connect transit VIF. In this scenario, even if account A owns the resource for DTO1 and account B owns the resource for DTO2, the Direct Connect Data Transfer charge is allocated to the owner of the attachment sending the traffic to the Direct Connect, in this case security account C.

Even if the preceding architecture used shared VPCs, and resources were deployed in those VPCs by other AWS accounts, the overarching principle is the same. Costs are allocated to the owner of the VPC attachment that sends the data to the Direct Connect connection by way of the Transit Gateway.

Scenario 3:  Transit VIF, Transit Gateway, VPN attachment

Summary:

Data Transfer out charge: Account A (the AWS account that owns the AWS Transit Gateway)

Direct Connect Port-hour charge: Account A (the AWS account that owns the Direct Connect connection)

Details:

In the preceding diagram (figure 2), we have a branch data center connected over a VPN attachment to the Transit Gateway. Traffic (DTO3) originates in the branch data center, flows through the VPN connection, through a Transit Gateway, and finally out over Direct Connect to the corporate data center. In this case, the resource generating the traffic is outside of the AWS environment. The account that owns the AWS Transit Gateway (account A) is considered the origin of the Data Transfer when attributing Direct Connect Data Transfer costs.

Please note that in the preceding example, both Direct Connect and Transit Gateway are owned by account A. This is representative of most customer environments where these two shared networking services are part of the same AWS account. However, there is a scenario where the Transit Gateway is owned by a different account than the Direct Connect connection (port) owner. In this case, the account that owns the Transit Gateway is considered as the resource owner generating the outbound Data Transfer and is attributed the charges accordingly.

Public virtual interfaces

Now let’s look at scenarios that use a public virtual interface.

A public virtual interface is used to access publicly routable AWS services like Amazon S3, Amazon DynamoDB, and others from your on-premises data center. We advertise appropriate Amazon prefixes so that you are able to access public AWS services. You access all Amazon prefixes through this public virtual interface; for example, Amazon EC2, Amazon S3, and Amazon.com. (For a current list of prefixes advertised by AWS, see AWS IP Address Ranges in the Amazon Web Services General Reference documentation.)

Here we walk through multi account scenarios that involve Amazon S3 buckets as shown in the architectural diagram that follows (figure 3). (This scenario applies when you are accessing other public AWS services as well, but here we are using Amazon S3 as an example.)

Scenario 4: Public VIF, accounts in the same AWS Organizations

Summary:

Data Transfer out charge: Allocated to account A or account B respectively (depending on the owner of the resource)

Direct Connect Port-hour charge: Allocated to account A (the owner of the Direct Connect connection)

Details:

Figure 3: Direct Connect allocation scenarios with Public VIF

When an S3 bucket in account A is accessed from an on-premises data center through Direct Connect (DTO1), the Direct Connect Data Transfer out charge, in addition to the Port-hours charge, is allocated to account A. A separate S3 bucket owned by account B is accessed from an on-premises data center over the public VIF (DTO2). In this case, Data Transfer out is allocated to AWS account B, as they are the resource owner. Because accounts A and B are part of the same AWS Organizations, the management account (that links all accounts in this diagram) sees the aggregated charge on its billing statement. (While this scenario uses S3 as an example, this logic applies to other public AWS services as well.)

Scenario 5: Public VIF, accounts in different AWS Organizations

Summary:

Data Transfer out charge: Allocated to account C (the account that owns the S3 bucket) using S3-Internet transfer rates

Direct Connect Port-hour charge: Allocated to account A (the owner of the Direct Connect connection)

Details:

In scenario 5 an S3 bucket is owned by account C. That S3 bucket is accessed over an account that is not part of the same AWS Organizations as the other accounts. This can occur when you have workloads that interact with resources in AWS account outside of their AWS Organizations umbrella. For example, accessing Amazon S3 buckets of SaaS solutions in other AWS accounts or S3 buckets of AWS accounts of merged entities or acquired companies. When a S3 bucket in account C is sending data out to an on-premises data center (DTO3), costs are allocated to AWS account C and charged for Data Transfer out from Amazon S3, at S3 internet transfer rates.

While this scenario uses S3 as an example, this is applicable for other public AWS services as well.  If the outbound traffic is destined for public prefixes owned by account A and its AWS Organizations management account, AND, the account that owns the resource (account C in this example) is not part of the same AWS Organizations, then Data Transfer out charges will be allocated to account C at internet rates.

In all the above scenarios, we are only considering Data Transfer out charges from S3. There are additional parameters that contribute to cost and specified in the S3 pricing page.

Conclusion

In this blog we examined five scenarios for allocating Direct Connect charges when public, private and transit virtual interfaces are used in multi account environments. It is important to consider how your Direct Connect is used and how outgoing data traffic flows through your network so that Data Transfer charges are attributed correctly to individual accounts.

And remember, the architectures shown here only used one Direct Connect connection in order to make it easier to understand each scenario. In practice, be sure to follow AWS Direct Connect Resiliency Recommendations.

For more information on Direct Connect pricing please refer our AWS Direct Connect pricing documentation.