3.1 EC2 & Compute Performance Optimization
Key Takeaways
- 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.
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, andOwnerallow 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
CostCenterorBusinessUnit. - 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.
A CloudOps engineer is reviewing compute rightsizing recommendations in AWS Compute Optimizer for an enterprise financial services application. The application runs month-end batch reconciliation processing on the last two days of every month, causing significant CPU and memory spikes, but remains lightly loaded during other days. The current Compute Optimizer finding lists the EC2 instances as Overprovisioned. Which operational configuration should the engineer implement to ensure Compute Optimizer accounts for these monthly processing peaks?
An operations team is deploying a 12-node Apache Kafka messaging cluster across two Availability Zones on Amazon EC2. The architecture requires that Kafka broker replicas are distributed across separate physical server racks to isolate hardware failure domains, while supporting more than 7 instances per Availability Zone. Which EC2 placement strategy satisfies these operational requirements?
A genomics research laboratory runs tightly coupled, multi-node High-Performance Computing (HPC) simulations on Amazon EC2 that rely heavily on Message Passing Interface (MPI) communication between compute nodes. The engineering team observes significant network latency and CPU kernel overhead during inter-node communication. Which compute and networking architecture provides the greatest performance optimization?