If you’re using CloudHealth to monitor, optimize, and govern your AWS environment, at some point you’re going to need to configure your AWS Identity and Access Management (IAM) roles and permissions. In this article, we outline the benefits of enabling CloudHealth AWS IAM permissions and five ways to configure them within the platform, ranging from manual setup to full automation.
Whether you’re just getting started with CloudHealth administration or you’re already an experienced administrator, if you’re using CloudHealth to monitor, optimize, and govern your AWS environment, at some point you’re going to need to configure your AWS Identity and Access Management (IAM) roles and permissions.
But you may be asking, why does CloudHealth need AWS IAM permissions? In this article, I’ll outline the benefits of enabling CloudHealth AWS IAM permissions and five ways to configure them within the platform, ranging from manual setup to full automation.
Benefits of enabling AWS IAM permissions for CloudHealth
Here’s a helpful chart that outlines the different permissions options and the benefits of enabling CloudHealth permissions across all of your AWS accounts.
| Cost and Usage Report (CUR) only | CUR + Read-Only IAM Role (Recommended) | CUR + Automated Actions IAM Role (Preferred) |
|---|---|---|
|
|
|
How to configure AWS IAM permissions in CloudHealth
For only a few accounts, manually configuring the IAM role and policy in each account is easy based on the instructions provided in the CloudHealth Help Center.
But what if you have more than a handful of AWS linked accounts? How can you set up your permissions properly in the first place, and then keep those permissions up-to-date across all your accounts when AWS and CloudHealth release support for new services and features?
Option 1: Manual configuration
“Clicky, clicky”
For a small number of accounts, this is the preferred approach. This method will require some back-and-forth between the CloudHealth Setup page and your AWS Console within your browser.
Login to the CloudHealth Platform and simply follow the steps in the AWS Quick Start in the CloudHealth Help Center, here.
Option 2: Using AWS CloudFormation
“Rinse and repeat”
To ensure consistency across accounts and avoid possible human error, rather than clicking around in your browser to configure each account, you can use a predefined template instead. AWS makes this easy with CloudFormation Stacks.
Once you’ve built one or more AWS CloudFormation stacks with the appropriate CloudHealth permissions, or downloaded the ones linked below, you can post them to an accessible S3 bucket and share the link with all your teams.
To enable the appropriate CloudHealth permissions for their AWS account, all your teams need to do is create and run the appropriate stack using the link to the S3 bucket that you centrally manage.
Reminder: AWS and CloudHealth often release new features or services. When that happens, you will need to update your CloudFormation stacks to support those new capabilities. After updating your CloudFormation stack, notify your teams to re-run the same CloudFormation stack by pointing to the S3 URL where you host the updated stack. This will update the permissions in their linked accounts and ensure consistent permissions across all accounts that use that CloudFormation stack.
The more detailed Platform Administration guide not only includes the steps for using CloudFormation stacks, but also has links to two commonly-used versions:
Read Only: Provides CloudHealth with read-only access to your AWS assets
Automated: Enables additional permissions for CloudHealth to take automated actions on your behalf, including:
- Starting or stopping EC2 Instances (useful for a “lights on/lights off” policy)
- Creating or deleting EC2 Snapshots
- Modifying or converting Reserved Instances
| Pros | Cons |
|---|---|
|
Easier than manually creating the IAM Policy and Role for many accounts “Infrastructure-as-Code” approach reduces the risk of human error |
Each team still needs to run the CloudFormation Stack initially Any updates to AWS or CloudHealth features and services will require updates to the CloudFormation stack, and each team will need to re-run the stack |
Instructions for Direct CloudHealth customers are in the Platform Administration guide here. Details for how CloudHealth partners can do this are included in the Help Center here.
The first two options make sense when you have a few dozen accounts, but what if you have hundreds or thousands of linked AWS accounts?
Option 3: Using AWS Service Catalog
“Opt-in”
Once you’ve built your AWS CloudFormation stacks with the appropriate permissions, you can post them to an accessible S3 bucket and share the link with all of your teams, as described in Option 2. But to streamline CloudHealth AWS Account Configuration even further, you can create a shared service using AWS Service Catalog.
With this approach, you use your CloudHealth CloudFormation templates to publish one or more services across your linked accounts. Teams will need to subscribe to the service from within AWS Service Catalog, but they do not need to manually create a new CloudFormation stack themselves. Whenever you make an update to the centralized CloudFormation Stacks, teams will be notified of the change. They will then need to manually approve the change within their accounts. Any updates you make to the CloudFormation template on the service will be applied to all accounts that are subscribed to the service.
| Pros | Cons |
|---|---|
|
Opt-in for teams Teams just need to subscribe to the AWS Service to enable CloudHealth permissions for their AWS accounts |
Each team must initially subscribe via AWS Service Catalog For updates, the team is notified of a change to the service, but they must manually approve the update to the CloudFormation Stack |
Option 4: Using AWS StackSets
“Centralized and managed control”
If you’re looking for more control over all of your linked accounts, you can enforce CloudHealth permissions using a “push” rather than an “opt-in” model.
AWS StackSets allow administrators to define CloudFormation Stacks that are automatically pushed down to all their linked accounts. Teams do not need to subscribe to the service. Any updates you make to the CloudFormation template on the service will be automatically applied to all accounts that are subscribed to the service.
| Pros | Cons |
|---|---|
|
Fully automated configuration for CloudHealth AWS Account permissions across hundreds or thousands of accounts No action required on behalf of teams or business units Can automatically provision CloudHealth permissions for new linked accounts |
Requires centralized permissions to run AWS StackSets within linked accounts Teams may not want a centralized organization to be able to push policies out to them automatically |
More details on working with AWS CloudFormation StackSets can be found on the AWS Documentation website here.
Option 5: Third-party infrastructure-as-code tools
“Kinda like a CloudFormation Stack”
If your team is already leveraging a third-party infrastructure-as-code tool, such as Terraform, then you can use that to provision CloudHealth AWS permissions for linked accounts.
While there is no major difference when using a third-party tool over AWS CloudFormation Stacks, many organizations prefer to avoid vendor lock-in or already have specialized knowledge with those tools.
By all means—if you know and prefer Terraform—use it to configure CloudHealth!
These are just some of the additional ways to configure and manage CloudHealth AWS account permissions at scale, but you may have other approaches.
*Bonus* Option 6: Using AWS managed policies
“Where’s the easy button?”
If the methods described above seem too cumbersome, some CloudHealth customers have used AWS managed policies for ReadOnlyAccess, AWSSavingsPlansReadOnlyAccess, or Managed Roles by Job Function. CloudHealth prides itself on following a least-privilege approach to cloud security so that we don’t make API calls to services we don’t support. While this is not our recommendation, AWS managed policies may simplify your CloudHealth configuration and management of IAM roles and policies.
One final note
Remember to configure your accounts in both AWS and CloudHealth!
Once you’ve configured the appropriate policies and roles within AWS, you will also need to enter the AWS Role ARN for your AWS accounts within CloudHealth.
There are three ways to do this:
- Manually, within the CloudHealth user interface, as described in our first option above
- Using the CloudHealth Accounts API
- Importing accounts via CSV
For customers or partners with additional questions, you can reference the CloudHealth Help Center and Knowledge Base, open a Support ticket, or talk to your Technical Account Manager.
If you’re not currently a CloudHealth customer, but you’re interested in learning more about how CloudHealth can improve the way your organization operates in the cloud, please feel free to reach out to us directly here. We also encourage you to explore some of our resources, including an in-depth whitepaper on how to Build a Successful Cloud Operations and Governance Practice.
