Sample Questions

AWS Resource Tags – Tagging Strategy & Cost Allocation

~ Last updated on : ~ jayendrapatil ~ 2 Comments

AWS Tags – Resource Groups – Tag Editor

  • Tags are key/value pairs that can be attached to AWS resources
  • Tags are metadata: that means that they don’t actually do anything, they’re purely for labeling purposes and helps to organize AWS resources
  • Tagging allows the user to assign her own (words/phrases/labels) metadata to each resource in the form of tags.
  • Tags don’t have any semantic meaning to the resources it is assigned and are interpreted strictly as a string of characters
  • Tags can
    • help to manage AWS resources & services for e.g. instances, images, security groups, etc.
    • help categorize AWS resources in different ways, for e.g., by purpose, owner (Developer, Finance, etc), or environment (DEV, TEST, PROD, etc).
    • help search and filter the resources
    • be used as a mechanism to organize resource costs on the cost allocation report.
    • enable Attribute-Based Access Control (ABAC) for fine-grained permissions management
    • support automation and operational workflows for e.g., automated patching, backup schedules, instance scheduling
  • Tags are not automatically assigned to the resources, however, are (sometimes) inherited for e.g. services such as Auto Scaling, Elastic Beanstalk, and CloudFormation can create other resources, such as RDS or EC2 instances, and usually tag that resource with a reference to itself. These tags do count toward the total tag limit for a resource
  • Tags can be defined using the
    • AWS Management Console,
    • AWS CLI
    • Amazon API.
  • Most AWS resources now support tagging on creation (tag-on-create), allowing tags to be applied when a resource is first created via console, CLI, or API.
  • Each tag consists of a key and value
    • key and an optional value, both of which are user-controlled
    • defining a new tag that has the same key as an existing tag on that resource, the new value overwrites the old value.
    • keys and values can be edited, removed from a resource at any time.
    • value can be defined as an empty string, but can’t be set to null.
  • IAM allows you the ability to control which users in the AWS account have permission to create, edit, or delete tags.
  • Common examples of tags are Environment, Application, Owner, Cost Center, Purpose, Stack, etc.
  • AWS also applies system-generated tags (prefixed with aws:) automatically to resources for internal tracking.

Tags Restriction

  • Maximum number of tags per resource – 50 (user-created tags; aws: prefixed tags do not count against this limit)
  • Maximum key length – 128 Unicode characters in UTF-8
  • Maximum value length – 256 Unicode characters in UTF-8
  • Tag keys and values are case-sensitive.
  • Do not use the aws: prefix in the tag names or values because it is reserved for AWS use. Tags with this prefix can’t be edited or deleted and they do not count against the tags per resource limit.
  • Tags allowed characters are: letters, spaces, and numbers representable in UTF-8, plus the following special characters: + – = . _ : / @.
  • Each tag key must be unique for each resource; it can have only one value per key.

Tagging Strategy

  • AWS recommends defining a comprehensive tagging strategy early when establishing your cloud foundation
  • Common tagging categories include:
    • Technical tags – Name, Application, Environment, Version, Cluster
    • Business tags – Owner, CostCenter, Project, Department
    • Automation tags – Schedule (start/stop), Backup, Patch Group
    • Security tags – Confidentiality, Compliance, DataClassification
  • Mandatory tags are the minimum set of tags every resource should have, regardless of purpose (e.g., Owner, Environment, CostCenter)
  • Use consistent naming conventions – decide on camelCase, PascalCase, or kebab-case and apply uniformly
  • As the number of tags allowed per resource are limited, Complex Tagging can be used for e.g. keyName = value1|value2|value3 or keyName = key1|value1;key2|value2

EC2 Resources Tags

  • For tags on EC2 instances, instances can’t terminate, stop, or delete a resource based solely on its tags; the resource identifier must be specified
  • Public or shared resources can be tagged, but the tags assigned are available only to the AWS account and not to the other accounts sharing the resource.
  • Almost all EC2 resources can be tagged, including instances, AMIs, volumes, snapshots, security groups, and network interfaces.
  • EC2 supports tag-on-create – tags can be specified during resource creation (e.g., RunInstances, CreateVolume) using the TagSpecification parameter.

Cost Allocation Tags

  • Tags can be used as a mechanism to organize the resource costs on the cost allocation report.
  • Cost allocation tags can be used to categorize and track AWS costs.
  • There are two types of cost allocation tags:
    • AWS-generated tags – automatically created by AWS (e.g., aws:createdBy), must be activated by the management account owner in the Billing console
    • User-defined tags – created by users and must be activated in the Billing console to appear in cost reports
  • When tags are applied to AWS resources such as EC2 instances or S3 buckets and activated in the billing console, AWS generates a cost allocation report as a (CSV file) with the usage and costs aggregated by active tags.
  • Tags can be applied so that they represent business categories (such as cost centers, application names, or owners) to organize costs across multiple services.
  • Cost allocation report includes all of the AWS costs for each billing period and includes both tagged and untagged resources
  • Tags can also be used to filter views in Cost Explorer
  • AWS Cost Categories – allows grouping costs into meaningful categories based on rules (including tag-based rules) for advanced cost allocation
  • Split Cost Allocation Data – provides granular container-level cost visibility for Amazon ECS tasks and EKS pods, using Kubernetes labels and ECS task tags as cost allocation tags. Supports CPU, memory, and accelerator (GPU, Trainium, Inferentia) cost tracking.
  • When an account moves to another organization, previously activated cost allocation tags lose their “active” status and need to be re-activated by the new management account.

Attribute-Based Access Control (ABAC)

  • ABAC is an authorization strategy that defines permissions based on attributes (tags) attached to IAM principals and AWS resources.
  • Tags can be attached to IAM users, roles, and AWS resources to implement fine-grained access control.
  • Key IAM condition keys for ABAC:
    • aws:ResourceTag/tag-key – matches the tag on the target resource
    • aws:RequestTag/tag-key – matches the tag in the API request
    • aws:PrincipalTag/tag-key – matches the tag on the calling IAM principal
    • aws:TagKeys – controls which tag keys can be used in a request
  • ABAC scales permissions automatically – new resources with matching tags are automatically accessible without policy updates
  • Requires fewer policies compared to traditional RBAC (Role-Based Access Control) as environments grow
  • Supported by most AWS services including EC2, S3, RDS, Lambda, DynamoDB, and SageMaker
  • Amazon S3 ABAC support (launched Nov 2025) – enables tag-based access control for S3 general purpose buckets, eliminating frequent IAM or bucket policy updates as the organization grows

Tag Policies (AWS Organizations)

  • Tag Policies allow standardization of tags attached to AWS resources across an organization’s accounts
  • Help maintain consistent tagging with proactive compliance, governance, and control
  • Two key capabilities:
    • Basic compliance rules – define acceptable tag key case treatment and tag values for specific resource types
    • Required tag keys – specify mandatory tag keys that must be present on resources
  • Two enforcement modes:
    • Reporting mode – evaluates compliance and reports violations without blocking operations
    • Enforcement mode – prevents resource creation/modification with non-compliant tag values
  • Wildcard support (July 2025) – Tag Policies now support ALL_SUPPORTED in the Resource element, simplifying policy authoring and reducing policy size
  • IaC enforcement (Nov 2025) – Tag Policies can now validate and enforce required tags in CloudFormation, Terraform, and Pulumi deployments, preventing non-compliant deployments proactively
  • Tag policy enforcement has no effect on resources that are created without tags; use SCPs or AWS Config for mandatory tag-on-create enforcement

Tag Compliance and Governance

  • AWS Config required-tags rule – managed rule that checks if resources have specified tags; supports up to 6 tags with optional values in a single rule
  • Service Control Policies (SCPs) – can be used to deny resource creation without required tags using aws:RequestTag and aws:TagKeys condition keys
  • Combining Tag Policies + SCPs + AWS Config provides comprehensive tag governance:
    • Tag Policies – define allowed values and enforce consistency
    • SCPs – prevent untagged resource creation
    • AWS Config – detect and report non-compliant existing resources
  • Use AWS Config conformance packs to deploy tag compliance rules across multiple accounts

Resource Groups

  • A Resource Group is a collection of resources that share one or more tags or are based on an AWS CloudFormation stack
  • Resource groups help combine information for multiple resources and services on a single screen for e.g. for a Dev tag there might be multiple resources for ELB, EC2, and RDS. Using Resource Groups all the resources and their status can be viewed on a single page
  • Two types of resource groups:
    • Tag-based groups – resources matching specified tag key/value pairs
    • AWS CloudFormation stack-based groups – resources belonging to a CloudFormation stack
  • Resource Groups can be used with AWS Systems Manager to automate operational tasks on grouped resources (e.g., patching, run commands)
  • Expanded resource type support (2024-2025) – AWS Resource Groups added support for 490+ new resource types across 2024-2025, covering services like AWS Entity Resolution, Amazon Personalize, Amazon Q Apps, AWS Backup, AWS Network Manager, and many more
  • AWS PrivateLink support (June 2025) – Resource Groups APIs can now be invoked from within a VPC without traversing the public internet via interface VPC endpoints

AWS Resource Explorer

  • AWS Resource Explorer (launched 2022) enables searching and discovering AWS resources across Regions and accounts from a single interface
  • Supports search using tags, resource types, service names, and other metadata
  • Key features:
    • Unified Search – integrated into the AWS Management Console search bar
    • Multi-region search – find resources across all enabled regions
    • Tag-based filtering – search for resources by tag keys and values
    • tag:none filter – find all resources missing user-generated tags
  • Tagged resource discovery (Sept 2024) – can now discover all tagged resources regardless of whether the resource type is fully supported
  • Tag support filtering (May 2024) – filter for resources that support tags to evaluate tagging coverage
  • Resource Explorer complements Tag Editor by providing a broader search-and-discovery capability across the entire AWS account/organization
  • Automatic resource search – no longer requires explicit setup; Resource Explorer enables resource search functionality automatically with appropriate permissions

Tag Editor

  • Tag Editor allows the addition of tags to multiple resources at once (up to 400 resources in a single operation)
  • Tag Editor allows searching of resources using tags and then add, edit, remove tags for these resources
  • Supports multi-region tag management – search for and manage tags of resources across multiple AWS Regions
  • Tag Editor is part of the AWS Resource Groups console and works with the Resource Groups Tagging API
  • Supports hundreds of AWS resource types for tagging operations

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. Fill in the blanks: _________ let you categorize your EC2 resources in different ways, for example, by purpose, owner, or environment.
    1. Wildcards
    2. Pointers
    3. Tags
    4. Special filters
  2. Please select the Amazon EC2 resource, which can be tagged.
    1. Key pairs
    2. Elastic IP addresses
    3. Placement groups
    4. Amazon EBS snapshots
  3. Can the string value of ‘Key’ be prefixed with aws:?
    1. No
    2. Only for EC2 not S3
    3. Yes
    4. Only for S3 not EC
  4. What is the maximum key length of a tag?
    1. 512 Unicode characters
    2. 64 Unicode characters
    3. 256 Unicode characters
    4. 128 Unicode characters
  5. An organization has launched 5 instances: 2 for production and 3 for testing. The organization wants that one particular group of IAM users should only access the test instances and not the production ones. How can the organization set that as a part of the policy?
    1. Launch the test and production instances in separate regions and allow region wise access to the group (possible using location constraint condition but not flexible)
    2. Define the IAM policy which allows access based on the instance ID (not flexible as it would change)
    3. Create an IAM policy with a condition which allows access to only small instances (not flexible as it would change)
    4. Define the tags on the test and production servers and add a condition to the IAM policy which allows access to specific tags (possible using aws:ResourceTag condition – this is ABAC)
  6. A user has launched multiple EC2 instances for the purpose of development and testing in the same region. The user wants to find the separate cost for the production and development instances. How can the user find the cost distribution?
    1. The user should download the activity report of the EC2 services as it has the instance ID wise data
    2. It is not possible to get the AWS cost usage data of single region instances separately
    3. User should use Cost Distribution Metadata and AWS detailed billing
    4. User should use Cost Allocation Tags and AWS billing reports
  7. An organization is using cost allocation tags to find the cost distribution of different departments and projects. One of the instances has two separate tags with the key/value as “InstanceName/HR”, “CostCenter/HR”. What will AWS do in this case?
    1. InstanceName is a reserved tag for AWS. Thus, AWS will not allow this tag
    2. AWS will not allow the tags as the value is the same for different keys
    3. AWS will allow tags but will not show correctly in the cost allocation report due to the same value of the two separate keys
    4. AWS will allow both the tags and show properly in the cost distribution report
  8. A user is launching an instance. He is on the “Tag the instance” screen. Which of the below mentioned information will not help the user understand the functionality of an AWS tag?
    1. Each tag will have a key and value
    2. The user can apply tags to the S3 bucket
    3. The maximum value of the tag key length is 64 unicode characters
    4. AWS tags are used to find the cost distribution of various resources
  9. Your system recently experienced down time during the troubleshooting process. You found that a new administrator mistakenly terminated several production EC2 instances. Which of the following strategies will help prevent a similar situation in the future? The administrator still must be able to:- launch, start stop, and terminate development resources. – launch and start production instances.
    1. Create an IAM user, which is not allowed to terminate instances by leveraging production EC2 termination protection. (EC2 termination protection is enabled on EC2 instance)
    2. Leverage resource based tagging along with an IAM user, which can prevent specific users from terminating production EC2 resources. (Identify production resources using tags and add explicit deny – ABAC pattern)
    3. Leverage EC2 termination protection and multi-factor authentication, which together require users to authenticate before terminating EC2 instances. (Does not still prevent user from terminating instance)
    4. Create an IAM user and apply an IAM role, which prevents users from terminating production EC2 instances. (Role is not applied to User but assumed by the User also need a way to identify production EC2 instances)
  10. Your manager has requested you to tag EC2 instances to organize and manage a load balancer. Which of the following statements about tag restrictions is incorrect?
    1. The maximum key length is 127 Unicode characters.
    2. The maximum value length is 255 Unicode characters.
    3. Tag keys and values are case sensitive.
    4. The maximum number of tags per load balancer is 20. (50 is the limit)
  11. What is the maximum number of tags that a user can assign to an EC2 instance?
    1. 50
    2. 10
    3. 5
    4. 25
  12. A company wants to ensure all EC2 instances launched in their AWS accounts have mandatory “Environment” and “CostCenter” tags. Which combination of AWS services can enforce this requirement? (Choose 2)
    1. AWS Organizations Tag Policies with required tag keys and IaC enforcement
    2. Amazon CloudWatch Events with tag monitoring
    3. Service Control Policies (SCPs) with aws:RequestTag and aws:TagKeys conditions
    4. AWS CloudTrail with tag logging enabled
    5. Amazon Inspector with tag assessment templates
  13. An organization uses ABAC (Attribute-Based Access Control) to manage permissions. A developer tagged with “team=backend” needs access to Lambda functions tagged with “team=backend”. Which IAM condition key should be used in the policy?
    1. aws:RequestTag/team
    2. aws:TagKeys
    3. aws:ResourceTag/team with aws:PrincipalTag/team
    4. aws:userid
  14. A company needs to find all AWS resources across multiple regions that are missing required tags. Which AWS service provides this capability most efficiently?
    1. AWS Config with required-tags rule
    2. AWS CloudTrail with tag event filtering
    3. AWS Resource Explorer with the tag:none filter
    4. AWS Tag Editor with cross-region search

 

CloudWatch Monitoring Supported AWS Services

~ Last updated on : ~ jayendrapatil ~ 8 Comments

CloudWatch Monitoring Supported AWS Services

  • CloudWatch offers either basic or detailed monitoring for supported AWS services.
  • Basic monitoring means that a service sends data points to CloudWatch every five minutes.
  • Detailed monitoring means that a service sends data points to CloudWatch every minute.
  • If the AWS service supports both basic and detailed monitoring, the basic would be enabled by default and the detailed monitoring needs to be enabled for detailed metrics.
  • High-Resolution Custom Metrics allow publishing data at 1-second resolution using the PutMetricData API with a StorageResolution of 1.

Monitoring Categories

  • Basic Monitoring – Free, default set of metrics published at 5-minute intervals for most services.
  • Detailed Monitoring – Paid, more frequent metrics (typically 1-minute intervals). Must be explicitly enabled.
  • High-Resolution Custom Metrics – Custom metrics published at up to 1-second intervals using PutMetricData API or Embedded Metric Format (EMF).

Services Offering Detailed Monitoring

The following services officially offer detailed monitoring (paid, more fine-grained metrics):

  • Amazon API Gateway – Additional dimensions for detailed metrics
  • AWS AppSync – Detailed CloudWatch metrics
  • Amazon CloudFront – Additional distribution metrics
  • Amazon EC2 – 1-minute metrics (vs. 5-minute basic)
  • AWS Elastic Beanstalk – Enhanced health reporting and monitoring
  • Amazon Kinesis Data Streams – Enhanced shard-level metrics
  • AWS Lambda – Event source mapping metrics
  • Amazon Managed Streaming for Apache Kafka (MSK) – Per-broker, per-topic metrics
  • Amazon S3 – Request metrics at 1-minute intervals
  • Amazon SES – Detailed monitoring via event publishing

AWS Services with Monitoring Support

  • Auto Scaling
    • By default, basic monitoring is enabled when the launch configuration is created using the AWS Management Console, and detailed monitoring is enabled when the launch configuration is created using the AWS CLI or an API.
    • Auto Scaling sends data to CloudWatch every 5 minutes by default when created from Console.
    • For an additional charge, you can enable detailed monitoring for Auto Scaling, which sends data to CloudWatch every minute.
  • Amazon CloudFront
    • Amazon CloudFront sends data to CloudWatch every minute by default.
    • Additional distribution metrics (detailed monitoring) can be enabled for more fine-grained visibility.
  • Amazon CloudSearch
    • Amazon CloudSearch sends data to CloudWatch every minute by default.
  • Amazon EventBridge (formerly Amazon CloudWatch Events)
    • Amazon EventBridge sends data to CloudWatch every minute by default.
  • Amazon CloudWatch Logs
    • Amazon CloudWatch Logs sends data to CloudWatch every minute by default.
  • Amazon DynamoDB
    • Amazon DynamoDB sends data to CloudWatch every minute for some metrics and every 5 minutes for other metrics.
    • DynamoDB Contributor Insights provides additional metrics for table and global secondary index access patterns.
  • Amazon Elastic Container Service (Amazon ECS)
    • Amazon ECS sends data to CloudWatch every minute.
    • Container Insights provides additional detailed metrics at the cluster, service, task, and container level including CPU, memory, network, and storage metrics.
  • Amazon ElastiCache
    • Amazon ElastiCache sends data to CloudWatch every minute.
  • Amazon Elastic Block Store (EBS)
    • Amazon EBS sends data to CloudWatch every 5 minutes for gp2, st1, and sc1 volumes.
    • Provisioned IOPS SSD (io1 and io2) volumes automatically send one-minute metrics to CloudWatch.
    • gp3 volumes also send metrics at 1-minute intervals.
  • Amazon Elastic Compute Cloud (EC2)
    • Amazon EC2 sends data to CloudWatch every 5 minutes by default. For an additional charge, you can enable detailed monitoring for Amazon EC2, which sends data to CloudWatch every minute.
  • Elastic Load Balancing
    • Elastic Load Balancing sends data to CloudWatch every minute (applies to ALB, NLB, GLB, and Classic Load Balancer).
  • Amazon EMR (formerly Amazon Elastic MapReduce)
    • Amazon EMR sends basic data to CloudWatch every 5 minutes by default at no additional cost.
    • Starting with Amazon EMR Release 7.0+, the CloudWatch Agent can publish 34 enhanced metrics every minute (additional charges apply).
    • EMR Serverless sends metrics to CloudWatch every minute.
  • Amazon OpenSearch Service (formerly Amazon Elasticsearch Service)
    • Amazon OpenSearch Service sends data to CloudWatch every minute.
  • Amazon Kinesis Data Streams (formerly Amazon Kinesis Streams)
    • Amazon Kinesis Data Streams sends stream-level data to CloudWatch every minute.
    • Enhanced shard-level metrics (detailed monitoring) provide additional per-shard metrics.
  • Amazon Data Firehose (formerly Amazon Kinesis Data Firehose)
    • Amazon Data Firehose sends data to CloudWatch every minute.
  • AWS Lambda
    • AWS Lambda sends data to CloudWatch every minute.
    • Lambda Insights provides enhanced monitoring with system-level metrics (CPU, memory, network) at 1-minute intervals.
  • Amazon SageMaker AI
    • Amazon SageMaker AI (which replaced the legacy Amazon Machine Learning service) sends training, endpoint, and transform job metrics to CloudWatch every minute.
    • ⚠️ Note: The original Amazon Machine Learning service is no longer accepting new users. AWS recommends using Amazon SageMaker AI for machine learning workloads.
  • Amazon Redshift
    • Amazon Redshift sends data to CloudWatch every minute.
  • Amazon Relational Database Service (RDS)
    • Amazon RDS sends data to CloudWatch every minute.
    • CloudWatch Database Insights (launched Dec 2024) provides comprehensive database observability with fleet-level and instance-level dashboards.
  • Amazon Route 53
    • Amazon Route 53 sends data to CloudWatch every minute.
  • Amazon Simple Notification Service (SNS)
    • Amazon SNS sends data to CloudWatch every 5 minutes.
    • SNS does not support detailed (1-minute) monitoring.
  • Amazon Simple Queue Service (SQS)
    • Amazon SQS sends data to CloudWatch every 5 minutes.
  • Amazon Simple Storage Service (S3)
    • Amazon S3 sends storage metrics (bucket size, object count) to CloudWatch once a day (basic monitoring, free).
    • Request metrics (detailed monitoring) are available at 1-minute intervals and are billed as CloudWatch custom metrics.
    • 1-minute metrics are available at the bucket-level by default when request metrics are enabled.
  • Amazon Simple Workflow Service (SWF)
    • Amazon SWF sends data to CloudWatch every 5 minutes.
    • Note: AWS Step Functions is the recommended alternative for new workflow orchestration workloads.
  • AWS Storage Gateway
    • AWS Storage Gateway sends data to CloudWatch every 5 minutes.
  • AWS WAF
    • AWS WAF sends data to CloudWatch every minute.
  • Amazon WorkSpaces
    • Amazon WorkSpaces sends data to CloudWatch every 5 minutes.

⚠️ AWS OpsWorks – End of Life

AWS OpsWorks reached End of Life (EOL) on May 26, 2024. The service has been disabled for both new and existing customers. The OpsWorks console, API, CLI, and CloudFormation resources are no longer available.

Alternatives: AWS Systems Manager, AWS CodeDeploy, AWS CloudFormation

Additional Services Publishing CloudWatch Metrics (2024-2026)

The following additional AWS services publish metrics to CloudWatch (not in the original list):

  • Amazon API Gateway – Sends metrics every minute
  • AWS AppSync – Sends metrics every minute
  • Amazon EKS – Control plane metrics and Container Insights
  • Amazon Bedrock – Model invocation and throughput metrics
  • AWS Step Functions – Execution metrics every minute
  • Amazon Aurora – Database metrics every minute (with Database Insights)
  • AWS Fargate – Container-level metrics via Container Insights
  • Amazon MSK – Streaming metrics with per-broker/topic detail
  • AWS Network Firewall – Firewall metrics every minute
  • Amazon MemoryDB – Database metrics every minute

CloudWatch Enhanced Observability Features

  • Container Insights – Collects and aggregates metrics and logs from containerized applications on Amazon ECS, Amazon EKS, and Kubernetes. Provides cluster, node, pod, task, and service level metrics.
  • Lambda Insights – Enhanced monitoring for Lambda functions with system-level metrics (CPU, memory, network, disk).
  • Database Insights (Dec 2024) – Comprehensive database observability for Amazon RDS and Aurora with fleet-level health monitoring and instance-level SQL query analysis.
  • Application Signals (June 2024) – Application performance monitoring (APM) with pre-built dashboards showing volume, availability, latency, faults, and errors.
  • Internet Monitor – Near-continuous internet measurements for availability and performance, tailored to your workload footprint on AWS.
  • CloudWatch Investigations – AI-powered investigation of operational issues across services.

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 is the minimum time interval for the data that Amazon CloudWatch receives and aggregates?
    1. One second (High-resolution custom metrics support 1-second resolution)
    2. Five seconds
    3. One minute
    4. Three minutes
    5. Five minutes

    Note: The original answer was “One minute” which was correct for standard metrics. With high-resolution custom metrics (introduced 2017), CloudWatch supports 1-second resolution. Exam questions may still reference 1 minute as the minimum for AWS service metrics.

  2. In the ‘Detailed’ monitoring data available for your Amazon EBS volumes, Provisioned IOPS volumes automatically send _____ minute metrics to Amazon CloudWatch.
    1. 3
    2. 1
    3. 5
    4. 2
  3. Using Amazon CloudWatch’s Free Tier, what is the frequency of metric updates, which you receive?
    1. 5 minutes
    2. 500 milliseconds.
    3. 30 seconds
    4. 1 minute
  4. What is the type of monitoring data (for Amazon EBS volumes) which is available automatically in 5-minute periods at no charge called?
    1. Basic
    2. Primary
    3. Detailed
    4. Local
  5. A user has created an Auto Scaling group using CLI. The user wants to enable CloudWatch detailed monitoring for that group. How can the user configure this?
    1. When the user sets an alarm on the Auto Scaling group, it automatically enables detail monitoring
    2. By default detailed monitoring is enabled for Auto Scaling (Detailed monitoring is enabled when you create the launch configuration using the AWS CLI or an API)
    3. Auto Scaling does not support detailed monitoring
    4. Enable detail monitoring from the AWS console
  6. A user is trying to understand the detailed CloudWatch monitoring concept. Which of the below mentioned services provides detailed monitoring with CloudWatch without charging the user extra?
    1. AWS Auto Scaling
    2. AWS Route 53
    3. AWS EMR
    4. AWS SNS
  7. A user is trying to understand the detailed CloudWatch monitoring concept. Which of the below mentioned services does not provide detailed monitoring with CloudWatch?
    1. AWS EMR (EMR sends basic metrics every 5 minutes by default; enhanced monitoring at 1-minute intervals is available starting with EMR 7.0+ via CloudWatch Agent)
    2. AWS RDS
    3. AWS ELB
    4. AWS Route53
  8. A user has enabled detailed CloudWatch monitoring with the AWS Simple Notification Service. Which of the below mentioned statements helps the user understand detailed monitoring better?
    1. SNS will send data every minute after configuration
    2. There is no need to enable since SNS provides data every minute
    3. AWS CloudWatch does not support monitoring for SNS
    4. SNS cannot provide data every minute
  9. A user has configured an Auto Scaling group with ELB. The user has enabled detailed CloudWatch monitoring on Auto Scaling. Which of the below mentioned statements will help the user understand the functionality better?
    1. It is not possible to setup detailed monitoring for Auto Scaling
    2. In this case, Auto Scaling will send data every minute and will charge the user extra
    3. Detailed monitoring will send data every minute without additional charges
    4. Auto Scaling sends data every minute only and does not charge the user
  10. Which of the following CloudWatch monitoring features provides near real-time visibility into application performance with pre-built dashboards?
    1. CloudWatch Logs Insights
    2. CloudWatch Alarms
    3. CloudWatch Application Signals
    4. CloudWatch Contributor Insights
  11. What is the minimum resolution supported by CloudWatch high-resolution custom metrics?
    1. 5 seconds
    2. 10 seconds
    3. 30 seconds
    4. 1 second
  12. Which CloudWatch feature provides comprehensive database observability with fleet-level health monitoring for Amazon RDS and Aurora?
    1. CloudWatch Logs Insights
    2. Enhanced Monitoring
    3. Performance Insights
    4. CloudWatch Database Insights

References

AWS Storage Options – Whitepaper – Certification

~ Last updated on : ~ jayendrapatil ~ 58 Comments

AWS Storage Options – Whitepaper – Certification

📋 Whitepaper Archived

The original AWS Storage Options whitepaper has been archived by AWS. AWS now recommends referring to the Storage section in the AWS Overview whitepaper or the AWS Cloud Storage page for current storage guidance.

This content is maintained and updated for certification exam preparation as the core storage concepts and service selection patterns remain highly relevant.

AWS Storage Options is one of the most important topics for AWS Solution Architect Professional Certification exam and covers a brief summary of each AWS storage option, their ideal usage patterns, anti-patterns, performance, durability and availability, scalability etc.

Overview

  • AWS offers multiple cloud-based storage options. Each has a unique combination of performance, durability, availability, cost, and interface, as well as other characteristics such as scalability and elasticity
  • All storage options are ideally suited for some use cases and there are certain Anti-Patterns which should be taken into account while making a storage choice
  • AWS storage services now span object storage, block storage, file storage, archival storage, hybrid storage, data transfer, and backup services

AWS Various Storage Options

AWS Storage Services

Amazon S3 & S3 Glacier Storage Classes

More Details @ AWS Storage Options – S3 & Glacier

Key Updates (2024-2026):

  • S3 Glacier is now three separate storage classes:
    • S3 Glacier Instant Retrieval – millisecond retrieval for rarely accessed data
    • S3 Glacier Flexible Retrieval (formerly S3 Glacier) – minutes to hours retrieval
    • S3 Glacier Deep Archive – lowest cost, 12-48 hour retrieval
  • S3 Express One Zone (launched 2023) – up to 10x faster performance than S3 Standard, single-digit millisecond latency, designed for most frequently accessed data. Received up to 85% price reduction in 2025.
  • S3 Tables (launched Dec 2024) – fully managed Apache Iceberg tables optimized for analytics workloads with up to 3x faster query throughput
  • S3 Intelligent-Tiering – now includes Archive Instant Access, Archive Access, and Deep Archive Access tiers

Amazon Elastic Block Store (EBS) & Instance Store Volumes

More details @ AWS Storage Options – EBS & Instance Store

Amazon EFS (Elastic File System)

  • Fully managed, elastic NFS file system for Linux workloads
  • Supports machine learning, big data analytics, web serving, and content management
  • Scales automatically without provisioning or managing capacity
  • Offers Standard and Infrequent Access storage classes with lifecycle management

Amazon FSx Family

  • FSx for Windows File Server – fully managed Windows-native file system
  • FSx for Lustre – high-performance file system for compute-intensive workloads (new Elastic storage class launched 2025)
  • FSx for NetApp ONTAP – fully managed shared storage with NetApp ONTAP (2nd gen file systems in 2024)
  • FSx for OpenZFS – fully managed OpenZFS file system (Intelligent-Tiering storage class launched Dec 2024, saves up to 85%)

Amazon RDS, DynamoDB & Database on EC2

More details @ AWS Storage Options – RDS, DynamoDB & Database on EC2

Amazon SQS & Redshift

More details @ AWS Storage Options – SQS & Redshift

Amazon CloudFront & ElastiCache

More details @ AWS Storage Options – CloudFront & ElastiCache

AWS Storage Gateway

More details @ AWS Storage Options – Storage Gateway & Import/Export

Key Updates:

  • Storage Gateway continues to provide S3 File Gateway, Tape Gateway, and Volume Gateway
  • FSx File Gateway is no longer available to new customers (effective October 28, 2024). Existing customers should migrate to direct Amazon FSx for Windows File Server access.
  • All Storage Gateway appliances must migrate from Amazon Linux 2 to AL2023 for continued updates

AWS Data Transfer & Migration Services

⚠️ AWS Import/Export & Snow Family Updates:

  • AWS Import/Export (original disk-shipping service) – deprecated long ago, replaced by Snow Family
  • AWS Snowmobile – Retired in March 2024. Service is no longer available.
  • AWS Snowcone – Discontinued effective November 12, 2024. Support ended November 12, 2025.
  • AWS Snowball Edge – Only available to existing customers as of November 7, 2025. Not available to new customers.

Recommended Replacements:

  • AWS DataSync – for online data transfers (now supports cross-cloud transfers to Google Cloud, Azure, Oracle Cloud as of 2025)
  • AWS Data Transfer Terminal (launched Dec 2024) – secure physical locations where you bring your storage devices and connect directly to the AWS network for high-speed uploads to S3, EFS, and other services
  • AWS Outposts – for edge computing use cases previously served by Snow devices
  • AWS Partner solutions – for specialized migration needs

AWS Backup

  • Fully managed, centralized backup service that automates data protection across AWS services and hybrid workloads
  • Supports EC2, EBS, RDS, DynamoDB, EFS, FSx, S3, Storage Gateway, and Amazon EKS (added 2025)
  • Provides ransomware detection and recovery capabilities
  • Supports cross-Region and cross-account backup with AWS Organizations integration
  • Logically air-gapped vaults for additional protection
  • Policy-based backup plans with configurable frequency and retention

Deprecated Services Referenced in Exam Questions

⚠️ Amazon Elastic Transcoder – EOL November 13, 2025

Amazon Elastic Transcoder has been discontinued. AWS Elemental MediaConvert is the recommended replacement, offering better performance, more features, and lower pricing. Questions referencing Elastic Transcoder still appear on older exam versions but the correct architectural pattern (S3 + transcoding + CloudFront) remains valid using MediaConvert.

⚠️ Amazon SWF (Simple Workflow Service) – Superseded by Step Functions

While SWF remains available, AWS recommends Step Functions for all new applications. SWF still appears in exam questions but new designs should use Step Functions for workflow orchestration.

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 developing a highly available web application using stateless web servers. Which services are suitable for storing session state data? Choose 3 answers.
    1. Elastic Load Balancing
    2. Amazon Relational Database Service (RDS)
    3. Amazon CloudWatch
    4. Amazon ElastiCache
    5. Amazon DynamoDB
    6. AWS Storage Gateway
  2. Your firm has uploaded a large amount of aerial image data to S3. In the past, in your on-premises environment, you used a dedicated group of servers to oaten process this data and used Rabbit MQ, an open source messaging system, to get job information to the servers. Once processed the data would go to tape and be shipped offsite. Your manager told you to stay with the current design, and leverage AWS archival storage and messaging services to minimize cost. Which is correct? [PROFESSIONAL]
    1. Use SQS for passing job messages, use Cloud Watch alarms to terminate EC2 worker instances when they become idle. Once data is processed, change the storage class of the S3 objects to Reduced Redundancy Storage.
    2. Setup Auto-Scaled workers triggered by queue depth that use spot instances to process messages in SQS. Once data is processed, change the storage class of the S3 objects to Reduced Redundancy Storage.
    3. Setup Auto-Scaled workers triggered by queue depth that use spot instances to process messages in SQS. Once data is processed, change the storage class of the S3 objects to Glacier. (Now S3 Glacier Flexible Retrieval or S3 Glacier Deep Archive)
    4. Use SNS to pass job messages use Cloud Watch alarms to terminate spot worker instances when they become idle. Once data is processed, change the storage class of the S3 object to Glacier.
  3. You are developing a new mobile application and are considering storing user preferences in AWS, which would provide a more uniform cross-device experience to users using multiple mobile devices to access the application. The preference data for each user is estimated to be 50KB in size. Additionally 5 million customers are expected to use the application on a regular basis. The solution needs to be cost-effective, highly available, scalable and secure, how would you design a solution to meet the above requirements? [PROFESSIONAL]
    1. Setup an RDS MySQL instance in 2 availability zones to store the user preference data. Deploy a public facing application on a server in front of the database to manage security and access credentials
    2. Setup a DynamoDB table with an item for each user having the necessary attributes to hold the user preferences. The mobile application will query the user preferences directly from the DynamoDB table. Utilize STS. Web Identity Federation, and DynamoDB Fine Grained Access Control to authenticate and authorize access
    3. Setup an RDS MySQL instance with multiple read replicas in 2 availability zones to store the user preference data .The mobile application will query the user preferences from the read replicas. Leverage the MySQL user management and access privilege system to manage security and access credentials.
    4. Store the user preference data in S3 Setup a DynamoDB table with an item for each user and an item attribute pointing to the user’ S3 object. The mobile application will retrieve the S3 URL from DynamoDB and then access the S3 object directly utilize STS, Web identity Federation, and S3 ACLs to authenticate and authorize access.
  4. A company is building a voting system for a popular TV show, viewers would watch the performances then visit the show’s website to vote for their favorite performer. It is expected that in a short period of time after the show has finished the site will receive millions of visitors. The visitors will first login to the site using their Amazon.com credentials and then submit their vote. After the voting is completed the page will display the vote totals. The company needs to build the site such that can handle the rapid influx of traffic while maintaining good performance but also wants to keep costs to a minimum. Which of the design patterns below should they use? [PROFESSIONAL]
    1. Use CloudFront and an Elastic Load balancer in front of an auto-scaled set of web servers, the web servers will first can the Login With Amazon service to authenticate the user then process the users vote and store the result into a multi-AZ Relational Database Service instance.
    2. Use CloudFront and the static website hosting feature of S3 with the Javascript SDK to call the Login With Amazon service to authenticate the user, use IAM Roles to gain permissions to a DynamoDB table to store the users vote.
    3. Use CloudFront and an Elastic Load Balancer in front of an auto-scaled set of web servers, the web servers will first call the Login with Amazon service to authenticate the user, the web servers will process the users vote and store the result into a DynamoDB table using IAM Roles for EC2 instances to gain permissions to the DynamoDB table.
    4. Use CloudFront and an Elastic Load Balancer in front of an auto-scaled set of web servers, the web servers will first call the Login With Amazon service to authenticate the user, the web servers would process the users vote and store the result into an SQS queue using IAM Roles for EC2 Instances to gain permissions to the SQS queue. A set of application servers will then retrieve the items from the queue and store the result into a DynamoDB table
  5. A large real-estate brokerage is exploring the option to adding a cost-effective location-based alert to their existing mobile application. The application backend infrastructure currently runs on AWS. Users who opt in to this service will receive alerts on their mobile device regarding real-estate offers in proximity to their location. For the alerts to be relevant delivery time needs to be in the low minute count. The existing mobile app has 5 million users across the US. Which one of the following architectural suggestions would you make to the customer? [PROFESSIONAL]
    1. Mobile application will submit its location to a web service endpoint utilizing Elastic Load Balancing and EC2 instances. DynamoDB will be used to store and retrieve relevant offers. EC2 instances will communicate with mobile carriers/device providers to push alerts back to mobile application.
    2. Use AWS Direct Connect or VPN to establish connectivity with mobile carriers EC2 instances will receive the mobile applications location through carrier connection: RDS will be used to store and relevant offers. EC2 instances will communicate with mobile carriers to push alerts back to the mobile application
    3. Mobile application will send device location using SQS. EC2 instances will retrieve the relevant offers from DynamoDB. AWS Mobile Push will be used to send offers to the mobile application (Note: Amazon SNS Mobile Push is now the terminology for mobile push notifications)
    4. Mobile application will send device location using AWS Mobile Push. EC2 instances will retrieve the relevant offers from DynamoDB. EC2 instances will communicate with mobile carriers/device providers to push alerts back to the mobile application.
  6. You are running a news website in the eu-west-1 region that updates every 15 minutes. The website has a worldwide audience and it uses an Auto Scaling group behind an Elastic Load Balancer and an Amazon RDS database. Static content resides on Amazon S3, and is distributed through Amazon CloudFront. Your Auto Scaling group is set to trigger a scale up event at 60% CPU utilization; you use an Amazon RDS extra-large DB instance with 10.000 Provisioned IOPS its CPU utilization is around 80%. While freeable memory is in the 2 GB range. Web analytics reports show that the average load time of your web pages is around 1.5 to 2 seconds, but your SEO consultant wants to bring down the average load time to under 0.5 seconds. How would you improve page load times for your users? (Choose 3 answers) [PROFESSIONAL]
    1. Lower the scale up trigger of your Auto Scaling group to 30% so it scales more aggressively.
    2. Add an Amazon ElastiCache caching layer to your application for storing sessions and frequent DB queries
    3. Configure Amazon CloudFront dynamic content support to enable caching of re-usable content from your site
    4. Switch Amazon RDS database to the high memory extra-large Instance type
    5. Set up a second installation in another region, and use the Amazon Route 53 latency-based routing feature to select the right region.
  7. A read only news reporting site with a combined web and application tier and a database tier that receives large and unpredictable traffic demands must be able to respond to these traffic fluctuations automatically. What AWS services should be used meet these requirements? [PROFESSIONAL]
    1. Stateless instances for the web and application tier synchronized using ElastiCache Memcached in an autoscaling group monitored with CloudWatch. And RDS with read replicas.
    2. Stateful instances for the web and application tier in an autoscaling group monitored with CloudWatch and RDS with read replicas
    3. Stateful instances for the web and application tier in an autoscaling group monitored with CloudWatch. And multi-AZ RDS
    4. Stateless instances for the web and application tier synchronized using ElastiCache Memcached in an autoscaling group monitored with CloudWatch and multi-AZ RDS
  8. You have a periodic Image analysis application that gets some files as input, analyzes them and for each file writes some data in output to a ten file. The number of files in input per day is high and concentrated in a few hours of the day. Currently you have a server on EC2 with a large EBS volume that hosts the input data and the results it takes almost 20 hours per day to complete the process. What services could be used to reduce the elaboration time and improve the availability of the solution? [PROFESSIONAL]
    1. S3 to store I/O files. SQS to distribute elaboration commands to a group of hosts working in parallel. Auto scaling to dynamically size the group of hosts depending on the length of the SQS queue
    2. EBS with Provisioned IOPS (PIOPS) to store I/O files. SNS to distribute elaboration commands to a group of hosts working in parallel Auto Scaling to dynamically size the group of hosts depending on the number of SNS notifications
    3. S3 to store I/O files, SNS to distribute evaporation commands to a group of hosts working in parallel. Auto scaling to dynamically size the group of hosts depending on the number of SNS notifications
    4. EBS with Provisioned IOPS (PIOPS) to store I/O files SQS to distribute elaboration commands to a group of hosts working in parallel Auto Scaling to dynamically size the group to hosts depending on the length of the SQS queue.
  9. A 3-tier e-commerce web application is current deployed on-premises and will be migrated to AWS for greater scalability and elasticity. The web server currently shares read-only data using a network distributed file system The app server tier uses a clustering mechanism for discovery and shared session state that depends on IP multicast The database tier uses shared-storage clustering to provide database fail over capability, and uses several read slaves for scaling. Data on all servers and the distributed file system directory is backed up weekly to off-site tapes. Which AWS storage and database architecture meets the requirements of the application? [PROFESSIONAL]
    1. Web servers store read-only data in S3, and copy from S3 to root volume at boot time. App servers share state using a combination of DynamoDB and IP unicast. Database use RDS with multi-AZ deployment and one or more Read Replicas. Backup web and app servers backed up weekly via AMIs, database backed up via DB snapshots.
    2. Web servers store read-only data in S3, and copy from S3 to root volume at boot time. App servers share state using a combination of DynamoDB and IP unicast. Database use RDS with multi-AZ deployment and one or more Read replicas. Backup web servers app servers, and database backed up weekly to Glacier using snapshots (Snapshots to Glacier don’t work directly with EBS snapshots)
    3. Web servers store read-only data in S3 and copy from S3 to root volume at boot time. App servers share state using a combination of DynamoDB and IP unicast. Database use RDS with multi-AZ deployment. Backup web and app servers backed up weekly via AMIs. Database backed up via DB snapshots (Need Read replicas for scalability and elasticity)
    4. Web servers, store read-only data in an EC2 NFS server, mount to each web server at boot time App servers share state using a combination of DynamoDB and IP multicast Database use RDS with multi-AZ deployment and one or more Read Replicas Backup web and app servers backed up weekly via AMIs database backed up via DB snapshots (IP multicast not available in AWS)
  10. Our company is getting ready to do a major public announcement of a social media site on AWS. The website is running on EC2 instances deployed across multiple Availability Zones with a Multi-AZ RDS MySQL Extra Large DB Instance. The site performs a high number of small reads and writes per second and relies on an eventual consistency model. After comprehensive tests you discover that there is read contention on RDS MySQL. Which are the best approaches to meet these requirements? (Choose 2 answers) [PROFESSIONAL]
    1. Deploy ElastiCache in-memory cache running in each availability zone
    2. Implement sharding to distribute load to multiple RDS MySQL instances (Would distribute read write both, focus is on read contention)
    3. Increase the RDS MySQL Instance size and Implement provisioned IOPS (Would distribute read write both, focus is on read contention)
    4. Add an RDS MySQL read replica in each availability zone
  11. Run 2-tier app with the following: an ELB, three web app server on EC2, and 1 MySQL RDS db. With grown load, db queries take longer and longer and slow down the overall response time for user request. What Options could speed up performance? (Choose 3) [PROFESSIONAL]
    1. Create an RDS read-replica and redirect half of the database read request to it
    2. Cache database queries in Amazon ElastiCache
    3. Setup RDS in multi-availability zone mode.
    4. Shard the database and distribute loads between shards.
    5. Use Amazon CloudFront to cache database queries.
  12. You have a web application leveraging an Elastic Load Balancer (ELB) In front of the web servers deployed using an Auto Scaling Group Your database is running on Relational Database Service (RDS) The application serves out technical articles and responses to them in general there are more views of an article than there are responses to the article. On occasion, an article on the site becomes extremely popular resulting in significant traffic Increases that causes the site to go down. What could you do to help alleviate the pressure on the infrastructure while maintaining availability during these events? Choose 3 answers [PROFESSIONAL]
    1. Leverage CloudFront for the delivery of the articles.
    2. Add RDS read-replicas for the read traffic going to your relational database
    3. Leverage ElastiCache for caching the most frequently used data.
    4. Use SQS to queue up the requests for the technical posts and deliver them out of the queue (does not process and would not be real time)
    5. Use Route53 health checks to fail over to an S3 bucket for an error page (more of an error handling then availability)
  1. Your website is serving on-demand training videos to your workforce. Videos are uploaded monthly in high resolution MP4 format. Your workforce is distributed globally often on the move and using company-provided tablets that require the HTTP Live Streaming (HLS) protocol to watch a video. Your company has no video transcoding expertise and it required you might need to pay for a consultant. How do you implement the most cost-efficient architecture without compromising high availability and quality of video delivery? [PROFESSIONAL]
    1. AWS Elemental MediaConvert to transcode original high-resolution MP4 videos to HLS. S3 to host videos with Lifecycle Management to archive original files to S3 Glacier Flexible Retrieval after a few days. CloudFront to serve HLS transcoded videos from S3. (MediaConvert replaces Elastic Transcoder (EOL Nov 2025) for high quality transcoding. S3 to host videos cheaply, Glacier for archives and CloudFront for high availability)
    2. A video transcoding pipeline running on EC2 using SQS to distribute tasks and Auto Scaling to adjust the number of nodes depending on the length of the queue S3 to host videos with Lifecycle Management to archive all files to Glacier after a few days CloudFront to serve HLS transcoding videos from Glacier
    3. AWS Elemental MediaConvert to transcode original high-resolution MP4 videos to HLS EBS volumes to host videos and EBS snapshots to incrementally backup original files after a few days. CloudFront to serve HLS transcoded videos from EC2.
    4. A video transcoding pipeline running on EC2 using SQS to distribute tasks and Auto Scaling to adjust the number of nodes depending on the length of the queue. EBS volumes to host videos and EBS snapshots to incrementally backup original files after a few days. CloudFront to serve HLS transcoded videos from EC2

    Note: Original question referenced Elastic Transcoder which reached End of Life on November 13, 2025. AWS Elemental MediaConvert is the replacement service. The architectural pattern remains the same.

  2. To meet regulatory requirements, a pharmaceuticals company needs to archive data after a drug trial test is concluded. Each drug trial test may generate up to several thousands of files, with compressed file sizes ranging from 1 byte to 100MB. Once archived, data rarely needs to be restored, and on the rare occasion when restoration is needed, the company has 24 hours to restore specific files that match certain metadata. Searches must be possible by numeric file ID, drug name, participant names, date ranges, and other metadata. Which is the most cost-effective architectural approach that can meet the requirements? [PROFESSIONAL]
    1. Store individual files in Amazon S3 Glacier, using the file ID as the archive name. When restoring data, query the Amazon Glacier vault for files matching the search criteria. (Individual files are expensive and does not allow searching by participant names etc)
    2. Store individual files in Amazon S3, and store search metadata in an Amazon Relational Database Service (RDS) multi-AZ database. Create a lifecycle rule to move the data to Amazon S3 Glacier after a certain number of days. When restoring data, query the Amazon RDS database for files matching the search criteria, and move the files matching the search criteria back to S3 Standard class. (As the data is not needed can be stored to Glacier directly and the data need not be moved back to S3 standard)
    3. Store individual files in Amazon S3 Glacier, and store the search metadata in an Amazon RDS multi-AZ database. When restoring data, query the Amazon RDS database for files matching the search criteria, and retrieve the archive name that matches the file ID returned from the database query. (Individual files and Multi-AZ is expensive)
    4. First, compress and then concatenate all files for a completed drug trial test into a single Amazon S3 Glacier archive. Store the associated byte ranges for the compressed files along with other search metadata in an Amazon RDS database with regular snapshotting. When restoring data, query the database for files that match the search criteria, and create restored files from the retrieved byte ranges.
    5. Store individual compressed files and search metadata in Amazon Simple Storage Service (S3). Create a lifecycle rule to move the data to Amazon S3 Glacier, after a certain number of days. When restoring data, query the Amazon S3 bucket for files matching the search criteria, and retrieve the file to S3 reduced redundancy in order to move it back to S3 Standard class. (Once the data is moved from S3 to Glacier the metadata is lost, as Glacier does not have metadata and must be maintained externally. Also S3 Reduced Redundancy Storage is no longer recommended.)
  3. A document storage company is deploying their application to AWS and changing their business model to support both free tier and premium tier users. The premium tier users will be allowed to store up to 200GB of data and free tier customers will be allowed to store only 5GB. The customer expects that billions of files will be stored. All users need to be alerted when approaching 75 percent quota utilization and again at 90 percent quota use. To support the free tier and premium tier users, how should they architect their application? [PROFESSIONAL]
    1. The company should utilize an Amazon Simple Workflow Service activity worker that updates the users data counter in Amazon DynamoDB. The activity worker will use Simple Email Service to send an email if the counter increases above the appropriate thresholds. (Note: For new implementations, AWS Step Functions with DynamoDB and SES would be the modern approach)
    2. The company should deploy an Amazon Relational Database Service relational database with a store objects table that has a row for each stored object along with size of each object. The upload server will query the aggregate consumption of the user in question by first determining the files stored by the user, and then querying the stored objects table for respective file sizes and send an email via Amazon Simple Email Service if the thresholds are breached.
    3. The company should write both the content length and the username of the files owner as S3 metadata for the object. They should then create a file watcher to iterate over each object and aggregate the size for each user and send a notification via Amazon Simple Queue Service to an emailing service if the storage threshold is exceeded.
    4. The company should create two separated Amazon Simple Storage Service buckets one for data storage for free tier users and another for data storage for premium tier users. An Amazon Simple Workflow Service activity worker will query all objects for a given user based on the bucket the data is stored
  4. Your company has been contracted to develop and operate a website that tracks NBA basketball statistics. Statistical data to derive reports like “best game-winning shots from the regular season” and more frequently built reports like “top shots of the game” need to be stored durably for repeated lookup. Leveraging social media techniques, NBA fans submit and vote on new report types from the existing data set so the system needs to accommodate variability in data queries and new static reports must be generated and posted daily. Initial research in the design phase indicates that there will be over 3 million report queries on game day by end users and other applications that use this application as a data source. It is expected that this system will gain in popularity over time and reach peaks of 10-15 million report queries of the system on game days. Select the answer that will allow your application to best meet these requirements while minimizing costs. [PROFESSIONAL]
    1. Launch a multi-AZ MySQL Amazon Relational Database Service (RDS) Read Replica connected to your multi AZ master database and generate reports by querying the Read Replica. Perform a daily table cleanup.
    2. Implement a multi-AZ MySQL RDS deployment and have the application generate reports from Amazon ElastiCache for in-memory performance results. Utilize the default expire parameter for items in the cache.
    3. Generate reports from a multi-AZ MySQL Amazon RDS deployment and have an offline task put reports in Amazon Simple Storage Service (S3) and use CloudFront to cache the content. Use a TTL to expire objects daily. (Offline task with S3 storage and CloudFront cache)
    4. Query a multi-AZ MySQL RDS instance and store the results in a DynamoDB table. Generate reports from the DynamoDB table. Remove stale tables daily.

References

AWS Storage Options – SQS & Redshift

~ Last updated on : ~ jayendrapatil ~ 13 Comments

SQS

  • is a fully managed message queuing service that provides a reliable, highly scalable, hosted queue for temporary storage and delivery of messages up to 1 MiB in size (increased from 256 KB in August 2025).
  • supports a virtually unlimited number of queues and supports two queue types:
    • Standard queues – unordered, at-least-once delivery with nearly unlimited throughput.
    • FIFO queues – exactly-once processing with strict message ordering, supporting up to 70,000 messages per second with high throughput mode.

Ideal Usage Patterns

  • is ideally suited to any scenario where multiple application components must communicate and coordinate their work in a loosely coupled manner particularly producer consumer scenarios.
  • can be used to coordinate a multi-step processing pipeline, where each message is associated with a task that must be processed.
  • enables the number of worker instances to scale up or down, and also enable the processing power of each single worker instance to scale up or down, to suit the total workload, without any application changes.
  • ideal for multi-tenant workloads using fair queues (launched July 2025) to mitigate noisy neighbor impact and ensure consistent processing across tenants.
  • supports event-driven architectures with AWS Lambda event source mapping, including provisioned mode for 3x faster scaling and 16x higher concurrency.

Anti-Patterns

  • Binary or Large Messages
    • SQS supports messages up to 1 MiB. If the application requires binary or messages exceeding this limit, it is best to use the Amazon SQS Extended Client Library with Amazon S3 to store the payload and SQS to store the pointer.
  • Long Term storage
    • SQS stores messages for max 14 days and if application requires storage period longer than 14 days, Amazon S3 or other storage options should be preferred.
  • High-speed message queuing or very short tasks
    • If the application requires a very high-speed message send and receive response from a single producer or consumer, use of Amazon DynamoDB or a message-queuing system hosted on Amazon EC2 may be more appropriate.

Performance

  • is a distributed queuing system that is optimized for horizontal scalability, not for single-threaded sending or receiving speeds.
  • Standard queues support nearly unlimited throughput (thousands of transactions per second per API action).
  • FIFO queues support up to 3,000 messages per second with batching by default, or up to 70,000 messages per second (700,000 with batching) in high throughput mode in select regions.
  • FIFO queues support up to 120,000 in-flight messages (increased from 20,000 in November 2024).
  • Higher receive performance can be achieved by requesting multiple messages (up to 10) in a single call.
  • Fair queues (July 2025) automatically reorder messages to maintain consistent dwell time across tenants, preventing noisy neighbors from impacting processing latency.

Durability & Availability

  • are highly durable but temporary.
  • stores all messages redundantly across multiple servers and data centers.
  • Message retention time is configurable on a per-queue basis, from a minimum of one minute to a maximum of 14 days.
  • Messages are retained in a queue until they are explicitly deleted, or until they are automatically deleted upon expiration of the retention time.
  • supports dead-letter queues (DLQ) for isolating messages that fail processing, with DLQ redrive capability to move messages back to the source queue or a custom destination for reprocessing.

Cost Model

  • pricing is based on
    • number of requests (per million requests)
    • the amount of data transferred out (priced per GB per month)
    • First 1 million requests per month are free (Free Tier)

Scalability & Elasticity

  • is both highly elastic and massively scalable.
  • is designed to enable a virtually unlimited number of computers to read and write a virtually unlimited number of messages at any time.
  • supports virtually unlimited numbers of queues and messages per queue for any user.
  • supports dual-stack (IPv4 and IPv6) endpoints for flexible network access.

Key Features (Recent Updates)

  • Message payload size increased to 1 MiB (August 2025) – supports larger messages for both standard and FIFO queues without needing the Extended Client Library.
  • Fair queues (July 2025) – automatically mitigates noisy neighbor impact in multi-tenant standard queues by reordering messages to maintain consistent dwell time across tenants.
  • FIFO high throughput mode – up to 70,000 TPS per API action (November 2023), enabling 700,000 messages per second with batching.
  • FIFO in-flight limit increase (November 2024) – increased from 20,000 to 120,000 in-flight messages per FIFO queue.
  • Lambda provisioned mode for SQS (January 2025) – dedicated polling resources providing 3x faster scaling and 16x higher concurrency for event source mapping.
  • Dead-letter queue redrive – move failed messages from DLQ back to source queue or a custom destination for both standard and FIFO queues.
  • Simplified KMS permissions – SendMessage no longer requires kms:Decrypt permission; only kms:GenerateDataKey is needed.
  • Temporary queues – application-managed virtual queues for request-response patterns that reduce cost and development time.

Amazon Redshift

  • is a fast, fully-managed, petabyte-scale data warehouse service that makes it simple and cost-effective to efficiently analyze all data using existing business intelligence tools.
  • is optimized for datasets that range from a few hundred gigabytes to a petabyte or more.
  • manages the work needed to set up, operate, and scale a data warehouse, from provisioning the infrastructure capacity to automating ongoing administrative tasks such as backups and patching.
  • offers two deployment models: Provisioned clusters (RA3 and new RG instances) and Redshift Serverless (pay-per-use with automatic scaling).
⚠️ Important: Amazon Redshift DC2 instances reached End of Life on April 24, 2026. New DC2 clusters cannot be created since May 15, 2025. Migrate to RA3 instances, RG instances (Graviton-powered, GA May 2026), or Redshift Serverless. DS2 instances were previously deprecated in favor of RA3.

Ideal Usage Pattern

  • is ideal for analyzing large datasets using existing business intelligence tools.
  • Common use cases include
    • Analyze global sales data for multiple products
    • Store historical stock trade data
    • Analyze ad impressions and clicks
    • Aggregate gaming data
    • Analyze social trends
    • Measure clinical quality, operation efficiency, and financial performance in the health care space
    • Near real-time analytics using zero-ETL integrations from Aurora, DynamoDB, RDS, and SaaS applications
    • Data lakehouse analytics querying data in S3 data lakes using Redshift Spectrum
    • Generative AI applications using Amazon Bedrock integration for sentiment analysis, text generation, and summarization directly on warehouse data

Anti-Pattern

  • OLTP workloads
    • Redshift is a column-oriented database and more suited for data warehousing and analytics. If application involves online transaction processing, Amazon RDS or Aurora would be a better choice.
  • Blob data
    • For Blob storage, Amazon S3 would be a better choice with metadata in other storage as RDS or DynamoDB.

Performance

  • Amazon Redshift allows very high query performance on datasets ranging in size from hundreds of gigabytes to a petabyte or more.
  • It uses columnar storage, data compression, and zone maps to reduce the amount of I/O needed to perform queries.
  • It has a massively parallel processing (MPP) architecture that parallelizes and distributes SQL operations to take advantage of all available resources.
  • Underlying hardware is designed for high performance data processing that uses local attached storage to maximize throughput.
  • New RG instances (GA May 2026) powered by AWS Graviton deliver up to 2.4x faster performance than RA3 at 30% lower price per vCPU.
  • AI-driven scaling and optimization in Redshift Serverless automatically provisions and scales capacity for demanding workloads.
  • Query performance improvements (March 2026) speed up new queries in BI dashboards and ETL workloads by up to 7x.
  • Concurrency scaling automatically adds additional cluster capacity to handle burst read and write workloads, with support for data ingestion (COPY queries in Parquet/ORC from S3).

Durability & Availability

  • Amazon Redshift stores three copies of your data—all data written to a node in your cluster is automatically replicated to other nodes within the cluster, and all data is continuously backed up to Amazon S3.
  • Snapshots are automated, incremental, and continuous and stored for a user-defined period (1-35 days).
  • Manual snapshots can be created and are retained until explicitly deleted.
  • Amazon Redshift continuously monitors the health of the cluster and automatically re-replicates data from failed drives and replaces nodes as necessary.
  • Multi-AZ deployments (GA for RA3 clusters) run your data warehouse across two Availability Zones simultaneously, providing continued operation during AZ failure scenarios.

Cost Model

  • Provisioned clusters pricing:
    • Compute node hours – total hours run across all compute nodes (RA3 or RG instances)
    • Redshift Managed Storage (RMS) – billed per GB/month, separate from compute (RA3/RG only)
    • Backup storage – for automated and manual snapshots beyond the free tier
    • Data transfer – standard AWS data transfer charges apply
    • Concurrency scaling – free for 1 hour per day per cluster, then per-second billing
    • Spectrum – per TB of data scanned in S3
  • Redshift Serverless pricing:
    • Compute – per RPU-hour (Redshift Processing Unit), billed per second with no charge when idle
    • Storage – per GB/month for managed storage
  • Reserved Instance pricing available for provisioned clusters (1-year or 3-year terms) for significant discounts.

Scalability & Elasticity

  • Provisioned clusters – Elastic resize allows adding or removing nodes within minutes. Classic resize available for node type changes.
  • Redshift Serverless – automatically scales compute capacity up and down based on workload demands with no cluster management required.
  • Data sharing allows securely sharing live, transactionally consistent data across Redshift clusters (cross-account, cross-region) without copying data.
  • Multi-warehouse writes through data sharing (GA November 2024) enable using different warehouses of different types and sizes for ETL workloads.

Key Features (Recent Updates)

  • RG Instances (GA May 2026) – New Graviton-powered instance family delivering 2.4x faster performance than RA3 at 30% lower price per vCPU.
  • DC2 End of Life (April 24, 2026) – Migrate to RA3, RG, or Serverless. New DC2 cluster creation blocked since May 15, 2025.
  • Redshift Serverless – Pay-per-use model with automatic scaling, AI-driven optimization, and per-second billing with no charge when idle.
  • Zero-ETL integrations – Near real-time data replication from Aurora, DynamoDB, RDS, and self-managed databases to Redshift without building ETL pipelines. Also supports SaaS sources (Salesforce, SAP, Zendesk).
  • Multi-AZ deployments – Run RA3 provisioned clusters across two Availability Zones for high availability.
  • Amazon Bedrock integration (October 2024) – Run generative AI tasks (text generation, sentiment analysis, summarization, classification) directly on Redshift data using foundation models via SQL.
  • Amazon Q generative SQL – Generate SQL from natural language prompts in the Redshift Query Editor.
  • Data sharing – Share live data across clusters, accounts, and regions without data movement. Supports multi-warehouse writes for ETL.
  • Redshift Spectrum – Query exabytes of data in S3 without loading it into Redshift, enabling data lakehouse architectures.
  • Concurrency scaling for ingestion (2026) – Automatically scales for COPY queries in Parquet/ORC formats from S3 during traffic spikes.
  • 7x query performance improvement (March 2026) – Faster response for BI dashboards, ETL pipelines, and near real-time analytics.

AWS Storage Options – CloudFront & ElastiCache

~ Last updated on : ~ jayendrapatil

Amazon CloudFront

  • is a webservice for content delivery
  • provides low latency by caching and delivering content from a global network of 750+ Points of Presence (PoPs) across 100+ cities in 50+ countries
  • supports HTTP/HTTPS for static and dynamic content delivery
  • optimized to work with Amazon services like S3, ELB, MediaConvert etc. as well as works seamlessly with any non-AWS origin server
⚠️ Note: CloudFront RTMP distributions were discontinued on December 31, 2020. For streaming, use HTTP-based streaming protocols (HLS, DASH) with CloudFront web distributions and AWS Elemental MediaConvert.

Ideal Usage Patterns

  • is ideal for distribution of frequently accessed static content, or dynamic content or for streaming audio or video that benefits from edge delivery
  • API acceleration and real-time content personalization at the edge
  • security at the edge with integrated WAF, DDoS protection, and bot management

Anti-Pattern

  • Infrequently accessed data
    • If the data is infrequently accessed, it would be better to serve the data from the Origin server
  • Programmatic cache invalidation
    • CloudFront supports cache invalidation, however AWS recommends using object versioning rather than programmatic cache invalidation.

Performance

  • is designed for low latency and high bandwidth delivery of content by redirecting the user to the nearest edge location in terms of latency and caching the content preventing the round trip to the origin server
  • supports HTTP/2 and HTTP/3 (QUIC) for improved connection performance

Durability & Availability

  • provides high Availability by delivering content from a distributed global network of edge locations. Amazon also constantly monitors the network paths connecting Origin servers to CloudFront
  • does not provide durable storage, which is more of the responsibility of the underlying Origin server providing the content for e.g. S3

Cost Model

  • has pay-as-you-go pricing with two main components:
    • regional data transfer out (per GB) and
    • requests (per 10,000)
  • Flat-Rate Pricing Plans (launched Nov 2025) — combine CloudFront CDN, AWS WAF, DDoS protection, bot management, Route 53 DNS, CloudWatch Logs, edge compute, and S3 storage credits into one monthly price with no overage charges

Scalability & Elasticity

  • provides seamless scalability & elasticity by automatically responding to the increase or the decrease in the demand

Edge Compute

  • CloudFront Functions — lightweight functions for high-scale, latency-sensitive request/response transformations (URL rewrites, header manipulation, redirects) executed at 750+ PoPs
  • Lambda@Edge — more powerful compute triggered at regional edge caches for complex logic (authentication, dynamic origin selection, content generation)
  • CloudFront KeyValueStore (launched 2023) — globally distributed, low-latency data store for CloudFront Functions enabling dynamic configuration (A/B testing, feature flags, geo-routing) without code redeployment

Security

  • Origin Access Control (OAC) — recommended method to restrict S3 origin access to CloudFront only, replacing the legacy Origin Access Identity (OAI). OAI creation was deprecated in 2024; new distributions since March 2026 can only use OAC.
  • AWS Shield Standard — included automatically with every CloudFront distribution for DDoS protection at no extra cost
  • AWS WAF integration — protect against web exploits and bots at the edge
  • Field-Level Encryption — encrypt sensitive data fields at the edge before forwarding to origin

ElastiCache

  • is a fully managed, serverless caching service that makes it easy to deploy, operate, and scale distributed in-memory caches in the cloud
  • helps improves performance of the applications by allowing retrieval of data from fast, managed, in-memory caching system with microsecond latency and up to 99.99% availability SLA
  • supports three open-source caching engines:
    • Valkey (recommended for new workloads) — open-source fork of Redis OSS 7.2, stewarded by the Linux Foundation (BSD-3 licensed)
    • Memcached — simple object caching engine
    • Redis OSS — key-value store (note: Redis OSS 7.2 is the last fully open-source Redis version)
🆕 Valkey Engine (Oct 2024): AWS recommends Valkey for new workloads. It provides 33% lower Serverless pricing and 20% lower node-based pricing compared to Redis OSS, with better performance and active open-source development. Valkey is a drop-in replacement for Redis OSS 7.2 and can be upgraded in-place.

Deployment Modes

  • ElastiCache Serverless (launched Nov 2023)
    • zero infrastructure management with instant auto-scaling
    • pay-per-use pricing based on data stored (GB-hour) and ElastiCache Processing Units (ECPUs)
    • creates a cache in under a minute; starts as low as $6/month with Valkey
    • zero downtime maintenance
  • Node-based (self-designed clusters)
    • fine-grained control over node type, count, and placement
    • supports Reserved Nodes for cost savings
    • Graviton3-based nodes available for better price-performance

Ideal Usage Patterns

  • improving application performance by storing critical data in-memory for low latency access
  • use cases involve usage as a database front end for read heavy applications, improving performance and reducing load on databases, or managing user session data, cache dynamically generated pages, or compute intensive calculations etc.
  • Real-time search (2026) — full-text, exact-match, numeric range, and hybrid search with microsecond latency
  • Vector similarity search — AI-driven semantic retrieval for RAG and recommendation systems

Anti-Patterns

  • Persistent Data
    • If the application needs fast access to data coupled with strong data durability, Amazon DynamoDB would be a better option
    • Note: ElastiCache for Valkey now supports durability with Multi-AZ transactional log (June 2026), enabling fast failover and data recovery without data loss

Performance

  • provides microsecond read latency and single-digit millisecond write latency with throughput up to millions of requests per second
  • Valkey 9.0 (May 2026) introduces enhanced search capabilities with full-text, hybrid, and aggregation queries directly in the cache

Durability & Availability

  • provides up to 99.99% availability SLA with Multi-AZ deployments
  • With the Memcached engine
    • all ElastiCache nodes in a single cache cluster are provisioned in a single Availability Zone.
    • ElastiCache automatically monitors the health of your cache nodes and replaces them in the event of network partitioning, host hardware, or software failure.
    • In the event of cache node failure, the cluster remains available, but performance may be reduced due to time needed to repopulate the cache in the new “cold” cache nodes.
    • To provide enhanced fault-tolerance for Availability Zone failures or cold-cache effects, you can run redundant cache clusters in different Availability Zones.
  • With the Valkey/Redis OSS engine,
    • ElastiCache supports replication to up to five read replicas for scaling. To improve availability, you can place read replicas in other Availability Zones.
    • ElastiCache monitors the primary node, and if the node becomes unavailable, ElastiCache will repair or replace the primary node if possible, using the same DNS name.
    • If the primary cache node recovery fails or its Availability Zone is unavailable, primary node can be failed over to one of the read replicas with an API call.
    • Durability support (June 2026): Multi-AZ transactional log enables data persistence across AZs, preventing data loss during failover, recovery, and node restarts.

Cost Model

  • offers two pricing models:
    • Serverless: pay-per-use based on data stored (GB-hour) and ECPUs consumed. Valkey Serverless is 33% cheaper than Redis OSS Serverless.
    • Node-based: pricing per cache node-hour consumed. Supports Reserved Nodes for up to 55% savings.

Scalability & Elasticity

  • ElastiCache is highly scalable and elastic.
  • Serverless: instantly auto-scales to match application demand with no capacity planning
  • Node-based: Cache nodes can be added or deleted from the cache cluster. Auto Discovery enables automatic discovery of Memcached cache nodes by ElastiCache Clients when the nodes are added to or removed from an ElastiCache cluster.

 

Storage Options Whitepaper – Storage Gateway – Import/Export – AWS Certification

~ Last updated on : ~ jayendrapatil ~ 8 Comments

AWS Storage Options – Storage Gateway & Import/Export (Snow Family)

Provides a brief summary for the Ideal Use cases and Anti-Patterns for AWS Storage Gateway and AWS Snow Family (formerly Import/Export) storage options.

📌 2025/2026 Update: This post has been significantly updated to reflect current AWS service terminology and availability:

  • Storage Gateway now offers four gateway types: S3 File Gateway, FSx File Gateway (no longer available to new customers), Volume Gateway, and Tape Gateway.
  • AWS Import/Export was replaced by AWS Snowball (2015), and the Snow Family is being significantly reduced — Snowmobile retired (March 2024), Snowcone discontinued (Nov 2024), and Snowball Edge restricted to existing customers only (Nov 2025).
  • AWS Data Transfer Terminal is the new physical data transfer alternative for new customers.

AWS Storage Gateway

  • AWS Storage Gateway is a hybrid cloud storage service that provides on-premises access to virtually unlimited cloud storage.
  • Storage Gateway provides a standard set of storage protocols such as iSCSI, SMB, and NFS, which allow you to use AWS storage without rewriting existing applications.
  • It provides low-latency performance by maintaining frequently accessed data on-premises while securely storing all data encrypted in AWS.
  • For disaster recovery scenarios, it can serve as a cloud-hosted solution, together with EC2, that mirrors the entire production environment.
  • Storage Gateway can be deployed as a virtual machine (VM) within VMware, Hyper-V, or Linux KVM virtual environments, or as an Amazon EC2 instance within a VPC, or on a dedicated hardware appliance.
  • Storage Gateway offers four gateway types:
    • Amazon S3 File Gateway
      • Presents Amazon S3 objects as files accessible via NFS or SMB protocols.
      • On-premises applications read and write files to the gateway, which stores them as objects in S3 buckets.
      • Maintains a local cache of recently accessed files for low-latency retrieval.
      • Supports S3 Standard, S3 Intelligent-Tiering, S3 Standard-IA, and S3 One Zone-IA storage classes.
    • Amazon FSx File Gateway
      • Provides low-latency, on-premises access to fully managed Windows file shares in Amazon FSx for Windows File Server.
      • ⚠️ No longer available to new customers as of October 28, 2024. Existing customers can continue using the service. AWS recommends connecting directly to Amazon FSx for Windows File Server as an alternative.
    • Volume Gateway
      • Presents cloud-backed iSCSI block storage volumes to on-premises applications.
      • Operates in two modes:
        • Cached volumes (formerly Gateway-cached volumes) – Primary data stored in S3, with frequently accessed data retained locally in a cache. Minimizes the need to scale on-premises storage while providing low-latency access to frequently accessed data.
        • Stored volumes (formerly Gateway-stored volumes) – Complete primary data stored locally, while asynchronously backing up data to AWS as EBS snapshots. Provides low-latency access to entire datasets with durable, off-site backups.
      • Cached volumes can be up to 32 TiB; stored volumes can be up to 16 TiB.
    • Tape Gateway
      • Presents a virtual tape library (VTL) interface to existing backup applications using iSCSI.
      • Virtual tapes are stored in S3, and archived tapes are stored in S3 Glacier or S3 Glacier Deep Archive.
      • Compatible with leading backup software (Veeam, Veritas NetBackup, Commvault, etc.).

Ideal Usage Patterns

  • AWS Storage Gateway use cases include
    • Corporate file sharing and collaboration (S3 File Gateway)
    • Enabling on-premises backup applications to store primary backups in S3 (Volume Gateway, Tape Gateway)
    • Disaster recovery with cloud-backed storage
    • Data mirroring to cloud-based compute resources
    • Tiering on-premises data to cloud storage

Anti-Patterns

  • Database storage
    • For Database backup or storage, EC2 instances using EBS volumes or managed database services (RDS, Aurora) are better choices.

Performance

  • Performance depends on the speed and configuration of underlying local disks, network bandwidth between the iSCSI initiator and gateway VM, amount of local storage allocated to the gateway VM, and bandwidth between the gateway VM and AWS.
  • For cached volumes, providing enough local cache storage for recently accessed data is important for low-latency read access.
  • Storage Gateway efficiently uses Internet bandwidth by only uploading incremental changes (data that has changed), minimizing data sent over the Internet.
  • AWS Direct Connect can be used to increase throughput and reduce network costs by establishing a dedicated network connection between the on-premises gateway and AWS.
  • Storage Gateway supports bandwidth throttling to control the amount of network bandwidth used for data transfer.

Durability and Availability

  • AWS Storage Gateway durably stores on-premises application data by uploading it to S3.
  • S3 stores data across multiple facilities and on multiple devices within each facility, providing 99.999999999% (11 9s) durability.
  • S3 performs regular, systematic data integrity checks and is built to be automatically self-healing.

Cost Model

  • AWS Storage Gateway pricing components vary by gateway type:
    • S3 File Gateway: Storage (S3 pricing), requests, and data transfer
    • Volume Gateway: Volume storage usage (per GB per month), snapshot storage, and data transfer
    • Tape Gateway: Virtual tape storage, virtual tape shelf (archive) storage, and data retrieval
    • All types: No charge for the gateway software; charges apply for AWS storage used

Scalability and Elasticity

  • Storage Gateway stores data in Amazon S3, which provides virtually unlimited scalability and elasticity.
  • A single gateway supports up to 32 cached volumes (max 1,024 TiB total) or 32 stored volumes (max 512 TiB total).

Interfaces

  • AWS Management Console, AWS CLI, and AWS SDKs can be used to manage Storage Gateway.
  • Gateway VM images are available for VMware ESXi, Microsoft Hyper-V, and Linux KVM.
  • Hardware appliance option is available for environments without virtualization infrastructure.
  • Volumes are attached as iSCSI devices; file shares are accessible via NFS or SMB protocols.

AL2 to AL2023 Migration (2025-2026)

  • AWS is transitioning Storage Gateway appliance OS from Amazon Linux 2 to AL2023.
  • This migration enables new hybrid cloud storage features and maintains optimal performance and security.
  • Gateway versions 1.x.x cannot be updated to 2.x.x — a new gateway deployment is required.

AWS Import/Export (Replaced by AWS Snow Family)

⚠️ SERVICE DEPRECATED & SIGNIFICANTLY REDUCED

AWS Import/Export (the original ship-your-own-disk service) was fully replaced by AWS Snowball in 2015.

AWS Snow Family Current Status (2025):

  • AWS Snowmobile — Retired (March 2024). Service is no longer available.
  • AWS Snowcone (HDD & SSD) — Discontinued November 12, 2024. Support for existing customers ended November 12, 2025.
  • Previous generation Snowball devices (80TB Storage Optimized, 52 vCPU Compute Optimized, Compute Optimized with GPU) — Discontinued November 12, 2024.
  • AWS Snowball Edge (latest generation) — Only available to existing customers as of November 7, 2025. New customers cannot order Snowball Edge devices.

Alternatives for New Customers:

  • AWS DataSync — For online data transfers when network bandwidth is available
  • AWS Data Transfer Terminal — For secure physical data transfers at AWS-managed locations
  • AWS Partner solutions — Third-party data migration services

AWS Snow Family (Current Service)

  • AWS Snow Family provides secure, rugged devices for edge computing and offline data transfer.
  • AWS Snowball Edge is the primary device, available in two options:
    • Snowball Edge Storage Optimized (210 TB) — Primary device for large data transfers with high storage capacity and faster transfer speeds.
    • Snowball Edge Compute Optimized — For edge computing workloads requiring local processing power.
  • Data encryption is performed on the device itself, enabling higher data throughput and shorter transfer times.
  • Supports Amazon S3 compatible storage on the device for edge workloads.

AWS Data Transfer Terminal (New Alternative)

  • AWS Data Transfer Terminal is a secure, physical location where customers bring their storage devices to transfer data using a high-throughput connection directly to AWS.
  • Provides direct network connectivity to AWS services including Amazon S3, Amazon EFS, and others.
  • Available in multiple locations globally (New York, Los Angeles, San Francisco Bay Area, Munich, and more being added).
  • Customers reserve a date and time, visit the location, connect their storage devices, and transfer data.
  • No device shipping required — eliminates wait times associated with Snowball device logistics.
  • Ideal for customers who need frequent, high-volume physical data transfers.

Original AWS Import/Export (Historical Reference)

  • AWS Import/Export (now fully replaced) accelerated moving large amounts of data into and out of AWS using portable storage devices for transport.
  • AWS transferred data directly onto and off of storage devices using Amazon’s high-speed internal network, bypassing the Internet.
  • Supported importing into EBS snapshots, S3 buckets, and Glacier vaults, and exporting data from S3.

Ideal Usage Patterns (Snow Family / Data Transfer Terminal)

  • Ideal for transferring large amounts of data in and out of the AWS cloud, especially in cases where transferring the data over the Internet would be too slow (a week or more) or too costly.
  • Common use cases include:
    • Initial data migration to AWS (large-scale lift-and-shift)
    • Content distribution or regular data interchange with customers/business associates
    • Transfer to Amazon S3 for off-site backup and archival storage
    • Edge computing in disconnected environments (Snowball Edge only)
    • Disaster recovery with rapid data retrieval

Anti-Patterns

  • Data that is more easily transferred over the Internet in less than one week — use AWS DataSync or AWS Transfer Family instead.
  • For new customers needing physical data transfer (post Nov 2025) — use AWS Data Transfer Terminal or AWS Partner solutions.

Performance

  • Snowball Edge Storage Optimized 210TB devices provide up to 100 Gbps network connectivity.
  • Data transfer rate is bounded by the read/write speed of the storage device and network connectivity.
  • AWS Data Transfer Terminal provides high-throughput direct connections for fast transfers.

Durability and Availability

  • Durability and availability characteristics of the target storage (S3, EBS, EFS) apply after data has been imported.
  • Snowball Edge devices use 256-bit encryption and tamper-resistant enclosures for data security during transit.

Cost Model

  • AWS Snowball Edge pricing includes: service fee per job, shipping costs, and per-day charges for device use beyond included days.
  • Standard Amazon S3, EBS, and other storage pricing applies for the destination storage.
  • AWS Data Transfer Terminal pricing is based on reservation time and data transferred.

Scalability and Elasticity

  • Multiple Snowball Edge devices can be used in parallel for petabyte-scale transfers.
  • Large Data Migration Manager available in the AWS Console for managing multi-device migration projects.
  • For Amazon S3, individual objects may range up to 5 terabytes in size.
  • Aggregate total amount of data that can be imported is virtually unlimited.

Interfaces

  • AWS Snowball is managed through the AWS Management Console (OpsHub), AWS CLI, and SDKs.
  • AWS OpsHub provides a graphical interface for managing Snow devices.
  • AWS Data Transfer Terminal is managed through the AWS Management Console for reservations.

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 working with a customer who has 10 TB of archival data that they want to migrate to Amazon Glacier. The customer has a 1-Mbps connection to the Internet. Which service or feature provides the fastest method of getting the data into Amazon Glacier?
    1. Amazon Glacier multipart upload
    2. AWS Storage Gateway
    3. VM Import/Export
    4. AWS Import/Export (Now: AWS Snowball)

    Note: This question uses legacy service names. AWS Import/Export has been replaced by AWS Snowball Edge. As of Nov 2025, Snowball Edge is only available to existing customers — new customers should use AWS Data Transfer Terminal.

  2. A company needs to provide on-premises applications with low-latency access to frequently used data while storing the complete dataset in AWS for disaster recovery. Which Storage Gateway configuration is most appropriate?
    1. S3 File Gateway with local cache
    2. Volume Gateway in cached mode
    3. Volume Gateway in stored mode
    4. Tape Gateway
    Show Answer

    Answer: C – Volume Gateway in stored mode keeps the complete primary data locally for low-latency access to the entire dataset, while asynchronously backing up data to AWS as EBS snapshots for disaster recovery.

  3. A company wants to minimize on-premises storage costs while maintaining low-latency access to frequently accessed data. The full dataset is several hundred terabytes. Which Storage Gateway solution is most suitable?
    1. S3 File Gateway
    2. Volume Gateway in cached mode
    3. Volume Gateway in stored mode
    4. Tape Gateway
    Show Answer

    Answer: B – Volume Gateway in cached mode stores primary data in S3 while retaining frequently accessed data locally in a cache, minimizing on-premises storage requirements.

  4. A new customer needs to physically transfer 50 TB of data to AWS but cannot use AWS Snowball Edge (no longer available to new customers as of November 2025). What is the recommended alternative?
    1. AWS Snowcone
    2. AWS Snowmobile
    3. AWS Data Transfer Terminal
    4. AWS Import/Export with customer-owned devices
    Show Answer

    Answer: C – AWS Data Transfer Terminal provides secure, physical locations where customers can bring their storage devices and transfer data using high-throughput connections to AWS. Snowcone and Snowmobile are discontinued, and Import/Export was replaced by Snowball in 2015.

  5. Which AWS Storage Gateway type would you recommend for a company that wants to replace their physical tape backup infrastructure with cloud-based backup while keeping existing backup software?
    1. S3 File Gateway
    2. Volume Gateway
    3. Tape Gateway
    4. FSx File Gateway
    Show Answer

    Answer: C – Tape Gateway presents a virtual tape library (VTL) interface compatible with existing backup applications, allowing companies to replace physical tape infrastructure while maintaining their current backup workflows.

AWS Storage Options – RDS, DynamoDB & Database on EC2

~ Last updated on : ~ jayendrapatil ~ 17 Comments

AWS Storage Options Whitepaper with RDS, DynamoDB & Database on EC2 Cont.

Provides a brief summary for the Ideal Use cases, Anti-Patterns and other factors for Amazon RDS, DynamoDB & Databases on EC2 storage options

📝 Note: The original AWS Storage Services Overview whitepaper has been archived by AWS. This content is maintained and updated with current service capabilities for certification study reference. See the AWS Overview – Storage Services for the latest official guidance.

Amazon RDS

  • RDS is a fully managed relational database service supporting Amazon Aurora, MySQL, PostgreSQL, MariaDB, Oracle, and Microsoft SQL Server database engines
  • RDS eliminates much of the administrative overhead associated with launching, managing, and scaling your own relational database on Amazon EC2 or in another computing environment.
  • RDS provides automated patching, backups, Multi-AZ high availability, read replicas, and monitoring out of the box.

Key Features (Updated 2024-2026)

  • Multi-AZ DB Cluster Deployments – deploys a primary and two readable standby instances across three AZs, providing faster failover (~35 seconds), improved commit latency via semisynchronous replication, and readable standbys (MySQL/PostgreSQL)
  • Blue/Green Deployments – creates a fully managed staging (green) environment that mirrors production (blue), allowing safe testing of major version upgrades and schema changes with minimal downtime switchover
  • RDS Proxy – a fully managed database proxy that pools and shares connections, improving application scalability, resilience to database failovers, and security via IAM/Secrets Manager authentication
  • RDS Data API – available for Aurora (Serverless v2 and provisioned), enables secure HTTP-based SQL execution without managing database drivers or connections
  • Aurora Serverless v2 – auto-scales database capacity in fine-grained increments based on application demand, scaling to hundreds of thousands of transactions per second
  • Aurora DSQL (launched Dec 2024) – a serverless, distributed SQL database with active-active multi-Region high availability, PostgreSQL-compatible, with strong consistency across all Regional endpoints
  • RDS Custom – provides OS and database access for Oracle and SQL Server when full administrative control is needed (Note: RDS Custom for Oracle reaches end of support March 31, 2027)
  • Graviton (ARM) Instances – M7g, R7g, M7i, R7i instance types offering better price-performance
  • gp3 Storage – baseline of 3,000 IOPS and 125 MiB/s, scalable up to 80,000 IOPS and 2,000 MiB/s per volume (up to 64 TiB per volume)
  • Extended Support – up to 3 additional years of critical security and bug fixes beyond community end-of-life for major engine versions

Ideal Usage Patterns

  • RDS is a great solution for cloud-based fully-managed relational database
  • RDS is also optimal for new applications with structured data that requires more sophisticated querying and joining capabilities than that provided by Amazon’s NoSQL database offering, DynamoDB.
  • RDS provides full compatibility with the databases supported and direct access to native database engines, code and libraries and is ideal for existing applications that rely on these databases
  • Applications requiring zero-downtime upgrades can leverage Blue/Green Deployments for safe major version changes
  • Serverless and event-driven applications benefit from RDS Proxy and Aurora Serverless v2 for connection management and auto-scaling

Anti-Patterns

  • Index and query-focused data
    • If the applications don’t require advanced features such as joins and complex transactions and is more oriented toward indexing and querying data, DynamoDB would be more appropriate for this needs
  • Numerous BLOBs
    • If the application makes heavy use of files (audio files, videos, images, etc), it is a better choice to use S3 to store the objects instead of database engines Blob feature and use RDS or DynamoDB only to save the metadata
  • Automated scalability
    • RDS provides vertical scaling (scale up) and limited horizontal scale-out via read replicas. For fully-automated serverless scaling, consider Aurora Serverless v2 or DynamoDB.
  • Complete control
    • RDS does not provide full OS-level admin access.
    • If the application requires complete OS-level control, consider RDS Custom (for Oracle/SQL Server) or a self-managed database on EC2.
  • Other database platforms
    • RDS supports Aurora, MySQL, PostgreSQL, MariaDB, Oracle, and SQL Server.
    • If any other database platform (such as IBM DB2, Informix, or Sybase) is needed, it should be deployed on a self-managed database on an EC2 instance.

Performance

  • RDS offers multiple storage types optimized for different workloads:
    • gp3 (General Purpose SSD) – baseline 3,000 IOPS, scalable up to 80,000 IOPS and 2,000 MiB/s throughput, up to 64 TiB per volume
    • io1/io2 (Provisioned IOPS SSD) – designed for I/O-intensive transactional workloads, up to 256,000 IOPS
  • Multi-AZ DB Cluster deployments provide improved write commit latency through optimized semisynchronous replication
  • Performance Insights provides a dashboard to monitor database load and identify bottlenecks
  • RDS Optimized Reads/Writes (Aurora) provide up to 2x faster query processing and 6x higher write throughput

Durability and Availability

  • RDS leverages Amazon EBS volumes as its data store
  • RDS provides database backups, for enhanced durability, which are replicated across multiple AZ’s
    • Automated backups
      • RDS automatically performs a full daily backup during the specified backup window, and captures DB transaction logs (up to 35-day retention)
    • User initiated backups (DB Snapshots)
      • User can initiate manual snapshots at any time; they are retained until explicitly deleted
  • Multi-AZ DB Instance – synchronously replicates data to a standby in another AZ with automatic failover (typically 60-120 seconds)
  • Multi-AZ DB Cluster – maintains a primary and two readable standbys across three AZs with faster failover (~35 seconds) and transaction log-based replication
  • RDS provides a DNS endpoint; in case of failure on the primary, it automatically fails over to the standby instance
  • RDS Read Replicas provide asynchronous replication for read scaling and can be promoted for disaster recovery (including cross-Region replicas)

Cost Model

  • RDS offers a tiered pricing structure based on instance size, deployment type (Single-AZ/Multi-AZ Instance/Multi-AZ Cluster), and AWS Region
  • Pricing components: DB instance hours, provisioned storage (per GB-month), I/O requests (for io1/io2), additional backup storage, and data transfer
  • Reserved Instances provide significant discounts (up to 69%) for 1-year or 3-year commitments
  • Aurora Serverless v2 charges per Aurora Capacity Unit (ACU) consumed per second

Scalability and Elasticity

  • RDS resources can be scaled in several dimensions: storage size, IOPS, instance compute capacity, and number of read replicas
  • Storage Auto Scaling automatically increases storage when approaching capacity limits
  • Aurora Auto Scaling automatically adjusts the number of Aurora Replicas based on demand
  • Aurora Serverless v2 scales compute capacity automatically in fine-grained increments (0.5 ACU) from minimum to maximum configured capacity
  • Read Replicas (up to 15 for Aurora, 5 for other engines) enable read scaling across AZs and Regions
  • Aurora Limitless Database provides horizontal write scaling by automatically sharding data across multiple writer instances

Interfaces

  • RDS APIs, AWS CLI, and the AWS Management Console provide management interfaces for creating, modifying, and managing DB instances
  • RDS Data API (Aurora) provides a secure HTTP endpoint for running SQL statements without managing database connections or drivers
  • Once a database is created, RDS provides a DNS endpoint for the database which can be used to connect using standard database drivers
  • Endpoint does not change over the lifetime of the instance, even during failover in Multi-AZ configurations
  • RDS Proxy endpoints provide connection pooling and improved failover handling for applications

Amazon DynamoDB

  • Amazon DynamoDB is a fully managed, serverless NoSQL database service that delivers single-digit millisecond performance at any scale.
  • DynamoDB offers zero infrastructure management, zero downtime maintenance, and automatic scaling to accommodate any workload demand.
  • DynamoDB provides both eventually-consistent reads (by default) and strongly-consistent reads (optional), as well as ACID transactions (TransactWriteItems, TransactGetItems) for coordinated operations across multiple items and tables.
  • Amazon DynamoDB handles data as follows:
    • DynamoDB stores structured data in tables, indexed by primary key, and allows low-latency read and write access to items.
    • DynamoDB supports rich data types: Scalar (String, Number, Binary, Boolean, Null), Document (List, Map), and Set (String Set, Number Set, Binary Set)
    • Tables do not have a fixed schema, so each data item can have a different number of attributes.
    • Primary key can either be a single-attribute partition key (hash key) or a composite partition key + sort key (hash-range key).
    • Local Secondary Indexes (LSI) – alternate sort key on the same partition key (defined at table creation)
    • Global Secondary Indexes (GSI) – alternate partition key and optional sort key, can be added/modified anytime

Key Features (Updated 2024-2026)

  • On-Demand Capacity Mode – pay-per-request pricing with no capacity planning; automatically scales to accommodate workload demand. 50% price reduction effective November 2024.
  • Global Tables – fully managed, multi-Region, multi-active replication with two consistency modes:
    • Multi-Region Eventual Consistency (MREC) – default mode, typically sub-second replication
    • Multi-Region Strong Consistency (MRSC) – GA 2025, provides zero RPO with strongly consistent reads/writes across all Regions
  • DynamoDB Accelerator (DAX) – fully managed, in-memory cache providing microsecond read latency for read-heavy workloads
  • Standard-IA Table Class – lower storage cost option (up to 60% cheaper storage) for infrequently accessed data
  • PartiQL – SQL-compatible query language for DynamoDB, enabling familiar SELECT, INSERT, UPDATE, DELETE syntax
  • Zero-ETL Integrations – seamless data replication to Amazon Redshift, OpenSearch Service, and SageMaker Lakehouse without building ETL pipelines
  • S3 Import/Export – bulk import data from S3 and export table data to S3 in DynamoDB JSON or Amazon Ion format
  • Point-in-Time Recovery (PITR) – continuous backups with per-second granularity, restorable to any point within a configurable 1-35 day window
  • Encryption at Rest – enabled by default using AWS owned keys, with options for AWS managed key or customer managed KMS key
  • DynamoDB Streams / Kinesis Data Streams – capture item-level changes for event-driven architectures, real-time analytics, and cross-Region replication

Ideal Usage Patterns

  • DynamoDB is ideal for applications that need a flexible NoSQL database with low read and write latencies, and the ability to scale storage and throughput up or down as needed without code changes or downtime.
  • Use cases requiring a highly available and scalable database e.g., mobile apps, gaming, digital ad serving, live voting, sensor networks, log ingestion, access control, metadata storage for S3 objects, e-commerce shopping carts, web session management, and serverless applications
  • Event-driven architectures leveraging DynamoDB Streams to trigger Lambda functions or downstream processing
  • Global applications requiring multi-Region active-active deployments with Global Tables

Anti-Patterns

  • Structured data with Join and/or Complex Transactions
    • If the application uses structured data and requires complex joins, multi-table transactions, or relationship infrastructure provided by traditional relational databases, RDS or Aurora would be a better choice. (Note: DynamoDB does support ACID transactions within and across tables, but not SQL-style joins.)
  • Large Blob data
    • DynamoDB has a maximum item size of 400 KB. For large media files, videos, etc., use S3 for storage and DynamoDB for metadata.
  • Large Objects with Low I/O rate
    • DynamoDB uses SSD drives and is optimized for high I/O workloads. If the application stores very large amounts of infrequently accessed data, S3 or the Standard-IA table class might be more cost-effective.
  • Complex ad-hoc analytics
    • For complex analytical queries across large datasets, use DynamoDB zero-ETL integration with Amazon Redshift or export to S3 for Athena queries.

Performance

  • SSDs and limited indexing on attributes provides single-digit millisecond latency at any scale.
  • Provisioned capacity mode – define exact read/write capacity units for predictable workloads with optional auto-scaling
  • On-demand capacity mode – automatically accommodates up to double previous peak traffic instantly, with further scaling within minutes
  • DAX (DynamoDB Accelerator) – in-memory cache providing microsecond response times for eventually consistent reads
  • DynamoDB automatically partitions data to maintain consistent performance as tables grow.

Durability and Availability

  • DynamoDB automatically and synchronously replicates data across three AZs in a Region for high availability and data protection against facility failures.
  • Global Tables provide multi-Region replication with 99.999% availability SLA (multi-Region)
  • PITR provides continuous backups for point-in-time restore capability
  • On-demand backups allow full table backups at any time without performance impact

Cost Model

  • DynamoDB offers two capacity modes:
    • On-Demand – pay per read/write request (no capacity planning). 50% price reduction since November 2024.
    • Provisioned – pay per hour for provisioned Read/Write Capacity Units (with optional auto-scaling and Reserved Capacity discounts)
  • Additional pricing components: data storage (per GB-month), Global Tables replication (per replicated write unit), backups, data export/import, DynamoDB Streams reads, and data transfer
  • Standard-IA table class reduces storage costs by up to 60% with higher per-request costs (ideal when storage dominates)
  • Global Tables pricing reduced by up to 67% (November 2024)

Scalability and Elasticity

  • DynamoDB is both highly-scalable and elastic with virtually unlimited storage and throughput capacity.
  • Data is automatically partitioned and re-partitioned as needed, while SSD storage provides predictable low-latency at any scale.
  • On-Demand mode provides truly serverless scaling with no capacity planning required
  • Provisioned mode with Auto Scaling automatically adjusts capacity based on utilization targets
  • DynamoDB can handle more than 10 trillion requests per day and support peaks of more than 100 million requests per second.

Interfaces

  • DynamoDB provides a low-level REST API, AWS SDKs in multiple languages, and the AWS CLI
  • PartiQL – SQL-compatible query language supported via Console, CLI, SDKs, and NoSQL Workbench
  • APIs provide both management and data interfaces: table management (create, list, delete, describe) and item operations (Get, Put, Update, Delete, Query, Scan, BatchWrite, BatchGet, TransactWrite, TransactGet)
  • DynamoDB Streams API – captures ordered sequence of item-level changes
  • NoSQL Workbench – visual tool for data modeling, visualization, and query development

Databases on EC2

  • EC2 with EBS volumes allows hosting a self-managed relational database with full OS and database administrative control
  • Ready-to-use, prebuilt AMIs are available from leading database vendors in AWS Marketplace
  • Note: With the introduction of RDS Custom (for Oracle and SQL Server), the need for self-managed databases on EC2 has decreased for these specific engines

Ideal Usage Patterns

  • Self-managed database on EC2 is ideal for applications that require a specific database platform not supported by Amazon RDS e.g., IBM DB2, Informix, Sybase, or specialized configurations
  • Applications requiring maximum level of administrative control and configurability including custom storage engines, specialized replication, or kernel-level tuning not available in RDS or RDS Custom
  • Database versions or configurations not yet supported by RDS

Anti-Patterns

  • Index and query-focused data
    • If the applications don’t require advanced features such as joins and complex transactions and is more oriented toward indexing and querying data, DynamoDB would be more appropriate
  • Numerous BLOBs
    • If the application makes heavy use of files (audio files, videos, images), use S3 for object storage and RDS or DynamoDB for metadata
  • Managed service available
    • If RDS supports the database engine and provides the needed features, RDS is preferred for reduced operational overhead. For Oracle/SQL Server requiring OS access, consider RDS Custom before self-managing on EC2.
  • Automated scalability
    • Self-managed databases require manual or scripted scaling operations. If fully-automated scaling is needed, DynamoDB, Aurora Serverless, or RDS with Auto Scaling may be better choices.

Performance

  • Performance depends on the EC2 instance type, number/configuration of EBS volumes, and database tuning
  • Scale up by choosing larger instance types (compute-optimized, memory-optimized) or Graviton-based instances for better price-performance
  • For storage: use gp3 or io2 Block Express EBS volumes. Use software RAID 0 (disk striping) across multiple EBS volumes for aggregated IOPS and bandwidth
  • Instance store (NVMe SSDs) can provide very high IOPS for temporary/cache workloads

Durability & Availability

  • Uses EBS for storage with same durability guarantees (99.999% availability for io2 Block Express)
  • Enhanced durability via EBS snapshots, cross-Region replication, or third-party backup tools (e.g., Oracle RMAN) to S3
  • High availability requires manual configuration: Multi-AZ replication, clustering solutions, or automated failover scripts

Cost Model

  • Cost determined by: EC2 instance size/type, EBS volume size and IOPS, data transfer, and any third-party database licensing costs
  • Savings Plans and Reserved Instances reduce EC2 compute costs for steady-state workloads
  • BYOL (Bring Your Own License) options available for Oracle, SQL Server, and other commercial databases

Scalability & Elasticity

  • Leverage EC2 scalability by creating AMIs for horizontal scaling, though database-specific clustering/sharding is required
  • Vertical scaling requires instance stop/start (brief downtime without clustering)
  • Auto Scaling groups can manage read replica fleets for read-heavy workloads

Comparison: RDS vs DynamoDB vs Database on EC2

Factor Amazon RDS DynamoDB Database on EC2
Type Managed Relational (SQL) Managed NoSQL (Key-Value/Document) Self-Managed Relational
Scaling Vertical + Read Replicas; Aurora Serverless for auto-scaling Fully automatic (on-demand) or provisioned with auto-scaling Manual vertical/horizontal
Availability Multi-AZ (2 or 3 AZs), automated failover Automatic across 3 AZs; Global Tables for multi-Region Manual HA configuration required
Admin Overhead Low (managed patching, backups) None (serverless) High (full responsibility)
Use Case Complex queries, joins, ACID transactions High-speed key-value access, flexible schema, massive scale Unsupported engines, full OS control

AWS Certification Exam Practice Questions

  • Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
  • AWS services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
  • AWS exam questions are not updated to keep up the pace with AWS updates, so even if the underlying feature has changed the question might not be updated
  • Open to further feedback, discussion and correction.
  1. Which of the following are use cases for Amazon DynamoDB? Choose 3 answers
    1. Storing BLOB data.
    2. Managing web sessions
    3. Storing JSON documents
    4. Storing metadata for Amazon S3 objects
    5. Running relational joins and complex updates.
    6. Storing large amounts of infrequently accessed data.
  2. A client application requires operating system privileges on a relational database server. What is an appropriate configuration for highly available database architecture?
    1. A standalone Amazon EC2 instance
    2. Amazon RDS in a Multi-AZ configuration
    3. Amazon EC2 instances in a replication configuration utilizing a single Availability Zone
    4. Amazon EC2 instances in a replication configuration utilizing two different Availability Zones

    Note: With the introduction of RDS Custom, this question’s context has evolved. RDS Custom for SQL Server now supports Multi-AZ. However, for full OS-level control beyond what RDS Custom offers, EC2 remains the answer.

  3. You are developing a new mobile application and are considering storing user preferences in AWS, which would provide a more uniform cross-device experience to users using multiple mobile devices to access the application. The preference data for each user is estimated to be 50KB in size. Additionally 5 million customers are expected to use the application on a regular basis. The solution needs to be cost-effective, highly available, scalable and secure, how would you design a solution to meet the above requirements?
    1. Setup an RDS MySQL instance in 2 availability zones to store the user preference data. Deploy a public facing application on a server in front of the database to manage security and access credentials
    2. Setup a DynamoDB table with an item for each user having the necessary attributes to hold the user preferences. The mobile application will query the user preferences directly from the DynamoDB table. Utilize STS. Web Identity Federation, and DynamoDB Fine Grained Access Control to authenticate and authorize access (DynamoDB provides high availability as it synchronously replicates data across three facilities within an AWS Region and scalability as it is designed to scale its provisioned throughput up or down while still remaining available. Also suitable for storing user preference data)
    3. Setup an RDS MySQL instance with multiple read replicas in 2 availability zones to store the user preference data. The mobile application will query the user preferences from the read replicas. Leverage the MySQL user management and access privilege system to manage security and access credentials.
    4. Store the user preference data in S3 Setup a DynamoDB table with an item for each user and an item attribute pointing to the user’ S3 object. The mobile application will retrieve the S3 URL from DynamoDB and then access the S3 object directly utilize STS, Web identity Federation, and S3 ACLs to authenticate and authorize access.
  4. A customer is running an application in US-West (Northern California) region and wants to setup disaster recovery failover to the Asian Pacific (Singapore) region. The customer is interested in achieving a low Recovery Point Objective (RPO) for an Amazon RDS multi-AZ MySQL database instance. Which approach is best suited to this need?
    1. Synchronous replication
    2. Asynchronous replication (Cross-Region Read Replicas use asynchronous replication. Note: DynamoDB Global Tables with MRSC now offers zero RPO across Regions for NoSQL workloads.)
    3. Route53 health checks
    4. Copying of RDS incremental snapshots
  5. You are designing a file-sharing service. This service will have millions of files in it. Revenue for the service will come from fees based on how much storage a user is using. You also want to store metadata on each file, such as title, description and whether the object is public or private. How do you achieve all of these goals in a way that is economical and can scale to millions of users?
    1. Store all files in Amazon Simple Storage Service (S3). Create a bucket for each user. Store metadata in the filename of each object, and access it with LIST commands against the S3 API.
    2. Store all files in Amazon S3. Create Amazon DynamoDB tables for the corresponding key-value pairs on the associated metadata, when objects are uploaded.
    3. Create a striped set of 4000 IOPS Elastic Load Balancing volumes to store the data. Use a database running in Amazon Relational Database Service (RDS) to store the metadata.
    4. Create a striped set of 4000 IOPS Elastic Load Balancing volumes to store the data. Create Amazon DynamoDB tables for the corresponding key-value pairs on the associated metadata, when objects are uploaded.
  6. Company ABCD has recently launched an online commerce site for bicycles on AWS. They have a “Product” DynamoDB table that stores details for each bicycle, such as, manufacturer, color, price, quantity and size to display in the online store. Due to customer demand, they want to include an image for each bicycle along with the existing details. Which approach below provides the least impact to provisioned throughput on the “Product” table?
    1. Serialize the image and store it in multiple DynamoDB tables
    2. Create an “Images” DynamoDB table to store the Image with a foreign key constraint to the “Product” table
    3. Add an image data type to the “Product” table to store the images in binary format
    4. Store the images in Amazon S3 and add an S3 URL pointer to the “Product” table item for each image
  7. A company needs to store IoT sensor data from thousands of devices. The data is small (under 1KB per reading), arrives at unpredictable rates, and must be queryable by device ID and timestamp with single-digit millisecond latency. Which database solution is most appropriate?
    1. Amazon RDS MySQL with Multi-AZ
    2. Self-managed Cassandra on EC2
    3. Amazon DynamoDB with on-demand capacity mode (DynamoDB with on-demand mode is ideal: handles unpredictable workloads without capacity planning, supports composite key (device ID as partition key, timestamp as sort key), and provides single-digit millisecond latency)
    4. Amazon Aurora Serverless
  8. A company wants to perform real-time analytics on data stored in their DynamoDB table without impacting production read/write performance. Which approach is the most operationally efficient?
    1. Create a read replica of the DynamoDB table
    2. Export data to S3 on a scheduled basis and query with Athena
    3. Use DynamoDB zero-ETL integration with Amazon Redshift (Zero-ETL integration provides near real-time data replication to Redshift without building custom pipelines or impacting DynamoDB performance)
    4. Use DynamoDB Streams with a Lambda function to copy data to RDS

AWS Storage Options – S3 & Glacier

~ Last updated on : ~ jayendrapatil ~ 30 Comments

📋 Post Updated: June 2026

This post has been updated to reflect the current AWS S3 storage classes (8 classes as of 2025), the deprecation of standalone Amazon Glacier vaults, S3 Glacier storage class renaming, removal of S3 Reduced Redundancy Storage (RRS) recommendation, and new S3 capabilities including S3 Tables, S3 Vectors, and S3 Express One Zone.

Amazon S3

  • highly-scalable, reliable, and low-latency data storage infrastructure at very low costs.
  • provides a simple web services interface that can be used to store and retrieve any amount of data, at any time, from within Amazon EC2 or from anywhere on the web.
  • allows you to write, read, and delete objects containing from 1 byte to 5 terabytes of data each.
  • number of objects you can store in an Amazon S3 bucket is virtually unlimited.
  • highly secure, supporting encryption at rest and in transit, and providing multiple mechanisms to provide fine-grained control of access to Amazon S3 resources.
  • as of January 5, 2023, all new objects are automatically encrypted with SSE-S3 (server-side encryption with S3 managed keys) at no additional cost.
  • highly scalable, allowing concurrent read or write access to Amazon S3 data by many separate clients or application threads.
  • provides data lifecycle management capabilities, allowing users to define rules to automatically transition data between storage classes (including S3 Glacier classes) or delete data at end of life.
  • stores data redundantly across a minimum of 3 Availability Zones by default (except One Zone classes), providing built-in resilience against widespread disaster.

S3 Storage Classes

Amazon S3 offers 8 storage classes designed for different access patterns and cost requirements:

  • S3 Standard – General-purpose storage for frequently accessed data. High throughput and low latency.
  • S3 Intelligent-Tiering – Automatic cost optimization by moving data between access tiers (Frequent, Infrequent, Archive Instant Access) based on changing access patterns, with no retrieval charges or operational overhead.
  • S3 Standard-Infrequent Access (S3 Standard-IA) – For data accessed less frequently but requiring rapid access when needed. Lower storage cost with per-GB retrieval charge.
  • S3 One Zone-Infrequent Access (S3 One Zone-IA) – Lower-cost option for infrequently accessed data that does not require multi-AZ resilience. Replaces the legacy Reduced Redundancy Storage (RRS).
  • S3 Express One Zone – Single-digit millisecond data access with up to 10x faster performance and 80% lower request costs than S3 Standard. Data stored in a single Availability Zone. Ideal for latency-sensitive applications like ML training and analytics.
  • S3 Glacier Instant Retrieval – Lowest-cost storage for long-lived data rarely accessed (once per quarter) that requires millisecond retrieval. 68% lower cost than S3 Standard-IA.
  • S3 Glacier Flexible Retrieval (formerly S3 Glacier) – For archive data accessed once or twice per year. Retrieval options: Expedited (1-5 minutes), Standard (3-5 hours), or free Bulk (5-12 hours). Minimum 90-day storage.
  • S3 Glacier Deep Archive – Lowest-cost storage class for long-term archive and digital preservation. Retrieval: Standard (within 12 hours) or Bulk (within 48 hours). Minimum 180-day storage.

Ideal Use Cases

  • Storage & Distribution of static web content and media
    • frequently used to host static websites and provides a highly-available and highly-scalable solution for websites with only static content, including HTML files, images, videos, and client-side scripts such as JavaScript
    • works well for fast growing websites hosting data intensive, user-generated content, such as video and photo sharing sites as no storage provisioning is required
    • content can either be directly served from Amazon S3 since each object in Amazon S3 has a unique HTTP URL address
    • can also act as an Origin store for the Content Delivery Network (CDN) such as Amazon CloudFront
    • it works particularly well for hosting web content with extremely spiky bandwidth demands because of S3’s elasticity
  • Data Store for Large Objects
    • can be paired with RDS or NoSQL database and used to store large objects for e.g. file or objects, while the associated metadata for e.g. name, tags, comments etc. can be stored in RDS or NoSQL database where it can be indexed and queried providing faster access to relevant data
  • Data store for computation and large-scale analytics
    • commonly used as a data store for computation and large-scale analytics, such as analyzing financial transactions, clickstream analytics, and media transcoding.
    • data can be accessed from multiple computing nodes concurrently without being constrained by a single connection because of its horizontal scalability
    • S3 Tables (launched Dec 2024) provides storage optimized for tabular data in Apache Iceberg format, with up to 3x faster query throughput for analytics workloads
  • Backup and Archival of critical data
    • used as a highly durable, scalable, and secure solution for backup and archival of critical data, and to provide disaster recovery solutions for business continuity.
    • stores objects redundantly on multiple devices across multiple facilities, it provides the highly-durable storage infrastructure needed for these scenarios.
    • it’s versioning capability is available to protect critical data from inadvertent deletion
  • AI and Machine Learning
    • S3 Vectors (GA Dec 2025) provides native vector storage with subsecond query performance for AI embeddings, reducing costs up to 90% compared to dedicated vector databases
    • integrated with Amazon Bedrock Knowledge Bases for retrieval augmented generation (RAG) workloads
  • Data Lakes
    • S3 serves as the foundation for building data lakes, with native integration with analytics services like Amazon Athena, Amazon EMR, and Amazon Redshift Spectrum
    • Mountpoint for Amazon S3 (GA Aug 2023) allows mounting S3 buckets as local file systems on Linux compute instances for high-throughput workloads

Anti-Patterns

Amazon S3 has following Anti-Patterns where it is not an optimal solution

  • Dynamic website hosting
    • While Amazon S3 is ideal for hosting static websites, dynamic websites requiring server side interaction, scripting or database interaction cannot be hosted and should rather be hosted on Amazon EC2 or AWS Lambda with API Gateway
  • Rapidly Changing Data
    • Data that needs to updated frequently might be better served by a storage solution with lower read/write latencies, such as Amazon EBS volumes, RDS, or DynamoDB.
  • File System Requirements
    • Amazon S3 uses a flat namespace and isn’t meant to serve as a standalone, POSIX-compliant file system. However, by using delimiters (commonly the ‘/’ character) you can emulate hierarchical folder structures within a bucket.
    • NOTE: Mountpoint for Amazon S3 provides file system access for read-heavy workloads, but is not a full POSIX file system. For full POSIX compliance, consider Amazon EFS or Amazon FSx.

Performance

  • Access to Amazon S3 from within Amazon EC2 in the same region is fast.
  • Amazon S3 is designed so that server-side latencies are insignificant relative to Internet latencies.
  • Amazon S3 automatically scales to high request rates — your application can achieve at least 3,500 PUT/COPY/POST/DELETE and 5,500 GET/HEAD requests per second per partitioned prefix in a bucket. There are no limits to the number of prefixes in a bucket.
  • If Amazon S3 is accessed using multiple threads, multiple applications, or multiple clients concurrently, total Amazon S3 aggregate throughput will typically scale to rates that far exceed what any single server can generate or consume.
  • S3 Express One Zone provides single-digit millisecond latency and up to 10x faster performance than S3 Standard for latency-sensitive workloads.
  • S3 Transfer Acceleration enables fast, easy, and secure transfers of files over long distances between your client and an S3 bucket using CloudFront’s globally distributed edge locations.

Durability & Availability

  • Amazon S3 storage provides the highest level of data durability and availability, by automatically and synchronously storing your data across a minimum of three Availability Zones within the selected geographical region
  • Amazon S3 is designed to sustain the concurrent loss of data in two facilities, making it very well-suited to serve as the primary data storage for mission-critical data.
  • Amazon S3 is designed for 99.999999999% (11 nines) durability per object and 99.99% availability over a one-year period.
  • Amazon S3 data can be protected from unintended deletions or overwrites using Versioning.
  • Versioning can be enabled with MFA (Multi Factor Authentication) Delete on the bucket, which would require two forms of authentication to delete an object
  • S3 Object Lock provides write-once-read-many (WORM) protection to prevent objects from being deleted or overwritten for a fixed period or indefinitely (Governance or Compliance mode).
  • For Non Critical and Reproducible data, S3 Reduced Redundancy Storage (RRS) was previously available but is no longer recommended. Use S3 One Zone-IA instead for non-critical, reproducible data at lower cost with 99.5% availability.

Cost Model

  • With Amazon S3, you pay only for what you use and there is no minimum fee.
  • Amazon S3 pricing components include: storage (per GB per month, varies by storage class), data transfer out (per GB per month), requests and data retrievals (per n thousand requests per month), and optional management/analytics features.
  • S3 Intelligent-Tiering has a small monthly monitoring and automation charge per object but no retrieval fees, making it ideal for data with unknown or changing access patterns.

Scalability & Elasticity

  • Amazon S3 has been designed to offer a very high level of scalability and elasticity automatically
  • Amazon S3 supports a virtually unlimited number of files in any bucket
  • Amazon S3 bucket can store a virtually unlimited number of bytes
  • Amazon S3 allows you to store any number of objects (files) in a single bucket, and Amazon S3 will automatically manage scaling and distributing redundant copies of your information across multiple AZs in the same region, all using Amazon’s high-performance infrastructure.

Security & Access Management

  • Default Encryption: Since January 5, 2023, all new objects are automatically encrypted with SSE-S3. Options include SSE-S3, SSE-KMS (AWS KMS keys), SSE-C (customer-provided keys), and client-side encryption.
  • SSE-C Disabled by Default: As of April 2026, SSE-C is disabled by default on all new S3 general purpose buckets for improved security.
  • S3 Access Points: Simplify managing data access at scale by creating named access points with distinct permissions and network controls for different applications or teams.
  • S3 Block Public Access: Bucket-level and account-level settings to prevent public access.
  • Bucket Policies & ACLs: Fine-grained access control using IAM policies, bucket policies, and (legacy) Access Control Lists.
  • VPC Endpoints: Access S3 privately from within a VPC without traversing the public internet.

Interfaces

  • Amazon S3 provides standards-based REST APIs for both management and data operations.
  • NOTE – SOAP support over HTTP was deprecated. New Amazon S3 features are not supported for SOAP. Use the REST API or the AWS SDKs.
  • Amazon S3 provides SDKs in multiple languages (Java, Python, .NET, Go, JavaScript/TypeScript, PHP, Ruby, and more) that wrap the underlying APIs
  • AWS CLI provides high-level S3 file commands (ls, cp, mv, sync, etc.) with support for parallel transfers and recursive operations.
  • AWS Management Console provides a web-based interface for managing S3 buckets and objects
  • Mountpoint for Amazon S3 – open-source file client that mounts S3 buckets as local file systems on Linux, optimized for high-throughput read-heavy workloads (GA August 2023).
  • All interfaces provide the ability to store Amazon S3 objects in uniquely-named buckets, with each object identified by a unique Object key within that bucket.

S3 Data Query & Analytics

  • Amazon Athena – Serverless query service to analyze data in S3 using standard SQL without loading data into a database.
  • S3 Tables (Dec 2024) – Fully managed Apache Iceberg tables optimized for analytics, with up to 3x faster query throughput. Supports Intelligent-Tiering and replication.
  • S3 Vectors (GA Dec 2025) – Native vector storage and query for AI embeddings with subsecond performance, up to 2 billion vectors per index.
  • S3 Storage Lens – Cloud storage analytics providing organization-wide visibility into object storage usage, activity, and cost optimization recommendations.
  • S3 Select – Closed to new customers as of July 25, 2024. Use Amazon Athena, S3 Object Lambda, or client-side filtering as alternatives.

Amazon S3 Glacier

⚠️ Standalone Amazon Glacier Vaults – No Longer Available to New Customers

As of December 15, 2025, the original standalone vault-based Amazon Glacier service stopped accepting new customers. Existing customers can continue using it, but no migration is required.

Recommendation: Use the S3 Glacier storage classes (Instant Retrieval, Flexible Retrieval, Deep Archive) which are fully integrated with Amazon S3 and provide the same low-cost archival storage with better management capabilities.

AWS provides a Data Transfer from Amazon S3 Glacier Vaults to Amazon S3 guidance for migrating existing vault data to S3 buckets.

Amazon S3 Glacier storage classes provide extremely low-cost storage for data archival and long-term backup:

  • S3 Glacier Instant Retrieval – Millisecond access for archive data accessed once per quarter. Up to 68% lower cost than S3 Standard-IA. Minimum 90-day storage.
  • S3 Glacier Flexible Retrieval (formerly S3 Glacier) – For archive data accessed once or twice per year. Retrieval options:
    • Expedited: 1-5 minutes
    • Standard: 3-5 hours
    • Bulk: 5-12 hours (free)

    Minimum 90-day storage duration.

  • S3 Glacier Deep Archive – Lowest-cost storage for data retained for 7-10+ years. Retrieval options:
    • Standard: Within 12 hours
    • Bulk: Within 48 hours

    Minimum 180-day storage duration.

Ideal Usage Patterns

  • Amazon S3 Glacier classes are ideally suited for long-term archival storage for infrequently accessed data including:
    • Offsite enterprise information archiving
    • Media asset preservation
    • Research and scientific data retention
    • Digital preservation and magnetic tape replacement
    • Regulatory and compliance archives
    • Healthcare records, financial records retention
  • S3 Glacier Instant Retrieval is ideal for data like medical images, news media assets, or user-generated content archives that need millisecond access but are rarely retrieved.

Anti-Patterns

Amazon S3 Glacier storage classes have following Anti-Patterns where they are not an optimal solution

  • Rapidly changing data
    • Data that must be updated very frequently should use a storage solution with lower read/write latencies such as Amazon EBS, DynamoDB, or S3 Standard
  • Real time access (Flexible Retrieval and Deep Archive)
    • Data stored in Glacier Flexible Retrieval or Deep Archive cannot be accessed in real time and requires a restore request with retrieval times from minutes to hours. If immediate access is needed, use S3 Standard, S3 Glacier Instant Retrieval, or S3 Intelligent-Tiering.
  • Short-lived data
    • Glacier classes have minimum storage duration charges (90 days for Instant/Flexible, 180 days for Deep Archive). Data deleted before the minimum is charged for the remainder.

Performance

  • S3 Glacier Instant Retrieval: Millisecond access time, same performance as S3 Standard-IA.
  • S3 Glacier Flexible Retrieval: Expedited (1-5 min), Standard (3-5 hours), Bulk (5-12 hours, free).
  • S3 Glacier Deep Archive: Standard (within 12 hours), Bulk (within 48 hours).

Durability and Availability

  • All S3 Glacier storage classes redundantly store data across a minimum of three Availability Zones
  • Designed to provide 99.999999999% (11 nines) durability per object
  • Data is synchronously stored across multiple facilities before returning SUCCESS on upload.
  • Regular, systematic data integrity checks are performed and the system is built to be automatically self-healing.

Cost Model

  • S3 Glacier pricing components include: storage (per GB per month), data transfer out (per GB per month), requests (per thousand requests per month), and data retrievals (per GB retrieved).
  • S3 Glacier Flexible Retrieval Bulk retrievals are free.
  • Early deletion charges apply if objects are deleted before the minimum storage duration (90 days for Instant/Flexible, 180 days for Deep Archive).
  • S3 Glacier Deep Archive offers storage starting at approximately $0.00099 per GB per month (lowest cost in the cloud).

Scalability & Elasticity

  • Individual objects can be up to 5 TB in size.
  • There is no limit to the total amount of data stored — Amazon S3 Glacier scales automatically from gigabytes to petabytes.

Interfaces & Lifecycle Integration

  • S3 Glacier storage classes are fully managed through the Amazon S3 APIs and console — objects are transitioned to Glacier classes via S3 Lifecycle policies or direct PUT with storage class specification.
  • S3 Lifecycle policies can automatically transition objects from S3 Standard → S3 Standard-IA → S3 Glacier Instant Retrieval → S3 Glacier Flexible Retrieval → S3 Glacier Deep Archive based on age.
  • Restoring objects from Glacier Flexible Retrieval or Deep Archive creates a temporary copy in S3 Standard for a specified retention period; the archived object remains in Glacier.
  • S3 Batch Operations can restore archived objects at scale across millions of objects.
  • Objects in S3 Glacier classes are managed through S3 APIs — they appear in S3 bucket listings and can be managed with standard S3 tools.
  • For data migration into AWS at scale, use the AWS Snow Family (Snowball Edge, Snowcone) for physical data transport. AWS Import/Export (legacy disk-based service) has been replaced by the Snow Family.

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 want to pass queue messages that are 1GB each. How should you achieve this?
    1. Use Kinesis as a buffer stream for message bodies. Store the checkpoint id for the placement in the Kinesis Stream in SQS.
    2. Use the Amazon SQS Extended Client Library for Java and Amazon S3 as a storage mechanism for message bodies. (Amazon SQS messages with Amazon S3 can be useful for storing and retrieving messages with a message size of up to 2 GB. To manage Amazon SQS messages with Amazon S3, use the Amazon SQS Extended Client Library for Java. Refer link)
    3. Use SQS’s support for message partitioning and multi-part uploads on Amazon S3.
    4. Use AWS EFS as a shared pool storage medium. Store filesystem pointers to the files on disk in the SQS message bodies.
  2. Company ABCD has recently launched an online commerce site for bicycles on AWS. They have a “Product” DynamoDB table that stores details for each bicycle, such as, manufacturer, color, price, quantity and size to display in the online store. Due to customer demand, they want to include an image for each bicycle along with the existing details. Which approach below provides the least impact to provisioned throughput on the “Product” table?
    1. Serialize the image and store it in multiple DynamoDB tables
    2. Create an “Images” DynamoDB table to store the Image with a foreign key constraint to the “Product” table
    3. Add an image data type to the “Product” table to store the images in binary format
    4. Store the images in Amazon S3 and add an S3 URL pointer to the “Product” table item for each image
  3. A company has 500 TB of archival data that must be retained for 10 years for regulatory compliance. The data is rarely accessed but must be retrievable within 12 hours when needed. Which S3 storage class is the MOST cost-effective?
    1. S3 Standard-IA
    2. S3 Glacier Instant Retrieval
    3. S3 Glacier Flexible Retrieval
    4. S3 Glacier Deep Archive (For data retained 7-10+ years with retrieval within 12 hours, Deep Archive provides the lowest cost at approximately $0.00099/GB/month with Standard retrieval within 12 hours.)
  4. A media company stores user-uploaded photos that are frequently accessed for the first 30 days, occasionally accessed for the next 90 days, and rarely accessed after that. They want to minimize storage costs without operational overhead. Which solution is MOST appropriate?
    1. Store in S3 Standard and create lifecycle rules to transition to S3 Standard-IA after 30 days and S3 Glacier Flexible Retrieval after 120 days
    2. Store in S3 Intelligent-Tiering which automatically moves objects between Frequent, Infrequent, and Archive Instant Access tiers based on access patterns (S3 Intelligent-Tiering eliminates operational overhead by automatically optimizing costs based on changing access patterns with no retrieval charges.)
    3. Store in S3 One Zone-IA with lifecycle rules
    4. Store in S3 Standard and manually move objects between storage classes
  5. An organization needs to query CSV data stored in S3 without provisioning any infrastructure. The data is several terabytes and they need to run ad-hoc SQL queries. Which AWS service should they use?
    1. Amazon RDS
    2. Amazon Redshift
    3. Amazon Athena (Amazon Athena is a serverless query service that can run SQL queries directly against data in S3 without loading it into a database. It’s ideal for ad-hoc queries on S3 data.)
    4. S3 Select
  6. A healthcare company needs to store patient records in S3 that cannot be deleted or modified for 7 years due to compliance regulations. Which S3 feature should they use?
    1. S3 Versioning with MFA Delete
    2. S3 Bucket Policy denying delete operations
    3. S3 Object Lock in Compliance mode with a 7-year retention period (S3 Object Lock in Compliance mode provides WORM protection that cannot be overridden by any user, including the root account, ensuring objects cannot be deleted or overwritten for the retention period.)
    4. S3 Glacier Vault Lock
  7. A machine learning team needs to store and query billions of vector embeddings from their AI models with subsecond performance. Which AWS service is purpose-built for this use case?
    1. Amazon OpenSearch Service
    2. Amazon DynamoDB
    3. Amazon S3 with Athena
    4. Amazon S3 Vectors (S3 Vectors provides native vector storage and query capabilities with subsecond performance, supporting up to 2 billion vectors per index, purpose-built for AI embedding workloads at S3’s low cost.)

References

AWS EC2 Best Practices

~ Last updated on : ~ jayendrapatil ~ 4 Comments

AWS EC2 Best Practices

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

Security & Network

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

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

Storage

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

Resource Management

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

Backup & Recovery

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

Networking

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

References

AWS Encrypting Data at Rest – Whitepaper – Certification

~ Last updated on : ~ jayendrapatil ~ 11 Comments

Encrypting Data at Rest

🔄 Major Updates (2023-2026)

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

Encryption Models in AWS

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

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

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

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

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

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

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

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

Sample Exam Questions

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

References