3.1 EC2 & Compute Performance Optimization

AWS Certified CloudOps Engineer – Associate SOA-C03

Track your progress as you read

Finished sections get a check mark.

1 Chapter 1: Monitoring & Observability Infrastructure

1.1 Configuring Workload Observability 1.2 CloudWatch Agent Architecture & Deployment 1.3 Metric Alarms, Anomaly Detection & Composite Alarms

2 Chapter 2: Alarms, Dashboards & Event-Driven Remediation

2.1 CloudWatch Dashboards & Multi-Account Visibility 2.2 Notification Architecture & Alarm Invocation 2.3 Amazon EventBridge Rules, Event Buses & Troubleshooting 2.4 Automated Remediation with Systems Manager & Lambda

3 Chapter 3: Performance Optimization for Compute, Storage & Databases

3.1 EC2 & Compute Performance Optimization 3.2 Amazon EBS Performance Metrics & Volume Tuning 3.3 S3 Performance Strategies & Data Transfer 3.4 Shared Storage (EFS/FSx) & Database Performance

4 Chapter 4: Compute & Database Scalability and Elasticity

4.1 EC2 Auto Scaling Policies & Elasticity 4.2 Auto Scaling Advanced Operations: Warm Pools & Lifecycle Hooks 4.3 Dynamic Scalability Through Caching 4.4 Managed Database Scaling: RDS, Aurora & DynamoDB

5 Chapter 5: High Availability, Fault Tolerance & Load Balancing

5.1 Elastic Load Balancing (ALB/NLB) Configuration & Troubleshooting 5.2 Route 53 Health Checks & DNS Failover 5.3 Multi-AZ Architecture & Fault-Tolerant Deployments

6 Chapter 6: Backup, Data Protection & Disaster Recovery

6.1 Centralized Backup Automation & AWS Backup 6.2 Database Restore Strategies & RTO/RPO Management 6.3 Storage Versioning, Replication & Immutability 6.4 Disaster Recovery Patterns & Multi-Region Resilience

7 Chapter 7: Infrastructure as Code with CloudFormation & AWS CDK

7.1 CloudFormation Foundations & Resource Modeling 7.2 Managing Stacks, Drift Detection & Change Sets 7.3 Infrastructure as Code with AWS CDK 7.4 Identifying & Remediating Deployment Failures

8 Chapter 8: Multi-Account Provisioning, Containers & Third-Party IaC

8.1 Golden Images with EC2 Image Builder & Amazon ECR 8.2 Multi-Account & Multi-Region Resource Sharing 8.3 Deployment Strategies & Container Deployments 8.4 Third-Party Automation with Terraform & Git Workflows

9 Chapter 9: Systems Manager & Event-Driven Operations Automation

9.1 AWS Systems Manager Core Management & Run Command 9.2 Systems Manager Patch Manager & Session Manager 9.3 Event-Driven Operations Automation

10 Chapter 10: Identity, Access Management & Governance

10.1 Advanced IAM Policies, Roles & Policy Conditions 10.2 Auditing Access with CloudTrail Lake & IAM Access Analyzer 10.3 Multi-Account Security: Organizations, SCPs & Identity Center 10.4 Compliance Enforcement with AWS Config & Conformance Packs

11 Chapter 11: Data Security, Encryption & Vulnerability Management

11.1 Data Classification & Amazon S3 Security 11.2 Encryption at Rest with AWS Key Management Service (KMS) 11.3 Encryption in Transit with AWS Certificate Manager (ACM) 11.4 Secrets Management & Centralized Security Findings

12 Chapter 12: VPC Architecture, Endpoints & Network Protection

12.1 VPC Core Architecture, Subnetting & High Availability NAT 12.2 Private Network Connectivity: VPC Endpoints & Peering 12.3 Network Protection & Edge Security Auditing

13 Chapter 13: DNS, Route 53 Routing & Content Delivery

13.1 DNS Architecture & Route 53 Resolver for Hybrid Clouds 13.2 Route 53 Advanced Routing Policies & Query Logging 13.3 Global Content & Service Distribution: CloudFront & Global Accelerator

14 Chapter 14: Network Troubleshooting, Traffic Analysis & Hybrid Connectivity

14.1 VPC Configuration Troubleshooting & Analysis Tools 14.2 Network Traffic Analysis: VPC Flow Logs & Log Analytics 14.3 CloudFront Caching & Hybrid Connectivity Troubleshooting

3.1 EC2 & Compute Performance Optimization

Key Takeaways Explain This Topic AI

AWS Compute Optimizer leverages machine learning on CloudWatch metrics to classify EC2 instances, Auto Scaling groups, EBS volumes, and Lambda functions as Underprovisioned, Overprovisioned, Optimized, or None.

The default 14-day metric lookback period can be extended to 3 months (90 days) with paid Enhanced Infrastructure Metrics to accurately capture monthly and quarterly cyclical workloads.

Resource tagging enables operational analysis, financial chargeback via Cost Allocation Tags, and automated lifecycle tasks via Systems Manager and AWS Backup.

EC2 Placement Groups configure physical hardware placement: Cluster provides low latency in a single AZ, Spread enforces rack-level isolation up to 7 instances per AZ, and Partition isolates logical hardware partitions for distributed systems like Kafka and Cassandra.

Enhanced Networking with ENA delivers up to 100+ Gbps, while EFA provides OS-bypass for MPI HPC workloads, contrasting with ephemeral instance store NVMe drives versus persistent EBS volumes.

Last updated: September 2026

3.1 EC2 & Compute Performance Optimization

CloudOps Blueprint Focus: AWS Certified CloudOps Engineer – Associate (SOA-C03) candidates must evaluate compute utilization, configure automated rightsizing, select resilient placement group topologies, and balance high-performance networking and storage architectures.

Compute Performance in Cloud Operations

Optimizing Amazon EC2 workloads requires continuous balancing of application responsiveness, availability, and cost. CloudOps engineers must identify workload patterns, prevent overprovisioning or underprovisioning, and place instances appropriately across the AWS physical infrastructure.

AWS Compute Optimizer: Machine Learning Resource Analysis

AWS Compute Optimizer evaluates historical Amazon CloudWatch metrics using machine learning algorithms to generate rightsizing recommendations for Amazon EC2 instances, Auto Scaling groups (ASGs), Amazon EBS volumes, and AWS Lambda functions.

Finding Classifications & Metric Requirements

Compute Optimizer analyzes workload history and assigns one of four finding classifications:

Underprovisioned: The resource is constrained in at least one hardware dimension (CPU, memory, storage throughput, or network I/O). Recommendations propose scaling up or moving to newer generational silicon.

Overprovisioned: Hardware allocations consistently exceed demands. The system can be safely downsized to reduce infrastructure spend without impacting performance SLAs.

Optimized: Specifications align well with workload demands, maintaining balanced performance and cost.

None: Insufficient metric history exists. Compute Optimizer requires at least 30 to 36 hours of continuous CloudWatch data before generating recommendations.

Evaluated Dimension CloudWatch Source Metric CloudWatch Agent Required?

• CPU Utilization CPUUtilization No (Hypervisor metric)
• Memory Utilization mem_used_percent Yes (OS-level metric via CloudWatch Agent)
• Local Disk I/O DiskReadOps , DiskWriteOps No (Instance store metric)
• Network In/Out NetworkIn , NetworkOut No (Hypervisor metric)
• EBS Throughput EBSReadBytes , EBSWriteBytes No (EBS-optimized metric)

Important

The EC2 hypervisor cannot observe operating system RAM. Unless the CloudWatch Agent is installed and actively publishing memory metrics, Compute Optimizer evaluates only CPU, disk, and network metrics, risking unintended downsizing of memory-intensive applications.

Lookback Periods & Inferred Workload Types

By default, Compute Optimizer evaluates CloudWatch metrics across a 14-day lookback window at no charge. For enterprise applications with monthly or quarterly batch spikes (such as financial reconciliation), a 14-day window may mistakenly label servers as overprovisioned.

Activating Enhanced Infrastructure Metrics , a paid add-on, extends the evaluation period to 3 months (90 days) . Furthermore, Compute Optimizer detects inferred workload types (such as relational databases or web servers) to prevent aggressive downsizing on workloads maintaining large in-memory caches.

Strategic Resource Tagging for CloudOps Governance

A standardized tagging taxonomy is foundational for operational governance:

Operational Analysis: Tags such as Environment ( prod , dev ), ApplicationID , and Owner allow operations teams to filter, monitor, and group resources during system incidents.

Cost Allocation: Activating user-defined tags in the AWS Billing console as Cost Allocation Tags allows granular chargeback by CostCenter or BusinessUnit .

Automated Lifecycle Management: Automation tools, Systems Manager Maintenance Windows, and AWS Backup query tags to execute scheduled maintenance, such as start/stop schedules ( Schedule=BusinessHours ) and patch baselines ( PatchGroup=Linux-Prod ). Tag Policies in AWS Organizations enforce mandatory tag keys and casing.

EC2 Placement Groups: Topologies & Isolation

EC2 Placement Groups determine how instances are physically positioned within AWS data center infrastructure: Cluster (Single AZ) Spread (Multi-AZ) Partition (Multi-AZ)

• [Rack 1] [Rack 1] [Rack 2] [Rack 3] [Partition 1] [Partition 2]
• +------------------+ +------+ +------+ +------+ +-------------+ +-------------+
• | Inst A | Inst B | | Inst | | Inst | | Inst | | Inst | Inst | | Inst | Inst |
• | Inst C | Inst D | | 1 | | 2 | | 3 | | A | B | | C | D |
• +------------------+ +------+ +------+ +------+ +-------------+ +-------------+
• (High throughput, <10µs) (Max 7 instances per AZ) (Up to 7 partitions per AZ)

Cluster Placement Groups: Tightly packs instances onto shared physical racks within a single Availability Zone. Delivers single-digit microsecond latency and network throughput up to 100 Gbps. Ideal for tightly coupled High-Performance Computing (HPC) and distributed machine learning training. Cannot span multiple AZs.

Spread Placement Groups: Places each instance on distinct physical hardware racks with independent power and network feeds. Eliminates correlated hardware failures for mission-critical primary/standby databases and quorum nodes. Limited to a strict maximum of 7 running instances per Availability Zone .

Partition Placement Groups: Divides the group into logical partitions (up to 7 partitions per AZ). Instances in one partition do not share hardware with instances in another partition, supporting hundreds of instances. Ideal for distributed datastores like Kafka, Cassandra, and HDFS. Partition assignments are visible via EC2 instance metadata.

• Placement Group AZ Boundary Capacity Limit Primary Use Case
• Cluster Single AZ Limited by instance limits HPC, tightly coupled MPI, low latency
• Spread Multi-AZ 7 instances per AZ Critical database pairs, quorum nodes
• Partition Multi-AZ Hundreds of instances Kafka brokers, Cassandra nodes, HDFS
• Enhanced Networking & High-Performance Interconnects

Traditional virtual networking relies on hypervisor emulation, adding CPU overhead. Enhanced Networking uses Single Root I/O Virtualization (SR-IOV) for direct hardware access:

Elastic Network Adapter (ENA): The standard interface for modern instances, delivering up to 100+ Gbps throughput, high packets-per-second, and low latency jitter.

Elastic Fabric Adapter (EFA): Designed for HPC and deep learning, EFA provides OS-bypass via the Scalable Reliable Datagram (SRD) protocol, allowing Message Passing Interface (MPI) applications to communicate directly with network hardware without traversing the OS kernel.

Storage Attachment Trade-offs: Instance Store vs. EBS

EC2 Instance Store: Physically attached NVMe/SSD drives offering ultra-high random IOPS, multi-gigabyte throughput, and sub-millisecond latency. However, it is ephemeral : data is lost when an instance stops, terminates, or fails. Used for temporary scratch data, read caches, and distributed datastores with application-level replication.

Amazon EBS: Network-attached virtual block storage persisting independently of instance lifecycles. Supports point-in-time snapshots to S3, live volume modification via Elastic Volumes, and native encryption, making it the standard choice for durable workloads.