EKS – a provider for bare-metal servers – Architecting for Disconnected Edge Computing Scenarios

Some disconnected environments require the use of a specific server vendor’s hardware for one reason or another. In such cases, the EKS-A provider for bare-metal servers can be used similarly to the provider for the AWS Snow family:

Figure 9.18 – EKS-A uses Tinkerbell to provision against the bare-metal provider

The key difference between the two providers is the absence of the AWS-managed APIs for out-of-band management that the AWS Snow family offers. Instead, it leverages the open source provisioning system created by Equinix called Tinkerbell. As shown in the preceding figure, Tinkerbell consists of multiple services that do things such as netboot/kickstart-style provisioning or control the power state of the server via whatever out-of-band management facilities that the server vendor offers.

See the Install on Bare Metal section of the EKS-A documentation for more information.

Forward deployment of AWS Outposts

As you’ll recall from our discussion of AWS Outposts, the site requirements are typical of a corporate data center or colocation facility. These are often difficult to accommodate in remote areas. For instance, the temperature and humidity must be kept within a tight range – not a simple proposition when a densely populated rack of servers generates as much as 50,000 BTUs an hour. This requires heavy-duty HVAC to maintain. Similar problems emerge when considering high amounts of well-conditioned AC power:

Figure 9.19 – AWS Modular Data Center

Enter AWS Modular Data Center (MDC). MDC is a self-contained mini-data center that meets MIL-STD-810H requirements and can be deployed to remote locations. Each MDC unit consists of two shipping containers – one of which contains the equipment needed to maintain the environment (including redundant HVAC and power), while the other can accommodate up to five AWS Outposts racks.

Perhaps most importantly, all of the environmental subsystems involved can be remotely monitored and managed by the customer. For example, an alert would go out if one of the HVAC units failed and one of the spares had to be brought online.

At the time of writing, MDC leverages MEO/GEO SATCOM provider SES’ Cloud Direct offering to deliver consistent connectivity back to the AWS parent region needed for the AWS Outposts service link.

Private 5G and DDIL

AWS Private 5G is a managed service that takes advantage of the open CBRS spectrum, which is only available in the US. It is similar in architecture to AWS Outposts – indeed, it can involve AWS Outposts rack in some cases. This means significant components of the service run in an AWS region, thus necessitating clean and consistent high-speed connectivity back to a region in the US. Due to this, it is not suitable for DDIL situations.

Many DDIL scenarios can benefit from an isolated 5G network, even in the absence of good enough connectivity to support AWS Private 5G – or any backhaul at all. Solutions for these situations can be built with AWS services such as the AWS Snow family combined with a partner product that runs on top such as those available from Athonet or Federated Wireless.

As we discussed in Chapter 2, network function virtualization based on containerization is the de facto standard upon which 5G core software is built. Thus, we need more than just the AWS Snow family for these situations.