S3

Amazon S3 Replication

S3 Replication
~ Last updated on : ~ jayendrapatil

Amazon S3 Replication

  • S3 Replication enables automatic, asynchronous copying of objects across S3 buckets in the same or different AWS regions.
  • S3 Replication supports two types:
    • Live Replication – automatically replicates new and updated objects as they are written to the source bucket.
    • On-Demand Replication (Batch Replication) – replicates existing objects from the source bucket to destination buckets on demand.
  • S3 Cross-Region Replication (CRR) is used to copy objects across S3 buckets in different AWS Regions.
  • S3 Same-Region Replication (SRR) is used to copy objects across S3 buckets in the same AWS Region.
  • S3 Replication supports two-way (bidirectional) replication between two or more buckets in the same or different AWS Regions.
  • S3 Replication helps to
    • Replicate objects while retaining metadata (creation time, version IDs, ACLs)
    • Replicate objects into different storage classes (including S3 Glacier, Deep Archive)
    • Maintain object copies under different ownership (owner override option)
    • Keep objects stored over multiple AWS Regions
    • Replicate objects within 15 minutes (with S3 Replication Time Control)
    • Sync buckets, replicate existing objects, and retry previously failed replications (with Batch Replication)
    • Replicate objects and fail over to a bucket in another AWS Region (with Multi-Region Access Points)
  • S3 can replicate all or a subset of objects with specific key name prefixes or object tags
  • S3 encrypts all data in transit across AWS regions using SSL
  • Object replicas in the destination bucket are exact replicas of the objects in the source bucket with the same key names and the same metadata.
  • Objects may be replicated to a single destination bucket or multiple destination buckets.
  • Cross-Region Replication can be useful for the following scenarios:-
    • Compliance requirement to have data backed up across regions
    • Minimize latency to allow users across geography to access objects
    • Operational reasons compute clusters in two different regions that analyze the same set of objects
  • Same-Region Replication can be useful for the following scenarios:-
    • Aggregate logs into a single bucket
    • Configure live replication between production and test accounts
    • Abide by data sovereignty laws to store multiple copies

S3 Replication

S3 Replication Requirements

  • Source and destination buckets must be versioning-enabled
  • For CRR, the source and destination buckets must be in different AWS Regions.
  • The source bucket owner must have the source and destination AWS Regions enabled for their account. The destination bucket owner must have the destination Region enabled for their account.
  • S3 must have permission to replicate objects from that source bucket to the destination bucket on your behalf.
  • If the source bucket owner also owns the object, the bucket owner has full permission to replicate the object. If not, the object owner must grant the bucket owner READ and READ_ACP permissions with the object ACL.
  • Setting up cross-region replication in a cross-account scenario (where the source and destination buckets are owned by different AWS accounts), the destination bucket owner must grant the source bucket owner permissions to replicate objects with a bucket policy.
  • If the source bucket has S3 Object Lock enabled, the destination buckets must also have S3 Object Lock enabled. Additional permissions s3:GetObjectRetention and s3:GetObjectLegalHold are required on the IAM role.
  • Destination buckets cannot be configured as Requester Pays buckets.

S3 Batch Replication

  • S3 Batch Replication allows you to replicate existing objects to different buckets as an on-demand operation.
  • Live replication (CRR/SRR) only replicates new objects created after the replication rule is configured. Batch Replication addresses the gap for pre-existing objects.
  • Use cases for Batch Replication:
    • Backfill newly created buckets with existing objects from another bucket
    • Retry failed replications – replicate objects with a replication status of FAILED
    • Migrate data across accounts while preserving metadata and version IDs
    • Add new buckets to your data lake by replicating existing objects to new destinations
    • Replicate replicas – replicate objects that were created by another replication rule (not possible with live replication)
  • Batch Replication uses S3 Batch Operations jobs and provides a completion report when finished.
  • S3 RTC does not apply to Batch Replication; it is tracked via S3 Batch Operations.

S3 Replication Time Control (S3 RTC)

  • S3 Replication Time Control (RTC) provides a predictable replication time backed by a Service Level Agreement (SLA).
  • S3 RTC replicates 99.99% of new objects within 15 minutes after upload, with the majority replicated in seconds.
  • S3 RTC is backed by an SLA with a commitment to replicate 99.9% of objects within 15 minutes during any billing month.
  • S3 RTC, by default, includes S3 Replication Metrics and S3 Event Notifications.
  • S3 RTC is available in all AWS Regions including AWS GovCloud (US) Regions.
  • Delete marker replication does not adhere to the 15-minute SLA granted by S3 RTC.

S3 Two-Way Replication (Bidirectional)

  • S3 Replication supports two-way (bidirectional) replication between two or more buckets in the same or different AWS Regions.
  • Replica Modification Sync enables replicating metadata changes (ACLs, object tags, Object Lock settings) made to replica objects back to the source.
  • Replica Modification Sync must be enabled on both buckets for bidirectional metadata synchronization.
  • Two-way replication is essential for:
    • Building shared datasets across multiple AWS Regions
    • Keeping data synchronized during failover with S3 Multi-Region Access Points
    • Making applications highly available even during Regional traffic disruptions
  • To set up two-way replication, create replication rules in both directions between the source and destination buckets.

S3 Multi-Region Access Points with Replication

  • S3 Multi-Region Access Points provide a single global endpoint that routes S3 requests to the bucket closest to the requester.
  • Multi-Region Access Points include failover controls to shift S3 data request traffic between AWS Regions within minutes.
  • Supports active-active and active-passive configurations:
    • Active-Active – Traffic is distributed to multiple active Regions. If disruption occurs, traffic is automatically redirected.
    • Active-Passive – An active Region services all requests; a passive Region is on standby for failover.
  • Multi-Region Access Points require Cross-Region Replication (CRR) to be configured so that objects are available regardless of which bucket receives the request.
  • Two-way replication rules should be configured with Multi-Region Access Points to keep all objects and metadata in sync during failover.
  • Multi-Region Access Points accelerate performance by routing requests via AWS Global Accelerator, reducing latency by up to 60%.

S3 Replication Metrics and Notifications

  • S3 Replication provides detailed metrics and notifications to monitor replication status between buckets.
  • Replication metrics available in S3 console and Amazon CloudWatch:
    • Bytes Pending – total size of objects pending replication
    • Operations Pending – total number of operations pending replication
    • Replication Latency – maximum time to replicate
    • Operations Failed Replication – per-minute count of objects that failed to replicate
  • S3 Replication metrics are automatically enabled with S3 Replication Time Control (RTC).
  • S3 Event Notifications provide replication events:
    • s3:Replication:OperationFailedReplication
    • s3:Replication:OperationMissedThreshold
    • s3:Replication:OperationReplicatedAfterThreshold
    • s3:Replication:OperationNotTracked
  • Failure notifications do NOT require S3 RTC to be enabled.
  • Notifications can be sent to Amazon SNS, Amazon SQS, or AWS Lambda to diagnose configuration issues.

S3 Replication – Replicated & Not Replicated

  • Only new objects created after you add a replication configuration are replicated by live replication. Use S3 Batch Replication to replicate existing objects.
  • Objects encrypted using:
    • SSE-S3 (S3 managed keys) – replicated by default
    • SSE-KMS (AWS KMS keys) – replicated when the replication rule is configured with KMS key specification
    • DSSE-KMS (Dual-layer server-side encryption) – supported for replication
    • SSE-C (Customer-provided keys) – supported for replication (added October 2022)
  • S3 replicates only objects in the source bucket for which the bucket owner has permission to read objects and read ACLs.
  • Any object ACL updates are replicated, although there can be some delay before S3 can bring the two in sync.
  • S3 does NOT replicate objects in the source bucket for which the bucket owner does not have permission.
  • Updates to bucket-level S3 subresources are NOT replicated, allowing different bucket configurations on the source and destination buckets.
  • Only customer actions are replicated & actions performed by lifecycle configuration are NOT replicated.
  • Replication chaining is NOT allowed – objects that are replicas created by another replication rule are NOT replicated by live replication. Use Batch Replication to replicate replicas.
  • S3 does NOT replicate the delete marker by default. However, you can enable delete marker replication in non-tag-based rules to replicate delete markers.
    • Delete marker replication is NOT supported for tag-based replication rules.
    • Delete markers added by S3 Lifecycle expiration rules are NOT replicated even with delete marker replication enabled.
  • S3 does NOT replicate deletion by object version ID. This protects data from malicious deletions.

S3 Replication with Encryption

  • Starting January 5, 2023, Amazon S3 applies server-side encryption with S3 managed keys (SSE-S3) as the base level of encryption for every bucket.
  • SSE-S3 encrypted objects are replicated by default with no additional configuration.
  • SSE-KMS encrypted objects require specifying the destination KMS key in the replication rule. The IAM role must have kms:Decrypt permission on the source key and kms:Encrypt on the destination key.
  • DSSE-KMS (dual-layer encryption with KMS keys) is supported for replication.
  • SSE-C encrypted objects are supported for replication since October 2022. S3 automatically replicates newly uploaded SSE-C objects if eligible per replication configuration.
  • Note: Starting April 2026, SSE-C is disabled by default on all new S3 general purpose buckets. Applications requiring SSE-C must explicitly enable it via the PutBucketEncryption API.

S3 on Outposts Replication

  • S3 Replication on AWS Outposts enables automatic replication of S3 objects across different Outposts or between buckets on the same Outpost.
  • Available at no additional cost in all AWS Regions where AWS Outposts racks are available (since March 2023).
  • Helps meet local data residency requirements while providing data redundancy.
  • S3 on Outposts does NOT support replicating delete markers for tag-based rules.
  • Existing Object Replication is NOT supported for S3 on Outposts buckets.

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 company needs to replicate millions of existing objects from a source S3 bucket to a new destination bucket in another region. They also need to replicate any new objects going forward. What combination of features should they use?
    1. Enable Cross-Region Replication for new objects and use S3 Batch Replication for existing objects
    2. Use S3 Batch Replication only, as it handles both existing and new objects
    3. Enable Cross-Region Replication with Replication Time Control
    4. Use AWS DataSync to copy existing objects and CRR for new objects

    Answer: a – CRR handles new objects automatically, while Batch Replication is the managed way to replicate existing objects on demand.

  2. A company requires that all replicated objects arrive at the destination bucket within 15 minutes and needs an SLA guarantee. Which feature should they enable?
    1. S3 Cross-Region Replication with Transfer Acceleration
    2. S3 Replication Time Control (S3 RTC)
    3. S3 Same-Region Replication with CloudWatch alarms
    4. S3 Multi-Region Access Points

    Answer: b – S3 RTC replicates 99.99% of objects within 15 minutes and is backed by an SLA guaranteeing 99.9% within 15 minutes.

  3. A company wants to build a highly available multi-region application using S3. They need automatic failover of S3 data requests if a region becomes unavailable. What should they configure?
    1. CRR with CloudFront distribution
    2. S3 Multi-Region Access Points with two-way replication and failover controls
    3. SRR with Route 53 failover routing
    4. S3 Batch Operations with Lambda triggers

    Answer: b – S3 Multi-Region Access Points with failover controls and two-way CRR provide a single global endpoint with the ability to shift traffic between regions.

  4. Which of the following statements about S3 Replication are correct? (Choose 3)
    1. Live replication automatically replicates objects that existed before the replication rule was configured
    2. Versioning must be enabled on both source and destination buckets
    3. S3 Batch Replication can replicate replicas that were created by another replication rule
    4. Delete markers are replicated by default
    5. SSE-C encrypted objects are supported for replication

    Answer: b, c, e – Live replication does NOT replicate pre-existing objects (a is wrong). Delete markers are NOT replicated by default (d is wrong). Versioning is required, Batch Replication can replicate replicas, and SSE-C is supported since October 2022.

  5. A company uses two-way replication between two S3 buckets. They want metadata changes (ACLs and tags) made to replica objects to be synchronized back to the source. What must they enable?
    1. S3 Replication Time Control on both buckets
    2. Replica Modification Sync on both buckets
    3. S3 Batch Replication with metadata preservation
    4. S3 Object Lock on both buckets

    Answer: b – Replica Modification Sync must be enabled on both buckets to replicate metadata changes (ACLs, tags, Object Lock settings) bidirectionally.

  6. Which S3 Replication metrics can be monitored via Amazon CloudWatch? (Choose 3)
    1. Bytes Pending replication
    2. Operations Pending replication
    3. Number of buckets with replication enabled
    4. Operations Failed Replication
    5. Cost of data transfer for replication

    Answer: a, b, d – S3 Replication metrics include Bytes Pending, Operations Pending, Replication Latency, and Operations Failed Replication. Number of buckets and cost are not replication metrics.

References

Amazon S3 Event Notifications

~ Last updated on : ~ jayendrapatil

S3 Event Notifications

  • S3 notification feature enables notifications to be triggered when certain events happen in the bucket.
  • Notifications are enabled at the Bucket level.
  • Notifications can be configured to be filtered by the prefix and suffix of the key name of objects. However, filtering rules cannot be defined with overlapping prefixes, overlapping suffixes, or prefix and suffix overlapping.
  • S3 event notifications are designed to be delivered at least once. Typically, event notifications are delivered in seconds but can sometimes take a minute or longer.
  • Event notifications are not guaranteed to arrive in the same order that the events occurred. On rare occasions, S3’s retry mechanism might cause duplicate event notifications for the same object event.

Supported Event Types

  • S3 can publish the following events:
    • New Object Created events (s3:ObjectCreated:*)
      • Can be enabled for Put, Post, Copy, or CompleteMultipartUpload operations
      • You will not receive event notifications from failed operations
    • Object Removal events (s3:ObjectRemoved:*)
      • Can publish delete events for object deletion (s3:ObjectRemoved:Delete) or insertion of delete marker (s3:ObjectRemoved:DeleteMarkerCreated)
      • You will not receive event notifications from automatic deletes from lifecycle configurations or from failed operations.
    • Restore Object events (s3:ObjectRestore:*)
      • Restoration of objects archived to S3 Glacier Flexible Retrieval, S3 Glacier Deep Archive, S3 Intelligent-Tiering Archive Access tier, or Deep Archive Access tier
      • s3:ObjectRestore:Post – restoration initiated
      • s3:ObjectRestore:Completed – restoration completed
      • s3:ObjectRestore:Delete – temporary restored copy expired
    • S3 Lifecycle Expiration events (s3:LifecycleExpiration:*)
      • s3:LifecycleExpiration:Delete – object in unversioned bucket is deleted or object version permanently deleted by lifecycle
      • s3:LifecycleExpiration:DeleteMarkerCreated – lifecycle creates a delete marker when a current version of an object in a versioned bucket is deleted
    • S3 Lifecycle Transition events (s3:LifecycleTransition)
      • Object transitioned to another S3 storage class by a lifecycle configuration
    • S3 Intelligent-Tiering Automatic Archival events (s3:IntelligentTiering)
      • Object within S3 Intelligent-Tiering moved to the Archive Access tier or Deep Archive Access tier
    • Object Tagging events (s3:ObjectTagging:*)
      • s3:ObjectTagging:Put – tag added or updated on an object
      • s3:ObjectTagging:Delete – tag removed from an object
    • Object ACL PUT events (s3:ObjectAcl:Put)
      • ACL is set on an object or existing ACL is changed
      • An event is not generated when a request results in no change to an object’s ACL
    • Object Annotation events (s3:ObjectAnnotation:*) (New – 2025)
      • s3:ObjectAnnotation:Put – annotation created or updated via PutObjectAnnotation
      • s3:ObjectAnnotation:Delete – annotation deleted via DeleteObjectAnnotation
      • GetObjectAnnotation and ListObjectAnnotations do not send event notifications
    • Replication events (s3:Replication:*)
      • For replication configurations with S3 Replication metrics or S3 Replication Time Control (S3 RTC) enabled
      • s3:Replication:OperationFailedReplication – object failed to replicate
      • s3:Replication:OperationMissedThreshold – replication exceeded 15-minute S3 RTC threshold
      • s3:Replication:OperationReplicatedAfterThreshold – object replicated after 15-minute threshold
      • s3:Replication:OperationNotTracked – object no longer tracked by replication metrics
    • Reduced Redundancy Storage (RRS) object lost events (s3:ReducedRedundancyLostObject)
      • Can be used to reproduce/recreate the Object
      • Note: RRS is no longer recommended. Standard S3 is more cost-effective with higher durability (99.999999999% vs 99.99%). Consider migrating to S3 Standard or other storage classes.

Supported Event Destinations

  • S3 can publish events to the following destinations:
    • SNS topic
      • Only Standard SNS topics are supported (SNS FIFO is not allowed)
    • SQS queue
      • Only Standard SQS queues are supported (SQS FIFO queues are not supported as a direct S3 event notification destination)
      • To send S3 events to SQS FIFO queues, use Amazon EventBridge as an intermediary
    • AWS Lambda function
    • Amazon EventBridge
      • Unlike other destinations, enabling EventBridge sends all events (no need to select specific event types)
      • EventBridge rules can then route events to over 20 targets including Lambda, Kinesis, Step Functions, SQS, SNS, etc.
      • Supports advanced content-based filtering on event attributes (object size, time range, key prefix, etc.)
  • Only one destination type can be specified per event notification configuration (except EventBridge which receives all events when enabled).
  • For S3 to be able to publish events to the destination, the S3 principal should be granted the necessary permissions.

Amazon EventBridge Integration

  • Amazon EventBridge provides a more powerful event routing mechanism compared to traditional S3 event notifications.
  • When EventBridge is enabled on a bucket, all events are sent to EventBridge automatically – no need to specify individual event types.
  • EventBridge supports additional event types beyond SNS/SQS/Lambda:
    • Object Storage Class Changed
    • Object Access Tier Changed
    • Object Restore Expired
    • Object ACL Updated
    • Object Tags Added/Deleted
    • Object Annotation Created/Removed
  • Key Advantages over SNS/SQS/Lambda destinations:
    • Content-based filtering – filter by any attribute in the event (object size, key pattern, metadata)
    • Multiple targets – single rule can route to multiple targets
    • Over 20 supported targets including Lambda, Step Functions, SQS, SNS, Kinesis, ECS tasks, API destinations
    • Archive and replay – ability to archive events and replay them later
    • Schema discovery – auto-detect event schemas
    • No need for separate notification configurations per event type
  • EventBridge and traditional S3 event notifications (SNS/SQS/Lambda) can be configured simultaneously on the same bucket.

Event Notification Key Points

  • Notification configuration is stored in the notification subresource associated with the bucket.
  • If notifications write to the same bucket that triggers the notification, it could cause an execution loop. Use two buckets or configure the trigger with a specific prefix for incoming objects.
  • Event notifications do not alert for automatic deletes from lifecycle policies (use s3:LifecycleExpiration events instead).
  • Failed operations do not generate event notifications.

S3 Event Notifications

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 company uses S3 to store images. When an image is uploaded, a Lambda function must be triggered to generate thumbnails. What is the MOST efficient approach?
    1. Configure CloudWatch Events to monitor S3 uploads and trigger Lambda
    2. Configure S3 Event Notification with s3:ObjectCreated:* event to invoke the Lambda function
    3. Use a scheduled Lambda function to poll S3 for new objects
    4. Use S3 Batch Operations to process new images

    Answer: b – S3 Event Notifications can directly invoke Lambda functions when objects are created. This is the most efficient event-driven approach.

  2. A development team needs to send S3 object creation events to an SQS FIFO queue for ordered processing. Which approach should they use?
    1. Configure S3 Event Notification directly to the SQS FIFO queue
    2. Enable Amazon EventBridge on the bucket and create a rule to route events to the SQS FIFO queue
    3. Use SNS FIFO topic as intermediary between S3 and SQS FIFO
    4. Configure S3 Event Notification to Lambda, which forwards to SQS FIFO

    Answer: b – SQS FIFO queues are not supported as a direct S3 event notification destination. Amazon EventBridge can route S3 events to SQS FIFO queues. SNS FIFO is also not supported as S3 event destination.

  3. An application needs to be notified when objects are transitioned to Glacier by S3 Lifecycle rules, and separately when objects are deleted by lifecycle expiration. Which event types should be configured?
    1. s3:ObjectRemoved:Delete and s3:ObjectRestore:Post
    2. s3:LifecycleTransition and s3:LifecycleExpiration:Delete
    3. s3:ObjectCreated:Copy and s3:ObjectRemoved:*
    4. s3:IntelligentTiering and s3:ObjectRemoved:Delete

    Answer: b – s3:LifecycleTransition fires when lifecycle transitions objects to another storage class. s3:LifecycleExpiration:Delete fires when lifecycle deletes objects. s3:ObjectRemoved:Delete does NOT fire for lifecycle deletions.

  4. A company wants to filter S3 events by object size and route them to different Lambda functions – small objects to one function and large objects to another. Which approach supports this?
    1. Configure two S3 Event Notification rules with different prefix filters
    2. Enable Amazon EventBridge and create content-based filtering rules
    3. Use SNS with message filtering policies
    4. Configure S3 Event Notification to SQS and use Lambda to filter

    Answer: b – Amazon EventBridge supports content-based filtering on any event attribute including object size, time range, and metadata fields. S3 Event Notifications natively only support prefix and suffix filtering on key names.

  5. Which of the following are valid S3 event notification destinations? (Choose 3)
    1. Amazon SNS FIFO topic
    2. Amazon SQS Standard queue
    3. AWS Lambda function
    4. Amazon EventBridge
    5. Amazon SQS FIFO queue

    Answer: b, c, d – S3 event notifications support SNS Standard topics, SQS Standard queues, Lambda functions, and Amazon EventBridge. SNS FIFO and SQS FIFO are not supported as direct S3 event notification destinations.

References

Amazon S3 Static Website Hosting

~ Last updated on : ~ jayendrapatil

S3 Static Website Hosting

📌 AWS Recommendation (October 2024): AWS now recommends using AWS Amplify Hosting to host static website content stored on S3. Amplify Hosting is a fully managed service that deploys your websites on a globally available CDN powered by Amazon CloudFront, with built-in HTTPS, custom domains, redirects, and custom headers. See AWS Amplify Hosting section below.

  • Amazon S3 can be used for Static Website hosting with Client-side scripts.
  • S3 does not support server-side scripting.
  • S3, in conjunction with Route 53, supports hosting a website at the root domain which can point to the S3 website endpoint
  • S3 website endpoints do not support HTTPS or access points. Use Amazon CloudFront to serve HTTPS traffic.
  • For S3 website hosting the content should be made publicly readable which can be provided using a bucket policy.
  • Since April 2023, all new S3 buckets have Block Public Access enabled and ACLs disabled by default. To use S3 static website hosting, Block Public Access must be explicitly disabled and a bucket policy must be configured for public read access.
  • Users can configure the index, and error document as well as configure the conditional routing of an object name
  • S3 supports up to 50 routing rules per website configuration for conditional redirects.
  • Requester Pays buckets do not allow access through the website endpoint. Any request to such a bucket will receive a 403 – Access Denied response.
  • If the S3 bucket is encrypted using SSE-KMS, the website endpoint cannot serve the content. Use CloudFront with Origin Access Control (OAC) instead.
  • S3 website endpoint domains are registered in the Public Suffix List (PSL). If setting sensitive cookies, use the __Host- prefix for CSRF protection.

S3 Website Endpoints

  • S3 provides two types of endpoints:
    • REST API endpoint (s3.amazonaws.com) – Supports HTTPS, access points, OAC
    • Website endpoint (s3-website-region.amazonaws.com or s3-website.region.amazonaws.com) – Supports only HTTP, no access points, no OAC
  • Website endpoint formats:
    • http://bucket-name.s3-website-Region.amazonaws.com (dash format)
    • http://bucket-name.s3-website.Region.amazonaws.com (dot format)
  • Website endpoints return HTML error documents for 4xx errors, while REST API endpoints return XML error responses.
  • Website endpoints support index documents and redirects; REST API endpoints do not.

S3 Static Website with CloudFront

  • CloudFront is the recommended approach to add HTTPS support, caching, and global distribution to S3-hosted websites.
  • Two approaches to use CloudFront with S3:
    • S3 REST API endpoint as origin with OAC (Recommended) – Keeps the bucket private; CloudFront uses Origin Access Control to authenticate requests to S3.
    • S3 website endpoint as custom origin – Bucket must be publicly accessible; does not support OAC/OAI. Can restrict access using a custom Referer header.
  • Origin Access Control (OAC) is the current best practice for securing S3 origins with CloudFront (replaces the legacy OAI).
    • OAI creation was deprecated in 2024.
    • As of March 2026, new CloudFront distributions can only use OAC.
    • OAC supports SSE-KMS encrypted objects, SigV4, and all AWS regions.
    • OAC requires S3 Object Ownership set to “Bucket owner enforced” (default for new buckets).
  • CloudFront Functions can handle URL rewriting (e.g., appending index.html to directory paths) when using the REST API endpoint with OAC, providing website-endpoint-like behavior while keeping the bucket private.
  • AWS Shield Standard is automatically included with every CloudFront distribution at no extra cost for DDoS protection.

AWS Amplify Hosting (Recommended Alternative)

  • AWS Amplify Hosting is a fully managed service for hosting static websites, officially recommended by AWS as of October 2024 for static content stored on S3.
  • Key benefits over S3 website hosting:
    • Built-in HTTPS with free SSL/TLS certificates
    • Global CDN powered by Amazon CloudFront
    • Custom domain configuration with automatic DNS setup
    • Custom headers and redirects without additional services
    • Atomic deployments and instant cache invalidation
    • No need to disable Block Public Access on S3 bucket
  • Amplify Hosting can deploy directly from an S3 general purpose bucket by selecting the location of objects within the bucket.
  • Does not support cross-account S3 bucket access.
  • Simplifies the setup compared to manually configuring S3 + CloudFront + Route 53 + ACM.

Security Best Practices

  • Prefer CloudFront + OAC or Amplify Hosting over making S3 buckets publicly accessible.
  • Keep Block Public Access enabled whenever possible; use CloudFront OAC to grant access to the distribution only.
  • If public access is required (S3 website endpoint), use a bucket policy (not ACLs) to grant read access, as ACLs are disabled by default on new buckets.
  • Enable access logging to track website requests.
  • Use CloudFront with WAF for additional security controls like geo-restriction, rate limiting, and IP filtering.

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. Company ABCD is currently hosting their corporate site in an Amazon S3 bucket with Static Website Hosting enabled. Currently, when visitors go to http://www.companyabcd.com the index.html page is returned. Company C now would like a new page welcome.html to be returned when a visitor enters http://www.companyabcd.com in the browser. Which of the following steps will allow Company ABCD to meet this requirement? Choose 2 answers.
    1. Upload an html page named welcome.html to their S3 bucket
    2. Create a welcome subfolder in their S3 bucket
    3. Set the Index Document property to welcome.html
    4. Move the index.html page to a welcome subfolder
    5. Set the Error Document property to welcome.html
  2. A company wants to host a static website on AWS with HTTPS support using a custom domain. The website files are stored in an S3 bucket. Which combination of services provides the MOST secure and recommended architecture? Choose 2 answers.
    1. Enable S3 static website hosting and use the website endpoint directly
    2. Use CloudFront with Origin Access Control (OAC) and the S3 REST API endpoint as origin
    3. Use CloudFront with Origin Access Identity (OAI)
    4. Keep S3 Block Public Access enabled on the bucket
    5. Disable server-side encryption on the bucket
  3. A developer needs to host a static single-page application on AWS. The requirements include HTTPS, a custom domain, atomic deployments, and minimal operational overhead. Which approach requires the LEAST configuration effort?
    1. S3 static website hosting with CloudFront and ACM certificate
    2. AWS Amplify Hosting with S3 as the source
    3. S3 static website hosting with Route 53 alias record
    4. EC2 instance with Nginx serving static files
  4. An organization hosts a static website on S3 using the website endpoint. They want to ensure only CloudFront can access the S3 content while keeping the bucket private. However, they need S3 website features like index documents for subdirectories. What is the recommended solution?
    1. Use OAC with the S3 website endpoint
    2. Use CloudFront with the S3 REST API endpoint, OAC, and a CloudFront Function for URL rewriting
    3. Use OAI with the S3 website endpoint
    4. Make the bucket public and use a custom Referer header
  5. A company created a new S3 bucket and enabled static website hosting. However, users are receiving 403 Forbidden errors when accessing the website. What is the MOST likely cause? (Choose 2)
    1. S3 Block Public Access is still enabled on the bucket (default for new buckets since April 2023)
    2. The bucket does not have versioning enabled
    3. No bucket policy has been configured to allow public read access
    4. The index document has not been uploaded
    5. The bucket is using SSE-S3 encryption

References

AWS S3 Storage Classes

S3 Storage Classes Performance
~ Last updated on : ~ jayendrapatil ~ 19 Comments

AWS S3 Storage Classes

  • AWS S3 offers a range of S3 Storage Classes to match the use case scenario and performance access requirements.
  • S3 storage classes are designed to sustain the concurrent loss of data in one or two facilities.
  • S3 storage classes allow lifecycle management for automatic transition of objects for cost savings.
  • All S3 storage classes provide the same durability, first-byte latency, and support SSL encryption of data in transit, and data encryption at rest.
  • S3 also regularly verifies the integrity of the data using checksums and provides the auto-healing capability.
  • S3 currently offers the following storage classes: S3 Standard, S3 Express One Zone, S3 Intelligent-Tiering, S3 Standard-IA, S3 One Zone-IA, S3 Glacier Instant Retrieval, S3 Glacier Flexible Retrieval, and S3 Glacier Deep Archive.

S3 Storage Classes Comparison

S3 Storage Classes Performance

S3 Standard

  • STANDARD is the default storage class, if none specified during upload
  • Low latency and high throughput performance
  • Designed for 99.999999999% i.e. 11 9’s Durability of objects across AZs
  • Designed for 99.99% availability over a given year
  • Resilient against events that impact an entire Availability Zone and is designed to sustain the loss of data in two facilities
  • Stores data redundantly across a minimum of 3 Availability Zones
  • Ideal for performance-sensitive use cases and frequently accessed data
  • S3 Standard is appropriate for a wide variety of use cases, including cloud applications, dynamic websites, content distribution, mobile and gaming applications, and big data analytics.
  • No minimum storage duration and no minimum billable object size

S3 Express One Zone

  • S3 Express One Zone is a high-performance, single-Availability Zone storage class purpose-built to deliver consistent single-digit millisecond data access for latency-sensitive applications.
  • Delivers data access speed up to 10x faster and request costs up to 50% lower than S3 Standard.
  • Supports up to 2 million GET transactions per second (TPS) and up to 200,000 PUT TPS per directory bucket.
  • Stores data in a single Availability Zone that you choose, enabling co-location with compute resources (EC2, EKS, ECS) for lowest latency.
  • Uses directory buckets (different from general purpose buckets).
  • Designed for 99.999999999% i.e. 11 9’s Durability within a single AZ
  • Designed for 99.95% availability
  • No minimum storage duration and no minimum billable object size
  • Data is not resilient to the physical loss of the Availability Zone.
  • Ideal for ML training, interactive analytics, media content creation, high-performance computing (HPC), and financial modeling.
  • Supports appending data to existing objects without downloading and re-uploading.
  • Pricing Update (April 2025): AWS reduced storage prices by 31%, PUT request prices by 55%, GET request prices by 85%, and data upload/retrieval per-byte charges by 60%.

S3 Intelligent Tiering (S3 Intelligent-Tiering)

  • S3 Intelligent Tiering storage class is designed to optimize storage costs by automatically moving data to the most cost-effective storage access tier, without performance impact or operational overhead.
  • S3 Intelligent-Tiering is the only cloud storage class that delivers automatic cost savings by moving data on a granular object level between access tiers when access patterns change.
  • S3 Intelligent-Tiering automatically stores objects in three automatic low-latency access tiers:
    • Frequent Access tier (automatic) – Default tier for newly uploaded objects. Provides low latency and high throughput.
    • Infrequent Access tier (automatic) – Objects not accessed for 30 consecutive days are moved here.
    • Archive Instant Access tier (automatic) – Objects not accessed for 90 consecutive days are moved here. Provides millisecond access and high throughput, with up to 68% lower cost vs. Frequent Access.
  • Additionally offers two optional asynchronous archive access tiers (must be activated):
    • Archive Access tier (optional) – For data that can be accessed asynchronously. Objects not accessed for a minimum of 90 consecutive days (configurable up to 730 days). Retrieval: 3-5 hours (standard).
    • Deep Archive Access tier (optional) – Objects not accessed for a minimum of 180 consecutive days (configurable up to 730 days). Retrieval: within 12 hours.
  • No retrieval fees when using the S3 Intelligent-Tiering storage class.
  • If an object in the Infrequent Access tier or Archive Instant Access tier is accessed, it is automatically moved back to the Frequent Access tier.
  • No additional fees apply when objects are moved between access tiers.
  • For a small monthly monitoring and automation fee per object, S3 monitors access patterns and moves objects automatically.
  • No minimum storage duration charge.
  • Objects smaller than 128 KB are not monitored and not eligible for auto-tiering; they are always stored in the Frequent Access tier. No monitoring and automation charge applies to objects smaller than 128 KB.
  • Designed for 99.999999999% i.e. 11 9’s Durability of objects across AZs
  • Designed for 99.9% availability over a given year
  • Ideal when you want to optimize storage costs for data with unknown or changing access patterns.

S3 Standard-Infrequent Access (S3 Standard-IA)

  • S3 Standard-Infrequent Access storage class is optimized for long-lived and less frequently accessed data. for e.g. for backups and older data where access is limited, but the use case still demands high performance
  • Ideal for use for the primary or only copy of data that can’t be recreated.
  • Data stored redundantly across multiple geographically separated AZs and are resilient to the loss of an Availability Zone.
  • Offers greater availability and resiliency than the ONEZONE_IA class.
  • Objects are available for real-time access.
  • Suitable for objects larger than 128 KB (smaller objects are charged for 128 KB only) kept for at least 30 days (charged for minimum 30 days)
  • Same low latency and high throughput performance of Standard
  • Designed for 99.999999999% i.e. 11 9’s Durability of objects across AZs
  • Designed for 99.9% availability over a given year
  • S3 charges a per-GB retrieval fee for these objects, so they are most suitable for infrequently accessed data.

S3 One Zone-Infrequent Access (S3 One Zone-IA)

  • S3 One Zone-Infrequent Access storage class is designed for long-lived and infrequently accessed data, but available for millisecond access (similar to the STANDARD and STANDARD_IA storage class).
  • Ideal when the data can be recreated if the AZ fails, and for object replicas when setting cross-region replication (CRR).
  • Objects are available for real-time access.
  • Suitable for objects greater than 128 KB (smaller objects are charged for 128 KB only) kept for at least 30 days (charged for a minimum of 30 days)
  • Stores the object data in only one AZ, which makes it less expensive than Standard-Infrequent Access
  • Data is not resilient to the physical loss of the AZ resulting from disasters, such as earthquakes and floods.
  • One Zone-Infrequent Access storage class is as durable as Standard-Infrequent Access, but it is less available and less resilient.
  • Designed for 99.999999999% i.e. 11 9’s Durability of objects in a single AZ
  • Designed for 99.5% availability over a given year
  • S3 charges a retrieval fee for these objects, so they are most suitable for infrequently accessed data.
  • Can also be used in directory buckets within AWS Local Zones for data residency and isolation use cases.

Reduced Redundancy Storage – RRS (Not Recommended)

⚠️ NOT RECOMMENDED – EFFECTIVELY DEPRECATED

AWS recommends NOT using Reduced Redundancy Storage (RRS). The S3 Standard storage class is more cost-effective. RRS no longer participates in AWS pricing discounts, making it more expensive than S3 Standard while providing lower durability (99.99% vs 99.999999999%).

Recommendation: Use S3 Standard for all use cases previously served by RRS. For infrequently accessed reproducible data, use S3 One Zone-IA instead.

  • NOTE – AWS recommends not to use this storage class. The STANDARD storage class is more cost-effective. RRS is effectively deprecated – it costs more than S3 Standard and offers lower durability.
  • Reduced Redundancy Storage (RRS) storage class is designed for non-critical, reproducible data stored at lower levels of redundancy than the STANDARD storage class
  • Designed for durability of 99.99% of objects (average annual expected loss of 0.01% of objects)
  • Designed for 99.99% availability over a given year
  • RRS does not replicate objects as many times as S3 standard storage and is designed to sustain the loss of data in a single facility.
  • If an RRS object is lost, S3 returns a 405 error on requests made to that object
  • S3 can send an event notification, configured on the bucket, to alert a user or start a workflow when it detects that an RRS object is lost

S3 Glacier Instant Retrieval

  • Use for archiving data that is rarely accessed (approximately once per quarter) and requires milliseconds retrieval.
  • Delivers the same low latency and high throughput performance as S3 Standard and S3 Standard-IA.
  • Provides up to 68% lower storage cost compared to S3 Standard-IA for data accessed once per quarter.
  • Storage class has a minimum storage duration period of 90 days
  • Minimum billable object size of 128 KB
  • Per-GB retrieval fees apply.
  • Designed for 99.999999999% i.e. 11 9’s Durability of objects across AZs
  • Designed for 99.9% availability
  • Ideal for medical images, news media assets, genomic sequences, satellite images, and user-generated content archives.

S3 Glacier Flexible Retrieval (formerly S3 Glacier)

  • S3 Glacier Flexible Retrieval storage class is suitable for low-cost data archiving where data access is infrequent and retrieval time of minutes to hours is acceptable.
  • Storage class has a minimum storage duration period of 90 days
  • Requires 40 KB of additional metadata per archived object (32 KB at Glacier rate + 8 KB at Standard rate).
  • Provides configurable retrieval times, from minutes to hours
    • Expedited retrieval: 1-5 mins
    • Standard retrieval: 3-5 hours
    • Bulk retrieval: 5-12 hours (free)
  • Objects in this storage class are managed through S3 (not through the separate Glacier service)
  • For accessing Glacier Flexible Retrieval objects,
    • the object must be restored which can take anywhere between minutes to hours
    • objects are only available for the time period (the number of days) specified during the restoration request
    • object’s storage class remains GLACIER
    • charges are levied for both the archive (GLACIER rate) and the copy restored temporarily
  • Vault Lock feature enforces compliance via a lockable policy.
  • Designed for 99.999999999% i.e. 11 9’s Durability of objects across AZs
  • Designed for 99.99% availability (after objects are restored)

S3 Glacier Deep Archive

  • Glacier Deep Archive storage class provides the lowest-cost data archiving where data access is infrequent and retrieval time of hours is acceptable.
  • Has a minimum storage duration period of 180 days.
  • Requires 40 KB of additional metadata per archived object (32 KB at Deep Archive rate + 8 KB at Standard rate).
  • Retrieval options:
    • Standard retrieval: within 12 hours
    • Bulk retrieval: within 48 hours
  • Supports long-term retention and digital preservation for data that may be accessed once or twice a year
  • Designed for 99.999999999% i.e. 11 9’s Durability of objects across AZs
  • Designed for 99.99% availability (after objects are restored)
  • Ideal alternative to magnetic tape libraries
  • Suitable for regulatory compliance archives, healthcare and life sciences data, financial services records, and media asset archiving.

S3 on Outposts

  • S3 on Outposts provides a storage class called S3 Outposts (OUTPOSTS) for on-premises object storage.
  • Allows creating S3 buckets on AWS Outposts resources for local data access, local data processing, and data residency requirements.
  • Uses the same S3 API operations and features as in AWS Regions, including access policies, encryption, and tagging.
  • Objects stored in S3 Outposts are always encrypted using SSE-S3 (can also use SSE-C).
  • Does not support SSE-KMS.
  • Capacity options: 26 TB, 48 TB, 96 TB, 240 TB, or 380 TB per Outpost.

S3 Analytics – S3 Storage Classes Analysis

  • S3 Analytics – Storage Class Analysis helps analyze storage access patterns to decide when to transition the right data to the right storage class.
  • S3 Analytics feature observes data access patterns to help determine when to transition less frequently accessed STANDARD storage to the STANDARD_IA (IA, for infrequent access) storage class.
  • Storage Class Analysis can be configured to analyze all the objects in a bucket or filters to group objects.
  • Results can help inform S3 Lifecycle policies and S3 Intelligent-Tiering configurations.

S3 Storage Classes – Key Differences Summary

Storage Class Designed For Availability AZs Min Duration Retrieval Fee
S3 Standard Frequently accessed data 99.99% ≥ 3 None None
S3 Express One Zone Latency-sensitive (single-digit ms) 99.95% 1 None None
S3 Intelligent-Tiering Unknown/changing access patterns 99.9% ≥ 3 None None
S3 Standard-IA Infrequent access, millisecond retrieval 99.9% ≥ 3 30 days Per-GB
S3 One Zone-IA Recreatable, infrequent access 99.5% 1 30 days Per-GB
S3 Glacier Instant Retrieval Archive, once/quarter, ms retrieval 99.9% ≥ 3 90 days Per-GB
S3 Glacier Flexible Retrieval Archive, once/year, min-to-hour retrieval 99.99%* ≥ 3 90 days Per-GB
S3 Glacier Deep Archive Long-term archive, hours retrieval 99.99%* ≥ 3 180 days Per-GB

* Availability is 99.99% after objects are restored.

All storage classes provide 99.999999999% (11 nines) durability.

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 RRS stand for when talking about S3?
    1. Redundancy Removal System
    2. Relational Rights Storage
    3. Regional Rights Standard
    4. Reduced Redundancy Storage
  2. What is the durability of S3 RRS?
    1. 99.99%
    2. 99.95%
    3. 99.995%
    4. 99.999999999%
  3. What is the Reduced Redundancy option in Amazon S3?
    1. Less redundancy for a lower cost
    2. It doesn’t exist in Amazon S3, but in Amazon EBS.
    3. It allows you to destroy any copy of your files outside a specific jurisdiction.
    4. It doesn’t exist at all

    Note: While the answer above was correct historically, RRS is now more expensive than S3 Standard and AWS recommends against using it.

  4. An application is generating a log file every 5 minutes. The log file is not critical but may be required only for verification in case of some major issue. The file should be accessible over the internet whenever required. Which of the below mentioned options is a best possible storage solution for it?
    1. AWS S3
    2. AWS Glacier
    3. AWS RDS
    4. AWS S3 RRS (Reduced Redundancy Storage (RRS) is an Amazon S3 storage option that enables customers to store noncritical, reproducible data at lower levels of redundancy than Amazon S3’s standard storage. RRS is designed to sustain the loss of data in a single facility.)

    Note: This question is outdated. Today the best answer would be S3 Standard or S3 One Zone-IA, as RRS is more expensive than S3 Standard and not recommended.

  5. A user has moved an object to Glacier using the life cycle rules. The user requests to restore the archive after 6 months. When the restore request is completed the user accesses that archive. Which of the below mentioned statements is not true in this condition?
    1. The archive will be available as an object for the duration specified by the user during the restoration request
    2. The restored object’s storage class will be RRS (After the object is restored the storage class still remains GLACIER. Read more)
    3. The user can modify the restoration period only by issuing a new restore request with the updated period
    4. The user needs to pay storage for both RRS (restored) and Glacier (Archive) Rates
  6. Your department creates regular analytics reports from your company’s log files. All log data is collected in Amazon S3 and processed by daily Amazon Elastic Map Reduce (EMR) jobs that generate daily PDF reports and aggregated tables in CSV format for an Amazon Redshift data warehouse. Your CFO requests that you optimize the cost structure for this system. Which of the following alternatives will lower costs without compromising average performance of the system or data integrity for the raw data? [PROFESSIONAL]
    1. Use reduced redundancy storage (RRS) for PDF and CSV data in Amazon S3. Add Spot instances to Amazon EMR jobs. Use Reserved Instances for Amazon Redshift. (Spot instances impacts performance)
    2. Use reduced redundancy storage (RRS) for all data in S3. Use a combination of Spot instances and Reserved Instances for Amazon EMR jobs. Use Reserved instances for Amazon Redshift (Combination of the Spot and reserved with guarantee performance and help reduce cost. Also, RRS would reduce cost and guarantee data integrity, which is different from data durability )
    3. Use reduced redundancy storage (RRS) for all data in Amazon S3. Add Spot Instances to Amazon EMR jobs. Use Reserved Instances for Amazon Redshift (Spot instances impacts performance)
    4. Use reduced redundancy storage (RRS) for PDF and CSV data in S3. Add Spot Instances to EMR jobs. Use Spot Instances for Amazon Redshift. (Spot instances impacts performance)

    Note: This question is outdated. RRS is now more expensive than S3 Standard. Modern approach would use S3 Standard or S3 Intelligent-Tiering.

  7. Which of the below mentioned options can be a good use case for storing content in AWS RRS?
    1. Storing mission critical data Files
    2. Storing infrequently used log files
    3. Storing a video file which is not reproducible
    4. Storing image thumbnails

    Note: RRS is no longer recommended. For reproducible data like thumbnails, use S3 Standard or S3 One Zone-IA.

  8. A newspaper organization has an on-premises application which allows the public to search its back catalogue and retrieve individual newspaper pages via a website written in Java. They have scanned the old newspapers into JPEGs (approx. 17TB) and used Optical Character Recognition (OCR) to populate a commercial search product. The hosting platform and software is now end of life and the organization wants to migrate its archive to AWS and produce a cost efficient architecture and still be designed for availability and durability. Which is the most appropriate? [PROFESSIONAL]
    1. Use S3 with reduced redundancy to store and serve the scanned files, install the commercial search application on EC2 Instances and configure with auto-scaling and an Elastic Load Balancer. (RRS impacts durability and commercial search would add to cost)
    2. Model the environment using CloudFormation. Use an EC2 instance running Apache webserver and an open source search application, stripe multiple standard EBS volumes together to store the JPEGs and search index. (Using EBS is not cost effective for storing files)
    3. Use S3 with standard redundancy to store and serve the scanned files, use CloudSearch for query processing, and use Elastic Beanstalk to host the website across multiple availability zones. (Standard S3 and Elastic Beanstalk provides availability and durability, Standard S3 and CloudSearch provides cost effective storage and search)
    4. Use a single-AZ RDS MySQL instance to store the search index and the JPEG images use an EC2 instance to serve the website and translate user queries into SQL. (RDS is not ideal and cost effective to store files, Single AZ impacts availability)
    5. Use a CloudFront download distribution to serve the JPEGs to the end users and Install the current commercial search product, along with a Java Container for the website on EC2 instances and use Route53 with DNS round-robin. (CloudFront needs a source and using commercial search product is not cost effective)
  9. A research scientist is planning for the one-time launch of an Elastic MapReduce cluster and is encouraged by her manager to minimize the costs. The cluster is designed to ingest 200TB of genomics data with a total of 100 Amazon EC2 instances and is expected to run for around four hours. The resulting data set must be stored temporarily until archived into an Amazon RDS Oracle instance. Which option will help save the most money while meeting requirements? [PROFESSIONAL]
    1. Store ingest and output files in Amazon S3. Deploy on-demand for the master and core nodes and spot for the task nodes.
    2. Optimize by deploying a combination of on-demand, RI and spot-pricing models for the master, core and task nodes. Store ingest and output files in Amazon S3 with a lifecycle policy that archives them to Amazon Glacier. (Master and Core must be RI or On Demand. Cannot be Spot)
    3. Store the ingest files in Amazon S3 RRS and store the output files in S3. Deploy Reserved Instances for the master and core nodes and on-demand for the task nodes. (Need better durability for ingest file. Spot instances can be used for task nodes for cost saving.)
    4. Deploy on-demand master, core and task nodes and store ingest and output files in Amazon S3 RRS (Input must be in S3 standard)
  10. A company stores rarely accessed medical images in S3. The images are accessed approximately once per quarter but must be available with millisecond latency when needed. Which storage class is most cost-effective?
    1. S3 Standard
    2. S3 Standard-IA
    3. S3 Glacier Instant Retrieval (S3 Glacier Instant Retrieval is designed for rarely accessed data (once per quarter) requiring millisecond access, with up to 68% lower cost than S3 Standard-IA.)
    4. S3 Glacier Flexible Retrieval
  11. A data lake has objects with unpredictable access patterns. Some objects are accessed frequently for a few weeks, then not again for months. Which storage class provides the best automatic cost optimization without operational overhead?
    1. S3 Standard with lifecycle policies to S3 Standard-IA
    2. S3 Intelligent-Tiering (S3 Intelligent-Tiering automatically moves objects between Frequent Access, Infrequent Access, and Archive Instant Access tiers based on access patterns, with no retrieval fees and no operational overhead.)
    3. S3 One Zone-IA
    4. S3 Glacier Flexible Retrieval
  12. An AI/ML team needs to store training datasets that are accessed thousands of times per second during model training. The datasets are in the same Availability Zone as their compute cluster. Which storage class provides the best performance?
    1. S3 Standard
    2. S3 One Zone-IA
    3. S3 Express One Zone (S3 Express One Zone provides single-digit millisecond data access, up to 10x faster than S3 Standard, and can be co-located in the same AZ as compute resources. It supports up to 2M GET TPS per directory bucket.)
    4. S3 Standard with Transfer Acceleration
  13. How many automatic access tiers does S3 Intelligent-Tiering provide? (Select TWO correct statements)
    1. Two automatic tiers: Frequent Access and Infrequent Access
    2. Three automatic tiers: Frequent Access, Infrequent Access, and Archive Instant Access
    3. Two optional archive tiers must be activated: Archive Access and Deep Archive Access
    4. Objects smaller than 128 KB are automatically tiered between all tiers
    5. Archive Instant Access tier requires manual activation
  14. A company needs to archive compliance data that must be retained for 7 years and is almost never accessed. When accessed, a retrieval time of 12 hours is acceptable. Which is the most cost-effective storage class?
    1. S3 Glacier Instant Retrieval
    2. S3 Glacier Flexible Retrieval
    3. S3 Glacier Deep Archive (S3 Glacier Deep Archive provides the lowest-cost storage for data that is rarely accessed and where a retrieval time of 12 hours (standard) or 48 hours (bulk) is acceptable. It has a 180-day minimum storage duration.)
    4. S3 Standard-IA

AWS S3 Subresources

~ Last updated on : ~ jayendrapatil ~ 9 Comments

AWS S3 Subresources

  • S3 Subresources provides support to store, and manage the bucket configuration information.
  • S3 subresources only exist in the context of a specific bucket or object
  • S3 subresources are associated with buckets and objects.
  • S3 Subresources are subordinates to objects; i.e. they do not exist on their own, they are always associated with some other entity, such as an object or a bucket.
  • S3 supports various options to configure a bucket for e.g., the bucket can be configured for website hosting, configuration added to manage the lifecycle of objects in the bucket, and to log all access to the bucket.

S3 Object Lifecycle

Refer blog post @ S3 Object Lifecycle Management

Static Website Hosting

  • S3 can be used for Static Website hosting with Client-side scripts.
  • S3 does not support server-side scripting.
  • S3, in conjunction with Route 53, supports hosting a website at the root domain which can point to the S3 website endpoint
  • S3 website endpoints do not support HTTPS or access points
  • For S3 website hosting the content should be made publicly readable which can be provided using a bucket policy or an ACL on an object.
  • Users can configure the index, and error document as well as configure the conditional routing of an object name
  • Bucket policy applies only to objects owned by the bucket owner. If the bucket contains objects not owned by the bucket owner, then public READ permission on those objects should be granted using the object ACL.
  • Requester Pays buckets or DevPay buckets do not allow access through the website endpoint. Any request to such a bucket will receive a 403 -Access Denied response

S3 Versioning

Refer blog post @ S3 Object Versioning

Policy & Access Control List (ACL)

Refer blog post @ S3 Permissions

CORS (Cross Origin Resource Sharing)

  • All browsers implement the Same-Origin policy, for security reasons, where the web page from a domain can only request resources from the same domain.
  • CORS allows client web applications loaded in one domain access to the restricted resources to be requested from another domain.
  • With CORS support, S3 allows cross-origin access to S3 resources
  • CORS configuration rules identify the origins allowed to access the bucket, the operations (HTTP methods) that would be supported for each origin, and other operation-specific information.

S3 Access Logs

  • S3 Access Logs enable tracking access requests to an S3 bucket.
  • S3 Access logs are disabled by default.
  • Each access log record provides details about a single access request, such as the requester, bucket name, request time, request action, response status, and error code, etc.
  • Access log information can be useful in security and access audits and also help learn about the customer base and understand the S3 bill.
  • S3 periodically collects access log records, consolidates the records in log files, and then uploads log files to a target bucket as log objects.
  • Logging can be enabled on multiple source buckets with the same target bucket which will have access logs for all those source buckets, but each log object will report access log records for a specific source bucket.
  • Source and target buckets should be in the same region.
  • Source and target buckets should be different to avoid an infinite loop of logs issue.
  • Target bucket can be encrypted using SSS-S3 default encryption. However, Default encryption with AWS KMS keys (SSE-KMS) is not supported.
  • S3 Object Lock cannot be enabled on the target bucket.
  •  S3 uses a special log delivery account to write server access logs.
    • AWS recommends updating the bucket policy on the target bucket to grant access to the logging service principal (logging.s3.amazonaws.com) for access log delivery.
    • Access for access log delivery can also be granted to the S3 log delivery group through the bucket ACL. Granting access to the S3 log delivery group using your bucket ACL is not recommended.
  • Access log records are delivered on a best-effort basis. The completeness and timeliness of server logging is not guaranteed i.e. log record for a particular request might be delivered long after the request was actually processed, or it might not be delivered at all.
  • S3 Access Logs can be analyzed using data analysis tools or Athena.

Tagging

  • S3 provides the tagging subresource to store and manage tags on a bucket
  • Cost allocation tags can be added to the bucket to categorize and track AWS costs.
  • AWS can generate a cost allocation report with usage and costs aggregated by the tags applied to the buckets.

Location

  • AWS region needs to be specified during bucket creation and it cannot be changed.
  • S3 stores this information in the location subresource and provides an API for retrieving this information

Event Notifications

  • S3 notification feature enables notifications to be triggered when certain events happen in the bucket.
  • Notifications are enabled at the Bucket level
  • Notifications can be configured to be filtered by the prefix and suffix of the key name of objects. However, filtering rules cannot be defined with overlapping prefixes, overlapping suffixes, or prefix and suffix overlapping
  • S3 can publish the following events
    • New Object created events
      • Can be enabled for PUT, POST, or COPY operations
      • You will not receive event notifications from failed operations
    • Object Removal events
      • Can public delete events for object deletion, version object deletion or insertion of delete marker
      • You will not receive event notifications from automatic deletes from lifecycle policies or from failed operations.
    • Restore object events
      • restoration of objects archived to the S3 Glacier storage classes
    • Reduced Redundancy Storage (RRS) object lost events
      • Can be used to reproduce/recreate the Object
    • Replication events
      • for replication configurations that have S3 replication metrics or S3 Replication Time Control (S3 RTC) enabled
  • S3 can publish events to the following destination
  • For S3 to be able to publish events to the destination, the S3 principal should be granted the necessary permissions
  • S3 event notifications are designed to be delivered at least once. Typically, event notifications are delivered in seconds but can sometimes take a minute or longer.

Cross-Region Replication & Same-Region Replication

  • S3 Replication enables automatic, asynchronous copying of objects across S3 buckets in the same or different AWS regions.
  • S3 Cross-Region Replication – CRR is used to copy objects across S3 buckets in different AWS Regions.
  • S3 Same-Region Replication – SRR is used to copy objects across S3 buckets in the same AWS Regions.
  • S3 Replication helps to
    • Replicate objects while retaining metadata
    • Replicate objects into different storage classes
    • Maintain object copies under different ownership
    • Keep objects stored over multiple AWS Regions
    • Replicate objects within 15 minutes
  • S3 can replicate all or a subset of objects with specific key name prefixes
  • S3 encrypts all data in transit across AWS regions using SSL
  • Object replicas in the destination bucket are exact replicas of the objects in the source bucket with the same key names and the same metadata.
  • Objects may be replicated to a single destination bucket or multiple destination buckets.
  • Cross-Region Replication can be useful for the following scenarios:-
    • Compliance requirement to have data backed up across regions
    • Minimize latency to allow users across geography to access objects
    • Operational reasons compute clusters in two different regions that analyze the same set of objects
  • Same-Region Replication can be useful for the following scenarios:-
    • Aggregate logs into a single bucket
    • Configure live replication between production and test accounts
    • Abide by data sovereignty laws to store multiple copies
  • Replication Requirements
    • source and destination buckets must be versioning-enabled
    • for CRR, the source and destination buckets must be in different AWS regions.
    • S3 must have permission to replicate objects from that source bucket to the destination bucket on your behalf.
    • If the source bucket owner also owns the object, the bucket owner has full permission to replicate the object. If not, the source bucket owner must have permission for the S3 actions s3:GetObjectVersion and s3:GetObjectVersionACL to read the object and object ACL
    • Setting up cross-region replication in a cross-account scenario (where the source and destination buckets are owned by different AWS accounts), the source bucket owner must have permission to replicate objects in the destination bucket.
    • if the source bucket has S3 Object Lock enabled, the destination buckets must also have S3 Object Lock enabled.
    • destination buckets cannot be configured as Requester Pays buckets
  • Replicated & Not Replicated
    • Only new objects created after you add a replication configuration are replicated. S3 does NOT retroactively replicate objects that existed before you added replication configuration.
    • Objects encrypted using customer provided keys (SSE-C), objects encrypted at rest under an S3 managed key (SSE-S3) or a KMS key stored in AWS Key Management Service (SSE-KMS).
    • S3 replicates only objects in the source bucket for which the bucket owner has permission to read objects and read ACLs
    • Any object ACL updates are replicated, although there can be some delay before S3 can bring the two in sync. This applies only to objects created after you add a replication configuration to the bucket.
    • S3 does NOT replicate objects in the source bucket for which the bucket owner does not have permission.
    • Updates to bucket-level S3 subresources are NOT replicated, allowing different bucket configurations on the source and destination buckets
    • Only customer actions are replicated & actions performed by lifecycle configuration are NOT replicated
    • Replication chaining is NOT allowed, Objects in the source bucket that are replicas, created by another replication, are NOT replicated.
    • S3 does NOT replicate the delete marker by default. However, you can add delete marker replication to non-tag-based rules to override it.
    • S3 does NOT replicate deletion by object version ID. This protects data from malicious deletions.

S3 Inventory

  • S3 Inventory helps manage the storage and can be used to audit and report on the replication and encryption status of the objects for business, compliance, and regulatory needs.
  • S3 inventory provides a scheduled alternative to the S3 synchronous List API operation.
  • S3 inventory provides CSV, ORC, or Apache Parquet output files that list the objects and their corresponding metadata on a daily or weekly basis for an S3 bucket or a shared prefix.

Requester Pays

  • By default, buckets are owned by the AWS account that created it (the bucket owner) and the AWS account pays for storage costs, downloads, and data transfer charges associated with the bucket.
  • Using Requester Pays subresource:-
    • Bucket owner specifies that the requester requesting the download will be charged for the download
    • However, the bucket owner still pays the storage costs
  • Enabling Requester Pays on a bucket
    • disables anonymous access to that bucket
    • does not support BitTorrent
    • does not support SOAP requests
    • cannot be enabled for end-user logging bucket

Torrent

  • Default distribution mechanism for S3 data is via client/server download
  • Bucket owner bears the cost of Storage as well as the request and transfer charges which can increase linearly for a popular object
  • S3 also supports the BitTorrent protocol
    • BitTorrent is an open-source Internet distribution protocol
    • BitTorrent addresses this problem by recruiting the very clients that are downloading the object as distributors themselves
    • S3 bandwidth rates are inexpensive, but BitTorrent allows developers to further save on bandwidth costs for a popular piece of data by letting users download from Amazon and other users simultaneously
  • Benefit for a publisher is that for large, popular files the amount of data actually supplied by S3 can be substantially lower than what it would have been serving the same clients via client/server download
  • Any object in S3 that is publicly available and can be read anonymously can be downloaded via BitTorrent
  • Torrent file can be retrieved for any publicly available object by simply adding a “?torrent” query string parameter at the end of the REST GET request for the object
  • Generating the .torrent for an object takes time proportional to the size of that object, so its recommended to make a first torrent request yourself to generate the file so that subsequent requests are faster
  • Torrent is enabled only for objects that are less than 5 GB in size.
  • Torrent subresource can only be retrieved, and cannot be created, updated, or deleted

Object ACL

Refer blog post @ S3 Permissions

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. An organization’s security policy requires multiple copies of all critical data to be replicated across at least a primary and backup data center. The organization has decided to store some critical data on Amazon S3. Which option should you implement to ensure this requirement is met?
    1. Use the S3 copy API to replicate data between two S3 buckets in different regions
    2. You do not need to implement anything since S3 data is automatically replicated between regions
    3. Use the S3 copy API to replicate data between two S3 buckets in different facilities within an AWS Region
    4. You do not need to implement anything since S3 data is automatically replicated between multiple facilities within an AWS Region
  2. A customer wants to track access to their Amazon Simple Storage Service (S3) buckets and also use this information for their internal security and access audits. Which of the following will meet the Customer requirement?
    1. Enable AWS CloudTrail to audit all Amazon S3 bucket access.
    2. Enable server access logging for all required Amazon S3 buckets
    3. Enable the Requester Pays option to track access via AWS Billing
    4. Enable Amazon S3 event notifications for Put and Post.
  3. A user is enabling a static website hosting on an S3 bucket. Which of the below mentioned parameters cannot be configured by the user?
    1. Error document
    2. Conditional error on object name
    3. Index document
    4. Conditional redirection on object name
  4. Company ABCD is running their corporate website on Amazon S3 accessed from http//www.companyabcd.com. Their marketing team has published new web fonts to a separate S3 bucket accessed by the S3 endpoint: https://s3-us-west1.amazonaws.com/abcdfonts. While testing the new web fonts, Company ABCD recognized the web fonts are being blocked by the browser. What should Company ABCD do to prevent the web fonts from being blocked by the browser?
    1. Enable versioning on the abcdfonts bucket for each web font
    2. Create a policy on the abcdfonts bucket to enable access to everyone
    3. Add the Content-MD5 header to the request for webfonts in the abcdfonts bucket from the website
    4. Configure the abcdfonts bucket to allow cross-origin requests by creating a CORS configuration
  5. Company ABCD is currently hosting their corporate site in an Amazon S3 bucket with Static Website Hosting enabled. Currently, when visitors go to http://www.companyabcd.com the index.html page is returned. Company C now would like a new page welcome.html to be returned when a visitor enters http://www.companyabcd.com in the browser. Which of the following steps will allow Company ABCD to meet this requirement? Choose 2 answers.
    1. Upload an html page named welcome.html to their S3 bucket
    2. Create a welcome subfolder in their S3 bucket
    3. Set the Index Document property to welcome.html
    4. Move the index.html page to a welcome subfolder
    5. Set the Error Document property to welcome.html

AWS S3 Security

~ Last updated on : ~ jayendrapatil

AWS S3 Security

  • AWS S3 Security is a shared responsibility between AWS and the Customer
  • S3 is a fully managed service that is protected by the AWS global network security procedures
  • AWS handles basic security tasks like guest operating system (OS) and database patching, firewall configuration, and disaster recovery.
  • Security and compliance of S3 are assessed by third-party auditors as part of multiple AWS compliance programs including SOC, PCI DSS, HIPAA, etc.
  • S3 provides several other features to handle security, which are the customers’ responsibility.
  • S3 Encryption supports both data at rest and data in transit encryption.
    • Data in transit encryption can be provided by enabling communication via SSL or using client-side encryption
    • Data at rest encryption can be provided using Server Side or Client Side encryption
  • S3 permissions can be handled using
  • S3 Object Lock helps to store objects using a WORM model and can help prevent objects from being deleted or overwritten for a fixed amount of time or indefinitely.
  • S3 Access Points simplify data access for any AWS service or customer application that stores data in S3.
  • S3 Versioning with MFA Delete can be enabled on a bucket to ensure that data in the bucket cannot be accidentally overwritten or deleted.
  • S3 Block Public Access provides controls across an entire AWS Account or at the individual S3 bucket level to ensure that objects never have public access, now and in the future.
  • S3 Access Analyzer monitors the access policies, ensuring that the policies provide only the intended access to your S3 resources.

S3 Encryption

  • S3 allows the protection of data in transit by enabling communication via SSL or using client-side encryption
  • S3 provides data-at-rest encryption using
    • Server-Side Encryption: S3 handles the encryption
      • SSE-S3
        • S3 handles the encryption and decryption using S3 managed keys
      • SSE-KMS
        • S3 handles the encryption and decryption using keys managed through AWS KMS.
      • SSE-C
        • S3 handles the encryption and decryption using keys managed and provided by the Customer.
    • Client Side Encryption: Customer handles the encryption
      • CSE-CMK
        • Customer handles the encryption and decryption using keys managed through AWS KMS.
      • Client-side Master Key
        • Customer handles the encryption and decryption using keys managed by them.

S3 Permissions

Refer blog post @ S3 Permissions

S3 Object Lock

  • S3 Object Lock helps to store objects using a write-once-read-many (WORM) model.
  • can help prevent objects from being deleted or overwritten for a fixed amount of time or indefinitely.
  • can help meet regulatory requirements that require WORM storage or add an extra layer of protection against object changes and deletion.
  • can be enabled only for new buckets and works only in versioned buckets.
  • provides two retention modes that apply different levels of protection to the objects
    • Governance mode
      • Users can’t overwrite or delete an object version or alter its lock settings unless they have special permissions.
      • Objects can be protected from being deleted by most users, but some users can be granted permission to alter the retention settings or delete the object if necessary.
      • Can be used to test retention-period settings before creating a compliance-mode retention period.
    • Compliance mode
      • A protected object version can’t be overwritten or deleted by any user, including the root user in the AWS account.
      • Object retention mode can’t be changed, and its retention period can’t be shortened.
      • Object versions can’t be overwritten or deleted for the duration of the retention period.

S3 Access Points

  • S3 access points simplify data access for any AWS service or customer application that stores data in S3.
  • Access points are named network endpoints that are attached to buckets and can be used to perform S3 object operations, such as GetObject and PutObject.
  • Each access point has distinct permissions and network controls that S3 applies for any request that is made through that access point.
  • Each access point enforces a customized access point policy that works in conjunction with the bucket policy, attached to the underlying bucket.
  • An access point can be configured to accept requests only from a VPC to restrict S3 data access to a private network.
  • Custom block public access settings can be configured for each access point.

S3 VPC Gateway Endpoint

  • A VPC endpoint enables connections between a VPC and supported services, without requiring that you use an internet gateway, NAT device, VPN connection, or AWS Direct Connect connection.
  • VPC is not exposed to the public internet.
  • A Gateway Endpoint is a gateway that is a target for a route in your route table used for traffic destined to either S3.

S3 Block Public Access

  • S3 Block Public Access provides controls across an entire AWS Account or at the individual S3 bucket level to ensure that objects never have public access, now and in the future.
  • S3 Block Public Access provides settings for access points, buckets, and accounts to help manage public access to S3 resources.
  • By default, new buckets, access points, and objects don’t allow public access. However, users can modify bucket policies, access point policies, or object permissions to allow public access.
  • S3 Block Public Access settings override these policies and permissions so that public access to these resources can be limited.
  • S3 Block Public Access allows account administrators and bucket owners to easily set up centralized controls to limit public access to their S3 resources that are enforced regardless of how the resources are created.
  • S3 doesn’t support block public access settings on a per-object basis.
  • S3 Block Public Access settings when applied to an account apply to all AWS Regions globally.

S3 Access Analyzer

  • S3 Access Analyzer monitors the access policies, ensuring that the policies provide only the intended access to your S3 resources.
  • S3 Access Analyzer evaluates the bucket access policies and enables you to discover and swiftly remediate buckets with potentially unintended access.

S3 Security Best Practices

S3 Preventative Security Best Practices

  • Ensure S3 buckets use the correct policies and are not publicly accessible
    • Use S3 block public access
    • Identify Bucket policies and ACLs that allow public access
    • Use AWS Trusted Advisor to inspect the S3 implementation.
  • Implement least privilege access
  • Use IAM roles for applications and AWS services that require S3 access
  • Enable Multi-factor authentication (MFA) Delete to help prevent accidental bucket deletions
  • Consider Data at Rest Encryption
  • Enforce Data in Transit Encryption
  • Consider S3 Object Lock to store objects using a “Write Once Read Many” (WORM) model.
  • Enable versioning to easily recover from both unintended user actions and application failures.
  • Consider S3 Cross-Region replication
  • Consider VPC endpoints for S3 access to provide private S3 connectivity and help prevent traffic from potentially traversing the open internet.

S3 Monitoring and Auditing Best Practices

  • Identify and Audit all S3 buckets to have visibility of all the S3 resources to assess their security posture and take action on potential areas of weakness.
  • Implement monitoring using AWS monitoring tools
  • Enable S3 server access logging, which provides detailed records of the requests that are made to a bucket useful for security and access audits
  • Use AWS CloudTrail, which provides a record of actions taken by a user, a role, or an AWS service in S3.
  • Enable AWS Config, which enables you to assess, audit, and evaluate the configurations of the AWS resources
  • Consider using Amazon Macie with S3 to automatically discover, classify, and protect sensitive data in AWS.
  • Monitor AWS security advisories to regularly check security advisories posted in Trusted Advisor for the AWS account.

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.

References

AWS_S3_Security

AWS S3 Object Lock

~ Last updated on : ~ jayendrapatil ~ 1 Comment

AWS S3 Object Lock

  • S3 Object Lock helps to store objects using a write-once-read-many (WORM) model.
  • can help prevent objects from being deleted or overwritten for a fixed amount of time or indefinitely.
  • can help meet regulatory requirements that require WORM storage or add an extra layer of protection against object changes and deletion.
  • can be enabled only for new buckets. For an existing bucket, you need to contact AWS Support.
  • works only in versioned buckets.
  • Once Object Lock is enabled
    • Object Lock can’t be disabled
    • automatically enables versioning for the bucket
    • versioning can’t be suspended for the bucket.
  • provides two ways to manage object retention.
    • Retention period
      • protects an object version for a fixed amount of time, during which an object remains locked.
      • During this period, the object is WORM-protected and can’t be overwritten or deleted.
      • can be applied on an object version either explicitly or through a bucket default setting.
      • S3 stores a timestamp in the object version’s metadata to indicate when the retention period expires. After the retention period expires, the object version can be overwritten or deleted unless you also placed a legal hold on the object version.
    • Legal hold
      • protects an object version, as a retention period, but it has no expiration date.
      • remains in place until you explicitly remove it.
      • can be freely placed and removed by any user who has the s3:PutObjectLegalHold permission.
      • are independent of retention periods.
    • Retention periods and legal holds apply to individual object versions.
    • Placing a retention period or legal hold on an object protects only the version specified in the request. It doesn’t prevent new versions of the object from being created.
    • An object version can have both a retention period and a legal hold, one but not the other, or neither.
  • provides two retention modes that apply different levels of protection to the objects
    • Governance mode
    • Compliance mode
  • S3 buckets with S3 Object Lock can’t be used as destination buckets for server access logs.
  •  has been assessed by Cohasset Associates for use in environments that are subject to SEC 17a-4, CFTC, and FINRA regulations.

S3 Object Lock – Retention Modes

Governance mode

  • Users can’t overwrite or delete an object version or alter its lock settings unless they have special permissions.
  • Objects can be protected from being deleted by most users, but some users can be granted permission to alter the retention settings or delete the object if necessary.
  • Can be used to test retention-period settings before creating a compliance-mode retention period.
  • To override or remove governance-mode retention settings, a user must have the s3:BypassGovernanceRetention permission and must explicitly include x-amz-bypass-governance-retention:true as a request header.

Compliance mode

  • A protected object version can’t be overwritten or deleted by any user, including the root user in the AWS account.
  • Object retention mode can’t be changed, and its retention period can’t be shortened.
  • Object versions can’t be overwritten or deleted for the duration of the retention period.

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 company needs to store its accounting records in Amazon S3. No one at the company; including administrative users and root users, should be able to delete the records for an entire 10-year period. The records must be stored with maximum resiliency. Which solution will meet these requirements?
    1. Use an access control policy to deny deletion of the records for a period of 10 years.
    2. Use an IAM policy to deny deletion of the records. After 10 years, change the IAM policy to allow deletion.
    3. Use S3 Object Lock in compliance mode for a period of 10 years.
    4. Use S3 Object Lock in governance mode for a period of 10 years.

References

Amazon_S3_Object_Lock

AWS S3 Encryption

~ Last updated on : ~ jayendrapatil ~ 2 Comments

AWS S3 Encryption

📌 Key Updates (2023-2026)

  • January 2023: All new S3 object uploads are automatically encrypted with SSE-S3 by default at no additional cost.
  • Terminology Change: AWS KMS replaced “Customer Master Key (CMK)” with “KMS key.” The concept is unchanged.
  • June 2023: Dual-Layer Server-Side Encryption (DSSE-KMS) introduced for compliance workloads.
  • November 2025: New bucket-level setting to standardize encryption types (block SSE-C per bucket).
  • January 2026: UpdateObjectEncryption API allows changing encryption type without data movement.
  • April 2026: SSE-C is now disabled by default on all new general purpose buckets.
  • Client-Side Encryption: AmazonS3EncryptionClient is deprecated; use the standalone Amazon S3 Encryption Client (v4) with key commitment.
  • AWS S3 Encryption supports both data at rest and data in transit encryption.
  • Starting January 5, 2023, all new object uploads to Amazon S3 are automatically encrypted with SSE-S3 at no additional cost and with no impact on performance.
  • Data in-transit
    • S3 allows protection of data in transit by enabling communication via SSL/TLS or using client-side encryption.
  • Data at Rest
    • Server-Side Encryption
      • S3 encrypts the object before saving it on disks in its data centers and decrypts it when the objects are downloaded.
      • SSE-S3 is automatically applied as the base level of encryption for every bucket.
    • Client-Side Encryption
      • Data is encrypted at the client-side and uploaded to S3.
      • The encryption process, the encryption keys, and related tools are managed by the user.

S3 Server-Side Encryption

  • Server-side encryption is about data encryption at rest.
  • Server-side encryption encrypts only the object data.
  • Any object metadata is not encrypted.
  • S3 handles the encryption (as it writes to disks) and decryption (when objects are accessed) of the data objects.
  • There is no difference in the access mechanism for both encrypted and unencrypted objects and is handled transparently by S3.
  • Starting January 5, 2023, SSE-S3 is applied as the base level of encryption for every bucket in Amazon S3. All new object uploads are automatically encrypted.
  • S3 supports the following server-side encryption options:
    • SSE-S3 – Server-Side Encryption with S3-Managed Keys (default)
    • SSE-KMS – Server-Side Encryption with AWS KMS Keys
    • DSSE-KMS – Dual-Layer Server-Side Encryption with AWS KMS Keys
    • SSE-C – Server-Side Encryption with Customer-Provided Keys

Server-Side Encryption with S3-Managed Keys – SSE-S3

  • Encryption keys are handled and managed by AWS.
  • SSE-S3 is the default encryption for all S3 buckets. Since January 5, 2023, all new objects are automatically encrypted with SSE-S3 unless a different encryption option is specified.
  • Each object is encrypted with a unique data key employing strong multi-factor encryption.
  • SSE-S3 encrypts the data key with a root key that is regularly rotated.
  • S3 server-side encryption uses one of the strongest block ciphers available, 256-bit Advanced Encryption Standard (AES-256), to encrypt the data.
  • Whether or not objects are encrypted with SSE-S3 can’t be enforced when they are uploaded using pre-signed URLs, because the only way server-side encryption can be specified is through the AWS Management Console or through an HTTP request header.
  • Request must set header x-amz-server-side-encryption to AES256
  • For enforcing server-side encryption for all of the objects that are stored in a bucket, use a bucket policy that denies permissions to upload an object unless the request includes x-amz-server-side-encryption header to request server-side encryption.
  • Since all objects are now encrypted by default, bucket policies to enforce encryption are no longer strictly required but can still be used to enforce a specific encryption type (e.g., SSE-KMS over SSE-S3).
SSE-S3 : Server Side Encryption using S3 Managed Keys
Source: Oreilly

Server-Side Encryption with AWS KMS Keys – SSE-KMS

Server-Side Encryption with AWS KMS Keys (SSE-KMS)

  • SSE-KMS is similar to SSE-S3, but it uses AWS Key Management Service (KMS) which provides additional benefits along with additional charges.
    • KMS is a service that combines secure, highly available hardware and software to provide a key management system scaled for the cloud.
    • KMS uses KMS keys (previously called customer master keys or CMKs) to encrypt the S3 objects.
    • The KMS key material is never made available in plaintext.
    • KMS enables you to centrally create encryption keys, and define the policies that control how keys can be used.
    • Allows audit of key usage to prove they are being used correctly, by inspecting logs in AWS CloudTrail.
    • Allows keys to be temporarily disabled and re-enabled.
    • Allows keys to be rotated regularly (automatic annual rotation or on-demand rotation).
    • Security controls in AWS KMS can help meet encryption-related compliance requirements.
  • SSE-KMS enables separate permissions for the use of an envelope key (that is, a key that protects the data’s encryption key) that provides added protection against unauthorized access to the objects in S3.
  • SSE-KMS provides the option to create and manage encryption keys yourself (customer managed keys), or use an AWS managed key that is unique to you, the service you’re using, and the region you’re working in.
  • Creating and managing customer managed keys gives more flexibility, including the ability to create, rotate, disable, and define access controls, and audit the encryption keys used to protect the data.
  • Data keys used to encrypt the data are also encrypted and stored alongside the data they protect and are unique to each object.
  • Process flow
    • An application or AWS service client requests an encryption key to encrypt data and passes a reference to a KMS key under the account.
    • Client requests are authenticated based on whether they have access to use the KMS key.
    • A new data encryption key is created, and a copy of it is encrypted under the KMS key.
    • Both the data key and encrypted data key are returned to the client.
    • Data key is used to encrypt customer data and then deleted as soon as is practical.
    • Encrypted data key is stored for later use and sent back to AWS KMS when the source data needs to be decrypted.
  • S3 only supports symmetric KMS keys and not asymmetric keys.
  • Must set header x-amz-server-side-encryption to aws:kms

S3 Bucket Keys

  • S3 Bucket Keys reduce the cost of SSE-KMS by decreasing the request traffic from Amazon S3 to AWS KMS by up to 99%.
  • When enabled, S3 generates a bucket-level key from KMS and uses it to create data keys for objects in the bucket, reducing the number of KMS API calls.
  • S3 Bucket Keys are recommended for all SSE-KMS workloads to optimize both performance and cost.
  • S3 Bucket Keys are always enabled when using SSE-KMS with S3 Express One Zone.
  • Bucket Keys can be enabled at the bucket level or specified per object in PUT requests.
SSE-KMS : Server Side Encryption using AWS KMS managed keys
Source: Oreilly

Dual-Layer Server-Side Encryption with AWS KMS Keys – DSSE-KMS

  • Launched June 2023 for compliance workloads requiring two layers of encryption.
  • DSSE-KMS applies two independent layers of encryption to objects when they are uploaded to Amazon S3.
  • Each layer uses a different implementation of the 256-bit AES-GCM algorithm.
  • Designed to meet CNSSP 15 and other compliance standards requiring multi-layer encryption.
  • Can be specified in PUT/COPY requests or configured as the bucket’s default encryption.
  • Can be enforced using IAM and bucket policies.
  • Must set header x-amz-server-side-encryption to aws:kms:dsse
  • Higher cost than SSE-KMS due to additional processing overhead and KMS API calls.
  • Use cases: Government workloads, financial services, and any regulated industry requiring dual-layer encryption at rest.

Server-Side Encryption with Customer-Provided Keys – SSE-C

AWS S3 Server Side Encryption using Customer Provided Keys SSE-C

⚠️ Important Change (April 2026)

SSE-C is now disabled by default on all new general purpose buckets and existing buckets in accounts with no SSE-C encrypted objects. To use SSE-C, you must explicitly enable it by setting BlockedEncryptionTypes to NONE in the bucket’s default encryption configuration via the PutBucketEncryption API.

  • Encryption keys can be managed and provided by the Customer and S3 manages the encryption, as it writes to disks, and decryption, when you access the objects.
  • When you upload an object, the encryption key is provided as a part of the request and S3 uses that encryption key to apply AES-256 encryption to the data and removes the encryption key from memory.
  • When you download an object, the same encryption key should be provided as a part of the request. S3 first verifies the encryption key and if it matches, the object is decrypted before returning back to you.
  • As each object and each object’s version can be encrypted with a different key, you are responsible for maintaining the mapping between the object and the encryption key used.
  • SSE-C requests must be done through HTTPS and S3 will reject any requests made over HTTP when using SSE-C.
  • For security considerations, AWS recommends considering any key sent erroneously using HTTP to be compromised and it should be discarded or rotated.
  • S3 does not store the encryption key provided. Instead, a randomly salted HMAC value of the encryption key is stored which can be used to validate future requests. The salted HMAC value cannot be used to decrypt the contents of the encrypted object or to derive the value of the encryption key. That means, if you lose the encryption key, you lose the object.
  • Starting April 2026: SSE-C is disabled by default for all new general purpose buckets. You must explicitly enable SSE-C on a bucket before using it. This change was introduced to prevent ransomware attacks that exploited SSE-C with attacker-controlled keys.
SSE-C : Server-Side Encryption with Customer-Provided Keys
Source: Oreilly

Client-Side Encryption

Client-side encryption refers to encrypting data before sending it to S3 and decrypting the data after downloading it.

⚠️ SDK Update Notice

The original AmazonS3EncryptionClient class is deprecated. AWS now provides a standalone Amazon S3 Encryption Client library (currently at v4) that supports key commitment (AES-GCM with Key Commitment) for enhanced security. The AWS SDK for Java v1 reached end-of-support on December 31, 2025. Migrate to the standalone S3 Encryption Client or AWS SDK v2/v4 equivalents.

AWS KMS-managed Key (Client-Side Encryption with KMS – CSE-KMS)

  • Customer can maintain the encryption KMS key with AWS KMS and can provide the KMS key ID to the client to encrypt the data.
  • Uploading Object
    • The S3 Encryption Client first sends a request to AWS KMS for the key to encrypt the object data.
    • AWS KMS returns a randomly generated data encryption key with 2 versions: a plaintext version for encrypting the data and a cipher blob to be uploaded with the object as object metadata.
    • The client obtains a unique data encryption key for each object it uploads.
    • The S3 Encryption Client uploads the encrypted data and the cipher blob with object metadata.
  • Download Object
    • The client first downloads the encrypted object along with the cipher blob version of the data encryption key stored as object metadata.
    • The client then sends the cipher blob to AWS KMS to get the plaintext version of the same, so that it can decrypt the object data.
Client Side Encryption - KMS Key CSE-KMS
Source: Oreilly

Client-Side Master Key (CSE-C)

  • Encryption master keys are completely maintained at the Client-side.
  • Uploading Object
    • The S3 Encryption Client locally generates a random one-time-use symmetric key (data encryption key or data key).
    • Client encrypts the data encryption key using the customer-provided master key.
    • Client uses this data encryption key to encrypt the data of a single S3 object (for each object, the client generates a separate data key).
    • Client then uploads the encrypted data to S3 and also saves the encrypted data key and its material description as object metadata (x-amz-meta-x-amz-key) in S3 by default.
  • Downloading Object
    • Client first downloads the encrypted object from S3 along with the object metadata.
    • Using the material description in the metadata, the client first determines which master key to use to decrypt the encrypted data key.
    • Using that master key, the client decrypts the data key and uses it to decrypt the object.
  • Client-side master keys and your unencrypted data are never sent to AWS.
  • If the master key is lost the data cannot be decrypted.

UpdateObjectEncryption API (January 2026)

  • Launched January 29, 2026 – allows changing the server-side encryption type of existing S3 objects without any data movement.
  • Atomically updates the encryption key of objects regardless of size or storage class.
  • Uses envelope encryption to re-encrypt the data key with the newly specified encryption type.
  • Supported transitions: SSE-S3 → SSE-KMS, and applying S3 Bucket Keys to existing objects.
  • Can be used with S3 Batch Operations to change encryption type at scale while preserving object properties and S3 Lifecycle eligibility.
  • Eliminates the need to copy objects to change their encryption (previously required COPY operations).

Enforcing S3 Encryption

  • S3 Encryption in Transit
    • S3 Bucket Policy can be used to enforce SSL/TLS communication with S3 using the effect deny with condition aws:SecureTransport set to false.
  • S3 Default Encryption
    • Helps set the default encryption behavior for an S3 bucket so that all new objects are encrypted when they are stored in the bucket.
    • Objects are encrypted using SSE with either S3-managed keys (SSE-S3) or AWS KMS keys (SSE-KMS).
    • Since January 2023, SSE-S3 is automatically applied as the base level of encryption for all buckets. You can override this to SSE-KMS or DSSE-KMS.
  • S3 Bucket Policy
    • Can be applied to deny permissions to upload an object unless the request includes x-amz-server-side-encryption header to request server-side encryption.
    • Since all objects are now encrypted by default (SSE-S3), bucket policies are primarily useful to enforce a specific encryption type (e.g., SSE-KMS).
    • Bucket policies are evaluated before the default encryption.
  • Bucket-Level Encryption Standardization (November 2025)
    • New BlockedEncryptionTypes setting via the PutBucketEncryption API.
    • Allows disabling specific encryption types (e.g., SSE-C) at the bucket level.
    • Helps standardize the server-side encryption types used with your buckets.
    • Configurable via AWS Management Console, API, CLI, and CloudFormation.

S3 Bucket Policy Enforce Encryption

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 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.
  2. A user has enabled versioning on an S3 bucket. The user is using server side encryption for data at Rest. If the user is supplying his own keys for encryption (SSE-C) which of the below mentioned statements is true?
    1. The user should use the same encryption key for all versions of the same object
    2. It is possible to have different encryption keys for different versions of the same object
    3. AWS S3 does not allow the user to upload his own keys for server side encryption
    4. The SSE-C does not work when versioning is enabled
  3. A storage admin wants to encrypt all the objects stored in S3 using server side encryption. The user does not want to use the AES 256 encryption key provided by S3. How can the user achieve this?
    1. The admin should upload his secret key to the AWS console and let S3 decrypt the objects
    2. The admin should use CLI or API to upload the encryption key to the S3 bucket. When making a call to the S3 API mention the encryption key URL in each request
    3. S3 does not support client supplied encryption keys for server side encryption
    4. The admin should send the keys and encryption algorithm with each API call
  4. A user has enabled versioning on an S3 bucket. The user is using server side encryption for data at rest. If the user is supplying his own keys for encryption (SSE-C), what is recommended to the user for the purpose of security?
    1. User should not use his own security key as it is not secure
    2. Configure S3 to rotate the user’s encryption key at regular intervals
    3. Configure S3 to store the user’s keys securely with SSL
    4. Keep rotating the encryption key manually at the client side
  5. 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
  6. You are designing a personal document-archiving solution for your global enterprise with thousands of employee. Each employee has potentially gigabytes of data to be backed up in this archiving solution. The solution will be exposed to the employees as an application, where they can just drag and drop their files to the archiving system. Employees can retrieve their archives through a web interface. The corporate network has high bandwidth AWS DirectConnect connectivity to AWS. You have regulatory requirements that all data needs to be encrypted before being uploaded to the cloud. How do you implement this in a highly available and cost efficient way?
    1. Manage encryption keys on-premise in an encrypted relational database. Set up an on-premises server with sufficient storage to temporarily store files and then upload them to Amazon S3, providing a client-side master key. (Storing temporary increases cost and not a high availability option)
    2. Manage encryption keys in a Hardware Security Module(HSM) appliance on-premise server with sufficient storage to temporarily store, encrypt, and upload files directly into Amazon Glacier. (Not cost effective)
    3. Manage encryption keys in Amazon Key Management Service (KMS), upload to Amazon Simple Storage Service (S3) with client-side encryption using a KMS key ID and configure Amazon S3 lifecycle policies to store each object using the Amazon S3 Glacier storage class. (with CSE-KMS the encryption happens at client side before the object is uploaded to S3 and KMS is cost effective as well)
    4. Manage encryption keys in an AWS CloudHSM appliance. Encrypt files prior to uploading on the employee desktop and then upload directly into Amazon Glacier (Not cost effective)
  7. A user has enabled server side encryption with S3. The user downloads the encrypted object from S3. How can the user decrypt it?
    1. S3 does not support server side encryption
    2. S3 provides a server side key to decrypt the object
    3. The user needs to decrypt the object using their own private key
    4. S3 manages encryption and decryption automatically
  8. When uploading an object, what request header can be explicitly specified in a request to Amazon S3 to encrypt object data when saved on the server side?
    1. x-amz-storage-class
    2. Content-MD5
    3. x-amz-security-token
    4. x-amz-server-side-encryption
  9. A company must ensure that any objects uploaded to an S3 bucket are encrypted. Which of the following actions should the SysOps Administrator take to meet this requirement? (Select TWO.)
    1. Implement AWS Shield to protect against unencrypted objects stored in S3 buckets.
    2. Implement Object access control list (ACL) to deny unencrypted objects from being uploaded to the S3 bucket.
    3. Implement Amazon S3 default encryption to make sure that any object being uploaded is encrypted before it is stored.
    4. Implement Amazon Inspector to inspect objects uploaded to the S3 bucket to make sure that they are encrypted.
    5. Implement S3 bucket policies to deny unencrypted objects from being uploaded to the buckets.
  10. A company wants to ensure all objects in their S3 bucket are encrypted with SSE-KMS using a specific customer managed key. They also want to reduce AWS KMS costs. What combination of steps should be taken? (Select TWO.)
    1. Configure the bucket’s default encryption to use SSE-KMS with the specific customer managed KMS key.
    2. Configure a bucket policy to deny all s3:PutObject requests that don’t include the x-amz-server-side-encryption header set to AES256.
    3. Enable S3 Transfer Acceleration to reduce KMS API calls.
    4. Enable S3 Bucket Keys to reduce request traffic from S3 to KMS and lower costs by up to 99%.
    5. Use DSSE-KMS to apply dual-layer encryption for cost savings.
  11. An organization needs to change the encryption type of millions of existing S3 objects from SSE-S3 to SSE-KMS without impacting object metadata or lifecycle policies. What is the most efficient approach?
    1. Download all objects and re-upload them with SSE-KMS specified in the PUT request.
    2. Use S3 Batch Operations with a COPY operation to copy objects in-place with SSE-KMS encryption.
    3. Use S3 Batch Operations with the UpdateObjectEncryption operation to atomically change the encryption type without data movement.
    4. Change the bucket default encryption to SSE-KMS; existing objects will be automatically re-encrypted.

References

AWS S3 Versioning

~ Last updated on : ~ jayendrapatil ~ 7 Comments

S3 Versioning

  • S3 Versioning helps to keep multiple variants of an object in the same bucket and can be used to preserve, retrieve, and restore every version of every object stored in the S3 bucket.
  • S3 Object Versioning can be used to protect from unintended overwrites and accidental deletions
  • As Versioning maintains multiple copies of the same objects as a whole and charges accrue for multiple versions for e.g. for a 1GB file with 5 copies with minor differences would consume 5GB of S3 storage space and you would be charged for the same.
  • Buckets can be in one of the three states
    • Unversioned (the default)
    • Versioning-enabled
    • Versioning-suspended
  • S3 Object Versioning is not enabled by default and has to be explicitly enabled for each bucket.
  • Versioning once enabled, cannot be disabled and can only be suspended
  • Versioning enabled on a bucket applies to all the objects within the bucket
  • Permissions are set at the version level. Each version has its own object owner; an AWS account that creates the object version is the owner. So, you can set different permissions for different versions of the same object.
  • Irrespective of the Versioning, each object in the bucket has a version.
    • For Non Versioned bucket, the version ID for each object is null
    • For Versioned buckets, a unique version ID is assigned to each object
  • With Versioning, version ID forms a key element to define the uniqueness of an object within a bucket along with the bucket name and object key

Object Retrieval

  • For Non Versioned bucket
    • An Object retrieval always returns the only object available.
  • For Versioned bucket
    • An object retrieval returns the Current latest object.
    • Non-Current objects can be retrieved by specifying the version ID.

Object Addition

  • For Non Versioned bucket
    • If an object with the same key is uploaded again it overwrites the object
  • For Versioned bucket
    • If an object with the same key is uploaded, the newly uploaded object becomes the current version and the previous object becomes the non-current version.
    • A non-current versioned object can be retrieved and restored hence protecting against accidental overwrites

Object Deletion

  • For Non Versioned bucket
    • An object is permanently deleted and cannot be recovered
  • For the Versioned bucket,
    • All versions remain in the bucket and Amazon inserts a delete marker which becomes the Current version
    • A non-current versioned object can be retrieved and restored hence protecting against accidental overwrites
    • If an Object with a specific version ID is deleted, a permanent deletion happens and the object cannot be recovered

Delete marker

  • Delete Marker object does not have any data or ACL associated with it, just the key and the version ID
  • An object retrieval on a bucket with a delete marker as the Current version would return a 404
  • Only a DELETE operation is allowed on the Delete Marker object
  • If the Delete marker object is deleted by specifying its version ID, the previous non-current version object becomes the current version object
  • If a DELETE request is fired on an object with Delete Marker as the current version, the Delete marker object is not deleted but a Delete Marker is added again

S3 Versioning - Delete Operation

Restoring Previous Versions

  • Copy a previous version of the object into the same bucket. The copied object becomes the current version of that object and all object versions are preserved – Recommended as it keeps all the versions.
  • Permanently delete the current version of the object. When you delete the current object version, you, in effect, turn the previous version into the current version of that object.

Versioning Suspended Bucket

  • Versioning can be suspended to stop accruing new versions of the same object in a bucket.
  • Existing objects in the bucket do not change and only future requests behavior changes.
  • An object with version ID null is added for each new object addition.
  • For each object addition with the same key name, the object with the version ID null is overwritten.
  • An object retrieval request will always return the current version of the object.
  • A DELETE request on the bucket would permanently delete the version ID null object and inserts a Delete Marker
  • A DELETE request does not delete anything if the bucket does not have an object with version ID null
  • A DELETE request can still be fired with a specific version ID for any previous object with version IDs stored

MFA Delete

  • Additional security can be enabled by configuring a bucket to enable MFA (Multi-Factor Authentication) for the deletion of objects.
  • MFA Delete enabled, requires additional authentication for operations
    • Changing the versioning state of the bucket
    • Permanently deleting an object version
  • MFA Delete can be enabled on a bucket to ensure that data in the bucket cannot be accidentally deleted
  • While the bucket owner, the AWS account that created the bucket (root account), and all authorized IAM users can enable versioning, but only the bucket owner (root account) can enable MFA Delete.
  • MFA Delete however does not prevent deletion or allow restoration.
  • MFA Delete cannot be enabled using the AWS Management Console. You must use the AWS Command Line Interface (AWS CLI) or the API.

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 set of Amazon S3 features helps to prevent and recover from accidental data loss?
    1. Object lifecycle and service access logging
    2. Object versioning and Multi-factor authentication
    3. Access controls and server-side encryption
    4. Website hosting and Amazon S3 policies
  2. You use S3 to store critical data for your company Several users within your group currently have full permissions to your S3 buckets. You need to come up with a solution that does not impact your users and also protect against the accidental deletion of objects. Which two options will address this issue? Choose 2 answers
    1. Enable versioning on your S3 Buckets
    2. Configure your S3 Buckets with MFA delete
    3. Create a Bucket policy and only allow read only permissions to all users at the bucket level
    4. Enable object life cycle policies and configure the data older than 3 months to be archived in Glacier
  3. To protect S3 data from both accidental deletion and accidental overwriting, you should
    1. enable S3 versioning on the bucket
    2. access S3 data using only signed URLs
    3. disable S3 delete using an IAM bucket policy
    4. enable S3 Reduced Redundancy Storage
    5. enable Multi-Factor Authentication (MFA) protected access
  4. A user has not enabled versioning on an S3 bucket. What will be the version ID of the object inside that bucket?
    1. 0
    2. There will be no version attached
    3. Null
    4. Blank
  5. A user is trying to find the state of an S3 bucket with respect to versioning. Which of the below mentioned states AWS will not return when queried?
    1. versioning-enabled
    2. versioning-suspended
    3. unversioned
    4. versioned

References

AWS S3 Versioning

AWS CloudFront with S3

CloudFront S3 Origin Access Identity - OAI
~ Last updated on : ~ jayendrapatil

AWS CloudFront with S3

  • CloudFront can be used to distribute the content from an S3 bucket.
  • For an RTMP distribution, the S3 bucket is the only supported origin, and custom origins cannot be used
  • Using CloudFront over S3 has the following benefits
    • can be more cost-effective if the objects are frequently accessed as at higher usage, and the price for CloudFront data transfer is much lower than the price for S3 data transfer.
    • downloads are faster with CloudFront than with S3 alone because the objects are stored closer to the users
  • CloudFront provides two ways to send authenticated requests to an S3 origin: Origin Access Control (OAC) and Origin Access Identity (OAI).
  • OAC is the recommended and preferred method. OAI is legacy and deprecated — new CloudFront distributions (as of March 2026) can only use OAC.
  • When using S3 as the origin for distribution and the bucket is moved to a different region, CloudFront can take up to an hour to update its records to include the change of region when both of the following are true:
    • Origin Access Control (OAC) or Origin Access Identity (OAI) are used to restrict access to the bucket.
    • Bucket is moved to an S3 region that requires Signature Version 4 for authentication
  • CloudFront does not currently support S3 directory buckets (S3 Express One Zone) as origins directly.

Origin Access Control – OAC

CloudFront Origin Access Control - OAC

  • Origin Access Control (OAC) is the recommended method to restrict direct S3 access and should be used for all new distributions.
  • OAC supports:
    • Enhanced security practices like short-term credentials, frequent credential rotations, and resource-based policies
    • All S3 buckets in all AWS Regions, including opt-in Regions launched after December 2022
    • S3 server-side encryption with AWS KMS (SSE-KMS)
    • Dynamic requests (PUT, POST, DELETE) to Amazon S3
    • Comprehensive HTTP methods support — OAC supports GET, PUT, POST, PATCH, DELETE, OPTIONS, and HEAD.
  • OAC is based on IAM service principals to authenticate with S3 origins using AWS Signature Version 4 (SigV4).
  • CloudFront OAC needs to be set up with permissions to access the S3 bucket origin using an S3 bucket policy that grants the CloudFront service principal (cloudfront.amazonaws.com) access, scoped to the specific distribution ARN.
  • For buckets with objects encrypted using server-side encryption with AWS Key Management Service (SSE-KMS), the OAC must be provided with permission to use the AWS KMS key via the KMS key policy.
  • When using CloudFront OAC with Amazon S3 bucket origins, Amazon S3 Object Ownership must be set to Bucket owner enforced (the default for new S3 buckets). If ACLs are required, use the Bucket owner preferred setting.
  • OAC does not work with S3 buckets configured as website endpoints — these must be set up as custom origins.
  • OAC Signing Behavior options:
    • Always sign requests (recommended) — CloudFront always signs requests to the S3 origin.
    • Never sign requests — Turns off OAC; bucket must be publicly accessible.
    • Do not override authorization header — CloudFront signs only when the viewer request doesn’t include an Authorization header.

OAC Extended Origin Support (2024)

  • CloudFront OAC is not limited to S3 origins. It now also supports:
    • AWS Lambda function URL origins (April 2024) — Secures Lambda function URLs by permitting access only from designated CloudFront distributions using SigV4.
    • AWS Elemental MediaPackage v2 origins — Restricts access to MediaPackage v2 channel endpoints.
    • AWS Elemental MediaStore origins — Restricts access to MediaStore container endpoints.

Migrating from OAI to OAC

  • To migrate, first update the S3 bucket policy to allow both the OAI and the distribution with OAC enabled to access the bucket’s content.
  • This ensures CloudFront never loses access during the transition.
  • After the distribution is fully deployed with OAC, remove the OAI statement from the bucket policy.

Origin Access Identity – OAI (Legacy, Not Recommended)

⚠️ OAI DEPRECATED

Origin Access Identity (OAI) is a legacy feature. AWS deprecated OAI creation in 2024. As of March 2026, new CloudFront distributions can only use Origin Access Control (OAC). Existing OAI-based distributions continue to function but cannot be attached to new distributions.

Action Required: Migrate to Origin Access Control (OAC) for enhanced security and feature support.

CloudFront S3 Origin Access Identity - OAI

  • OAI doesn’t support:
    • Amazon S3 buckets in opt-in Regions (launched after January 2023)
    • Amazon S3 server-side encryption with AWS KMS (SSE-KMS)
    • Dynamic requests (PUT, POST, or DELETE) to Amazon S3
  • S3 origin objects must be granted public read permissions and hence the objects are accessible from both S3 as well as CloudFront.
  • Even though CloudFront does not expose the underlying S3 URL, it can be known to the user if shared directly or used by applications.
  • For using CloudFront signed URLs or signed cookies to provide access to the objects, it would be necessary to prevent users from having direct access to the S3 objects.
  • Users accessing S3 objects directly would
    • bypass the controls provided by CloudFront signed URLs or signed cookies, for e.g., control over the date-time that a user can no longer access the content and the IP addresses can be used to access content
    • CloudFront access logs are less useful because they’re incomplete.
  • Origin Access Identity (OAI) can be used to prevent users from directly accessing objects from S3.
  • Origin access identity, which is a special CloudFront user, can be created and associated with the distribution.
  • S3 bucket/object permissions need to be configured to only provide access to the Origin Access Identity.
  • When users access the object from CloudFront, it uses the OAI to fetch the content on the user’s behalf, while the S3 object’s direct access is restricted

CloudFront with S3 Objects

  • CloudFront can be configured to include custom headers or modify existing headers whenever it forwards a request to the origin, to
    • validate the user is not accessing the origin directly, bypassing CDN
    • identify the CDN from which the request was forwarded, if more than one CloudFront distribution is configured to use the same origin
    • if users use viewers that don’t support CORS, configure CloudFront to forward the Origin header to the origin. That will cause the origin to return the Access-Control-Allow-Origin header for every request

Adding & Updating Objects

  • Objects just need to be added to the Origin and CloudFront would start distributing them when accessed.
  • For objects served by CloudFront, the Origin can be updated either by
    • Overwriting the original object
    • Create a different version and update the links exposed to the user.
  • For updating objects, it is recommended to use versioning e.g. have files or the entire folders with versions, so links can be changed when the objects are updated forcing a refresh.
  • With versioning,
    • there is no wait time for an object to expire before CloudFront begins to serve a new version of it.
    • there is no difference in consistency in the object served from the edge
    • no cost is involved to pay for object invalidation.

Removing/Invalidating Objects

  • Objects, by default, would be removed upon expiry (TTL) and the latest object would be fetched from the Origin
  • Objects can also be removed from the edge cache before it expires
    • File or Object Versioning to serve a different version of the object that has a different name.
    • Invalidate the object from edge caches. For the next request, CloudFront returns to the Origin to fetch the object
  • Object or File Versioning is recommended over Invalidating objects
    • if the objects need to be updated frequently.
    • enables to control which object a request returns even when the user has a version cached either locally or behind a corporate caching proxy.
    • makes it easier to analyze the results of object changes as CloudFront access logs include the names of the objects
    • provides a way to serve different versions to different users.
    • simplifies rolling forward & back between object revisions.
    • is less expensive, as no charges for invalidating objects.
    • for e.g. change header-v1.jpg to header-v2.jpg
  • Invalidating objects from the cache
    • objects in the cache can be invalidated explicitly before they expire to force a refresh
    • allows to invalidate selected objects
    • allows to invalidate multiple objects for e.g. objects in a directory or all of the objects whose names begin with the same characters, you can include the * wildcard at the end of the invalidation path.
    • the user might continue to see the old version until it expires from those caches.
    • A specified number of invalidation paths can be submitted each month for free. Any invalidation requests more than the allotted no. per month, a fee is charged for each submitted invalidation path
    • The First 1,000 invalidation paths requests submitted per month are free; charges apply for each invalidation path over 1,000 in a month.
    • Invalidation path can be for a single object for e.g. /js/ab.js or for multiple objects for e.g. /js/* and is counted as a single request even if the * wildcard request may invalidate thousands of objects.
  • For RTMP distribution, objects served cannot be invalidated

Invalidation by Cache Tag (2026)

  • CloudFront now supports tag-based cache invalidation (announced April 2026), enabling invalidation of cached objects based on semantic tags rather than URL paths.
  • How it works:
    • Configure a CacheTagConfig on the distribution specifying the HTTP header name for cache tags.
    • The origin returns a cache tag header (e.g., x-amz-meta-cache-tag) with comma-separated tag values in HTTP responses.
    • Use the CreateInvalidation API with a # prefix to invalidate all objects matching a tag (e.g., #product:electronics).
  • For S3 origins, cache tags can be attached as S3 object metadata. A metadata key of cache-tag is returned by S3 as an x-amz-meta-cache-tag header.
  • Alternatively, a Lambda@Edge origin response function can add cache tag headers.
  • Tag format requirements:
    • ASCII visible characters (33–126), no spaces or commas
    • Case-insensitive, maximum 256 characters per tag
    • Maximum 50 tags per object
  • Path and tag invalidations can be mixed in a single request.
  • Tag invalidation is opt-in — distributions without CacheTagConfig ignore cache tag headers.
  • Backward compatible — existing path and wildcard invalidations continue to work unchanged.

Partial Requests (Range GETs)

  • Partial requests using Range headers in a GET request help to download the object in smaller units, improving the efficiency of partial downloads and the recovery from partially failed transfers.
  • For a partial GET range request, CloudFront
    • checks the cache in the edge location for the requested range or the entire object and if exists, serves it immediately
    • if the requested range does not exist, it forwards the request to the origin and may request a larger range than the client requested to optimize performance
    • if the origin supports range header, it returns the requested object range and CloudFront returns the same to the viewer
    • if the origin does not support range header, it returns the complete object and CloudFront serves the entire object and caches it for future.
    • CloudFront uses the cached entire object to serve any future range GET header requests

CloudFront VPC Origins (2024)

  • CloudFront VPC Origins (launched November 2024) allows CloudFront to deliver content from applications hosted in VPC private subnets.
  • Eliminates the need for applications to be exposed on the public internet by restricting access solely through CloudFront distributions.
  • Supports Application Load Balancers (ALBs), Network Load Balancers (NLBs), or EC2 instances in private subnets as origins.
  • For S3 origins, OAC remains the managed solution. VPC Origins is designed for compute-based origins (ALB, NLB, EC2).
  • Origin servers remain hidden from the internet, reducing the attack surface.
  • VPC Origin modification via CloudFront Functions is also supported (April 2025).

CloudFront Origin Modification via CloudFront Functions (2024)

  • CloudFront supports origin modification within CloudFront Functions (announced November 2024), enabling conditional origin changes on each request.
  • Allows dynamically routing requests to different S3 buckets or other origins based on request attributes (headers, path, query strings).
  • Use cases include A/B testing, failover, geographic routing, and multi-tenant architectures.
  • Additional capabilities added (November 2025): edge location and Regional Edge Cache (REC) metadata, raw query string retrieval, and advanced origin overrides.

CloudFront Mutual TLS for Origins (2026)

  • CloudFront now supports mutual TLS (mTLS) authentication for origins (announced January 2026), enabling end-to-end certificate-based authentication from viewers to origins.
  • Ensures that only authorized CloudFront distributions can establish connections with origin servers.
  • Supports per-origin configuration with different client certificates for different origins within the same distribution.
  • Stronger than custom headers or IP allowlists for origin authentication.
  • Works with AWS, on-premises, and third-party backends.
  • CloudFront also supports mTLS Passthrough Mode for viewers (May 2026), forwarding client certificates to the origin without verification at CloudFront.

AWS Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • AWS services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • AWS exam questions are not updated to keep up the pace with AWS updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.
  1. You are building a system to distribute confidential training videos to employees. Using CloudFront, what method could be used to serve content that is stored in S3, but not publically accessible from S3 directly?
    1. Create an Origin Access Identity (OAI) for CloudFront and grant access to the objects in your S3 bucket to that OAI. [Note: While this answer remains technically correct for the question, OAI is now legacy. The recommended approach for new implementations is Origin Access Control (OAC).]
    2. Add the CloudFront account security group “amazon-cf/amazon-cf-sg” to the appropriate S3 bucket policy.
    3. Create an Identity and Access Management (IAM) User for CloudFront and grant access to the objects in your S3 bucket to that IAM User.
    4. Create an S3 bucket policy that lists the CloudFront distribution ID as the Principal and the target bucket as the Amazon Resource Name (ARN).
  2. A company wants to restrict access to its S3 bucket origin so that content is only accessible through their CloudFront distribution. They also need to support uploading files via CloudFront and use SSE-KMS encryption. Which approach should they use?
    1. Configure Origin Access Identity (OAI) with a bucket policy granting s3:GetObject and s3:PutObject.
    2. Configure Origin Access Control (OAC) with a bucket policy granting the CloudFront service principal s3:GetObject and s3:PutObject, and update the KMS key policy to allow CloudFront.
    3. Make the S3 bucket public and use CloudFront signed URLs to restrict viewer access.
    4. Use a Lambda@Edge function to sign all requests to S3 using IAM credentials.
  3. A development team needs to invalidate all cached product images across their CloudFront distribution whenever a product category is updated, regardless of URL path structure. What is the most efficient approach?
    1. Create a wildcard invalidation for /* to clear all cached content.
    2. Maintain a list of all product image URLs and submit individual invalidation paths.
    3. Configure cache tag invalidation on the distribution and tag objects with category metadata, then invalidate by cache tag.
    4. Reduce the TTL to 0 for all product images so they are never cached.
  4. An organization uses CloudFront to serve a web application from an ALB in a private subnet. They want to ensure the ALB is never directly accessible from the internet. Which CloudFront feature should they use?
    1. Origin Access Control (OAC)
    2. AWS WAF with IP restriction rules
    3. CloudFront VPC Origins
    4. CloudFront signed URLs with a custom policy
  5. A company needs to verify that requests to their origin server come exclusively from their authorized CloudFront distribution, using certificate-based authentication instead of shared secrets or IP allowlists. Which feature should they implement?
    1. CloudFront Origin Access Control (OAC)
    2. Custom origin headers with a shared secret value
    3. AWS WAF with CloudFront managed prefix list
    4. CloudFront mutual TLS (mTLS) for origins

References