Search code examples
amazon-web-services.net-coreaws-ssmlocalstackaws-sdk-net

AWS gets empty SSM parameter list from LocalStack


I have some SSM parameters stored in LocalStack, but when the application runs is unable of getting the parameters, although the parameters are there.

The app log even says: [AWSSDK] Found AWS credentials for the profile local

The parameters are there as can be seen below.

Any idea why this would happen?

$ aws ssm get-parameters-by-path --path "/app-local/dynamodb" --endpoint-url http://127.0.0.1:4566 --profile local --recursive
{
    "Parameters": [
        {
            "Name": "/app-local/dynamodb/urls/expire",
            "Type": "String",
            "Value": "1.00:00:00",
            "Version": 1,
            "LastModifiedDate": 1656607246.131,
            "ARN": "arn:aws:ssm:us-west-2:000000000000:parameter/app-local/dynamodb/urls/expire",
            "DataType": "text"
        }
    ]
}

Program.cs

config.AddSystemsManager("/app-local");

appsettings.json

{
  "AWS": {
    "Profile": "local",
    "ServiceURL": "http://127.0.0.1:4566",
    "UseHttp": "true"
  }
}

Setting this code in my Main.cs:

var awsFile = new SharedCredentialsFile();
                if (awsFile.TryGetProfile(awsOptions.Profile, out var profile))
                {
                    Console.WriteLine($"Found credentials for '{awsOptions.Profile}' in credentials file '{awsFile.FilePath}'.");
                }

It prints:

Found credentials for 'local' in credentials file '/root/.aws/credentials'.
root@8bb9c17a7179:/app# cat /root/.aws/credentials
[local]
aws_access_key_id = local
aws_secret_access_key = local
region=us-west-2

Solution

  • The AWS SDK for some reason is not using the configured region, and it is trying to figure out the region from the endpoint url, which is dumb. As it cannot figure it out, when signing the HTTP requests uses the default us-east-1 as region, causing the described problem, because Localstack has different data stores per region.

    Using http://us-west-2.localhost:4566 as service url instead of http://127.0.0.1:4566 fixed the problem. Of course you need to add that entry in your /etc/hosts.

    It is not a bug. It is a dumb design decision.