Your AWS account is the boundary for billing and administration. Protect the root user with MFA and use it only for account-level tasks (billing, closing the account). For everyday work, use IAM users or your organization’s identity provider. Turn on AWS Budgets and alerts so spend is visible early.

A Region is a geographic area with multiple Availability Zones (isolated datacenters). You choose a Region when you create most resources. An ARN (Amazon Resource Name) uniquely identifies a resource in API calls and policies. The AWS SDK (for example boto3 or @aws-sdk/client-s3) signs requests so your code does not implement raw cryptography by hand.

Picture AWS as a city: EC2 is renting an office building you manage yourself. S3 is the warehouse district for objects. IAM is the security desk — who may enter which building. Lambda is a courier that shows up only when called. VPC is the gated community where you control roads and gates. The cards below name every core service beginners touch most often; later modules go deeper.

Imagine AWS as a corporate office building. Everything inside — compute, storage, databases — is a service. IAM is the security system for who enters, which rooms they may use, and what they may do there.

An IAM User is a full-time employee with a photo ID. They have a permanent badge with their name. They sign in to the console with a password (humans) or use access key ID + secret for the CLI and SDK (automation). One person, one User — never share a User between people, or you lose audit trails and clean revocation.

IAM Groups batch users for the same job: attach policies to Developers or ReadOnly, add users to the group, and everyone inherits the same permissions. Prefer attaching policies to groups, not directly to users, so moves between teams are a group membership change.

The root user created the account. It can do things no IAM user can (for example close the account or change billing). Do not use root for daily work. Enable MFA on root, create a personal IAM administrator for yourself, and leave root logged out until you truly need it.

An IAM Role is a contractor badge kept in a drawer at reception. When a delivery robot (for example Lambda) arrives, reception hands it the badge. The robot enters only the rooms allowed on the access list, finishes the job, and returns the badge. The badge has no permanent owner — AWS issues short-lived credentials when the role is assumed. That is why Lambda, EC2, and Bedrock use roles, not long-lived user keys in code.

An IAM Policy is the laminated list on each door: who may enter, which actions they may perform inside (read, write, delete), and which rooms (resources) the rule applies to. In JSON, that is Effect (Allow/Deny), Action, and Resource — plus optional Condition. A User or Role only gains power when a policy is attached.

Default is deny. Nothing is allowed until a policy Allow says so. An explicit Deny always wins over Allow — use Deny for guardrails nobody can override with a broader Allow elsewhere.

A trust policy on a role answers: who may assume this role (for example lambda.amazonaws.com). Permission policies answer: what may this role do once assumed (for example s3:GetObject on one bucket ARN). Mixing them up is a common source of “I attached a policy but nothing works.”

A VPC is your isolated network in a Region. You split it into subnets across Availability Zones. Route tables send traffic to an Internet Gateway (public subnets), a NAT gateway (private outbound), or VPC endpoints (private access to AWS APIs). Security groups are stateful firewalls attached to ENIs; network ACLs are optional subnet-level rules.

The gated community mental model still fits: you decide what is visible from the internet and what stays internal. Start with default VPC documentation in your Region, then learn public vs private subnets before running databases or internal APIs.

EC2 gives you full control of a virtual server: AMI, instance family, storage, and patching. Attach an IAM instance profile (a role) so applications use temporary credentials. Lambda runs a handler on events (HTTP, queues, schedules) with no servers to SSH into; watch timeouts, memory, and cold starts.

S3 stores objects in buckets with global unique names. Use Block Public Access, encryption, and IAM or bucket policies — not accidental public ACLs. Secrets Manager stores API keys and database passwords with optional rotation; grant GetSecretValue via IAM to Lambdas or EC2 roles instead of baking secrets into images.

API Gateway fronts HTTP or WebSocket APIs with throttling, authentication, and integration to Lambda or HTTP backends. DynamoDB is a managed key-value and document store: design partition keys for even access patterns; use on-demand or provisioned capacity.

SQS buffers work between services with visibility timeouts and dead-letter queues for poison messages. Kinesis ingests streams for real-time analytics and fan-out consumers. Together they let you build pipelines that stay responsive under load.

Amazon Bedrock exposes foundation models through a single API so you are not operating GPU fleets. Knowledge Bases combine retrieval with models for RAG — answers grounded in your documents stored in S3 or connected sources. Model and feature availability varies by Region; check quotas and pricing where you deploy.

CloudWatch is where logs, metrics, and alarms live for Lambda, API Gateway, and nearly every service. CloudTrail records management events — who changed IAM, bucket policies, or network rules — which you need for security reviews and compliance. Pair observability with least-privilege IAM from modules 02–03.