EC2, EBS, S3 and RDS Performance Optimization for SOA-C03

Right-sizing means matching an instance's type and size to what its utilization history shows it actually uses. CloudWatch already records CPUUtilization, network throughput, and per-volume disk I/O for every instance; memory and disk-space usage appear only after the CloudWatch agent publishes them (configuring that agent belongs to task 1.1 — here you consume its output). An instance averaging 4% CPU for two weeks is over-provisioned and burning money. One pinned above 80% with climbing queue depths is under-provisioned and burning users.

AWS Compute Optimizer automates that judgment. It applies machine learning to your CloudWatch utilization history and classifies each EC2 instance as over-provisioned, under-provisioned, or optimized, then recommends specific alternative instance types alongside the projected utilization on each. It produces the same style of recommendation for EBS volumes (better volume type or IOPS/throughput settings), Lambda functions (memory size), and Auto Scaling group configurations. Trusted Advisor flags idle and low-utilization instances as a cost check, but Compute Optimizer is the service built to recommend replacements.

Three details decide whether a recommendation is safe to act on:

• Lookback period. By default Compute Optimizer analyzes the last 14 days. A workload whose peak comes once a month can look idle in a 14-day window, so its recommendation undersizes it. The rightsizing lookback period preference can be set to 14 days (default), 32 days or 93 days: 14 and 32 are free, and 32 days is enough to capture a monthly cycle; 93 days requires the paid enhanced infrastructure metrics feature and is for longer cycles such as quarterly ones.
• Memory. Compute Optimizer considers memory utilization only when it is published — by the CloudWatch agent (or an external metrics ingestion integration). Without it, a memory-bound workload can be recommended a type with too little RAM. Settings that change the granularity or length of the analysed history cannot fix this, because they never add a metric that was not collected.
• Preferences. CPU and memory headroom and utilization threshold preferences make recommendations more or less conservative, but they still work from whatever data is in the lookback window.

Resource tags make optimization operational at scale. Tag instances with team, application, and environment keys so every finding can be attributed to an owner and acted on. For spend, a user-defined tag appears in Cost Explorer and cost reports only after it is activated as a cost allocation tag in the Billing and Cost Management console, By default, costs are grouped by it only from activation onward; to see earlier spend by that key, the management (payer) account can request a cost allocation tag backfill of up to 12 months, which applies the activated tag to past usage of resources that already carried it. Tag policies in AWS Organizations are a separate governance tool: they define allowed keys and values and report non-compliance, while activation (and backfill) is what controls a key's visibility in the billing tools.

An instance family encodes a resource ratio, so picking one is deciding which resource your workload exhausts first. General purpose (M, and burstable T) balances CPU and memory and fits most app servers. Compute optimized (C) gives a higher CPU share for encoding, batch processing, and CPU-bound APIs. Memory optimized (R and X) suits caches, in-memory analytics, and databases that show memory pressure. Diagnose from metrics: an instance out of memory needs R, not a bigger C.

Burstable T-family instances earn CPU credits at a fixed rate while running below their baseline CPU share and spend them to burst above it. What happens when the balance reaches zero depends on the credit specification:

So the classic slowdown signature — performance degrades after a period of sustained load, or a service slows at the same busy hour every day — applies to a T instance running in standard mode (a T2 by default, or a T3/T4g launched with standard credits). CPUCreditBalance sliding to zero right before the slowdown is the diagnosis.

Several tempting fixes do not stop the throttling. Baselines rise only modestly between T sizes, some neighbouring sizes share the same per-vCPU baseline, and t3a has the same baselines as t3, so a larger or AMD-based T instance under constant above-baseline load still drains its credits. T3, T3a and T4g instances in standard mode receive no launch credits, so stopping and starting them does not refill the balance.

The real remediation is a cost decision. Unlimited mode lets the instance keep bursting past an empty balance and suits occasional overruns. But an instance that runs above its baseline most of the day pays surplus-credit charges every day; that workload is not bursty, and a same-size fixed-performance family (M or C) is cheaper and steadier. Standard and unlimited only trade throttling for surplus charges; neither raises the baseline.

Every EBS volume type has a performance model and a ceiling, and troubleshooting starts with knowing which one you bought:

The decisive SSD difference: gp2 couples performance to size — the only way to get more baseline IOPS is a bigger volume — while gp3 decouples them, so you dial IOPS and throughput up without paying for capacity you don't need, usually at a lower price per GiB. That is why the standing recommendation is to migrate gp2 volumes to gp3.

Move to Provisioned IOPS for one of three reasons, not just raw IOPS: the volume needs more than gp3's 80,000 IOPS or 2,000 MiB/s, it needs consistent sub-millisecond latency, or it needs the highest single-volume durability (io2's 99.999% versus 99.8–99.9% for gp3, gp2 and io1). Of the two, io2 Block Express has both the higher ceiling and the higher durability. Striping several volumes in RAID 0 can add up to more IOPS, but it needs configuration inside the operating system and keeps each volume's latency profile.

For the HDD types, size on baseline, not burst. Both st1 and sc1 earn throughput credits only while running below baseline, so a scan that runs continuously empties the burst bucket and then lives on baseline throughput, which scales with size: a 2 TiB st1 volume sustains 80 MiB/s, a 2 TiB sc1 only 24 MiB/s. sc1's burst figure can look sufficient on paper while its baseline is far too low for a round-the-clock job.

io2 Multi-Attach lets one Provisioned IOPS volume attach to up to 16 Nitro-based instances in the same Availability Zone, but the application or a cluster-aware file system must coordinate writes. It is block storage for a small clustered application, not a shared file system for hundreds of readers — that is what EFS, FSx or S3 Files are for.

Here is the incident the exam loves, end to end. A nightly reporting job reads heavily from a 500 GiB gp2 data volume. The job starts fast, then slows to a crawl about twenty-five minutes in, every night. The application team swears nothing changed.

Diagnose from the volume's CloudWatch metrics. BurstBalance starts the night at 100% and slides to 0% right when the slowdown begins — the volume was bursting to 3,000 IOPS on credits, ran dry, and got throttled to its baseline of 1,500 IOPS (500 GiB × 3 IOPS/GiB). VolumeQueueLength climbs at the same moment: I/O requests are arriving faster than the throttled volume can service them, so they queue. That pair — BurstBalance at zero, queue length rising — is the textbook burst-exhaustion signature. Note the near-twins: CPUCreditBalance is the EC2 CPU equivalent, and EBSIOBalance% is a burst balance for the instance's EBS connection, not the volume.

Fix it without downtime. Elastic Volumes lets you modify a volume's type, size, and provisioned performance while it stays attached and in use. Change the volume from gp2 to gp3 at the same size — it now has 3,000 IOPS with no credit mechanism at all — and if the job needs more, provision extra IOPS or throughput directly. The modification happens in place: no detach, no restart, no maintenance window. Because gp3 performance is not tied to size, there is no reason to buy capacity the data doesn't need just to raise IOPS.

Then check the other ceiling. Volumes are not the only limit — the instance has one too, covered next. If volume metrics are clean but storage is still slow, the bottleneck is above the volumes.

An EBS slowdown is caused either by a volume reaching its own limit or by the instance reaching its aggregate EBS limit, and CloudWatch has a metric for each. Every EBS-optimized instance type has a maximum EBS bandwidth, IOPS and throughput for all its attached volumes combined. Many smaller instance sizes have a lower baseline and can burst to their maximum for a limited time (at least 30 minutes once every 24 hours), then drop back — so a slowdown that starts some time into a peak, while every volume still has headroom, points at the instance.

Read the two layers together. Volume checks at 0 with the instance check at 1 (or the instance balance draining to zero) means the volumes have room and the instance is the cap: provisioning more IOPS or switching to io2 changes nothing, and the fix is an instance type with a higher EBS limit (check the documented limit — a bigger size helps only if its EBS limit is actually higher) or spreading volumes across instances. Volume checks at 1 means the volume is undersized: raise its provisioned IOPS or throughput, or change its type.

S3 optimization questions are about matching a transfer tool to a transfer problem, then keeping request rates and storage costs under control.

Multipart upload splits a large object into parts uploaded in parallel and reassembled by S3 as one object. Parallelism raises throughput, a failed part is retried alone instead of restarting the whole object, and an interrupted upload can resume. AWS recommends it for objects over 100 MB, and since a single PUT is capped at 5 GB, larger objects require it — the limit is fixed, not a Service Quotas value.

S3 Transfer Acceleration targets distance: clients upload through the nearest edge location to the bucket's accelerate endpoint and the data rides the AWS backbone. It helps when users are far from the bucket's Region and does nothing useful for uploads that originate nearby. It combines with multipart upload: one shortens the path, the other parallelizes and makes retries cheap.

AWS DataSync is the managed bulk-transfer service: scheduled, incremental, verified transfers with built-in bandwidth throttling into S3, EFS, or FSx. From on-premises NFS or SMB storage it needs an agent; between AWS storage services (for example between EFS, FSx and S3 locations) it runs without an agent, so there is no server to deploy or patch. Choose it for migrations and recurring syncs; choose Transfer Acceleration for application uploads from distant clients; choose multipart for any single large object.

Request rate. S3 scales per prefix: at least 3,500 PUT/COPY/POST/DELETE and 5,500 GET/HEAD requests per second per partitioned prefix. A workload that hammers one prefix can receive 503 Slow Down errors while S3 scales; spread keys across more prefixes to raise the aggregate ceiling, and retry throttled requests with exponential backoff. Because the ceiling is per prefix, the fix is key design and retry behaviour; tools that speed up individual transfers do not raise it.

Storage efficiency with S3 Lifecycle. Lifecycle rules transition aging objects to cheaper classes and expire what nobody needs. Two minimums shape the rule: an object must be at least 30 days old before a transition to S3 Standard-IA or One Zone-IA, and IA classes bill objects smaller than 128 KB as 128 KB, so tiny objects rarely save money there. Add a rule that aborts incomplete multipart uploads after a few days — parts from failed uploads are billed but do not appear in object listings. S3 Storage Lens shows where storage and waste are, but it only reports; Lifecycle rules make the change.

Shared-storage questions are selection questions: match the protocol, the clients and where the data must live to the service.

The trigger words do most of the work. Linux servers need a shared file system is EFS. Windows file share with Active Directory permissions is FSx for Windows File Server. Hundreds of nodes reading one dataset at once, highest aggregate throughput is FSx for Lustre. Linux over NFS and Windows over SMB on the same data is FSx for NetApp ONTAP.

Amazon S3 Files (generally available April 2026) is a shared file system linked to an S3 bucket. Applications mount it over NFS and read, write, edit and lock files with full file-system semantics, while S3 Files keeps the file system and bucket consistent in both directions — changes made through the mount reach the bucket, and objects written through the S3 API appear as files, with no copy job. Only the active working set sits on its high-performance storage; large reads stream from S3. Place it against its look-alikes:

• Mountpoint for Amazon S3 is a client that mounts a bucket for high-throughput reads and sequential writes of new files, but it has no file locking and does not support editing existing files in place.
• FSx for Lustre also links to S3, but it is a separate parallel file system with its own client, built for HPC throughput rather than general file access to the bucket.
• Copying the data into EFS gives file access but creates a second copy that has to be kept in step with the bucket.

EFS lifecycle policies optimize cost without changing paths: Transition into Infrequent Access (and into Archive) moves files not accessed for a set period to cheaper storage classes, while files keep the same path. Transition into Standard set to On first access moves a file back to Standard when it is read again — the fix when cold files become hot again and IA access charges and latency climb. EFS throughput mode (Elastic, Provisioned or Bursting) governs how much throughput the file system delivers; which storage class a file sits in is decided only by the lifecycle policies.

RDS troubleshooting starts with CloudWatch Database Insights, the successor to Amazon RDS Performance Insights: the Performance Insights console reached end of life in 2026 and its functions now live in Database Insights (the Performance Insights API continues). It shows database load as average active sessions over time against the instance's vCPU line, sliced by wait event, SQL statement, host, and user. When load crosses the vCPU line, sessions are waiting; the SQL breakdown names the query, and the wait events say whether it is CPU, I/O, or lock contention. It runs in a Standard mode and an Advanced mode that adds features such as lock diagnostics, execution plans and fleet-level monitoring, and it raises proactive recommendations for detected issues with suggested fixes. That makes it the first stop for which queries are causing the load — before anyone resizes anything.

Do not confuse it with Enhanced Monitoring, which collects operating-system metrics from an agent on the DB host at up to 1-second granularity, including CPU and memory per OS process. Use Enhanced Monitoring to tell the database engine apart from other host activity; use Database Insights to find the SQL behind the load.

The CloudWatch side gives four metrics to read fluently: CPUUtilization (compute-bound queries or an undersized class), DatabaseConnections (an unusual spike often precedes exhaustion), FreeableMemory (a steady decline signals memory pressure and cache eviction, pushing reads to disk), and ReadLatency/WriteLatency (storage-level slowness pointing at IOPS limits or volume type). Alarms on these turn them into early warnings.

RDS Proxy answers the connection-storm scenario. It pools and shares connections, so thousands of short-lived clients — classically Lambda functions scaling out — reuse a small warm pool, and it shortens failover impact by holding client connections while the database recovers. Raising max_connections is not equivalent: each connection consumes database memory, and it treats the symptom rather than the churn.

Proxy multiplexing fails when sessions get pinned. When a client changes session state the proxy cannot safely share — for example SET statements on PostgreSQL, temporary tables, or certain prepared statements — the proxy pins that client to one database connection for the rest of the session. A high DatabaseConnectionsCurrentlySessionPinned metric shows pooling has collapsed. Fixes: move the per-connection SET statements into the proxy's initialization query, so every pooled connection is prepared once; or avoid the pinning statements in code. Session pinning filters (which tell the proxy to ignore some state changes) exist only for the MySQL engine family.

Read scaling. A read replica offloads read-heavy work such as reporting from the primary, accepting replication lag. Know the Multi-AZ difference: a Multi-AZ DB instance deployment has one standby that serves no reads — it exists only for failover — while a Multi-AZ DB cluster has two readable standbys behind a reader endpoint. And when the resource itself is undersized, scale the instance class or storage — moving RDS storage to gp3 or Provisioned IOPS raises the I/O ceiling. Automated scaling policies belong to Domain 2; here you make the sizing call.

Placement groups control where EC2 puts instances relative to each other, and each of the three strategies answers a different requirement.

A cluster group's trade-off is blast radius and capacity: everything shares one AZ, and a launch into an existing group can fail with InsufficientInstanceCapacity even though the type launches elsewhere. AWS guidance is to launch the instances you need in a single launch request using one instance type, and, if capacity runs out, to stop and start all instances in the group and retry — a restart can move the whole group onto hardware with room for all of it. The low-latency, high-throughput networking applies between instances inside one cluster placement group; traffic between separate groups gets no such guarantee.

A partition group exposes each instance's partition number, so a rack-aware application can place each replica in a different partition and one rack failure cannot take out two copies. It scales far beyond spread's seven-per-AZ cap, which is why spread is the wrong answer for isolation in a large cluster.

Enhanced networking with the Elastic Network Adapter (ENA) gives higher packets-per-second, lower latency and lower jitter at no extra charge, and it is enabled by default on current-generation instance types with current AMIs. It is the companion to a placement group, not a competing choice; EBS optimization, by contrast, concerns storage bandwidth.

Elastic Fabric Adapter (EFA) adds OS-bypass networking for tightly coupled workloads that use MPI or NCCL, such as simulations and distributed ML training, and pairs with a cluster placement group. Its deployment rules are strict: EFA traffic cannot cross Availability Zones or VPCs and is not routable, so the instances belong in one subnet; the security group must allow all inbound and outbound traffic to and from itself; and an EFA-only interface (no IP networking) cannot be an instance's primary interface, so the primary is an ENA or EFA-with-ENA interface. Because EFA traffic is not routable, its connectivity depends on subnet placement and security group rules, not route tables.