aws-cli should set default region to EC2 instance region

Created on 14 Nov 2013  Â·  31Comments  Â·  Source: aws/aws-cli

Recently we provisioned an EC2 instance with the aws-cli installed that is using IAM roles. We forgot to set the AWS_DEFAULT_REGION environment variable and got an error stating that the default region was not specified.

I am proposing that aws-cli should be able to assume the given region of the EC2 instance. This would eliminate one step of adding the environment variable to the system. If the aws-cli needs to talk to a different region, it can always use a different profile or override the region.

I am sure there are implications to this that need to be thought about.

feature-request v2

Most helpful comment

All right then, +1 on the feature request, why in god's name has this not been implemented yet???

All 31 comments

It seems to me that this would require aws-cli to query every region out there to find the specified instance id. This would be slower and more expensive. Plus, instance-ids are not guaranteed to be unique between regions, so there is an (admittedly small) risk that the wrong instance could be acted on.

It is completely standard with most AWS services to have to pick which region you want to interact with and I'm not sure this should be hidden in the cli.

An alternative would be to potentially look at storing the region information into the metadata server which I believe the cli uses to get some of it's information.

As @jamesls has found, we can get the region itself from the instance metadata:

$ curl http://169.254.169.254/latest/dynamic/instance-identity/document
{
  "version" : "2010-08-31",
  "architecture" : "x86_64",
  "instanceType" : "t1.micro",
  ...
  "region" : "us-west-2",
  "availabilityZone" : "us-west-2b",
  ...
}

So, we can discover the region in which an EC2 instance is running quickly and efficiently.

If a customer ran aws configure on an EC2 instance, it would seem reasonably to offer the region in which they are currently running as the default value to place in their config file. I think this makes a lot of sense.

However, what if they are using an IAM Role rather than traditional credentials. In this case they probably wouldn't run aws configure. Should we still just automatically assume that they want to use the region of the instance as the default region? I'm not so sure about that. Sometimes it will be exactly what they want and in other situations it may be confusing.

Comments?

I misread the original question. I was thinking that an "aws ec2 ... --instance-ids X" command was being run _outside_ of EC2 and there was an expectation that the command should find the region for the specified instance before operating on it.

Now I see the question is really about running aws-cli inside an EC2 instance which has an IAM role.

+1 for defaulting the aws-cli region to the region of the current instance running aws-cli if IAM roles are being used.

This is going to correctly reduce work for the vast majority of IAM role users and is easy to override for anybody who wants a different behavior (which they would have had to do anyway even without a default).

The only other possible options are defaulting to "us-east-1" (almost certainly not what they wanted) and an error message.

Anybody who is using multiple regions should be used to specifying --region or configuring aws-cli with a region.

This is a great idea. If it's an instance and then the region is easily accessible by the metadata. If the host has something to stop access to the metadata (eg host firewall) then it can just fail as it does now. It would remove one step from my bootstrap process which currently sets the default region based on the metadata.

Any updates about potentially implementing this?

+1

+1

And aws opsworks should ignore the region specification, since it always
uses us-east-1.
On Oct 29, 2014 10:20 PM, "Dustin Withers" [email protected] wrote:

+1

—
Reply to this email directly or view it on GitHub
https://github.com/aws/aws-cli/issues/486#issuecomment-60997358.

+1

+1

+1

+1
I think this would be great, even if I had to pass a param like --use-instance-region. Right now I have to parse the region from ec2metadata and a regex and then pass it as --region.

+1

+1

+1

This still isn't a thing? Its super annoying....

I currently get around it by:

region=$(curl http://169.254.169.254/latest/dynamic/instance-identity/document|grep region|awk -F\" '{print $4}')
echo "[default]" > /root/.aws/config
echo "region = ${region}" >> /root/.aws/config

It would be so useful to have it default to the region that the instance is spawned in...

+1

+1

+1
When using an IAM EC2 Role, I don't want to have to specify region in all my CLI commands when there is only 1 region in GovCloud (us-gov-west-1). When a second region is added, just default to the region that the instance is running in.

+1

Why has this not yet been implemented?

+1

+1, ran into the same issue myself trying to run something on Boto3

any progress here? plz

As a workaround we run the following before any aws cli command:

export AWS_DEFAULT_REGION=$(curl -m5 -sS http://169.254.169.254/latest/meta-data/placement/availability-zone | sed 's/.$//')

Good Morning!

We're closing this issue here on GitHub, as part of our migration to UserVoice for feature requests involving the AWS CLI.

This will let us get the most important features to you, by making it easier to search for and show support for the features you care the most about, without diluting the conversation with bug reports.

As a quick UserVoice primer (if not already familiar): after an idea is posted, people can vote on the ideas, and the product team will be responding directly to the most popular suggestions.

We’ve imported existing feature requests from GitHub - Search for this issue there!

And don't worry, this issue will still exist on GitHub for posterity's sake. As it’s a text-only import of the original post into UserVoice, we’ll still be keeping in mind the comments and discussion that already exist here on the GitHub issue.

GitHub will remain the channel for reporting bugs.

Once again, this issue can now be found by searching for the title on: https://aws.uservoice.com/forums/598381-aws-command-line-interface

-The AWS SDKs & Tools Team

This entry can specifically be found on UserVoice at: https://aws.uservoice.com/forums/598381-aws-command-line-interface/suggestions/33168346-aws-cli-should-set-default-region-to-ec2-instance

Based on community feedback, we have decided to return feature requests to GitHub issues.

All right then, +1 on the feature request, why in god's name has this not been implemented yet???

Upvote for this feature request.

I have a case when instances in China (cn-north-1) using IAM Roles fail to query a s3 bucket just because the region is not specified. Meanwhile instances in Ireland (eu-west-1) with the same IAM Role can run the same command without errors.

The error is:
An error occurred (InvalidToken) when calling the PutObject operation: The provided token is malformed or otherwise invalid.

The EC2 Instance, the IAM Role and their association to one another is performed by terraform, so there are no disparities in privileges.

When I run aws configure list on both instances, I get the same result:
$ aws configure list Name Value Type Location ---- ----- ---- -------- profile <not set> None None access_key ****************AAAA iam-role secret_key ****************AAAA iam-role region <not set> None None

And to finish, if I run aws configure on the China instance and set the default region to cn-north-1, the s3 command starts working.

This problem also shows up in another way when working in govcloud. In the default AWS regions some awscli commands work just fine, such as uploading an ssh key to IAM. In govcloud, though, I get an invalid token error. If I add an explicit region the command works.

This has been implemented in v2: https://github.com/aws/aws-cli/pull/3680 and it pulls region from the instance metadata service by default. We'd recommend upgrading and relying on it once v2 is GA. Closing issue.

Was this page helpful?
0 / 5 - 0 ratings