Cost-Optimized Storage: S3 Classes, Lifecycle Policies, and EBS Economics

Before you can optimize storage, you have to know what is costing money and whose it is, so Task 4.1 opens with the cost-management toolkit. Cost allocation tags are the attribution mechanism: tag resources with keys like project or team, activate those tags in the Billing console, and every tool downstream can slice spend by them. When a scenario says finance "cannot determine which department is driving S3 costs," the answer is a tagging standard plus activated cost allocation tags — nothing else in the toolkit creates per-team attribution.

The tools then divide by job. AWS Cost Explorer is for interactive analysis: visualize spend over time, filter by service, account, or tag, and spot the trend — "identify which storage service grew last quarter" is Cost Explorer. AWS Budgets is for thresholds and action: set a budget on cost or usage and get alerted (or trigger an action) when actual or forecasted spend crosses a limit — "notify the team before the monthly bill exceeds an amount" is Budgets, and only Budgets, because Cost Explorer reports but never alerts. The Cost and Usage Report (CUR) is the most granular option: line-item detail delivered to an S3 bucket, typically queried with Athena — the answer when a question demands "the most detailed billing data" for custom analysis.

For multi-account setups, consolidated billing through AWS Organizations gives one bill for all member accounts and — the decision-relevant part — aggregates usage across accounts, so volume-tiered pricing (like S3's per-GB tiers) is reached faster and unused reservation discounts can be shared across the family. An organization asking to "reduce cost without changing any workloads" across many accounts is often just being pointed at consolidated billing.

The exam tests this as tool selection under a one-line requirement: alerting means Budgets, visual trend analysis means Cost Explorer, granular line items mean the CUR, per-team attribution means cost allocation tags, and cross-account aggregation means consolidated billing. Options that swap these jobs are the distractors.

Every S3 class trades storage price against access price, and the exam hands you an access pattern and asks for the cheapest class that still satisfies it. S3 Standard has the highest per-GB storage cost but no retrieval fee and no minimum storage duration — the default for data accessed frequently or unpredictably in the short term. S3 Standard-IA (Infrequent Access) charges much less per GB stored but adds a per-GB retrieval fee, a 30-day minimum storage duration, and a minimum billable object size — right for data accessed roughly monthly, like older reports or backups you restore occasionally. S3 One Zone-IA costs less again by storing data in a single Availability Zone: same fees and minimums as Standard-IA, but the data does not survive the loss of that AZ, so it is only correct for data that is re-creatable or replicated elsewhere — secondary backup copies, easily regenerated thumbnails.

The Glacier family trades retrieval time for storage price. Glacier Instant Retrieval keeps millisecond access with the lowest storage price that still allows it, for data touched maybe once a quarter — with a 90-day minimum and a retrieval fee. Glacier Flexible Retrieval drops to asynchronous restores measured in minutes to hours (expedited, standard, and free bulk options), also with a 90-day minimum — the archive for data you can wait for. Glacier Deep Archive is the cheapest storage in S3, with restores taking up to 12 hours (longer for bulk) and a 180-day minimum — for compliance archives touched once a year or less.

Exam questions encode the pattern in phrases: "accessed once a month but must be immediately available" (Standard-IA), "can be regenerated" (One Zone-IA), "retrieved within 12 hours for an audit" (Deep Archive). Match the phrase, then verify no trap in the next section disqualifies the pick.

The wrong answers in storage-class questions are rarely nonsense — they are cheaper-looking classes that a hidden fee makes more expensive. Three traps account for almost all of them.

Minimum storage duration. Standard-IA and One Zone-IA bill a minimum of 30 days; Glacier Instant and Flexible Retrieval bill 90 days; Deep Archive bills 180 days. Delete or transition an object earlier and you are charged for the remainder anyway. So data deleted after two weeks does not belong in Standard-IA no matter how rarely it is read, and an archive purged after 90 days must not sit in Deep Archive — the "cheapest" class becomes the expensive one. When a scenario states a short retention period, check every option's minimum duration against it before anything else.

Retrieval fees against real access frequency. Every class below Standard charges per GB retrieved. Infrequent-access pricing only wins when access truly is infrequent: put a working dataset that analysts hit daily into Standard-IA and the retrieval fees swamp the storage savings. The exam encodes this as a class choice for data "accessed several times a week" — the IA option is the trap, and Standard (or Intelligent-Tiering) is correct. Read the stated access frequency literally and price the retrievals mentally, not just the storage.

Small objects. Standard-IA and One Zone-IA carry a minimum billable object size, so millions of tiny objects gain little from IA pricing; Intelligent-Tiering does not monitor very small objects at all and leaves them at the frequent-access rate. Aggregating small files (batching log records into larger objects before upload) is itself a cost technique the guide names — batch uploads beat individual uploads on request costs too, since every PUT is billed.

On the exam, treat these as a veto checklist: an option can name a cheaper class, but if the scenario's retention or access pattern violates that class's minimum duration or makes retrieval fees dominate, the option is wrong, and the question was testing exactly that.

Data has a lifecycle — hot when new, cooling with age, eventually deletable — and an S3 Lifecycle configuration automates the cost curve so nobody has to remember to move or delete anything. A lifecycle rule attaches to a bucket (optionally scoped by prefix or tags) and has two action types. Transition actions move objects to a cheaper class at an age you set: to Standard-IA after 30 days, to Glacier Flexible Retrieval after 90, to Deep Archive after 365. Transitions are a one-way waterfall down the price list — lifecycle never moves data back up. Note that transitions into Standard-IA or One Zone-IA are only supported after the object is 30 days old, which pairs naturally with the 30-day minimum duration. Expiration actions delete objects at a set age — the mechanism behind every "retain for seven years, then delete" requirement.

On a versioned bucket, lifecycle earns its keep twice over, because versioning quietly multiplies storage: every overwrite and delete keeps the old version, billed at full price, forever, unless you say otherwise. Lifecycle rules can act on noncurrent versions separately — transition noncurrent versions to a cheaper class after a few days, and permanently delete them after a retention window (optionally keeping a fixed number of newer ones). A scenario where "a versioned bucket's costs keep growing although the live dataset is stable" is pointing at noncurrent versions, and the fix is a noncurrent-version expiration rule, not turning versioning off in place.

The third cleanup target is invisible in the console's object list: incomplete multipart uploads. A multipart upload that never completes leaves its uploaded parts in the bucket, billed, indefinitely. The AbortIncompleteMultipartUpload lifecycle action deletes parts after a set number of days, and it belongs in effectively every bucket that receives large uploads. Lifecycle can also remove expired delete markers left behind by versioned deletes.

Exam questions test lifecycle as design: given stated ages and retention, assemble the transition-and-expire sequence that respects every class's minimum duration — and recognize versioning cost bloat and abandoned multipart parts as lifecycle problems, not manual-cleanup ones.

Lifecycle rules assume you can predict the access curve. When you cannot — new datasets, user-generated content, data lakes where some objects stay hot for years while their neighbors go cold in a week — the answer is S3 Intelligent-Tiering. It monitors each object's access and moves it automatically between tiers: a frequent-access tier, an infrequent-access tier after 30 days without access, and an archive-instant tier after 90 — with optional opt-in asynchronous archive tiers (after 90 and 180 days without access) for buckets that can tolerate restore delays. If a cold object is accessed again, it moves back to the frequent tier automatically — something a lifecycle waterfall can never do.

Its economics are the decision rule. Intelligent-Tiering charges a small per-object monitoring and automation fee, but — unlike the IA and Glacier classes — it has no retrieval fees and no minimum-duration charges. That makes it the safe default when patterns are unknown or changing: you can never be ambushed by a retrieval bill, and the worst case is paying the monitoring fee on data that turns out to be permanently hot. The caveats: very small objects are not monitored (they simply stay at the frequent-access rate), so a bucket of millions of tiny objects gains nothing, and if the access pattern is genuinely known, an explicit lifecycle into IA or Glacier is cheaper because it skips the monitoring fee. Exam phrasing is nearly a password: "unknown," "unpredictable," or "changing access patterns" plus "without operational overhead" selects Intelligent-Tiering.

Requester Pays answers a different question: not how data is stored, but who pays to access it. Normally the bucket owner pays for requests and data transfer out. Enabling Requester Pays on a bucket shifts those request and transfer costs to the requester, who must be an authenticated AWS principal that flags the request accordingly — the owner keeps paying only for storage. It fits organizations sharing large public-interest datasets: researchers pay for their own downloads. A scenario where a team "shares a large dataset with external partners but does not want to pay for their downloads" is Requester Pays; options about presigned URLs or replication miss the point, which is cost shifting.

EBS bills on what you provision, not what you use — a 1 TB volume holding 100 GB costs the same as one that is full — so EBS cost design is about provisioning less, and provisioning smarter. The headline rule: choose gp3 over gp2. gp3 has a lower per-GB price and includes a free performance baseline of 3,000 IOPS and 125 MiB/s regardless of volume size, with more IOPS and throughput provisionable independently. gp2's performance scales with size (3 IOPS per GB), which forced a notorious anti-pattern: oversizing a volume purely to buy IOPS. A gp2 volume "sized larger than the data requires for performance" resolves to migrating to gp3 and right-sizing — same performance, smaller volume, cheaper per GB — and Elastic Volumes does the modification online. Reach for io1/io2 only when the workload needs more IOPS than gp3 can provision. Below the SSDs, the HDD types are cheap per GB but sequential-only: st1 (throughput-optimized) for frequently accessed large sequential workloads like log processing and big-data scratch space, sc1 (cold HDD) as the cheapest EBS option for infrequent sequential access. Neither boots an instance, and both are wrong for random I/O — but "sequential," "throughput," or "large log files" plus a cost qualifier selects HDD over SSD.

The other recurring shape is the audit: "storage spend keeps growing although the workload has not changed." The answer is some subset of the same four leaks — treat them as a checklist.

• Unattached EBS volumes. Terminating an instance does not delete non-root volumes by default; volumes in the available state bill at full price while doing nothing. Snapshot if in doubt, then delete.
• Old EBS snapshots. Snapshots are incremental, and deleting old ones is safe — AWS preserves any blocks newer snapshots still reference. Automate retention with Amazon Data Lifecycle Manager or AWS Backup, and move long-retention, rarely restored snapshots to the EBS Snapshots Archive tier — cheaper storage, restores measured in hours: "Glacier for snapshots."
• Noncurrent object versions in versioned buckets — the symptom is bucket storage far exceeding the visible object count.
• Incomplete multipart uploads — invisible billed parts, cleaned by AbortIncompleteMultipartUpload.

The exam tests this section as swap-spotting and leak-hunting: find the gp2, the oversized volume, the SSD doing sequential batch work, or the named leaks — and prefer the option that fixes them with standing automated policies, since LEAST-operational-overhead beats a quarterly manual cleanup.

Amazon EFS is elastic — you pay for bytes actually stored, no provisioning — and it has its own cost tiering. EFS lifecycle management moves files that have not been accessed for a configured period (for example 30 days) from the Standard storage class into EFS Infrequent Access, at a fraction of the per-GB price, and can move long-idle files further into the archive class; files move back to Standard when accessed again (per configuration). Like S3's IA, EFS IA charges per-GB access fees, so the win depends on the data actually being cold — but for the classic file-share pattern where most files are written once and rarely reopened, enabling lifecycle management is close to free money, and it is the standard answer to "reduce EFS costs without changing the application." EFS One Zone classes cut the price further for data that does not need multi-AZ resilience, mirroring the One Zone-IA trade-off. FSx appears in this task at recognition level: it is the file service you pick for workload compatibility (Windows/SMB, Lustre for HPC), not the low-cost default.

The service-selection question sits above all of this: given a requirement, which storage service is cheapest? The economics rank clearly. S3 is the cheapest per GB and the default whenever the application can use object storage over an API — static assets, backups, data lakes, anything write-once-read-many. EBS is block storage for one instance at a time, priced on provisioned capacity — required for databases and boot volumes, wasteful as a file dump. EFS costs more per GB than either but is the only one of the three offering a shared POSIX file system mounted by many instances concurrently — you pay the premium only when simultaneous shared file access is a stated requirement.

The exam encodes the choice in the requirement's verbs: "accessed via API / static website / archive" means S3; "attached to an instance / low-latency block" means EBS; "shared by multiple instances / mounted concurrently" means EFS. The classic trap offers EFS for content that could live in S3 — if nothing demands a file-system interface across instances, the MOST cost-effective answer is S3.

Archival design starts from one question: how long can you wait for the data back? Retrieval tolerance selects the Glacier tier — milliseconds means Glacier Instant Retrieval, minutes-to-hours means Flexible Retrieval, and up-to-12-hours-or-more means Deep Archive, the cheapest storage on AWS and the default for "retain seven years for compliance." Always cross-check retention against minimum durations (90/90/180 days) before committing. For backups themselves, AWS Backup centralizes policy across services — EBS, RDS, EFS, DynamoDB and more — with backup plans that set frequency and retention, and lifecycle rules that transition backups to cold storage and expire them on schedule. "Centrally manage and automatically expire backups across services" is AWS Backup; per-service scripting is the overhead distractor.

Getting data into AWS storage cheaply is the other half. Two anchors are free: data transfer into AWS costs nothing, and traffic between EC2 and S3 in the same Region is free — so an option is never wrong for uploading from an in-Region instance to S3, while cross-Region replication and internet egress are the transfers that cost real money and need justifying. For migrations, the choice is bandwidth math. AWS DataSync is the online mover: an agent transfers file or object data over the internet or Direct Connect, with scheduling, verification, and incremental sync — right when the dataset fits the available bandwidth in the available time, and for ongoing replication. The Snowball family is the offline path: AWS ships a ruggedized device, you load tens of terabytes to petabytes locally and ship it back. The rule of thumb the exam rewards: when the transfer would take weeks over the existing link — huge datasets, thin or saturated bandwidth, remote sites — Snowball wins; with ample bandwidth or a recurring sync requirement, DataSync wins. Transfer Family (managed SFTP/FTPS endpoints for partner uploads) and Storage Gateway (hybrid access with local caching, and Tape Gateway replacing physical tape backup with S3/Glacier) are recognition-level: match them to "partners upload via SFTP" and "replace on-premises tape," respectively.

Scenario 1. A company generates compliance reports into S3. Each report is read frequently for its first month, occasionally (but it must load without delay) for about a year, and must then be retained for seven years for auditors who accept retrievals taking up to a day. After seven years the reports must be deleted. What is the MOST cost-effective design?

Reasoning: Map each phase to the cheapest class that meets it, then verify the traps. Month one is frequent access: S3 Standard — any IA class would bleed retrieval fees. From day 30, access is occasional but must stay immediate: transition to Standard-IA at 30 days, which is also the earliest the transition is allowed and cleanly satisfies IA's 30-day minimum. One Zone-IA is the trap here — cheaper, but compliance reports are not re-creatable data, so single-AZ storage fails the requirement. At one year, access effectively stops and a day's wait is acceptable: transition to Glacier Deep Archive at 365 days — its 12-hour standard restore fits "up to a day," and seven years of remaining retention clears the 180-day minimum many times over. Glacier Instant Retrieval would preserve millisecond access nobody asked for at a higher price; Flexible Retrieval works but stores at a higher rate than Deep Archive with no requirement justifying it. Finally, an expiration action at 7 years deletes the objects — plus an AbortIncompleteMultipartUpload rule, since reports are uploaded continuously. The winning option is the full lifecycle waterfall; every distractor either parks hot data in IA too early, uses One Zone-IA for a sole copy, or archives to a tier whose retrieval time or minimum duration contradicts a stated number.

Scenario 2. A cost review shows EBS is a company's fastest-growing line item. The account contains hundreds of gp2 volumes, several sized at 1 TB "for performance" while storing under 200 GB; dozens of volumes in the available state left over from terminated instances; and thousands of snapshots dating back years, kept because "deleting incremental snapshots might break the chain." Compliance requires month-end snapshots be kept for five years. What should the architect recommend?

Reasoning: Run the waste checklist. The oversized gp2 volumes exist only to buy IOPS via gp2's size-linked performance — migrate to gp3, which delivers a 3,000-IOPS baseline regardless of size at a lower per-GB price, and right-size the volumes to the data. The available volumes are pure waste: snapshot if in doubt, then delete unattached volumes. The snapshot fear is the tested misconception: snapshots are incremental, but deleting old ones is safe — AWS retains any blocks that newer snapshots reference — so the answer automates retention with Data Lifecycle Manager, keeping recent snapshots briefly and month-end snapshots per policy. Those five-year compliance snapshots, rarely restored, belong in EBS Snapshots Archive at a much lower storage price. Distractors here keep gp2 "because migration is risky" (Elastic Volumes modifies volumes online), keep every snapshot, or delete the compliance snapshots — the last one is the requirement-breaking "savings" the qualifier exists to punish.