Encryption

Google Cloud Storage Security – IAM, ACLs & CMEK

~ Last updated on : ~ jayendrapatil

Google Cloud Storage Security

Google Cloud Storage Security includes controlling access using

  • Uniform Bucket or Fine-grained ACL access control policies
  • Public Access Prevention
  • VPC Service Controls for data perimeter security
  • Managed Folders for granular IAM
  • Data encryption at rest and transit
  • Retention policies, Object Retention Lock, and Bucket Lock
  • Soft Delete for recovery from accidental deletion
  • Signed URLs

GCS Access Control

  • Cloud Storage offers two systems for granting users permission to access the buckets and objects: IAM and Access Control Lists (ACLs)
  • IAM and ACLs can be used on the same resource, Cloud Storage grants the broader permission set on the resource
  • Cloud Storage access control can be performed using
    • Uniform (recommended)
      • Uniform bucket-level access allows using IAM alone to manage permissions.
      • IAM applies permissions to all the objects contained inside the bucket or groups of objects with common name prefixes.
      • IAM also allows using features that are not available when working with ACLs, such as IAM Conditions and Cloud Audit Logs.
      • Enabling uniform bucket-level access disables ACLs, but it can be reversed before 90 days
    • Fine-grained
      • Fine-grained option enables using IAM and Access Control Lists (ACLs) together to manage permissions.
      • ACLs are a legacy access control system for Cloud Storage designed for interoperability with S3.
      • Access and apply permissions can be specified at both the bucket level and per individual object.
  • Objects in the bucket can be made public using ACLs AllUsers:R or IAM allUsers:objectViewer permissions

Public Access Prevention

  • Public Access Prevention protects Cloud Storage buckets and objects from being accidentally exposed to the public.
  • When enforced, no one can make data in applicable buckets public through IAM policies or ACLs.
  • Can be set at the bucket level or enforced at the project, folder, or organization level using the storage.publicAccessPrevention organization policy constraint.
  • When applied at the organization level, public access is restricted for all buckets and objects, both new and existing, under that resource.
  • Public access prevention does not apply to Signed URLs, since signed URLs grant access through scoped service account permissions.

Managed Folders

  • Managed folders allow granting IAM roles on specific groups of objects within a bucket, providing more fine-grained access control.
  • IAM policies can be set on managed folders to control access to objects that share a common name prefix.
  • Managed folders can be nested up to 15 levels deep.
  • Requires uniform bucket-level access to be enabled on the bucket.
  • Useful for meeting data security and compliance requirements by restricting access to specific data partitions within a shared bucket.

VPC Service Controls

  • VPC Service Controls create a security perimeter around Cloud Storage resources to prevent data exfiltration.
  • Data cannot be copied to unauthorized resources outside the perimeter using operations such as gcloud storage cp.
  • Protects against data exfiltration risks such as stolen credentials, misconfigured permissions, or malicious insiders.
  • Fine-grained perimeter controls can be enforced across multiple Google Cloud services and projects.
  • Supports access levels, ingress/egress rules, and perimeter bridges for controlled data sharing.

Bucket IP Filtering

  • Bucket IP filtering allows restricting access to a bucket based on the source IP address of incoming requests.
  • IP filtering rules can be configured to allow or deny access from specific IP ranges.
  • Provides an additional layer of network-level security for sensitive buckets.
  • Can be bypassed by authorized principals with specific IAM permissions when needed.

Data Encryption

  • Cloud Storage always encrypts the data on the server-side, before it is written to disk, at no additional charge.
  • Cloud supports the following encryption
    • Server-side encryption: encryption that occurs after Cloud Storage receives the data, but before the data is written to disk and stored.
      • Google-managed encryption keys (default)
        • Cloud Storage always encrypts the data on the server-side, before it is written to disk
        • Cloud Storage manages server-side encryption keys using the same hardened key management systems, including strict key access controls and auditing.
        • Cloud Storage encrypts user data at rest using AES-256.
        • Data is automatically decrypted when read by an authorized user
      • Customer-managed encryption keys (CMEK)
        • Customers manage their own encryption keys generated by Cloud Key Management Service (KMS)
        • CMEK keys can be set as the default encryption key for a bucket, which then applies to all new objects.
        • Supports organization policy constraints (constraints/gcp.restrictNonCmekServices) to enforce CMEK usage across the organization.
        • Cloud KMS Autokey (GA 2024) simplifies CMEK by automatically provisioning key rings, keys, and service agent IAM roles on demand during resource creation — eliminating manual key planning and assignment.
        • CMEK keys can be stored as software keys, in an HSM cluster, or externally (Cloud External Key Manager).
      • Customer-supplied encryption keys (CSEK)
        • Customers create and manage their own encryption keys outside of Google Cloud.
        • Customer provides the key for each GCS operation, and the key is purged from Google’s servers after the operation is complete.
        • Cloud Storage stores only a cryptographic hash of the key so that future requests can be validated against the hash.
        • The key cannot be recovered from this hash, and the hash cannot be used to decrypt the data.
    • Client-side encryption: encryption that occurs before data is sent to Cloud Storage, encrypted at the client-side. This data also undergoes server-side encryption.
  • Cloud Storage supports Transport Layer Security, commonly known as TLS or HTTPS for data encryption in transit
  • Organization policy constraints can be used to enforce or restrict encryption types (e.g., require CMEK for all new buckets).

Signed URLs

  • Signed URLs provide time-limited read or write access to an object through a generated URL.
  • Anyone having access to the URL can access the object for the duration of time specified, regardless of whether or not they have a Google account.
  • Uses the V4 signing process with a maximum expiration of 604,800 seconds (7 days).
  • Signed URLs can only be used to access resources through XML API endpoints.
  • Can be signed using a service account private key or HMAC key credentials.
  • Public access prevention does not block access via signed URLs.

Signed Policy Documents

  • Signed policy documents help specify what can be uploaded to a bucket.
  • Policy documents allow greater control over size, content type, and other upload characteristics than signed URLs, and can be used by website owners to allow visitors to upload files to Cloud Storage.

Soft Delete

  • Soft delete (GA 2024) provides bucket-level protection against accidental or malicious deletion by retaining recently deleted objects for a configurable retention period.
  • Soft delete is enabled by default on all buckets with a retention duration of 7 days.
  • Retention duration can be set between 7 and 90 days, or soft delete can be disabled entirely.
  • Soft-deleted objects can be restored within the retention window.
  • Soft-deleted buckets can also be restored.
  • Organization-level tags can be used to set a default soft delete retention duration for new buckets.
  • Soft-deleted objects incur storage charges at the same rate as active objects.

Retention Policies

  • Retention policy on a bucket ensures that all current and future objects in the bucket cannot be deleted or replaced until they reach the defined age
  • Retention policy can be applied when creating a bucket or to an existing bucket
  • Retention policy retroactively applies to existing objects in the bucket as well as new objects added to the bucket.

Retention Policy Locks

  • Retention policy locks will lock a retention policy on a bucket, which prevents the policy from ever being removed or the retention period from ever being reduced (although it can be increased)
  • Once a retention policy is locked, the bucket cannot be deleted until every object in the bucket has met the retention period.
  • Locking a retention policy is irreversible

Bucket Lock

  • Bucket Lock feature provides immutable storage i.e. Write Once Read Many (WORM) on Cloud Storage
  • Bucket Lock feature allows configuring a data retention policy for a bucket that governs how long objects in the bucket must be retained
  • Bucket Lock feature also locks the data retention policy, permanently preventing the policy from being reduced or removed.
  • Bucket Lock applies the retention policy uniformly to all objects in the bucket.
  • Bucket Lock can help with regulatory, legal, and compliance requirements

Object Retention Lock

  • Object Retention Lock (GA 2024) allows defining data retention requirements on a per-object basis, unlike Bucket Lock which applies uniformly to all objects.
  • A retention configuration on an object contains:
    • Retain-until time — a date and time until which the object cannot be deleted or replaced (max 100 years from current date).
    • Retention mode:
      • Unlocked (Governance) — authorized users can modify or remove the retention configuration.
      • Locked (Compliance) — permanently prevents the retention date from being reduced or removed; the mode cannot be changed and retention can only be increased.
  • Object Retention Lock must be enabled on the bucket before retention configurations can be set on objects. Once enabled, it cannot be disabled.
  • Can help with regulatory and compliance requirements such as FINRA, SEC, CFTC, and health care regulations.
  • An object can be subject to both its own Object Retention Lock and a Bucket Lock retention policy — the object is retained until both are satisfied.
  • Storage batch operations can be used to set or update retention configurations on millions of objects in a single job.

Object Holds

  • Object holds, when set on individual objects, prevents the object from being deleted or replaced, however allows metadata to be edited.
  • Cloud Storage offers the following types of holds:
    • Event-based holds.
    • Temporary holds.
  • When an object is stored in a bucket without a retention policy, both hold types behave exactly the same.
  • When an object is stored in a bucket with a retention policy, the hold types have different effects on the object when the hold is released:
    • An event-based hold resets the object’s time in the bucket for the purposes of the retention period.
    • A temporary hold does not affect the object’s time in the bucket for the purposes of the retention period.

Organization Policy Constraints

  • Cloud Storage supports predefined and custom organization policy constraints to enforce security standards across the organization.
  • Key predefined constraints include:
    • storage.publicAccessPrevention — enforce public access prevention on all buckets.
    • storage.uniformBucketLevelAccess — require uniform bucket-level access (disable ACLs).
    • storage.retentionPolicySeconds — enforce minimum retention policies.
    • gcp.restrictNonCmekServices — require CMEK encryption for Cloud Storage.
    • storage.restrictAuthTypes — restrict authentication types.
  • Custom constraints can be created to enforce specific bucket or object behaviors not covered by predefined constraints.
  • Detailed audit logging mode logs request and response details for Cloud Storage, helping with regulatory compliance.

GCP 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).
  • GCP services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • GCP exam questions are not updated to keep up the pace with GCP updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.
  1. You have an object in a Cloud Storage bucket that you want to share with an external company. The object contains sensitive data. You want access to the content to be removed after four hours. The external company does not have a Google account to which you can grant specific user-based access privileges. You want to use the most secure method that requires the fewest steps. What should you do?
    1. Create a signed URL with a four-hour expiration and share the URL with the company.
    2. Set object access to “public” and use object lifecycle management to remove the object after four hours.
    3. Configure the storage bucket as a static website and furnish the object’s URL to the company. Delete the object from the storage bucket after four hours.
    4. Create a new Cloud Storage bucket specifically for the external company to access. Copy the object to that bucket. Delete the bucket after four hours have passed
  2. Your organization requires that all Cloud Storage buckets in production must use Customer-Managed Encryption Keys (CMEK) and must not be publicly accessible. How should you enforce this?
    1. Set organization policy constraints gcp.restrictNonCmekServices with Cloud Storage in the deny list and storage.publicAccessPrevention enforced at the organization level.
    2. Create a Cloud Function that checks each new bucket and deletes it if not compliant.
    3. Use IAM conditions to prevent bucket creation without CMEK.
    4. Train developers to always use CMEK and enable public access prevention manually.
  3. A compliance requirement states that certain objects in a shared bucket must be retained for 5 years and cannot be deleted, while other objects in the same bucket have no retention requirement. What is the best approach?
    1. Create separate buckets with different Bucket Lock retention policies for each set of objects.
    2. Use Object Retention Lock with Locked (Compliance) mode and set a retain-until time of 5 years on the specific objects that require retention.
    3. Use Object Lifecycle Management to prevent deletion of specific objects.
    4. Set a Bucket Lock retention policy of 5 years on the entire bucket.
  4. Your team accidentally deleted critical objects from a Cloud Storage bucket yesterday. The bucket has default settings. What is the best recovery option?
    1. Recover from a backup bucket if one was configured.
    2. Restore the soft-deleted objects, since soft delete is enabled by default with a 7-day retention duration.
    3. Contact Google Cloud support to recover the objects.
    4. Use Object Versioning to retrieve previous versions.
  5. You need to provide granular access to a specific set of objects within a bucket that uses uniform bucket-level access, without granting access to the entire bucket. What should you use?
    1. Switch to fine-grained access control and use ACLs on individual objects.
    2. Create signed URLs for each object.
    3. Create a managed folder for the objects and set IAM policies on the managed folder.
    4. Create a separate bucket for those objects.

AWS Elastic Block Store Storage – EBS

~ Last updated on : ~ jayendrapatil ~ 61 Comments

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 Encrypting Data at Rest – Whitepaper – Certification

~ Last updated on : ~ jayendrapatil ~ 11 Comments

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

AWS S3 Data Protection

~ Last updated on : ~ jayendrapatil ~ 4 Comments

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