eu-west-1.amazonaws.com
eu‐west‐2
eu-west-2.amazonaws.com
eu‐west‐3
eu-west-3.amazonaws.com
eu‐north‐1
eu-north-1.amazonaws.com
me‐south‐1
me-south-1.amazon.aws.com
ec2, apigateway, or cloudformation are 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‐1a and 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 Reliability and Compliance
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/programs for more information.)
The AWS Shared Responsibility Model
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
The AWS Service Level Agreement
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.
Working with AWS
Whatever AWS services you choose to run, you'll need a way to manage them all. The browser‐based management console is an excellent way to introduce yourself to a service's features and learn how it will perform in the real world. There are few AWS administration tasks that you can't do from the console, which provides plenty of useful visualizations and helpful documentation. But as you become more familiar with the way things work, and especially as your AWS deployments become more complex, you'll probably find yourself getting more of your serious work done away from the console.
The AWS CLI
The AWS Command Line Interface (CLI) lets you run complex AWS operations from your local command line. Once you get the hang of how it works, you'll discover that it can make things much simpler and more efficient.
As an example, suppose you need to launch a half‐dozen EC2 instances to make up a microservices environment. Each instance is meant to play a separate role and therefore will require a subtly different provisioning process. Clicking through window after window to launch the instances from the console can quickly become tedious and time‐consuming, especially if you find yourself repeating the task every few days. But the whole process can alternatively be incorporated into a simple script that you can run from your local terminal shell or PowerShell interface using the AWS CLI.
Installing and configuring the AWS CLI on Linux, Windows, or macOS machines is not hard at all, but the details might change depending on your platform. For the most up‐to‐date instructions, see docs.aws.amazon.com/cli/latest/userguide/installing.html.
AWS SDKs
If you want to incorporate access to your AWS resources into your application code, you'll need to use an AWS software development kit (SDK) for the language you're working with. AWS currently offers SDKs for nine languages, including Java, .NET, and Python, and a number of mobile SDKs that include Android and iOS. There are also toolkits available for IntelliJ, Visual Studio, and Visual Studio Team
