CLOUD COMPUTING

Question 1: Scenario Analysis (Online University Portal)

Part a: Automated Scaling Listener & Horizontal vs. Vertical Scaling
During course registration week, thousands of students attempt to log in simultaneously. The
Automated Scaling Listener detects the surge (e.g., CPU usage crossing 75%) and immediately
initiates the scaling process to prevent slowdowns or crashes.
 Horizontal Scaling (Scaling Out): This involves adding more instances (virtual
machines or containers) to distribute the load across multiple servers. For example, if the
portal runs on 3 servers and traffic spikes, the listener adds 5 more servers bringing the
total to 8. This approach is preferred in cloud environments because it is virtually
limitless, cost-effective, and supports fault tolerance.
 Vertical Scaling (Scaling Up): This involves increasing the power of an existing server,
adding more CPU cores, RAM, or storage to a single machine. For example, upgrading a
server from 8 GB RAM to 32 GB RAM. While simpler to implement, vertical scaling has
a physical ceiling and requires downtime in many cases.
For the university portal, the Scaling Listener would apply horizontal scaling; spinning up new
instances behind a load balancer to absorb the registration week surge, then automatically
terminating them once traffic normalizes (scale-in), keeping costs efficient.

Part b: Load Balancer Role & Health Checks

Once the Scaling Listener adds new instances, the Load Balancer acts as the intelligent traffic
controller sitting between users and the server pool.
Role of the Load Balancer:
 It receives all incoming student login requests and distributes them evenly across all
available server instances using algorithms such as Round Robin, Least Connections, or
IP Hashing.
 It ensures no single server becomes a bottleneck while others sit idle.
 It provides a single access point (one URL/IP) to users, abstracting away the complexity
of multiple backend servers.
 It improves response times, reduces latency, and maintains a seamless experience even
during heavy registration traffic.
Health Checks & Availability: Health checks are periodic probes sent by the load balancer to
each server instance (e.g., every 10–30 seconds) to verify it is alive and responding correctly. A
typical health check sends an HTTP request to a dedicated endpoint (like /health) and expects a
200 OK response.
If one server crashes during registration week:
1. The health check detects no response (timeout or error code).
2. The load balancer immediately marks that instance as unhealthy.
3. All new incoming requests are rerouted to the remaining healthy instances.
4. The failed instance is removed from the active pool students experience no disruption.
5. The Scaling Listener may simultaneously provision a replacement instance to restore
capacity.
This mechanism ensures high availability and prevents a single point of failure from bringing
down the entire portal.
Question 2: State Management
State refers to any data that represents the current condition or context of a user's interaction
with an application at a given point in time.
Why Store State in a Dedicated State Management Database?
In a cloud environment, applications run across multiple instances that can be created or
destroyed at any time. If state is stored inside the running application instance (in-memory), the
following problems arise:
1. Instance Termination Loss: If an instance is scaled down or crashes, all in-memory
state is permanently lost, the user's session disappears and they are logged out mid-
registration.
2. Inconsistency Across Instances: If a user's next request is routed to a different server
(which is normal with load balancing), that new server has no knowledge of the user's
previous actions causing errors or forcing re-login.
3. No Fault Tolerance: There is no backup or recovery path for in-memory data.
By storing state in a dedicated State Management Database:
 All application instances share access to the same state data.
 A user's session persists even if the instance serving them is replaced.
 Scaling in or out has no impact on the user experience.
 The database itself can be replicated for high availability and durability.
 It enables stateless application instances, which are easier to scale, replace, and manage.

Question 3: Monitoring & Compliance

The cloud provider requires two distinct types of monitoring tools for the two different
objectives described:
Tool 1: SLA Compliance / Availability Monitoring Tool
Purpose: To track whether the provider is meeting its 99.9% uptime SLA.
This tool continuously monitors the operational status of all services, servers, and network
components. It measures:
 Uptime and downtime periods
 Incident detection
 Availability percentage calculation
The tool generates availability reports that are used to verify SLA adherence and trigger penalty
clauses or credits if the target is missed.
Tool 2: Resource Usage Metering / Billing Monitoring Tool
Purpose: To track consumption of resources per user for accurate monthly billing.
This tool records granular usage data at the per-user or per-account level, including:
 Bandwidth consumed
 CPU hours
 Storage I/O, API calls, memory allocation, and other billable dimensions.
It operates on a metering model (like a utility meter) collecting timestamped usage logs that are
aggregated at the end of each billing cycle to generate an itemized invoice.

Question 4: Virtualization vs. Clustering

Hypervisor
A Hypervisor (also called a Virtual Machine Monitor) is software that sits between physical
hardware and operating systems, enabling a single physical server to run multiple isolated
Virtual Machines (VMs) simultaneously. Each VM believes it has its own dedicated hardware,
but the hypervisor abstracts and allocates the physical resources (CPU, RAM, storage)
dynamically.
How it enables infrastructure flexibility:
 A single physical server can host 10, 20, or more VMs running different operating
systems (Windows, Linux, etc.) simultaneously.
 VMs can be created, cloned, migrated to different physical hosts, or deleted in minutes
without touching hardware.
 Resources can be reallocated on the fly giving a VM more RAM or CPU without
physical intervention.
 This enables multi-tenancy, multiple customers sharing the same physical infrastructure
securely and efficiently, which is the economic foundation of cloud computing.
Resource Cluster
A Resource Cluster is a group of multiple independent physical computers (nodes)
interconnected via a high-speed network that work together as a unified computing system. From
the outside, the cluster appears as a single powerful resource, but internally, workloads are
distributed across all nodes.
How it improves system reliability:
 If one node in the cluster fails, the other nodes automatically absorb its workload
resulting in no single point of failure.
 This is called failover, ensuring continuous service availability even during hardware
failures.
 Clusters also enable parallel processing.
 They provide horizontal scalability

Question 5: Startup Cloud Optimization Scenario

1. Cost Metrics Contributing Most to High Cost
After 6 months of stable operations, the startup's highest cost drivers under pay-as-you-go are:
 Compute Cost (10 VMs running 24/7): Pay-as-you-go charges per hour of VM usage.
Running 10 VMs continuously at on-demand rates is the single largest expense. On-
demand pricing carries a significant premium (often 3–4x more than reserved pricing)
because it offers flexibility.
 Storage Cost (2 TB): Object or block storage is billed per GB per month. At scale, 2 TB
incurs substantial recurring charges, especially if redundancy (replication across zones) is
enabled.
 API Request Usage: High-volume API calls are billed per million requests. With an e-
commerce platform (product searches, cart updates, payment calls), this cost compounds
rapidly and is often underestimated.
 Data Egress/Bandwidth: Data transferred out of the cloud to end users is billed per GB,
high traffic e-commerce generates significant outbound bandwidth costs.

2. Two Pricing Models to Switch To or Combine

Model 1: Reserved Instances (RI) / Committed Use Contracts: For the 10 VMs running
continuously, the startup should purchase 1-year or 3-year Reserved Instances. This involves
committing to a specific VM type for a fixed period in exchange for discounts of 40–75%
compared to on-demand pricing.
Model 2: Savings Plans (or Spot Instances for non-critical workloads): For flexible or batch
workloads, the startup can use Spot/Preemptible Instances at discounts of up to 90%. For
predictable spend across multiple services, Compute Savings Plans offer flexibility with
committed spend discounts.
Combination Strategy: Use Reserved Instances for the stable baseline (10 core VMs) and retain
a small pay-as-you-go capacity for genuine traffic spikes. This hybrid approach balances cost
savings with flexibility.

3. How Switching Models Will Reduce Cost

 Reserved Instances eliminate the on-demand premium. A VM costing $0.10/hour on-
demand may cost $0.04/hour reserved saving 60% on compute alone. For 10 VMs
running 730 hours/month, this represents thousands of dollars in monthly savings.
 Savings Plans consolidate billing across services, ensuring the startup only pays for what
it commits to.
 Spot Instances for background tasks dramatically reduce compute costs for workloads
that can tolerate interruption (e.g., image resizing, batch analytics).
 The overall cloud bill becomes predictable and budgetable which is critical for financial
planning as the company grows.

4. Two Strategies to Avoid Resource Waste

Strategy 1: Auto-Scaling with Scheduled Scaling Policies Rather than running all 10 VMs at
full capacity 24/7, implement auto-scaling that reduces the active instance count during known
low-traffic periods (e.g., 2 AM – 6 AM). If daily traffic patterns are stable and predictable,
scheduled scaling can pre-emptively scale down at night and scale up before peak hours.
Strategy 2: Right-Sizing Instances Use cloud monitoring tools (AWS Compute Optimizer,
Azure Advisor) to analyze actual CPU and memory utilization of all 10 VMs. If VMs are
consistently running at 15–20% CPU, they are over-provisioned, the startup is paying for
capacity it never uses. Downsizing to smaller instance types that match actual utilization directly
reduces per-hour costs without impacting performance.

5. CAPEX vs. OPEX Decision

Recommendation: Stay with OPEX, but optimize it.
Justification:
 As a startup, preserving capital is critical. CAPEX (purchasing physical servers) would
require large upfront investment ($50,000–$200,000+) that ties up funds needed for
product development, marketing, and growth.
 The startup's traffic, while now stable, may still evolve, a new product launch or
marketing campaign could spike demand overnight. Cloud OPEX allows them to scale
without additional capital investment.
 However, by switching to Reserved Instances (a form of partial commitment within
OPEX), they gain the cost predictability of CAPEX-style planning while retaining cloud
flexibility.
  CAPEX also brings hidden costs: hardware maintenance, data center space, IT staff
salaries, power, cooling, and hardware refresh cycles every 3–5 years. These operational
burdens are eliminated with cloud OPEX.
 The goal is not to abandon OPEX but to mature their cloud financial management
(FinOps) using reservations, right-sizing, and waste elimination to make OPEX as
economical as CAPEX would be, without the rigidity.

Question 6: University Cloud Migration Scenario

1. Main Problem Causing Overspending
The primary problem is idle resource consumption. Virtual machines allocated for student labs
are left running 24/7 even though they are only actively used during scheduled class hours. In a
cloud environment, resources are billed by the hour (or minute) regardless of whether they are
actively used or sitting completely idle. Unlike physical on-premise servers (which have already
been paid for), every idle cloud VM continues to generate charges, this is the fundamental
operational mistake causing the unexpected high billing.

2. Cost Metrics the University Should Monitor Regularly

 Compute Hours per VM: Track exactly how many hours each virtual lab VM is
running. Idle hours outside class schedules should be zero.
 Active vs. Idle Instance Ratio: Monitor what percentage of running VMs have active
user sessions versus those sitting idle. A high idle ratio is the direct cause of
overspending.
 Storage Costs: VM disk images and student data stored persistently are billed
continuously, monitor GB-hours of storage consumption.
 Total Monthly Spend vs. Budget: Set budget alerts (e.g., 80% threshold notifications) to
catch unexpected spikes before the billing cycle ends.
 Cost Per Department/Course: Tag resources by course or department to identify which
programs are the highest consumers.

3. Suitable Pricing Model

 For Regular Classes (Predictable, recurring schedule): Reserved Instances: Since
regular classes follow a fixed weekly timetable (e.g., Monday–Friday, 8 AM–6 PM), the
university can commit to reserved capacity for those peak hours. This provides
significant discounts over on-demand pricing for consistently scheduled usage.
 For Occasional Workshops (Infrequent, unpredictable): Pay-As-You-Go (On-
Demand) Workshops happen irregularly and their exact timing may not be known
months in advance. Ondemand pricing is ideal here because the university only pays for
the exact hours the workshop VMs are active, with no long-term commitment required.
The premium on-demand rate is acceptable given the infrequent and short-duration nature
of workshops.

4. Three Cost Optimization Techniques

Technique 1: Automated Scaling Listener
An automated scaling listener continuously monitors system demand and adjusts resources
accordingly. It can automatically reduce or shut down virtual machines during low demand
periods and scale up resources during class hours when usage increases.
This helps in eliminating idle resources and significantly reduces unnecessary costs.
Technique 2: Monitoring Tools (Pay-Per-Use Monitor)
Monitoring tools, especially the pay-per-use monitor, track resource consumption such as CPU
usage, memory, and runtime. They help in identifying idle virtual machines and unnecessary
resource usage. This enables better budget control and allows administrators to take corrective
actions to optimize costs.
Technique 3: Scheduling / Auto Shutdown
Scheduling mechanisms can be configured to automatically start virtual machines at the
beginning of classes and shut them down after class hours. This ensures that no virtual machine
remains active when not required, thereby preventing wasteful spending.

5. How Cloud Helps Compared to CAPEX Despite Higher Bills

Despite the current billing issues, cloud (OPEX) remains fundamentally advantageous over the
previous on-premise CAPEX model for the university:
 Elimination of Capital Expenditure: The University previously had to purchase
physical servers, networking equipment, storage arrays, and UPS systems investing
hundreds of thousands of dollars every 3–5 years during hardware refresh cycles. These
upfront costs no longer exist.
 Scalability for Exam Periods & Enrollment Growth: On-premise labs had a fixed
capacity. If 500 students needed simultaneous access during finals week, the university
needed hardware for 500 even if average daily use was only 100 students. Cloud allows
the university to provision 500 VMs during finals and reduce to 100 the rest of the year,
paying only for actual usage.
 No Maintenance Burden: Physical servers require dedicated IT staff for hardware
maintenance, OS patching, cooling management, and failure replacements. Cloud shifts
this responsibility entirely to the provider reducing IT operational costs and staffing
requirements.
 Geographic & Remote Access: Cloud virtual labs can be accessed by students from
home, eliminating the physical lab dependency that was a major limitation during
disruptions (e.g., pandemic closures).
 The current high billing is not a cloud problem it is a resource management
problem. By implementing the optimization techniques described above (automated
scheduling, snapshotting, budget controls), the university can reduce its cloud bill by 50–
65% while retaining all the flexibility and scalability advantages that make cloud superior
to the rigid CAPEX model they previously operated under.