Study guide
Technical reference and lesson notes
Purpose of This Lesson
AWS offers different database and analytics services for different data models, performance profiles, availability requirements, and operational responsibilities. The key exam skill is selecting the service that best matches the workload rather than choosing the most powerful option by default.
This guide compares managed relational databases, NoSQL databases, caches, data warehouses, big-data processing platforms, streaming services, and serverless analytics tools.
Key Concepts
Database service selection
| Requirement | Strong AWS candidate | Main reason |
|---|---|---|
| Full operating-system and database-engine control | Database on Amazon EC2 | You manage the instance, operating system, patches, and database software |
| Managed traditional relational database and OLTP | Amazon RDS | Supports common relational engines and managed operations |
| Cloud-optimized relational database | Amazon Aurora | Distributed storage, high availability, read scaling, and MySQL/PostgreSQL compatibility |
| Flexible key-value or document data | Amazon DynamoDB | Serverless operation, horizontal scaling, and schema flexibility |
| Low-latency temporary data or sessions | Amazon ElastiCache | In-memory Redis or Memcached caching |
| DynamoDB-specific microsecond caching | DynamoDB Accelerator (DAX) | Managed cache compatible with DynamoDB APIs |
| Large-scale SQL analytics and OLAP | Amazon Redshift | Managed relational data warehouse |
| Hadoop or Spark processing and ETL | Amazon EMR | Managed clusters for big-data frameworks |
| Real-time streaming ingestion with consumer-controlled processing | Kinesis Data Streams | Durable stream divided into shards |
| Managed delivery of streaming data to destinations | Amazon Data Firehose | Automatic scaling and delivery with optional transformation |
| SQL queries against data in Amazon S3 | Amazon Athena | Serverless interactive querying |
| Managed ETL and metadata catalog | AWS Glue | Crawlers, Data Catalog, and serverless-scale ETL jobs |
Amazon RDS
Amazon RDS is a managed service for traditional relational databases and online transaction processing (OLTP). Supported engines include MySQL, MariaDB, PostgreSQL, Oracle, Microsoft SQL Server, and Aurora.
Important characteristics:
- You select a DB instance class and storage configuration.
- Scaling is primarily vertical: increase the instance size or storage configuration where supported.
- Read replicas provide read scaling for read-heavy workloads.
- Multi-AZ deployments provide high availability and automated failover.
- Encryption at rest uses AWS Key Management Service (AWS KMS).
- Encryption can include database storage, automated backups, read replicas, and snapshots.
- Encryption must be enabled when the DB instance is created; it cannot be added in place to an existing unencrypted instance.
- Manual backups are DB snapshots of the DB instance rather than selective backups of individual databases.
- Maintenance windows are used for operating-system and database-engine patching. Some maintenance operations require downtime or failover.
#### RDS Multi-AZ versus read replicas
| Capability | RDS Multi-AZ | RDS read replica |
|---|---|---|
| Primary purpose | High availability and failover | Read scaling and, in some cases, disaster recovery |
| Replication | Synchronous | Asynchronous |
| Normal application reads | Directed to the primary | Replicas are readable |
| Failover | Automatic when RDS detects an eligible failure | Promotion is generally a manual action |
| Placement | Typically across two Availability Zones in one Region | Same AZ, another AZ, or another Region, depending on engine and configuration |
| Version upgrades | Coordinated with the primary and standby | Can be performed independently from the source |
| Data-loss risk during failover | Designed for no data loss within the synchronous design | Asynchronous lag can result in data loss |
| Default backup behavior | Automated backups are supported | Backups are not automatically configured simply by creating a replica |
A Multi-AZ standby is not a read-scaling target. The standby database engine does not normally serve application reads. Read replicas, by contrast, are active readable copies and are appropriate when the bottleneck is read throughput.
#### RDS backup and encryption considerations
- Automated backups support point-in-time recovery within the configured retention period.
- Manual snapshots do not expire automatically; they remain until deleted.
- Creating a snapshot can briefly suspend I/O, depending on the deployment and engine. For several Multi-AZ engines, the snapshot is taken from the standby to reduce impact on the primary.
- An encrypted DB instance cannot be converted in place to unencrypted. An unencrypted instance can be migrated to an encrypted design by creating an encrypted copy or restoring an unencrypted snapshot as encrypted, subject to the applicable workflow.
- An encrypted read replica must remain encrypted. A replica in the same Region uses the source KMS key; a cross-Region replica uses a KMS key in the destination Region.
- You cannot create an encrypted read replica directly from an unencrypted source, or an unencrypted read replica from an encrypted source.
- Oracle and SQL Server can also support transparent data encryption features, which are separate from RDS storage encryption and may have their own performance implications.
Amazon Aurora
Aurora is an RDS-compatible relational database designed for cloud deployments. It is compatible with MySQL and PostgreSQL and uses a distributed, fault-tolerant storage layer rather than conventional database-attached storage.
Relevant features include:
- Automatic storage growth and distributed storage designed for durability and self-healing.
- Continuous backup and point-in-time recovery.
- Aurora Replicas for in-Region read scaling and automated failover targets.
- Aurora Global Database for cross-Region replication, low-latency reads in secondary Regions, and disaster recovery.
- Aurora MySQL cross-Region replicas for cross-Region read scaling and disaster recovery, with asynchronous replication lag as a consideration.
- Multi-master options for specific write-scaling requirements within a Region.
- Aurora Serverless for variable, intermittent, or unpredictable workloads where fixed capacity is inefficient.
Aurora Replicas and cross-Region engine replicas serve different purposes:
| Feature | Aurora Replica | Aurora MySQL/PostgreSQL cross-Region replica |
|---|---|---|
| Location | Within the same Region | Different Region |
| Replication | Asynchronous at the replica layer, using Aurora’s shared storage architecture | Asynchronous engine-level replication |
| Read scaling | Yes | Yes |
| Automated failover | Yes, within the Aurora cluster | Promotion is generally a manual disaster-recovery action |
| Potential lag/data loss | Designed for rapid in-Region failover | Replication lag can cause some data loss during promotion |
| Version or schema independence | More closely tied to the cluster | Can support more independent version, schema, or replication-delay use cases |
Aurora Serverless is a good fit for development and test systems, infrequently used applications, new applications with unknown capacity needs, and workloads that vary substantially. It is not a universal replacement for provisioned Aurora; compatibility, scaling behavior, and feature support must be checked for the selected Aurora version and configuration.
When Amazon RDS is not the right choice
Use a database on Amazon EC2 when:
- The required database engine is not supported by RDS.
- You need root or operating-system access.
- You need complete control over database installation, configuration, extensions, or patching.
- A third-party or specialized engine must be deployed.
Use other managed services when the data model points elsewhere:
- Amazon S3 is better for large binary objects and durable object storage.
- DynamoDB is better for flexible key-value or document data, very high request rates, and automated horizontal scaling.
- ElastiCache is better for temporary, frequently accessed data rather than the system of record.
The operational tradeoff is significant: EC2 provides maximum flexibility, but the customer becomes responsible for database installation, backups, patching, replication, monitoring, failure recovery, and capacity management.
Amazon ElastiCache
ElastiCache provides managed Redis and Memcached clusters. Both are in-memory key-value stores designed for very low latency and are commonly placed in front of RDS, Aurora, or DynamoDB.
Common use cases include:
- Frequently read, relatively static data.
- Session state.
- Results that are expensive or slow to retrieve from the system of record.
- Workloads that can tolerate stale or evicted data.
- Reducing database read pressure.
#### Memcached versus Redis
| Capability | Memcached | Redis |
|---|---|---|
| Persistence and snapshots | Not supported | Supported, depending on configuration |
| Replication and automatic failover | Not supported | Supported |
| Encryption features | More limited | Supported |
| Multithreading | Supported | Primarily single-threaded command processing per shard |
| Data partitioning | Add nodes to distribute partitions | Cluster mode enabled uses shards |
| Scaling | Larger nodes or more nodes/partitions | Larger nodes, replicas, or additional shards depending on mode |
| Multi-AZ behavior | Nodes can span AZs, but there is no replicated failover model | Replicas can span AZs with automatic failover |
Redis cluster mode disabled uses one primary with replicas and can support read replicas. Redis cluster mode enabled distributes data across shards and allows replicas per shard. The correct choice depends on whether the workload needs persistence, replication, failover, complex Redis data structures, or horizontal partitioning.
A cache should not normally be treated as the authoritative copy of critical data unless the selected service and application design explicitly support that model.
DynamoDB
DynamoDB is a fully managed, serverless NoSQL service supporting key-value and document data models. It is appropriate for high-scale applications that can be designed around known access patterns and partition keys.
Core characteristics:
- Schema flexibility beyond the primary key definition.
- Horizontal scaling through on-demand capacity or provisioned capacity with auto scaling.
- Synchronous replication across multiple facilities within a Region.
- Eventually consistent reads by default, with strongly consistent reads available where supported.
- ACID transactions for coordinated changes across items and tables within the service limits.
- Time to Live (TTL) for automatically expiring items based on a per-item timestamp.
- Global Tables for multi-Region, multi-active replication and local access.
- Point-in-time recovery and on-demand backup and restore.
#### DynamoDB capacity modes
- On-demand capacity: Pay for actual read and write request usage. This is useful for unpredictable or newly launched workloads, though request-rate and scaling behavior still need to be considered.
- Provisioned capacity: Specify expected read and write capacity and pay for the provisioned amount whether fully used or not. This can be more economical for predictable traffic.
#### DynamoDB Streams and DAX
DynamoDB Streams records an ordered sequence of item-level changes for a limited retention period of up to 24 hours. The stream can capture:
- Keys only.
- The new item image.
- The old item image.
- Both old and new images.
Streams are useful for event-driven processing, audit workflows, search indexing, replication logic, and triggering AWS Lambda functions.
DynamoDB Accelerator (DAX) is a managed, highly available in-memory cache designed specifically for DynamoDB. It can reduce read latency from milliseconds to microseconds and supports DynamoDB-compatible APIs, reducing application changes. DAX can support read-through and write-through caching behavior. A write is cached only after the corresponding DynamoDB write succeeds.
DAX is preferable when the application is already built for DynamoDB and needs a DynamoDB-specific cache. ElastiCache is more flexible when the cache must support multiple data sources, richer cache-control logic, or other Redis/Memcached use cases; however, the application generally needs explicit cache integration.
Amazon Redshift
Amazon Redshift is a SQL-based relational data warehouse for online analytical processing (OLAP). It is designed for complex queries over large volumes of structured and semi-structured data, rather than high-volume transactional workloads.
Use Redshift when the requirements include:
- Aggregations across large datasets.
- Business intelligence and reporting.
- SQL access through standard tools.
- A structured analytical model and repeated queries.
- Managed provisioning, patching, backups, and scaling.
Redshift continuously backs up data to Amazon S3 and maintains redundant copies within the service architecture. Redshift Spectrum can query data stored directly in S3, allowing a warehouse to analyze data in a data lake without loading every object into local Redshift storage.
Do not select Redshift simply because the data volume is large. For ad hoc SQL queries against files in S3, Amazon Athena may be simpler. For transactional workloads, use RDS, Aurora, or DynamoDB based on the data model.
Amazon EMR
Amazon EMR is a managed cluster platform for frameworks such as Apache Hadoop and Apache Spark. It is useful for large-scale distributed processing, analytics, data transformation, and ETL.
Compared with fully serverless analytics services, EMR offers more control over cluster frameworks and processing environments, but it introduces cluster sizing, lifecycle, and operational decisions. It is a strong candidate when an organization already uses Hadoop/Spark ecosystems or needs custom distributed-processing behavior.
Kinesis Data Streams
Kinesis Data Streams provides durable, real-time ingestion of streaming records. Producers write records to a stream, where records are retained in shards for a default period of 24 hours and can be retained for up to seven days.
Key decisions:
- Shard capacity and partition-key distribution affect throughput.
- Consumers control when and how records are processed.
- Multiple consumer applications can process the same stream independently.
- Processing typically has sub-second latency, often around hundreds of milliseconds.
- The Kinesis Client Library (KCL) coordinates shard processing. Each shard is assigned to one KCL worker at a time, while one worker can process multiple shards.
Kinesis Data Streams is appropriate when records must remain available for later or repeated processing. It is different from Firehose, which focuses on managed delivery to a destination.
Amazon Data Firehose
Amazon Data Firehose captures, optionally transforms, and delivers streaming data to configured destinations. It automatically handles scaling and does not expose shards for customers to manage.
Destinations can include Amazon S3, Amazon Redshift, OpenSearch, Splunk, Datadog, MongoDB, New Relic, and supported HTTP endpoints. AWS Lambda can optionally transform records before delivery.
Firehose is near real time rather than immediate real time. Delivery commonly has a delay of approximately one minute or more because records are buffered and batched. Choose Firehose when the primary requirement is managed delivery and minimal operational overhead, not custom consumer-controlled stream processing.
Amazon Kinesis Data Analytics
Kinesis Data Analytics enables SQL-based processing of streaming data from sources such as Kinesis Data Streams and Firehose. Results can be sent to another stream, Firehose, or Lambda.
It is useful when streaming data must be filtered, aggregated, or transformed continuously using SQL without building a complete custom stream-processing application.
Amazon Athena and AWS Glue
Amazon Athena is a serverless query service for analyzing data in Amazon S3 using SQL. It can query multiple file formats and uses the AWS Glue Data Catalog for database, table, and schema metadata.
Athena performance and cost depend heavily on how much data each query scans. Common optimization techniques include:
- Partition data according to common query predicates.
- Use columnar formats such as Apache Parquet or Apache ORC.
- Compress data.
- Avoid many very small files; use appropriately sized objects.
- Select only required columns rather than using
SELECT *. - Use bucketing where it benefits the access pattern.
- Use appropriate filtering, grouping, ordering, and approximate functions where exact results are unnecessary.
AWS Glue is a managed ETL service and metadata platform. Glue crawlers inspect data stores and create or update tables in the Glue Data Catalog. Glue ETL jobs run on a managed, scalable Apache Spark environment and can work with data in S3, Redshift, RDS, and other supported sources.
A crawler discovers metadata; it does not automatically perform the full business transformation process. ETL jobs use catalog tables as sources and targets to transform and move data.
Exam-Relevant Takeaways
- Choose Multi-AZ for RDS high availability and automatic failover; choose read replicas for read scaling.
- Multi-AZ replication is synchronous; read-replica replication is asynchronous.
- A read replica can be placed in another Region and manually promoted for disaster recovery.
- RDS encryption must be enabled at creation and relies on KMS.
- RDS snapshots are instance-level and manual snapshots do not expire automatically.
- Choose Aurora when a cloud-optimized relational database, distributed storage, or Aurora-specific scaling is required.
- Aurora Replicas are in-Region failover/read-scaling targets; cross-Region replicas address geographic distribution and disaster recovery.
- Choose EC2-hosted databases when unsupported engines or operating-system access are mandatory.
- Memcached is a simple, nonpersistent cache; Redis provides replication, persistence, snapshots, and automatic failover.
- DynamoDB supports key-value and document models, serverless scaling, TTL, Streams, transactions, and Global Tables.
- DAX is specifically optimized for DynamoDB and can often be adopted without changing DynamoDB API calls.
- Redshift is for OLAP and data warehousing, not ordinary transactional processing.
- Athena queries S3 directly; Redshift provides a managed analytical warehouse; EMR runs distributed Hadoop/Spark workloads.
- Kinesis Data Streams provides consumer-controlled real-time processing with shards and retention.
- Firehose automatically delivers streaming data to destinations but is near real time and does not provide the same consumer-control model.
- Athena cost and performance improve when queries scan less data through partitioning, compression, and columnar formats.
Architecture Decision Guide
| Scenario | Recommended design | Why |
|---|---|---|
| E-commerce transactions require relational constraints and failover | RDS or Aurora with Multi-AZ | OLTP and high availability are the main requirements |
| Reporting queries are slowing the transactional database | RDS/Aurora primary plus read replicas, or load data into Redshift for analytics | Separates read scaling or OLAP from transactional traffic |
| Application has unpredictable request volume and flexible item structure | DynamoDB on-demand capacity | Serverless operation and flexible scaling reduce capacity management |
| Application requires multi-Region active-active key-value access | DynamoDB Global Tables | Provides multi-Region replication and local access |
| Users repeatedly request the same expensive database results | ElastiCache in front of RDS/Aurora | Reduces database load and latency |
| Existing DynamoDB application needs lower read latency with minimal code change | DAX | DynamoDB-compatible managed cache |
| Data must be delivered automatically to S3 or Redshift | Kinesis Data Firehose | Managed buffering, scaling, transformation, and delivery |
| Several applications need to process the same stream at different times | Kinesis Data Streams | Retention and consumer-controlled processing |
| Analysts need ad hoc SQL against files in S3 | Athena with Glue Data Catalog | Serverless querying without loading data into a warehouse |
| Complex recurring BI workloads require a warehouse | Redshift, optionally with Spectrum | Optimized for analytical SQL and S3 data-lake access |
| Custom Spark/Hadoop ETL is required | EMR | Managed distributed-processing platform |
| Specialized commercial database requires OS-level customization | Database on EC2 | Full control outweighs the operational burden |
Common Exam Traps
- Confusing Multi-AZ with read replicas: Multi-AZ improves availability; it does not normally scale reads.
- Assuming read replicas are synchronous: They use asynchronous replication and can lag.
- Treating a standby as readable: The RDS Multi-AZ standby is not the normal target for application reads.
- Forgetting encryption timing: RDS encryption must be configured at creation and cannot simply be toggled on later.
- Using ElastiCache as the system of record: Cached data can be evicted, stale, or unavailable during failure.
- Selecting Memcached for persistence or automatic failover: Those requirements point toward Redis.
- Choosing Redshift for OLTP: Redshift is an analytical warehouse, not a replacement for an application transaction database.
- Confusing Athena and Redshift: Athena queries objects in S3; Redshift stores and processes warehouse data, although Spectrum can query S3.
- Confusing Kinesis Data Streams and Firehose: Streams expose shards and consumer control; Firehose provides managed delivery with buffering.
- Assuming Firehose is strictly real time: It is near real time and commonly buffers data before delivery.
- Ignoring Athena scan costs: Poorly partitioned, uncompressed row-oriented data can make queries slow and expensive.
- Assuming DynamoDB is completely schema-free: Tables still require a defined primary key, and efficient designs depend on access patterns and partition-key distribution.
- Assuming TTL deletes are immediate: TTL expiration is asynchronous and should not be treated as a precise deletion deadline.
- Assuming Glue crawlers perform all ETL: Crawlers populate metadata; Glue ETL jobs perform transformations.
Real-World Engineer Notes
- Design RDS and Aurora maintenance, backup, and failover procedures before production launch. High availability does not eliminate the need to test recovery.
- Monitor replica lag, storage capacity, connections, I/O, and database-specific performance metrics. A read replica that is significantly behind may not be suitable for current reads or disaster recovery.
- Use separate KMS keys and tightly scoped IAM permissions where cross-Region encryption and administrative separation are required.
- For DynamoDB, model tables from access patterns first. A theoretically flexible schema can still perform poorly if partition keys create hot partitions or queries require inefficient scans.
- Use idempotent consumers for Streams and Kinesis processing. Records may be retried, and downstream writes should tolerate duplicate processing.
- Treat cache invalidation, expiration, and stale data behavior as explicit application requirements. A cache strategy without an eviction and refresh policy is incomplete.
- For Athena, establish an S3 data-lake layout with predictable prefixes, partitions, compression, and columnar output as part of the ingestion pipeline.
- Use Redshift for repeated analytical workloads with warehouse-style governance and workload management; use Athena for flexible, intermittent exploration.
- Use Firehose when operational simplicity matters more than sub-second processing. Use Data Streams when consumers need replay, custom processing, or multiple independent applications.
Quick Reference Summary
- RDS: Managed relational OLTP database.
- Aurora: Cloud-optimized MySQL/PostgreSQL-compatible relational database.
- RDS Multi-AZ: Synchronous standby and automatic failover.
- RDS read replica: Asynchronous readable copy for read scaling or DR.
- EC2 database: Maximum engine and OS control with maximum management responsibility.
- ElastiCache: Managed Redis or Memcached in-memory cache.
- DAX: DynamoDB-specific managed cache.
- DynamoDB: Serverless key-value/document database with horizontal scaling.
- Redshift: Managed SQL data warehouse for OLAP.
- EMR: Managed Hadoop/Spark platform for distributed processing and ETL.
- Kinesis Data Streams: Sharded, consumer-controlled real-time stream.
- Kinesis Data Firehose: Automatically scaled near-real-time delivery pipeline.
- Kinesis Data Analytics: SQL processing for streaming data.
- Athena: Serverless SQL queries directly against S3.
- Glue: Managed ETL plus the Glue Data Catalog.
Flashcards
1. What is the primary distinction between RDS Multi-AZ and an RDS read replica?
Answer: Multi-AZ is for high availability and automatic failover using synchronous replication. A read replica is for read scaling or disaster recovery using asynchronous replication.
2. Can an RDS standby in a Multi-AZ deployment serve application reads?
Answer: No. The standby is maintained as a failover target, not as a normal read endpoint.
3. When should a database run on EC2 instead of RDS?
Answer: When the engine is unsupported, root or OS access is required, or extensive database and instance customization is necessary.
4. What does RDS encryption protect?
Answer: Depending on the configuration, it protects database storage, backups, snapshots, and read replicas using KMS-managed encryption.
5. Which ElastiCache engine supports persistence, replication, and automatic failover?
Answer: Redis. Memcached is simpler and does not provide those capabilities.
6. What are DynamoDB’s two capacity modes?
Answer: On-demand, which charges for actual requests, and provisioned, which charges for configured read and write capacity.
7. What is DynamoDB Streams used for?
Answer: Capturing an ordered sequence of item-level changes for event processing, auditing, replication workflows, or Lambda triggers.
8. What is the main benefit of DAX?
Answer: It provides a managed in-memory cache optimized for DynamoDB and uses DynamoDB-compatible APIs to reduce application changes.
9. Which service is designed for OLAP and business intelligence queries over large datasets?
Answer: Amazon Redshift.
10. What is the key operational difference between Kinesis Data Streams and Firehose?
Answer: Data Streams uses customer-managed shards and consumer-controlled processing. Firehose automatically scales and delivers records to configured destinations.
11. What is the typical latency distinction between Data Streams and Firehose?
Answer: Data Streams supports near-real-time processing with sub-second latency, while Firehose commonly buffers data and provides delivery in roughly a minute or more.
12. How can Athena query costs be reduced?
Answer: Partition data, compress it, use Parquet or ORC, avoid small files, select only required columns, and filter data effectively.
13. What does a Glue crawler do?
Answer: It discovers data and creates or updates table metadata in the Glue Data Catalog. It does not replace the transformation logic of an ETL job.
14. Which service is best for custom Apache Spark or Hadoop processing?
Answer: Amazon EMR.
Practice Questions
Question 1
An online banking application uses PostgreSQL on Amazon RDS. The business requires automatic failover to another Availability Zone with no application changes. The standby must not serve normal application queries. Which design meets the requirement?
A. Create an asynchronous read replica in another Availability Zone
B. Configure an RDS Multi-AZ deployment
C. Use DynamoDB Global Tables
D. Place PostgreSQL on an EC2 instance with an EBS snapshot schedule
Correct answer: B. Configure an RDS Multi-AZ deployment.
Explanation: Multi-AZ provides a synchronous standby and automatic failover. Read replicas are readable and primarily intended for read scaling; their asynchronous replication makes them a different solution.
Question 2
A new application stores user profiles and session records. Traffic is unpredictable, the attributes vary by user, and the application must scale without managing database instances. Which option is most appropriate?
A. RDS with a large provisioned instance
B. Redshift with scheduled resize operations
C. DynamoDB using on-demand capacity
D. ElastiCache Memcached as the only data store
Correct answer: C. DynamoDB using on-demand capacity.
Explanation: DynamoDB supports key-value and document data, flexible attributes, serverless operation, and on-demand capacity for unpredictable traffic. A cache should not be the sole authoritative store for durable user data.
Question 3
A company receives application events from thousands of producers. Three independent applications must process the same events, and one consumer may need to replay events from earlier in the retention window. The company does not want to manage delivery buffering to a final destination. Which service should ingest the events?
A. Kinesis Data Streams
B. Kinesis Data Firehose
C. Amazon Athena
D. AWS Glue crawler
Correct answer: A. Kinesis Data Streams.
Explanation: Data Streams retains records in shards and allows multiple consumer applications to process data independently and replay records. Firehose is primarily a managed delivery service and does not provide the same consumer-controlled processing model.
Question 4
Analysts run occasional SQL queries against compressed files in Amazon S3. Queries are slow and scan the entire dataset. Which changes should improve performance and reduce cost? (Choose two.)
A. Convert data to Apache Parquet or ORC
B. Partition data according to common query filters
C. Move all files to ElastiCache
D. Replace Athena with an RDS Multi-AZ instance
E. Use SELECT * to allow Athena to optimize automatically
Correct answers: A and B.
Explanation: Columnar formats reduce the data read for column-specific queries, while partitioning allows Athena to skip unrelated objects. Selecting only needed columns is also beneficial; SELECT * generally increases scanned data.
Question 5
An organization needs a commercial database engine that RDS does not support. The database vendor requires root-level operating-system access and custom kernel and filesystem configuration. Which architecture is most appropriate?
A. Amazon Aurora Serverless
B. Amazon DynamoDB with DAX
C. A database deployed on Amazon EC2
D. Amazon Redshift with Spectrum
Correct answer: C. A database deployed on Amazon EC2.
Explanation: EC2 provides control over the operating system, database engine, and instance configuration. The organization must accept responsibility for patching, backups, monitoring, replication, and recovery.