EC2 create-image on Outposts now fails without --snapshot-location: 2 values, 0 copies back to the Region

Summary. On 19 August 2026 AWS announced that Amazon EC2 can create Amazon Machine Images with local snapshots from instances on AWS Outposts, and said the change "enables customers to integrate AMI creation into their existing backup and lifecycle workflows for instances on Outposts". The Amazon EBS user guide adds a sentence the announcement leaves out: if the source instance sits on an Outpost that supports local snapshots, the --snapshot-location parameter is required, and "if you omit it, the request fails with an InvalidParameterValue error". Every unchanged create-image call against an Outpost instance now breaks. The flag takes 2 values, local and regional. Once an AMI is backed by local snapshots there are 0 supported ways to copy it back to a Region, to another Outpost, or within the same Outpost, and it can launch instances only on the Outpost that holds it. Amazon S3 capacity freed by deleting local snapshots takes up to 72 hours to return.

The feature is genuinely useful for data residency. It is not a drop-in addition to an existing backup pipeline, which is the reading the announcement invites.

What AWS said, and what the flag does

The What's New entry states that when keeping data local, "EC2 automatically determines the target Outpost from the instance's location, no need to manually specify an Outpost ARN". That part is accurate. You do not supply an Outpost ARN.

You supply something else instead. The EBS local snapshots on Outposts page documents the mechanism:

aws ec2 create-image \
    --instance-id i-1234567890abcdef0 \
    --name "My Outpost image" \
    --snapshot-location local

local stores the backing snapshots on the same Outpost as the instance. regional stores them in the parent Region. There is no default. On an Outpost that supports local snapshots, the parameter is mandatory, and the failure mode is a rejected API call rather than a silent choice.

That is the operational headline. Any Data Lifecycle Manager policy, backup script, Systems Manager runbook or CI job that calls create-image against an Outpost instance and predates this release will now error until someone adds the flag. AWS did not mention it.

What you can and cannot do with the result

Operation	Local snapshots on an Outpost	Snapshots in the parent Region
Copy to the Region	Not supported	n/a
Copy to another Outpost	Not supported	Supported, Region to Outpost only
Copy within the same Outpost	Not supported	n/a
Share the snapshot	Not supported	Supported
Fast snapshot restore	Not supported	Supported
EBS direct APIs	Not supported	Supported
Launch Spot Instances or Spot Fleet	Not supported	Supported
Launch an Auto Scaling group	Same Outpost subnet only	Supported

The copy row is the one that changes disaster-recovery design. The EBS guide is explicit: "You can't copy local snapshots or AMIs from an Outpost to an AWS Region, from one Outpost to another, or within an Outpost. However, you can copy snapshots from an AWS Region to an Outpost." AMI copies from a Region to an Outpost work through the copy-image CLI command only, not the console.

So the data flows one way. An image built to satisfy residency stays where it was built, and if that Outpost is lost, the image is lost with it. Teams that treat AMIs as a recovery artefact need a second, Region-stored image built with --snapshot-location regional, which by definition does not meet the residency requirement the local option exists to serve. That tension is the design decision, and no flag resolves it.

Auto Scaling is a partial exception worth knowing. Groups can launch from AMIs backed by local snapshots, but only into a subnet on the same Outpost, and the Amazon EC2 Auto Scaling service-linked role needs permission on the KMS key used to encrypt the snapshots. Launching such a group in a Region is not supported. Spot Instances and Spot Fleet are excluded outright.

The lineage rule that decides your first snapshot

The EBS guide sets rules that make the storage location sticky per volume:

If the most recent snapshot of a volume is on an Outpost, every successive snapshot must go to the same Outpost.
If the most recent snapshot is in a Region, every successive snapshot must stay in that Region.
Local snapshots, whether created on the Outpost or copied to it from a Region, can create volumes only on that same Outpost.
A volume created on an Outpost from a Region snapshot keeps taking Region snapshots. A volume created from a local snapshot keeps taking local ones.

Switching an existing volume from Region storage to local storage is a four-step rebuild: snapshot the volume in the Region, copy that snapshot to the Outpost, create a new volume from the local snapshot, then attach the new volume to an instance on the Outpost. There is no in-place flip.

One more constraint applies to the AMI itself. You cannot create an AMI whose backing snapshots are spread across multiple Outposts. Mixing an Outpost-local data volume with a Region-stored root volume is allowed and documented; mixing two Outposts is not.

Residency: what the IAM control actually covers

The announcement frames this as a residency capability, and the EBS guide agrees that IAM is the enforcement mechanism. The example policy denies ec2:CreateSnapshot and ec2:CreateSnapshots where ec2:SourceOutpostArn matches a specific Outpost and ec2:OutpostArn is null, which blocks a principal from snapshotting an Outpost volume into the Region while still permitting local snapshots.

The same page carries an important limitation in an Important callout: "you currently can't use IAM policies to enforce data residency for CopySnapshot and CopyImage actions." Today that gap is closed by the copy restriction itself, because Outpost-to-Region copies are not supported at all. It stops being closed the day AWS ships that path, so a residency control built on this feature should be documented as depending on a product limitation, not only on a policy.

Two further residency details belong in any assessment. Snapshot metadata is stored in the AWS Region associated with the Outpost; the guide says this does not include snapshot data. And the Outpost must have connectivity to its Region to create, use or delete local snapshots, because the Region supplies access, authorization, logging and monitoring. A disconnected Outpost cannot create a new local snapshot, cannot create volumes or launch instances from existing ones, and cannot delete them.

Capacity is the failure mode to instrument

Local snapshots consume S3 on Outposts capacity, which is finite hardware rather than an elastic Region service. The guide sets out what happens at the ceiling: Data Lifecycle Manager keeps attempting to create local snapshots, "the snapshots immediately transition to the error state and they are eventually deleted by Amazon Data Lifecycle Manager". The recommended detection is the SnapshotsCreateFailed CloudWatch metric on the lifecycle policy.

Reclaiming space is slow. After you delete local snapshots, capacity "becomes available within 72 hours after deleting the snapshot and the volumes that reference that snapshot". Deleting a snapshot on a full Outpost does not free room for tonight's backup, and retention policies have to be sized with that lag in mind.

Constraint	Value	Where it is documented
Capacity reclaim after deletion	Up to 72 hours	EBS local snapshots on Outposts
Snapshot encryption	Mandatory, unencrypted not supported	EBS local snapshots on Outposts
Re-encrypt on volume create	Not allowed, same KMS key required	EBS local snapshots on Outposts
Prerequisite	Outpost provisioned with S3 on Outposts	EBS local snapshots on Outposts
Region connectivity	Required to create, use or delete	EBS local snapshots on Outposts
Backing snapshots across Outposts	Not supported in one AMI	EBS local snapshots on Outposts

Encryption is worth a line of its own. Local snapshots are always encrypted, with the Region default KMS key or one you specify at request time, and a volume created from a local snapshot must use the same key as the source snapshot. There is no re-encryption on restore, so key rotation strategy has to be settled before the first local snapshot, not after.

What to do this week

Search your automation for create-image calls that can target an Outpost instance and add --snapshot-location. Decide the value deliberately: local for anything covered by a residency obligation, regional for anything you expect to restore somewhere else. Then check whether any Data Lifecycle Manager policy writes local snapshots, and put a CloudWatch alarm on SnapshotsCreateFailed before capacity, not after. Multi-volume crash-consistent local snapshots are supported, so consistency groups do not need to change.

The judgement worth stating plainly: the real cost here is not the flag, it is the recovery plan. Choosing local converts an AMI from a portable artefact into an on-premises one, and the backup design has to say out loud what happens if the Outpost itself is unavailable.

India-specific considerations

For Indian organisations placing workloads on Outposts to keep data on premises, this closes a real gap, because AMI backing snapshots no longer have to leave the rack. Under the Digital Personal Data Protection Act 2023, the useful control is the IAM deny on ec2:CreateSnapshot with a null ec2:OutpostArn, which produces an auditable technical boundary rather than a policy statement. Two caveats belong in the same document: snapshot metadata still lands in the associated AWS Region, and the copy restriction that currently backstops the CopyImage policy gap is a product limitation AWS could lift. Teams building on this should also plan around the connectivity dependency, since an Outpost cut off from Asia Pacific (Mumbai) cannot take a local snapshot at all.

What is still unknown

AWS has not said whether --snapshot-location will gain a default value, which would restore compatibility for unchanged scripts. There is no published timeline for Outpost-to-Region copy, and therefore none for the CopySnapshot and CopyImage residency policy gap. The guide does not state a per-Outpost limit on local snapshots or AMIs, so capacity planning currently rests on S3 on Outposts sizing rather than a documented quota.

FAQ

What changed for EC2 AMIs on Outposts on 19 August 2026?

AWS enabled creating Amazon Machine Images with local snapshots directly from instances on an Outpost. The backing snapshots can be stored on the same Outpost as the instance or in its parent Region, and EC2 determines the target Outpost from the instance location rather than an Outpost ARN you supply.

Why do my existing create-image calls now fail?

The EBS user guide states that if the source instance is on an Outpost supporting local snapshots, the --snapshot-location parameter is required, and omitting it fails the request with an InvalidParameterValue error. Scripts, runbooks and lifecycle jobs written before this release must be updated with the new flag.

What values does --snapshot-location accept?

Two. Specify local to store the backing snapshots on the same Outpost as the instance, or regional to store them in the parent Region of the Outpost. There is no documented default value, which is why an omitted parameter produces an error rather than a fallback behaviour on affected Outposts.

Can I copy an Outpost AMI back to its AWS Region?

No. The EBS guide states you cannot copy local snapshots or AMIs from an Outpost to a Region, from one Outpost to another, or within an Outpost. Copies run one way only, from a Region to an Outpost, and AMI copies to an Outpost use the copy-image CLI command.

Where can I launch instances from an AMI backed by local snapshots?

Only on the same Outpost that holds the AMI. Auto Scaling groups can use these images, but only into a subnet on that Outpost, and the Auto Scaling service-linked role needs permission on the encryption key. Spot Instances and Spot Fleet cannot use local snapshots or AMIs backed by them.

How long does deleted snapshot capacity take to come back?

Up to 72 hours. The Amazon S3 storage capacity used by a deleted local snapshot becomes available within 72 hours after both the snapshot and the volumes referencing it are deleted. Retention policies should account for that lag rather than assuming deletion frees space immediately.

Do IAM policies fully enforce data residency here?

Not for every action. The EBS guide states you currently cannot use IAM policies to enforce data residency for the CopySnapshot and CopyImage actions. That gap is masked today because Outpost-to-Region copies are unsupported, so the control depends on a product limitation as much as on the policy itself.

What happens if the Outpost loses connectivity to its Region?

Local snapshot operations stop. The guide states the Outpost must have Region connectivity because the Region provides access, authorization, logging and monitoring. Without it you cannot create new local snapshots, create volumes or launch instances from existing local snapshots, or delete local snapshots.

How eCorpIT can help

Deciding between local and regional is a residency and recovery question before it is a CLI change: which workloads carry an on-premises obligation, what the recovery plan is when the image cannot leave the rack, and how key rotation works when volumes must inherit the source snapshot's KMS key. Our data residency and cloud architecture team runs that assessment alongside the AWS IAM policy limits review the deny policies usually trigger, and it pairs naturally with India data centre capacity planning. To scope it, contact our AWS infrastructure team.