How to maintain availability with multiple AWS accounts

Modern Digital Applications with Lee Atchison

In this episode, we know that using multiple availability zones helps increase your application availability and resiliency by distributing our application across multiple disperse data centers. But did you know that availability zones don’t necessarily give you the separation you expect? In fact, it is entirely possible to have two instances of a service running in two distinct availability zones, but actually have them running in the same data center, in the same physical rack, and possibly even on the same physical server! How can this be? And even more importantly, how can we avoid it? The answer involves understanding how availability zones work and how they are structured.

And then, one of the oddest cloud services created is also one of the first cloud services. Before AI and before machine learning, humans actually powered a part of the cloud.

This is, Life with Multiple AWS Accounts.

Links and More Information

The following are links mentioned in this episode, and links to related information:

• How to maintain availability when using multiple AWS accounts (https://www.infoworld.com/article/3444860/5-pain-points-of-modern-software-development-and-how-to-overcome-them.html)
• Modern Digital Applications Website (https://mdacast.com)
• Lee Atchison Articles and Presentations (https://leeatchison.com)
• Architecting for Scale, published by O’Reilly Media (https://architectingforscale.com)

Distributing Your Application

When building a modern, high-performant application at scale, it’s important to make sure the individual application instances are distributed across a variety of data centers in such a way that if any given data center goes offline, the application can continue to function relatively normally. This is an industry-wide best practice, and an important characteristic to architect into your applications in order to make them sufficiently resilient to data center problems.

The same philosophy occurs when you build your application in the cloud. Except, when you build a cloud-based application, you typically do not have visibility into which data center a particular server or cloud resource is located. This is part of the abstraction that gives the cloud its value.

Not having visibility into which data centers your application is operating in makes it difficult to build multi data center resiliency into your applications.

To solve this problem, AWS created a cloud abstraction of the data center that allows you to build on this level of resiliency without being exposed to the details of data center location. The abstraction is the availability zone.

AWS availability zones

An AWS availability zone is an isolated set of cloud resources that allows specifying a certain level of isolation into your applications. Resources within a single availability zone may be physically or virtually near each other, to the extent that they can be dependent on each other and share subcomponents with each other. For example, two EC2 servers that are in the same availability zone may be in the same data center, in the same rack, or even on the same physical server.

However, cloud resources that are in different availability zones are guaranteed to be separated into distinct data centers. They cannot be in the same data center, they cannot be in the same rack, and they cannot be using the same physical servers. They are distinct and independent from each other.

Hence, the solution to the resiliency problem, you can build your application to live in multiple availability zones. If you construct your application so instances of your application are distributed across multiple availability zones, you can isolate yourself from hardware failures such as server failures, rack failures, and even entire data center failures. Using multiple availability zones allows you to build in application resiliency.

Availability zones as data centers

Loosely, availability zones can be thought of as data centers. At a first level of approximation, this is a roughly reasonable assumption to make. However, there is not a one-to-one mapping of availability zones to data centers. When you create your AWS account, your availability zone names are mapped to individual data centers in a dynamic fashion. This means one AWS account may have an availability zone named us-east-1a mapped to data center #4, and another account may have the same availability zone mapped to data center #2. Even worse, a given data center may map to different availability zones in different accounts. For example, data center #4 in account #1 may be used for availability zone us-east-1a, but the same data center in account #2 may be used for availability zone us-east-1b.

You can find out how your availability zones are mapped to specific data centers in a given account by looking in the AWS console in the Resource Access Manager (RAM). This shows a mapping of availability zone names to an AZ ID. An AZ ID is a unique identifier that can be effectively used as a data center identifier. It shows the mapping, for your current account, of each availability zone to its associated data center’s AZ ID. This mapping is shown for your currently selected region, but you can simply switch regions to show the mapping for any region in your account.

So, when you are using multiple accounts, don’t use availability zone to determine data center redundancy. Instead, you should use the AZ ID. If two availability zones in different accounts have different AZ IDs, you can be sure that those two availability zones are in distinct data centers. Using the AZ ID, rather than the availability zone name, is a safe way to ensure your applications live in distinct data centers across multiple accounts.

Tech Tapas — Mechanical Turk

One of the oddest cloud services created was also one of the first cloud services. In 2005, Amazon’s Jeff Bezos had an idea and created the Mechanical Turk service. Mechanical Turk, or MTurk, was a service that allowed one to programmatically request execution of micro tasks that could only be performed by a human being. The service allowed software applications to request the execution of a task, and on the back end a human was used to execute the task. In the days before high quality Artificial Intelligence, it was a way of automating many tasks that only a human could perform. One early use for mechanical Turk was to use it to compare product pictures to determine if pictures were of the same product or different products. A single micro task might be to compare one picture to another and respond back yes or no if they represented the same product. This technique was used to improve the quality of the Amazon catalog. Another common task was to examine a picture of a sales receipt and record what information was found on the receipt.

Workers on the back end were paid for each task they completed, typically making on average 10 cents for each micro task they completed.

I remember when I was working at Amazon the day that Jeff presented to the employees the Mechanical Turk service. It was highly innovative. Of course, most of what it could do is now, or soon will be, replaced by machine learning algorithms and Artificial Intelligence. But still, it was a fantastic innovation at the time.

This podcast uses the following third-party services for analysis:
Chartable - https://chartable.com/privacy
Podtrac - https://analytics.podtrac.com/privacy-policy-gdrp