What is AWS
Cloud basics
Learn how on-demand, pay-as-you-go cloud infrastructure replaces buying hardware.

This page is a self-contained introduction to AWS (Amazon Web Services)—the cloud platform behind EC2, S3, and dozens of other on-demand services. You will understand what AWS is, the core cloud concepts, the handful of services CodeToFun’s guides cover, and where to go next in the topic index.
Cloud basics
Learn how on-demand, pay-as-you-go cloud infrastructure replaces buying hardware.
Where things run
Understand Regions, Availability Zones, and why placement affects latency and uptime.
Virtual servers
Meet EC2 instances—the virtual machines that run your code.
Object storage
Store and serve files at scale with Amazon S3 buckets.
ALB · Route 53 · CloudFront
Route traffic, resolve DNS, and cache content at the edge.
Full roadmap
Jump from launching EC2 to load balancing, CDN, storage, and TLS.
Amazon Web Services (AWS) is a cloud computing platform that rents compute, storage, database, and networking capacity over the internet, billed by usage instead of a flat monthly fee. It launched in 2006 and remains the most widely used cloud provider, with data centers organized into Regions and Availability Zones around the world.
Instead of buying physical servers, you provision an EC2 virtual machine in minutes, store files in an S3 bucket, and let a load balancer or CDN route traffic—all through the AWS console, the AWS CLI, or infrastructure-as-code tools.
Because every resource is an API call, you can script deployments, scale up for a traffic spike, and scale back down afterward—something much harder to do with a single rented server.
Most production websites, APIs, and startups run at least part of their infrastructure on a cloud provider. AWS gives you global reach, managed services that would take a team to build in-house, and pricing that scales with your actual traffic—so a side project and a growing product can share the same building blocks.
Dozens of Regions worldwide, so you can place resources close to your users.
Billed for what you use—by the second or hour—no large upfront hardware spend.
Offload databases, load balancing, and DNS instead of running them yourself.
Fine-grained permissions via IAM users, roles, and policies—least privilege by design.
In short: AWS rents cloud infrastructure by the second. Pick a Region, launch services like EC2 and S3, secure them with IAM, and pay only for what you use.
Once the AWS CLI is installed and configured with credentials, the first thing worth running is an identity check—it confirms your setup works before you touch any real resources:
aws sts get-caller-identity | Term | Meaning |
|---|---|
| AWS CLI | Official command-line tool; installs on Windows, macOS, and Linux and talks to every AWS API. |
| credentials | An access key ID and secret, stored via aws configure in ~/.aws/credentials—never hard-code these in source. |
| STS | Security Token Service—the API group behind get-caller-identity and temporary session credentials. |
| Account / ARN | Your 12-digit account ID and the full Amazon Resource Name identifying exactly who (or what) made the call. |
CodeToFun’s AWS guides focus on this small set of services—enough to run and secure a real web app. Each links to its dedicated tutorial:
| Service | Description | Tutorial |
|---|---|---|
| EC2 | Resizable virtual machines that run your application code | Launch an EC2 instance |
| Elastic IP | A static public IP address you attach to an EC2 instance | Elastic IP for EC2 |
| Target Groups | Named sets of instances that a load balancer routes traffic to | Target groups |
| Application Load Balancer | Layer 7 load balancer that spreads HTTP(S) traffic across targets | Application Load Balancer |
| Route 53 | Managed DNS—domains, hosted zones, and records | Route 53 |
| CloudFront | Content delivery network (CDN) that caches content at edge locations | CloudFront |
| S3 | Durable object storage for files, backups, and static assets | Amazon S3 |
| ACM | Free managed TLS/SSL certificates for load balancers and CloudFront | AWS Certificate Manager |
| HTTP → HTTPS | Listener rule pattern that redirects plain HTTP to encrypted HTTPS | Redirect HTTP to HTTPS |
Start with Launch an EC2 instance—the recommended first hands-on guide—then explore the rest.
| Task | Example |
|---|---|
| Configure credentials | aws configure |
| Check identity | aws sts get-caller-identity |
| List S3 buckets | aws s3 ls |
| Upload a file to S3 | aws s3 cp file.txt s3://my-bucket/ |
| List running EC2 instances | aws ec2 describe-instances --filters "Name=instance-state-name,Values=running" |
| SSH into an instance | ssh -i key.pem ubuntu@<public-ip> |
| Switch default Region | aws configure set region us-east-1 |
All three run your app on someone else’s hardware—but they trade control for convenience differently.
granular servicesFine-grained building blocks (EC2, S3, ALB, Route 53…). Most control and scalability, more setup and IAM to manage.
single serverOne rented box (DigitalOcean/Linode-style) with a flat monthly price. Simple, but you patch, scale, and secure it yourself.
git push deployHeroku-style platforms manage the infrastructure entirely. Fastest to ship, least infrastructure control, often pricier at scale.
Learn the AWS building blocks here, then decide per-project whether the extra control is worth the extra setup.
Reach for AWS when your project needs more than one server can comfortably give you.
Scale compute up for a launch or sale, then back down—instead of buying hardware for peak load.
Put content close to users with CloudFront edge locations and Regions on multiple continents.
Offload databases, queues, and storage instead of running and patching them yourself.
AWS remains the most widely used cloud platform in job postings and production stacks.
For one small hobby site, a $5 VPS or a free static host is often simpler—grow into AWS as needs multiply.
Key benefit: pay only for the exact compute, storage, and network you use—while keeping the option to add a service the moment you need it.
Browse every AWS tutorial on CodeToFun, grouped by learning path. Start with Launch an EC2 instance.
Five starter snippets. Use View Output to preview here, or open Try It Yourself to run a self-contained HTML page with a mock terminal (?tryit=1 through 5).
Verify your identity, then list what already exists in the account.
Run this before anything else—if it returns your account and ARN, the CLI is configured correctly.
aws sts get-caller-identity sts get-caller-identity asks AWS’s Security Token Service who the current credentials belong to. It returns your Account ID and the full Arn of the IAM user or role—no permissions on other services required.
List every bucket in the account, with its creation date.
aws s3 ls aws s3 ls with no path lists every bucket owned by the account, oldest listing shown by creation timestamp. Add a bucket path (aws s3 ls s3://codetofun-assets/) to list the objects inside it.
Inspect running compute, visualize the request path, and reason about IAM policies.
Filter to running instances only, and trim the JSON response down to the fields that matter with --query.
aws ec2 describe-instances \
--filters "Name=instance-state-name,Values=running" \
--query "Reservations[].Instances[].[InstanceId,InstanceType,PublicIpAddress]" \
--output table --filters narrows the API response to running instances only, --query applies a JMESPath expression to keep just the ID, type, and public IP, and --output table pretty-prints the result for the terminal instead of raw JSON.
A simplified diagram of how a request reaches your app once CloudFront, an ALB, and EC2 are wired together.
<div class="flow">
<div class="node">User</div>
<div class="arrow">→</div>
<div class="node">CloudFront</div>
<div class="arrow">→</div>
<div class="node">ALB</div>
<div class="arrow">→</div>
<div class="node">EC2</div>
</div> CloudFront caches static content at the edge and forwards misses toward the origin; the Application Load Balancer receives the request and picks a healthy target; EC2 runs the code that returns the response. Learn each hop in the CloudFront and Application Load Balancer tutorials.
Grant public read access to one prefix only—not the whole bucket—a common, safer starting point for static assets.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "PublicReadOnlyForAssets",
"Effect": "Allow",
"Principal": "*",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::codetofun-assets/public/*"
}
]
} Principal: "*" means anyone can call the action, but Action is limited to reads and Resource is scoped to a single prefix—so the rest of the bucket, and every other action, stays denied by default. This is the least-privilege pattern: grant exactly what is needed, nothing more.
Real-world places AWS shows up behind everyday products.
EC2 instances run Node.js, Express, Next.js, React, and WordPress sites.
Example: a Node.js API behind an Application Load Balancer.
S3 stores images, downloads, logs, and database backups durably.
Example: a bucket serving public product images.
CloudFront caches pages and assets close to visitors on every continent.
Example: a CDN in front of an ALB for a marketing site.
Load balancers spread traffic across instances in multiple AZs.
Example: two EC2 instances behind one Application Load Balancer.
ACM issues free certificates so every listener serves HTTPS.
Example: redirecting all HTTP traffic to HTTPS at the ALB.
Free Tier limits make AWS a practical sandbox for cloud skills.
Example: deploying a personal project end-to-end on EC2 and S3.
Pro Tip: if your project only needs one always-on server with predictable traffic, weigh AWS against a simpler VPS before committing to the extra moving parts.
Why AWS is a strong default choice for hosting production workloads.
Add or remove EC2 instances and let a load balancer route around the change.
No large upfront hardware purchase; stop paying the moment you stop a resource.
DNS, CDN, load balancing, and certificates are all handled without extra servers.
The console, CLI, and SDKs all hit the same APIs—automate what you can click.
IAM policies scope permissions down to a single action on a single resource.
Pro Tip: set a billing alarm in the first five minutes of a new account—it is the cheapest insurance you will ever configure.
Follow these practices from your very first account.
Sign in with root only to create your first IAM admin user, then stop using root for daily work.
Resources in one Region are invisible from another—consistency avoids “where did my instance go?” confusion.
A simple CloudWatch billing alarm catches a forgotten instance before it becomes a surprise invoice.
Open SSH (port 22) only to your IP, not 0.0.0.0/0; open web ports only where the app actually listens.
A Project or Owner tag makes cleanup and cost tracking far easier later.
Pro Tip: know basic Node.js first—most of CodeToFun’s EC2 deployment guides assume a small Node.js, Express, or Next.js app to deploy.
Avoid these mistakes that cause most beginner AWS security and cost surprises.
0.0.0.0/0 foreverLeaving port 22 open to the whole internet invites constant brute-force scanning.
→ Restrict the security group rule to your own IP, or use Session Manager instead of a public SSH port.
Root has unlimited access and no permission boundaries—risky for everyday tasks.
→ Create an IAM admin user immediately and lock the root credentials away with MFA.
A forgotten test instance bills 24/7 even when nobody is using it.
→ Stop or terminate instances you are not actively using, and set a billing alarm as a backstop.
A misconfigured bucket policy or disabled “Block Public Access” setting can expose private files.
→ Keep Block Public Access on by default; open only specific prefixes when you truly need public reads.
Long-lived access keys committed to a repo or baked into client-side code get scraped and abused.
→ Use IAM roles for EC2 and CI/CD wherever possible, and rotate any key that ever leaked.
Pro Tip: if a bill looks wrong or a security group looks too open, check Cost Explorer and the security group rules first—those two catch most beginner surprises.
Create an AWS account with a payment method and enable MFA on the root user.
Stop using root for daily work; create an admin IAM user (or role) instead.
Choose a Region close to your users; every resource you launch lives inside it.
Start with EC2—pick an AMI, instance type, key pair, and security group.
Tighten security groups, set a billing alarm, and review IAM permissions as you grow.
Quick Takeaway: pick a Region, create an IAM user before you do anything else, launch EC2 or S3 for your first resource, and set a billing alarm on day one.
The AWS Management Console runs entirely in the browser—no separate app to install—while the AWS CLI is a small download for Windows, macOS, and Linux that talks to the same underlying APIs.
Manage every service from the browser-based console on any modern browser, or automate the same actions with the AWS CLI (or SDKs) on Windows, macOS, and Linux—no vendor lock-in on the client side.
Bottom line: Safe to explore, but remember the Free Tier has monthly limits, not unlimited free usage—set a billing alarm before you start clicking around.
AWS turns servers, storage, and networking into API calls you can script, scale, and pay for by the second. Its Free Tier makes it approachable for learning, and its managed services (S3, ALB, Route 53, CloudFront, ACM) save you from running that infrastructure yourself.
By understanding Regions, IAM, and the handful of services above, you can launch a real, secured web app—from a single EC2 instance to a load-balanced, CDN-fronted deployment.
Practice the five examples above, then continue to Launch an EC2 instance—the recommended first hands-on guide.
Pick a Region, create an IAM user, launch EC2 or S3, and set a billing alarm. Everything else in the topic index builds on those basics.
0.0.0.0/0 indefinitely* permissions on * resources out of convenienceStart renting cloud infrastructure the safe way.
Pay-as-you-go infrastructure
FoundationWhere resources live
PlacementCompute and storage basics
ServicesLeast-privilege security
SecurityYour first running instance
ActionAWS runs in Regions made of multiple Availability Zones. Prefer the closest Region for latency, keep backups cross-AZ, and use IAM least privilege—never put long-lived access keys in client-side code. AWS launched in 2006 starting with S3 and EC2—two of the very same services this page teaches today, nearly two decades later.
Open the AWS console, pick an AMI and instance type, and get a Ubuntu server running in minutes.
9 people found this page helpful