0

I have a public snapshot ID, e.g. snap-d203feb5. How can I know in which US region(s) it is located?

I know that I can go on https://us-east-2.console.aws.amazon.com/ec2/v2/home?region=us-east-2#Snapshots:visibility=public;search=snap-d203feb5;sort=snapshotId and try all US regions:

enter image description here

but it is inconvenient.

  • Aren't the public data set snapshots always in us-east-1? I'm not sure this is a "webapps" question. – Michael - sqlbot Apr 14 '18 at 8:04
  • @Michael-sqlbot could be for public datasets, but I'm asking for any public snapshot id. The question is about how to use AWS website (here, the search feature) so is on topic here. – Franck Dernoncourt Apr 14 '18 at 8:32
  • 1
    I see your point, and appreciate the clarification. – Michael - sqlbot Apr 14 '18 at 12:50
1

There isn't a way to search multiple regions for an EBS snapshot. Snapshots are literally, actually located (stored) in a specific geographic region, and interactions involving that snapshot are always sent to the infrastructure in that region. (Copying a snapshot to another region creates a literal copy in the new region, with a new snapshot identifier.)

Even though the snapshot IDs are designed to be globally unique -- hence the expansion from 8 hex digits to 17 for the identifiers of new snapshots that happened in 2016 -- there doesn't appear to be a global directory.

This apparent lack of functionality seems to be explained by the fact that console interactions with AWS services are done via the documented APIs, and the console -- with very few exceptions -- is actually a front-end to the same APIs used by the SDKs and aws-cli, as opposed to being a separate, independent interface to the services. This is why the console will typically let you attempt to do something you aren't authorized to do, only to return an error, rather than gray-out or not offer those operations -- the console doesn't actually know your AWS service permissions. It sends API requests as you, the underlying service allows or denies your request, and if denied, the console returns the error.

The various services in AWS follow one of three basic architectural philosophies, which I discussed in more detail at SO, and the console reflects this in the region selection drop-down at the top right.

The most common architecture is for the service in each of the geographic regions to be administratively and operationally independent. While the regional deployments do have some cross-region communications capabilities, such as the ability to copy an EBS snapshot from one region to another, the regions only communicate with each other in a few limited circumstances. EC2, of which EBS is a part, falls into this category. Most operations are fully independent from all other regions, because more dependencies would reduce reliability and availability. If a search for a snapshot were to fan-out to each independent region, then all searches would necessarily need to fail if any one region were experiencing an operational fault and couldn't respond, otherwise search results would be inconsistent, returning an erroneous "not found" response in the event of a failure to secure a response from all regions.

The second type of service is global service, which the console will report "does not require region selection." These services, like IAM, CloudFront, and Route 53, still have operational segregation across regions, they operate from a global database that is not subject to regional modification, and all API requests are actually sent to an endpoint on one region, which happens to be the original AWS region, us-east-1, a fact that the console hides from the user because it isn't relevant. Administratively, these services are dependent on us-east-1. Operationally, they are not. A catastrophic event in us-east-1 would not prevent these services from continuing to function elsewhere, but there's a potential that no provisioning changes would be possible until such an issue was resolved.

The third architecture is a hybrid, Amazon S3. Each region is independent, yet the console "doesn't require region selection" here, either. This is because S3 is indeed a hybrid, allowing all of its regional endpoints to have access to the global database of buckets, while restricting each regional endpoint to being able to access only the contents of buckets that you declared to be created within that region (except in the case of copying objects between buckets, which S3 can do internally, even across regional boundaries, avoiding the need to download+upload). You can send an API request to any S3 regional endpoint and ask it to create a bucket in any other region, and any region can give you a list of all your buckets across all regions (but, again, not a listing of objects within the foreign buckets). So the console asks S3 where each bucket is, in the background, and routes its generated API requests to the appropriate endpoint for each action.

This is a lot of background detail, arguably helpful, offered for your consideration as a plausible explanation of why a global search for a specific EBS snapshot is not supported -- it seems to be a side effect of the design of the underlying service architecture, for reasons of reliability and scale.

  • Thanks a lot for the explanation, it is very informative! – Franck Dernoncourt Apr 14 '18 at 22:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.