An Amazon EBS volume is in us-east-1a and you need the same data on an instance in us-east-1b, and later in eu-west-1. What is the scope of an EBS volume compared with an EBS snapshot, and how do you actually move the data?

## What an EBS volume is Amazon Elastic Block Store (EBS) gives an EC2 instance a **network-attached block device** — it looks like a raw disk to the operating system, but it is not physically inside the host. That indirection is what makes the data survive stopping, starting, or replacing an instance. It also means EBS has its own placement rules, and the first one candidates trip over is scope. An EBS volume is created **in one Availability Zone** and stays there. When you call `CreateVolume` you must pass an `AvailabilityZone`, and the volume can only be attached to instances in that AZ. Behind the scenes AWS replicates the volume's data across multiple devices *within* that single AZ — that redundancy protects you from a device failure, not from an AZ failure. The AZ is both the durability domain and the latency domain: an instance talks to its volume over a network path that is only short because both sit in the same zone. ## The snapshot is the portable object A snapshot is a point-in-time copy of a volume held in **S3 storage managed by AWS** — it is billed to you as EBS snapshot storage, but it does not appear in any bucket you own. Crucially, a snapshot is a **Region-scoped** resource: it is visible from every AZ of the Region it was taken in. That asymmetry is the whole answer to "how do I move a volume": - To reach **another AZ in the same Region**: `CreateSnapshot` on the source volume, then `CreateVolume` from that snapshot with the target AZ. - To reach **another Region or another account**: `CopySnapshot` (or share the snapshot with the target account), then create the volume from the copy in the destination. Restoring is not a byte-for-byte clone. From one snapshot you may create a volume that is **larger** than the original (never smaller), of a **different volume type** (for example restore a `gp2` snapshot onto `gp3`), and you may set `Encrypted` on the new volume even if the snapshot was unencrypted. That makes "snapshot and restore" the standard migration and re-platforming tool, not just the backup tool. ```bash aws ec2 create-snapshot --volume-id vol-0abc --description "pre-move" aws ec2 create-volume --availability-zone us-east-1b \ --snapshot-id snap-0abc --volume-type gp3 ``` ## What this means for availability design Because a volume cannot span AZs, any instance-plus-EBS design has an **AZ-sized blast radius** for that data. If the AZ is impaired, the volume is unreachable until it recovers; you do not fail over an EBS volume the way you fail over a Multi-AZ RDS instance. The usual answers are: keep recent snapshots (optionally copied to a second Region for disaster recovery), replicate at the application layer, or put the data in a service that is Regional by design — S3, DynamoDB, EFS — rather than on a single block device. That is also why snapshot copies are a real DR lever: a cross-Region snapshot copy costs storage plus one-time data transfer, and it converts "we lost a Region" from unrecoverable into a restore with a known, measurable recovery time. ## Two adjacent facts people confuse **An AMI is not a volume.** An AMI is a machine image backed by one or more snapshots. Copying an AMI to another Region copies its underlying snapshots. If you only need data, snapshot the data volume; if you need a bootable machine, use an AMI. **`DeleteOnTermination`** is an attribute of the block-device mapping, not of the volume's scope. By default a root volume created with an instance is deleted when that instance terminates, while volumes you attach later are not. Getting this wrong destroys data that the AZ boundary had nothing to do with. ## Performance after a restore A volume created from a snapshot is available immediately, but its blocks are pulled from S3 **on first access**. Until a block has been touched once, reading it costs a round trip to snapshot storage, so a freshly restored database volume can feel dramatically slower than the original for minutes to hours. You either accept that, pre-read the whole device to warm it, or enable Fast Snapshot Restore on the snapshot in the target AZ so volumes come up fully initialised.