Lets start with the concept of data centers: stacks and stacks of server hardware built with high speed RAMs, powerful CPUs and low latency storage drives running 24/7/365. They host the websites you visit, enterprise company data and pictures of the moon that you took with your budget phone!
Relying on only one datacenter is not enough redundancy-wise. This is where AWS defines their ‘Availability Zone’ concept. 1 AZ = 1 (or more) data center acting as a single logical unit. What’s behind that ‘single logical unit’? the promise of AWS Cloud’s service guarantee that it will always work, officially called a ‘Service Level Agreement’.
This is what it looks like: Suppose after some downtime and disruption incidents, the AWS storage service S3 had an uptime of (less than) 95% in January, then you get 100% refund credit for the next monthly billing cycle.
Despite proper backups, nobody can prevent a city-wide natural calamity or man-made crisis. To ensure close to 100% uptime, we as the user can also choose to host our websites or storage in multiple availability zones. For example: the Mumbai Region has three availability zones. If we keep our resources in all three AZ, though more pricier, we can ensure closer to 100% uptime.
AZs are designed not to be simultaneously impacted by a shared fate scenario like utility power, water disruption, fiber isolation, earthquakes, fires, tornadoes, or floods. Common points of failure, like generators and cooling equipment, are not shared across Availability Zones and are designed to be supplied by different power substations.
Read More about AZs
Also note that in a new aws cloud account, not all regions and availability zones will be available by default. We have to manually turn them on. Its not an issue unless you are looking for a zone closer to your user base for your latency sensitive boutique flower shop’s online service!
Some new features appear some regions first.
Some AWS services are zone-specific, region-specific or global. Meaning while configuring them you have to be mindful under which zones/regions you are deploying them or setting particular rules.
Like Amazon EC2 and Amazon EBS, A zonal service is one that provides the ability to specify which Availability Zone the resources are deployed into. These services operate independently in each Availability Zone within a Region, and more importantly, fail independently in each Availability Zone as well.
Note that, if the AZ suffers downtime, the EC2 instance and the attached block storage(EBS) also goes offline (not corrupted/destroyed, depending how severe the AZ failure was). This is called ‘static stability’, meaning AWS will not automatically/dynamically move the EC2 instance to another AZ and ensure EC2 is up. We have to do it ourselves e.g. select more than 1 AZ if 100% uptime is crucial.
Regional services are services that AWS has built on top of multiple Availability Zones so that customers don’t have to figure out how to make the best use of zonal services. We logically group together the service deployed across multiple Availability Zones to present a single Regional endpoint to customers. Amazon SQS and Amazon DynamoDB are examples of Regional services. They use the isolation and redundancy of Availability Zones to minimize infrastructure failure…
Beyond Regions and Availability Zones there are also the concept of AWS Local Zones (infrastructure set up closer to large populations) and Point-of-Presence colloquially also known as ‘edge locations’ which host 3 key AWS service: Amazon CloudFront, a content delivery network (CDN); Amazon Route 53, a public Domain Name System (DNS) resolution service; and AWS Global Accelerator (AGA), an edge networking optimization service. Read more.
IAM: Identity Access Management
Moving the discussion away from ‘where our resources and workloads run’, our next concern should be who can do what, also known as Authorization. Authentication and Authorization is covered under a suite of concepts and tools called IAM.
Lets start from square one. When you try to login to your aws cloud via “console.aws.amazon .com/console” you are presented with a login panel which mentions two types of accounts:
- IAM user
- Root user
A root user, which can do anything, can spawn(make) many IAM users and specify what they can/cant do. You dont want your company’s data analyst working with full priviledge to destroy everything, instead of only limited read and write permission. You can also create a user group and place many of the same types of users under it. This helps reduce click operations and good management.
Note that we are using the ‘IAM’ jargon freely here! The entire AWS service and the account type are also called ‘IAM’. Dont think about the jargons for too long, just go with it!
Below is what a IAM setup could look like, read from left:
This is what an IAM user would see after login. There will be some access denied flags depending on what permission they have been given.
Screenshot taken from youtube video by Mr. Mitul Shahriyar, an AWS Community Builder.
AWS IAM has these concepts that we will discuss in short. The best way is to actually browse and DIY.
To be contd…