AWS Cloud

AWS is Amazon's cloud platform — the largest by service breadth and market share, organized around independently-billed services rather than one monolithic platform. Its core structural ideas (regions/AZs, IAM, VPC) recur across nearly every other service.

Regions, Availability Zones, and global services

• A Region is an independent geographic area (e.g. us-east-1); an Availability Zone (AZ) is one or more discrete, isolated datacenters within a region with independent power/networking. Spreading resources across AZs (not just regions) is the standard way to survive a single datacenter failure.
• Most services are region-scoped (you pick a region when creating a resource); IAM, Route 53, and CloudFront are notable global services with no region selection.

Identity and access: IAM

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": ["s3:GetObject"],
    "Resource": "arn:aws:s3:::my-bucket/*"
  }]
}

• Users, groups, and roles are the core IAM identities; policies (JSON documents like the one above) attach permissions to them. A role is assumed temporarily (by a service, another account, or federated identity) rather than tied to one person's long-lived credentials — the preferred pattern over embedding long-lived access keys in application code.
• Least privilege is the governing principle: scope a policy's Resource and Action as narrowly as the task requires, rather than reaching for a wildcard "*" to make an error go away.

Core service map (by category, not exhaustive)

| Category | Common services | | --- | --- | | Compute | EC2 (VMs), Lambda (serverless functions), ECS/EKS (containers), Fargate (serverless containers) | | Storage | S3 (object storage), EBS (block storage for EC2), EFS (managed NFS) | | Database | RDS (managed relational: Postgres/MySQL/etc.), DynamoDB (managed NoSQL), Aurora (AWS's own MySQL/Postgres-compatible engine) | | Networking | VPC, Route 53 (DNS), CloudFront (CDN), API Gateway | | Identity/security | IAM, Cognito (app user auth), Secrets Manager, KMS | | Messaging/integration | SQS (queues), SNS (pub/sub), EventBridge (event bus) | | Observability | CloudWatch (metrics/logs/alarms), X-Ray (tracing) |

Infrastructure as code

aws s3 ls                          # AWS CLI: list buckets
aws sts get-caller-identity        # check which identity/role you're using

# CloudFormation (AWS-native IaC)
Resources:
  MyBucket:
    Type: AWS::S3::Bucket

Three common ways to provision AWS infrastructure as code: CloudFormation (AWS-native YAML/JSON templates), the AWS CDK (define infrastructure in a real programming language — TypeScript, Python, etc. — which synthesizes to CloudFormation), and Terraform (HashiCorp's cloud-agnostic tool, widely used for AWS despite not being AWS-native). Prefer one of these over manual console clicks for anything meant to be reproducible or reviewed.

The shared responsibility model

AWS secures "the cloud" (physical infrastructure, hypervisor, managed-service internals); the customer secures "in the cloud" (IAM policies, security group rules, data encryption choices, patching an EC2 instance's OS). A misconfigured public S3 bucket or an overly permissive security group is a customer-side failure under this model, not an AWS failure, however common it is in incident writeups.

Common pitfalls

• Long-lived IAM access keys committed to source control or embedded in code — prefer roles (assumed by EC2/Lambda/ECS via an instance/execution role) so credentials are never a static secret to leak in the first place.
• A public S3 bucket by accident — check Block Public Access settings and bucket policies explicitly; this is one of the most common real-world AWS security incidents.
• Choosing EC2 by default without considering Lambda/Fargate — for event-driven or intermittent workloads, a managed compute service can remove a whole category of patching/scaling operational work that a raw EC2 fleet requires.
• Ignoring AZ placement — provisioning everything in one AZ defeats the purpose of a multi-AZ region; a Multi-AZ RDS deployment, for example, is a deliberate, named option, not the default.
• Not tagging resources — cost attribution and cleanup both depend on consistent tagging; an untagged sprawl of resources is a common source of "what is this and can we delete it" months later.

Learn more

• AWS documentation
• AWS Well-Architected Framework — the canonical cross-cutting best-practices reference.
• AWS CLI reference, AWS CDK docs
• Terraform AWS provider docs