DescribeRegions requires a region in order to describe all regions.

[stephen-mw]

Forgive me if I'm wrong or this is not a bug, or perhaps a feature requests, but gathering a list of available regions to an account still requires ec2.New to declare a region. I came upon this when gathering an up-to-date list of regions for an account.

The following fails with the error: "could not find region configuration"

svc := ec2.New(&aws.Config{
    Credentials: creds,
})

req := ec2.DescribeRegionsInput{}
regions, err := svc.DescribeRegions(&req)
check(err)

 "could not find region configuration."

Declaring any region works. It appears to use this string to decide which aws https endpoint to make api calls to. It seems to me that if ec2.New has no Region, and DescribeRegions is invoked, then simply "us-east-1" should be used.

[lsegal]

@stephen-mw thanks for opening this discussion.

This is expected behavior in the SDK. We can do a better job of documenting this in the future, but you must have either a region or endpoint configured at minimum to use the SDK, even for operations that may enumerate other regions. The SDK will never default to a region on your behalf. If us-east-1 is a default that works for you, it's something you can configure in your application logic.

Hope that helps!

[nightlyone]

If you already are on an EC2 machine and want to use services from the same region, you can query the availability zone via "http://169.254.169.254/latest/meta-data/placement/availabilty-zone" and derive the region from that by stripping the last lowercase letter.

And might be useful to allow auto-configuration of the region this way.

But when you are outside an EC2 machine, e.g. using a service on a machine in your office, there is no way knowing which region you want to talk to.

[stephen-mw]

Thank you both for the feedback. @nightlyone that seems like a very reasonable workaround to me. I'm going to close this since the default behavior does appear to be the best. Thanks again.