4 of the 5 questions we have for this objective, shown with the answer and the reasoning.
Design cost-optimized database solutions
Ellery Analytics provides an internal reporting portal backed by an Amazon Aurora MySQL cluster with a db.r6g.2xlarge writer and one reader. Usage data shows the database is busy for about 3 hours on weekday mornings when managers run reports, idle for the rest of the day, and almost completely idle on weekends, yet the instances are billed every hour. The company wants to keep Aurora MySQL and the current schema while paying mainly for the hours the database is actually used.
Which solution will meet these requirements MOST cost-effectively?
- APurchase 1-year Reserved DB Instances for the writer and reader.Reserved DB Instances reduce the hourly rate but commit to paying for every hour, so the roughly 90 percent idle time is still charged.
- BMigrate the reporting data to Amazon DynamoDB with on-demand capacity.DynamoDB on-demand charges only for requests, but the requirement is to keep Aurora MySQL and the relational schema, and reporting queries with joins are a poor fit for a key-value store.
- CStop the Aurora cluster every afternoon with a scheduled Lambda function and start it each morning.Aurora clusters can be stopped for at most 7 days and take several minutes to start, and managers who run an ad hoc report in the afternoon would find the database unavailable; it also still pays full price during the busy mornings for both instances.
- DConvert the writer and reader to Aurora Serverless v2 instances with a low minimum capacity in Aurora capacity units.Aurora Serverless v2 instances scale capacity in fine-grained ACU increments within seconds, so the cluster bills near the minimum ACU during idle periods (and can even scale to 0 ACU and pause when the minimum is set to 0) and scales up only during the morning reporting window, all without changing the engine, schema, or endpoints.
Why: Aurora Serverless v2 is the cost-optimized choice for relational workloads with intermittent or highly variable load because capacity, and therefore price, follows demand in half-ACU steps rather than fixed instance sizes. It keeps full Aurora MySQL or PostgreSQL compatibility, so the schema and application are unchanged, and it can be mixed with provisioned instances in the same cluster. The deciding constraints are long idle periods, a requirement to keep Aurora, and no tolerance for an unavailable database when someone runs a report at an unexpected time. The trap is a reserved pricing discount, which lowers the rate on hours that should not be billed in the first place.
Design cost-optimized database solutions
Northwind Turbines collects vibration and temperature readings from 15,000 wind turbines every second, roughly 1.3 billion data points per day. Engineers query the most recent 24 hours constantly, run trend queries over the last 90 days a few times a day, and must keep 5 years of history that is rarely queried. The readings are currently inserted into an Amazon RDS for PostgreSQL instance whose storage and IOPS cost grows every month. The company wants a purpose-built, managed database that lowers cost for this pattern.
Which solution will meet these requirements MOST cost-effectively?
- AMove the readings to Amazon Redshift and query them with SQL.Redshift is a columnar data warehouse for analytical queries over large data sets, but it is not optimized for high-rate per-second ingestion with automatic tiering by age, and a continuously running cluster is expensive for a single telemetry use case.
- BMove the readings to Amazon DynamoDB with a time-to-live attribute set to 5 years.DynamoDB can absorb the writes but charges the same per GB for 5 years of history, offers no time-window aggregation functions, and would require a large provisioned write capacity or on-demand write charges for 1.3 billion items a day.
- CMove the readings to an Amazon Timestream for InfluxDB 3 Enterprise cluster and set a 5-year retention on the database.Timestream for InfluxDB 3 is the managed purpose-built time series engine AWS now offers to new customers: it caches recent data in memory on the cluster nodes for the hot 24-hour queries, persists all history as compressed columnar Parquet in low-cost S3-backed object storage billed only for the data actually stored, applies retention automatically, and has native time-window and downsampling functions for the 90-day trend queries.
- DKeep RDS for PostgreSQL and move the instance to the io2 storage type for better IOPS.io2 raises the storage cost rather than lowering it and does nothing about the growth of 5 years of row-oriented history in a general-purpose relational engine.
Why: Purpose-built database types exist because storing data in the format that matches its access pattern is cheaper than forcing it into a general-purpose engine: time series data is append-only, queried by time range, and loses value with age, which a time series database exploits with in-memory caching of recent data, compressed columnar storage of history in object storage, and automatic retention. Amazon Timestream for LiveAnalytics, with its memory store and magnetic store tiers, stopped accepting new customers in June 2025, so Timestream for InfluxDB (whose InfluxDB 3 engine stores data as Parquet in Amazon S3) is the current managed time series choice. Columnar stores like Redshift are the right answer when the scenario emphasizes complex analytical queries across many dimensions, not high-frequency ingestion with aging data. The deciding constraints are per-second ingestion, hot recent data, and years of cold history. The trap is choosing DynamoDB for the write rate alone and ignoring that it has no age-based storage tiering.
Design cost-optimized database solutions
Bellhaven Retail runs a 1.5 TB Microsoft SQL Server 2019 database in an on-premises data center for its order management system. The company plans to move it to Amazon Aurora MySQL-Compatible Edition to remove licensing cost and wants the cutover downtime to be under 30 minutes. A 1 Gbps AWS Direct Connect connection is already in place. The database contains several hundred tables, views, and stored procedures.
Which solution will meet these requirements with the LEAST operational effort?
- ATake a native SQL Server backup, restore it to Amazon RDS for SQL Server, then export the tables to CSV and import them into Aurora MySQL.A native backup and restore works only between SQL Server engines, and a CSV export and import converts no stored procedures or views and requires the source to be frozen for hours during the copy.
- BUse AWS Schema Conversion Tool to convert the schema and code objects to Aurora MySQL, then use AWS Database Migration Service with a full load plus change data capture task to migrate the data and keep it in sync until cutover.SCT handles the heterogeneous schema and stored procedure conversion and reports what needs manual work, while a DMS full-load-and-CDC task copies the data over Direct Connect and replicates ongoing changes so the final cutover is only a brief switch of connection strings.
- CUse AWS Application Migration Service to replicate the database server into EC2 and then export the data to Aurora MySQL.Application Migration Service performs lift-and-shift rehosting of entire servers; it does not convert a SQL Server schema to MySQL and would leave the licensing cost in place on EC2.
- DShip a copy of the database on an AWS Snowball Edge device and load it into Aurora MySQL with the mysqlimport utility.A 1.5 TB copy over an existing 1 Gbps Direct Connect takes a few hours, so a Snow device adds delay for no benefit, and an offline copy cannot capture the changes that occur before cutover.
Why: A heterogeneous database migration has two distinct problems: converting the schema and code between engines, which AWS Schema Conversion Tool automates as far as possible, and moving the data with minimal downtime, which AWS Database Migration Service handles through a full load followed by continuous change data capture. Running the two together lets the source keep serving traffic until the target is in sync, so the cutover window is minutes. The deciding constraints are a change of engine, a short downtime window, and existing network capacity that makes online transfer practical. The trap is any approach that copies the data as a snapshot without replicating changes, which forces a long freeze of the source.
Design cost-optimized database solutions
Greywater Utilities runs an Amazon RDS for MySQL instance named billing-db with 2 TB of storage. The instance has automated backups set to the maximum 35-day retention, and a nightly script also takes a manual DB snapshot that is never deleted, so the account now holds more than 900 manual snapshots. The business requirement is point-in-time recovery for the last 7 days and one monthly snapshot retained for 1 year for audit purposes. The company wants to reduce backup storage cost while meeting these requirements with minimal ongoing administration.
Which two actions should a solutions architect take? Each correct answer presents part of the solution.
- AReduce the automated backup retention period on billing-db to 7 days.Automated backups and transaction logs provide point-in-time recovery for the retention window, so a 7-day window meets the requirement and stops paying for 28 extra days of backup storage.
- BDisable automated backups on billing-db and rely on the manual snapshots.Manual snapshots are discrete points in time and cannot provide point-in-time recovery, which requires automated backups with transaction logs.
- CReplace the nightly snapshot script with an AWS Backup plan that creates a monthly snapshot and deletes it after 1 year, and delete the existing manual snapshots that are older than 1 year.An AWS Backup plan enforces the monthly frequency and the 1-year retention automatically, and cleaning up the backlog removes storage that no requirement justifies.
- DCopy every manual snapshot to a second Region for durability.Cross-Region copies double the snapshot storage and add data transfer charges without addressing retention or any stated requirement.
- EConvert the instance to Multi-AZ so that the standby holds the backup copies.A Multi-AZ standby provides failover, not backups; it adds instance cost and changes nothing about snapshot storage or retention.
Why: Backup cost is driven by frequency multiplied by retention, so the first design question is what the business actually requires: here a 7-day point-in-time window and twelve monthly audit snapshots. Automated backups are the only mechanism for point-in-time recovery and should be set to exactly the required window, while longer-term audit copies are best handled by an AWS Backup plan whose lifecycle deletes them on schedule. Manual snapshots never expire on their own, which is why unmanaged scripts accumulate hundreds of copies; moving them under a managed plan with an explicit retention removes that silent cost. The trap is turning off automated backups to save money, which sacrifices the recovery capability the requirement actually asks for.