AWS SAA-C03: Storage & Data Lifecycle — Study Guide

By Laurynas Brazys · 15 July 2026 · #amazon #aws #saa-c03 #storage #certification #exam-prep #study-guide

Part of the AWS SAA-C03 Complete Study Guide. Practice these concepts with verified answers in the AWS/Amazon exam hub, or take timed practice tests on ExamRoll.io.

S3 Storage Classes and the Cost/Latency Spectrum

S3 storage classes exist on a spectrum trading retrieval latency, minimum storage duration, and per-GB retrieval fees against per-GB storage cost. Choosing correctly is the single largest lever for cost optimization on object storage.

S3 Standard is the default: eleven-nines durability across three or more AZs, millisecond latency, no retrieval fee, highest per-GB price. Standard-IA and One Zone-IA drop storage cost by roughly 40–50% but add a per-GB retrieval fee, a 30-day minimum billable duration, and a 128 KB minimum object size (smaller objects are billed as 128 KB, which erodes the savings). One Zone-IA further reduces cost by storing in a single AZ — appropriate only for reproducible secondary copies where a single-AZ loss is tolerable.

S3 Intelligent-Tiering is the correct choice whenever access patterns are unknown, unpredictable, or shifting across a large corpus. It automatically migrates objects between frequent, infrequent, archive-instant, archive, and deep-archive tiers based on observed access, charging a small per-object monitoring fee. Because there are no retrieval charges between the frequent and infrequent tiers and no minimum duration, it is the safest default for data lakes and mixed workloads with objects ≥128 KB. It is the wrong choice when you already know objects are permanently hot (extra monitoring cost) or permanently cold for a decade (Deep Archive is far cheaper).

Glacier Instant Retrieval provides millisecond access at archive prices for data accessed quarterly or less — medical images, compliance PDFs that must be produced immediately when requested. Glacier Flexible Retrieval offers minutes-to-hours retrieval. Glacier Deep Archive is the cheapest tier in AWS at roughly $1/TB/month, with 12-hour standard retrieval (or 48-hour bulk) and a 180-day minimum — the correct answer for 7–10-year regulatory retention and tape replacement.

The two dominant cost traps are opposite mistakes. Selecting Standard for long-term rarely-read data burns money because Standard has no cold-storage price break — a 5 TB dataset held for years in Standard costs several times more than the same data in Deep Archive. Conversely, jumping brand-new objects straight to Standard-IA or Glacier is a trap because the 30/90/180-day minimum charges plus retrieval fees exceed the savings when objects are still hot. Glacier Flexible or Deep Archive are also outright incompatible with any workload that expects a synchronous read — a user waiting on an HTTP GET cannot tolerate a minutes-to-12-hour retrieval SLA. Glacier Instant Retrieval is the only Glacier tier compatible with immediate access.

Lifecycle Policies and Version Handling

Lifecycle configuration is declarative JSON/YAML attached to a bucket that transitions or expires objects based on age, tag, or prefix. Transitions are evaluated once per day and only fire after the specified age is reached — a Days: 30 transition means Standard rates apply for the first 30 days. Transitions must move to progressively colder tiers, and objects smaller than 128 KB are not transitioned from Standard to IA because per-object overhead outweighs savings; consolidate small objects via tar/zip or S3 Batch Operations first.

A canonical policy for a workload that is hot for 30 days, cold thereafter, needing immediate access throughout, retained four years, with proper hygiene:

Rules:
  - ID: archive-and-clean
    Status: Enabled
    Transitions:
      - Days: 30
        StorageClass: STANDARD_IA
      - Days: 180
        StorageClass: DEEP_ARCHIVE
    NoncurrentVersionTransitions:
      - NoncurrentDays: 30
        StorageClass: GLACIER
    NoncurrentVersionExpiration:
      NoncurrentDays: 365
    Expiration:
      Days: 1460
    AbortIncompleteMultipartUpload:
      DaysAfterInitiation: 7

A frequent version-handling trap: on a versioned bucket, a lifecycle rule that expires current objects merely inserts delete markers; prior versions accumulate silently and continue to bill. Noncurrent versions require their own explicit NoncurrentVersionTransitions and NoncurrentVersionExpiration. Similarly, always include AbortIncompleteMultipartUpload — orphaned multipart parts are invisible in the console listing and accrue storage indefinitely.

For blended patterns — say, IoT telemetry that is hot for ML training the first month, then queried quarterly for a year, then archival — the right answer is Intelligent-Tiering for the first year (letting the class auto-optimize between training bursts and idle days) followed by a scheduled transition to Deep Archive at day 365.

Versioning, MFA Delete, and Object Lock

Once enabled, versioning becomes suspended-only; it cannot be turned off. Every PUT creates a new version ID; DELETE inserts a delete marker rather than removing data. Versioning protects against accidental overwrite but is not immutability: any principal with s3:DeleteObjectVersion can permanently remove a specific version. MFA Delete adds a requirement that the root account present an MFA token to permanently remove versions or change versioning state — closing the accidental-delete gap for high-value buckets but still not preventing an authorized actor from destroying data.

True immutability requires S3 Object Lock, which requires versioning and must generally be enabled at bucket creation. It has two modes that are frequently confused:

Retention can be applied per-object (Retain-Until-Date) or via a Legal Hold, which has no expiry. For accounting records requiring one year hot, nine years archived, and no deletion for ten years, the correct pattern is Object Lock in Compliance mode with a ten-year retention, combined with a lifecycle transition to Deep Archive at day 365. Governance is not an acceptable substitute for a legal mandate — a regulator will not accept “someone with permissions could have deleted this” as immutability.

To apply retention to an existing corpus of PDFs in a single job, use S3 Batch Operations driven by an S3 Inventory manifest. Batch Operations is the managed answer for large-scale mutations — retention, tagging, PUT-copy re-encryption, Lambda invocation — across billions of keys; hand-written iteration scripts are not the right pattern.

Encryption: SSE-S3, SSE-KMS, and Bucket Keys

Every bucket has default encryption. SSE-S3 (AES-256, S3-managed keys) is free and requires no key administration. SSE-KMS uses a KMS customer master key, enabling per-key CloudTrail audit trails, IAM-based key access policies, and key-rotation control — at the cost of KMS API charges and, more critically, KMS request throttling that can bottleneck high-throughput read workloads. Choose SSE-KMS when you actually need those controls (regulatory attestation, separation of duties, cross-account key sharing). Defaulting to SSE-KMS “to be safe” adds unnecessary cost and complexity when SSE-S3 satisfies the requirement.

S3 Bucket Keys address SSE-KMS request cost. S3 generates a short-lived bucket-level key from the CMK and derives per-object data keys locally, avoiding a KMS GenerateDataKey/Decrypt call per object and reducing KMS request costs by up to 99%:

"ServerSideEncryptionConfiguration": {
  "Rules": [{
    "ApplyServerSideEncryptionByDefault": {
      "SSEAlgorithm": "aws:kms",
      "KMSMasterKeyID": "arn:aws:kms:..."
    },
    "BucketKeyEnabled": true
  }]
}

Switching to SSE-S3 to “avoid KMS costs” is the wrong workaround when the requirement mandates KMS — Bucket Keys satisfy both compliance and cost objectives without abandoning KMS.

Enabling default bucket encryption ensures all future uploads are encrypted (unencrypted PUTs are transparently encrypted). To reject unencrypted PUTs outright, deny writes lacking the header:

{
  "Effect": "Deny",
  "Principal": "*",
  "Action": "s3:PutObject",
  "Resource": "arn:aws:s3:::my-bucket/*",
  "Condition": {
    "StringNotEquals": {
      "s3:x-amz-server-side-encryption": "AES256"
    }
  }
}

Default encryption does nothing to existing unencrypted objects. Re-encrypt them via S3 Inventory + Batch Operations running a Copy job that overwrites each key in place — the standard bulk-re-encryption pattern.

Ad-hoc client-side encryption is inferior to default encryption plus KMS: it scatters key management across application teams, cannot be audited centrally through CloudTrail KMS events, and cannot use Bucket Keys.

Cross-Region Replication and Multi-Region KMS Keys

Cross-Region Replication (CRR) asynchronously copies objects to a bucket in a different Region for compliance, DR, or latency. Same-Region Replication (SRR) serves compliance separation, log aggregation, and cross-account copies. Both require versioning on source and destination and an IAM role the source bucket assumes. CRR is the low-effort answer whenever a bucket must mirror to another Region — scripting aws s3 sync, wiring Lambdas on ObjectCreated, or running scheduled batch copies introduces operational overhead, race conditions, and silent failures. Neither CRR nor SRR replicates existing objects by default; use S3 Batch Replication for backfills.

Encryption interactions are where designs commonly fail:

• SSE-S3 objects replicate transparently.
• SSE-KMS objects are not replicated by default — you must explicitly opt in, specify a destination KMS key in the destination Region, and grant the replication role kms:Decrypt on the source key and kms:Encrypt on the destination key. A single-Region key cannot encrypt objects in another Region.
• Client-side-encrypted objects replicate as opaque ciphertext; the destination Region gains nothing unless the client’s key material is available there.

The historical friction of managing two independent CMKs is resolved by AWS KMS multi-Region keys, which present the same key material and key ID (with a Region prefix) in multiple Regions. A replicated object can then be decrypted in the destination Region without cross-Region KMS calls and without re-wrapping the data key. This is the canonical pattern for encrypted, replicated buckets that must remain usable in Regional failover.

Cross-account snapshot and object sharing under a customer-managed KMS key requires the target account principals to hold kms:Decrypt, kms:CreateGrant, kms:DescribeKey, and kms:ReEncrypt* on the source key via key policy, plus matching IAM permissions. AWS-managed keys (e.g., aws/ebs, aws/s3) cannot be shared across accounts, so customer-managed keys are mandatory for cross-account workflows.

Block Public Access and Restricting Access to CloudFront

S3 Block Public Access (BPA) has four settings — block new public ACLs, ignore existing public ACLs, block new public bucket policies, restrict public bucket policies — configurable per bucket and, more importantly, at the account level. Account-level BPA supersedes any bucket policy that would grant public access and is the correct control for “no object in this account may be public.” Bucket-level policies alone are fragile: a new bucket may launch without one; account-level BPA fails closed.

To prevent an administrator in a member account from disabling BPA, layer a Service Control Policy at the Organizations OU or root:

{
  "Effect": "Deny",
  "Action": "s3:PutAccountPublicAccessBlock",
  "Resource": "*",
  "Condition": {
    "Bool": { "aws:PrincipalIsAWSService": "false" }
  }
}

To serve S3 content only through CloudFront, attach an Origin Access Control (OAC) — the modern replacement for the legacy OAI — to the distribution and gate the bucket policy on the distribution ARN:

{
  "Effect": "Allow",
  "Principal": { "Service": "cloudfront.amazonaws.com" },
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::my-bucket/*",
  "Condition": {
    "StringEquals": {
      "AWS:SourceArn": "arn:aws:cloudfront::111122223333:distribution/E123"
    }
  }
}

BPA stays enabled on the bucket. For time-limited access to private objects by a specific user (upload/download expiry), generate a presigned URL whose embedded signature inherits the signing principal’s permissions.

Private Network Paths: Gateway Endpoints

EC2-to-S3 traffic within a VPC does not automatically use the AWS private backbone. Without configuration, S3 API calls resolve to public endpoints and traverse the internet gateway or NAT gateway, incurring NAT data-processing charges and exposing traffic to the internet. A gateway VPC endpoint for S3 (and DynamoDB) is free, is added as a prefix-list route in specified route tables, and keeps traffic on the AWS network. Interface endpoints (PrivateLink) for S3 also exist and are billable, useful when access originates from on-premises via Direct Connect. Pair the endpoint with a bucket policy aws:SourceVpce condition to enforce that the bucket is only reachable from approved VPC endpoints — the standard pattern for regulated workloads.

Object Lambda for On-the-Fly Transformation

S3 Object Lambda inserts a Lambda function into the GET/HEAD/LIST path so the object returned to the caller is transformed at read time. This avoids duplicating data for each variant (redacted, resized, reformatted) and keeps a single source of truth in the underlying bucket. Typical uses: PII redaction for analysts versus full data for auditors, per-user image watermarking, XML-to-JSON conversion for legacy clients. IAM and bucket policies still gate the underlying object; the Lambda sees only what its execution role permits.

Event Notifications

S3 emits events (s3:ObjectCreated:*, s3:ObjectRemoved:*, replication and lifecycle events) to Lambda, SQS, SNS, or EventBridge. EventBridge is preferred when you need multiple targets, filtering on object metadata, or cross-account routing; direct notifications are simpler and cheaper for single-target pipelines like on-upload thumbnail generation. Notifications are at-least-once, so consumers must be idempotent.

Throughput Optimization: Multipart Upload and Transfer Acceleration

For objects over 100 MB multipart upload is best practice; over 5 GB it is mandatory. Parts upload in parallel, failed parts retry independently, and throughput scales with concurrency. Byte-range GETs give the equivalent parallelism on downloads. As noted, always attach an AbortIncompleteMultipartUpload lifecycle rule to avoid billing for orphaned parts.

S3 Transfer Acceleration routes uploads through the nearest CloudFront edge over AWS’s backbone — use for globally distributed clients uploading to a single bucket. For downloads, front S3 with CloudFront to cache at the edge. Transfer Acceleration is upload-oriented; CloudFront is download-oriented; they solve related but distinct problems.

EBS: Volume Types, Encryption, and Snapshots

EBS volumes are AZ-scoped block devices attached to a single EC2 instance. gp3 is the default general-purpose SSD; its critical advantage over gp2 is that IOPS (up to 16,000) and throughput (up to 1,000 MiB/s) are provisioned independently of capacity, eliminating the gp2 anti-pattern of overprovisioning storage just to reach performance targets. io2 Block Express delivers up to 256,000 IOPS at sub-millisecond latency for latency-sensitive databases. st1 and sc1 are HDD-backed for throughput-oriented sequential and cold workloads. Multi-Attach on io1/io2 exists but is limited to 16 instances in the same AZ running a cluster-aware filesystem — a narrow exception, not a general “shared EBS” pattern. Attempting to attach EBS broadly across instances (say, behind a load balancer) is a category error that produces exactly the “some documents visible on refresh, others not” symptom because each volume is a private block device.

EBS volumes encrypt at rest with AES-256 using KMS-wrapped data keys. Encryption is transparent — no performance penalty, no application changes. Once a volume is encrypted, derivative snapshots and volumes are encrypted; you cannot un-encrypt in place. Enable EBS encryption by default per Region so every new volume and snapshot is encrypted regardless of developer memory:

aws ec2 enable-ebs-encryption-by-default --region us-east-1
aws ec2 modify-ebs-default-kms-key-id \
  --kms-key-id arn:aws:kms:us-east-1:111122223333:key/abcd-...

Existing unencrypted volumes are not retroactively encrypted — remediation requires snapshot, copy-with-encryption, and volume creation from the encrypted snapshot.

Snapshots are incremental block-level backups stored on S3-managed infrastructure — but they are not free (you pay for retained changed blocks), they do not disappear when the source volume is deleted, and they are not removed when an AMI referencing them is deregistered. Age them into the EBS Snapshots Archive tier (75% cheaper, 24–72 hour restore) via aws ec2 modify-snapshot-tier, Amazon Data Lifecycle Manager (DLM), or AWS Backup. Fast Snapshot Restore (FSR) pre-warms a snapshot in specific AZs so instances launched from it deliver full performance immediately — enable for AMIs behind autoscaling groups that must handle rapid scale-out.

Recycle Bin captures deleted EBS snapshots and AMIs into a restore window (1 day to 1 year). Without it, snapshot deletion is immediate and permanent:

aws rbin create-rule \
  --retention-period RetentionPeriodValue=30,RetentionPeriodUnit=DAYS \
  --resource-type EBS_SNAPSHOT \
  --description "30-day snapshot recovery"

Relying on daily EBS snapshots alone for long-term compliance retention is a common architectural mistake — snapshots are priced closer to warm storage and require explicit archival transitions.

Amazon EFS: Shared POSIX for Linux Fleets

EFS is a fully managed, elastic, POSIX-compliant NFSv4.1 file system mountable simultaneously from thousands of EC2, ECS, EKS, or Lambda clients across multiple AZs in a Region, and from on-premises hosts via Direct Connect or VPN. The defining property is that the same file system, with identical file handles and byte-level semantics, is visible to every client at once. EFS is therefore the correct answer whenever a Linux fleet behind a load balancer must share a common set of files — user uploads, config, shared home directories.

Mount targets live in each AZ subnet you configure. The amazon-efs-utils helper enables TLS in transit and IAM mount authorization:

sudo mount -t efs -o tls,iam fs-0123456789abcdef0:/ /mnt/shared

EFS storage classes span two dimensions. Lifecycle management tiers files not accessed for 7–90 days from Standard to Infrequent Access and optionally to Archive, cutting storage cost up to 92%; Intelligent-Tiering moves them back on access. One Zone classes store in a single AZ for ~47% less — appropriate for dev/test or reproducible data, never for data whose loss during an AZ failure is unacceptable. A cost-tuning move for a workload already on EFS Standard-IA is switching to EFS One Zone-IA without any application change.

Performance has two independent knobs. Performance mode (set at creation): General Purpose is lowest-latency and correct for metadata-heavy web serving; Max I/O is a legacy option superseded by Elastic. Throughput mode: Bursting scales with size (50 KB/s per GB baseline, burst credits when below baseline), Provisioned pays for a fixed MB/s independent of size, and Elastic — the current default — auto-scales to 10+ GB/s with no capacity planning. A tiny file system under sustained load can exhaust bursting credits and throttle to a low baseline, so heavy-I/O workloads with small footprints must use Elastic or Provisioned.

EFS is not a substitute for high-IOPS block storage. Every EFS I/O is an NFS RPC over the network, so single-writer, sub-millisecond, transaction-log-style workloads belong on EBS io2 Block Express — a single volume delivers 256,000 IOPS at sub-ms latency, which EFS cannot match on a per-operation basis. EFS is also grossly overpriced for cold data compared to Deep Archive; keeping compliance data on EFS “because it’s easy” is indefensible.

FSx: Windows, Lustre, ONTAP, OpenZFS

FSx is a family of managed file systems selected by protocol and workload:

FSx for Windows File Server delivers native SMB 2.0/3.1.1 with NTFS ACLs, DFS Namespaces, shadow copies, and Kerberos over Active Directory. Multi-AZ deploys an active file server in one AZ with a synchronously replicated standby in another and a single failover DNS name. AD integration is not optional: FSx must join AWS Managed Microsoft AD or a reachable self-managed AD, and clients authenticate as domain users against domain SIDs. Skipping AD, or pointing clients at a file system in an untrusted forest without a cross-forest trust, produces the classic access-denied-despite-share-visible symptom. FSx for Windows is the drop-in target for lift-and-shift of Windows file shares.

FSx for Lustre is a parallel POSIX file system for HPC, ML training, EDA, and genomics — thousands of clients, hundreds of GB/s throughput, sub-ms metadata. Its critical AWS feature is the data repository association with S3: object keys appear as files in the Lustre namespace and are lazily loaded on first access (or preloaded via hsm_restore); new/modified files export back to S3 on schedule or on demand. The canonical HPC pattern is:

1. Copy on-prem datasets to S3 (via DataSync or Storage Gateway).
2. Create Lustre linked to that bucket.
3. Mount on all Spot workers; read inputs, write outputs at line rate.
4. Export results to S3, which remains the durable long-term repository.
5. Delete the Lustre file system when the job ends.

Lustre Scratch deployments have no replication and lose data on hardware failure — cheapest and fastest, appropriate for transient job data. Persistent deployments replicate within an AZ for higher durability. Throughput is provisioned in MB/s per TiB (50/125/250/500/1000), decoupling capacity from performance.

FSx for NetApp ONTAP is the multi-protocol answer: NFS, SMB, and iSCSI simultaneously on the same data, with snapshots, SnapMirror replication, FlexClones, and deduplication. Choose ONTAP when consolidating mixed Linux NFS and Windows SMB shares needing cross-protocol access with Multi-AZ redundancy, or when migrating from on-prem NetApp. FSx for OpenZFS fills a niche for Linux workloads needing ZFS features (snapshots, clones) over NFS. Don’t confuse ONTAP’s multi-protocol strength with the other variants.

Choose wrong and you fail cleanly: EBS for a shared workload, EFS for a Windows SMB share, or Lustre for an AD-integrated Windows share are all misfits — match protocol and access pattern first.

Storage Gateway: Hybrid Access

Storage Gateway presents cloud storage as if it were local. This is distinct from DataSync, which moves data.

For a rendering application that moved its media library to S3 but still needs low-latency reads on-prem, S3 File Gateway is the fit — NFS/SMB access, local cache, cold objects fetched from S3 on demand. FSx File Gateway is the branch-office answer: LAN-speed SMB cache of a central cloud FSx share, not a solution for shared access between EC2 instances (which should mount FSx directly). Volume Gateway applies when the workload uses block iSCSI rather than file semantics. Tape Gateway replaces physical tape libraries under existing backup software.

Data Transfer and Migration

AWS DataSync is agent-based online migration for NFS, SMB, HDFS, and object stores to S3, EFS, or FSx — up to 10× faster than open-source tools, with encryption, integrity verification, scheduling, and preservation of POSIX metadata and NTFS ACLs. For a large-scale SMB migration with millions of small files and deep hierarchies, the least-overhead answer is DataSync into FSx for Windows: SMB is preserved, ACLs/timestamps intact, small-file throughput handled via parallel transfers, no application changes. Migrating such a dataset directly into S3 is a trap — object storage handles small-file listings in deep prefixes poorly and SMB clients cannot mount buckets.

AWS Snow Family ships physical appliances for offline transfer: Snowcone (up to 8 TB, edge-ruggedized), Snowball Edge (up to ~80 TB usable, with compute options), and Snowmobile (exabyte-scale). Rule of thumb: if network transfer would take longer than a week, Snowball is cheaper and faster.

AWS Transfer Family exposes SFTP, FTPS, FTP, and AS2 backed by S3 or EFS — the right answer when external partners must keep using standard file-transfer protocols.

AWS Backup, Cross-Region Copy, and Vault Lock

AWS Backup centralizes policy across EBS, EFS, FSx, RDS, DynamoDB, S3, and more. A backup plan defines schedule, warm retention, cold-storage transition, and cross-Region/cross-account copy actions:

BackupPlan:
  Rules:
    - RuleName: DailyWithDRCopy
      TargetBackupVault: prod-vault
      ScheduleExpression: "cron(0 5 * * ? *)"
      Lifecycle:
        MoveToColdStorageAfterDays: 30
        DeleteAfterDays: 2555        # 7 years
      CopyActions:
        - DestinationBackupVaultArn: arn:aws:backup:eu-west-1:...:backup-vault:dr-vault
          Lifecycle:
            MoveToColdStorageAfterDays: 30
            DeleteAfterDays: 2555

Cold-storage transition requires at least 90 days of warm retention plus at least 90 days in cold; misconfigured lifecycles are rejected. For true multi-year regulatory retention, pair with AWS Backup Vault Lock (WORM), which prevents even administrators from shortening retention — satisfying SEC 17a-4 and similar mandates. Cross-Region copy addresses regional DR; cross-account copy addresses ransomware and insider-threat scenarios by isolating backups from the production account’s blast radius.

Selection Cheat Sheet

← Previous: Serverless · All domains · Next: Data Transfer →

Practice Storage questions → · Timed practice on ExamRoll.io →

Browse Amazon →