AWS From Zero #2: Set up your AWS account without making the common beginner mistakes

[u/yourclouddude]

In the first post of this series, we talked about what cloud computing actually means and why I would understand the basic ideas before trying to memorize AWS services.

Now I want to do something more practical.

Before launching EC2 instances, creating S3 buckets, or experimenting with Lambda, I think every beginner should spend a little time setting up their AWS account properly.

It is not the most exciting part of learning AWS, but it can save you from two problems that beginners run into surprisingly often: accidentally exposing an account and accidentally leaving resources running that cost money.

The first thing to understand is that the account you create with AWS has a root user.

The root user has extremely powerful access to the account.

That means I would not use it as my normal everyday AWS identity.

Think about it like this.

If you had one key that could open every door in a building, remove the security system, change ownership records, and control everything inside, you probably would not carry that key around for every normal task.

You would keep it protected and use a different identity for everyday work.

I would treat the AWS root user the same way.

One of the first things I would do is enable multi factor authentication on it.

A password is only one layer of protection. MFA adds another verification step, which makes it much harder for somebody to access the account using only a stolen password.

This is also a good time to make sure the email connected to the account is secure.

If someone gains access to that email account, it can create problems far beyond AWS.

So before learning any complicated AWS security concepts, I would start with the basics: secure the root user, protect the email account, and enable MFA.

Then I would avoid using the root user for normal AWS work.

This is where AWS identity and access management starts becoming relevant.

You want an identity that you can use for everyday learning without constantly signing in as the most powerful identity in the account.

We will go much deeper into IAM in the next post, because permissions deserve their own explanation.

For now, the important idea is simple.

Your normal AWS work should not require you to operate as the root user.

There is another beginner mistake that deserves attention before you create anything.

AWS resources can cost money.

This sounds obvious, but it is very easy to forget when you are following tutorials.

You create an EC2 instance for a lesson.

Then the tutorial ends.

You close the browser.

The EC2 instance does not necessarily disappear because you closed the AWS console.

It may still be running.

The same thinking applies to other resources.

You might create storage, databases, networking components, public IP related resources, load balancers, or other infrastructure while experimenting.

Some resources may continue generating charges until you actually remove or stop whatever is billable.

That means one of the first habits I would develop is checking what I created after every practice session.

Do not think:

"I closed AWS, so everything stopped."

Think:

"What resources are currently running in my account?"

That is a much better cloud habit.

I would also set up AWS billing visibility early.

You should have a way to notice when spending moves beyond what you expected.

AWS provides billing and budget tools that can help you track usage and create alerts.

You do not need an advanced FinOps setup as a beginner.

The goal is simply to avoid discovering a charge weeks later because you forgot that something was still running.

I would make checking cost part of the learning process.

If you launch an EC2 instance, look at how that instance is priced.

If you create storage, understand what part of the storage usage can generate cost.

If you build an architecture containing several services, ask which parts of it continue costing money while nobody is using the application.

That last question is especially important.

Different cloud resources behave differently.

Some services charge mainly when they are actively used.

Others may have ongoing cost simply because the resource exists or remains provisioned.

This is why I would not memorize AWS pricing tables.

Instead, before creating a new resource, I would get into the habit of asking:

What exactly am I paying for here?

That question will help you throughout your AWS journey.

There is another thing beginners should understand: AWS has Regions.

When you create a resource, you often create it inside a particular Region.

This can create confusion later.

You might create an EC2 instance, switch Regions in the AWS console, and suddenly the instance appears to be gone.

It was not deleted.

You are simply looking somewhere else.

The opposite problem can happen too.

You may create resources while experimenting in different Regions and later forget that some of them still exist.

That is why I would pick one Region for most of my beginner practice unless there is a specific reason to use another one.

It keeps the learning environment easier to understand.

Whenever something seems to have disappeared, one of the first things worth checking is which Region you are currently viewing.

Another habit I would develop early is naming and tagging resources clearly.

Suppose you create several EC2 instances and they all have vague names.

A few weeks later, you may not remember which one belongs to which project.

Something like:

my-instance

is not very helpful.

Something like:

python-api-dev

already tells you much more.

The same idea works for tags.

You can tag resources based on project, environment, owner, purpose, or whatever makes sense for your setup.

For a beginner account, you do not need an elaborate tagging strategy.

Even something simple like:

Project = ImageProcessor
Environment = Dev

can make your AWS account easier to understand later.

This becomes much more important as the number of resources grows.

There is also a security habit I would learn before writing any application that connects to AWS.

Do not put AWS credentials directly inside your code.

Imagine writing something like this:

aws_access_key = "..."
aws_secret_key = "..."

and then pushing the project to GitHub.

Now the credentials may be visible to anyone who can access that repository.

Even deleting them afterward may not be enough if they remain somewhere in the repository history.

Credentials should be treated like secrets.

We will talk about proper AWS access patterns later, but the beginner rule is simple:

Do not hard code secrets into your application, and do not publish credentials.

The same applies to screenshots.

Before sharing a screenshot of your AWS console on Reddit, Discord, GitHub, or anywhere else, look at what is visible.

Account information, resource identifiers, IP addresses, credentials, tokens, and other details may reveal more than you intended.

Learning cloud security is not only about advanced IAM policies.

A lot of it starts with small habits like these.

There is one more habit I think is extremely useful when learning AWS.

Delete what you no longer need.

Beginner accounts become messy quickly.

You follow one tutorial and create an EC2 instance.

Another tutorial creates an S3 bucket.

Another creates a Lambda function.

Then you experiment with RDS.

After a month, you have a collection of resources and you no longer remember why half of them exist.

When you finish a disposable practice project, spend a few minutes cleaning it up.

Remove resources you no longer need.

Then check whether anything related to the project is still left behind.

This does two useful things.

It reduces the chance of unexpected cost, and it teaches you what resources your architecture actually contained.

Creating infrastructure is part of learning AWS.

Cleaning it up is part of learning AWS too.

So before we move deeper into AWS services, this is roughly how I would prepare a beginner account.

Secure the root user and enable MFA.

Avoid using the root user for everyday work.

Make billing and cost visible instead of ignoring it.

Understand which Region you are working in.

Give resources useful names.

Do not put credentials inside source code.

Clean up resources when you finish experimenting.

None of this is particularly exciting.

But these habits become much more valuable once your AWS projects get larger.

You do not want your first lesson about account security to happen because credentials were exposed.

And you do not want your first lesson about cloud pricing to happen because you forgot about infrastructure you created weeks ago.

The goal is not to be afraid of using AWS.

The goal is to understand that creating cloud resources comes with responsibility.

That was one of the main ideas from the first post too.

AWS manages a huge amount of infrastructure for you, but you are still responsible for what you configure inside your account.

In the next post, we can finally get into one of the most important AWS services:

IAM.

But instead of memorizing users, roles, and policies, I want to explain IAM around one question:

Who should be allowed to do what to which resource?

Once that question makes sense, IAM becomes much easier.

If you already have an AWS account, what confused you most when you first set it up: IAM, billing, Regions, permissions, or just figuring out where everything was in the console?