How to you get an AWS client-token to use with `aws ec2 run-instances`

amazon ec2amazon-web-servicesaws-cli

As described here https://aws.amazon.com/blogs/aws/new-amazon-ec2-feature-idempotent-instance-creation/ AWS CLI enforces idempotency of the aws ec2 run-instances --cli-input-json command. Unfortunately there is no documentation on how a client-token is generated.

I did find that there is a ClientToken field in the aws ec2 describe-instances results, but of course you still get the following error if you try to use one:

An error occurred (IdempotentParameterMismatch) when calling the RunInstances operation: Arguments on this idempotent request are inconsistent with arguments used in previous request(s).

How do I get a token to use with --client-token?

Best Answer

You make one up!

Putting any string < 64 chars will work. The describe call simply gives you back the client-token string used to create the instance

The idea then is then you handle failures like this.

Generate the client Token i.e. "Bobs instance"
Make successful run instance call with client-token
Something goes wrong on the client i.e. Script fails or times out
Your code starts again and generates the same client token( the trick is making sure this happens)
You get an a success but you actually get back the same response with same reservation-Id you got the first time you made the request and no second instance is created

I suggest reading http://docs.aws.amazon.com/AWSEC2/latest/APIReference/Run_Instance_Idempotency.html for more info on idempotency.

It's been ages since I coded this but I believe when I did it I had my workers use the SQS message ID as the client-token, so if my workers failed, or sqs delivered twice, I wouldn't leak instances.

Related Solutions

Access Denied when calling the CreateInvalidation operation on AWS CLI

IAM Policies do not allow restriction of access to specific CloudFront distributions. The solution is to use a wildcard for the resource, instead of only referencing a specific CloudFront resource. Adding that to your IAM policy will fix the issue you're having.

Here is an example of that in a working IAM policy:

{
  "Statement": [  
    {
      "Effect": "Allow",
      "Action": "s3:*",
      "Resource": "arn:aws:s3:::*"
    },
    {
      "Effect": "Allow",
      "Action": [
        "cloudfront:CreateInvalidation",
        "cloudfront:GetInvalidation",
        "cloudfront:ListInvalidations"
      ],
      "Resource": "*"
    }
  ]
}

Docs:

Windows – AWS Encrypted EBS Boot Volumes for Windows Instances

It is now possible to do this (as of May 2019). You do not need to copy an AMI. Instead you can launch an instance with encrypted volumes (boot/ephemeral/ebs) directly from an unencrypted marketplace AMI.

I have not tried to do this with the CLI or programmatically, but it works from the EC2 console using the latest windows server image (Windows_Server-2019-English-Full-Base-2019.08.16)

The "extra steps" that detail creating/copying your own private AMI have been removed from their latest documentation. I could not find any more information on it other than this blog post.

Launch Encrypted EBS Bcked EC2 Instances from Unencrypted AMI's

Best Answer

Related Solutions

Access Denied when calling the CreateInvalidation operation on AWS CLI

Windows – AWS Encrypted EBS Boot Volumes for Windows Instances

Related Topic