Amazon Web Services Beginner

Cloud computing is renting computing resources — servers, storage, databases, networking — over the internet, paying only for what you use instead of buying and running your own hardware.

Amazon Web Services (AWS) is the largest cloud provider. It offers hundreds of services you call through a web console, a command-line tool, or an API. The three classic delivery models are:

• IaaS (Infrastructure as a Service) — raw virtual machines and storage, e.g. EC2.
• PaaS (Platform as a Service) — a managed platform you deploy code onto, e.g. Elastic Beanstalk.
• SaaS (Software as a Service) — finished software you just use, e.g. a hosted email app.

The big wins are elasticity (scale up or down on demand), pay-as-you-go pricing, and no upfront capital cost.

To use AWS you create an account tied to an email and a payment method. The very first identity created is the root user — it has unrestricted power and should be locked away (we cover that under IAM).

New accounts get the AWS Free Tier, which has three flavours:

• 12-month free — e.g. 750 hours/month of a t2.micro or t3.micro EC2 instance, and 5 GB of S3, for the first year.
• Always free — e.g. 1 million AWS Lambda requests per month, forever.
• Trials — short-term free use of specific services.

The free tier is a great sandbox, but you can still be billed if you exceed limits — so set up a budget early (covered later).

The AWS Management Console is the web UI at console.aws.amazon.com. Every service has its own page, and a Region selector sits in the top-right — most resources you see depend on the Region you have selected.

AWS CloudShell is a browser-based terminal built into the console. It launches a Linux shell that is already authenticated as your console identity, with the aws CLI pre-installed — so you can run commands without configuring anything locally.

CloudShell gives you 1 GB of persistent storage in your home directory per Region, and is itself free (you pay only for resources it creates).

The AWS CLI is a command-line tool that talks to every service. On your own machine you install it, then run aws configure to store an access key, secret key, default Region and output format in ~/.aws/.

Every command follows the same shape: aws <service> <operation> [--options]. The CLI returns JSON by default, which you can filter with --query or reformat with --output table.

Prefer IAM roles over long-lived access keys when you can; keys stored on disk are a common source of leaks.

AWS hardware is organised into a hierarchy:

• A Region is a separate geographic area (e.g. eu-north-1 in Stockholm). Regions are isolated from each other for fault tolerance and data residency.
• An Availability Zone (AZ) is one or more discrete data centres inside a Region, with independent power and networking. Each Region has multiple AZs (e.g. eu-north-1a, eu-north-1b).
• Edge locations are many smaller sites used by content-delivery and DNS services (CloudFront, Route 53) to serve users with low latency.

Spreading resources across several AZs is the simplest way to survive a single data-centre failure.

IAM (Identity and Access Management) controls who can do what in your account. Its building blocks:

• Users — a person or app with long-term credentials.
• Groups — a collection of users that share permissions.
• Roles — a set of permissions that can be assumed temporarily, ideal for EC2 instances or other AWS services.
• Policies — JSON documents that grant or deny specific actions on specific resources.

IAM is deny by default: an action is allowed only if a policy explicitly allows it and nothing explicitly denies it.

The root user can do anything, including closing the account and changing billing — so you should almost never use it. Best practice:

• Use root only for the handful of tasks that require it, then log out.
• Create an IAM admin user (or use IAM Identity Center) for daily work.
• Delete any root access keys — root should not have programmatic keys.
• Enable Multi-Factor Authentication (MFA) on root and on every privileged user.

MFA adds a second proof of identity (a code from an authenticator app or a hardware key) on top of the password, so a stolen password alone is not enough to log in.

Amazon EC2 (Elastic Compute Cloud) provides resizable virtual servers, called instances. To launch one you pick an AMI (a machine image / OS template), an instance type (size), and a key pair.

A key pair is an SSH public/private key. AWS keeps the public key on the instance; you keep the private .pem file. You connect over SSH using that private key — AWS never stores your private key, so if you lose it you cannot recover it.

To reach the instance, its security group must allow inbound SSH (port 22) from your IP, and the instance needs a public IP.

EC2 instance types are grouped by purpose and sized by a letter+number, e.g. t3.micro, m5.large, c6g.xlarge. Families include general-purpose (t, m), compute-optimised (c), memory-optimised (r) and more.

You also choose a pricing model:

• On-Demand — pay per second/hour, no commitment. Best for short or unpredictable workloads.
• Spot — bid on spare capacity for up to ~90% off, but AWS can reclaim the instance with a 2-minute warning. Great for fault-tolerant batch jobs.
• Reserved Instances / Savings Plans — commit to 1 or 3 years for a big discount on steady workloads.

Amazon S3 (Simple Storage Service) stores files as objects inside buckets. Bucket names are globally unique across all of AWS, and each object has a key (its path-like name) plus metadata.

S3 offers storage classes that trade cost against access speed:

• S3 Standard — frequent access, lowest latency.
• S3 Standard-IA / One Zone-IA — infrequent access, cheaper storage, retrieval fee.
• S3 Glacier / Deep Archive — very cheap long-term archive, slower retrieval.

By default buckets are private; you grant access deliberately with policies — never make a bucket public by accident.

Amazon EBS (Elastic Block Store) provides persistent block storage that attaches to an EC2 instance like a virtual hard drive. Unlike S3 (object storage), EBS is mounted as a filesystem and survives instance stops/starts.

• A volume lives in a single Availability Zone and can attach to instances in that same AZ.
• Common types: gp3 (general-purpose SSD), io2 (high-IOPS SSD), st1 (throughput HDD).
• You back up a volume with a snapshot, which is stored in S3 and can be copied across Regions.

Instance store (ephemeral) disks are faster but lost on stop — EBS is the durable choice.

A VPC (Virtual Private Cloud) is your own isolated network in AWS, defined by a CIDR range like 10.0.0.0/16. Inside it you carve out subnets, each living in one AZ.

• A public subnet has a route to an Internet Gateway (IGW), so resources can reach (and be reached from) the internet.
• A private subnet has no direct internet route; instances there reach out via a NAT gateway and stay unreachable from outside.
• A route table decides where traffic for a destination goes — adding 0.0.0.0/0 → IGW is what makes a subnet public.

Two firewall layers protect a VPC, and they behave differently:

• Security Groups act at the instance level. They are stateful — if you allow inbound traffic, the matching return traffic is automatically allowed. They support allow rules only.
• Network ACLs (NACLs) act at the subnet level. They are stateless — you must allow both inbound and outbound directions explicitly. They support both allow and deny rules and are evaluated in numbered order.

In practice you control most access with security groups and use NACLs as a coarse subnet-wide backstop.

An Elastic IP (EIP) is a static public IPv4 address you allocate to your account and attach to an instance. Unlike a default public IP (which changes when an instance stops), an EIP stays the same — handy for a fixed endpoint.

An Elastic Load Balancer (ELB) spreads incoming traffic across several instances, improving availability and scale. The common type is the Application Load Balancer (ALB), which routes HTTP/HTTPS traffic to a target group of instances and runs health checks, sending traffic only to healthy targets.

Putting an ALB in front of instances across multiple AZs is a standard way to build a resilient web tier.

Security in AWS is a partnership defined by the shared responsibility model:

• AWS is responsible for security of the cloud — the physical data centres, hardware, and the global infrastructure that runs the services.
• You are responsible for security in the cloud — your data, IAM permissions, OS patching on EC2, security-group rules, and encryption settings.

The split shifts with the service. For a managed service like S3 or Lambda, AWS handles more of the stack; for raw EC2, you manage the guest OS and everything above it. Misconfiguration on your side (e.g. a public bucket) is your responsibility, not a failure of AWS.

AWS charges per service and per usage; there is no single flat fee. To stay in control:

• AWS Pricing Calculator — estimate costs before you build.
• Cost Explorer — visualise and analyse your historical spend, broken down by service, Region or tag.
• AWS Budgets — set a spending or usage threshold and get alerted (or take action) when you approach it.

Setting a small monthly budget with an email alert on a new account is the single best habit to avoid surprise bills — do it on day one.

A tag is a simple key/value label you attach to almost any AWS resource, e.g. Environment=production or Owner=alice. Tags carry no inherent meaning to AWS but are powerful for organising your account:

• Cost allocation — group spend by project, team or environment in Cost Explorer.
• Automation — scripts and policies can target resources by tag.
• Access control — IAM policies can allow actions only on resources with a given tag.

Agree on a tagging convention early; retro-tagging a sprawling account is painful.

Infrastructure as Code (IaC) means describing your resources in a text file instead of clicking through the console. AWS CloudFormation is the native IaC service.

You write a template (YAML or JSON) listing the resources you want, then deploy it as a stack. CloudFormation figures out the order, creates everything, and tracks it as one unit — so you can update or delete the whole stack reproducibly.

Benefits: version-controlled infrastructure, repeatable environments, and easy teardown (deleting the stack removes everything it created).

Let us tie it together and put a real website online. The steps:

1. Launch a free-tier EC2 instance from an Amazon Linux AMI in a public subnet.
2. Attach a security group allowing inbound HTTP (80) from anywhere and SSH (22) from your IP.
3. Use a user-data script to install and start a web server automatically on first boot.
4. Browse to the instance public IP to see the page.

User data is a script the instance runs once at launch — perfect for bootstrapping software without logging in.

AWS certifications validate your skills and map nicely to a learning journey:

• AWS Certified Cloud Practitioner — the foundational, mostly non-technical exam covering the concepts in this course: services, pricing, the shared responsibility model and the cloud value proposition. A great first goal.
• AWS Certified Solutions Architect – Associate — the popular next step, going deeper into designing resilient, cost-effective architectures with EC2, S3, VPC, IAM and more.
• Beyond that sit other Associate, Professional and Specialty certifications.

A common path is Cloud Practitioner → Solutions Architect Associate, building on exactly the fundamentals you have just learned.