—

Big Data Systems

Cloud Computing and Cloud-Hosted Big Data Platforms

Published: 2026-08-03

Level: postgraduate

Audience: Postgraduate students in Big Data Systems

5.1 Why Cloud Computing Matters

5.1.1 The Motivation: Pay per Usage, Scale as You Go

Why does a big data course spend a session on cloud computing? Because the story of big data today is the story of the cloud: most big data components — storage, processing engines, databases, analytics services — are hosted on cloud platforms, AWS and Azure being the best known. To understand how big data systems are actually built today, you first need to understand the cloud platform underneath them. That is the agenda of this session: look at cloud computing from a big data perspective — what each vendor offers, how you can architect big data solutions out of those components, and how the architecture of a platform like AWS hangs together. Two services get special attention later: Elastic MapReduce (EMR) and S3 buckets, because together they show the canonical pattern of hosting a big data application on the cloud.

The whole business in one sentence: industries move to the cloud because they can pay as per usage and scale as per demand. You rent computing, network, and storage resources when you need them instead of buying them, and you release them when you do not. That trade-off — renting rather than owning — is the foundation of the entire cloud business model.

Think of it like a taxi versus a private car. Buying a car means paying a large upfront cost for a vehicle you may use for two hours a day; a taxi means paying only for the kilometres you actually travel, and getting a bigger or smaller car exactly when you need it. The cloud is the taxi: pay for what you use, scale the "size of the car" with your demand, and walk away with no maintenance obligation. The analogy breaks in one important place — a taxi ride ends and you are done, whereas a cloud application keeps running for years, so ongoing costs and architecture choices matter much more than a single trip fare.

The course's focus on AWS is practical, not ideological: most big data components are hosted on cloud platforms, so understanding what each vendor offers is a prerequisite for architecting big data solutions. The reference books frame the same idea from the infrastructure side: cloud computing exists to serve cheap and abundant storage, faster processors, and affordable, distributed big data platforms — cloud computing and other flexible resource-allocation arrangements are listed among the technologies big data analytics relies on (T1 Ch 3). The cloud is the delivery mechanism for the hardware side of big data.

5.1.2 The Formal Definition

A formal definition helps because "cloud computing" is used loosely. The definition used in this course: cloud computing is a model for enabling a request-convenient, on-demand network service to a shared pool of configurable computing resources. The resources can be network, servers, storage, applications, and services, and they can be rapidly provisioned and released with minimal management effort or service provider interaction.

The formal definition (cloud computing): a model for enabling a request-convenient, on-demand network service to a shared pool of configurable computing resources (network, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction.

Two ideas carry the weight of the whole definition:

The resources are shared — you draw from a pool, you do not purchase a dedicated system. The reference book's definition is consistent: "cloud computing is a type of Internet-based computing that provides shared processing resources and data to the computers and other devices on demand" (T2 Ch 1).
Provisioning and release is fast — fast enough that you can act on demand: spin up resources this morning, return them this evening, and pay only for the window you used.

Both properties are what make the pay-per-usage model possible. If resources were dedicated (unshared), you would be paying for idle capacity. If provisioning were slow (say, weeks), the "on-demand" promise would be meaningless.

Note the deliberate word choice in the definition: the service is network-based — you never install the infrastructure next to you; you reach it over the network from anywhere. And the pool is configurable — the same physical hardware serves many different workloads, which is what makes the provider's economics work: many customers, each paying only for what they consume, sharing one large pool.

5.1.3 Cloud Service Providers: Renting Instead of Buying

Who runs these pools? There are cloud service providers, and the market has three big players:

Amazon Web Services (AWS) — one of the biggest, and the historical market leader.
Google Cloud Platform (GCP) — Google's offering.
Microsoft Azure — Microsoft's offering.

There are more (Rackspace is among them), but these three dominate the market. The practical picture is the same for all of them: if you need certain computing resources, certain network resources, certain storage resources, you can rent them rather than buying them, scaling up and down as per the demand.

Real-world: the decision to move to the cloud is not made for the entire organization at once — each application is a separate candidate. An application that is easy to containerize, has bursty demand, or has no compliance constraint to stay on-premises is a good candidate; an application bound by strict data-residency rules may not be. The motivation for this course's focus on AWS is that most big data components are hosted on cloud platforms, so understanding what each vendor offers is a prerequisite for architecting big data solutions.

5.1.4 Planning Before You Move: It Is Not Automatic

It sounds like a trivial move: "today I decided, okay, I will move my application to the cloud, and without any proper planning I simply move it, start working, and my cost will be ready." That is not the case. Moving to the cloud is a planning exercise, not a lift-and-shift exercise.

The naive-move trap: pushing an application to the cloud without planning the resources it needs is a sure way to increase your operational cost. Cloud pricing is per-usage — so every miscalculation in resource sizing becomes a monthly bill, not a one-time purchase mistake. Proper planning means answering, before the move: what resources does this application actually use, what does it cost to run it at the expected load, and which parts of it can scale elastically?

Because the planning framework is used throughout cloud discussions, it is worth locking in now: the three-four-five rule of cloud computing, which the professor flags as very, very important. Any cloud platform has:

three cloud service models (or service types),
four deployment models,
five characteristics of cloud computing infrastructure.

The next section walks through all three layers in order, starting with the five characteristics.

Recap: Cloud computing exists so that big data applications can rent — rather than own — a shared, rapidly provisionable pool of compute, network, and storage, paying only for usage and scaling with demand. The formal definition rests on shared and rapidly provisioned. The practical discipline: plan before you move, using the three-four-five rule (3 service models, 4 deployment models, 5 characteristics) as the organizing framework for everything that follows in this session.

5.2 The 3-4-5 Rule of Cloud Computing

The three-four-five rule is the professor's memory framework for the whole cloud landscape: any cloud platform has five characteristics, four deployment models, and three service models. We walk through each layer, starting from the characteristics.

Exam note: the "three-four-five rule" framing — three service models, four deployment models, five characteristics — is a recurring organizing structure for this course's cloud discussion. Remember the numbers and what sits in each slot: the service models (IaaS, PaaS, SaaS), the deployment models, and the characteristics are covered in order below.

5.2.1 The Five Characteristics

1. On-demand self-service. Today my application needs this many resources; tomorrow I want to scale it because my customers have increased. Scaling up is possible — but that is a naive statement, because "how to scale up" has options: there is manual scaling and there is auto scaling, and multiple options are available for each. On-demand means you, the customer, trigger provisioning yourself without waiting on a salesperson or a support ticket.

2. Broad network access. Whenever you move something to the cloud, you access your applications through networks. You need access to the network, and the network access must be broad — available from wherever you are, not just from the office LAN. Because services are reached over the network, broad connectivity (typically standard internet protocols over HTTPS) is what makes the shared pool usable.

3. Resource pooling. The provider pools its computing resources and serves many customers from the same shared pool. This is the "shared" idea from the formal definition made concrete: the provider's large pool of physical machines is sliced into virtual machines, databases, and storage that many customers share. One customer's burst can be absorbed by the pool's idle capacity rather than by a dedicated machine.

4. Rapid elasticity. This is again in the scalability part: the pool can expand and contract quickly as demand changes. Elasticity is the speed of scaling — resources appear and disappear in minutes, not weeks. The classic phrasing: scale to match demand in real time, then release the resources when the demand passes.

5. Measured service. You see how much you are using, how many resources you are consuming, and you pay based on that. The usage can be measured, and you can pay per day as you go. Metering is what turns the other four characteristics into a viable business: the provider measures your consumption (CPU hours, storage bytes, requests) and bills accordingly — the "pay as per usage" promise from section 5.1.

Why these five, and not some other list? Each characteristic plugs a hole that would otherwise break the pay-per-use model: without on-demand self-service, provisioning would be slow; without broad network access, the pool would be unreachable; without resource pooling, prices could not be low; without rapid elasticity, scaling could not track demand; without measured service, nobody could be billed fairly. The reference book (T2 Ch 1) lists a compatible set — on-demand service, resource pooling, scalability, accountability, and broad network access — where "accountability" plays the same role as measured service, and "scalability" covers elasticity.

5.2.2 The Four Deployment Models

Public cloud is a mega-scale cloud infrastructure made available to the general public or to large industry groups, and it is owned by the organization selling the cloud services — typically AWS or Google. These are the classic examples: you rent a slice of a provider's massive, multi-tenant infrastructure over the internet.

Private cloud is owned by one particular organization. It can be on-premise, or it can be outside the premises of the organization, but it is not shared — it is private to one particular organization. The organization gets cloud-style self-service and elasticity, but pays for dedicated hardware.

Hybrid cloud combines the two: maybe I use a private as well as a public cloud, with portions of my applications on the private cloud and certain portions on the public cloud. What is important here is the communication between the public cloud and the private cloud, because there may be data movement happening between them when we use hybrid. Managing those operations — keeping the private and public sides consistent, moving data across the boundary securely — is very, very challenging in a hybrid cloud.

Community cloud is a cloud that a bunch of organizations own together. Typically these are government organizations: if they own one particular cloud and share that cloud, it becomes a community cloud. The infrastructure is shared among the member organizations with common concerns (for example, regulatory requirements), but is not open to the general public.

A management choice applies to all of these: if you have the IT expertise, you can manage the clouds yourself; otherwise there are cloud service vendors who can manage them for us. Both options are available — "who operates it" is independent of "which deployment model it is".

Deployment-model traps:

Hybrid sounds like the best of both worlds, but the hardest. The private and public sides must be networked securely and consistently; every data movement across the boundary is an attack surface and a consistency problem. Do not pick hybrid "because it is flexible" without a concrete reason for each portion of the workload.
Private cloud is not automatically safer. A private cloud is still a distributed system — it still needs redundancy, monitoring, and security design. "It is on our premises" is not a security policy.
Community and public are easy to confuse. Public = open to anyone who pays; community = shared only among member organizations, typically with common compliance needs.

5.2.3 The Three Service Models

Infrastructure as a Service (IaaS) is when you rent something — computing resources like CPUs, storage, network, or any other kind of resource. What you are using is infrastructure, so it becomes infrastructure as a service. Rackspace hosting and Amazon Web Services are providers of this infrastructure service — when you rent out certain EC2 instances, that is IaaS. You get raw building blocks (virtual machines, volumes, networks) and you manage the operating systems and software on top yourself.

Platform as a Service (PaaS) is where you deploy certain customer-created applications on a platform as a service. Take MongoDB hosted on the cloud: you do not need to install MongoDB or manage its self-configuration — all of that is taken care of by the provider, and you simply use that MongoDB. That becomes platform as a service. You get a ready-to-use runtime — a database, a Hadoop cluster, an application server — and you only bring your data or your code.

Software as a Service (SaaS) sits at the topmost level: you are given a particular solution and you consume it — customers consume a full-play solution out of it. Salesforce CRM is one of the best examples of software as a service, quite popular in industry and successful as well. You get a finished application (a CRM, an email service, an analytics dashboard) and you use it through a browser — no code, no servers, no installation.

The responsibility ladder (what you manage at each level):

Model	Provider manages	You manage	Typical example
IaaS	Physical machines, network, storage, virtualization	OS, runtime, application, data	EC2 instances, Rackspace
PaaS	Everything above, plus OS and runtime	Your application and its data	Hosted MongoDB, AWS EMR
SaaS	Everything, including the application	Just your usage of the product	Salesforce CRM, Gmail

The ladder reads top to bottom as "who does the work": IaaS hands you bare infrastructure, PaaS hands you a ready platform, SaaS hands you a finished product. The reference book (T2 Ch 1) gives the same three-way classification with matching examples: IaaS like Amazon data centers and virtual servers; PaaS like the Hadoop cloud services (IBM BigInsight, Microsoft Azure HDInsight); SaaS like SQL services hosted by the provider.

Which model you pick depends on what you want: do you want only infrastructure and plan to build applications on the cloud yourself, or do you want a platform, or software as a service? It depends on the IT team and the expertise you have, and then you can plan out all these things. The rule of thumb: the more expertise your team has, the lower you can work on the ladder (and the more you control); the less expertise, the higher you go (and the less you manage).

Real-world (big data fit of each model): For big data, IaaS provides huge storage and computational power — the limitless storage and computing ability of cloud companies. Typical examples are S3 for storage and EC2 instances for compute. PaaS vendors offer a platform ready with Hadoop and MapReduce — AWS EMR, the Elastic MapReduce service — which saves the hassle of installing and managing these environments yourself. SaaS is a great help to an organization that needs specialized software for big data, such as social media analytics or feedback monitoring: those can be bundled as one software and you simply call that service and use it. For certain common use cases the cloud vendors provide these solutions, and that is software as a service.

Recap + bridge: The 3-4-5 rule organizes the entire cloud discussion: five characteristics (on-demand self-service, broad network access, resource pooling, rapid elasticity, measured service), four deployment models (public, private, hybrid, community), and three service models (IaaS, PaaS, SaaS — a responsibility ladder from raw infrastructure to finished software). With the framework in place, the next section maps each service model to the concrete products the big three vendors actually sell.

5.3 Cloud Providers and Their Big Data Components

The service models from section 5.2 are abstractions; this section makes them concrete by naming the actual products the three big vendors sell. Each vendor offers the same categories of components — compute, storage, data warehouse, NoSQL — under different names.

5.3.1 Amazon Web Services (AWS)

The AWS component list is long and all of it is quite popular:

Amazon EC2 — compute instances (rentable virtual machines); this is the IaaS core of AWS.
Elastic MapReduce — managed Hadoop (a PaaS offering: a Hadoop/MapReduce platform ready to run, without installing Hadoop yourself).
DynamoDB — a NoSQL database (key-value/document store).
S3 buckets — object storage (the storage service that gets special attention later in this session).
High performance computing (HPC) offerings — specialized compute configurations for HPC workloads.
Redshift — a data warehouse (managed, columnar analytics database).

5.3.2 Google Cloud Platform (GCP)

Google offers:

Compute Engine — their virtual machine service (the GCP analogue of EC2).
BigQuery — their managed data warehouse/analytics service (the GCP analogue of Redshift).
A Prediction API — a machine-learning prediction service.

5.3.3 Microsoft Azure

Microsoft offers:

The Azure platform — the Azure cloud, built on Windows.
SQL Azure — the managed SQL database (a relational database as a managed service).
HDInsight — their Hadoop distribution on the cloud (the Azure analogue of EMR).

These are some of the components they offer in the market.

The same catalog, three vendors. Notice the one-to-one mapping: every vendor sells a virtual machine (EC2 / Compute Engine / Azure VMs), a managed Hadoop (EMR / Dataproc-style offerings / HDInsight), a data warehouse (Redshift / BigQuery / SQL Azure), and so on. Once you understand the categories — compute, managed platform, NoSQL, object storage, warehouse — you can map your knowledge onto any vendor's catalog. The reference book (T2 Ch 1) lists the same landscape: EC2 and S3 from Amazon, and the Hadoop cloud services from IBM, Microsoft, and Oracle — evidence that the "managed Hadoop as a service" pattern is industry-wide, not AWS-specific.

5.3.4 Why AWS Leads

The first player in this list is the most popular because they were the first to figure out that cloud services could happen as a business. Amazon discovered this kind of business and they are the market leaders. The other two are also very good, but Amazon was first and they are leading.

Why being first mattered here: Amazon had already built massive infrastructure for its own retail business (a point developed in section 5.12 — the origin story), so it could over-provision for its internal demand and sell the spare capacity. Google and Microsoft had to build their cloud businesses after watching Amazon prove the market. Being first gave AWS the largest catalogue, the deepest ecosystem of partners, and the longest-running track record — the reasons it remains the reference point for this course's case studies.

Recap: The three big providers — AWS, GCP, Azure — offer parallel catalogs of big data components: compute (EC2, Compute Engine), managed Hadoop (EMR, HDInsight), warehouses (Redshift, BigQuery, SQL Azure), NoSQL (DynamoDB), and object storage (S3). AWS leads because Amazon started the cloud business first. Next: a real company — Nasdaq — that assembles these components into a big data platform, and the architectural decision at the heart of it.

5.4 Case Study: Nasdaq on AWS (S3 + EMR Instead of HDFS)

5.4.1 The Setup

Nasdaq is a financial organization, and everyone knows they make use of cloud-based systems to operate. The way they use AWS is the interesting part for a big data course. If we recall the Hadoop ecosystem, we used HDFS as the storage part largely, and we said there could be other storage options. But Nasdaq does not use HDFS as its storage. Instead it uses S3 buckets as storage and Elastic MapReduce as the platform-as-a-service compute layer. With that combination they access huge datasets with much more cost efficiency.

The surprising part is not the cloud; it is the storage swap. A company running Hadoop-family workloads would "normally" store its data in HDFS, the Hadoop Distributed File System tied to the cluster. Nasdaq deliberately separates the two: data lives in S3 (an object store, outside the cluster), and compute runs on transient EMR clusters that read from S3. The motivation is money: huge datasets are stored once in cheap object storage, and compute clusters exist only while a job is running.

5.4.2 Hadoop 1.x Coupled vs Hadoop 2.x Decoupled

To understand why, recall the differences between Hadoop 1.0 and 2.0 that we looked at earlier. In Hadoop 1.x, the storage part and the compute part were strongly coupled: when you add a node you are adding storage and you are adding compute to it. If I want to increase my storage but do not want to increase my computation, adding a node by default increases my computation too — so in Hadoop 1.0, scaling storage without scaling compute is impossible. From Hadoop 2.0 onwards there is a decoupling of storage and compute, and there are multiple benefits.

Hadoop 1.x vs 2.x — coupled vs decoupled:

Hadoop 1.x (coupled): a cluster node is both a storage unit (DataNode) and a compute unit (TaskTracker). Adding a node adds both at once. If you need storage but not compute, you still buy compute; if you need compute but not storage, you still buy storage.
Hadoop 2.x (decoupled): storage (HDFS) and compute (YARN) run as separate layers over the same nodes — and, crucially, the storage layer can be something other than HDFS. Compute and storage can be scaled independently.

Benefit 1 — independent scaling: I can scale compute and storage independently. If I want to add storage I can add just that; if I want more computational resources I can add those.

Benefit 2 — non-HDFS storage is allowed: when storage and compute were coupled, we were bound to use HDFS storage. After decoupling, we can use non-HDFS storage and still run Hadoop — for example we can put the data in S3 buckets. This is exactly what Nasdaq has done.

5.4.3 Why EMR and S3 Instead of HDFS

The case for EMR plus S3: EMR gives on-demand setup of Hadoop clusters on the cloud to run short-term projects with existing technology, and S3 lets you move terabytes of data onto cloud storage and scale very large datasets.

Why not HDFS? Because you want to decouple the data from the compute: the data size is disproportionately higher than the compute frequency, so the storage needs frequent scaling. You cannot add a Hadoop node just for the data — especially with the replication factor, adding a node means replicating everything to it.

Worked example — why HDFS replication makes the mismatch worse.

Suppose a workload has 10 terabytes (TB) of data but only runs analytics for a few hours a day — the data size is "disproportionately higher than the compute frequency".

With HDFS: HDFS default replication factor is 3, so those 10 TB of data occupy ~30 TB of cluster disk. Every new node that joins the cluster must receive replicas, so "adding storage" drags compute nodes and replication traffic along with it. The 30 TB footprint is idle outside the few processing hours — and you are paying for the compute that is attached to it 24/7.
With S3 + EMR: the 10 TB sits once in S3. When a processing window opens, you launch an EMR cluster, it reads the data from S3, runs the jobs, and you terminate the cluster when the window closes. Compute hours are paid only during the window; storage is paid per byte-month whether or not a cluster exists.

Sense-check: the storage-only workload is exactly the case where the coupled model over-buys — 30 TB of replicated disk tied to compute you rarely use, versus one copy in S3 plus short-lived compute. That is the cost efficiency Nasdaq buys by breaking the HDFS habit.

The price of decoupling: locality of reference is lost. In classic Hadoop, compute is moved to the data (a scheduler places tasks on nodes that already hold the data blocks). With S3 + EMR, data is not local to compute nodes — the EMR cluster must read it over the network from S3, and the network transfer cost/time replaces the disk-local read. The trade-off is deliberate: for workloads where the data is huge and the processing is short and intermittent, network reads of cheap storage beat keeping 3×-replicated data permanently attached to compute. The student question in section 5.4.5 develops exactly this tension.

5.4.4 Netflix Does the Same

Netflix has done a similar thing. The EMR file system layer enables the compute nodes to access the data in S3: Elastic MapReduce can read the data from S3 buckets directly rather than shifting the data. You can hook the data from the S3 buckets and start your map and reduce jobs — that is possible. So when Amazon offers both components — EMR for compute and S3 for storage — there is a way to connect them for efficient processing.

Worked example — the EMR file system layer (Netflix pattern).

Netflix's batch processing runs a similar architecture: data lands in S3, and EMR clusters run analytics directly over it.

Write once: processed data (for example, the results of ETL or recommendation-model inputs) is written to S3.
Launch on demand: when an analytics job is scheduled, EMR launches a cluster configured to use the EMR file system layer (s3:// paths in Hive, Spark, or MapReduce jobs).
Read in place: the cluster reads data from S3 buckets directly — no copying or "shifting" of data from S3 into HDFS first.
Job runs → cluster terminates: compute disappears after the job; the data stays in S3.

The point to remember: the EMR file system layer is the bridge that lets the two AWS components work as one system — compute reads storage in place. This is the pattern that lets both Nasdaq and Netflix handle data volumes far too large to shuffle into per-cluster HDFS copies.

5.4.5 Student Questions and Answers

Q: In Hadoop we are moving compute near to the data. Here, with EMR, the data needs to be brought near the compute. Is this understanding correct?

A: It depends on how you architect your application — you need to check whether it makes sense to put them together or whether it makes sense to separate them out. What is the cost involved if I add a compute node? What is the cost involved if I add a storage node? Because you may want to scale them independently, you are losing one feature of Hadoop — the locality of reference — as you have correctly pointed out. On the other hand, you need to understand the pricing things properly and then decide on the infrastructure part: what I need and what I don't. Pricing is altogether a very huge and probably a separate topic which is not part of this course, but yes, it needs to be considered while you look at how much resource usage is there and whether it makes sense to put them together or to separate them out.

The follow-up: Compute and storage is decoupled, so the locality of reference we were getting there may not be there, but again we need to check the pricing parameters as well. And EMR can read the data from S3 buckets — both are AWS components, so there is a way that your cluster can hook up to the S3 buckets and read the data. There are multiple things we need to think about before moving our applications to the cloud — multiple parameters.

Q: Has anyone used AWS? Any one of you?

A: No one — except last semester, in a cloud computing course, where there may have been setting up an EC2 instance and all those things, or something else like Elastic Beanstalk. That gives some idea. Also: there were one or two questions left unanswered from the previous lab session, including one on MongoDB — that will be checked and confirmed, and any other questions from previous sessions can be dropped over email.

Recap + bridge: Nasdaq (and Netflix) host big data by decoupling storage from compute — data in S3, short-lived EMR clusters on demand — instead of the coupled HDFS-everything model of Hadoop 1.x. The trade-off: you lose data locality, but you gain independent scaling and cost efficiency for storage-heavy, intermittently-processed workloads. The student exchange shows the decision is a pricing/architecture judgment, not a one-size-fits-all rule — a theme that continues in the pros-and-cons discussion next.

5.5 Pros and Cons of Cloud Computing

The Nasdaq example showed the appeal; this section makes the full trade-off explicit. The honest picture is that the cloud is conditionally cheaper and simpler — the conditions are what the cons section is about.

5.5.1 The Pros

Cost effective in specific cases — especially for short-term projects. If I want to do certain experimentation, I can move my application to the cloud and carry out experiments. But be clear about the usage: know how many resources you are going to use. (The "specific cases" wording is deliberate — the next section shows when it stops being cost effective.)

No in-house capability needed. You do not need to own data centers or hardware; you can access the cloud from anywhere, from anywhere in the world, because of global data centers. A startup can run an infrastructure footprint that would otherwise require building a data center.

Reliability. Once your application is up, it is the responsibility of the cloud vendor's experts to keep your system up. They take care of fault tolerance and other aspects.

Backup and recovery are managed by the experts at the cloud service vendors.

Storage and compute scaling as required for short time periods. For example, maybe there is a sale happening on an e-commerce website: you may need more resources at that particular moment. You should not guess anything — there could be services that predict the demand, and accordingly you can put the resources in place.

The key insight behind the pros: the cloud converts capital expense into operating expense and fixed capacity into elastic capacity. On-premises, you pay for peak capacity all year to serve a few hours of peak; on the cloud, you pay for exactly the capacity curve you actually consume. That is why the "flash crowd" workloads — a sale, a product launch, a festival ticketing window — are the canonical cloud wins.

5.5.2 The Cons

Not very cost effective if it is not planned well. This is important. You need to know how many resources your application will use. We should not over-procure: you may say "okay, these many resources are enough", but that may be another prediction. We should have a proper way to know how much we will be paying, and we should track that. Only then will it be cost effective; otherwise you may end up paying a high operational cost.

Vendor lock-in. Suppose you have moved your application to the cloud and you store your data in S3 buckets. You are using AWS today and you have built a certain ecosystem around it — how the different technologies will read the data, process it, and all — everything is set up. Then it becomes very, very difficult to move from one vendor to another, or to host it on your private setup.

Dependence on external providers. You need to depend on external providers for infrastructure and application if anything goes wrong — there are cloud service providers on which you have to depend. When the vendor's service has an outage, your application is down too, and there is no one on your team who can fix it.

No fine-grained control that you have on the system. The provider dictates the machine catalog, the network architecture options, the upgrade windows; you cannot reach into the physical infrastructure.

Security. This is an important topic: what about the security of the data on the cloud, or on the hybrid mode of operation where something is on premises and something is on the public cloud? How should we connect it? It may not be as simple as putting up a firewall and specifying certain rules. It may be something more than that. There are more security services offered by the cloud service providers, but you need to pay for those if you want to use them.

The over-procurement trap (called out by the professor): you may say "okay, these many resources are enough" — but that statement is itself a prediction, and predictions need measurement behind them. The discipline is: estimate usage from the application architecture, monitor actual consumption, and track the bill. Over-procurement converts the cloud's pay-per-use model into paying for idle capacity — the exact thing you moved to the cloud to avoid.

Recap + bridge: the pros (cost for short-term work, no in-house capability needed, reliability, managed backup, short-term scaling) and the cons (unplanned cost, vendor lock-in, dependence on external providers, no fine-grained control, security) are two sides of one coin: the cloud is cheap when you size it right and expensive, sticky, and less controllable when you do not. With the economic picture set, the next sections go inside the machine — how an IaaS cloud is actually assembled from its components.

5.6 Anatomy of an Infrastructure as a Service Cloud

5.6.1 The Building Blocks

This architecture is taken from Red Hat OpenStack, and any IaaS cloud from any vendor typically consists of the same few components:

Networking services — because multiple instances are there, you need network services. Instances must be able to reach each other and the outside world, and the provider must manage that at scale.
Compute services — the computational services that run your workloads (the "hypervisor" layer that hosts the virtual machines).
Block storage service — storage volumes attached to instances (the virtual disks that give an instance its file system).
Image storage services — to store the images of your virtual machines (VMs), so a machine can be recreated from its image. An image is a snapshot of a VM's disk — OS and configuration included — so a new instance can be booted from it at any time.
Object storage — for unstructured data (the S3-style store: files addressed by key, not by block; used for large, unstructured payloads).
Telemetry services — to track how much you are using (the measurement half of "measured service").

The division of labour inside an IaaS cloud. Block storage and object storage answer different questions: block storage is the raw virtual disk attached to one instance (fast, low-level, instance-scoped), while object storage is a network-addressable repository for unstructured data (durable, shared, key-addressed). Image storage is the templates for instances; telemetry is the meter that makes billing possible. Together these six services are the "shared pool" from the formal definition, made physical.

5.6.2 Orchestration and the Heat Stack

On top of those comes an orchestration service, which creates a workflow: once you have decided "okay, this has to be used", it creates a Heat stack — this is a definition of the technologies you are going to use to build your virtual system. The Heat stack gets executed to actually build the environment.

Think of a Heat stack as a recipe, and orchestration as the chef. A stack is a declarative description: "create two compute instances of size X, attach this block volume to each, connect them to this network, expose this port." The orchestration service reads the stack and executes it — provisioning the instances, wiring the network, attaching storage — in the right order. One template, reproducibly rebuilt every time: this is the same idea that later shows up as "automate build and deployment" in the best-practices list (section 5.17). The name Heat comes from the OpenStack project that provides this orchestration; the stack is the resulting collection of resources created by running the template.

5.6.3 The Dashboard

Users interact through a dashboard — a graphical user interface through which users interact with whatever the cloud service vendors offer. From the dashboard you should be able to see what kind of services you are looking into. AWS has a console, which is exactly this dashboard.

Recap + bridge: an IaaS cloud is assembled from standard building blocks — networking, compute, block storage, image storage, object storage, and telemetry — orchestrated by a service that turns declarative definitions (Heat stacks) into running environments, all fronted by a dashboard. AWS's console is this dashboard; the next section zooms into how AWS arranges its physical geography (regions and availability zones) to keep that dashboard's workloads running when things fail.

5.7 AWS Regions and Availability Zones

5.7.1 Regions and Data Centers

When you host a service, data centers are located in specific regions, and you choose the region where you want to host your services. In the AWS architecture picture, the internet sits on top, and inside an AWS region you have certain instances, block storage connected to those instances, and S3 buckets for storage of state — the S3 buckets are the primary external storage for an instance.

Region = a geographic location containing data centers. A region is a named geographical area (for example, us-east-1 in Virginia, eu-west-1 in Ireland, ap-south-1 in Mumbai). You pick a region for three reasons: latency (put your service near your users), compliance (some regulations require data to stay in a country), and cost (prices differ by region). Inside a region, the architecture is the same picture every time: instances, their attached block storage, and S3 buckets as the external state store.

5.7.2 Availability Zones and Redundancy

Each region has certain availability zones. Catastrophic failures can happen within a zone: a power failure in a particular data center, or a natural calamity affecting an entire data center. Availability zones within a region are connected with a low latency network. If something happens, the data should be backed up and your services should be up and running, so you build up redundancy with physical options — an availability zone has redundant power. Data may be flowing from the region where you are hosted to the availability zones, so the data is backed up to the availability zone. This gives a kind of fault tolerance: you can deal with failures more importantly because the compute instances can be moved across these availability zones.

Think of regions and availability zones as city and neighbourhoods. A region is the city; availability zones are the neighbourhoods, each an isolated data center with its own power, cooling, and networking, connected to the others by low-latency links. If one neighbourhood loses power, the others keep running — so you place copies of your service in two or more zones, and the system survives the loss of one zone entirely. The low-latency links between zones are what make this practical: data can be mirrored and instances can fail over without users noticing. The professor's rule of thumb: within a region, zones give you redundancy; across regions, you get disaster recovery.

Single-zone deployment is the classic availability mistake. If you deploy all instances and all data in one availability zone, the zone's failure is your failure — no amount of redundancy inside the zone helps when the whole data center is down. The design-for-failure list (section 5.13) formalizes the fix: deploy across multiple zones, replicate data across zones, and be able to relaunch instances elsewhere.

Recap + bridge: a region is a geographic cluster of data centers; within a region, availability zones are isolated facilities with redundant power, linked by low-latency networks. Backing data up across zones and moving instances between them gives fault tolerance. This is the physical layer under the architecture picture — next, the individual building blocks that live inside a region: compute instances, storage, networking, and the elastic IP trick.

5.8 Compute, Storage, and Networking Building Blocks

5.8.1 Compute Instances and Elastic Static IPs

A compute instance is what actually runs your work. It could be a machine, a VM, a container, or a function — that last one is a new term, and it connects to Function as a Service and serverless computing, which we cover separately. A compute instance comes with DNS support and elastic static IPs can be started for it.

The elastic static IP is a neat trick for availability. If there is any EC2 machine or VM running, some IP is given to it so it can be located. Now what happens if that system goes down? You back up the image of that particular system and you host it on some other machine. The user should not get to know that you changed the machine, so you configure the other machine with the same IP — the end user never finds out. You migrate your IP to a new machine, and that is possible with the help of these elastic static IPs. You can purchase these IPs from the cloud vendors.

The elastic IP trick — a hotel room number that follows you. Normally an IP address is tied to a machine, the way a phone number is tied to a physical handset. An elastic static IP is a public IP address you own and can reattach to any instance in your account — the way a hotel guest's room number can be reassigned: when a guest (the running machine) dies, the room number (the IP) is given to the next guest on the spot, and nobody outside knows anything changed. Concretely: machine A with IP 1.2.3.4 fails → restore A's image as machine B → attach IP 1.2.3.4 to B → all traffic resumes seamlessly. The user sees the same address before, during, and after the failure. This is the professor's canonical design-for-failure mechanism.

5.8.2 Attached Volumes and External Storage

An attached volume is a block storage volume connected to a compute instance, used for the local file system. Then there is external storage for raw or unstructured data coming in — that is the S3 bucket in this case.

Two kinds of storage, two jobs.

	Attached volume (block storage)	External storage (object storage / S3)
Attached to	one specific instance	the account, accessible from anywhere
Used for	local file system, OS, working data	raw/unstructured data, backups, shared state
Lifetime	lives and dies with (or is reattached to) instances	persists independently of any instance
Access	block-level, low latency	key-addressed over the network

The distinction matters for architecture: the instance's working files go on the volume; the durable payload — raw data coming in, backups, anything that must survive the instance — goes to S3.

5.8.3 Security Groups, Load Balancing, Scaling, and Snapshots

Security groups let you write certain rules: we do not want everyone to have access to everything. Different people should have access to certain portions and not to each and every portion, so you specify rules to control access to the compute and storage instances. A security group is an instance-level virtual firewall: rules like "allow HTTPS from anywhere" or "allow SSH only from the office IP".

Load balancing divides the load across the multiple instances. The load balancer sits in front of a set of instances and distributes incoming requests, so no single instance is overwhelmed.

Scaling can be manual or automatic: manual means you set up an EC2 instance and you add it up yourself; automatic means it is taken care of by the vendor — for which you need to pay something extra. (Section 5.12 develops the three scaling approaches in detail.)

Backup and recovery work through snapshots: snapshots can be taken from time to time to preserve a state, so that in case of a failure you can restore. A snapshot captures the state of a volume at a point in time; restore = build a new volume from the snapshot.

5.8.4 The AWS Console

This is one typical snapshot of a console: there is a panel on the left across which you can look into multiple things — networks and security, instances, how many instances are running, and all those things — plus a navigation bar on top. You can create an account, host an instance, and then see this console once to get a look and feel of it.

Console warning (from the professor's lab experience): be very, very careful — when you create an account they might ask you for a credit card, and if there is any processing happening you might be charged for that. Certain credits may be given, but we need to check the pricing — charges are not heavy for a small, rate-limited processing, but if it is heavy processing, they can charge. The discipline from section 5.5 applies even to a first lab experiment: know what you are running, and check the pricing before you let anything run unattended.

Recap + bridge: the building blocks inside a region are compute instances (machines, VMs, containers, or functions), elastic static IPs (addresses that can follow a replacement machine), attached block volumes plus S3 external storage, security groups (instance-level firewalls), load balancing, scaling, and snapshots — all operated through the AWS console. Next: the practical question of choosing which machine specification to rent, and the pricing discipline around it.

5.9 Choosing the Right Compute Specifications

5.9.1 Specifications, Pricing, and the Application

When moving to the cloud you need compute resources and storage, and the discussion for compute is: you pick from a set of machine specifications. Cloud vendors generally give you options — say they have given you ten options: you can go with two cores and 4 GB, or four cores and 16 GB, or one of the other specifications. The question is how to decide what the right specifications are for your application. How do we know whether we need a two-core machine or a four-core 16 GB machine?

The decision inputs. The right specification comes from three facts about your workload, not from the vendor's menu:

Resource usage of the application — what does the application actually consume? Memory-bound jobs (in-memory analytics, large caches) need RAM; CPU-bound jobs (encoding, simulation) need cores; I/O-bound jobs need storage throughput.
Pricing — how does the hourly cost scale across the menu? It is tempting to assume linear scaling, but the professor warns explicitly: a four-core machine may not cost twice a two-core machine; at times the cost may not be linear.
Application architecture — can the workload be split across smaller machines, or does it need one large machine? Two smaller instances may cost less than one large one if the application can be distributed.

This is very, very critical from the operating cost standpoint: we need to understand the pricing, the resource usage of our application, and then decide. One should have an understanding of billing, pricing, and also the application architecture, to pick up the right set of services and the right set of machine specifications. We cannot simply say "a two-core machine with 4 GB may cost you \(x\) amount and a four-core machine may cost this much, maybe two times \(x\)" — at times this cost may not be that linear. If we do not plan it properly, we may end up paying a very high operational cost. Pricing is altogether a very different topic. That is one part of it: a bunch of options are given by the cloud vendors to make your job easy, and we can choose from them.

The linear-pricing assumption: "four cores costs about twice two cores" is a guess, not a rule. Instance families differ in CPU generation, memory type, network bandwidth, and discounts (reserved vs on-demand vs spot), so the price curve across the menu is irregular. Pick the specification by measuring the application's actual usage, then reading the price per hour off the vendor's table — not by scaling a headline price by cores.

Exam note: the pricing question — how to put a rupee figure on a specific specification — is stated to be outside the scope of this course. What matters here is the discipline: understand resource usage and application architecture before choosing a specification, and remember that costs may not scale linearly.

5.9.2 The Full Compute Checklist

Working through the compute part end to end:

Pick the right specification for the application, after understanding pricing and the application architecture.
Define the security profile to allow or deny specific traffic — you write certain rules in the firewall, deciding that this particular instance can listen to traffic coming from this particular source.
Choose multiple instances across regions and availability zones for fault tolerance.
Decide between auto scaling and manual scaling. In manual scaling you add new instances to a load balancer; with auto scaling the new instances will be added on the cloud as per the requirement.
Use elastic IPs to quickly reassign instances in the other availability zones, which stay connected because of the fault addresses. As mentioned, when a machine is going down, we do not want to give the end user an experience that some machine has died and another machine has taken over — we replicate the same IP on another machine across different availability zones, and that keeps the system up and running without interrupting the end user.

There is another very broad topic attached to the security profile: identity and access management (IAM) — who can access what, with different roles for different users. IAM is the account-level access-control service: users, groups, roles, and policies that decide who may create instances, read S3 buckets, or stop services. It appears again in section 5.15 as part of the security-at-every-layer story.

Recap + bridge: choosing compute is a five-step discipline — specification from real usage, security profile, multi-region/zone placement, scaling choice, elastic IPs — plus IAM for who-can-do-what. The next section removes the server-manager entirely: serverless computing and Function as a Service, where the provider runs your code and you never see an instance at all.

5.10 Serverless Computing and Function as a Service

5.10.1 Serverless Computing

When we start creating and running cloud applications, we need infrastructure. But there is another way of using the cloud: serverless computing. Suppose I want to use a certain database and I do not want to install and keep an instance — the cloud service platform offers database servers, a database service, and I just use that DB. I need not manage any database; the responsibility is given to the cloud service vendor. This gives an illusion to the application developer that they need not focus on databases, connecting to databases, and managing data — it is taken care of by the cloud service vendor. That is what serverless is all about. You can explore more about this through AWS Lambda.

The word "serverless" is a promise, not a literal fact. Servers still exist — the point is that you never see or manage them. The provider owns the machines, the operating systems, the patching, and the capacity planning; you just consume the service. The developer experience is the giveaway: with a serverless database you never install, upgrade, or back up a database server — the vendor does all of it, and the application developer's mental model becomes "a database exists", not "a database runs on my instance".

5.10.2 Function as a Service: A Subset of Serverless

Function as a Service (FaaS) is a new way to host code at the function level, where the user is abstracted away from the underlying infrastructure needed to run the function. FaaS is a subset of serverless computing: serverless computing can happen for any kind of resource, while function as a service is a cloud service where, whenever a function is called in response to a particular trigger, you get charged based on the calling frequency and the duration. The minute difference: a function responds to certain events — say there is a web page and somebody clicks a certain component on the web page, and then the function is called.

Concretely: I create a function and host it on a serverless platform. I do not need to worry about whether I should install any of the runtimes on my system — whether I wrote a Java program, a Python program, or a Ruby program, the platform takes care of that. I simply write the function; I need not manage installation and the things around it; the cloud service vendor automatically takes care of that.

Serverless ⊃ FaaS. Serverless is the umbrella idea — the provider manages any kind of resource for you (a database, a queue, a cluster). Function as a Service is the narrower idea — the provider runs your code, per function, per event. The relationship is set inclusion: every FaaS is serverless, but not everything serverless is FaaS. A serverless database (like a hosted MongoDB) has no functions at all — it is serverless without being FaaS. The professor calls out this subset relationship explicitly, so it is a distinction to keep sharp.

5.10.3 Triggers and Stateless Functions

What triggers a FaaS function? Any call to an API, a file upload (somebody has uploaded an image), a timer that expired, a message arrival in a queue, or an alert notification. These functions can use storage and DB services, and SNS (the notification service from AWS) for input and output — the input to the system and the output of the system. But they will not maintain state: functions are stateless — there is no DB connected to them. If you want to do something, there could be external calls.

Stateless means: the function remembers nothing between calls. Each invocation starts fresh — no open connections, no cached session data inside the function. If a function needs to remember something (a counter, a user session, a job ID), it stores it externally — in a database, S3, or a queue — and reads it back on the next invocation. That is also why FaaS and message queues are natural partners: a function consumes a message, does its work, and emits a message for the next stage. Statelessness is the price of the provider being able to start and stop instances of your function at will — there is no guaranteed long-lived process to hold state.

When creating a function, you specify things like the memory requirement, timeouts for function execution, and where to get the data from. Once created and hosted on a serverless platform like AWS Lambda, there is special pricing available in the AWS documentation.

5.10.4 Pricing and Configuration of FaaS

Pricing for FaaS is in terms of the number of requests coming in, the duration, and the maximum memory. We can put a limit on the resources allocated for these functions — that is required, so that we are not using too many resources, which would surprise us at the end of the month.

Worked example — how a FaaS bill builds up. Suppose a function is invoked 1,000,000 times in a month, each invocation runs for 200 milliseconds (0.2 s) with 512 MB of memory configured.

Request count: 1,000,000 invocations × (price per request).
Duration × memory: each invocation contributes 0.2 s × 512 MB of compute-seconds; the vendor's bill multiplies the total (here 1,000,000 × 0.2 s = 200,000 compute-seconds, scaled by the 512 MB memory allocation) by the per-unit price.
The ceiling that protects you: the memory limit you configure caps the bill per invocation, and the timeout caps runaway executions — a function stuck in an infinite loop is billed only up to its configured timeout.

Sense-check: both knobs — requests and duration×memory — are things the callers and code control, which is why the professor insists you configure limits: an unconfigured function is an unbounded bill. The per-request and duration prices themselves are published in the vendor's pricing pages (special pricing available in the AWS documentation), not part of this course's examinable material.

These two techniques — serverless computing and function as a service — simplify infrastructure management: there is a lot of infrastructure involved when hosting cloud applications, and we want to simplify the task of managing it. One example: I want to use a serverless DB — I am using a database, but the configuration management is provided by the service provider. Similarly, if I have set up any cluster, I do not want to manage it — I simply use it and let the service provider take responsibility for configuring and managing it.

Recap + bridge: serverless computing hands infrastructure management to the provider for any resource; FaaS is the subset where your code runs per-event — triggered by API calls, uploads, timers, queue messages, or alerts; functions are stateless, so persistent data lives externally; pricing is requests × duration × memory, and you must configure limits to avoid bill surprises. Next: the network side of the private-space idea — the virtual private cloud (VPC) and its services.

5.11.1 The Virtual Private Cloud

You have certain instances, and those instances are connected via a network. Can you manage that network? When we are using a public cloud, we can still carve out a private space that we do not want to share with others — a private space of one organization. Around it you need a network security fencing, because it is private to one particular organization. We call this the virtual private cloud (VPC): a private cloud set up on AWS, typically used instead of setting up a private cloud on premises. You have control over the networking within the virtual private cloud, and you can create a kind of isolation around it.

The VPC is your fenced garden inside the shared park. The public cloud is a shared park, but you can fence off a garden that only you use: your own address space, your own subnets, your own routing — isolated from every other customer. This is not the private deployment model from section 5.2 (that is physically private hardware); a VPC is a logically isolated network on shared hardware. You get private-cloud-style control of networking — subnets, IP ranges, routing tables — without building any of the physical infrastructure.

5.11.2 Subnets, NAT, VPN, and Routing

Once you have a VPC there are a bunch of things you can do. You can specify subnets for public access, and subnets for private IPs that are not externally accessible — you have that kind of control, which you do not have in a plain public cloud, where networking is largely managed by the cloud service vendors. Subnets can be within the availability zones in AWS.

Network address translation (NAT) is also possible: we expose one public IP to the outside, and we do not want to expose how many machines are under it, so we do NAT around it. That is optional.

For external access, a virtual private network (VPN) can be used. If it is a hybrid environment — something on premise and something on the virtual private cloud — we need to connect them for various reasons, maybe for data transfer. We can use virtual private networking applications. Or our application could be at multiple sites, and we want to connect the VPC with its multiple sites: we can specify certain routing options for connecting the virtual private cloud to the enterprise sites. These are some of the configurations we get access to when we deal with a VPC; otherwise, in public clouds, this is largely done by the vendor.

The VPC toolbox — what each service does:

Service	Role
Subnets	Divide the VPC's address space; public subnets hold instances reachable from the internet, private subnets hold instances with no external address
NAT	One public IP hides many private machines — the outside world sees a single address, and the NAT device forwards traffic inward
VPN	Encrypted tunnel connecting the VPC to an on-premises network (the hybrid-cloud bridge)
Routing options	Connect the VPC to enterprise sites or between multiple sites of the same application

The pattern to internalize: public means "reachable from the internet"; private means "not externally accessible"; NAT lets private machines initiate outbound traffic while staying unreachable from outside; VPN connects the VPC to your own premises securely.

5.11.3 DNS and Direct Connect

DNS services may also be provided, which give a name to IP address translation for internet-based applications — in AWS that service is Route 53. VLAN services may be provided for connecting the on-premise network to the cloud, using AWS Direct Connect. When you move the data, you need more constraints: whether the cloud location supports an enterprise router, has the right internet routing protocol, the right physical link type, and so on — because when two parties communicate, they need to sync up on something. These are the services you can configure when you look for the VPC. The VPC diagram is important.

Pitfalls when designing the VPC:

Private ≠ unreachable forever. A private subnet is private because the routing says so; a single misconfigured route, an over-permissive security group, or a NAT rule can expose it. Isolation is a configuration, not a property of the subnet itself.
VPN vs Direct Connect confusion. A VPN runs over the internet with encryption (cheap, good for modest traffic); Direct Connect is a dedicated physical link from your premises to AWS (low latency, high bandwidth, expensive). "When you move the data, you need more constraints" — volume and latency requirements decide which one you need; the two parties must agree on router support, routing protocol, and physical link type.
Route 53 is a DNS service, not a router. It translates domain names to IP addresses (and routes traffic within AWS); it does not replace the VPC routing tables.

The VPC diagram — instances inside subnets, the internet gateway at the boundary, NAT in the public subnet, VPN/Direct Connect on the hybrid side — is worth drawing mentally whenever you hear "isolation" or "hybrid" in a cloud discussion: it is the concrete answer to how an organization's private space exists inside the shared cloud.

Recap + bridge: the VPC is a logically isolated private network inside the public cloud, giving you control (subnets, NAT, routing) you do not get in plain public networking, plus DNS (Route 53) and dedicated or tunneled connections to on-premises (Direct Connect, VPN) for hybrid setups. Next: the reason this whole machinery exists — elasticity, and the three ways to scale (up, out, auto).

5.12 Elasticity: Scaling Up, Scaling Out, Auto Scaling

5.12.1 Automated Elasticity

This is about automated elasticity, and it is the reason we move to the cloud: we want to scale as per the demand. It is not that easy to buy your infrastructure and set it up quickly, while on the cloud it is possible. So why do we need the cloud, and how did things progress?

The lecture chart plots infrastructure cost against automated elasticity and scalability: as you move from manually managed on-premises infrastructure toward automated, elastic cloud infrastructure, the cost of meeting demand safely falls — because you stop paying for capacity you do not use. The takeaway of the chart: the on-demand resources are available, but how to scale them is very important. You should not over-provision the resources and not use them (then you are paying extra), and you should not under-provision them either — under-provisioning may lead to loss of your customers, loss of your business.

The two failure modes of scaling:

Over-provisioning — you rent more capacity than the workload ever needs. Safe, but wasteful: every idle hour is money paid for nothing. On the cloud this is the easy mistake because capacity is one click away.
Under-provisioning — you rent less capacity than demand requires. The system slows down or fails under peak load; the consequence is not a bill but lost customers and lost business — the reputation damage a retailer suffers when the checkout dies during a sale.

The discipline of elasticity is staying between the two: provisioned capacity should track actual demand. That is exactly what automated elasticity does, and why section 5.12.3's three curves are the heart of this topic.

5.12.2 Student Questions and Answers

Q: I have a question related to the assignment. This is the first time I'm going to use a remote lab. Is there any guide on how to bring the test data into the remote lab environment?

A: The answer is given to you. You can use GitHub. Second: you can upload the file in your Google Drive, press your email inside that, and download that.

Q: It looks too theoretical and too abstract — we are talking just in terms of how the things happen. We are not looking into practicals.

A: To me also it looks very abstract. But this course is too vast. We cannot go to practicals at every level.

5.12.3 Scale-Up, Scale-Out, and Auto Scaling

Traditional scale-up approach (own infrastructure): you have spent certain cost initially — this is your own infrastructure, and you maintain it for a certain period of time. Then you realize, let us upgrade it, and you spend an extra cost; after a year you think, let us upgrade it again, and so on. If we follow this kind of approach, at certain times we may not be able to meet the peak demands that might happen. Look at the lines on the chart: this is your actual demand, and this is the demand prediction. In the shaded region, the resource need was at one point but the provisioned level was below it — so in this portion we might lose our customers, even if we are scaling on a yearly basis.

Traditional scale-out approach: you move to a cluster mode — you add more nodes and the capacity increases. Now we are increasing more frequently, but bringing the nodes into the cluster may take some time, so it is not even that easy. The region of shortfall has reduced, but we still come across a certain region where it poses a challenge to deal with all the orders — the processing capability was still not meeting it.

Auto scaling: look at what my actual demand is, and then allocate resources according to it — this is what auto scaling depicts: at what point of time I will have this much, and I should set up these many resources accordingly. I am bringing up certain resources, and after going up it also comes down when they are not needed — which is a much better way, because I can increase and release resources on demand, and it saves me cost. Applications can be provisioned with resources on demand when they need them. This means we need to rethink the application: understand which application components can be elastic, and what the impact of being elastic is on the overall application.

Three scaling strategies, compared:

Strategy	What you do	How often you adjust	Cost behaviour	Failure mode
Scale-up (own infrastructure)	Replace machines with bigger machines	Rarely (yearly upgrades)	Big lumpy purchases; you own capacity	Cannot meet demand spikes between upgrades — customers lost in the shaded region
Scale-out (cluster mode)	Add more nodes to the cluster	More frequently (but node bring-up takes time)	Capacity grows in node-sized steps	Shortfall region shrinks but still exists — provisioning lags demand
Auto scaling (cloud)	Measure actual demand; allocate and release resources to match	Continuously, up and down	Pay only for the resources that are up	Requires the application to be elastic (rethink components)

Visual intuition — demand vs provisioned capacity over time. The chart has time on the x-axis and capacity on the y-axis. Three pairs of lines: actual demand (jagged) and provisioned level (stepwise). In scale-up, the provisioned line is a staircase with one step per year — mostly above demand but visibly below it in the shaded spike region where customers are lost. In scale-out, the staircase has more, smaller steps — the shaded shortfall region shrinks but a peak still pokes above the last step. In auto scaling, the provisioned line hugs the demand curve closely, rising before peaks and falling after them. Takeaway: the area where demand is above provisioned capacity is lost business; the area where provisioned capacity is above demand is wasted money; auto scaling shrinks both areas at once.

Why "rethink the application"? Auto scaling only works if the application can use a varying number of resources. A single monolith that holds all state in memory cannot shed instances; an application split into independent, stateless components can. So the scaling strategy is chosen twice: at the infrastructure level (which strategy) and at the application level (can components start and stop cleanly?). This is the bridge to section 5.14, where the application side — loose coupling and queues — is built out in full.

5.12.4 How the Cloud Business Was Born

How did the cloud business emerge? Amazon was hosting an online application and they had provisioned resources for it — they over-provisioned the resources. And that is where they thought: let us sell this kind of resource to the others. Amazon ran an online application for their internal use, which was probably a cloud kind of setup, and they found they had over-provisioned the resources — that is how they came up with the idea of selling it to the others. This is how the cloud business emerged: Amazon was the first to lead with it.

Worked example — the origin story as a business case.

Amazon built its own infrastructure to run its online retail platform, sized for peak demand — holiday season, sale events — which meant the infrastructure sat mostly idle the rest of the year. The over-provisioned capacity was a cost with no revenue.

Observe: the infrastructure was over-provisioned relative to average demand — the classic over-provisioning failure from section 5.12.1, but with a twist: the idle capacity was real, running hardware.
Repurpose: instead of wasting the idle capacity, sell it. A customer rents an EC2 instance — a slice of that idle pool — and pays per usage.
Result: Amazon monetizes capacity that would otherwise be idle, and the customer pays only for usage — the two-sided deal at the heart of every cloud provider.

Sense-check: the story is consistent with everything earlier in this session — resource pooling (one physical pool, many customers), measured service (billing per usage), and why AWS is the market leader (section 5.3.4): they were first, because they had the over-provisioned infrastructure and noticed the opportunity. The cloud business is over-provisioning turned into a product.

Recap + bridge: elasticity is the reason for the cloud: provisioned capacity should track demand, avoiding both over-provisioning (wasted money) and under-provisioning (lost customers). Scale-up and scale-out cannot track demand tightly; auto scaling can — if the application is designed to be elastic. The Amazon origin story shows over-provisioned internal infrastructure becoming the cloud business itself. Next: how you design systems that survive failures — because elasticity and resilience are built, not bought.

5.13 Design for Failure

5.13.1 The Principles

In AWS we design for failures. The theme has appeared before: if one machine is down, we make use of elastic IPs, which give an illusion to the end user that the machine never died. You configure the state of the machine onto some other machine with the same IP address, and the user feels the system is never down — because the IP was statically allocated and you simply moved it to a different machine.

The design philosophy: failure is the default assumption. On-premises thinking assumes machines are reliable and you add protection where budget allows. Cloud design inverts this: assume any machine, any availability zone, any region can fail at any moment, and build so that no single failure takes the service down. The elastic IP from section 5.8 is the prototype: the address survives the machine, so the user-facing identity of the service is decoupled from any one physical instance.

These are the designs we need to consider while dealing with failures:

Use multiple availability zones during deployment.
Create replicas across availability zones.
Maintain images — Amazon machine images (AMI) — for restoration and replication, in case your data is corrupted.
Use a monitoring service — AWS CloudWatch is one — to look at how many resources are being used.
Create auto scaling groups to replace the failed instances quickly.
Take snapshots and back up on the external storage (S3) to store the system state: if any system goes down, and a backup has been taken, it is easy to take the copy from this backup and provide it.

The design-for-failure toolkit — one job per tool:

Tool	What it does	Which failure it answers
Multiple availability zones	Place instances in two or more zones	A whole zone failing (power, natural calamity)
Replicas across zones	Copy data to a second zone	Data loss when a zone dies
AMI (Amazon Machine Images)	A reusable image of an instance's disk+config	Corrupted or lost instances — relaunch from the image
CloudWatch	Monitors resource usage and health	Silent degradation you do not notice until it is too late
Auto scaling groups	Automatically replace failed instances with fresh ones	A single instance dying — the group restores the fleet
Snapshots to S3	Point-in-time backups of volumes stored externally	Restoring system state after a failure

The pattern across all six: redundancy (more than one copy of everything that matters), recoverability (a path back from a failed state — images, snapshots), and automation (monitoring plus auto scaling so recovery happens without a human on call).

Worked example — the failure chain, end to end. Suppose a web instance in availability zone A dies at 3 a.m.

CloudWatch notices the instance is unhealthy (heartbeat missed, metrics dropped).
The auto scaling group terminates the dead instance and launches a replacement — in availability zone B (the group spans zones).
The replacement boots from the AMI, so it starts with the same OS and configuration as the original.
Its volumes are restored from the latest snapshot in S3, and the elastic IP is reattached — the public address never changes.
Data replicas in zone B already cover anything written before the failure.

Sense-check: each step answers a different question — was it noticed? (CloudWatch), is there a replacement? (auto scaling group), can it be rebuilt? (AMI), can state be restored? (snapshots), does anyone notice? (elastic IP). No single tool covers the whole chain; the design is the combination.

Recap + bridge: design for failure means assuming failure and stacking redundancy, recoverability, and automation: multiple availability zones, cross-zone replicas, AMIs, CloudWatch monitoring, auto scaling groups, and S3 snapshots — with the elastic IP making replacements invisible to users. The same design philosophy now moves from the infrastructure to the application itself: elasticity at the component level, which is section 5.14.

5.14 Designing Elastic Applications

5.14.1 Tight Coupling vs Loose Coupling

This is about the overall application being elastic, and one way to achieve it is to decouple the application components. Look at two designs. The first design has three controllers — certain logic — and they are tightly coupled, in a procedural-programming style: a method in controller A calls a method in B, B calls a method in C, function calls another function, function calls another function. That is tight coupling.

The second design introduces queues: something comes to controller A, and before that it is queued, so it gets some buffering time. Controller A does certain logic and then pushes to the queue for B — not directly to controller B. We are creating a decoupled system here — loose coupling, independent phases.

Tight vs loose coupling — the pattern:

Tight coupling: A calls B directly, B calls C directly — one long chain of function calls. Every component knows the exact identity and interface of the next.
Loose coupling: components never talk directly; they hand work to a queue and the next component pulls from the queue. Each component knows only the queue, not the producer or consumer.

Why queues create independent phases: with direct calls, A cannot finish its work item until B (and B's entire downstream chain) finishes — the whole chain shares one rate of progress. With a queue, A puts a message and is done; B processes messages at its own pace; work in between buffers in the queue. The components no longer run in lockstep — each phase is independent.

5.14.2 Independent Scaling and Impedance Matching

Why does this matter? It is quite possible that these controllers operate at different rates. The rate at which controller A operates may be different from controller B, which may differ from controller C. Suppose controller A is doing a lightweight function — let us allocate three instances to it. Controller B is doing very heavy work — we want to allocate fifteen instances to it. We want to scale them independently; we are trying to impedance match by scaling them independently, and this is where we bring in some decoupling — loose coupling — among these queues. If we were pushing directly, one of these would become a bottleneck. With queues we get buffering, and then depending on what kind of logic each one is processing we can scale them independently. So application components should interact using queues, and components should be stateless as much as possible — without any interaction with the DB or any session state held in an external database. This is a very high-level picture, not a very detailed one.

Worked example — 3 instances versus 15 instances. Imagine an order-processing pipeline with three controllers.

Controller A does light work — say, validating input. You allocate 3 instances of A.
Controller B does heavy work — say, running a recommendation computation per order. You allocate 15 instances of B.
Controller C generates invoices — maybe 5 instances.

With direct calls, the slowest stage drags everyone: A's 3 instances cannot push work into B faster than B's chain allows, and one long call chain means all of A's instances can be blocked waiting on B. With queues, A's 3 instances keep validating and dropping messages into B's queue; B's 15 instances drain the queue at up to 5× the rate of A; when the workload spikes, you add instances to only the stage that is the bottleneck — that is impedance matching: the number of instances per stage matches that stage's per-request cost and rate.

Sense-check: 15 heavy instances + 3 light instances is wasteful if they must run in lockstep; with queues, each stage's instance count is set independently, and the buffer absorbs rate differences — the whole pipeline advances at the rate of its slowest provisioned stage rather than its slowest linked stage.

The bottleneck trap: in the tightly coupled design, the slowest stage in the call chain becomes the system-wide bottleneck — you cannot add capacity to A without the call chain still stalling at B. Decoupling with queues turns each stage into its own bottle that can be widened independently. The pitfall is reintroducing coupling silently — for example, components that share a database table as their "queue" without real buffering, or components that keep session state in memory so an instance cannot be terminated and replaced.

5.14.3 Automating the Infrastructure

This is the automation of infrastructure, which is difficult to manage when it comes to the cloud. The key to auto scaling: create auto scaling groups for different classes of workload, monitor the resources, and take actions — like using machine images to launch new instances, or sending notifications. In the build process, the latest builds go on global external storage, so any instance can spin up and use the latest build. For updates: if there is an application and we want to release an update, we should be able to release it in phases — release it to a small set of users first, and if it is not working properly, we should be able to roll it back.

Automation rests on three practices:

Auto scaling groups per workload class — each class of workload (the light A-stage, the heavy B-stage) gets its own scaling group with its own min/max and metric thresholds, so each scales to its own demand.
Monitoring + actions — the group watches resource metrics and acts: launch new instances from machine images, or send notifications when thresholds are crossed.
Builds on global storage + phased updates — the latest build artifacts live on global external storage (S3), so any new instance boots directly into the current build; updates roll out to a small user set first and roll back if they misbehave. Compensation (rollback) is later listed among the course's best practices (section 5.17).

Recap + bridge: elasticity at the application level means loose coupling — components interact through queues, get independent scaling (impedance matching), and stay stateless so instances are replaceable — while automation handles the operational side (scaling groups per workload, monitoring, builds on shared storage, phased rollouts). The next section adds the security dimension to this architecture: protecting every interaction point, not just the perimeter.

5.15 Security at Every Layer

5.15.1 Why One Firewall Is Not Enough

Security is another parameter. Traditionally, when we hosted applications on premises, we built a firewall, wrote certain rules, and built some fencing around it — "this is our security". But traditional enterprise perimeter security does not work on the cloud; we need a security layer at every layer of the application architecture. Here is why. Suppose our application has a web server that users interact with, an application server, and a database server: the web server interacts with the application server, and the application server interacts with the database server. Only the web server is exposed to the outside world. If we build a firewall around it, you would think the others are never exposed, and if we safeguard the perimeter, the system is safe. But that is not the reality. Intruders who are trying to hack into the system can directly interact with your application server or your database server — that is one possibility. So we need to take care of the security around each and every interaction point: from the data coming from the web server to the application server, build security mechanisms around it that accept data only from the web server, not from anybody else. Similarly, the database server should accept the data from the application server only: configure certain security rules around it — it should only take data from the application server, and all other traffic should be denied. We can do this by building security at each level, and it is also offered by the cloud service providers — but we need to pay for that.

Why the perimeter firewall fails on the cloud (the professor's correction): the assumption behind perimeter security is that everything inside the firewall is trusted. That assumption breaks in two ways. First, intruders can reach the inner servers directly — the application and database servers have network addresses too, and the perimeter does not filter who can reach them if any other path exists. Second, a compromised inner component spreads: if an attacker gets into the web server, the perimeter is meaningless against the application server sitting right next to it in the same network. The fix is defense in depth: at each interaction point, a rule that says "accept data only from this specific source; deny everything else."

Worked example — security rules at every interaction point. Three servers, three rules:

Interaction point	Security rule
Internet → web server	Allow only user traffic on the public endpoints (e.g., HTTPS on port 443); deny everything else
Web server → application server	Accept connections only from the web server; deny all other sources
Application server → database server	Accept only the application server's connections; all other traffic denied

Sense-check: even if an attacker learns the database server's address, no rule lets them connect — every hop is individually locked, so no single breach of one layer exposes the next. This is the concrete meaning of "security at every layer", and it is the layer below the broader tools that follow (IAM, encryption, VPNs).

5.15.2 Data in Motion, Data at Rest, and Keys

Second: protect the data in motion — use encryption, use VPNs to secure your virtual private cloud or to connect from on-premises to the cloud instances. Third: protect the data at rest — the data already stored in the database servers: you can encrypt your files, entire volumes. Key management is critical: make sure your keys are secure and not lost. For data in motion you can also buy SSL certificates. And there is the identity and access management (IAM) service: there are different roles for each user, and each user should be able to access certain parts and certain ports — that can be done through IAM. It is a very, very broad topic. In one line: use instance-specific virtual firewalls for compute instances, load balancers, and so on — there are a bunch of things you can do, and you can read more from the linked documentation. It is not simply one firewall; at each interaction we are building security, plus IAM, plus encryptions, SSL, VPNs — everything has to come in place to have the security of the data when you are hosting your application on the cloud.

The security stack — each tool answers one question:

Tool	Question it answers
Data in motion (encryption, VPN, SSL certificates)	Is the data safe while travelling — between users and the web server, between servers, between on-premises and the VPC?
Data at rest (file/volume encryption)	Is the data safe while stored — on volumes, in databases, in S3? Encryption protects against theft of the physical/backup media
Key management	Where do the encryption keys live, and who can use them? Lost keys make your own data unrecoverable; leaked keys decrypt everything
IAM	Who can do what? Different roles for different users — access to certain parts and certain ports only
Instance-level virtual firewalls (security groups)	What traffic may reach this specific instance, load balancer, or service?

In one line: at each interaction point you are building security — instance-specific virtual firewalls — and over the whole system you layer IAM (identity), encryptions (data in motion and at rest), SSL, and VPNs. Everything has to come in place to secure the data when hosting an application on the cloud.

The data-protection trio in plain words. Data in motion is a letter in the post — encrypt it so no one reads it in transit (VPNs, SSL). Data at rest is the letter in your drawer — encrypt it so stealing the drawer does not reveal it (volume/file encryption). Keys are the only copy of the key to the drawer — secure them and never lose them: losing the key loses the data. All three are needed; protecting only transit leaves the stored data exposed, and protecting only storage leaves the traffic exposed.

Common security mistakes on the cloud:

One firewall, trusted interior — the perimeter assumption that breaks on the cloud; lock each interaction point instead.
Encryption without key management — encrypted data is useless (or lost) if the keys are leaked or lost; key management is part of the security design, not an afterthought.
Skipping IAM — using one all-powerful account for everything means any user gets every port and every service; roles should limit each user to the parts they need.
Assuming security services are free — the professor's point: many security mechanisms are offered by the providers, "but we need to pay for that"; plan the budget alongside the architecture.

Recap + bridge: cloud security is not a firewall at the edge — it is security at every layer: per-interaction-point rules, encryption for data in motion and at rest, disciplined key management, IAM roles, and instance-level virtual firewalls. With the pieces in place — elasticity, decoupling, failure design, security — the session closes with a full worked architecture that combines them: the keyword search application.

5.16 Case Study: A Keyword Search Application

5.16.1 The Application

Here is a full application architecture following the cloud best practices. It is a keyword search application, like what we do in Google search: you put in something, and there is a crawler (here a clock-style crawler) which crawls the websites, stores the crawled URLs on a global storage, and then runs a parallel search application for multiple users. The architecture uses a clustering database to manage the metadata and monitor. Amazon queuing services (SQS) manage the queues, there is one controller, and Amazon SimpleDB is also a service offered by AWS. An EC2 cluster processes the things; input and output happen through Amazon services — user info and job status info are dealt with. Basically we are searching a kind of regular expression against certain URLs that were crawled into a database — that is what the input is, coming from the Amazon database. The controller is there. Now, how do we create components out of this application? We do a loose coupling, the way we did with the earlier controllers.

The application's components and their roles:

Component	Role
Crawler (clock-style)	Periodically crawls websites; produces the URL list to search
Global storage	Stores the crawled URLs (durable, shared — the S3-style store)
SQS (Simple Queue Service)	The message queues that decouple the components
SimpleDB	AWS's lightweight structured data store, holding the crawled URL data to be searched
EC2 cluster	Runs the parallel search jobs (the map-style work)
One controller	(Original design) coordinates the whole job

The input: a regular expression (the search string) matched against the crawled URLs from the database; the output: the relevant URLs given to the end user. The point of the case study is the transformation: the single monolithic controller is broken into four decoupled controllers in section 5.16.2, exactly the loose-coupling pattern from section 5.14.

5.16.2 The Decoupled Design: Launch, Monitor, Shutdown, Billing

In the decoupled version we have created queues: there is a launch queue, a launch controller, a monitor controller, a shutdown controller, and a billing controller — previously everything was done with one controller.

The launch controller simply launches your map and reduce jobs. We have a bunch of URLs that the crawler has produced; we match our string with all the URLs, and at the end we want to give the relevant URLs to the end user. Basically we do multiple map jobs in parallel, and the launch controller launches those jobs.
The monitor controller checks the status — it looks at what is happening, monitors everyone connected to it, and checks the jobs that are running (which were launched by the launch controller). The monitor takes care of what is happening.
Once processing is complete, the shutdown controller stops the jobs: a status is shared to the shutdown controller, and after it is complete it shuts down.
The billing controller deals with the billing services — how much the resources are being used.

Look at the flow: there are queues, so it is not a tightly coupled system. We have added a launch queue → launch controller → monitor queue, and so on. Each component is doing a different job, so they may be operating at a different rate. Input data is coming in and output will be generated — in the form of the URLs which we have crawled, matched against different maps of different data, matched against our search, and whatever relevant URLs matched are given to the end users. This is one high-level example of dividing an application into different components as much as possible — decoupling an application for elasticity.

Worked example — one search through the decoupled pipeline. A user submits the regular expression sales.*report against the crawled URL corpus.

The search request lands on the launch queue.
The launch controller picks it up and launches parallel map jobs across the EC2 cluster — each map task matches the pattern against its slice of the crawled URLs from SimpleDB.
Job status flows through the monitor queue to the monitor controller, which watches the running jobs (for example, tracking which map tasks finished and which are still running).
When the last job completes, the status reaches the shutdown controller, which terminates the job instances so the cluster stops accruing compute charges.
Meanwhile the billing controller tracks resource usage for the whole run — which instances ran, how long — feeding the measured-service bill.
The matching URLs are returned to the end user.

The elasticity payoff: each controller can be scaled to its own rate — more launch capacity during peak search demand, more monitor capacity when many jobs run — without touching the others, because every hand-off goes through a queue. And when demand drops, the shutdown controller's job is to release resources, not keep them warm.

Sense-check: the original "one controller" did all four jobs, so it had to be sized for the worst of all four rates at once; the decoupled version sizes each controller for its own rate. That is the section 5.14 pattern — independent scaling and impedance matching — applied to a concrete, named architecture.

Recap + bridge: the keyword search application is the session's capstone: crawler → global storage → parallel search over the EC2 cluster, with the single controller split into launch, monitor, shutdown, and billing controllers connected by SQS queues — an application decoupled for elasticity, using AWS's actual components. The session closes next with the distilled best-practices list and a look ahead at what remains in the course.

5.17 Best Practices and Wrap-Up

5.17.1 The Best Practices List

The best practices one should follow:

Horizontal scale out — add more instances rather than only making machines bigger. (This is the scale-out/auto-scaling family from section 5.12 applied as a default: prefer more small units to one giant machine, because they can be added, released, and failed over individually.)
Layered security, especially for data. (The security-at-every-layer doctrine from section 5.15 — firewalls per interaction point, encryption, IAM.)
Application componentization and message queues. (The loose-coupling pattern from sections 5.14 and 5.16 — independent, queue-connected components that scale at their own rate.)
Design for failures. (The section 5.13 toolkit — availability zones, replicas, images, monitoring, scaling groups, snapshots.)
Automate build and deployment. (The section 5.14.3 practices — builds on global storage, phased releases, new instances booting into the current build.)
Compensation — the ability to roll back or compensate when something goes wrong. (An update released in phases can be rolled back to the small user set; a failed payment flow can be compensated. "Compensation" is the operations word for the rollback/undo capability built into the workflow.)

But this totally depends on the kind of team we have and what capabilities we have to manage. If we do not have the capability, we can ask the experts — the cloud service vendors — to do it for us.

Why six practices, and why they chain together. Each practice answers one failure mode of the others: scale out so no machine is irreplaceable; layered security so one breach does not own the system; componentization so one stage does not bottleneck the rest; design for failures so the system survives; automation so the surviving system keeps rebuilding itself; compensation so a bad change can be undone. If the team cannot run these, the honest fallback is managed services from the vendors — the capability question from section 5.2 (who operates it) comes back here as the final decision.

5.17.2 What Is Next

The storage part is left, and it will be covered in the next session. From the big data standpoint we have talked about EMR and S3, but there is something more that you have to do with the data. Once you learn something on AWS, the remaining big data pieces are easier: largely what is left after this is the Spark part, which will take two to three sessions probably, and one small thing, DynamoDB, which we may cover. We are learning this because many big data solutions are hosted on the cloud — although we are not talking in depth about AWS and other cloud platforms, which other courses in the cloud domain may cover.

Recap of this session's takeaway: components are being created, the rate at which they operate may be different, so we try to scale them independently — that is one possibility when we are creating components of an application, and it helps in auto scaling. Simply putting up an application on the cloud and expecting everything to work automatically may not work; we need to rethink the architecture of the application.

Bridge: the next session covers the storage part of the cloud story — the piece this session deliberately left aside — followed later by Spark (two to three sessions) and DynamoDB.

Exam Guidance Summary

No exam-specific guidance (marks, question patterns, or paper details) was given in this session. The following course-scope notes are the study-relevant items that were stated:

Pricing calculations are not part of this course. What matters is the discipline of understanding resource usage and application architecture before choosing a specification, and the fact that costs may not scale linearly.
Storage is covered in the next session — the storage part of the cloud discussion is pending.
Spark is up next, taking roughly two to three sessions, followed by a small DynamoDB topic.
This course does not go deep into AWS or other cloud platforms; a dedicated cloud computing course (mentioned as covered last semester) is where EC2 instance setup and Elastic Beanstalk were seen.
Expect the "three-four-five rule" framing — three service models, four deployment models, five characteristics — as a recurring organizing structure; the Hadoop 1.x versus 2.x coupling story and the Nasdaq/Netflix S3-plus-EMR pattern are the concrete examples to remember.

Key Industry Applications

Real-world: Nasdaq runs a large-scale data processing workload on AWS using S3 buckets for storage and Elastic MapReduce for compute instead of HDFS, buying cost efficiency and independent scaling of storage and compute.
Real-world: Netflix uses the EMR file system layer so compute nodes read data directly from S3, avoiding data movement.
Real-world: AWS components commonly used in big data pipelines — EC2 (compute), EMR (managed Hadoop/MapReduce), S3 (object storage), DynamoDB (NoSQL database), Redshift (data warehouse), and high performance computing offerings.
Real-world: Google Cloud Platform offers Compute Engine, BigQuery, and a Prediction API; Microsoft Azure offers the Azure platform, SQL Azure, and HDInsight.
Real-world: Rackspace hosting is a classic infrastructure-as-a-service provider; MongoDB hosted on the cloud is the classic platform-as-a-service example; Salesforce CRM is the classic software-as-a-service example, popular and successful in industry.
Real-world: AWS Lambda is the flagship Function-as-a-Service platform, with pricing based on requests, duration, and memory; SNS provides notifications for input and output of stateless functions.
Real-world: AWS networking services used in production — VPC with subnets and NAT, Route 53 for DNS, Direct Connect for on-premise to cloud links, and VPN for hybrid connectivity.
Real-world: Design-for-failure toolkit in production AWS environments — elastic static IPs, multiple availability zones, AMI machine images, CloudWatch monitoring, auto scaling groups, and S3 snapshots for backup.
Real-world: The keyword search architecture (crawler → global storage → parallel search) built with SQS queues, SimpleDB, and an EC2 cluster is the classic reference design for decoupling an application into independently scalable controllers.

BDS Lecture 5 notes

Big Data Systems· postgraduate· 2026-08-03

Sections Breakdown

15.1 Why Cloud Computing Matters

Why organizations rent shared cloud resources instead of buying hardware: pay-per-usage economics, the formal definition built on a shared pool and rapid provisioning, the cloud service providers, and the planning a cloud migration demands.

25.2 The 3-4-5 Rule of Cloud Computing

The memory framework for any cloud platform: five characteristics, four deployment models, and three service models, from raw infrastructure (IaaS) to finished software (SaaS).

35.3 Cloud Providers and Their Big Data Components

The parallel catalogs of big data services from AWS, Google Cloud Platform, and Microsoft Azure: compute, managed Hadoop, data warehouses, NoSQL, and object storage, and why AWS leads.

45.4 Case Study: Nasdaq on AWS (S3 + EMR Instead of HDFS)

How Nasdaq replaced permanent HDFS clusters with S3 buckets plus short-lived EMR clusters, what Hadoop 2.x storage/compute decoupling makes possible, the cost trade-offs, and the Netflix parallel.

55.5 Pros and Cons of Cloud Computing

When the cloud is cost effective and when it is not: the upsides of renting infrastructure versus vendor lock-in, dependence on external providers, limited control, and security concerns.

65.6 Anatomy of an Infrastructure as a Service Cloud

The internal parts of an infrastructure-as-a-service cloud: networking, compute, block and object storage, telemetry, declarative orchestration with Heat stacks, and the dashboard users interact with.

75.7 AWS Regions and Availability Zones

How data centers are organized into regions and availability zones, and how spreading instances across isolated facilities buys redundancy and fault tolerance.

85.8 Compute, Storage, and Networking Building Blocks

The core cloud primitives: compute instances with elastic static IPs, attached volumes versus S3, security groups, load balancing, scaling, snapshots, and operating it all through the AWS console.

95.9 Choosing the Right Compute Specifications

How resource usage, pricing, and application architecture decide a machine specification, plus the full compute checklist from security profiles to IAM access control.

105.10 Serverless Computing and Function as a Service

Serverless computing and its FaaS subset: stateless, trigger-driven functions, pricing by requests, duration, and memory, and why unconfigured limits mean unbounded bills.

115.11 Networking on the Cloud: VPC and Related Services

The virtual private cloud and its neighbors: subnets, NAT, VPN, routing, Route 53 DNS, and Direct Connect for dedicated on-premises links.

125.12 Elasticity: Scaling Up, Scaling Out, Auto Scaling

Why automated elasticity is the point of the cloud: the cost of over- and under-provisioning, the limits of scale-up and scale-out, auto scaling to actual demand, and the birth of the cloud business.

135.13 Design for Failure

The design-for-failure toolkit: multiple availability zones, cross-zone replicas, AMI images, CloudWatch monitoring, auto scaling groups, snapshots, and elastic IPs that hide replacements.

145.14 Designing Elastic Applications

How loose coupling with queues lets components scale independently: the controller A and B example, stateless components, and automating infrastructure with auto scaling groups.

155.15 Security at Every Layer

Why perimeter security fails on the cloud: locking every interaction point between web, application, and database servers, plus encryption in motion and at rest, key management, and IAM.

165.16 Case Study: A Keyword Search Application

A crawler-to-storage-to-MapReduce search pipeline whose single controller is decoupled into launch, monitor, shutdown, and billing controllers joined by SQS queues.

175.17 Best Practices and Wrap-Up

The six cloud best practices: scale out horizontally, layered security, componentization with queues, design for failure, automation, and compensation, plus what the course covers next.

18Exam Guidance Summary

The professor's exam pointers for this lecture: what is in scope, what is out of scope, and the concrete cases to remember.

19Key Industry Applications

Where these ideas show up in industry: Nasdaq and Netflix on S3 plus EMR, the major providers' big data stacks, serverless patterns, and the keyword search reference design.

Postgraduate students in Big Data Systems

Exam Revision Notes

Below is the distilled, exam-ready core. Every entry comes from the full explanation above. Use this section for rapid review; return to the main notes when a point needs more context.

Why Cloud Computing Matters

Must-know: Cloud computing is an on-demand network service to a shared pool of configurable computing resources; the two load-bearing ideas are shared (pool) and rapid provisioning/release.

⚠️ Top pitfall: Moving an application to the cloud without proper planning does not reduce cost - it can raise operational cost.

Self-check: What are the two ideas that carry the weight of the formal definition of cloud computing?

Connects to: 5.2

The 3-4-5 Rule of Cloud Computing

Must-know: Any cloud platform has 3 service models (IaaS, PaaS, SaaS), 4 deployment models (public, private, hybrid, community), and 5 characteristics (on-demand self-service, broad network access, resource pooling, rapid elasticity, measured service).

⚠️ Top pitfall: Hybrid cloud is hardest to manage: communication and data movement between private and public sides; private cloud is not automatically safer.

Self-check: Under which service model does a customer rent EC2 compute instances? Which model is Salesforce CRM an example of?

Connects to: 5.1, 5.3

Cloud Providers and Their Big Data Components

Must-know: AWS: EC2, EMR, DynamoDB, S3, Redshift, HPC. GCP: Compute Engine, BigQuery, Prediction API. Azure: Azure platform, SQL Azure, HDInsight. The catalogs map one-to-one by category.

⚠️ Top pitfall: Confusing which vendor offers which service (e.g., BigQuery is GCP, Redshift is AWS, HDInsight is Azure).

Self-check: Which AWS service is the managed Hadoop offering? Which is the NoSQL database?

Connects to: 5.2, 5.4

Case Study: Nasdaq on AWS (S3 + EMR Instead of HDFS)

Must-know: Nasdaq uses S3 buckets (storage) + EMR (compute) instead of HDFS: Hadoop 2.x decouples storage from compute, enabling non-HDFS storage and independent scaling; the trade-off is losing locality of reference.

⚠️ Top pitfall: Thinking EMR+S3 keeps Hadoop's data locality: decoupled storage means compute reads data over the network from S3; locality is lost and the decision is a pricing/architecture trade-off.

Self-check: What two benefits does Hadoop 2.x decoupling of storage and compute bring, and what feature is lost?

Connects to: 5.3, 5.5, 5.12

Pros and Cons of Cloud Computing

Must-know: Cloud pros: cost effective for short-term projects, no in-house capability, reliability, managed backup/recovery, short-period scaling. Cons: costly if not planned, vendor lock-in, dependence on external providers, no fine-grained control, security.

⚠️ Top pitfall: Over-procurement: assuming a resource estimate is right without tracking usage; you end up paying for idle capacity.

Self-check: Why is the cloud 'cost effective in specific cases' rather than always?

Connects to: 5.1, 5.4

Anatomy of an Infrastructure as a Service Cloud

Must-know: IaaS building blocks: networking, compute, block storage, image storage, object storage, telemetry; orchestration executes Heat stacks (declarative definitions); users interact via a dashboard (AWS console).

⚠️ Top pitfall: Confusing block storage (virtual disk attached to an instance) with object storage (key-addressed repository for unstructured data).

Self-check: What does the orchestration service do with a Heat stack?

Connects to: 5.2, 5.7

AWS Regions and Availability Zones

Must-know: Region = geographic area with data centers; availability zones = isolated facilities inside a region with redundant power, linked by low-latency networks; redundancy across zones gives fault tolerance.

⚠️ Top pitfall: Deploying everything in one availability zone: the zone's failure becomes your failure.

Self-check: Why are availability zones within a region connected with a low-latency network?

Connects to: 5.13, 5.8

Compute, Storage, and Networking Building Blocks

Must-know: Elastic static IP: a public IP you can reattach to another instance so the end user never notices a machine change. Attached volume = block storage for local file system; S3 = external storage for unstructured data.

⚠️ Top pitfall: Leaving heavy processing running unattended on a cloud account: charges apply and can be significant; check pricing before running.

Self-check: How does an elastic static IP keep the end user unaware that a machine died?

Connects to: 5.7, 5.9, 5.12

Choosing the Right Compute Specifications

Must-know: Pick specifications from resource usage + pricing + application architecture; costs may not scale linearly with cores/RAM. Pricing calculation itself is outside course scope.

⚠️ Top pitfall: Assuming compute cost scales linearly (e.g., four cores = 2x two cores); prices vary by instance family, generation, and discount type.

Self-check: What three inputs determine the right machine specification for an application?

Connects to: 5.8, 5.10, 5.15

Serverless Computing and Function as a Service

Must-know: FaaS is a subset of serverless computing; functions run per trigger, are stateless, and are priced on requests, duration, and max memory; configure limits to avoid unbounded bills.

⚠️ Top pitfall: Leaving memory/timeout limits unconfigured: an unconfigured function is an unbounded bill at month end.

Self-check: Why is a FaaS function required to be stateless?

Connects to: 5.2, 5.14, 5.16

Networking on the Cloud: VPC and Related Services

Must-know: VPC = logically isolated private network on AWS; subnets (public/private), NAT (one public IP hides many machines), VPN (hybrid bridge), Route 53 (DNS), Direct Connect (dedicated physical link).

⚠️ Top pitfall: Confusing VPN (encrypted tunnel over the internet) with Direct Connect (dedicated physical link); or treating a private subnet as inherently unreachable rather than a routing configuration.

Self-check: How does NAT let private machines stay hidden while reaching the outside world?

Connects to: 5.2, 5.7, 5.15

Elasticity: Scaling Up, Scaling Out, Auto Scaling

Must-know: Chart: infrastructure cost vs automated elasticity+scalability. Over-provisioning pays for idle capacity; under-provisioning loses customers. Auto scaling allocates and releases resources to match actual demand.

⚠️ Top pitfall: Over-provisioning (idle resources billed) and under-provisioning (customers lost at peaks); scale-up/scale-out leave shaded shortfall regions where demand exceeds provisioned capacity.

Self-check: Why does auto scaling require rethinking the application rather than just the infrastructure?

Connects to: 5.4, 5.14, 5.3

Design for Failure

Must-know: Design-for-failure toolkit: multiple availability zones, replicas across zones, AMI images, CloudWatch monitoring, auto scaling groups, snapshots to S3; elastic IPs hide replacements from users.

⚠️ Top pitfall: Relying on a single tool (e.g., only snapshots) instead of the full chain: notice (monitor), replace (group), rebuild (AMI), restore (snapshot), hide (elastic IP).

Self-check: Which tool notices that an instance has failed, and which replaces it?

Connects to: 5.7, 5.8, 5.14

Designing Elastic Applications

Must-know: Loose coupling via queues lets each controller scale independently (impedance matching: 3 instances for light A, 15 for heavy B); components should be stateless; automate with auto scaling groups per workload class.

⚠️ Top pitfall: Tight coupling makes the slowest stage the system-wide bottleneck; silent re-coupling (shared tables without buffering, in-memory session state) breaks elasticity.

Self-check: Why does a queue let controller A scale differently from controller B?

Connects to: 5.10, 5.12, 5.16, 5.17

Security at Every Layer

Must-know: Perimeter security fails on the cloud: lock every interaction point (web server accepts only internet traffic, app server only web server, DB only app server); add data-in-motion (VPN/SSL), data-at-rest encryption, key management, IAM.

⚠️ Top pitfall: Trusting the interior behind one firewall: intruders can reach inner servers directly, and a compromised inner component spreads.

Self-check: Why can an attacker reach the application server even when the web server is the only externally exposed component?

Connects to: 5.8, 5.9, 5.11

Case Study: A Keyword Search Application

Must-know: Keyword search app: crawler -> global storage -> parallel map jobs on EC2; controllers (launch, monitor, shutdown, billing) connected by SQS queues so each scales independently.

⚠️ Top pitfall: Keeping a single controller sized for the worst of all rates; decoupling via queues lets each controller scale to its own rate.

Self-check: What does the shutdown controller do once processing is complete?

Connects to: 5.14, 5.10

Best Practices and Wrap-Up

Must-know: Six best practices: horizontal scale out, layered security, componentization + queues, design for failures, automate build/deployment, compensation. Takeaway: scale components independently; rethink application architecture.

⚠️ Top pitfall: Expecting everything to work automatically after moving to the cloud without rethinking the application architecture.

Self-check: Which best practice answers the question of undoing a bad release?

Connects to: 5.12, 5.13, 5.14, 5.15, 5.16

Exam Guidance Summary

Must-know: Pricing is out of scope; the three-four-five rule and the Hadoop 1.x/2.x coupling + Nasdaq/Netflix S3+EMR pattern are the concrete examples to remember.

Connects to: 5.2, 5.4

Previous LectureLecture 04 · NoSQL Databases

Next LectureLecture 06 · Storage on the Cloud: S3, EFS, EBS, and the Dynamo Legacy

Was this lecture useful?

Loading comments…