Book Image

Simplifying Hybrid Cloud Adoption with AWS

By : Frankie Costa Negro
Book Image

Simplifying Hybrid Cloud Adoption with AWS

By: Frankie Costa Negro

Overview of this book

The hybrid edge specialty is often misunderstood because it began with an on-premises-focused view encompassing everything not running inside the traditional data center. If you too have workloads that need to live on premises and need a solution to bridge the gap between both worlds, this book will show you how AWS Outposts allows workloads to leverage the benefits of the cloud running on top of AWS technology. In this book, you’ll learn what the Edge space is, the capabilities to look for when selecting a solution to operate in this realm, and how AWS Outposts delivers. The use cases for Outposts are thoroughly explained and the physical characteristics are detailed alongside the service logical constructs and facility requirements. You’ll gain a comprehensive understanding of the sales process—from order placement to rack delivery to your location. As you advance, you’ll explore how AWS Outposts works in real life with step-by-step examples using AWS CLI and AWS Console before concluding your journey with an extensive overview of security and business continuity for maximizing the value delivered by the product. By the end of this book, you’ll be able to create compelling hybrid architectures, solve complex use cases for hybrid scenarios, and get ready for your way forward with the help of expert guidance.
Table of Contents (14 chapters)
Part 1: Understanding AWS Outposts – What It Is, Its Components, and How It Works
Part 2: Security, Monitoring, and Maintenance
Part 3: Maintenance, Architecture References, and Additional Information

Hybrid architecture tenets

Now that we understand AWS and its purpose, it is time to show how it fits in the so-called hybrid space. As we outlined in the first section, this concept has been redefined since it was initially coined with a vision originating from the data center to the outside world, where the cloud infrastructure was out there somewhere. From this perspective, the edge was anything outside the data center, with the cloud providers being just one of the alternatives for running a compute.

As the advent of the cloud gained traction, solidified, and became the de facto standard as an IT choice for any business to run its workloads and applications, the movement now originates in the cloud reaching out into the world, where the edge nodes are. Any given data center now represents just one of these nodes where compute processing power takes place.

When designing a product to address specific use cases or be fit for certain purposes, one of the strategies is to define the tenets of the architecture. Simply put, the tenets express a belief about what is important or guide us on how to make decisions, which is vital in helping teams to remain focused on what is most important and move quickly as we scale and deliver on our promises. Most good tenets tell you the how and not the what.

If correctly defined, tenets help to resolve critical decisions by lowering the cognitive load, promoting consistent decision-making over time and across teams, and effectively educating all involved personnel on the thinking and approach to a problem, which, in turn, produces richer feedback. It is a relieving mechanism to gain velocity in delivering a product and a guiding structure to keep the process on track, avoiding derails.

To define some tenets for the hybrid space, enterprises started thinking about the challenges involved in this space and how to address them. Any solution has to be a mechanism driving hybrid adoption and must demonstrate how it meets business demands. It needs to have a clear focus on the business problems that it tries to solve and uniquely describe the use cases it is best suited for.

Modern hybrid cloud infrastructure is starting to sediment around some tenets. Here is a list of commonly identified beliefs for a hybrid cloud architecture:

  • Inherently secure
  • Reliable and available
  • Simplicity of use
  • Build once and deploy anywhere
  • Leverage existing skill sets and tools
  • Same pace of innovation as running in the cloud

Here, we can see the power of the tenets in driving decision-making. For example, if we are confronted with a security decision with multiple options on how to address the requirements, the tenet on simplicity of use comes into play to help rule out solutions with a high level of complexity. This can be a tremendous advantage within technical debates.

Tenets are fundamental to narrowing down our choices by creating these soft boundaries on how to select, in this example, candidate security solutions and approaches. Only then can the debate focus on what to do to utilize any selected choices. Without tenets, there could be turmoil within the process of deciding the ways of doing something, where any decision brings the risk of discomfort and disagreement from some unfavored party.

Now that we have our bedrock, let’s frame Outposts into the hybrid space to see how it fits:

  • Inherently secure: AWS says security is paramount and that holds for every AWS product. Any AWS product is secure by default, and it does not grant full, unlimited, or public access unless strictly told to do so. AWS Outposts is no different.

Let’s showcase features geared towards making AWS Outposts, as any AWS solution, fully furnished with security capabilities.

On the physical structure, AWS Outposts features a built-in tamper detection, which is powered by the AWS Nitro System. The Nitro System is a set of peripheral component interconnect express (PCIe) cards purposely built to offload tasks related to security, network, and storage to be executed by dedicated ASICs and spare CPU cycles.

Outposts comes in an enclosed rack with a lockable door and features the Nitro Security Key (NSK), a physical encryption module with destruction available that is equivalent to physical data destruction (data shredding on the hardware).

In the data protection realm, AWS Outposts comes with encryption at rest enabled by default. Amazon Elastic Block Store (EBS) volumes are encrypted using AWS Key Management Service (AWS KMS), where customers store their customer master keys (CMKs). For Outpost servers, the Amazon EC2 instance store is encrypted by default. Moreover, encryption is required. You cannot create unencrypted EBS volumes.

All data traffic is protected by enforcing encryption in transit. Any communications between an Outpost and its AWS Region use an encrypted set of VPN connections called a service link. User data, management, and application traffic fall under the responsibility of the customer, but AWS strongly advises using an encryption protocol such as Transport Layer Security (TLS) to encrypt sensitive data in transit through the local gateway to the local network.

When an Amazon EC2 instance is stopped or terminated, any memory space allocated to it is scrubbed (as in, set to zero) before it can be reallocated to any other instance. The data blocks of storage are also reset.

In the IAM realm, AWS leverages the capabilities of its IAM service. Authentication and authorization are handled by this service. As mentioned, by default, IAM users don’t have permissions for AWS Outposts resources and operations. Any permissions must be explicitly granted by attaching policies to the IAM users or groups that require those permissions.

Being a managed service, AWS Outposts operates under the strict AWS global network security procedures that are described in the Overview of Security Processes white paper available at ( API calls to interact with AWS Outposts are encrypted with TLS and all requests must be signed using an access key ID and a secret access key associated with an IAM principal.

  • Reliable and available: Reliable can be characterized in short as something that may be relied on and is fit to be depended on and trustworthy. Available can be something that is said to be capable of producing the desired effect. Using these dictionary definitions as lenses, let’s glance at how AWS Outposts takes shape.

The rack comes with all the expected bells and whistles highly available. Redundancy can be identified across power components and networking gear. When it comes to server units, it is a strategy derived from customer availability requirements. AWS recommends the allocation of additional capacity, especially to operate mission-critical applications. One strategy is to order the rack with a built-in capacity to support N+1 instances for each instance family to enable recovery and failover if there is an underlying host issue.

When you create AWS Outposts, it is tied to a single Availability Zone in a given Region. The control plane exists in the Region and is fully managed by AWS. When designing for failure, benefitting from multiple Availability Zones that exist in any AWS Region, the strategy should involve having individual racks associated with distinct Availability Zones.

This approach can be stretched even further. Designs may take into consideration different power grids, but AWS recommends at least dual power sources in a given location. AWS may also consider different physical locations or place the racks apart in different buildings or a Metro area. Certainly, multiple network connections are something to be strictly enforced, optimally using different providers and making sure they operate using different circuits to deliver communication ports at the customer site.

Lastly, you can leverage EC2 placement groups to make sure compute instances are placed onto distinct hosts in a given rack or distinct racks. This capability works in the same manner as in the Region, supporting cluster, partition, or spread placement groups, where a cluster strategy requires a single rack and partition and spread strategies require multiple racks.

Naturally, the application architecture must offer some high availability or fault tolerance feature – otherwise, it will solely rely on server hardware redundancies and mechanical or electronic components in the Mean time between failures (MTBF). Some third-party solutions promote the ability to replicate operating systems and their changes using tracking features such as Changed Block Tracking (CBT), but those must be tested and validated by the customer.

  • The simplicity of use: The AWS Outposts experience is designed to be frictionless and streamlined as much as possible. Starting with the outstanding status of a managed service, customers don’t have to touch the hardware, they don’t need to configure anything on the rack, they don’t have to connect to serial ports or management modules, and they don’t have to replace spare parts. AWS is fully responsible for carrying out these tasks. Customers order the rack, and once it is deployed and paired with its peered Region, they begin consuming its resources. Period.

This may appear to be a simple concept but it is huge. If you ever used traditional hardware in your IT department, you certainly know everything that comes associated with it. The selection process, while it can be compared to a fun exercise of choosing food from a menu at the restaurant, frequently may turn into a nightmare of comparing long lists of specifications and features because procurement and purchasing departments always want apple-to-apple comparisons.

Okay, let’s say you survived the quest to find a cheaper price for commoditized hardware that should, ideally, use the same components and deliver the same performance with a similar set of technical specifications, so much so that they could be considered interchangeable. You order it, you get your estimated delivery date, it arrives on site, and now the fun begins.

The task of receiving boxes, unpacking and seating racks, racking individual components, setting up wires to bring power and cables to enable the network, and starting up, configuring, and provisioning the services is all yours unless you buy vendor services for that purpose. Again, let’s say it all goes well. Now, it is time to put it to the test, starting by carving out resources and interoperating with other components. All good – it worked. End of story? No, not at all!

Now, it is time to maintain the infrastructure. The significant overhead of patching and upgrading the equipment and managing against a complex compatibility matrix across various hardware and software components is risky, potentially disruptive, time-consuming, and often nerve-racking. As time goes on, the cycle continues, only to start all over again when the next hardware refresh period kicks in.

None of these is an issue for AWS Outposts, as you are always dealing with AWS. Procurement is tremendously simplified – the business has decided to move to the cloud using AWS technology, but there is nothing to compare or match. Delivery, installation, power up, and startup are operated and supervised by AWS.

All the necessary information, preparation, and site readiness are organized in advance to make sure everything works neatly. Technicians are sent on site to verify whether network configurations are correct and automated processes are working as expected. Service readiness can be achieved in a matter of hours by the time Outposts is brought to life. By the time the bootstrap is finished and the logical Outpost ID is up and running, you can jump into AWS Console and begin using your AWS Outposts rack. Don’t worry: AWS takes care of maintenance.

  • Build once, deploy anywhere: We are now using Outposts. How does this solution measure against this tenet? As mentioned before, it is not AWS-like infrastructure – it is AWS-downscaled infrastructure. Its design, components, technical solutions, and capabilities are the same as those used inside AWS Regions. This is mind-boggling – by ordering AWS Outposts, you are effectively bringing a piece of AWS to your site, for your use, at your disposal.

That translates into the power of consistency. If you have ever used AWS in the region, it is the same experience with AWS Outposts—same console, same concepts, same configurations. If you provision EC2 in the region, it is the same EC2 provisioned in the rack. If you leverage EC2 service capabilities, they will likely be available to be used in the rack. A service that is available on Outposts has very similar capabilities when compared with the same service operating in a region.

While, understandably, a service running on Outposts will hardly have all the feature sets available in the region, it is absolutely and truly the same foundation. The only difference is the natural constraint of operating within the limits of the Outposts hardware. Within a region, we have that sense of virtually unlimited hardware and the hundreds of AWS services available and connected using gigantic network pipes. Within the confines of an Outposts rack, other restrictions and considerations may apply.

Physical limitations aside, it is powerful to be able to build applications using AWS technologies and solutions present on Outposts and deploy them seamlessly to any rack on any location. No adaptations, changes, conversions, or adjustments are needed. It runs on a given Outposts SKU and it will run on any similar Outposts, anywhere, anytime. It runs on Outposts, so it will run even more comfortably in the Region.

  • Leverage existing skill sets and tools: This tenet relates to productivity and the DevOps community. There are challenges associated with the usage of different APIs and tools to build apps for the cloud and on-premises environments, and then the need to re-architect them to work in other environments. The question arises on how to build applications once, run on-premises or in the cloud using the same APIs and tools, and use the wide range of popular services and APIs that you use in the cloud for the applications that run on-premises.

Enter AWS Outposts. You build on Outposts the same way you build in the region. You use the same AWS Console to view and manage their resources, whether those resources and services are in the AWS cloud or on-premises. You can use the same AWS CLI and SDKs to run and deploy applications and use the same API endpoints to send requests to applications running in the AWS cloud.

AWS services commonly used by applications running in the cloud are also available when these are deployed on Outposts. Foundational components such as IAM policies and permissions, VPCs, security groups, and access control lists work the same way as in a Region.

API calls will automatically be logged via AWS CloudTrail and tools such as AWS CloudFormation, Amazon CloudWatch, AWS Elastic Beanstalk, and others can be used to run and manage applications running on-premises just the same as they are used for cloud workloads today. If you already use CloudFormation, existing templates will also work with minor tweaks.

Businesses are very sensitive to the impacts of productivity. The time to market is vital, as the pace of innovation is tremendous. Competition is fierce and developers must constantly be launching new features and improving applications. Development cycles have been shortened. Multiple commits are made per day, resulting in multiple daily build cycles, often in the magnitude of tens but stretching to hundreds, even thousands.

Outposts can rightfully make the case for increased development productivity because it is a genuine portion of AWS tech reaching out to the customer premises for their private use and not a venture of multiple suppliers and vendors compounding a solution that is delivered to a customer to act as a bridge between both locations.

  • Same pace of innovation as in the cloud: Here, we consider the challenges associated with supporting the business. Inefficiency in IT results in poor Return on Investment (ROI) for technology investments and slower business growth. As a result, on-premises environments lag behind the cloud when considering the pace of innovation. In a fast-paced, ever-changing environment, this can ultimately appear to be the death knell for a company.

How do we leverage new technology innovations for better and faster deployment of services and deeper business insights? How do we enable innovation in your on-premises environments using services that exist in the cloud?

The answer can only be to have a solution at the edge that evolves in close parity with its parent cloud. AWS Outposts reaches a breakthrough, being the only solution that employs the same foundations as its parent cloud company and being able to evolve in close contact with AWS’s latest data center advancements.

  • A truly consistent hybrid experience: This is the statement coalescing the AWS vision about hybrid environments, which ultimately led to the development of AWS Outposts, and it excels in this aspect. If you look at other cloud providers and their proposed solutions to conquer the edge, look at how many can proclaim to be as seamless, comprehensive, and integrated as Outposts.

Are they designing and manufacturing their hardware infrastructure? Do they use the exact same technologies as used in their data centers? Outposts can rightfully make these claims and they hold on both counts. To date, AWS Outposts is an unmatched product when it comes to fulfilling the promise of the everywhere cloud.

Now that we have explored the concept of tenets and how they can be helpful to drive, among other things, the development of a product, let’s go ahead and see how AWS Outposts as a solution match the tenets for a hybrid space with the help of some use cases.