Hakuna allows to easily manage your AWS resources’ states by automatically stopping them when not used, or starting them otherwise. Setting up Hakuna is as easy as granting it access to your resources, and choosing which one you want it to manage.

However, there might be reasons why you don’t feel you want a third party tool to potentially access all of your resources and perform any action against them.

One solution to this problem is to let Hakuna run on behalf of a purposedly created service account whose permissions are defined by a custom policy.

This post describes two examples of this approach, the first applied to the awsec2 flavour, and the second applied to the awscf flavour.


The awsec2 flavour basically starts, stops and creates images for an EC2 instance, that is, it won’t need to perform any action on EC2 instances other ec2:StartInstances, ec2:RunInstances, ec2:StopInstances, ec2:TerminateInstances, ec2:CreateImage and a few more ones.

The ability of executing these actions can even be restricted only to those specific resources handled by Hakuna. You can use tags to label and identify such resources. For example, you can add a resource tag named hakuna and set with any value to the resources you want Hakuna to manage.

To summarize, the policy should allow running some given actions against resources with a given tag on behalf of a given user.

Here’s how such policy is represented in AWS:

    "Version": "2012-10-17",
    "Statement": [
            "Sid": "RestrictToHakuna",
            "Effect": "Allow",
            "Action": [
            "Resource": "*",
            "Condition": {
                "ForAnyValue:StringLike": {
                    "ec2:ResourceTag/hakuna": "*"
            "Sid": "AllowDescribingInstancesAndCreatingImages",
            "Effect": "Allow",
            "Action": [
            "Resource": "*",

Full steps:

  1. Create a service account in AWS IAM
  2. Create security credentials for the service account
  3. Create a policy and assign it to the service account
  4. Apply Resource Tags to EC2 instances
  5. Create a new provider for the awsec2 flavour using credentials created on step 2


The strategy for restricting access to CloudFormation is similar to what we’ve just seen for EC2, although with a couple of differences.

First of all, the policy should not only allow access to CloudFormation required actions like cloudformation:CreateStack, cloudformation:DeleteStack and more, but to all actions required to manage stack’s resources as well.

For example, if your stack defines an EC2 instance, the policy should allow CloudFormation actions and the EC2 actions described above in the previous section.

The second difference is that you cannot use tags to identify which stacks could be managed by Hakuna: while it is possible to add tags to stacks, it isn’t possible to define tags in the stack’s template itself, which makes it impossible to Hakuna to create stacks it would be then allowed to manage itself.

To get around this issue, you can protect Stacks from being deleted.


Setting up Hakana access to your resources is easy, and restricting access is easy as well. What we described in this post is only one of the possible solutions one can think of. To learn more about access control we recommend reading Amazon AWS documentation about AWS Identity and Access Management