Role based access for ExAWS

I am trying to get AWS authentication (for S3) working for a company AWS environment that relies heavily on IAM roles. This has to be one of the least transparent/most confusing things I have encountered for a long while, and I can’t find a fully configured working example.


  • Am I correct in thinking the AccessDenied I currently get with standard KEY/SECRET is due to the different role I have when creating S3 buckets?
  • How do I retrieve my role_arn and how does this fit in to the ex_aws config?
  • What is my profile_name and where does this come from?
  • Is there a working example somewhere I can take a look at?

Hopefully someone has this working

For me it worked OOtB, so it seems that IAM role assigned to that machine do not allow for accessing that S3 bucket.

Care to share how you set up your configuration? Where does the role_arn go?

Nowhere, role is assigned to the machine, not to application. So in the end anything that is running on that particular machine can access given S3 bucket.

I’m sorry to hear that you’re having trouble. ExAws is completely compatible with and thus to some extent assumes a familiarity with the general AWS authorization mechanics. As a general rule, if you can get the configuration working with the aws cli it will also work fine with ExAws.

Concretely, in order to have key based authentication you need an AWS user. This is not the same thing as a role. However you can have a user assume a role when taking on actions provided that the role has a trust association with the user that allows the user to assume the role:

output = json
region = us-east-1
role_arn = arn:aws:iam::1234567890:role/YourRoleHere
1 Like

Thanks for chiming in, I have made some progress and got it working to an extent. Reasons for confusion:

  • how STS.assume_role works, I believe a name like fetch_role_credentials would be more apt, since as far as I can tell it is fully up to developers to use/cache/refresh/propagate these temporary credentials. assume_role suggests some stateful (shudder) change that applies to subsequent requests. I stumbled on this and found it very helpful, maybe link to it from the README?
  • differences between the release and master for ex_aws_sts, there is a awscli_auth_adapter: ExAws.STS.AuthCache.AssumeRoleCredentialsProvider in master and READMIE that is not in the 2.0 release.
  • incompatibility with tools like stavro/arc, which rely solely on the fixed, hard coded credentials from aws_ex config, so I don’t think IAM roles can be used with those tools (I have created an issue for arc)
  • diabolically opaque error messages from Amazon

Again, thanks for your input, any further help is equally appreciated.

I’m having issues with exactly that as well.

I have the following dependencies on my mix.exs:

      {:ex_aws, "~> 2.0"},
      {:ex_aws_sqs, "~> 2.0"},
      {:ex_aws_sts, "~> 2.0"},
      {:configparser_ex, "~> 2.0"}

I have configuration like this (per the ex_aws README):

config :ex_aws,
  debug_requests: true,
  region: "sa-east-1",
  access_key_id: [{:system, "AWS_ACCESS_KEY_ID"}, {:awscli, "foo-dev", 30}, :instance_role],
  secret_access_key: [{:system, "AWS_SECRET_ACCESS_KEY"}, {:awscli, "foo-dev", 30}, :instance_role],
  awscli_auth_adapter: ExAws.STS.AuthCache.AssumeRoleCredentialsAdapter,
  json_codec: Jason

In my ~/.aws/config file I have the foo-dev as a valid profile.

But when trying to, say, receive messages via SQS:

iex(2)> ExAws.SQS.receive_message("MY_QUEUE") |> ExAws.request
[debug] Request URL: ""
[debug] Request HEADERS: [{"Authorization", "**REDACTED**"}, {"host", ""}, {"x-amz-date", "20190531T211829Z"}, {"content-type", "application/x-www-form-urlencoded"}]
[debug] Request BODY: "Action=ReceiveMessage"
[warn] ExAws: HTTP ERROR: {:closed, ""}

Turns out that the queue URL is actually wrong (in the AWS dashboard the URL is

But still getting the {:error, :closed} from hackney which I suspect should be a different issue.

Any help would be appreciated