Setting up an AWS nOps account (Automatic Setup)

nOps requires safe, secure, and AWS-approved access to your AWS accounts in order to give you the analysis, dashboards, and reports that you need. We only see what we need, no more, and we need you to give us permission first.

In order to get started with nOps, the first step is to set up an AWS account for nOps via the Setup Wizard and subscribe to nOps on the AWS marketplace. We made the setup process as easy as possible for you while complying with AWS security best practices.

In Automatic Setup, nOps takes care of creating the IAM policy and the CloudFormation stack for the account.

Prerequisites

To successfully set up the AWS account(s), the AWS user must possess:

• Access to the Payer account, if you are using AWS Organizations.
• Permission to create and run an AWS CloudFormation stack.
• Permission to create AWS Identity and Access Management (IAM) roles in your account.
• The name of an Amazon S3 bucket where your AWS Cost and Usage Reports (CURs) will be written. (nOps will create a bucket with the provided name if one does not exist.)
• CURs enabled in the account.

Note: If you add an AWS child account instead of a Payer Account, nOps will only see the cost details of the specific child account instead of the cost details of the entire organization.

Adding AWS Account(s)

When you log in to your nOps account for the first time, a pop-up screen will appear. This pop-up screen will guide you on how you can add your AWS account(s) to nOps. The screen consists of four distinct sections:

1. Select Cloud Type
2. Getting Started
3. Link Cloud Accounts
4. Fetching

Note:

If you only add a single account during the automatic setup and want to add more accounts later, once your single account is onboarded and you have access to the nOps platform:

1. On the top-right corner of your nOps account, click on your user avatar to open a drop-down list.
2. In the dropdown list, click Organization Settings. This will take you to the Cloud Accounts page.
3. On the Cloud Accounts page, click + Add New Account.

Select Cloud Type

On this page, select the type of cloud account that you want to onboard and click Next. In the scope of this document, we will only explore the AWS Account option.

If you want to explore nOps first before you onboard any accounts, click Let Me Explore App.

Getting Started

In this section, you need to select the account setup method. In the scope of this article, we will deal with the Automatic Setup. Select the nOps Wizard Setup and click Next.

To learn more about Manual Setup, see Manual Setup. To learn more about IaaC Setup, see IaaC Multiple Accounts Setup.

Link Cloud Accounts

On the first page of this section, you can either select an AWS Organization account or a Single Account.

In the case of an AWS Organization account:

• Make sure that you are logged into your AWS Master Payer Account.
• Select the AWS Organization option.
• Fill out the AWS Master Payer Account Name and S3 Bucket Name fields.
• Click Setup Account.

If you select AWS Organization account, in the next section Link Cloud Account, you will have the option to onboard the child accounts associated with your AWS Organization Account.

In the case of Single Account:

• Make sure that you are logged into your AWS account.
• Select the Single Account option.
• Fill out the AWS Account Name and S3 Bucket Name fields.
• Click Setup Account.

When you click Setup Account, you will be redirected to your AWS > Create Stack page. All the fields on this page will be pre-populated. Click on the checkbox for “I acknowledge that AWS CloudFormation might create IAM resources”. nOps needs this permission to automate the creation of the IAM role.

After you click the checkbox, click on the Create button to start the data ingestion.

Note:

CF stack can run from any region you prefer. You can easily change the region of the CF stack from the CloudFormation screen once you launch it from nOps after your setup process is complete.

Once the stack is created, come back to nOps. nOps will check the account connectivity with AWS and check the CloudFormation stack permissions, and start the ingestion:

When data ingestion starts, in AWS console CloudFormation > Stacks > Stack Detail:

1. If you have all the required permissions, as mentioned in the prerequisites section, the setup will start creating the stack with the status “CREATE_IN_PROGRESS”. Once the stack is created the “Status” will change to “CREATE_COMPLETE”. You can click the browser refresh button to check progress. Normally it takes 1 to 2 minutes to complete the process.
2. If you don’t have proper permissions then you will see errors as shown in the screenshot below, and the stack will not be created. You can assign the necessary permissions to the AWS user or ask other teammates to rerun the setup.
3. Once the stack creation is successful, log in to nOps Dashboard after the nOps integration (stack) creation process is completed

Fetching

Once your AWS accounts are linked successfully, you will see the following screen:

Once you log back into nOps, after data ingestion is complete, in the case of AWS Organization Account you will see the Setup Child Account page. With the help of your CUR, the setup process will automatically pull in the child accounts associated with your organization account.

To onboard a child account, click the Automatic Setup button against the child account that you want to add. If you don’t want to add a specific child account, click Skip Setup.

Note:

If you don’t have the required permissions to onboard a child account, click Invite team member to invite a member of your organization who has the required permissions.

If you click Automatic Setup, the setup process will show you a confirmation popup.

Before you click Proceed, make sure that you are logged in to the child account you are onboarding. When you click Proceed, you will be redirected to the AWS CloudFormation console with all the fields pre-filled:

Check the I acknowledge that AWS CloudFormation might create an IAM resources checkbox, and click Create Stack.

To take a look at the nOps CloudFormation template, see CloudFormation YAML Template.

In case, nOps detects more than 10 child accounts, you will get a prompt to use the nOps IaaC Setup. nOps recommends that in this case, you use the IaaC Setup instead of the Automatic Setup. To learn more about the IaaC setup, see IaaC Multiple Account Setup.

Once all the Child Accounts are added or skipped, click Next.

The setup process is now complete.

Note:

It can take up to 24 hours before you start seeing the different nOps dashboards and compliance views populated with data from your workload.

If you have any questions, please contact us at help@nops.io, or by phone at +1 866-673-9330.

On initial ingestion, nOps will pull the data from AWS accounts based on the following durations:

• Cost data: 6 months look back + current month.
• Rules: Current date.
• CloudTrail Events: 14 days look back.

IAM and CloudFormation:

The IAM policy used by nOps is scoped to read and write permissions only.

Lambda function automates the creation of Role and Bucket (if it’s absent) for nOps integration to work.

The code for the Lambda function is available for your review. Click the link to get the YAML file.

If you are not comfortable with using the automated setup, you can use manual steps for the setup.

Article: Adding Your AWS account with the Manual Setup

View the latest IAM Policy here

Troubleshooting Tips:

• Do you have a pop-up blocker on your browser? A pop-up blocker on your browser will stop nOps from redirecting you to an AWS account to create a stack.
• There may have been a disconnect when creating the S3 stack causing the stack to have an error of ROLLBACK_ERROR. In this case, re-try the automatic setup, then delete the first one.
• Is it pulling in incorrect data? Make sure that you are logging into the correct account. When you have multiple access to AWS accounts, it can import the wrong data. Ensure that you’re logged in to the correct account prior to starting the integration process.
• If you belong to an Organization ( multiple accounts linked to a Master Account) ensure that you are logged into the Master account before running the wizard (so the billing data is populated) or having organizational billing data files exported to one of your buckets.

Related Articles:

How Child Accounts Work in nOps

Setting up an AWS nOps account (Manual Setup)

nOps requires safe, secure, and AWS-approved access to your AWS accounts in order to give you the analysis, dashboards, and reports that you need. We only see what you want us to see in order to provide our services, no more, and we need you to give us permission first.

In order to get started with nOps, the first step is to set up an AWS account for nOps via the Automatic Setup, Manual Setup, IaaC Multi Account Setup (CloudFormation), or IaaC Multi Account Setup (Terraform). We made the setup process as easy as possible for you while complying with AWS security best practices.

This Manual Setup is used in complex environments by experienced AWS administrators who need granular control and insight into the access that nOps require.

The Manual Setup approach is also useful for administrators who want to embed nOps access into their automation.

Prerequisites

You must have Admin role permissions in AWS before you can set up an AWS nOps account with Manual Setup.

Pro Tip: The Manual Setup is used in complex environments by experienced AWS administrators. Most customers opt to use the Automatic Setup procedure.

Adding AWS account (Manual Setup)

In the scope of this article, we will look at the Manual Setup procedure.

To use the Manual Setup for complex environments, follow these steps, in this order:

1. Get the auto-generated External ID from nOps
2. Setup a S3 billing bucket for Cost & Usage Reports
3. Give nOps Permission and Create an IAM Policy
4. Create an IAM Role
5. Return to nOps to complete Manual Setup

Note: If you need any help with this process don’t hesitate to contact help@nops.io

Important information to copy and save

During this process, you should copy and save some information as you will need to enter it later. This information will be used in AWS and in nOps in order to complete the process:

• Copy the External ID auto-generated through nOps.
• Copy the ARN for IAM Policy that was created in the IAM Policy.
• Copy Report name created for the Cost and Usage Report (CUR).
• Copy Report path prefix from the S3 billing bucket creation.

Get the auto-generated External ID in nOps

When you log in to your nOps account for the first time, a pop-up screen will appear. This pop-up screen will guide you on how you can add your AWS account(s) to nOps. The screen consists of four distinct sections:

1. Select Cloud Type
2. Getting Started
3. Link Cloud Accounts
4. Fetching

If you only add a single account during the automatic setup and want to add more accounts later, once your single account is onboarded and you have access to the nOps platform:

1. On the top-right corner of your nOps account, click on your user avatar to open a drop-down list.
2. In the dropdown list, click Organization Settings. This will take you to the Cloud Accounts page.
3. On the Cloud Accounts page, click + Add New Account.

Select Cloud Type

On this page, select the type of cloud account that you want to onboard and click Next.

In the scope of this article, we are only going to deal with the AWS Account setup.

Getting Started

In this section, you need to select the account setup method. In the scope of this article, we will deal with the Manual Setup. Select the Manual Setup and click Next.

When you click Next, you should see a screen similar to:

Copy the External ID and save it, you will need it later on.

If you want to add more accounts after the completion of your onboarding:

1. Log into the nOps application.
2. From your Profile name drop-down, in the top-right, click Organization Settings. If you are a Partner or Client Admin, select a client first, then click Organization Settings.
3. In the Settings page, click + Add New Account, this will take you to the Cloud Account page.
4. In the Cloud Account page, select AWS Account and click Next. This will take you to the Setup Method page.
5. In the Setup Method page, select Manual Setup and click Next. This will take you to the Account Details (Manual Setup) page.
6. In the Account Details (Manual Setup) page, an External ID is auto-generated for you and prefilled in the External ID field.

Important: Do not exit this page, you will return to this page later to complete the account setup.

Setup S3 billing bucket for Cost & Usage Reports

This section is divided into two steps, in the first step you will create the Cost & Usage Report, and in the second step you will create/select an S3 bucket for the Cost & Usage Report.

Note: Ensure that your AWS SCP configurations allow IAM administrators to make the changes.

Create the Cost & Usage Report

In this step you will create a Cost & Usage Report (also called Detailed Billing Reports or CUR) so that nOps can analyze your cost information:

1. Login to your AWS Management Console account.
2. Go to: Billing & Cost Management Dashboard
   On the left-hand side select Cost & Usage Report
   or, go to: https://console.aws.amazon.com/billing/home?#/reports
3. Click on Create Report:
4. Create a report name (such asnopsbilling-daily-gzip).
5. In Additional report details, check the Include resource IDs checkbox (mandatory).
6. In the Data refresh settings, checkthe Automatically refresh your Cost & Usage Report when charges are detected for previous months with closed bills checkbox.
7. Click Next.

When you click Next, it will take you to the Delivery options page where you will create the S3 billing bucket.

Create/Select the S3 billing bucket

AWS needs a place to save your cost and usage/detailed billing files, a place that is safe for you. In this step, you will create an S3 bucket that secures your information:

1. In the Delivery options (the page you reached at the end of the last section), click Configure. This will open the Configure S3 Bucket dialog box.
2. In the dialog box, do one of the following:
   – Select an existing bucket: Use an existing bucket from your AWS Account.
   or
   – Create a new bucket: Create a new S3 bucket to be used specifically for nOps.
3. Click Next to go to Verify Policy.
4. Check the “I have confirmed that this policy is correct” checkbox.
5. Click Save to save this policy. When the policy is saved, you will return to the Delivery options page.
6. In the Delivery options page:
   
   • Click the Verify button to make sure the S3 bucket has an appropriate policy for the delivery report (step 3).
   • Enter the report path prefix (required) – Suggestion: nopsbilling
   • Choose Daily (mandatory) for Time granularity.
   • Select an option for Report versioning (optional) — Suggestion: Overwrite existing report.
   • Select GZIP as Compression type (mandatory).
     Important: You will need the Report Path Prefix name later when you are adding the AWS Account in nOps

7. Click Next.

8. Then, click Review and Complete.

Give nOps permission: Create the IAM policy

In this step, you’ll give nOps permission to read the Cost & Usage Report in the S3 bucket.

Note:

———-

AWS has a sophisticated security system for Identity and Access Management (IAM). There are no shortcuts for this. The nOps Wizard/Automatic Setup makes this easier with a CloudFormation Template, but the details provided in this article are for AWS practitioners who need more information for their own automation or auditing purposes.

———-

To manually create the IAM policy in order to allow nOps access:

1. On the AWS Management Console, go to the Identity and Access Management screen.
2. From the left navigation panel, click Policies.
3. Click Create Policy.
4. Switch to the ‘JSON’ tabandreplace the existing JSON script with the script provided in nOps IAM Policy (click this link to get the script).
5. Click Next: Tags (optional).
6. Click Next: Review.
7. Click on ‘Review Policy’.
8. Copy and save the ARN of the IAM role. This will be used later when you create the IAM Policy.
9. Provide a name and description for the policy.
10. Click on ‘Create Policy’.

Now, follow the same steps above to create another policy, this time for the S3 bucket that houses the Cost & Usage Report.

To create this policy, follow all the steps as is except for step 4. In step 4 use the following script:

{
"Version": "2012-10-17",
"Statement": [
{
"Action": "s3:*",
"Effect": "Allow",
"Resource": [
"arn:aws:s3:::<paste-bucket-name-here>",
"arn:aws:s3:::<paste-bucket-name-here>/*"
]
}
]
}

Make sure you replace <paste-bucket-name-here> with the name of the S3 bucket that houses the Cost & Usage Report to ensure policy efficacy.

You will attach both above policies to the IAM Role that you will create for nOps in the next step.

Creating IAM roles

IMPORTANT: You will need to enter the nOps auto-generated ID to create the IAM Role.

In order to allow the nOps SaaS application to use the IAM policy you just created, you need to create an IAM role.

To create a new role:

1. On the AWS Management Console, go to the Identity and Access Management screen.
2. From the left navigation panel, click Roles.
3. Click Create Role.
4. On Select trusted entity page, select AWS account.
5. Click Another AWS account.
6. For Account ID enter the nOps account ID (202279780353).
7. Click Require external ID.
8. For External ID, enter the string that was auto-generated for you by nOps in Step. The auto-generated External ID adds an extra level of security for you.
9. Click Next.
10. In Add permissions, select the two IAM policies you created in Give nOps permission: Create the IAM policy.
11. Click Next.
12. Enter a name and description for the role.
13. Click Add tags, in orderto add tags to be associated with this role (optional).
14. Click Create Role.

You have now completed the first part of the Manual Setup related to the AWS console.

Continue the Manual Setup of AWS account in nOps

Now that you have manually configured an IAM Role in your AWS account for access to AWS resources, the last step is to add that account to nOps.

Since you have already generated an External ID for nOps in Create an auto-generated External ID from nOps, you must now add information about the AWS role you created for nOps to fetch CloudTrail. You also need to add the S3 bucket so that nOps can fetch the billing data including the Cost & Usage Report.

Note: If you do not add a S3 bucket, your billing stats pages in nOps will not display any data.

1. Start from where you left off in Create an auto-generated External ID from nOps section.
2. In the Account Details (Manual Setup) page, enter a name for the AWS account you are adding to nOps.
3. The External ID is auto-generated.
4. Enter the ARN of the IAM role that you copied earlier in step 8 of Give nOps permission: Create the IAM policy section.
5. Add the S3 bucket name. Make sure the S3 bucket name is the same as the S3 bucket you created for Cost & Usage Report in the AWS console.
6. Enter the name of the Cost & Usage Report you created in step 4 of Create the Cost & Usage Report section.
7. Enter the report prefix path that you created in step 6 of Create/Select the S3 billing bucket.
8. Click Setup Account.

When adding the AWS account to nOps make sure you save the settings after filling all the fields.

Link Cloud Accounts

nOps will check the account connectivity with AWS, and start the ingestion:

Fetching

Once your AWS accounts are linked successfully, you will see the following screen:

Once you log back into nOps, after data ingestion is complete, in the case of AWS Organization Account you will see the Setup Child Account page. With the help of your CUR, the setup process will automatically pull in the child accounts associated with your Organization account:

To onboard a child account, click Automatic Setup. If you don’t want to add a specific child account, click Skip Setup

If you don’t have the required permissions to onboard a child account, click Invite team member to invite a member of your organization who has the required permissions.

If you click Automatic Setup, the setup process will show you a confirmation popup:

Before you click Proceed, make sure that you are logged in to the child account you are onboarding. When you click Proceed, you will redirect you to the AWS CloudFormation console with all the fields pre-filled:

Check the I acknowledge that AWS CloudFormation might create an IAM resources checkbox, and click Create Stack.

To take a look at the nOps CloudFormation template, see CloudFormation YAML Template.

If you decide not to give nOps the required access, you might face the following warning:

You can click Proceed and Setup later, but in this case you will not be able to access the features that depend on the required services.

In case, nOps detects more than 10 child accounts, you will see the following prompt:

nOps recommends that in this case, you use the IaaC Setup instead of the Automatic Setup. To learn more about the IaaC setup, see IaaC Multiple Account Setup.

Once all the Child Accounts are added or skipped, click Next.

The setup process is now complete:

Note: It can take up to 24 hours before you start seeing the different nOps dashboards and compliance views populated with data from your workload.

If you have any questions, please contact us at help@nops.io, or by phone at +1 866-673-9330.

On initial ingestion, nOps will pull the data from AWS accounts based on the following durations:

• Cost data: 6 months look back + current month.
• Rules: Current date.
• CloudTrail Events: 14 days look back.

The Manual Setup is now complete.

Note: It can take up to 24 hours for data to populate. If you have any questions, please contact us at help@nops.io

Viewing Added AWS Accounts:

In nOps, you can view the list of all cloud accounts that you add to nOps.

To view the cloud accounts, go to UserName Dropdown (Top right) > Organization Settings > Cloud Accounts where:

• For AWS accounts, the name of the S3 bucket [If added] is displayed, and also the “Last fetch” time of the S3 bucket.
• For Azure accounts, the name of the account is displayed.

To edit an existing cloud account:

• Go to UserName Dropdown (Top right) > Organization Settings > Cloud Accounts
• Click the Edit button.

You can make any changes you need. Ensure that, when you are done making the changes, you click the Update Account button in order to save the changes.

Note: Editing the S3 bucket, for an AWS account, of an existing project can cause changes in cost data or undesired results.

Related Articles:

How Child Accounts Work in nOps

How to Add a Read Only IAM Policy

Onboarding via IaaC (Terraform)

nOps requires safe, secure, and AWS-approved access to your AWS accounts in order to give you the analysis, dashboards, and reports that you need. We only see what you want us to see in order to provide our services, no more, and we need you to give us permission first.

In order to credential and register multiple accounts, we leverage AWS Organizations, CloudFormation, StackSets, and Lambda.

Prerequisites

• Admin role permissions in AWS in order to add AWS Payer and/or Child accounts to nOps using Terraform.
• Access to the nOps public Github repository nOps Cloud Account Registration.

nOps Onboarding – Terraform Setup

When you log in to your nOps account for the first time, a pop-up screen will appear. This pop-up screen will guide you on how you can add your AWS account(s) to nOps. The screen consists of four distinct sections:

1. Select Cloud Type
2. Getting Started
3. Link Cloud Accounts
4. Fetching

1 – Select Cloud Type

On this page, select the type of cloud account that you want to onboard (AWS or Azure) and click Next.

In the scope of this article, we are going to deal with the AWS Account setup process.

2 – Getting Started

In this section, you need to select the account setup method. In the scope of this article, we will deal with the IaaC Multiple Accounts Setup. Select the IaaC Multiple Accounts Setup option and click Next.

3 – Link Cloud Accounts

The first page in the Link Cloud Accounts section informs you of the prerequisites. If this is your first time onboarding accounts in nOps, click Proceed to Create API Key.

Note:

If you are adding multiple accounts after you’ve already been onboarded, go to Create an API key to learn how you can get the API key.

On the second page in the Link Cloud Accounts section, enter:

• An API key name
• API Key description
• Signature verification (optional)

After you add all the information, click Create API Key.

Once you click Create API Key nOps will generate an API key for you. Copy and save the API key for future use, and click Next.

When you click Next, nOps will start checking for its connectivity with your AWS accounts. In order for nOps to establish a connection with your accounts and start fetching data, you need to:

1. Go to your AWS console to enable CloudFormation Stacksets in AWS Organization, and enable StackSets in AWS CloudFormation.
2. Go to the nOps Cloud Account Registration Github repo and follow the instructions in Terraform Multiple Child Account Registration via Stackset section.

To enable CloudFormation StackSets in AWS Organizations, go to AWS Organizations > Services. If you see Access disabled against CloudFormation StackSets option, enable it.

To enable StackSets in AWS CloudFormation, go to CloudFormation > StackSets. If there is no prompt to enable StackSets, then skip this step. If you see an option to enable the StackSets, then enable it.

Before you continue with the onboarding process any further, make sure that you have:

• nOps API Key
• IDs of Organization Units you want to onboard.
• Organization Root ID.
• Payer Account ID.

Note:

To view the details about your organization including Organization Unit IDs, Root ID, and Master Payer Account ID, see Details About Your Organization.

nOps Terraform code is available in a public GitHub repository nOps Cloud Account Registration. You need to:

1. Clone the repository.
2. Navigate to `nops-cloud-account-registration/nops-aws-account-register/`.
3. Follow the instructions in terraform-master-payer-regiaster/ folder to add a Payer account. Follow the instruction in terraform-multiple-child-accs-register-via-stacksets/ folder to add child account(s).

After you’ve gone through the installation steps in the public GitHub repository (nOps Cloud Account Registration), the data ingestion process will start.

You can monitor the progress from the terminal where you ran the Terraform commands or you can also monitor the progress from the AWS CloudFormation console. In your AWS CloudFormation console, find the stack with the name member-consolidated-nops-account-register, open it, and go to the Stack Instances tab to see the progress.

After a few minutes (depending on the number of accounts) all stacks should be in the state CURRENT.

4 – Fetching

Once your AWS accounts are linked successfully, the data-fetching process will start It might take several hours for nOps to fetch the data from your AWS account, in the meantime, you can click Let Me Explore to enter the nOps web application to see all the savings that nOps has to offer.

When the data fetching process is complete, you will see the message Your AWS accounts linked successfully on the setup screen.

The setup process is now complete and you will see the following screen.

If you have any questions, please contact us at help@nops.io, or by phone at +1 866-673-9330.

On initial ingestion, nOps will pull the data from AWS accounts based on the following durations:

• Cost data: 6 months look back + current month.
• Rules: Current date.
• CloudTrail Events: 14 days look back.

nOps requires safe, secure, and AWS-approved access to your AWS accounts in order to give you the analysis, dashboards, and reports that you need. We only see what you want us to see in order to provide our services, no more, and we need you to give us permission first.

In order to credential and register multiple accounts, we leverage AWS Organizations, CloudFormation, Stack, StackSets, and Lambda.

For multi-account setup, nOps recommends that use CloudFormation (this setup) instead of Terraform (intended for advanced users with specific requirements).

In this CloudFormation setup, the S3 bucket with the CUR is only required with the Master Payer account.

For a Master Payer account or a single account, during this setup, you will use the same CloudFormation YAML template for both. In order to add Child accounts, you will use a different CloudFormation template. Thus, you will create two stacks, one for the Master Payer, and one for the Child accounts.

Prerequisites

• You must have Admin role permissions in AWS before you can add multiple AWS accounts to nOps using CloudFormation.
• Access to the nOps public Github repository nOps Cloud Account Registration.

Once you’ve taken care of the prerequisites, the next steps are simple and straightforward.

Adding Multiple AWS Accounts (CloudFormation)

When you log in to your nOps account for the first time, a pop-up screen will appear. This pop-up screen will guide you on how you can add your AWS account(s) to nOps. The screen consists of four distinct sections:

1. Select Cloud Type
2. Getting Started
3. Link Cloud Accounts
4. Fetching

After the Link Cloud Accounts section, in the case of Adding Multiple AWS Accounts (CloudFormation), you need to perform these extra steps on the AWS console:

1. Enable Stackset in AWS Organizations and AWS CloudFormation.
2. Go to AWS CloudFormation and create a Stack for the Master Payer account.
3. Log in to the Master Payer account and create a Stackset for the child/member accounts.

To create the Master Payer account Stack and the child/member account stacksets, use the CloudFormation YAML templates from nOps Cloud Account Registration public GitHub repository.

Pull the nOps Cloud Account Registration public repository to your local machine before you continue with the setup. You will need the CloudFormation YAML templates in the repository while creating the stacksets. You will also need the nOps API key.

Select Cloud Type

On this page, select the type of cloud account that you want to onboard and click Next.

In the scope of this article, we are going to deal with the AWS Account setup process.

Getting Started

In this section, you need to select the account setup method. In the scope of this article, we will deal with the IaaC Multiple Accounts Setup. Select the IaaC Multiple Accounts Setup option and click Next.

Link Cloud Accounts

The first page in the Link Cloud Accounts section informs you of the prerequisites. If you are adding multiple accounts after you’ve already been onboarded into nOps, go to Create an API key to learn how you can get the API key.

If this is your first time onboarding accounts in nOps, click Proceed to Create API Key:

On the second page in the Link Cloud Accounts section, enter:

• An API key name
• API Key description
• Signature verification (optional)

After you add all the information, click Create API Key:

Once you click Create API Key nOps will generate an API key for you. Copy and save the API key for future use, and click Next:

When you click next, nOps will start checking for its connectivity with your AWS accounts. In order for nOps to establish a connection with your accounts and start the data ingestion, you need to:

1. Enable Stackset in AWS Organizations and AWS CloudFormation.
2. Go to AWS CloudFormation and create a Stack for the Master Payer account.
3. Log in to the Master Payer account and create a Stackset for the child/member accounts.

Once you complete these two steps, come back to the nOps setup, and you will see the following screen. Click Refresh.

Enable Stacksets

To enable CloudFormation StackSets in AWS Organizations, go to AWS Organizations > Services. If you see Access disabled against CloudFormation StackSets, enable it.

Once enabled, against CloudFormation StackSets, you should see Access enabled:

To enable StackSets in AWS CloudFormation, go to CloudFormation > StackSets. If there is no prompt to enable StackSets, then skip this step.

If you see an option to enable the StackSets, then enable it:

Create a Stack for the Master Payer Account

Stack is a regional service for single account deployment, which in this case, is the Master Payer account. First, we will deploy a Cloudformation Stack in the Master Payer Account. Then we will log into the Organization Master Account to create a Stackset for the Child Accounts (OUs).

Note: It is important to note that an Organization Master Account != Master Payer account. A child account can also be a Master Payer account, but a child account can never be an Organization Master Payer Account.

To create a stack for the Master Payer Account account, go to AWS Console > CloudFormation > Stacks page and click Create stack > With new resources (standard).

The creation of a stack is divided into 4 steps:

In Step 1 (Specify template) —

1. In the Specify template section, choose Upload a template file option.
2. Click Choose file:
3. When you click Choose file, AWS will open a navigation window for you to navigate and select the YAML template in your local machine. In your local copy of the repository navigate to nops-cloud-account-registration/nops-aws-account-register/cloudformation-single-acc-register/ and select the nops_register_aws_acc.yaml file.
4. Click Next.

In Step 2 (Specify stack details) —

1. Provide a Stack name.
2. Enter the account name to register in nOps.
3. Provide the nOpsAPIKey.
4. Enter nOpsPrivateKey with a single slash instead of a double slash since we are using CloudFormation directly.
5. Click Next.

In Step 3 (Configure stack options) — leave every field to its default and click Next.

In Step 4 (Review) —

1. Review the stack details.
2. Check the “I acknowledge that AWS CloudFormation might create IAM resources” checkbox (important).
3. Click Create stack

Create a Stackset for the Child/Member Accounts

Stackset is multi-account and multi-region. To create and deploy a stackset for the Child accounts, make sure that you are logged into your Master Account.

To create a stackset for the Child/Member account, log in to AWS with your Master Payer Account, go to AWS Console > CloudFormation > Stacksets page, and click Create Stackset. The creation of a Stackset is divided into 5 steps:

In Step 1 (Choose a template) —

1. In the Specify template section, choose Upload a template file option.
2. Click Choose file:
3. When you click Choose file, AWS will open a navigation window for you to navigate and select the YAML template in your local machine. In your local copy of the repository navigate to nops-cloud-account-registration/nops-aws-account-register/cloudformation-org-member-accounts-register/ and select the member_consolidated_aws_acc_nops_register.yamlfile.
4. Click Next.

In Step 2 (Specify Stackset details) —

1. Provide a StackSet name.
2. Enter the account name to register in nOps.
3. Provide the nOpsAPIKey.
4. Enter nOpsPrivateKey with a single slash instead of a double slash since we are using CloudFormation directly.
5. Click Next.

In Step 3 (Configure Stackset options) —

1. In the Execution configuration section, select the Inactive option.
2. Click Next.

In Step 4 (Set deployment options) —

1. In the Add stacks to stack set section, select the Deploy new stacks option.
2. In the Deploy targets section, select the Deploy stacks in organizational units option.
3. Provide the organizational unit ID.
4. In the Specify regions section, select your desired region.
5. In the Deployment options section, select the Parallel option (optional).
6. Click Next

In Step 5 (Review), review and create the stackset.

Fetching

Once the stacksets are created and your AWS accounts are linked successfully, you will see the following screen:

It might take several hours for nOps to fetch the data from your AWS account.

After the data is fetched, the setup process is now complete.

Note: It can take up to 24 hours before you start seeing the different nOps dashboards and compliance views populated with data from your workload.

If you have any questions, please contact us at help@nops.io, or by phone at +1 866-673-9330.

On initial ingestion, nOps will pull the data from AWS accounts based on the following durations:

• Cost data: 6 months look back + current month.
• Rules: Current date.
• CloudTrail Events: 14 days look back.

There are three different methods of onboarding a child account:

1. During Automatic Setup
2. Via your nOps Organization Account
3. With the help of Terraform Multi Account Registration (IaaC)

All of these onboarding methods give the child accounts IAM permissions that allow nOps to read metadata, CloudTrail, and everything else about the child accounts. It allows nOps to offer its monitoring and recommendations features for security, operations, reliability, and performance.

During Automatic Setup

You can add child accounts to nOps during the automatic setup process. When you add an AWS Organization Master Payer Account during the automatic process, nOps will automatically pull in child accounts associated with the Parent account. nOps learns about these accounts with the help of your Cost and Usage Report (CUR).

During the Automatic Setup process, you need to set up an AWS Organization account and add an AWS Master Payer Account:

After your Master Payer Account is linked successfully, the automatic setup will then ask you if you want to onboard the child account(s) right now. You can click on Automatic Setup against each child account to start the child account onboarding process:

If you click on Automatic Setup, it will redirect you to the respective AWS account for you to create a stack that nOps will use to access the child account. Please ensure that you are logged into the respective child AWS account when you click Proceed:

When you click on Proceed, you will be redirected to AWS > CloudFormation > Stacks > Create stack > Quick create stack page, with most of the information pre-filled. Click on Create Stack to start the onboarding process.

During the onboarding process of child accounts, nOps will not ask for the CUR since it has already been added with the AWS Organization Master Payer Account.

The setup process can take 1-2 hours to pull in data from AWS.

You can skip the onboarding of child accounts during this setup and add the accounts later.

nOps Organization Account

If you decided to skip onboarding of the child accounts during the Automatic Setup, you can still onboard your child accounts via your nOps Organization Account.

Click on your account at the top right corner of the page and go to Organization Settings > Cloud Accounts, there you will see a list of child accounts that nOps detected with the help of your Cost and Usage Report (CUR).

You can onboard each child account with Manual Setup or Automatic Setup:

Click Automatic Setup or Manual Setup to start the onboarding process.

If you click Automatic Setup, it will redirect you to the respective AWS account for you to create a stack that nOps will use to access the child account. Please ensure that you are logged into the respective child AWS account when you click Proceed:

When you click on Proceed, you will be redirected to AWS > CloudFormation > Stacks > Create stack > Quick create stack page, with most of the information pre-filled. Click on Create Stack to start the onboarding process.

If you click Manual Setup, you will be redirected to the Account Details (Manual Setup) page. Since nOps already has the information for S3 bucket that houses the CUR, the field for the S3 bucket will be locked. Click Update Account to start the onboarding process:

During the onboarding process of child accounts, nOps will not ask for the CUR since it has already been added with the AWS Organization Master Payer Account.

The setup process can take 1-2 hours to pull in data from AWS.

Terraform Multi Account Registration (IaaC)

Use the Terraform Multi Account Registration process when, along with your AWS Organization Master Payer Account, you have numerous child accounts that you want to onboard in nOps. This process makes it easier for you to onboard your child accounts with minimal effort.

You can simply provide the Organizational Unit IDs (OUs) of your child accounts during this setup and nOps will take care of the rest.

To learn about this onboarding process, see Adding Multiple AWS Accounts to nOps with Terraform.

Use the following steps to setup Azure for nOps

Setup Azure for nOps

Content

1. Prerequisites
2. Ensure you have the required permissions in Azure Active Directory (AAD)
3. Creating an Azure AD application
4. Obtain the Tenant ID
5. Create the application and obtain its ID
6. Create and obtain the application secret
7. Grant API access to your application
8. Grant the Reader role to the application

Prerequisites

You must have access to register an Azure AD application in order to continue. To ensure that you have proper access to be able to complete the steps, your account will need specific permissions. There are two main paths to follow:

• For Admin roles, you should already have access to register applications
• For User roles, ensure that you can register applications, or you have been assigned the Application administrator or Application developer role for Azure AD

Use the following process to check which roles and permissions have been assigned to you.

Ensure you have the required permissions in Azure Active Directory (AAD)

1. Log in to the Azure portal
2. Select Azure Active Directory. in the left pane. (Or use search bar at the top of the page.)
3. Select the overview pane to see your login information (2) and your role (marked in red).
   If you are an Administrator or Global Admin, you are all set – skip to Creating an Azure AD application section.
4. If you are a User, click on your email address to open your user page. Click on Assigned roles in the left pane to check if you have either Application administrator or Application developer roles. If either one is listed, you will be able to finish this process.
5. If no additional roles are assigned, you will only be able to continue if non-admin users have the option of creating apps. To check that, use the following steps:

1. Log in to the Azure portal if you are not already logged in.
2. In the left pane, select Azure Active Directory. (Or use the search bar at the top of the page)
3. Click User Settings (1) in the left pane.
4. In the right pane, review the App registrations settings (2) Yes – Allows any user in the Azure AD tenant to register AD apps.No – Only admin users can register AD apps.
5. If the setting is Yes, continue to Creating an Azure AD application section.
6. If App Registrations for your account is set to No, you do not have the correct permissions to continueIn this case, please contact your administrator to allow access using one of the steps listed below. Once the permissions are set you can proceed to the next section of creating the application.
   • Assign you application administrator/application developer role
   • Assign you to an administrator role for the entire tenant
   • Change the App registrations setting to Yes (simplest option)NOTE: Options are listed following the principal of least privilege, i.e., assigning application developer is safer than allowing all users to create apps on the tenant.

For more information about checking the Azure Active Directory permissions, see Check Azure Active Directory permissions.

Creating an Azure AD application

Successfully linking your account with nOps is a manual process of creating a customer application on your Azure tenant. The application you create and the information you will provide during nOps onboarding process allows access to your Azure account through REST APIs and for nOps a way to get the necessary information about your resources.

Using these steps, you will:

• Create and correctly configure the Azure AD application
• Create an application secret
• Assign correct permissions to the application
• Link the application with the appropriate subscriptions within your tenant

Obtain the Tenant ID

1. Log in to the Azure portal
2. In the left pane, select Azure Active Directory. (Or use search bar at the top of the page)
3. Select the Overview page from the left pane.
4. Under Tenant information, find Tenant ID and note it. You will need this ID later.

Ensure that you have the required permissions in Azure Active Directory (AAD)

1. Using the steps documented above in Ensure you have the required permissions in Azure Active Directory (AAD), check that your permissions are correctly set in order to continue.

For more information about checking the Azure Active Directory permissions, see Check Azure Active Directory permissions.

Create an AAD application to access the Azure resources

1. Log in to the Azure portal
2. In the left pane, select Azure Active Directory. (Or use search bar at the top of the page)
3. In the left pane of Azure Active Directory, click App Registrations and click New registration.
4. Specify the following details and click Register.
   • Enter a Name for your application.
   • Under Supported account types, leave the default setting: Accounts in this organizational directory only.
   • Under Redirect URI (optional), leave the default drop-down, Web, and in the blank text field, type ‘https://localhost.’

Your AAD application is now created and added to Azure Active Directory.

For more information about creating the Azure Active Directory application, see Create an Azure Active Directory application.

Obtain the application ID, create and the application secret

1. Log in to the Azure portal
2. In the left pane, select Azure Active Directory. (Or use search bar at the top of the page)
3. In the left pane of Azure Active Directory, click App Registrations, and in the right pane, select the application that you created in AAD.
4. Note the Application (client) ID for the application.You will need to enter this later.
5. To generate an authentication secret, click on Certificates & secrets in the left pane
6. Under Client secrets, click + New client secret to create a new secret.
   Provide a basic description (which will be seen only by you) and expiry duration (a longer period is advised to avoid credential issues from your nOps app) for the secret and click Add. Once that is complete, you will see the newly created entry. From there, note the content of the Value field. IMPORTANT: Please pay close attention to this step and copy the correct field.

For more information about obtaining the application ID and generating the authentication secret, see Get application ID and authentication key.

Grant API access to your application

1. Log in to the Azure portal
2. In the left pane, select Azure Active Directory. (Or use search bar at the top of the page)In the left pane of Azure Active Directory, click App Registrations, and in the right pane, select the application that you created in AAD
3. In the left pane, select API permissions, and in the right pane, select Add a permission.
4. In the Select an API pane, search for Azure Service Management or Microsoft Graph and select it. The five required permissions to ensure the nOps application works properly and has the minimum required access are listed below:
   • Microsoft Graph – Delegated permission
     a. User.Read
   • Microsoft Graph – Application permissiona. AuditLog.Read.Allb. Directory.Read.Allc. Reports.Read.All
   • Azure Service Managementa. user_impersonationFor each section, after checking the permissions, click on the Add permissions in the bottom left corner.

The final screen with correctly configured permissions should look as seen below.

Note that for all the three Application Graph permissions, you will need to Grant admin consent using the button outlined in red.

Grant the Reader role to the application

Ensure that the account in your Azure subscription has the Owner or User Access Administration role to manage access to Azure resources. If your account is assigned the Contributor role, you cannot grant roles.

Only subscriptions that have the Reader role for the application will be displayed to you on nOps.

1. Log in to the Azure portal
2. In the left pane, select Subscriptions. (Or use search bar at the top of the page.)
3. Locate and select the required subscription from the list.
4. n the left pane, choose Access control (IAM) and click + Add followed by Add Role assignment.
5. In the Add role assignment pane, select Reader role Assign access to ‘User, group, or service principal’. NOTE: If you are Global Admin and you don’t see this button/menu being enabled, you need to check the Azure Portal.
   Navigate to Azure Active Directory > Properties > Access Management for Azure resources and set the toggle to YES. Save the settings, sign out from the portal and sign back in to see this menu.
6. Select your Application and click Save

For more information about granting the Reader role to the application, see Assign application to role.

The following information should be captured after successfully completing these steps:

• TenantID
• Application ID
• Authentication secret

All values will be required for onboarding your Azure tenant to nOps.

In this article, you will learn how to add a client from “Partner Portal”. The process is simple and straightforward:

1. Log in to your nOps partner account.
2. Click on your profile name.
3. Click Manage Clients, this will take you to the “Manage Clients” page.
4. In the “Manage Clients” page, click + New Clients > Create a new client.
5. In the “Create a new client” popup —
   1. Fill out the Enter Client Name field.
   2. Select a product from the Product list. Click on the highlighted icon to open the product list.
6. Click Create client.

When you click Create client, the popup will close and the client list on the “Manage Clients” page will be updated with the name of the new client. You can click on the three dots highlighted in red to open the action list:

From the actions list, to add a client’s cloud account to nOps, click Go To This Account. You can also edit client details or cancel their subscription from the action list:

In this article, you will learn how to invite a client in nOps for a well-architected review. The process is simple and straightforward:

1. Log in to your nOps partner account.
2. Click on your profile name.
3. Click Manage Clients, this will take you to the “Manage Clients” page.
4. In the Manage Clients page, click + New Clients > Invite a client for well-architected assessment.
5. In the “Invite customer to nOps” popup, fill out the Email of the client and click Invite Client. The Email Subject, Email Body, and Invitation Link are already prefilled for you. You can edit the Email Subject and Email Body before sending the invitation.

Once you click Invite Client, the client will receive an email with an invitation link, similar to:

If they click on Sign up now, they will be redirect to the nOps sign up page.

After creating an account an signing up for nOps, the clients will also need to verify their email address. The verification email is sent to the same email address that was used for the invite.

When a client logs in into their nOps account for the first time they will see the “Set Up nOps” popup screen from where they can set up a cloud account with nOps. To learn more about the cloud account setup see, Adding an AWS account to nOps with Automatic Setup and Adding an AWS Account to nOps with Manual Setup.

Use nOps Cost Control facilities to manage and optimize your cloud costs.

nOps provides a variety of views to aid you in managing and controlling your cloud costs. Calculating your cloud costs goes beyond just adding up resource costs for a specific region. nOps Cost Control also shows you related costs and credits, to give you a clear picture of your monthly spend.

To access nOps Cost facilities:

Partners:

1. Log in to your nOps account.
2. From Profile Menu select Manage Clients.
3. Click on a client name and go to the client account.
4. Click on Cost in the top menu.

Customers:

1. Log into your nOps account.
2. Click on Cost, in the top menu, and choose one of the options in the drop-down.

This topic describes:

• nOps Dashboard
• Overall Cost Features
• nOps Analysis Tools in Cloud Resources Cost

nOps Dashboard

The nOps Dashboard summarizes changes in your cloud costs and allows you to choose what period of time to compare. The cost changes are broken out by:

• Cloud Accounts
• Cloud Services
• Usage types
• Operations

The order of these sections is constant and reflects the general impact to your cloud spend. Individual line items are listed within each group ordered by spend,

Buttons at the upper right enable you to choose which cloud-account types to include and also whether the cost comparison should be monthly, month-to-date,or weekly.

Note that the Cloud Accounts summary at the top includes links to give you detail of potential savings and underutilized resources.

Note also the View More link at the bottom left of the individual items partial list in each group, to show all records for that group.

Overall Cost Control Options

Expanded dashboards for Partners

The Opportunities dashboard contains information about changes made by your clients to their cloud environments. Only Partners (users and Admins)can access this dashboard.

The dashboard contains a number of charts that you can scroll by using the arrow keys. The charts are followed by a List of Opportunities. The list items change based on what you click or select.

Access the Opportunities dashboard using the following path:
Log in as a Partner > Click on the Opportunities icon from the Partner Dashboard or click the Opportunities tab at the top menu.

Use the dashboard to see which services your clients use most (or least) and find opportunities to engage with them.

As a Partner you now have better visibility into your clients cloud environments to assist them to achieve their cost savings goals and to make rightsizing recommendations.

This article contains the following topics:

The Dashboard View

How to use the charts

Create a Category

The Opportunities List

The Dashboard View

The dashboard displays charts separated by the following tabs: Categories, Services, and Customers. Click a tab to see the default charts. The Categories and Services tabs allow you to view categories and services used by your clients. The By Customers tab lists the top ten clients and their use of services and categories.

There are two types of categories:

• Categories that are mapped to AWS database service categories.
  Note: These are predefined and cannot be changed, edited or deleted.
• Custom categories that you define. You can create categories based on your requirements. These can be edited to add or delete services, or to delete the category.
  For example: You can create a category to customize for example the types of services the use of EC2 instances that are HIPAA compliant. See To create a Category for more information.
  Note: Clicking on any custom categories (defined by you) will not change the List of Opportunities view. That functionality is available only for the default charts.

How to use the charts

Information on the default charts can be viewed in a number of ways.
Note: Clicking, removing, or changing a selection in a chart changes the information displayed in the List of Opportunities section.

• Click on a chart group, then hover on a section to view information about it.
• Click on a section of a pie chart. Information about your selection appears in the updated List of Opportunities.
• Click the navigation arrows under the chart key to scroll through the key to find an item.
• Click an item in the chart key to remove that item from the chart view.
  The removed item no longer appears in the list.
• Click the search box drop-down to display information about one or more items in a category, service. Reset the view by clicking on Clear Filters on the top right of the chart list.
• Use the date filter to view changes made within a date range you specify. The default date range for the charts is the last 15 days.

To create a Category

1. Click the Add new Category button to open the dialog.
2. Add a Name and select one or more Service from the drop-down. The services are grouped by type of AWS category such as Container, Storage, Networking and Content Delivery, and so on. It is easier to find an AWS Service by typing the first few letters to narrow the choices before making a selection.
3. Click Add Category for the system to begin assembling the data for the new category.

IMPORTANT: Custom categories do not change the list view when clicking a selection or removing an item in the key. That functionality is only available for Default Categories and Services.

Edit or Delete a Category

Note: Only custom categories (that you created) can be edited or deleted.

1. Click the settings icon on the top right, for any custom category you created.
2. At the Edit Category dialog, edit the selections (including the Category Name) or click Delete to delete it.

List of Opportunities

The list contains data about which new services were added by your customers within the past fifteen days. You can customize the date range and use filters as described below:

• Change the date range by using the Date drop-down at the top right of each section.
• Filter the results by selecting one or more items from the Category, Service, or Client drop-downs. Enter the first few letters to narrow the results.
  The drop down only lists default categories. The list data is filtered by your selections and changes immediately. Selecting a Service may change the options available on the Category filter.
• Change the list view by removing or adding items to the drop-down.
• Download the information by clicking the Download List button.
• Click an opportunity to expand the information. View information such as the Customer name the Category the selected Services type and their spend. The & 4 others displays any custom categories you created where this category also appears.
• Click Full Usage History or View all other services, to see details on a Usage History dialog for details on Spend and Other Used Services.
• The Opportunity Spend tab under the Usage History dialog, displays the total spend by each resource flagged in this opportunity.

Write a query in the search bar to find specific resources. Learn how to create search queries

How to Use nOps Search DSL

Searching for resources in nOps can be a daunting task. There are a lot of resources in an AWS account, that have been captured by nOps. The ability to pinpoint the specific resource or set of resources is important. Using a single search query might not reveal many results. Using the nOps DSL queries makes this much easier and faster. This tutorial shows some principles and how to search with the DSL Queries

Supported comparison operators:
=, != (int, float and dates, strings)
>, >= (int, float and dates)
<, <= (int, float and dates)

Supported bool operators (case-insensitive):
and, &
or, |

Date format:
yyyy-mm-dd
Example: some_date = 2020-05-02

“IN” operator:
field IN [int, “str”, float]
Example: type in [ec2, “aws.s3”, aws_ebs]

Bool logical order with brackets: The same thing as in other languages: use “()” to show the execution order of logical blocks.
Example. (type = ec2 or type = s3) and cost.usagetype.cost > 13.37

Examples:

Find all EC2 instances with VPC equals “vpc-092eb20aa971a6e0b” or “vpc-d5339bb0” and with the total cost less than or equal to $500:
vpc_id in [“vpc-092eb20aa971a6e0b”, “vpc-d5339bb0”] and type=ec2 and cumulative_cost &lt;= 500

Find all EC2 instances with the Average CPU Utilization less than 30% for the last 3 months
type=ec2 and utilization.months.months_3.cpu.cpu_usage < 30.00

Find all EBS volumes without Encryption enabled
type=ebs and encrypted=false

Find all EC2 instances launched after some date:
type=ec2 and launch_time>2020-01-01

These are a list of the fields that can be used for query. Subsequently this list will be limited to some pre-defined set of fields only

'Name',

'active',

'active_services_count',

'allocation_id',

'arn',

'association_id',

'attached',

'attached_policies.AttachedPolicies.PolicyArn',

'attached_policies.AttachedPolicies.PolicyName',

'attached_policies.HasAttachedPolicies',

'attr_defs.AttributeName',

'attr_defs.AttributeType',

'availability_zone',

'availability_zones',

'available_ip_address_count',

'backup_retention_period',

'billing',

'billing_type',

'bucket_name',

'canonical_hosted_zone_name',

'canonical_hosted_zone_name_id',

'cf_stack',

'cidr_block',

'cloudtrail.first_event.created_by',

'cloudtrail.first_event.event_id',

'cloudtrail.first_event.event_name',

'cloudtrail.first_event.event_time',

'cloudtrail.meta.type',

'codesize',

'cost.available_operation',

'cost.available_usagetype',

'cost.dates_available',

'cost.meta.account',

'cost.meta.availability_zone',

'cost.meta.region',

'cost.meta.resource',

'cpu',

'cpu*',

'cpu_2592000',

'cpu_3600',

'cpu_600',

'cpu_604800',

'cpu_86400',

'create_date',

'create_time',

'created_time',

'creation_date',

'ct',

'cumulative_cost',

'current_month_cost',

'db_cluster_identifier',

'db_instance_class',

'desc',

'description',

'dhcp_options_id',

'dns_name',

'domain',

'ec2_ids',

'encrypted',

'endpoint.Address',

'endpoint.HostedZoneId',

'endpoint.Port',

'engine',

'first_seen',

'groups.Groups.Arn',

'groups.Groups.CreateDate',

'groups.Groups.GroupId',

'groups.Groups.GroupName',

'groups.Groups.Path',

'groups.HasGroups',

'health_check.access_point',

'health_check.healthy_threshold',

'health_check.interval',

'health_check.target',

'health_check.timeout',

'health_check.unhealthy_threshold',

'id',

'instance_id',

'instance_name',

'instance_state',

'instance_tenancy',

'instance_type',

'instances_sg',

'iops',

'ip_address',

'is_as',

'is_default',

'is_eks',

'is_multi_region',

'item_count',

'item_id',

'key_name',

'last_updated',

'lastmodified',

'launch_time',

'listeners.instance_port',

'listeners.instance_protocol',

'listeners.load_balancer',

'listeners.load_balancer_port',

'listeners.protocol',

'listeners.ssl_certificate_id',

'log_file_validaton_enabled',

'memsize',

'mfa_enabled',

'monitored',

'multi_az',

'name',

'network_interface_id',

'network_interface_owner_id',

'node_type',

'number_of_mount_targets',

'number_of_nodes',

'owner_id',

'password_last_used',

'path',

'performance_mode',

'policies.HasPolicies',

'policies.Policies',

'policies.other_policies',

'policy_document.Statement.Action',

'policy_document.Statement.Condition.StringEquals.sts:ExternalId',

'policy_document.Statement.Effect',

'policy_document.Statement.Principal.AWS',

'policy_document.Statement.Principal.Federated',

'policy_document.Statement.Principal.Service',

'policy_document.Statement.Sid',

'policy_document.Version',

'preferred_backup_window',

'private_dns_name',

'private_ip',

'private_ip_address',

'product',

'project.access_key',

'project.access_type',

'project.account_number',

'project.client',

'project.id',

'project.name',

'project.role_name',

'project.status',

'public_ip',

'publicly_accessible',

'region',

'remediation.action',

'remediation.compliance_type',

'remediation.function',

'remediation.id',

'remediation.integration',

'remediation.message_id',

'remediation.modified',

'remediation.status',

'remediation.user',

'replica_role',

'role_id',

'rules.from_port',

'rules.grants.resource_id',

'rules.grants.resource_name',

'rules.grants.type',

'rules.grants.value',

'rules.ip_protocol',

'rules.to_port',

'runtime',

's3_bucket_access_log_enabled',

'scheme',

'search',

'security_alerts.from_port',

'security_alerts.grant.type',

'security_alerts.grant.value',

'security_alerts.ip_protocol',

'security_alerts.status',

'security_alerts.to_port',

'security_groups',

'size',

'snapshot_id',

'state',

'state_change_time',

'status',

'storage_type',

'subnet_id',

'subnets',

'suggest',

'tab_size_bytes',

'tags.key',

'tags.value',

'tags_key.key',

'tags_key.value',

'throughput_mode',

'type',

'user_id',

'user_name',

'user_name_lowercase',

'utilization.consumed_capacity_percents.read',

'utilization.consumed_capacity_percents.write',

'utilization.cpu.cpu_usage',

'utilization.disk.read_iops',

'utilization.disk.read_ops',

'utilization.disk.total_io',

'utilization.disk.write_iops',

'utilization.disk.write_ops',

'utilization.io_limit.percents',

'utilization.months.months_1.consumed_capacity_percents.read',

'utilization.months.months_1.consumed_capacity_percents.write',

'utilization.months.months_1.cpu.cpu_harmonic_mean',

'utilization.months.months_1.cpu.cpu_usage',

'utilization.months.months_1.cpu.cpu_utilization',

'utilization.months.months_1.cpu.cpu_variance',

'utilization.months.months_1.cpu.utilization_percent',

'utilization.months.months_1.disk.disk_read_harmonic_mean',

'utilization.months.months_1.disk.disk_write_harmonic_mean',

'utilization.months.months_1.disk.read_iops',

'utilization.months.months_1.disk.read_ops',

'utilization.months.months_1.disk.space_utilization',

'utilization.months.months_1.disk.total_io',

'utilization.months.months_1.disk.write_iops',

'utilization.months.months_1.disk.write_ops',

'utilization.months.months_1.io_limit.percents',

'utilization.months.months_1.memory.utilization_percent',

'utilization.months.months_1.network.in',

'utilization.months.months_1.network.network_in_harmonic_mean',

'utilization.months.months_1.network.network_out_harmonic_mean',

'utilization.months.months_1.network.out',

'utilization.months.months_1.ram.freeable_memory',

'utilization.months.months_12.consumed_capacity_percents.read',

'utilization.months.months_12.consumed_capacity_percents.write',

'utilization.months.months_12.cpu.cpu_harmonic_mean',

'utilization.months.months_12.cpu.cpu_usage',

'utilization.months.months_12.cpu.cpu_utilization',

'utilization.months.months_12.cpu.cpu_variance',

'utilization.months.months_12.cpu.utilization_percent',

'utilization.months.months_12.disk.disk_read_harmonic_mean',

'utilization.months.months_12.disk.disk_write_harmonic_mean',

'utilization.months.months_12.disk.read_iops',

'utilization.months.months_12.disk.read_ops',

'utilization.months.months_12.disk.space_utilization',

'utilization.months.months_12.disk.total_io',

'utilization.months.months_12.disk.write_iops',

'utilization.months.months_12.disk.write_ops',

'utilization.months.months_12.io_limit.percents',

'utilization.months.months_12.memory.utilization_percent',

'utilization.months.months_12.network.in',

'utilization.months.months_12.network.network_in_harmonic_mean',

'utilization.months.months_12.network.network_out_harmonic_mean',

'utilization.months.months_12.network.out',

'utilization.months.months_12.ram.freeable_memory',

'utilization.months.months_3.consumed_capacity_percents.read',

'utilization.months.months_3.consumed_capacity_percents.write',

'utilization.months.months_3.cpu.cpu_harmonic_mean',

'utilization.months.months_3.cpu.cpu_usage',

'utilization.months.months_3.cpu.cpu_utilization',

'utilization.months.months_3.cpu.cpu_variance',

'utilization.months.months_3.cpu.utilization_percent',

'utilization.months.months_3.disk.disk_read_harmonic_mean',

'utilization.months.months_3.disk.disk_write_harmonic_mean',

'utilization.months.months_3.disk.read_iops',

'utilization.months.months_3.disk.read_ops',

'utilization.months.months_3.disk.space_utilization',

'utilization.months.months_3.disk.total_io',

'utilization.months.months_3.disk.write_iops',

'utilization.months.months_3.disk.write_ops',

'utilization.months.months_3.io_limit.percents',

'utilization.months.months_3.memory.utilization_percent',

'utilization.months.months_3.network.in',

'utilization.months.months_3.network.network_in_harmonic_mean',

'utilization.months.months_3.network.network_out_harmonic_mean',

'utilization.months.months_3.network.out',

'utilization.months.months_3.ram.freeable_memory',

'utilization.months.months_6.consumed_capacity_percents.read',

'utilization.months.months_6.consumed_capacity_percents.write',

'utilization.months.months_6.cpu.cpu_harmonic_mean',

'utilization.months.months_6.cpu.cpu_usage',

'utilization.months.months_6.cpu.cpu_utilization',

'utilization.months.months_6.cpu.cpu_variance',

'utilization.months.months_6.cpu.utilization_percent',

'utilization.months.months_6.disk.disk_read_harmonic_mean',

'utilization.months.months_6.disk.disk_write_harmonic_mean',

'utilization.months.months_6.disk.read_iops',

'utilization.months.months_6.disk.read_ops',

'utilization.months.months_6.disk.space_utilization',

'utilization.months.months_6.disk.total_io',

'utilization.months.months_6.disk.write_iops',

'utilization.months.months_6.disk.write_ops',

'utilization.months.months_6.io_limit.percents',

'utilization.months.months_6.memory.utilization_percent',

'utilization.months.months_6.network.in',

'utilization.months.months_6.network.network_in_harmonic_mean',

'utilization.months.months_6.network.network_out_harmonic_mean',

'utilization.months.months_6.network.out',

'utilization.months.months_6.ram.freeable_memory',

'utilization.network.in',

'utilization.network.out',

'volume_id',

'vpc_id',

'zone',

'cloudtrail.events.event_id',

'cloudtrail.events.event_name',

'cloudtrail.events.event_operation_type',

'cloudtrail.events.event_source',

'cloudtrail.events.event_time',

'cloudtrail.events.username',

'cost.daily.cost',

'cost.daily.date',

'cost.monthly.cost',

'cost.monthly.date',

'cost.operation.cost',

'cost.operation.date',

'cost.operation.item_type',

'cost.operation_dates_available.dates',

'cost.operation_dates_available.item_type',

'cost.tags.key',

'cost.tags.value',

'cost.usagetype.cost',

'cost.usagetype.date',

'cost.usagetype.item_type',

'cost.usagetype_dates_available.dates',

'cost.usagetype_dates_available.item_type',

'tags_kv.key',

'tags_kv.source',

'tags_kv.value',

'violations.Arn',

'violations.ContinuousBackupsStatus',

'violations.CreateDate',

'violations.PasswordLastUsed',

'violations.Path',

'violations.PointInTimeRecoveryStatus',

'violations.Region',

'violations.TableName',

'violations.UserId',

'violations.UserName',

'violations._id',

'violations.access_key_id',

'violations.access_key_last_used',

'violations.access_key_masked',

'violations.actual_iops',

'violations.admin_access_policies.PolicyArn',

'violations.admin_access_policies.PolicyName',

'violations.arn',

'violations.cluster_name',

'violations.compliant',

'violations.cost',

'violations.cpu_604800',

'violations.cpu_utilization',

'violations.create_date',

'violations.current_30d_cost',

'violations.details.cpu_average',

'violations.details.cpu_min_cores_required',

'violations.details.cpu_variance',

'violations.details.diskreadops_average',

'violations.details.diskwriteops_average',

'violations.details.legacy',

'violations.details.network_required',

'violations.details.networkin_average',

'violations.details.networkout_average',

'violations.details.ram_used',

'violations.disk_utilization',

'violations.errors',

'violations.estimated_saving_month',

'violations.impact',

'violations.inline_policies',

'violations.io_usage_percents',

'violations.iops',

'violations.is_config_channels_present',

'violations.is_config_recorder_running',

'violations.is_config_recorders_present',

'violations.item_id',

'violations.item_type',

'violations.last_used',

'violations.log_events_bandwidth_kbytes',

'violations.logging_enabled',

'violations.max_read_avg',

'violations.max_read_request',

'violations.max_write_avg',

'violations.max_write_request',

'violations.memory_utilization',

'violations.monthly_saving',

'violations.multi_az',

'violations.name',

'violations.network_in',

'violations.network_mbytes',

'violations.network_out',

'violations.new_type',

'violations.node_type',

'violations.not_public_read',

'violations.not_public_write',

'violations.old_type',

'violations.overlaps.region',

'violations.overlaps.vpc_cidr',

'violations.overlaps.vpc_id',

'violations.overlaps.vpc_name',

'violations.overwrite',

'violations.performance_mode',

'violations.period',

'violations.policies.PolicyArn',

'violations.policies.PolicyName',

'violations.ports',

'violations.possible_30d_cost',

'violations.project',

'violations.project_id',

'violations.read_capacity_units',

'violations.read_consumed_percentage',

'violations.read_iops',

'violations.read_iops_utilization',

'violations.read_usage_percents',

'violations.reason',

'violations.recommendations.current_30d_cost',

'violations.recommendations.details.early_delete_days',

'violations.recommendations.details.requests_count',

'violations.recommendations.details.storage_gb',

'violations.recommendations.has_early_delete_fee',

'violations.recommendations.new_type',

'violations.recommendations.possible_30d_cost',

'violations.recommendations.update_monthly_change',

'violations.region',

'violations.requests_count',

'violations.resource_id',

'violations.server_side_encryption_enabled',

'violations.size',

'violations.status',

'violations.subnet_ids',

'violations.tab_size_mbytes',

'violations.table_name',

'violations.table_size_bytes',

'violations.tags.CostUnit',

'violations.tags.Name',

'violations.tags.Owner',

'violations.tags.Purpose',

'violations.tags.User',

'violations.tags.aws:autoscaling:groupName',

'violations.tags.aws:cloudformation:logical-id',

'violations.tags.aws:cloudformation:stack-id',

'violations.tags.aws:cloudformation:stack-name',

'violations.tags.aws:ec2launchtemplate:id',

'violations.tags.aws:ec2launchtemplate:version',

'violations.tags.eks:cluster-name',

'violations.tags.eks:nodegroup-name',

'violations.tags.k8s.io/cluster-autoscaler/enabled',

'violations.tags.k8s.io/cluster-autoscaler/nops-test-eks',

'violations.tags.kubernetes.io/cluster/nops-test-eks',

'violations.tags.nOps',

'violations.tags.owner',

'violations.throughput',

'violations.timestamp',

'violations.total_io',

'violations.type',

'violations.update_monthly_change',

'violations.use_days',

'violations.use_weeks',

'violations.user_id',

'violations.user_name',

'violations.versioning_enabled',

'violations.violation_date',

'violations.violation_subtype',

'violations.violation_type',

'violations.volume_id',

'violations.vpc_cidr',

'violations.vpc_id',

'violations.vpc_name',

'violations.write_capacity_units',

'violations.write_consumed_percentage',

'violations.write_iops',

'violations.write_iops_utilization',

'violations.write_usage_percents',

'violations_dates_available.dates',

'violations_dates_available.first_seen',

'violations_dates_available.violation_subtype',

'violations_dates_available.violation_type',

'violations_history.Arn',

'violations_history.ContinuousBackupsStatus',

'violations_history.CreateDate',

'violations_history.PasswordLastUsed',

'violations_history.Path',

'violations_history.PointInTimeRecoveryStatus',

'violations_history.Region',

'violations_history.TableName',

'violations_history.UserId',

'violations_history.UserName',

'violations_history._id',

'violations_history.access_key_id',

'violations_history.access_key_last_used',

'violations_history.access_key_masked',

'violations_history.admin_access_policies.PolicyArn',

'violations_history.admin_access_policies.PolicyName',

'violations_history.arn',

'violations_history.cluster_name',

'violations_history.compliant',

'violations_history.cost',

'violations_history.cpu_604800',

'violations_history.cpu_utilization',

'violations_history.create_date',

'violations_history.current_30d_cost',

'violations_history.details.cpu_average',

'violations_history.details.cpu_min_cores_required',

'violations_history.details.cpu_variance',

'violations_history.details.diskreadops_average',

'violations_history.details.diskwriteops_average',

'violations_history.details.early_delete_days',

'violations_history.details.legacy',

'violations_history.details.network_required',

'violations_history.details.networkin_average',

'violations_history.details.networkout_average',

'violations_history.details.ram_used',

'violations_history.details.requests_count',

'violations_history.details.storage_gb',

'violations_history.details.warning_message',

'violations_history.disk_utilization',

'violations_history.errors',

'violations_history.has_early_delete_fee',

'violations_history.id',

'violations_history.impact',

'violations_history.inline_policies',

'violations_history.io_usage_percents',

'violations_history.item_id',

'violations_history.item_type',

'violations_history.last_used',

'violations_history.log_events_bandwidth_kbytes',

'violations_history.logging_enabled',

'violations_history.max_read_avg',

'violations_history.max_read_request',

'violations_history.max_write_avg',

'violations_history.max_write_request',

'violations_history.memory_utilization',

'violations_history.monthly_saving',

'violations_history.multi_az',

'violations_history.name',

'violations_history.network_in',

'violations_history.network_mbytes',

'violations_history.network_out',

'violations_history.new_type',

'violations_history.node_type',

'violations_history.not_public_read',

'violations_history.not_public_write',

'violations_history.old_type',

'violations_history.overlaps.region',

'violations_history.overlaps.vpc_cidr',

'violations_history.overlaps.vpc_id',

'violations_history.overlaps.vpc_name',

'violations_history.overwrite',

'violations_history.performance_mode',

'violations_history.period',

'violations_history.policies.PolicyArn',

'violations_history.policies.PolicyName',

'violations_history.ports',

'violations_history.possible_30d_cost',

'violations_history.project',

'violations_history.read_capacity_units',

'violations_history.read_consumed_percentage',

'violations_history.read_iops',

'violations_history.read_iops_utilization',

'violations_history.read_usage_percents',

'violations_history.reason',

'violations_history.recommendations.current_30d_cost',

'violations_history.recommendations.details.early_delete_days',

'violations_history.recommendations.details.requests_count',

'violations_history.recommendations.details.storage_gb',

'violations_history.recommendations.has_early_delete_fee',

'violations_history.recommendations.new_type',

'violations_history.recommendations.possible_30d_cost',

'violations_history.recommendations.update_monthly_change',

'violations_history.region',

'violations_history.requests_count',

'violations_history.server_side_encryption_enabled',

'violations_history.status',

'violations_history.subnet_ids',

'violations_history.tab_size_mbytes',

'violations_history.table_name',

'violations_history.table_size_bytes',

'violations_history.tags.ChangeVersion1',

'violations_history.tags.CostUnit',

'violations_history.tags.JT',

'violations_history.tags.Name',

'violations_history.tags.Owner',

'violations_history.tags.Purpose',

'violations_history.tags.User',

'violations_history.tags.aws:autoscaling:groupName',

'violations_history.tags.aws:cloudformation:logical-id',

'violations_history.tags.aws:cloudformation:stack-id',

'violations_history.tags.aws:cloudformation:stack-name',

'violations_history.tags.aws:ec2launchtemplate:id',

'violations_history.tags.aws:ec2launchtemplate:version',

'violations_history.tags.aws:ec2spot:fleet-request-id',

'violations_history.tags.eks:cluster-name',

'violations_history.tags.eks:nodegroup-name',

'violations_history.tags.k8s.io/cluster-autoscaler/enabled',

'violations_history.tags.k8s.io/cluster-autoscaler/nops-test-eks',

'violations_history.tags.kubernetes.io/cluster/nops-test-eks',

'violations_history.tags.nOps',

'violations_history.tags.ownder',

'violations_history.tags.owner',

'violations_history.timestamp',

'violations_history.total_io',

'violations_history.type',

'violations_history.update_monthly_change',

'violations_history.user_id',

'violations_history.user_name',

'violations_history.versioning_enabled',

'violations_history.violation',

'violations_history.violation_date',

'violations_history.violation_subtype',

'violations_history.violation_type',

'violations_history.volume_id',

'violations_history.vpc_cidr',

'violations_history.vpc_id',

'violations_history.vpc_name',

'violations_history.write_capacity_units',

'violations_history.write_consumed_percentage',

'violations_history.write_iops',

'violations_history.write_iops_utilization',

'violations_history.write_usage_percents'

Managing and viewing AWS Reserved Instances via Commitment Management Dashboard

nOps enables you to view usage of AWS Reserved Instances on a near-real-time basis. Reserved instances provide significant cost savings compared to on-demand billing, and instances and usage can be monitored through the nOps Commitment Management dashboard.

This article explains:

1. Why Use Reserved Instances.
2. Accessing the Reserved Instance Pages via the Commitment Management Dashboard
3. Reserved Instance Planning
4. Reserved Instance Coverage
5. Saving Plans Recommendations
6. Saving Plan Utilization
7. Troubleshooting

Why Use Reserved Instances

AWS Reserved Instances can save you significant costs compared with on-demand instance use. Standard reserved instances that you purchase must match certain attributes of your running instances in order to achieve the savings, such as instance type and region. Convertible reserved instances provide more flexibility, and scheduled reserved instances ensure capacity for specific time periods.

See the AWS Types of Reserved Instances documentation for a complete description of each.

nOps’ Commitment Management pages (Reserved Instances Planning, Reserved Instance Coverage) provide insight into your current utilization of reserved instances that you’ve purchased and provide planning insights to get even more cost savings from this important AWS feature.

Accessing the Reserved Instance Pages via the Commitment Management Dashboard

To access Reserved Instances management:

1. Log into nOps.
2. From the Dashboard, click Cost to open the drop-down menu, and choose Commitment Management:
3. Note that the in the Commitment Management dashboard the following tabs are for Reserved Instances:
   • Reserved Instance Planning
   • Reserved Instance Coverage

Reserved Instance Planning

Use the Filters in the left pane to see reserved-instance recommendations, and historical usage, by AWS account, instance type, and other criteria. Using filters to subset the recommendations can help target how your costs could improve for various reserved-instance recommendations.

Recommended Instance Reservations

• Based on your current instance use, recommends how many reserved instances you should have to cover that use, and shows what the savings would be.

• Note that the instance use is per combination of instance type, AWS region, and OS – the three left-hand columns.
• If the number of records exceeds the table maximum, click the blue Download button to get a CSV that includes the full list of recommendations:

Historical Usage

• The historical usage table lists – by instance type, availability zone, and OS – your instance usage over the past five months, to aid your RI planning.

Reserved Instance Coverage

To use the Reserved Instance Coverage tab, you must first enable it.

Enabling the Reserved Instance Coverage Feature

This tab to manage Reserved Instance Usage is only available for Client Member users who subscribe to this feature. It is not available for Partners, or for Partner Clients. Only Client Members can subscribe to this feature and configure their environment to enable the Reserved Instance Coverage tab.

This feature currently only shows coverage for EC2 instances.

To use this dashboard, you must configure your AWS environment using an nOps-authored CloudFormation stack from the nops-aws-forwarder project in the nOps GitHub repository. The project contains a ReadMe that describes requirements and installation, and includes a button that launches the CloudFormation stack.

As noted in the ReadMe, you must configure AWS CloudTrail with an S3 bucket for CloudTrail logs before deploying the CloudFormation stack. A CloudTrail events log in your AWS account provides nOps the information needed to calculate RI utilization and EC2 instances. Note that the S3 bucket for AWS CloudTrail and the nOps-aws-forwarder should be within the same region.

The Reserved Instance Coverage Tab

The boxes at the top of this page summarize:

• Running Normalized Units
• Reserved Normalized Units
• Running Instance Coverage

Running Normalized Units and Reserved Normalized Units are explained by the AWS documentation for the various instance families.

Running Instance Coverage is the percentage of running instances that are covered by a reserved instance – 100% means all normalized units within a given size are covered, and 0% means that none of the normalized units within a given size are covered.

Below the boxes, the Reserved Instances list gives RI coverage for AWS accounts broken out by region, tenancy, platform, and family.

Note: The column headings on this page include sorting by clicking on the column heading, plus filtering and column-choice options that appear and can be chosen when you hover over any column heading:

When you hover over a column heading, then click the symbol that appears, options appear for column sizing:

Note that filtering and column-choice options are also in the heading of the drop-down – here’s the filtering option used to show reserved-instance coverage for a specific region:

The column-choice options let you include in the table only the columns of use to you:

Symbols in the column headings show the sorting and filtering that are in effect:

Note also the arrow → in the Action column, which you can click to view the details page for that account group. More than one account can be included in a group.

The filtering and sorting options you’ve chosen on the main Coverage page persist on that page if you navigate to a details page then back again, and the same options are available on the details page (though the details sorting and filtering resets when you leave that page).

Note also the Refresh data button at the upper right:

Reserved Instance Coverage Details

In the details page, accessed by clicking the arrow in the Action column, boxes at the top summarize account, region, OS (platform), etc. of the line you’ve chosen:

The Usage Summary graph shows running and reserved instances in normalized units, over the last 12 hours – though you can change the time period by pulling down the blue button at the right:

The delta between the Reserved and Running lines in the graph help you understand how much under-provisioned or over-provisioned you are in reserved instances over time.

Important: You can set a webhook to inform you if you are running a deficit or a surplus on Reserved Instance coverage. See the Webhooks topic for more information.

Note the two tabs below the chart that provide tabulated details for reserved and running instances:

And, in the tables under those tabs, the column heads provide the same sorting, filtering, and column-choice abilities as described above for the Coverage page itself. Click on any column heading to sort (repeated clicks change sort order), or hover over any column heading and click the icon that appears to filter, choose columns, and adjust column width.

Use the Go Back button at the upper left to return to the Reserved Instance Coverage page:

Savings Plans Recommendations

In the Savings Plans Recommendations tab, you can tweak the filter properties to calculate the savings you can get on Reserved instances if you buy Savings Plans:

In the Filters section, you can select the desired:

• AWS Account
• Savings Plans Type
  • Compute
  • EC2 Instance
  • SageMaker
• Savings Plans Term
  • 1 Year
  • 3 Year
• Payment Option
  • No Upfront
  • Partial Upfront
  • All Upfront
• Look-Back Period in Days
  • 7 Days
  • 30 Days
  • 60 Days

Once you set the filter, in the Recommendations section, you can see the:

• Upfront Cost on the Savings Plan
• Hourly Commitment To Purchase
• Estimated Utilization of the plan based on your current usage
• Estimated Monthly Savings:

You will also get the look-back analysis, you can adjust the look-back period in the Filters section. In the Look-Back Analysis section, you can see:

• Look-Back on Demand
• Estimated Savings Plan
• Estimated New On Demand
• Estimated Savings
• Estimated Return on Investment (ROI)
• Minimum Hourly Charges
• Maximum Hourly Charges
• Average Hourly Charges

All the Savings Plans and the details that you see on this page come directly from AWS. When you set a filter, nOps sends your selections to AWS and simply shows the response allowing you an easy way to find the Savings Plans according to your requirements.

Savings Plans Utilization

If you have purchased Savings Plans, you can see well you are utilizing the Savings Plans.

In the Savings Plan Utilization tab, you can select the AWS account in the Project drop-down list and use the Calendar field to filter the timeframe for which you want to check the utilization of your Savings Plans:

In the Savings Plan Utilization tab, you can see the:

• Net Savings For Selected Period
• Savings Plans ARN
• Hourly Commitment
• Total Commitment (in hours)
• Used Commitment
• Unused Commitment
• Utilization in percentage
• Net Savings
• On Demand Cost Equivalent

You can also click on the “>” icon to see the detailed breakdown of each of your savings plan. When you click the “>” icon, you will see:

• Account ID
• Start Date
• End Date
• Savings Plan Type
• Instance Family
• Region
• Payment Option
• Term
• Amortized Monthly Recurring
• Amortized Upfront
• Amortized Total

Troubleshooting for Reserved Instance Usage

Q: Why don’t I see any data on the page?

A: There are few possibilities for why you may not see any data on this page.

• You may have opted not to enable this feature, or you may not be using any reserved instances.
• You may not have configured CloudTrail or the nOps Forwarder that provides the data to nOps. See Enabling the Reserved Instance Coverage Feature above.
• If you have enabled this feature and done the configuration, it may take up to 10 hours to receive data about your instances. Contact nOps Customer Support if you do not begin to see the data after that time.
• This tab is not available for Partner Users or Partner Client Users

Choosing Cloud Resources Cost from the Cost Control pull-down gives you a set of tabs that show your cloud spend broken out by:

• Cloud Accounts – spend by account in AWS, Azure, etc.
• Regions – spend by region in cloud vendor
• Cloud Services – spend by service in each cloud vendor
• Resources – spend from cloud resources being used
• Non-resources – spend not specifically from cloud resources
• Usage Types – spend by AWS usage type
• Operations – spend by AWS operation
• Tags – spend by tagged resource, with tagged resources grouped under key name
• Change Management – log of daily cost changes

The first seven of these tabs(Cloud Accounts, Regions, Cloud Services, Resources, Non-resources, Usage Types, and Operations) each give you:

• A Spend Summary at the top :
  • Yesterday’s Total Spend
  • Last Week’s Spend
  • Month to Date Spend
  • AWS Credits (applicable tabs only)
• An array of Filters in the vertical box at the left, enabling you to view cost trends over time, and to understand which resources contribute to higher costs.
• A History bar chart just below the Spend Summary. Note the two buttons above the right side of the chart:
  • See Spend Forecast
  • See Spend History
• Details of Daily Spend listed in a table below the History chart

Spend Summaries

A few notes:

• The periods for the Spend Summary boxes Yesterday, Last Week, and Month to Date are as defined by AWS.
• If you choose a specific date range in the Filters box at the left, the Spend Summary becomes just the total spend for that date range (no yesterday’s spend, last week’s, or month to date).
• On the Resources and Non-resources tabs, the Spend Summary gives the appropriate subtotals for resources or non-resources. For the other five tabs, the Spend Summary gives the same overall totals. (The History chart and Daily Spend table below the Spend Summary do give details broken out per the specific tab title.)
• Credits: The overall credits value in the spend summary is as reported by AWS, and includes both AWS credits and refunds. The number in the Credits box of the Spend Summary is for the specific date range in the Filters box at the left. The credits value in the summary when you hover your cursor over a “circle-i” is the portion of the AWS credits plus refunds, reported by AWS, for yesterday, last week, or month to date, depending on the box.
• Hover text summary: Hovering your cursor over the “circle-i” in any of the three Spend Summary boxes gives the Resources, Non-resources, and AWS Credits value for the time period of that box (yesterday, last week, month to date). These numbers and the associated time periods are as defined in AWS.

Filters for Analyzing Costs

The Filters vertical box at the left allows you to zero in on a combination of resources and parameters and so find the sources of cost trends over time, or understand which resources contribute most to higher costs. See How to use nOps Search for information on even more sophisticated search possibilities.

Filtering criteria you’ve chosen are shown by ovals above the Spend Summary, so that you can easily track the filtering criteria that you have in effect — however, note that any custom date range is not represented by an oval above the Spend Summary.

The Filters box includes a calendar tool, which allows you to specify a date range for which costs are to be displayed and summed. When specifying a custom date range:

• Use the Apply button at the very bottom of the enlarged calendar tool, to make your date range take effect
• Note the “easy-button” pre-specified date ranges, like 1W, 3M,or May 2022, just above the Apply button.

The default cost display might only cover the preceding month. The calendar tool can be used to view cost changes over time periods that are meaningful to your business.

Spend figures next to regions, cloud-managed services, and other criteria listed in the Filters box are the total for that filter criterion and will match the total in the Daily Spend table on the page.

History Chart

The color-coded choices beneath the chart can be clicked to exclude each from the chart, enabling you to focus on particular regions, services, resources, etc.

Daily Spend

• The Total column in the table is the total for the date range set in the Filters box on the left.
• The table of daily values scrolls left to right through the days (scroll bar at bottom) and is paginated 10 records per page (page selection at lower right).
• The Daily Spend detail on each page has a Download CSV button at the upper right that downloads all spend records for that page. For example, if a tab such as Operations has 170 records, the default view may display only 10 records at a time. However, clicking the download icon will download all records (in this example, 170) in a .csv file:

Non-resources

This tab gives costs not associated directly with a resource, such as taxes and AWS or Azure services (for example, AWS Key Management Service, or AWS CloudTrail). To see a complete list of your non-resource costs for the selected filter criteria (including selected date range in the Filters box calendar tool), click Download CSV at the top of the Daily Spend table below the History bar chart.

Cost Details for Resources and Non-resources

You can get details for any Daily Spend value or Total value in the Resources or Non-resources pages by clicking on the value:

Tags

The Tags tabgives the spend for all tags by key name. Note that:

• To see the spend for each value under a key name, expand a key name by clicking on it, or by clicking on > at the right end of the row.
• To see detailed costs for tag key-value pairs, use the Tag Explorer page under Cost Control (Cost Control pull-down, choose Tag Explorer).
• A blue Download button (upper right) gives you a CSV file of the spend figures by key name, for all keys. The CSV does not break out by key value.
• The Cost (total) column gives the total spend for the time period specified in the Filters column at the left — default, 1 month to date.

Change Management

The Change Management tab lists the changes in your account and the potential billing impact of these changes. You can expand or collapse each day’s list of changes by clicking the down arrow at the right, and you can click on the Daily, Weekly, or Monthly filter options to see the total spend change over daily, weekly, or monthly intervals for each resource type. Change the Sort by options to view increases or decreases by cost or by percent.

Finding Cost Changes

Use one or a combination of the following methods to explore cost changes, compare what you paid this month vs last month, or investigate a spike in costs.

• Check costs on the dashboard. From the Dashboard, navigate to Cost Control / Cloud Resources Cost. Check the Cloud Accounts, Cloud Services, Resources, and Operations spends. Spend numbers flagged in red show are higher than in the previous time period. Check for variances. You might notice (for example) that unexpectedly higher costs stem from adding a number of new resources.
• Use the calendar tool. For example, in the Resources tab, if the spend and usage look normal and there are no spikes, use the calendar tool to include costs for the prior month. This may show changes in resources. Also examine Non-resources tab to see how such items as support costs, usage costs for pausing and restarting an instance, egress costs, or tax costs are contributing to your spend.
• Also in the Resources tab, use the various filters in the box at left – for example, to isolate key resources by tags, region, account, usage type, etc., so that you can evaluate a specific resource or a set of resources for changes in cost over time.
• From the Regions tab, click on See Spend Forecast to see estimates based on your current spend.
• Set up Notifications. From the Change Management tab click on Subscribe to be notified of cost changes. You can select a period of time, and a range for the cost comparison (by week or by month). Enter emails for people who will receive these notifications.

How to use Resource Rightsizing

How to use Resource Rightsizing

Rightsizing is one of the best ways to bring cloud costs under control. To do this you must continuously analyze instance performance, usage patterns and needs. After that, turn off idle instances and rightsize any instance that is either poorly matched to the workloads or over-provisioned.

Rightsizing is an ongoing process since resource needs are constantly changing. To achieve cost optimization make rightsizing a regular part of your cloud management process. nOps simplifies both resource analysis and monitoring.

Review Amazon Cloudwatch metrics to identify usage patterns and needs that enable you to take advantage of rightsizing opportunities:

• Steady State: In the steady state, the load remains at a constant level for some time. It is even possible to forecast the compute load at any one time. For this type of usage pattern, consider Reserved Instances. They can yield significant savings.
• Variable and predictable: For such instances, the load varies over time but on a predictable schedule. AWS Auto Scaling is ideal for applications that exhibit stable demand patterns weekly, daily, or on hourly usage variability. You can use AWS Auto Scaling to scale EC2 capacity whenever there is a spike or fluctuation in traffic.
• Dev/test/production: Turn off production, testing, and development environments in the evening since organizations usually use them during business hours.
• Temporary: Do you have temporary workloads with flexible starting times that you can interrupt? Avoid using an on-demand instance. Instead, place a bid on an Amazon EC2 Spot Instance.

Click on Cost Control:

Select Resource Rightsizing:

Use the tabs at the top to switch between EC2, RDS, and S3:

Use the Filters section to look through specific information on:

• AWS Account
• Instance Types
• CloudFormation: StackName
• Autoscaling Group
• Regions
• Tags

Current Config and Suggested Config columns use data over the past 2 weeks to make the suggestion of downsizing:

Click on Resource Details to look at Resource Details, Cost History, and Configuration History:

How does nOps Rightsizing Algorithm Work?

With CloudWatch Enabled

nOps collects 6 key metrics for every CloudWatch enabled EC2 instance in your environment:

• NetworkIn
• NetworkOut
• DiskReadOps
• DiskWriteOps
• CPUUtilization
• mem_used_percent

For each instance in your environment, we make the following calculations:

• Network average
• Harmonic mean of disk read and write
• Disk read and write averages
• Average network in / out utilization to six points of precision
• Average memory utilization
• Average CPU utilization

We continuously monitor a 30 day sample of your utilization data and match your CPU requirements to the latest offerings in the AWS pricing catalog to select the best match for your resource requirements.

Without CloudWatch Enabled:

nOps will recommend the latest offering upgrades for your given instance class, when they are available.

Identify EC2 instances and view details on the Spot instances

How to View nOps Spot Advisor

The spot advisor helps you to find EC2 instances that can be migrated to use Spot instances. This guide will show how to navigate to the Spot Advisor to see the instances that can be converted to Spot Instance pricing.

On the dashboard, go to menu item Cost Control and click to pop-out the drop-down menu item. Navigate to the Spot Advisor menu item and click it.

This will lead you to the Spot Advisor Dashboard which shows the list of instances and the cost estimates for the Spot option of those instances.

There is an option to view more detail on the Spot Instance. Click on the Instance name.

This will pop-up a new screen, which will give detailed information on the EC2 Usage for the Spot Instance. There is options to view Resource Details, Cost History, and Config History.

How to use Tag Explorer

Tag Explorer

The Tag Explorer feature allows you to assess tags you attached to resources for billing information to better organize your costs. Such as costs for different stacks, customers, environments, projects, departments, or teams. Displaying the current information will highlight untagged resources. Following are some terms and what they mean:

Tag Key: is top level of the tag.

Tag Value: you can assign more than one tag value to a tag key. For example:

• Application: Production
• Application: Testing

Use Case: Use tags to understand the cost of all the resources used to run an app. You can report on Tag Keys and Tag values. It’s an easier way to group resources to view their corresponding costs

This feature is available from a Client Page.

On the NavBar click Cost Explorer > Tag Explorer

Filter by any of the following:

• Date
• Custom Rules
• Resources Launched after
• Resources Launched before
• AWS Account
• CloudFormation: Stack-Name
• Regions
• AWS Manages Resources
• Operations
• Usage Type

When hovering over the row for Tags used on the left-hand side it will breakdown the cost of each AWS managed services by color. Depending on the color of the graph line you hover over it will bring the cost of the AWS managed service to the top of the graph key.

In the All tags list, you can select a tag to view details. To do this click the arrow in the ACTION column.

The following page displays a breakdown of the Tag name. From this page you can see: Service, Resource name, Project, Region, and Total Cost.

Clicking the arrow in the ACTION column, for details about the selected Service .

A pop-up dialog provides details on when the Service was created and last used.

• Select Add a Jira Ticket to connect to Jira to create a ticket.
• Click View Resource on AWS Console to navigate directly to the resource in your AWS Account.

Did this answer your question?

View IAM security principles that show any violations

How to view IAM violations

IAM violations show you IAM security principles that your account does not comply with. For this to be possible, you must first set up your AWS account(s) on nOps. These violations could range from accounts not using MFA, accounts not granted least privilege To view IAM role violations take the following steps

Go to the nOps Rules tab.

nOps Rules page will be launched with various tabs showing the different options. Such as Security, Cost, Reliability, Operations, Performance, and Change Management

On the left side-bar, there is a section called Filters. Under Filters, there is a search bar. In that search bar type the word IAM. and press the enter key to search

This will show a list of IAM violations on the right-hand side. From the screenshot we can see at least 4 sections of violations; 266 AWS IAM roles aren’t attached to any resource, 36 users have not been granted least privilege permissions in AWS IAM, 11 active root account access key(s) detected, 6 AWS IAM users aren’t using MFA-enabled sign in

Fix under utilized EBS volumes from the nOps Rules page

How to View Under-Utilized EBS Volume

nOps has the feature to view underutilized EBS volume on the nOps Rules page. Using the Costs section will display underutilized resources that can then be fixed in the AWS account.

Navigate to the menu bar, and click on the nOps Rules menu item.

This will lead to the nOps Rules page

On the nOps Rules dashboard. There are series of tabs with labels Security, Cost, Reliability, Operations, Performance and Change Management. Click on the Cost tab

This will show a list of items that can be re-configured to save your overall AWS cost. From the list, identify the item unused Amazon EBS volumes detected

Manage under utilized resources and address the resource by overriding the violation or fix through the AWS account

How to view Under-Utilized Network Resources

nOps has the feature to view underutilized network resources on the nOps Rules page. Using the Costs section will display under utilized resources that can then be fixed in the AWS account.

Tip: While looking at the Underutilized resources, nOps does not recognize credits that are applied to the account. (Screenshot provided from Dashboard)

See example below:

How to find Underutilized Resources

Navigate to the menu bar, and click on the nOps Rules menu.

This will lead to the nOps Rules dashboard.

On the nOps Rules dashboard.There are series of tabs with labels Security, Cost, Reliability, Operations, Performance and Change Management. Click on the Cost tab

This will show a list of items. This list shows items that can be re-configured to save your overall AWS cost. Under-utilized network resources range from unused EIP, unused NAT resources

Under the Rule Name there is an option to view the underutilized resource in detail. Click the arrow to view the resource in detail.

On the Unused Resource Details will list in detail the resources. By clicking the 3 dots on the right-hand side of the resource detail, it will list actions to resolve this issue.

Custom Templates are used to create SOW’s, review, and more.

How to Create a Custom Template – Partners

Using the Custom Template feature is a tool to customize a report. Saving the Report Template can then later be used for a Custom Report for the company or clients.

Click on Custom Templates on Dashboard

Or, click on Reports>Custom Templates

On the Custom Template page, click on Create Custom Template

A pop up will appear. Add a name for the report, and click New Template.

*There is an option to edit all the existing templates., by clicking on one of the created custom templates it will take you to a screen to edit the existing version

On the right-hand side there are options to add to the report by clicking on the Library options it give the option to select which block to add to the report.

*Some of the items you can click on and it will add the block to the bottom of the template. Others will need to clicked and dragged.

Within the built template the you can move the blocks up and down. Or, delete blocks that were added, that you no longer need.

Heading – Create a Title for the Report

Paragraph – Add text to the report (Explanation, Purpose…)

Table of Contents – Will add a table of content to the template to explain which blocks will be used in template

Remediation – Select a plan to remediate

Recommendation – Select any recommendations for improvement

Table – Add a Pricing Table

Cost Summary – AWS spend from yesterday, last week, and month to date

All Rules – Select rules from Security, Cost, Reliability, Operations, Performance

Resources – Resources from AWS account

High Risk Issues – Issues that are considered HRI

Example of how the Template will appear:

How to Create and View Custom Reports (MSP)

If you are not logged into your Partner Dashboard already, follow these steps:

Navigate to the top right corner of the screen where you have the name of the user that is currently logged in. Click on the name to display the drop-down menu. On the menu that shows, navigate to the Partner Dashboard menu item and click.

This will take us to the Partner Dashboard page.

Navigate to the top menu bar and click on the Templates menu item. On the drop-down that pops-out, click on the Custom Reports menu item

This will lead to the list of reports you can create or view.

Creating a New Report

Note Reports are created and managed by the Administrator. You can only view the Custom Reports

Select which template to use. A pop-up will ask for a name and for which client.

Once on the Custom Report, there are options to select what items to add to the report for a client. There are options to drag and drop in the Library and add comments to the report

By clicking the Share button the ability to share the report through email or copying the URL to the report.

How to Check if the Root Account MFA status

nOps has the option of checking security across your AWS account that it is connected with. One crucial part of the AWS account is the root account. The maximum-security has to be applied to it, else any vulnerability or risk found and exploited can be devastating to the whole AWS account. Let us show you how to check if MFA is activated for your AWS account

Click on the Security Dashboard menu item, which is one of the top menu items.

This will lead to the Security Compliance Dashboard. This dashboard displays different rules and violations. On the page IAM Role Permission and Account Usage. Scroll to the item called AWS accounts doesn’t have root account MFA.

This shows if the root user has MFA enabled or not. Clicking on the arrow on this row, will display who is not in compliance

View all security violations for Network Layer, S3, IAM and more

How to view all Security Violations

There are lots of security violations that are available across an AWS account from Network Layer to S3 to IAM and others. This guide shows how to view all security violations in your AWS account.

Go to the Security Dashboard menu item.

This view will give a Summary of all security violations on your AWS account which can be filtered with these options; Custom Rules, AWS Account, Cloudformation Stack Name, Tags, Regions, and VPC

Describes how to create a workload

How to Create a Workload

Workloads in nOps help you to group different AWS resources that have been created within your AWS environment. This makes it easier to carry out various assessments on those specific services that make up with Workload. These are the steps to create a workload in nOps.

Access Workloads by clicking Workloads from the tabs.

Creating a workload is as easy as selecting the Workloads tab and clicking the Add New Workload button on the top right. Once a workload is created you can edit it to add or remove resources. Note that you cannot rename a workload, but you can always create a new one.

What to know before you begin

nOps offers the following review types and compliance frameworks

Creating Your First Workload

If this is the first time you have created a workload, you will click “Create new Workload” in the middle of the screen. After that, the Create new Workload button will move to the top right of the window.

To Create a new Workload

1. Click the Create New Workload button to create a new workload. This opens a dialog with a form to fill for creating the Workload
2. Enter the following information:.
   • Workload Name – This is an unique identifier for your workload.
   • Select the Review types you want to use to asses this Workload. Select Well Architected for AWS Cloud accounts
   • Select the Compliance Frameworks for this workload from the list. This setting is optional.
3. If you are using an AWS account select the toggle to change the choices and to allow nOps to find your Resources and save the WAFR compliance progress. Select an AWS Account and an Environment type and enter a Description for the Workload .
4. Specify the Workload resources Enter all Regions that nOps will pull resources from. This defaults to All.
   The AWS Managed Services that nOps will include in your workload. This defaults to All Managed Services and
   Enter VPCs that contain the resources that nOps will include in your workload.
   
5. Select tags to be assigned to the resources you want to include, e.g., “ApplicationA.” You can add as many tags as you need.
   
6. Add notes for the workload and click Save to save and create this workload. And that’s it!

It may take a few minutes for the Workload to appear. The workload is displayed on the Workloads Dashboard.

Click on the workload to view the details.

How to Create Workloads (MSP)

If you are not already logged into the Partner Dashboard follow these steps:

Navigate to the top right corner of the screen where you have the name of the user that is currently logged in. Click on the name to display the drop-down menu. On the menu that shows, navigate to the Partner Dashboard menu item and click.

This will take us to the Partners Dashboard page.

1. On the Partners Dashboard, there is a menu item at the top with the title Workloads.

Click on the Workloads link. This will take you to the Workloads page.

On the Workloads page, click on the Create New Workload on the top-right corner of the screen.

A form will pop-up on the side, fill out the form with all the required information.

Workload Name – This is the unique identifier for your workload.

• AWS Account(s) – The AWS Account(s) where the resources for your workload live.
• Workload Type – Defines the overall workload type. Please select “Well-Architected.”
• Lens – nOps supports the AWS lens concept. Please select FTR for the lens type.
• Environment – This defaults to Production and defines the environment from an AWS perspective.
• Jira project – If you are using the built-in Jira integration, you will be able to select a Jira project to integrate with.
• Description – A text description of your workload.

After you have filled out the metadata for your workload, you can click the gray bar that says, “Specify Workload Resource,” causing the query builder to slide into view. nOps allows you to specify rules that define which resources will be added to the workload.

• Regions – The regions that nOps will pull resources from. This defaults to All.
• AWS Managed Services – The AWS services that nOps will include in your workload. This defaults to All.
• VPC – The VPCs that contain the resources that nOps will include in your workload. This defaults to All.
• Tags – Select tags to be assigned to the resources you want to include, e.g., “ApplicationA.”

Click “Save” to create your workload.

Attach new resources to an existing or new WAFR/Workload

How to Add New Resources in Workloads

You can add new resources to an already existing workload that has been created, this guide helps to make that possible.

1. Login to your nOps account
2. Click on the Workloads Tab
3. Choose an existing Workload and click the Edit button on the right.
4. At the Modify Workload dialog, click Specify Workload Resource and edit or change the resources by using the options in the drop-down.
5. Add any additional tags then click Save to add the resources to the workload.

See Also: How to create Workloads, and Viewing and Managing Workloads

View and Manage Workloads using the dashboard

Workloads are a collection of resources that include your compute resources and comprise a basic unit. A workload should contain all of the resources (EBS or EC2 volumes, S3 buckets etc.) and specify all of the Regions where these resources live.

This article contains the following information:

Why create a workload?

Viewing a Workload using the Workload Summary tab

Compliance Ops

Why create a workload?

Creating a workload lets you define competencies, lenses, and frameworks for a workload environment in order to get contextual recommendations, targeted assessments and detailed reports.

If you are new to nOps you may find that a Workload has already been created for you. The workload contains all of the regions where you currently have compute resources for the accounts you have shared with nOps.

Recommendation: nOps recommends that you create a Production workload that contains all of the compute and other resources used for your Production environment. This workload should be assessed periodically using the AWS Well-Architected review.

You can group different AWS resources in a workload to assess specific services. Create workloads to monitor and report on different parts of your Cloud Architecture. For example, a Production Workload that is comprised of all Production computing resources and regions, or a Dev-ops workload that contains only dev-ops computing resources and regions.

Click the link for information about How to Create a Workload

Viewing a Workload using the Workload Summary tab

From the Workloads tab, click on a workload to view detailed information.

The Workload Summary displays the information using charts.

Click the arrow on a chart to see details about that Resource type or click See All at the bottom of each chart.

Click an item in the key as seen below to remove it from the chart.

Click any section of a chart to view the complete list of that item on the Resources List page. Click an item in the bar to view information about that specific resource. You can also use the filters or search options on the top right of the list. These selections and available options will change based on the type of resource you view.

Workloads can be viewed in the following ways:

Click the Compliance Ops tab to change an AWS Lens or Compliance Framework associated with the Workload.

Compliance Ops tab

The Compliance Ops tab allows you to change your workload to select or remove additional Lenses and Compliance Frameworks. It contains the following sections:

Lenses Summary

Contains Assessment links and downloadable Reports associated with Lenses and Compliance Frameworks.

Integrated reports contain insights and assessments about the selected workload. It walks you through the process of creating and evaluating improvement plans and budgets to plan and track your monthly or yearly spend.

nOps WAFR (AWS Well-Architected) Report

Is created based on your answers to questions about the 6 AWS Well-Architected Framework, ‘pillars’. For more information about the pillars see: The Six Pillars of the Framework.

The report lets you review the state of your workloads and compares them to the latest AWS architectural best practices. The information is based on the AWS tools developed to help cloud architects build secure, high-performing, resilient, and efficient application infrastructure. To ensure compliance, Well Architected Reviews must be conducted on your production workload on a periodic basis. After the review, prioritize the remediation of any issues identified for you.

Foundational Technical Review Report

This report is based on the lens types selected by you and ensures that your cloud deployment meets the requirements of the lens/es.

Top Recommendations

When you create a workload nOps makes recommendations based on the workload priority, and provides details about what to Fix based on your answers. Click See Details for more information. Click Fix to upload the policy document (or enter a link) for remediation. Then click Upload & Fix to upload the document to the Compliance Documents data repository.

For example if you selected a WAFR (Well-architected framework) lens, nOps may recommend that you upload a reliability incident playbook. Note that creating a workload on an existing AWS account automatically selects the WAFR Review for you.

All AWS accounts should periodically undergo a WAFR review.

Compliance Documents

You can upload documents related to a Workload (or use drag and drop). nOps organizes these documents as you upload them. You can find them easily and in one place. The Compliance Documents repository allows you to track and maintain governance for your cloud environment.

See Also Links:

How to Create a Workload
How to add or change Resources in Workloads

How to Attach Documents to Workloads

Workloads in nOps help you to group different AWS resources that have been created within your AWS environment. This makes it easier to carry out various assessments on those specific services that make up with Workload. These are the steps to create a workload in nOps

Click on the Workload link on the top menu bar.

On the Workloads page or Dashboard, we will find already created workloads if they exist, and if there are no workloads the page will be blank.

Click on any of the workloads to view details and assessments under that workload

On the page, there are a section labeled Workload Attachments

Click the Upload a file button to pop-up the upload dialog box. Fill out the form with all the details needed.

Click the Choose file option to select the file to upload.

Click the Submit & Upload button to upload the file and submit the contents of the form.

This will take us to the Workload page with the resource that has been uploaded.

Describes the Workload Risk Summary

The Workload Summary displays an assessment toolbar that summarizes the associated risks.

The toolbar can be viewed by all users. Use the following path to see the toolbar. From the top menu bar or from the dashboard:
Click Workloads > Select a Workload from the list > Click the Compliance Ops tab > from the Lenses Summary dialog, click the Assessment button for any lens to see the Assessment page.

This topic contains:

Assessment Page and Toolbar Overview
Overview of Assessments

How Risk Levels are Assigned

The Section tabs

How to use the Interactive Assessment toolbar

Related Functionality for the Assessment Summary page

See Also Links

Assessment Page and Toolbar Overview

The Assessment page evaluates workloads against existing regulations or threat environment policies. Risk framework questions are based on best practices for compliance standards, and regulations for Security and Network. The toolbar displays:

• Risk levels: Unanswered, Medium, High and None and Not Applicable.
• The number of questions that fall under each risk.
• A graph for percentage of Assessment Completed.

Each assessment-type contains section tabs below the toolbar. The data in the section tabs changes when any risk-type is clicked. See Section Tabs for more information.

Overview of Assessments

Following is an overview of the different assessment types available through nOps and the pillars (for WAFR) or, section tabs that appear under different Assessment types. Each of the questions in the section tabs are assigned risk levels. Your answers to these impact compliance with Compliance Frameworks such as HIPAA.

How Risk Levels are Assigned

A risk level is assigned each time a question is answered, and is based on your selections. Each question has sub-questions. Some of which may have a higher risk value than others. Answering them could change the risk or threat level for that question. Ensure that you answer all questions correctly and to the best of your ability, since they impact the safety, security, and threats to your cloud account. Support your answers by uploading and storing documents to ensure compliance.

If any question is unanswered it is not flagged with a risk assessment. However any unanswered question may pose a greater risk, as the issues it covers are not mitigated in your environment. You can see which questions are unanswered for a specific section by clicking on the Unanswered section. See How to use the Interactive Assessment toolbar for more information.

The Not Applicable section in the toolbar displays a count, for any questions where you have enabled the Question does not apply to this workload toggle. Click the toggle only if the question is not applicable for the selected workload. The question is disabled and removed from the assessment. Removing a question excludes it from the Assessment Completed percentage. This will impact your overall risk levels.

The Section Tabs

Section tabs vary based on the type of assessment. Each tab contains its own set of questions, displays the number of questions in each, and how many of them are answered as seen in the following example.

See How to use the Interactive Assessment toolbar for more information.

How to use the Interactive Assessment toolbar

The Assessments toolbar is ‘clickable’. When a section is clicked, it changes color and displays which section tabs have a related issue.

In the following example, the Medium risk section was clicked, and shows that the Security assessment tab contains 1 question that was assigned a risk level of Medium.

Click through both the toolbar and the section tabs to see the changes within your workload.

Click a risk level, then click the section that contains the associated risk. The question will be highlighted as shown in the following example. Questions also display whether any answers were auto-discovered by nOps.

Related Functionality for the Assessment Summary page

• Click the Expand All /Collapse All button within each question to view question prompts. These may help you answer the question.
• Click the More (3 dot) menu to see additional functionality such as the ability to Attach a Document or Add a Label.
• Click the Export Report button at the top right to export a report-type available in the list.
• Click Exit Assessment to return to the Workload Summary page.

See Also Links:

How to Create Workloads

Viewing and Managing Workloads

Well-Architected Framework Review

Workloads API Documentation

API token generation Go to settings -> API Key menu item

Click “Generate API Key”

Copy the key you’ve have.

To use the nOps API, you will need to append your query string in the following manner: https://app.nops.io/nops_api/v1/some_endpoint/?api_key=<YOUR_API_KEY>

List workloads
/nops_api/v1/workload/?api_key=<API_KEY>

Get specific workload data (with answers data) by its ID: /nops_api/v1/workload/<WORKLOAD_ID>/?api_key=<API_KEY>

Get WA summary for a specific workload /nops_api/v1/workload/<WORKLOAD_ID>/rules_summary/?api_key=<API_KEY>

Get a budget for a specific workload /nops_api/v1/workload/<WORKLOAD_ID>/budget/?api_key=<API_KEY>

List attached resources for a specific workload /nops_api/v1/workload/<WORKLOAD_ID>/resources/?api_key=<API_KEY>

How to perform a WAFR with nOps

In this article you will learn how to perform a Well-Architected Framework Review (WAFR) with nOps. This article contains the following information:

1. Getting Started
2. Creating Your First Workload
3. Defining the Workload Query
4. Workload Summary View
5. Running the Well-Architected Framework Review (WAFR)
6. AWS Well-Architected Tool Integration
7. IAM Role Updates

Getting Started

AWS Well-Architected helps cloud architects build secure, high-performing, resilient, and efficient infrastructure for their applications and workloads. Based on five pillars — operational excellence, security, reliability, performance efficiency, and cost optimization — AWS Well-Architected provides a consistent approach for customers and partners to evaluate architectures and implement designs that can scale over time.

To get started, log in to your nOps account and switch to the Workloads > WAFR section. In the Workloads section, you can:

1. Create a new Workload.
2. Filter Workload based on the compliance framework.
3. Search Workloads based on the Workload name.
4. Edit or Delete a Workload.
5. Click on a Workload to go to its summary page.

Creating Your First Workload

To create a Workload, click the + Create New Workload button at the top-right corner of the screen:

When you click “ + Create New Workload” the workload creation panel will appear. Remember that the Workload name cannot be changed once it’s created:

In the Workload creation panel:

• Workload name — Create a unique identifier/name for your workload. A Workload name cannot be changed once it’s created.
• Review types — Selectthe type(s) of review/lens you want to apply on this Workload, for WAFR the review type must always be “Well-Architected Framework Review (WAFR)“.
• Compliance frameworks — Select the desired compliance framework — HIPAA, SOC2, or CIS.
• Create workload on your AWS account — Toggle this button to allows create and sync this workload in your AWS Well-Architected Tool. If you toggle this button:
  • A new field “AWS account to save WAFR progress” is added to the Create new Workload panel.
  • Well-Architected Framework Review (WAFR) is automatically selected in Review types field.
• AWS account to save WAFR progress — Select the AWS account your workload will be written to.
• AWS account to pull resources from — Select the AWS Account(s) where the resources for your workload live. All your AWS account associated with nOps will be shown in this list.
• Select Environment — This defaults to PRODUCTION and defines the environment from an AWS perspective. Note: Sanctioned Well-Architected Framework Reviews should always be performed on a production workload. You also have the option to create and select a custom environment.
• Description — A text description of your workload.

Once you’ve filled out the fields, click Save to create a Workload with all the resources in the AWS account specified in AWS account to pull resources from field.

To filter out the resources that are not required for WAFR, use the Specify Workload Resource section. To learn more about how to specify workload resources, see the next section.

Defining the Workload Query

After filling out the information, in the Create new Workload panel click the gray bar Specify Workload Resource to open a query builder:

The nOps query builder allows you to specify rules that define which resources will be added to the workload. You can change the default settings and specify the filters using the drop-downs:

In nOps query builder:

• Regions — Select the region(s) that nOps will pull resources from. This setting defaults to All.
• AWS Managed Services — Select the AWS service(s) that nOps will include in your workload. This setting defaults to All.
• Select Tag Name & Select Tag Value — Select the tags that are associate with the resources that you want to include. Only the resources with the selected tags will be included in the workload. When you select a tag in the Select Tag Name, the values list in the Select Tag Value will update according to the values of the selected tag name.
• + Add Another Tag — Allows you to add multiple tags.
• Note — Allows you to add a note against this filter.

Click “Save” to create your workload.

Workload Summary View

In the Workloads section, click on any Workload to go to its summary page. There are 3 tabs in the summary page:

• Diagram
• Summary
• Compliance Ops

When you click on a Workload, you will land on the Diagram tab of the summary page.

Diagram Tab

In the Diagram tab of the summary page, you will see the diagrams of your Workload resources segregated at the level of VPCs, regions, and subnets.

You can click on any VPC, region, subnet, or node to see its details. A summary of violations against your selection is shown on the right side of the diagram:

Summary

In the Summary tab, you have an overview of the your Workload:

In this page you will find:

• Resource Summary — In this section you will find the total number of resources, the number of resources with violation, the number of reserved instances, and the number of resources that are a part of AutoScaling in this Workload.
• Resource by Regions — Shows a donut chart with breakdown of all the regions where your resources belong to. You can hover over the chart to see how many resources you have in each region. You can also click on See All to see the full list of resources by region.
• Resource by Cloud Services — Shows a donut chart with breakdown of the cloud services to which your resource belong to. You can hover over the chart to see how many resources you have in each service. You can also click on See All to see the full list of resources by cloud services.
• Resource by Service Category — Provides a breakdown of resource by service category in the form of a bar chart with services on the Y-axis and the number of resources on the X-axis. You can also click on See All to see the full list of resources by service category.
• Tagged and Untagged Resources — In this section you will find the total number of tags used, tagged resources, and untagged resource in the Workload. This section also shows a bar chart with a breakdown of all the values against each tag. You can hover over the chart to see the values of each tag. You can also click on See All to see the full list of Tags and their values.

ComplianceOps

In the ComplinaceOps tab of the summary page, you will find the details of your assessment:

In this tab, you have:

• Lenses Summary — In the lenses summary you have the option to add/remove the review lenses and the compliance frameworks. In this section, you will see the assessments and reports according to your selection, along with the Assessment Completed percentage. If you change you selection, the assessments and reports will change accordingly. In this section you also have two buttons:
  • Assessment — Takes you to your assessment section. See Running the Well-Architected Framework Review (WAFR) to learn more.
  • View Report — Takes you to the assessment report page.
• Top Recommendations — Show you a list of top recommendation to resolve the violations.
• Compliance Documents — Show you the documents you attach to each recommendation in the Top Recommendations section.

Running the Well-Architected Framework Review (WAFR)

In this assessment section, you may notice that the assessment is at a completion percentage greater than 0%. This is because that nOps uses its rules engine to automatically discover information about the Workload and answers some the questions in the assessment:

Note: Each question specifies whether this is considered a High, Medium or Low risk question.

The assessment questioner is divided in to the 6 pillars of the WAFR assessment. To switch to a specific assessment pillar, click on the desired pillar:

Alongside the pillar name can also see how many question are answered and how many are still unanswered.

You can also click on the vulnerability levels to see exactly how many vulnerability are of the choose level:

For each question in the WAFR assessment, nOps will either automatically detect the answer to the question or allow you to answer it manually. Clicking on the checkbox(es) in each section will designate that your workload meets or exceeds the particular requirements. You can add notes to a particular question by clicking “Add Note.” Hover the mouse over a question to view a context menu that gives you several options.

• Autodiscovery Details – Information about what nOps was able to detect in your account.
• Attach Resources – Allows you to attach specific resources to a question. These resources will be included in the report generated by nOps.
• Create Jira Ticket – If you have integrated an instance of Jira Cloud, you can open Jira issues from nOps. Use this option to assign tasks while completing your WAFR.
• Show Description – Shows a description of the question.

To attach a Query to you answer as an evidence, click on the + Attach Query:

You can also click on the details icon to open a list of other options that you can use to enrich your answers:

After you have answered each question, if you are working on this assessment for the first time, you can click “Submit Report”. This will enable you to export the report to AWS as part of the WAFR. Click Export Report for and select the desired export format.

Clicking “Exit Assessment” will return you to the summary screen where you can upload any additional documentation, see the assessment completion percentage, and export the report of the assessment.

AWS Well-Architected Tool Integration

While creating you Workload in nOps, if you selected “Create workload on AWS account“, your Workload will be synchronized to the AWS Well-Architected Tool, each Workload in AWS will be listed as if you had created it from the tool itself.

Changes made from nOps can be synchronized to the AWS Well-Architected Tool by clicking Update Report.

IAM Role Updates

If you are using an existing nOps account, you will receive notifications that nOps has added new AWS IAM policies to enable AWS Well-Architected Tool integration. Please update your IAM policies to allow nOps to access the AWS Well-Architected Tool in your account. For more information, you can watch this short video.

Get notified about new AWS IAM policies on nOps – YouTube

View the WAFR for a User account or Client

How to view Well-Architected Framework Report

Log in to your nOps account

This will lead you to the landing page dashboard that shows a summary of different metrics.

Navigate to the main menu and to the Reports menu item. Click the menu item to view the list. Click the WAFR Report

This will lead to the WAFR Report report page showing the Well-Architected Framework Report page

Send a Workload that is still in progress to a PDF

How to Export a WAFR Report In Progress

When a Workload has been created, the WAFR Report when still in progress can be exported. These are the steps to export the report options selected when the assessment is still in progress.

Click on the Workload link on the top menu bar.

This will lead us to the Workloads page

Click on the particular workload that you need to export that is In Progress

1. This will open up the details page for the WAFR report, then click the Update Access button on the top right corner of the screen

This will open up the WAFR Assessment page

Click the Download Report Report button on the top left corner of the screen

Invite clients from the Partner Dashboard to sign up for nOps

How to Invite a Customer to complete a WAFR Assessment

1. Login to the nOps Partner Dashboard here
2. From the Dashboard click on Clients.
3. From the Settings pane, Click Manage Clients.
4. At the Manage Clients page click New Client and select Invite a client for a well-architected assessment.
5. Enter information about the customer on the Invitationdialog, then click the Invite client button to invite the customer.
   The customer receives an email containing a link to Sign Up.
6. The customer must click the Sign up now button, and enter information on the form to complete the Sign Up process.
   This will automatically log a new customer into their nOps account.

To Add an AWS Account

From the Partner pageSwitch to the user account page by clicking here.

To add an AWS account, to the customers nOps account, click on the +Add New AWS Account

Select the nOps Wizard Setup option, then click the Next button.

Enter a name to represent the AWS account within nOps, which is also called an nOps project, and the name of the S3 Bucket that has been created for the nOps account. Then click on Setup Account button

This will launch the CloudFormation Console in your AWS account, if you are logged-in it will direct you to the CloudFormation Console with the stack creation wizard.

Click the check box to acknowledge AWS Cloudformation will create IAM resources, then click on Create Stack to create the Cloudformation stack that is needed to link your AWS account to the nOps project.

The stack creation will take a couple of minutes. When it is complete. When the Cloudformation stack is completely created, you will get a notification email that the account is ready to be used.

The account is ready for a Well-Architected Framework Review.

Getting Started

For all AWS Partner-hosted solutions, passing the AWS Foundational Technical Review (FTR) requires you to complete an AWS Well-Architected Review (Review) to identify opportunities for improvement across all of the Well-Architected pillars.

You do not need to complete the remediation of identified issues to pass the FTR, only execute the Review. You can complete this assessment using either nOps or the AWS Well-Architected Tool accessible from the AWS Management Console.

PREPARATION CHECKLIST: Before you begin, you will need to gather the following:

• Access to the master payer account if you are using organizations.
• Permission to create and run an AWS CloudFormation stack.
• Permission to create AWS Identity and Access Management (IAM) roles in your account.
• Friendly account name.
• The name of an Amazon S3 bucket where your AWS Cost and Usage Reports (CURs) will be written. (We will create one if one does not exist.)
• CURs are enabled in the account.

To Get started Click Here

Signing Up for nOps

Step 1: Once you’ve clicked on the link above (nOps Sign Up), you’ll be taken to the FTR user registration page.

Complete the signup process by entering your business email, company name, etc. and clicking “Sign Up.” Doing so will cause a verification email to be sent to you — please click it to verify your email address. If you do not receive the verification email, please check your Spam folder.

Congrats! You are now registered as an nOps user.

Adding an AWS Account

Connect your AWS account(s) where the resources in your workload live.

*You will need to have access to the master payer account if you are using organizations. Additionally, you will need permissions to create and run a CloudFormation stack and create IAM roles in your account.

Click + Add AWS Account on the right.

Or, click on your username in the top right and go to: Settings > AWS Accounts Click “Add a new AWS account.”

nOps has two setup options:

• nOps Wizard Setup (recommended) – nOps will create a CloudFormation stack using your AWS credentials.
• Manual Setup – Used to reconfigure specific AWS accounts.

When adding a new AWS account, nOps will ask for the friendly name and the name of an S3 bucket where your CURs will be written. If you already have an S3 bucket for your CURs, you can add it here. Otherwise, nOps will attempt to create an S3 bucket.

Click “Setup Account” to be redirected to your AWS account.

*Please remember to log in to the AWS account that you want nOps to collect data from.

Agree to the CloudFormation template being able to create an IAM role and then click Create Stack.

Step 2 Once you have successfully added your AWS account to nOps, it will start the data ingestion process.

This process can take two to four hours, depending on the size of your AWS account. You should be able to see your AWS account in Settings > AWS Accounts > Active AWS Accounts.

AWS Accounts are now synced when this screen appears:

Workloads

A workload, in nOps, is a dynamic collection of AWS resources. Workloads allow you to group and manage only the resources that match a particular query. Click “Workloads” in the top nav bar to be taken to the Workloads view.

Creating Your First Workload

Step 3 If this is the first time you have created a workload, you will be able to click “Create New Workload” in the middle of the screen. After that, the Create New Workload button will move to the top right of the window.

When you click “Create New Workload,” the workload creation pane will slide into view.

• Workload Name – This is the unique identifier for your workload.
• AWS Account(s) – The AWS Account(s) where the resources for your workload live.
• Workload Type – Defines the overall workload type. Please select “Well-Architected.”
• Lens – nOps supports the AWS lens concept. Please select FTR for the lens type.
• Environment – This defaults to Production and defines the environment from an AWS perspective.
• Jira project – If you are using the built-in Jira integration, you will be able to select a Jira project to integrate with.
• Description – A text description of your workload.

*At this time, creating workloads in your AWS account is not fully functional. Clicking the option can cause errors in your workload creation.

Defining the Workload Query

Step 4 After you have filled out the metadata for your workload, you can click the gray bar that says, “Specify Workload Resource,” causing the query builder to slide into view. nOps allows you to specify rules that define which resources will be added to the workload.

• Regions – The regions that nOps will pull resources from. This defaults to All.
• AWS Managed Services – The AWS services that nOps will include in your workload. This defaults to All.
• VPC – The VPCs that contain the resources that nOps will include in your workload. This defaults to All.
• Tags – Select tags to be assigned to the resources you want to include, e.g., “ApplicationA.”

Click “Save” to create your workload.

Workload Summary View

Step 5 After you have created your workload, you will see the Workloads view. Here you can see a list of all workloads you’ve created, edit the query that builds your workload, and delete your workload.

Click on the workload to be taken to the Workload Summary view. In the Workload Summary view, you will see two sections.

Assessment Summary – An overview of how far into the assessment you are. – Workload Attachments – Any files and/or links attached to the workload are added to the report generated by nOps when the assessment is completed.

Running the FTR Assessment

You might notice that the assessment is at a completion percentage greater than 0. This is normal and due to the fact that nOps uses its rules engine to discover information about the workload automatically. Click “Start Assessment” to begin the FTR Assessment.

For each question in the FTR, nOps will either automatically detect the answer to the question or allow you to answer it manually. Clicking on the box(es) in each section will designate that your workload meets or exceeds the particular requirements. You can add notes to a particular question by clicking “Add Note.” Hovering the mouse over the question will raise a context menu that gives you several options.

• Autodiscovery Details – Information about what nOps was able to detect in your account.
• Attach Resources – Allows you to attach specific resources to a question. These resources will be included in the report generated by nOps.
• Create Jira Ticket – If you have integrated an instance of Jira Cloud, you will be able to open Jira issues from nOps. Use this option to assign tasks while completing your FTR.
• Show Description – Shows a description of the question.

After you have answered the question, you can click “Submit Report,” enabling you to export the report to AWS as part of the FTR. Clicking “Exit Assessment” will return you to the summary screen where you can upload any additional documentation, see the assessment completion percentage, and export the report of the assessment.

Submitting the Package to AWS

Step 6 Once you have completed the FTR Assessment, you will need to export your completed FTR Report and send it to your Partner Solutions Architect via email. You will also need to include the following information:

• A brief description of your solution.
• An architecture diagram illustrating major system components and their network communication paths (examples of reference architecture diagrams here).
• Is the solution currently generally available to customers?
• Is the solution in AWS GovCloud? If yes, what is the reason it is in AWS GovCloud?

Next Steps

nOps enables you to complete your FTR efficiently, but it can do far more than that. nOps lets you monitor, analyze, and manage an AWS Well-Architected infrastructure that is cost-optimized, secure, reliable, efficient, and operationally excellent — and help keep it that way through continuous compliance.

Click here to learn all you can do with nOps.

nOps is used by AWS partners in the ISV Program to get their FTR accreditation and access program benefits. This is a sample report.

The nOps FTR Report can be exported from nOps to be emailed by the ISV partner to their AWS representative to complete the FTR process and access ISV program benefits:

The nOps FTR Report gives you access to:

1. At-a-glance summary
2. List of attached AWS resources with $costs
3. 14 detail sections for the complete FTR process.

nOps FTR Report at-a-glance summary

nOps FTR attached AWS resources list

Note: The AWS ARNs for each AWS resource have been redacted.

nOps FTR Report detail sections

These are the sections that the ISV has to complete to pass the FTR process.

1. Support Level

2. AWS Well-Architected Review

3. AWS Root Account

4. AWS Accounts

5. Communications from AWS

6. CloudTrail

7. Identity and Access Management

8. Backups and Recovery

9. Disaster Recovery

10. Amazon S3 Bucket Access

11. Cross-Account Access

12. Sensitive Data

13. Protected Health Information

14. Regulatory Compliance Validation Process

Learn what each question in the FTR is describing

Foundational Technical Review Question Descriptions

The Foundational Technical Review (FTR) Lens provides a set of specific questions for independent software vendors (ISVs) to perform a workload assessment. To understand what the question is asking, below is a definition of each question in the FTR.

List of Questions and the descriptions:

1. Support Level

Enable AWS Business Support (or greater) on all production AWS accounts.

AWS Support provides a mix of tools and technology, people, and programs designed to proactively help you optimize performance, lower costs, and innovate faster. AWS Business Support provides additional benefits including access to AWS Trusted Advisor and AWS Personal Health Dashboard and faster response times. Subscribing to AWS Business Support or greater for all production accounts is a requirement to successfully complete the FTR. Business Support billing calculations are performed on a per-account basis. Monthly charges are based on each month’s AWS usage charges, subject to monthly minimum. For latest pricing information see Premium Support Pricing.

2. AWS Well-Architected Review

Conduct a Well-Architected Review with FTR Lens on the production workload on a periodic basis(minimum once every year).

The AWS Well-Architected Tool helps you review the state of your workloads and compares them to the latest AWS architectural best practices. The tool is based on the AWS Well-Architected Framework, developed to help cloud architects build secure, high-performing, resilient, and efficient application infrastructure. Well Architected Reviews must be conducted on the production workload on a periodic basis. After conducting the review, you should prioritize the remediation of any identified issues according to your business priorities. It is not a requirement to complete the remediation of any issues identified in the review other than the requirements defined in this checklist.

3. AWS Root Account

Use root user is only by exception.

The root user has unlimited access to your account and its resources, and using it only by exception helps protect your AWS resources. The AWS root user must not be used for everyday tasks, even administrative ones. Instead, adhere to the best practice of using the root user only to create your first AWS Identity and Access Management (IAM) user. Then securely lock away the root user credentials and use them to perform only a few account and service management tasks. To view the tasks that require you to sign in as the root user, see AWS Tasks That Require Root User. To learn more about FTR AWS root account protection and IAM configuration requirements, watch Baseline Bits: 03 AWS Root Account Protection and AWS Identity and Access Management Configuration.

Remove access keys for the root user.

Programmatic access to AWS APIs should never use the root user. It is best not to generate a static access key for the root user. If one already exists, you should transition any processes using that key to use temporary access keys from an AWS Identity and Access Management (IAM) role, or, if necessary, static access keys from an IAM user.

Enable multi-factor authentication (MFA) on root user.

If an account is not managed by AWS Organizations, enabling MFA provides an additional control for account sign-in. Because your root user can perform sensitive operations in your account, adding an additional layer of authentication helps you to better secure your account. Multiple types of MFA are available, including virtual MFA and hardware MFA. To learn more about FTR AWS root account protection and AWS Identity and Access Management configuration requirements, watch Baseline Bits: 03 AWS Root Account Protection and AWS Identity and Access Management Configuration.

Create an incident response (IR) runbook for root account credential misuse.

A runbook that details an appropriate response to root account credential misuse enables you to promptly act in the event that your root user becomes compromised. In the event your root account credentials are inaccessible, you will need to either change your AWS account root user password, or contact account and billing support through the Unable to Sign in & Submit Billing or Account Request page.

4. AWS accounts

Use separate accounts for production and non-production stages.

Multiple AWS accounts allow you to separate data and resources, and enable the use of Service Control Policies to implement guardrails. For example, users outside of your account do not have access to your resources by default. Similarly, the cost of AWS resources that you consume is allocated to your account. AWS recommends that you use multiple AWS Accounts to separate workloads and workload stages, such as production and non-production.

5. Communications from AWS

Configure AWS account contacts.

If an account is not managed by AWS Organizations , alternate account contacts help AWS get in contact with the appropriate personnel if needed. Configure the account’s alternate contacts to point to a group rather than an individual. For example, create separate email distribution lists for billing, operations, and security and configure these as Billing, Security, and Operations contacts in each active AWS account. This ensures that multiple people will receive AWS notifications and be able to respond, even if someone is on vacation, changes roles, or leaves the company.

Set account contact information including the root user email address to email addresses and phone numbers owned by your company.

Using company-owned email addresses and phone numbers for contact information enables you to access them even if the individuals whom they belong to are no longer with your organization.

6. CloudTrail

Configure CloudTrail in all AWS Accounts and in all Regions.

AWS CloudTrail enables governance, compliance, operational auditing, and risk auditing of your AWS account. To meet FTR requirements, you must have management events enabled for all AWS accounts and aggregate these logs into an Amazon Simple Storage Service (Amazon S3) bucket owned by a separate AWS account. The first copy of management events in each region is delivered free of charge and you only pay for S3 storage cost. Additional copies of management events will incur charges. Should you enable data events, you will incur charges for each copy along with associated S3 storage costs. For the latest pricing information see CloudTrail pricing. To learn more about FTR audit and logging requirements, watch Baseline Bits 05: Audit and Logging on AWS Accounts.

Store logs in a separate administrative domain with limited access (e.g. Separate AWS Account or an equivalent AWS Partner solution).

Configuring the logs to flow to a central account (i.e. separate AWS Account that is only intended for log storage and limited access ) or an equivalent AWS Partner solution protects the logs from manipulation or deletion. To learn more about FTR audit and logging requirements, watch Baseline Bits 05: Audit and Logging on AWS Accounts.

Protect log storage from unintended access (e.g. MFA-delete, versioning on S3, object lock, or an equivalent solution)

Protecting log storage locations from unintended access helps with avoiding any unintended changes to log files.

Enable CloudTrail log file integrity validation.

A validated log file using integrity validation enables you to assert positively that the log file itself has not changed, or that particular user credentials performed specific API activity. The CloudTrail log file integrity validation process also lets you know if a log file has been deleted or changed, or assert positively that no log files were delivered to your account during a given period of time. CloudTrail log file integrity validation uses industry-standard algorithms: SHA-256 for hashing and SHA-256 with RSA for digital signing. This makes it computationally unfeasible to modify, delete or forge CloudTrail log files without detection. For more information, see Enabling Validation and Validating Files.

7. Identity and Access Management

Enable multi-factor authentication for all Human Identities with AWS access.

You must require any human identities to authenticate using MFA before accessing your AWS accounts. Typically this means enabling MFA within your corporate identity provider. If you have existing legacy IAM users you must enable MFA for console access for those principals as well. Enabling MFA for IAM users provides an additional layer of security. With MFA, users have a device that generates a unique authentication code (a one-time password, or OTP). Users must provide both their normal credentials (user name and password) and the OTP. The MFA device can either be a special piece of hardware, or it can be a virtual device (for example, it can run in an app on a smartphone). To learn more about FTR IAM configuration requirements, watch Baseline Bits: 03 AWS Root Account Protection and AWS Identity and Access Management Configuration. Please note that Machine Identities do not require MFA.

Rotate credentials regularly.

When you cannot rely on temporary credentials and require long term credentials, rotate the IAM access keys regularly. If an access key is compromised without your knowledge, you limit how long the credentials can be used to access your resources. For information about rotating access keys for IAM users, see Rotating Access Keys. To learn more about FTR IAM configuration requirements, watch Baseline Bits: 03 AWS Root Account Protection and AWS Identity and Access Management Configuration.

Use strong password policy.

Enforce a strong password policy, and educate users to avoid common or re-used passwords. For IAM users, you can create a password policy for your account on the Account Settings page of the IAM console. You can use the password policy to define password requirements, such as minimum length, whether it requires non-alphabetic characters, and so on. For more information, see Setting an Account Password Policy for IAM Users. To learn more about FTR IAM configuration requirements, watch Baseline Bits: 03 AWS Root Account Protection and AWS Identity and Access Management Configuration.

Create individual identities (no shared credentials) for anyone who needs AWS access.

By creating individual identities for people accessing your account, you can give each user a unique set of security credentials and permissions. Individual users provide the ability to audit each users activity. To learn more about FTR IAM configuration requirements, watch Baseline Bits: 03 AWS Root Account Protection and AWS Identity and Access Management Configuration.

Use IAM roles and its temporary security credentials to provide access to third parties.

Do not provision IAM users and share those credentials with people outside of your organization. Any external services that need to make AWS API calls against your account (e.g. a monitoring solution that accesses your account’s AWS CloudWatch metrics) must use a cross-account role. See documentation on providing access to AWS accounts owned by third parties for more information.

Grant least privilege access.

You must follow the standard security advice of granting the least privilege. Grant only the access that identities require by allowing access to specific actions on specific AWS resources under specific conditions. Rely on groups and identity attributes to dynamically set permissions at scale, rather than defining permissions for individual users. For example, you can allow a group of developers access to manage only resources for their project. This way, when a developer is removed from the group, access for the developer is revoked everywhere that group was used for access control, without requiring any changes to the access policies. To learn more about FTR IAM configuration requirements, watch Baseline Bits: 03 AWS Root Account Protection and AWS Identity and Access Management Configuration.

Manage access based on life cycle.

Integrate access controls with operator and application lifecycle and your centralized federation provider and IAM. For example, remove a user’s access when they leave the organization or change roles

Audit identities quarterly.

Auditing the identities that are configured in your identity provider and IAM helps ensure that only authorized identities have access to your workload. For example, remove people that leave the organization, and remove cross-account roles that are no longer required. Have a process in place to periodically audit permissions to the services accessed by an IAM entity. This helps you identify the policies you need to modify to remove any unused permissions, see IAM access advisor.

Do not embed credentials in application code.

Ensure all credentials used by your applications (e.g. IAM access keys, database passwords, etc.) are never included in your application’s source code or committed to source control in any way.

Store secrets in specialized service.

Where you cannot use temporary credentials, such as tokens from AWS Security Token Service, storing your secrets, such as database passwords, using a service like AWS Secrets Manager or an equivalent AWS Partner solution, helps secure your credentials.

Encrypt all end user/customer credentials and hash passwords at rest.

If storing end user/customer credentials in a database that you manage, encrypt credentials at rest and hash passwords. As an alternative, AWS recommends using a user identity synchronization service, such as Amazon Cognito or an equivalent AWS Partner solution.

8. Backups and Recovery

Perform data backup automatically.

You must perform regular backups to a durable storage service. Backups ensure that you have the ability to recover from administrative, logical, or physical error scenarios. Configure backups to be taken automatically based on a periodic schedule, or by changes in the dataset. RDS instances, EBS volumes, DynamoDB tables, and S3 objects can all be configured for automatic backup. AWS Marketplace solutions or third-party solutions can also be used. To learn more about FTR backup and recovery requirements, watch Baseline Bits 07: Backups and Disaster Recovery.

Perform periodic recovery of the data to verify backup integrity and processes.

Validate that your backup process implementation meets your recovery time objectives (RTO) and recovery point objectives (RPO) by performing a recovery test both on a periodic basis and after making significant changes to your cloud environment. AWS provides resources to help you manage backup and restore of your data. To learn more about FTR backup and recovery requirements, watch Baseline Bits 07: Backups and Disaster Recovery.

9. Disaster Recovery

Define a Recovery Point Objective (RPO) according to your organizational needs.

Your data loss tolerance is the basis of your backup strategy and frequency. Recovery Point Objective (RPO) defines your data loss tolerance in-terms of time. Define a Recovery Point Objective (RPO) according to your organizational needs.

Establish a Recovery Time Objective (RTO) to meet business needs and expectations. This should be on the order of minutes for all components that are critical for providing service to your customers but should never exceed 24 hours.

Recovery Time Objective (RTO) defines your tolerance for downtime. The FTR requirement is for the RTO to be less than 24.

Test disaster recovery implementation to validate the implementation.

Test failover to DR to ensure that RTO and RPO are met, both periodically and after major updates. The DR test must include accidental data loss, instance, and Availability Zone (AZ) failures. At least one DR test that passes RTO and RPO requirements must be completed prior to FTR approval.

10. Amazon S3 Bucket Access

Review all Amazon S3 buckets to determine appropriate access levels.

You must ensure that buckets that require public access have been reviewed to determine if public read or write access is needed, and appropriate controls are in place to control public access. When using AWS, it’s best practice to restrict access to your resources to the people that absolutely need it (the principle of least privilege). To learn more about FTR S3 bucket access management requirements, watch Baseline Bits 06: S3 Bucket Access Management and Configuration.

Restrict access to S3 buckets that should not have public access.

You must ensure that buckets that should not allow public access are properly configured to prevent public access. By default, all S3 buckets are private, and can only be accessed by users that have been explicitly granted access. Most use cases won’t require broad-ranging public access to read files from your S3 buckets, unless you’re using S3 to host public assets (for example, to host images for use on a public website), and it’s best practice to never open access to the public. To learn more about FTR S3 bucket access management requirements, watch Baseline Bits 06: S3 Bucket Access Management and Configuration.

Implement monitoring and alerting to identify when S3 buckets become public.

You must have monitoring or alerting in place to identify when S3 buckets become public. Trusted Advisor checks for S3 buckets that have open access permissions. Bucket permissions that grant List access to everyone can result in higher than expected charges if objects in the bucket are listed by unintended users at a high frequency. Bucket permissions that grant Upload/Delete access to everyone create potential security vulnerabilities by allowing anyone to add, modify, or remove items in a bucket. The Trusted Advisor check examines explicit bucket permissions and associated bucket policies that might override the bucket permissions. You can also use AWS Config to monitor your S3 buckets for public access. For more information on using AWS Config to monitor S3, please take a look at this blog. To learn more about FTR S3 bucket access management requirements, watch Baseline Bits 06: S3 Bucket Access Management and Configuration.

11. Cross-Account Access

Use cross-account roles to access customer accounts.

Cross-account roles reduce the amount of sensitive information AWS Partners need to store for their customers. To learn more about FTR cross-account access requirements, watch Baseline Bits 04: Using AWS Identity and Access Management Roles for Cross-Account Access.

Provide guidance or an automated setup mechanism (e.g. AWS CloudFormation template) for creating cross-account role with minimum required privileges.

The policy created for cross-account access in customer accounts must follow the least privilege principle. The partner must provide a role policy document or an automated setup mechanism (e.g. an AWS CloudFormation template) for the customers to use to ensure that the roles are created with minimum required privileges.

Use external ID with cross-account roles to access customer accounts.

The external ID allows the user that is assuming the role to assert the circumstances in which they are operating. It also provides a way for the account owner to permit the role to be assumed only under specific circumstances. The primary function of the external ID is to address and prevent the confused deputy problem.

Use a value you generate (not something provided by the customer) for the external ID.

When configuring cross-account access using IAM roles, you must use a value you generate for the external ID, instead of one provided by the customer, to ensure the integrity of the cross account role configuration. A partner-generated external ID ensures that malicious parties cannot impersonate a customer’s configuration and enforces uniqueness and format consistency across all customers. If you are not generating an external ID today we recommend implementing a process that ensures a random unique value, such as a Universally Unique Identifier, is generated for the external ID that a customer would use to setup a cross account role.

Ensure all external IDs are unique.

The external IDs used must be unique across all customers. Re-using external IDs for different customers does not solve the confused deputy problem and runs the risk of customer A being able to view data of customer B by using the role ARN of customer B along with the external ID of customer B. To resolve this, we recommend implementing a process that ensures a random unique value, such as a Universally Unique Identifier, is generated for the external ID that a customer would use to setup a cross account role.

Provide read-only access to external ID to customers.

Customers must not be able to set or influence external IDs. When the external ID is editable, it is possible for one customer to impersonate the configuration of another. When the external ID is editable Customer A can create a cross account role setup using customer B’s role ARN and external id, granting customer A access to customer B’s data. Remediation of this item involves making the external ID a view only field ensuring that the external ID cannot be changed for purposes of impersonating the setup of another customer.

Deprecate any historical use of customer-provided IAM credentials.

If your application provides legacy support for the use of static IAM credentials for cross-account access, the application’s user interface and customer documentation must make it clear that this method is deprecated and the use of a cross-account IAM role is recommended. Existing customers should be encouraged to switch to cross-account role based-access, and collection of credentials should be disabled for new customers. To learn more about FTR cross-account access requirements, watch Baseline Bits 04: Using AWS Identity and Access Management Roles for Cross-Account Access

12. Sensitive Data

Identify sensitive data (e.g. Personally Identifiable Information (PII) and Protected Health Information (PHI)).

Data classification enables you to determine which data needs to be protected and how. Based on the workload and the data it processes, identify the data that is not common public knowledge.

Encrypt all sensitive data at rest.

Encryption maintains the confidentiality of sensitive data even when it gets stolen or the network through which it is transmitted becomes compromised.

Only use protocols with encryption when transmitting sensitive data.

Encryption maintains data confidentiality even when the network through which it is transmitted becomes compromised.

Log access to sensitive data comprehensively throughout the system

Visibility into any unexpected access to sensitive data provides you with the opportunity to perform necessary corrective actions to further protect your data. Scope your systems for components that store sensitive data. Implement application- and resource-level auditing and logging to monitor all access to data and quickly identify unauthorized access.

13. Protected Health Information

If the solution handles Protected Health Information (PHI), the partner must have a Business Associate Addendum (BAA) in place with AWS for every AWS account with PHI

Have a Business Associate Addendum (BAA) in place with AWS for every AWS account with Protected Health Information (PHI).

Only use services in the HIPAA Eligible Services Reference for solutions that handle PHI.

Solutions handling PHI must use services in the HIPAA Eligible Services Reference.

14. Regulatory Compliance Validation Process

Establish a process to ensure that all required compliance standards are met.

If you advertise that your product meets specific compliance standards, you must have an internal process for ensuring compliance. Examples of compliance standards include PCI DSS, FedRAMP, and HIPAA. Applicable compliance standards are determined by various factors, such as what types of data the solution stores or transmits and which geographic regions the solution supports.

If you’re participating in AWS’s Migration Assistance Program, you probably know that getting AWS credits for resources that you’ve migrated into AWS requires that you apply the right tags to those resources – and you want to apply those tags as early as possible in order to earn the credits as early as possible. nOps MAP features help automate this process, ensuring that you get the right tags applied to your resources as early as possible and get the maximum credit from the MAP program.

These MAP features can aid you if you’re a new AWS customer, just starting out with AWS and migrating your workloads into the AWS cloud, or an existing AWS customer moving workloads from on-prem data centers or from other cloud providers.

And note that qualifying for the credit also requires an AWS Well Architected Framework Review, so that you get the most from your cloud deployment – and that review is also facilitated by nOps tools.

nOps Automated Tagging for MAP-Program Credits

In order to get your AWS MAP credits, all your resources must be tagged according to the MAP rules. If your resources are not tagged properly, you won’t get the credits – and credits will only accrue on spends that occur after the tags are applied. nOps helps you to list the resources migrating for your various workloads, identify those that have yet to be tagged, apply the right tags, and then track your AWS incentive credits over the course of your migration. And in so doing, you’ll be setting up all your workloads for the required Well Architected Review, which nOps can also help you conduct.

To use the nOps MAP facitliy, from the nOps dashboard go to Workload > AWS MAP:

Defining Your Migration Projects

The nOps MAP facility starts with the page AWS MAP 2.0 Summary, where you’ll find three sections:

• QTD (Overall Migration Resource Spend Summary) – gives quarter to date total spending in AWS on migrated resources (tagged and untagged), untagged resources, and earned MAP credits.
• Your Current Tagging Status – shows the % of your migrated resources are tagged with map-migrated in order to get credits, and what % are untagged. It also shows the resource spend equivalent to the percentages.
• List of Migration Projects – shows projects that you’ve defined. Each project corresponds with a MAP Migration Contract from AWS and is identified by the project number in that contract, of the form MPExxxxx (where xxxxx are digits).

To create/add a MAP migration project in nOps, click + Create MAP Project at the upper right; it will bring up this dialog:

In the dialog, fill out the details:

• Project Name — Choose one that is meaningful to you.
• Project ID — The project ID starts with “MP” followed by 5 digits (MPExxxxx, where xxxxx are digits). If you are not sure where to find your MAP Project ID, refer to the top of the first page of your MAP contract.
• Start Date and End Date — They should be per your MAP contract terms from AWS.
• Tag Key — Prefilled for you.
• Server ID — Must be the exact server-ID string from AWS. If you do not already have an AWS server ID, click the blue Generate Server ID button, which will take you to the AWS facility for creating one – be sure and copy the ID that you create there in order to come back to this dialog and paste it into this Server ID field.
• Workload (optional) — As identified in nOps’ Well Architected Framework Review facility. You can select an existing workload that you’ve created in nOps or you can create a new workload for the MAP project. To create a new workload, click Create Workload, this will take you to the Workloads page in nOps. With workloads, you have the option to define a scope for where nOps should look for tagged and untagged resources.

Once you’ve entered all the details for this MAP project, click Create. The project you just created will show up in the List of Migration Projects on the AWS MAP 2.0 Summary page:

Every MAP project that you create this way in nOps will correspond to a MAP Migration Contract.

Note: Creating a migration project will not tag the resources of that project. To tag resources, continue to the next section, “Tagging Resources”.

Tagging Resources Within Each Project to Earn MAP Credits

nOps provides an easy automated way for you to tag any untagged resources.

Once your MAP migration projects are defined, each with its associated resources via the server ID, nOps will show you all the AWS resources associated with the servers you have identified for the migration projects. As more and more resources from the servers/storage units are added, you will periodically come back to nOps to tag all untagged resources.

To tag resources of a project:

1. Click ➡️ in the Action column of the List of Migration Projects section:
   This will take you to the Migration Details of the migration project.
2. Scroll down to the List of resources section. This list contains all the resources associated with the migration project:
3. Select the resource(s) you want to tag, and click + Add Migration Tag and then + Tag Now:
4. Click Yes:

Note:

Once you click Yes, nOps will redirect you to AWS, where you will tag the selected resources. nOps will pre-fill Tag Key, Tag Value, and ARN, which is some of the information required to tag the selected resource.

To successfully tag a resource in AWS, you (the customer) will need two permissions from your AWS Admin – permission for the selected resources and the permission to tag resources.

Managing Your Migration Projects

Once you’ve defined one or more migration projects in nOps, you will see each of those projects listed at the bottom of the AWS MAP 2.0 Summary page where you started:

You can access and manage any migration project by clicking the ➡️ button in the Action column of the List of Migration Projects section.

In the AWS MAP 2.0 Summary page you will also find a collective summary of all of your migration projects in the form of:

• Overall Migration Resource Spend Summary — Shows quarter to date (QTD) migrated resource spend, untagged resource spend, and estimated credit.
• Your Current Tagging Status — Shows a bar chart for how much of your spending has been tagged and how much remains untagged in the current QTD, across all of your migration projects.

Note: Once a quarter ends and the next one starts, you can still tag the untagged resources from the previous quarter but the previous quarter’s cost will not change.

Navigate and Track Your Incentive Credits

In the AWS MAP 2.0 Summary page, again note the arrow at the right of each migration project line, in the Action column. Clicking that arrow brings up the details of that migration project:

The details page shows the performance of a specific migration project, and it is divided into four distinct sections. At the top of the details page you will see the Migration ID, Start Date, End Date, Tag Key, Server ID, and Workload associated with the migration project you just clicked:

The next three sections are all about navigating your incentive credits, tracking your tagging status, and tagging untagged resources:

• MAP Tracker
• Your Current Tagging Status
• List of Resources

MAP Tracker

MAP Tracker offers a way for you to find the scope of your project and navigate your incentive credits over the entire period of your migration, with the help of:

• MAP Spend: Total Spend/Cost excluding CUR line-item types Tax, Credit, and Refunds.
• Trailing Twelve Month (TTM) MAP Spend: Sum of MAP spend in the existing quarter and the previous three quarters.
• General Spend Growth: Refer to the MAP Credit Calculations section of your AWS MAP plan.
• Multiply by 25%: 25% delta value of General Spend Growth.
• Earned MAP Incentives: Credits that you have earned from AWS with the MAP plan.
• MAP Credits Disbursed: Credits that you have received from AWS. You only receive your earned credits in the month after a quarter ends.
• Cumulative MAP Credits Disbursed: Cumulative sum of all past quarters and the current quarter (-) MAP credits disbursed.

Current Tagging Status

This section is similar to the Current Tagging Status of the AWS MAP 2.0 Summary page, which summarizes the tagging status of all your migration projects.

The Current Tagging Status on this details page shows the tagging status for only this specific migration project. It shows a bar chart for how much of your spending has been credited against tagged resources, and how much remains against untagged resources, in the current QTD, for this specific migration project.

List of Resources

This section shows all the resources, tagged or untagged, within the migration project. You can filter the resources based on the account associated with the resource and the tagging status (tagged, untagged) of the resource. You also have the option to search any specific service with the help of the search box at the top right of the list.

To tag untagged resources, select the untagged resources and click the + Add Migration Tag button. To learn more about the process in detail, see the Tagging Resources Within Each Project to Earn MAP Credits section of this article.

The resource table gives:

• Service Name — AWS service that contains the resources.
• Resource Name — Resource associated with the AWS service.
• Account — The AWS account associated with the resource.
• Region — Region of the resource.
• QTD Cost — Quarter to date cost of the resource.
• Action — Click the Action to see the Details, Cost History, and Config History of the resource.

The resource table will update periodically as more resources are added. Continue visiting the List of Resources section to tag all newly added untagged resources for the duration of the migration project.

Note:

Once you tag an untagged resource, it will take approximately one hour for the change to reflect in nOps.

You can select multiple resources and tag, then click on the + Add Migration Tag button to tag them in one go. For resources that belong to different accounts, nOps will present them grouped by account, and you can tag resources for one account at a time.

Troubleshooting

Matching Spend and Credit Numbers with AWS

What to do if numbers don’t match what see in AWS:

– Check dates of tagging vs Amazon

– Put in past dates for tagging when not tagged till later in AWS

– Vs Tag Explorer, which assumes the resource had the tag for the history of its life

AWS Logins for Generating Server ID and for Tagging Resources

What to do if you don’t have the permissions to tag your migration project resources:

• Ask your AWS admin to grant you permissions.
• Check if you have the permissions for the resource that you are trying to tag.

Query your cloud resources directly from the nOps platform.

nOps provides an easy and automated method for you to query your cloud resources directly from the nOps platform with the help of nOps Data Explorer powered by GraphQL.

The nOps Data Explorer is divided into:

• Query Explorer
• Query Builder
• Query Output
• Data Explorer Actions

Query Explorer

In the nOps Data Explorer panel, nOps constantly refreshes the cloud resources so that you have access to the current state of your environment.

As you expand the resources, you’ll see that you can filter using a simple clickable interface that will build the query interactively — retrieve the exact configuration elements about your resources, and use simple SQL type logic to filter the results.

We’ve also mapped the related resources in the nOps relationship graph. As you expand, you’ll see additional data sources for related resources. This allows you to ask questions like “Find all of the EC2 instances in a specific VPC with Auto Scaling enabled”.

Add New Query/Subscription

With the Query selection, you can add multiple queries in the same request.

Like queries, subscriptions enable you to fetch data. Unlike queries, subscriptions are long-lasting operations that can change their result over time. They can maintain an active connection to your GraphQL server (most commonly via WebSocket), enabling the server to push updates to the subscription’s result.

Subscriptions are useful for notifying your client in real time about changes to back-end data, such as the creation of a new object or updates to an important field.

Query Builder

As you interact with the Data Explorer, you’ll see your query dynamically generated in the Query Builder tab. Once you become a GraphQL ninja, you can also edit directly in this interface.

If you write a query directly into the Query Builder, simply click the Prettify button to automatically format the query and mitigate any flaws in the indentation.

To run a query, click the Play button. The output of your query will be shown in the Query Output tab.

Query Variables

Variables simplify GraphQL queries and mutations by letting you pass data separately. A GraphQL request can be split into two sections: one for the query or mutation, and another for variables.

Request Headers

Use Request Headersto send custom headers with the query.

Query Output

The Query Output tab will present your query results. They’ll be presented in an easy-to-consume JSON format. As you add more filters to your query and select the exact resource attributes that you’d like to retrieve, your result set will give you access to the precise data that you’re searching for.

To see the query output in a formatted table format, click the Table View button.

If there are errors in the syntax of the query, the Query Output tab will show an error message.

Data Explorer Actions

Data Explorer actions support the entire exploring process. With Data Explorer actions you can:

• Execute Query: After building your query you can click on the run query button to see results.
• Prettify Query: Formats the queries that you manually created to a visually presentable form.
• Toggle Explorer: Hide or show the Query Explorer to get more screen space for writing queries and reading the query output.
• Save Query: Save your queries as Public or Private.
• My Queries: Access saved queries.
• History: See the history of all the queries you’ve made.
• Table View: See the query output in a formatted table format.
• Documentation Explorer: Access the GraphQL Schema documentation right here in the Data Explorer.

Save Query

With the Save Query button, you will be able to perform actions on your created queries. You can save your queries as Public and Private.

My Queries

My Queries will open a panel where you can access all the queries that you have saved and those shared by your colleagues. In addition, you’ll be able to favorite, archive, and delete to keep them organized.

Code Exporter

Once you’ve created a query that returns a meaningful set of resources –like looking for unencrypted S3 buckets– you’ll likely want to integrate with your CI/CD or monitoring system so that you can continuously monitor for matches. The Code Exporter will generate Python and Javascript code that can be easily integrated into your engineering systems.

Documentation Explorer

With the Documentation Explorer, you can access the GraphQL Schema documentation right here in the Data Explorer while creating your queries.

Sample Data Explorer Queries

Following are a few sample queries that you can use to get data for your own cloud resources using nOps Data Explorer:

ShareSave provides risk-free Auto-pilot EC2, RDS, ElasticCache, OpenSearch, and Redshift Reserved Instances Management.

ShareSave provides risk-free Auto-pilot EC2, RDS, ElasticCache, OpenSearch, and Redshift Reserved Instances Management.

ShareSave is ideal for organizations that are growing rapidly and are having difficulties keeping track of everything ranging from server side, CMS stack, API stack, analytics, to linear playout engine.

ShareSave is also ideal for organizations that, during their rapid expansion, over-buy reserved instances at an alarming rate to keep up with the demands and it is now difficult for them to wind down after everything settles. ShareSave can not only help during their expansion but also helps save a substantial percentage on monthly AWS costs with the help of ShareSave RI management, ShareSave Scheduler, and ShareSave Graviton programs.

ShareSave Automations

The following is the list of cost-saving automation under ShareSave:

• Risk-Free Commitment
• Graviton
• Resource Scheduler
• Auto Scaling Groups
• Amazon Relational Database Service

Risk-Free Commitment

Real-time, risk-free, hands-free automatic life-cycle management of Amazon EC2 and RDS commitments.

The ShareSave AI engine collects Amazon CloudWatch and AWS CloudTrail logs and continuously monitors and analyzes infrastructure usage data points. It then automatically reacts in real time by purchasing RIs upon an increase in compute usage and selling RIs upon a decrease in compute usage. nOps continuously purchases and sells commitments on an hourly basis, depending on your infrastructure’s capacity changes.

ShareSave grabs the most lucrative discounts in the Amazon EC2 Reserved Instance Marketplace.

Graviton

Switching workloads to AWS Graviton-based instances that provide the best price-performance for workloads in Amazon EC2.

Resource Scheduler

nOps ShareSave Resource Scheduler makes it easy to pause resources during inactivity and leverages the Amazon EventBridge bus to deliver signals to resources to stop them during inactivity and restart them when they are most likely to be used automatically.

Auto Scaling Groups

A data-driven approach to recommending new autoscaling configurations and real-time optimization opportunities based on your actual usage:

• Determine your group’s idle resources using statistical analysis based on the group’s utilization data.

• Reconfigure your autoscaling group based on actual usage.
• The most optimal personalized configuration based on your historical utilization data.
• Keep only the amount of resources you need.

Low and no code, one-click automation built into every recommendation you see.

Amazon Relational Database Service

The RDS recommendations clearly describe the optimization approach you should take and shows the recommendations to implement.

nOps looks at the utilization metrics and determines time periods when RDS instances are running but are inactive. The insights that nOps gather from your utilization partners turn into scheduling recommendations that you can implement to immediately start savings and reducing your spend.

ShareSave Dashboard

The Sharesave Dashboard provides clear visibility of the potential savings that can be achieved using the nOps Platform. The ShareSave program is able to process 6 months’ worth of data.

nOps continually refines its savings recommendations and strives to take ShareSave to absolute perfection.

The ShareSave Dashboard consists of three sections:

1. Savings Summary and Breakdown
2. List of Opportunities
3. Filter

Savings Summary and Breakdown

In the Savings Summary, you will find:

• Lost Opportunities — Money you could have saved, if you had signed up for nOps ShareSave, in the last 60 days.
• Estimated Total Saving — Estimated saving nOps ShareSave for the specified time period (MTD, 7 Days, 30 Days, 60 Days, 90 Days).
• Estimated Total ShareSave Fee — What we will charge for saving your money.
• Estimated NET Savings — What you Save after paying nOps.
• Net Savings % — The percentage of costs that you saved vs on-demand
• Estimated Annualized Net Savings — What you will save in a year with ShareSave (Estimated savings vs on-demand with ShareSave).

You can also select the following tabs within the Saving Summary and Breakdown section to see a graphical representation and breakdown of your savings with respect to date and opportunity type:

• Total Savings
• Total ShareSave Fee
• Net Savings
• Annualized Net Savings

List of Opportunities

The List of Opportunities section consists of the following list:

• List of Risk-Free Commitments
• List of Graviton
• Resource Scheduler
• Auto Scaling Groups
• Amazon Relational Database Service

List of Risk-Free Commitments

Actions against the List of Risk-Free Commitments are automatic and are carried out by the nOps ShareSave AI.

In the List of Risk-Free Commitment, click on an opportunity name to expand the list and see the details including resource name, account name, region, previous configuration, suggested configuration, detection date, total savings, and action:

List of Graviton

In the List of Graviton, click on an opportunity name to expand the list and see the details including resource name, region, previous configuration, suggested new configuration, detection date, and total savings:

Resource Scheduler

In Resource Scheduler, click on an opportunity name to expand the list and see the details including instance type, account name, region, schedule name, new configuration, confidence level, total saving, and action:

Click on the Schedule button against an opportunity to create an automated schedule to turn the instance on and off with the help of EventBridge. To learn more about the Resource Scheduler, see Utilize nOps Resource Scheduler with EventBridge Integration to Reduce Costs Automatically.

Auto Scaling Groups

In the Auto Scaling Groups, click on an opportunity name to expand the list and see the details including instance type, account name, current configuration, recommended one-time configuration, recommended dynamic configuration, scheduling status, one-time configuration savings, dynamic configuration savings, and action:

Click on the Schedule button in the Action column against the opportunity for the Autoscaling Group that you want to schedule. This will open up a list with two options: Create One-Time Configuration and Create Dynamic Configuration. Select your desired configuration.

If you select Create One-Time Configuration, you will see the one-time configuration screen. Populate the fields and click Create to create the schedule:

If you select Create Dynamic Configuration, you will see the dynamic configuration screen. Populate the fields and click Create to create the schedule:

Amazon Relational Database Service

In the Amazon Relational Database Service, click on an opportunity name to expand the list and see the details including resource name, RDS type, instance size, account name, region, current schedule, recommended schedule, total savings, and action:

Click on any opportunity name to see the details of the resource and its usage pattern:

To schedule a recommendation, click the Schedule button against the recommendation. If you click the Schedule button, you will see two options:

• Create New Schedule
• Attach Existing Schedule

To create a new schedule, based on the nOps recommendation, click Create New Schedule, all fields will be prepopulated according to the recommendation. Simply click Create to start reducing your spend:

To attach an existing schedule to the RDS resource(s), click the Attach Existing Schedule button, select an existing schedule from the dropdown list, and click Attach.

Filters

Use the Filter section, to apply filters on the entire ShareSave dashboard based on the selected cloud accounts and opportunity types:

Prerequisites

You must have access to your AWS Master Payer Account ID. With this ID, we will be able to generate a $5 Market Place Private Offer (MPPO) and send it over to you. It’s very easy to accept the offer and onboard an account.

nOps recommends that you link your AWS accounts to nOps with Automatic Setup. If you are an advanced AWS user and have specific requirements, you can also link your account to nOps with Manual Setup, Multi-Account Setup with Terraform, and Multi-Account Setup with CloudFormation.

If you are an existing nOps customer, in order to get access to all the cost saving features of ShareSave, you might need to update the IAM permissions for nOps. To update the IAM permissions:

1. Log into your nOps account.
2. Click on your profile name in the top right corner.
3. Navigate to the IAM Policy Update section. You will see a list of your AWS accounts associated with nOps.
4. Click the Update on AWS button against your master payer account. Make sure that you are already logged in to your master payer account before you click the button.
5. Click the Update on AWS button against all associated accounts. Make sure that you are already logged in to the respective AWS account before you click the button (optional).

ShareSave Configuration

In the scope of this document, we will go through the configuration of ShareSave – List of Risk-Free Commitments.

To learn about ShareSave – Resource Scheduler and its configuration, see Utilize nOps Resource Scheduler with EventBridge Integration to Reduce Costs Automatically. To learn about the ShareSave – List of Graviton and its configuration, see Graviton.

To configure ShareSave – List of Risk-free Commitment, follow these steps:

1. Log in to your nOps environment and head over to the ShareSave dashboard:
2. On the ShareSave dashboard, in the List of Opportunities section, click the Configure Risk Free Commitment button:
   1. If your account has already been configured, you won’t see the Configure Risk Free Commitment button. The button is only visible to new customers and existing customers who haven’t configured ShareSave yet.
   2. Risk Free Commitments are only available to customers that onboard a Master Payer Account. You will not see the button if you haven’t onboarded a Master Payer account.
3. Once you click the Configure Risk Free Commitment button, the following pop-up will appear:
   1. If the pop-up does not appear, make sure that the pop-up isn’t being blocked by your browser.
   2. Before you click Proceed, make sure that you’re logged in to your AWS master account in the same browser.
4. After you click Proceed, nOps will take you to your AWS console’s CloudFormation Quick create stack page —with all the required information pre-filled— in order to create the required Cost and Usage Report (CUR). Acknowledge and click Create stack:

ShareSave – List of Risk-Free Commitments configuration is now complete.

Note: It will take upto 24 hours for the data to populate in nOps.

Under Construction

A group of highly intellectual Technical Writers are doing their best to keep up with equally intellectual Developers.

Developers outnumber us 30 to 1. We are doing our best. Give us some slack. Contact the nOps Support team in the meantime.

Add a new user to nOps

Adding users to nOps

One can subscribe nOps from AWS Marketplace or using payment gateway integrated within nOps.

You can signup using link.

The first user who signup for nOps by default has the Admin rights for the nOps account.

This admin user can add additional users to the nOps account by following these steps below.

Go to Settings from top-right user avatar drop-down.

Click on the Team Members on the side bar. Then click on Invite New Member to add additional team members.

Then type the team member’s email id which you want to invite to nOps. You can select a role which is either “Member” or “Admin user”.

Once you add the email and click on Send Invite message below will be shown in the browser.

The user whose email id is added will receive an invite from nOps which will be like below.

The user can set up his account entering the details as per below screen

How to add another user to your partner account

Adding a User to a Partner Account

Easily add new user to access the partner account.

Recommended for partner employees only or contractors.

Go to Settings>Partner User

Click +Invite New User

Enter their email and select the role the user should be and Invite

How to add a client to your partner account

Adding a Client on the Partner Account

To add a client to the partner account:

Go to Settings:

Select on Clients on the left.

On the top right click on +New Client

Now select how the client should be invited:

Create a new client – Add the clients name and then go to their account to finish setup. It will bring you to a page to add their AWS account to start retrieving the account data.

Add the AWS account. There is an option to add additional users to this account. Here you can add the client to the nOps account for their AWS account only.

Invite a client for well-architected assessment – This will send an email to the client to have them add their AWS Account for the well-architected assessment. The email body can be customized or use the default message.

AWS account data will take 2-4 hours to load into the nOps account.

Using the Notification center for Cost Changes, nOps Rules, Security, SOC2 Readiness, HIPAA Readiness Report, and CIS Readiness Report

How to use the Notifications Center

The Notifications Center enables alerts of changes within your AWS accounts. The alerts will be sent to an email and/or Slack channel. Set alerts for the following; Cost Changes, nOps Rules, Security, SOC2 Readiness Report, HIPAA Readiness Report, CIS Readiness Report

On the main dashboard, click on the name of the logged-in user and click the Settings menu item to go to the settings page

On the settings page, click on the Notifications Center menu item on the left-hand side of the screen.

In the Notifications Center, you can configure different notifications based on Cost Changes, nOps Rules, Security, SOC2 Readiness Report, HIPAA Readiness Report, CIS Readiness Report

Example email for Cost Control:

How to disable Notification for a user

To delete a user from getting a notification to take the following steps

Log in to your nOps account

On the top left corner of the dashboard, where the name of the user is currently logged in; click on the arrow to reveal the drop-down menu. Click on the Settings menu item

This will lead to the nOps notifications page that shows a list of different notification configurations

Click the specific user you want to disable notification for a user from. For this example, we will be using the Cost Changes tab. Under Users who you want to Notify (optional)

Click the X next to the email that should be removed from receiving notifications. Next, go through each section to make sure they are not listed on the other tabs (Cost Changes, nOps Rules, Security Dashboard, SOC2 Readiness Report, HIPAA Readiness Report, CIS Readiness Report)

Click Update Preferences.

Change your nOps password

How to Change nOps Password

Navigate to the top left corner menu that displays the name of the user that is logged in. Click on the menu and click on Settings menu item

On the Settings page, navigate to the left-hand side and click on the Change Password menu item.

This will lead to the Change Password page

Enter your old password and New Password, and the new password again to confirm, then click the Change password button to save the new password

Find out how to reset a forgotten password

How Recover a lost password

Visit the nOps Sign in page on apps.nops.io

On the Sign In page navigate to the Forgot Password link and click it.

This will lead to the Password Reset page. On the page, enter your nOps registered email in the box, and click the “Reset My Password” button to recover/reset your password.

Learn how to toggle between AWS Accounts

How to switch between different AWS accounts

nOps is designed to allow the integration of multiple AWS accounts. This makes nOps more robust to help analyze more than one AWS account. This analysis is done in one account at a time and we will show how to switch between different AWS accounts:

Navigate to the top left corner of the screen where the name of the user currently is logged into. Click on the name of the currently logged-in user. On the drop-down menu, there is a menu item called “Switch Account”

Move the mouse over to the “Switch Account” option to view a list of AWS accounts that you can switch to

Click on the specific account you wish to switch to based on the list of AWS accounts displayed.

This will switch to the selected account.

How nOps remove data from an account

How nOps purges data

The data purge policy describes how we purge data after you delete an account and how we remove data.

Delete account from nOps

• A client admin will be able to delete AWS account on nOps settings page.
• When the admin clicks on delete account in nOps, the account will be scheduled for deletion within 30 days.

When the account deletion queue task is executed:

• Deletes all data fetched from AWS API.
• Deletes all cost data ingested to nOps.
• Keeps user login (email address and password which is used to login to nOps system)

Marketplace subscription:

• Delete AWS account in nOps wouldn’t change the status of Marketplace Subscription.
• Customer should go to AWS console in order to unsubscribe nOps https://console.aws.amazon.com/marketplace/home

Delete client from nOps partner portal

• A partner admin can delete their client in the nOps partner portal client settings page.
• When the admin clicks on delete client in nOps, the client will be scheduled for deletion within 30 days.

When the client deletion queue task is executed, it would:

• Deletes all data fetched from AWS API.
• Deletes all cost data ingested to nOps.
• Deletes client from the list of clients.
• Keeps the invoice generated for that client.
• Delete all Personally Identifiable Information associated with the client, including e-mail addresses, user names, and any other PII.:

For more information on our Privacy Policy please visit here: nOps Privacy Policy

These are the steps to add a new customer billing type:

Log in to the nOps Partner Dashboard here

Click on the Settings Icon on the top-right corner of the screen.

On the Settings page, there is a side menu with options such as Clients, Partner User, Company Profile, Billing Accounts.

Click on Clients

On the Partner Clients page, click on the New Client button on the top-right corner of the page.

On the dialog box, you can enter the client name in the text box and select the billing options, which are two options Full Access or Well-Architected Review Access . Select the specific billing option you would prefer to use for the client.

Click the Create Client button to create the client with the specific billing option.

Partner Dashboard for Invoicing clients

How to Invoice for Clients

nOps Partner Dashboard has an intuitive interface that makes it easy to generate invoices for clients. Here are the simple steps to do that

Move the mouse to the top bar that contains the name of the logged-in user. On the drop-down that displays and click on the Partner Dashboard menu item.

This will lead us to the Partner Dashboard home page.

On the Partner Dashboard, go to the top menu bar and click on the Billing menu item.

Select Customer Invoicing, this will show the Customers List page. Each customer item has an arrow link, click on the arrow link.

Click on the arrow to see all the invoices for the customer.

This will open up the different invoices for the customer.

On the customer invoice page, go to the Action column and click the print icon on the specific invoice you wish to download or view the detail of the invoice.

This will download the PDF version of the invoice.

How to use Chargeback Center to shift-left cost optimization and make your users cost accountable for the cloud they use

Chargeback Center

Overview:

Using the Chargeback Center brings visibility and accountability to AWS cloud cost. tie cloud resources to teams and attach chargeback features to them. The larger the number of AWS accounts you have the bigger this problem becomes. This also gives teams a handle on their own budgets and uncontrolled cloud budget spend.

The Chargeback Center does not create invoices. It will help visualize spend for business units, teams, and billing.

How to use Chargeback Center:

Go to Cost Control>Chargeback Center

The Chargeback Center is your dashboard for the chargeback “perspectives” that you can create. You can create as many buckets as you wish to represent different perspectives which can be multiple workloads for different teams.

Creating a new Chargeback by clicking on Create New Chargeback then just complete the simple pop-up form.

On the pop-up fill out the following fields:

Chargeback Name – Enter a name for the Chargeback that makes sense to your organization. If it’s a team, project or person then use a combination of identifiers like “Developer-UX-Project5-Staging”

Chargeback Type:

• Predefined – Use the default labels provided; Business Unit, Team, or Billing. These are just text labels that make sense to you and don’t modify how nOps works.
• Custom – Create your own label if the Predefined Labels don’t cover your use case.

Set Monthly Budget Limit – Create a budget for the Chargeback. And, select if an email should be sent if the budget is over the spend.

Filters:

• AWS Managed Services – The AWS services that nOps will include in your workload. This defaults to All.
• VPC – The VPCs that contain the resources that nOps will include in your workload. This defaults to All.
• Tags – Select tags to be assigned to the resources you want to include, e.g., “ApplicationA.”

Click Save

There’s an option to Favorite this Chargeback for easier filtering by clicking the star in the top right.

Click See chargeback details

• You will see the spend and difference over the months broken down on this page.
• Download the chargeback as an invoice.
• Track if the chargeback has been; sent, paid, or unpaid.

Other things you can do with nOps chargeback:

• You can go from AWS Region and accounts down to the granularity of AWS tags to allocate resources to the chargeback bucket.
• You get a dashboard for that chargeback and you get notifications.
• You can set the period to monthly, quarterly, or annually.
• You can see underspend and overspend.
• You can see the history and mark overspend as paid or not.

Granular costs to your EKS, pods, and services.

How to view the cost of Kubernetes Pod and Service (Container Cost)

nOps is designed to help give granular costs to your EKS pods, and services. To view the cost of your EKS resources, use the following steps:

1. Click Cost Control on the top menu and select Container Cost from the list.
2. The dashboard contains a graph, that shows daily container cost. Scroll down to see a list of EKS clusters that have been created within the AWS account. This list shows the cost of each EKS cluster per day:
3. The EKS clusters are shown in the EKS Clusters List. From here you can view detailed costs for components in this Kubernetes cluster. Such as the cost for each Worker Node (EC2 Instance), Services, and Pods. Click on an EKS cluster for more details. From our screenshot, we will click on ys-addon-po-s cluster.
4. This will provide details about the Services, Nodes (EC2 Instances), and Pods within the cluster:

How to use this data

The instances in the cluster are listed with a status. If you see instances in the cluster that are inactive you may want to consider deleting them if they are unused in order to save costs. Any data contained in these clusters can be archived or moved to another resource/resource type.

This guide is for AWS Consulting Partners that are using nOps to manage consolidated billing and invoicing for multiple clients.

Consolidated Billing for AWS Partners

AWS Consulting Partners can grow their AWS practice by adding a service to manage billing and invoicing on behalf of their AWS customer clients.

For example, an AWS customer that already works with an AWS partner to benefit from their technical expertise is often willing to extend this to benefit from help understanding and managing their billing. As their AWS footprint grows, so does the complexity of their billing and this can become a large, regular monthly effort to keep on top of costs.

An AWS partner that uses nOps can introduce the benefits of consolidated billing to ease the burden of billing and work together to further reduce their cloud bill with intelligence management of costs and discounts.

This guide has been written for AWS partners so they can understand the simple end-to-end process of adding new clients to their nOps system.

• Introduction
  • Who is this guide for?
  • What you’ll find in this document
    • Why this document is modular and not a monolith
    • Style
    • Terminology
• Step 1 – Setting up your AWS Master Payer Account
  • Suggested Reading
  • How to set up a new AWS Master Payer Account
• Step 2 – Set up and link nOps Accounts
  • Suggested Reading
  • How to setup nOps accounts
• Step 3 – Configuring nOps Billing
  • Understanding credit and discount sharing
  • How to create a Billing Import
• Step 4 – Monthly invoices
  • Key points
• Conclusion
  • Feedback and Support
  • Further reading

Introduction

There are four steps in this guide to delivering nOps-managed consolidated billing for an AWS Consulting Partner:

Who is this guide for?

This guide is for Cloud Solution Architects or FinOps Practitioners at AWS Consulting Partners that are using nOps to manage consolidated billing and invoicing for multiple clients.

There are two main scenarios for setting up consolidated billing and both are addressed in this document:

1. A “new” AWS partner that is doing consolidated billing for the first time. They have multiple clients with multiple accounts, but they are not using AWS Organizations yet. This is addressed specifically in Step 1, then the rest of the Steps apply.
2. An “existing” AWS partner that is doing consolidated billing with AWS Organizations but they want to move to nOps to benefit from the extra cost management features and invoicing.

The two scenarios are only different because of their starting point. This document delivers the same outcome in both scenarios: nOps providing monthly invoices for consolidated billing.

What you’ll find in this document

To address the three scenarios in a modular, accessible fashion we have arranged the document as follows:

AWS Consolidated Billing is a large and complex topic and to make it more digestible in this document we have made some design designs to help:

• Use a modular format instead of a monolith document.
• Use font styles to clarify product features and the vendor.
• Use consistent terminology to avoid confusion.

Why this document is modular and not a monolith

To keep this document to a reasonable size we have decided to modularize the content:

• This document covers the entire “left-to-right” process and only goes deep enough in each step to describe the actions required.
• For details on each step there are linked documents that have screenshots and deeper technical guidance.

Style

There is an intentional capitalization and coloration style in force to help clarify specific features in AWS and nOps:

• nOps product components will be capitalized and coloured blue, for example as Partner Dashboard.
• AWS product components will be capitalized and coloured orange such as AWS Organization.

Terminology

AWS Organizations and Consolidated Billing can be confusing and much of that confusion arises from too many new terminology / taxonomy .

The following terminology is used in this document:

• Partner MPA is the Partner’s own AWS Master Payer Account all the Partner’s client AWS account bills roll-up to.
• Client Member Account is the Partner’s Client’s AWS account that rolls-up it’s bills to the Partner MPA
• Client MPA is a special case when a Partner’s Client has their own separate Master Payer Account.
• AWS Organization is the AWS account management service that manages multiple AWS accounts under one consolidated organization.
• Partner Dashboard is the Partner-level screen to access Partner-only functions of nOps.
• Client Dashboard is the Client-level screen to access Client-only functions of nOps.

Step 1 – Setting up your AWS Master Payer Account

This step applies to Scenario One only, “AWS partners that are creating a new consolidated billing system, perhaps as part of a new service portfolio offering to resell AWS and/or manage customer invoicing.”

Suggested Reading

We recommend becoming familiar with the best practices for setting up a new AWS account, using AWS Organizations and understanding consolidated billing and Master Payer Accounts.

• nOps documentation
  • Setting up Consolidated Billing
• AWS documentation
  • What are AWS Cost and Usage Reports?

How to set up a new AWS Master Payer Account

The steps below are intended to explain the process at a high-level. For a more detailed guide please refer to nOps Documentation – Setting up Consolidated Billing.

A completed AWS Organization with an MPA might look like this:

Now you have an AWS Organization with one Master Payer Account and one or more Member Accounts organized into Organizational Units.

Step 2 – Set up and link nOps Accounts

The goal of this step is to configure nOps in preparation of the final step to link nOps Client Accounts with your AWS Master Payer Account and your AWS Member Accounts.

Suggested Reading

We recommend becoming familiar with the best practices for setting up a new AWS account, using AWS Organizations and understanding consolidated billing and Master Payer Accounts.

• nOps documentation
  • Setting up Consolidated Billing

How to setup nOps accounts

Thanks to the nOps account setup wizard, you can create nOps accounts and link them to existing AWS accounts in one step.

Now that nOps accounts have been created and linked to AWS accounts you are ready to configure AWS billing.

Step 3 – Configuring nOps Billing

By configuring nOps billing you are telling nOps about the relationship between accounts and how to process credits and discounts as part of the billing process.

This is of special importance to AWS partners that have multiple clients and may even have different billing relationships for each client.

The simple case is when a partner has one MPA and multiple clients who all have the same billing configuration with respect to credits and discounts.

Understanding credit and discount sharing

Inside the AWS account settings for Billing, you can toggle the sharing of Credits and Discounts which means:

Someone might disable sharing of credits and discounts to have a predictable, though more expensive, cloud bill each month.

What should I set as the AWS MPA default for sharing costs and discounts?

When their AWS account is joined to the AWS organization then it will inherit the blended cost and sharing of credits and discounts set at the Master Payer Account level.

The best configuration for nOps to assume control of costs and discounts is to configure the AWS Master Payer Account as follows:

To learn more about how AWS manages credits, read AWS Credits.

How to create a Billing Import

First you need to create a tell nOps which is your Partner MPA to import the consolidated billing from. We do this by linking it as a Billing Import.

Go to Partner Dashboard → Settings → Billing Imports

Once you click Add Billing Export, the configuration screen will appear:

How to complete each field:

How to create a Billing Export

A Billing Export is a configuration that creates a client AWS bill from your Partner MPA account (the Billing Import):

If you’ve configured a Billing Export for your Partner MPA then nOps is already processing data when it’s available from AWS.

The next step towards producing client invoices is to link the Partner MPA to the client and tell it how to process costs and discounts for that client by going to Partner Dashboard → Settings → Billing Exports.

How to complete each Billing Export field:

Step 4 – Monthly invoices

As part of the AWS monthly billing cycle, nOps will automatically generate your bills for those configured Billing Exports and make them available under the Partner Dashboard Billing option

Key points

1. You will only get invoices for Billing Exports you have set up.
2. If you have AWS accounts that you have not configured a Billing Export for, then that will be shown on the Partner invoice.
3. If you haven’t explained how consolidated billing works, how blended costs with credit and discount sharing can influence a customer’s invoice, then you might be queried.
4. You clients can’t see their own invoices via their own Client Dashboard. You need to download and share the PDF with them.
5. If your customers still have access to the Billing Dashboard in AWS and if they don’t understand how consolidated billing works, then expect queries — avoid these with our guide (how to prepare….)

Conclusion

This guide should have helped you to:

Feedback and Support

We welcome feedback on this document to help us improve.

Please email help@nops.io or use live chat in the nOps application.

Further reading

A number of documents and articles were linked to in this document and we collect them all together here for ease of reference:

• nOps Documentation
  • Setting up Consolidated Billing
  • Creating the initial settings
  • Configure AWS using the Wizard
• AWS Documentation
  • What are AWS Cost and Usage Reports?
  • AWS account best practices for security
  • Setting up an Amazon S3 bucket for Cost and Usage Reports
  • Service Control policies