Detect region based on ~/.aws/config

[kennyk65]

When running local tests, or anytime running outside of an EC2 instance, it would be terrific if Spring Cloud AWS would detect that I'm not on an EC2 instance (because there is no instance metadata) and fall back to region selection based on ~/.aws/config. That way, I can manage my local region selection via the CLI / eclipse plugin and the setting is automatically respected by Spring Cloud AWS.

[codefromthecrypt]

I think this is what @sethp-jive was looking for, too. Basically to inherit CLI env. right? openzipkin/zipkin#1302 (comment)

[sethp-jive]

Indeed – the trouble is that there's an awful lot of behavior baked into the DefaultAwsRegionProviderChain (and far more baked into the DefaultAWSCredentialsProviderChain). I'm not an expert on how spring cloud likes to take its configuration, but in AWS-land a hard-coded access key and secret id are just the beginning.

The others allow dynamic role-switching based on some initial profile, which involves an online call to the STS service to get dynamic credentials. This flow is often required for certain organizations, as a common pattern is to partition AWS accounts and STS is the only way to get from the account where the user is provisioned to where the resources live. Unfortunately, as is the way of all things broadly consumed, everyone's got a slightly different way into the same broad idea – and while they're not perfect, the default provider chains do at least capture some of the more common behavior.

[kennyk65]

The AWS SDK for Java resolves region using a straightforward chain. So does Spring Cloud AWS, but it's not the same chain.

See https://github.com/aws/aws-sdk-java/blob/master/aws-java-sdk-core/src/main/java/com/amazonaws/regions/DefaultAwsRegionProviderChain.java . The order is 1) Environment variable 2) System Property 3) Profile (that's the .aws/config file), and 4) instance metadata. This behavior is becoming consistent with the non-Java SDKs too.

But Spring's chain appears to ignore the environment variable, system property, and profile, charging straight to the instance metadata. This causes a fatal error when running locally, which makes the entire framework hard to use: one must begin by hard-coding a region in a Spring-specific, non-AWS-native way (i.e. setting cloud.aws.region.static)

[maciejwalkowiak]

I agree with @kennyk65. Spring Cloud AWS should follow same chain as DefaultAwsRegionProviderChain for region resolution.

As an opt-in feature we can add it to 2.2.3. It will work in a same it has been done for credentials:

cloud.aws.region.useDefaultAwsRegionChain=true