Boto3: EC2 Copy Snapshot Ignoring Destination Region Parameter

[Raiju1]

When I attempt to call copy_snapshot using the DestinationRegion parameter, it is ignored in favour of the region that the Lambda is run from.

For example, I wanted to copy a snapshot from us-east-1 to us-west-2, so I made this call similar to the one in the boto3 docs:

response = ec2.copy_snapshot(
    SourceSnapshotId='snapshotId',
    DestinationRegion='us-west-2',
    SourceRegion='us-east-1',
    Description = "TEST"
)

The response that I receive looks correct, however instead of the copy going to us-west-2, it winds up in the region from which I call the Lambda which is generally us-east-1.

When I make the call using the AWS CLI, I get the same result as I expect (copy goes to us-west-2), so I feel like this is an issue on boto's end.

[JordonPhillips]

boto3 and the cli use the exact same code base (botocore) to handle this. The destination region is implied by the region you send the request to. We should probably hide that parameter from the docs since we don't expect it to be set.

[Raiju1]

@JordonPhillips If this is the case, does that mean that I'm limited to copying snapshots to regions that support Lambda if I want to use a Lambda function to do so and am out of luck for regions that do not (us-west-1 for example), or is there a way to get around this?

[JordonPhillips]

@Raiju1 no, that just means that when copying to a region you need to use a client configured for that region.

[Raiju1]

@JordonPhillips Alright, I get what you're saying, thanks a lot for the help!

[FrancescoRizzi]

I was going to point out the inconsistency in the boto3 documentation (DestinationRegion is described in the Parameters section, but not used in the Request Syntax section)... but now that I read this...

If I read correctly, you're saying the ec2 client.copy_snapshot does not use the DestinationRegion at all, because it uses the "current" region (from the client's session) as the destination. And, indeed, it requires the SourceRegion argument (feels like we could call this a "pull" model).

If I'm writing a script to run, for instance, on my machine, I can establish a session with the source region, look among the snapshots to find one I wish to copy (grab its id), then establish a separate/new session with the destination region, and use the ec2 client copy_snapshot to perform the copy.
Feels a bit clunky, but ...hmm.. ok..

But if I am a Lambda?
If I'm a Lambda running _in the source region_, then it's easy to look at the snapshots available to find the one I want to copy, but then I have to make a separate session with the destination region, and use that client's copy_snapshot method. Right?

'Cause if my Lambda was running _in the destination region_ (in which case the client on which I call copy_snapshot can use the implicit current region), I don't think I have a way to get the list of available snapshots from the source region (no filter in DescribeSnapshots talks about regions)... except by opening a separate session with the source region and using a client from that session ...

It does feel clunky, doesn't it?

[vineethvijay]

This is possible as @FrancescoRizzi suggested, lambda function can be run from destination region, but set the region parameter in the code to the source region where you have the snasphots.

region = 'eu-central-1'
ec = boto3.client('ec2',region_name=region)

def lambda_handler(event, context):
    response=ec.copy_snapshot(SourceSnapshotId='snap-082*********4aac2',
                     SourceRegion=region,
                     DestinationRegion='eu-west-1',
                     Description='copied from Frankfurt')
    print (response)

Here, the lambda function is created in eu-west-1(Ireland), and SourceSnapshotId is a snap Id from eu-central-1(Frankfurt)

[github-actions[bot]]

Greetings! It looks like this issue hasn’t been active in longer than one year. We encourage you to check if this is still an issue in the latest release. Because it has been longer than one year since the last update on this, and in the absence of more information, we will be closing this issue soon. If you find that this is still a problem, please feel free to provide a comment to prevent automatic closure, or if the issue is already closed, please feel free to reopen it.