Understanding AWS Compute - Conceptual Guide

Introduction to Cloud Computing Models

Traditional Computing vs. Cloud Computing
Traditional On-Premises Model:
Physical servers in your datacenter
Fixed capacity regardless of actual usage
High upfront capital expenditure
You manage hardware, OS, runtime, and applications
Scaling requires purchasing new hardware
Cloud Computing Model:
Virtual resources provided as a service
Pay-as-you-use pricing model
Operational expenditure instead of capital
Shared responsibility model
Instant scaling capabilities
The Compute Spectrum: From Metal to Serverless
AWS compute services exist on a spectrum of abstraction and management responsibility:
[Bare Metal] → [Virtual Machines] → [Containers] → [Functions]
More Control Less Management
More Complexity More Abstraction

Core Compute Concepts

1. Virtualization Fundamentals
What is Virtualization? Virtualization creates multiple virtual instances from a single physical machine
using a hypervisor. This enables:
Resource sharing and optimization
Isolation between workloads
Hardware abstraction
 Rapid provisioning and scaling
Types of Virtualization in AWS:
Full Virtualization: Complete hardware emulation (older generation)
Paravirtualization: Modified guest OS for better performance
Hardware-Assisted Virtualization: CPU features for virtualization (modern instances)
Nitro System: AWS's custom hypervisor for enhanced performance
2. Shared Responsibility Model
Understanding who manages what is crucial for AWS compute:
AWS Responsibilities (Security OF the Cloud):
Physical infrastructure and facilities
Hypervisor and underlying hardware
Network infrastructure and controls
Service availability and patching of managed services
Customer Responsibilities (Security IN the Cloud):
Guest operating system and patches
Application software and utilities
Security groups and firewall configuration
Identity and access management
Data encryption and network traffic protection
AWS Compute Service Categories
1. Infrastructure as a Service (IaaS) - EC2
Mental Model: "Renting a computer in the cloud"
Key Concepts:
Instance: A virtual server with defined CPU, memory, storage, and network
AMI (Amazon Machine Image): Template containing OS and software configuration
Instance Types: Predefined hardware configurations optimized for different use cases
Placement Groups: Control instance placement for performance or availability
When to Use EC2:
Need full control over the operating system
Legacy applications that can't be containerized
Specific software licensing requirements
Custom network configurations
Long-running, persistent workloads
Decision Framework:
Do you need OS-level control? → Yes → Consider EC2
Do you have specific compliance requirements? → Yes → Consider EC2
Are you migrating existing applications? → Yes → EC2 might be easiest path

2. Container as a Service (CaaS) - ECS/EKS

Mental Model: "Shipping containers for your applications"
Container Benefits:
Consistency: Same environment from development to production
Efficiency: Better resource utilization than VMs
Portability: Run anywhere containers are supported
Scalability: Quick startup times enable rapid scaling
Isolation: Process-level isolation with shared OS kernel
ECS vs EKS Decision Matrix:
ECS:
- AWS-native container orchestration
- Simpler learning curve
- Tight AWS integration
- Good for AWS-first organizations
EKS:
- Industry-standard Kubernetes
- Portable across cloud providers
- Rich ecosystem and tooling
- Good for multi-cloud or Kubernetes expertise
When to Use Containers:
Microservices architectures
Applications with varying resource needs
Development/production environment consistency
CI/CD pipelines
Applications that scale frequently
3. Function as a Service (FaaS) - Lambda
Mental Model: "Code that runs only when needed"
Serverless Principles:
Event-driven: Code executes in response to triggers
Stateless: No persistent server state between invocations
Managed infrastructure: AWS handles all server management
Automatic scaling: From zero to thousands of concurrent executions
Pay-per-use: Charged only for actual execution time
Lambda Execution Model:
1. Event triggers Lambda function
2. AWS provisions execution environment (if needed)
3. Function code executes
4. Environment may be reused for subsequent invocations
5. Environment destroyed after period of inactivity
When to Use Lambda:
Event-driven processing
Infrequent or unpredictable workloads
Short-running tasks (< 15 minutes)
API backends with variable traffic
Data transformation and processing
Integration between AWS services
4. Batch Processing - AWS Batch
Mental Model: "Assembly line for computational jobs"
Batch Processing Characteristics:
Large volumes of data processed in groups
Non-interactive, background processing
Resource-intensive computations
Can tolerate delays in processing
Often run during off-peak hours
When to Use Batch:
Financial risk analysis
Scientific simulations
Image/video processing
ETL (Extract, Transform, Load) operations
Machine learning training jobs
Compute Selection Framework
1. Workload Analysis Questions
Performance Requirements:
What are the CPU, memory, and storage needs?
Are there specific performance patterns (steady, spiky, predictable)?
What are the latency requirements?
Do you need specialized hardware (GPUs, high-frequency CPUs)?
Operational Requirements:
How much operational overhead can you accept?
What level of infrastructure control do you need?
Are there specific compliance or security requirements?
What's your team's expertise level with different technologies?
Economic Considerations:
What's more important: minimizing costs or maximizing performance?
Is the workload predictable enough for reserved capacity?
 How cost-sensitive is the application?
What's the total cost of ownership including operational overhead?
2. Service Selection Decision Tree
Start: What type of workload do you have?
├── Long-running, persistent application
│ ├── Need OS control → EC2
│ ├── Containerized → ECS/EKS + EC2 or Fargate
│ └── Simple web app → Lightsail
│
├── Event-driven, short-running tasks
│ ├── < 15 minutes → Lambda
│ ├── > 15 minutes → ECS/Batch
│ └── Scheduled jobs → Lambda + EventBridge or Batch
│
├── Batch processing workload
│ ├── Complex scheduling needs → Batch
│ ├── Simple parallel processing → Lambda
│ └── Large-scale HPC → Batch + Spot instances
│
└── Development/Testing
├── Simple environments → Lightsail
├── Production-like → EC2
└── Container testing → ECS/EKS

Scaling Strategies
1. Vertical Scaling (Scale Up/Down)
Concept: Increasing the size/power of existing instances Pros: Simple, no application changes needed
Cons: Limited by instance size limits, single point of failure Best for: Databases, legacy applications
2. Horizontal Scaling (Scale Out/In)
Concept: Adding/removing instances Pros: Nearly unlimited scaling, better fault tolerance Cons:
Application must support distributed architecture Best for: Web applications, microservices
3. Auto Scaling Patterns
Reactive Scaling: Scale based on current metrics (CPU, memory) Predictive Scaling: Scale based on
forecasted demand Scheduled Scaling: Scale based on known patterns (business hours)
Auto Scaling Components:
Launch Templates: Define instance configuration
Auto Scaling Groups: Manage instance lifecycle
Scaling Policies: Define when and how to scale
Health Checks: Determine instance health
Cost Optimization Strategies
1. Understanding AWS Pricing Models
On-Demand Pricing: Pay-as-you-go with no commitments
Use case: Unpredictable workloads, testing, short-term projects
Pros: Maximum flexibility, no upfront costs
Cons: Highest per-hour cost
Reserved Instances: 1-3 year commitments for significant discounts
Standard RIs: Up to 75% discount, least flexibility
Convertible RIs: Up to 54% discount, can change instance types
Use case: Predictable, steady-state workloads
Spot Instances: Bid for unused capacity at up to 90% discount
Use case: Fault-tolerant, flexible workloads
Considerations: Can be interrupted with 2-minute notice
Best practices: Use in Auto Scaling groups with On-Demand backup
Savings Plans: Flexible pricing with 1-3 year commitments
Compute Savings Plans: Apply to any compute usage
EC2 Instance Savings Plans: Apply to specific instance families
2. Cost Optimization Techniques
Right-Sizing: Match instance types to actual usage patterns
Use CloudWatch metrics to identify over-provisioned resources
Start with smaller instances and scale up as needed
Regular review and optimization cycles
Scheduling: Turn off non-production resources when not needed
Development environments outside business hours
Test environments can be stopped between test cycles
Use Lambda functions to automate start/stop schedules
Storage Optimization: Choose appropriate storage types
gp3: General purpose SSD, good performance/cost balance
io2: High IOPS for database workloads
sc1: Cold HDD for infrequent access
st1: Throughput optimized for big data workloads
Performance Optimization
1. Instance Selection Strategy
CPU-Intensive Workloads: C5, C6i families
High-frequency processors
Optimized for compute-heavy applications
Examples: Web servers, scientific computing
Memory-Intensive Workloads: R5, R6i, X1e families
High memory-to-CPU ratios
Optimized for in-memory applications
Examples: In-memory databases, real-time analytics
Storage-Intensive Workloads: I3, I4i families
NVMe SSD storage
High sequential read/write performance
Examples: Distributed file systems, databases
Network-Intensive Workloads: Enhanced networking instances
SR-IOV and DPDK support
Higher packet-per-second performance
Examples: Network appliances, HPC clusters
2. Performance Monitoring
Key Metrics to Monitor:
CPU Utilization: Should be 70-90% for optimal efficiency
Memory Usage: Monitor for memory leaks and optimization opportunities
Network I/O: Identify bandwidth constraints
Disk I/O: Monitor IOPS and throughput usage
Application Metrics: Custom metrics specific to your application
Tools for Monitoring:
CloudWatch: Built-in monitoring for AWS resources
CloudWatch Insights: Query and analyze log data
X-Ray: Distributed tracing for applications
Third-party tools: Datadog, New Relic, AppDynamics
Security Considerations
1. Network Security
VPC (Virtual Private Cloud): Isolated network environment
Public Subnets: Resources accessible from internet
Private Subnets: Resources accessible only within VPC
Security Groups: Instance-level firewalls
NACLs: Subnet-level firewalls
Best Practices:
Use private subnets for application and database tiers
Implement defense in depth with multiple security layers
Regular security group audits and cleanup
Enable VPC Flow Logs for network monitoring
2. Identity and Access Management
IAM Roles vs. Users:
Roles: Temporary credentials for AWS resources
 Users: Permanent credentials for human access
Best practice: Use roles for EC2 instances and Lambda functions
Principle of Least Privilege:
Grant only the minimum permissions necessary
Use policy conditions to restrict access
Regular access reviews and permission audits
Implement separation of duties
3. Data Protection
Encryption at Rest:
EBS volume encryption using AWS KMS
S3 bucket encryption for data storage
Database encryption for RDS and DynamoDB
Encryption in Transit:
TLS/SSL for all network communications
VPN connections for hybrid environments
AWS PrivateLink for service-to-service communication
Disaster Recovery and Business Continuity
1. Availability Zones and Regions
Availability Zones (AZs):
Physically separate data centers within a region
Low-latency connections between AZs
Use multiple AZs for high availability
Regions:
Geographically separate areas
Use multiple regions for disaster recovery
Consider data sovereignty and compliance requirements
2. Backup and Recovery Strategies
RTO (Recovery Time Objective): How quickly you need to recover RPO (Recovery Point Objective):
How much data loss is acceptable
Backup Strategies:
EBS Snapshots: Point-in-time backups of EBS volumes
AMI Creation: Full instance backups including OS and applications
Database Backups: Automated backups for RDS and other databases
Cross-region replication: For disaster recovery scenarios
3. Multi-AZ and Multi-Region Patterns
Multi-AZ Deployment:
Load balancers distribute traffic across AZs
Auto Scaling groups span multiple AZs
Database replication across AZs
Multi-Region Deployment:
Route 53 for DNS failover
Cross-region replication for data
Warm standby or pilot light patterns
Migration Strategies
1. The 6 R's of Migration
Rehost (Lift and Shift):
Move applications without changes
Fastest migration path
Limited cloud benefits initially
Replatform (Lift, Tinker, and Shift):
Minor optimizations during migration
Examples: Migrate to RDS instead of self-managed database
Balance between speed and optimization
Refactor/Re-architect:
 Redesign application for cloud-native benefits
Highest effort but maximum cloud benefits
Examples: Migrate to serverless, microservices
Retire:
Decommission applications that are no longer needed
Reduces overall migration scope and costs
Retain:
Keep applications on-premises
May be due to compliance or technical constraints
Repurchase:
Move to SaaS solutions
Examples: Move from on-premises CRM to Salesforce
2. Migration Tools and Services
AWS Application Migration Service:
Lift-and-shift migrations with minimal downtime
Automated replication of source servers
AWS Database Migration Service:
Migrate databases with minimal downtime
Supports homogeneous and heterogeneous migrations
AWS Snow Family:
Offline data transfer for large datasets
Snowball, Snowball Edge, Snowmobile
Best Practices Summary
1. Design Principles
Design for Failure:
Assume components will fail
 Implement redundancy and failover mechanisms
Use multiple AZs and regions when appropriate
Implement Elasticity:
Design applications to scale automatically
Use managed services that scale with demand
Implement proper monitoring and alerting
Optimize for Cost:
Right-size resources based on actual usage
Use appropriate pricing models for each workload
Implement automated cost controls and monitoring
2. Operational Excellence
Infrastructure as Code:
Use CloudFormation, Terraform, or CDK
Version control your infrastructure
Automated deployment pipelines
Monitoring and Observability:
Implement comprehensive monitoring
Use distributed tracing for complex applications
Set up automated alerting and response
Security by Design:
Implement security at every layer
Use managed security services when possible
Regular security assessments and updates
3. Performance Optimization
Continuous Optimization:
Regular performance testing and optimization
Monitor and adjust resource allocation
 Stay current with new instance types and features
Leverage AWS Services:
Use managed services to reduce operational overhead
Take advantage of AWS global infrastructure
Implement proper caching strategies
Conclusion
Understanding AWS Compute requires grasping the fundamental shift from traditional infrastructure
thinking to cloud-native approaches. The key is matching your specific requirements—performance,
cost, operational overhead, and scalability needs—with the most appropriate compute service.
Success in AWS compute comes from:
Understanding the trade-offs between different service models
Designing for cloud-native patterns like elasticity and fault tolerance
Continuously optimizing based on actual usage patterns
Implementing proper security and operational practices
Staying current with AWS service evolution and best practices
The cloud computing landscape continues to evolve, with increasing abstraction and automation. The
trend is toward serverless and managed services that allow you to focus on business logic rather than
infrastructure management. However, traditional compute models like EC2 remain important for
specific use cases where control and customization are required.