Amazon Web Services in Action

Imagine deliberately dropping the price of your core product not just once, but like thirty two times in just six years.

Right, which in any normal business is basically a one way ticket to bankruptcy exactly.

But for the invisible engine that powers you know, the modern Internet, it was actually this calculated master stroke. It led to total global dominance.

Yeah, and today we're looking at the mechanics of Amazon Web Services or AWS.

Right, Welcome to today's deep dive. We are stripping down the architecture behind the book Amazon Web Services and Action by Andreas and Michael Whittig.

And we're also pulling heavily from that foundational forward by Ben Wayley.

Yeah. And since you the listener probably already know the basic definitions of cloud computing, we aren't going to like waste time reciting textbook acronyms.

No, definitely not yea. We are going to look at the fundamental inversion of how digital infrastructure is actually built, scaled and paid for.

The mechanical how and the economic why. Okay, let's unpack this To understand why those forty two price drops make perfect sense, you have to look at the environment AWS completely.

Disruptive, oh, the dark ages.

Right, In the forward, Ben Wayey paints this very visceral picture of it. In the late nineties and early two thousands, it was brutal. Deploying an application was a heavy construction project. It's like wanting glass of milk and previously having to buy the cow, build the barn, and then hire the farmer. Now you just turn on a tap.

I love that analogy. If we connect this to the bigger picture, this wasn't just a technological shift. It was a massive business disruption that leveled the playing field.

Because before it was rooted in physical constraints right entirely physical.

If you had a successful application and you needed more database capacity, you couldn't just write a line of code.

You had to endure this massive procurement cycle.

Yeah, negotiate with vendors, wait weeks for shipping, and then deal with what Whaley calls literal.

Cable slinging, which just sounds awful.

It was you had engineers in freezing cold data centers physically bolting servers into metal racks. They're wiring up power supplies, walking around with like CDs to install operating systems on every single machine.

Oh wait, I want to push back on that. A little bit. Go for if I own the physical box and I have it in my own server room, isn't that inherently simpler, Like I have total control over my own hardware. Sure, so why introduce a massive third party into the mix?

Well, it feels simpler right up until the moment a power supply fails at two in the morning.

Ah.

When you own the physical box, you own all the physical liabilities. To achieve genuine reliability on premises, you have to buy two of.

Everything, two servers, two switches.

Two independent power grids. To enterprise grade HVAC systems, you are spending massive amounts of capix capital expenditure.

On redundant hardware that literally just sits there doing.

Nothing, just waiting for the primary system to fail. That financial barrier to entry strangled innovation. You needed millions in venture capital just to see if your software even worked.

Which brings us to the seismic shift in two thousand and six when AWS launched. Suddenly you transition from massive CAPEX to operational expenditure op X. You drop the starting costs to mere sense per hour.

It was revolutionary.

But to really grasp how they did this, we need to address a trope that drives me absolutely crazy. Which one People constantly joke that the cloud is just quote someone else's computer. Ah, It completely misrepresents the underlying mechanic.

It completely misses the point. It is not someone else's computer. It is a highly orchestrated software defined data center.

Right lift Look at the officialness definition for a second, the National Institute of Standards and Technology. They call it ubiquitous convenient on demand network access to a shared pool of configurable computing resources.

Which is a mouthful. But the magic there is the virtualization layer. AWS uses hypervisors, which is basically software that sits directly on the bare metal hardware.

And what does that do Practically?

It slices a single mansive physical server into dozens of completely isolated virtual machines.

So when I spin up an EC two instance, I'm getting a mathematically isolated slice of compute power.

Exactly, And the hypervisor tricks your operating system into thinking it has the entire physical machine all to itself.

Wow. And this introduces deep layers of abstraction. AWS hides the physical hardware layer entirely.

You don't know, and you really shouldn't care which specific hard drive sector or motherboard your code is running.

On because if the motherboard degrades, AWS just seamlessly migrates your virtual instance to a healthy physical.

Machine, often without you even noticing a blip in performance.

That abstraction naturally leads into how we deploy architecture. You know, we have public, private, and hybrid deployment models, and we all know the basic service types infrastructure as a service, platform as a service, software as a service, right, POS and sauce. But let's look at the actual implications of choosing between them. Wait, can we use the pizza delivery model to explain the shared responsibility model? Here?

Oh, go ahead, laid out. I like that one.

Okay, So if you build on premises, that's like making a pizza entirely from scratch. You grew the tomatoes, you bought the oven, you build the dining table. It takes forever. Right, infrastructure as a service or ies like Amazon EC two, that's like buying a frozen pizza. AWS provides the foundational ingredients, the compute, the storage, the networking, and you still.

Have to put it in your own oven, bake it and serve it exactly.

You manage the operating system and the run time. Then you have platform as a service pass like Elastic beanstalk that's getting a hot pizza delivered.

They manage the underlying infrastructure and the runtime environment. Yep.

You just supply the application code, which is the toppings.

Yeah.

And finally, software as a service like Amazon Workspaces. That's just going out to a restaurant. You eat the pizza. They handle everything.

It's an excellent way to visualize the shared responsibility model. AWS handles the security of the cloud, you know, the physical data centers, the hypervisors, the network cables.

While you handle the security and the.

Cloud precisely, your firewall configurations, your OS patches, your customer data encryption. The further up the stack you move from IAS to pious to sauce, the more responsibility you offload to AWS.

So instead of looking at isolated textbook examples of how these services work, let's look at the life cycle of a modern business. Using the case studies from the.

Text let's weave them together.

Yeah, we'll start at the genesis of a company with Alexa the startup engineer. Her entire operating philosophy is Murphy's law. Anything that can go wrong will go wrong, which.

Is the exact right mindset for the cloud. Alexa assumes virtual servers will fail because well, eventually, underlying hardware always fails, Right, so she designs a fault tolerant, stateless architecture. Instead of putting all her application logic on one massive server, she uses a load balancer.

And mechanically, a load balancer is constantly running health checks. Right, it's pinging the servers every few seconds.

Exactly, It's actively pinging her fleet of virtual servers. If a server stops responding to the health check, the load balancer automatically stops routing user traffic to it.

But Alexa takes it a step further. She deploys redundant virtual servers across multiple availability zones.

Yes, the ass.

Let's clarify availability zones, because that's crucial. An availability zone isn't just like a different rack in a server room, No, not at all. It's a completely distinct physical facility with its own independent power grid, cooling system, and network connectivity, usually located miles away from the others.

Right. So if a literal lightning strike takes out an entire data center, Alexa's startup doesn't go offline.

The load balancer instantly detects the failure and routes all traffic to the healthy virtual servers in the other availability zone.

She has enterprise grade disaster recovery built in from day one without buying a single piece of hardware.

Okay, so Alexa startup survives and grows. Now it evolves into the second stage of our business life cycle, represented by John the.

Cioh the webshop.

Yeah, he runs a massive high traffic webshop. Traffic is exploding and his compute costs are starting to rise. His problem is that he's treating all his web traffic the same, which.

Is incredibly inefficient. When a user loads Jones webshop, they are requesting dynamic content like querying the database for a specific user's shopping cart, right, But they're also requesting static content like the company logo or high resolution product images. John realizes he shouldn't be using expensive compute instances to repeatedly serve the exact same static JPEG image, Right.

Why make a virtual server work hard to deliver a picture of a shoe?

Exactly? Yeah, So John decouples his architecture. He points all the static content to a CDN, a content delivery network.

And this is what the mechanics get really elegant. A CDN uses edge locations. So if John's primary servers are in Forgi, but a user in Tokyo requests the.

Web page, the DNS resolution doesn't send that user all the way across the Pacific Ocean.

No, the CDN cashes a copy of that image on a physical server located in Tokyo.

The user in Tokyo gets the image delivered locally in milliseconds, which drastically reduces latency.

But more importantly for John's wallet, that request never reaches his primary servers in Virginia.

He is completely offloaded massive amounts of network traffic and compute load, making his infrastructure drastically cheaper and faster at the same time brilliant.

So the web shop scales globally, which brings us to the third stage of our life cycle, the enterprise tier. This is Maureen the architect doing enterprise Java. Yet right, the company is now a massive global entity with highly sensitive regulated corporate data living in legacy on premises databases. Maureen needs to integrate this with AWS. But here is where I genuinely have a hard time. If I am Maureen dealing with highly sensitive corporate data like proprietary trade

Cloud right where it's sitting on the same hardware as a million other companies.

Exactly why would you do that?

It is the single most common fear for enterprise architects, and it brings us back to the power of virtualization and software defined networking. Maureen doesn't just throw her data onto the public Internet. She creates a VPC, a virtual private cloud.

How does that actually guarantee isolation?

Though a VPC allows Maureene to carve out a logically isolated section of the AWS cloud, she defines her own IP address range, creates private subnets, and configures route tables.

Okay, but how does it connect back to her office.

The traffic between her on premises data center and her AWSVPC doesn't travel over the open Internet. It travels through a cryptographically secured IPSECVPN tunnel.

Oh wow.

Or if she wants to bypass the Internet entirely, she can use AWS direct Connect to lay a dedicated physical fiber optic line straight from her data center to the AWS facility.

So even though she is technically on shared physical infrastructure. The software defined networking rules make it mathematically impossible for another AWS customer to access her network packing exactly.

And beyond the logical isolation, you have to look at the physical and operational security. The text notes that AWS is compliant with incredibly stringent security frameworks.

Like FedRAMP and DODCSM for the US military right YEP.

And PCIDSS Level one for the global payment card industry. The reality is the physical security, the access controls, and the specialized security engineering at an AWI data center are vastly superior to what almost any independent corporation can afford to build for their own private server room.

It's an economy of scale applied to security, which transitions perfectly to the final stage of our company's life cycle, long term compliance and archiving.

Which brings us to Greg, the IT manager at the law firm.

Yes, the law firm now has years of legal paperwork and strict archiving requirements. Greg is trying to replace an archaic, expensive, dual hardware backup system.

Greg's old system was dangerous. He was backing up his primary data to a secondary server located in the same building.

So a fire or a flood would destroy both the primary data and the backup right.

But instead of buying an off site physical facility, Greg implements an AWS storage.

Gateway, and the book uses this amazing term here, a virtual tape deck. I love this because it perfectly illustrates abstraction. We took this archaic physical constraint literally winding magnetic tape to store cold data, and turned it into infinite software.

Mechanically, the Storage Gateway is a virtual appliance that Greg installs on his local network. It looks and acts exactly like a traditional physical storage array to his local servers, So.

His local servers write data to it just like they always did, but the.

Storage Gateway automatically and asynchronously replicates that data into AWS. Is highly durable object storage like Amazon S three or Glacier.

So Greg gets to keep his frequently access files cased locally for instant access, but the massive bulk of his cold historical data is silently pushed to the.

Cloud, giving him off site disaster recovery and infinite scalability without changing how his applications actually write the data.

It seamlessly bridges the on premises world on the cloud exactly. So we've taken this company from a fault tolerant startup, scaled it with a CDN, secured it with a VPC, and archived it with a storage gateway.

It's quite the journey.

But like, how is this all managed? If you have hundreds of virtual servers, load balancers and gateways, human beings cannot manually configure all of this through a web console without making catastrophic errors.

And here's where it gets really interesting. This is the true engine of innovation. Here in the preface, the authors Andreas and Michael Whittig talk about their experience migrating the entire IT infrastructure of a German bank to AWS.

They were the first to do it in Germany right first.

And the biggest takeaway wasn't just where the servers lived. It was a profound shift in operational culture. It shifted them to micro services and enabled the core DevOps principle you build it, you run it.

Because the developers are no longer tossing their code over a literal wall to a separate IT operations team, right.

They are managing the infrastructure themselves through a concept called infrastructure as code or IAC.

This is the holy grail of cloud computing. Infrastructure as code means you stop manually clicking buttons.

You write a blueprint using Jason or Yamel templates in a service like AWS CloudFormation that explicitly declares exactly what your infrastructure should look like.

You decline that you need a VPC, two load balancers, and a database. You execute that text file, and the AWS orchestration engine automatically provisions the entire environment in minutes.

And the mechanical beauty of ISIC is idempotency.

Let's explain idemptancy, because if I run that exact same script one hundred times, it doesn't create one hundred databases exactly.

It simply checks the current state of the infrastructure against the declared state in your code and only makes the necessary changes.

I can now version control my physical data center the exact same way I version control my software. I can roll back a firewall change by just reverting a commit.

And get what fascinating here is when you think about the physical reality underlying it. This level of automation is what enables the staggering scale of AWS. By the time the data in this book was published in twenty fourteen, AWS was operating one point four million servers globally.

That is just insane.

They're releasing new features weekly.

Which brings us all the way back to the hook of this deep dive, dropping prices forty two times between two thousand and eight and twenty fourteen. If you are operating at the scale of one point four million servers, you fundamentally break traditional supply and demand economics.

You do because AWS is buying hardware at a scale no other company own earth can match. They dictate the supply chain. Yeah, they build highly optimized custom hardware. They squeeze every drop of inefficiency out of their data centers, and instead of just pocketing the margin, their business model is to pass those massive economies of scale back to the customer in the form of price cuts.

Which drives more customers to the platform, which increases their scale even further. It is a relentless compounding flywheel.

It really is.

So what does this all mean. Let's look at how that flywheel impacts the wallet of the end user, the economics of elasticity.

Right, the paper use model.

The book uses an electric bill analogy, which is med but you know it's also highly accessible for anyone just wanting to learn. There's the AWS free tier.

Oh yeah, seven hundred and fifty hours of EC two, seven hundred and fifty hours of load balancer, five GBS three storage, a twenty GB database, all free for the first year.

Incredible, But I want to look at the actual math for growing business. Let's go back to John's webshop.

Okay, John's webshop.

The text gives us a very precise breakdown. In January, John gets one hundred thousand visitors and his AWS bill is one hundred and forty two dollars and thirty seven cents. In February, a marketing campaign goes viral and his traffic explodes to five hundred thousand visitors. Wow, okay, that is a five x increase in traffic, but his bill only goes up to five hundred and thirty eight dollars and nine cents, which is just a three point seven x increase.

It comes down to decoupling fixed versus variable costs within his architecture. When traffic spiked, his dynamic computing needs scaled up, his load balancer spun up more easy two instances to handle the database queries, and his outbound network data transfer increase.

Those are the variable costs right.

But his static storage costs the gigabytes of space folding his product images and S three remained exactly the same. The size of the files didn't change, only the velocity at which they were accessed.

So a massive portion of his baseline costs remained flat, while his revenue generating traffic whinentupled.

That nonlinear scaling is the dream for any business. But the even bigger mechanic here is elasticity. Through auto scaling, one didn't have to call AWS and ask for more servers when the viral campaign hit No.

His architecture dynamically reacted to the load. He sets a cloud watch alarm if his CPU utilization hits seventy percent, the auto scaling group automatically provisions another virtual server and attaches it to the load balancer.

And crucially, when the viral spike dies down at three zero am, the alarm triggers in reverse. The system automatically terminates those extra servers. He scales down to baseline.

He stops paying for idle resources. If you extrapolate that across a global enterprise, the amount of wasted CAPEX that is suddenly reclaimed is astronomical.

It changes how businesses fundamentally assess risk. You don't have to guess what your peak capacity will be on Black Friday in over provisioned hardware just in case. You just let the flexible capacity of the cloud absorb the impact.

So let's pull all of this together. We have journeyed from the physical, rigid constraints of legacy data centers, where racking servers and guessing capacities stickled innovation, to a radically elastic, squere defined ecosystem.

We watched a startup engineer build for inevitable failure.

We watched the CIO leverage edgeenodes to drastically drop costs.

We saw an enterprise architect carve out cryptographically secure networks on public hardware.

And we saw how infrastructure as code fundamentally changes the discipline of it operations.

And when you step back and look at the synthesis of all these mechanisms, the virtualization, the global edge networks, the automated provisioning, you realize that infrastructure is no longer a physical constraint. It is a programmable utility.

Which leaves us with a truly staggering philosophical question.

What's that?

Well, think about it. If a massive globally redundant corporate IT network, complete with firewalls, load balancers, database clusters, and secure subnets, is no longer made of steel cabinets and copper wires, but is literally just a text file of declarative code sitting in a GIT repository. What does that mean for the traditional concept of a company.

It dissolves the physical boundaries. If you can provision a Fortune five hundred level infrastructure in ten minutes just by executing a script, the entire concept of organizational scale changes.

You don't need a massive IT department to manage the hardware.

You just need a developer who understands the architecture.

The barrier to entry in the digital age is no longer capital. It is strictly your imagination and your ability to write the logic. What are the limits of what a single person sitting at their laptop can build tomorrow?

It's an incredible thought.

The next time you sit down to stream a four K movie, or run a complex data query, or even just sink a document, remember what is actually happening. You aren't just clicking a button. You are executing code that is orchestrating hypervisors, routing packets through edge locations and dynamically spinning up compute power across a global ocean of automated infrastructure.

You are tapping into the most complex machine humanity has ever built.

Thank you for taking this deep dive with us.