EC2

EC2 Instance Store – Ephemeral NVMe Storage & Use Cases

EC2 Instance Store
~ Last updated on : ~ jayendrapatil ~ 19 Comments

EC2 Instance Store

  • An instance store provides temporary or Ephemeral block-level storage for an Elastic Cloud Compute – EC2 instance.
  • is located on the disks that are physically attached to the host computer.
  • consists of one or more instance store volumes exposed as block devices.
  • The size of an instance store varies by instance type.
  • Virtual devices for instance store volumes are named ephemeral[0-23], starting the first one as ephemeral0 and so on.
  • While an instance store is dedicated to a particular instance, the disk subsystem is shared among instances on a host computer.
  • is ideal for temporary storage of information that changes frequently, such as buffers, caches, scratch data, and other temporary content, or for data that is replicated across a fleet of instances, such as a load-balanced pool of web servers.
  • delivers very high random I/O performance and is a good option for storage with very low latency requirements, but you don’t need the data to persist when the instance terminates or you can take advantage of fault-tolerant architectures.
  • Instance store volumes are included as part of the usage cost of the instance. There is no additional charge.

EC2 Instance Store

Instance Store Volume Types

  • Instance store volumes use either NVMe-based solid state drives (SSD), SATA-based SSDs, or SATA-based hard disk drives (HDD).
  • NVMe SSD – Used by most current-generation instances (e.g., C8gd, M8gd, R8gd, C8id, M8id, R8id, I7i, I8g, I8ge, M9gd). Provides the highest performance.
  • Non-NVMe SSD – Used by older instance types such as C3, I2, M3, R3, and X1.
  • HDD – Used by dense storage instances such as D2 and H1.
  • For instance types with NVMe instance store volumes, all supported instance store volumes are automatically attached at launch.
  • For instance types with non-NVMe instance store volumes (C1, C3, M1, M2, M3, R3, D2, H1, I2, X1, X1e), block device mappings must be manually specified at launch.

Instance Store Lifecycle

  • Instance store data lifetime is dependent on the lifecycle of the Instance to which it is attached.
  • Data on the Instance store persists when an instance is rebooted.
  • However, the data on the instance store does not persist if the
    • underlying disk drive fails
    • instance terminates
    • instance hibernates
    • instance stops i.e. if the EBS-backed instance with instance store volumes attached is stopped
  • Stopping, hibernating, or terminating an instance causes every block of storage in the instance store to be reset.
  • You can’t stop or hibernate instance store-backed instances.
  • If an AMI is created from an Instance with an Instance store volume, the data on its instance store volume isn’t preserved.
  • Do not rely on instance store volumes for valuable, long-term data.

Instance Store Volumes

  • Instance type of an instance determines the size of the instance store available for the instance and the type of hardware used for the instance store volumes.
  • Instance store volumes are included as part of the instance’s usage cost.
  • Some instance types use solid-state drives (SSD) to deliver very high random I/O performance, which is a good option when storage with very low latency is needed, but the data does not need to be persisted when the instance terminates or architecture is fault tolerant.
  • Instance store volume capacity varies widely by instance type:
    • General purpose (M8gd, M9gd): up to 11.4 TB NVMe SSD
    • Compute optimized (C8gd, C8id): up to 11.4–22.8 TB NVMe SSD
    • Memory optimized (R8gd, R8id): up to 11.4–22.8 TB NVMe SSD
    • Storage optimized (I7i): up to 45 TB NVMe SSD
    • Storage optimized (I8g): up to 45 TB NVMe SSD (3rd gen Nitro SSDs)
    • Storage optimized (I8ge): up to 120 TB NVMe SSD (3rd gen Nitro SSDs)

Instance Store Volumes with EC2 instances

  • EBS volumes and instance store volumes for an instance are specified using a block device mapping.
  • Instance store volume
    • can only be attached to an EC2 instance when the instance is launched.
    • cannot be detached and reattached to a different instance.
  • After an instance is launched, the instance store volumes for the instance should be formatted and mounted before it can be used.
  • Root volume of an instance store-backed instance is mounted automatically.
  • For NVMe-based instance store volumes, all volumes are automatically attached at launch — no block device mapping specification is needed.

Instance Store Encryption

  • Data on NVMe instance store volumes is encrypted at rest using an XTS-AES-256 block cipher implemented in a hardware module on the instance.
  • Encryption keys are generated using the hardware module and are unique to each NVMe instance storage device.
  • All encryption keys are destroyed when the instance is stopped or terminated and cannot be recovered.
  • You cannot disable this encryption and you cannot provide your own encryption key.
  • Some HDD instance store volumes also support encryption at rest.
  • AWS Nitro SSDs (used in I4i, I7i, I8g, I8ge, and other storage-optimized instances) provide always-on encryption as part of the hardware design.

Instance Store TRIM Support

  • Some instance types support SSD volumes with TRIM.
  • Instance store volumes that support TRIM are fully trimmed before they are allocated to the instance.
  • These volumes are not formatted with a file system when an instance launches, so you must format them before they can be mounted and used.
  • For faster access, skip the TRIM operation when initially formatting the volumes.
  • Use the TRIM command to notify the SSD controller when data is no longer needed, which provides more free space, reduces write amplification, and increases performance.
  • On Linux, use the fstrim command to enable periodic TRIM.
  • On Windows, use fsutil behavior set DisableDeleteNotify 0 to ensure TRIM support is enabled.

Instance Store Optimizing Writes

  • Because of the way that EC2 virtualizes disks, the first write to any location on an instance store volume performs more slowly than subsequent writes.
  • Amortizing (gradually writing off) this cost over the lifetime of the instance might be acceptable.
  • However, if high disk performance is required, AWS recommends initializing the drives by writing once to every drive location before production use.
  • To reduce write amplification on SSD-based instance store volumes, leave 10 percent of the volume unpartitioned for over-provisioning. This decreases usable storage but increases performance even when the disk is close to full capacity.

Detailed NVMe Performance Statistics

  • EC2 provides real-time, high-resolution performance statistics for NVMe instance store volumes attached to Nitro-based instances (launched September 2025).
  • Statistics include 11 comprehensive metrics at 1-second granularity:
    • Total read/write operations and bytes
    • Total read/write time (microseconds)
    • Volume queue length
    • Volume performance exceeded IOPS/throughput counters
    • Read/Write I/O latency histograms (broken down by I/O size)
  • Statistics are available at no additional cost.
  • Can be accessed via nvme-cli tool directly on the instance or via Amazon CloudWatch agent for monitoring and alarms.
  • Counters are not persistent across instance stops and restarts.
  • Helps identify performance bottlenecks and optimize latency-sensitive workloads.

Latest Instance Types with Instance Store (2025-2026)

  • Graviton5 (M9gd) – General purpose instances with local NVMe SSD storage, powered by AWS Graviton5 processors (June 2026). Ideal for data logging, media processing, and batch/log processing.
  • Graviton4 (C8gd, M8gd, R8gd) – Compute, general purpose, and memory optimized instances with up to 11.4 TB NVMe SSD storage, powered by AWS Graviton4 (April 2025). 30% better performance vs. Graviton3-based predecessors.
  • Intel Xeon 6 (C8id, M8id, R8id) – Up to 22.8 TB NVMe SSD storage with up to 384 vCPUs (February 2026). 43% higher performance and 3x more local storage vs. 6th generation.
  • Storage Optimized I7i – Up to 45 TB NVMe storage with PCIe Gen5-based Nitro SSDs. 50% better real-time storage performance and 50% lower I/O latency vs. I4i.
  • Storage Optimized I7ie – Up to 120 TB NVMe storage (highest density in the cloud). Up to 2x vCPUs and memory vs. prior generation.
  • Storage Optimized I8g – Graviton4-powered with 3rd generation Nitro SSDs, up to 45 TB. 65% better performance per TB and 60% lower latency variability vs. I4g (December 2024).
  • Storage Optimized I8ge – Up to 120 TB NVMe with 3rd gen Nitro SSDs. 55% better performance per TB and 75% lower I/O latency variability vs. Im4gn (August 2025).

AWS Nitro SSDs

  • AWS Nitro SSDs are custom-built by AWS specifically for cloud-scale storage workloads.
  • Provide high I/O performance, low latency, minimal latency variability, and security with always-on encryption.
  • Currently in 3rd generation, used in I8g and I8ge instance types.
  • PCIe Gen5-based Nitro SSDs are used in I7i and I7ie instances.
  • Combined with the AWS Nitro System (6th generation Nitro Cards), these offload CPU virtualization, storage, and networking functions to dedicated hardware.

EBS vs Instance Store

Refer blog post @ EBS vs Instance Store

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. Please select the most correct answer regarding the persistence of the Amazon Instance Store
    1. The data on an instance store volume persists only during the life of the associated Amazon EC2 instance
    2. The data on an instance store volume is lost when the security group rule of the associated instance is changed.
    3. The data on an instance store volume persists even after associated Amazon EC2 instance is deleted
  2. A user has launched an EC2 instance from an instance store backed AMI. The user has attached an additional instance store volume to the instance. The user wants to create an AMI from the running instance. Will the AMI have the additional instance store volume data?
    1. Yes, the block device mapping will have information about the additional instance store volume
    2. No, since the instance store backed AMI can have only the root volume bundled
    3. It is not possible to attach an additional instance store volume to the existing instance store backed AMI instance
    4. No, since this is ephemeral storage it will not be a part of the AMI
  3. When an EC2 instance that is backed by an S3-based AMI Is terminated, what happens to the data on the root volume?
    1. Data is automatically saved as an EBS volume.
    2. Data is automatically saved as an EBS snapshot.
    3. Data is automatically deleted
    4. Data is unavailable until the instance is restarted.
  4. A user has launched an EC2 instance from an instance store backed AMI. If the user restarts the instance, what will happen to the ephemeral storage data?
    1. All the data will be erased but the ephemeral storage will stay connected
    2. All data will be erased and the ephemeral storage is released
    3. It is not possible to restart an instance launched from an instance store backed AMI
    4. The data is preserved
  5. When an EC2 EBS-backed instance is stopped, what happens to the data on any ephemeral store volumes?
    1. Data will be deleted and will no longer be accessible
    2. Data is automatically saved in an EBS volume.
    3. Data is automatically saved as an EBS snapshot
    4. Data is unavailable until the instance is restarted
  6. A user has launched an EC2 Windows instance from an instance store backed AMI. The user has also set the Instance initiated shutdown behavior to stop. What will happen when the user shuts down the OS?
    1. It will not allow the user to shutdown the OS when the shutdown behavior is set to Stop
    2. It is not possible to set the termination behavior to Stop for an Instance store backed AMI instance
    3. The instance will stay running but the OS will be shutdown
    4. The instance will be terminated
  7. Which of the following will occur when an EC2 instance in a VPC (Virtual Private Cloud) with an associated Elastic IP is stopped and started? (Choose 2 answers)
    1. The Elastic IP will be dissociated from the instance
    2. All data on instance-store devices will be lost
    3. All data on EBS (Elastic Block Store) devices will be lost
    4. The ENI (Elastic Network Interface) is detached
    5. The underlying host for the instance is changed
  8. Which of the following statements about EC2 instance store NVMe encryption is correct? (Choose 2 answers)
    1. You can provide your own encryption key for instance store NVMe volumes
    2. Data on NVMe instance store volumes is encrypted using XTS-AES-256 cipher in hardware
    3. Encryption keys persist after the instance is terminated for data recovery
    4. Encryption keys are unique per device and destroyed when the instance stops or terminates
    5. Instance store encryption must be enabled manually via the AWS Console
  9. A company needs temporary high-performance storage with up to 120 TB capacity and the lowest possible I/O latency for a real-time analytics workload on AWS. Which EC2 instance family should they choose?
    1. R8gd instances with up to 11.4 TB NVMe storage
    2. I7i instances with up to 45 TB NVMe storage
    3. I8ge instances with up to 120 TB NVMe storage and 3rd gen Nitro SSDs
    4. C8id instances with up to 22.8 TB NVMe storage
  10. Which feature allows you to monitor NVMe instance store volume performance at 1-second granularity on Nitro-based EC2 instances?
    1. Amazon EBS CloudWatch Metrics
    2. EC2 Detailed NVMe Performance Statistics
    3. AWS CloudTrail storage events
    4. Amazon Inspector performance assessment

References

AWS EC2 Network – Enhanced Networking

~ Last updated on : ~ jayendrapatil ~ 9 Comments

EC2 Enhanced Networking

  • Enhanced networking results in higher bandwidth, higher packet per second (PPS) performance, lower latency, consistency, scalability and lower jitter
  • EC2 provides enhanced networking capabilities using single root I/O virtualization (SR-IOV) only on supported instance types
    • SR-IOV is a method of device virtualization that provides higher I/O performance and lower CPU utilization
  • There is no additional charge for using enhanced networking.
  • Enhanced networking is supported only in a VPC.
  • All current-generation instances built on the AWS Nitro System use ENA for enhanced networking by default.
  • Amazon Linux AMIs, Ubuntu HVM AMIs, and Windows Server AMIs already have the ENA module installed with the attributes set and do not require any additional configurations.
  • It can be enabled for other OS distributions by installing the module with the correct attributes configured
  • Enhanced Networking is supported using
    • Elastic Network Adapter (ENA)
      • The Elastic Network Adapter (ENA) supports network speeds of up to 200 Gbps for supported instance types (e.g., C6in, R6in, M6in instances). Some accelerated instances like P4d support up to 400 Gbps.
      • All Nitro-based instances use ENA for enhanced networking.
      • The following Xen-based instances also use ENA: H1, I3, G3, m4.16xlarge, P3, P3dn, and R4.
      • ENA is the recommended and standard adapter for all current-generation workloads.
    • Intel 82599 Virtual Function (VF) interface
      • The Intel 82599 Virtual Function interface supports network speeds of up to 10 Gbps for supported instance types.
      • Supported only on previous-generation instance types: C3, C4, D2, I2, M4 (excl. m4.16xlarge), and R3.
      • These are all previous-generation instances. AWS recommends migrating to current-generation Nitro-based instances with ENA for better performance.

ENA Express

  • ENA Express is powered by AWS Scalable Reliable Datagram (SRD) technology, a high-performance network transport protocol.
  • ENA Express increases the maximum single flow bandwidth from 5 Gbps up to 25 Gbps within the same Region, up to the aggregate instance limit.
  • Reduces tail latency: up to 50% reduction in P99 latency and up to 85% reduction in P99.9 latency compared to TCP.
  • Works transparently with existing TCP and UDP applications — no code changes required.
  • SRD distributes packets across different network paths and dynamically adjusts when congestion is detected.
  • Handles packet reordering on the receiving end and most retransmits in the network layer.
  • Cross-AZ support (May 2026): ENA Express now supports traffic between instances in different Availability Zones within the same Region, delivering up to 25 Gbps single-flow bandwidth.
  • Requirements:
    • Both sending and receiving instances must be supported instance types.
    • Both instances must have ENA Express enabled on their network interface attachment.
    • The network path must not include middleware boxes.
    • Linux instances require ENA driver version 2.2.9 or higher for full bandwidth; version 2.8+ for metrics.
  • ENA Express is available on supported 6th generation and later instance types (e.g., m6i, m6a, c6i, r6i, and newer).
  • If ENA Express is not supported on both ends, communication falls back to standard ENA transmission.
  • Note: For workloads requiring high packets-per-second with lowest latency during uncongested periods, standard enhanced networking (without ENA Express) may be more appropriate.

Elastic Fabric Adapter (EFA)

  • An Elastic Fabric Adapter (EFA) is a network device for Amazon EC2 instances to accelerate AI/ML, and High Performance Computing (HPC) applications.
  • EFA provides lower and more consistent latency and higher throughput than TCP transport for inter-instance communication.
  • Supports Message Passing Interface (MPI) for HPC and NVIDIA Collective Communications Library (NCCL) for ML workloads, scaling to thousands of cores or GPUs.
  • Available as an optional EC2 networking feature at no additional cost on supported instance types.
  • EFA uses OS-bypass capabilities to provide low-latency, high-bandwidth RDMA-like networking.
  • EFA decoupled from ENA (October 2024): AWS introduced a new interface type that decouples EFA from ENA, enabling dedicated high-bandwidth, low-latency networking crucial for scaling AI/ML workloads.
  • EFA-only interfaces (June 2026): Amazon SageMaker HyperPod supports EFA-only network interfaces without ENA for IP networking, enabling dedicated accelerator networking.
  • Supported on instances like P4d (400 Gbps), P5, Trn1, Trn2, Hpc6a, Hpc7a, Hpc7g (200 Gbps), and others.
  • EFA is ideal for tightly coupled workloads requiring high internode communication bandwidth.

ENA Enhanced Networking Requirements

  • Instance must be in a VPC (EC2-Classic was fully retired in August 2023)
  • An HVM virtualization type AMI
  • Instance must be based on the Nitro System (for current-generation instances)
  • For Xen-based instances (H1, I3, G3, m4.16xlarge, P3, R4): must have ENA module installed and enaSupport attribute enabled
  • Supported instance types: All Nitro-based instances (5th generation and later: C5, M5, R5, C6i, M6i, R6i, C7g, M7g, R7g, C8g, M8g, etc.)
  • Enhanced networking cannot be managed from the Amazon EC2 console — use AWS CLI or CloudShell

Intel 82599 VF Enhanced Networking Requirements (Previous Generation)

  • VPC (EC2-Classic was fully retired in August 2023)
  • An HVM virtualization type AMI
  • Instance kernel version
    • Linux kernel version of 2.6.32+
    • Windows: Server 2008 R2+
  • Appropriate Virtual Function (VF) driver
    • Linux – should have the ixgbevf module installed and that sriovNetSupport attribute set for the instance
    • Windows – Intel 82599 Virtual Function driver
  • Supported instance types (previous generation only): C3, C4, D2, I2, M4 (excl. m4.16xlarge), and R3.
  • Note: AWS recommends migrating to current-generation Nitro-based instances with ENA for significantly better networking performance (up to 200 Gbps vs. 10 Gbps).

Enhanced Networking vs. ENA Express vs. EFA

  • Enhanced Networking (ENA/VF): Higher PPS, lower latency, lower jitter using SR-IOV. Available on all Nitro instances. Best for general workloads requiring consistent network performance.
  • ENA Express: Uses SRD protocol on top of ENA. Increases single-flow bandwidth to 25 Gbps and significantly reduces tail latency. Best for workloads with large data transfers or latency-sensitive applications. Available on 6th gen+ instances.
  • Elastic Fabric Adapter (EFA): Network device providing OS-bypass RDMA-like capabilities. Best for HPC (MPI) and AI/ML (NCCL) workloads requiring ultra-low latency inter-node communication. Available on specific compute/GPU 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. You have multiple Amazon EC2 instances running in a cluster across multiple Availability Zones within the same region. What combination of the following should be used to ensure the highest network performance (packets per second), lowest latency, and lowest jitter? Choose 3 answers
    1. Amazon EC2 placement groups (Cluster placement groups are within a single AZ, would not work for multiple AZs)
    2. Enhanced networking (provides network performance, lowest latency)
    3. Amazon PV AMI (Requires HVM)
    4. Amazon HVM AMI (Requires HVM)
    5. Amazon Linux (Can be on others as well)
    6. Amazon VPC (works only in VPC; EC2-Classic was retired August 2023)
  2. A group of researchers is studying the migration pattern of a beetle that eats and destroys grain. The researchers must process massive amounts of data and run statistics. Which one of the following options provides the high performance computing for this purpose.
    1. Configure an Autoscaling Scaling group to launch dozens of spot instances to run the statistical analysis simultaneously
    2. Launch AMI instances that support SR-IOV in a single Availability Zone
    3. Launch compute optimized (C4) instances in at least two Availability Zones
    4. Launch enhanced network type instances in a placement group
  3. A company is running a latency-sensitive financial trading application on EC2 instances. They need to maximize single-flow bandwidth between two instances in the same Availability Zone. Which feature should they enable?
    1. Enhanced networking with Intel 82599 VF
    2. Elastic Fabric Adapter (EFA)
    3. ENA Express (ENA Express uses SRD to increase single-flow bandwidth from 5 Gbps to 25 Gbps and reduces tail latency)
    4. Placement group with standard ENA
  4. A machine learning team needs to scale their distributed training workload across hundreds of GPU instances with the lowest possible inter-node latency. Which networking feature is most appropriate?
    1. ENA Express with SRD protocol
    2. Enhanced networking with cluster placement groups
    3. Elastic Fabric Adapter (EFA) (EFA provides OS-bypass, RDMA-like capabilities optimized for MPI and NCCL workloads at scale)
    4. Multiple Elastic Network Interfaces
  5. Which of the following statements about ENA Express are correct? (Choose 2)
    1. ENA Express uses AWS Scalable Reliable Datagram (SRD) protocol to improve network performance (Correct – SRD is the underlying protocol)
    2. ENA Express requires application code changes to work
    3. ENA Express only works with TCP traffic
    4. ENA Express can increase single-flow bandwidth from 5 Gbps up to 25 Gbps (Correct – major benefit of ENA Express)
  6. A company wants to migrate from C3 instances to improve network performance. Which statement is correct regarding the migration?
    1. C3 instances support ENA with speeds up to 100 Gbps
    2. C3 instances use Intel 82599 VF (up to 10 Gbps) and should be migrated to current-generation Nitro instances with ENA for up to 200 Gbps (C3 is previous gen with VF; current gen instances offer significantly better networking)
    3. C3 instances cannot use enhanced networking
    4. C3 instances already support ENA Express

References

AWS EC2 Monitoring – CloudWatch Metrics & Alarms

~ Last updated on : ~ jayendrapatil ~ 8 Comments

EC2 Monitoring

Status Checks

  • Status monitoring helps quickly determine whether EC2 has detected any problems that might prevent instances from running applications.
  • EC2 performs automated checks on every running EC2 instance to identify hardware and software issues.
  • Status checks are performed every minute and each returns a pass or a fail status.
  • If all checks pass, the overall status of the instance is OK.
  • If one or more checks fail, the overall status is Impaired.
  • Status checks are built into EC2, so they cannot be disabled or deleted.
  • There are three types of status checks:
    • System status checks
    • Instance status checks
    • Attached EBS status checks
  • Status checks data augments the information that EC2 already provides about the intended state of each instance (such as pending, running, and stopping) as well as the utilization metrics that CloudWatch monitors (CPU utilization, network traffic, and disk activity).
  • Alarms can be created or deleted, that are triggered based on the result of the status checks. for e.g., an alarm can be created to warn if status checks fail on a specific instance.

System Status Checks

  • monitor the AWS systems, required to use the instance, to ensure they are working properly.
  • detect problems with the instance that require AWS involvement to repair.
  • System status checks failure might due to
    • Loss of network connectivity
    • Loss of system power
    • Software issues on the physical host
    • Hardware issues on the physical host
  • When a system status check fails, one can either
    • check AWS Health Dashboard for any scheduled critical maintenance by AWS to the instance’s host.
    • wait for AWS to fix the issue
    • or resolve it by stopping and restarting or terminating and replacing an instance

Instance Status Checks

  • monitor the software and network configuration of the individual instance
  • checks to detect problems that require involvement to repair.
  • Instance status checks failure might be due to
    • Failed system status checks
    • Misconfigured networking or startup configuration
    • Exhausted memory
    • Corrupted file system
    • Incompatible kernel
  • When an instance status check fails, it can be resolved by either rebooting the instance or by making modifications to the operating system

Attached EBS Status Checks

  • monitor whether the EBS volumes attached to an instance are reachable and able to complete I/O operations.
  • available for Nitro-based instances only.
  • helps detect issues where the instance cannot communicate with one or more attached EBS volumes.
  • Attached EBS status check failure might be due to
    • Hardware or software issues on the storage subsystem underlying the EBS volume
    • Hardware issues on the physical host impacting reachability to EBS
  • The metric StatusCheckFailed_AttachedEBS is available at a 1-minute frequency at no additional charge.
  • Can be used with CloudWatch alarms and Auto Scaling health checks to replace instances with impaired EBS volumes.

EC2 Instance Recovery

  • Simplified Automatic Recovery
    • enabled by default during instance launch on supported instances.
    • automatically moves the instance from the impaired host to a different host when a system status check failure is detected.
    • recovered instance is identical to the original (instance ID, private IP, Elastic IP, metadata, placement group).
    • does not require a CloudWatch alarm to be configured.
    • works only for system status check failures, not for instance status check failures.
    • available for over 90% of deployed EC2 instances.
  • CloudWatch Action Based Recovery
    • can be configured optionally after instance launch using CloudWatch alarms.
    • provides the ability to set a recovery action on a CloudWatch alarm monitoring the StatusCheckFailed_System metric.
    • provides more granular control over recovery conditions and notification.

CloudWatch Monitoring

  • CloudWatch helps monitor EC2 instances, which collects and processes
    raw data from EC2 into readable, near real-time metrics.
  • Statistics are recorded for a period of two weeks so that historical information can be accessed and used to gain a better perspective on how
    the application or service is performing.
  • By default, Basic monitoring is enabled and EC2 metric data is sent to CloudWatch in 5-minute periods automatically
  • Detailed monitoring can be enabled on the EC2 instance, which sends data to CloudWatch in 1-minute periods.
  • Organization-wide Detailed Monitoring Enablement (2026)
    • CloudWatch Ingestion enablement rules can automatically enable detailed monitoring for both existing and newly launched EC2 instances matching the rule scope.
    • Ensures consistent 1-minute metrics collection across EC2 instances at the organization or account level.
  • Aggregating Statistics Across Instances/ASG/AMI ID
    • Aggregate statistics are available for the instances that have detailed monitoring (at an additional charge) enabled, which provides data in 1-minute periods
    • Instances that use basic monitoring are not included in the aggregates.
    • CloudWatch does not aggregate data across Regions. Therefore, metrics are completely separate between regions.
    • CloudWatch returns statistics for all dimensions in the AWS/EC2 namespace if no dimension is specified
    • The technique for retrieving all dimensions across an AWS namespace does not work for custom namespaces published to CloudWatch.
    • Statistics include Sum, Average, Minimum, Maximum, Data Samples
    • With custom namespaces, the complete set of dimensions that are associated with any given data point to retrieve statistics that include the data point must be specified
  • CloudWatch alarms
    • can be created to monitor any one of the EC2 instance’s metrics.
    • can be configured to automatically send you a notification when the metric reaches a specified threshold.
    • can automatically stop, terminate, reboot, or recover EC2 instances
    • can automatically recover an EC2 instance when the instance becomes impaired due to an underlying hardware failure or a problem that requires AWS involvement to repair
    • can automatically stop or terminate the instances to save costs (EC2 instances that use an EBS volume as the root device can be stopped
      or terminated, whereas instances that use the instance store as the root device can only be terminated)
    • can use EC2ActionsAccess IAM role, which enables AWS to perform stop, terminate, or reboot actions on EC2 instances
    • If you have read/write permissions for CloudWatch but not for EC2, alarms can still be created but the stop or terminate actions won’t be performed on the EC2 instance
    • Composite Alarms can combine multiple metric alarms into a single alarm for aggregated health, but cannot perform EC2 actions directly.

CloudWatch Agent

  • The unified CloudWatch agent collects system-level metrics and logs from EC2 instances that are not available through the default hypervisor-level metrics.
  • Key OS-level metrics collected by the agent include:
    • Memory utilization (mem_used_percent)
    • Disk usage (disk_used_percent)
    • Swap usage
    • Process-level metrics (procstat)
  • EC2 does NOT provide memory or disk usage metrics by default — these require the CloudWatch agent.
  • Can be installed and managed via AWS Systems Manager (SSM).
  • Configuration is stored in a JSON file or as an SSM Parameter Store parameter.
  • Metrics collected by the CloudWatch agent are billed as custom metrics.
  • In-Console Agent Management (2025/2026)
    • CloudWatch provides visibility into agent status across the EC2 fleet directly in the console.
    • Automatic detection of supported workloads and recommended monitoring configurations.
    • Visual configuration editor for the agent eliminates the need to hand-edit JSON (April 2026).

EC2 Monitoring Metrics

Instance Metrics

  • CPUUtilization
    • % of physical CPU time that EC2 uses to run the instance, including time spent running both user code and EC2 code.
    • At a very high level, CPUUtilization is the sum of guest CPUUtilization and hypervisor CPUUtilization.
  • DiskReadOps
    • Completed read operations from all instance store volumes available to the instance in a specified period of time.
    • If there are no instance store volumes, the value is 0 or the metric is not reported.
  • DiskWriteOps
    • Completed write operations to all instance store volumes available to the instance in a specified period of time.
    • If there are no instance store volumes, the value is 0 or the metric is not reported.
  • DiskReadBytes
    • Bytes read from all instance store volumes available to the instance.
    • This metric is used to determine the volume of the data the application reads from the hard disk of the instance.
  • DiskWriteBytes
    • Bytes written to all instance store volumes available to the instance.
    • This metric is used to determine the volume of the data the application writes onto the hard disk of the instance.
  • MetadataNoToken
    • The number of times the Instance Metadata Service (IMDS) was successfully accessed using a method that does not use a token (IMDSv1).
    • Used to determine if there are any processes accessing instance metadata using IMDSv1, which is less secure than IMDSv2.
    • If all requests use token-backed sessions (IMDSv2), the value is 0.
  • MetadataNoTokenRejected
    • The number of times an IMDSv1 call was attempted after IMDSv1 was disabled on the instance.
    • Indicates that software on the instance still attempts IMDSv1 calls and needs updating.
  • NetworkIn
    • The number of bytes received on all network interfaces by the instance. This metric identifies the volume of incoming network traffic to an application on a single instance.
  • NetworkOut
    • The number of bytes sent out on all network interfaces by the instance. This metric identifies the volume of outgoing network traffic from a single instance.
  • NetworkPacketsIn
    • The number of packets received on all network interfaces by the instance.
    • This metric is available for basic monitoring only (5-minute periods).
  • NetworkPacketsOut
    • The number of packets sent out on all network interfaces by the instance.
    • This metric is available for basic monitoring only (5-minute periods).

CPU Credit Metrics (Burstable Performance Instances)

  • Applicable to all burstable performance instances (T2, T3, T3a, T4g) — not just T2.
  • CPU Credit metrics are available at a 5-minute frequency only.
  • CPUCreditUsage
    • The number of CPU credits spent by the instance for CPU utilization.
    • One CPU credit equals one vCPU running at 100% utilization for one minute.
  • CPUCreditBalance
    • The number of earned CPU credits that an instance has accrued since it was launched or started.
    • For T2 Standard, also includes the number of launch credits accrued.
    • When a T3/T3a instance stops, the CPUCreditBalance persists for seven days. When a T2 instance stops, credits are lost.
    • Used to determine how long an instance can burst beyond its baseline performance level.
  • CPUSurplusCreditBalance (Unlimited mode only)
    • The number of surplus credits spent when the CPUCreditBalance is zero.
    • Surplus credits are paid down by earned CPU credits.
    • If surplus credits exceed the maximum earnable in a 24-hour period, additional charges apply.
  • CPUSurplusCreditsCharged (Unlimited mode only)
    • The number of surplus credits that are not paid down and incur an additional charge.
    • Charged when surplus credits exceed 24-hour maximum, instance is stopped/terminated, or switched from unlimited to standard mode.

Amazon EBS Metrics for Nitro-based Instances

  • Available for EBS volumes attached to Nitro-based instances (non-bare-metal).
  • EBSReadOps / EBSWriteOps – Completed read/write operations from all attached EBS volumes.
  • EBSReadBytes / EBSWriteBytes – Bytes read from/written to all attached EBS volumes.
  • EBSIOBalance%
    • Percentage of I/O credits remaining in the burst bucket.
    • Available for basic monitoring only.
    • Available for some *.4xlarge and smaller instance sizes that burst to maximum performance for 30 minutes every 24 hours.
  • EBSByteBalance%
    • Percentage of throughput credits remaining in the burst bucket.
    • Available for basic monitoring only.
    • Available for some *.4xlarge and smaller instance sizes that burst to maximum performance for 30 minutes every 24 hours.
  • InstanceEBSIOPSExceededCheck
    • Reports whether the application attempted to drive IOPS exceeding the maximum EBS IOPS limits for the instance.
    • Values: 0 (not exceeded) or 1 (exceeded).
  • InstanceEBSThroughputExceededCheck
    • Reports whether the application attempted to drive throughput exceeding the maximum EBS throughput limits for the instance.
    • Values: 0 (not exceeded) or 1 (exceeded).

Status Check Metrics

  • Available at a 1-minute frequency at no charge by default.
  • StatusCheckFailed
    • Reports if either of the status checks has failed.
    • Values: 0 (passed) or 1 (failed).
  • StatusCheckFailed_Instance
    • Reports whether the instance has passed the EC2 instance status check in the last minute.
    • Values: 0 (passed) or 1 (failed).
  • StatusCheckFailed_System
    • Reports whether the instance has passed the EC2 system status check in the last minute.
    • Values: 0 (passed) or 1 (failed).
  • StatusCheckFailed_AttachedEBS
    • Reports whether the instance has passed the attached EBS status check in the last minute.
    • Values: 0 (passed) or 1 (failed).
    • Available for Nitro-based instances only.

Accelerator Metrics

  • GPUPowerUtilization
    • Active power usage as a percentage of maximum active power.
    • Available for supported accelerated computing instances only.

CloudWatch Network Flow Monitor

  • Launched at re:Invent 2024 as part of CloudWatch Network Monitoring.
  • Provides near real-time visibility into network performance (packet loss and latency) for traffic between EC2 instances, EKS workloads, and AWS services (S3, DynamoDB).
  • Uses fully-managed agents installed on EC2 instances to collect TCP-based performance metrics.
  • Agents send aggregated metrics to the backend approximately every 30 seconds.
  • Top contributors feature identifies network flows with the highest retransmissions or latency to help pinpoint impairments.
  • Supports multi-account monitoring via AWS Organizations integration.

EC2 Metric Dimensions

  • InstanceId – Filters data for a specific instance.
  • InstanceType – Filters data for all instances of a specific type (requires Detailed Monitoring).
  • ImageId (AMI ID) – Filters data for all instances running a specific AMI (requires Detailed Monitoring).
  • AutoScalingGroupName – Filters data for all instances in a specified Auto Scaling group.

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. In the basic monitoring package for EC2, Amazon CloudWatch provides the following metrics:
    1. Web server visible metrics such as number failed transaction requests
    2. Operating system visible metrics such as memory utilization
    3. Database visible metrics such as number of connections
    4. Hypervisor visible metrics such as CPU utilization
  2. Which of the following requires a custom CloudWatch metric to monitor?
    1. Memory Utilization of an EC2 instance
    2. CPU Utilization of an EC2 instance
    3. Disk usage activity of an EC2 instance
    4. Data transfer of an EC2 instance
  3. A user has configured CloudWatch monitoring on an EBS backed EC2 instance. If the user has not attached any additional device, which of the below mentioned metrics will always show a 0 value?
    1. DiskReadBytes
    2. NetworkIn
    3. NetworkOut
    4. CPUUtilization
  4. A user is running a batch process on EBS backed EC2 instances. The batch process starts a few instances to process Hadoop Map reduce jobs, which can run between 50 – 600 minutes or sometimes for more time. The user wants to configure that the instance gets terminated only when the process is completed. How can the user configure this with CloudWatch?
    1. Setup the CloudWatch action to terminate the instance when the CPU utilization is less than 5%
    2. Setup the CloudWatch with Auto Scaling to terminate all the instances
    3. Setup a job which terminates all instances after 600 minutes
    4. It is not possible to terminate instances automatically
  5. An AWS account owner has setup multiple IAM users. One IAM user only has CloudWatch access. He has setup the alarm action, which stops the EC2 instances when the CPU utilization is below the threshold limit. What will happen in this case?
    1. It is not possible to stop the instance using the CloudWatch alarm
    2. CloudWatch will stop the instance when the action is executed
    3. The user cannot set an alarm on EC2 since he does not have the permission
    4. The user can setup the action but it will not be executed if the user does not have EC2 rights
  6. A user has launched 10 instances from the same AMI ID using Auto Scaling. The user is trying to see the average CPU utilization across all instances of the last 2 weeks under the CloudWatch console. How can the user achieve this?
    1. View the Auto Scaling CPU metrics (Refer AS Instance Monitoring)
    2. Aggregate the data over the instance AMI ID (Works but needs detailed monitoring enabled)
    3. The user has to use the CloudWatch analyser to find the average data across instances
    4. It is not possible to see the average CPU utilization of the same AMI ID since the instance ID is different
  7. Which EC2 status check type monitors whether the EBS volumes attached to a Nitro-based instance are reachable?
    1. System status check
    2. Instance status check
    3. Attached EBS status check
    4. Volume status check
  8. An organization wants to monitor memory utilization of their EC2 instances. Which approach should they use?
    1. Enable detailed monitoring on the instances
    2. Install the unified CloudWatch agent and configure memory metrics
    3. Use the default CloudWatch EC2 metrics
    4. Enable enhanced monitoring on the instances
  9. Which CloudWatch metric can help identify if an EC2 instance is still using the less secure IMDSv1 to access instance metadata?
    1. StatusCheckFailed_Instance
    2. MetadataNoToken
    3. CPUCreditBalance
    4. NetworkPacketsIn
  10. A company wants to ensure all EC2 instances across their AWS Organization have detailed monitoring enabled. What is the most efficient approach? [Select 2]
    1. Manually enable detailed monitoring on each instance
    2. Create CloudWatch Ingestion enablement rules scoped to the organization
    3. Use enablement rules to automatically enable detailed monitoring for existing and new instances
    4. Use AWS Config rules to detect and auto-remediate

References

AWS EC2 Spot Instances – Pricing & Interruption

~ Last updated on : ~ jayendrapatil

Spot Instances

  • EC2 Spot instances allow access to spare EC2 computing capacity at up to 90% off the On-Demand price.
  • Spot Instance prices are set by Amazon EC2 and adjust gradually based on long-term trends in supply and demand for Spot Instance capacity, but never exceed On-Demand prices.
  • Spot Instances can be interrupted by EC2 when EC2 needs the capacity back with a two-minute notification.
  • Spot instances are a cost-effective choice and can bring the EC2 costs down significantly.
  • Spot instances can be used for applications flexible in the timing when they can run and also able to handle interruption by storing the state externally for e.g. they are well-suited for data analysis, batch jobs, background processing, and optional tasks
  • The only difference between an On-Demand Instance and a Spot Instance is that a Spot Instance can be interrupted by Amazon EC2, with two minutes of notice, when EC2 needs the capacity back.
  • Usual strategy involves using Spot instances with On-Demand or Reserved Instances, which provide a minimum level of guaranteed compute resources, while spot instances provide an additional computation boost.
  • Spot instances can also be launched with a required duration (also known as Spot blocks), which are not interrupted due to changes in the Spot price.
  • Spot Blocks (Defined Duration) have been discontinued. Spot Blocks were not available to new customers from July 1, 2021, and support ended entirely on December 31, 2022.
  • EC2 provides a data feed, sent to an S3 bucket specified during subscription, that describes the Spot instance usage and pricing.
  • Spot Instances are not suitable for workloads that are inflexible, stateful, fault-intolerant, or tightly coupled between instance nodes.
  • Well Suited for
    • Ideal for various stateless, fault-tolerant, or flexible applications such as big data, containerized workloads, CI/CD, high-performance computing (HPC), stateless web servers, image and media rendering, machine learning, and other test & development workloads
    • Applications that have flexible start and end times
    • Applications that are only feasible at very low compute prices
    • Users with urgent computing needs for large amounts of additional capacity

Spot Concepts

  • Spot capacity pool – A set of unused EC2 instances with the same instance type (for example, m5.large), operating system, Availability Zone, and network platform.
  • Spot price – Current price of a Spot Instance per hour, set by Amazon EC2 and adjusting gradually based on long-term trends in supply and demand. Spot prices never exceed On-Demand prices.
  • Spot Instance request
    • Provides the maximum price per hour that you are willing to pay for a Spot Instance. If unspecified, it defaults to the On-Demand price.
    • EC2 fulfils the request when the maximum price per hour for the request exceeds the Spot price and if capacity is available.
    • A Spot Instance request is either one-time or persistent.
    • EC2 automatically resubmits a persistent Spot request after the Spot Instance associated with the request is terminated.
  • Spot Instance interruption – EC2 terminates, stops, or hibernates the Spot Instance when capacity is no longer available. EC2 provides a Spot Instance interruption notice, which gives the instance a two-minute warning before it is interrupted.
  • EC2 Instance Rebalance Recommendation is a signal that notifies when a Spot Instance is at elevated risk of interruption. The signal provides an opportunity to proactively manage the Spot Instance in advance of the two-minute Spot Instance interruption notice.
  • Spot placement score – indicates how likely it is that a Spot request will succeed in a Region or Availability Zone, scored on a scale from 1 to 10.

Spot Pricing Model

ℹ️ Important: Since 2017, AWS uses a simplified Spot pricing model. Spot prices adjust gradually based on long-term supply and demand trends, not on a real-time bidding/auction system. You no longer need to analyze historical prices or determine bidding strategies. Typical savings are 70-90% over On-Demand prices.

  • Spot Instance prices are set by Amazon EC2 and adjust gradually based on long-term trends in supply and demand for Spot Instance capacity.
  • Spot prices never exceed On-Demand prices.
  • You can specify a maximum price when requesting Spot Instances. If unspecified, it defaults to the On-Demand price.
  • EC2 fulfils the request when the maximum price per hour exceeds the Spot price and capacity is available.
  • Everyone pays the same Spot price for the period irrespective of the maximum price specified, given the maximum price is more than the Spot price.
  • EC2 can interrupt the Spot Instance when the demand for Spot instances rises or when the supply of Spot instances decreases.
  • When EC2 interrupts a Spot Instance, it provides a two-minute warning before interruption.
  • Termination notice warning is made available via:
    • Instance metadata: http://169.254.169.254/latest/meta-data/spot/termination-time
    • Amazon EventBridge event: EC2 Spot Instance Interruption Warning
  • Applications on Spot Instances should poll for the termination notice at 5-second intervals or use EventBridge for event-driven handling.
  • EBS-backed Spot Instance can be stopped, started, rebooted, or terminated.

Spot Instance Billing

  • Spot Instances use per-second billing (with a minimum of 60 seconds) for Linux and Windows instances.
  • If Amazon EC2 interrupts the Spot Instance in the first hour, you are not charged for the usage.
  • If Amazon EC2 interrupts the Spot Instance after the first hour, you are charged for the seconds used.
  • If you stop or terminate the Spot Instance, you are charged for the seconds used (even in the first hour).
  • While an interrupted Spot Instance is stopped, you are charged only for the EBS volumes, which are preserved.

Spot Instances Requests

  • A Spot Instance request is either
    • One-time
      • A one-time request remains active until EC2 launches the Spot Instance, the request expires, or you cancel the request.
    • Persistent
      • EC2 automatically resubmits a persistent Spot request after the Spot Instance associated with the request is terminated.
      • A persistent Spot Instance request remains active until it expires or you cancel it, even if the request is fulfilled.
      • Cancelling spot instance requests does not terminate the instances.
      • Be sure to cancel the spot request before you terminate the instances, else they would be launched again.

EC2 Spot Instance Requests

Spot Fleet and EC2 Fleet

⚠️ Spot Fleet is Legacy: AWS strongly discourages using Spot Fleet because it uses a legacy API with no planned investment. Use EC2 Fleet or EC2 Auto Scaling groups instead.

  • EC2 Fleet (Recommended)
    • Creates a fleet of both On-Demand Instances and Spot Instances in a single request.
    • Supports multiple launch specifications that vary by instance type, AMI, Availability Zone, or subnet.
    • EC2 Fleet types:
      • instant – Places a synchronous one-time request. Returns launched instances immediately. Recommended when you don’t need auto scaling.
      • request – Places an asynchronous one-time request. Does not attempt to replenish interrupted capacity.
      • maintain – Places an asynchronous request and maintains capacity by automatically replenishing interrupted Spot Instances.
  • Spot Fleet (Legacy – Not Recommended)
    • Collection of Spot Instances and optionally On-Demand Instances.
    • Attempts to launch the number of instances to meet the specified target capacity.
    • Uses a legacy API with no planned investment.

Allocation Strategies

  • priceCapacityOptimized (Recommended)
    • Requests Spot Instances from the pools that have the lowest chance of interruption AND the lowest possible price.
    • Best choice for most Spot workloads: containerized applications, microservices, web applications, data analytics, batch processing.
    • AWS recommended default strategy.
  • capacityOptimized
    • From the pools with optimal capacity for the number of instances launching.
    • Lowest risk of interruption.
  • capacityOptimizedPrioritized
    • Optimizes for capacity first, but honors instance type priorities on a best-effort basis.
    • Set priority for each instance type using the Priority parameter.
  • diversified
    • Distributed across all specified pools.
    • Good for high availability, long workloads.
  • lowestPrice (Not Recommended)
    • From the pool with the lowest price.
    • AWS does not recommend this strategy because it has the highest risk of interruption for Spot Instances.

Spot Instances Interruption

  • EC2 Instance Rebalance Recommendations and Spot Instance interruption notices can be used to gracefully handle Spot Instance interruptions.
  • EC2 Instance Rebalance Recommendation
    • Signal that notifies when a Spot Instance is at elevated risk of interruption.
    • Provides an opportunity to proactively manage the Spot Instance in advance of the two-minute interruption notice.
    • Can be monitored via Amazon EventBridge events.
    • Capacity Rebalancing feature in Auto Scaling groups and EC2 Fleet automatically acts on these signals.
  • Spot Instance Interruption Notice
    • Warning issued two minutes before EC2 interrupts a Spot Instance (except for hibernation, which begins immediately).
    • Available as an EventBridge event and in instance metadata.
  • Interruption Behavior – You can specify what happens when a Spot Instance is interrupted:
    • Terminate (default) – Instance is terminated.
    • Stop – Instance is stopped and can be restarted when capacity is available. You are charged only for EBS volumes while stopped.
    • Hibernate – Instance memory (RAM) is saved to EBS root volume. Instance resumes from where it left off when capacity is available. Hibernation begins immediately (no two-minute warning period).
  • Initiate a Spot Instance Interruption
    • You can test your application’s fault tolerance by initiating Spot Instance interruptions using AWS Fault Injection Service (AWS FIS).
    • Available directly from the Amazon EC2 console: Spot Request → Actions → Initiate interruption.
    • FIS-injected interruptions behave identically to real interruptions (including notifications and configured behaviors).

Spot Placement Score

  • Indicates how likely it is that a Spot request will succeed in a Region or Availability Zone.
  • Scored on a scale from 1 to 10 (10 = highly likely to succeed, 1 = not likely to succeed).
  • Recommends optimal Regions or Availability Zones based on capacity requirements and instance type specifications.
  • A point-in-time recommendation — capacity can vary over time. It does not guarantee available capacity or predict interruption risk.
  • Best for workloads that are flexible about instance types and Region/AZ.
  • Available via Amazon EC2 console, AWS CLI, or SDKs.

Attribute-Based Instance Type Selection

  • Specify instance attributes (vCPUs, memory, storage, network throughput) rather than specific instance types.
  • EC2 Auto Scaling or EC2 Fleet automatically identifies and launches matching instances.
  • Automatically uses newly released instance types as they become available.
  • Removes the effort of manually selecting specific instance types.
  • Provides access to an increasingly broad range of Spot Instance capacity, reducing interruption risk.
  • Ideal for workloads that can be flexible about instance types: HPC, big data, containerized workloads.

Which is the Best Spot Request Method?

  • CreateAutoScalingGroup (Recommended)
    • Use when you need multiple instances and want automated lifecycle management.
    • Supports horizontal scaling between specified minimum and maximum limits.
    • Best for most workloads that need Spot Instances.
  • CreateFleet (EC2 Fleet) (Recommended)
    • Use when you need multiple instances but want to self-manage instance lifecycle.
    • Creates both On-Demand and Spot Instances in a single request.
    • Use instant mode if you don’t need auto scaling.
  • RunInstances
    • Use if already using RunInstances for On-Demand and want to switch to Spot.
    • Does not allow mixed instance types in a single request.
  • RequestSpotFleet – Legacy. DO NOT USE. No planned investment.
  • RequestSpotInstances – Legacy. DO NOT USE. No planned investment.

Spot Instances vs On-Demand Instances

Spot Instances vs On-Demand Instances

Spot Instances Best Practices

  • Be flexible about instance types and Availability Zones
    • Be flexible across at least 10 instance types for each workload.
    • Include larger instance types (for vertical scaling) and older generation types (less demand from On-Demand customers).
    • Ensure all Availability Zones are configured for use in your VPC.
  • Use attribute-based instance type selection
    • Specify attributes (vCPUs, memory) instead of specific instance types.
    • Automatically uses new instance types as they become available.
  • Use Spot placement scores
    • Identify optimal Regions and Availability Zones before launching.
  • Use EC2 Auto Scaling groups or EC2 Fleet to manage aggregate capacity
    • Think in terms of aggregate capacity (vCPUs, memory, throughput) rather than individual instances.
    • These services automatically request resources to replace interrupted instances.
  • Use the price-capacity-optimized allocation strategy
    • Automatically provisions instances from pools that are least likely to be interrupted AND have the lowest price.
    • Recommended strategy for most Spot workloads.
  • Prepare individual instances for interruptions
    • Make applications fault-tolerant. Store important data externally (S3, EBS, DynamoDB).
    • Use EventBridge rules to capture rebalance recommendations and interruption notices.
    • Configure Spot Instances to stop or hibernate instead of terminate if workload is time-flexible.
  • Use Proactive Capacity Rebalancing
    • Proactively augments fleet with new Spot Instances before a running instance receives the two-minute interruption notice.
    • Auto Scaling or EC2 Fleet replaces instances that have received a rebalance recommendation.
    • Complements the capacity-optimized allocation strategy and mixed instances policy.
  • Test interruption handling with AWS FIS
    • Use AWS Fault Injection Service to simulate Spot interruptions.
    • Verify application handles unexpected termination gracefully.
  • Use integrated AWS services
    • Amazon EMR, Amazon ECS, AWS Batch, Amazon EKS, Amazon SageMaker, AWS Elastic Beanstalk, Amazon GameLift Servers all integrate with Spot.

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. You have a video transcoding application running on Amazon EC2. Each instance polls a queue to find out which video should be transcoded, and then runs a transcoding process. If this process is interrupted, the video will be transcoded by another instance based on the queuing system. You have a large backlog of videos, which need to be transcoded, and would like to reduce this backlog by adding more instances. You will need these instances only until the backlog is reduced. Which type of Amazon EC2 instances should you use to reduce the backlog in the most cost efficient way?
    1. Reserved instances
    2. Spot instances
    3. Dedicated instances
    4. On-demand instances
  2. You have a distributed application that periodically processes large volumes of data across multiple Amazon EC2 Instances. The application is designed to recover gracefully from Amazon EC2 instance failures. You are required to accomplish this task in the most cost-effective way. Which of the following will meet your requirements?
    1. Spot Instances
    2. Reserved instances
    3. Dedicated instances
    4. On-Demand instances
  3. A company runs a fault-tolerant batch processing workload on EC2 instances. The workload can be interrupted and resumed. Which allocation strategy should be used with EC2 Fleet to minimize cost while reducing interruptions?
    1. lowestPrice
    2. capacityOptimized
    3. priceCapacityOptimized
    4. diversified
  4. A company wants to run Spot Instances for a containerized workload. They need to identify which AWS Region is most likely to have available Spot capacity for their required instance types. Which feature should they use?
    1. Spot Instance Advisor
    2. Spot placement score
    3. EC2 Fleet instant mode
    4. Capacity Reservations
  5. A company uses Spot Instances for a stateless web application. They want to be notified before interruption so they can gracefully drain connections. Which TWO signals can they use? (Choose 2)
    1. EC2 Instance Rebalance Recommendation
    2. Spot Instance interruption notice (two-minute warning)
    3. CloudWatch CPU alarm
    4. Auto Scaling lifecycle hook
  6. Which of the following is the AWS recommended method for launching and managing Spot Instances for workloads that require auto scaling?
    1. RequestSpotInstances API
    2. Spot Fleet (RequestSpotFleet API)
    3. EC2 Auto Scaling group (CreateAutoScalingGroup API)
    4. RunInstances API with Spot market options
  7. A Spot Instance is interrupted by Amazon EC2 within the first hour of launch. How is the customer billed for Linux instances?
    1. Charged for the full hour
    2. Charged for seconds used
    3. No charge
    4. Charged at 50% of the Spot price
  8. A company wants to test how their application handles Spot Instance interruptions. Which AWS service allows them to simulate Spot interruptions?
    1. AWS CloudWatch
    2. AWS Config
    3. AWS Fault Injection Service (AWS FIS)
    4. AWS Systems Manager

References

AWS Compute Services Cheat Sheet – EC2, Lambda, ECS

~ Last updated on : ~ jayendrapatil ~ 22 Comments

AWS Compute Services Cheat Sheet

AWS Compute Services

Elastic Cloud Compute – EC2

  • provides scalable computing capacity
  • Features
    • Virtual computing environments, known as EC2 instances
    • Preconfigured templates for EC2 instances, known as Amazon Machine Images (AMIs), that package the bits needed for the server (including the operating system and additional software)
    • Various configurations of CPU, memory, storage, and networking capacity for your instances, known as Instance types
    • Secure login information for your instances using key pairs (public-private keys where private is kept by user)
    • Storage volumes for temporary data that’s deleted when you stop or terminate your instance, known as Instance store volumes
    • Persistent storage volumes for data using Elastic Block Store (EBS)
    • Multiple physical locations for your resources, such as instances and EBS volumes, known as Regions and Availability Zones
    • A firewall to specify the protocols, ports, and source IP ranges that can reach your instances using Security Groups
    • Static IP addresses, known as Elastic IP addresses
    • Metadata, known as tags, can be created and assigned to EC2 resources
    • Virtual networks that are logically isolated from the rest of the AWS cloud, and can optionally connect to on-premises network, known as Virtual private clouds (VPCs)

Amazon Machine Image – AMI

    • template from which EC2 instances can be launched quickly
    • does NOT span across regions, and needs to be copied
    • can be shared with other specific AWS accounts or made public

Instance Types

  • T for applications needing general usage
    • T2 instances are Burstable Performance Instances that provide a baseline level of CPU performance with the ability to burst above the baseline.
    • T2 instances accumulate CPU Credits when they are idle, and consume CPU Credits when they are active.
    • T2 Unlimited Instances can sustain high CPU performance for as long as a workload needs it at an additional cost.
    • T4g instances are powered by AWS Graviton2 processors and provide the next generation low cost burstable general purpose instance type.
  • R for applications needing more RAM or Memory
    • R8g instances powered by Graviton4 processors deliver up to 30% better performance over Graviton3-based instances for memory-intensive workloads.
  • C for applications needing more Compute
    • C8g instances powered by Graviton4 and C8i instances powered by Intel Xeon 6 processors represent the latest generation (2024-2025).
  • M for applications needing more Medium or Moderate performance on both Memory and CPU
    • M8g instances powered by Graviton4 and M8i instances powered by Intel Xeon 6 processors are the latest generation (2024-2025).
  • I for applications needing more IOPS
  • G for applications needing more GPU
  • P for applications needing GPU-accelerated computing for ML/AI
    • P5 and P5e instances for high-performance ML training and inference workloads.
  • Graviton-based instances (suffix “g”, e.g., C8g, M8g, R8g) are powered by AWS-designed Arm processors and provide the best price performance for most workloads.

Instance Purchasing Option

  • On-Demand Instances
    • pay for instances and compute capacity that you use by the hour or second
    • no long-term commitments or up-front payments
  • Reserved Instances
    • provides lower hourly running costs by providing a billing discount (up to 72%)
    • capacity reservation is applied to instances
    • suited if consistent, heavy, predictable usage
    • provides benefits with Consolidate Billing
    • can be modified to switch Availability Zones or the instance size within the same instance type, given the instance size footprint (Normalization factor) remains the same
    • pay for the entire term regardless of the usage
    • is not a physical instance that is launched, but rather a billing discount applied to the use of On-Demand Instances
    • available in Standard and Convertible options
  • Savings Plans
    • flexible pricing model offering savings up to 72% on compute usage in exchange for a commitment to a consistent amount of usage (measured in $/hour) for a 1 or 3 year term
    • Compute Savings Plans apply to EC2, Fargate, and Lambda usage regardless of instance family, size, AZ, region, OS, or tenancy
    • EC2 Instance Savings Plans apply to a specific instance family within a region
    • recommended over Reserved Instances for new workloads due to greater flexibility
  • Scheduled Reserved Instances
    • ⚠️ Scheduled Reserved Instances are no longer available for purchase. AWS does not have capacity available and has no plans to make it available in the future. Use On-Demand Capacity Reservations instead.
  • On-Demand Capacity Reservations
    • reserve compute capacity for instances in a specific AZ for any duration
    • can be created to start immediately or scheduled for a future date
    • ensures access to EC2 capacity when needed, independent of billing discounts
    • can be combined with Savings Plans or Reserved Instances for cost savings
  • Capacity Blocks for ML
    • reserve GPU instances (P4d, P5, P5e, Trn1) for ML workloads up to 8 weeks in advance
    • durations of up to 6 months in cluster sizes of 1 to 64 instances
    • supports instant start times and extensions
    • instances are placed in EC2 UltraClusters for low-latency networking
  • Spot Instances
    • cost-effective choice (up to 90% discount) but does NOT guarantee availability
    • applications flexible in the timing when they can run and also able to handle interruption by storing the state externally
    • provides a two-minute warning if the instance is to be terminated to save any unsaved work
    • Spot blocks can also be launched with a required duration, which are not interrupted due to changes in the Spot price Spot Blocks (Defined Duration) are no longer available for new customers.
    • Spot Fleet is a collection, or fleet, of Spot Instances, and optionally On-Demand Instances, which attempts to launch the number of Spot and On-Demand Instances to meet the specified target capacity
  • Dedicated Instances
    • is a tenancy option that enables instances to run in VPC on hardware that’s isolated, dedicated to a single customer
  • Dedicated Host
    • is a physical server with EC2 instance capacity fully dedicated to your use
    • helps meet compliance requirements and reduce costs by allowing use of existing server-bound software licenses
  • Light, Medium, and Heavy Utilization Reserved Instances are no longer available for purchase and were part of the Previous Generation AWS EC2 purchasing model

Enhanced Networking

  • results in higher bandwidth, higher packet per second (PPS) performance, lower latency, consistency, scalability, and lower jitter
  • supported using Single Root – I/O Virtualization (SR-IOV) only on supported instance types
  • is supported only with a VPC and HVM virtualization type
  • available by default on Amazon AMI but can be installed on other AMIs as well
  • no additional charge for using enhanced networking
  • Note: EC2-Classic has been fully retired (August 2023). All instances now run in VPC only.

Placement Group

  • Cluster Placement Group
    • provide low latency, High-Performance Computing via 10Gbps network
    • is a logical grouping on instances within a Single AZ
    • don’t span availability zones, can span multiple subnets but subnets must be in the same AZ
    • can span across peered VPCs for the same Availability Zones
    • An existing instance can be moved to a placement group, or moved from one placement group to another, or removed from a placement group, given it is in the stopped state.
    • for capacity errors, stop and start the instances in the placement group
    • use homogenous instance types which support enhanced networking and launch all the instances at once
  • Spread Placement Groups
    • is a group of instances that are each placed on distinct underlying hardware i.e. each instance on a distinct rack across AZ
    • recommended for applications that have a small number of critical instances that should be kept separate from each other.
    • reduces the risk of simultaneous failures that might occur when instances share the same underlying hardware.
  • Partition Placement Groups
    • is a group of instances spread across partitions i.e. group of instances spread across racks across AZs
    • reduces the likelihood of correlated hardware failures for the application.
    • can be used to spread deployment of large distributed and replicated workloads, such as HDFS, HBase, and Cassandra, across distinct hardware

EC2 Monitoring

  • CloudWatch provides monitoring for EC2 instances
  • Status monitoring helps quickly determine whether EC2 has detected any problems that might prevent instances from running applications.
  • Status monitoring includes
    • System Status checks – indicate issues with the underlying hardware
    • Instance Status checks – indicate issues with the underlying instance.

Elastic Load Balancer

  • Managed load balancing service and scales automatically
  • distributes incoming application traffic across multiple EC2 instances
  • is distributed system that is fault tolerant and actively monitored by AWS scales it as per the demand
  • are engineered to not be a single point of failure
  • supports Load Balancer Capacity Unit (LCU) Reservation to proactively set a minimum capacity for ALB and NLB, complementing auto-scaling for planned traffic events (launched Nov 2024)
  • supports routing traffic to instances in multiple AZs in the same region
  • performs Health Checks to route traffic only to the healthy instances
  • support Listeners with HTTP, HTTPS, SSL, TCP protocols
  • has an associated IPv4 and dual stack DNS name
  • can offload the work of encryption and decryption (SSL termination) so that the EC2 instances can focus on their main work
  • supports Cross Zone load balancing to help route traffic evenly across all EC2 instances regardless of the AZs they reside in
  • to help identify the IP address of a client
    • supports Proxy Protocol header for TCP/SSL connections
    • supports X-Forward headers for HTTP/HTTPS connections
  • supports Stick Sessions (session affinity) to bind a user’s session to a specific application instance,
    • it is not fault tolerant, if an instance is lost the information is lost
    • requires HTTP/HTTPS listener and does not work with TCP
    • requires SSL termination on ELB as it users the headers
  • supports Connection draining to help complete the in-flight requests in case an instance is deregistered
  • For High Availability, it is recommended to attach one subnet per AZ for at least two AZs, even if the instances are in a single subnet.
  • supports Static/Elastic IP (NLB only)
  • IPv4 & IPv6 support. VPC supports IPv6.
  • HTTPS listener does not support Client Side Certificate
  • For SSL termination at backend instances or support for Client Side Certificate use TCP for connections from the client to the ELB, use the SSL protocol for connections from the ELB to the back-end application, and deploy certificates on the back-end instances handling requests
  • Uses Server Name Indication to supports multiple SSL certificates
  • Supports four types: Application Load Balancer (ALB), Network Load Balancer (NLB), Gateway Load Balancer (GWLB), and Classic Load Balancer (CLB – previous generation)

Application Load Balancer

  • supports HTTP and HTTPS (Secure HTTP) protocols
  • supports HTTP/2, which is enabled natively. Clients that support HTTP/2 can connect over TLS
  • supports WebSockets and Secure WebSockets natively
  • supports Request tracing, by default.
    • request tracing can be used to track HTTP requests from clients to targets or other services.
    • Load balancer upon receiving a request from a client, adds or updates the X-Amzn-Trace-Id header before sending the request to the target
  • supports containerized applications. Using Dynamic port mapping, ECS can select an unused port when scheduling a task and register the task with a target group using this port.
  • supports Sticky Sessions (Session Affinity) using load balancer generated cookies, to route requests from the same client to the same target
  • supports SSL termination, to decrypt the request on ALB before sending it to the underlying targets.
  • supports layer 7 specific features like X-Forwarded-For headers to help determine the actual client IP, port and protocol
  • automatically scales its request handling capacity in response to incoming application traffic.
  • supports hybrid load balancing, to route traffic to instances in VPC and an on-premises location
  • provides High Availability, by allowing more than one AZ to be specified
  • integrates with ACM to provision and bind a SSL/TLS certificate to the load balancer thereby making the entire SSL offload process very easy
  • supports multiple certificates for the same domain to a secure listener
  • supports IPv6 addressing, for an Internet facing load balancer
  • supports dual-stack without public IPv4, enabling clients to connect using only IPv6 addresses without needing public IPv4 addresses (launched May 2024)
  • supports Cross-zone load balancing, and cannot be disabled.
  • supports Security Groups to control the traffic allowed to and from the load balancer.
  • provides Access Logs, to record all requests sent the load balancer, and store the logs in S3 for later analysis in compressed format
  • provides Delete Protection, to prevent the ALB from accidental deletion
  • supports Connection Idle Timeout – ALB maintains two connections for each request one with the Client (front end) and one with the target instance (back end). If no data has been sent or received by the time that the idle timeout period elapses, ALB closes the front-end connection
  • integrates with CloudWatch to provide metrics such as request counts, error counts, error types, and request latency
  • integrates with AWS WAF, a web application firewall that helps protect web applications from attacks by allowing rules configuration based on IP addresses, HTTP headers, and custom URI strings
  • integrates with CloudTrail to receive a history of ALB API calls made on the AWS account
  • back-end server authentication is NOT supported
  • does not provide Static, Elastic IP addresses

Network Load Balancer

  • handles volatile workloads and scale to millions of requests per second, without the need of pre-warming
  • offers extremely low latencies for latency-sensitive applications.
  • provides static IP/Elastic IP addresses for the load balancer
  • allows registering targets by IP address, including targets outside the VPC (on-premises) for the load balancer.
  • supports containerized applications. Using Dynamic port mapping, ECS can select an unused port when scheduling a task and register the task with a target group using this port.
  • monitors the health of its registered targets and routes the traffic only to healthy targets
  • enable cross-zone loading balancing only after creating the NLB
  • preserves client side source IP allowing the back-end to see client IP address. Target groups can be created with target type as instance ID or IP address. If targets registered by instance ID, the source IP addresses of the clients are preserved and provided to the applications. If register targets registered by IP address, the source IP addresses are the private IP addresses of the load balancer nodes.
  • supports both network and application target health checks.
  • supports long-lived TCP connections ideal for WebSocket type of applications
  • supports Zonal Isolation, which is designed for application architectures in a single zone and can be enabled in a single AZ to support architectures that require zonal isolation
  • supports sticky sessions using source IP affinity at the target group level to route traffic from the same client to the same target
  • supports removing Availability Zones after creation, enabling subnet reconfiguration without recreating the NLB (launched Feb 2025)
  • supports weighted target groups for blue/green and canary deployments without multiple load balancers (launched 2025)
  • supports QUIC protocol in passthrough mode, enabling low-latency forwarding of QUIC traffic while preserving session stickiness through QUIC Connection ID (launched Nov 2025)
  • supports UDP over IPv6 for dualstack load balancers (launched Nov 2024)

Gateway Load Balancer

  • enables deployment, scaling, and management of third-party virtual appliances such as firewalls, intrusion detection/prevention systems, and deep packet inspection systems
  • provides one gateway for distributing traffic across multiple virtual appliances while scaling them up or down based on demand
  • operates at Layer 3 (Network layer) and listens for all IP packets across all ports
  • uses the GENEVE protocol on port 6081 to encapsulate traffic
  • supports flow stickiness using 2-tuple, 3-tuple, or 5-tuple hash
  • configurable TCP idle timeout from 60 to 6000 seconds
  • decreases potential points of failure in network and increases availability
  • use cases include centralized network security inspection, traffic mirroring, and compliance monitoring

Auto Scaling

  • ensures correct number of EC2 instances are always running to handle the load by scaling up or down automatically as demand changes
  • cannot span multiple regions.
  • attempts to distribute instances evenly between the AZs that are enabled for the Auto Scaling group
  • performs checks either using EC2 status checks or can use ELB health checks to determine the health of an instance and terminates the instance if unhealthy, to launch a new instance
  • can be scaled using manual scaling, scheduled scaling, dynamic scaling (target tracking, step, simple) or predictive scaling
  • Predictive Scaling uses machine learning to predict future traffic based on historical patterns and proactively launches instances ahead of demand, ideal for applications with recurring traffic spikes
  • Target Tracking scaling now features highly responsive scaling policies that adapt to unique application usage patterns and support high-resolution CloudWatch metrics (enhanced Nov 2024)
  • cooldown period helps ensure instances are not launched or terminated before the previous scaling activity takes effect to allow the newly launched instances to start handling traffic and reduce load

AWS Auto Scaling & ELB

  • Auto Scaling & ELB can be used for High Availability and Redundancy by spanning Auto Scaling groups across multiple AZs within a region and then setting up ELB to distribute incoming traffic across those AZs
  • With Auto Scaling, use ELB health check with the instances to ensure that traffic is routed only to the healthy instances

Lambda

  • offers Serverless computing that allows applications and services to be built and run without thinking about servers.
  • helps run code without provisioning or managing servers, where you pay only for the compute time when the code is running.
  • is priced on a pay-per-use basis and there are no charges when the code is not running.
  • performs all the operational and administrative activities on your behalf, including capacity provisioning, monitoring fleet health, applying security patches to the underlying compute resources, deploying code, running a web service front end, and monitoring and logging the code.
  • does not provide access to the underlying compute infrastructure.
  • handles scalability and availability as it
    • provides easy scaling and high availability to the code without additional effort on your part.
    • is designed to process events within milliseconds.
    • is designed to run many instances of the functions in parallel.
    • is designed to use replication and redundancy to provide high availability for both the service and the functions it operates.
    • has no maintenance windows or scheduled downtimes for either.
    • has a default safety throttle for the number of concurrent executions per account per region.
    • has a higher latency immediately after a function is created, or updated, or if it has not been used recently.
    • for any function updates, there is a brief window of time, less than a minute, when requests would be served by both versions
  • Security
    • stores code in S3 and encrypts it at rest and performs additional integrity checks while the code is in use.
    • each function runs in its own isolated environment, with its own resources and file system view
    • supports Code Signing using AWS Signer, which offers trust and integrity controls that enable you to verify that only unaltered code from approved developers is deployed in the functions.
  • Functions must complete execution within 900 seconds (15 minutes). The default timeout is 3 seconds. The timeout can be set to any value between 1 and 900 seconds.
  • Supports up to 10,240 MB (10 GB) of memory per function.
  • AWS Step Functions can help coordinate a series of Lambda functions in a specific order. Multiple functions can be invoked sequentially, passing the output of one to the other, and/or in parallel, while the state is being maintained by Step Functions.
  • AWS X-Ray helps to trace functions, which provides insights such as service overhead, function init time, and function execution time.
  • Lambda Provisioned Concurrency provides greater control over the performance of serverless applications.
  • Lambda@Edge allows you to run code across AWS locations globally without provisioning or managing servers, responding to end-users at the lowest network latency.
  • Lambda Extensions allow integration of Lambda with other third-party tools for monitoring, observability, security, and governance.
  • Compute Savings Plan can help save money for Lambda executions.
  • CodePipeline and CodeDeploy can be used to automate the serverless application release process.
  • RDS Proxy provides a highly available database proxy that manages thousands of concurrent connections to relational databases.
  • Supports Elastic File Store, to provide a shared, external, persistent, scalable volume using a fully managed elastic NFS file system without the need for provisioning or capacity management.
  • Supports Function URLs, a built-in HTTPS endpoint that can be invoked using the browser, curl, and any HTTP client.
  • Lambda SnapStart reduces cold start latency from several seconds to sub-second for Java, Python, and .NET functions by taking a snapshot of the initialized execution environment (GA for Python & .NET in Nov 2024).
  • Lambda Durable Functions enable building resilient multi-step applications and AI workflows that can execute for up to one year, automatically checkpoint progress, suspend execution during long-running tasks, and recover from failures without custom state management code (launched Dec 2025).
  • Lambda Managed Instances enables running Lambda functions on EC2 instances (including Graviton4, GPU, network-optimized) while maintaining Lambda’s operational simplicity, with access to EC2 commitment-based pricing (Savings Plans, Reserved Instances) for up to 72% cost savings (launched Nov 2025).
  • Supports runtimes including Node.js 24, Python 3.12+, Java 25, .NET 8, and more.

AWS Compute – Additional Services

  • Amazon ECS (Elastic Container Service) – fully managed container orchestration service
    • Supports Fargate (serverless) and EC2 launch types
    • ECS Express Mode (launched Nov 2025) – streamlines deployment of containerized workloads by automatically setting up load balancing, auto scaling, networking, and monitoring with simplified APIs
    • ECS Managed Instances (launched Sep 2025) – fully managed compute option for broader EC2 instance access without infrastructure overhead
    • Supports predictive scaling (launched Nov 2024)
  • Amazon EKS (Elastic Kubernetes Service) – managed Kubernetes service for running containers at scale
  • AWS Fargate – serverless compute engine for containers that works with both ECS and EKS, removing the need to manage underlying infrastructure
  • AWS Batch – fully managed batch computing service for running batch jobs at any scale
  • AWS App Runner – ⚠️ No longer accepting new customers as of April 30, 2026. Existing services continue to operate. AWS recommends migrating to Amazon ECS Express Mode. No new features planned.

Related Posts

AWS EC2 VM Import/Export

~ Last updated on : ~ jayendrapatil ~ 5 Comments

EC2 VM Import/Export

  • EC2 VM Import/Export enables importing virtual machine (VM) images from existing virtualization environment to EC2, and then export them back to the on-premises environment.
  • EC2 VM Import/Export enables
    • migration of applications and workloads to EC2,
    • copying VM image catalog to EC2, or
    • creating a repository of VM images for backup and disaster recovery,
    • leveraging previous investments in building VMs by migrating the VMs to EC2.
  • VM Import/Export is available at no additional charge beyond standard usage charges for Amazon EC2 and Amazon S3.
  • For large-scale lift-and-shift migrations, AWS Transform MGN (formerly AWS Application Migration Service) is the recommended service as it provides continuous block-level replication, automated testing, and minimal-downtime cutover.

Supported Image Formats

  • OVA – Open Virtual Appliance image format, supports importing images with multiple hard disks
  • VMDK – Stream-optimized ESX Virtual Machine Disk, compatible with VMware ESX and VMware vSphere
  • VHD/VHDX – Fixed and Dynamic Virtual Hard Disk formats, compatible with Microsoft Hyper-V, Microsoft Azure, and Citrix Xen
  • RAW – Raw format for importing disks and VMs
⚠️ Important (April 2026): Starting April 1, 2026, VM Import/Export no longer supports i386 (32-bit) architecture. Import and Export tasks will not work for 32-bit OS versions including Windows Server 2003/2008 (32-bit), Windows 7/8 (32-bit), CentOS 5/6 (32-bit), Debian 6-12 (32-bit), and Ubuntu 12.04-17.04 (32-bit).

Supported Operating Systems

  • Linux:
    • Amazon Linux 2023 (kernel 6.1)
    • Ubuntu 24.04, 25.10, 26.04
    • Red Hat Enterprise Linux (RHEL) 8.9, 9.3–9.6
    • Rocky Linux 9.1–9.6
    • Oracle Linux 8.9, 9.3–9.6
    • CentOS 5.1–8.x (64-bit only for older versions)
    • Debian 7–12
    • SUSE Linux Enterprise Server 12, 15
  • Windows:
    • Windows Server 2008 R2 through Windows Server 2025
    • Windows 7 through Windows 11
    • Windows 11 requires UEFI boot mode
  • Not Supported: ARM64 architecture VMs, VMs from physical-to-virtual (P2V) conversions

Boot Modes

  • VM Import/Export supports two boot modes: UEFI (Unified Extensible Firmware Interface) and Legacy BIOS
  • The optional --boot-mode parameter can be specified as legacy-bios or uefi during import
  • Windows 11 requires UEFI boot mode
  • If no boot mode is specified and the VM is compatible with both, GPT volumes are converted to MBR partitioned volumes (Legacy BIOS is selected by default)

AWS EC2 VM Import/Export

EC2 VM Import/Export Features

  • Import a VM from a virtualization environment to EC2 as an Amazon Machine Image (AMI), which can be used to launch EC2 instances. (Recommended approach)
  • Import a VM as an EC2 instance (initially in a stopped state). Note: Importing as an instance is deprecated — the AWS CLI only supports importing as an image via aws ec2 import-image.
  • Export a VM that was previously imported from the virtualization environment.
  • Import disks as EBS snapshots.

Export Limitations

  • Cannot export instances/images containing third-party software provided by AWS (e.g., Windows or SQL Server images, or any image from AWS Marketplace)
  • Only supports exporting to an S3 bucket in the same AWS account
  • Export operations do not support hybrid boot configurations (GRUB2 must be enabled for either BIOS or UEFI, not both)

Import Limitations

  • Does not support importing disks separated into multiple files
  • Does not support VMs that use Raw Device Mapping (RDM)
  • Does not support VMs created by physical-to-virtual (P2V) conversion
  • ARM64 architecture VMs are not supported
  • Maximum 24 volumes can be attached to an import task

Integration with EC2 Image Builder

  • EC2 Image Builder works in conjunction with VM Import/Export to create and maintain golden images for both Amazon EC2 (AMI) and on-premises VM formats (VHDX, VMDK, OVF).
  • The import-vm-image command in Image Builder CLI references the VM Import task ID to pull in the created AMI as a base image for Image Builder recipes.
  • This enables building automated image pipelines that span both cloud and on-premises environments.

Related Migration Services

  • AWS Transform MGN (formerly AWS Application Migration Service / AWS MGN) – Recommended for lift-and-shift migrations. Provides continuous block-level replication with agent-based or agentless (VMware only) options. Automates server conversion to native EC2 instances with near-zero data loss and minimal downtime cutover.
    • Replaces deprecated AWS Server Migration Service (SMS) and CloudEndure Migration
    • Supports physical, virtual, and cloud-to-cloud migrations
  • Amazon Elastic VMware Service (Amazon EVS) – GA since August 2025. Run VMware Cloud Foundation (VCF) directly within your Amazon VPC without re-architecting applications. Ideal for organizations wanting to maintain VMware tools and investments while leveraging AWS infrastructure.
  • AWS Transform – Agentic AI service (GA May 2025) that accelerates full-stack migration and modernization including Windows, mainframe, and VMware workloads.

When to Use VM Import/Export vs. AWS Transform MGN

Criteria VM Import/Export AWS Transform MGN
Best for One-off imports, image catalog migration, DR repository Large-scale migrations, continuous replication
Downtime Higher (full image upload required) Minimal (continuous replication + cutover)
Automation CLI-based, manual process Fully automated with testing and cutover workflows
Replication Point-in-time snapshot Continuous block-level replication
Scale Individual VMs Multiple servers concurrently

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. You are responsible for a legacy web application whose server environment is approaching end of life. You would like to migrate this application to AWS as quickly as possible, since the application environment currently has the following limitations: The VM’s single 10GB VMDK is almost full. The virtual network interface still uses the 10Mbps driver, which leaves your 100Mbps WAN connection completely underutilized. It is currently running on a highly customized Windows VM within a VMware environment: You do not have the installation media. This is a mission critical application with an RTO (Recovery Time Objective) of 8 hours. RPO (Recovery Point Objective) of 1 hour. How could you best migrate this application to AWS while meeting your business continuity requirements?
    1. Use the EC2 VM Import Connector for vCenter to import the VM into EC2
    2. Use Import/Export to import the VM as an EBS snapshot and attach to EC2. (Import/Export is used to transfer large amount of data)
    3. Use S3 to create a backup of the VM and restore the data into EC2.
    4. Use the ec2-bundle-instance API to Import an Image of the VM into EC2 (only bundles a Windows instance store instance)
  2. You are tasked with moving a legacy application from a virtual machine running inside your datacenter to an Amazon VPC. Unfortunately this app requires access to a number of on-premises services and no one who configured the app still works for your company. Even worse there’s no documentation for it. What will allow the application running inside the VPC to reach back and access its internal dependencies without being reconfigured? (Choose 3 answers)
    1. An AWS Direct Connect link between the VPC and the network housing the internal services (VPN or a DX for communication)
    2. An Internet Gateway to allow a VPN connection. (Virtual and Customer gateway is needed)
    3. An Elastic IP address on the VPC instance (Don’t need a EIP as private subnets can also interact with on-premises network)
    4. An IP address space that does not conflict with the one on-premises (IP address cannot conflict)
    5. Entries in Amazon Route 53 that allow the Instance to resolve its dependencies’ IP addresses (Route 53 is not required)
    6. A VM Import of the current virtual machine (VM Import to copy the VM to AWS as there is no documentation it can’t be configured from scratch)
  3. A company wants to migrate 200 VMs from on-premises VMware to AWS with minimal downtime. The VMs run various Linux and Windows workloads. Which service should they use?
    1. VM Import/Export (VM Import/Export is for individual VM image imports, not large-scale migrations)
    2. AWS Transform MGN (Application Migration Service) (MGN provides continuous block-level replication with automated cutover for large-scale migrations with minimal downtime)
    3. AWS Server Migration Service (SMS was discontinued in March 2022, replaced by MGN)
    4. Amazon S3 with manual AMI creation
  4. An organization needs to maintain a golden image pipeline that produces AMIs for EC2 and VMDK/VHD images for on-premises deployment. Which combination of services should they use?
    1. EC2 Image Builder with VM Import/Export (Image Builder uses VM Import/Export to create and maintain images for both EC2 (AMI) and on-premises VM formats (VHDX, VMDK, OVF))
    2. AWS Transform MGN with manual exports
    3. AWS Backup with cross-region replication
    4. CloudFormation with custom AMI resources
  5. A company running VMware vSphere on-premises wants to extend their environment to AWS without re-architecting their applications or changing their operational tools. Which AWS service is most appropriate?
    1. VM Import/Export (VM Import/Export converts VMs to EC2 instances, doesn’t maintain VMware environment)
    2. AWS Transform MGN (MGN converts to native EC2, doesn’t maintain VMware tooling)
    3. Amazon Elastic VMware Service (Amazon EVS) (Amazon EVS runs VMware Cloud Foundation directly within your VPC, maintaining VMware tools and operational runbooks)
    4. Amazon EC2 with VMware Cloud on AWS (VMware Cloud on AWS is a Broadcom-managed service, different from Amazon EVS)

References

AWS EC2 – Elastic Cloud Compute

~ Last updated on : ~ jayendrapatil ~ 9 Comments

Elastic Cloud Compute – EC2

  • Elastic Compute Cloud – EC2 provides scalable computing capacity in AWS.
  • EC2 offers the broadest and deepest compute platform, with over 1,000 instance types and choice of the latest processor, storage, networking, operating system, and purchase model.
  • Elastic Compute Cloud – EC2
    • eliminates the need to invest in hardware upfront, so applications can be developed and deployed faster.
    • can be used to launch as many or as few virtual servers as you need, configure security and networking, and manage storage.
    • enables you to scale up or down to handle changes in requirements or spikes in popularity, reducing the need to forecast traffic.
    • launches instances in minutes, scales capacity in seconds, and you pay only for what you use with no capital expenditure.

EC2 features

  • EC2 instances – Virtual computing environments running on the AWS Nitro System, a purpose-built hypervisor that offloads virtualization functions to dedicated hardware.
  • Amazon Machine Images (AMIs) – Preconfigured templates for the instances that package the bits needed for a server (including the operating system and additional software). Supported OS includes Amazon Linux 2023, Windows Server 2025, Ubuntu, Red Hat, SUSE, and macOS.
  • Instance types – Various configurations of CPU, memory, storage, and networking capacity for the instances, organized into families: General Purpose, Compute Optimized, Memory Optimized, Storage Optimized, Accelerated Computing, and High-Performance Computing (HPC).
  • Processor Options – Choice of processors including AWS Graviton (Arm-based), Intel Xeon, and AMD EPYC. AWS Graviton processors are custom-built by AWS for the best price-performance.
  • Key Pairs – Secure login information for the instances (AWS stores the public key, and you store the private key in a secure place). Supports ED25519 and RSA key types.
  • Instance Store Volumes – Storage volumes for temporary data that are deleted when you stop or terminate your instance (ephemeral storage)
  • EBS Volumes – Persistent storage volumes for the data using Elastic Block Store (EBS)
  • Regions and Availability Zones – Multiple physical locations for the resources, such as instances and EBS volumes
  • Security Groups – A virtual firewall that enables you to specify the protocols, ports, and source IP ranges that can reach the instances
  • Elastic IP addresses – Static IPv4 addresses for dynamic cloud computing
  • Tags – Metadata can be created and assigned to EC2 resources
  • Placement Groups – Logical grouping of instances (Cluster, Spread, or Partition) to influence instance placement for performance or fault tolerance

AWS Nitro System

  • The AWS Nitro System is the underlying platform for all modern EC2 instances.
  • Nitro System offloads virtualization functions (networking, storage, security) to dedicated hardware and software, delivering practically all of the compute resources of the host hardware to the instances.
  • Components include:
    • Nitro Cards – Dedicated cards that handle I/O for VPC networking, EBS storage, and instance storage. Latest is 6th generation Nitro Cards (2026).
    • Nitro Security Chip – Provides hardware root of trust, continuously monitors and protects instance hardware and firmware.
    • Nitro Hypervisor – Lightweight hypervisor that manages memory and CPU allocation. Features the Nitro Isolation Engine (GA 2026) – a formally verified component that provides mathematical proof of VM isolation.
    • Nitro Enclaves – Isolated compute environments within an EC2 instance for processing highly sensitive data (PII, healthcare, financial). No persistent storage, no admin access, no external networking.
    • NitroTPM – Virtual Trusted Platform Module (TPM 2.0) for securely storing passwords, certificates, and encryption keys used to authenticate the instance.
  • Security model is locked down and prohibits administrative access, eliminating the possibility of human error and tampering. No AWS operator has access to the system.

AWS Graviton Processors

  • AWS Graviton processors are custom Arm-based processors designed by AWS to deliver the best price-performance for cloud workloads.
  • Graviton2 – 64 Arm Neoverse N1 cores, supports always-on 256-bit DRAM encryption. Powers 6th gen instances (M6g, C6g, R6g, T4g).
  • Graviton3 – 25% better compute performance, 2x floating-point and crypto performance, 50% faster memory access, 60% lower energy consumption vs. Graviton2. Powers 7th gen instances (M7g, C7g, R7g).
  • Graviton4 (2024) – Up to 30% better compute performance vs. Graviton3, up to 3x more vCPUs (up to 48xlarge) and memory. Uses DDR5 memory. Powers 8th gen instances (M8g, C8g, R8g).
  • Graviton5 (2026) – Up to 25% better compute performance vs. Graviton4, 192 cores, 33% lower inter-core latency. Most powerful and energy-efficient AWS processor. Powers 9th gen instances (M9g). Apps run 35% faster, ML inference 35% faster, databases 30% faster.
  • Graviton instances offer up to 40% better price-performance compared to equivalent x86 instances.
  • Support Arm features including Scalable Vector Extension (SVE), SVE2, Pointer Authentication, and Branch Target Identification (generation dependent).

EC2 Instance Types (Current Generation)

  • General Purpose (M-series, T-series, Mac) – Balance of compute, memory, and networking. Includes M8g, M8gd, M8a, M8in, M9g (Graviton5), T3, T4g. Mac instances (M4, M4 Pro, M4 Max) support Apple Silicon for iOS/macOS development.
  • Compute Optimized (C-series) – High-performance processors for batch processing, gaming, ML inference. Includes C8g, C8gd, C8gn (600 Gbps networking), C8ine.
  • Memory Optimized (R-series, X-series, U-series) – Fast performance for workloads processing large data sets in memory. Includes R8g, R8gd, R8gn (600 Gbps), R8in, X2idn, U-series High Memory (up to 24 TB).
  • Storage Optimized (I-series, D-series, H-series) – High sequential read/write access to large data sets on local storage. Includes I4g, Im4gn, Is4gen, D3, H1.
  • Accelerated Computing (P-series, G-series, Trn-series, Inf-series) – Hardware accelerators for ML, graphics, HPC. Includes P5e (NVIDIA H200), G7e (NVIDIA RTX PRO 6000 Blackwell), Trn1/Trn2 (AWS Trainium for ML training), Inf2 (AWS Inferentia2 for ML inference).
  • High-Performance Computing (HPC-series) – Purpose-built for tightly coupled HPC workloads. Includes Hpc7g (Graviton), Hpc7a (AMD), Hpc8a (5th Gen AMD EPYC, 192 cores, 300 Gbps EFA).

EC2 Instance Naming Convention

  • Instance types follow the convention: [Family][Generation][Attributes].[Size]
  • Example: m8g.xlarge = General Purpose (m), 8th generation (8), Graviton (g), extra-large size
  • Common attributes:
    • g – AWS Graviton (Arm-based)
    • a – AMD processor
    • i – Intel processor
    • n – Network optimized
    • d – NVMe local storage (instance store)
    • b – EBS optimized
    • e – Extra storage or memory

EC2 Networking

  • Elastic Network Adapter (ENA) – High-performance network interface supporting up to 200 Gbps bandwidth on supported instances.
  • ENA Express – Uses AWS Scalable Reliable Datagram (SRD) protocol to deliver up to 25 Gbps single-flow bandwidth and lower tail latency. Now supports cross-AZ traffic (2026) and 120+ instance types.
  • Elastic Fabric Adapter (EFA) – Network interface for HPC and ML workloads, supports OS-bypass for low-latency inter-node communication. Up to 300 Gbps on Hpc8a instances.
  • Enhanced Networking – Uses SR-IOV to provide high-performance networking capabilities. Enabled by default on Nitro-based instances.
  • EC2 instances support IPv4 and IPv6 addressing.
  • Network bandwidth scales with instance size, up to 200 Gbps for largest instances.

EC2 Security

  • Instance Metadata Service v2 (IMDSv2) – Session-oriented metadata access that adds defense-in-depth against unauthorized metadata access. IMDSv2 is now the default for all new instance launches and mandatory for new instance type families (since mid-2024).
  • Security Groups – Stateful virtual firewall at the instance level.
  • Key Pairs – SSH key-based access (Linux) or password decryption (Windows). Supports ED25519 and RSA.
  • IAM Roles – Attach IAM roles to EC2 instances for secure access to AWS services without storing credentials.
  • Nitro Enclaves – Isolated environments for confidential computing.
  • NitroTPM – Hardware-based root of trust for measured boot and platform integrity.
  • Nitro Isolation Engine (2026) – Formally verified hypervisor component providing mathematical guarantees of VM isolation.

Accessing EC2

  • Amazon EC2 console
    • Amazon EC2 console is the web-based user interface that can be accessed from the AWS management console
  • AWS Command Line Interface (CLI)
    • Provides commands for a broad set of AWS products, supported on Windows, Mac, and Linux.
  • AWS Tools for Windows PowerShell
    • Provides commands for a broad set of AWS products for those who script in the PowerShell environment
  • AWS SDKs
    • AWS provides SDKs in various languages (Python/Boto3, Java, Go, .NET, JavaScript, etc.) which provide API abstractions and handle authentication, retries, and error handling
  • AWS CloudFormation / Infrastructure as Code
    • EC2 instances can be provisioned and managed using CloudFormation, CDK, or Terraform
  • EC2 Instance Connect
    • Browser-based SSH connection to EC2 instances without needing to manage SSH keys
  • AWS Systems Manager Session Manager
    • Secure shell access without opening inbound ports, managing SSH keys, or using bastion hosts

EC2 Key Changes and Deprecations

  • EC2-Classic Retired (August 2023) – All instances now run in VPC only. EC2-Classic networking is no longer available.
  • Amazon Linux 1 EOL (December 31, 2023) – No security updates or bug fixes since January 1, 2024. Migrate to Amazon Linux 2023.
  • Amazon Linux 2 Extended Support Ending – AWS recommends migration to Amazon Linux 2023. ECS AL2 AMIs end support June 30, 2026.
  • IMDSv2 Default (2024) – New instance types only support IMDSv2. Account-level default can enforce IMDSv2 for all launches.
  • Windows Server 2025 Support (November 2024) – Available with License Included AMIs, supports Nitro instance types only.
  • Previous Generation Instances – Older instance families (M1, M3, C1, C3, etc.) are classified as “previous generation” and still supported but not recommended for new deployments.

Additional Reading

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. What are the Amazon EC2 API tools?
    1. They don’t exist. The Amazon EC2 AMI tools, instead, are used to manage permissions.
    2. Command-line tools to the Amazon EC2 web service
    3. They are a set of graphical tools to manage EC2 instances.
    4. They don’t exist. The Amazon API tools are a client interface to Amazon Web Services.
  2. When a user is launching an instance with EC2, which of the below mentioned options is not available during the instance launch console for a key pair?
    1. Proceed without the key pair
    2. Upload a new key pair
    3. Select an existing key pair
    4. Create a new key pair
  3. Which of the following is the underlying platform for all modern EC2 instances that offloads virtualization functions to dedicated hardware?
    1. Xen Hypervisor
    2. KVM Hypervisor
    3. AWS Nitro System
    4. VMware ESXi
  4. Which AWS processor family is custom-designed by AWS using Arm architecture to deliver the best price-performance for cloud workloads?
    1. Intel Xeon
    2. AMD EPYC
    3. AWS Graviton
    4. Apple Silicon
  5. Which version of the EC2 Instance Metadata Service is now required by default for all new instance type launches since mid-2024?
    1. IMDSv1
    2. IMDSv2
    3. IMDSv3
    4. IMDS is optional and not required
  6. A company needs isolated compute environments within their EC2 instances to securely process PII data. Which AWS feature should they use?
    1. Security Groups
    2. VPC Private Subnets
    3. AWS Nitro Enclaves
    4. AWS KMS
  7. Which EC2 networking feature uses the AWS Scalable Reliable Datagram (SRD) protocol to deliver up to 25 Gbps single-flow bandwidth?
    1. Enhanced Networking
    2. Elastic Fabric Adapter
    3. ENA Express
    4. AWS Direct Connect
  8. Which of the following is NOT a valid EC2 instance type family category?
    1. High-Performance Computing (HPC)
    2. Storage Optimized
    3. Network Optimized
    4. Accelerated Computing
  9. A developer needs to build and test iOS applications on AWS. Which EC2 instance type family should they choose?
    1. G-series (GPU instances)
    2. C-series (Compute Optimized)
    3. Mac instances (Apple Silicon)
    4. T-series (Burstable Performance)
  10. Which AWS Graviton processor generation was released in 2026 featuring 192 cores and up to 25% better compute performance than the previous generation?
    1. Graviton3
    2. Graviton4
    3. Graviton5
    4. Graviton6

References

AWS EC2 Security

~ Last updated on : ~ jayendrapatil ~ 17 Comments

AWS EC2 Security

  • IAM helps control whether users in the organization can perform a task using specific EC2 API actions and whether they can use specific AWS resources.
  • Use IAM roles to prevent the need to share as well as manage, and rotate the security credentials that the applications use.
  • Security groups act as a virtual firewall that controls the traffic to the EC2 instances. They can help specify rules that control the inbound traffic that’s allowed to reach the instances and the outbound traffic that’s allowed to leave the instance.
  • Use AWS Systems Manager Session Manager to connect to the instance as it provides secure and auditable instance management without the need to open inbound ports, maintain bastion hosts, or manage SSH keys.
  • Use EC2 Instance Connect to connect to your instances using Secure Shell (SSH) without the need to share and manage SSH keys.
  • Use EC2 Instance Connect Endpoint to connect securely to instances in private subnets without requiring a public IP address, Internet Gateway, or bastion host.
  • Use AWS Systems Manager Run Command to automate common administrative tasks instead of opening inbound SSH ports and managing SSH keys.
  • Use Systems Manager Patch Manager to automate the process of patching, installing security-related updates for both the operating system and applications.
  • Use AWS Verified Access to provide secure, VPN-less, zero-trust access to EC2 instances over SSH, RDP, and other protocols.
  • Enforce IMDSv2 (Instance Metadata Service Version 2) to add defense-in-depth against unauthorized metadata access using session-oriented token-based requests.

EC2 Key Pairs

  • EC2 uses public-key cryptography to encrypt & decrypt login information
  • Public-key cryptography uses a public key to encrypt a piece of data, such as a password, then the recipient uses the private key to decrypt the data.
  • Public and private keys are known as a key pair.
  • To log in to an EC2 instance, a key pair needs to be created and specified when the instance is launched, and the private key can be used to connect to the instance.
  • Linux instances have no password, and the key pair is used for ssh log in
  • For Windows instances, the key pair can be used to obtain the administrator password and then log in using RDP
  • EC2 stores the public key only, and the private key resides with the user. EC2 doesn’t keep a copy of your private key
  • Public key content (on Linux instances) is placed in an entry within ~/.ssh/authorized_keys at boot time and enables the user to securely access the instance without passwords
  • Public key specified for an instance when launched is also available through its instance metadata http://169.254.169.254/latest/meta-data/public-keys/0/openssh-key
  • EC2 Security Best Practice: Store the private keys in a secure place as anyone who possesses the private key can decrypt the login information
  • Also, if the private key is lost, there is no way to recover the same.
    • For instance store, you cannot access the instance
    • For EBS-backed Linux instances, access can be regained.
      • EBS-backed instance can be stopped, its root volume detached and attached to another instance as a data volume
      • Modify the authorized_keys file, move the volume back to the original instance, and restart the instance
  • Key pair associated with the instances can either be
    • Generated by EC2
      • EC2 supports RSA (2048-bit SSH-2) and ED25519 key pair types.
      • ED25519 keys are not supported for Windows instances.
      • Key pairs can be generated in PEM or PPK format.
    • Created separately (using third-party tools) and Imported into EC2
      • EC2 accepts RSA and ED25519 keys for import (does not accept DSA keys)
      • RSA supported lengths: 1024, 2048, and 4096
  • Supports five thousand key pairs per region
  • Key pair management features include viewing creation date and public key material for existing and new key pairs.
  • Deleting a key pair only deletes the public key and does not impact the servers already launched with the key.
  • Use AWS Systems Manager Session Manager to connect to the instance as it provides secure and auditable instance management without the need to open inbound ports, maintain bastion hosts, or manage SSH keys.

EC2 Instance Connect

  • EC2 Instance Connect provides a simple and secure way to connect to instances using SSH without the need to share and manage SSH keys.
  • Generates a one-time-use SSH public key and pushes it to the instance metadata, where it remains available for 60 seconds.
  • IAM policies control which users can access and connect to specific instances.
  • All connection requests using EC2 Instance Connect are logged to AWS CloudTrail for auditing.
  • Supports IPv6 connectivity (added Sep 2024), allowing connections to instances with IPv6 addresses.
  • Available at no additional cost.

EC2 Instance Connect Endpoint

  • EC2 Instance Connect Endpoint (EIC Endpoint), launched in June 2023, allows secure connectivity from the Internet to instances in private subnets.
  • Eliminates the need for an Internet Gateway (IGW) in the VPC, a public IP address on the resource, a bastion host, or any agent to connect to instances.
  • Supports SSH (Linux) and RDP (Windows) connectivity without public IP addresses.
  • Uses IAM-based authentication to establish secure connections.
  • Supports IPv6 connectivity (added Oct 2025) — EIC Endpoints can be configured as dual-stack or IPv6-only.
  • IAM policies can restrict which instances users can connect to through the endpoint.
  • Available at no additional cost.
  • Replaces traditional bastion host architecture for many use cases, reducing operational overhead and attack surface.

EC2 Security Groups

  • An EC2 instance, when launched, can be associated with one or more security groups, which acts as a virtual firewall that controls the traffic to that instance
  • Security groups help specify rules that control the inbound traffic that’s allowed to reach the instances and the outbound traffic that’s allowed to leave the instance
  • Security groups are associated with network interfaces. Changing an instance’s security groups changes the security groups associated with the primary network interface (eth0)
  • An ENI can be associated with 5 security groups and with 60 inbound and 60 outbound rules per security group (120 total rules per security group)
  • A single network interface cannot have more than 1000 combined rules from all attached Security Groups.
  • Rules for a security group can be modified at any time; the new rules are automatically applied to all instances associated with the security group.
  • All the rules from all associated security groups are evaluated to decide where to allow traffic to an instance
  • Security Group features
    • For the VPC default security group, it allows all inbound traffic from other instances associated with the default security group
    • By default, VPC default security groups or newly created security groups allow all outbound traffic
    • Security group rules are always permissive; deny rules can’t be created
    • Rules can be added and removed any time.
    • Any modification to the rules are automatically applied to the instances associated with the security group after a short period, depending on the connection tracking for the traffic
    • Security groups are stateful — if you send a request from your instance, the response traffic for that request is allowed to flow in regardless of inbound security group rules. For VPC security groups, this also means that responses to allowed inbound traffic are allowed to flow out, regardless of outbound rules
    • If multiple rules are defined for the same protocol and port, the Most permissive rule is applied for e.g. for multiple rules for tcp and port 22 for specific IP and Everyone, everyone is granted access being the most permissive rule

Security Group VPC Associations (Oct 2024)

  • Security groups can now be associated with multiple VPCs in the same account and AWS Region using Security Group VPC Associations.
  • Enables enforcing consistent traffic filtering rules for workloads regardless of the VPC.
  • Security groups can be shared with participant accounts using AWS Resource Access Manager (RAM) in shared VPC environments.
  • Cannot share security groups that are in a default VPC.
  • Eliminates the need to duplicate security group rules across multiple VPCs.

Security Group Referencing across Transit Gateway (Sep 2024)

  • Security group referencing is now supported across VPCs connected by AWS Transit Gateway.
  • Allows creating inbound security rules that reference security groups defined in other VPCs attached to a Transit Gateway within the same Region.
  • Simplifies management and provides better security posture for TGW-based networks.
  • Also supported across AWS Cloud WAN (Jun 2025) for cross-VPC connectivity.

Related Resources View (Feb 2026)

  • The EC2 and VPC consoles now display a “Related resources” tab for security groups.
  • Provides a consolidated view of all resources that depend on a specific security group.
  • Eliminates the need to manually check multiple services before making security group configuration changes.

Connection Tracking

  • Security groups are Stateful and they use Connection tracking to track information about traffic to and from the instance.
  • This allows responses to inbound traffic to flow out of the instance regardless of outbound security group rules, and vice versa.
  • Connection Tracking is maintained only if there is no explicit Outbound rule for an Inbound request (and vice versa)
  • However, if there is an explicit Outbound rule for an Inbound request, the response traffic is allowed on the basis of the Outbound rule and not on the Tracking information
  • Any existing flow of traffic, that is tracked, is not interrupted even if the rules for the security groups are changed. To ensure traffic is immediately interrupted, use NACL as they are stateless and therefore do not allow automatic response traffic.
  • Also, If the instance (host A) initiates traffic to host B and uses a protocol other than TCP, UDP, or ICMP, the instance’s firewall only tracks the IP address and protocol number for the purpose of allowing response traffic from host B. If host B initiates traffic to your instance in a separate request within 600 seconds of the original request or response, your instance accepts it regardless of inbound security group rules, because it’s regarded as response traffic.
  • Can be controlled by modifying the security group’s outbound rules to permit only certain types of outbound traffic or using NACL

Configurable Idle Timeouts (Nov 2023)

  • Idle timeouts for connection tracking are now configurable on a per Elastic Network Interface (ENI) basis.
  • Configurable timeout settings:
    • TCP Established: Min 60 seconds, Max 432,000 seconds (5 days). Default: 432,000 seconds (pre-Nitro v6) or 350 seconds (Nitro v6 instances).
    • UDP Stream: Min 60 seconds, Max 180 seconds. Default: 180 seconds.
    • UDP Unidirectional: Min 30 seconds, Max 60 seconds. Default: 30 seconds.
  • Important (Jun 2025): Sixth-generation Nitro (Nitro v6) instances (c8, r8, etc.) changed the default TCP connection tracking idle timeout from 432,000 seconds (5 days) to 350 seconds. If a TCP connection remains idle for more than 350 seconds, the ENI evicts the session from its tracking table.
  • Applications with long-lived idle connections on Nitro v6 instances should either configure keep-alive mechanisms or adjust the idle timeout setting.

Instance Metadata Service v2 (IMDSv2)

  • IMDSv2 is an enhancement to the Instance Metadata Service that uses session-oriented token-based requests to add defense-in-depth against unauthorized metadata access.
  • IMDSv2 requires a session token obtained via a PUT request before metadata can be retrieved, protecting against SSRF attacks and unauthorized access.
  • Sessions can last up to six hours and tokens can only be used from the EC2 instance where the session began.
  • Session token PUT requests are blocked if they contain an X-forwarded-for header (mitigates reverse proxy exploitation).
  • IMDSv2 enforcement timeline:
    • Mar 2024: Account-level setting available to set IMDSv2 as default for all new instance launches.
    • Mid-2024: All newly released EC2 instance types require IMDSv2 only (IMDSv1 disabled).
    • AWS Console Quick Starts and other launch pathways default to IMDSv2.
  • Methods to enforce IMDSv2:
    • Set account-level default using ModifyInstanceMetadataDefaults API
    • Set AMI-level property to require IMDSv2
    • Set instance metadata options during launch
    • Use declarative policies via AWS Organizations for multi-account, multi-region enforcement
  • When IMDSv2 is required, IMDSv1 is disabled — applications relying on IMDSv1 will break.
  • Default hop limit is set to 2 when IMDSv2 is required (supports containerized workloads).
  • Best Practice: Enforce IMDSv2 across all instances to prevent credential theft via SSRF attacks

IAM with EC2

  • IAM policy can be defined to allow or deny a user access to the EC2 resources and actions
  • EC2 partially supports resource-level permissions. For some EC2 API actions, you cannot specify which resource a user is allowed to work with for that action; instead, you have to allow users to work with all resources for that action
  • IAM allows to control only what actions a user can perform on the EC2 resources but cannot be used to grant access for users to be able to access or login to the instances

EC2 with IAM Role

  • EC2 instances can be launched with IAM roles so that the applications can securely make API requests from your instances.
  • IAM roles prevent the need to share as well as manage, rotate the security credentials that the applications use.
  • IAM role can be added to an existing running EC2 instance.
  • EC2 uses an instance profile as a container for an IAM role.
    • Creation of an IAM role using the console, creates an instance profile automatically and gives it the same name as the role it corresponds to.
    • When using the AWS CLI, API, or an AWS SDK to create a role, the role and instance profile needs to be created as separate actions, and they can be given different names.
    • One role per instance profile (this limit cannot be increased).
  • To launch an instance with an IAM role, the name of its instance profile needs to be specified.
  • An application on the instance can retrieve the security credentials provided by the role from the instance metadata item http://169.254.169.254/latest/meta-data/iam/security-credentials/role-name.
  • Security credentials are temporary and are rotated automatically and new credentials are made available at least five minutes prior to the expiration of the old credentials.
  • EC2 IAM role credentials are not subject to maximum session durations configured in the role.
  • Best Practice: Always launch EC2 instance with IAM role instead of hardcoded credentials

EC2 IAM Role S3 Access

AWS Verified Access

  • AWS Verified Access provides secure, VPN-less access to corporate applications and resources using zero-trust principles (“never trust, always verify”).
  • Evaluates each access request based on user identity and device health rather than network location.
  • Supports fine-grained access policies using the Cedar policy language.
  • Originally supported HTTP(S) applications only (GA April 2023).
  • Non-HTTP(S) protocol support (GA Feb 2025): Extends zero-trust access to SSH, RDP, JDBC, ODBC, and other TCP protocols.
    • Eliminates the need for VPNs or bastion hosts for SSH/RDP access to EC2 instances.
    • Simplifies security operations by using a single solution for all application types.
  • Integrates with third-party identity providers (IdPs) and device management solutions.
  • All access requests are logged for auditing and compliance.
  • Achieved FedRAMP High and Moderate authorization (Mar 2025).
  • Can be combined with AWS Network Firewall for deep packet inspection.

EC2 Resiliency

  • EC2 offers the following features to support your data resiliency:
    • Copying AMIs across Regions
    • Copying EBS snapshots across Regions
    • Automating EBS-backed AMIs using Data Lifecycle Manager
    • Automating EBS snapshots using Data Lifecycle Manager
    • Maintaining the health and availability of the fleet using EC2 Auto Scaling
    • Distributing incoming traffic across multiple instances in a single AZ or multiple AZs using Elastic Load Balancing
    • Using Recycle Bin to protect EBS snapshots, EBS-backed AMIs, and EBS Volumes from accidental deletion with configurable retention periods
    • Automatically deleting underlying EBS snapshots when deregistering AMIs (Jun 2025) to simplify cleanup

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. You launch an Amazon EC2 instance without an assigned AWS identity and Access Management (IAM) role. Later, you decide that the instance should be running with an IAM role. Which action must you take in order to have a running Amazon EC2 instance with an IAM role assigned to it?
    1. Create an image of the instance, and register the image with an IAM role assigned and an Amazon EBS volume mapping.
    2. Create a new IAM role with the same permissions as an existing IAM role, and assign it to the running instance. (As per AWS latest enhancement, this is possible now)
    3. Create an image of the instance, add a new IAM role with the same permissions as the desired IAM role, and deregister the image with the new role assigned.
    4. Create an image of the instance, and use this image to launch a new instance with the desired IAM role assigned (This was correct before, as it was not possible to add an IAM role to an existing instance)
  2. What does the following command do with respect to the Amazon EC2 security groups? ec2-revoke RevokeSecurityGroupIngress
    1. Removes one or more security groups from a rule.
    2. Removes one or more security groups from an Amazon EC2 instance.
    3. Removes one or more rules from a security group
    4. Removes a security group from our account.
  3. Which of the following cannot be used in Amazon EC2 to control who has access to specific Amazon EC2 instances?
    1. Security Groups
    2. IAM System
    3. SSH keys
    4. Windows passwords
  4. You must assign each server to at least _____ security group
    1. 3
    2. 2
    3. 4
    4. 1
  5. A company is building software on AWS that requires access to various AWS services. Which configuration should be used to ensure that AWS credentials (i.e., Access Key ID/Secret Access Key combination) are not compromised?
    1. Enable Multi-Factor Authentication for your AWS root account.
    2. Assign an IAM role to the Amazon EC2 instance
    3. Store the AWS Access Key ID/Secret Access Key combination in software comments.
    4. Assign an IAM user to the Amazon EC2 Instance.
  6. Which of the following items are required to allow an application deployed on an EC2 instance to write data to a DynamoDB table? Assume that no security keys are allowed to be stored on the EC2 instance. (Choose 2 answers)
    1. Create an IAM Role that allows write access to the DynamoDB table
    2. Add an IAM Role to a running EC2 instance. (As per AWS latest enhancement, this is possible now)
    3. Create an IAM User that allows write access to the DynamoDB table.
    4. Add an IAM User to a running EC2 instance.
    5. Launch an EC2 Instance with the IAM Role included in the launch configuration (This was correct before, as it was not possible to add an IAM role to an existing instance)
  7. You have an application running on an EC2 Instance, which will allow users to download files from a private S3 bucket using a pre-assigned URL. Before generating the URL the application should verify the existence of the file in S3. How should the application use AWS credentials to access the S3 bucket securely?
    1. Use the AWS account access Keys the application retrieves the credentials from the source code of the application.
    2. Create a IAM user for the application with permissions that allow list access to the S3 bucket launch the instance as the IAM user and retrieve the IAM user’s credentials from the EC2 instance user data.
    3. Create an IAM role for EC2 that allows list access to objects in the S3 bucket. Launch the instance with the role, and retrieve the role’s credentials from the EC2 Instance metadata
    4. Create an IAM user for the application with permissions that allow list access to the S3 bucket. The application retrieves the IAM user credentials from a temporary directory with permissions that allow read access only to the application user.
  8. A user has created an application, which will be hosted on EC2. The application makes calls to DynamoDB to fetch certain data. The application is using the DynamoDB SDK to connect with from the EC2 instance. Which of the below mentioned statements is true with respect to the best practice for security in this scenario?
    1. The user should attach an IAM role with DynamoDB access to the EC2 instance
    2. The user should create an IAM user with DynamoDB access and use its credentials within the application to connect with DynamoDB
    3. The user should create an IAM role, which has EC2 access so that it will allow deploying the application
    4. The user should create an IAM user with DynamoDB and EC2 access. Attach the user with the application so that it does not use the root account credentials
  9. Your application is leveraging IAM Roles for EC2 for accessing object stored in S3. Which two of the following IAM policies control access to you S3 objects.
    1. An IAM trust policy allows the EC2 instance to assume an EC2 instance role.
    2. An IAM access policy allows the EC2 role to access S3 objects
    3. An IAM bucket policy allows the EC2 role to access S3 objects. (Bucket policy is defined with S3 and not with IAM)
    4. An IAM trust policy allows applications running on the EC2 instance to assume as EC2 role (Trust policy allows EC2 instance to assume the role)
    5. An IAM trust policy allows applications running on the EC2 instance to access S3 objects. (Applications can access S3 through EC2 assuming the role)
  10. You have an application running on an EC2 Instance, which will allow users to download files from a private S3 bucket using a pre-assigned URL. Before generating the URL the application should verify the existence of the file in S3. How should the application use AWS credentials to access the S3 bucket securely?
    1. Use the AWS account access Keys the application retrieves the credentials from the source code of the application.
    2. Create a IAM user for the application with permissions that allow list access to the S3 bucket launch the instance as the IAM user and retrieve the IAM user’s credentials from the EC2 instance user data.
    3. Create an IAM role for EC2 that allows list access to objects in the S3 bucket. Launch the instance with the role, and retrieve the role’s credentials from the EC2 Instance metadata
    4. Create an IAM user for the application with permissions that allow list access to the S3 bucket. The application retrieves the IAM user credentials from a temporary directory with permissions that allow read access only to the application user.

New Practice Questions

  1. A company wants to provide secure SSH access to EC2 instances in private subnets without using bastion hosts, VPNs, or public IP addresses. Which AWS service should they use?
    1. AWS Direct Connect
    2. AWS Site-to-Site VPN
    3. EC2 Instance Connect Endpoint
    4. AWS PrivateLink
  2. A security team wants to protect EC2 instances from credential theft through SSRF (Server-Side Request Forgery) attacks targeting the instance metadata service. Which approach should they implement?
    1. Disable the instance metadata service entirely
    2. Use security groups to block metadata access
    3. Enforce IMDSv2 which requires session tokens for metadata access
    4. Encrypt the metadata service endpoint
  3. An organization uses multiple VPCs within the same account and region and wants to maintain consistent security group rules across all VPCs without duplication. Which feature should they use?
    1. VPC Peering with security group referencing
    2. Security Group VPC Associations
    3. AWS Network Firewall
    4. AWS Config rules
  4. A company is migrating to sixth-generation Nitro (Nitro v6) EC2 instances and experiencing dropped TCP connections for long-running idle workloads. What is the most likely cause?
    1. Security group rules are being modified
    2. Network ACLs are timing out
    3. The default TCP connection tracking idle timeout changed from 432,000 seconds to 350 seconds on Nitro v6 instances
    4. The instance is being stopped by Auto Scaling
  5. A company wants to implement zero-trust access for SSH and RDP connections to EC2 instances, evaluating user identity and device security posture for each request without requiring a VPN. Which AWS service provides this capability?
    1. EC2 Instance Connect Endpoint
    2. AWS Systems Manager Session Manager
    3. AWS Verified Access
    4. AWS Client VPN
  6. Which of the following key pair types are supported for EC2 Linux instances? (Choose 2)
    1. DSA
    2. RSA
    3. ED25519
    4. ECDSA

AWS EC2 Instance Lifecycle – States & Transitions

~ Last updated on : ~ jayendrapatil ~ 18 Comments

EC2 Instance Lifecycle Overview

  • EC2 instance lifecycle determines how an EC2 instance transitions through different states from the moment it is launched to its termination

EC2 Instance Lifecycle

Instance Launch

  • Pending
    • When the instance is first launched it enters into the pending state
  • Running
    • After the instance is launched, it enters into the running state
    • Charges are incurred for each second, with a one-minute minimum, that the instance is running, even if the instance remains idle

Instance Start & Stop (EBS-backed instances only)

  • Only an EBS-backed instance can be stopped and started.
  • Instance store-backed instance cannot be stopped and started.
  • An instance can be stopped & started in case the instance fails a status check or is not running as expected
  • Stop
    • After the instance is stopped, it enters in stopping state and then to stopped state.
    • Charges are only incurred for the EBS storage and not for the instance usage or data transfer.
    • While the instance is stopped, its root volume can be treated like any other volume, and modified for e.g. repair file system problems or update software or change the instance type, user data, EBS optimization attributes, etc
    • Volume can be detached from the stopped instance, and attached to a running instance, modified, detached from the running instance, and then reattached to the stopped instance. It should be reattached using the storage device name that’s specified as the root device in the block device mapping for the instance.
  • Start
    • When the instance is started, it enters into pending state and then into running
    • An instance, when stopped and started, is moved to a new host computer (though in some cases, it remains on the current host)
    • Any data on an instance store volume (not root volume) would be lost while data on the EBS volume persists
  • EC2 instance retains its private IP address as well as the Elastic IP address.
  • If the instance has an IPv6 address, it retains its IPv6 address.
  • However, the public IP address, if assigned instead of the Elastic IP address, would be released
  • For each transition of an instance from stopped to running, charges per second are incurred when the instance is running, with a minimum of one minute every time the instance is started

Instance Stop Protection

  • Stop protection (DisableApiStop attribute) can be enabled to prevent an instance from being accidentally stopped.
  • Stop protection also prevents accidental termination when using the console, AWS CLI, or API.
  • However, it does not automatically set the DisableApiTermination attribute.
  • Can be enabled at launch, while the instance is running, or while it is stopped.
  • Stop protection does not prevent:
    • Stopping an instance by initiating a shutdown from the OS (e.g., shutdown or poweroff command)
    • AWS from stopping the instance when there is a scheduled event
    • Amazon EC2 Auto Scaling from terminating an instance when unhealthy or during scale-in events
  • Cannot be enabled for instance store root volume instances or Spot Instances.

Instance Hibernate

  • Instance hibernation signals the operating system to perform hibernation (suspend-to-disk), which saves the contents from the instance memory (RAM) to the EBS root volume
  • Instance’s EBS root volume and any attached EBS data volumes are persisted, including the saved contents of the RAM.
  • Any EC2 instance store volumes remain attached to the instance, but the data on the instance store volumes is lost.
  • When the instance is restarted, the EBS root volume is restored to its previous state and the RAM contents are reloaded. Previously attached data volumes are reattached and the instance retains its instance ID.
  • After the instance is hibernated, it enters in stopping state and then to stopped state.
  • Billing Note: Unlike a regular stop, you are billed while the instance is in the stopping state during hibernation. You stop incurring charges once the instance is in the stopped state.
  • When the instance is restarted
    • It enters the pending state and the instance is moved to a new host computer (though in some cases, it remains on the current host).
    • EBS root volume is restored to its previous state
    • RAM contents are reloaded
    • Processes that were previously running on the instance are resumed
    • Previously attached data volumes are reattached and the instance retains its instance ID
    • Instance retains private IPv4 addresses and any IPv6 addresses
    • Instance retains its Elastic IP address
    • Instance releases its Public IPv4 address and would get a new one
  • Hibernation prerequisites
    • Supported instance families (significantly expanded):
      • General purpose: M3, M4, M5, M5a, M5ad, M5d, M6a, M6g, M6gd, M6i, M6id, M6idn, M6in, M7a, M7g, M7gd, M7i, M7i-flex, M8a, M8azn, M8g, M8gb, M8gd, M8gn, M8i, M8i-flex, M8in, M8idn, M8ib, M8idb, M9g, M9gd, T2, T3, T3a, T4g
      • Compute optimized: C3, C4, C5, C5d, C6a, C6g, C6gd, C6gn, C6i, C6id, C6in, C7a, C7g, C7gd, C7gn, C7i, C7i-flex, C8a, C8g, C8gb, C8gd, C8gn, C8i, C8i-flex, C8in, C8ib
      • Memory optimized: R3, R4, R5, R5a, R5ad, R5d, R6a, R6g, R6gd, R6idn, R6in, R7a, R7g, R7gd, R7i, R7iz, R8a, R8g, R8gb, R8gd, R8gn, R8i, R8i-flex, R8in, R8idn, R8ib, R8idb, X2gd, X8aedz, X8i
      • Storage optimized: I3, I3en, I4g, I7i, I7ie, I8g, I8ge, Im4gn, Is4gen
    • Instance RAM size – Linux: must be less than 150 GiB; Windows: must be less than or equal to 16 GiB.
    • Instance size – not supported for bare metal instances.
    • Supported AMIs must be an HVM AMI that supports hibernation (includes AL2023, Amazon Linux 2, Ubuntu 20.04/22.04, RHEL 8/9, Windows Server 2012-2022)
    • Graviton support (added July 2024): Hibernation is now supported on AWS Graviton-based instances (M6g, M7g, M8g, M9g, C6g, C7g, C8g, R6g, R7g, R8g, T4g, etc.)
    • Root volume type – must be EBS volume and not instance store
    • EBS root volume size – must be large enough to store the RAM contents
    • EBS root volume MUST be encrypted to ensure the protection of sensitive content that is in memory at the time of hibernation
    • EBS volume type – must be General Purpose SSD (gp2 or gp3) or Provisioned IOPS SSD (io1 or io2)
    • Enable hibernation at launch, as changing it is not supported on an existing instance
    • Purchasing options – On-Demand Instances and Spot Instances are supported. For Spot Instances, only Amazon EC2 can hibernate them (upon interruption).
  • Limitations or Unsupported Actions
    • Changing the instance type or size of a hibernated instance
    • Creating snapshots or AMIs from hibernated instances or instances for which hibernation is enabled
    • The data on any instance store volumes is lost
    • Can’t hibernate a Linux instance that has more than 150 GiB of RAM.
    • Can’t hibernate a Windows instance that has more than 16 GiB of RAM.
    • Can’t hibernate an instance that is in an Auto Scaling group or used by Amazon ECS. If the instance is in an Auto Scaling group and is hibernated, the EC2 Auto Scaling service marks the stopped instance as unhealthy, and may terminate it and launch a replacement instance.
    • An instance cannot be hibernated for more than 60 days.
  • Auto Scaling Warm Pools with Hibernation
    • EC2 Auto Scaling Warm Pools support hibernation as a pool state, allowing pre-initialized instances to be hibernated and quickly resumed when scaling out.
    • This is available in all commercial regions and AWS GovCloud (US) Regions (added Feb 2024).
    • Helps achieve faster scale-out by maintaining pre-warmed instances in a hibernated state.

Instance Reboot

  • Both EBS-backed and Instance store-backed instances can be rebooted
  • An instance remains on the same host computer and maintains its public DNS name, private IP address
  • Data on the EBS and Instance store volume is also retained
  • Rebooting an instance doesn’t start a new instance billing period; per-second billing continues without a further one-minute minimum charge.
  • AWS recommends using EC2 to reboot the instance instead of running the operating system reboot command from the instance as it performs a hard reboot if the instance does not cleanly shut down within four minutes also creates an API record in CloudTrail if enabled.

Instance Retirement

  • An instance is scheduled to be retired when AWS detects an irreparable failure of the underlying hardware hosting the instance.
  • When an instance reaches its scheduled retirement date, it is stopped or terminated by AWS.
  • If the instance root device is an EBS volume, the instance is stopped and can be started again at any time.
  • If the instance root device is an instance store volume, the instance is terminated, and cannot be used again.
  • AWS sends notifications (via email and AWS Health Dashboard) about scheduled retirements in advance.

Instance Termination

  • An instance can be terminated, and it enters into the shutting-down, and then the terminated state
  • After an instance is terminated, it can’t be connected and no charges are incurred
  • Instance Shutdown behavior
    • Each EBS-backed instance supports the InstanceInitiatedShutdownBehavior attribute which determines whether the instance would be stopped or terminated when a shutdown command is initiated from the instance itself for e.g. shutdown, halt or poweroff command in linux
    • Default behavior for the instance to be stopped.
    • A shutdown command for an Instance store-backed instance will always terminate the instance
  • Termination protection
    • Termination protection ( DisableApiTermination attribute) can be enabled on the instance to prevent it from being accidentally terminated
    • DisableApiTermination from the Console, CLI or API.
    • Instance can be terminated through EC2 CLI.
    • Termination protection does not work for instances when
      • part of an Autoscaling group
      • launched as Spot instances
      • terminating an instance by initiating shutdown from the instance (if InstanceInitiatedShutdownBehavior is set to terminate)
  • Data persistence
    • EBS volume has a DeleteOnTermination attribute which determines whether the volumes would be persisted or deleted when an instance they are associated with are terminated
    • Data on Instance store volume data does not persist
    • Default is to delete the root device volume and preserve any other EBS volumes. i.e.
      • Data on EBS root volumes have the DeleteOnTermination flag set to true and would be deleted by default
      • Additional EBS volumes attached have the DeleteOnTermination flag set to false are not deleted but just detached from the instance

Replace Root Volume

  • EC2 supports replacing the root volume of a running instance without stopping it.
  • The replacement volume can be based on the original launch snapshot, a different snapshot, or a new AMI.
  • Use cases include:
    • Restoring the root volume to its initial launch state
    • Quick OS patching or application updates
    • Troubleshooting boot issues without losing instance store data or networking configuration
  • The instance retains its instance ID, private IP addresses, Elastic IP addresses, instance store data, and network interface attachments.
  • EC2 Auto Scaling also supports a ReplaceRootVolume strategy within instance refresh (announced Nov 2025).

Simplified Automatic Recovery

  • If AWS detects that an instance is unavailable due to an underlying hardware or software issue (system status check failure), simplified automatic recovery can automatically restore instance availability.
  • The instance is moved from the host with the underlying issue to a different host.
  • The recovered instance retains its instance ID, private IP addresses, Elastic IP addresses, and all instance metadata.
  • Simplified automatic recovery is enabled by default on supported instance types (most Nitro-based instances).
  • Does not recover instances that fail an instance status check (only system status check failures).

Instance State Change Notifications

  • Amazon EC2 sends EC2 Instance State-change Notification events to Amazon EventBridge when an instance changes state (e.g., pending, running, stopping, stopped, shutting-down, terminated).
  • You can create EventBridge rules to trigger actions (Lambda functions, SNS notifications, etc.) based on specific state changes.
  • Useful for automation, monitoring, and alerting on instance lifecycle events.

EC2 Instance Lifecycle States and Billing

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. What does Amazon EC2 provide?
    1. Virtual servers in the Cloud
    2. A platform to run code (Java, PHP, Python), paying on an hourly basis.
    3. Computer Clusters in the Cloud.
    4. Physical servers, remotely managed by the customer.
  2. A user has enabled termination protection on an EC2 instance. The user has also set Instance initiated shutdown behavior to terminate. When the user shuts down the instance from the OS, what will happen?
    1. The OS will shutdown but the instance will not be terminated due to protection
    2. It will terminate the instance
    3. It will not allow the user to shutdown the instance from the OS
    4. It is not possible to set the termination protection when an Instance initiated shutdown is set to Terminate
  3. A user has launched an EC2 instance and deployed a production application in it. The user wants to prohibit any mistakes from the production team to avoid accidental termination. How can the user achieve this?
    1. The user can the set DisableApiTermination attribute to avoid accidental termination
    2. It is not possible to avoid accidental termination
    3. The user can set the Deletion termination flag to avoid accidental termination
    4. The user can set the InstanceInitiatedShutdownBehavior flag to avoid accidental termination
  4. You have been doing a lot of testing of your VPC Network by deliberately failing EC2 instances to test whether instances are failing over properly. Your customer who will be paying the AWS bill for all this asks you if he being charged for all these instances. You try to explain to him how the billing works on EC2 instances to the best of your knowledge. What would be an appropriate response to give to the customer in regards to this?
    1. Billing commences when Amazon EC2 AMI instance is completely up and billing ends as soon as the instance starts to shutdown.
    2. Billing commences when Amazon EC2 initiates the boot sequence of an AMI instance and billing ends when the instance shuts down.
    3. Billing only commences only after 1 hour of uptime and billing ends when the instance terminates.
    4. Billing commences when Amazon EC2 initiates the boot sequence of an AMI instance and billing ends as soon as the instance starts to shutdown.
  5. A company wants to prevent EC2 instances running critical databases from being accidentally stopped by developers. Which feature should they use?
    1. DisableApiTermination attribute
    2. InstanceInitiatedShutdownBehavior attribute
    3. DisableApiStop attribute (Stop Protection)
    4. EC2 instance store volumes
  6. Which of the following is true about EC2 instance hibernation? (Select TWO)
    1. Instance store volume data is preserved during hibernation
    2. The EBS root volume must be encrypted
    3. Hibernation can be enabled on an existing running instance
    4. RAM contents are saved to the EBS root volume
    5. An instance can be hibernated for up to 90 days
  7. A team wants to use EC2 hibernation with their Graviton-based M7g instances running Amazon Linux 2. Which statement is correct?
    1. Hibernation is not supported on Graviton-based instances
    2. Hibernation is supported on Graviton-based instances including M7g (added July 2024)
    3. Hibernation on Graviton requires instance store root volumes
    4. Hibernation on Graviton only supports Windows AMIs
  8. An application running on an EC2 instance experiences a system status check failure due to underlying hardware issues. If simplified automatic recovery is enabled, what happens?
    1. The instance is terminated and a new one is launched
    2. The instance remains on the same host and is rebooted
    3. The instance is moved to a different host while retaining its instance ID, IP addresses, and metadata
    4. The instance enters a stopped state and requires manual restart

References

AWS EC2 Instance Purchasing Option

~ Last updated on : ~ jayendrapatil ~ 27 Comments

AWS EC2 Instance Purchasing Options

  • Amazon provides different ways to pay for the EC2 instances
    • On-Demand Instances
    • Savings Plans
    • Reserved Instances
    • Spot Instances
    • Dedicated Hosts
    • Dedicated Instances
    • On-Demand Capacity Reservations
    • Capacity Blocks for ML
  • EC2 instances can be launched on shared or dedicated tenancy
  • AWS recommends Savings Plans over Reserved Instances for most use cases due to greater flexibility, though RIs still provide capacity reservations and slightly deeper discounts for narrow workloads

On-Demand Instances

  • Pay for the instances and the compute capacity used by the second (Linux, Windows, RHEL, Ubuntu) or by the hour (SUSE), depending on which instances you run
  • No long-term commitments or up-front payments
  • Instances can be scaled accordingly as per the demand
  • Although AWS makes effort to have the capacity to launch On-Demand instances, there might be instances during peak demand where the instance cannot be launched
  • Per-second billing (with a 60-second minimum) is available for Amazon Linux, Windows, RHEL (since April 2024), Ubuntu, and Ubuntu Pro instances across all Regions
  • SUSE Linux Enterprise Server instances are still billed per-hour
  • Well suited for
    • Users that want the low cost and flexibility of EC2 without any up-front payment or long-term commitment
    • Applications with short term, spiky, or unpredictable workloads that cannot be interrupted
    • Applications being developed or tested on EC2 for the first time

Savings Plans

  • Savings Plans are a flexible pricing model offering savings of up to 72% on AWS compute usage, in exchange for a commitment to a consistent amount of usage (measured in $/hour) for a 1 or 3-year term
  • Unlike Reserved Instances which commit to specific instance configurations, Savings Plans commit to a dollar-per-hour spend, providing significantly more flexibility
  • Savings Plans automatically apply to usage across accounts in an AWS Organization
  • AWS offers four types of Savings Plans:
    • Compute Savings Plans
      • Provide the most flexibility with savings up to 66% off On-Demand rates
      • Automatically apply to EC2 instance usage regardless of instance family, size, Region, OS, or tenancy
      • Also apply to AWS Fargate and AWS Lambda usage
      • Best for workloads where instance family or Region may change over time
    • EC2 Instance Savings Plans
      • Provide savings up to 72% off On-Demand (similar to Standard RIs)
      • Committed to a specific instance family in a chosen Region (e.g., M5 in us-east-1)
      • Automatically apply regardless of instance size, OS, and tenancy within the specified family
      • Best for stable workloads with a known instance family
    • SageMaker AI Savings Plans
      • Provide savings up to 64% off On-Demand rates for SageMaker AI usage
      • Apply regardless of instance family, size, Region, and component (Notebook, Training, Inference)
    • Database Savings Plans (Launched December 2025)
      • Provide savings up to 35% on AWS database services
      • Apply to Aurora, RDS, DynamoDB, ElastiCache, DocumentDB, Timestream, Neptune, Keyspaces, DMS, and Amazon OpenSearch Service
      • Automatically apply regardless of engine, instance family, size, AZ, or Region
      • Available only as a 1-year term with no upfront payment
  • Savings Plans can be returned within 7 days of purchase (announced March 2024)
  • Savings Plans purchases can be queued to align with expiring commitments
  • Well suited for
    • Applications with steady state or predictable usage where flexibility in instance configuration is desired
    • Organizations that want simplified commitment management across multiple services
    • Workloads that may change instance families, sizes, or Regions over time

Savings Plans vs Reserved Instances

  • Savings Plans commit to a spend rate ($/hour); Reserved Instances commit to a specific instance configuration
  • Savings Plans offer more flexibility; RIs can offer slightly deeper discounts (up to 72-75%) for narrow, stable workloads
  • Only RIs provide capacity reservations (when scoped to an AZ)
  • RIs can be sold on the RI Marketplace; Savings Plans cannot be resold
  • AWS recommends Savings Plans for most new commitments due to their flexibility and broader applicability

Reserved Instances

  • Reserved Instances provides lower hourly running costs by providing a billing discount (up to 72%) as well as capacity reservation that is applied to instances and there would never be a case of insufficient capacity (when scoped to an AZ)
  • Discounted usage price is fixed as long as you own the Reserved Instance, allowing compute costs prediction over the term of the reservation
  • Reserved instances are best suited if consistent, heavy, use is expected and they can provide savings over owning the hardware or running only On-Demand instances.
  • Well Suited for
    • Applications with steady state or predictable usage
    • Applications that require reserved capacity
    • Users are able to make upfront payments to reduce their total computing costs even further
  • Reserved instance is not a physical instance that is launched, but rather a billing discount applied to the use of On-Demand Instances
  • On-Demand Instances must match certain attributes, such as instance type and Region, in order to benefit from the billing discount.
  • Reserved Instances do not renew automatically, and the EC2 instances can be continued to be used but charged On-Demand rates
  • Auto Scaling or other AWS services can be used to launch the On-Demand instances that use the Reserved Instance benefits
  • With Reserved Instances
    • You pay for the entire term, regardless of the usage
    • Once purchased, the reservation cannot be canceled but can be sold in the Reserved Instance Marketplace
    • Reserved Instance pricing tier discounts only apply to purchases made from AWS, and not to the third party Reserved instances
    • As of January 2024, AWS prohibits the resale of RIs acquired at a discount (EDP) on the RI Marketplace
    • As of June 2025, AWS prohibits sharing of RIs and Savings Plans across end customers within a single AWS Organization (impacts MSPs/resellers)

Reserved Instance Pricing Key Variables

Instance attributes

A Reserved Instance has four instance attributes that determine its price.

  • Instance type: Instance family + Instance size e.g.m4.large composed of the instance family (m4) and the instance size (large).
  • Region: Region in which the Reserved Instance is purchased.
  • Tenancy: Whether your instance runs on shared (default) or single-tenant (dedicated) hardware.
  • Platform: Operating system; for example, Windows or Linux/Unix.

Term commitment

Reserved Instance can be purchased for a one-year or three-year commitment, with the three-year commitment offering a bigger discount.

  • One-year: A year is defined as 31536000 seconds (365 days).
  • Three-year: Three years is defined as 94608000 seconds (1095 days).

Payment options

  • No Upfront
    • No upfront payment is required and the account is charged at a discounted hourly rate for every hour, regardless of the usage
    • Only available as a 1-year reservation
  • Partial Upfront
    • A portion of the cost is paid upfront and the remaining hours in the term are charged at an hourly discounted rate, regardless of the usage
  • Full Upfront
    • Full payment is made at the start of the term, with no costs for the remainder of the term, regardless of the usage

Offering class

  • Standard: Provide the most significant discount (up to 72%), but can only be modified.
  • Convertible: Provide a lower discount (up to 66%) than Standard Reserved Instances, but can be exchanged for another Convertible Reserved Instance with different instance attributes. Convertible Reserved Instances can also be modified.

How Reserved Instances Work

Billing Benefits & Payment Options

  • Reserved Instance purchase reservation is automatically applied to running instances that match the specified parameters
  • Reserved Instance can also be utilized by launching On-Demand instances with the same configuration as to the purchased reserved capacity

Understanding Billing

  • Reserved Instances are billed for every clock-hour during the term that you select, regardless of whether the instance is running or not.
  • A Reserved Instance billing benefit can be applied to a running instance on a per-second basis. Per-second billing is available for instances using Amazon Linux, Windows, RHEL (since April 2024), and Ubuntu.
  • Per-hour billing is used for SUSE Linux Enterprise Server.
  • A Reserved Instance billing benefit can apply to a maximum of 3600 seconds (one hour) of instance usage per clock-hour. You can run multiple instances concurrently, but can only receive the benefit of the Reserved Instance discount for a total of 3600 seconds per clock-hour; instance usage that exceeds 3600 seconds in a clock-hour is billed at the On-Demand rate.

Consolidated Billing

  • Pricing benefits of Reserved Instances are shared when the purchasing account is part of a set of accounts billed under one consolidated billing payer account
  • Consolidated billing account aggregates the list value of member accounts within a region.
  • When the list value of all active Reserved Instances for the consolidated billing account reaches a discount pricing tier, any Reserved Instances purchased after this point by any member of the consolidated billing account are charged at the discounted rate (as long as the list value for that consolidated account stays above the discount pricing tier threshold)

Buying Reserved Instances

Buying Reserved Instances need a selection of the following

  • Platform (for example, Linux)
  • Instance type (for example, m5.large)
  • Availability Zone in which to run the instance for Zonal reserved instance
  • Term (time period) over which you want to reserve capacity
  • Tenancy – reserve capacity for shared or dedicated tenancy
  • Offering (No Upfront, Partial Upfront, All Upfront).

Modifying Reserved Instances

  • Standard or Convertible Reserved Instances can be modified and continue to benefit from the capacity reservation as the computing needs change.
  • Availability Zone, instance size (within the same instance family and generation), and scope of the Reserved Instance can be modified
  • All or a subset of the Reserved Instances can be modified
  • Two or more Reserved Instances can be merged into a single Reserved Instance
  • Modification does not change the remaining term of the Reserved Instances; their end dates remain the same.
  • There is no fee, and you do not receive any new bills or invoices.
  • Modification is separate from purchasing and does not affect how you use, purchase, or sell Reserved Instances.
  • Complete reservation or a subset of it can be modified in one or more of the following ways:
    • Switch Availability Zones within the same region
    • Change the scope between Regional and Zonal
    • Change the instance size within the same instance family and generation, given the instance size footprint (normalization factor) remains the same for e.g. four m4.medium instances (4 x 2), you can turn it into a reservation for eight m4.small instances (8 x 1) and vice versa. However, you cannot convert a reservation for a single m4.small instance (1 x 1) into a reservation for an m4.large instance (1 x 4).

Scheduled Reserved Instances (Discontinued)

⚠️ SERVICE DISCONTINUED

As of September 2024, Scheduled Reserved Instances are no longer available for purchase. AWS has no plans to make them available in the future.

Alternative: Use On-Demand Capacity Reservations (including future-dated reservations) instead.

  • Scheduled Reserved Instances (Scheduled Instances) previously enabled capacity reservations that recurred on a daily, weekly, or monthly basis, with a specified start time and duration, for a one-year term.
  • They were suited for workloads that do not run continuously, but do run on a regular schedule
  • This content is maintained for historical reference only.

On-Demand Capacity Reservations

  • On-Demand Capacity Reservations enable you to reserve compute capacity for the EC2 instances in a specific AZ for any duration.
  • This gives you the ability to create and manage Capacity Reservations independently from the billing discounts offered by Savings Plans or regional Reserved Instances.
  • By creating Capacity Reservations, you ensure that you always have access to EC2 capacity when you need it, for as long as you need it.
  • Capacity Reservations can be created at any time, without entering into a one-year or three-year term commitment, and the capacity is available immediately.
  • Billing starts as soon as the capacity is provisioned and the Capacity Reservation enters the active state. Charged at the equivalent On-Demand rate whether instances run in the reserved capacity or not.
  • When no longer needed, the Capacity Reservation can be canceled to stop incurring charges.
  • Savings Plans and Regional RIs apply to both unused reservations and instances running on the reservation, reducing effective cost.
  • Capacity Reservation creation requires
    • AZ in which to reserve the capacity
    • Number of instances for which to reserve capacity
    • Instance attributes, including the instance type, tenancy, and platform/OS
  • Capacity Reservations can only be used by instances that match their attributes. By default, they are automatically used by running instances that match the attributes. If you don’t have any running instances that match the attributes of the Capacity Reservation, it remains unused until you launch an instance with matching attributes.

Future-Dated Capacity Reservations (November 2024)

  • You can now plan and schedule Capacity Reservations up to 120 days in advance
  • Specify the capacity needed, start date, delivery preference, and minimum commitment duration
  • No upfront charges to schedule a future-dated Capacity Reservation
  • AWS evaluates the request (usually within 5 days) and changes status to “Scheduled” if supportable
  • On the scheduled date, the reservation activates automatically and instances can be launched immediately
  • Minimum commitment is typically 14 days; recommended to request at least 56 days (8 weeks) in advance
  • Ideal for planned events such as product launches, large migrations, or seasonal sales events

Split, Move, and Modify (August 2024)

  • Split: Separate available capacity from an existing reservation into a new reservation
  • Move: Move available capacity from one reservation into another with matching configuration
  • Modify: Change additional attributes like instance count
  • Provides flexibility to redistribute capacity across teams and accounts

Interruptible Capacity Reservations (November 2025)

  • Make unused compute capacity in your reservations temporarily available to other workloads within your account
  • Maintain control to reclaim capacity when needed – instances running on interruptible reservations are terminated when capacity is reclaimed
  • Helps optimize reservation utilization and reduce costs
  • Can share unused capacity across accounts within an AWS Organization

Capacity Reservation Fleets

  • A Capacity Reservation Fleet is a group of Capacity Reservations
  • Reserve large amounts of capacity across multiple instance types using a single request up to a specified target capacity
  • Manage all reservations in the fleet collectively by modifying or canceling the fleet

EC2 Capacity Blocks for ML

  • EC2 Capacity Blocks allow you to reserve GPU-based accelerated computing instances for machine learning workloads
  • Reserve instances for up to six months in cluster sizes of 1 to 64 instances (512 GPUs or 1024 Trainium chips)
  • Can be reserved up to eight weeks in advance
  • Support instant start times and extensions (since November 2024)
  • Supported instance types include P4d, P5, P5e, P5en, and Trn1
  • Pricing consists of a reservation fee and an operating system fee; prices are updated regularly based on supply and demand
  • Pay upfront for the reserved capacity
  • Ideal for short-duration ML workloads such as model training, fine-tuning, and experimentation
  • Different from On-Demand Capacity Reservations – specifically designed for GPU/ML chip capacity

Spot Instances

Refer blog post @ EC2 Spot Instances

Dedicated Instances

  • Dedicated Instances are EC2 instances that run in a VPC on hardware that’s dedicated to a single customer
  • Dedicated Instances are physically isolated at the host hardware level from the instances that aren’t Dedicated Instances and from instances that belong to other AWS accounts.
  • There are no performance, security, or physical differences between Dedicated Instances and instances on Dedicated Hosts.
  • Each VPC has a related instance tenancy attribute.
    • default
      • default is shared.
      • the tenancy can be changed to dedicated after creation
      • all instances launched would be shared, unless you explicitly specify a different tenancy during instance launch.
    • dedicated
      • all instances launched would be dedicated
      • the tenancy can’t be changed to default after creation
  • Each instance launched into a VPC has a tenancy attribute. Default tenancy depends on the VPC tenancy, which by default is shared.
    • default – instance runs on shared hardware.
    • dedicated – instance runs on single-tenant hardware.
    • host – instance runs on a Dedicated Host, which is an isolated server with configurations that you can control.
    • default tenancy cannot be changed to dedicated or host and vice versa.
    • dedicated tenancy can be changed to host and vice versa
  • Dedicated Instances can be launched using
    • Create the VPC with the instance tenancy set to dedicated, all instances launched into this VPC are Dedicated Instances even though if you mark the tenancy as shared.
    • Create the VPC with the instance tenancy set to default, and specify dedicated tenancy for any instances that should be Dedicated Instances when launched.
  • Dedicated Instances are charged a per-region fee of $2/hour whenever at least one Dedicated Instance is running in the Region (not discounted by Savings Plans)

Dedicated Hosts

  • EC2 Dedicated Host is a physical server with EC2 instance capacity fully dedicated to your use
  • Dedicated Hosts allow using existing per-socket, per-core, or per-VM software licenses, including Windows Server, Microsoft SQL Server, SUSE, Red Hat Enterprise Linux, or other software licenses bound to VMs, sockets, or physical cores.
  • Dedicated Hosts provide visibility and control over instance placement and support host affinity
  • Can launch and run instances on specific hosts, and ensure that instances run only on specific hosts
  • Host Maintenance with Live Migration (October 2024): AWS can now automatically migrate instances to a replacement Dedicated Host without stopping them when maintenance is required, improving uptime and reducing operational effort
  • Host maintenance options include:
    • Live migration – instances are migrated to a new host within 24 hours without stopping
    • Reboot-based maintenance – instances are rebooted on a replacement host
  • Dedicated Hosts can be purchased On-Demand or as Reserved Instances (1 or 3-year term) or covered by Savings Plans

Dedicated Hosts vs Dedicated Instances

Feature Dedicated Instances Dedicated Hosts
Billing Per-instance + per-region fee Per-host billing
Visibility of sockets, cores, host ID No Yes
Host and instance affinity No Yes
Targeted instance placement No Yes
Automatic instance recovery Yes Yes
BYOL (Bring Your Own License) No Yes
Capacity reservation No Yes (host-level)

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. If I want my instance to run on a single-tenant hardware, which value do I have to set the instance’s tenancy attribute to?
    1. dedicated
    2. isolated
    3. one
    4. reserved
  2. You have a video transcoding application running on Amazon EC2. Each instance polls a queue to find out which video should be transcoded, and then runs a transcoding process. If this process is interrupted, the video will be transcoded by another instance based on the queuing system. You have a large backlog of videos, which need to be transcoded, and would like to reduce this backlog by adding more instances. You will need these instances only until the backlog is reduced. Which type of Amazon EC2 instances should you use to reduce the backlog in the most cost efficient way?
    1. Reserved instances
    2. Spot instances
    3. Dedicated instances
    4. On-demand instances
  3. The one-time payment for Reserved Instances is __________ refundable if the reservation is cancelled.
    1. always
    2. in some circumstances
    3. never
  4. You run a web application where web servers on EC2 Instances are In an Auto Scaling group. Monitoring over the last 6 months shows that 6 web servers are necessary to handle the minimum load. During the day up to 12 servers are needed. Five to six days per year, the number of web servers required might go up to 15. What would you recommend to minimize costs while being able to provide full availability?
    1. 6 Reserved instances (heavy utilization). 6 Reserved instances (medium utilization), rest covered by On-Demand instances
    2. 6 Reserved instances (heavy utilization). 6 On-Demand instances, rest covered by Spot Instances (don’t go for spot as availability not guaranteed)
    3. 6 Reserved instances (heavy utilization) 6 Spot instances, rest covered by On-Demand instances (don’t go for spot as availability not guaranteed)
    4. 6 Reserved instances (heavy utilization) 6 Reserved instances (medium utilization) rest covered by Spot instances (don’t go for spot as availability not guaranteed)
  5. A user is running one instance for only 3 hours every day. The user wants to save some cost with the instance. Which of the below mentioned options is advised in this case?
    1. The user should not use RI; instead only go with the on-demand pricing (Scheduled Reserved Instances are no longer available. On-Demand Capacity Reservations with future-dated scheduling could be considered for recurring workloads, but for cost savings, On-Demand remains the best option for 3 hours/day usage)
    2. The user should use the AWS heavy utilized RI
    3. The user should use the AWS medium utilized RI
    4. The user should use Savings Plans
  6. Which of the following are characteristics of a reserved instance? Choose 3 answers
    1. It can be migrated across Availability Zones (can be modified)
    2. It is specific to an Amazon Machine Image (AMI) (specific to platform, not AMI)
    3. It can be applied to instances launched by Auto Scaling (are allowed)
    4. It is specific to an instance Type (specific to instance family but instance size can be changed within same family)
    5. It can be used to lower Total Cost of Ownership (TCO) of a system (helps to reduce cost)
  7. You have a distributed application that periodically processes large volumes of data across multiple Amazon EC2 Instances. The application is designed to recover gracefully from Amazon EC2 instance failures. You are required to accomplish this task in the most cost-effective way. Which of the following will meet your requirements?
    1. Spot Instances
    2. Reserved instances
    3. Dedicated instances
    4. On-Demand instances
  8. Can I move a Reserved Instance from one Region to another?
    1. No
    2. Only if they are moving into GovCloud
    3. Yes
    4. Only if they are moving to US East from another region
  9. An application you maintain consists of multiple EC2 instances in a default tenancy VPC. This application has undergone an internal audit and has been determined to require dedicated hardware for one instance. Your compliance team has given you a week to move this instance to single-tenant hardware. Which process will have minimal impact on your application while complying with this requirement?
    1. Create a new VPC with tenancy=dedicated and migrate to the new VPC (possible but impact not minimal)
    2. Use ec2-reboot-instances command line and set the parameter dedicated=true
    3. Right click on the instance, select properties and check the box for dedicated tenancy
    4. Stop the instance, create an AMI, launch a new instance with tenancy=dedicated, and terminate the old instance
  10. Your department creates regular analytics reports from your company’s log files. All log data is collected in Amazon S3 and processed by daily Amazon Elastic Map Reduce (EMR) jobs that generate daily PDF reports and aggregated tables in CSV format for an Amazon Redshift data warehouse. Your CFO requests that you optimize the cost structure for this system. Which of the following alternatives will lower costs without compromising average performance of the system or data integrity for the raw data? [PROFESSIONAL]
    1. Use reduced redundancy storage (RRS) for PDF and CSV data in Amazon S3. Add Spot instances to Amazon EMR jobs. Use Reserved Instances for Amazon Redshift. (Spot instances impacts performance)
    2. Use reduced redundancy storage (RRS) for all data in S3. Use a combination of Spot instances and Reserved Instances for Amazon EMR jobs. Use Reserved instances for Amazon Redshift (Combination of the Spot and reserved with guarantee performance and help reduce cost. Also, RRS would reduce cost and guarantee data integrity, which is different from data durability )
    3. Use reduced redundancy storage (RRS) for all data in Amazon S3. Add Spot Instances to Amazon EMR jobs. Use Reserved Instances for Amazon Redshift (Spot instances impacts performance)
    4. Use reduced redundancy storage (RRS) for PDF and CSV data in S3. Add Spot Instances to EMR jobs. Use Spot Instances for Amazon Redshift. (Spot instances impacts performance)
  11. A research scientist is planning for the one-time launch of an Elastic MapReduce cluster and is encouraged by her manager to minimize the costs. The cluster is designed to ingest 200TB of genomics data with a total of 100 Amazon EC2 instances and is expected to run for around four hours. The resulting data set must be stored temporarily until archived into an Amazon RDS Oracle instance. Which option will help save the most money while meeting requirements? [PROFESSIONAL]
    1. Store ingest and output files in Amazon S3. Deploy on-demand for the master and core nodes and spot for the task nodes.
    2. Optimize by deploying a combination of on-demand, RI and spot-pricing models for the master, core and task nodes. Store ingest and output files in Amazon S3 with a lifecycle policy that archives them to Amazon Glacier. (Reserved Instance not cost effective for 4 hour job and data not needed in S3 once moved to RDS)
    3. Store the ingest files in Amazon S3 RRS and store the output files in S3. Deploy Reserved Instances for the master and core nodes and on-demand for the task nodes. (Reserved Instance not cost effective)
    4. Deploy on-demand master, core and task nodes and store ingest and output files in Amazon S3 RRS (RRS provides not much cost benefits for a 4 hour job while the amount of input data would take time to upload and Output data to reproduce)
  12. A company currently has a highly available web application running in production. The application’s web front-end utilizes an Elastic Load Balancer and Auto scaling across 3 availability zones. During peak load, your web servers operate at 90% utilization and leverage a combination of heavy utilization reserved instances for steady state load and on-demand and spot instances for peak load. You are asked with designing a cost effective architecture to allow the application to recover quickly in the event that an availability zone is unavailable during peak load. Which option provides the most cost effective high availability architectural design for this application? [PROFESSIONAL]
    1. Increase auto scaling capacity and scaling thresholds to allow the web-front to cost-effectively scale across all availability zones to lower aggregate utilization levels that will allow an availability zone to fail during peak load without affecting the applications availability. (Ideal for HA to reduce and distribute load)
    2. Continue to run your web front-end at 90% utilization, but purchase an appropriate number of utilization RIs in each availability zone to cover the loss of any of the other availability zones during peak load. (90% is not recommended as well RIs would increase the cost)
    3. Continue to run your web front-end at 90% utilization, but leverage a high bid price strategy to cover the loss of any of the other availability zones during peak load. (90% is not recommended as high bid price would not guarantee instances and would increase cost)
    4. Increase use of spot instances to cost effectively to scale the web front-end across all availability zones to lower aggregate utilization levels that will allow an availability zone to fail during peak load without affecting the applications availability. (Availability cannot be guaranteed)
  13. You run accounting software in the AWS cloud. This software needs to be online continuously during the day every day of the week, and has a very static requirement for compute resources. You also have other, unrelated batch jobs that need to run once per day at any time of your choosing. How should you minimize cost? [PROFESSIONAL]
    1. Purchase a Heavy Utilization Reserved Instance to run the accounting software. Turn it off after hours. Run the batch jobs with the same instance class, so the Reserved Instance credits are also applied to the batch jobs. (Because the instance will always be online during the day, in a predictable manner, and there are sequences of batch jobs to perform at any time, we should run the batch jobs when the account software is off. We can achieve Heavy Utilization by alternating these times, so we should purchase the reservation as such, as this represents the lowest cost. There is no such thing a “Full” level utilization purchases on EC2.)
    2. Purchase a Medium Utilization Reserved Instance to run the accounting software. Turn it off after hours. Run the batch jobs with the same instance class, so the Reserved Instance credits are also applied to the batch jobs.
    3. Purchase a Light Utilization Reserved Instance to run the accounting software. Turn it off after hours. Run the batch jobs with the same instance class, so the Reserved Instance credits are also applied to the batch jobs.
    4. Purchase a Full Utilization Reserved Instance to run the accounting software. Turn it off after hours. Run the batch jobs with the same instance class, so the Reserved Instance credits are also applied to the batch jobs.

New Practice Questions

  1. A company wants to reduce EC2 costs but anticipates changing instance families and Regions over the next year as they modernize their architecture. Which purchasing option provides the most flexibility while still offering significant savings?
    1. Standard Reserved Instances
    2. Convertible Reserved Instances
    3. Compute Savings Plans (Compute Savings Plans provide up to 66% savings and apply regardless of instance family, size, Region, OS, or tenancy)
    4. EC2 Instance Savings Plans
  2. A company needs guaranteed EC2 capacity for a planned product launch event in 3 months. They want to reserve capacity without paying until the capacity is actually used. Which option best meets this requirement?
    1. Purchase Reserved Instances 3 months in advance
    2. Create a future-dated On-Demand Capacity Reservation (Future-dated CRs can be scheduled up to 120 days in advance with no upfront charges. Billing starts only when the reservation activates on the scheduled date)
    3. Purchase Savings Plans
    4. Use EC2 Capacity Blocks
  3. A machine learning team needs to reserve GPU capacity (P5 instances) for a 2-week training job that will start in 4 weeks. Which EC2 purchasing option is most appropriate?
    1. On-Demand Instances
    2. Spot Instances
    3. Reserved Instances
    4. EC2 Capacity Blocks for ML (Capacity Blocks are designed specifically for short-duration ML workloads, supporting GPU reservations up to 6 months, reservable up to 8 weeks in advance)
  4. Which of the following statements about Savings Plans is CORRECT? (Select TWO)
    1. Compute Savings Plans apply to EC2, Lambda, and Fargate usage
    2. Savings Plans provide capacity reservations
    3. Savings Plans can be returned within 7 days of purchase
    4. EC2 Instance Savings Plans apply across all Regions
    5. Savings Plans can be sold on the RI Marketplace
  5. A company has unused On-Demand Capacity Reservations for 50 instances, but only uses 30 instances most of the time. They want to allow other teams in their organization to temporarily use the unused capacity. Which feature should they use?
    1. Capacity Reservation Fleets
    2. Split Capacity Reservations
    3. Interruptible Capacity Reservations (Interruptible CRs allow making unused capacity temporarily available to other workloads while maintaining control to reclaim it when needed)
    4. Future-dated Capacity Reservations
  6. Which of the following correctly describes the difference between Reserved Instances and Savings Plans? (Select TWO)
    1. Reserved Instances scoped to an AZ provide capacity reservation; Savings Plans do not
    2. Savings Plans offer deeper discounts than Standard RIs
    3. Reserved Instances can cover Lambda and Fargate; Savings Plans cannot
    4. Savings Plans commit to a dollar-per-hour spend; RIs commit to specific instance configurations
    5. Savings Plans require a 3-year minimum commitment

References