Learning AWS in Public: A Student Developer's Journey — Part 2
In the first article, I introduced my AWS learning journey and the roadmap I'm going to follow. The goal isn't to memorize dozens of AWS services. Instead, I want to understand how cloud infrastructure actually works by starting with the fundamentals and gradually building real applications. Before launching a server, deploying an API, or creating a database, there are a few things every beginner should understand first.
Series: AWS for Students — From Local Projects to the Cloud (4 articles)
- 2Learning AWS in Public: A Student Developer's Journey — Part 2 This article
Learning AWS in Public: A Student Developer's Journey — Part 2
Getting Started with AWS: Account Setup, Console, Regions, and Cost Awareness
In the first article, I introduced my AWS learning journey and the roadmap I'm going to follow.
The goal isn't to memorize dozens of AWS services.
Instead, I want to understand how cloud infrastructure actually works by starting with the fundamentals and gradually building real applications.
Before launching a server, deploying an API, or creating a database, there are a few things every beginner should understand first:
- How the AWS account works
- How to navigate the AWS Management Console
- What AWS Regions and Availability Zones are
- How IAM works
- How AWS billing works
- How to reduce the risk of unexpected charges
So in this article, I'm setting up the foundation for everything that comes next.
1. What Do We Need Before Starting?
To follow this article, you'll need:
- An AWS account
- A web browser
- An email address
- A phone number
- A valid payment method accepted by AWS
- Basic knowledge of using a web browser
You don't need to know EC2, Docker, Kubernetes, or Terraform yet.
We'll learn those gradually.
2. Creating an AWS Account
The first step is creating an AWS account.
Go to the official AWS website and choose the option to create an AWS account.
During registration, AWS will ask for information such as:
- Email address
- Account name
- Password
- Contact information
- Payment information
- Identity verification
The exact signup flow and available free-tier benefits can change over time, so always follow the current instructions shown by AWS during registration.
Important
AWS is a commercial cloud platform.
Some services have free usage allowances, but AWS is not simply a "free cloud server."
Whether something is free depends on factors such as:
- The service
- Your account eligibility
- Usage amount
- Region
- Resource configuration
- Current AWS pricing terms
Therefore, understanding billing should be part of learning AWS from day one.
3. The AWS Management Console
After creating your account, you'll enter the AWS Management Console.
Think of the Console as the graphical interface through which we interact with AWS.
Instead of configuring physical servers manually, we can use the Console to create and manage cloud resources.
For example, from the Console we can:
- Launch virtual machines
- Create storage buckets
- Create databases
- Configure networking
- Manage users and permissions
- Monitor applications
- View billing information
However, the Console isn't the only way to interact with AWS.
There are three common approaches:
1
2
3
4
5
6
7
AWS
|
+------------+------------+
| | |
v v v
Console AWS CLI SDKs
(Graphical) (Command Line) (Code)AWS Management Console
Best when:
- You're learning a service.
- You want to visually understand configurations.
- You're performing occasional administrative tasks.
AWS CLI
The Command Line Interface allows you to interact with AWS from your terminal.
For example, instead of using the Console to list S3 buckets, the AWS CLI can perform the operation from a command.
This becomes especially useful for automation.
AWS SDKs
AWS also provides SDKs that allow applications to communicate with AWS services programmatically.
For example, a Java application can interact with AWS services through AWS SDKs for Java.
We'll explore this later in the series.
4. Understanding AWS Regions
One of the first concepts that confused me when I started looking at AWS was:
What exactly is an AWS Region?
An AWS Region is a geographic area where AWS has infrastructure for running its services.
For example, AWS has Regions in locations around the world, including India.
A simplified representation looks like this:
1
2
3
4
5
6
7
8
9
AWS
+-------------+-------------+
| | |
v v v
Region A Region B Region C
| | |
v v v
AZs AZs AZsWhen creating many AWS resources, you'll need to select a Region.
For example:
1
2
3
4
5
6
7
8
9
10
Application
|
v
AWS Region
|
+---- Compute
|
+---- Database
|
+---- Storage5. Why Does Region Selection Matter?
Choosing a Region isn't just a random dropdown selection.
It can affect:
1. Latency
If your users are primarily located in India, deploying your application closer to them can generally reduce network latency compared with deploying it very far away.
2. Service availability
Not every AWS service or feature is necessarily available in every Region.
3. Pricing
The price of some AWS services can vary between Regions.
4. Data residency
Depending on the application and regulatory requirements, where data is stored can matter.
5. Architecture
Resources that need to communicate frequently are often placed strategically within the same Region to simplify architecture and reduce unnecessary network complexity.
6. What Are Availability Zones?
A Region isn't simply one giant data center.
AWS divides many Regions into multiple Availability Zones (AZs).
An Availability Zone is made up of one or more discrete data centers with redundant power, networking, and connectivity.
A simplified architecture looks like this:
1
2
3
4
5
6
7
8
AWS Region
|
+------------+------------+
| | |
v v v
AZ-1 AZ-2 AZ-3
| | |
Server Server ServerWhy is this useful?
Because applications can distribute components across multiple Availability Zones to improve resilience.
For example:
1
2
3
4
5
6
7
8
Load Balancer
|
+---------+---------+
| |
v v
AZ-1 AZ-2
| |
Server ServerIf one Availability Zone experiences a problem, an appropriately designed application may continue operating through resources in another Availability Zone.
We'll explore this concept in much more detail when we discuss highly available architectures.
7. Region vs Availability Zone
This distinction is worth remembering:
| Concept | Meaning |
|---|---|
| Region | Geographic AWS location |
| Availability Zone | Isolated infrastructure location within a Region |
Think about it like this:
1
2
3
4
5
6
7
8
9
10
Region
│
├── Availability Zone 1
│ └── Data centers
│
├── Availability Zone 2
│ └── Data centers
│
└── Availability Zone 3
└── Data centersYou don't need to memorize the infrastructure details yet.
The important idea is:
Region = geographic area
Availability Zone = isolated infrastructure location inside a Region
8. Choosing Your First Region
For this learning series, I'll generally use a Region that is convenient for my target users and supports the AWS services I'm going to experiment with.
For readers in India, AWS provides Regions in India, but the exact Region you should choose depends on the services you're using, pricing, latency requirements, and current AWS availability.
Before creating a resource, check whether the service is available in your selected Region.
This is especially important because beginners sometimes create a resource in one Region and later wonder why they can't see it after switching to another.
9. The Region Trap
Here's a very common beginner mistake.
Imagine you create an EC2 instance in:
1
Region ALater, you switch the Console to:
1
Region BYou might open EC2 and think:
"Where did my server go?"
Nothing necessarily happened to the server.
You're simply looking at a different Region.
AWS resources are often Region-specific.
So whenever something appears to be "missing," one of the first things to check is:
Am I in the correct AWS Region?
10. Understanding IAM
Before creating resources, we should also understand AWS Identity and Access Management (IAM).
IAM controls:
- Who can access AWS
- What they can access
- What actions they can perform
A simplified model is:
1
2
3
4
5
6
7
User / Role
|
v
Permissions
|
v
AWS ResourcesFor example, one identity might be allowed to:
1
Read S3 objectswhile another might be allowed to:
1
Create EC2 instancesand another might have much broader administrative permissions.
This is based on the principle of least privilege:
Give an identity only the permissions it actually needs.
This principle will become increasingly important as our projects become more complex.
11. Root User vs IAM
When you create an AWS account, you initially have access through the root user.
The root user has extremely powerful permissions.
For everyday development and administration, AWS recommends protecting the root user and avoiding unnecessary use of it.
Important security practices include:
- Enable multi-factor authentication (MFA).
- Don't share root credentials.
- Don't use the root account for routine tasks.
- Create appropriate IAM identities for normal operations.
- Grant only the permissions required.
Security isn't something we should add at the end of a project.
It should be part of the architecture from the beginning.
12. Understanding AWS Billing
Now comes one of the most important sections for students:
How much will this cost?
Before creating AWS resources, I recommend understanding the billing model.
Different AWS services charge differently.
Some may charge based on:
- Time
- Requests
- Storage
- Data transfer
- Compute usage
- Number of operations
- Provisioned capacity
For example, a resource that seems small can still generate charges if it remains active for a long period or exceeds a free usage allowance.
Therefore:
Never assume that something is free just because you are a student or because a tutorial says "free."
Always verify the current AWS pricing and your account's applicable free-tier terms.
13. Setting Up a Budget
One of the first things I recommend doing after creating an AWS account is setting up a budget or billing alert.
The exact AWS billing interface can change, but the goal is simple:
1
2
3
4
5
6
7
8
9
10
AWS Usage
|
v
Billing / Cost Management
|
v
Budget / Alert
|
v
NotificationFor example, you might configure an alert when estimated spending reaches a small amount that you're comfortable with.
The purpose isn't to guarantee that you can never be charged.
Instead, it gives you an early warning that your usage may be generating costs.
Important distinction
A billing alert is not the same as a hard spending limit.
It is possible for charges to occur before a notification is generated.
Therefore, you should still:
- Check active resources.
- Review billing regularly.
- Delete resources you no longer need.
- Read pricing documentation before experimenting.
14. A Beginner's AWS Safety Checklist
Before creating your first EC2 instance or database, I want to make this checklist part of my workflow.
Account
- AWS account created
- Recovery email/contact information verified
- MFA enabled
- Root credentials protected
Billing
- Billing dashboard understood
- Budget or billing alert configured
- Current free-tier eligibility checked
- Pricing reviewed before creating resources
Region
- Primary Region selected
- Required services available in that Region
- Region checked before creating resources
Security
- IAM concepts understood
- Credentials never committed to Git
- Secrets not hardcoded in applications
This may look like a lot before writing your first line of cloud code.
But learning these habits early can prevent much bigger problems later.
15. What I Want to Build
Now that the basic AWS environment is understood, it's time to start building.
The project we'll gradually work toward will look something like this:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
User
|
v
Internet
|
v
+-------------+
| AWS Service |
+-------------+
|
v
Backend API
|
v
DatabaseWe'll start simple.
Then we'll gradually introduce:
1
2
3
4
5
6
7
8
9
10
11
12
Frontend
|
v
API / Backend
|
+---------+---------+
| |
v v
Database Storage
|
v
MonitoringEventually, we'll explore more advanced components such as:
- Authentication
- Serverless functions
- CI/CD
- Infrastructure as Code
- Monitoring
- AI services
- Scalability
- Security
- Cost optimization
But we won't build everything at once.
One service at a time.
16. What I Learned From This Setup
Even before deploying an application, there are several important concepts to understand.
1. AWS is much more than virtual machines
EC2 is only one part of the AWS ecosystem.
AWS provides services for compute, storage, networking, databases, security, analytics, AI, monitoring, and much more.
2. Region selection matters
Resources are often tied to specific Regions, so understanding where your resources are deployed is important.
3. Security starts with the account
IAM and MFA aren't advanced topics that can be postponed until production.
They are foundational concepts.
4. Cloud costs require attention
Cloud platforms provide flexibility, but that flexibility also means resources can continue running and generating costs if they aren't managed properly.
5. The Console is only the beginning
As I become more comfortable with AWS, I want to move from manually clicking through the Console toward:
1
2
3
4
5
6
7
8
9
Console
↓
CLI
↓
SDKs
↓
Infrastructure as Code
↓
AutomationThis is where cloud development starts becoming much more powerful.
17. What's Next?
Now that the AWS account and basic concepts are in place, it's time to actually deploy something.
In the next article, I'll take a locally running application and attempt to move it to the cloud.
We'll start with Amazon EC2.
I'll cover:
- What EC2 actually is
- Choosing an instance
- Understanding AMIs
- Instance types
- Key pairs
- Security groups
- Connecting to the server
- Installing the required runtime
- Deploying an application
- Accessing it from the internet
- Understanding the cost implications
- Cleaning up the resources afterward
The goal will be simple:
1
2
3
4
5
6
7
8
LOCALHOST
|
| Deploy
v
AWS
|
v
PUBLIC APPLICATIONThat's where the real hands-on part of this journey begins.
Final Thoughts
Starting with AWS can feel overwhelming because there are hundreds of services and an enormous amount of documentation.
But you don't need to learn everything at once.
I'm approaching AWS the same way I learned programming:
Understand the concept → Build something → Break it → Fix it → Document it → Move to the next concept.
If you're also a student or developer beginning your cloud journey, you can follow along with this series and build your own version of the projects.
The objective isn't to become an AWS expert overnight.
It's to become comfortable enough with cloud technologies to understand how modern applications move from localhost to production.
Next article: Deploying My First Application on Amazon EC2 — From Localhost to the Cloud.
Series: AWS for Students — From Local Projects to the Cloud (4 articles)
- 2Learning AWS in Public: A Student Developer's Journey — Part 2 This article
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article