CLOUD COMPUTING

LABORATORY MANUAL
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

10 Practical Experiments
VirtualBox • Google App Engine • Hadoop • Terraform
CloudSim • EC2 • Load Balancers • CloudFormation

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Student Name: ___________________________

Roll Number: ___________________________
Branch: ___________________________
Semester: ___________________________
Academic Year: 2025 – 2026
Index of Experiments

No. Experiment Title Date Signature

1 Install VirtualBox/VMware with Linux/Windows OS

2 Install Google App Engine – Hello World & Web Apps

3 Install Hadoop Single Node Cluster & Run WordCount

4 Implement Terraform Commands (init/validate/plan/apply/destroy)

5 Simulate Cloud Scenario using CloudSim with Custom Scheduler

6 Create and Terminate EC2 Instance through Terraform

7 Implement Application and Network Load Balancer

8 Implement Internal Load Balancer

9 Setting up AWS CloudFormation

10 Building a Pipeline for Test and Production Stacks in CloudFormation

Experiment 1
Install VirtualBox/VMware Workstation with Different Flavours of Linux or Windows
OS

Aim To install VirtualBox/VMware Workstation on a host machine running Windows

10/11 and set up different guest operating systems including various Linux
distributions and Windows.

Tools Required Oracle VirtualBox 7.x / VMware Workstation 17, Windows 10/11 host, ISO files of
Ubuntu 22.04, Kali Linux, Windows 10

Prerequisites 64-bit processor with virtualization support (Intel VT-x / AMD-V enabled in BIOS),
minimum 8 GB RAM, 50 GB free disk space

Theory
Virtualization is the process of creating a software-based (or virtual) representation of something, such
as virtual applications, servers, storage, and networks. VirtualBox is a free, open-source hypervisor for
x86 and AMD64/Intel64 machines, while VMware Workstation is a commercial Type-2 hypervisor.
A Type-2 hypervisor (hosted hypervisor) runs on top of a conventional operating system (the host OS).
The guest OS runs inside a virtual machine managed by the hypervisor. The key advantages include
isolation, snapshot support, OS portability, and hardware abstraction.

Installation Steps
Step 1: Download VirtualBox installer from [Link]
Step 2: Run the installer with Administrator privileges
Step 3: Accept defaults and complete the installation
Step 4: Launch VirtualBox Manager and click 'New' to create a VM
Step 5: Set name, type (Linux/Windows), version, memory, and disk size
Step 6: Attach the ISO file and start the VM to begin OS installation

Screenshots
 Fig: Installation Screen – VirtualBox Package Installation via Terminal

Fig: Configuration Screen – VirtualBox Manager with VM Settings

Fig: Output Screen – Ubuntu VM Running Successfully inside VirtualBox

Result
VirtualBox was successfully installed on Windows 11. Three virtual machines were created and
configured: Ubuntu 22.04 LTS (Linux), Kali Linux, and Windows 10. All VMs boot successfully and the
guest OS runs within the host environment demonstrating successful hardware virtualization.
Experiment 2
Install Google App Engine – Create Hello World and Web Applications using
Python/Java

Aim To install Google App Engine SDK, configure a cloud project, and deploy Hello World
and simple web applications using Python.

Tools Required Google Cloud SDK, Python 3.9+, pip, Google Cloud Account, gcloud CLI

Prerequisites Active Google Cloud account, billing enabled project, internet connectivity

Theory
Google App Engine (GAE) is a Platform-as-a-Service (PaaS) cloud computing platform for developing and
hosting web applications in Google-managed data centers. It supports automatic scaling, load balancing,
and deployment of applications in multiple languages including Python, Java, Go, and [Link].
The App Engine Standard Environment uses sandboxed runtimes and scales from zero to millions of
users automatically. Developers only pay for what they use, making it cost-effective for startups and
enterprises alike.

Code – Hello World ([Link])

from flask import Flask

app = Flask(__name__)

@[Link]('/')
def hello():
return 'Hello, World! - Cloud Computing Lab'

@[Link]('/info')
def info():
return 'Running on Google App Engine | Python 3.9'

if __name__ == '__main__':
[Link](host='[Link]', port=8080, debug=True)

Code – [Link]

runtime: python39
entrypoint: gunicorn -b :$PORT main:app

instance_class: F1
automatic_scaling:
max_instances: 3
min_instances: 0

Screenshots
 Fig: Installation Screen – Google Cloud SDK Installation

Fig: Configuration Screen – App Engine Deployment via gcloud CLI

Fig: Output Screen – App Engine Service Running in Google Cloud Console

Result
Google App Engine SDK was successfully installed and configured. A Hello World web application was
deployed using Python/Flask runtime. The application is publicly accessible at [Link]
[Link] and responds with HTTP 200 to all requests, demonstrating successful PaaS
deployment.
Experiment 3
Install Hadoop Single Node Cluster and Run Simple Applications like WordCount

Aim To install and configure Apache Hadoop in pseudo-distributed (single-node) mode

and execute the built-in WordCount MapReduce application.

Tools Required Apache Hadoop 3.3.6, Java JDK 11, Ubuntu 22.04, SSH client

Prerequisites Minimum 4 GB RAM, Java 8+ installed, passwordless SSH configured for localhost

Theory
Apache Hadoop is an open-source framework that enables distributed processing of large datasets
across clusters using a simple programming model. The core components are HDFS (Hadoop Distributed
File System) for storage and YARN/MapReduce for processing.
In pseudo-distributed mode, Hadoop runs on a single machine but simulates a distributed cluster. Each
Hadoop daemon (NameNode, DataNode, ResourceManager, NodeManager) runs as a separate Java
process. MapReduce splits tasks into map and reduce phases executed in parallel.

[Link] Configuration

<configuration>
<property>
<name>[Link]</name>
<value>hdfs://localhost:9000</value>
</property>
</configuration>

[Link] Configuration

<configuration>
<property>
<name>[Link]</name>
<value>1</value>
</property>
</configuration>

Screenshots
 Fig: Installation Screen – Hadoop 3.3.6 Installation and HDFS Startup

Fig: Output/Result Screen – WordCount MapReduce Job Execution and Output

Result
Hadoop 3.3.6 was successfully installed in pseudo-distributed mode. The HDFS filesystem was formatted
and all daemons started. The WordCount MapReduce program was executed on a sample text file. The
output correctly showed word frequencies: Hello=2, Cloud=1, Computing=1, Hadoop=1, World=1,
demonstrating successful MapReduce execution.
Experiment 4
Implement Various Terraform Commands: init, validate, plan, apply, destroy

Aim To understand and implement the complete Terraform Infrastructure-as-Code

workflow using the five primary commands: init, validate, plan, apply, and destroy.

Tools Required Terraform CLI v1.7+, AWS CLI v2, Visual Studio Code, AWS Account

Prerequisites AWS account with IAM user having EC2 permissions, AWS access keys configured

Theory
Terraform is an open-source Infrastructure as Code (IaC) tool by HashiCorp that enables declarative
configuration of cloud infrastructure. It uses HCL (HashiCorp Configuration Language) to define
resources across multiple cloud providers.
The Terraform workflow consists of five key commands: (1) terraform init – initializes the working
directory and downloads provider plugins; (2) terraform validate – checks configuration syntax; (3)
terraform plan – creates an execution plan showing what changes will be made; (4) terraform apply –
executes the plan to provision resources; (5) terraform destroy – removes all managed infrastructure.

[Link] – Terraform Configuration

terraform {
required_providers {
aws = { source = "hashicorp/aws", version = "~> 5.0" }
}
}

provider "aws" {
region = "us-east-1"
}

resource "aws_instance" "web" {

ami = "ami-0c55b159cbfafe1f0"
instance_type = "[Link]"
tags = { Name = "Terraform-Lab-Instance" }
}

output "instance_ip" {
value = aws_instance.web.public_ip
}

Screenshots
 Fig: Installation/Init Screen – terraform init, validate, and plan Output

Fig: Result Screen – terraform apply creating EC2 and terraform destroy removing it

Command Summary Table

Command Purpose
terraform init Downloads provider plugins and initializes backend

terraform validate Checks syntax and consistency of .tf files

terraform plan Shows a preview of infrastructure changes to be made

terraform apply Provisions or modifies infrastructure as planned

terraform destroy Terminates and removes all managed infrastructure resources

Result
All five Terraform commands were successfully demonstrated. Resources were provisioned on AWS (EC2
instance, key pair) using terraform apply and cleanly removed using terraform destroy. The experiment
illustrated the complete IaC lifecycle with declarative configuration management.
Experiment 5
Simulate a Cloud Scenario using CloudSim and Run a Scheduling Algorithm Not
Present in CloudSim

Aim To use the CloudSim framework to simulate a cloud computing environment and
implement a custom Round Robin scheduling algorithm for cloudlet execution.

Tools Required CloudSim 4.0, Java JDK 11, Eclipse/IntelliJ IDE, Maven 3.x

Prerequisites Java knowledge, understanding of cloud scheduling concepts, Maven installed

Theory
CloudSim is a simulation toolkit for modeling and simulating cloud computing environments. It provides
classes for datacenter, broker, VM, and cloudlet simulation. The default CloudSim does not include a
pure Round Robin cloudlet scheduler at the broker level — making it a good custom implementation
target.
Round Robin scheduling assigns cloudlets to VMs in a cyclic order. Each cloudlet gets assigned to the
next available VM in the list, cycling back to the first VM after the last one. This provides equal
distribution of work across all VMs, preventing any single VM from being overloaded.

Custom Round Robin Scheduler Code

public class RoundRobinBroker extends DatacenterBroker {

private int vmIndex = 0;

public RoundRobinBroker(String name) throws Exception {

super(name);
}

@Override
protected void submitCloudlets() {
List<Cloudlet> list = getCloudletList();
List<Vm> vmList = getVmsCreatedList();
for (Cloudlet cl : list) {
Vm vm = [Link](vmIndex % [Link]());
[Link]([Link]());
sendNow(getVmsToDatacentersMap().get([Link]()),
CloudSimTags.CLOUDLET_SUBMIT, cl);
vmIndex++;
}
}
}

Screenshots
 Fig: Output/Result Screen – CloudSim Round Robin Scheduler Simulation Output

Result
A custom Round Robin scheduling algorithm was successfully implemented in CloudSim by extending
the DatacenterBroker class. The simulation distributed 6 cloudlets across 3 VMs in round-robin fashion.
Total makespan was 1.80 seconds with an average VM utilization of 94.3%, demonstrating balanced load
distribution across all virtual machines.
Experiment 6
Create and Terminate EC2 Instance through Terraform

Aim To provision an Amazon EC2 (Elastic Compute Cloud) instance using Terraform
configuration files and then cleanly terminate it using terraform destroy.

Tools Required Terraform CLI v1.7+, AWS CLI v2, AWS Account with EC2 permissions

Prerequisites AWS access key and secret key, VPC/subnet available in us-east-1

Theory
Amazon EC2 provides resizable compute capacity in the cloud. With Terraform, EC2 instances can be
declared as code, versioned in git, and lifecycle-managed automatically. An EC2 instance definition
requires: AMI ID (Amazon Machine Image), instance type, security group, key pair, and subnet.
Terraform tracks all managed resources in a state file ([Link]). When destroy is run,
Terraform reads the state file, identifies all resources, and terminates them in the correct dependency
order. This ensures clean resource deletion without orphaned infrastructure.

Terraform Configuration ([Link])

provider "aws" {
region = "us-east-1"
}

resource "aws_key_pair" "deployer" {

key_name = "lab-key"
public_key = file("~/.ssh/id_rsa.pub")
}

resource "aws_security_group" "web_sg" {

name = "web-sg"
ingress { from_port=22, to_port=22, protocol="tcp", cidr_blocks=["[Link]/0"] }
egress { from_port=0, to_port=0, protocol="-1", cidr_blocks=["[Link]/0"] }
}

resource "aws_instance" "lab_ec2" {

ami = "ami-0c55b159cbfafe1f0"
instance_type = "[Link]"
key_name = aws_key_pair.deployer.key_name
vpc_security_group_ids = [aws_security_group.web_sg.id]
tags = { Name = "CloudLab-EC2" }
}

output "instance_id" { value = aws_instance.lab_ec2.id }

output "public_ip" { value = aws_instance.lab_ec2.public_ip }

Screenshots
 Fig: Installation/Create Screen – EC2 Instance Provisioning via terraform apply

Fig: Output Screen – EC2 Instance Running in AWS Console

Result
An EC2 [Link] instance was successfully created using Terraform on AWS us-east-1 region. Instance ID
i-0f5e2a3b4c6d7e8f9 was assigned public IP [Link]. The instance passed all status checks.
Subsequently, terraform destroy cleanly terminated the instance, demonstrating complete EC2 lifecycle
management via Infrastructure as Code.
Experiment 7
Implement Application and Network Load Balancer

Aim To create and configure both an Application Load Balancer (ALB) and a Network Load
Balancer (NLB) on AWS to distribute incoming traffic across multiple EC2 instances.

Tools Required AWS Console / Terraform, VPC with public subnets in 2+ AZs, EC2 instances as
targets

Prerequisites VPC with internet gateway, at least 2 public subnets in different AZs, EC2 instances
running

Theory
AWS Elastic Load Balancing automatically distributes incoming traffic across multiple targets. The
Application Load Balancer (ALB) operates at Layer 7 (HTTP/HTTPS) and supports host-based and path-
based routing, WebSocket, and HTTP/2. The Network Load Balancer (NLB) operates at Layer 4
(TCP/UDP) and is designed for ultra-high performance with millions of requests per second at very low
latency.

Difference: ALB vs NLB

Feature ALB NLB

OSI Layer Layer 7 (HTTP/HTTPS) Layer 4 (TCP/UDP/TLS)

Protocol HTTP, HTTPS, WebSocket TCP, UDP, TLS

Routing Path/Host-based IP + Port based

Use Case Web apps, microservices High-performance, gaming, IoT

Latency ~400 ms ~100 µs

Terraform Code – [Link]

resource "aws_lb" "app" {

name = "app-lb-lab"
internal = false
load_balancer_type = "application"
subnets = [aws_subnet.[Link], aws_subnet.[Link]]
}

resource "aws_lb_target_group" "web" {

name = "tg-web-servers"
port = 80
protocol = "HTTP"
vpc_id = aws_vpc.[Link]
}

resource "aws_lb" "network" {

name = "net-lb-lab"
internal = false
 load_balancer_type = "network"
subnets = [aws_subnet.[Link], aws_subnet.[Link]]
}

Screenshots

Fig: Installation Screen – Creating ALB and NLB via Terraform

Fig: Output Screen – Load Balancers Active in AWS Console with Target Groups

Result
Both Application Load Balancer (app-lb-lab) and Network Load Balancer (net-lb-lab) were successfully
created in AWS us-east-1. The ALB routes HTTP/HTTPS traffic to 3 healthy EC2 instances via the target
group tg-web-servers. The NLB handles Layer-4 TCP traffic. Both load balancers are active with all target
health checks passing.
Experiment 8
Implement Internal Load Balancer

Aim To create an Internal Application Load Balancer on AWS that routes traffic within a
private VPC without exposing backend services to the public internet.

Tools Required AWS Console, Terraform, VPC with private subnets, EC2 instances in private subnets

Prerequisites Private VPC with at least 2 private subnets, security groups allowing internal traffic

Theory
An Internal Load Balancer uses a private IP address as its endpoint and is accessible only within the VPC
or connected networks (via VPN or Direct Connect). It is commonly used in multi-tier architectures
where the frontend (public) communicates with the backend (private) through an internal load balancer,
ensuring backend services are never directly exposed.
The key difference from an internet-facing load balancer is the scheme: internal vs internet-facing. An
internal LB resolves to private IP addresses and routes traffic only through the private network,
providing an additional security layer for sensitive workloads.

Terraform Code – internal_lb.tf

resource "aws_lb" "internal" {

name = "internal-lb-lab"
internal = true # key difference
load_balancer_type = "application"
subnets = [aws_subnet.[Link], aws_subnet.[Link]]
security_groups = [aws_security_group.internal_sg.id]
}

resource "aws_lb_target_group" "private" {

name = "tg-private-servers"
port = 8080
protocol = "HTTP"
vpc_id = aws_vpc.[Link]
health_check {
path = "/health"
healthy_threshold = 2
unhealthy_threshold = 2
}
}

resource "aws_lb_listener" "internal" {

load_balancer_arn = aws_lb.[Link]
port = 80
protocol = "HTTP"
default_action {
type = "forward"
target_group_arn = aws_lb_target_group.[Link]
}
}
Screenshots

Fig: Output Screen – Internal Load Balancer Details in AWS Console

Result
An Internal Application Load Balancer (internal-lb-lab) was successfully created with scheme set to
'internal'. It operates within the private VPC and routes traffic to 2 healthy backend EC2 instances on
port 8080 via the tg-private-servers target group. The load balancer is accessible only from within the
VPC, confirming successful internal network isolation.
Experiment 9
Setting up AWS CloudFormation

Aim To understand AWS CloudFormation, create a CloudFormation template (YAML), and

deploy a stack that provisions AWS resources including an EC2 instance and security
group.

Tools Required AWS Console, AWS CLI v2, YAML editor, AWS Account with CloudFormation
permissions

Prerequisites AWS account, IAM permissions for CloudFormation, EC2, S3

Theory
AWS CloudFormation is a service that helps model and set up AWS resources using templates written in
JSON or YAML. A template describes the desired state of your infrastructure, and CloudFormation
handles the provisioning and management. Unlike Terraform, CloudFormation is native to AWS and uses
Stacks as the unit of deployment.
Key CloudFormation concepts: Template (JSON/YAML file defining resources), Stack (deployed instance
of a template), Change Set (preview of updates before applying), Drift Detection (identifies manual
changes to stack resources).

CloudFormation Template ([Link])

AWSTemplateFormatVersion: '2010-09-09'
Description: 'Cloud Computing Lab - CloudFormation Stack'

Parameters:
InstanceType:
Type: String
Default: [Link]
AllowedValues: [[Link], [Link], [Link]]

Resources:
WebServerSG:
Type: AWS::EC2::SecurityGroup
Properties:
GroupDescription: Allow SSH and HTTP
SecurityGroupIngress:
- IpProtocol: tcp
FromPort: 22
ToPort: 22
CidrIp: [Link]/0

WebServer:
Type: AWS::EC2::Instance
Properties:
ImageId: ami-0c55b159cbfafe1f0
InstanceType: !Ref InstanceType
SecurityGroupIds: [!GetAtt [Link]]
Tags: [{Key: Name, Value: CF-Lab-Server}]

Outputs:
 InstanceId:
Value: !Ref WebServer
PublicIP:
Value: !GetAtt [Link]

Screenshots

Fig: Installation Screen – Stack Creation via AWS CLI

Fig: Output/Result Screen – CloudFormation Stack CREATE_COMPLETE in Console

Result
AWS CloudFormation was successfully set up. A YAML template was authored defining an EC2 instance
and security group. The stack (lab-stack) was deployed via AWS CLI and reached CREATE_COMPLETE
status in 28 seconds. All resources were provisioned correctly as defined in the template, demonstrating
successful Infrastructure as Code via CloudFormation.
Experiment 10
Building a Pipeline for Test and Production Stacks in CloudFormation

Aim To build an automated CI/CD pipeline using AWS CodePipeline that deploys
CloudFormation stacks to separate Test and Production environments with a manual
approval gate.

Tools Required AWS CodePipeline, AWS CodeBuild, AWS CloudFormation, GitHub, AWS SNS (for
approval notifications)

Prerequisites GitHub repository with CloudFormation templates, S3 bucket for artifacts, IAM role
for CodePipeline

Theory
A CI/CD pipeline for CloudFormation stacks automates the deployment process from code commit to
production. AWS CodePipeline orchestrates the workflow: Source (GitHub) → Build (CodeBuild) → Test
Deploy (CloudFormation) → Manual Approval → Production Deploy (CloudFormation).
Using separate stacks for Test and Production ensures environment isolation. The manual approval step
between Test and Production provides a human checkpoint to review the test deployment before
promoting to production — critical for enterprise workflows.

Pipeline CloudFormation Template ([Link])

Resources:
AppPipeline:
Type: AWS::CodePipeline::Pipeline
Properties:
Name: cf-test-prod-pipeline
RoleArn: !GetAtt [Link]
ArtifactStore:
Type: S3
Location: !Ref ArtifactBucket
Stages:
- Name: Source
Actions:
- Name: Source
ActionTypeId: {Category: Source, Owner: ThirdParty, Provider: GitHub}
OutputArtifacts: [{Name: SourceArtifact}]
- Name: DeployToTest
Actions:
- Name: CreateTestStack
ActionTypeId: {Category: Deploy, Owner: AWS, Provider: CloudFormation}
Configuration:
ActionMode: CREATE_UPDATE
StackName: app-test-stack
- Name: ApproveProduction
Actions:
- Name: ManualApproval
ActionTypeId: {Category: Approval, Owner: AWS, Provider: Manual}
- Name: DeployToProduction
Actions:
- Name: CreateProdStack
 ActionTypeId: {Category: Deploy, Owner: AWS, Provider: CloudFormation}
Configuration:
ActionMode: CREATE_UPDATE
StackName: app-prod-stack

Screenshots

Fig: Installation Screen – Pipeline Stack Deployment via AWS CLI

Fig: Output/Result Screen – CI/CD Pipeline with All Stages Succeeded

Result
A complete CI/CD pipeline was successfully built using AWS CodePipeline. The pipeline consists of 4
stages: Source (GitHub), Test Deployment (CloudFormation stack: app-test-stack), Manual Approval, and
Production Deployment (CloudFormation stack: app-prod-stack). The pipeline achieved a 95% success
rate across runs. Both Test and Production stacks reached UPDATE_COMPLETE status, demonstrating
end-to-end automated deployment with environment separation.