Edge Computing with Amazon Web Services E-Book

Sean Howard

• Herausgeber: Packt Publishing
• Kategorie: Fachliteratur
• Sprache: Englisch

Seitenzahl: 438

Veröffentlichungsjahr: 2024

Beschreibung

The surge in connected edge devices has driven organizations to capitalize on the opportunities presented by the massive amounts of data generated by these devices. However, adapting to this landscape demands significant changes in application architectures.
This book serves as your guide to edge computing fundamentals, shedding light on the constraints and risks inherent in selecting solutions within this domain. You’ll explore an extensive suite of edge computing services from AWS, gaining insights into when and how to use AWS Outposts, AWS Wavelength, AWS Local Zones, AWS Snow Family, and AWS IoT Greengrass. With detailed use cases, technical requirements, and architectural patterns, you’ll master the practical implementation of these services and see how they work in real life through step-by-step examples, using the AWS CLI and AWS Management Console. To conclude, you’ll delve into essential security and operational considerations to maximize the value delivered by AWS services.
By the end of this book, you'll be ready to design powerful edge computing architectures and handle complex edge computing use cases across multiple AWS services.

Leseprobe

Edge Computing with Amazon Web Services

A practical guide to architecting secure edge cloud infrastructure with AWS

Sean Howard

Edge Computing with Amazon Web Services

Copyright © 2024 Packt Publishing

All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, without the prior written permission of the publisher, except in the case of brief quotations embedded in critical articles or reviews.

Every effort has been made in the preparation of this book to ensure the accuracy of the information presented. However, the information contained in this book is sold without warranty, either express or implied. Neither the author, nor Packt Publishing or its dealers and distributors, will be held liable for any damages caused or alleged to have been caused directly or indirectly by this book.

Packt Publishing has endeavored to provide trademark information about all of the companies and products mentioned in this book by the appropriate use of capitals. However, Packt Publishing cannot guarantee the accuracy of this information.

Associate Group Product Manager: Preet Ahuja

Publishing Product Manager: Surbhi Suman

Book Project Manager: Ashwini Gowda

Senior Editor: Divya Vijayan

Technical Editor: Arjun Varma

Copy Editor: Safis Editing

Proofreader: Safis Editing

Indexer: Rekha Nair

Production Designer: Vijay Kamble

Senior DevRel Marketing Executive: Linda Pearlson

DevRel Marketing Coordinator: Rohan Dobhal

First published: February 2024

Production reference: 1020224

Published by Packt Publishing Ltd.

Grosvenor House

11 St Paul’s Square

Birmingham

B3 1RB, UK

ISBN 978-1-83508-108-2

www.packtpub.com

To Nick, Alice, and Angelica, thanks for putting up with this.

– Sean Howard

Contributors

About the author

Sean Howard is a principal solutions architect (SA) at Amazon Web Services (AWS). He’s held several roles at AWS, including partner SA, SA manager, and now, principal SA, supporting aerospace and satellite customers in EMEA. Before AWS, he spent seven years at VMware as a network virtualization specialist. Before that, he spent a number of years in operations at the worlds second largest DNS registrar. His introduction to IT came during his time in the US Marines, where he worked on shipboard and field-deployed networks.

He holds a bachelor of science in computer information systems from Excelsior College, as well as a number of technology certifications, such as the VMware VCDX (#130).

Special contribution

Jay Naves supports aerospace and satellite customers at AWS with edge computing in space. In this role, he led the technical deployment of AWS Snowcone to the International Space Station (ISS) for use as an edge compute device and, at the time of writing, continues to manage its operation.

He is an expert in Linux systems administration and, prior to joining AWS, spent 20 years creating and leading high-performance compute (HPC), systems, and security teams at General Dynamics IT.

Jay holds the Red Hat Certified System Administrator and AWS Professional certifications.

About the reviewer

Maurice “Mo” Ramsey is an AWS disaster response and humanitarian leader. In this role, Mo brings significant business and technology leadership experience, advancing cloud technology adoption to support, enable, and activate humanitarian assistance and disaster response (HADR) missions for customers, partners, and communities.

Previously, Mo served in the US Army (active) from 1992 to 1997. He was honorably discharged in 1997 as a disabled veteran. He has served in leadership roles such as director at Slalom Consulting over advanced infrastructure and strategy (serving as a CIO “on-demand” resource), senior director for the cloud at CenturyLink (formerly Tier3), GM of advisory services at Lighthouse, and, most recently, area practice lead of professional services for nonprofits with AWS.

Mo earned a BA from Columbia College and holds multiple business and technology certifications.

Table of Contents

Preface

Part 1: Compute, Network, and Security Services at the Edge

1

Getting Started with Edge Computing on AWS

The intersection of cloud and edge computing

Physics

Economics

Regulatory compliance

Inertia

The AWS edge computing strategy

Disconnected, denied, intermittent, or low-bandwidth

Multi-access edge computing

Immersive experiences

IIoT

Overview of the AWS edge computing toolbox

Localized AWS infrastructure and services

Developer tools and resources

Security and compliance

Consistent experience

Architectural guidance

Summary

2

Understanding Network and Security for Near-Edge Computing

Understanding internet challenges

The impact of latency and packet loss

Causes of packet loss on the internet

TCP receive window (RWIN)

User Datagram Protocol (UDP)

Using a private wide-area network (WAN)

Multiprotocol Label Switching (MPLS)

Software-defined networking (SDN)

Software-defined WAN (SD-WAN)

Optimizing ingress with global server load balancing (GSLB)

Internet Control Message Protocol (ICMP) triangulation

IP geolocation database

Custom rules

Steering traffic at the network layer with IP Anycast

Addressing TCP issues with HTTP/3 and QUIC

Upsides of HTTP/3 and QUIC

Downsides of HTTP/3 and QUIC

Current status

Securing networks at the near edge

Identity and Access Management (IAM)

Encryption

Secure communication protocols

Device hardening

Network segmentation

Monitoring and logging

Security updates and vulnerability management

Physical security

Incident response and disaster recovery

Training and awareness

Summary

3

Understanding Network and Security for Far-Edge Computing

Introduction to radio frequency (RF) communications

Frequency and wavelength

Antennas

Modulation

Duplexing

Multipath propagation

Multiplexing

Utilizing cellular networks

4G/LTE

5G

Cellular Vehicle-to-Everything (C-V2X)

Narrow-Band IoT (NB-IoT)

Optimizing Wi-Fi (802.11x)-based connectivity

Wi-Fi-1 through Wi-Fi-6

Modulation and coding schemes (MSCs)

Spatial streams

WiFi and MIMO

MU-OFDMA

802.11p (DSRC)

Connecting to low-powered devices with LoRaWAN

LoRa

Long range wide area network (LoRaWAN)

LoRaWAN network topology

Direct communication between devices

Geolocation

LoRaWAN device classes

Integrating SATCOM

SATCOM frequency bands

Satellite orbits

Global Navigation Satellite System (GNSS)

Summary

Part 2: Introducing AWS Edge Computing Services

4

Addressing Disconnected Scenarios with AWS Snow Family

Introduction to the AWS Snow Family

Using AWS Snowball Edge

Migrating data to the cloud

Physical networking

Logical networking

Storage allocation

Using AWS Snowcone

Wi-Fi

Power supply

Data transfer targets

Summary

5

Incorporating AWS Outposts into Your On-Premises Data Center

Introducing AWS Outposts

Using AWS Outposts Rack

Use cases

Ordering an AWS Outposts rack

Physical elements

Logical networking

Available services

High availability (HA)

Security

Using AWS Outposts Server

Ordering

Physical networking

Service link

Logical network interfaces (LNIs)

High Availability (HA)

Service availability

Storage

Summary

6

Lowering First-Hop Latency with AWS Local Zones

Introduction to AWS Local Zones

Customer needs

AWS Outposts versus AWS Local Zones

AWS Dedicated Local Zones

AWS Local Zones pricing

Latency to AWS Local Zones

Opting into AWS Local Zones

Connecting on-premises networks to AWS Local Zones

AWS Direct Connect

Routing internet traffic into AWS Local Zones

Application Load Balancer

Amazon Route53 for load balancing

AWS Local Zone as primary with parent region as secondary

Using AWS Global Accelerator

Traffic between AWS Local Zones

Summary

7

Using AWS Wavelength Zones on Public 5G Networks

Introduction to AWS Wavelength Zones

Comparing AWS Wavelength deployments across global carriers

Connecting to AWS Wavelength from mobile devices

Enabling AWS Wavelength Zones

Carrier gateways

Application Load Balancer

Amazon Route53 for load balancing

Edge Discovery Service (EDS)

Extending a VPC into AWS Wavelength

Communication between AWS Wavelength Zones

Communicating to AWS endpoints

Integrating AWS Wavelength with other services

EC2 instances

Amazon ECS

Amazon EKS

Service pricing

Summary

Part 3: Building Distributed Edge Architectures with AWS Edge Computing Services

8

Utilizing the Capabilities of the AWS Global Network at the Near Edge

Overview of the AWS Global Network

AWS Global Network

Processing at the near edge with Amazon CloudFront

Content distribution

Regional edge caches (RECs)

Amazon CloudFront Embedded POPs

HTTP/3 and QUIC

AWS Lambda@Edge

Amazon CloudFront functions

Leveraging IP Anycast with AWS Global Accelerator

TCP termination

Endpoint groups

Using the AWS global backbone as a private WAN

AWS Cloud WAN

Summary

9

Architecting for Disconnected Edge Computing Scenarios

Overview of DDIL

Using AWS IoT services in DDIL scenarios

The AWS Snow family as an IoT gateway

Embedded Linux devices as IoT gateways

Tactical edge

Forward deployment of the AWS Snow family

EKS-A

Forward deployment of AWS Outposts

Private 5G and DDIL

Using AWS Snowball Edge to host a private 5G core

Summary

10

Utilizing Public 5G Networks for Multi-Access Edge (MEC) Architectures

Overview of architecting 5G-based MEC solutions

Public MEC

Private MEC

Observability, security, and capacity of Wi-Fi versus 5G

Observability

Security

Capacity

Computer Vision

V2X

ISA devices

AWS IoT FleetWise

Software-defined video production

Summary

11

Addressing the Requirements of Immersive Experiences with AWS

Overview of immersive experiences

Virtual Reality (VR)

Augmented Reality (AR)

Mixed Reality (MR)

XR development platforms

Online gaming with Unity

Dedicated servers

Game clients

Pixel streaming

Amazon GameLift plugin for Unity

Connected workers

Mobile edge computing (MEC) and connected workers

Workforce development and training

AR-enhanced sporting events

AR-integrated live video

Summary

Part 4: Implementing Edge Computing Solutions via Hands-On Examples and More

12

Configuring an AWS Snowcone Device to Be an IOT Gateway

Ordering an AWS Snowcone device

Step 1 – Creating an S3 bucket

Step 2 – Creating a new job

Step 3 – Selecting the job type

Step 4 – Choosing a form factor

Step 5 – Selecting optional components

Step 6 – Setting encryption options

Step 7 – Confirming your selections

Step 8 – Saving output files

Step 9 – Setting up the physical environment

Deploying the backend in your AWS account

Step 1 – Installing and configuring AWS CLI v2

Step 2 – Cloning the code repository from GitHub

Step 3 – Copying the code repository to your S3 bucket

Step 4 – Deploying the CloudFormation templates

Step 5 – Retrieving outputs from CloudFormation and passing them to environment variables

Step 6 – Configuring the AWS IoT Greengrass v2 service policy on your account

Preparing the device with the Snowball Edge CLI

Step 1 – Installing the AWS Snow CLI client

Step 2 – Configuring the AWS Snow CLI

Step 3 – Unlocking your Snow device with the CLI

Step 4 – Retrieving the output of the unlocking procedure

Step 5 – Creating a virtual network interface

Step 6 – Obtaining local credentials from your Snow device

Step 7 – Retrieving the certificate from your Snow device

Step 8 (optional) – Adding the EC2 endpoint URL to your AWS CLI config file

Configuring AWS IoT Greengrass on the Snow device

Step 1 – Creating an EC2 keypair on the Snow device

Step 2 – Obtaining the ImageId value from your Snow device

Step 3 – Launching the EC2 instance on your Snow device

Step 4 – Attaching the VNI to your EC2 instance

Step 5 – SSHing into your EC2 instance

Step 6 – Installing the AWS IoT Greengrass prerequisites into your EC2 instance

Step 7 – Installing the AWS IoT Greengrass v2 agent onto your EC2 instance

Walkthrough of what you’ve created

Controlling your EC2 instance remotely

Exploring the Greengrass components on your device

Summary

13

Deploying a Distributed Edge Computing Application

Deploying a distributed EKS cluster with Terraform

Architecture

Components

Cost

Setting up your environment

Deploying the EKS cluster

Using Terraform to push a distributed application

Components

Deploying the distributed application

Testing the application from multiple sources

Checking the user experience from your desktop/laptop

Checking the user experience from your mobile device

Cleanup

Notes

Summary

14

Preparing for the Future of Edge Computing with AWS

Business drivers for growth in edge computing

Industry 4.0

Data sovereignty and privacy concerns

Building a solid foundation for the future

Taking a systematic approach

Patterns and anti-patterns

Leveraging cloud-native services

Staying ahead of emerging AWS services and trends

Summary

Index

Other Books You May Enjoy

Preface

During the last few decades, computing models have fluctuated between drives toward centralization and distribution. At first, all compute horsepower was centralized on a mainframe, user terminals had no ability to operate independently, and networking was very simple. Then, client-server architectures took over, and corporate data centers were filled with racks full of servers that weren’t much different than the clients they served. Next, those servers were virtualized to improve utilization and manageability. Finally, the bulk of those VMs were centralized in the cloud for similar reasons. Now, we are facing demand for a new hybrid model of cloud operation – distributed edge computing, sometimes known as Industry 4.0 or hybrid edge.

This shift is driven by the incredible growth in the number of networked devices, the amount of data they produce, and advances in our ability to process this data. A new hybrid edge computing model has emerged. This book aims to demystify this emerging computing model, particularly through the lens of architecting distributed edge applications in the Amazon Web Services (AWS) cloud.

Distributed edge computing allows us to process data and make decisions closer to its source. This approach reduces response time, lowers cost, and supports new use cases. AWS, with its world-class cloud and history of innovation, is uniquely positioned to help you capitalize on the strengths of centralization and distribution.

AWS services facilitate the deployment, management, and hosting of application components wherever they are needed. The AWS strategy is about reimagining what computing can look like when it is not constrained by physical location.

Throughout this book, we will explore offerings such as AWS Outposts, AWS Snow Family, AWS Wavelength, AWS Local Zones, AWS IoT Greengrass, and Amazon CloudFront. Whether it’s processing data on a remote oil rig, processing and distributing live video, supporting the latency requirements of augmented reality, or running a full-scale data center in a disconnected environment, AWS has a solution.

After covering the what and why of distributed edge computing, this book explains the how – with hands-on exercises and an example of Infrastructure-as-Code (IaC) that you can use as a starting point for your own applications.

Who this book is for

This book is for cloud architects, cloud engineers, solution architects, and enterprise architects who are already familiar with the AWS cloud. It is particularly useful for those facing requirements to move compute, storage, database, and/or machine learning resources closer to the sources of data – but who aren’t sure how to do so in a scalable, secure, and cost-effective manner.

What this book covers

Chapter 1, Getting Started with Edge Computing on AWS, introduces the concept of edge computing and its integration with cloud computing with a focus on AWS’s strategy and tools for edge computing solutions.

Chapter 2, Understanding Network and Security for Near Edge Computing, dives into the challenges and solutions for networking and security specific to near edge computing, including private WANs, GSLB, IP Anycast, and new protocols such as HTTP/3 and QUIC.

Chapter 3, Understanding Network and Security for Far Edge Computing, covers the networking and security aspects of far edge computing, including RF communications, cellular networks, Wi-Fi connectivity, Low-powered networks such as LoRaWAN, and integration with satellite communication systems (SATCOM).

Chapter 4, Addressing Disconnected Scenarios with AWS Snow Family, introduces AWS’s Snow Family products (Snowball Edge and Snowcone) and how they address the needs of disconnected or remote computing scenarios.

Chapter 5, Incorporating AWS Outposts into Your On-Premise Data Center, introduces AWS Outposts, offering insights into how it integrates with on-premise data centers and the various deployment options such as Outposts Rack and Server.

Chapter 6, Lowering First-Hop Latency with AWS Local Zones, introduces AWS Local Zones, explaining how they reduce latency by connecting on-premise networks to local AWS resources and routing internet traffic effectively into region-based applications.

Chapter 7, Using AWS Wavelength Zones on Public 5G Networks, introduces AWS Wavelength Zones, exploring their role in 5G networks, VPC extension, and integration with other AWS services.

Chapter 8, Utilizing the Capabilities of the AWS Global Network at the Near Edge, provides an overview of the AWS Global Network, its role in edge computing, and specific services offered at its edge such as Amazon CloudFront and AWS Global Accelerator.

Chapter 9, Architecting for Disconnected Edge Computing Scenarios, focuses on designing solutions for environments with limited connectivity, discussing AWS IoT services, tactical edge scenarios, and private 5G networks.

Chapter 10, Utilizing Public 5G Networks for Multi-Access Edge (MEC)Architectures, covers the architecture of 5G-based MEC solutions, comparing Wi-Fi and 5G in terms of observability, security, and capacity, and discusses applications such as V2X and software-defined video production.

Chapter 11, Addressing the Requirements of Immersive Experiences with AWS, discusses creating immersive experiences using AWS, including applications in online gaming, connected workers, and augmented/virtual reality.

Chapter 12, Configuring an AWS Snowcone Device to Be an IoT Gateway, details the process of setting up an AWS Snowcone as an IoT gateway, from ordering and configuring the device to deploying backend services and IoT Greengrass with AWS CloudFormation.

Chapter 13, Deploying a Distributed Edge Computing Application, details the process of quickly pushing a containerized application that runs on AWS Elastic Kubernetes Service, which has elements in a core Region, AWS Local Zones, and AWS Wavelength.

Chapter 14, Preparing for the Future of Edge Computing with AWS, concludes the book by discussing the future trends in edge computing, including business drivers, foundational strategies, and emerging patterns and anti-patterns in this field.

To get the most out of this book

It is assumed that you have a basic familiarity with general IT concepts such as IP networking, virtual machines, servers, and data centers, as well as an understanding of common AWS services equivalent to the AWS Certified Solution Architect – Associate level.

Software/hardware covered in the book

Operating system requirements

AWS Command-Line Interface (CLI) >= 2.13.9

Windows, macOS, or Linux

AWS Snowball Edge Client >= 1.2

Windows, macOS, or Linux

AWS OpsHub >= 1.15

Windows, macOS, or Linux

HashiCorp Terraform >=1.6

Windows, macOS, or Linux

Kubectl >= 1.28

Windows, macOS, or Linux

If your workstation is Windows-based, it is strongly recommended that you install Windows Subsystem for Linux (WSL), specifically the Ubuntu LTS 22(x) environment available from the Windows Store. This will allow you to directly use the example commands given with no modification.

If you are using the digital version of this book, we advise you to type the code yourself or access the code from the book’s GitHub repository (a link is available in the next section). Doing so will help you avoid any potential errors related to the copying and pasting of code.

Download the example code files

You can download the example code files for this book from GitHub at https://github.com/PacktPublishing/Edge-Computing-with-Amazon-Web-Services. If there’s an update to the code, it will be updated in the GitHub repository.

We also have other code bundles from our rich catalog of books and videos available at https://github.com/PacktPublishing/. Check them out!

Code in Action

The Code in Action videos for this book can be viewed at https://bit.ly/3Ued07P

Conventions used

There are a number of text conventions used throughout this book.

Code in text: Indicates code words in text, database table names, folder names, filenames, file extensions, pathnames, dummy URLs, user input, and Twitter handles. Here is an example: “Mount the downloaded WebStorm-10*.dmg disk image file as another disk in your system.”

When we wish to draw your attention to a particular part of a code block, the relevant lines or items are set in bold:

[default] exten => s,1,Dial(Zap/1|30) exten => s,2,Voicemail(u100) exten => s,102,Voicemail(b100) exten => i,1,Voicemail(s0)

Any command-line input or output is written as follows:

aws configure \ set aws_access_key_id "your_access_key" aws configure \ set aws_secret_access_key "your_secret_key" aws configure \ set region "your_region"

Bold: Indicates a new term, an important word, or words that you see onscreen. For instance, words in menus or dialog boxes appear in bold. Here is an example: “Select System info from the Administration panel.”

Tips or important notes

Appear like this.

Get in touch

Feedback from our readers is always welcome.

General feedback: If you have questions about any aspect of this book, email us at [email protected] and mention the book title in the subject of your message.

Errata: Although we have taken every care to ensure the accuracy of our content, mistakes do happen. If you have found a mistake in this book, we would be grateful if you would report this to us. Please visit www.packtpub.com/support/errata and fill in the form.

Piracy: If you come across any illegal copies of our works in any form on the internet, we would be grateful if you would provide us with the location address or website name. Please contact us at [email protected] with a link to the material.

If you are interested in becoming an author: If there is a topic that you have expertise in and you are interested in either writing or contributing to a book, please visit authors.packtpub.com.

Share Your Thoughts

Once you’ve read Edge Computing with Amazon Web Services, we’d love to hear your thoughts! Please click here to go straight to the Amazon review page for this book and share your feedback.

Your review is important to us and the tech community and will help us make sure we’re delivering excellent quality content.

Download a free PDF copy of this book

Thanks for purchasing this book!

Do you like to read on the go but are unable to carry your print books everywhere?

Is your eBook purchase not compatible with the device of your choice?

Don’t worry, now with every Packt book you get a DRM-free PDF version of that book at no cost.

Read anywhere, any place, on any device. Search, copy, and paste code from your favorite technical books directly into your application.

The perks don’t stop there, you can get exclusive access to discounts, newsletters, and great free content in your inbox daily

Follow these simple steps to get the benefits:

Scan the QR code or visit the link below

https://packt.link/free-ebook/9781835081082

Submit your proof of purchaseThat’s it! We’ll send your free PDF and other benefits to your email directly

Part 1: Compute, Network, and Security Services at the Edge

Part One provides an introduction to distributed edge computing. It focuses on specific challenges and solutions related to networking and security in such architectures. This section is essential for understanding why you would want to use distributed edge computing as well as how you would go about managing data and network traffic efficiently and securely at the edge.

This part has the following chapters:

Chapter 1, Getting Started with Edge Computing on AWSChapter 2, Understanding Network and Security for Near Edge ComputingChapter 3, Understanding Network and Security for Far Edge Computing

1

Getting Started with Edge Computing on AWS

In recent years, a new operating model known as “edge computing” has emerged as a key enabler of digital transformation strategies across a variety of industries and organization types 1. The exponential growth of data generated by an ever-increasing number of connected devices, coupled with an insatiable appetite for real-time processing and analysis, has driven new operational models in the cloud. An example of this is the Industrial Internet of Things (IIoT). Also known as Industry 4.0, IIoT involves a fusion of traditional industrial processes with advanced techniques such as Artificial Intelligence (AI), Machine Learning (ML), and real-time data analytics.

1 Gartner Predicts the Future of Cloud and Edge Infrastructure

Due to this, “edge computing” has become a buzzword. Its meaning has been diluted through overuse by vendors who want in on the opportunities presented by this emerging model of computing. This book uses the term to mean “an architectural design that locates appropriate AWS cloud processing closer to where data is generated”.

By disaggregating AWS services closer to the source of data generation, edge computing facilitates shorter time from data generation to decision-making, reduced system costs, and enhanced data security.

In this chapter, we’re going to cover the following main topics:

The intersection of cloud and edge computingThe AWS edge computing strategyOverview of the AWS edge computing toolbox

The intersection of cloud and edge computing

Definition of cloud computing – according to NIST

Cloud computing is a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (for example, networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider (SP) interaction.

AWS can deliver client-server computing in the same way a utility delivers electricity to you – pay-as-you-go with no upfront investment. AWS achieves economies of scale that even the largest businesses struggle to compete with. This is true in obvious ways such as data center and server prices it can negotiate.

It is true in many non-obvious ways as well. AWS has millions of customers and an infrastructure that must be secured both within and without. AWS security operations are world-class because they have to be. When you pay for an EC2 instance, you’re not just getting a virtual machine. You’re also getting that world-class security operations team protecting its data physically, but also against – for example – a Distributed Denial of Service (DDoS) attack. Those are two things that are very costly to do in your own data center.

Your EC2 instance is also sitting right next to a panoply of additional services it can consume. Storage, networking, AI/ML, databases, analytics – the list is long2. It is this proximity to all that computing power and value-add services AWS provides that pushes architectures more and more toward centralization. The more things you move in-region, the greater the benefit, and thus the flywheel of migrating things into the AWS cloud.

2 List of AWS Services Available by Region

Great – so what are the problems with centralizing all applications into an AWS region? Well, they fall into four categories: physics, economics, regulatory compliance, and good old-fashioned organizational inertia.

Physics

The speed of light is fast, but finite – a rule of thumb is to expect a 1 millisecond of latency for every 100 km of distance a signal has to travel. Keep in mind that this is rarely measured in a straight line on a map. The following diagram illustrates a common situation. In this case, a sensor is located in Oxford – just under 100 km from London:

Figure 1.1 – Latency incurred by physical distance and indirect routing

Notice, however, that the latency from the sensor to its compute resources in the AWS region in London is 50 milliseconds, not 1. This is due to the fact that it is communicating over a mobile network using 4G/LTE. The architecture of those networks requires what is known as a backhaul to a central location where the mobile network peers with the internet. Further, due to the vagaries of how data roaming works in 4G/LTE, 40 milliseconds just to reach the internet is not unusual. Then, the packets need to travel across the internet from wherever that central location happens to be to the London region.

Take the example of a cloud-based system that manages and monitors 1 million smart cars. A sensor in a car that can detect a crash is about to occur needs a decision made quickly by a compute resource physically close to it. Waiting for a response from the remote compute in the cloud, approx. 50 milliseconds, may well be too slow. This is especially true if multiple sensors need to send in data for a multivariate decision to be made.

In such cases, physically distributing where that decision is made closer to where the sensors are is the only viable approach.

Economics

Bandwidth can be quite expensive, especially in remote locations. Sometimes, it makes sense to build aggregation points into a system to preprocess data locally before transmitting just the important parts back to a datastore in an AWS region.

Suppose an ML model is being trained on the words people say into microphones in remote locations. A digital recording of a person saying the words “bandwidth can be quite expensive” in M4A format is about 100 KB, while a text file containing those words is only 32 bytes. If all our ML model cares about is the text, we can reduce our bandwidth costs by 3,000-fold by doing that conversion in the field. If the full-sized digital recording needs to be retained, perhaps for legal reasons, it can be queued up on a storage device and physically swapped out once a month as it fills up.

Regulatory compliance

Data privacy and sovereignty requirements vary across political entities. Compliance regimes such as the EU’s General Data Protection Regulation (GDPR) impose constraints upon where a given piece of data associated with an individual is physically located. For instance, a US-based company that runs its applications in the AWS cloud might decide it needs to keep records associated with EU data subjects within the physical boundaries of a country where AWS does not have a region.

Other times, national sovereignty comes into play. Countries often have special rules regarding emergency services systems, such as 911 in North America or 112 in Europe. It is not uncommon that such government-operated applications must certify that it is not possible for another country to disable them. This generally entails keeping the physical infrastructure within the borders of said country.

Inertia

Since the inception of AWS in 2006, some organizations (or individual departments within them) have taken a wait-and-see approach – maybe the cloud will just go away if they ignore it. Sometimes there are trust issues, especially when implementing hybrid cloud solutions that involve on-premise components. While this becomes less common every year, such inertia is still encountered at times.

So, given all of that, how is AWS addressing these challenges?

The AWS edge computing strategy

The combined effects of physics, economics, regulatory compliance, and organizational inertia have led to customers implementing hybrid architectures that require them to continue operating a full data center stack – even if all they want to do is host a few virtual machines.

An example of such a situation is depicted next. In this instance, the customer has built a cloud-native application making full use of the benefits afforded by AWS managed services. This application interacts with their ERP system to provide real-time insights from their manufacturing plants. However, because their ERP system must reside in a particular geography, they have retained a small physical footprint in their corporate data center. Their developers have to interact with on-premise components using different APIs than they use for cloud-based elements. Their operations team has to use a different set of tools to manage those resources, and what’s worse, they have to care about the underlying substrate to a far greater degree than they do in the cloud:

Figure 1.2 – Hybrid cloud architecture

The AWS edge computing strategy is intended to simplify this situation for customers. It does so by extending AWS’ managed service offerings to physical locations outside of the core regions – to wherever customers need them.

Take the example of AWS Lambda functions. While you are likely familiar with running them in a region, they can also be run in one of AWS’ 400+ points of presence for ingress/egress to its global backbone. You can take this further and run a function in your on-premise data center(s) on an AWS Outposts server or in the middle of nowhere on an embedded device such as a smart camera.

Examples of situations where this extension of AWS managed services farther from the regions can help include:

An autonomous Unmanned Aerial Vehicle (UAV) circling over a factory scanning the perimeter for human faces and comparing them to a list of employeesAn offshore oil rig with a developing problem that local maintenance staff need to be alerted to – and even told which valve needs to be turned and at how many degrees by a digital overlay they see through their smart glassesAn AR headset worn by a worker deep underground in a mine shaft being assisted by a geologist on the other side of the worldA soldier observing an enemy position using a device that delivers inferences based on petabytes of cloud data to enhance that soldier’s situational awarenessIn the parking lot outside of State Farm Stadium onboard a semi-trailer that acts as a miniature data center on wheels where workers are editing and producing the live video feed for Super Bowl LVII

The AWS edge computing strategy focuses on customer use cases. These are grouped into families, four of which this book will address – DDIL, MEC, immersive experiences, and IIoT.

Disconnected, denied, intermittent, or low-bandwidth

While the specific term Disconnected, Denied, Intermittent, or Low-bandwidth (DDIL) emerged from the US Department of Defense, it captures well the circumstances faced by a group of use cases seen across industries. It refers to edge computing in situations where network connectivity is unreliable, constrained, or completely unavailable. In such scenarios, traditional cloud-based computing approaches might not be feasible, and edge computing can play a crucial role in enabling data processing and decision-making at the source. Services such as AWS Snowball, AWS Snowcone, and AWS IoT Greengrass can help in these cases.

Disconnected

In environments where there is no network connectivity at all, devices must be able to operate independently, processing data and making decisions locally. This typically requires the implementation of efficient data storage, processing capabilities, and pre-trained ML models to allow the device to function effectively without access to the cloud. These are usually the same situations where standard data center environmental controls such as HVAC, particulate filtration, and physical security measures are lacking.

As an example, an energy company is conducting a survey for oil in a remote desert location. They are driving a special kind of truck, known as a thumper, that shakes the ground with hydraulically driven metal pads. The shock waves travel through the earth to instruments known as geophones. The data thus collected must be analyzed to produce a three-dimensional map of what is going on underground. Local ruggedized computers can be used for this first step, but the second step requires a highly trained and experienced geologist to make a judgment call about what is seen in this map – in a similar way that a radiologist is needed to properly analyze an x-ray image.

While they may be able to make voice calls or transmit data via satellite connectivity, this is both expensive and very low throughput – measured in kilobits per second. Wouldn’t it be great if those determinations – inferences, in ML parlance – could be made on the spot? It would be even better if every time such a team came back into a place with better connectivity, the data they collected automatically synchronized with the cloud. This would constantly improve the experience of the system. In AI parlance, this is known as training. Such a model would necessarily be quite large, and the AWS cloud is the perfect place for this training to happen.

While most AWS services are dependent upon consistent high-speed connectivity to the AWS control plane, AWS Snow Family is different. These devices maintain their own local control- and management-plane services yet expose the same APIs and management constructs as their in-region equivalents.

Denied

In certain situations, network access can be actively denied or restricted due to security concerns, regulatory requirements, or other factors. Edge computing solutions must be able to adapt to these constraints by offering secure and compliant data processing and storage capabilities.

The classic example is forward-deployed military command posts. While in hostile territories, they may need to limit network connectivity to minimize the risk of data interception, cyber-attacks, or simply exposing their presence to the enemy. In such cases, edge computing devices can process data locally, ensuring mission-critical information remains secure and accessible. Further, pre-trained ML models can provide insights based on data gathered from thousands of disposable vibration sensors air-dropped across a hostile area – giving commanders real-time information about enemy troop movements. A combination of AWS Snow Family and AWS IoT Greengrass is ideal when such needs arise.

Intermittent/low-bandwidth

In scenarios where network connectivity is sporadic or limited, edge computing devices must be capable of managing data synchronization, processing, and storage during periods of limited connectivity, while also handling potential data conflicts and inconsistencies that might arise. AWS IoT Greengrass is perfect for a store-and-forward model such as this.

Autonomous vehicles operating in urban areas may experience intermittent connectivity due to factors such as network congestion or physical obstructions. Increasingly smaller and more powerful single-board computers can enable these vehicles to process sensor data locally and make real-time decisions, regardless of the network’s reliability.

Rural healthcare facilities may have limited bandwidth, making it difficult to send large medical imaging files to the cloud for analysis. Much like the situation discussed with oil exploration, local inferences can be made in time-critical situations. Large datasets can be automatically synchronized by physical transport as time permits using members of AWS Snow Family.

Multi-access edge computing

Multi-access Edge Computing (MEC) is an innovative paradigm that brings computation and data storage capabilities closer to the edge of mobile networks, enabling real-time processing and ultra-low latency for a wide range of applications.

Mobile network operators

A Mobile Network Operator (MNO) is a telecommunications company that provides wireless voice and data services to its customers by owning and operating a cellular network infrastructure. MNOs are responsible for the deployment, maintenance, and management of the network, including radio access, core network components, backhaul connections, and interfaces with the internet or landline networks.

MNOs purchase radio frequency spectrum licenses from government authorities to transmit their signals and provide services such as voice calls, text messaging (SMS), multimedia messaging (MMS), and mobile internet access (3G, 4G, and 5G) to subscribers using mobile devices, such as smartphones and tablets.

Some of the largest and most well-known MNOs globally include Verizon based in North America, Vodafone based in Europe, and KDDI based in Japan. These companies play a crucial role in the telecommunications ecosystem by connecting millions of users and enabling seamless communication and data access across various geographic locations.

Emergence of 5G

Most MNOs have upgraded their networks from 4G/LTE to 5G within major metropolitan areas. However, more remote areas of the same networks are still serviced by 4G/LTE. The delay has been economic. The market for mobile devices has largely been captured. Customers want 5G but aren’t willing to pay extra for it. Therefore, MNOs that do roll out 5G can steal customers from ones that don’t – which ultimately means 5G rollout occurs primarily in areas of highest demand and highest competition.

This is starting to change as MNOs realize they can leverage the same upgrades they did for 5G to capture entirely new revenue streams. Historically, MNO Central Offices (COs) have been small facilities filled with purpose-built hardware for the Radio Access Network (RAN) only, with backhauls to a regional office that is an actual data center – a relic of decades-old copper-wire telco networks:

Figure 1.3 – 4G/LTE backhaul model

However, COs for an MNO moving to 5G have to be transformed into small data centers to support Network Functions Virtualization (NFV) and the distributed nature of 5G:

Figure 1.4 – 5G network distributed model

At the same time, more and more devices are coming online with demand for applications that require more bandwidth or do not tolerate the jitter and latency that inevitably occurs when traffic is backhauled and only then routed over the internet to a cloud provider.

COs become multitenant data centers

Enter MEC. In this model, MNOs use their existing physical footprint to provide compute and storage capacity for customer applications in the same way that cloud providers do – only much closer to the mobile devices consuming those applications. Average latency from mobile device to application is reduced to single digits, while 5G network slicing can ensure a level of jitter, security, and throughput that meets customer needs on a per-application basis:

Figure 1.5 – MEC example

MEC pushes significant compute resources close to the mobile devices without requiring any change to said devices. Emerging use cases such as Virtual Reality (VR), Augmented Reality (AR), smart cities, and robotics benefit from lower latency. Ever-increasing demands from video streaming apps exploit MEC for pre-staging content to reduce upstream bandwidth consumption. AI/ML systems can deliver inferences closer to real-time than if bulk observations had to be shipped back to a central location.

AWS Wavelength is an end-to-end MEC service built in partnership with MNOs around the world. It allows you to activate a special type of Availability Zone (AZ) that can host instances or containers, and participate in a Virtual Private Cloud (VPC) just like a region-based AZ. Further, services such as AWS Outposts, AWS Local Zones, and AWS EKS or ECS Anywhere can be used to build your own MEC platform.

Immersive experiences

The term “immersive experiences” includes AR and VR applications, both of which present a unique set of requirements foredge computing.

AR

Not all immersive experiences involve a user wearing an expensive helmet and gloves like something out of a sci-fi movie. In fact, the majority require only a mobile device such as a phone or tablet that users are accustomed to. It’s likely they privately own such devices already. AR simply means an application that overlays digital information onto your physical environment – typically using technologies such as the Global Navigation Satellite System (GNSS) and/or Wi-Fi Access Point (AP) data to triangulate your current position.

The most common example of an AR application you probably use every day is something such as Apple Maps to help you navigate. Long gone are the days of paper maps and stopping at gas stations to ask for directions. Most cars can now give you verbal directions, and some can even do things such as show a flashing red arrow on the windshield’s heads-up display telling you it’s time to make a right turn. There are specialized versions of such apps – for example, a maintenance worker can receive location-specific information when navigating a large industrial facility. Amazon’s own fulfillment centers make heavy use of location-based AR to guide workers to the products they need to pack for a certain order.

AR technology can also enhance customer experiences in retail and e-commerce by allowing users to virtually try on products or see how items will look in their home environment. For example, customers can use their smartphones to view a piece of furniture in their living room or try on clothes virtually, helping them make more informed purchasing decisions and reducing product returns.

Educational applications are becoming AR-enhanced by overlaying digital information, such as text, images, or animations, onto physical objects or environments. For instance, students learning about anatomy can view 3D models of organs overlaid on a physical mannequin, or field technicians can receive real-time instructions and guidance when repairing complex machinery.

VR

The first place your mind probably goes when you think of the term “VR” is video gaming or entertainment, and for good reason. VR has revolutionized both industries by providing fully immersive experiences that transport users to virtual worlds. Players can engage in interactive adventures, explore fantasy landscapes, or participate in competitive sports simulations, all while feeling as though they are physically present within the game environment.

Simulation for training purposes is another area where full VR is in use today by a variety of industries. As an example, VR can provide medical professionals with a safe and controlled environment to practice surgical procedures, diagnostic techniques, or patient communication skills. By replicating real-world scenarios, VR allows trainees to build their expertise and confidence without risking patient safety or well-being.

Another use case may include engineers who are taking advantage of VR to enhance both the quality of their products and the time it takes to design them. Architects, designers, and engineers can now create and explore 3D virtual models of their projects before construction or production begins. This immersive visualization also helps non-engineering stakeholders identify potential design flaws, optimize layouts, and gain a better understanding of the finished product, ultimately saving time and resources.

Specialized requirements

Immersive experiences rely heavily on real-time user interactions, and any delay or lag can significantly degrade the user experience. AWS edge computing services can help to minimize latency by processing data closer to the source, thereby reducing the time taken to transmit data between the user’s device and the data center. Services such as AWS Wavelength and AWS Local Zones bring AWS services closer to end users, ensuring low-latency processing.

AR/VR applications often involve the transmission of large volumes of data, including high-resolution graphics, audio, and sensor inputs. This requires substantial network bandwidth to ensure seamless and immersive experiences. 5G devices are capable of as much as 10 Gbps of throughput in both directions – but generally only to the first hop. AWS Wavelength allows customers to capitalize on this fact by placing instances and containers directly at that first hop. Further, services such as AWS IoT Greengrass and AWS Snow Family enable local data processing and reduce the amount of data transmitted to the cloud in the first place.

As these applications grow in popularity and complexity, the underlying infrastructure must be able to scale accordingly. AWS provides scalable edge computing solutions that can adapt to the changing demands of AR/VR workloads, ensuring optimal performance and resource utilization. Finally, immersive experience applications often involve sensitive user data, making security a critical concern. AWS edge computing solutions incorporate robust security features, such as encryption, access control, and full auditability, to protect user data and maintain compliance with industry regulations.

IIoT

IIoT refers to the integration of internet-connected sensors, devices, and machinery in industrial settings. This includes manufacturing plants, utilities, oil and gas, transportation, and agriculture. IIoT leverages advanced technologies such as big data analytics, ML, and cloud computing to collect, analyze, and transmit data from various sources, allowing for real-time decision-making, process optimization, and improved operational efficiency. By connecting industrial assets and systems, IIoT enables organizations to monitor performance, predict and prevent equipment failures, and drive overall productivity and innovation within the industry.

Message Queuing Telemetry Transport

Message Queuing Telemetry Transport (MQTT) is a lightweight, open source, and widely adopted messaging protocol designed for limited capacity networks, often used in Machine-to-Machine (M2M) and IoT applications where a low code footprint is required and/or network bandwidth is at a premium:

Figure 1.6 – MQTT’s publish/subscribe model

MQTT operates on a publish/subscribe model, which means that devices (clients) can publish messages to a topic on a central broker, and other devices can subscribe to the broker to receive these messages. This model allows for efficient data transfer and real-time updates, without requiring a continuous connection between devices.

MQTT is renowned for its efficient use of the network, ability to operate well in unreliable environments, and ease of implementation, making it an excellent choice for edge computing, mobile applications, and other scenarios where network conditions may be challenging.

Lastly, MQTT also supports a “last will and testament” feature that allows a client to publish a message when it disconnects ungracefully. This can be useful for monitoring and managing the status of devices.

By default, MQTT uses TCP ports 1183 (unsecured) and 8883 (TLS encrypted) for reliable transport over standard IP networks or the open internet. Most IIoT devices sold these days can natively use the MQTT protocol to communicate with brokers. However, this is not always the case.

Legacy IIoT networking technologies

Legacy industrial automation systems relied on a variety of networks and protocols to facilitate communication and control among devices, machines, and systems. Examples include MODBUS, PROFINET, EtherCAT, and Fieldbus. These networks were typically closed systems – islands unto themselves. They were also developed at a time when such devices were limited in number and directly connected via serial cable:

Figure 1.7 – Legacy poll/response IIoT protocols

This is why they typically use a poll/response protocol architecture. Unlike the publish/subscribe and report-by-exception techniques MQTT uses, these protocols require a server to periodically query each device. Those devices, in turn, respond with the requested data.

Poll/response protocols have a number of disadvantages compared to MQTT:

Efficiency: Legacy poll/response protocols require the client to continually ask (poll) the server for data. This can lead to excessive network traffic and wastage of bandwidth, especially when dealing with a large number of devices. MQTT, on the other hand, only publishes updates by exception. For example, an MQTT-based temperature sensor will only publish a new reading if the temperature changes – in a poll/response model, there could be hundreds of duplicate readings sent over the network.Scalability: Legacy protocols struggle to scale such that they can handle the high number of devices and data points typically found in today’s IIoT environments3. MQTT was designed with scalability in mind and can easily handle communication between a large number of devices.

3 How MQTT is Helping Support the Digital Transformation

Real-time updates: Legacy poll/response protocols may not provide real-time updates as they work on the request/response model. With MQTT, updates can be pushed immediately when the data changes, enabling near real-time communication.Network resilience: Poll/response protocols offer no guarantee that the data was received. MQTT is designed to work over unreliable networks, and with features such as Quality-of-Service (QoS) levels and “last will and testament,” it ensures data delivery even in challenging network conditions.Security: Many legacy protocols were not designed with security in mind and do not include built-in security features such as encryption or outbound-only connection initiation, making them vulnerable to cyber-attacks. MQTT uses TCP/IP and supports modern security mechanisms such as SSL/TLS for secure data transmission. MQTT also does not require inbound TCP/UDP ports on clients to be open, as connections are always initiated from the client to the broker.State awareness: With poll/response, the server does not know the state of the client, while the MQTT broker keeps track of client sessions and their subscriptions, improving the overall awareness of the system’s state.Flexibility: Legacy protocols may not support diverse data types and structures, limiting flexibility. MQTT, on the other hand, is data-agnostic and can support various data types and complex nested structures, making it more versatile for modern IIoT applications.

Despite these advantages, the older devices do continue to function and often represent a significant capital investment. It is unusual for IIoT deployments to call for a total replacement of those past capital expenses.

Supervisory Control and Data Acquisition

Supervisory Control and Data Acquisition (SCADA) systems are used in industrial settings to monitor and control processes and infrastructure in various industries – including manufacturing, utilities, oil and gas, water management, and transportation. SCADA systems enable real-time data collection and processing from remote equipment, allowing operators to supervise and manage industrial processes from a centralized location:

Figure 1.8 – Typical SCADA system architecture

A typical SCADA system consists of several components, including the following:

Remote Terminal Units (RTUs), Intelligent Electronic Devices (IEDs), or Programmable Logic Controllers (PLCs)

These devices are responsible for collecting data from sensors and controlling equipment at remote sites. They communicate with the central SCADA system to transmit data and receive control commands.

Sensors and actuators

Sensors measure various process parameters, such as temperature, pressure, and flow rate, while actuators perform control actions, such as opening or closing valves and adjusting motor speeds. These devices interface with the RTUs or PLCs to provide data and receive control signals.

Human-machine interface (HMI)

An HMI is a graphical interface that allows operators to interact with the SCADA system, visualizing process data, and issuing control commands. HMIs typically display real-time data in the form of charts, graphs, and schematics, enabling operators to monitor system status and make informed decisions.

Historians

A historian is a system that holds an archive of past data samples taken from PLCs, RTUs, sensors, actuators, and the SCADA system itself. These are similar to Time Series Databases (TSDBs) such as CrateDB or TimescaleDB.

SCADA server

The SCADA server hosts the software that manages data collection, processing, and storage. It also handles alarm management, event logging, and reporting functions. The software enables operators to configure the system, define control logic, and analyze historical data.

AWS integration with SCADA systems

While there has been an explosion in the number of inexpensive sensors that natively speak IoT protocols such as MQTT, doing IIoT with AWS does not entail a complete replacement of existing systems. Services such as AWS IoT SiteWise Edge help customers interface with these protocols to merge existing data sources with new ones. In fact, the analysis of historical data from these systems helps customers realize value more quickly than starting from ground zero. AWS IoT TwinMaker can, in turn, consume this normalized data to produce digital twins of industrial operations.

When store-and-forward capabilities are desirable, or ML inferences need to be made locally, AWS IoT Greengrass is an ideal solution. It can run on your own hardware, or hardware provided by AWS in the form of AWS Outposts and AWS Snow Family.

As use cases go, DDIL, MEC, AR/VR, and IIoT all seem rather distinct from one another. How does AWS go about taking a unified approach to helping customers with all four? This is what we’ll cover in the next section.

Overview of the AWS edge computing toolbox

The AWS edge computing strategy