DevOps with AWS

01. Runtime and Deployment Foundations

What changes between running an app on my laptop and running it for users?

• DevOps ownership: development, operations, environments, and the software delivery lifecycle.
• Linux and the shell: files, permissions, pipes, exit codes, and useful diagnostic commands.
• Processes and services: ports, signals, background work, CPU, memory, and disk.
• Build artifacts and dependencies: lockfiles, reproducible builds, static output, and server runtimes.
• Configuration: environment variables, build-time versus runtime values, and secrets versus public configuration.
• Request fundamentals: DNS, TCP, TLS, HTTP, proxies, browser errors, and server errors.

Focus: Build the vocabulary before opening the AWS console.

Practice milestone: Build and serve your frontend locally, inspect its process and port, then diagnose an incorrect environment value and a stopped server.

02. AWS Accounts, Access, and Costs

Who can change my infrastructure, in which account, and at what cost?

• Cloud responsibility: managed services, shared responsibility, Regions, Availability Zones, and resource scope.
• Account setup: root user protection, MFA, IAM Identity Center, and temporary credentials.
• Authorization: principals, roles, trust policies, permission policies, least privilege, and explicit deny.
• Daily access: console, CLI profiles, SDK credentials, account identity, Region selection, and session expiry.
• Environment isolation: development, staging, production, account boundaries, and tagging.
• Cost basics: pricing dimensions, budgets, alerts, Cost Explorer, quotas, resource inventory, and teardown.

Focus: Complete this group before provisioning paid lab resources.

Practice milestone: Set up a learning account and budget notifications, verify the CLI account and Region, and explain a deliberately denied read operation.

03. Networking and Request Paths

How does a request reach the right service, and where can it stop?

• Addressing: IP addresses, CIDR ranges, ports, DNS records, and Route 53.
• VPC layout: public and private subnets, route tables, internet gateways, and NAT.
• Network controls: security groups, network ACLs, ingress, egress, and VPC endpoints.
• HTTPS: certificates, AWS Certificate Manager, TLS termination, and certificate renewal.
• Traffic routing: reverse proxies, Application Load Balancers, target groups, and health checks.
• Diagnosis: DNS failure, connection timeout, refused connections, TLS errors, CORS, and VPC Flow Logs.

Focus: Learn to draw the request path and distinguish access from reachability.

Practice milestone: Draw browser-to-service traffic and trace one failed request. Predict the result of a route or security-group change before trying it.

04. Frontend Hosting and Edge Caching

How do users receive the correct frontend release quickly and securely?

• Hosting choices: static SPA, static export, server rendering, and managed hosting with Amplify.
• Object hosting: S3 buckets, objects, metadata, private origins, and CloudFront origin access control.
• Edge delivery: CloudFront distributions, origins, behaviors, domains, and HTTPS.
• Cache correctness: Cache-Control, cache keys, asset hashing, HTML freshness, and invalidation.
• Frontend routing: deep links, fallback handling, missing assets, and meaningful HTTP status codes.
• Release consistency: asset upload order, old browser tabs, API compatibility, preview environments, and rollback.

Focus: Make this your first complete AWS application deployment.

Practice milestone: Deploy a static frontend through CloudFront with a private S3 origin. Verify a deep link and a new release, then restore the previous release.

05. Compute, Containers, and Scaling

Where should this workload run, and what will I still need to operate?

• Compute models: virtual machines, containers, functions, and the operational trade-offs.
• EC2 basics: instances, images, storage, service management, patching, and Systems Manager access.
• Container basics: Dockerfiles, image layers, registries, ports, volumes, and local Compose workflows.
• Container delivery: ECR, image tags and digests, image scanning, and architecture compatibility.
• ECS with Fargate: task definitions, services, roles, resource sizing, health checks, and load balancing.
• Serverless and scaling: Lambda, API Gateway, cold starts, concurrency, statelessness, and autoscaling.

Focus: Practice containers on ECS with Fargate; compare other models before adding them.

Practice milestone: Containerize an existing sample API, publish it to ECR, and run it on ECS with Fargate. Diagnose a failed health check and compare this design with Lambda.

06. Data, Secrets, and Messaging Operations

Which dependencies hold state, and how does the app use them safely?

• Storage choices: object, block, and file storage; S3, EBS, EFS, and ephemeral container filesystems.
• Database operations: RDS connectivity, connection limits, migrations, snapshots, and restore planning.
• Managed data choices: relational databases, DynamoDB access patterns, and ElastiCache.
• Secrets and encryption: Secrets Manager, Parameter Store, KMS, rotation, and application access.
• Asynchronous work: SQS queues, SNS notifications, EventBridge routing, retries, and dead-letter queues.
• Dependency failure: timeouts, duplicate delivery, idempotency, backpressure, and data retention.

Focus: Study how to operate dependencies; leave backend business logic and database design to the separate backend track.

Practice milestone: Use a prepared app to access one managed dependency with a workload role. Rotate a test secret or diagnose a dependency failure, then clean up the lab.

07. CI/CD and Release Engineering

How does a reviewed commit become a release I can verify and reverse?

• Git collaboration: pull requests, branch protection, reviews, release tags, and traceability.
• Continuous integration: install, lint, tests, build, dependency scanning, artifacts, and cache correctness.
• Deployment identity: GitHub Actions OIDC, AWS roles, trust conditions, and environment permissions.
• Delivery pipelines: build once, artifact promotion, staging, production approvals, and concurrent deployments.
• Release strategies: rolling updates, blue-green, canary, feature flags, and database compatibility.
• Release verification: smoke tests, health checks, rollback triggers, previous artifacts, and pipeline diagnosis.

Focus: Use GitHub Actions with AWS as the primary practice path.

Practice milestone: Deploy the frontend from a reviewed commit using temporary AWS credentials. Promote a known artifact and rehearse rollback after a failed smoke test.

08. Infrastructure as Code and AI-Assisted Changes

Can I explain and reproduce an infrastructure change before applying it?

• Desired state: declarative infrastructure, dependencies, idempotency, and resource ownership.
• CloudFormation lifecycle: stacks, templates, change sets, updates, replacements, and deletion policies.
• CDK workflow: constructs, synthesis, diffs, deployment, reusable boundaries, and environment configuration.
• Terraform literacy: providers, plans, state, locking, drift, and why state must be protected.
• Existing infrastructure: imports, console drift, configuration review, and recovery from partial failure.
• AI review: resource diffs, IAM scope, public exposure, data replacement, expected cost, and cleanup.

Focus: Use AWS CDK in TypeScript for the main lab, understand CloudFormation underneath, and learn Terraform concepts for recognition.

Practice milestone: Recreate the frontend infrastructure as code. Ask AI to propose a small change, predict the diff yourself, review it, apply it in the lab, and verify the result.

09. Observability and Incident Diagnosis

How do I know users are affected, and what evidence narrows down the cause?

• Operational signals: logs, metrics, traces, structured events, and correlation IDs.
• CloudWatch: log groups, retention, metric dimensions, dashboards, alarms, and Logs Insights.
• End-to-end diagnosis: frontend errors, synthetic checks, request tracing, and OpenTelemetry concepts.
• Audit and network evidence: CloudTrail, VPC Flow Logs, deployment history, and access changes.
• Service health: latency percentiles, traffic, error rate, saturation, SLIs, SLOs, and alert quality.
• Incident workflow: triage, mitigation, rollback, communication, runbooks, and blameless postmortems.

Focus: Build the habit of diagnosing from evidence before changing configuration.

Practice milestone: Break a lab deployment deliberately, detect the symptom, trace the cause, restore service, and write a short incident note with evidence.

10. Reliability, Cost, and Architecture Judgment

Can this system survive a failure, and is its complexity worth the cost?

• Failure boundaries: single points of failure, Availability Zones, health checks, failover, and capacity limits.
• Recovery: backups versus availability, restore drills, RPO, RTO, and disaster recovery choices.
• Load behavior: load testing, autoscaling lag, rate limiting, caching, and graceful degradation.
• Cost and security review: idle resources, data transfer, NAT, logs, storage lifecycle, WAF, and access review.
• Architecture decisions: Well-Architected review, managed-service trade-offs, and documenting why a design fits.
• Advanced awareness: Organizations, multi-account governance, multi-Region systems, Kubernetes/EKS, and platform engineering.

Focus: Bring the earlier groups together; advance by explaining trade-offs and testing recovery.

Practice milestone: Review your deployed project, run one recovery drill, estimate its ongoing cost, and explain which advanced components it does not yet need.

One project that grows with me

Use a small frontend project and a prepared API with a health endpoint. Add one dependency when group 6 needs it. Backend implementation can remain simple while the deployment becomes more realistic.

1. Serve it locally and explain its build output.
2. Publish the frontend through a domain and HTTPS.
3. Deploy the sample API and explain the complete request path.
4. Add one managed dependency and workload permissions.
5. Automate a release and recover the previous working version.
6. Recreate the infrastructure from code.
7. Detect a deliberate failure, restore service, and write an incident note.

Each milestone should leave evidence: a diagram, a request trace, a reviewed diff, a deployment record, or a restore result. A green console status alone is not the learning goal.

Working with AI

Let AI draft; learn to judge the result.

AI can help draft policies, pipeline files, infrastructure code, and diagnostic commands. My job is to explain what will change, who gains access, what can fail, and how I will verify or reverse it.

Before applying generated configuration, I will ask:

• Which account, Region, and resources does this affect?
• What permissions and network access does it create?
• What data could be replaced or deleted?
• What costs remain while the application is idle?
• Which observation would prove the change worked?
• What is the recovery and cleanup plan?

I can ask AI to quiz me, explain a diff, or suggest a failure experiment. For each lab, I will first predict the outcome myself, then compare that prediction with what actually happened.

Make cost part of every lab.

Estimate before provisioning, track the resources created, and verify cleanup afterward. Budget notifications are not a universal spending cap; check the account's current pricing and eligibility rather than assuming a lab is free. See AWS Budgets.

What I will add as I study

Each group starts as a topic outline. As I work through a topic, I will add its mental model, a small experiment, the observed result, a real failure case, and the source that verifies the behavior. Configuration examples will record relevant versions and assumptions.

Ready to move on

I can explain the design without reading the configuration, predict one failure, find evidence of it, and recover from it in my lab. I do not need to memorize every service option.

Gotchas to revisit

Looks like	Actually	Why
A successful deployment finishes the work	Verification and recovery are part of delivery	Users experience the running system
Knowing AWS means memorizing every service	Daily judgment starts with request paths, identity, state, and failure	Services are implementations of those concepts
AI generated a valid configuration	I still need to assess whether the design fits	Syntax does not express my full operational intent
Advanced architecture is the next requirement	Complexity needs a demonstrated reason	Each component adds ownership and failure modes

Resources

• AWS services by category: locate a service by the problem it solves.
• IAM best practices: establish human and workload access.
• AWS Well-Architected Framework: evaluate architecture trade-offs as the project grows.

The linked group files contain the more specific reading. This roadmap is a learning sequence, not a certification syllabus or a requirement to deploy every named service.