AWS Elastic Block Store Storage – EBS

EC2 Elastic Block Store – EBS

  • Elastic Block Store – EBS provides highly available, reliable, durable, block-level storage volumes that can be attached to an EC2 instance.
  • EBS as a primary storage device is recommended for data that requires frequent and granular updates e.g. running a database or filesystem.
  • An EBS volume
    • behaves like a raw, unformatted, external block device that can be attached to a single EC2 instance at a time (except with Multi-Attach enabled io1/io2 volumes).
    • persists independently from the running life of an instance.
    • is Zonal and can be attached to any instance within the same Availability Zone and can be used like any other physical hard drive.
    • is particularly well-suited for use as the primary storage for file systems, databases, or any applications that require fine granular updates and access to raw, unformatted, block-level storage.
    • is designed for 99.999% availability and offers 99.999% durability for io2 Block Express volumes (0.001% annual failure rate).

Elastic Block Storage Features

  • EBS Volumes are created in a specific Availability Zone and can be attached to any instance in that same AZ.
  • Volumes can be backed up by creating a snapshot of the volume, which is stored in S3.
  • Volumes can be created from a snapshot that can be attached to another instance within the same region.
  • Volumes can be made available outside of the AZ by creating and restoring the snapshot to a new volume anywhere in that region.
  • Snapshots can also be copied to other regions and then restored to new volumes, making it easier to leverage multiple AWS regions for geographical expansion, data center migration, and disaster recovery.
  • Volumes allow encryption using the EBS encryption feature. All data stored at rest, disk I/O, and snapshots created from the volume are encrypted.
  • Encryption occurs on the EC2 instance, providing encryption of data-in-transit from EC2 to the EBS volume.
  • Elastic Volumes help easily adapt the volumes as the needs of the applications change. Elastic Volumes allow you to dynamically increase capacity, tune performance, and change the type of any new or existing current generation volume with no downtime or performance impact.
  • You can dynamically increase size, modify the provisioned IOPS capacity, and change volume type on live production volumes.
  • EBS now supports up to four Elastic Volumes modifications per volume within a rolling 24-hour window (previously required a 6-hour cooldown between modifications). A new modification can be initiated as soon as the previous one completes.
  • General Purpose SSD (gp3) volumes support up to 80,000 IOPS and 2,000 MiB/s of throughput with up to 64 TiB capacity (increased from 16,000 IOPS, 1,000 MiB/s, and 16 TiB in September 2025).
  • Provisioned IOPS SSD (io2 Block Express) volumes support up to 256,000 IOPS and 4,000 MB/s of throughput with up to 64 TiB capacity and sub-millisecond latency.

EBS Benefits

  • Data Availability
    • Data is automatically replicated in an Availability Zone to prevent data loss due to the failure of any single hardware component.
    • io2 Block Express volumes are designed for 99.999% durability (0.001% annual failure rate), while other volume types provide 99.8%-99.9% durability.
  • Data Persistence
    • persists independently of the running life of an EC2 instance
    • persists when an instance is stopped, started, or rebooted
    • Root volume is deleted, by default, on Instance termination but the behaviour can be changed using the DeleteOnTermination flag
    • All attached volumes persist, by default, on instance termination
  • Data Encryption
    • can be encrypted by the EBS encryption feature
    • uses 256-bit AES-256 and an Amazon-managed key infrastructure.
    • Encryption occurs on the server that hosts the EC2 instance, providing encryption of data-in-transit from the EC2 instance to EBS storage
    • Snapshots of encrypted EBS volumes are automatically encrypted.
    • EBS encryption by default can be enabled at the account level per region, so all new volumes created are automatically encrypted.
  • Snapshots
    • provides the ability to create snapshots (backups) of any EBS volume and write a copy of the data in the volume to S3, where it is stored redundantly in multiple Availability Zones.
    • can be used to create new volumes, increase the size of the volumes or replicate data across Availability Zones or Regions.
    • are incremental backups and store only the data that was changed from the time the last snapshot was taken.
    • Snapshot size can probably be smaller than the volume size as the data is compressed before being saved to S3.
    • Even though snapshots are saved incrementally, the snapshot deletion process is designed so that you need to retain only the most recent snapshot in order to restore the volume.

EBS Volume Types

Refer blog post @ EBS Volume Types

EBS Volume

EBS Volume Creation

  • Creating New volumes
    • Completely new from console or command line tools and can then be attached to an EC2 instance in the same Availability Zone.
  • Restore volume from Snapshots
    • Volumes can also be restored from previously created snapshots
    • New volumes created from existing snapshots are loaded lazily in the background.
    • There is no need to wait for all of the data to transfer from S3 to the volume before the attached instance can start accessing the volume and all its data.
    • If the instance accesses the data that hasn’t yet been loaded, the volume immediately downloads the requested data from S3, and continues loading the rest of the data in the background.
    • Volumes restored from encrypted snapshots are always encrypted, by default.
    • Provisioned Rate for Volume Initialization (May 2025) allows specifying an initialization rate (up to 300 MiB/s) to accelerate the transfer of snapshot data to new volumes, ensuring fully performant volumes within a predictable time frame.
  • Volumes can be created and attached to a running EC2 instance by specifying a block device mapping

EBS Volume Clones (Oct 2025)

  • EBS Volume Clones allow creating instant point-in-time copies of EBS volumes within the same Availability Zone with a single API call.
  • Cloned volumes are available within seconds and provide immediate access to data with single-digit millisecond latency.
  • Data is copied lazily in the background without impacting the performance of the source volume.
  • Eliminates the previous multi-step process of taking snapshots and creating volumes from them for same-AZ copies.
  • Useful for quickly setting up test/development environments with production data.

EBS Volume Detachment

  • EBS volumes can be detached from an instance explicitly or by terminating the instance.
  • EBS root volumes can be detached by stopping the instance.
  • EBS data volumes, attached to a running instance, can be detached by unmounting the volume from the instance first.
  • If the volume is detached without being unmounted, it might result in the volume being stuck in a busy state and could possibly damage the file system or the data it contains.
  • EBS volume can be force detached from an instance, using the Force Detach option, but it might lead to data loss or a corrupted file system as the instance does not get an opportunity to flush file system caches or file system metadata.
  • Charges are still incurred for the volume after its detachment

EBS Volume Deletion

  • EBS volume deletion would wipe out its data and the volume can’t be attached to any instance. However, it can be backed up before deletion using EBS snapshots
  • Recycle Bin for EBS Volumes (Nov 2025) allows setting retention periods for deleted volumes. Deleted volumes can be recovered within the retention period with all attributes (tags, permissions, encryption status) preserved.

EBS Volume Resize

  • EBS Elastic Volumes can be modified to increase the volume size, change the volume type, or adjust the performance of your EBS volumes.
  • If the instance supports Elastic Volumes, changes can be performed without detaching the volume or restarting the instance.
  • Volumes can be modified up to four times within a rolling 24-hour window (enhanced Jan 2026, previously limited to one modification with a 6-hour cooldown).

EBS Volume Snapshots

Refer blog post @ EBS Snapshot

EBS Snapshot Lock

  • EBS Snapshot Lock (Nov 2023) enables locking snapshots to protect them from inadvertent or malicious deletions for compliance and data retention requirements.
  • Snapshots can be locked for a duration ranging from 1 day to approximately 100 years.
  • Supports WORM (Write Once Read Many) compliance requirements.
  • Locked snapshots cannot be deleted until the lock duration expires.
  • No additional cost for locking snapshots.

EBS Snapshots Archive

  • EBS Snapshots Archive provides a low-cost storage tier for long-term retention of rarely-accessed snapshots.
  • Up to 75% lower cost compared to standard snapshot storage.
  • Archived snapshots can be restored when needed (restoration takes 24-72 hours).
  • Amazon Data Lifecycle Manager can automate archival and retention policies.

Recycle Bin for Snapshots

  • Recycle Bin enables restoration of accidentally deleted EBS Snapshots and EBS-backed AMIs.
  • Supports customized delete protection with exclusion tags (Nov 2024) to exclude non-critical resources.
  • Supports CloudFormation for managing Recycle Bin rules (Nov 2024).
  • Supports IPv6 endpoints (Dec 2024).
  • Now also supports EBS Volumes (Nov 2025) in addition to snapshots and AMIs.

EBS Encryption

  • EBS volumes can be created and attached to a supported instance type and support the following types of data
    • Data at rest
    • All disk I/O i.e All data moving between the volume and the instance
    • All snapshots created from the volume
    • All volumes created from those snapshots
  • Encryption occurs on the servers that host EC2 instances, providing encryption of data-in-transit from EC2 instances to EBS storage.
  • EBS encryption is supported with all EBS volume types (gp3, gp2, io2, io1, st1, and sc1), and has the same IOPS performance on encrypted volumes as with unencrypted volumes, with a minimal effect on latency
  • EBS encryption is available on all current generation instance types and select previous generation types.
  • Volumes created from encrypted snapshots and snapshots of encrypted volumes are automatically encrypted using the same encryption key.
  • EBS encryption uses AWS KMS keys (formerly called customer master keys/CMK) when creating encrypted volumes and any snapshots created from the encrypted volumes.
  • EBS volumes can be encrypted using either
    • the AWS managed key (aws/ebs) created for you automatically in each region.
    • a customer managed key that you created separately using AWS KMS, giving you more flexibility, including the ability to create, rotate, disable, define access controls, and audit the encryption keys used to protect your data.
  • Encryption by default can be enabled at the account level per region. When enabled, all new EBS volumes and snapshot copies are automatically encrypted.
  • Public or shared snapshots of encrypted volumes are not supported, because other accounts would be able to decrypt your data and needs to be migrated to an unencrypted status before sharing.
  • Existing unencrypted volumes cannot be encrypted directly, but can be migrated by
    • Option 1
      • create an unencrypted snapshot from the volume
      • create an encrypted copy of an unencrypted snapshot
      • create an encrypted volume from the encrypted snapshot
    • Option 2
      • create an unencrypted snapshot from the volume
      • create an encrypted volume from an unencrypted snapshot (selecting encryption during volume creation)
  • An encrypted snapshot can be created from an unencrypted snapshot by creating an encrypted copy of the unencrypted snapshot.
  • Unencrypted volume cannot be created from an encrypted volume directly but needs to be migrated

EBS Multi-Attach

  • EBS Multi-Attach allows attaching a single Provisioned IOPS SSD (io1 or io2) volume to up to 16 Nitro System-based EC2 instances within the same Availability Zone.
  • All attached instances have full read and write access to the shared volume.
  • io2 Block Express volumes support NVMe reservations for I/O fencing, enabling shared storage with proper coordination between instances (enabled by default for io2 volumes created after Sept 18, 2023).
  • Multi-Attach can be enabled for io2 volumes after creation (if not attached to any instances). For io1, it must be enabled at creation time.
  • Requires a cluster-aware file system (not standard XFS or EXT4) for data resiliency in production.

Refer blog Post @ EBS Multi-Attach

EBS Performance

Refer blog Post @ EBS Performance

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. _____ is a durable, block-level storage volume that you can attach to a single, running Amazon EC2 instance.
    1. Amazon S3
    2. Amazon EBS
    3. None of these
    4. All of these
  2. Which Amazon storage do you think is the best for my database-style applications that frequently encounter many random reads and writes across the dataset?
    1. None of these.
    2. Amazon Instance Storage
    3. Any of these
    4. Amazon EBS
  3. What does Amazon EBS stand for?
    1. Elastic Block Storage
    2. Elastic Business Server
    3. Elastic Blade Server
    4. Elastic Block Store
  4. Which Amazon Storage behaves like raw, unformatted, external block devices that you can attach to your instances?
    1. None of these.
    2. Amazon Instance Storage
    3. Amazon EBS
    4. All of these
  5. A user has created numerous EBS volumes. What is the general limit for each AWS account for the maximum number of EBS volumes that can be created?
    1. 10000
    2. 5000
    3. 100
    4. 1000
  6. Select the correct set of steps for exposing the snapshot only to specific AWS accounts
    1. Select Public for all the accounts and check mark those accounts with whom you want to expose the snapshots and click save.
    2. Select Private and enter the IDs of those AWS accounts, and click Save.
    3. Select Public, enter the IDs of those AWS accounts, and click Save.
    4. Select Public, mark the IDs of those AWS accounts as private, and click Save.
  7. If an Amazon EBS volume is the root device of an instance, can I detach it without stopping the instance?
    1. Yes but only if Windows instance
    2. No
    3. Yes
    4. Yes but only if a Linux instance
  8. Can we attach an EBS volume to more than one EC2 instance at the same time?
    1. Yes, with Multi-Attach enabled io1/io2 volumes to up to 16 Nitro-based instances in the same AZ
    2. No
    3. Only EC2-optimized EBS volumes.
    4. Only in read mode.

    Note: This answer has been updated. EBS Multi-Attach (available since 2020) allows io1/io2 volumes to be attached to up to 16 Nitro-based instances simultaneously within the same AZ.

  9. Do the Amazon EBS volumes persist independently from the running life of an Amazon EC2 instance?
    1. Only if instructed to when created
    2. Yes
    3. No
  10. Can I delete a snapshot of the root device of an EBS volume used by a registered AMI?
    1. Only via API
    2. Only via Console
    3. Yes
    4. No
  11. By default, EBS volumes that are created and attached to an instance at launch are deleted when that instance is terminated. You can modify this behavior by changing the value of the flag_____ to false when you launch the instance
    1. DeleteOnTermination
    2. RemoveOnDeletion
    3. RemoveOnTermination
    4. TerminateOnDeletion
  12. Your company policies require encryption of sensitive data at rest. You are considering the possible options for protecting data while storing it at rest on an EBS data volume, attached to an EC2 instance. Which of these options would allow you to encrypt your data at rest? (Choose 3 answers)
    1. Implement third party volume encryption tools
    2. Do nothing as EBS volumes are encrypted by default
    3. Encrypt data inside your applications before storing it on EBS
    4. Encrypt data using native data encryption drivers at the file system level
    5. Implement SSL/TLS for all services running on the server
  13. Which of the following are true regarding encrypted Amazon Elastic Block Store (EBS) volumes? Choose 2 answers
    1. Supported on all Amazon EBS volume types
    2. Snapshots are automatically encrypted
    3. Available to all instance types
    4. Existing volumes can be encrypted
    5. Shared volumes can be encrypted
  14. How can you secure data at rest on an EBS volume?
    1. Encrypt the volume using the S3 server-side encryption service
    2. Attach the volume to an instance using EC2’s SSL interface.
    3. Create an IAM policy that restricts read and write access to the volume.
    4. Write the data randomly instead of sequentially.
    5. Use an encrypted file system on top of the EBS volume
  15. A user has deployed an application on an EBS backed EC2 instance. For a better performance of application, it requires dedicated EC2 to EBS traffic. How can the user achieve this?
    1. Launch the EC2 instance as EBS dedicated with PIOPS EBS
    2. Launch the EC2 instance as EBS enhanced with PIOPS EBS
    3. Launch the EC2 instance as EBS dedicated with PIOPS EBS
    4. Launch the EC2 instance as EBS optimized with PIOPS EBS
  16. A user is trying to launch an EBS backed EC2 instance under free usage. The user wants to achieve encryption of the EBS volume. How can the user encrypt the data at rest?
    1. Use AWS EBS encryption to encrypt the data at rest (EBS encryption is supported on all current generation instance types including t2/t3 micro)
    2. User cannot use EBS encryption and has to encrypt the data manually or using a third party tool
    3. The user has to select the encryption enabled flag while launching the EC2 instance
    4. Encryption of volume is not available as a part of the free usage tier
  17. A user is planning to schedule a backup for an EBS volume. The user wants security of the snapshot data. How can the user achieve data encryption with a snapshot?
    1. Use encrypted EBS volumes so that the snapshot will be encrypted by AWS
    2. While creating a snapshot select the snapshot with encryption
    3. By default the snapshot is encrypted by AWS
    4. Enable server side encryption for the snapshot using S3
  18. A user has launched an EBS backed EC2 instance. The user has rebooted the instance. Which of the below mentioned statements is not true with respect to the reboot action?
    1. The private and public address remains the same
    2. The Elastic IP remains associated with the instance
    3. The volume is preserved
    4. The instance runs on a new host computer
  19. A user has launched an EBS backed EC2 instance. What will be the difference while performing the restart or stop/start options on that instance?
    1. For restart it does not charge for an extra hour, while every stop/start it will be charged as a separate hour
    2. Every restart is charged by AWS as a separate hour, while multiple start/stop actions during a single hour will be counted as a single hour
    3. For every restart or start/stop it will be charged as a separate hour
    4. For restart it charges extra only once, while for every stop/start it will be charged as a separate hour
  20. A user has launched an EBS backed instance. The user started the instance at 9 AM in the morning. Between 9 AM to 10 AM, the user is testing some script. Thus, he stopped the instance twice and restarted it. In the same hour the user rebooted the instance once. For how many instance hours will AWS charge the user?
    1. 3 hours
    2. 4 hours
    3. 2 hours
    4. 1 hour
  21. You are running a database on an EC2 instance, with the data stored on Elastic Block Store (EBS) for persistence At times throughout the day, you are seeing large variance in the response times of the database queries Looking into the instance with the isolate command you see a lot of wait time on the disk volume that the database’s data is stored on. What two ways can you improve the performance of the database’s storage while maintaining the current persistence of the data? Choose 2 answers
    1. Move to an SSD backed instance
    2. Move the database to an EBS-Optimized Instance
    3. Use Provisioned IOPs EBS
    4. Use the ephemeral storage on an m2.4xLarge Instance Instead
  22. An organization wants to move to Cloud. They are looking for a secure encrypted database storage option. Which of the below mentioned AWS functionalities helps them to achieve this?
    1. AWS MFA with EBS
    2. AWS EBS encryption
    3. Multi-tier encryption with Redshift
    4. AWS S3 server-side storage
  23. A user has stored data on an encrypted EBS volume. The user wants to share the data with his friend’s AWS account. How can user achieve this?
    1. Create an AMI from the volume and share the AMI
    2. Copy the data to an unencrypted volume and then share
    3. Take a snapshot and share the snapshot with a friend
    4. If both the accounts are using the same encryption key then the user can share the volume directly
  24. A user is using an EBS backed instance. Which of the below mentioned statements is true?
    1. The user will be charged for volume and instance only when the instance is running
    2. The user will be charged for the volume even if the instance is stopped
    3. The user will be charged only for the instance running cost
    4. The user will not be charged for the volume if the instance is stopped
  25. A user is planning to use EBS for his DB requirement. The user already has an EC2 instance running in the VPC private subnet. How can the user attach the EBS volume to a running instance?
    1. The user must create EBS within the same VPC and then attach it to a running instance.
    2. The user can create EBS in the same zone as the subnet of instance and attach that EBS to instance. (Should be in the same AZ)
    3. It is not possible to attach an EBS to an instance running in VPC until the instance is stopped.
    4. The user can specify the same subnet while creating EBS and then attach it to a running instance.
  26. A user is creating an EBS volume. He asks for your advice. Which advice mentioned below should you not give to the user for creating an EBS volume?
    1. Take the snapshot of the volume when the instance is stopped
    2. Stripe multiple volumes attached to the same instance
    3. Create an AMI from the attached volume (AMI is created from the snapshot)
    4. Attach multiple volumes to the same instance
  27. An EC2 instance has one additional EBS volume attached to it. How can a user attach the same volume to another running instance in the same AZ?
    1. Terminate the first instance and only then attach to the new instance
    2. Attach the volume as read only to the second instance
    3. Detach the volume first and attach to new instance
    4. No need to detach. Just select the volume and attach it to the new instance, it will take care of mapping internally
  28. What is the scope of an EBS volume?
    1. VPC
    2. Region
    3. Placement Group
    4. Availability Zone

Additional Practice Questions (Updated 2025-2026)

  1. A company wants to create instant copies of their EBS volumes for testing purposes within the same Availability Zone without using snapshots. Which feature should they use?
    1. EBS Fast Snapshot Restore
    2. EBS Snapshot Copy
    3. EBS Volume Clones
    4. EBS Multi-Attach
  2. Which EBS volume type provides sub-millisecond latency, up to 256,000 IOPS, and 99.999% durability?
    1. gp3
    2. io1
    3. io2 Block Express
    4. gp2
  3. A company needs to protect their EBS snapshots from accidental or malicious deletion to meet regulatory compliance requirements. Which feature should they use?
    1. EBS Encryption
    2. Recycle Bin
    3. AWS Backup
    4. EBS Snapshot Lock
  4. What is the maximum size, IOPS, and throughput for a gp3 volume as of September 2025?
    1. 16 TiB, 16,000 IOPS, 1,000 MiB/s
    2. 64 TiB, 64,000 IOPS, 4,000 MiB/s
    3. 64 TiB, 80,000 IOPS, 2,000 MiB/s
    4. 32 TiB, 32,000 IOPS, 2,000 MiB/s
  5. A team needs to accelerate the initialization of hundreds of EBS volumes from snapshots for a large-scale deployment. Which feature ensures predictable initialization times?
    1. EBS Fast Snapshot Restore
    2. Provisioned Rate for Volume Initialization
    3. EBS Volume Clones
    4. EBS Elastic Volumes
  6. How many times can you modify an EBS volume within a rolling 24-hour window? (as of Jan 2026)
    1. 1 time with 6-hour cooldown
    2. 2 times
    3. 4 times
    4. Unlimited
  7. Which of the following statements about EBS Multi-Attach is correct? (Choose 2)
    1. Multi-Attach is supported on io1 and io2 Provisioned IOPS volumes
    2. Multi-Attach allows attachment to instances across multiple Availability Zones
    3. Multi-Attach enabled volumes can be attached to up to 16 Nitro-based instances
    4. Multi-Attach is supported on gp3 volumes

Reference

Amazon EBS User Guide

AWS EC2 Instance Types – Families & Use Cases

EC2 Instance Types

📌 2026 Update Summary

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

EC2 Instance Naming Convention

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

EC2 Instance Types Selection Criteria

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

EBS-Optimized

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

Placement Groups

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

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

EC2 Instance Families – Current Generation (2024-2026)

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

AWS Graviton-Based Instances

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

Flex Instances

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

Burstable Performance Instances (T-Series)

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

CPU Credits

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

⚠️ Previous Generation: T2 Instances

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

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

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

C7i/C8i Instances (Compute Optimized – Current Generation)

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

⚠️ Previous Generation: C4 Instances

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

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

G5/G6/G7 Instances (Accelerated Computing – Graphics)

  • GPU instances provide high parallel processing capability for graphics and ML inference workloads.
  • Current generation:
    • G7 / G7e (2026) – NVIDIA RTX PRO 4500/6000 Blackwell Server Edition GPUs (up to 8), up to 4.6x AI inference and 2.1x graphics performance over G6, up to 700 Gbps EFA networking
    • G6 / G6e (2024) – NVIDIA L4 GPUs (up to 8), ideal for ML inference and graphics workloads
    • G5 – NVIDIA A10G GPUs (up to 8), for graphics-intensive applications and ML inference
  • Well suited for:
    • Machine learning inference
    • Graphics rendering and game streaming
    • Video transcoding with hardware acceleration
    • Remote visualization workstations
  • For deep learning training, use P-series instances:
    • P5 / P5en – NVIDIA H100/H200 Tensor Core GPUs for large-scale training
    • P4d / P4de – NVIDIA A100 GPUs
  • For cost-effective ML training, consider Trn-series (AWS Trainium):
    • Trn2 – AWS Trainium2 chips, 30-40% better price-performance than GPU-based P5e/P5en instances
    • Trn1 – AWS Trainium chips, purpose-built for ML training
  • For ML inference at scale, consider Inf-series (AWS Inferentia):
    • Inf2 – AWS Inferentia2, 3x compute performance, 4x memory vs Inf1, up to 40% cost savings vs GPU-based alternatives
  • Features:
    • Built on AWS Nitro System
    • Requires HVM AMI with NVIDIA drivers installed
    • Support Enhanced Networking with ENA
    • Support Elastic Fabric Adapter (EFA) for GPU-to-GPU communication

⚠️ Previous Generation: G2 Instances

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

  • G7 / G7e – NVIDIA RTX PRO Blackwell GPUs, latest generation (June 2026), up to 4.6x AI inference performance
  • G6 / G6e – NVIDIA L4 GPUs, widely available
  • G5 – NVIDIA A10G GPUs

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

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

⚠️ Previous Generation: I2 Instances

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

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

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

D3/D3en Instances (Storage Optimized – HDD)

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

⚠️ Previous Generation: D2 Instances

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

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

Network-Optimized Instances (2026)

  • AWS introduced network-optimized instance variants (suffix “n” and “ne”) for workloads requiring extreme network performance.
  • Current network-optimized instances:
    • M8in / R8in – Network-optimized general purpose and memory instances, Intel Granite Rapids + Nitro v6, up to 400 Gbps networking
    • C8ine / M8ine – Dataplane packet processing optimized, up to 2.5x higher packet performance per vCPU vs C6in, up to 2x higher internet gateway bandwidth
    • C8gn – Graviton4-based, up to 600 Gbps network bandwidth for network appliances and real-time analytics
  • Well suited for: network virtual appliances, firewalls, load balancers, real-time data streaming, and high-bandwidth inter-node communication.

AWS Nitro System

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

AWS Certification Exam Practice Questions

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

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

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

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

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

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

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

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

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

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

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

References

AWS EC2 Best Practices

AWS EC2 Best Practices

AWS recommends the following best practices to get maximum benefit and satisfaction from EC2.

Security & Network

  • Manage access to AWS resources and APIs using identity federation with an identity provider and IAM roles whenever possible.
  • Implement the least permissive rules for the security group.
  • Regularly patch, update, and secure the operating system and applications on the instance. Use AWS Systems Manager Patch Manager to automate OS and application patching across EC2 fleets.
  • Use AWS Systems Manager Session Manager for secure shell access instead of opening SSH/RDP ports. Session Manager provides IAM-based access control, full audit logging via CloudTrail, and eliminates the need for bastion hosts or managing SSH keys.
  • Establish credential management policies and procedures for creating, distributing, rotating, and revoking AWS access credentials.
  • Use Amazon Inspector to automatically discover and scan EC2 instances for software vulnerabilities and unintended network exposure.
  • Use AWS Security Hub controls to monitor EC2 resources against security best practices and standards (e.g., EBS encryption enabled, IMDSv2 required, no public IPv4 addresses).
  • Enforce IMDSv2 (Instance Metadata Service Version 2) on all instances. IMDSv2 uses session-oriented requests with tokens, protecting against SSRF attacks. As of mid-2024, all newly released EC2 instance types use IMDSv2 only by default.
  • Encrypt EBS volumes and snapshots. Enable EBS encryption by default at the account level to ensure all newly created volumes are automatically encrypted using AWS KMS.
  • Set the time-to-live (TTL) value for applications to 255 for both IPv4 and IPv6. Using a smaller value risks TTL expiring while traffic is in transit, causing reachability issues.
  • Use the AWS Nitro System based instances which provide enhanced security through hardware-based isolation, encrypted memory (starting with Graviton2, AMD EPYC Milan, and Intel Ice Lake processors), and a minimized attack surface with no administrative access.

📝 Note: EC2-Classic was fully retired on August 15, 2023. All instances now launch into a VPC by default. Any references to EC2-Classic are historical only.

Storage

  • EC2 supports Instance store and EBS volumes. Understand the implications of the root device type for data persistence, backup, and recovery.
  • Use separate Amazon EBS volumes for the operating system (root device) versus the data.
  • Ensure that the data volume persists after instance termination by configuring the DeleteOnTermination attribute appropriately.
  • Use the instance store available for the instance to store only temporary data. Data stored in instance store is deleted when an instance is stopped, hibernated, or terminated.
  • If instance store is used for database storage, ensure a cluster with a replication factor that ensures fault tolerance.
  • Enable EBS encryption by default at the account/region level so all new volumes and snapshots are encrypted automatically.
  • Use appropriate EBS volume types based on workload requirements:
    • gp3 – General purpose SSD (baseline 3,000 IOPS, up to 16,000 IOPS)
    • io2 Block Express – High-performance SSD (up to 256,000 IOPS) for mission-critical workloads
    • st1/sc1 – HDD volumes for throughput-intensive or cold storage workloads

Resource Management

  • Use instance metadata and custom resource tags to track and identify AWS resources.
  • View current limits for Amazon EC2 using Service Quotas. Plan to request any limit increases in advance of the time needed.
  • Use AWS Trusted Advisor to inspect the AWS environment and get recommendations for saving money, improving system availability and performance, and closing security gaps.
  • Use AWS Compute Optimizer for right-sizing recommendations based on actual utilization metrics. It analyzes CPU, memory, network, and storage to recommend optimal instance types.
  • Consider AWS Graviton instances (Arm-based processors) for up to 40% better price-performance compared to x86 instances for compatible workloads.
  • Use Savings Plans or Reserved Instances for predictable workloads (up to 72% discount), and Spot Instances for fault-tolerant workloads (up to 90% discount).

Backup & Recovery

  • Regularly back up EBS volumes using Amazon EBS snapshots and create an Amazon Machine Image (AMI) from the instance to save the configuration as a template for launching future instances.
  • Use Amazon Data Lifecycle Manager (DLM) to automate the creation, retention, and deletion of EBS snapshots and EBS-backed AMIs on a schedule.
  • Use AWS Backup for centralized, policy-based backup management across EC2, EBS, and other AWS services with cross-account and cross-region capabilities.
  • Deploy critical components of the application across multiple Availability Zones, and replicate data appropriately.
  • Design applications to handle dynamic IP addressing when the instance restarts.
  • Monitor and respond to events using Amazon EventBridge and CloudWatch Alarms.
  • Implement failover:
    • For a basic solution, manually attach a network interface or Elastic IP address to a replacement instance.
    • For an automated solution, use Amazon EC2 Auto Scaling with health checks to automatically replace unhealthy instances.
    • For predictable traffic patterns, use Predictive Scaling to proactively scale capacity ahead of demand spikes.
  • Regularly test the process of recovering instances and EBS volumes to ensure data and services are restored successfully.
  • Use EC2 instance recovery with CloudWatch alarms to automatically recover instances when underlying hardware fails.

Networking

  • Set the time-to-live (TTL) value for applications to 255, for IPv4 and IPv6, to prevent TTL expiry during transit.
  • Be aware of connection tracking behavior on Nitro-based instances. Sixth-generation Nitro (Nitro V6) instances launched in June 2025 changed the default TCP connection tracking idle timeout from 432,000 seconds (5 days) to 350 seconds.
  • Use configurable idle timeouts for connection tracking to optimize conntrack allowance usage and reduce leaked connections.
  • Use Capacity Reservations for business-critical workloads to ensure EC2 capacity is available when needed, especially in multi-AZ deployments.

References

AWS Encrypting Data at Rest – Whitepaper – Certification

Encrypting Data at Rest

🔄 Major Updates (2023-2026)

  • Amazon S3 now automatically encrypts ALL new objects with SSE-S3 by default (Jan 2023). SSE-C disabled by default on new buckets (April 2026).
  • Amazon S3 DSSE-KMS — new dual-layer server-side encryption option (June 2023).
  • AWS KMS — now FIPS 140-3 Level 3 validated. Supports flexible automatic key rotation (90 days to 7 years) and on-demand rotation (April 2024). Post-quantum cryptography support with ML-KEM and ML-DSA (2025-2026).
  • AWS CloudHSM — new hsm2m.medium instance type (Aug 2024) with FIPS 140-3 Level 3 certification and non-FIPS mode.
  • Amazon Aurora — encryption at rest enabled by default for all new clusters (Feb 2026).
  • Amazon EBS — supports encryption by default for all new volumes (opt-in per region), including boot volumes.
  • Amazon Glacier (standalone vault-based service) — stopped accepting new customers Dec 15, 2025. Use S3 Glacier storage classes instead.
  • AWS delivers a secure, scalable cloud computing platform with high availability, offering the flexibility for you to build a wide range of applications
  • AWS allows several options for encrypting data at rest, for additional layer of security, ranging from completely automated AWS encryption solution to manual client-side options
  • Encryption requires 3 things
    • Data to encrypt
    • Encryption keys
    • Cryptographic algorithm method to encrypt the data
  • AWS provides different models for Securing data at rest on the following parameters
    • Encryption method
      • Encryption algorithm selection involves evaluating security, performance, and compliance requirements specific to your application
    • Key Management Infrastructure (KMI)
      • KMI enables managing & protecting the encryption keys from unauthorized access
      • KMI provides
        • Storage layer that protects plain text keys
        • Management layer that authorize key usage
  • Hardware Security Module (HSM)
    • Common way to protect keys in a KMI is using HSM
    • An HSM is a dedicated storage and data processing device that performs cryptographic operations using keys on the device.
    • An HSM typically provides tamper evidence, or resistance, to protect keys from unauthorized use.
    • A software-based authorization layer controls who can administer the HSM and which users or applications can use which keys in the HSM
  • AWS CloudHSM
    • AWS CloudHSM appliance has both physical and logical tamper detection and response mechanisms that trigger zeroization of the appliance.
    • Zeroization erases the HSM’s volatile memory where any keys in the process of being decrypted were stored and destroys the key that encrypts stored objects, effectively causing all keys on the HSM to be inaccessible and unrecoverable.
    • AWS CloudHSM can be used to generate and store key material and can perform encryption and decryption operations.
    • AWS CloudHSM, however, does not perform any key lifecycle management functions (e.g., access control policy, key rotation) and needs a compatible KMI.
    • KMI can be deployed either on-premises or within Amazon EC2 and can communicate to the AWS CloudHSM instance securely over SSL to help protect data and encryption keys.
    • Update (Aug 2024): AWS CloudHSM launched a new hsm2m.medium instance type with FIPS 140-3 Level 3 certification, non-FIPS mode option, increased key storage (16,666 keys), and mTLS support. The previous hsm1.medium type should be migrated to the new instance type.
    • AWS CloudHSM clusters are backed by HSMs certified at FIPS 140-3 Level 3 (previously FIPS 140-2 Level 2/3).
  • AWS Key Management Service (KMS)
    • AWS KMS is a managed encryption service that allows you to provision and use keys to encrypt data in AWS services and your applications.
    • Master keys (now called KMS keys), after creation, are designed to never be exported from the service.
    • AWS KMS gives you centralized control over who can access your KMS keys to encrypt and decrypt data, and it gives you the ability to audit this access.
    • Data can be sent into the KMS to be encrypted or decrypted under a specific KMS key under your account.
    • AWS KMS is natively integrated with other AWS services (for e.g. Amazon EBS, Amazon S3, Amazon RDS, and Amazon Redshift) and AWS SDKs to simplify encryption of your data within those services or custom applications.
    • AWS KMS provides global availability, low latency, and a high level of durability for your keys.
    • AWS KMS HSMs are now validated at FIPS 140-3 Security Level 3 (upgraded from FIPS 140-2 Level 2 in 2023).
    • Key Rotation (2024 Update):
      • Customizable automatic rotation period from 90 days to 7 years (2560 days), previously fixed at 1 year.
      • On-demand key rotation available for immediate rotation of customer managed symmetric encryption keys.
      • Key rotation history tracking available via console and API.
    • External Key Store (XKS): Allows you to store and use encryption keys in an HSM or key manager outside AWS, while still using KMS APIs. Useful for regulatory requirements mandating key storage outside cloud provider infrastructure.
    • Post-Quantum Cryptography (2025-2026):
      • ML-KEM (Module-Lattice Key-Encapsulation Mechanism) support for post-quantum TLS connections to KMS.
      • ML-DSA (Module-Lattice Digital Signature Algorithm) support for quantum-resistant digital signatures (June 2025).
      • CRYSTALS-Kyber support will be removed in 2026 in favor of ML-KEM.
    • Key Store Options:
      • Default KMS key store (FIPS 140-3 Level 3 HSMs managed by AWS)
      • CloudHSM key store (custom key store backed by your CloudHSM cluster)
      • External key store (XKS — keys stored outside AWS)

Encryption Models in AWS

Encryption models in AWS depends on how you/AWS provides the encryption method and the KMI

  • You control the encryption method and the entire KMI
  • You control the encryption method, AWS provides the storage component of the KMI, and you provide the management layer of the KMI.
  • AWS controls the encryption method and the entire KMI.

Model A: You control the encryption method and the entire KMI

  • You use your own KMI to generate, store, and manage access to keys as well as control all encryption methods in your applications
  • Proper storage, management, and use of keys to ensure the confidentiality, integrity, and availability of your data is your responsibility
  • AWS has no access to your keys and cannot perform encryption or decryption on your behalf.
  • Amazon S3
    • Encryption of the data is done before the object is sent to AWS S3
    • Encryption of the data can be done using any encryption method and the encrypted data can be uploaded using the PUT request in the Amazon S3 API
    • Key used to encrypt the data needs to be stored securely in your KMI
    • To decrypt this data, the encrypted object can be downloaded from Amazon S3 using the GET request in the Amazon S3 API and then decrypted using the key in your KMI
    • AWS provides Client-side encryption handling, where you can provide your key to the AWS S3 encryption client which will encrypt and decrypt the data on your behalf. However, AWS never has access to the keys or the unencrypted data
  • Amazon EBS
    • Amazon Elastic Block Store (Amazon EBS) provides block-level storage volumes for use with Amazon EC2 instances. Amazon EBS volumes are network-attached, and persist independently from the life of an instance.
    • Because Amazon EBS volumes are presented to an instance as a block device, you can leverage most standard encryption tools for file system-level or block-level encryption
    • Block level encryption
      • Block level encryption tools usually operate below the file system layer using kernel space device drivers to perform encryption and decryption of data.
      • These tools are useful when you want all data written to a volume to be encrypted regardless of what directory the data is stored in
    • File System level encryption
      • File system level encryption usually works by stacking an encrypted file system on top of an existing file system.
      • This method is typically used to encrypt a specific directory
    • These solutions require you to provide keys, either manually or from your KMI.
    • Both block-level and file system-level encryption tools can only be used to encrypt data volumes that are not Amazon EBS boot volumes
    • Update: Amazon EBS now supports native encryption for both boot and data volumes through its built-in encryption feature integrated with AWS KMS. The limitation of third-party tools not supporting boot volume encryption is less relevant as EBS native encryption is the recommended approach.
  • AWS Storage Gateway
    • AWS Storage Gateway is a service connecting an on-premises software appliance with Amazon S3. Data on disk volumes attached to the AWS Storage Gateway will be automatically uploaded to Amazon S3 based on policy
    • Encryption of the source data on the disk volumes can be either done before writing to the disk or using block level encryption on the iSCSI endpoint that AWS Storage Gateway exposes to encrypt all data on the disk volume.
  • Amazon RDS
    • Amazon RDS doesn’t expose the attached disk it uses for data storage, transparent disk encryption using techniques for EBS section cannot be applied.
    • However, individual fields data can be encrypted before the data is written to RDS and decrypted after reading it.
    • Update: Amazon RDS now supports native KMS-based encryption at rest for all database engines. All new Amazon Aurora clusters are encrypted by default (Feb 2026).

Model B: You control the encryption method, AWS provides the KMI storage component, and you provide the KMI management layer

  • Model B is similar to Model A where the encryption method is managed by you
  • Model B differs in the approach to Model A where the keys are maintained in AWS CloudHSM rather than the on-premise key storage system
  • Only you have access to the cryptographic partitions within the dedicated HSM to use the keys
  • Update: With the new hsm2m.medium instance type (Aug 2024), CloudHSM provides FIPS 140-3 Level 3 certification, non-FIPS mode option, and increased key storage capacity (16,666 keys).

Model C: AWS controls the encryption method and the entire KMI

  • AWS provides and manages the server-side encryption of your data, transparently managing the encryption method and the keys.
  • AWS KMS and other services that encrypt your data directly use a method called envelope encryption to provide a balance between performance and security.
  • Envelope Encryption method
    • A master key (KMS key) is defined either by you or AWS
    • A data key (data encryption key) is generated by the AWS service at the time when data encryption is requested
    • Data key is used to encrypt your data.
    • Data key is then encrypted with a key-encrypting key (KMS key) unique to the service storing your data.
    • Encrypted data key and the encrypted data are then stored by the AWS storage service on your behalf.
  • KMS keys used to encrypt data keys are stored and managed separately from the data and the data keys
  • For decryption of the data, the process is reversed. Encrypted data key is decrypted using the KMS key; the data key is then used to decrypt your data
  • Authorized use of encryption keys is done automatically and is securely managed by AWS.
  • Because unauthorized access to those keys could lead to the disclosure of your data, AWS has built systems and processes with strong access controls that minimize the chance of unauthorized access and had these systems verified by third-party audits to achieve security certifications including SOC 1, 2, and 3, PCI-DSS, and FedRAMP.
  • Amazon S3
    • Important (Jan 2023): Amazon S3 now automatically encrypts ALL new objects with SSE-S3 as the base level of encryption. No action required — encryption is applied by default at no additional cost.
    • SSE-S3
      • AWS encrypts each object using a unique data key
      • Data key is encrypted with a periodically rotated master key managed by S3
      • Amazon S3 server-side encryption uses 256-bit Advanced Encryption Standard (AES) keys for both object and master keys
      • This is now the default encryption for all S3 objects
    • SSE-KMS
      • KMS keys are defined and managed in KMS for your account
      • Object Encryption
        • When an object is uploaded, a request is sent to KMS to create an object key.
        • KMS generates a unique object key and encrypts it using the KMS key; KMS then returns this encrypted object key along with the plaintext object key to Amazon S3.
        • Amazon S3 web server encrypts your object using the plaintext object key and stores the now encrypted object (with the encrypted object key) and deletes the plaintext object key from memory.
      • Object Decryption
        • To retrieve the encrypted object, Amazon S3 sends the encrypted object key to AWS KMS.
        • AWS KMS decrypts the object key using the correct KMS key and returns the decrypted (plaintext) object key to S3.
        • Amazon S3 decrypts the encrypted object, with the plaintext object key, and returns it to you.
    • DSSE-KMS (Dual-Layer Server-Side Encryption — New June 2023)
      • Applies two independent layers of encryption to objects using AES-256-GCM algorithm
      • Each layer uses a different implementation of AES-256-GCM for defense-in-depth
      • Both layers use KMS keys for key management
      • Designed to meet compliance requirements (e.g., NSA CNSSP 15) that mandate dual-layer encryption
      • Can be configured as bucket default encryption or specified per-object
    • SSE-C
      • Amazon S3 is provided an encryption key, while uploading the object
      • Encryption key is used by Amazon S3 to encrypt your data using AES-256
      • After object encryption, Amazon S3 deletes the encryption key
      • For downloading, you need to provide the same encryption key, which AWS matches, decrypts and returns the object
      • Update (April 2026): SSE-C is now disabled by default on all new S3 general purpose buckets. Existing buckets without SSE-C objects will also have SSE-C disabled. Must be explicitly enabled via bucket settings if needed.
    • S3 Bucket-Level Encryption Enforcement (Nov 2025): New setting to standardize encryption types (SSE-S3 or SSE-KMS only) for all write requests to a bucket.
  • Amazon EBS
    • When Amazon EBS volume is created, you can choose the KMS key to be used for encrypting the volume
    • Encryption by Default: You can enable EBS encryption by default per-region, so all newly created EBS volumes (including boot volumes) are automatically encrypted with the default KMS key or a specified key.
    • Volume encryption
      • Amazon EC2 server sends an authenticated request to AWS KMS to create a volume key.
      • AWS KMS generates this volume key, encrypts it using the KMS key, and returns the plaintext volume key and the encrypted volume key to the Amazon EC2 server.
      • Plaintext volume key is stored in memory to encrypt and decrypt all data going to and from your attached EBS volume.
    • Volume decryption
      • When the encrypted volume (or any encrypted snapshots derived from that volume) needs to be re-attached to an instance, a call is made to AWS KMS to decrypt the encrypted volume key.
      • AWS KMS decrypts this encrypted volume key with the correct KMS key and returns the decrypted volume key to Amazon EC2.
  • Amazon S3 Glacier
    • S3 Glacier provides encryption of the data, by default
    • Before it’s written to disk, data is always automatically encrypted using 256-bit AES keys unique to the service that are stored in separate systems under AWS control
    • S3 Glacier storage classes include: S3 Glacier Instant Retrieval, S3 Glacier Flexible Retrieval (formerly S3 Glacier), and S3 Glacier Deep Archive
    • Note: The original standalone vault-based Amazon Glacier service stopped accepting new customers on December 15, 2025. Use S3 Glacier storage classes instead.
  • AWS Storage Gateway
    • AWS Storage Gateway transfers your data to AWS over SSL
    • AWS Storage Gateway stores data encrypted at rest in Amazon S3 or S3 Glacier using their respective server side encryption schemes.
  • Amazon RDS – Oracle
    • Oracle Advanced Security option for Oracle on Amazon RDS can be used to leverage the native Transparent Data Encryption (TDE) and Native Network Encryption (NNE) features
    • Oracle encryption module creates data and key-encrypting keys to encrypt the database
    • Key-encrypting keys specific to your Oracle instance on Amazon RDS are themselves encrypted by a periodically rotated 256-bit AES master key.
    • Master key is unique to the Amazon RDS service and is stored in separate systems under AWS control
    • Update: Amazon RDS also supports native KMS-based encryption at the storage layer (EBS-level encryption) as an alternative to Oracle TDE.
  • Amazon RDS – SQL Server
    • Transparent Data Encryption (TDE) can be provisioned for Microsoft SQL Server on Amazon RDS.
    • SQL Server encryption module creates data and key-encrypting keys to encrypt the database.
    • Key-encrypting keys specific to your SQL Server instance on Amazon RDS are themselves encrypted by a periodically rotated, regional 256-bit AES master key
    • Master key is unique to the Amazon RDS service and is stored in separate systems under AWS control
    • Update (Oct 2025): Amazon RDS for SQL Server now supports encrypting native backups using SSE-KMS.
  • Amazon Aurora (New – Feb 2026)
    • All new Aurora database clusters created on or after February 18, 2026 are encrypted at rest by default using AES-256 encryption
    • Uses AWS owned keys if no custom encryption is specified
    • Encryption is transparent with no performance impact
    • Existing unencrypted clusters are unaffected but can be migrated to encrypted clusters
    • Supports customer managed KMS keys for additional control

Sample Exam 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. How can you secure data at rest on an EBS volume?
    1. Encrypt the volume using the S3 server-side encryption service
    2. Attach the volume to an instance using EC2’s SSL interface.
    3. Create an IAM policy that restricts read and write access to the volume.
    4. Write the data randomly instead of sequentially.
    5. Use an encrypted file system on top of the EBS volume
  2. Your company policies require encryption of sensitive data at rest. You are considering the possible options for protecting data while storing it at rest on an EBS data volume, attached to an EC2 instance. Which of these options would allow you to encrypt your data at rest? (Choose 3 answers)
    1. Implement third party volume encryption tools
    2. Do nothing as EBS volumes are encrypted by default
    3. Encrypt data inside your applications before storing it on EBS
    4. Encrypt data using native data encryption drivers at the file system level
    5. Implement SSL/TLS for all services running on the server
  3. A company is storing data on Amazon Simple Storage Service (S3). The company’s security policy mandates that data is encrypted at rest. Which of the following methods can achieve this? Choose 3 answers
    1. Use Amazon S3 server-side encryption with AWS Key Management Service managed keys
    2. Use Amazon S3 server-side encryption with customer-provided keys
    3. Use Amazon S3 server-side encryption with EC2 key pair.
    4. Use Amazon S3 bucket policies to restrict access to the data at rest.
    5. Encrypt the data on the client-side before ingesting to Amazon S3 using their own master key
    6. Use SSL to encrypt the data while in transit to Amazon S3.
  4. Which 2 services provide native encryption
    1. Amazon EBS
    2. Amazon S3 Glacier
    3. Amazon Redshift (is optional)
    4. Amazon RDS (is optional)
    5. Amazon Storage Gateway
  5. With which AWS services CloudHSM can be used (select 2)
    1. S3
    2. DynamoDb
    3. RDS
    4. ElastiCache
    5. Amazon Redshift
  6. A company needs to ensure all new objects uploaded to Amazon S3 are encrypted. What is the MOST operationally efficient approach? [Updated 2023+]
    1. Create a bucket policy denying unencrypted uploads
    2. No action needed — S3 automatically encrypts all new objects with SSE-S3 by default since January 2023
    3. Enable default encryption on each bucket manually
    4. Use AWS Config rules to detect unencrypted objects
  7. A company requires FIPS 140-3 Level 3 validated key management. Which options meet this requirement? (Choose 2) [Updated 2024+]
    1. AWS KMS default key store
    2. AWS Secrets Manager
    3. AWS CloudHSM with hsm2m.medium instance type
    4. Amazon S3 SSE-S3 managed keys
    5. AWS Certificate Manager
  8. An organization needs to rotate KMS keys every 90 days for compliance. How can this be achieved? [New 2024]
    1. Create a Lambda function to create new keys quarterly
    2. This is not possible as KMS only supports annual rotation
    3. Configure automatic key rotation with a custom period of 90 days using the rotation period setting
    4. Use AWS Config to trigger manual key rotation
  9. A regulated financial institution requires encryption keys to remain outside AWS infrastructure at all times. Which AWS KMS feature addresses this requirement? [New 2024]
    1. AWS KMS custom key store with CloudHSM
    2. AWS KMS imported key material (BYOK)
    3. AWS KMS External Key Store (XKS)
    4. AWS CloudHSM with on-premises HSM replication
  10. Which Amazon S3 encryption option applies two independent layers of server-side encryption to objects? [New 2023]
    1. SSE-S3 with bucket key
    2. SSE-KMS with automatic key rotation
    3. DSSE-KMS (Dual-Layer Server-Side Encryption with KMS)
    4. SSE-C with two different customer keys

References

S3 Consistency Model Explained – Strong Read-After-Write [2026]

AWS S3 Data Consistency Model

  • S3 Data Consistency provides strong read-after-write consistency for PUT and DELETE requests of objects in the S3 bucket in all AWS Regions
  • This behavior applies to both writes to new objects as well as PUT requests that overwrite existing objects and DELETE requests.
  • Read operations on S3 Select, S3 ACLs, S3 Object Tags, and object metadata (for example, the HEAD object) are strongly consistent.
  • Updates to a single key are atomic. for e.g., if you PUT to an existing key, a subsequent read might return the old data or the updated data, but it will never write corrupted or partial data.
  • S3 achieves high availability by replicating data across multiple servers within Amazon’s data centers. If a PUT request is successful, the data is safely stored. Any read (GET or LIST request) that is initiated following the receipt of a successful PUT response will return the data written by the PUT request.
  • S3 Data Consistency behavior examples
    • A process writes a new object to S3 and immediately lists keys within its bucket. The new object appears in the list.
    • A process replaces an existing object and immediately tries to read it. S3 returns the new data.
    • A process deletes an existing object and immediately tries to read it. S3 does not return any data because the object has been deleted.
    • A process deletes an existing object and immediately lists keys within its bucket. The object does not appear in the listing.
  • S3 does not currently support object locking for concurrent writes. S3 now supports Conditional Writes (launched Aug 2024) to handle concurrent write scenarios. for e.g. If two PUT requests are simultaneously made to the same key, the request with the latest timestamp wins. You can use conditional writes with If-None-Match or If-Match headers to prevent unintentional overwrites.
  • Updates are key-based; there is no way to make atomic updates across keys. for e.g, an update of one key cannot be dependent on the update of another key unless you design this functionality into the application.
  • S3 Object Lock is different as it allows to store objects using a write-once-read-many (WORM) model, which prevents an object from being deleted or overwritten for a fixed amount of time or indefinitely.

S3 Conditional Writes

  • S3 Conditional Writes, launched in August 2024, allow adding preconditions to write requests to coordinate concurrent writers and prevent unintentional overwrites.
  • If-None-Match header (Aug 2024)
    • Prevents overwrites of existing data by checking if an object with the same key name already exists in the bucket.
    • Expects the * (asterisk) value.
    • If an identical key name exists, the operation fails with a 412 Precondition Failed response.
    • Useful for ensuring exactly-once uploads and preventing duplicate data.
    • Supported on PutObject, CompleteMultipartUpload, and CopyObject APIs.
  • If-Match header (Nov 2024)
    • Compares the provided ETag value with the ETag of the object currently in S3.
    • If the ETag values don’t match (object was modified), the write operation fails with a 412 Precondition Failed response.
    • Enables optimistic concurrency control — check-and-set pattern without external locking.
    • Helps coordinate simultaneous writes and prevents multiple concurrent writers from unintentionally overwriting objects.
    • Supported on PutObject, CompleteMultipartUpload, and CopyObject APIs.
  • Conditional Write Enforcement via Bucket Policy (Nov 2024)
    • Bucket owners can use s3:if-none-match or s3:if-match condition keys in bucket policies to mandate the use of conditional headers.
    • Requests without the required conditional headers will be denied with a 403 Access Denied error.
  • Conditional Writes for Copy Operations (Oct 2025)
    • Extended conditional write support to CopyObject operations.
    • Allows verifying if an object exists or has been modified in the destination bucket before copying.
    • Uses s3:if-match and s3:if-none-match condition keys enforceable via bucket policies.
  • Error Responses
    • 412 Precondition Failed — Precondition not met (object exists or ETag mismatch).
    • 409 Conflict — A concurrent delete request succeeded before the conditional write completed.
    • 404 Not Found — Object no longer exists when using If-Match (concurrent delete).
  • There is no additional charge for conditional writes — standard request pricing applies.
  • Use cases include leader election, distributed locking, write-once data pipelines, and multi-writer applications without external coordination systems like DynamoDB.

S3 Default Data Integrity Protections

  • Starting December 2024, S3 provides default data integrity protections for new object uploads.
  • The latest AWS SDKs automatically calculate CRC-based checksums for uploads as data is transmitted over the network.
  • S3 independently verifies these checksums and accepts objects after confirming data integrity was maintained in transit.
  • If no checksum is provided on upload, S3 automatically calculates and applies a CRC64NVME checksum as default integrity protection.
  • Checksums can be requested during download to verify data consistency.
  • This ensures end-to-end data integrity without requiring application-level checksum implementation.

S3 Consistency with S3 Express One Zone

  • S3 Express One Zone (launched Nov 2023) provides strong read-after-write consistency with single-digit millisecond data access.
  • Objects are stored in directory buckets in a single Availability Zone, co-located with compute resources for lowest latency.
  • Delivers up to 10x faster performance and up to 50% lower request costs compared to S3 Standard.
  • Supports conditional deletes (Nov 2024) — can evaluate whether an object is unchanged before deleting it, improving data durability in high-concurrency scenarios.
  • Provides the same strong consistency model as S3 Standard for all operations.

S3 Legacy Consistency Model (Historical Reference)

  • S3 provides strong Read-after-Write consistency for PUTS of new objects
    • For a PUT request, S3 synchronously stores data across multiple facilities before returning SUCCESS
    • A process writes a new object to S3 and will be immediately able to read the Object i.e. PUT 200 -> GET 200
    • A process writes a new object to S3 and immediately lists keys within its bucket. Until the change is fully propagated, the object might not appear in the list.
    • However, if a HEAD or GET request to a key name is made before the object is created, then create the object shortly after that, a subsequent GET might not return the object due to eventual consistency. i.e. GET 404 -> PUT 200 -> GET 404
  • S3 provides Eventual Consistency for overwrite PUTS and DELETES in all regions.
    • For updates and deletes to Objects, the changes are eventually reflected and not available immediately i.e. PUT 200 -> PUT 200 -> GET 200 (might be older version) OR DELETE 200 -> GET 200
    • if a process replaces an existing object and immediately attempts to read it, S3 might return the prior data till the change is fully propagated
    • if a process deletes an existing object and immediately attempts to read it, S3 might return the deleted data until the deletion is fully propagated
    • if a process deletes an existing object and immediately lists keys within its bucket. Until the deletion is fully propagated, S3 might list the deleted object.
  • Note: Since December 2020, S3 provides strong read-after-write consistency for ALL operations (GET, PUT, LIST, DELETE, tags, ACLs, metadata). The eventual consistency model above is no longer applicable but retained for historical and exam reference.

AWS Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • AWS services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • AWS exam questions are not updated to keep up the pace with AWS updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.
  1. Which of the following are valid statements about Amazon S3? Choose 2 answers
    1. S3 provides read-after-write consistency for any type of PUT or DELETE. (S3 now provides strong read-after-write consistency)
    2. Consistency is not guaranteed for any type of PUT or DELETE.
    3. A successful response to a PUT request only occurs when a complete object is saved
    4. Partially saved objects are immediately readable with a GET after an overwrite PUT.
    5. S3 provides eventual consistency for overwrite PUTS and DELETES
  2. A customer is leveraging Amazon Simple Storage Service in eu-west-1 to store static content for web-based property. The customer is storing objects using the Standard Storage class. Where are the customers’ objects replicated?
    1. Single facility in eu-west-1 and a single facility in eu-central-1
    2. Single facility in eu-west-1 and a single facility in us-east-1
    3. Multiple facilities in eu-west-1
    4. A single facility in eu-west-1
  3. A user has an S3 object in the US Standard region with the content “color=red”. The user updates the object with the content as “color=”white”. If the user tries to read the value 1 minute after it was uploaded, what will S3 return?
    1. It will return “color=white” (strong read-after-write consistency — S3 provides strong consistency for all operations since December 2020)
    2. It will return “color=red”
    3. It will return an error saying that the object was not found
    4. It may return either “color=red” or “color=white” i.e. any of the value (Eventual Consistency — No longer applicable)
  4. A company has multiple applications writing to the same S3 object simultaneously. They want to ensure that an application only writes to the object if no other application has modified it since it was last read. What S3 feature should they use?
    1. S3 Object Lock with Governance mode
    2. S3 Versioning with MFA Delete
    3. S3 Conditional Writes with the If-Match header (If-Match compares ETag to ensure object hasn’t changed since last read — optimistic concurrency control)
    4. S3 Cross-Region Replication
  5. An application needs to ensure that an object is uploaded to S3 only if no object with the same key already exists. Which approach provides this guarantee at the storage layer without external coordination?
    1. Check with a GET request before uploading with PUT
    2. Use S3 Versioning to track duplicates
    3. Use DynamoDB as a distributed lock manager
    4. Use the If-None-Match header with PutObject (If-None-Match with * value ensures the PUT only succeeds if no object with that key exists — atomic check-and-put)
  6. Which of the following statements about S3 Conditional Writes are correct? (Choose 2)
    1. The If-Match header can be used to update an object only if its ETag matches the expected value
    2. Conditional writes require S3 Object Lock to be enabled on the bucket
    3. Bucket policies can enforce conditional writes using s3:if-none-match condition keys
    4. Conditional writes are only supported on S3 Express One Zone directory buckets
    5. Conditional writes incur additional per-request charges

References

AWS Simple Storage Service – S3

AWS Simple Storage Service – S3

  • Amazon Simple Storage Service – S3 is a simple key, value object store designed for the Internet
  • provides unlimited storage space and works on the pay-as-you-use model. Service rates get cheaper as the usage volume increases
  • offers an extremely durable, highly available, and infinitely scalable data storage infrastructure at very low costs.
  • is Object-level storage (not Block level storage like EBS volumes) and cannot be used to host OS or dynamic websites (however, S3 can host static websites).
  • S3 resources e.g. buckets and objects are private by default.
  • As of March 2026, S3 stores more than 500 trillion objects, serves more than 200 million requests per second globally across hundreds of exabytes of data.
  • S3 provides strong read-after-write consistency for all operations (PUT, GET, LIST, DELETE, HEAD) automatically, at no additional cost, in all AWS Regions.
  • Starting January 5, 2023, all new objects are automatically encrypted with SSE-S3 (server-side encryption with Amazon S3 managed keys) by default at no additional cost.
  • Starting April 2023, all new S3 buckets have S3 Block Public Access enabled and ACLs disabled by default.
  • Starting April 2026, SSE-C (server-side encryption with customer-provided keys) is disabled by default on all new S3 general purpose buckets.

S3 Bucket Types

  • Amazon S3 offers multiple bucket types designed for different use cases:
    • General Purpose Buckets – Standard buckets for most workloads, storing objects across multiple Availability Zones for high durability
    • Directory Buckets – Used with S3 Express One Zone storage class, stored in a single Availability Zone for lowest latency access
    • Table Buckets – Store Apache Iceberg tables for analytics workloads with built-in table maintenance and optimization
    • Vector Buckets – Purpose-built for storing and querying vector embeddings for AI/ML applications

S3 Buckets & Objects

S3 Buckets

  • A bucket is a container for objects stored in S3
  • Buckets help organize the S3 namespace.
  • A bucket is owned by the AWS account that creates it and helps identify the account responsible for storage and data transfer charges.
  • Bucket names are globally unique, regardless of the AWS region in which it was created and the namespace is shared by all AWS accounts
  • Even though S3 is a global service, buckets are created within a region specified during the creation of the bucket.
  • Every object is contained in a bucket
  • There is no limit to the number of objects that can be stored in a bucket and no difference in performance whether a single bucket or multiple buckets are used to store all the objects
  • The S3 data model is a flat structure i.e. there are no hierarchies or folders within the buckets. However, logical hierarchy can be inferred using the key name prefix e.g. Folder1/Object1
  • Restrictions
    • 10,000 general purpose buckets (default quota) per AWS account, with the ability to request up to 1 million buckets. (Updated Nov 2024: increased from the previous limit of 100)
    • Bucket names should be globally unique and DNS compliant
    • Bucket ownership is not transferable
    • Buckets cannot be nested and cannot have a bucket within another bucket
    • Bucket name and region cannot be changed, once created
  • Empty or a non-empty buckets can be deleted
  • S3 allows retrieval of 1000 objects and provides pagination support

Objects

  • Objects are the fundamental entities stored in a bucket
  • An object is uniquely identified within a bucket by a key name and version ID (if S3 versioning is enabled on the bucket)
  • Objects consist of object data, metadata, and others
    • Key is the object name and a unique identifier for an object
    • Value is actual content stored
    • Metadata is the data about the data and is a set of name-value pairs that describe the object e.g. content-type, size, last modified. Custom metadata can also be specified at the time the object is stored.
    • Version ID is the version id for the object and in combination with the key helps to uniquely identify an object within a bucket
    • Subresources help provide additional information for an object
    • Access Control Information helps control access to the objects
  • S3 objects allow two kinds of metadata
    • System metadata
      • Metadata such as the Last-Modified date is controlled by the system. Only S3 can modify the value.
      • System metadata that the user can control, e.g., the storage class, and encryption configured for the object.
    • User-defined metadata
      • User-defined metadata can be assigned during uploading the object or after the object has been uploaded.
      • User-defined metadata is stored with the object and is returned when an object is downloaded
      • S3 does not process user-defined metadata.
      • User-defined metadata must begin with the prefix “x-amz-meta“, otherwise S3 will not set the key-value pair as you define it
  • Object metadata cannot be modified after the object is uploaded and it can be only modified by performing copy operation and setting the metadata
  • Objects belonging to a bucket that reside in a specific AWS region never leave that region, unless explicitly copied using Cross Region Replication
  • Each object can be up to 5 TB in size
  • An object can be retrieved as a whole or a partially
  • With Versioning enabled, current as well as previous versions of an object can be retrieved

S3 Bucket & Object Operations

  • Listing
    • S3 allows the listing of all the keys within a bucket
    • A single listing request would return a max of 1000 object keys with pagination support using an indicator in the response to indicate if the response was truncated
    • Keys within a bucket can be listed using Prefix and Delimiter.
    • Prefix limits result in only those keys (kind of filtering) that begin with the specified prefix, and the delimiter causes the list to roll up all keys that share a common prefix into a single summary list result.
  • Retrieval
    • An object can be retrieved as a whole
    • An object can be retrieved in parts or partially (a specific range of bytes) by using the Range HTTP header.
    • Range HTTP header is helpful
      • if only a partial object is needed for e.g. multiple files were uploaded as a single archive
      • for fault-tolerant downloads where the network connectivity is poor
    • Objects can also be downloaded by sharing Pre-Signed URLs
    • Metadata of the object is returned in the response headers
  • Object Uploads
    • Single Operation – Objects of size 5GB can be uploaded in a single PUT operation
    • Multipart upload – can be used for objects of size > 5GB and supports the max size of 5TB. It is recommended for objects above size 100MB.
    • Pre-Signed URLs can also be used and shared for uploading objects
    • Objects if uploaded successfully can be verified if the request received a successful response. Additionally, returned ETag can be compared to the calculated MD5 value of the upload object
  • Conditional Writes
    • S3 supports conditional writes using HTTP conditional headers to prevent unintended overwrites (Launched August 2024)
    • If-None-Match – prevents overwrites of existing objects by checking that no object with the same key exists; useful for write-once patterns
    • If-Match – ensures an object has not been modified since last read by comparing ETags; useful for read-modify-write patterns (Added November 2024)
    • Conditional writes can be enforced via bucket policies using s3:if-none-match and s3:if-match condition keys
    • Supported on PutObject, CompleteMultipartUpload, and CopyObject operations
    • Helps coordinate simultaneous writes from multiple writers without external locking mechanisms
  • Copying Objects
    • Copying of objects up to 5GB can be performed using a single operation and multipart upload can be used for uploads up to 5TB
    • When an object is copied
      • user-controlled system metadata e.g. storage class and user-defined metadata are also copied.
      • system controlled metadata e.g. the creation date etc is reset
    • Copying Objects can be needed to
      • Create multiple object copies
      • Copy objects across locations or regions
      • Renaming of the objects
      • Change object metadata for e.g. storage class, encryption, etc
      • Updating any metadata for an object requires all the metadata fields to be specified again
  • Deleting Objects
    • S3 allows deletion of a single object or multiple objects (max 1000) in a single call
    • For Non Versioned buckets,
      • the object key needs to be provided and the object is permanently deleted
    • For Versioned buckets,
      • if an object key is provided, S3 inserts a delete marker and the previous current object becomes the non-current object
      • if an object key with a version ID is provided, the object is permanently deleted
      • if the version ID is of the delete marker, the delete marker is removed and the previous non-current version becomes the current version object
    • Deletion can be MFA enabled for adding extra security
  • Restoring Objects from Glacier
    • Objects must be restored before accessing an archived object stored in S3 Glacier Flexible Retrieval or S3 Glacier Deep Archive
    • S3 Glacier Instant Retrieval provides millisecond access without requiring a restore operation
    • Retrieval options for Glacier Flexible Retrieval include:
      • Expedited – 1-5 minutes
      • Standard – 3-5 hours
      • Bulk – 5-12 hours
    • Restoration request also needs to specify the number of days for which the object copy needs to be maintained.
    • During this period, storage cost applies for both the archive and the copy.

Pre-Signed URLs

  • All buckets and objects are by default private.
  • Pre-signed URLs allows user to be able to download or upload a specific object without requiring AWS security credentials or permissions.
  • Pre-signed URL allows anyone to access the object identified in the URL, provided the creator of the URL has permission to access that object.
  • Pre-signed URLs creation requires the creator to provide security credentials, a bucket name, an object key, an HTTP method (GET for download object & PUT of uploading objects), and expiration date and time
  • Pre-signed URLs are valid only till the expiration date & time.
  • Pre-signed URLs can have a maximum expiration of 7 days when generated using SigV4.

Multipart Upload

  • Multipart upload allows the user to upload a single large object as a set of parts. Each part is a contiguous portion of the object’s data.
  • Multipart uploads support 1 to 10000 parts and each part can be from 5MB to 5GB with the last part size allowed to be less than 5MB
  • Multipart uploads allow a max upload size of 5TB
  • Object parts can be uploaded independently and in any order. If transmission of any part fails, it can be retransmitted without affecting other parts.
  • After all parts of the object are uploaded and completed initiated, S3 assembles these parts and creates the object.
  • Using multipart upload provides the following advantages:
    • Improved throughput – parallel upload of parts to improve throughput
    • Quick recovery from any network issues – Smaller part size minimizes the impact of restarting a failed upload due to a network error.
    • Pause and resume object uploads – Object parts can be uploaded over time. Once a multipart upload is initiated there is no expiry; you must explicitly complete or abort the multipart upload.
    • Begin an upload before the final object size is known – an object can be uploaded as is it being created
  • Three Step process
    • Multipart Upload Initiation
      • Initiation of a Multipart upload request to S3 returns a unique ID for each multipart upload.
      • This ID needs to be provided for each part upload, completion or abort request and listing of parts call.
      • All the Object metadata required needs to be provided during the Initiation call
    • Parts Upload
      • Parts upload of objects can be performed using the unique upload ID
      • A part number (between 1 – 10000) needs to be specified with each request which identifies each part and its position in the object
      • If a part with the same part number is uploaded, the previous part would be overwritten
      • After the part upload is successful, S3 returns an ETag header in the response which must be recorded along with the part number to be provided during the multipart completion request
    • Multipart Upload Completion or Abort
      • On Multipart Upload Completion request, S3 creates an object by concatenating the parts in ascending order based on the part number and associates the metadata with the object
      • Multipart Upload Completion request should include the unique upload ID with all the parts and the ETag information
      • The response includes an ETag that uniquely identifies the combined object data
      • On Multipart upload Abort request, the upload is aborted and all parts are removed. Any new part upload would fail. However, any in-progress part upload is completed, and hence an abort request must be sent after all the parts uploads have been completed.
      • S3 should receive a multipart upload completion or abort request else it will not delete the parts and storage would be charged.

S3 Transfer Acceleration

  • S3 Transfer Acceleration enables fast, easy, and secure transfers of files over long distances between the client and a bucket.
  • Transfer Acceleration takes advantage of CloudFront‘s globally distributed edge locations. As the data arrives at an edge location, data is routed to S3 over an optimized network path.
  • Transfer Acceleration will have additional charges while uploading data to S3 is free through the public Internet.

S3 Batch Operations

  • S3 Batch Operations help perform large-scale batch operations on S3 objects and can perform a single operation on lists of specified S3 objects.
  • A single job can perform a specified operation on billions of objects containing exabytes of data.
  • S3 tracks progress, sends notifications, and stores a detailed completion report of all actions, providing a fully managed, auditable, and serverless experience.
  • Batch Operations can be used with S3 Inventory to get the object list and use S3 Select to filter the objects.
  • Batch Operations can be used for copying objects, modify object metadata, applying ACLs, encrypting objects, transforming objects, invoke a custom lambda function, etc.

S3 Express One Zone

  • S3 Express One Zone is a high-performance, single-Availability Zone storage class designed for latency-sensitive applications (Launched November 2023)
  • Delivers data access speeds up to 10x faster and request costs up to 50-80% lower than S3 Standard
  • First S3 storage class where you can select a specific Availability Zone to co-locate storage with compute resources
  • Uses directory buckets instead of general purpose buckets, with a hierarchical namespace using forward slash (/) as delimiter
  • Designed for 99.95% availability within a single Availability Zone (vs. 99.99% for S3 Standard across multiple AZs)
  • Supports up to 200,000 reads and 100,000 writes per second per directory bucket
  • Ideal use cases:
    • Machine learning training and inference
    • Interactive analytics
    • Media content creation
    • High-performance computing (HPC)
    • Financial modeling
  • Uses session-based authentication (CreateSession API) for optimized request handling

S3 Tables (Apache Iceberg)

  • S3 Tables provide the first cloud object store with built-in Apache Iceberg support (Launched December 2024)
  • Optimized for analytics workloads with up to 3x faster query throughput and up to 10x higher transactions per second compared to self-managed tables
  • Stores tabular data in table buckets with tables as subresources
  • Provides automatic table maintenance including compaction, snapshot management, and unreferenced file removal
  • Supports Intelligent-Tiering access tiers for automatic cost optimization (Added 2025)
  • Integrates with analytics engines like Apache Spark, Trino, and Amazon Athena
  • Use cases: data lakes, business analytics, real-time analytics, and ML feature stores

S3 Vectors

  • S3 Vectors is the first cloud object storage with native support for storing and querying vector data (GA December 2025)
  • Reduces the total cost of storing and querying vectors by up to 90% compared to specialized vector database solutions
  • Uses a new bucket type — vector bucket — optimized for durable, low-cost vector storage
  • Supports up to 2 billion vectors per index and 10,000 vector indexes per vector bucket
  • Delivers sub-second latency for infrequent queries and ~100ms for frequent queries
  • Supports up to 50 metadata keys alongside each vector for fine-grained filtering
  • Ideal use cases:
    • AI agent persistent memory
    • Retrieval Augmented Generation (RAG)
    • Semantic search
    • Recommendation systems

S3 Files

  • S3 Files makes S3 buckets accessible as high-performance file systems on AWS compute resources (Launched April 2026)
  • First and only cloud object store that provides fully-featured, high-performance file system access via NFS v4.2
  • Provides full file system semantics with sub-millisecond latency on small files
  • Changes to data on the file system are automatically reflected in the S3 bucket
  • Can be attached to multiple compute resources enabling data sharing across clusters without duplication
  • Supported on EC2, Lambda, EKS, and ECS
  • Eliminates the tradeoff between object storage benefits and interactive file capabilities
  • Use cases: AI/ML training, legacy application migration, shared data access across compute

S3 Metadata

  • S3 Metadata automatically captures metadata for objects in general purpose buckets and stores it in read-only, fully managed Apache Iceberg tables (Preview Dec 2024, enhanced 2025)
  • Provides two types of metadata tables:
    • Journal table – records changes as objects are added or modified
    • Live inventory table – provides a complete current snapshot of all objects and their metadata
  • Accelerates data discovery for analytics, AI/ML model training, and content retrieval
  • Supports metadata for existing objects via backfill (Added July 2025)
  • Queryable using standard SQL via Amazon Athena, Spark, and other analytics engines

S3 Access Grants

  • S3 Access Grants provide a simplified model for defining access permissions to S3 data by prefix, bucket, or object (Launched November 2023)
  • Maps corporate identities from directories (Microsoft Entra ID, Okta) directly to S3 datasets without requiring IAM principal mapping
  • Integrates with AWS IAM Identity Center for trusted identity propagation
  • Logs end-user identity and application used to access S3 data in AWS CloudTrail
  • Integrates with AWS Glue, Amazon Redshift, and Lake Formation for analytics workloads
  • Provides fine-grained access control at the prefix or object level

Mountpoint for Amazon S3

  • Mountpoint for Amazon S3 is an open-source file client that mounts an S3 bucket as a local file system on Linux instances (GA August 2023)
  • Translates local file system API calls to S3 REST API calls automatically
  • Optimized for high-throughput read-heavy workloads (sequential and random reads, sequential writes)
  • Available as a CSI driver for Kubernetes/EKS containerized workloads
  • Backed by AWS support for customers with Business and Enterprise Support plans
  • Use cases: data lakes, machine learning training, HPC, media processing
  • Note: For full file system semantics including NFS access, see S3 Files (launched April 2026)

Virtual Hosted Style vs Path-Style Request

S3 allows the buckets and objects to be referred to in Path-style or Virtual hosted-style URLs

Path-style

  • Bucket name is not part of the domain (unless region specific endpoint used)
  • Endpoint used must match the region in which the bucket resides for e.g, if you have a bucket called mybucket that resides in the EU (Ireland) region with object named puppy.jpg, the correct path-style syntax URI is http://s3-eu-west-1.amazonaws.com/mybucket/puppy.jpg.
  • A “PermanentRedirect” error is received with an HTTP response code 301, and a message indicating what the correct URI is for the resource if a bucket is accessed outside the US East (N. Virginia) region with path-style syntax that uses either of the following:
    • http://s3.amazonaws.com
    • An endpoint for a region different from the one where the bucket resides for e.g., if you use http://s3-eu-west-1.amazonaws.com for a bucket that was created in the US West (N. California) region
  • Path-style URLs were planned for deprecation after September 30, 2020, but AWS has indefinitely delayed this plan. Virtual hosted-style is still recommended for all new implementations.

Virtual hosted-style

  • S3 supports virtual hosted-style and path-style access in all regions.
  • In a virtual-hosted-style URL, the bucket name is part of the domain name in the URL for e.g. http://bucketname.s3.amazonaws.com/objectname
  • S3 virtual hosting can be used to address a bucket in a REST API call by using the HTTP Host header
  • Benefits
    • attractiveness of customized URLs,
    • provides an ability to publish to the “root directory” of the bucket’s virtual server. This ability can be important because many existing applications search for files in this standard location.
  • S3 updates DNS to reroute the request to the correct location when a bucket is created in any region, which might take time.
  • S3 routes any virtual hosted-style requests to the US East (N.Virginia) region, by default, if the US East (N. Virginia) endpoint s3.amazonaws.com is used, instead of the region-specific endpoint (for e.g., s3-eu-west-1.amazonaws.com) and S3 redirects it with HTTP 307 redirect to the correct region.
  • When using virtual hosted-style buckets with SSL, the SSL wild card certificate only matches buckets that do not contain periods.To work around this, use HTTP or write your own certificate verification logic.
  • If you make a request to the http://bucket.s3.amazonaws.com endpoint, the DNS has sufficient information to route the request directly to the region where your bucket resides.

S3 Pricing

  • S3 costs vary by Region
  • S3 pricing has dropped approximately 85% since launch, with current rates as low as ~$0.021/GB/month for S3 Standard in US regions
  • Charges are incurred for
    • Storage – cost is per GB/month
    • Requests – per request cost varies depending on the request type GET, PUT
    • Data Transfer
      • data transfer-in is free
      • data transfer out is charged per GB/month (except in the same region or to Amazon CloudFront)

S3 Select (Maintenance Mode)

  • S3 Select is closed to new customers as of July 25, 2024. Existing customers can continue to use the service.
  • S3 Select enabled applications to retrieve only a subset of data from an object using simple SQL expressions
  • Recommended alternatives: S3 Object Lambda, Amazon Athena, or S3 Metadata with Apache Iceberg for querying object data

Additional Topics

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 S3 stand for?
    1. Simple Storage Solution.
    2. Storage Storage Storage (triple redundancy Storage).
    3. Storage Server Solution.
    4. Simple Storage Service
  2. What are characteristics of Amazon S3? Choose 2 answers
    1. Objects are directly accessible via a URL
    2. S3 should be used to host a relational database
    3. S3 allows you to store objects or virtually unlimited size
    4. S3 allows you to store virtually unlimited amounts of data
    5. S3 offers Provisioned IOPS
  3. You are building an automated transcription service in which Amazon EC2 worker instances process an uploaded audio file and generate a text file. You must store both of these files in the same durable storage until the text file is retrieved. You do not know what the storage capacity requirements are. Which storage option is both cost-efficient and scalable?
    1. Multiple Amazon EBS volume with snapshots
    2. A single Amazon Glacier vault
    3. A single Amazon S3 bucket
    4. Multiple instance stores
  4. A user wants to upload a complete folder to AWS S3 using the S3 Management console. How can the user perform this activity?
    1. Just drag and drop the folder using the flash tool provided by S3
    2. Use the Enable Enhanced Folder option from the S3 console while uploading objects
    3. The user cannot upload the whole folder in one go with the S3 management console
    4. Use the Enable Enhanced Uploader option from the S3 console while uploading objects (NOTE – The S3 console now natively supports folder upload via drag and drop without any special option)
  5. A media company produces new video files on-premises every day with a total size of around 100GB after compression. All files have a size of 1-2 GB and need to be uploaded to Amazon S3 every night in a fixed time window between 3am and 5am. Current upload takes almost 3 hours, although less than half of the available bandwidth is used. What step(s) would ensure that the file uploads are able to complete in the allotted time window?
    1. Increase your network bandwidth to provide faster throughput to S3
    2. Upload the files in parallel to S3 using mulipart upload
    3. Pack all files into a single archive, upload it to S3, then extract the files in AWS
    4. Use AWS Import/Export to transfer the video files
  6. A company is deploying a two-tier, highly available web application to AWS. Which service provides durable storage for static content while utilizing lower Overall CPU resources for the web tier?
    1. Amazon EBS volume
    2. Amazon S3
    3. Amazon EC2 instance store
    4. Amazon RDS instance
  7. You have an application running on an Amazon Elastic Compute Cloud instance, that uploads 5 GB video objects to Amazon Simple Storage Service (S3). Video uploads are taking longer than expected, resulting in poor application performance. Which method will help improve performance of your application?
    1. Enable enhanced networking
    2. Use Amazon S3 multipart upload
    3. Leveraging Amazon CloudFront, use the HTTP POST method to reduce latency.
    4. Use Amazon Elastic Block Store Provisioned IOPs and use an Amazon EBS-optimized instance
  8. When you put objects in Amazon S3, what is the indication that an object was successfully stored?
    1. Each S3 account has a special bucket named_s3_logs. Success codes are written to this bucket with a timestamp and checksum.
    2. A success code is inserted into the S3 object metadata.
    3. A HTTP 200 result code and MD5 checksum, taken together, indicate that the operation was successful.
    4. Amazon S3 is engineered for 99.999999999% durability. Therefore there is no need to confirm that data was inserted.
  9. You have private video content in S3 that you want to serve to subscribed users on the Internet. User IDs, credentials, and subscriptions are stored in an Amazon RDS database. Which configuration will allow you to securely serve private content to your users?
    1. Generate pre-signed URLs for each user as they request access to protected S3 content
    2. Create an IAM user for each subscribed user and assign the GetObject permission to each IAM user
    3. Create an S3 bucket policy that limits access to your private content to only your subscribed users’ credentials
    4. Create a CloudFront Origin Identity user for your subscribed users and assign the GetObject permission to this user
  10. You run an ad-supported photo sharing website using S3 to serve photos to visitors of your site. At some point you find out that other sites have been linking to the photos on your site, causing loss to your business. What is an effective method to mitigate this?
    1. Remove public read access and use signed URLs with expiry dates.
    2. Use CloudFront distributions for static content.
    3. Block the IPs of the offending websites in Security Groups.
    4. Store photos on an EBS volume of the web server.
  11. You are designing a web application that stores static assets in an Amazon Simple Storage Service (S3) bucket. You expect this bucket to immediately receive over 150 PUT requests per second. What should you do to ensure optimal performance?
    1. Use multi-part upload.
    2. Add a random prefix to the key names.
    3. Amazon S3 will automatically manage performance at this scale. (S3 automatically scales to handle at least 3,500 PUT/COPY/POST/DELETE and 5,500 GET/HEAD requests per second per partitioned prefix, with no prefix randomization needed)
    4. Use a predictable naming scheme, such as sequential numbers or date time sequences, in the key names
  12. What is the maximum number of S3 buckets available per AWS Account?
    1. 100 Per region
    2. There is no Limit
    3. 100 Per Account (Previously correct, but updated Nov 2024)
    4. 500 Per Account
    5. 100 Per IAM User
    6. 10,000 Per Account (default), up to 1 million per account by request (Updated Nov 2024)
  13. Your customer needs to create an application to allow contractors to upload videos to Amazon Simple Storage Service (S3) so they can be transcoded into a different format. She creates AWS Identity and Access Management (IAM) users for her application developers, and in just one week, they have the application hosted on a fleet of Amazon Elastic Compute Cloud (EC2) instances. The attached IAM role is assigned to the instances. As expected, a contractor who authenticates to the application is given a pre-signed URL that points to the location for video upload. However, contractors are reporting that they cannot upload their videos. Which of the following are valid reasons for this behavior? Choose 2 answers { “Version”: “2012-10-17”, “Statement”: [ { “Effect”: “Allow”, “Action”: “s3:*”, “Resource”: “*” } ] }
    1. The IAM role does not explicitly grant permission to upload the object. (The role has all permissions for all activities on S3)
    2. The contractorsˈ accounts have not been granted “write” access to the S3 bucket. (using pre-signed urls the contractors account don’t need to have access but only the creator of the pre-signed urls)
    3. The application is not using valid security credentials to generate the pre-signed URL.
    4. The developers do not have access to upload objects to the S3 bucket. (developers are not uploading the objects but its using pre-signed urls)
    5. The S3 bucket still has the associated default permissions. (does not matter as long as the user has permission to upload)
    6. The pre-signed URL has expired.
  14. A company wants to prevent concurrent writers from accidentally overwriting each other’s data in Amazon S3. Which S3 feature should they use?
    1. S3 Object Lock
    2. S3 Versioning with MFA Delete
    3. S3 Conditional Writes with If-None-Match or If-Match headers
    4. S3 Block Public Access
  15. A machine learning team needs the lowest latency access to frequently accessed training data stored in S3, and their compute resources are in a single Availability Zone. Which S3 storage class is MOST appropriate?
    1. S3 Standard
    2. S3 Intelligent-Tiering
    3. S3 Express One Zone
    4. S3 One Zone-Infrequent Access
  16. An organization wants to grant S3 data access to users based on their corporate directory identity without creating individual IAM users. Which S3 feature enables this? [Choose 1]
    1. S3 Bucket Policies with IAM conditions
    2. S3 ACLs with cross-account access
    3. S3 Access Grants with IAM Identity Center
    4. S3 Object Lambda Access Points
  17. Which of the following are S3 bucket types available as of 2025? (Choose 3)
    1. General purpose buckets
    2. Directory buckets
    3. Archive buckets
    4. Table buckets
    5. Compute buckets
  18. A data engineering team needs to automatically track and query metadata about millions of objects in their S3 bucket for data discovery. Which service should they use?
    1. S3 Inventory with Athena
    2. S3 Select with SQL queries
    3. S3 Metadata with managed Apache Iceberg tables
    4. AWS Glue Data Catalog

AWS S3 Data Protection

AWS S3 Data Protection

  • S3 provides S3 data protection using highly durable storage infrastructure designed for mission-critical and primary data storage.
  • Objects are redundantly stored on multiple devices across multiple facilities in an S3 region.
  • S3 PUT and PUT Object copy operations synchronously store the data across multiple facilities before returning SUCCESS.
  • Once the objects are stored, S3 maintains its durability by quickly detecting and repairing any lost redundancy.
  • S3 also regularly verifies the integrity of data stored using checksums. If S3 detects data corruption, it is repaired using redundant data.
  • In addition, S3 calculates checksums on all network traffic to detect corruption of data packets when storing or retrieving data.
  • S3 is designed for 99.999999999% (11 nines) durability and operates to be lossless.
  • Data protection against accidental overwrites and deletions can be added by enabling Versioning to preserve, retrieve and restore every version of the object stored.
  • S3 also provides the ability to protect data in transit (as it travels to and from S3) and at rest (while it is stored in S3).

S3 Data Integrity Protections

  • S3 provides end-to-end data integrity checking using checksums to verify data has not been altered in transit or at rest.
  • Starting December 2024, AWS SDKs automatically calculate CRC-based checksums (e.g., CRC32, CRC64NVME) for uploads by default, providing automatic data integrity protection.
  • S3 independently verifies these checksums and accepts objects after confirming data integrity was maintained in transit.
  • Supported checksum algorithms include:
    • CRC64NVME – Default checksum algorithm for latest SDKs
    • CRC32 – Default for directory buckets (S3 Express One Zone)
    • CRC32C
    • SHA-1
    • SHA-256
  • Checksums are stored with the object and can be validated when the object is downloaded.
  • S3 continually monitors data durability over time with periodic integrity checks of data at rest.

S3 Conditional Writes

  • Launched August 2024, S3 supports conditional writes that help prevent applications from unintentionally overwriting existing objects.
  • Conditional writes use HTTP conditional headers:
    • If-None-Match – Prevents overwrites by validating that no object with the same key exists (prevents creating duplicate objects).
    • If-Match – Validates an object is unmodified (by matching ETag) before updating it, helping coordinate simultaneous writes.
  • Supported on PutObject and CompleteMultipartUpload API requests.
  • November 2024: S3 added enforcement of conditional writes using bucket policies with s3:if-none-match and s3:if-match condition keys.
  • October 2025: S3 extended conditional write functionality to copy operations.
  • Useful for distributed applications that require coordination to prevent race conditions and duplicate writes.

S3 Versioning

  • Versioning is a means of keeping multiple variants of an object in the same bucket.
  • Versioning can be used to preserve, retrieve, and restore every version of every object stored in the bucket.
  • Once enabled, versioning cannot be disabled — only suspended.
  • When an object is deleted in a versioning-enabled bucket, a delete marker is created rather than removing the object permanently.
  • Versioning protects against accidental deletes and overwrites.
  • MFA Delete adds an additional layer of security by requiring MFA authentication to:
    • Change the versioning state of a bucket
    • Permanently delete an object version
  • Only the root account (bucket owner) can enable MFA Delete.

S3 Object Lock

  • S3 Object Lock provides Write-Once-Read-Many (WORM) protection for objects, preventing them from being deleted or overwritten for a fixed amount of time or indefinitely.
  • Object Lock requires S3 Versioning to be enabled (automatically enabled when Object Lock is activated).
  • Object Lock provides two retention modes:
    • Governance Mode – Users with specific IAM permissions (s3:BypassGovernanceRetention) can override or remove the lock. Protects against most users deleting objects.
    • Compliance Mode – No user, including the root account, can overwrite or delete the object during the retention period. The retention period cannot be shortened.
  • Legal Hold – Provides the same protection as a retention period but has no expiration date. Remains in place until explicitly removed. Requires s3:PutObjectLegalHold permission.
  • Object Lock can be applied at the bucket level (default retention) or individual object level.
  • S3 Batch Operations can be used to apply Object Lock retention at scale across petabytes of existing data.
  • Object Lock helps meet regulatory compliance requirements (SEC, FINRA, CFTC, etc.).

S3 Encryption

  • Starting January 5, 2023, Amazon S3 automatically encrypts ALL new objects at rest with server-side encryption using Amazon S3 managed keys (SSE-S3) as the base level of encryption, at no additional cost and with no impact on performance.
  • S3 supports the following encryption options:
    • SSE-S3 (Server-Side Encryption with S3 Managed Keys) – Default encryption for all buckets. Uses AES-256.
    • SSE-KMS (Server-Side Encryption with AWS KMS Keys) – Uses AWS Key Management Service for key management with additional audit trail via CloudTrail.
    • DSSE-KMS (Dual-Layer Server-Side Encryption with AWS KMS Keys) – Launched June 2023. Applies two layers of encryption using different implementations of AES-GCM algorithm. Designed for compliance workloads requiring CNSSP 15 multi-layer encryption.
    • SSE-C (Server-Side Encryption with Customer-Provided Keys) – Customer manages the encryption keys; S3 manages encryption/decryption.
  • S3 Bucket Keys reduce the cost of SSE-KMS by up to 99% by decreasing request traffic from S3 to KMS. A bucket-level key is used to create short-lived, bucket-specific keys for encryption.

SSE-C Disabled by Default (April 2026)

  • Starting April 6, 2026, Amazon S3 disables SSE-C (server-side encryption with customer-provided keys) by default for all new general purpose buckets.
  • For existing buckets in AWS accounts with no SSE-C encrypted objects, S3 also disabled SSE-C for new write requests.
  • Accounts with existing SSE-C usage are not affected — their bucket configurations remain unchanged.
  • SSE-C can be explicitly re-enabled per bucket if needed.
  • This change mitigates the risk of ransomware attacks where malicious actors encrypt objects with their own keys via SSE-C.

Refer blog post @ S3 Encryption

S3 Malware Protection

  • Launched June 2024, Amazon GuardDuty Malware Protection for Amazon S3 provides built-in malware and antivirus scanning for objects uploaded to S3 buckets.
  • Automatically scans newly uploaded objects using multiple AWS-developed and industry-leading third-party scanning engines.
  • GuardDuty automatically updates malware signatures every 15 minutes.
  • Can be configured to quarantine or tag potentially malicious objects before they are ingested into downstream processes.
  • Helps address compliance requirements for malware scanning without managing additional infrastructure.

AWS Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • AWS services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • AWS exam questions are not updated to keep up the pace with AWS updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.
  1. A customer is leveraging Amazon Simple Storage Service in eu-west-1 to store static content for a web-based property. The customer is storing objects using the Standard Storage class. Where are the customers objects replicated?
    1. A single facility in eu-west-1 and a single facility in eu-central-1
    2. A single facility in eu-west-1 and a single facility in us-east-1
    3. Multiple facilities in eu-west-1
    4. A single facility in eu-west-1
  2. A system admin is planning to encrypt all objects being uploaded to S3 from an application. The system admin does not want to implement his own encryption algorithm; instead he is planning to use server side encryption by supplying his own key (SSE-C). Which parameter is not required while making a call for SSE-C?
    1. x-amz-server-side-encryption-customer-key-AES-256
    2. x-amz-server-side-encryption-customer-key
    3. x-amz-server-side-encryption-customer-algorithm
    4. x-amz-server-side-encryption-customer-key-MD5
  3. A company needs to ensure that critical data stored in S3 cannot be accidentally or maliciously deleted for 7 years to comply with regulatory requirements. Which S3 feature should they use?
    1. S3 Versioning with MFA Delete
    2. S3 Cross-Region Replication
    3. S3 Object Lock in Compliance Mode
    4. S3 Lifecycle policies
  4. An organization wants to prevent applications from accidentally overwriting objects in their S3 bucket during concurrent upload operations. Which recently launched feature addresses this? (Select TWO)
    1. S3 Versioning
    2. S3 Conditional Writes with If-None-Match header
    3. S3 Object Lock in Governance Mode
    4. S3 Conditional Writes with If-Match header
    5. S3 Access Points
  5. Starting January 2023, what encryption is automatically applied to ALL new objects uploaded to Amazon S3 by default?
    1. SSE-KMS with AWS managed key
    2. SSE-C with customer-provided key
    3. SSE-S3 with Amazon S3 managed keys (AES-256)
    4. No encryption is applied by default
  6. A company requires two independent layers of encryption for their S3 objects to meet CNSSP 15 compliance requirements. Which S3 encryption option should they use?
    1. SSE-S3 with bucket keys enabled
    2. SSE-KMS with customer managed CMK
    3. SSE-C with client-provided encryption key
    4. DSSE-KMS (Dual-Layer Server-Side Encryption with AWS KMS)

References

AWS S3 Permissions

AWS S3 Permissions

  • By default, all S3 buckets, objects, and related subresources are private.
  • Only the Resource owner, the AWS account (not the user) that creates the resource, can access the resource.
  • Resource owner can be
    • AWS account that creates the bucket or object owns those resources
    • If an IAM user creates the bucket or object, the AWS account of the IAM user owns the resource
    • If the bucket owner grants cross-account permissions to other AWS account users to upload objects to the buckets, the objects are owned by the AWS account of the user who uploaded the object and not the bucket owner except for the following conditions
      • Bucket owner can deny access to the object, as it is still the bucket owner who pays for the object
      • Bucket owner can delete or apply archival rules to the object and perform restoration
  • User is the AWS Account or the IAM user who access the resource
  • Bucket owner is the AWS account that created a bucket
  • Object owner is the AWS account that uploads the object to a bucket, not owned by the account
  • S3 permissions are classified into
    • Resource based policies and
    • User policies

S3 Object Ownership

  • S3 Object Ownership is a bucket-level setting that controls ownership of objects uploaded to the bucket and allows disabling or enabling ACLs.
  • By default (since April 2023), Object Ownership is set to Bucket owner enforced and all ACLs are disabled for all new buckets.
  • A majority of modern use cases in S3 no longer require ACLs, and AWS recommends keeping ACLs disabled.
  • With ACLs disabled, the bucket owner owns all objects and manages access exclusively using policies (IAM policies, bucket policies, access point policies).
  • Object Ownership has three settings:
    • Bucket owner enforced (default) – ACLs are disabled. The bucket owner automatically owns and has full control over every object. ACLs no longer affect permissions. The bucket uses policies exclusively for access control.
    • Bucket owner preferred – ACLs are enabled. The bucket owner owns new objects written with the bucket-owner-full-control canned ACL. Objects uploaded with other ACLs are owned by the writing account.
    • Object writer – ACLs are enabled. The AWS account that uploads an object owns it and can grant access via ACLs.
  • When ACLs are disabled (Bucket owner enforced):
    • All bucket and object ACLs are disabled, giving full access only to the bucket owner
    • The bucket owner automatically owns and has full control over every object
    • ACLs no longer affect access permissions; access control is based on IAM policies, bucket policies, VPC endpoint policies, and Organizations SCPs/RCPs
    • Requests to set or update ACLs fail, but requests to read ACLs are still supported
    • Only PUT requests that don’t specify an ACL or specify bucket-owner-full-control are accepted
  • ACLs can be re-enabled at any time by changing to another Object Ownership setting, and preexisting ACLs are restored.
  • For S3 Replication across accounts, the Bucket owner enforced setting automatically changes replica ownership to the destination bucket owner without needing the s3:ObjectOwnerOverrideToBucketOwner permission.
  • Permissions required: s3:PutBucketOwnershipControls to set, s3:GetBucketOwnershipControls to view.

S3 Block Public Access

  • S3 Block Public Access provides controls to ensure that S3 resources never have public access.
  • Since April 2023, Block Public Access is enabled by default for all newly created buckets in all AWS Regions.
  • Block Public Access can be applied at three levels:
    • Bucket level – applies to a specific bucket and its objects
    • Account level – applies to all buckets in the AWS account (current and future)
    • Organization level – centrally managed via AWS Organizations policies across all member accounts
  • Block Public Access settings override S3 permissions that allow public access, regardless of how an object is added or bucket is created.
  • Four settings are available:
    • BlockPublicAcls – blocks PUT requests that include public ACLs for buckets and objects
    • IgnorePublicAcls – ignores all public ACLs on a bucket and its objects
    • BlockPublicPolicy – rejects bucket policy changes that grant public access
    • RestrictPublicBuckets – restricts access to buckets with public policies to only AWS service principals and authorized users
  • S3 takes the most restrictive combination of bucket-level, account-level, and organization-level settings.
  • AWS recommends turning on “Block all public access” unless public access is explicitly required for specific use cases.

User Policies

  • User policies use IAM with S3 to control the type of access a user or group of users has to specific parts of an S3 bucket the AWS account owns
  • User policy is always attached to a User, Group, or a Role
  • Anonymous permissions cannot be granted
  • If an AWS account that owns a bucket wants to grant permission to users in its account, it can use either a bucket policy or a user policy

Resource-Based policies

  • Bucket policies and access control lists (ACLs) are resource-based because they are attached to the S3 resources

Screen Shot 2016-03-28 at 5.57.36 PM

Bucket Policies

  • Bucket policy can be used to grant cross-account access to other AWS accounts or IAM users in other accounts for the bucket and objects in it.
  • Bucket policies provide centralized, access control to buckets and objects based on a variety of conditions, including S3 operations, requesters, resources, and aspects of the request (e.g. IP address)
  • If an AWS account that owns a bucket wants to grant permission to users in its account, it can use either a bucket policy or a user policy
  • Permissions attached to a bucket apply to all of the objects in that bucket created and owned by the bucket owner
  • Policies can either add or deny permissions across all (or a subset) of objects within a bucket
  • Only the bucket owner is allowed to associate a policy with a bucket
  • Bucket policies can cater to multiple use cases
    • Granting permissions to multiple accounts with added conditions
    • Granting read-only permission to an anonymous user
    • Limiting access to specific IP addresses
    • Restricting access to a specific HTTP referer
    • Restricting access to a specific HTTP header for e.g. to enforce encryption
    • Granting permission to a CloudFront OAI
    • Adding a bucket policy to require MFA
    • Granting cross-account permissions to upload objects while ensuring the bucket owner has full control
    • Granting permissions for S3 inventory and Amazon S3 analytics
    • Granting permissions for S3 Storage Lens

Access Control Lists (ACLs)

  • Note: Since April 2023, ACLs are disabled by default for all newly created S3 buckets (Object Ownership set to “Bucket owner enforced”). AWS recommends keeping ACLs disabled and using bucket policies instead for the majority of use cases.
  • Each bucket and object has an ACL associated with it.
  • An ACL is a list of grants identifying grantee and permission granted
  • ACLs are used to grant basic read/write permissions on resources to other AWS accounts.
  • ACL supports limited permissions set and
    • cannot grant conditional permissions, nor can you explicitly deny permissions
    • cannot be used to grant permissions for bucket subresources
  • Permission can be granted to an AWS account by the email address or the canonical user ID (is just an obfuscated Account Id). If an email address is provided, S3 will still find the canonical user ID for the user and add it to the ACL.
  • It is Recommended to use Canonical user ID as email address would not be supported
  • Bucket ACL
    • Only recommended use case for the bucket ACL is to grant write permission to the S3 Log Delivery group to write access log objects to the bucket
    • Bucket ACL will help grant write permission on the bucket to the Log Delivery group if access log delivery is needed to the bucket
    • Only way you can grant necessary permissions to the Log Delivery group is via a bucket ACL
  • Object ACL
    • Object ACLs control only Object-level Permissions
    • Object ACL is the only way to manage permission to an object in the bucket not owned by the bucket owner i.e. If the bucket owner allows cross-account object uploads and if the object owner is different from the bucket owner, the only way for the object owner to grant permissions on the object is through Object ACL
    • If the Bucket and Object is owned by the same AWS account, Bucket policy can be used to manage the permissions
    • If the Object and User is owned by the same AWS account, User policy can be used to manage the permissions
    • With Bucket owner enforced (default), cross-account object ownership issues are eliminated as the bucket owner automatically owns all objects

S3 Access Points

  • S3 Access Points are named network endpoints attached to buckets that simplify managing data access at scale for shared datasets.
  • Each access point has its own access point policy and can enforce distinct permissions and network controls for any request made through it.
  • Access point policies work in conjunction with the underlying bucket policy.
  • A bucket can have thousands of access points per AWS Region per account, each with a policy up to 20 KB.
  • Access points can only be used to perform object operations (GetObject, PutObject, etc.), not bucket operations like deleting buckets or configuring replication.
  • Network Controls:
    • Access points can be configured to accept requests only from a specific Virtual Private Cloud (VPC), restricting S3 data access to a private network.
    • Custom Block Public Access settings can be configured for each access point independently.
  • Use Cases:
    • Managing access for shared datasets (data lakes, media archives, user-generated content)
    • Creating individualized access points with permissions customized per application, team, or user
    • Simplifying complex bucket policies by distributing access rules across multiple access points
    • Restricting data access to specific VPCs for security compliance
  • S3 Multi-Region Access Points:
    • Provide a single global endpoint to access replicated datasets across multiple AWS Regions
    • Dynamically route requests via AWS Global Accelerator, reducing latency by up to 60%
    • Include failover controls for active-passive or active-active configurations
    • Allow shifting S3 data access request traffic between AWS Regions at any time
  • Access points are referenced using ARNs, access point aliases, or virtual-hosted-style URIs.

S3 Access Grants

  • S3 Access Grants (launched November 2023) provides a simplified model for defining access permissions to S3 data by prefix, bucket, or object.
  • Supports up to 100,000 grants per Region per account.
  • Grants access to both IAM principals and directly to users or groups from corporate directories (Microsoft Entra ID, Okta, Ping).
  • Key Capabilities:
    • Define direct access mappings of S3 prefixes to users and roles
    • Grant read-only, write-only, or read-write access on a per-prefix basis
    • Integrate with AWS IAM Identity Center for trusted identity propagation
    • End-user identities propagated to S3, simplifying audit via CloudTrail data events
    • Cross-account access support without frequent IAM policy updates
  • When to Use S3 Access Grants:
    • Bucket policy size limit (20 KB) is being reached
    • Granting corporate directory users/groups (Entra ID, Okta) access to S3 data for analytics
    • Cross-account access is needed without frequent policy updates
    • Data access is unstructured and object-level rather than row/column format
  • Components:
    • Access Grants Instance – container for grants, one per Region per account
    • Locations – registered S3 paths (default s3://, bucket, or prefix) with an IAM role
    • Grants – individual access mappings from a grantee to an S3 location with a permission level
  • Applications request temporary credentials from S3 Access Grants on behalf of the authenticated user.
  • Integrates with AWS services including Amazon SageMaker, Amazon Redshift, and AWS Glue.

S3 Request Authorization

When S3 receives a request, it must evaluate all the user policies, bucket policies, and ACLs to determine whether to authorize or deny the request.

S3 evaluates the policies in 3 context

  • User context is basically the context in which S3 evaluates the User policy that the parent AWS account (context authority) attaches to the user
  • Bucket context is the context in which S3 evaluates the access policies owned by the bucket owner (context authority) to check if the bucket owner has not explicitly denied access to the resource
  • Object context is the context where S3 evaluates policies owned by the Object owner (context authority)

Analogy

  • Consider 3 Parents (AWS Account) A, B and C with Child (IAM User) AA, BA and CA respectively
  • Parent A owns a Toy box (Bucket) with Toy AAA and also allows toys (Objects) to be dropped and picked up
  • Parent A can grant permission (User Policy OR Bucket policy OR both) to his Child AA to access the Toy box and the toys
  • Parent A can grant permissions (Bucket policy) to Parent B (different AWS account) to drop toys into the toys box. Parent B can grant permissions (User policy) to his Child BA to drop Toy BAA
  • Parent B can grant permissions (Object ACL) to Parent A to access Toy BAA
  • Parent A can grant permissions (Bucket Policy) to Parent C to pick up the Toy AAA who in turn can grant permission (User Policy) to his Child CA to access the toy
  • Parent A can grant permission (through IAM Role) to Parent C to pick up the Toy BAA who in turn can grant permission (User Policy) to his Child CA to access the toy

Bucket Operation Authorization

Screen Shot 2016-03-28 at 6.35.36 AM

  1. If the requester is an IAM user, the user must have permission (User Policy) from the parent AWS account to which it belongs
  2. Amazon S3 evaluates a subset of policies owned by the parent account. This subset of policies includes the user policy that the parent account attaches to the user.
  3. If the parent also owns the resource in the request (in this case, the bucket), Amazon S3 also evaluates the corresponding resource policies (bucket policy and bucket ACL) at the same time.
  4. Requester must also have permissions (Bucket Policy or ACL) from the bucket owner to perform a specific bucket operation.
  5. Amazon S3 evaluates a subset of policies owned by the AWS account that owns the bucket. The bucket owner can grant permission by using a bucket policy or bucket ACL.
  6. Note that, if the AWS account that owns the bucket is also the parent account of an IAM user, then it can configure bucket permissions in a user policy or bucket policy or both

Object Operation Authorization

Screen Shot 2016-03-28 at 6.39.54 AM

  1. If the requester is an IAM user, the user must have permission (User Policy) from the parent AWS account to which it belongs.
  2. Amazon S3 evaluates a subset of policies owned by the parent account. This subset of policies includes the user policy that the parent attaches to the user.
  3. If the parent also owns the resource in the request (bucket, object), Amazon S3 evaluates the corresponding resource policies (bucket policy, bucket ACL, and object ACL) at the same time.
  4. If the parent AWS account owns the resource (bucket or object), it can grant resource permissions to its IAM user by using either the user policy or the resource policy.
  5. S3 evaluates policies owned by the AWS account that owns the bucket.
  6. If the AWS account that owns the object in the request is not the same as the bucket owner, in the bucket context Amazon S3 checks the policies if the bucket owner has explicitly denied access to the object.
  7. If there is an explicit deny set on the object, Amazon S3 does not authorize the request.
  8. Requester must have permissions from the object owner (Object ACL) to perform a specific object operation.
  9. Amazon S3 evaluates the object ACL.
  10. If bucket and object owners are the same, access to the object can be granted in the bucket policy, which is evaluated in the bucket context.
  11. If the owners are different, the object owners must use an object ACL to grant permissions.
  12. If the AWS account that owns the object is also the parent account to which the IAM user belongs, it can configure object permissions in a user policy, which is evaluated in the user context.

Permission Delegation

  • If an AWS account owns a resource, it can grant those permissions to another AWS account.
  • That account can then delegate those permissions, or a subset of them, to users in the account. This is referred to as permission delegation.
  • But an account that receives permissions from another account cannot delegate permission cross-account to another AWS account.
  • If the Bucket owner wants to grant permission to the Object which does not belong to it to another AWS account it cannot do it through cross-account permissions and need to define an IAM role which can be assumed by the AWS account to gain access

AWS Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • AWS services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • AWS exam questions are not updated to keep up the pace with AWS updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.
  1. Which features can be used to restrict access to data in S3? Choose 2 answers
    1. Set an S3 ACL on the bucket or the object.
    2. Create a CloudFront distribution for the bucket.
    3. Set an S3 bucket policy.
    4. Enable IAM Identity Federation
    5. Use S3 Virtual Hosting
  2. Which method can be used to prevent an IP address block from accessing public objects in an S3 bucket?
    1. Create a bucket policy and apply it to the bucket
    2. Create a NACL and attach it to the VPC of the bucket
    3. Create an ACL and apply it to all objects in the bucket
    4. Modify the IAM policies of any users that would access the bucket
  3. A user has granted read/write permission of his S3 bucket using ACL. Which of the below mentioned options is a valid ID to grant permission to other AWS accounts (grantee) using ACL?
    1. IAM User ID
    2. S3 Secure ID
    3. Access ID
    4. Canonical user ID
  4. A root account owner has given full access of his S3 bucket to one of the IAM users using the bucket ACL. When the IAM user logs in to the S3 console, which actions can he perform?
    1. He can just view the content of the bucket
    2. He can do all the operations on the bucket
    3. It is not possible to give access to an IAM user using ACL
    4. The IAM user can perform all operations on the bucket using only API/SDK
  5. A root AWS account owner is trying to understand various options to set the permission to AWS S3. Which of the below mentioned options is not the right option to grant permission for S3?
    1. User Access Policy
    2. S3 Object Policy
    3. S3 Bucket Policy
    4. S3 ACL
  6. A system admin is managing buckets, objects and folders with AWS S3. Which of the below mentioned statements is true and should be taken in consideration by the sysadmin?
    1. Folders support only ACL
    2. Both the object and bucket can have an Access Policy but folder cannot have policy
    3. Folders can have a policy
    4. Both the object and bucket can have ACL but folders cannot have ACL
  7. A user has created an S3 bucket which is not publicly accessible. The bucket is having thirty objects which are also private. If the user wants to make the objects public, how can he configure this with minimal efforts?
    1. User should select all objects from the console and apply a single policy to mark them public
    2. User can write a program which programmatically makes all objects public using S3 SDK
    3. Set the AWS bucket policy which marks all objects as public
    4. Make the bucket ACL as public so it will also mark all objects as public
  8. You need to configure an Amazon S3 bucket to serve static assets for your public-facing web application. Which methods ensure that all objects uploaded to the bucket are set to public read? Choose 2 answers
    1. Set permissions on the object to public read during upload.
    2. Configure the bucket ACL to set all objects to public read.
    3. Configure the bucket policy to set all objects to public read.
    4. Use AWS Identity and Access Management roles to set the bucket to public read.
    5. Amazon S3 objects default to public read, so no action is needed.
  9. Amazon S3 doesn’t automatically give a user who creates _____ permission to perform other actions on that bucket or object.
    1. a file
    2. a bucket or object
    3. a bucket or file
    4. a object or file
  10. A root account owner is trying to understand the S3 bucket ACL. Which of the below mentioned options cannot be used to grant ACL on the object using the authorized predefined group?
    1. Authenticated user group
    2. All users group
    3. Log Delivery Group
    4. Canonical user group
  11. A user is enabling logging on a particular bucket. Which of the below mentioned options may be best suitable to allow access to the log bucket?
    1. Create an IAM policy and allow log access
    2. It is not possible to enable logging on the S3 bucket
    3. Create an IAM Role, which has access to the log bucket
    4. Provide ACL for the logging group
  12. A user is trying to configure access with S3. Which of the following options is not possible to provide access to the S3 bucket / object?
    1. Define the policy for the IAM user
    2. Define the ACL for the object
    3. Define the policy for the object
    4. Define the policy for the bucket
  13. A user is having access to objects of an S3 bucket, which is not owned by him. If he is trying to set the objects of that bucket public, which of the below mentioned options may be a right fit for this action?
    1. Make the bucket public with full access
    2. Define the policy for the bucket
    3. Provide ACL on the object
    4. Create an IAM user with permission
  14. A bucket owner has allowed another account’s IAM users to upload or access objects in his bucket. The IAM user of Account A is trying to access an object created by the IAM user of account B. What will happen in this scenario?
    1. The bucket policy may not be created as S3 will give error due to conflict of Access Rights
    2. It is not possible to give permission to multiple IAM users
    3. AWS S3 will verify proper rights given by the owner of Account A, the bucket owner as well as by the IAM user B to the object
    4. It is not possible that the IAM user of one account accesses objects of the other IAM user
  15. A company creates a new S3 bucket using default settings. What security features are automatically enabled? [Choose 2 answers]
    1. S3 Block Public Access is enabled
    2. Server-side encryption with customer-managed KMS keys
    3. ACLs are disabled (Object Ownership set to Bucket owner enforced)
    4. S3 Object Lock is enabled
    5. Cross-Region Replication is enabled
  16. A company has a shared data lake in S3 accessed by multiple teams. They want to simplify access management without complex bucket policies. Which approach is most appropriate?
    1. Create separate buckets for each team
    2. Create S3 Access Points with individualized policies per team
    3. Use S3 ACLs for each team’s objects
    4. Create one large bucket policy with all team permissions
  17. A company needs to grant corporate directory users (Microsoft Entra ID) access to specific S3 prefixes for analytics workloads without mapping each user to an IAM principal. Which S3 feature should they use?
    1. S3 Bucket Policies with IAM federation
    2. S3 Access Points
    3. S3 Access Grants
    4. S3 ACLs with canonical user IDs
  18. An organization wants to restrict S3 data access to requests originating only from within their VPC. Which feature allows creating an S3 endpoint that enforces VPC-only access?
    1. S3 Bucket Policy with VPC condition key
    2. S3 Access Point configured with VPC network origin
    3. S3 Block Public Access at account level
    4. S3 Object Ownership with Bucket owner enforced
  19. With S3 Object Ownership set to “Bucket owner enforced”, what happens when another AWS account uploads an object to the bucket?
    1. The upload fails unless the uploader specifies an ACL
    2. The uploading account retains ownership of the object
    3. The bucket owner automatically owns the object and ACLs have no effect
    4. The object is placed in a pending state until the bucket owner approves it

References

AWS S3 Lifecycle Rules – Transitions & Expiration

S3 Lifecycle Management

S3 Object Lifecycle Management

  • S3 Object lifecycle can be managed by using a lifecycle configuration, which defines how S3 manages objects during their lifetime.
  • Lifecycle configuration enables simplification of object lifecycle management, for e.g. moving of less frequently access objects, backup or archival of data for several years, or permanent deletion of objects.
  • S3 controls all transitions automatically.
  • Lifecycle Management rules applied to a bucket are applicable to all the existing objects in the bucket as well as the ones that will be added anew.
  • S3 Object lifecycle management allows the following types of actions:
    • Transition – changes the storage class for the objects.
    • Expiration – permanently deletes objects.
    • AbortIncompleteMultipartUpload – aborts incomplete multipart uploads after a specified number of days since initiation.
  • Lifecycle Management can be configured with Versioning, which allows storage of one current object version and zero or more non-current object versions.
  • Object’s lifecycle management applies to both Non Versioning and Versioning enabled buckets.
  • For Non Versioned buckets:
    • Transitioning period is considered from the object’s creation date.
  • For Versioned buckets:
    • Transitioning period for the current object is calculated from the object creation date.
    • Transitioning period for a non-current object is calculated from the date when the object became a noncurrent versioned object.
    • S3 uses the number of days since its successor was created as the number of days an object is noncurrent.
  • S3 calculates the time by adding the number of days specified in the rule to the object creation time and rounding the resulting time to the next day midnight UTC for e.g. if an object was created at 15/1/2016 10:30 AM UTC and you specify 3 days in a transition rule, which results in 18/1/2016 10:30 AM UTC and rounded to next day midnight time 19/1/2016 00:00 UTC.
  • Lifecycle configuration on MFA-enabled buckets is not supported.
  • 1000 lifecycle rules can be configured per bucket (not adjustable).
  • General purpose buckets – You can’t use a bucket policy to prevent deletions or transitions by an S3 Lifecycle rule. Even if your bucket policy denies all actions for all principals, your S3 Lifecycle configuration still functions as normal.
  • Directory buckets (S3 Express One Zone) – S3 Lifecycle supports expiration actions only (no transitions between storage classes). Bucket policies can block lifecycle deletions in directory buckets, requiring proper CreateSession permissions.

S3 Lifecycle Filters

  • Lifecycle rules can filter objects using the following criteria:
    • Prefix – applies rule to objects with a specific key prefix.
    • Object Tags – applies rule to objects with one or more specific tags.
    • Object Size – filters by ObjectSizeGreaterThan and/or ObjectSizeLessThan to specify minimum and maximum object sizes.
    • And operator – combines multiple filter criteria (prefix, tags, and size).
  • If the Filter element is left empty, the Lifecycle Rule applies to all objects in the bucket.
  • Object size filters allow overriding the default 128 KB minimum transition size restriction.

S3 Object Lifecycle Management Rules

Supported Lifecycle Transitions (Waterfall Model)

Amazon S3 supports a waterfall model for transitioning between storage classes:

  • S3 Standard → S3 Standard-IA, S3 Intelligent-Tiering, S3 One Zone-IA, S3 Glacier Instant Retrieval, S3 Glacier Flexible Retrieval, or S3 Glacier Deep Archive.
  • S3 Standard-IA → S3 Intelligent-Tiering, S3 One Zone-IA, S3 Glacier Instant Retrieval, S3 Glacier Flexible Retrieval, or S3 Glacier Deep Archive.
  • S3 Intelligent-Tiering → depends on the current access tier:
    • Frequent Access or Infrequent Access tier → S3 One Zone-IA, S3 Glacier Instant Retrieval, S3 Glacier Flexible Retrieval, or S3 Glacier Deep Archive.
    • Archive Instant Access tier → S3 Glacier Instant Retrieval, S3 Glacier Flexible Retrieval, or S3 Glacier Deep Archive.
    • Archive Access tier → S3 Glacier Flexible Retrieval or S3 Glacier Deep Archive.
    • Deep Archive Access tier → S3 Glacier Deep Archive.
  • S3 One Zone-IA → S3 Glacier Flexible Retrieval or S3 Glacier Deep Archive.
  • S3 Glacier Instant Retrieval → S3 Glacier Flexible Retrieval or S3 Glacier Deep Archive.
  • S3 Glacier Flexible Retrieval → S3 Glacier Deep Archive.

Lifecycle Transitions Constraints

  1. Object Size Default Behavior (Updated September 2024)
    • Objects smaller than 128 KB will not transition to any storage class by default.
    • This applies to all storage classes (updated from previous behavior that allowed small objects to transition to Glacier classes).
    • To allow smaller objects to transition, add an object size filter (ObjectSizeGreaterThan or ObjectSizeLessThan) to your rule.
    • Configurations created before September 2024 retain the previous behavior unless modified.
  2. Minimum 30 Days for S3 Standard-IA or S3 One Zone-IA
    • Objects must be stored for at least 30 days in the current storage class before being transitioned to S3 Standard-IA or S3 One Zone-IA.
    • Similarly, noncurrent objects in versioned buckets must be at least 30 days noncurrent.
  3. Minimum Storage Duration Charges
    • S3 Standard-IA / S3 One Zone-IA – 30 days minimum.
    • S3 Glacier Instant Retrieval – 90 days minimum.
    • S3 Glacier Flexible Retrieval – 90 days minimum.
    • S3 Glacier Deep Archive – 180 days minimum.
    • Deleting or transitioning objects before the minimum duration incurs prorated early deletion fees.
    • You can’t create a single lifecycle rule that transitions through storage classes faster than minimum durations allow (e.g., transition to Glacier Instant Retrieval after 4 days, then to Deep Archive after 20 days). Two separate rules are needed, but minimum duration charges still apply.
  4. Replication and Lifecycle Interaction (Updated March 2026)
    • S3 Lifecycle now prevents expiration and transition actions on objects with PENDING or FAILED replication status.
    • This ensures lifecycle does not act on objects until they have successfully replicated to their destination bucket.
    • For versioning-enabled or versioning-suspended buckets, objects with a Pending or Failed replication status cannot be transitioned.
  5. Archival Storage Overhead
    • For each object archived to S3 Glacier Flexible Retrieval or S3 Glacier Deep Archive, S3 adds 8 KB metadata (charged at S3 Standard rates) + 32 KB index data (charged at Glacier rates) = 40 KB total overhead per object.
    • Consider aggregating small objects into larger ones to reduce overhead costs.
  6. Expiration Rules
    • For Non Versioned bucket:
      • Object is permanently deleted.
    • For Versioned bucket:
      • Expiration applies to the Current object only and does not impact noncurrent versions.
      • S3 inserts a Delete Marker with a unique version ID; the previous current object becomes noncurrent.
      • S3 will not take any action if the Current object is already a Delete Marker.
      • If the bucket has a single object which is the Delete Marker (expired object delete marker), S3 removes the Delete Marker.
    • For Versioned Suspended bucket:
      • S3 inserts a Delete Marker with version ID null and overwrites any object with version ID null.
  7. NoncurrentVersionExpiration
    • Allows permanent deletion of noncurrent object versions after a specified number of days.
    • NewerNoncurrentVersions – Specifies how many noncurrent versions to retain (up to 100). S3 permanently deletes any additional noncurrent versions beyond this number.
    • Helps control storage costs in versioning-enabled buckets by keeping only a defined number of older versions.
  8. Asynchronous Processing
    • When an object reaches the end of its lifetime, S3 queues it for removal and removes it asynchronously.
    • There may be a delay between the expiration/transition date and the actual action.
    • However, billing changes occur based on the rule satisfaction date (except for transitions to S3 Intelligent-Tiering where billing changes after physical transition).
    • S3 Lifecycle rules run once each day.
  9. Tag-based Filter Evaluation
    • S3 evaluates objects against tag-based filters daily.
    • At execution time, S3 re-evaluates the object’s current tags. If the triggering tag is no longer present, the transition does not proceed.
    • Removing a tag does not guarantee immediate cancellation – the action may execute before the tag removal is observed.

S3 Lifecycle Event Notifications

  • S3 can send event notifications when lifecycle actions are performed:
    • s3:LifecycleTransition – notifies when an object is transitioned from one storage class to another.
    • s3:LifecycleExpiration:Delete – notifies when an object is permanently deleted (unversioned bucket) or when an object version is permanently deleted.
    • s3:LifecycleExpiration:DeleteMarkerCreated – notifies when S3 Lifecycle creates a delete marker for a current version in a versioned bucket.
  • Notifications can be published to SNS, SQS, or Lambda.
  • Useful for tracking and auditing lifecycle actions.

S3 Intelligent-Tiering and Lifecycle

  • S3 Intelligent-Tiering automatically moves objects through access tiers based on access patterns:
    • Frequent Access – default tier for newly uploaded objects.
    • Infrequent Access – objects not accessed for 30 consecutive days (40% lower cost).
    • Archive Instant Access – objects not accessed for 90 consecutive days (68% lower cost than Infrequent Access).
    • Archive Access (optional) – objects not accessed for 90-730 days (configurable).
    • Deep Archive Access (optional) – objects not accessed for 180-730 days (configurable).
  • Objects accessed in any tier are automatically moved back to the Frequent Access tier.
  • Lifecycle rules can transition objects from any storage class to S3 Intelligent-Tiering.
  • No retrieval charges when objects move between tiers within Intelligent-Tiering.
  • A monthly monitoring and automation charge per object applies.
  • No minimum object size requirement (no 128 KB minimum) for Intelligent-Tiering.

S3 Express One Zone Lifecycle (Directory Buckets)

  • S3 Express One Zone (directory buckets) supports S3 Lifecycle expiration rules since November 2024.
  • Supported actions: Expiration (delete objects) only. Transition actions between storage classes are not supported.
  • Lifecycle rules can filter by prefix or object size.
  • Unlike general purpose buckets, bucket policies in directory buckets can block lifecycle deletions – requires proper CreateSession permissions.
  • Useful for automatically cleaning up temporary or short-lived data in high-performance workloads.

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 an object is stored in the Standard S3 storage class and you want to move it to Glacier, what must you do in order to properly migrate it?
    1. Change the storage class directly on the object.
    2. Delete the object and re-upload it, selecting Glacier as the storage class.
    3. None of the above.
    4. Create a lifecycle policy that will migrate it after a minimum of 30 days. (Any object uploaded to S3 must first be placed into either the Standard, Reduced Redundancy, or Infrequent Access storage class. Once in S3 the only way to move the object to glacier is through a lifecycle policy. NOTE: As of current AWS updates, you can also use the CopyObject API or S3 console to directly change storage class, but lifecycle policies remain the automated approach.)
  2. A company wants to store their documents in AWS. Initially, these documents will be used frequently, and after a duration of 6 months, they would not be needed anymore. How would you architect this requirement?
    1. Store the files in Amazon EBS and create a Lifecycle Policy to remove the files after 6 months.
    2. Store the files in Amazon S3 and create a Lifecycle Policy to remove the files after 6 months.
    3. Store the files in Amazon Glacier and create a Lifecycle Policy to remove the files after 6 months.
    4. Store the files in Amazon EFS and create a Lifecycle Policy to remove the files after 6 months.
  3. Your firm has uploaded a large amount of aerial image data to S3. In the past, in your on-premises environment, you used a dedicated group of servers to process this data and used Rabbit MQ, an open source messaging system, to get job information to the servers. Once processed the data would go to tape and be shipped offsite. Your manager told you to stay with the current design, and leverage AWS archival storage and messaging services to minimize cost. Which is correct?
    1. Use SQS for passing job messages, use CloudWatch alarms to terminate EC2 worker instances when they become idle. Once data is processed, change the storage class of the S3 objects to Reduced Redundancy Storage (Need to replace On-Premises Tape functionality. Also, RRS is no longer recommended.)
    2. Setup Auto-Scaled workers triggered by queue depth that use spot instances to process messages in SQS. Once data is processed, change the storage class of the S3 objects to Reduced Redundancy Storage (Need to replace On-Premises Tape functionality. Also, RRS is no longer recommended.)
    3. Setup Auto-Scaled workers triggered by queue depth that use spot instances to process messages in SQS. Once data is processed, change the storage class of the S3 objects to Glacier (Glacier suitable for Tape backup. Note: Current terminology is S3 Glacier Flexible Retrieval.)
    4. Use SNS to pass job messages use CloudWatch alarms to terminate spot worker instances when they become idle. Once data is processed, change the storage class of the S3 object to Glacier.
  4. You have a proprietary data store on-premises that must be backed up daily by dumping the data store contents to a single compressed 50GB file and sending the file to AWS. Your SLAs state that any dump file backed up within the past 7 days can be retrieved within 2 hours. Your compliance department has stated that all data must be held indefinitely. The time required to restore the data store from a backup is approximately 1 hour. Your on-premise network connection is capable of sustaining 1gbps to AWS. Which backup methods to AWS would be most cost-effective while still meeting all of your requirements?
    1. Send the daily backup files to Glacier immediately after being generated (will not meet the RTO)
    2. Transfer the daily backup files to an EBS volume in AWS and take daily snapshots of the volume (Not cost effective)
    3. Transfer the daily backup files to S3 and use appropriate bucket lifecycle policies to send to Glacier (Store in S3 for seven days and then archive to S3 Glacier Flexible Retrieval)
    4. Host the backup files on a Storage Gateway with Gateway-Cached Volumes and take daily snapshots (Not Cost-effective as local storage as well as S3 storage)
  5. A company has millions of small objects (5 KB each) stored in S3 Standard. They want to create a lifecycle rule to transition these objects to S3 Glacier Flexible Retrieval after 90 days. What should they consider?
    1. Objects smaller than 128 KB will not be transitioned by default. They should use an object size filter to explicitly allow small object transitions, and also consider the 40 KB per-object storage overhead in Glacier.
    2. Objects smaller than 128 KB are automatically transitioned to Glacier with no restrictions.
    3. Small objects cannot be stored in any Glacier storage class.
    4. They must first transition to Standard-IA before transitioning to Glacier.
  6. A company uses S3 Cross-Region Replication (CRR) and S3 Lifecycle rules on the same bucket. Some objects have a replication status of FAILED. What happens when the lifecycle expiration rule is triggered for these objects?
    1. The objects are immediately deleted as per the lifecycle rule.
    2. S3 Lifecycle pauses expiration and transition actions on objects with PENDING or FAILED replication status until replication succeeds or is resolved.
    3. The objects are transitioned to Glacier despite the failed replication.
    4. The lifecycle rule is permanently disabled for the bucket.
  7. Which of the following is a valid S3 Lifecycle transition path?
    1. S3 Glacier Deep Archive → S3 Standard
    2. S3 One Zone-IA → S3 Standard-IA
    3. S3 Glacier Instant Retrieval → S3 Glacier Flexible Retrieval
    4. S3 Glacier Flexible Retrieval → S3 Glacier Instant Retrieval
  8. A company wants to retain only the 5 most recent noncurrent versions of objects in a versioned S3 bucket and delete all older versions. Which lifecycle configuration should they use?
    1. Set an Expiration action with Days = 5
    2. Use a transition rule to move old versions to Glacier
    3. Configure NoncurrentVersionExpiration with NewerNoncurrentVersions set to 5
    4. Enable S3 Object Lock with a retention period of 5 days

References

AWS Interaction Tools – Certification

AWS Interaction Tools Overview

AWS is API-driven and provides multiple interaction tools to enable communication with its services. These tools range from graphical interfaces to programmatic access, supporting diverse workflows and automation needs.

AWS Management Console

  • AWS Management Console is a web-based graphical user interface (GUI) to access and manage AWS services
  • Requires credentials in the form of User Name and Password (or federated identity via IAM Identity Center) to log in
  • Uses Query APIs underlying for its interaction with AWS
  • Supports Multi-Factor Authentication (MFA) for enhanced security
  • Includes Amazon Q Developer integration providing AI-powered assistance for resource analysis, troubleshooting, and best practices guidance directly within the console
  • Features Console-to-Code (GA Oct 2024) — records console actions and uses generative AI to generate equivalent AWS CLI commands, CloudFormation templates, or CDK code
  • Received a visual update (2024-2025) with improved typography, visual hierarchy, and streamlined navigation
  • Supports visual customization to selectively display relevant AWS Regions and services, reducing cognitive load
  • Available via the AWS Console Mobile App, which evolved into an operational platform in 2025 with AI assistance, observability, and financial management capabilities

AWS Command Line Interface (CLI)

  • AWS Command Line Interface (CLI) is a unified tool that provides a consistent interface for interacting with all parts of AWS
  • Provides commands for a broad set of AWS products, and is supported on Windows, Mac, and Linux
  • AWS CLI v2 is the current recommended version (GA since Feb 2020) with enhanced features including:
    • AWS IAM Identity Center (SSO) integration for authentication
    • Client-side pager for output
    • New output formats (announced 2025) with improved error messaging using aws: [ERROR]: prefix
    • Account-based endpoints using AWS account ID (2025)
    • OAuth 2.0 authorization code flows with PKCE (v2.22.0+, 2025) as default for aws sso login
    • Upgrade debug mode to assist migration from v1 to v2
  • AWS CLI v1 will enter maintenance mode on July 15, 2026 and reach end-of-support on July 15, 2027. Users should migrate to CLI v2.
  • CLI requires Access Key & Secret Key credentials (or IAM Identity Center/SSO token) for interaction
  • CLI constructs and sends requests to AWS, signing requests using credentials provided
  • Handles connection details such as calculating signatures, request retries, and error handling
  • Integrates with Amazon Q Developer CLI (2025) providing agentic coding capabilities — can read/write files, query AWS resources, write code, and debug issues from the terminal

AWS CloudShell

  • AWS CloudShell is a browser-based, pre-authenticated shell launched directly from the AWS Management Console
  • Based on Amazon Linux 2023 (migrated from AL2 in 2024)
  • Pre-installed with AWS CLI v2, Python, Node.js, git, make, pip, and other development tools
  • Supports Bash, PowerShell, and Z shell
  • Provides 1 GB of persistent storage per Region at no additional cost
  • Supports VPC connectivity, Docker environments, and improved start times (2024)
  • Users are pre-authenticated — no need to configure credentials separately
  • Replaced AWS Cloud9 as the recommended browser-based development environment (Cloud9 closed to new customers in July 2024)

Software Development Kits (SDKs)

  • Software Development Kits (SDKs) simplify using AWS services in applications with an API tailored to your programming language or platform
  • SDKs currently support a wide range of languages including:
    • Java (SDK v2.x — GA since Nov 2018; v1.x reached end-of-support Dec 2025)
    • Python (Boto3)
    • JavaScript/TypeScript (SDK v3.x — GA since Dec 2020; v2 end-of-support Sept 2025)
    • .NET (SDK v4.x — GA April 2025; v3.x still supported)
    • Go (SDK v2 — GA since Jan 2021; v1 end-of-support July 2025)
    • PHP (SDK v3.x)
    • Ruby
    • C++ (SDK v1.x)
    • Rust (GA since Nov 2023) — idiomatic, type-safe API with async/await and non-blocking IO
    • Kotlin (GA since Nov 2023) — multiplatform support for JVM and Android
    • Swift (GA since Sept 2024) — for iOS, macOS, and server-side Swift applications
  • SDKs construct and send requests to AWS, signing requests using credentials provided
  • Handle connection details such as calculating signatures, request retries, and error handling
  • Follow the AWS SDKs and Tools maintenance policy with defined lifecycle phases (GA → Maintenance → End-of-Support)

Infrastructure as Code (IaC) Tools

  • AWS CloudFormation — declarative infrastructure provisioning using JSON/YAML templates
    • 2025 enhancements: early validation, improved drift management, AI-powered development with IaC MCP Server
  • AWS Cloud Development Kit (CDK) — define infrastructure using familiar programming languages (TypeScript, Python, Java, C#, Go)
    • CDK v2 consolidates all stable constructs into a single aws-cdk-lib package
    • 2025: CLI and Construct Library split into independent release cadences
    • 2025: cdk refactor command (preview) for safe infrastructure reorganization
  • AWS SAM (Serverless Application Model) — extension of CloudFormation for serverless applications

Query APIs

  • Query APIs provide HTTP or HTTPS requests that use the HTTP verb GET or POST and a Query parameter named “Action”
  • Require Access Key & Secret Key credentials for authentication
  • Query APIs form the core of all access tools and require you to calculate signatures (Signature Version 4) and attach them to the request
  • All other tools (Console, CLI, SDKs) use Query APIs or REST APIs under the hood

AWS Tools for PowerShell

  • AWS Tools for PowerShell enables managing AWS services from the PowerShell command line
  • Built on the AWS SDK for .NET, exposing AWS services as PowerShell cmdlets
  • Available as AWS.Tools (modular), AWSPowerShell.NetCore, and AWSPowerShell packages
  • Supports IAM Identity Center (SSO) authentication
  • Available on Windows PowerShell 5.1+ and PowerShell 7+ (cross-platform)

Amazon Q Developer

  • Amazon Q Developer is an AI-powered assistant integrated across AWS tools:
    • In Console — provides resource analysis, operational troubleshooting, and best practices guidance
    • In CLI — agentic coding experience for reading/writing files, querying resources, and debugging
    • In IDEs — code generation, reviews, documentation, and unit test generation
    • Console-to-Code — records console actions and generates equivalent IaC code
  • Supports Model Context Protocol (MCP) for integration with external AI tools
  • Available in AWS CloudShell and SageMaker Unified Studio

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. REST or Query requests are HTTP or HTTPS requests that use an HTTP verb (such as GET or POST) and a parameter named Action or Operation that specifies the API you are calling.
    1. FALSE
    2. TRUE (Refer link)
  2. Through which of the following interfaces is AWS Identity and Access Management available?
    A) AWS Management Console
    B) Command line interface (CLI)
    C) IAM Query API
    D) Existing libraries

    1. Only through Command line interface (CLI)
    2. A, B and C
    3. A and C
    4. All of the above
  3. Which of the following programming languages have an officially supported AWS SDK? Choose 2 answers
    1. PHP
    2. Pascal
    3. Java
    4. SQL
    5. Perl
  4. HTTP Query-based requests are HTTP requests that use the HTTP verb GET or POST and a Query parameter named_____________.
    1. Action
    2. Value
    3. Reset
    4. Retrieve
  5. Which AWS service provides a browser-based shell environment that is pre-authenticated with your console credentials?
    1. AWS Cloud9
    2. AWS CloudShell
    3. Amazon EC2 Instance Connect
    4. AWS Systems Manager Session Manager
  6. A company wants to convert console actions into reusable infrastructure-as-code. Which AWS feature should they use?
    1. AWS CloudTrail
    2. AWS Config
    3. AWS Console-to-Code (Amazon Q Developer)
    4. AWS CloudFormation Designer
  7. Which of the following are valid AWS SDK languages as of 2025? (Choose 3)
    1. Rust
    2. Perl
    3. Kotlin
    4. COBOL
    5. Swift
  8. A developer needs to interact with AWS services from the command line using single sign-on credentials. Which approach is recommended?
    1. Store long-term access keys in ~/.aws/credentials
    2. Configure AWS CLI v2 with IAM Identity Center (SSO) authentication
    3. Use AWS CLI v1 with environment variables
    4. Embed credentials in application code