Compute Services in AWS and Azure
Amazon EC2 (Elastic Compute Cloud)
Entity:
Amazon Web Services
1.1 What EC2 Actually Is (Beyond “Virtual Machine”)
EC2 is a hypervisor-based virtualized compute service built on AWS’s global infrastructure.
At the infrastructure level:
AWS uses its Nitro Hypervisor, which offloads:
• Networking
• Storage virtualization
• Security monitoring
This ensures:
• Near bare-metal performance
• Strong isolation
• Reduced virtualization overhead
1.2 EC2 Instance Components
When you launch EC2, you define:
1. vCPU
Virtual CPUs mapped to physical cores.
Important:
• Hyperthreaded cores count as 2 vCPUs.
• CPU credit model exists for burstable instances.
2. Memory (RAM)
Directly proportional to instance family.
3. Storage Options
Two major types:
a) EBS (Elastic Block Store)
• Persistent
• Network attached
• Survives instance stop
b) Instance Store
• Local disk
• Ephemeral
• High IOPS
• Data lost on stop/terminate
1.3 AMI (Amazon Machine Image)
Entity:
Amazon Machine Image
An AMI includes:
• OS image
• Kernel
• Application stack
• Block device mappings
• Permissions
AMI Lifecycle
Enterprise Usage:
• Immutable infrastructure
• Golden image strategy
• Auto-scaling template
1.4 EC2 Instance Families (Deep Classification)
General Purpose
Balanced CPU/RAM.
Use case:
• Web servers
• Application servers
Examples:
• t-series (burstable, CPU credits)
• m-series
Compute Optimized
High CPU-to-RAM ratio.
Use case:
• High-performance computing
• Gaming servers
• Batch processing
Memory Optimized
High RAM-to-CPU ratio.
Use case:
• In-memory DB
• Redis
• SAP HANA
Storage Optimized
High disk throughput.
Use case:
• NoSQL
• Data warehousing
Accelerated Computing
GPU / FPGA.
Use case:
• ML training
• AI inference
• Graphics rendering
Auto Scaling Groups (ASG)
Entity:
Amazon EC2 Auto Scaling
Auto Scaling automatically adjusts compute capacity.
2.1 Core Components
1. Launch Template (AMI + instance config)
2. Auto Scaling Group
3. Scaling Policy
4. Load Balancer
2.2 Architecture Diagram
2.3 Scaling Policies
Target Tracking
Maintain CPU at 60%.
Step Scaling
Add 2 instances if CPU > 75%.
Predictive Scaling
Uses ML to forecast demand.
2.4 High Availability Strategy
Deploy across multiple AZs:
If AZ-1 fails → traffic routed to AZ-2/3.
Microsoft Azure Virtual Machines
Entity:
Microsoft Azure
3.1 Azure VM Architecture
Azure uses:
• Hyper-V virtualization
3.2 VM Sizes
Azure VM sizes classified as:
Category Example
General Purpose B, D series
Compute Optimized F series
Memory Optimized E series
Storage Optimized L series
GPU N series
3.3 Availability Sets vs Zones
Availability Set
Protects against:
• Hardware failure
• Rack failure
Uses:
• Fault domains
• Update domains
Availability Zones
Physically separate datacenters.
Higher resilience than Availability Sets.
Serverless Computing
AWS Lambda
Entity:
AWS Lambda
Lambda executes code:
• Without provisioning servers
• Event-driven
Lambda Architecture
Features:
• Auto scaling
• Millisecond billing
• Stateless execution
Azure Functions
Entity:
Azure Functions
Same concept:
• Trigger-based
• Consumption plan
• Automatic scaling
Serverless Characteristics
• No server management
• Short execution time
• Event-driven
• Pay-per-execution
Container Services
Containers ≠ VMs
VM:
• Full OS
Container:
• Shared kernel
• Isolated runtime
ECS
Entity:
Amazon Elastic Container Service
AWS-native container orchestration.
Two modes:
• EC2 launch type
• Fargate (serverless containers)
EKS
Entity:
Amazon Elastic Kubernetes Service
Managed Kubernetes.
AWS manages:
• Control plane
You manage:
• Worker nodes
AKS
Entity:
Azure Kubernetes Service
Managed Kubernetes in Azure.
Kubernetes Architecture
Launching and Managing Real Workloads
Let’s design a real-world architecture:
Example: E-commerce Application
Add:
• CloudWatch / Azure Monitor
• IAM roles
• Security groups
• Backup policies
Comparison Summary
Feature AWS Azure
VM Service EC2 Azure VM
Serverless Lambda Azure Functions
Kubernetes EKS AKS
Native Containers ECS AKS
Auto Scaling ASG VM Scale Sets
Architectural Decision Guidance
Choose EC2/VM if:
• Full OS control required
• Long-running workload
• Custom runtime
Choose Serverless if:
• Event-driven
• Intermittent workloads
• Microservices
Choose Containers if:
• Portability needed
• DevOps pipelines
• Microservice architecture