In order to properly communicate with AWS services you have to create an IAM Policy that allows Kikaha to execute tasks on your behalf. For the sake of simplicity, and make this guide a little less verbose, we will not describe a whole IAM policy that may or not be used for each AWS resource Kikaha may use, but describe the set of "actions" required for the above-described features as needed.

Maybe the most important think one should care about when is designing an application that interacts with AWS services is its credential model. By default, on Kikaha applications, any managed class are able to inject com.amazonaws.auth.AWSCredentials definitions (or AmazonWebServiceConfiguration, which basically contains com.amazonaws.auth.AWSCredentialsProvider and com.amazonaws.regions.Regions). The bellow sample code shows how you can do this.

public class MyManagedClass {

  @Inject AWSCredentials credentials;
  @Inject AmazonWebServiceConfiguration awsConfiguration;
}

As stated by the IAM Roles for Amazon EC2 guide, attach a IAM Role to your EC2 instances is a good strategy for managing credentials for your applications. The default Kikaha configuration will respect the Default Credential Chain ensuring that you can provide credentials by Environment Variables, EC2 Roles, ECS container credentials and the default credential profiles file (usually located at {USER HOME DIR}/.aws/credentials file).

Kikaha also provide an alternative mechanism, just in case you want to configure keep your credential configuration along with other configuration entries at application.yml file for any reason. Basically, all you need to do is define kikaha.cloud.aws.iam.AmazonCredentialsFactory$Yml as credential factory for AWS services, as shown bellow.

# application.yml
server:
  aws:
    credentials-factory: kikaha.cloud.aws.iam.AmazonCredentialsFactory$Yml
    iam-policy:
      access-key-id: ACCESS_KEY
      secret-access-key: SECRET_ACCESS_KEY

As you can see, you would be able to define your credentials on the alias called default at the service named iam-policy. Under the hood, this Yml-based configuration follow the convention server.aws. to provide information regarding an specific module, in this case, iam-policy.

It is also possible to configure which region an AWS resource should use. Basically, you can set the attribute _server.aws.<service>._region, where service represents the AWS resource you want to define. Bellow, is the default yml configuration Kikaha uses.

server:
  aws:
    # fall back configuration for every AWS service
    default:
      region: "us-east-1"

    # IAM service
    iam-policy:
        # access-key-id: ACCESS_KEY
        # secret-access-key: SECRET_ACCESS_KEY

    # EC2 service
    ec2:
      #region: "us-east-1"

    # ELB service
    elb:
      #region: "us-east-1"

    # SQS service
    sqs:
      #region: "us-east-1"

    # CloudWatch service
    cloudwatch:
      #region: "us-east-1"

    # X-Ray service does not provide a way to setup the region.
    # During the tests, it seems to send to the current region your appliction is actually running.
    x-ray: