AWS Storage and Migration Architecture Playbook (2026)

Scope and baseline date

This playbook covers storage and data movement choices that are frequently confused in production AWS architectures. Guidance reflects AWS positioning and documentation available as of May 18, 2026. The goal is operationally sound decisions across durability, latency, retrieval behavior, migration windows, and compliance boundaries.

How to read this document

Treat each comparison as a workload-fit decision instead of a feature checklist. For every pair:

1. Define data access pattern and recovery objectives.
2. Validate throughput, latency, and lifecycle needs.
3. Confirm migration and operations model with CLI checks.

If your team cannot state restore-time expectations before selecting storage, pause and define recovery objectives first. Most costly storage mistakes happen before any service is provisioned.

1) Amazon S3 and Amazon EBS

This is object storage versus block storage.

Choose Amazon S3 when:

• Data is object-oriented (files, artifacts, logs, media, backups, data lake content).
• You need high durability and API-based object lifecycle automation.
• Workloads can tolerate object-store semantics rather than filesystem/block semantics.

Choose Amazon EBS when:

• You need low-latency block devices attached to EC2.
• Applications expect filesystem semantics on top of block volumes.
• You need explicit volume performance classes and fine-grained IOPS control for instance-bound data paths.

Design warning:

• S3 is not a direct drop-in for block-mounted transactional storage.
• EBS is not a replacement for globally accessible object archives.

CLI checkpoint

aws s3api list-buckets
aws ec2 describe-volumes --max-results 20
aws ec2 describe-volume-status --max-results 20

2) Amazon S3 and Amazon EFS

This is object API versus shared POSIX file system semantics.

Choose S3 for:

• Static assets, backup objects, data lakes, and event-driven object processing.
• Large object fleets where request pattern and lifecycle policy drive cost optimization.

Choose EFS for:

• Shared file access from multiple compute clients.
• POSIX-compatible application expectations and lift-and-shift Linux file share patterns.
• Scenarios where serverless or containerized workloads need concurrent read/write filesystem behavior.

Operational note:

• Teams often keep source objects in S3 and publish working sets to EFS only where shared mutable file semantics are required.

CLI checkpoint

aws s3api list-buckets
aws efs describe-file-systems
aws efs describe-mount-targets --file-system-id YOUR_EFS_ID

3) Amazon EBS and Amazon EFS

Both serve active workloads, but with different attachment and sharing models.

Choose EBS when:

• Storage should be tightly coupled to one instance lifecycle (or limited multi-attach patterns where supported).
• You need controlled block-level performance profiles.
• Application design expects local-volume style behavior.

Choose EFS when:

• Multiple compute nodes must mount shared storage concurrently.
• File-level coordination is easier than object-level data exchange.
• Your workload growth pattern benefits from managed elasticity in shared file access.

Architecture guardrail:

• Do not force EBS into multi-client collaboration patterns that are fundamentally shared-filesystem problems.
• Do not use EFS for workloads that actually require deterministic block IOPS tuning per node.

CLI checkpoint

aws ec2 describe-volumes --max-results 20
aws efs describe-file-systems
aws efs describe-file-system-policy --file-system-id YOUR_EFS_ID

4) Amazon EFS and Amazon FSx

This is generic shared Linux file service versus workload-specific file systems.

Choose EFS when:

• You need managed NFS-style shared Linux file storage with minimal operational complexity.
• Your workload does not require specialized protocol/tooling from enterprise file systems.

Choose Amazon FSx when:

• Workload requires filesystem-specific behavior such as Windows file shares, Lustre acceleration, NetApp ONTAP features, or OpenZFS behavior.
• You need advanced enterprise file-service features tied to specific protocols, management tooling, or performance profiles.

Practical migration pattern:

• Start with EFS only when requirements are generic and portable.
• Move to a specific FSx flavor when specialized file-service capabilities become mandatory.

CLI checkpoint

aws efs describe-file-systems
aws fsx describe-file-systems
aws fsx describe-data-repository-associations

5) S3 Standard and S3 Glacier classes

This is hot access versus archive economics.

Choose S3 Standard when:

• Access is frequent, unpredictable, or latency-sensitive.
• You need immediate retrieval without archive restore workflows.

Choose S3 Glacier classes when:

• Access is rare and data retention horizons are long.
• Cost optimization is prioritized over immediate retrieval.
• You can operationalize retrieval timing and restore workflows.

Lifecycle strategy:

• Keep recent objects in Standard.
• Transition by age and access profile into colder classes.
• Test restore runbooks quarterly so archive data is operationally recoverable, not merely “stored.”

CLI checkpoint

aws s3api get-bucket-lifecycle-configuration --bucket YOUR_BUCKET
aws s3api put-bucket-lifecycle-configuration --bucket YOUR_BUCKET --lifecycle-configuration file://lifecycle.json
aws s3api list-object-versions --bucket YOUR_BUCKET --max-items 20

6) S3 Standard-IA and S3 One Zone-IA

This is resilience domain versus lower-cost single-AZ infrequent access.

Choose Standard-IA when:

• Data is infrequently accessed but still requires multi-AZ resilience.
• Risk tolerance does not allow single-AZ dependency for that dataset.

Choose One Zone-IA when:

• Data can be recreated or restored from other sources.
• You intentionally accept single-AZ risk in exchange for lower storage cost.

Governance rule:

• One Zone-IA should require explicit data owner sign-off documenting recovery path and business impact.

CLI checkpoint

aws s3api get-bucket-location --bucket YOUR_BUCKET
aws s3api get-bucket-versioning --bucket YOUR_BUCKET
aws s3api get-bucket-replication --bucket YOUR_BUCKET

7) AWS DataSync and AWS Transfer Family

This is managed transfer automation versus managed protocol endpoints for partner/user exchange.

Choose DataSync when:

• You need scheduled or recurring high-throughput data copy between storage endpoints.
• You want managed movement with verification and automation controls.
• Data movement is platform-driven, not human/partner interactive file exchange.

Choose Transfer Family when:

• You need managed SFTP/FTPS/FTP endpoints for partners, customers, or internal users.
• External systems require traditional file-transfer protocols with account-level access patterns.

Operational distinction:

• DataSync is a transfer engine for system-to-system movement.
• Transfer Family is an endpoint service for protocol-based file exchange users.

CLI checkpoint

aws datasync list-tasks
aws datasync list-locations
aws transfer list-servers
aws transfer list-users --server-id YOUR_TRANSFER_SERVER_ID

8) AWS Snow Family and AWS DataSync

This is offline/edge physical transport versus online network transfer.

Choose Snow Family when:

• Network transfer windows are impractical for required data volumes.
• Edge or disconnected environments require physical device workflows.
• Compliance or site constraints demand controlled offline transfer logistics.

Choose DataSync when:

• Network paths are available and transfer operations can run continuously or on schedule.
• You need recurring synchronization and operational automation.

Hybrid strategy:

• Seed large historical datasets with Snow.
• Keep deltas flowing via DataSync after baseline cutover.

CLI checkpoint

aws snowball list-jobs
aws snowball describe-addresses
aws datasync list-tasks
aws datasync list-task-executions --task-arn YOUR_TASK_ARN

9) AWS DMS and AWS Snow Family

This decision compares logical database migration/replication with physical data shipping.

Choose AWS DMS when:

• You need schema/data migration with optional ongoing replication.
• Cutover requires minimal downtime with change-data-capture behavior.
• Source and target systems are network reachable and replication semantics are required.

Choose Snow Family when:

• The bottleneck is raw data volume over constrained links.
• Initial movement is physical and network migration windows are unrealistic.

Combined enterprise pattern:

1. Bulk load historical data via Snow where network is insufficient.
2. Use DMS for delta replication and controlled cutover.
3. Validate row counts, checksums, and application reconciliation before production switch.

CLI checkpoint

aws dms describe-replication-instances
aws dms describe-endpoints
aws dms describe-replication-tasks
aws snowball list-clusters

Tutorial: lifecycle policy and archive governance

Create and apply an S3 lifecycle policy that transitions objects by age.

lifecycle.json

{
  "Rules": [
    {
      "ID": "archive-policy",
      "Status": "Enabled",
      "Filter": {"Prefix": ""},
      "Transitions": [
        {"Days": 30, "StorageClass": "STANDARD_IA"},
        {"Days": 120, "StorageClass": "GLACIER"}
      ],
      "NoncurrentVersionTransitions": [
        {"NoncurrentDays": 30, "StorageClass": "STANDARD_IA"},
        {"NoncurrentDays": 120, "StorageClass": "GLACIER"}
      ]
    }
  ]
}

aws s3api put-bucket-versioning --bucket YOUR_BUCKET --versioning-configuration Status=Enabled
aws s3api put-bucket-lifecycle-configuration --bucket YOUR_BUCKET --lifecycle-configuration file://lifecycle.json
aws s3api get-bucket-lifecycle-configuration --bucket YOUR_BUCKET

Tutorial: migration cutover readiness checks

Use this checklist before database migration cutover.

1. Confirm source and target endpoint connectivity.
2. Validate replication instance capacity and failover plan.
3. Verify full load completion metrics.
4. Verify CDC lag is within cutover threshold.
5. Freeze high-risk writes during final consistency window.
6. Run application-level data integrity checks.
7. Keep rollback path ready until post-cutover verification closes.

CLI helpers:

aws dms describe-replication-tasks --filters Name=replication-task-id,Values=YOUR_TASK_ID
aws dms describe-table-statistics --replication-task-arn YOUR_TASK_ARN
aws cloudwatch get-metric-statistics --namespace AWS/DMS --metric-name CDCLatencySource --statistics Average --period 60 --start-time 2026-05-18T00:00:00Z --end-time 2026-05-18T01:00:00Z

Operational anti-patterns to avoid

• Treating archive classes as “backup strategy” without restore testing.
• Choosing One Zone-IA without explicit recovery owner and tested recreation plan.
• Using EBS where many clients need concurrent shared writes.
• Selecting Transfer Family for internal batch replication that should be DataSync.
• Expecting DMS alone to solve large offline-first data transport constraints.

Storage governance model for 2026 teams

Adopt four explicit controls:

1. Data classification: map datasets by sensitivity and availability requirement.
2. Lifecycle policy: define hot/warm/cold transitions with ownership.
3. Recovery testing cadence: test restore and replay from each tier.
4. Migration runbooks: document cutover and rollback with clear thresholds.

When these controls exist, service choice becomes measurable and repeatable instead of opinion-driven.

Extended architecture decision worksheet

Use these prompts in architecture review meetings:

• What is the 95th percentile object retrieval urgency for this dataset?
• Can this data be recreated? If yes, from where and within what timeframe?
• Does this workload require block device semantics or shared file semantics?
• Is transfer human-driven (partner protocol) or system-driven (scheduled data movement)?
• Is the first migration move online, offline, or hybrid?
• What are the security and key-management boundaries for data at rest and in transit?
• How will lifecycle transitions be audited and exception-handled?

These prompts force explicit trade-offs and usually surface hidden risks before implementation.

Final recommendations

For most teams:

• Start with S3 for object-centric data domains.
• Use EBS only where block semantics are required.
• Use EFS for shared Linux file workloads and FSx when specialized filesystem behavior is required.
• Treat archive tiers as operational workflows, not passive cost knobs.
• Use DataSync for system movement, Transfer Family for protocol endpoints, and Snow for offline scale constraints.
• Use DMS for replication-aware cutovers and combine with Snow when data gravity demands it.

References

• https://docs.aws.amazon.com/decision-guides/latest/storage-on-aws-how-to-choose/choosing-aws-storage-service.html
• https://docs.aws.amazon.com/decision-guides/latest/migration-on-aws-how-to-choose/migration-on-aws-how-to-choose.html
• https://docs.aws.amazon.com/datasync/latest/userguide/what-is-datasync.html
• https://docs.aws.amazon.com/transfer/latest/userguide/what-is-aws-transfer-family.html
• https://docs.aws.amazon.com/snowball/latest/developer-guide/whatissnowball.html
• https://docs.aws.amazon.com/dms/latest/userguide/Welcome.html
• https://docs.aws.amazon.com/AmazonS3/latest/userguide/lifecycle-transition-general-considerations.html

Deep-dive scenarios and migration patterns

Scenario A: Media platform with multi-year retention

A media platform ingests large video objects daily, serves recent content frequently, and keeps older assets for legal retention. Teams often overpay by keeping everything in hot storage.

A practical pattern:

• Store new assets in S3 Standard.
• Transition older assets into infrequent/archival classes using lifecycle rules.
• Keep metadata in a fast query store to avoid scanning archives for catalog operations.
• Test restore workflow before legal or customer-facing deadlines.

Key lessons:

• Archive without tested retrieval is operational risk, not optimization.
• Lifecycle controls need exception tags for assets that must remain hot.

Scenario B: Enterprise NAS modernization

An enterprise migrating legacy file shares often faces a confusing EFS-versus-FSx decision.

Use EFS when the goal is Linux-shared file access with minimal administration. Use FSx when organizational requirements include protocol/feature expectations from Windows shares, Lustre throughput patterns, or NetApp/OpenZFS capabilities.

Migration recommendation:

1. Segment workloads by protocol and feature dependency.
2. Migrate generic shared workloads first.
3. Move specialized workloads to the correct FSx family with pilot validation.

Scenario C: Factory edge data transfer

Factories and offshore sites may generate large telemetry bundles with constrained uplink bandwidth. Online transfer can be impractical for initial baselines.

Pattern:

• Use Snow devices for historical baseline export.
• Resume continuous delta transfer with DataSync where links permit.
• Monitor transfer lag and automate exception handling for delayed sites.

This combination usually reduces time-to-visibility while preserving operational continuity.

Cost and performance modeling guidance

Storage decisions should include both direct service pricing and operational effort.

Model these dimensions:

1. Access frequency by dataset age.
2. Retrieval urgency (minutes, hours, days).
3. Volume growth trend and retention policy.
4. Replication and cross-region requirements.
5. Incident recovery workload and staffing readiness.

Example interpretation:

• If retrieval urgency is strict and unpredictable, hot storage bias is safer.
• If access declines rapidly with age and recovery windows are flexible, lifecycle transitions can materially reduce cost.

Security and compliance controls

For storage and migration pipelines, enforce:

• Encryption at rest and in transit.
• Least-privilege IAM for movement tasks and endpoint services.
• Immutable audit logs for migration runs and policy changes.
• Data classification labels tied to storage policy.
• Explicit key rotation and access review cadence.

Controls to standardize:

• Deny unencrypted upload paths.
• Restrict public access policies by default.
• Require change review for lifecycle and replication policy updates.
• Monitor failed transfer tasks with alerting and ticket automation.

CLI mini-lab: transfer and migration health

#!/usr/bin/env bash
set -euo pipefail

echo "== Storage inventory =="
aws s3api list-buckets
aws efs describe-file-systems
aws fsx describe-file-systems

echo "== Transfer inventory =="
aws datasync list-tasks
aws transfer list-servers
aws snowball list-jobs

echo "== Migration inventory =="
aws dms describe-replication-instances
aws dms describe-replication-tasks

Data owner questionnaire (use before provisioning)

1. What is the maximum acceptable restore time for this dataset?
2. What proportion of data is accessed after 30, 90, and 365 days?
3. Can data be rebuilt from source systems, and how long does rebuild take?
4. Do multiple compute clients need concurrent shared writes?
5. Are external partners using SFTP/FTPS/FTP as mandatory protocols?
6. Is initial migration network-feasible, or does it need physical transport?
7. What evidence is required for audit and compliance review?

Final operating model

By 2026, strong teams treat storage as a lifecycle system:

• Data lands in the right service for current access behavior.
• Data transitions based on policy, not manual cleanup events.
• Migration strategies combine online and offline patterns pragmatically.
• Recovery drills are tested regularly and documented.

When these practices exist, storage architecture decisions become durable, cost-aware, and incident-resilient.

Practical cutover timeline template

Use this timeline as a reusable migration rhythm for large storage or database moves.

• T-30 days: finalize service selection, validate IAM policies, and define success metrics.
• T-21 days: run pilot transfer with representative data volume and record throughput.
• T-14 days: execute first full rehearsal and verify downstream application behavior.
• T-7 days: freeze non-essential schema/pipeline changes and publish rollback steps.
• T-2 days: run final differential sync and reconciliation checks.
• T day: perform controlled cutover window, monitor latency/error/lag metrics live.
• T+1 day: validate business KPIs, reconcile counts, and close incident watch.

This operational discipline prevents most migration surprises by surfacing compatibility and throughput constraints early.

What “done” looks like

A storage or migration project is complete only when:

• Data movement succeeded with validated integrity checks.
• Recovery from target storage was tested, not assumed.
• Monitoring and alerting are active for transfer failures and policy drift.
• Data owners approved lifecycle, retention, and archive retrieval rules.
• Runbooks are documented and usable by the on-call team.

Short reminder

Do not finalize any storage decision without verifying three things in a live account: encryption defaults, lifecycle policy behavior, and restore workflow timing. Teams that validate these early avoid expensive redesign later. Add periodic governance review meetings so data owners, security, and platform teams review transfer failures, archive retrieval requests, and lifecycle exceptions together. This single habit keeps storage architecture aligned with real business behavior.