AWS is moving towards longer EC2 and EBS IDs and you can enable them for an IAM user or at an account level using the root credentials. You can avoid using the root credentials by using an IAM role instead. This is a quick post to explain the steps needed to use an IAM role on an instance to enable the longer IDs at an account level.
Update: You can now use the --principal-arn argument to to make this change to the root account, see the AWS support post here.
Update 2: Another alternative, using this script.
1. Create a policy allowing modify and describe of ID format (IAM console -> Policies -> Create Policy -> Create Your Own Policy). The following policy document (originally from here with the Deny changed to Allow) provides the necessary permissions,
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:ModifyIdFormat", "ec2:DescribeIdFormat"
],
"Resource": "*"
}
]
}
2. Create an EC2 role (IAM console -> Roles -> Create New Role -> [Pick a name] -> Amazon EC2). Select the policy name you created in step 1 and attach it to the role.
3. Launch an instance with the role. It is probably easiest to use an Amazon Linux AMI as the AWS CLI is installed by default. Instance size and region don't really matter.
4. SSH to the instance and use the CLI to enable the longer IDs in the region that you would like to test against:
$ aws --region eu-west-1 ec2 modify-id-format --resource instance --use-long-ids
If you don't specify a region the CLI will prompt you to run 'aws configure' to set a default. To check the status of the ID format you can use describe-id-format:
$ aws --region eu-west-1 ec2 describe-id-format
{
"Statuses": [
{
"UseLongIds": false,
"Resource": "reservation"
},
{
"UseLongIds": true,
"Resource": "instance"
},
{
"UseLongIds": false,
"Resource": "volume"
},
{
"UseLongIds": false,
"Resource": "snapshot"
}
]
}
5. Longer IDs are now enabled for the account. Resources created by the root account (such as Auto Scaled instances) will be launched with longer IDs.
Thursday, 5 May 2016
Wednesday, 4 May 2016
'Connection to s3.amazonaws.com timed out' using VPC S3 Endpoint
A quick post to point you in the right direction if you are getting connection time out errors using the AWS CLI or Boto with AWS S3 VPC Endpoints in a private subnet. The two most likely causes of this are:
1. Your bucket name contains dots.
To work around this you can specify the region of the bucket, for example:
aws --region eu-west-1 s3 ls s3://bucket.with.dots/
2. You are trying to access a bucket in a different region.
This is not supported by VPC Endpoints, see the restrictions here.
1. Your bucket name contains dots.
To work around this you can specify the region of the bucket, for example:
aws --region eu-west-1 s3 ls s3://bucket.with.dots/
2. You are trying to access a bucket in a different region.
This is not supported by VPC Endpoints, see the restrictions here.
Subscribe to:
Posts (Atom)