AWS SAA-C03 Journey: The Fun..damentals!

AWS SAA-C03 Journey: The Fun..damentals!

Picture of By Ramzi Marjaba

By Ramzi Marjaba

Before AWS, or any other cloud solution, each organization would have to manage and maintain their own datacenter. This would include the physical servers, databases, software patches, connectivity and so much more.

Each business had to run 2 businesses, the main one, for example Banks needed to run banking, and the time sucking one which is IT. Although this is not overcome all the way, the advent of cloud sure made it easier.

So let’s talk about the time sucking business.

According to datacenterknowledge.com, JPMorgan Chase spent 500 Million Dollars to build a Datacenter before 2012, and 2 Billion Dollars in 2021 even though they are using the “cloud” for some of their needs.

AWS on the other hand has datacenters in 20 countries and 100 locations back in 2020!

So let’s talk about these.

Regions are basically big land mass. For exmaple, in North America, there are 7 regions. And when you go onto AWS console you can see these regions call US West (Oragon) and the other ones:

This is showing that you have Datacenters in Oregon, N. Virginia, etc. You can go to https://aws.amazon.com/about-aws/global-infrastructure/regions_az/ and see the regions.

Then you can look at what they call the Availability Zones. An availability zone (AZ) is one or more discrete and fully functional datacenter with redundancy. Each Region has 3 or more AZs. Note that the course says 2 or more so they must have increased them across the board. And this will change depending on when you read this.

Now why do we care about availability zones and regions:

1- Latency – If someone is located in the middle east and using US-West-1, then you’re adding some unnessesary delay to your applications.

2- Not all services are available in all the regions.

3- Disaster recovery. If in earthquake happens in japan, someone who is using the 1 Japan region

Then there are the Local Zones which were not mentioned at all in the Cloud Guru Course or in the Stephane Mareek Course.

Local Zones are used for applications that need single digit millisecond latency. That means that organizations used to have to run local datacenters or servers to be able to get that latency, but Local Zones is currently used to solve that problem. Basically if you’re located in South Carolina and the closes AZ to you is in North Virginia, well there is a local zone in Miami which will allow you to use the same services (mostly) to get the latency required.

Edge Locations is Content Delivery Network (CDN). The AWS Service corresponding to that is AWS Cloudfront. The course on cloud guru says there is over 215, but it seems that AWS website has been updated to show over 400 edge locations. It is basically caching the content as close as possible the the end user which improves the quality of experience. There are also some security benefits but the course did not get into them and I didn’t want to give myself a headache so early in the journey. I’ll leave that for another day.

Now in each AZ you can run a service. Some of these services are similar to what most organizations used to run in their own datacenters, but there is a twist to them now that they are on AWS.

The main ones, as listed in Cloud Guru are Compute, Storage, Database and networking. And all this work has to be secure.

And that brings me to the topic of responsibility. When an organization ran it’s own database, it was responsible for everything, from physical security, cooling, power, to the applications running on the server.

But now, with the fact that AWS is in control of some stuff and the client is in control of others, comes the “Shared Responsibility Model”.

Link to the Shared Responsibility Model Page

There is an entire article dedicated to this I’ve linked above, but the summary as I understand it is, What you can control as a client is your responsibility, and what AWS controls is theirs. So the physical HW, patching of software that they are running, that is their responsbility. Customer data, application, IAM, all yours. Enjoy!

That article I’ve linked above has many other links to many other articles about security, documentations, and other joyful readings.

Next blog is covering IAM. Stay tuned!

Stay in the loop

Subscribe to get our latest content by email.

We won't send you spam. Unsubscribe at any time. Powered by ConvertKit