SAP-C03 Storage and Database Cost Optimization: S3 Tiering and Lifecycle, EFS, EBS gp3, DynamoDB, Aurora I/O-Optimized, Database Savings Plans, Backup and Log Costs

S3 Intelligent-Tiering cuts storage cost by moving each object between access tiers based on that object's own access history, so you do not need to know or analyse the access pattern in advance. It charges no retrieval fees, has no minimum storage duration, and moves an object back to the Frequent Access tier as soon as it is read. In exchange it adds a small monthly monitoring and automation charge per object.

Automatic tiers versus opt-in archive tiers

The three automatic tiers are always on and every read is synchronous. The two archive tiers are activated with a bucket-level Intelligent-Tiering archive configuration (optionally filtered by prefix or tag). Once an object is in one of them, a GetObject fails with InvalidObjectState until the object is restored with RestoreObject; a restore moves it back to Frequent Access. Deleting the archive configuration stops new archiving, but objects already archived stay there until they are restored.

When it fits and when it does not

• Fits: data lakes, media libraries and user content whose access is unknown or changes (a dataset that sits idle and then is queried heavily during an audit), when every read must stay synchronous and you want no retrieval fees.
• Activate the archive tiers only when the application can tolerate asynchronous restores; otherwise rely on Archive Instant Access, which already gives a low price with millisecond reads.
• Small objects: objects smaller than 128 KB are not monitored or tiered; they always stay in Frequent Access (and do not pay the monitoring charge). For large objects the per-object charge is negligible.
• Objects read about every month rarely stay idle for 30 days, so most of them sit in Frequent Access at the S3 Standard price and still pay the monitoring charge. When the access pattern is known, a Lifecycle rule to a specific class is usually cheaper.

You choose S3 storage classes in a Lifecycle policy by matching each age band of the data to the cheapest class that still meets that band's retrieval time, read frequency and resilience needs, and by checking that each class's minimum storage duration is met. Lifecycle rules move objects by age (days since creation, or since becoming noncurrent), not by access, so they suit data whose access pattern is known in advance.

Reading a requirement into a class

• "Must load within milliseconds" rules out the two archive classes. Between the instant classes, read frequency decides: monthly reads favour the IA classes, quarterly reads favour Glacier Instant Retrieval, because its higher retrieval fee is paid less often.
• "A few hours is acceptable" points at Glacier Flexible Retrieval; "12 hours is acceptable" points at Deep Archive, the cheapest class whose standard retrieval meets it. Paying for millisecond access a requirement does not ask for is the most common way an otherwise valid design costs more.
• "Losing the data if an AZ is lost is acceptable" (thumbnails, renditions or anything regenerable from a master copy) is what makes One Zone-IA the cheapest instant-access choice.
• Minimum storage durations are billed even if an object is deleted or transitioned earlier, so a schedule should keep data in each class at least that long. Lifecycle also does not move objects into Standard-IA or One Zone-IA until they are at least 30 days old.

The transition waterfall

Lifecycle only moves objects "down" towards colder classes: from S3 Standard to any class, from Standard-IA to Intelligent-Tiering, One Zone-IA or the Glacier classes, and so on down to Deep Archive. It never moves objects back up, and it cannot move objects from Intelligent-Tiering to Standard-IA. To bring archived data back to a warmer class you restore it and copy it.

S3 costs more than its per-GB price suggests when a bucket holds billions of tiny objects, keeps every overwritten version, or keeps the parts of abandoned multipart uploads. Lifecycle can both cause and remove these charges, so an architect checks them before trusting a per-GB estimate.

Small objects

• Transition requests are billed per object. Moving a billion 8 KB objects costs a billion transition requests, whatever their total size.
• Archive metadata overhead: every object stored in Glacier Flexible Retrieval or Deep Archive carries about 40 KB of extra billed metadata: 8 KB at the S3 Standard rate (for the object's name and metadata) and 32 KB at the archive class rate. For a 4-16 KB object that overhead is several times the object itself.
• 128 KB minimum billable size applies to Standard-IA, One Zone-IA and Glacier Instant Retrieval: a smaller object is billed as if it were 128 KB.
• Default minimum transition size (since September 2024): new Lifecycle configurations do not transition objects smaller than 128 KB to any storage class by default, because the transition can cost more than it saves. Configurations created earlier keep their old default, which let small objects move into the Glacier archive classes. To include or exclude small objects explicitly, add an ObjectSizeGreaterThan / ObjectSizeLessThan filter to the rule or set the x-amz-transition-default-minimum-object-size header on the configuration.

The fix for tiny-object archives is to aggregate small objects into larger ones (for example batching telemetry into compressed files) before they are archived, or to filter them out of the transition by size. A rule that seems to "ignore" small objects in a new bucket is usually the 128 KB default working as designed.

Versioned buckets and multipart uploads

Every overwrite in a versioned bucket keeps the previous object as a full-size noncurrent version, so a frequently overwritten bucket can cost several times its visible size. The cost-optimal pattern keeps current versions where they are, moves noncurrent versions to the cheapest class that meets the restore time, and expires them at the end of the required recovery window. Suspending versioning does not delete existing versions and removes the ability to recover overwrites.

Amazon EFS lifecycle policies reduce file storage cost by moving files that have not been accessed for a set period from EFS Standard into the cheaper EFS Infrequent Access (IA) and EFS Archive storage classes of the same file system. Paths, mount targets and applications do not change: a tiered file is read at the same path, with higher first-byte latency and a per-GB data access charge.

• Set the IA timer longer than the real access interval. A file read every month that tiers after 7 days spends most of its life in IA and pays IA access charges and latency on every read.
• Use On first access for files that become hot again. With the default (None), files already in IA stay there even if they are read repeatedly; lengthening the IA timer only affects files that have not tiered yet.
• Files smaller than 128 KiB are not tiered, and metadata always stays in Standard.
• Throughput mode (Elastic, Provisioned, Bursting) changes performance and how throughput is billed, not the per-GB access charge for files in IA or Archive.

Moving files to S3 or replacing EFS can be cheaper per GB but changes how the application reads its data; backup tiering (AWS Backup cold storage) lowers the cost of backups, not of the live file system.

You choose EBS volumes for cost by buying exactly the capacity, IOPS and throughput the workload needs, on the cheapest volume type that delivers them. In practice that means gp3 by default, io2 only when the workload needs an io2-only property, and the HDD types for large sequential data.

Typical cost moves

• gp2 to gp3 in place: Elastic Volumes changes the volume type, size, IOPS and throughput while the volume stays attached and in use, with no snapshot-and-swap. A gp2 volume that never needs more than 3,000 IOPS and 125 MiB/s gets that performance from the gp3 baseline at a lower price. (After a modification you must wait before modifying the same volume again.)
• Over-sized gp2 bought for IOPS: a 6 TiB gp2 volume holding 500 GiB of data exists only to buy its 16,000 IOPS (gp2's cap, reached from about 5,334 GiB at 3 IOPS per GiB). A right-sized gp3 volume provisions the same IOPS on far less capacity (16,000 IOPS needs at least 32 GiB at 500 IOPS per GiB).
• gp3 throughput needs IOPS: because throughput cannot exceed 0.25 MiB/s per provisioned IOPS, a target of T MiB/s needs at least T ÷ 0.25 IOPS. At the 3,000 IOPS baseline the ceiling is 750 MiB/s; 1,200 MiB/s needs at least 4,800 IOPS; 2,000 MiB/s needs 8,000.
• io2 to gp3: if the workload tolerates single-digit millisecond latency and gp3 durability (99.8-99.9%), does not use Multi-Attach and fits within gp3 limits, one gp3 volume is cheaper and simpler than io2 or a RAID 0 stripe. The gp3 maximums were raised in 2025 (from 16,000 IOPS and 1,000 MiB/s), so striping several gp3 volumes is rarely needed now.
• HDD for sequential data: st1 and sc1 are much cheaper per GiB but deliver poor random IOPS and cannot be boot volumes. st1 tops out at 500 MiB/s per volume, so a sustained higher sequential rate needs gp3. Check scan windows from the per-TiB numbers: a 12 TiB sc1 volume bursts at its 250 MiB/s cap, so a full sequential read takes about 14 hours (12 × 1,048,576 MiB ÷ 250 MiB/s ÷ 3,600 s); compare that with the scan window before choosing sc1 over st1.

You optimize DynamoDB cost with three independent choices: the capacity mode (how throughput is billed), reserved capacity (a commitment discount on provisioned throughput) and the table class (the trade-off between storage price and request price).

• Read the bill first. If storage is the larger part of a table's cost, Standard-IA usually wins; if throughput dominates, it loses.
• Combine the rules: on-demand tables cannot use reserved capacity, and neither can Standard-IA tables. Moving a table that is still covered by a reservation to Standard-IA means paying the unused reservation plus Standard-IA request prices, so time a class change to the end of the reservation term.
• Table class and capacity mode can both be changed on a live table without downtime (within service limits on how often), so they are reversible decisions; a reservation is not.
• Database Savings Plans (below) are an alternative commitment that also covers DynamoDB usage, but a workload is covered by either reserved capacity or the plan, not both.

You optimize Aurora cost by choosing the storage configuration that matches the cluster's I/O share of spend, and the compute model that matches how often the cluster is busy.

Aurora Standard versus Aurora I/O-Optimized

• The storage configuration is a cluster setting, not a migration: the same cluster volume is billed differently, no data is copied and the application does not change. It works with provisioned instances and Serverless v2, and reserved DB instances keep applying.
• You can switch from Standard to I/O-Optimized only once every 30 days; you can switch back to Standard at any time. It is a monthly-scale decision, not something to toggle around a weekly batch.
• On instances without local NVMe storage the switch causes no downtime; on NVMe-based instance classes it restarts the database engine.
• Aurora Optimized Reads is different: NVMe-based instance classes (such as db.r6gd and db.r6id) use local storage for tiered caching and temporary objects to speed up read-heavy and complex queries. It is a performance feature; it does not remove per-request I/O billing on Aurora Standard.

Aurora Serverless v2 and auto-pause

Aurora Serverless v2 bills compute in Aurora capacity units (ACUs) per second and scales between a minimum and maximum capacity. Setting the minimum capacity to 0 ACUs enables auto-pause: after a configurable period with no user connections, the instance pauses, instance charges stop (storage is still billed) and the next connection resumes it, typically in about 15 seconds and longer after a long pause (more than 24 hours). Any non-zero minimum, such as 0.5 ACU, turns auto-pause off and bills that capacity around the clock.

An instance cannot pause while something keeps it busy. Common blockers:

• Open connections, including the connections an RDS Proxy keeps to every instance in the cluster.
• Binary log or logical replication, being the primary cluster of an Aurora global database, and zero-ETL integrations.
• Being a secondary cluster of an Aurora global database (its instances never auto-pause), or having any provisioned instance in the cluster, which keeps a Serverless v2 writer running.

The auto-pause interval is configurable from 300 seconds (5 minutes, the default) up to 86,400 seconds (24 hours); a shorter interval only shortens the wait after the last connection closes, it never overrides a blocker. Reader placement in failover tiers changes how readers follow the writer, not whether the cluster can pause. For dev and test fleets with ad hoc use, Serverless v2 with a 0 ACU minimum replaces stop/start schedulers (which do not fit unpredictable use) and is cheaper than reserving instances that sit idle.

You buy reserved DB instances when the engine, Region and instance family will stay fixed for the term and you want the deepest discount, and a Database Savings Plan when the database estate will change engine, family, size or Region during the term.

• Size flexibility means a reservation for one size in a family (for example db.m7g) applies proportionally to other sizes in that family, so growth from db.m7g.large to db.m7g.xlarge is covered by adding reservations, not by a second kind of commitment.
• Do not stack a Database Savings Plan with reserved DB instances or DynamoDB reserved capacity on the same usage; one of them would go unused.
• Compute Savings Plans cover EC2, Fargate and Lambda, not RDS or Aurora. EC2 pricing models in general are covered in the pricing-models lesson for Task 3.1.
• Reservations bought for clusters that do not exist yet pay for nothing until they do; reservations also discount idle hours, so they do not help a mostly idle database.

You keep backups cost-optimized by keeping each recovery point only as long as policy requires, keeping recent ones in warm storage while they are restored often, and moving long-kept ones to a colder tier only where the resource type supports it and the tier is actually cheaper.

AWS Backup lifecycle and cold storage

• A backup rule's lifecycle sets when to move to cold storage and when to delete. Cold storage has a 90-day minimum, so retention must be at least the transition day plus 90 (a 200-day transition with 250-day retention is rejected).
• Transition after the frequent-restore window: moving too early sends routine restores to cold storage, and for incrementally backed-up resources AWS recommends keeping backups warm for at least 8 days so incremental chains are not broken into extra full backups.
• Only some resource types support cold storage. Amazon EFS (stays incremental in cold), DynamoDB (only with AWS Backup advanced DynamoDB features turned on), and Amazon EBS through EBS Snapshots Archive (which needs a monthly or less frequent schedule and converts snapshots to full copies) are examples. Amazon RDS and Aurora snapshots do not support cold storage: a rule's transition setting has no effect on them, and they stay at warm rates until deletion. Cost estimates that assume a plan-wide transition will undercount.

Amazon Data Lifecycle Manager and EBS Snapshots Archive

• Data Lifecycle Manager (DLM) automates EBS snapshot and AMI creation by tag, with age-based or count-based retention, optional cross-Region and cross-account copies, and optional archiving.
• An archive-enabled DLM schedule must create snapshots no more often than every 28 days (for example a monthly cron expression); daily and weekly schedules cannot archive. Archived snapshots have a 90-day minimum retention, and restoring one takes up to 72 hours.
• An archived snapshot is a full snapshot. Standard-tier snapshots are incremental (only changed blocks), while the archive tier stores every block, at up to about 75% lower price per GB. Archiving therefore pays off when each snapshot is already close to the volume size (most blocks change between snapshots) and is kept for a long time; it costs more for small weekly incrementals of a slowly changing volume.
• Copies to another Region or account double storage and add transfer cost; add them only when a stated DR or isolation requirement asks for them.

Backup governance (vault locks, cross-account backup policies, recovery objectives) belongs to the resilience domain; this task is about what retention and tiering cost.

You design cost-effective observability by reducing what is ingested at the source, choosing the right log class and destination, setting retention, and keeping custom-metric cardinality low. Each lever addresses a different line of the bill: filters applied after ingestion never reduce ingestion charges, and retention never reduces them either.

Retention

CloudWatch Logs log groups created with default settings (as Lambda and many services create them) never expire, so storage grows forever. Setting a retention period per log group makes CloudWatch Logs delete older events automatically. Exporting to S3 (CreateExportTask) or streaming with a subscription filter copies events but does not delete them from CloudWatch Logs.

Log classes

The class is chosen when a log group is created and cannot be changed afterwards. Split by purpose: logs searched only during investigations go to Infrequent Access; logs that drive alarms through metric filters, stream to a SIEM or carry EMF metrics stay in Standard.

Filtering before ingestion

• Lambda advanced logging controls: set the function's log format to JSON, then set an application log level (for example WARN) per function, and Lambda drops lower-level application lines before they reach CloudWatch Logs. Log-level filtering requires JSON format. The system log level filters Lambda's own platform lines (START, REPORT and similar), not the function's output. Levels are set per function, so development can keep DEBUG with no code change.
• VPC flow logs: choose the traffic type (ACCEPT, REJECT or ALL) and the destination. A flow log's settings cannot be edited after creation, so changing the traffic type means creating a new flow log and deleting the old one. Delivering to Amazon S3 uses lower vended-log pricing than CloudWatch Logs, S3 Lifecycle can expire the records, and Amazon Athena serves occasional queries.

Metric aggregation and cardinality

CloudWatch bills custom metrics per unique combination of metric name and dimension values, so every new dimension value is a new metric. Collection interval, flush interval and storage resolution change data points and API calls, not the number of metrics.

• CloudWatch agent: aggregation_dimensions (for example a list containing a dimension set such as InstanceType) publishes roll-ups per dimension set, and drop_original_metrics stops the agent also sending the per-instance originals, which is what keeps metric counts growing on fleets whose instances are replaced often. append_dimensions adds dimensions and therefore more metrics.
• Embedded metric format: each distinct value set of a declared dimension set becomes a metric. Keep high-cardinality identifiers (customer ID, request ID) out of Dimensions and leave them as plain fields in the log event, where CloudWatch Logs Insights can filter on them when an investigation needs one customer's data.
• A metric filter that extracts a high-cardinality field as a dimension has the same problem as EMF.