EBS-Optimized

AWS EBS Performance

~ Last updated on : ~ jayendrapatil ~ 9 Comments

AWS EBS Performance Tips

  • EBS Performance depends on several factors including I/O characteristics, instances and volumes configuration and can be improved using Provisioned IOPS (io2 Block Express), EBS-Optimized instances, proper volume type selection, and RAID configuration.

📢 Key Updates (2025-2026)

  • gp3 volumes enhanced (Sept 2025) – Now support up to 64 TiB size (4x increase), 80,000 IOPS (5x increase), and 2,000 MiB/s throughput (2x increase).
  • io2 Block Express – Delivers up to 256,000 IOPS, 4,000 MB/s throughput, 64 TiB capacity with sub-millisecond latency and 99.999% durability.
  • Instance Bandwidth Weighting – New feature allows shifting up to 25% of network bandwidth to EBS for I/O-intensive workloads.
  • io1 → io2 migration recommended – AWS recommends upgrading io1 to io2 for better performance and durability at the same cost.
  • gp2 → gp3 migration recommended – gp3 offers 20% lower cost with better baseline performance (3,000 IOPS, 125 MiB/s).
  • RAID 0 less necessary – With gp3’s increased limits (80,000 IOPS per volume), many workloads no longer require multi-volume striping.

EBS Volume Type Selection for Performance

  • Selecting the right volume type is the most impactful decision for EBS performance.
  • gp3 (General Purpose SSD) – Recommended default for most workloads.
    • Baseline: 3,000 IOPS and 125 MiB/s at any volume size (no burst credits needed)
    • Max: 80,000 IOPS and 2,000 MiB/s throughput
    • Size: up to 64 TiB
    • Performance is provisioned independently of storage capacity
    • 20% lower cost per GB than gp2
  • io2 Block Express (Provisioned IOPS SSD) – For mission-critical, latency-sensitive workloads.
    • Max: 256,000 IOPS, 4,000 MB/s throughput, 64 TiB capacity
    • Sub-millisecond latency (avg. under 500 microseconds)
    • 99.999% durability (vs 99.8-99.9% for gp3)
    • Up to 1,000 IOPS per GiB ratio
    • Multi-Attach support (up to 16 instances simultaneously)
    • Available on all Nitro-based EC2 instances
  • gp2 (Previous Generation General Purpose SSD) – Still available but migration to gp3 is recommended.
    • Max: 16,000 IOPS, 250 MB/s throughput, 16 TiB
    • IOPS scales with volume size at 3 IOPS/GiB
    • Burst credit model for volumes under 1 TiB
  • io1 (Previous Generation Provisioned IOPS SSD) – Migration to io2 Block Express is recommended.
    • Max: 64,000 IOPS, 1,000 MB/s throughput, 16 TiB
    • 50 IOPS per GiB ratio
    • 99.8-99.9% durability

EBS-Optimized or 10 Gigabit Network Instances

  • An EBS-Optimized instance uses an optimized configuration stack and provides additional, dedicated capacity for EBS I/O.
  • Optimization provides the best performance for the EBS volumes by minimizing contention between EBS I/O and other traffic from an instance.
  • EBS-Optimized instances deliver dedicated throughput to EBS depending on the instance type used.
  • All current-generation EC2 instance types are EBS-optimized by default at no additional cost.
  • Some previous-generation instance types support EBS-optimization as an optional feature with an additional hourly fee.
  • When attached to an EBS–optimized instance,
    • General Purpose (gp3) volumes are designed to deliver within 10% of their provisioned performance 99% of the time in a given year.
    • Provisioned IOPS (io2 Block Express) volumes are designed to deliver within 10% of their provisioned performance 99.9% of the time in a given year.
  • The maximum EBS throughput varies by instance type – for example, latest generation instances like C8gd/M8gd/R8gd provide up to 40 Gbps of EBS bandwidth.

Instance Bandwidth Weighting

  • EC2 instances on select Nitro-based instance types support configurable bandwidth weighting between EBS and VPC networking.
  • Using the ebs-1 bandwidth weighting option increases EBS bandwidth by up to 25%, which reduces VPC network bandwidth by the same amount.
  • This is beneficial for I/O-intensive workloads that require higher EBS throughput but have lower network requirements.
  • The total available baseline bandwidth for the instance remains the same; it only shifts the allocation.
  • Network PPS and EBS IOPS specifications are unaffected by bandwidth weighting changes.
  • Can be configured at launch time using launch templates or modified on running instances.

EBS Volume Initialization – Pre-warming

  • Empty EBS volumes receive their maximum performance the moment that they are available and DO NOT require initialization (pre-warming).
  • EBS volumes needed a pre-warming, previously, before being used to get maximum performance to start with. Pre-warming of the volume was possible by writing to the entire volume with 0 for new volumes or reading the entire volume for volumes from snapshots.
  • Storage blocks on volumes that were restored from snapshots must be initialized (pulled down from S3 and written to the volume) before the block can be accessed.
  • This preliminary action takes time and can cause a significant increase in the latency of an I/O operation the first time each block is accessed.
  • To avoid this initial performance hit in a production environment, the following options can be used:
    • Force the immediate initialization of the entire volume by using the dd or fio utilities to read from all of the blocks on a volume.
    • Enable Fast Snapshot Restore (FSR) on a snapshot to ensure that the EBS volumes created from it are fully-initialized at creation and instantly deliver all of their provisioned performance.
  • Fast Snapshot Restore (FSR) considerations:
    • FSR eliminates the latency of I/O operations on first access of snapshot-restored volumes.
    • Available in all commercial AWS regions (expanded to 6 additional regions in August 2024).
    • Not supported with AWS Outposts, Local Zones, and Wavelength Zones.
    • FSR is charged per AZ per hour per snapshot enabled, so cost should be considered.

Elastic Volumes

  • Elastic Volumes allows modifying EBS volume size, type, IOPS, and throughput without detaching the volume or stopping the instance.
  • Supported on all current-generation instances and several previous-generation instances (C1, C3, C4, G2, I2, M1, M3, M4, R3, R4).
  • Modifications include:
    • Increasing volume size (cannot decrease)
    • Changing volume type (e.g., gp2 → gp3, io1 → io2)
    • Adjusting provisioned IOPS and throughput (gp3, io1, io2)
  • Size increases take effect once the modification reaches the “optimizing” state (usually seconds).
  • The file system must be extended within the OS after a size increase.
  • A volume can only be modified once every 6 hours.

RAID Configuration

  • EBS volumes can be striped, if a single EBS volume does not meet the performance requirements.
  • Note: With gp3 volumes now supporting up to 80,000 IOPS and 2,000 MiB/s per volume, many workloads that previously required RAID 0 can now use a single volume, improving resiliency.
  • Striping volumes allows pushing tens of thousands of IOPS beyond single-volume limits.
  • EBS volumes are already replicated across multiple servers in an AZ for availability and durability, so AWS generally recommends striping for performance rather than durability.
  • For greater I/O performance than can be achieved with a single volume, RAID 0 can stripe multiple volumes together; for on-instance redundancy, RAID 1 can mirror two volumes together.
  • RAID 0 allows I/O distribution across all volumes in a stripe, allowing straight gains with each addition.
  • RAID 1 can be used for durability to mirror volumes, but in this case, it requires more EC2 to EBS bandwidth as the data is written to multiple volumes simultaneously and should be used with EBS–optimization.
  • EBS volume data is replicated across multiple servers in an AZ to prevent the loss of data from the failure of any single component.
  • AWS doesn’t recommend RAID 5 and 6 because the parity write operations of these modes consume the IOPS available for the volumes and can result in 20-30% fewer usable IOPS than RAID 0.
  • A 2-volume RAID 0 config can outperform a 4-volume RAID 6 that costs twice as much.
  • Durability consideration: Each additional volume in a RAID 0 stripe reduces effective durability (e.g., 4 gp3 volumes in RAID 0 = ~99.6% effective durability vs. 99.9% for a single volume). With increased gp3 limits, fewer volumes are needed for the same performance.

RAID Configuration

EBS Performance Best Practices Summary

  • Use gp3 as the default volume type – provides better baseline performance than gp2 at 20% lower cost.
  • Use io2 Block Express for critical databases – sub-millisecond latency, 99.999% durability, up to 256K IOPS.
  • Right-size your instance – ensure the instance’s EBS bandwidth limit is not the bottleneck (use CloudWatch EBSIOBalance% and EBSByteBalance% metrics).
  • Use EBS bandwidth weighting for I/O-intensive workloads with lower network needs.
  • Prefer single larger volumes over RAID 0 when gp3 limits (80,000 IOPS, 2,000 MiB/s) are sufficient – simpler and more durable.
  • Enable Fast Snapshot Restore for production volumes restored from snapshots to avoid first-access latency.
  • Monitor with CloudWatch – track VolumeReadOps, VolumeWriteOps, VolumeQueueLength, and BurstBalance (gp2) metrics.
  • Migrate legacy volumes – upgrade gp2 → gp3 and io1 → io2 using Elastic Volumes (no downtime required).

AWS Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • AWS services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • AWS exam questions are not updated to keep up the pace with AWS updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.
  1. A user is trying to pre-warm a blank EBS volume attached to a Linux instance. Which of the below mentioned steps should be performed by the user?
    1. There is no need to pre-warm an EBS volume (with latest update no pre-warming is needed)
    2. Contact AWS support to pre-warm (This used to be the case before, but pre warming is not necessary now)
    3. Unmount the volume before pre-warming
    4. Format the device
  2. A user has created an EBS volume of 10 GB and attached it to a running instance. The user is trying to access EBS for first time. Which of the below mentioned options is the correct statement with respect to a first time EBS access?
    1. The volume will show a size of 8 GB
    2. The volume will show a loss of the IOPS performance the first time (the volume needed to be wiped cleaned before for new volumes, however pre warming is not needed any more)
    3. The volume will be blank
    4. If the EBS is mounted it will ask the user to create a file system
  3. You are running a database on an EC2 instance, with the data stored on Elastic Block Store (EBS) for persistence At times throughout the day, you are seeing large variance in the response times of the database queries Looking into the instance with the isolate command you see a lot of wait time on the disk volume that the database’s data is stored on. What two ways can you improve the performance of the database’s storage while maintaining the current persistence of the data? Choose 2 answers
    1. Move to an SSD backed instance
    2. Move the database to an EBS-Optimized Instance
    3. Use Provisioned IOPs EBS
    4. Use the ephemeral storage on an m2.4xLarge Instance Instead
  4. You have launched an EC2 instance with four (4) 500 GB EBS Provisioned IOPS volumes attached. The EC2 Instance is EBS-Optimized and supports 500 Mbps throughput between EC2 and EBS. The two EBS volumes are configured as a single RAID 0 device, and each Provisioned IOPS volume is provisioned with 4,000 IOPS (4000 16KB reads or writes) for a total of 16,000 random IOPS on the instance. The EC2 Instance initially delivers the expected 16,000 IOPS random read and write performance. Sometime later in order to increase the total random I/O performance of the instance, you add an additional two 500 GB EBS Provisioned IOPS volumes to the RAID. Each volume is provisioned to 4,000 IOPS like the original four for a total of 24,000 IOPS on the EC2 instance Monitoring shows that the EC2 instance CPU utilization increased from 50% to 70%, but the total random IOPS measured at the instance level does not increase at all. What is the problem and a valid solution?
    1. Larger storage volumes support higher Provisioned IOPS rates: increase the provisioned volume storage of each of the 6 EBS volumes to 1TB.
    2. EBS-Optimized throughput limits the total IOPS that can be utilized use an EBS-Optimized instance that provides larger throughput. (EC2 Instance types have limit on max throughput and would require larger instance types to provide 24000 IOPS)
    3. Small block sizes cause performance degradation, limiting the I’O throughput, configure the instance device driver and file system to use 64KB blocks to increase throughput.
    4. RAID 0 only scales linearly to about 4 devices, use RAID 0 with 4 EBS Provisioned IOPS volumes but increase each Provisioned IOPS EBS volume to 6.000 IOPS.
    5. The standard EBS instance root volume limits the total IOPS rate, change the instant root volume to also be a 500GB 4,000 Provisioned IOPS volume
  5. A user has deployed an application on an EBS backed EC2 instance. For a better performance of application, it requires dedicated EC2 to EBS traffic. How can the user achieve this?
    1. Launch the EC2 instance as EBS provisioned with PIOPS EBS
    2. Launch the EC2 instance as EBS enhanced with PIOPS EBS
    3. Launch the EC2 instance as EBS dedicated with PIOPS EBS
    4. Launch the EC2 instance as EBS optimized with PIOPS EBS
  6. A company is running an I/O-intensive database on a gp2 EBS volume and experiencing inconsistent performance. The DBA wants to achieve consistent 50,000 IOPS with the lowest cost. Which approach should they use?
    1. Use multiple gp2 volumes in RAID 0 configuration
    2. Migrate to a single gp3 volume and provision 50,000 IOPS
    3. Use an io2 Block Express volume with 50,000 provisioned IOPS
    4. Use multiple gp3 volumes in RAID 0 to aggregate IOPS

    (gp3 now supports up to 80,000 IOPS per volume at a lower cost than io2. For 50,000 IOPS without needing 99.999% durability, gp3 is the most cost-effective choice.)

  7. An application requires 256,000 IOPS with sub-millisecond latency for a critical Oracle database. Which EBS configuration provides the required performance?
    1. Four gp3 volumes with 64,000 IOPS each in RAID 0
    2. Multiple io1 volumes in RAID 0 configuration
    3. A single io2 Block Express volume with 256,000 provisioned IOPS on a Nitro-based instance
    4. Eight gp3 volumes with 32,000 IOPS each in RAID 0

    (io2 Block Express supports up to 256,000 IOPS per volume with sub-millisecond latency. A single volume approach is simpler and provides higher durability (99.999%) than RAID configurations.)

  8. A team has restored an EBS volume from a snapshot and needs to serve production traffic immediately with full provisioned IOPS. What should they do?
    1. Pre-warm the volume by reading all blocks using the dd utility
    2. Wait for 24 hours for background initialization to complete
    3. Enable Fast Snapshot Restore (FSR) on the snapshot before creating the volume
    4. Attach the volume to an EBS-optimized instance to speed up initialization

    (Fast Snapshot Restore ensures volumes created from the snapshot are fully initialized at creation, eliminating first-access latency. This must be enabled before creating the volume.)

  9. An EC2 instance is running an I/O-heavy analytics workload with low network traffic requirements. The team wants to maximize EBS throughput without changing the instance type. What feature can help?
    1. Enable Enhanced Networking on the instance
    2. Configure the instance with ebs-1 bandwidth weighting to increase EBS bandwidth by 25%
    3. Enable placement groups for the instance
    4. Attach additional network interfaces to the instance

    (Instance bandwidth weighting allows reallocating up to 25% of VPC network bandwidth to EBS, beneficial for workloads with high I/O but low networking needs.)

  10. A company wants to migrate their existing io1 volumes to a newer volume type with better durability and performance without application downtime. Which approach is recommended? (Select TWO)
    1. Create new io2 volumes from snapshots and switch
    2. Use Elastic Volumes to modify the volume type from io1 to io2 without detaching
    3. The migration provides 99.999% durability (up from 99.8-99.9%) at the same cost
    4. io1 to io2 migration requires stopping the instance
    5. io2 volumes cost 50% more than io1 for the same IOPS

    (Elastic Volumes supports online type change from io1 to io2. io2 provides higher durability and performance (1,000 IOPS/GiB vs 50 IOPS/GiB) at the same storage and IOPS pricing.)

AWS EC2 Instance Types

~ Last updated on : ~ jayendrapatil ~ 12 Comments

EC2 Instance Types

📌 2026 Update Summary

  • EC2-Classic retired (August 2023) – All instances now run in VPC only.
  • T2, C4, G2, I2, D2 are now Previous Generation instances. Current generation alternatives include T3/T4g, C7i/C8i/C7g/C8g, G5/G6, I4i/I7i/I8g, and D3/D3en.
  • All current generation instances are built on the AWS Nitro System, are HVM-only, and EBS-optimized by default.
  • AWS Graviton processors (Graviton4/Graviton5) power Arm-based instance families (suffix “g”) with up to 40% better price-performance.
  • Flex instances (M7i-flex, C7i-flex, M8i-flex, C8i-flex) offer cost-effective burst performance for most workloads.
  • Paravirtual (PV) virtualization is effectively deprecated – all current instances use HVM exclusively.
  • EC2 Instance types determine the hardware of the host computer used for the instance.
  • EC2 Instance types offer different compute, memory & storage capabilities and are grouped in instance families based on these capabilities.
  • EC2 provides each instance with a consistent and predictable amount of CPU capacity, regardless of its underlying hardware.
  • EC2 dedicates some resources of the host computer, such as CPU, memory, and instance storage, to a particular instance.
  • EC2 shares other resources of the host computer, such as the network and the disk subsystem, among instances. If each instance on a host computer tries to use as much of one of these shared resources as possible, each receives an equal share of that resource. However, when a resource is under-utilized, an instance can consume a higher share of that resource while it’s available.
  • All current generation instances are built on the AWS Nitro System, a combination of dedicated hardware and a lightweight hypervisor that delivers isolated multi-tenancy, private networking, and fast local storage.

EC2 Instance Naming Convention

  • Instance types follow a naming convention: [Family][Generation][Additional capabilities].[Size]
  • Example: m7i.xlarge = General Purpose (m), 7th generation, Intel processor, Extra Large size
  • Common suffixes:
    • g – AWS Graviton (Arm-based) processor
    • i – Intel processor
    • a – AMD processor
    • d – Local NVMe instance storage
    • n – Network optimized
    • e – Extra storage or memory
    • flex – Flex variant (baseline + burst)

EC2 Instance Types Selection Criteria

  • All current generation instances use HVM virtualization exclusively. Paravirtual (PV) is only available on legacy previous-generation instances and is not recommended.
  • All EC2 instances run in a VPC. EC2-Classic was fully retired in August 2023.
  • Some instances support only EBS volumes, while others support both EBS and Instance store volumes (indicated by “d” suffix, e.g., m7gd, c7gd). Instance store volumes on current generations use NVMe-based SSDs.
  • All current generation instances are EBS-optimized by default with dedicated capacity for EBS I/O.
  • Some EC2 Instance types can be launched in placement groups to optimize instances for High-Performance Computing (HPC).
  • All current generation instances support Enhanced Networking using Elastic Network Adapter (ENA) for significantly higher packet per second (PPS) performance, lower network jitter, and lower latencies.
  • All EBS volumes support encryption on current generation instances.
  • Processor options: Intel Xeon (6th Gen), AMD EPYC, or AWS Graviton (Arm-based) processors depending on the instance family.

EBS-Optimized

  • EBS-optimized instance uses an optimized configuration stack and provides additional, dedicated capacity for EBS I/O.
  • EBS-optimized instances enable you to get consistently high performance for the EBS volumes by eliminating contention between EBS I/O and other network traffic from the instance.
  • EBS-optimized instances deliver dedicated throughput between Amazon EC2 and EBS, with options between 500 and 400,000 Megabits per second (Mbps) depending on the instance type used.
  • When attached to an EBS-optimized instance, General Purpose (SSD) volumes are designed to deliver within 10 percent of their baseline and burst performance 99.9 percent of the time in a given year, and Provisioned IOPS (SSD) volumes are designed to deliver within 10 percent of their provisioned performance 99.9 percent of the time in a given year.
  • All current generation instances (5th gen and later) are EBS-optimized by default at no additional cost.

Placement Groups

  • EC2 Placement groups determine how the instances are placed on the underlying hardware.
  • AWS provides three types of placement groups:
    • Cluster – clusters instances into a low-latency group in a single AZ
    • Partition – spreads instances across logical partitions, ensuring that instances in one partition do not share underlying hardware with instances in other partitions
    • Spread – strictly places a small group of instances across distinct underlying hardware to reduce correlated failures

NOTE – AWS continuously releases new instance types. Refer to the AWS EC2 Instance Types documentation for the latest information.

EC2 Instance Families – Current Generation (2024-2026)

Family Category Current Generations Use Cases
M General Purpose M7i, M7g, M7a, M8i, M8g, M9g Web servers, app servers, gaming, mid-size databases
T General Purpose (Burstable) T3, T3a, T4g Micro-services, dev/test, small databases
C Compute Optimized C7i, C7g, C7a, C8i, C8g, C8a HPC, batch processing, gaming, ML inference
R Memory Optimized R7i, R7g, R7a, R8i, R8g In-memory databases, real-time analytics
X Memory Intensive X2gd, X2idn, X8g SAP HANA, large in-memory databases
I Storage Optimized (SSD) I4i, I4g, I7i, I8g NoSQL databases, OLTP, data warehousing
D Storage Optimized (HDD) D3, D3en Hadoop, data lakes, distributed file systems
G Accelerated Computing (Graphics) G5, G6, G6e ML inference, graphics rendering, game streaming
P Accelerated Computing (GPU) P4d, P5, P5e, P5en, P6 Deep learning training, HPC, scientific computing
Hpc High Performance Computing Hpc7g, Hpc7a, Hpc6a Tightly-coupled HPC workloads

AWS Graviton-Based Instances

  • AWS Graviton processors are custom-designed by AWS to deliver the best price-performance for cloud workloads.
  • Graviton-based instances (suffix “g”) deliver up to 40% better price-performance over comparable x86-based instances.
  • Graviton4 (current, 2024) – Powers M8g, C8g, R8g, X8g instances with up to 30% better performance over Graviton3.
  • Graviton5 (GA June 2026) – Powers M9g instances with 25% better performance over Graviton4, purpose-built for agentic AI workloads.
  • Graviton instances support Linux-based operating systems (Amazon Linux 2/2023, Ubuntu, RHEL, SUSE) and containers.
  • Ideal for applications that can run on Arm architecture: web servers, containers, microservices, open-source databases, caching layers, and ML inference.

Flex Instances

  • EC2 Flex instances (M7i-flex, C7i-flex, M8i-flex, C8i-flex) are lower-priced variants of their standard counterparts.
  • They deliver a baseline of 40% CPU performance and can scale up to full CPU performance 95% of the time.
  • Offer up to 19% better price-performance compared to previous generation instances.
  • Available in sizes from large to 16xlarge.
  • Well suited for: web/application servers, virtual desktops, batch processing, microservices, databases, and enterprise applications.
  • Unlike T-series burstable instances, Flex instances do not use a CPU credit system — they simply deliver baseline performance with automatic scaling.

Burstable Performance Instances (T-Series)

  • T-series instances (current: T3, T3a, T4g) are designed to provide moderate baseline performance with the capability to burst to significantly higher performance as required.
  • Mainly intended for workloads that don’t use the full CPU often or consistently, but occasionally need to burst.
  • Well suited for:
    • General-purpose workloads such as web servers, developer environments, remote desktops, and small databases
  • Current T-series Instances:
    • T4g – Powered by AWS Graviton2 (Arm-based), up to 40% better price-performance than T3
    • T3 – Intel Xeon processors, Nitro-based
    • T3a – AMD EPYC processors, lower cost alternative to T3
  • Features:
    • Launch with HVM AMI only
    • VPC only (EC2-Classic retired)
    • EBS-backed only
    • Available as On-Demand, Reserved, Dedicated Instances (T3/T3a), and Spot Instances
    • Built on AWS Nitro System
    • Support Enhanced Networking with ENA
    • Support Unlimited mode by default (T3/T3a/T4g)
  • Unlimited Mode (Default for T3/T3a/T4g)
    • Can sustain high CPU performance for as long as a workload needs it.
    • For most general-purpose workloads, provides ample performance without additional charges.
    • If the instance runs at higher CPU utilization for a prolonged period beyond earned credits, additional charges apply at a flat rate per vCPU-hour.

CPU Credits

  • CPU Credits provide the performance of a full CPU core for one minute.
  • T-series instances provide a baseline level of CPU performance, while CPU credits govern the ability to burst above the baseline level.
  • One CPU credit is equal to one vCPU running at 100% utilization for one minute. For e.g., One vCPU running at 100% for One min OR One vCPU running @ 50% for 2 mins OR Two vCPU running @ 25% for 2 mins.
  • Each instance continuously receives a set rate of CPU credits per hour, depending on instance size.
  • Each instance accumulates CPU credits when it uses fewer CPU resources than its allowed baseline performance levels.
  • Maximum earned credit balance for an instance is equal to the number of CPU credits received per hour times 24 hours.
  • CPU credit balance is available for a period of 24 hours; it expires 24 hours after they were earned.
  • CPU credits cease to persist between an instance stop-start. However, after the start, the instance receives initial CPU credits again.
  • In Standard mode, when the credit balance is completely exhausted, the instance will perform at its baseline performance.
  • In Unlimited mode (default for T3/T3a/T4g), the instance can burst beyond earned credits and surplus credits are charged.

⚠️ Previous Generation: T2 Instances

T2 instances are now classified as Previous Generation. They are still fully supported but AWS recommends migrating to:

  • T3 – Intel-based, Nitro system, better performance
  • T3a – AMD-based, lower cost than T3
  • T4g – Graviton2-based, up to 40% better price-performance than T3

Key differences: T3/T3a/T4g are Nitro-based, support Unlimited mode by default, and provide better baseline performance and networking.

C7i/C8i Instances (Compute Optimized – Current Generation)

  • Compute-optimized instances are ideal for compute-bound applications that benefit from high-performance processors.
  • Current generation compute-optimized:
    • C8i / C8i-flex (2025) – Custom Intel Xeon 6 processors, up to 20% better performance than C7i
    • C8g / C8gn (2025) – Graviton4, up to 30% better performance than C7g; C8gn offers up to 600 Gbps network bandwidth
    • C8a (2025) – AMD EPYC, up to 57% faster for Java workloads than C7a
    • C7i / C7i-flex – 4th Gen Intel Xeon Scalable (Sapphire Rapids)
    • C7g / C7gn – Graviton3 processors
    • C7a – AMD EPYC (Genoa) processors
  • Well suited for:
    • Batch processing workloads
    • Media transcoding
    • High-performance web servers
    • High-performance computing (HPC)
    • Scientific modeling and machine learning inference
    • Dedicated gaming servers and ad serving engines
  • Features:
    • EBS-optimized by default
    • Enhanced Networking with ENA (up to 600 Gbps for C8gn)
    • Can be launched in placement groups
    • Built on AWS Nitro System
    • Requires 64-bit HVM AMI

⚠️ Previous Generation: C4 Instances

C4 instances are now classified as Previous Generation. Upgrade to:

  • C7i / C8i – Intel-based, significantly better performance
  • C7g / C8g – Graviton-based, best price-performance
  • C7a / C8a – AMD-based alternative

G5/G6 Instances (Accelerated Computing – Graphics)

  • GPU instances provide high parallel processing capability for graphics and ML inference workloads.
  • Current generation:
    • G6 / G6e (2024) – NVIDIA L4 GPUs (up to 8), ideal for ML inference and graphics workloads
    • G5 – NVIDIA A10G GPUs (up to 8), for graphics-intensive applications and ML inference
  • Well suited for:
    • Machine learning inference
    • Graphics rendering and game streaming
    • Video transcoding with hardware acceleration
    • Remote visualization workstations
  • For deep learning training, use P-series instances:
    • P5 / P5en – NVIDIA H100/H200 Tensor Core GPUs for large-scale training
    • P4d / P4de – NVIDIA A100 GPUs
  • Features:
    • Built on AWS Nitro System
    • Requires HVM AMI with NVIDIA drivers installed
    • Support Enhanced Networking with ENA
    • Support Elastic Fabric Adapter (EFA) for GPU-to-GPU communication

⚠️ Previous Generation: G2 Instances

G2 instances are now classified as Previous Generation. Upgrade to:

  • G6 / G6e – NVIDIA L4 GPUs, latest generation for inference and graphics
  • G5 – NVIDIA A10G GPUs, widely available

I4i/I7i/I8g Instances (Storage Optimized – SSD)

  • Storage-optimized I-series instances are designed to deliver high random I/O operations per second (IOPS) to applications.
  • Current generation:
    • I8g (2024) – Graviton4 + 3rd Gen Nitro SSDs, up to 65% better storage performance per TB vs I4g
    • I7i (2025) – Intel Xeon + 3rd Gen Nitro SSDs, up to 50% better storage performance vs I4i, up to 45TB NVMe
    • I4i – Intel Xeon (Ice Lake) + Nitro SSDs, up to 30TB NVMe storage
    • I4g / Im4gn / Is4gen – Graviton2-based storage optimized
  • Well suited for:
    • NoSQL databases (Cassandra, MongoDB, DynamoDB-compatible)
    • In-memory databases
    • Online transaction processing (OLTP) systems
    • Real-time analytics and data warehousing
  • Features:
    • NVMe-based SSD instance storage with always-on encryption
    • Built on AWS Nitro System
    • Enhanced Networking with ENA
    • Can be launched in placement groups
    • EBS-optimized by default

⚠️ Previous Generation: I2 Instances

I2 instances are now classified as Previous Generation. Upgrade path:

  • I2 → I3 → I4i → I7i (Intel-based progression)
  • I4g / I8g (Graviton-based alternative for best price-performance)

I3 provides 4x higher I/O performance, 2x higher disk throughput, and NVMe SSDs compared to I2.

D3/D3en Instances (Storage Optimized – HDD)

  • D3/D3en instances are designed for workloads with very high storage density and that require high sequential read/write access to very large data sets on local storage.
  • Current generation:
    • D3 – 30% higher processor performance, 2.5x higher networking, 45% higher disk throughput compared to D2
    • D3en – Up to 336TB of HDD storage, optimized for lowest cost per TB of storage
  • Well suited for:
    • Massive parallel processing (MPP) data warehouse
    • Hadoop/Spark distributed computing and data lakes
    • Log or data processing applications
    • Distributed file systems
  • Features:
    • Primary data storage is HDD-based instance storage
    • EBS-optimized by default
    • Enhanced Networking with ENA
    • Can be clustered in a placement group
    • Built on AWS Nitro System

⚠️ Previous Generation: D2 Instances

D2 instances are now classified as Previous Generation. Upgrade to:

  • D3 – 30% more compute power, 2.5x networking, 45% higher disk throughput
  • D3en – Up to 336TB storage, lowest cost per TB

AWS Nitro System

  • The AWS Nitro System is the underlying platform for all current generation EC2 instances.
  • It offloads virtualization, storage, and networking functions to dedicated hardware and software.
  • Benefits:
    • Nearly all CPU resources devoted to customer workloads
    • Enhanced security with hardware-based isolation
    • Higher network performance (up to 600 Gbps)
    • Higher EBS performance (up to 400 Gbps)
    • Bare metal instances (no hypervisor overhead)
  • Nitro components: Nitro Cards (VPC, EBS, local storage), Nitro Security Chip, Nitro Hypervisor.
  • 6th generation Nitro Cards (2026) power the latest C8, M8, R8 instances.

AWS Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • AWS services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • AWS exam questions are not updated to keep up the pace with AWS updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.
  1. Which of the following instance types are available as Amazon EBS-backed only? Choose 2 answers
    1. General purpose T2
    2. General purpose M3
    3. Compute-optimized C4
    4. Compute-optimized C3
    5. Storage-optimized I2
  2. A t2.medium EC2 instance type must be launched with what type of Amazon Machine Image (AMI)?
    1. An Instance store Hardware Virtual Machine AMI
    2. An Instance store Paravirtual AMI
    3. An Amazon EBS-backed Hardware Virtual Machine AMI
    4. An Amazon EBS-backed Paravirtual AMI
  3. You have identified network throughput as a bottleneck on your m1.small EC2 instance when uploading data into Amazon S3 in the same region. How do you remedy this situation?
    1. Add an additional ENI
    2. Change to a larger instance
    3. Use DirectConnect between EC2 and S3
    4. Use EBS PIOPS on the local volume

    [Note: m1.small is a previous generation instance. Current recommendation would be to migrate to a current-gen instance like M7i or T3 for better network performance.]

  4. You are using an m1.small EC2 Instance with one 300 GB EBS volume to host a relational database. You determined that write throughput to the database needs to be increased. Which of the following approaches can help achieve this? Choose 2 answers
    1. Use an array of EBS volumes (Striping to increase throughput)
    2. Enable Multi-AZ mode
    3. Place the instance in an Auto Scaling Groups
    4. Add an EBS volume and place into RAID 5 (RAID 5 is not recommended as it provides parity and EBS volumes are already replicated across multiple servers in an Availability Zone for availability and durability, so AWS recommends striping for performance rather than durability)
    5. Increase the size of the EC2 Instance
    6. Put the database behind an Elastic Load Balancer
  5. You are tasked with setting up a cluster of EC2 Instances for a NoSQL database. The database requires random read IO disk performance up to a 100,000 IOPS at 4KB block size per node. Which of the following EC2 instances will perform the best for this workload?
    1. A High-Memory Quadruple Extra Large (m2.4xlarge) with EBS-Optimized set to true and a PIOPs EBS volume
    2. A Cluster Compute Eight Extra Large (cc2.8xlarge) using instance storage
    3. High I/O Quadruple Extra Large (hi1.4xlarge) using instance storage
    4. A Cluster GPU Quadruple Extra Large (cg1.4xlarge) using four separate 4000 PIOPS EBS volumes in a RAID 0 configuration

    [Note: This is a legacy question. For current generation, I4i or I7i instances would be the optimal choice for high IOPS NoSQL workloads, offering hundreds of thousands of IOPS with NVMe SSDs.]

  6. A t2.medium EC2 instance type must be launched with what type of Amazon Machine Image (AMI)?
    1. An Instance store Hardware Virtual Machine AMI
    2. An Instance store Paravirtual AMI
    3. An Amazon EBS-backed Hardware Virtual Machine AMI
    4. An Amazon EBS-backed Paravirtual AMI
  7. You are implementing a URL whitelisting system for a company that wants to restrict outbound HTTPS connections to specific domains from their EC2-hosted applications. You deploy a single EC2 instance running proxy software and configure it to accept traffic from all subnets and EC2 instances in the VPC. After a few days you notice that some machines are failing to successfully download some updates. What might be happening? (Choose 2 answers) [PROFESSIONAL]
    1. You are running the proxy on an undersized EC2 instance type so network throughput is not sufficient for all instances to download their updates in time.
    2. You have not allocated enough storage to the EC2 instance running the proxy so the network buffer is filling up causing some requests to fail
    3. You are running the proxy in a public subnet but have not allocated enough EIPs to support the needed network throughput through the Internet Gateway (IGW)
    4. You are running the proxy on a sufficiently-sized EC2 instance in a private subnet and its network throughput is being throttled by a NAT running on an undersized EC2 instance
    5. The route table for the subnets containing the affected EC2 instances is not configured to direct network traffic for the software update locations to the proxy
  8. You have been asked to design the storage layer for an application. The application requires disk performance of at least 100,000 IOPS. The storage layer must be able to survive the loss of an individual disk, EC2 instance, or Availability Zone without any data loss. The volume must have a capacity of at least 3TB. Which design will meet these objectives? [PROFESSIONAL]
    1. Instantiate an i2.8xlarge instance in us-east-1a. Create a RAID 0 volume using the four 800GB SSD ephemeral disks provided with the instance. Provision 3×1 TB EBS volumes, attach them and configure them as a second RAID 0 volume. Configure synchronous, block-level replication from the ephemeral backed volume to the EBS-backed volume. (Same AZ will not survive the AZ loss)
    2. Instantiate an i2.8xlarge instance in us-east-1a. Create a RAID 0 volume using the four 800GB SSD ephemeral disks provided with the instance. Configure synchronous block-level replication to an identically configured instance in us-east-1b.
    3. Instantiate a c3.8xlarge instance in us-east-1. Provision an AWS Storage Gateway and configure it for 3 TB of storage and 100,000 IOPS. Attach the volume to the instance. (Need synchronous replication to prevent any data loss)
    4. Instantiate a c3.8xlarge instance in us-east-1. Provision 4x1TB EBS volumes, attach them and configure them as a single RAID 5 volume. Ensure that EBS snapshots are performed every 15 minutes. (RAID 5 not recommended by AWS and Need synchronous replication to prevent any data loss)
    5. Instantiate a c3.8xlarge instance in us-east-1. Provision 3x1TB EBS volumes, attach them and configure them as a single RAID 0 volume. Ensure that EBS snapshots are performed every 15 minutes. (Need synchronous replication to prevent any data loss)

    [Note: This is a legacy question using previous-gen instances (i2, c3). For current architecture, I7i instances with cross-AZ replication or io2 Block Express volumes with Multi-Attach would be considered.]

  9. [NEW] A company wants to deploy a general-purpose web application with unpredictable traffic patterns. They want the best price-performance and the application runs on Linux with open-source software. Which instance type provides the best option?
    1. M7i.large
    2. T4g.large
    3. C7i.large
    4. T3.large

    [T4g offers the best price-performance for burstable workloads with open-source Linux applications due to Graviton2 Arm-based processors.]

  10. [NEW] A company needs to run a high-performance NoSQL database that requires consistent sub-millisecond latency and at least 100,000 random read IOPS from local storage. Which current-generation instance family is MOST suitable?
    1. D3en
    2. M7i
    3. I4i
    4. R7g

    [I4i instances use AWS Nitro NVMe SSDs optimized for high random IOPS with consistent low latency, ideal for NoSQL databases.]

  11. [NEW] Which of the following are benefits of AWS Graviton-based instances? (Choose 3 answers)
    1. Up to 40% better price-performance over comparable x86 instances
    2. Support for Windows Server operating system
    3. Lower energy consumption and better sustainability
    4. Support for Linux-based operating systems and containers
    5. Support for PV (paravirtual) AMIs
  12. [NEW] Which statement about EC2 Flex instances (e.g., M7i-flex, C7i-flex) is correct?
    1. They use a CPU credit system similar to T2 instances
    2. They are only available for Graviton-based instances
    3. They deliver a baseline of 40% CPU performance and can scale up to full performance 95% of the time
    4. They are limited to small and medium instance sizes only
  13. [NEW] All current generation EC2 instances share which of the following characteristics? (Choose 3 answers)
    1. Built on the AWS Nitro System
    2. Support both HVM and PV virtualization
    3. EBS-optimized by default
    4. Support Enhanced Networking with ENA
    5. Include local instance storage

References