How to Grant Access to AWS Billing Data

Granting IAM users access to AWS Billing data is a bit tricky. Here are some simple steps to solve it.

Access to the AWS Billing Portal is handled differently than all of the other permissions you grant Identity and Access Management (IAM) users.  But you can’t hold IT accountable for cost if they can’t see the billing data.  By following these steps you can grant read only or full access to you AWS Billing data to IAM users.

Enable IAM User Access

For the first step, log in as the root user for your account.  In the upper right hand corner, click your user name and the “My Account” as shown below.


Scroll down to the “IAM User Access to Billing Information” and click edit


Then enable access to billing for IAM Users.


Create IAM Billing Policies

Nearly every other AWS Service has predefined ReadOnly and FullAccess polices, but not billing.  Because IAM user access is not enabled by default, there are no predefined policies.  You have to create them yourself.

Start by switching to the IAM service.  In the left hand column, click “Policies.”  If this is your first time editing policies, you will see a “Get Started” button.  Click it.

Full Access

The click the “Create Policy” button.


Select the “Policy Generator” button on the next page.

On the “Edit Permissions” page, select “AWS Billing” as the AWS Service.  Under Actions, select “All Actions”.  The click “Add Statement” and “Next Step.”  Full-Control-AWS-Billing-Policy

Name your policy “BillingFullAccess” the click “Create Policy.”  You now have a policy that allows full access to those users to whom you wish to grant such access.

Read Only

Repeat the steps to create a “Read Only” policy.  Click “Create Policy” and “Policy Generator.”  Select “AWS Billing”, but then, rather than selecting “All Actions,” select only the “View Actions.”


click “Add Statement,” then “Next Step” and name your policy “BillingReadOnly.”  Click “Create Policy.”

Create Groups

Now that you have the policies created, you need groups to map users to policies.  Mapping policies to groups and then adding users to groups is considered a best practice.  Assigning policies directly to users can become difficult to manage over time.

To create groups, start by clicking “Groups” in the left hand column of the IAM Service console.  The click the “Create Group” button.


On the next screen, name your group “BillingFullAccess” or another name that will clearly convey the purpose of the group.  Go to the next screen to attach policies to your group.  Type “billing” in the filter box to show only policies with “billing” in their name.  Check the box next to your “BillingFullAccess” policy, then click next step.


Complete the process of creating the group, then repeat the steps to create a “BillingReadOnly” group and attach the “BillingReadOnly” policy to that group.

Add Users to the Groups

The last step is to add users who need full access or read only access to billing to the appropriate group.  From the IAM Groups page, click the appropriate group name.  On the next page, click the “Add Users to Group” button and select the users to add to the group.

Congratulations!  You have now granted access to AWS billing data for your IAM users.


Should I Buy Reserved EC2 Instances?

AWS Reserved EC2 instances offer a compelling cost savings. But if you are not careful, they may lock you in for higher costs than you really need.

Savings Through Reserved Instances

Your effective monthly cost for EC2 instances can be significantly reduced by selecting a reserved instance.  The longer your reservation period and the more you choose to pay up front, the more you save.


From the chart above, you can see the us-east pricing for an m4.large instance as of May of 2016.  By committing to a one-year reserved instance, you can save 31% of your monthly cost.  By paying up front, you can save almost 43% for a one year commitment.  If you are willing to commit to a three-year contract, you can save as much as 63%.  These savings can be compelling!

Reserving the Wrong Size Instance Can Cost You More

Despite these savings, there are reasons not to buy a reserved instance.  Especially when you first start using Amazon Web Services.  If you are coming from the non-cloud world, you may be used to over-provisioning your servers.  Servers are a big purchase and they are expected to last at least three years and maybe five.  As a result, when physical servers are purchased, they are often bought in a larger size than needed to allow for growth over time and to guard against possible errors in estimating what size server is necessary.

Immediate Visibility of Performance Trends

If you are coming from an on premise model, you may not be accustomed to having immediate visibility of performance trends.  Or you may have had to wait for complicated monitoring systems to be installed and configured before you had visibility into this data.

In the cloud, AWS CloudWatch provides immediate visibility into performance trends on the CPU, disk, and network usage of your EC2 instances.  You can also set alarms to notify you if usage rises above a threshold of your choice.

The CloudWatch graphs below show an Ec2 instance that is almost certainly oversized.  In the last two weeks, the CPU usage has never exceeded 15% and has only rarely exceeded 5%.


The owner of this EC2 instance would certainly be using a smaller, less expensive instance, except that they made the exact mistake I am warning against and purchased a reserved instance prior to fully understanding their resource needs.  Because of this, they are locked into a more expensive instance than they need for a year.  Lucky for them, they chose a one year term rather than a three year term.

So What Should I Do?

If you are evaluating whether to buy a reserved instance ask yourself these questions:

  1. How certain am I of the load my application will put on this instance?
  2. Have I observed the performance and behavior of my application on a variety of instance sizes to know which one is best?
  3. Am I confident that load will remain consistent for the next one to three years?
  4. If I outgrow my EC2 instance, can I take advantage of elastic load balancing and auto-scaling to distribute the load to additional instances?
  5. Do I have time to perform this analysis, or do I need to simply make a choice and move on?

How certain am I of the load my application will put on this instance?

Are you deploying a new application to the cloud, or migrating and existing application to the cloud?  Do you have metrics of what load the application will put on the EC2 instance?  If not, before you select a reserved instance, you should consider observing the behavior of your application and confirming the right instance size before you reserve an instance.  Though you will spend more to run on an on demand instance for the initial testing and monitoring period, you might save significant money over the life of the reservation by ensuring you do not reserve an instance size large than you need.  Use the “Monitoring Tab” on the EC2 control panel to observe CPU, network and disk usage of the instance.

Have I observed the performance and behavior of my application on a variety of instance sizes to know which one is best?

Before you lock in a one or three year contract for a given instance size, try a few different sizes to see how your application performs.  To resize an EC2 instance, Follow these steps:

  • Stop the Ec2 instance
    • On the EC2 console, select your instance
    • Choose Actions -> Instance State -> Stop
  • Resize the instance
    • On the EC2 console, select your instance
    • Choose Actions -> Instance Settings -> Change Instance Type
    • Select a new instance type
  • Start the instance
    • On the EC2 console, select your instance
    • Choose Actions -> Instance State -> Start

The whole process takes only a minute or two.  If you cannot tolerate a minute or two of downtime, consider putting an Elastic Load Balancer in front of your instance.  This will allow you to add and remove instances from behind the load balancer without downtime.  The load balancer also offers the ability to monitor request latency.  This allows you to see whether a new instance size has caused a slower response time for your application.

If you choose to use the elastic load balancer, you will need to take an image of your EC2 instance and then launch a new instance of a different size.  Add the new instance to the load balancer and remove the old one to shift traffic seamlessly between instances.

Am I confident that load will remain consistent for the next one to three years?

Reserving an instance locks you in to paying to use that instance for the entire term of the reservation.  If you expect that your traffic may increase or your application may change such that you outgrow that instance type before the reservation term is complete, then reserved instances may not be the best option for you.

If I outgrow my EC2 instance, can I take advantage of elastic load balancing and auto-scaling to distribute the load to additional instances?

Leveraging elastic load balancing and auto-scaling can significantly reduce the risk that you outgrow your instance and can significantly reduce your cloud costs.  Elastic Load Balancing distributes the traffic for your application across a group of instances.  If your traffic grows, you can add more instances.  If your traffic drops, you can stop the unneeded instances.

Auto Scaling automates the process of adding and removing instances in response to traffic changes.  Combining auto scaling and load balancing can optimize your cloud costs by running extra instances only when your traffic demands them.  It will automatically terminate unneeded instances when the traffic drops.

If you go the route of load balancing and auto scaling, you should reserve only the minimum number of instances you plan to run all the time.  Let the other instances be on demand.

Do I have time to perform this analysis?

An important question to ask yourself is whether you have the time and interest in optimizing your costs.  If you are already over tasked and think you may never get around to evaluating the right size for your instance, perhaps you want to just pick a safe, oversized, instance and move on.  Perhaps the cost savings offered by selecting a smaller instance are not worth the time you would invest.  If this is the case, you may be best off reserving a one year term rather than allowing the project to linger on indefinitely all the while paying on demand prices.


The correct use of reserved EC2 instances can save you significantly on your cloud computing costs.  But reserving an instance before determining the size you really need can lock you in to an oversized instance and end up costing you more in the long run.  You should take the time to test your application on a variety of instance sizes to ensure you select the best size for your needs.  You should also try to use Elastic Load Balancing and Autoscaling to optimize your cloud computing costs by responding dynamically to traffic load.