Compute Services and Virtual Machine Deployment

Introduction and Context

Cloud computing provides on-demand access to configurable computing resources. In Infrastructure as a Service (IaaS), a cloud provider operates physical data centres, networking, storage, and virtualization, while the customer selects and manages virtual machines (VMs), operating systems, applications, and much of the security configuration.

Amazon Web Services (AWS) and Google Cloud Platform (GCP) are two major providers. Their principal VM services are Amazon Elastic Compute Cloud (EC2) and Google Compute Engine (Compute Engine). Although their terminology differs, both services support machine images, instance types, startup automation, virtual networks, persistent disks, identity controls, autoscaling, and load balancing.

A VM deployment is not merely the act of launching a server. It is a design decision involving workload characteristics, availability requirements, security, operational effort, performance, and cost. A sound deployment therefore begins with requirements and ends with monitoring, controlled change, and eventual decommissioning.

Learning Objectives

By the end of this chapter, a learner should be able to:

1. Explain the architecture and terminology of EC2 and Compute Engine.
2. Select an appropriate machine image, instance type, storage configuration, and region.
3. Provision a VM using a console, command-line tool, or infrastructure-as-code approach.
4. Secure instances using identity, network, operating-system, and data-protection controls.
5. Use startup scripts and machine images to create repeatable deployments.
6. Explain autoscaling and load balancing and identify when each is appropriate.
7. Compare performance, availability, and pricing options.
8. Evaluate a deployment using operational and governance criteria.

1. The Virtual Machine Resource Model

A cloud VM is a software-defined computer running on shared physical infrastructure. The hypervisor allocates virtual CPUs, memory, network interfaces, and storage to the guest operating system. The customer normally sees a logical machine rather than the physical host.

A typical VM deployment consists of the following resources:

An important design principle is separation of compute from state. Stateless web servers can be replaced freely if user sessions, uploaded files, and databases are stored in durable services rather than on an individual VM's local disk.

Regions and Availability Zones

A region is a geographic area containing one or more isolated data-centre locations. AWS calls these locations Availability Zones (AZs); GCP uses zones within regions. A single-zone deployment can be suitable for development but creates a larger failure domain. Production systems commonly distribute instances across at least two zones and place them behind a load balancer.

Geographic selection affects latency, legal requirements, disaster recovery, and price. A region close to users generally reduces network latency, but data-residency regulations may require processing or storage in a particular jurisdiction.

2. EC2 and Compute Engine

Amazon EC2

An EC2 instance is launched from an Amazon Machine Image (AMI). An AMI specifies the operating system and boot configuration. AWS instance families include general-purpose, compute-optimized, memory-optimized, storage-optimized, and accelerated-computing categories. The selected instance size determines resources such as vCPUs, memory, network capacity, and sometimes included local storage.

Common EC2 deployment choices include:

• On-Demand Instances: flexible capacity with no long-term commitment.
• Reserved Instances or Savings Plans: reduced effective cost in exchange for a commitment, depending on the purchasing model.
• Spot Instances: use spare capacity at a lower price but may be interrupted.
• Elastic IP addresses: static public IPv4 addresses, subject to AWS pricing and usage rules.
• Elastic Block Store (EBS): persistent block storage attached to instances.
• Security groups: stateful virtual firewalls associated with network interfaces.
• IAM roles: temporary credentials supplied to applications running on instances.

Google Compute Engine

A Compute Engine VM is created from an image, such as a public Linux or Windows image, or a custom image created by the organization. A machine type specifies vCPUs and memory. GCP offers predefined and custom machine configurations in supported locations.

Important Compute Engine features include:

• Persistent Disk and Hyperdisk storage options.
• VPC firewall rules applied to network interfaces.
• Service accounts and IAM permissions for workload identity.
• Managed instance groups for repeated VM deployment and autoscaling.
• Preemptible or Spot VMs for interruptible workloads.
• Regional and zonal resources, depending on the service.

Conceptual comparison

The names differ, but the engineering questions are similar: what workload is being run, what resources does it need, how is it reached, how is it secured, and how does it recover from failure?

3. Selecting an Instance

Instance selection should be based on measured or estimated workload requirements rather than brand familiarity. Consider:

1. CPU profile: Is the workload compute-intensive, lightly threaded, or highly parallel?
2. Memory profile: Does it maintain large caches, in-memory datasets, or many concurrent processes?
3. Network profile: Does it serve large files, process messages, or communicate heavily with databases?
4. Storage profile: Is the workload sensitive to latency, throughput, or input/output operations per second (IOPS)?
5. Acceleration: Does it require GPUs, specialized machine-learning processors, or high-performance networking?
6. Availability: Can the workload tolerate interruption or must it remain continuously available?
7. Operating system and licensing: Are there commercial licenses or software compatibility constraints?

A practical selection method is to begin with a modest instance, test under representative load, observe CPU, memory, disk, and network metrics, and then resize or change families. CPU utilization alone is insufficient: a VM may be CPU-idle while waiting for disk I/O or constrained by memory.

4. Images and Repeatable Deployment

An image is a reusable baseline. Public images are supplied by the cloud provider or trusted publishers. Custom images are created after installing an organization-approved operating system, security agents, packages, and configuration.

Images should be:

• versioned and labelled with creation date and software revision;
• built from trusted sources;
• regularly patched;
• free from embedded passwords, private keys, and long-lived credentials;
• tested before production use;
• retained according to an established lifecycle policy.

A golden image is an approved baseline maintained by an organization. Image baking tools can create it automatically from source definitions. This approach reduces startup time and configuration drift, but images must still be rebuilt when vulnerabilities or dependencies change.

A useful distinction is between immutable and mutable infrastructure. In immutable infrastructure, a changed server is replaced by a newly built image rather than modified repeatedly in place. Mutable administration may be appropriate for investigation or special-purpose systems, but uncontrolled manual changes make deployments difficult to reproduce.

5. Provisioning a Secure VM

Provisioning can be performed through a web console, CLI, SDK, or infrastructure-as-code tool. Regardless of the interface, the workflow should be explicit:

1. Select the region and zone.
2. Select an approved image.
3. Select an instance type or machine type.
4. Define the virtual network and subnet.
5. Configure boot and data storage, including encryption.
6. Attach an instance role or service account with least privilege.
7. Define firewall rules.
8. Configure startup automation and metadata.
9. Apply tags, labels, and ownership information.
10. Launch, validate, monitor, and document the instance.

Network security

A public IP address should not be assigned automatically unless direct public access is required. A common architecture places a load balancer in a public subnet and application VMs in private subnets. Administrative access can use a managed session service, bastion host, or private connectivity rather than exposing SSH or Remote Desktop Protocol to the entire Internet.

Firewall rules should allow only required traffic. For example, a web server may accept TCP 443 from the load balancer, application traffic from approved internal sources, and management traffic only from an administrative network. The principle is default deny, explicit allow.

Do not confuse a stateful security group with application authentication. A firewall determines whether network traffic is allowed; the application must still authenticate users and authorize actions.

Identity and secrets

Applications should obtain temporary credentials through an instance role or service account. Access keys embedded in source code, images, startup scripts, or environment files are a serious risk. Secrets should be stored in a managed secrets service and retrieved using narrowly scoped identity permissions.

Operating-system security

A secure VM should use supported software, automatic or centrally managed patching, host-based protection where appropriate, time synchronization, audit logging, and removal of unnecessary services. Administrative access should use individual accounts, multifactor authentication where supported, strong key management, and recorded activity.

Storage and data protection

Boot and data disks should normally be encrypted. Backups must be tested by restoration, not merely declared successful. Encryption at rest does not protect data while it is being transmitted; TLS and appropriate network controls are required for data in transit.

6. Startup Scripts and Instance Initialization

A startup script runs during initial boot or instance initialization. It can install packages, create directories, retrieve configuration, register the VM with a monitoring system, and start an application.

A conceptual Linux startup script might:

#!/bin/bash
set -e
apt-get update
apt-get install -y nginx
systemctl enable nginx
systemctl start nginx

The exact package manager and cloud metadata mechanism differ by operating system and provider. Production scripts should be idempotent: running them more than once should not produce unintended duplication or corruption. They should also write logs, fail clearly, avoid hard-coded secrets, and pin important software versions where reproducibility matters.

Startup scripts are useful for small deployments and demonstrations. For larger fleets, a baked image plus a short initialization script is often more reliable. Long, network-dependent scripts can increase boot time and create failure points.

7. Load Balancing and Autoscaling

A load balancer distributes client requests among healthy backend instances. It can also terminate TLS, perform health checks, preserve or transform headers, and provide a stable endpoint while instances change.

A Layer 4 load balancer routes based mainly on transport information such as TCP or UDP. A Layer 7 load balancer understands application protocols such as HTTP and HTTPS and can route using hostnames, paths, or HTTP attributes.

A health check should test meaningful service readiness, not simply whether a process has opened a port. A web application health endpoint might verify that the application can serve requests while avoiding an unnecessarily expensive database operation.

Autoscaling changes the number of instances in response to demand or schedule. A managed group normally uses an instance template, health checks, minimum and maximum capacity, and a scaling policy. Scaling may use CPU utilization, request count, queue length, or another workload metric.

A simple average CPU utilization measure is:

where U_i is the utilization percentage of instance i and n is the number of instances. This arithmetic average is useful only when instances have comparable capacity and the metric represents the operational constraint. It does not by itself prove that the service is healthy.

Scaling has delay. New instances require provisioning and initialization time, so a policy based only on current CPU may react too late to sudden demand. Cooldowns, warm capacity, predictive policies, queue-based signals, and load testing can improve behaviour. Scaling out does not solve a database bottleneck or a memory leak in every instance.

8. Availability, Performance, and Cost

Availability

Availability is the proportion of time a service is usable. For a period, a basic availability measure is:

where T_total is the measurement period and T_unavailable is the time during which the defined service objective was not met. Both times must use the same unit, such as minutes. Availability calculations must define exclusions, maintenance treatment, and the monitored service boundary.

Using multiple zones can reduce the impact of a zonal failure, but redundancy is effective only if the application, load balancer, data layer, deployment process, and operational procedures also support failure. Two VMs in one zone are not equivalent to two VMs in separate zones.

Performance

Performance should be measured with workload-relevant indicators: response-time percentiles, throughput, error rate, CPU saturation, memory pressure, disk latency, IOPS, and network throughput. Average latency can hide a serious tail-latency problem; p95 or p99 latency often better represents the experience of slower requests.

Benchmark results are meaningful only when the software version, dataset, concurrency, region, storage type, and test method are recorded. Provider marketing specifications should be treated as capacity information, not as a guarantee of application performance.

Cost

A simplified monthly compute estimate is:

where each term represents the applicable monthly cost category. If compute is billed at an hourly rate r_h for h hours, then:

This estimate assumes the hourly rate remains constant and excludes discounts, taxes, free tiers, licensing, and less obvious charges. Real bills may include disk capacity, disk operations, snapshots, public IPv4 addresses, data transfer, load balancers, monitoring, and support plans.

Cost optimization techniques include rightsizing, scheduling development systems, using committed discounts for stable demand, using Spot or preemptible capacity for interruption-tolerant workloads, deleting unattached disks, and selecting appropriate storage performance rather than maximum performance by default.

9. Worked Deployment Example

An organization needs a small HTTPS application. It expects four million requests per month, requires moderate CPU, stores user files in object storage, and must tolerate failure of one availability zone.

A suitable design is:

1. Place a public HTTPS load balancer across two zones.
2. Deploy application VMs in private subnets in both zones.
3. Use an approved Linux image and an instance template.
4. Store sessions in a shared session service or use stateless tokens.
5. Store files in object storage rather than on VM boot disks.
6. Use a managed instance group or Auto Scaling group with a minimum of two instances and a tested maximum.
7. Permit HTTPS from the load balancer to the VMs and deny direct Internet access to the VMs.
8. Attach only the service permissions needed to retrieve configuration and write logs.
9. Enable encrypted disks, centralized logs, metrics, alerts, and backups for persistent data.
10. Test a failed instance and a failed-zone scenario before production release.

This design prioritizes availability and replaceability. It may cost more than one public VM, but it removes a single instance and single-zone failure point. The final size and scaling thresholds should be determined through load testing rather than assumed from request count alone.

10. Applied Case: Retail Checkout Service

The following is an illustrative case.

Background

A small online retailer initially operated its checkout application on one manually configured VM. During a promotional event, the machine became overloaded. An administrator increased the VM size manually, but the change required downtime and did not address the risk of a second failure.

Analysis

Monitoring showed high CPU during traffic peaks, but the database connection pool also reached its limit. The application stored uploaded receipts on local disk and used a static cloud access key in a configuration file. Therefore, simply adding more VMs would have created inconsistent files and multiplied the credential risk.

Approach

The team created a versioned custom image, removed the static key, and assigned a narrowly scoped instance identity. Receipt files were moved to object storage. A managed load balancer was placed before two private application instances distributed across zones. A managed instance group was configured with health checks and CPU/request-based scaling. Database capacity and connection pooling were tuned separately. Logs and alerts were centralized, and an automated deployment replaced instances rather than modifying them manually.

Outcome

The service continued operating when one instance was stopped. Deployment became repeatable, administrative exposure was reduced, and capacity could increase during the event. Costs rose slightly because the service maintained multi-zone baseline capacity, but the business accepted this in exchange for improved availability and lower operational risk.

Learning points

The case demonstrates that scalability is not only a VM-sizing problem. State management, identity, database limits, health checks, deployment automation, and observability must be considered together. Autoscaling cannot compensate for an architecture that stores essential state locally or has an unscalable dependency.

11. Challenges, Governance, and Contemporary Practice

Cloud VMs create a shared-responsibility boundary. The provider secures the underlying facilities, hardware, and core virtualization platform; the customer remains responsible for correct configuration, identity, network rules, operating systems, applications, and data according to the service model.

Governance should include asset ownership, tagging or labelling, approved images, vulnerability management, change records, backup policies, retention rules, incident response, and cost budgets. Logs may contain personal or confidential data, so collection, access, retention, and cross-border transfer must comply with applicable organizational and legal requirements.

Artificial intelligence is increasingly used for anomaly detection, capacity forecasting, incident correlation, and operational assistance. Such tools should support—not replace—human approval for destructive actions, security changes, or production scaling policies. Training data, false positives, access permissions, and auditability must be considered.

Contemporary practice is moving toward immutable images, policy-as-code, automated vulnerability scanning, confidential-computing options, workload identity, and hybrid combinations of VMs with containers and managed services. VMs remain important because they support legacy applications, specialized operating systems, custom networking, and workloads requiring stronger host-level control.

Best-Practice Checklist

• Choose a region and zone strategy based on latency, resilience, compliance, and cost.
• Use approved, patched, versioned images.
• Prefer private instances behind a load balancer where direct public access is unnecessary.
• Apply least privilege to IAM roles and service accounts.
• Store secrets in managed secret systems, never in images or source code.
• Encrypt disks and protect data in transit.
• Automate provisioning and record configuration as code.
• Make startup scripts idempotent and observable.
• Use health checks that represent real service readiness.
• Test autoscaling, backup restoration, and failure recovery.
• Monitor latency, errors, saturation, capacity, and cost.
• Remove unused instances, disks, addresses, snapshots, and credentials.

Chapter Summary

EC2 and Compute Engine provide flexible virtual machines whose design includes images, machine types, storage, networking, identity, and monitoring. Effective deployment begins with workload requirements and considers CPU, memory, I/O, network, availability, compliance, and cost. Images and startup scripts support repeatability, while immutable approaches reduce configuration drift. Security requires layered controls: least-privilege identity, restricted network access, patched operating systems, protected secrets, encryption, and auditability. Load balancers provide stable service endpoints and distribute traffic; autoscaling adjusts capacity but cannot repair an unscalable dependency. Multi-zone architectures improve resilience when all relevant components support redundancy. Finally, performance and cost must be validated through measurement, testing, and complete accounting of compute, storage, network, monitoring, and operational charges.

Key Terms

Machine image: A reusable template containing an operating system and configuration.

AMI: An Amazon Machine Image used to launch EC2 instances.

Availability Zone: An isolated cloud location within a region.

Instance type: An AWS specification of virtual CPU, memory, network, and related capabilities.

Machine type: A GCP specification of VM compute resources.

Virtual machine: A software-defined computer running on virtualized infrastructure.

Boot disk: Storage containing the operating system and boot files.

Persistent disk: Durable block storage designed to survive VM replacement.

Security group: A stateful AWS virtual firewall associated with network interfaces.

VPC firewall rule: A GCP rule controlling permitted network traffic.

IAM role: An identity granting temporary permissions to an AWS workload.

Service account: An identity used by a GCP workload or user-managed process.

Startup script: Initialization code executed when a VM starts.

Golden image: An approved, standardized machine-image baseline.

Load balancer: A service that distributes traffic among backend resources.

Health check: A test used to determine whether a backend can receive traffic.

Autoscaling: Automatic adjustment of compute capacity in response to policy or demand.

Spot or preemptible VM: Lower-cost capacity that may be interrupted by the provider.

Immutable infrastructure: A practice of replacing changed resources instead of modifying them repeatedly.

Rightsizing: Matching resource capacity to measured workload requirements.

Review Questions

Short Answer Questions

1. What is the purpose of a machine image?
2. Why should application VMs commonly be placed in private subnets?
3. Distinguish a load balancer from an autoscaling group.
4. Why are instance roles and service accounts preferable to embedded access keys?
5. Name three factors that should influence instance selection.

Long Answer Questions

1. Compare EC2 and Compute Engine in terms of images, identity, storage, firewalls, and autoscaling.
2. Explain how a secure, repeatable VM provisioning workflow should be designed.
3. Discuss the advantages and limitations of startup scripts and custom images.
4. Explain how multi-zone deployment improves availability and identify its limitations.
5. Describe the major components of VM cost and propose a cost-optimization strategy.

Analytical / Application Questions

1. Design an architecture for a web application that must survive the loss of one availability zone. Justify the placement of load balancers, VMs, data, and management access.
2. A service has low average CPU but high disk latency and increasing response-time p99. What evidence would you collect, and which resource or architecture changes would you evaluate?
3. An autoscaled application stores user uploads on each VM's local disk. Analyse the failure and scaling risks, and propose a migration plan that preserves availability and data integrity.

Multiple Choice Questions with Answers

Question 1

Which AWS resource provides persistent block storage for an EC2 instance?

A. Amazon EBS volume

B. Security group

C. IAM role

D. Route table

Correct Answer: A. Amazon EBS volume

Question 2

What is the primary purpose of a startup script?

A. To replace all firewall rules

B. To initialize and configure a VM during boot

C. To provide physical data-centre security

D. To calculate monthly tax

Correct Answer: B. To initialize and configure a VM during boot

Question 3

Which design most directly reduces exposure of application VMs to the public Internet?

A. Assigning public IP addresses to every VM

B. Placing VMs behind a public load balancer in private subnets

C. Disabling all health checks

D. Embedding administrator credentials in the image

Correct Answer: B. Placing VMs behind a public load balancer in private subnets

Question 4

What does a managed instance group or Auto Scaling group primarily manage?

A. The physical construction of a data centre

B. The number and health of repeated VM instances

C. The legal ownership of domain names

D. The contents of user passwords

Correct Answer: B. The number and health of repeated VM instances

Question 5

Which workload is generally most suitable for Spot or preemptible VMs?

A. A workload that must never be interrupted

B. A batch job designed to resume after interruption

C. A single production database with no replication

D. A firewall rule set

Correct Answer: B. A batch job designed to resume after interruption

Question 6

An availability period is 1,000 minutes and unavailable time is 10 minutes. Using A = (T_total − T_unavailable) ÷ T_total, what is availability?

A. 0.01

B. 0.10

C. 0.99

D. 1.10

Correct Answer: C. 0.99

Question 7

Which practice best follows least privilege?

A. Giving every VM administrator permissions

B. Using a narrowly scoped workload identity for required API actions

C. Sharing one permanent access key across all applications

D. Disabling audit logging

Correct Answer: B. Using a narrowly scoped workload identity for required API actions

Question 8

Why is a health check important for a load balancer?

A. It identifies backends that are ready to receive traffic

B. It increases the VM's physical memory

C. It permanently prevents all software defects

D. It eliminates the need for backups

Correct Answer: A. It identifies backends that are ready to receive traffic

Question 9

What is the main benefit of an immutable infrastructure approach?

A. It encourages undocumented manual changes

B. It replaces changed resources with tested versions

C. It requires every server to have a public IP

D. It prevents monitoring

Correct Answer: B. It replaces changed resources with tested versions

Question 10

Which item is commonly included in a complete VM cost estimate?

A. Only the operating-system boot time

B. Compute, storage, network transfer, and related services

C. Only the number of source-code files

D. Only the geographic distance to the office

Correct Answer: B. Compute, storage, network transfer, and related services