AWS Basics

Getting an AWS account set up is more straightforward than most people expect, though there are a few things worth knowing before you start. First off, you will need a working email address — this becomes your root account login, so do not use one you are planning to abandon anytime soon. You will also need a payment card, either credit or debit, because AWS asks for one even if you only plan to use free tier resources. It is mostly there for verification and to charge you if you go past the free limits.

On top of that, expect to hand over a phone number. AWS uses it to send a verification code during signup, and there is no real way around this step. You will also be asked for a billing address and to pick a support plan; the free Basic plan is fine for beginners. One thing that trips people up: the root account has full access to everything in your AWS environment, so once you are in, it is smart to set up a separate IAM user for daily work rather than using the root login constantly — but we will get into IAM properly in Unit 4.

The whole signup process usually takes ten to fifteen minutes if you have your card and phone ready. Once you clear identity verification, AWS places a small temporary hold on your card, and then you are in. From there you land on the AWS Management Console, which is essentially the control room for every service AWS offers.

One of the more confusing parts of AWS for newcomers is figuring out what actually costs money. There are four categories, and mixing them up is an easy way to get a surprise bill. First, there is Always Free — services, or parts of services, that never expire and never cost anything, no matter how long you have had your account, as long as you stay under the usage limits.

Then there is the 12 Months Free tier, which applies to specific resources like a certain number of EC2 hours per month, but only for the first year after you sign up. After that year ends, you are billed at standard rates whether you notice or not. Trials are a different thing entirely — usually 30 to 90 days, and tied to a specific service rather than your whole account. They exist so you can test something like a database engine or a machine learning tool before committing to it.

And then, of course, there is everything else: standard paid usage, billed by the hour, by the gigabyte, or by the request, depending on the service. Arguably the biggest mistake beginners make is assuming "free tier" means "free forever" — it does not, not for most services. Set a billing alarm early on; AWS lets you do this from the Billing dashboard, and it is one of the smartest five-minute tasks a new user can do.

Unit 3 covers two of the most fundamental AWS services: EC2 and S3. EC2, short for Elastic Compute Cloud, is essentially a virtual machine you rent by the hour, or by the second depending on the instance type. Think of it as renting a computer that lives somewhere in an AWS data center instead of on your desk. You choose the operating system, the amount of CPU and memory, and the storage size, and AWS spins up that machine for you within minutes. People use EC2 for hosting websites, running background jobs, training models, and much more. The free tier includes 750 hours a month of a small instance type for the first year, enough to keep one instance running continuously if you are careful.

S3, or Simple Storage Service, works differently. Rather than a virtual computer, it is cloud storage for files — images, backups, videos, documents, whatever you need to keep somewhere durable and accessible. Files in S3 live inside "buckets," which function a bit like top-level folders, though the internal structure is technically flat rather than hierarchical. What makes S3 popular is not just the storage itself but the reliability behind it; AWS designs S3 for what they call eleven nines of durability, meaning the odds of losing a file are vanishingly small.

A common beginner project pairs the two: host a website's backend on EC2 while storing static assets like images on S3. It is a pattern you will see constantly once you start building real projects.

The final unit is about security, and if there is one lesson to take from this whole course, it is this one. AWS operates on what is called the Shared Responsibility Model — AWS secures the underlying infrastructure, but you are responsible for how you configure and use it. Misconfigured permissions are, by a wide margin, the most common cause of security incidents on AWS, not some sophisticated hack.

This is where IAM, Identity and Access Management, comes in. IAM lets you create individual users, each with their own login and their own permissions, instead of everyone sharing the root account. You can group users, attach specific policies that say what someone can or cannot do, and even set up roles that grant temporary access rather than permanent credentials. A good rule of thumb: give people, and applications, only the permissions they actually need, nothing more. This is usually called the principle of least privilege, and it is one of the more important habits to build early.

A few other basics worth mentioning: enable multi-factor authentication on your root account immediately, never share access keys in code repositories or chat messages, and rotate credentials periodically. AWS also provides tools like CloudTrail for logging every action taken in your account, which becomes invaluable if you ever need to investigate what happened and when. Security in AWS is not a one-time setup — it is an ongoing habit. Get IAM right early, and most of the bigger risks take care of themselves.