Ternary has rich support for ingesting your Cost and Usage Report from AWS, as well as connecting to metrics data from CloudWatch and accessing reserved instances and savings plan inventories. We also provide service-specific pages for you to dive in to your personalized utilization of features like EC2, S3, Redshift, and MemoryDB. In this guide, we'll help you connect your AWS organization to Ternary.

Single Account Onboarding

Prerequisites

An AWS Cloud Engineer with access to create an IAM role and Cost and Usage Report (if you have not already created a report)
An AWS Cloud Engineer with access to configure Cost Explorer
A Ternary user assigned the Ternary 'Owner' role to create a new AWS cloud

Configuration

Part 1: Configure AWS Cost and Usage Report (CUR)

If your organization has not yet configured an AWS Cost and Usage Report (CUR) that Ternary will use to ingest your AWS spend, we recommend following the AWS Creating Cost and Usage Reports documentation. For the best results, we recommend selecting the following CUR options:

Include resource IDs: Yes
Automatically refresh your Cost & Usage Report: Yes
Compression type: GZIP

Part 2: Configure AWS Cost Explorer

To surface your AWS rightsizing recommendations in Ternary, you will need to enable and save the AWS Cost Explorer preferences option 'Receive Amazon EC2 resource recommendations' documentation

Part 3: Configure AWS Role for Ternary CUR Access

Ternary will access your CUR by assuming a role you will define in the account containing your S3 bucket and CUR. We have created a CloudFormation template and Terraform script to automate the role provisioning process and, most importantly, provide you with the transparency to inspect the specific AWS permissions Ternary requires.

First, obtain the Service Account and Service Account Unique ID from the Admin page of Ternary.

Now, create the Ternary role in your AWS account containing your CUR and S3 Bucket using our CloudFormation template or Terraform script, whichever you prefer. For the Terraform script, fill in the blanks at the top of the file with your S3 CUR bucket's ARN, your unique Ternary Service Account email and Service Account Unique ID you copied. If you are using CloudFormation, you will be prompted for these values in the console.

CloudFormation Steps

Login to your AWS Console and Account where your created the CUR and S3 bucket
Search for CloudFormation in the list of AWS services
Once on CloudFormation page, click "Create stack" icon
- Select "Choose an existing template" option
- Select "Upload a template file" and upload the ternary-payer-account-cfn.json CloudFormation template
Follow the prompts in the AWS console:
- Stack name: can be any name you'd like but we suggest Ternary Service Agent Role
- Parameters:
  - CurBucketArnParameter: The S3 Bucket ARN copied from the AWS console (It should look something like: arn:aws:s3:::ternarycurbucket)
  - ServiceAccountParameter: The Service Account copied from within Ternary platform on the Admin => Tenant page
  - ServiceAccountUniqueIDParameter: The Service Account Unique ID copied from within Ternary platform on the Admin => Tenant page
- All other settings can be left as default or can be modified to conform to your organizations standards

Once the role is created, locate it in the IAM Roles page within the AWS Console, and copy its ARN.

Part 4: Configure AWS Role for Ternary CloudWatch Metric Access

In the likely case that you have more than one AWS account, Ternary will not have access to the usage information from CloudWatch in the other accounts from the work we have done so far. Only the usage information from the account where the CUR and your Role ARN reside can be gathered at this point.

To provide accurate recommendations for potential cost savings across various AWS services (EC2, RDS, etc) we need to gather the CloudWatch metrics from your other accounts and direct them into a centralized monitoring account.

This can be a complicated operation, so Ternary has developed scripts to support this. Additionally, if it is too complicated right now, it can always be revisited later with the help of our Success Team. If you're still here, let's get started!

Decide on a single AWS account to use to aggregate the monitoring data from across your other AWS accounts. The simplest choice is to use the same account where you created the CUR. In this case, notate that the Role ARN you generated in Part 3 is also your Metrics Collection Role ARN, and proceed to step 3.
If you chose to dedicate an account to metrics gathering, apply the CloudFormation or Terraform script from here to that account: <https://github.com/TernaryInc/ternary-onb-permissions/tree/master/aws/centralized-monitoring>, filling in the same values as you did for Part 3. Then record the resulting ARN as your Metrics Collection Role ARN.
Run the script here: https://github.com/TernaryInc/aws-centralized-monitoring to deploy metrics aggregation from your entire organization's AWS accounts into the account ID you decided in step 1. This approach will be resilient to creation of new AWS accounts in your organization and is a permanent solution for complete visibility over your whole organization.

Keep your Metrics Collection Role ARN handy; we're now ready to enter all our information into Ternary.

Part 5: [Optional] Configure AWS Roles for Linked Accounts

For AWS Organizations, some information requires specific access to member accounts. For example, account-scoped Reserved Instance details must be queried from the individual accounts in which they were purchased.

Ternary provides Terraform and CloudFormation templates to define a custom role that allows your Ternary service account to access this information: https://github.com/TernaryInc/ternary-onb-permissions/tree/master/aws/linked-account

The template must be applied to each member account owning a Reserved Instance (e.g. EC2 Reserved Instance, Elasticache Reserved Cache Node, Redshift Reserved Node, OpenSearch Reserved Instance). Once again, record the resulting Role ARNs and the Account IDs as you create the roles. Our Success Team can help you register these Role ARNs to your AWS integration through the API.

Enter information into Ternary

You are now ready to create an AWS cloud. In Ternary, navigate to Admin > Clouds, then click Create New Cloud in the top right corner and choose Create Amazon Cloud. You will be shown the following dialog. In this dialog, paste the Role ARN you copied in Part 3 and your Metrics Collection Role ARN from part 4. You should also enter a recognizable display name for this AWS connection.

Navigate to the 'Cost & Usage Reports' tab. From your AWS CUR configuration completed in the prior section, enter the following:

CUR report name
CUR S3 Bucket Name
CUR report path prefix (copy and paste the report path prefix from your AWS Cost and Usage reports details page in the AWS console)
AWS region location of your S3 Bucket hosting your CUR report.

You can now hit the blue Submit button to record your AWS configuration and have it validated by our back end. If everything is good, you should see a clean tile in your Clouds list which repeats the information you have just saved. If there are issues, you will see an error icon "<!>" next to your tile, and you will be able to hover over the tile to view the error:

If this happens, click the [...] next to your tile to Edit your configuration, and try again.

If you need further support with Amazon Web Services setup, don't hesitate to reach out to our Success Team.

Multi Account Onboarding

Prerequisites

An AWS Cloud Engineer with administrator privileges outlined in the Definitions section
A Ternary user assigned the Ternary 'Owner' role to create a new AWS cloud
If your source accounts have workloads in regions that aren’t enabled by default in AWS and you’d like to collect metrics for these regions, please enable them in your monitoring account.

Note: The below steps are for doing this through the AWS management console but we also offer scripts to do this programmatically which is less prone to human error and can be viewed here: https://github.com/TernaryInc/aws-centralized-monitoring

Definitions

Monitoring Account: A monitoring account is a central AWS account that can view and interact with observability data generated from source accounts. For maximum compatibility and metrics coverage, we recommend designating your management account as your monitoring account.
- Due to CloudFormation constraints, we are unable to collect metrics from management accounts that are not also monitoring account
Source Account: A source account is an individual AWS account that generates observability data for the resources that reside in it
- Source accounts share their observability data (Logs, Metrics, X-Ray traces) with the monitoring account

Permissions

Monitoring Account: Sign in with full admin permissions, or sign in to the monitoring account with the following permissions:

{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowSinkModification",
"Effect": "Allow",
"Action": [
"oam:CreateSink",
"oam:DeleteSink",
"oam:PutSinkPolicy",
"oam:TagResource"
],
"Resource": ""
},
{
"Sid": "AllowReadOnly",
"Effect": "Allow",
"Action": ["oam:Get", "oam:List"],
"Resource": ""
}
]
}

Source Account [NOT NECESSARY IF USING AWS ORGANIZATIONS]: Sign in with full admin permissions, or sign in to the source account with the following permissions

Note: you may omit the blocks concerning “logs:Link” and “xray:Link” if you will not be using this information in your monitoring account. Ternary is not ingesting this data.

{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": [
"oam:CreateLink",
"oam:UpdateLink"
],
"Resource": [
"arn:aws:oam:::link/",
"arn:aws:oam:::sink/"
]
},
{
"Effect": "Allow",
"Action": [
"oam:List",
"oam:Get"
],
"Resource": ""
},
{
"Effect": "Allow",
"Action": [
"oam:DeleteLink",
"oam:GetLink",
"oam:TagResource"
],
"Resource": "arn:aws:oam:::link/"
},
{
"Action": "cloudwatch:Link",
"Effect": "Allow",
"Resource": ""
},
{
"Action": "logs:Link",
"Effect": "Allow",
"Resource": ""
},
{
"Action": "xray:Link",
"Effect": "Allow",
"Resource": "*"
}
]
}

[OPTIONAL] Use AWS Organizations:

Highly recommended, as AWS will automatically configure new accounts as source accounts when they are added
Documentation

Note: These steps must be repeated for each region you have AWS services you wish to centralize monitoring in. You may want to do the Monitoring Account steps for each Region before proceeding to the Management Account steps

Monitoring Account:

Sign in to your AWS Monitoring Account as an admin, or as a user with the permissions mentioned above
If using Organizations:
- Get your organization path:

Using the UI:

Video (video steps are outlined below)
Monitoring Account:
Sign in to your AWS Monitoring Account as an admin, or as a user with the permissions mentioned above
If using Organizations:
- Get your organization path:

From the organizations page, select Root if you’d like to monitor your whole organization, or select an organizational unit if you’d prefer to monitor a select subset of accounts

Get the organization ID from the ARN
- ex. arn:aws:organizations::11111111111:ou/o-aaaaaaa1a1/ou-bbb2-22bbbb2b → o-aaaaaaa1a1
If you have suspended AWS Accounts, please note the OU ID of your root (starts with r- )
If not using Organizations:
- Produce a list of accounts you are interested in monitoring
Navigate to CloudWatch > Settings

Click on Monitoring Account Configuration

[OPTIONAL] Uncheck the Logs/Traces boxes. Ternary does not collect this data, but you may be interested in centralizing it
Fill out your configuration as desired (example below), and click confirm

Back in the CloudWatch page, click Resources to link accounts and then Download CloudFormation Template
NOTE: If you aren’t using AWS Organizations, please click the Any Account radio button before downloading the CloudFormation template

Management Account:

Log in to your management account, and navigate to CloudFormation, and then to StackSets and Create StackSet
If you have not already done so, press the Enable Trusted access button to enable CloudFormation to create Stacks in constituent accounts

Select Service-managed permissions
Select Template is ready
Select Upload a template file, and upload the CloudFormation Template you downloaded earlier and click Next

On the next page, enter a name for your StackSet, and click Next
Optionally, add tags to associate to your StackSet, and click Next
Under the Set Deployment Options screen, leave all of the default settings, and select the region corresponding to the region you configured your sink in, and then

Note: If you have suspended AWS Accounts, your Stack creation will fail, please exclude them by following the steps below. If you wish to exclude non-suspended AWS Accounts from your centralized monitoring, you may do so by following the steps below

Choose Deploy to organizational units (OUs)
Enter the OU ID (starts with r- if you’re monitoring everything in your organization, or ou- if you’re only monitoring part of your organization)
Select Difference under Account filter type - optional
Enter the account numbers you wish to exclude, separated by commas (or specify them in a .csv file, and upload that file here), and click Next

Review your settings in the Review screen, and then click Submit to create your StackSet
From the StackSets page, you should be able to
Repeat the Using the UI process per Region as needed