Day 1  - Setting up new AWS Account

Checklist Item 1 – Understanding AWS Free Tier

Note: Though you will understand free tier here, AWS account for you should be under the AWS organization created for your company , department or team. Reach out to your manager for provisioning the AWS account for you under AWS organization.  Ideally every developer should have an account in your organization, guardrails and permissions for each develpers AWS accounts can be managed at organizational unit or team level. You can verify with your manager in case you do not have admin permissions in the account, for example setting up MFA for yourself and adhering to AWS best practices.


The AWS Free Tier is a program offered by Amazon Web Services (AWS) that provides customers with free access to a limited set of AWS services for a specified period. It allows users to explore and experiment with various AWS services without incurring any charges. Especially you need to understand if your organization is a start up. 

Here are some key points to understand about the AWS Free Tier:

Remember that the Free Tier is designed for learning, testing, and exploring AWS services, and it may not be suitable for production workloads or high-traffic applications. Always review the AWS documentation and pricing details to understand the terms and conditions associated with each service to avoid unexpected charges.

For the most accurate and up-to-date information on the AWS Free Tier, refer official AWS Free Tier webpage or contacting AWS support directly (Ref: AWS Free Tier ).

WARNING. You might fall into the trap of not understanding is that using a service can sometimes cause other services to be used as well. The linked service may not qualify for free tier which can lead to unexpected bills. For example, say you were to start using AWS Lambda which qualifies for free tier. When emitting to system output (i.e. using console.log() or print functions), your log files are sent to Cloudwatch. If your log files exceed 5GB (the current threshold for free tier), you will be charged incrementally at a rate of $.50 per GB of log files.

Checklist Item 2 – Create a User Account and Enable Multi Factor Authentication


Note: In your AWS development account, a user account should be created instead of using the root user, if your manager created this for you, you may only need to enable multi factor authentication (MFA). (Ref: Enable MFA )

When someone first signs up for your AWS account, you are able to sign up using the email and password you originally provided. Signing in with this method is called signing in as the Root User. The Root User is a very powerful user in the context of an AWS account. It is effectively the top level super user that has access to special security (and other) controls that normal users do not have access to. Some special privileges include things like revoking a normal user’s account and viewing/delegating billing permissions.

This means that if for some reason an employee or sub-user of your AWS account accidentally leaks their credentials on the web, the root user will be capable of revoking access. This is a powerful ability. After you create your user account (which we will discuss below), you should safely store your root account credentials.

Note that you should never use the root user to perform day to day tasks. Instead, you immediately lock down your root user with MFA and create a normal “user” account for your day to day activities.

Create a User Account

The next thing you’ll want to do is create a normal user account. This is the account that you should use on a day to day basis to interact with AWS. You can still use a user account to log in with a username and password to access the AWS console, or alternatively can use secret keys to access it programmatically.

There are a couple advantages of using this account over the Root User account. For one, User Accounts can (and usually do) have less permissive permission policies. This can protect you from accidentally creating or using a resource you don’t intend to.

The second advantage has to do with reducing the blast radius in case of compromised credentials. Heaven forbid you accidentally leak you secret keys to the public, you can use your Root User to revoke the User Account’s credentials. This will immediately put a stop to the bad actor and allow you to begin the damage assessment and cleanup phase.

You can learn how to create a user account as a root user in my video below.

REMEMBER – You’ll want to activate MFA on your user account as well for the same reasons as doing so on the Root Account. As a general best practice, any human using AWS should be logging in with MFA.

Checklist Item 3 – Setting up the AWS CLI

Ref: https://docs.aws.amazon.com/cli/latest/userguide/getting-started-quickstart.html

To set up the AWS Command Line Interface (CLI) on your local machine, you can follow these steps:

That's it! You have successfully set up the AWS CLI on your local machine. You can now use the AWS CLI to interact with various AWS services and manage your resources from the command line. 

Checklist Item 4 – Setup Billing Alert Notifications

It is important to check if Billing is crossing a threshold set for your organization budgets. In cloud everyone in the team is responsible for managing the resources.


By default, AWS sends you monthly bills based on your usage. One proactive step you can take to ensure you don’t end up with surprises is to enable billing alerts.

Billing alerts allow you to get automatic notifications when the amount spend on your current bill exceeds a dollar value threshold. The threshold you set can be customized to any value you please.

This simple little trick has helped me numerous times avoid unexpected surprises at the end of the month. Sometimes you might create an AWS resource as a test, get pre-occupied with something else, and forget to come back and clean up your work. Depending on the resource you create, this can be a pretty costly mistake if you wait till the end of the month to find out.

Another risk this helps with is getting early warnings if there is a security issue with your account. If a bad actor gets ahold of your credentials and starts spawning up hundreds of EC2 instances to mine Bitcoin, you’ll atleast get early warnings and be able to revoke the access keys pretty quickly.

The exact dollar amount you decide to use for your billing alert depends from person to person. I like to set mine to $25.00 since my usual bills are around $15.00 per month. However if you’re trying to avoid charges altogether, set this to a really low value such as $1.00.

Checklist Item 5 – Enable the Billing Dashboard Widget

The Billing Dashboard widget allows you to see quickly see your spending per month directly on the home page of the AWS console.

The widget shows you the top services you’ve spent on so far this month in descending order. This is a really handy feature that has helped remind me on numerous occasions to tear down an unused resource. This tip in conjunction with using billing alerts should effectively safeguard you from any surprise bills.

One thing to note though of this feature is that by default, normal AWS users (except the root user) can not view the billing dashboard widget. It will simply show up as empty.

This is because the root user is the only user that has permission to view billing details unless specific steps have been taken. This involves enabling bill viewing for other users via a specific tucked away setting, and granting users a specific IAM policy permission.


What To Do If You Get A Surprise Bill OR Your Account Gets Hacked

Waking up to a multi thousand dollar AWS bill is a gut-wrenching moment. Anxiety, fear, anger jolt through your veins as you try to assess the damage and stop the madness from worsening. Here’s how to handle it.

First, stay calm and relax. If you’ve followed all of the steps from this checklist, it is very likely that AWS will forgive your bill regardless of the cost. This is because you took all reasonable pro-active steps to protect your account. This is especially true if this is the first time an issue like this has occurred on your account. AWS employees aren’t monsters – they understand that people make mistakes. 

Deactivating Users

It’s more than likely your account was “hacked” because someone re-used a password, or accidentally leaked their access keys. This is an easy problem to fix – you simply need to disable the affected accounts.

To start getting the situation under control, you need to start revoking IAM user permissions in the AWS console. This will prevent users from creating resources in the console, or programmatically using their access keys. You will be able to do this as the root user which has an elevated permission set. Simply log in to the console as your root user, and deactivate all user accounts.

Identifying which account to de-activate can be a bit tricky though. In a situation like this, I suggest shooting first and asking questions later – just deactivate them all and figure it out later. Later on you can use CloudTrail to identify which user account was responsible for creating the resources. 

Clean Up The Mess

Your next priority should be to clean up all the resources that the bad actor created. This can be from any AWS service – but by far the most commonly used one for hackers is EC2 since its such a versatile service.

What you can do to narrow down what they created quickly is to head over to the Billing Dashboard section of the AWS console. Here, the dashboard will show you a summary of all AWS services that are being used in the account.

You’ll need to identify the services the individual created resources in and go and delete/remove them. Also remember to do this for all AWS regions to ensure you got everything.

Contact AWS Support

After you’ve mitigated the attack, its time to get AWS involved. Do note that if you get stuck in any of the prior steps and don’t know how to proceed – just contact AWS and they will give you advice. The best way to contact AWS is through the Support section of the AWS console. You can file a ticket with them and request either Web or Phone support. Web opens up a live chat box that should get you on the horn with an AWS employee pretty quickly. Phone support means to expect a callback. I’d go with web.

If you’re following this sequence, you’ll now need to contact AWS and beg for forgiveness. Let them know that you received a surprise bill and the steps that you went through to mitigate the attack. Tell them that you had billing alerts enabled, used the billing dashboard widget, and made efforts to safely store your access keys.