This post covers how to use AWS as your Internet Service Provider (ISP). The idea behind this approach is that customers who already connected their on-premises locations, e.g. offices, via AWS Direct Connect can leverage this connectivity to also provide Internet access via AWS.
Before diving into the solution proposal, let’s look at the benefits as well as constraints of this use case.
Leveraging AWS as your centralized egress point to the Internet, allows you to deploy egress inspection or filtering solutions within AWS. This in return enables you to restrict HTTP and HTTPS egress traffic from your offices to a whitelisted set of hostnames (FQDN). Centralizing such a component will save you licensing and maintenance cost.
The cost of leveraging AWS as the ISP instead of utilizing a local ISP might actually be cheaper. While local ISPs usually charge for Internet connectivity based on the provided maxim bandwidth, the charges associated with AWS are based on consumption. Assuming you use an EC2-based NAT instance - e.g. as part of the egress filtering solution above - the cost for Internet egress traffic would be the following for the AWS N. Virginia region (US-East-1):
- Traffic from on-premises to Internet (Request):
- AWS DX In: 0.00 $/GB
- Transit Gateway processing: 0.02 $/GB
- Internet Data Transfer Out: 0.09 $/GB
- Sum: 0.11 $/GB
- Traffic from Internet to on-premises (Response)
- AWS DX Out: 0.02 $/GB
- Transit Gateway processing: 0.02 $/GB
- Internet Data Transfer In: 0.00 $/GB
- Sum: 0.04 $/GB
In the case you use an AWS NAT Gateway the cost increases by 0.045 $/GB in both directions.
As mentioned above this setup assumes that you already have your offices or other interesting on-premises locations connected via AWS Direct Connect with AWS. From a cost perspective this approach also assumes that your on-premises locations are within close proximity of AWS Direct Connect locations. Otherwise the cost of connecting your on-premises locations via an AWS Direct Connect partner might be more expensive than using a local ISP.
The fundamental design of this approach is depicted in Figure 1. One of more on-premises locations such as offices connect via carrier ethernet or another local connectivity option to two Direct Connect locations within close proximity.
Traffic from on-premises destined to the Internet is routed via one of the two Direct locations, while the other location serves as backup path. Alternatively both Direct Connect locations can be used in an Active/Active setup. Within AWS the egress traffic traverses a Transit VIF, Direct Connect Gatewy, and Transit Gateway into an “Egress VPC”, where an EC2-based Firewall or NAT device resides. Here internal RFC1918 addresses are translated via Elastic IP Addresses to public IPs.
Refer to the AWS blog post “Creating a single internet exit point from multiple VPCs Using AWS Transit Gateway” to learn more about creating the egress VPC.
While implementing this approach there are a few caveats that need to be considered.
Intra Region traffic
Keep in mind that the AWS Direct Connect Gateway does not allow you to route traffic from one Virtual Interface to another Virtual Interface. Therefore the traffic flow as despicted in Figure 2 is not possible.
If you have a need to route traffic between offices in a certain region through the same AWS region, you need to leverage a separate Direct Connect Gateway, Transit VIF, and Direct Connect connection for each of your offices. The resulting design is depicted in Figure 3.
This approach could make sense in case you have the requirement of inspecting and filtering traffic between on-premises locations. In case you have no such requirement, it makes more sense to route traffic between offices directly via the Carrier Ethernet connectivity (Figure 4), completely leaving it out of AWS.
Such setup will reduce the cost for Direct Connect connections.
Inter Region traffic
Thanks to the recently released capability of Inter-Region Peering for the Transit Gateway you can extend the above described model and interconnect your offices across the globe with AWS Direct Connect and Transit Gateway (Figure 5).
When implementing this inter region approach it is highly recommended to egress traffic to the Internet within each AWS region. Carrying traffic destined for the Internet over the AWS backbone does not make financial sense, due to the added cost. In addition traffic would experience increased latency, resulting in a poor end-user experience.
In this article we discuss the possibility of using AWS as your Internet Service Provider (ISP), while connecting your on-premises locations, e.g. offices, via AWS Direct Connect to AWS. It touches on some of the benefits, constraints, and implementation caveats.