In my previous cloud computing articles, I was mainly learning the concepts and theory.
But today, I started moving from:
“What is cloud computing?”
to:
“Okay, how do I actually start using AWS?” 😄
And while doing that, I realized that there are some basic things I should understand before creating EC2 instances, databases, or other cloud resources.
So, in today's learning, I explored:
- Creating an AWS account
- Root User vs IAM User
- IAM Groups & Permissions
- AWS Regions
- Metered Billing
- AWS Budgets
- AWS Free Tier
- Free Tier Usage Alerts
- Billing Alarms
- MFA
I found these topics quite important because when we are beginners, we usually focus only on creating resources.
But there is another question we should ask:
“How do I use AWS safely without accidentally losing money or compromising my account?”
So let's understand everything step by step. 👇
🟢 1. Creating an AWS Account
The first step is obviously creating an AWS account.
When we create an AWS account, AWS asks for our basic information and a payment method.
But there is something important I learned here.
The account that we create initially has a Root User.
And the Root User is not just an ordinary login account.
It has very high-level access to the AWS account.
So my first thought was:
“If this is my AWS account, can't I just use this account for everything?”
But that's not a good practice.
Instead, we should create another user for our regular AWS activities.
And this is where IAM comes in.
📸
📸
🔐 2. What is IAM?
IAM stands for:
Identity and Access Management
I understood IAM as the system that helps us answer three simple questions:
Who are you?
↓
What are you allowed to access?
↓
What are you allowed to do?
For example, imagine a company has 10 people using AWS.
Do we want all 10 people to have complete access to everything?
Probably not.
Maybe one person works with EC2.
Another person works with S3.
Another person manages databases.
And maybe only one or two people should have administrator-level access.
IAM helps us control these permissions.
So instead of giving everyone the “key to the whole house”, we can give them access only to the rooms they actually need. 😄
👑 3. Root User vs IAM User
This was one of the most important things I learned today.
👑 Root User
The Root User is the highest-level identity associated with the AWS account.
It has very powerful permissions.
Because of that:
⚠️ We should not use the Root User for normal everyday activities.
Instead, we should create an IAM User and use that for our regular work.
I found it easier to remember like this:
AWS Account
│
├── 👑 Root User
│ └── Highest-level access
│
└── 👤 IAM Users
├── Developer
├── Admin
└── Other Users
So the basic idea is:
Root User → Keep it protected and use it only when necessary
IAM User → Use it for normal AWS activities
The IAM setup also allows us to provide console access to the user we create.
📸
📸
📸
📸
👥 4. IAM Groups & Permissions
While creating an IAM User, I also came across Groups.
Instead of assigning permissions separately to every user, users can be organized into groups.
For example:
Admin Group
↓
Administrator Permissions
↓
Admin Users
Or:
Developer Group
↓
Development-related Permissions
↓
Developer Users
One thing that stood out to me was that Administrator access is very powerful.
So we shouldn't simply give administrator permissions to everyone.
A better approach is:
Give a user only the permissions they actually need.
This makes the account easier to manage and also improves security.
In simple words:
More permission ≠ Better
Instead:
Required permission = Better
This idea is often called the principle of least privilege — giving only the access that is actually required.
🌍 5. What is an AWS Region?
After understanding IAM, I came across another concept that is very important when working with AWS:
AWS Regions
When we open the AWS Management Console, we can see a selected region.
For example:
US East (N. Virginia)
But what exactly is a Region?
A simple way I understood it is:
An AWS Region represents a geographic location where AWS has infrastructure for providing cloud services.
AWS has multiple regions around the world.
So when we create certain resources, we need to know which region we are creating them in.
📸
📸
🤔 Why should I care about Regions?
Suppose I create an EC2 instance in:
US East (N. Virginia)
Then later I accidentally switch my AWS console to another region.
Now I open EC2 and don't see my instance.
My first reaction might be:
“Where did my EC2 instance go? 😐”
But the instance hasn't disappeared.
I'm simply looking at a different region.
This is something I think beginners can easily get confused about.
So whenever you're following an AWS tutorial and suddenly can't find a resource:
First check your selected AWS Region.
This is a small thing, but it can save a lot of confusion later.
🌎 6. Regional vs Global Services
This was another interesting point I learned.
Not every AWS service behaves in exactly the same way with regions.
For example, EC2 resources are associated with a region.
If I create an EC2 instance in one region, I shouldn't expect to see that same instance when I switch to another region.
Conceptually:
Region A
↓
EC2 Instance
Switch to:
Region B
↓
The EC2 instance created in Region A
may not appear here
But some AWS services have a global scope.
The examples I came across while learning were:
- CloudFront
- S3
So one thing I want to remember is:
Before creating or searching for an AWS resource, understand whether that service is regional or global.
📸
📸
💰 7. AWS Uses Metered Billing
Now comes the part that I think every AWS beginner should pay attention to:
💸 Billing
One major advantage of cloud computing is that we don't necessarily have to purchase and maintain physical servers ourselves.
Instead, we can use cloud resources and pay according to our usage.
This is called metered or usage-based billing.
I understood it like this:
Use a resource
↓
AWS measures the usage
↓
You are charged based on the usage
This can be great because we're not necessarily paying for a huge infrastructure setup upfront.
But...
There is a dangerous side too. 😅
If we create a resource and forget to stop or delete it, the cost can continue increasing.
So cloud gives us flexibility, but it also gives us responsibility.
⚠️ Always keep an eye on what resources you are running.
😨 8. The AWS Bill Can Surprise You!
There was a practical example in the learning material that made this point very clear.
A resource was created for testing, but the selected configuration was more expensive than what was actually needed.
The important lesson here isn't really about that particular AWS service.
The lesson is:
Don't blindly click “Create”.
Before creating a resource, check:
- What type of resource am I creating?
- What configuration am I selecting?
- Is there a cheaper option?
- How much could it cost?
- Do I actually need to keep it running?
Think about this:
Small hourly cost
↓
Running for many hours
↓
Running for many days
↓
💸 Unexpected bill
Even a small amount can become significant when a resource keeps running.
So now I want to build a habit:
Before creating a resource, check the configuration and the possible cost.
📸
📸
📸
📸
📊 9. AWS Budgets — My First Cost Safety Net
After learning about unexpected spending, naturally my next question was:
“How can I keep track of my AWS spending?”
One option is AWS Budgets.
AWS Budgets allows us to define a budget and monitor our spending against it.
For example, suppose I decide:
Monthly Budget
↓
$100
Now I can monitor things such as:
Actual Cost
+
Forecasted Cost
↓
Compared with Budget
We can also configure alerts.
For example:
Budget = $100
80% reached
↓
📧 Send Alert
So before the spending becomes a bigger problem, I can get a notification.
This is something I would definitely configure while experimenting with AWS.
📸
📸
📸
🆓 10. What is the AWS Free Tier?
Another thing I learned today was the AWS Free Tier.
When we are beginners, this is obviously interesting because we want to experiment with AWS without spending a lot of money.
The Free Tier provides certain AWS services with free usage under specific limits and conditions.
And here I want to highlight one important word:
Conditions
Because:
❌ Free Tier does NOT mean everything in AWS is completely free.
Different services can have different:
- Usage limits
- Time periods
- Eligibility conditions
- Resource types
So before using a service, we should check exactly what is included.
For me, the easiest way to remember it is:
Free Tier = Free usage within specific rules and limits
Not:
Free Tier = Everything is free ❌
📸
📸
📌 11. Free Tier Usage Alerts
While learning about the Free Tier, I also learned that we can enable Free Tier usage alerts.
This is useful because AWS usage can increase without us realizing it.
The basic idea is:
AWS Usage
↓
Approaching Free Tier Limit?
↓
📧 Email Alert
So instead of manually checking everything all the time, we can receive an alert when our usage is approaching or exceeding the relevant Free Tier limits.
For someone learning AWS, I think this is a very useful safety feature.
It gives us one more way to keep track of our usage while experimenting.
🚨 12. Billing Alarms with CloudWatch
Another way to monitor our AWS spending is through CloudWatch billing alarms.
I understood the basic idea like this:
AWS Cost
↓
Crosses a threshold
↓
CloudWatch Alarm
↓
📧 Notification
For example, I could set a threshold of:
$50
If the monitored cost crosses that threshold, the alarm can move into an alarm state and trigger a notification.
This gives us another layer of protection.
📸
📸
🔔 13. Where does SNS come into this?
While setting up the billing alarm, I also came across SNS.
SNS stands for:
Simple Notification Service
I found it easier to understand SNS as a service that helps send notifications.
For example:
Billing Alarm
↓
SNS
↓
📧 Email Notification
So if an alarm is triggered, SNS can help send the notification to the configured destination.
I don't need to understand everything about SNS right now.
For now, I just want to remember:
SNS = Notification Service
🔐 14. MFA — One More Layer of Security
Finally, we come to something very important:
MFA — Multi-Factor Authentication
Suppose someone somehow gets my password.
Does that automatically mean they should be able to access my AWS account?
With MFA enabled, there is an additional verification step.
So instead of:
Password
↓
Access
we have:
Password
+
MFA Verification
↓
Access 🔐
For example, we can use a virtual MFA application on our phone.
The application generates a temporary code which changes periodically.
During login:
Enter Password
↓
Enter MFA Code
↓
Access AWS 🔐
There are also hardware security keys that can be used for MFA.
But the important lesson for me is not which option I use.
The important lesson is:
MFA should be enabled, especially for the AWS Root User.
🧠 What I Learned From Day 3
If I had to summarize today's learning in one flow, I would write it like this:
Create AWS Account
↓
Protect Root User
↓
Create IAM User
↓
Understand Permissions
↓
Understand AWS Regions
↓
Check Resource Configuration
↓
Monitor AWS Spending
↓
Set AWS Budget
↓
Monitor Free Tier
↓
Set Billing Alerts
↓
Enable MFA 🔐
And honestly, these may look like small topics.
But I realized that they are actually the foundation for using AWS properly.
Because learning AWS isn't only about:
“How do I create an EC2 instance?”
It is also about:
“How do I create it safely, in the correct region, with the correct permissions, while keeping an eye on the cost?”
💡 My Biggest Takeaway
The biggest thing I learned today is:
Before learning how to build on the cloud, I should first learn how to use the cloud responsibly.
As a beginner, I don't want my first AWS experience to be:
“I created something for practice.” 😄
↓
“I forgot to delete it.” 😐
↓
“Why is my AWS bill so high?” 😭💸
So from now on, whenever I create an AWS resource, I want to get into the habit of checking:
✅ Which region am I using?
✅ What exactly am I creating?
✅ Is it within my Free Tier?
✅ How much could it cost?
✅ Do I need to keep it running?
✅ Have I configured billing alerts?
✅ Is my account properly secured?
☁️ Day 3 Complete!
So that's what I learned on Day 3 of my Cloud Computing journey.
Today wasn't about building a big application or launching something complicated.
Instead, I learned the basic AWS setup, security and cost-management concepts that I should know before going further.
I'm learning cloud step by step and sharing what I understand along the way so that someone who is also starting from zero can learn with me. 😊
If you're also learning AWS:
What was the first AWS service you tried?
I'd love to know! 👇
Top comments (0)