David Clinton - AWS Certified Solutions Architect Study Guide

AWS maintains data centers for its physical servers around the world. Because the centers are so widely distributed, you can reduce your own services' network transfer latency by hosting your workloads geographically close to your users. It can also help you manage compliance with regulations requiring you to keep data within a particular legal jurisdiction.

Data centers exist within AWS regions, of which there are currently 21—not including private U.S. government AWS GovCloud regions—although this number is constantly growing. It's important to always be conscious of the region you have selected when you launch new AWS resources; pricing and service availability can vary from one to the next. Table 1.3shows a list of all 21 (nongovernment) regions along with each region's name and core endpoint addresses. Note that accessing and authenticating to the two Chinese regions requires unique protocols.

TABLE 1.3 A list of publicly accessible AWS regions

Endpoint addresses are used to access your AWS resources remotely from within application code or scripts. Prefixes like ec2, apigateway, or cloudformationare often added to the endpoints to specify a particular AWS service. Such an address might look like this: cloudformation.us-east-2.amazonaws.com. You can see a complete list of endpoint addresses and their prefixes at docs.aws.amazon.com/general/latest/gr/rande.html.

Because low‐latency access is so important, certain AWS services are offered from designated edge network locations. These services include Amazon CloudFront, Amazon Route 53, AWS Firewall Manager, AWS Shield, and AWS WAF. For a complete and up‐to‐date list of available locations, see aws.amazon.com/about-aws/global-infrastructure/regional-product-services.

Physical AWS data centers are exposed within your AWS account as availability zones. There might be half a dozen availability zones within a region, like us‐east‐1aand us‐east‐1b, each consisting of one or more data centers.

You organize your resources from a region within one or more virtual private clouds (VPCs). A VPC is effectively a network address space within which you can create network subnets and associate them with availability zones. When configured properly, this architecture can provide effective resource isolation and durable replication.

AWS has a lot of the basic regulatory, legal, and security groundwork covered before you even launch your first service.

AWS has invested significant planning and funds into resources and expertise relating to infrastructure administration. Its heavily protected and secretive data centers, layers of redundancy, and carefully developed best‐practice protocols would be difficult or even impossible for a regular enterprise to replicate.

Where applicable, resources on the AWS platform are compliant with dozens of national and international standards, frameworks, and certifications, including ISO 9001, FedRAMP, NIST, and GDPR. (See aws.amazon.com/compliance/programsfor more information.)

Of course, those guarantees cover only the underlying AWS platform. The way you decide to use AWS resources is your business—and therefore your responsibility. So, it's important to be familiar with the AWS Shared Responsibility Model.

AWS guarantees the secure and uninterrupted operation of its “cloud.” That means its physical servers, storage devices, networking infrastructure, and managed services. AWS customers, as illustrated in Figure 1.3, are responsible for whatever happens within that cloud. This covers the security and operation of installed operating systems, client‐side data, the movement of data across networks, end‐user authentication and access, and customer data.

FIGURE 1.3 The AWS Shared Responsibility Model

By “guarantee,” AWS doesn't mean that service disruptions or security breaches will never occur. Drives may stop spinning, major electricity systems may fail, and natural disasters may happen. But when something does go wrong, AWS will provide service credits to reimburse customers for their direct losses whenever uptimes fall below a defined threshold. Of course, that won't help you recover customer confidence or lost business.

The exact percentage of the guarantee will differ according to service. The service level agreement (SLA) rate for AWS EC2, for instance, is set to 99.99 percent—meaning that you can expect your EC2 instances, ECS containers, and EBS storage devices to be available for all but around four minutes of each month.

The important thing to remember is that it's not if things will fail but when . Build your applications to be geographically dispersed and fault tolerant so that when things do break, your users will barely notice.