Contact Me

Top 5 Best Practices for AWS Beginners

May 15, 2024





There are several pitfalls you can fall into when initially starting with AWS. There are a few basic things you can take to protect yourself from both a security and financial standpoint.

It can be a thrilling experience to learn AWS for the first time. But before you begin fiddling, there are a few things you should take to safeguard your account.

Below are the top 5 best practices to protect your account when getting started with AWS.

Below are the top 5 best practices to protect your account when getting started with AWS.

1. Stop Using Root Account

When you first sign up for an AWS account, you are given what is known as the Root Account. This account has full access to all AWS services, Users, and a variety of other ‘special’ permissions on your account. The Root Account is similar to the top level node in the permissions hierarchy in that it has complete control over the account, including the ability to revoke access for compromised users and billing information.

When you first signed up for AWS, you logged in with your root account. Usually with your email and password.

The very next step is to create a user account in the Identity and Access Management (IAM) section. IAM is an AWS security access control service that allows you to create users and assign fine grain (or broad) permissions to them.

After creating your user account, you should never access your root account unless absolutely necessary (for example, revoking a user’s permissions or performing one of the few actions that are only possible through the root account, such as viewing billing information).

Amazon Web Services IAM Policies

From this point forward, you really should lock away your root account credentials and use your IAM User Account for all day to day activities.

2. Utilize Billing Alert

Surprise bills are one of the scariest things about using AWS. Take it from me, when I first started learning AWS, I accidentally spun up the non-free tier EC2 instance and forgot to terminate it until it was too late. The result? Over $400 worth of AWS bills. You might think this isn’t a lot, but for a broke college lad like me, it was a month of food expense.

I definitely don’t want this to happen to you – and it turns out there’s an easy way to prevent it with proactive billing alerts.

AWS has a comprehensive billing ecosystem that lets you understand where the costs on your monthly bills are coming from. You can enable billing alerts which will allow you to set up a CloudWatch Alarm based on your spending on AWS.

AWS Billing Alarm

You can easily set up a billing alert alarm using CloudWatch Alarms if your bill exceeds a configurable threshold. For instance, a user set up a reminder notification if the usage spending ever goes more than $10.00. This allows the user to quickly become aware of any infrastructure he or she provisioned or inadvertently left on, letting the user rectify the situation.

Another thing to mention is that, in my experience, AWS is very understanding when it comes to surprise bills. If you are charged unknowingly, you can file a support ticket and have an AWS representative look into your particular instance. They usually provide you with a refund when it is your first time.

3. Enable Multi Factor Authentication (MFA)

Upon creating your IAM User, the very next step you will need to do is to enable Multi Factor Authentication, or MFA.

MFA adds an additional layer of security to your account. It allows you to add a secondary authentication process after logging in with your username and password – typically using a cell phone or dedicated MFA device.

Users can use Authenticator apps such as Google Authenticator to connect their mobile phones to their AWS User Account. This way, when you log in, you’ll need to enter the code from the Google Authenticator app into the AWS login prompt. You will only be able to log in after it is successfully authenticated with both your password and your digital code.

As an AWS user, I strongly recommend that you enable MFA on all of your accounts. The last thing you want is to have your account compromised and rack up surprise AWS bills.


4. Safeguard Your Access Keys

One of the most common methods of interacting with AWS services is through programmatic access using an access key.

When creating an IAM user, you have the option to grant the user the ability to use programmatic access. This instructs AWS to generate an access key and a secret access key.

You can programmatically interact with AWS using these two keys, provided your account has the appropriate level of IAM permissions for the service you’re interacting with.

Just remember you should never ever share these keys with the public.  These are the literal keys to your AWS account. A couple of years back, I had the unfortunate event of publishing one of these keys to my GitHub repo. A bad actor was able to rack up over $3000 worth of AWS charges in one night. So… don’t be like me.

5. Audit Your Account Regularly

You should audit your security configuration on a regular basis to ensure that it meets your current business needs. An audit allows you to remove unnecessary IAM users, roles, groups, and policies, as well as ensure that your users and software only have the permissions that are required.

AWS recommends the following auditing best practices:

  • Make sure that IAM users have the most restrictive policies possible, with only the permissions necessary to complete their intended tasks (least privilege).
  • Set up individual IAM users for each set of tasks.
  • When associating multiple policies with the same IAM user, keep in mind that the policy with the fewest restrictions takes precedence.
  • Audit your IAM users and their permissions on a regular basis and delete any unused IAM users or keys.
  • If your IAM user requires console access, you can set up a password to grant console access while restricting the user’s permissions.
  • Set up a separate MFA device for each IAM user who has console access.


Written by Ethan

Cloud Solutions Architect. Full Stack Web Developer. Cloud Enthusiast. Gym rat. I'm a driven, detail oriented, Cloud Solution Architect based in Pittsburgh, PA. Experienced in both networking and software development cycles where I enjoy designing scalable, flexible and cost effective solutions with a focus on end user experience and business objectives. When I'm not working or at the gym I enjoy continuous learning, experimenting with new technologies and sharing what I learned to the communities.



Submit a Comment

Your email address will not be published. Required fields are marked *






Software Design

Network Icon

Network Design



Stay up to date with the latest news on the Cloud! We promise we won't spam you.

Stay up to date with the latest news on the Cloud! We promise we won't spam you.

Join our mailing list to receive the latest updates from our team. We promise we won't spam you.

You have Successfully Subscribed!

Share This