Cloud Computing & Security BIS613D Module 1: Dr.

Aravinda Thejas Chandra, Professor, Dept of ISE, SJCIT

MODULE – 1

DISTRIBUTED SYSTEM MODELS AND ENABLING

TECHNOLOGIES

Section Topic

1.1 Scalable Computing Over the Internet

1.2 Technologies for Network-Based Systems

1.3 System Models for Distributed and Cloud Computing

1.4 Software Environments for Distributed Systems and Clouds

1.5 Performance, Security, and Energy Efficiency

Page 1
Cloud Computing & Security BIS613D Module 1: Dr. Aravinda Thejas Chandra, Professor, Dept of ISE, SJCIT

1.1 Scalable Computing Over the Internet

Introduction
The evolution of computing has moved from standalone mainframes to massively distributed systems
interconnected over the Internet. Cloud computing represents the culmination of this evolution —
delivering computing resources (CPU, memory, storage, networking) as on-demand services. Scalability is
the cornerstone property that allows cloud systems to handle workloads ranging from a handful of users to
billions of simultaneous requests.

1.1.1 Platform Evolution of Computing Technologies

Computing platforms have undergone four major generations. Understanding each generation helps to
appreciate why cloud computing emerged as the dominant paradigm.

Era Technology Key Feature Limitation

Batch processing,
1950–1970 Mainframes Expensive, single user
centralised

1970–1990 Mini/PCs Time-sharing, multi-user Limited scalability

1990–2000 Client-Server Network-based, distributed Static provisioning

2000–2010 Clusters & Grids Parallel computing, HPC Complex management

Cloud Elastic, on-demand,

2010–now Vendor lock-in
Computing pay-per-use

Table 1.1 – Evolution of Computing Platforms

1.1.2 Cloud Architecture Diagram

The following figure illustrates the layered architecture of a cloud computing ecosystem from end-users
through service layers to the underlying data center infrastructure.

Page 2
Cloud Computing & Security BIS613D Module 1: Dr. Aravinda Thejas Chandra, Professor, Dept of ISE, SJCIT

SaaS
Layer

End Internet Data

Users (Network) PaaS Center
Layer

IaaS
Layer

Figure 1.1 – Layered Cloud Computing Architecture (End User → Internet → SaaS/PaaS/IaaS → Data Center)

1.1.3 Eight Reasons for Cloud Adoption

Hwang and Fox identified eight fundamental technical and business drivers for migrating to cloud
computing:
1. Unlimited Computing Resources On Demand
Cloud providers pool vast hardware resources and present them as seemingly infinite capacity. Users can
provision thousands of servers in minutes without capital expenditure.

2. Elimination of Up-Front Commitment

Traditional IT required large upfront investment in hardware and software licenses. Cloud uses an
operational expense (OPEX) model — pay only for what you use.

3. Short-Term Use of Resources as Needed

Resources can be rented for hours, days, or months, ideal for seasonal spikes, batch jobs, or prototype
development.

4. Economy of Scale — Lower Cost

Large-scale data centres achieve economies of scale in power, cooling, hardware procurement, and
administration, passing cost savings to users.

5. Simplified IT Management
Cloud platforms handle system administration, patching, backups, and disaster recovery, freeing
developers to focus on application logic.

6. High Availability and Fault Tolerance

Geographic redundancy, load balancing, and automated failover ensure 99.99% SLA uptime.

7. Global Reach and Low Latency

Page 3
Cloud Computing & Security BIS613D Module 1: Dr. Aravinda Thejas Chandra, Professor, Dept of ISE, SJCIT

Providers maintain edge data centres worldwide, reducing network latency through content delivery
networks (CDN) and anycast routing.

8. Green Computing and Energy Efficiency

Consolidated data centres with advanced cooling and renewable energy achieve higher energy efficiency
than thousands of individual enterprise data centres.

1.1.4 Scalability Concepts

Scalability refers to a system's ability to handle growing work by adding resources. Two primary forms of
scalability are:
• Vertical Scalability (Scale-Up): Adding more power (CPU, RAM) to existing nodes. Bounded by
hardware limits; single point of failure remains.
• Horizontal Scalability (Scale-Out): Adding more nodes to the system. Preferred in cloud computing
— theoretically unlimited; improves both capacity and fault tolerance.

Amdahl's Law – Theoretical Speedup Limit

Amdahl's Law quantifies the theoretical maximum speedup achievable when parallelising a task. Let p be
the fraction of the program that can be parallelised, and n be the number of processors.

Speedup(n) = 1 / [ (1 – p) + p/n ]

Equation 1.1 – Amdahl's Law

As n → , the maximum speedup approaches 1/(1–p). If 95% of a program is parallelisable (p = 0.95), the
maximum speedup is 20×, regardless of the number of processors.

Gustafson's Law (Scaled Speedup)

Gustafson's Law provides an alternative view: as n increases, users tend to solve larger problems in the
same time, so the parallel fraction effectively grows.

Scaled Speedup = n – (1–p) × (n–1) = n + (1–n) × (1–p)

Equation 1.2 – Gustafson's Law

Figure 1.2 – Ideal vs. Actual Speedup with Increasing Nodes (Amdahl's Law)

Ideal (Linear)

Actual

Throughput

2 N4umber of Nodes 8 16 32

Page 4
Cloud Computing & Security BIS613D Module 1: Dr. Aravinda Thejas Chandra, Professor, Dept of ISE, SJCIT

Scalability Metrics
Table 1.2 – Key Scalability and Performance Metrics

Metric Definition Formula

Throughput Work done per unit time T = Jobs / Time

Response Time Time from request to response RT = Completion – Submit

S = 1 / (α + (1 − α) / n)
Speedup Ratio of serial to parallel execution time

Efficiency Speedup per processor E=S/n

Scalability Efficiency maintained as n grows Scale  E(n) constant

Note: High-Throughput Computing (HTC) — not High-Performance Computing (HPC) — is the key
requirement for cloud systems. HTC optimises for maximum jobs/day rather than peak FLOP/s.

Page 5
Cloud Computing & Security BIS613D Module 1: Dr. Aravinda Thejas Chandra, Professor, Dept of ISE, SJCIT

1.2 Technologies for Network-Based Systems

Introduction
Network-based systems form the backbone of cloud computing. Several key enabling technologies —
cluster computing, grid computing, peer-to-peer (P2P) systems, and service-oriented architectures (SOA)
— collectively shaped the infrastructure on which modern clouds are built.

1.2.1 OSI and TCP/IP Network Models

The Open Systems Interconnection (OSI) model defines seven layers of network communication,
providing a conceptual framework for understanding how data travels from application to physical medium.

Layer 1: Physical Layer

Layer 2: Data Link Layer

Layer 3: Network Layer

Layer 4: Transport Layer

Layer 5: Session Layer

Layer 6: Presentation Layer

Layer 7: Application Layer

Figure 1.3 – OSI Seven-Layer Network Model

OSI vs. TCP/IP Comparison

OSI Layer TCP/IP Layer Key Protocols Function

7 – Application Application HTTP, FTP, SMTP, DNS User-facing services

Data formatting,
6 – Presentation Application SSL/TLS, MIME
encryption

5 – Session Application RPC, NetBIOS Session management

4 – Transport Transport TCP, UDP End-to-end delivery

3 – Network Internet IP, ICMP, ARP Routing and addressing

2 – Data Link Network Access Ethernet, Wi-Fi Frame transmission

1 – Physical Network Access Cables, NIC, Hubs Bit transmission

Page 6
Cloud Computing & Security BIS613D Module 1: Dr. Aravinda Thejas Chandra, Professor, Dept of ISE, SJCIT

Table 1.3 – OSI vs. TCP/IP Model with Protocols

1.2.2 Cluster Computing

A cluster is a collection of interconnected standalone computers (nodes) that work together as a single
integrated computing resource. Clusters provide high availability and high performance at relatively low
cost using commodity hardware.
Characteristics of Clusters:
• Homogeneous hardware and OS (typically Linux)
• High-speed interconnect (InfiniBand, 10/100 GbE)
• Single system image presented to users
• Shared storage via NFS, Lustre, or GPFS
• Workload management via schedulers: PBS, SLURM, SGE

Beowulf Clusters
The Beowulf cluster (1994, NASA) demonstrated that commodity PCs running Linux and interconnected
with Fast Ethernet could achieve supercomputer-class performance at a fraction of the cost. This
democratised HPC and directly inspired modern cloud infrastructure.

1.2.3 Grid Computing

Grid computing extends the cluster concept to heterogeneous, geographically distributed resources
administered by different organisations. The grid appears as a single virtual supercomputer.

Property Cluster Grid Cloud

Location Single site Multi-site Multi-site/region

Ownership Single org Multiple orgs Provider-owned

Homogeneity Homogeneous Heterogeneous Virtualised

Access Direct login Certificate/GSI API/Console/CLI

Billing None/Fixed Allocation-based Pay-per-use

Standard MPI, OpenMP OGSA, WSRF, GT4 REST, SOAP APIs

Table 1.4 – Comparison: Cluster, Grid, and Cloud Computing

1.2.4 Peer-to-Peer (P2P) Systems

P2P systems are fully decentralised networks where each node (peer) acts as both client and server. P2P
concepts influenced cloud storage systems (DHT-based key-value stores) and content delivery networks.
• Unstructured P2P: Gnutella, Napster — simple flooding-based discovery
• Structured P2P: Chord, Kademlia, Pastry — use Distributed Hash Tables (DHT)
• Hybrid P2P: BitTorrent — tracker-assisted peer discovery

Page 7
Cloud Computing & Security BIS613D Module 1: Dr. Aravinda Thejas Chandra, Professor, Dept of ISE, SJCIT

Distributed Hash Table (DHT) Routing

m
key → node_id using: node_id = SHA-1(key) mod 2

Equation 1.3 – DHT Key-to-Node Mapping (m = key-space bits)

Each node maintains a finger table of O(log N) entries, enabling O(log N) lookup hops in an N-node ring.
This O(log N) routing is the foundation for scalable distributed storage in clouds.

1.2.5 Service-Oriented Architecture (SOA)

SOA is an architectural style that structures software as a collection of loosely coupled, interoperable
services. Web Services (SOAP/WSDL/UDDI) and RESTful APIs are the two major SOA implementations
in cloud computing.
• SOAP-based Web Services: XML messaging, WSDL contracts, UDDI registries — used in
enterprise ESB and WS-* standards.
• RESTful APIs: HTTP verbs (GET/POST/PUT/DELETE), JSON payloads, stateless — used by AWS,
GCP, Azure management APIs.

Feature SOAP REST

Protocol SOAP over HTTP/SMTP HTTP/HTTPS

Data Format XML only JSON, XML, HTML

State Stateful possible Stateless

Discovery UDDI registry API documentation

Security WS-Security OAuth 2.0, JWT, TLS

Performance Higher overhead Lightweight

Table 1.5 – SOAP vs. REST Comparison for Cloud APIs

1.2.6 Message Passing Interface (MPI)

MPI is a standardised API for communication among parallel processes distributed across multiple nodes.
It is the de-facto standard for HPC applications and is also used in tightly coupled cloud workloads.

Page 8
Cloud Computing & Security BIS613D Module 1: Dr. Aravinda Thejas Chandra, Professor, Dept of ISE, SJCIT

MPI Call Description

MPI_Init / MPI_Finalize Initialise / shutdown MPI environment

MPI_Comm_rank Get rank (ID) of calling process

MPI_Comm_size Get total number of processes

MPI_Send / MPI_Recv Point-to-point blocking communication

MPI_Isend / MPI_Irecv Non-blocking point-to-point communication

MPI_Bcast Broadcast from one to all processes

MPI_Scatter / MPI_Gather Distribute / collect data array segments

MPI_Reduce / MPI_Allreduce Aggregate results with operation (SUM, MAX …)

MPI_Barrier Synchronise all processes at a point

Table 1.6 – Key MPI Primitives and Their Functions

Note: MPI is synchronous by nature. For asynchronous, event-driven cloud workloads, message queues
(AWS SQS, RabbitMQ, Kafka) are preferred.

Page 9
Cloud Computing & Security BIS613D Module 1: Dr. Aravinda Thejas Chandra, Professor, Dept of ISE, SJCIT

1.3 System Models for Distributed and Cloud Computing

Introduction
A system model defines the abstract structure and interaction rules among components. Distributed and
cloud systems are characterised by concurrency, lack of a global clock, and the possibility of partial
failures. Several formal models guide the design of robust cloud systems.

1.3.1 Distributed System Architecture

A distributed system consists of autonomous computers connected via a network that coordinate to
appear as a single coherent system. The key challenge is achieving transparency — hiding distribution
from users and applications.

N5 N6

Node 5 Node 6

N1 C N2

Node 1 Coord Node 2

N3 N4

Node 3 Node 4

Figure 1.4 – Star Topology Distributed System with Coordinator Node

Eight Transparency Goals (ISO/IEC 10746)

Transparency Description

Access Transparency Hide differences in data representation and access methods

Location Transparency Hide where resource/process resides physically

Migration Transparency Hide movement of resources without affecting users

Replication Transparency Hide that multiple copies exist to enhance performance/availability

Concurrency
Hide that resources may be shared by concurrent users
Transparency

Failure Transparency Hide failure and recovery of components

Performance
Allow reconfiguration to improve performance dynamically
Transparency

Scaling Transparency Allow growth in scale without changing structure or algorithms

Table 1.7 – Eight Transparency Goals for Distributed Systems

Page 10
Cloud Computing & Security BIS613D Module 1: Dr. Aravinda Thejas Chandra, Professor, Dept of ISE, SJCIT

1.3.2 Cloud Service Delivery Models

The NIST definition of cloud computing (SP 800-145) identifies three service models that form a layered
stack. Each layer abstracts the one below it.

Model Full Form What User Controls Example

Only application usage Gmail, Salesforce,

SaaS Software as a Service
settings Dropbox

Google App Engine,

Applications + data; not
PaaS Platform as a Service Heroku, AWS Elastic
OS/infra
Beanstalk

Infrastructure as a OS, middleware, apps, data, AWS EC2, Azure VMs,

IaaS
Service runtime GCP Compute Engine

Table 1.8 – Cloud Service Delivery Models (SaaS, PaaS, IaaS)

1.3.3 Cloud Deployment Models

NIST identifies four deployment models based on who controls and uses the infrastructure:
Public Cloud: Owned and operated by a third-party provider; resources shared among tenants.
Examples: AWS, Azure, GCP. Highest elasticity; lowest administrative burden.

Private Cloud: Deployed exclusively for one organisation; may be on-premises or hosted. Greater control
and security; requires internal management expertise.

Hybrid Cloud: Composition of public and private clouds that remain distinct entities but are bound
together by standardised or proprietary technology. Enables cloud bursting.

Community Cloud: Shared by a group of organisations with common concerns (e.g., healthcare,
government). Costs shared; policy/compliance tailored to the community.

1.3.4 Virtualisation as a System Model Enabler

Virtualisation is the foundational technology that enables multi-tenancy, isolation, and elastic resource
provisioning in cloud computing. A Virtual Machine Monitor (VMM) or Hypervisor decouples the hardware
from the operating system.

Page 11
Cloud Computing & Security BIS613D Module 1: Dr. Aravinda Thejas Chandra, Professor, Dept of ISE, SJCIT

App A App B | App C | App D App E

Guest OS 1 | Guest OS 2 | Guest OS 3

Hypervisor / VMM (Type 1 or Type 2)

Hardware (CPU, Memory, Storage, Network)

Figure 1.5 – VM Layered Structure: Hardware → Hypervisor → Guest OS → Applications

VM Primitive Operations
Operation Description

Create Allocate resources (CPU, memory, disk, NIC) and instantiate a new VM

Destroy Deallocate all resources and permanently remove the VM

Suspend Pause VM execution; save CPU state to memory

Resume Restore VM from suspended state; continue execution

Move running VM from one physical host to another (Live Migration via dirty
Migrate
page copy)

Checkpoint Save complete VM state snapshot to disk for rollback

Clone Create an identical copy of an existing VM image

Snapshot Capture point-in-time state of VM disk (not necessarily CPU state)

Table 1.9 – VM Primitive Operations in Cloud Data Centers

1.3.5 CAP Theorem

Brewer's CAP Theorem (2000) states that a distributed data store can provide at most two of the following
three guarantees simultaneously:
• Consistency (C): Every read receives the most recent write or an error.
• Availability (A): Every request receives a (non-error) response.
• Partition Tolerance (P): System continues to operate despite arbitrary message loss.

In presence of network partition: choose C or A, not both.

Page 12
Cloud Computing & Security BIS613D Module 1: Dr. Aravinda Thejas Chandra, Professor, Dept of ISE, SJCIT

Equation 1.4 – CAP Theorem Constraint

System Type Sacrifices Examples

HBase, MongoDB (w:majority),

CP (Consistent + Partition-tolerant) Availability
Zookeeper

DynamoDB, Cassandra,
AP (Available + Partition-tolerant) Consistency
CouchDB

Traditional RDBMS (single

CA (Consistent + Available) Partition-tolerance
node)

Table 1.10 – CAP Theorem: System Categories and Examples

Important: Partition tolerance (P) is non-negotiable in any real-world distributed system because
network partitions will inevitably occur. Hence, architects choose between C and A.

Page 13
Cloud Computing & Security BIS613D Module 1: Dr. Aravinda Thejas Chandra, Professor, Dept of ISE, SJCIT

1.4 Software Environments for Distributed Systems and Clouds

Introduction
Software environments encompass the programming models, middleware, runtime systems, and
frameworks that allow developers to build applications for distributed and cloud platforms. This section
covers the major programming paradigms and platforms used in cloud computing.

1.4.1 Programming Models for Parallel Computing

Model Paradigm Communication Tool

Threads share Lock, mutex,

Shared Memory OpenMP, pthreads
address space semaphore

Processes exchange
Message Passing Send/Receive calls MPI
messages

Same op on data
Data Parallel Implicit in framework MapReduce, Spark
partitions

Different tasks
Task Parallel DAG scheduling Dask, Celery, Luigi
concurrently

Asynchronous
Actor Model Actors with mailboxes Akka, Erlang
messages

[Link], AWS
Event-Driven Callbacks on events Event queue/bus
Lambda

Table 1.11 – Parallel and Distributed Programming Models

1.4.2 MapReduce Programming Model

MapReduce, introduced by Google (2004), is a functional programming model for processing large
datasets in parallel across a cluster. It simplifies distributed computing by hiding fault tolerance, data
distribution, and parallelisation from the programmer.

MapReduce Execution Flow

• 1. Input Split: Input dataset divided into fixed-size chunks (default 128 MB in Hadoop HDFS)
• 2. Map Phase: Each split processed by a Mapper: (k1, v1) → list(k2, v2)
• 3. Shuffle & Sort: Framework groups all values by key: k2 → list(v2)
• 4. Reduce Phase: Each group processed by a Reducer: (k2, list(v2)) → list(k3, v3)
• 5. Output: Results written to distributed storage (HDFS, GCS, S3)

map: (k1, v1) → list(k2, v2) reduce: (k2, list(v2)) → list(k3, v3)

Page 14
Cloud Computing & Security BIS613D Module 1: Dr. Aravinda Thejas Chandra, Professor, Dept of ISE, SJCIT

Equation 1.5 – MapReduce Functional Signatures

Word Count Example — MapReduce

Map(key=filename, value=line_content): for each word w in value: emit(w, 1)
Reduce(key=word, values=list_of_counts): total = sum(values) emit(word, total)

1.4.3 Apache Hadoop Ecosystem

Hadoop is the open-source implementation of MapReduce, with HDFS as the underlying distributed file
system. The Hadoop ecosystem has grown into a comprehensive data platform.

Component Role

HDFS Distributed file system: NameNode (metadata) + DataNodes (blocks)

Resource manager: ApplicationMaster + NodeManager +

YARN
ResourceManager

MapReduce Batch processing framework on top of YARN

Hive SQL-on-Hadoop: HiveQL translated to MapReduce/Tez jobs

HBase Column-oriented NoSQL store on HDFS; CP system

Pig Data flow language (Pig Latin) for ETL pipelines

Spark In-memory processing: 10–100× faster than MapReduce

ZooKeeper Distributed coordination and configuration service

Oozie Workflow scheduler for Hadoop jobs

Table 1.12 – Apache Hadoop Ecosystem Components

1.4.4 HDFS Architecture

HDFS follows a master-slave architecture. The NameNode maintains the filesystem namespace and
file-to-block mappings. DataNodes store the actual data blocks and send heartbeats to the NameNode.

Client NameNode
(Metadata Master)

DataNode 1 DataNode 2 DataNode 3 DataNode 4

Figure 1.6 – HDFS Architecture: NameNode, DataNodes, and Client Interaction

Page 15
Cloud Computing & Security BIS613D Module 1: Dr. Aravinda Thejas Chandra, Professor, Dept of ISE, SJCIT

HDFS Key Parameters

Block Size (default) = 128 MB Replication Factor = 3 (2 on same rack, 1 on different rack)
Storage Overhead = Block_Size × Replication_Factor × Num_Blocks

Equation 1.6 – HDFS Storage Parameters

1.4.5 Container and Microservices Environments

Modern cloud-native applications are built using containers and microservices, orchestrated by platforms
like Kubernetes (K8s). Containers provide OS-level virtualisation — lighter than VMs as they share the
host kernel.
• Docker: Build, ship, and run containers using images and a layered union filesystem (OverlayFS).
• Kubernetes: Orchestrates containers — auto-scaling, rolling updates, service discovery,
self-healing.
• Service Mesh (Istio): Handles inter-service communication, mTLS, observability, traffic shaping.
• Serverless (FaaS): AWS Lambda, Azure Functions — execute code in response to events with zero
infrastructure management.

Feature Virtual Machine Container

Kernel Full separate kernel + OS Shared host kernel

Startup Time Minutes Seconds / milliseconds

Size GBs (full OS image) MBs (just application layer)

Isolation Strong (hardware-enforced) Moderate (namespaces, cgroups)

Performance Slight overhead (hypervisor) Near-native

Portability OVF/OVA images Docker Hub, container registries

Table 1.13 – Virtual Machines vs. Containers Comparison

Page 16
Cloud Computing & Security BIS613D Module 1: Dr. Aravinda Thejas Chandra, Professor, Dept of ISE, SJCIT

1.5 Performance, Security, and Energy Efficiency

Introduction
Performance, security, and energy efficiency form the three non-functional cornerstones of cloud system
design. They are tightly interrelated: security measures consume compute resources (affecting
performance), while aggressive performance optimisations (e.g., DVFS) improve energy efficiency but
may create timing side-channels.

1.5.1 Performance Metrics and Benchmarks

Performance in distributed cloud systems must be measured holistically across compute, storage,
network, and application tiers.

Metric Definition Unit Benchmark Tool

Requests or jobs processed req/s,

Throughput Apache JMeter, Linpack
per unit time FLOP/s

Time from request to first byte

Latency ms, µs Ping, wrk, k6
of response

Storage I/O operations per

IOPS ops/s fio, iometer
second

Bandwidth Network data transfer rate Gbps, MB/s iperf3, netperf

Fraction of capacity in active

Utilisation % top, vmstat, CloudWatch
use

Contractual/target availability
SLA / SLO %, ms PagerDuty, Datadog
& response time

Table 1.14 – Cloud Performance Metrics and Benchmark Tools

Little's Law — Queuing Theory

Little's Law relates throughput, latency, and the number of concurrent requests in a system at steady state.
It is fundamental for capacity planning:

L=×W

Equation 1.7 – Little's Law (L = avg. items in system,  = arrival rate, W = avg. time in system)

Example: If 500 requests/s arrive and each takes 200 ms to process, the system must handle L = 500 ×
0.2 = 100 concurrent requests at any instant.

Page 17
Cloud Computing & Security BIS613D Module 1: Dr. Aravinda Thejas Chandra, Professor, Dept of ISE, SJCIT

M/M/1 Queuing Model

The M/M/1 queue models a single-server system with Poisson arrivals (rate ) and exponential service
times (rate µ). The server utilisation  must be < 1 for stability.

 =  / µ (Server Utilisation) L_q = ² / (1 – ) (Avg. queue length) W_q =  / (µ – ) (Avg. waiting

time)

Equation 1.8 – M/M/1 Queue Performance Formulae

Note: When  → 1 (system near saturation), L_q → . Cloud auto-scaling keeps  < 0.7 for headroom
during traffic spikes.

1.5.2 Cloud Security

Security in cloud computing addresses the threats arising from multi-tenancy, internet exposure,
third-party data custody, and shared infrastructure. The CIA Triad is the foundational framework.

Availability

CIA■Triad

Confidentiality Integrity
Figure 1.7 – CIA Security Triad: Confidentiality, Integrity, Availability

CIA Triad — Detailed Explanation

Confidentiality: Ensures that information is accessible only to authorised entities. Mechanisms:
encryption (AES-256, RSA), access control (RBAC, ABAC), data masking.

Integrity: Ensures data is accurate, complete, and unaltered. Mechanisms: cryptographic hashes
(SHA-256, SHA-3), digital signatures, HMAC, version control.

Availability: Ensures authorised users can access services when needed. Mechanisms: redundancy, load
balancing, DDoS mitigation, disaster recovery, SLA guarantees.

Page 18
Cloud Computing & Security BIS613D Module 1: Dr. Aravinda Thejas Chandra, Professor, Dept of ISE, SJCIT

Cloud Security Attack Taxonomy

Attack Type Description Countermeasure

Flood target with traffic to exhaust CDN scrubbing, rate limiting,

DDoS
resources Anycast

Malicious SQL in input fields to Parameterised queries, WAF, input

SQL Injection
extract/corrupt data validation

Inject scripts into web pages viewed CSP headers, output encoding,
XSS
by other users WAF

Attacker breaks out of VM to access Hypervisor patching,

VM Escape
hypervisor/host microarchitecture mitigations

Infer secrets via timing, power, cache Constant-time code, cache

Side-Channel
access patterns partitioning, noise injection

Unauthorised transfer of sensitive DLP, egress filtering, CASB,

Data Exfiltration
data encryption

Malicious/negligent actions by Zero-trust, least privilege, UEBA,

Insider Threat
authorised personnel audit logs

Intercept communication between TLS/mTLS, certificate pinning,

MITM
two parties HSTS

Table 1.15 – Cloud Security Attack Types and Countermeasures

Cryptographic Foundations
Cloud security relies on the following cryptographic primitives:
• Symmetric Encryption (AES-256-GCM): Same key for encryption and decryption. Used for bulk
data encryption (at-rest, in-transit). Key distribution is the challenge.
• Asymmetric Encryption (RSA-2048/4096, ECC): Public key encrypts; private key decrypts. Used
for key exchange (TLS handshake), digital signatures.
• Hash Functions (SHA-256, SHA-3): One-way functions producing a fixed-size digest. Used for
integrity checks, password hashing (PBKDF2, bcrypt, Argon2), Merkle trees.
• HMAC: Hash-based Message Authentication Code. Combines hash with secret key for message
authentication.

HMAC(K, m) = H((K  opad) || H((K  ipad) || m))

Equation 1.9 – HMAC Construction (H = hash function, K = key, m = message)

Page 19
Cloud Computing & Security BIS613D Module 1: Dr. Aravinda Thejas Chandra, Professor, Dept of ISE, SJCIT

TLS 1.3 Handshake

Transport Layer Security (TLS) 1.3 protects all data in transit in cloud environments. The handshake is
reduced to 1-RTT (or 0-RTT for resumed sessions):
• ClientHello: Client sends supported cipher suites, key_share (ECDHE public key)
• ServerHello: Server selects cipher suite, sends its key_share, certificate, CertificateVerify
• Key Derivation: Both compute shared secret using ECDHE; derive handshake & application keys via
HKDF
• Finished: Server sends Finished (MAC over handshake); client verifies and sends its own Finished
• Application Data: Encrypted data exchange using derived symmetric keys (AES-256-GCM)

1.5.3 Energy Efficiency in Cloud Data Centers

Data centres are major consumers of global electricity — approximately 1–2% of global electricity
consumption. Improving energy efficiency is both economically and environmentally critical.

Power Usage Effectiveness (PUE)

PUE is the primary industry metric for data centre energy efficiency, defined as:

PUE = Total Facility Power / IT Equipment Power

Equation 1.10 – Power Usage Effectiveness (PUE) — lower is better; ideal = 1.0

PUE Value Rating Typical Operator

3.0+ Very inefficient Older enterprise data centres

2.0 – 3.0 Below average Average co-location facilities

1.5 – 2.0 Average Many commercial data centres

1.2 – 1.5 Good Modern hyperscale data centres

1.0 – 1.2 Excellent Google, Facebook, AWS (some sites)

Table 1.16 – PUE Ratings and Typical Operators

Energy Optimisation Techniques

Dynamic Voltage and Frequency Scaling (DVFS):
DD2
CPU voltage and frequency reduced at low utilisation. Power  C·V²·f. Equation: P = ·C·V ·f where  is
activity factor, C is capacitance, VDD is supply voltage, f is frequency.

Server Consolidation via VM Packing:

Bin-packing algorithms migrate workloads to fewer physical servers, powering off idle ones. First-Fit
Decreasing (FFD) is commonly used.

Cooling Optimisation:
Hot-aisle/cold-aisle containment, liquid cooling, free-air cooling (economisers). Google uses seawater
cooling in Finland.

Renewable Energy Integration:

Page 20
Cloud Computing & Security BIS613D Module 1: Dr. Aravinda Thejas Chandra, Professor, Dept of ISE, SJCIT

Power Purchase Agreements (PPA) for solar/wind. Google: 100% renewable energy matched.
Carbon-aware workload scheduling shifts jobs to greener regions/times.

Power-Proportional Computing:
Ideal: power  load (0% power at 0% load). Reality: idle servers consume ~50–70% of peak power. Goal:
achieve a linear power-to-utilisation relationship.

P_dynamic =  · C · V2 · f P_static = V · Ileak P_total = P_dynamic + P_static

DD
Equation 1.11 – CMOS Power Dissipation Components

Green Metrics Summary

Metric Formula Notes

PUE Total Power / IT Power Ideal = 1.0

IT Power / Total Power ×

DCiE DCiE = 100/PUE
100%

CO■ emitted / IT Power

CUE Lower = greener energy mix
(kWh)

Annual water usage / IT

WUE Litres per kWh; data centre cooling water
Energy

(Total – Reused Energy) / IT

ERE Measures energy reuse (e.g., district heating)
Energy

Table 1.17 – Green Data Centre Metrics: PUE, DCiE, CUE, WUE, ERE

Page 21
Cloud Computing & Security BIS613D Module 1: Dr. Aravinda Thejas Chandra, Professor, Dept of ISE, SJCIT

Module 1 — Comprehensive Summary

Key Takeaways
Topic Core Concepts Key Equations/Standards

Scalable Platform evolution, HTC vs HPC, Amdahl: S=1/[(1–p)+p/n]

Computing vertical vs horizontal scaling Gustafson: S=n+(1–n)(1–p)

Network OSI 7-layer, TCP/IP, P2P, SOA, MPI DHT: node=SHA-1(key) 2■

Technologies Send/Recv/Bcast/Reduce
Cluster, Grid,
mod MPI:

System Models 8 Transparency goals, CAP theorem: choose C or A

SaaS/PaaS/IaaS, deployment models, under partition
VM ops, CAP

Software MapReduce, Hadoop/HDFS, HDFS block=128MB, RF=3

Environments containers vs VMs, K8s, serverless L=×W (Little's Law)

Performance Throughput, latency, IOPS, SLA, =/µ; L_q=²/(1–)

M/M/1 queuing, benchmarks

Security CIA Triad, attack taxonomy, AES, PUE = Total Power / IT Power
RSA, SHA-256, TLS 1.3, HMAC

Energy Efficiency PUE, DCiE, DVFS, VM consolidation, P=CV²f+V·I_leak

green metrics

Table 1.18 – Module 1 Comprehensive Summary Table

Previous Year / Model Exam Questions

Q1. Explain the Platform Evolution of different computer technologies with a neat diagram. [10 M]

Q2. Outline eight reasons to adapt the cloud for upgraded Internet applications and web services. [8 M]

Q3. Briefly explain Message Passing Interface (MPI) with its key primitives. [2 M]

Q4. Summarise VM Primitive Operations with relevant diagram. [10 M]

Q5. Illustrate various system attacks and network threats to the cyberspace resulting in four types of
losses, with a neat diagram. [8 M]

Q6. Explain Amdahl's Law and its implications for cloud scalability. [6 M]

Page 22
Cloud Computing & Security BIS613D Module 1: Dr. Aravinda Thejas Chandra, Professor, Dept of ISE, SJCIT

Q7. Compare Cluster, Grid, and Cloud computing with respect to ownership, homogeneity, billing, and
standards. [8 M]

Q8. Explain the CAP Theorem and classify NoSQL databases using the theorem. [6 M]

Q9. Describe MapReduce programming model with a word-count example. [8 M]

Q10. Define PUE and describe techniques to improve energy efficiency in cloud data centres. [8 M]

Q11. Compare Virtual Machines and Containers with respect to performance, isolation, and startup time.
[6 M]

Q12. Explain the three cloud service delivery models (SaaS, PaaS, IaaS) with examples. [6 M]

Equations Reference Sheet

Eq. No. Name Formula

1.1 Amdahl's Law S(n) = 1 / [(1–p) + p/n]

1.2 Gustafson's Law S_scaled = n + (1–n)(1–p)

1.3 DHT Key Mapping node_id = SHA-1(key) mod 2^m

1.4 CAP Theorem Constraint Under partition: guarantee C or A, not both

map:(k1,v1)→list(k2,v2);
1.5 MapReduce Signatures
reduce:(k2,list(v2))→list(k3,v3)

Storage = BlockSize × ReplicationFactor ×

1.6 HDFS Parameters
NumBlocks

1.7 Little's Law L=×W

1.8 M/M/1 Queue =/µ; L_q=²/(1–); W_q=/(µ–)

1.9 HMAC HMAC(K,m)=H((Kopad)||H((Kipad)||m))

1.10 PUE PUE = Total Facility Power / IT Equipment Power

1.11 CMOS Power P_total = ·C·V²·f + V_DD·I_leak

Table 1.19 – Module 1 Equations Quick Reference

Page 23
Cloud Computing & Security BIS613D Module 1: Dr. Aravinda Thejas Chandra, Professor, Dept of ISE, SJCIT

Key Terminology Glossary

Term Definition
API Application Programming Interface — contract for service communication

Consistency, Availability, Partition tolerance — at most 2 of 3

CAP Theorem
simultaneously

Content Delivery Network — geographically distributed servers for

CDN
low-latency delivery

Dynamic Voltage and Frequency Scaling — CPU power management

DVFS
technique

DHT Distributed Hash Table — peer-to-peer key-value routing structure

FLOP Floating Point Operation — standard unit of compute performance

Hadoop Distributed File System — fault-tolerant, block-level distributed

HDFS
storage

High-Throughput Computing — optimise for jobs/day rather than peak

HTC
FLOP/s

Hypervisor Virtual Machine Monitor (VMM) — manages multiple guest VMs on a host

IaaS Infrastructure as a Service — cloud delivers VMs, storage, networking

IOPS Input/Output Operations Per Second — storage performance metric

Message Passing Interface — standard for parallel process

MPI
communication

Multi-tenancy Multiple customers sharing cloud infrastructure with isolation

PaaS Platform as a Service — cloud delivers runtime + middleware + tools

PUE Power Usage Effectiveness — data centre energy efficiency ratio

Role-Based Access Control — permissions assigned to roles, not

RBAC
individuals

SaaS Software as a Service — cloud delivers complete application to end users

Service Level Agreement — contractual uptime and performance

SLA
guarantees

Service-Oriented Architecture — software as interoperable, loosely

SOA
coupled services

TLS Transport Layer Security — cryptographic protocol for data in transit

VM Virtual Machine — software emulation of a physical computer

YARN Yet Another Resource Negotiator — Hadoop 2 resource manager

Table 1.20 – Module 1 Key Terminology Glossary

Page 24