June 29, 2021 Continent 8 Team

Connecting AWS Outposts

With significant growth in AWS Outpost utilisation by our customers, and AWS activity in selling this product to deliver the AWS iGaming capability at the regulated edge, the teams at Continent 8 Technologies (C8) have had many conversations with customers about how best to connect an AWS Outpost to AWS, the Internet, B2B partners, and their own infrastructure.

An AWS Outpost is a physical rack of AWS supplied and managed equipment which is only supported by AWS and brings a subset of AWS services (listed in the diagram below) to the co-located environment they are hosted.  Requiring permanent connectivity to AWS (region(s) specified during order placement) via minimum 1Gbps (10Gbps preferred) Service Link – through which on first power up will download and configure all services – an AWS Outpost does assume highly available uncontended connectivity exists at installation location.

AWS has significant documentation on options and requirements here, so this is an opportunity for me to provide a summarised high-level approach to the options and the resulting advantages or considerations, which we have been undertaking in recent customer engagements.

C8 can always provide support and guidance depending upon customer requirements, however, in our experience thus far, we have found that most customers will need some sort of supporting network infrastructure to enable the most efficient and highly available connectivity.

As an example, specifically in the US, C8 suggests that a mixture of local in-state internet and out of state Tier 1 and Internet Exchange peering (IP), as well as direct private connectivity to AWS and B2B partners and other customer implementations (MPLS), creates a platform for successful delivery, as shown in the below high-level diagram.

This approach allows customers the maximum capability, highest availability and lowest latency to connectivity:

  1. Use of private connectivity (Cloud Connect) to AWS for reduced DDoS footprint and data transfer cost.
  2. Internet connectivity (Transit) to B2B or B2C, without ‘tromboning’ via cloud provider, also acts as resilience to Direct Connect to Cloud.
  3. Secure private connection (MPLS) to other implementations or management network or customer infrastructure.
  4. Ability to make use of C8 iGaming ecosystem (future Exchange) for partner connectivity at lowest latency and highest availability.

How to connect?

Physically

Connecting an AWS Outpost to either connectivity services or co-located customer infrastructure is a relatively simple and standard structured cabling method for delivery – using AWS Outpost’s inclusive patch panel supporting single or multimode fibre LC connections (up to 16 depending upon speed).  C8 will take care of enabling this for you to deliver whichever services are required, as part of the ‘AWS Outpost Enablement Package‘, including support on answering and completing necessary AWS documentation and online forms, and presentation of services to AWS Outpost supported requirements.

Logically

AWS provide significant documentation on how to implement or configure the connectivity here, covering the below areas:

  1. Service Link (SL) and Local Gateway (LGW) definitions and uses
  2. Link Aggregation Control Protocol (LACP) to establish two link aggregation group (LAG) connections to your Outpost network devices and to your local network devices.
  3. Virtual LAN (vLAN) connectivity between the Outpost and your customer local network devices.
  4. Layer 3 point-to-point connectivity for each VLAN.
  5. Border Gateway Protocol (BGP) for the route advertisement between the Outpost and your on-premises service link.
  6. BGP for the route advertisement between the Outpost and your on-premises local network device for connectivity to the local gateway.

What to connect?

Internet or direct, or both?

This is where the majority of C8 support has been engaged before or during AWS Outpost order or delivery.  An AWS Outpost can connect to AWS Region EITHER via the Internet, publicly, or via Direct Connect, privately, to the AWS Network (C8 provide this capability via our “Cloud Connect” service), or even have both.

Depending upon criteria, there are different advantages and considerations to be considered, especially when an AWS Outpost doesn’t provide all router or firewall edge functions by default. (Specifically, no DNAT or PAT capability resulting in a significant IPv4 requirement).

Until December 2020, any selection still depended upon local dedicated customer infrastructure OR a service provider capable of providing a network edge service (NEaaS) because of the lack of these router or firewall network functions within the AWS Outpost, and the resulting requirement for significant IPv4 address space.

After December 2020, AWS released the ability for an AWS Outpost to utilise a Direct Connect (C8 Cloud Connect) connection to AWS directly and singularly for all connectivity, which does offer a simplified method.

As per the documentation, there are two vLAN’s to consider for use with an AWS Outpost – the Service link (SL) and Local Gateway (LGW).  Service Links (SL) are limited (~1Gbps) in capability whereas Local Gateways (LGW) are capable of significant Gbps capability.

Any customer using an AWS region in front of an AWS Outpost with no separate Internet Transit service utilising the service link (SL); will be liable for Data Transfer Out (DTO) charges for traffic ingested via the region then via the service link to the AWS Outpost.

Even so, there remain several different options for connecting the AWS Outpost to connectivity services, and we run through them below.

Via Customer Infrastructure

This appeared to be the default and expected configurations for all AWS Outposts – all AWS documentation and engagement came from a perspective of placing an AWS Outpost into an EXISTING customer infrastructure location.  However, many C8 customers were looking to use an AWS Outpost in a ‘greenfield’ location where no existing infrastructure existed – this presented a challenge, especially for customers who had no previous expertise or capability or were looking to no longer need any.

Nonetheless – for customers with an existing co-located footprint or prepared to implement one, C8 can support both configurations via this method as shown below, with customers either connecting the AWS Outpost entirely via own network edge (NE), or an AWS Outpost directly to AWS and Internet via own network edge (NE).

The advantages with this method are:

  • Flexible customer options, direct connect and IP transit supported.
  • Maximum resilience and reach for minimum latency.
  • Customers can control data ingress and egress fees.
  • Other connectivity and security services supported (Exchange / MPLS / etc.)
  • Universal availability with C8 (even shared racks for reduced co-location footprint in some locations).

Via C8 Network Edge Service (NEaaS)

To meet the demand or need expressed by some customers to connect an AWS Outpost without needing any local co-located infrastructure, C8 provided its own network edge service capability via the C8 Public Cloud.

This gave customers all the advantages of connectivity options, but without the need for their own dedicated co-located infrastructure, whilst retaining control and manageability of the network edge, as shown in the diagram.

The advantages with this method are:

  • Flexible customer options, direct connect and IP transit supported.
  • Maximum resilience and reach for minimum latency.
  • Customers can control data ingress and egress fees.
  • Other connectivity and security services supported.
  • No customer infrastructure requirements.
AWS Outpost Only

Since December 2020 customers have now been able to install an AWS Outpost ‘greenfield’ and connect directly to AWS via Direct Connect (C8 Cloud Connect) for all connectivity, as shown in the diagram.

The obvious advantages here are that there are no customer infrastructure or network edge (NE) requirements and there is a universal ability to provision anywhere in C8 locations because of the support for Direct Connect via Cloud Connect offered.

NOTE: It is theoretically possible to connect an AWS Outpost to an internet service, however this configuration isn’t optimal and will utilise significant IPv4 address space for the necessary vLAN configurations without NAT capability.

However, the below considerations exist:

  • Internet transit requires significant IPv4 Address space.
  • Other C8 connectivity services unsupported.

NOTE: If NO internet transit taken:

  • All ingress and egress via AWS region Service Link.
  • All traffic “out of jurisdiction” (Latency to “trombone”).
  • Via service link, maximum 1Gbps capability irrespective port speed.
  • Data Transfer Out (DTO), where traffic ingested via region first.

Conclusion

In summary, C8 can enable or connect AWS Outposts to AWS and customers or partners with or without customer infrastructure, but we have experience in how to architect the most available or resilient or best connectivity depending upon the customers priorities or application environment needs.  Network edge is available as a service with C8 where a public cloud exists to remove the need for local dedicated customer infrastructure whilst maintaining control and functionality.

  • AWS supports multiple scenarios and will always encourage the use of Direct Connect (C8 Cloud Connect) to support an Outpost.
  • Data Transfer Out (DTO) fees should be considered, especially if considering using the AWS Region as the only ingress and egress point.
  • AWS Outpost Service Link (SL) used for all connectivity will limit the performance capability.
  • Whilst more complex from a routing perspective and manageability, multiple options and capabilities will deliver the best and most available connectivity.
  • C8 is ready to support and connect AWS Outpost 1U and 2U options using shared co-location and network edge services as and when available.

Learn more about our AWS partnership via https://www.continent8.com/aws/ or contact me via justin.cosnett@continent8.com

Justin Cosnett, Chief Product Officer at Continent 8 Technologies. With 20+ years’ experience in the hosting and SaaS sectors in a number of customer facing roles, Justin has a strong technical background. He joined Continent 8 in 2012 and was Head of Solution Architect before being promoted to Chief Product Officer.