Course: SAA · High-Performing Architectures — Tracks: SAA — Level: SAA-C03 — ~38 min

Optimize global request paths with Route 53, CloudFront, Global Accelerator, load balancers, API Gateway, and private or hybrid connectivity.

Objectives

• Select Route 53 routing policies and health-check behavior.
• Differentiate CloudFront and Global Accelerator.
• Choose ALB, NLB, Gateway Load Balancer, and API Gateway from protocol and feature requirements.

Mental model

Route 53 answers DNS queries and can route by simple, weighted, latency, failover, geolocation, geoproximity, or multivalue policies. DNS TTL and resolver caching affect how quickly clients observe changes. Health checks can influence routing, but the endpoint and data tier must be ready.

CloudFront caches HTTP content at edge locations and supports edge security and origin controls. Global Accelerator provides static anycast IP addresses and routes TCP/UDP traffic over the AWS global network to healthy regional endpoints. They optimize different protocols and caching requirements.

Design

Choose from protocol and feature needs. Use CloudFront when caching, edge HTTP processing, or content delivery matters. Use Global Accelerator for static global IPs and improved noncacheable TCP/UDP paths. Use Route 53 policies for DNS-level routing among endpoints.

Decision rules

Operations

Monitor cache hit ratio, origin latency, 4xx/5xx, accelerator endpoint health, load balancer target health, DNS health-check state, and API throttling. Test routing changes with realistic resolver caching.

Failure modes

• Using CloudFront as if it were a general UDP accelerator.
• Using DNS failover without accounting for TTL and client caching.
• Selecting an NLB when path-based HTTP routing is a hard requirement.

Key points

• ALB provides Layer 7 HTTP/HTTPS routing; NLB provides high-performance Layer 4 TCP/UDP/TLS behavior and static IP patterns.
• Gateway Load Balancer deploys and scales virtual network appliances through transparent service insertion.
• API Gateway provides managed API front doors with authorization, throttling, transformations, stages, and integrations.
• Origin location, cache keys, TTLs, compression, connection reuse, and payload size all affect latency.

Example — Routing service comparison

Route 53           → DNS answer selection
CloudFront          → HTTP(S) CDN, edge cache, edge security
Global Accelerator  → global static IPs, TCP/UDP path optimization
ALB                 → regional HTTP(S) Layer 7 routing
NLB                 → regional TCP/UDP/TLS Layer 4 load balancing
Gateway LB          → transparent virtual appliance insertion
API Gateway         → managed REST/HTTP/WebSocket API front door

Related labs

• Repair a fragile web architecture (lab-resilient-web)
• Build a two-AZ VPC skeleton (lab-two-az-vpc)

Sources

• Amazon Route 53 Developer Guide — Networking
• Amazon CloudFront Developer Guide — Networking
• Amazon VPC User Guide — Networking

Course: SAA · High-Performing Architectures — Tracks: SAA — Level: SAA-C03 — ~37 min

Select streaming, delivery, query, catalog, ETL, warehouse, and transfer patterns from latency, ordering, transformation, scale, and connectivity needs.

Objectives

• Differentiate Kinesis Data Streams, Firehose, MSK, SQS, and EventBridge ingestion patterns.
• Choose Athena, Glue, Redshift, EMR, and OpenSearch for common analytics roles.
• Select DataSync, Storage Gateway, transfer services, acceleration, or Snow Family.

Mental model

Streaming services differ by consumer model and operational control. Kinesis Data Streams retains ordered records by shard/partition key for custom consumers. Firehose delivers streams to destinations with managed buffering and optional transformation. MSK provides managed Apache Kafka. SQS is a work queue rather than an analytics stream.

A common data-lake pattern stores durable raw and curated data in S3, catalogs schema with Glue, queries with Athena, and transforms with Glue, EMR, Lambda, or other engines. Redshift serves warehouse workloads, while OpenSearch supports search and operational analytics.

Design

Define event rate, size, ordering, replay, consumer count, delivery latency, transformation, and destination. For data movement, compare total bytes, available bandwidth, cutover window, change rate, encryption, and whether the source must remain online.

Decision rules

Operations

Monitor iterator age or consumer lag, throttling, delivery failure, malformed records, partition skew, S3 object layout, query bytes scanned, and transfer verification. Preserve a raw immutable landing zone when reprocessing is required.

Failure modes

• Using one partition key for all events and creating a hot shard.
• Sending tiny uncompressed files to a data lake and causing inefficient queries and metadata overhead.
• Choosing offline transfer without planning incremental synchronization before cutover.

Key points

• Partition keys determine ordering scope and traffic distribution in stream services.
• Firehose trades some buffering latency for managed delivery; Data Streams provides custom consumers and replay within retention.
• DataSync accelerates and automates online data movement; Storage Gateway provides hybrid storage interfaces; Snow Family supports offline or edge transfer scenarios.
• Compress and partition analytical data to reduce scanned bytes and improve query efficiency.

Example — Managed telemetry lake

Producers → Kinesis Data Firehose → S3 raw/yyyy/mm/dd/hour
                    └→ Lambda transform (optional)
Glue crawler/catalog → schema metadata
Athena → interactive SQL
Glue/EMR → curated Parquet datasets
QuickSight → visualization

Controls: failed-record prefix, encryption, lifecycle, partitioning, data-quality checks.

Related labs

• Assemble a serverless order flow (lab-serverless-orders)
• Stage, benchmark, and export HPC data (lab-fsx-stage)

Sources

• Amazon S3 User Guide — Storage
• Application Integration on AWS — Integration
• AWS Documentation — Reference

Course: SAA · Cost-Optimized Architectures — Tracks: SAA — Level: SAA-C03 — ~41 min

Optimize the workload’s unit economics across compute, storage, database, network, licensing, and operations while preserving hard requirements.

Objectives

• Choose compute purchasing and scaling strategies from utilization and interruption tolerance.
• Optimize storage classes, database capacity, caching, and data transfer paths.
• Use tagging, Cost Explorer, Budgets, anomaly detection, and architecture metrics to sustain savings.

Mental model

Cost optimization is continuous resource alignment, not a one-time discount exercise. The largest gains often come from architecture: eliminate idle capacity, select managed or serverless units that follow demand, move cold data, reduce transfer, and choose a data model that avoids overprovisioning.

Price and cost are different. A cheaper instance with twice the runtime may cost more per completed job. Optimize a business unit such as cost per request, simulation, report, or customer while meeting performance and recovery requirements.

Design

List every cost dimension in the request path and background workflow. Rank by spend, then change one variable at a time while tracking performance and resilience. Prefer reversible optimizations and protect critical headroom.

Decision rules

Operations

Review cost by owner, environment, service, and unit metric. Detect anomalies early, remove unattached resources, inspect commitment coverage/utilization, and include optimization checks in architecture reviews and deployment pipelines.

Failure modes

• Buying commitments for a workload scheduled for migration or retirement.
• Reducing redundancy below the stated availability or recovery objective.
• Optimizing compute while ignoring a larger data-transfer or licensing charge.

Key points

• Cover stable compute usage with appropriate Savings Plans or reservations after measuring the baseline; use flexible or Spot capacity for variable, fault-tolerant demand.
• Use Auto Scaling, scheduling, and serverless services to avoid paying for idle peaks.
• Use S3 lifecycle/Intelligent-Tiering, EBS right-sizing, snapshot lifecycle, and database right-sizing or serverless options where suitable.
• Reduce NAT, cross-AZ, cross-Region, and internet transfer through topology, endpoints, caching, compression, and data locality.

Example — Cost optimization order of operations

1. Remove: delete idle, orphaned, and obsolete resources
2. Schedule: stop nonproduction capacity outside use windows
3. Right-size: match CPU, memory, network, storage, and database demand
4. Architect: autoscale, cache, queue, tier data, use endpoints
5. Purchase: commit only after the stable baseline is measured
6. Measure: track cost per workload outcome and regression alarms

Related labs

• Optimize without breaking requirements (lab-cost-optimize)
• Select storage from access patterns (lab-storage-selection)
• Survive a Spot interruption (lab-spot-checkpoint)

Sources

• AWS Cost Management — Cost
• AWS Pricing — Cost
• AWS Well-Architected Framework — Architecture

Course: SAA · Resilient Architectures — Tracks: SAA — Level: SAA-C03 — ~35 min

Select transfer and migration mechanisms, stage safe cutovers, and modernize only where the target capability justifies change.

Objectives

• Choose server, database, file, object, and offline data migration tools.
• Plan discovery, replication, validation, cutover, rollback, and decommissioning.
• Identify modernization opportunities in decoupling, managed data, containers, and serverless services.

Mental model

Migration architecture must keep source and target consistent enough for the cutover objective. Continuous block replication, database change-data capture, file synchronization, object transfer, and offline devices solve different data shapes and outage windows.

Modernization is a separate decision from movement. Rehosting can reduce data-center risk quickly; replatforming can move a database to a managed engine; refactoring can split deployment or scaling boundaries. Each adds change that must be justified and tested.

Design

Inventory dependencies, data volume/change rate, network capacity, downtime, licensing, security, and target operations. Choose a strategy per workload, then pilot the migration factory with a representative low-risk application.

Decision rules

Operations

Measure replication lag, error rate, data checksums, application performance, DNS/connection cutover, and rollback time. Decommission sources only after business validation and recovery controls pass.

Failure modes

• Migrating components separately while hidden dependencies require coordinated cutover.
• Underestimating schema, stored procedure, and application changes in heterogeneous database migration.
• Leaving both source and target active indefinitely without ownership or data authority.

Key points

• Application Migration Service supports lift-and-shift server migration patterns.
• Database Migration Service supports homogeneous and heterogeneous database replication patterns, often with Schema Conversion Tool or other schema work.
• DataSync moves file/object data online; Storage Gateway supports hybrid interfaces; Snow Family addresses constrained large transfers.
• Migration waves should group dependencies and preserve observable rollback points.

Example — Low-downtime database cutover

1. Assess source engine, schema, unsupported objects, and throughput
2. Create target and secure network path
3. Load existing data
4. Start change-data capture
5. Validate counts, checksums, queries, and performance
6. Quiesce writes for the final delta
7. Switch application connection
8. Monitor and retain rollback window
9. Decommission after formal acceptance

Related labs

• Choose a disaster-recovery strategy (lab-dr-strategy)
• Stage, benchmark, and export HPC data (lab-fsx-stage)

Sources

• AWS Cloud Adoption Framework — Transformation
• AWS Documentation — Reference
• Disaster Recovery of Workloads on AWS — Reliability

Course: HPC · Parallel Foundations — Tracks: HPC — Level: HPC Core — ~39 min

Classify workloads by coupling, decompose work, distinguish strong and weak scaling, and locate the serial, communication, memory, and I/O limits that govern speedup.

Objectives

• Differentiate embarrassingly parallel, loosely coupled, tightly coupled, and data-intensive workloads.
• Explain strong scaling, weak scaling, Amdahl’s law, Gustafson’s law, efficiency, and throughput.
• Build a measurement plan before selecting cloud hardware or cluster size.

Mental model

Parallel computing divides work among processing elements. Embarrassingly parallel jobs exchange little data and often scale through queues. Tightly coupled jobs exchange messages frequently and may synchronize at collective operations. Data-intensive workloads can be constrained by storage and memory movement more than arithmetic.

Strong scaling keeps the problem size fixed while adding resources; ideal runtime falls inversely with resource count. Weak scaling grows the problem with resources and asks whether runtime stays approximately constant. The serial fraction and communication overhead eventually cap useful scale.

Design

Start with a single-node baseline and a representative dataset. Measure runtime phases, then run a scaling sweep with fixed software, data, placement, and storage. Choose the smallest resource count that meets time-to-solution or throughput goals at acceptable efficiency and cost.

Decision rules

Operations

Record software version, compiler flags, instance type, topology, process/thread placement, dataset, storage state, and warm-up conditions with every benchmark. A speedup claim without reproducibility metadata is not actionable.

Failure modes

• Comparing different datasets or compiler builds and attributing the change to instance type.
• Using all available cores while memory bandwidth or license tokens are already saturated.
• Optimizing node-hour price while ignoring time-to-solution and failed-run cost.

Key points

• Speedup S(p)=T(1)/T(p); parallel efficiency E(p)=S(p)/p.
• Amdahl’s law highlights the fixed serial fraction; Gustafson’s law explains why larger problems can use more resources effectively.
• Throughput optimization may favor many independent jobs, while time-to-solution optimization may favor one larger tightly coupled allocation.
• Profile compute, memory bandwidth, communication, synchronization, metadata, and I/O separately.

Example — Scaling efficiency calculation

Baseline: 1 node = 160 minutes

Nodes  Runtime  Speedup  Efficiency
1      160 min  1.00x    100%
2       84 min  1.90x     95%
4       46 min  3.48x     87%
8       30 min  5.33x     67%
16      25 min  6.40x     40%

If the deadline is 35 minutes, 8 nodes may be the economic knee.
If throughput matters, compare total completed jobs per currency unit instead.

Related labs

• Choose an HPC orchestration model (lab-hpc-service-choice)
• Diagnose an HPC performance regression (lab-hpc-diagnosis)

Sources

• AWS Well-Architected Framework — HPC Lens — HPC
• High Performance Computing on AWS — HPC
• Open MPI Documentation — Parallel computing

Course: HPC · Schedulers & Cluster Services — Tracks: HPC — Level: HPC Core — ~44 min

Understand Slurm controllers, nodes, partitions, jobs, steps, resources, priorities, arrays, dependencies, accounting, and the scheduler signals that drive elastic clusters.

Objectives

• Explain the role of slurmctld, slurmd, optional accounting components, partitions, jobs, and steps.
• Write and reason about sbatch requests for nodes, tasks, CPUs, memory, GPUs, time, arrays, and dependencies.
• Diagnose pending jobs from reason codes and resource/partition constraints.

Mental model

Slurm accepts a resource request, places the job in a partition, evaluates priority and constraints, allocates nodes, and launches job steps. slurmctld coordinates the cluster; slurmd runs on compute nodes; accounting services persist usage and job history where configured.

A partition is a scheduling grouping, not necessarily a separate physical cluster. A job is an allocation request; a job step is work launched inside the allocation. sbatch submits a script, srun launches parallel tasks or interactive work, salloc obtains an interactive allocation.

Design

Map the application launch model to Slurm: MPI ranks become tasks, OpenMP threads become CPUs per task, GPU processes request GPUs, and memory can be per node or per CPU depending on policy. Keep environment setup deterministic and emit job metadata into logs.

Decision rules

Operations

Use sinfo for partition/node state, squeue for pending/running jobs, scontrol show job for detail, and sacct for completed-job efficiency. Track requested versus used CPU, memory, GPU, and elapsed time to improve future requests.

Failure modes

• Requesting one task with many nodes when the application expects one rank per node.
• Using an extremely long wall time 'to be safe' and reducing backfill opportunities.
• Debugging a pending dependency as if it were a capacity shortage.

Key points

• Request only resources the program can use: nodes, tasks, CPUs per task, memory, generic resources such as GPUs, and wall time.
• Pending reason codes such as Resources, Priority, Dependency, QOS, or ReqNodeNotAvail identify different remedies.
• Job arrays efficiently submit repeated independent tasks; dependencies construct workflows without polling loops.
• Short accurate wall times and right-sized requests improve backfill opportunities and cluster utilization.

Example — Hybrid MPI + OpenMP batch script

#!/bin/bash
#SBATCH --job-name=solver
#SBATCH --partition=compute
#SBATCH --nodes=4
#SBATCH --ntasks-per-node=8
#SBATCH --cpus-per-task=4
#SBATCH --time=00:45:00
#SBATCH --output=logs/%x-%j.out

module load openmpi
export OMP_NUM_THREADS=$SLURM_CPUS_PER_TASK
srun --cpu-bind=cores ./solver --input s3-staged/case-42

Related labs

• Schedule and inspect Slurm jobs (lab-slurm-queue)
• Survive a Spot interruption (lab-spot-checkpoint)

Sources

• Slurm Overview — HPC scheduler
• Slurm Documentation — HPC scheduler
• AWS Parallel Computing Service User Guide — HPC

Course: HPC · MPI & Networking — Tracks: HPC — Level: HPC Core — ~46 min

Reason about ranks, communicators, point-to-point traffic, collectives, hybrid threading, process affinity, network transports, and communication scaling.

Objectives

• Explain MPI ranks, communicators, point-to-point operations, and common collectives.
• Relate message size and communication pattern to latency, bandwidth, and synchronization cost.
• Choose process/thread placement and benchmark communication separately from compute.

Mental model

MPI creates processes called ranks that communicate inside communicators. Point-to-point operations connect specific ranks. Collectives such as broadcast, reduce, all-reduce, gather, and all-to-all involve groups of ranks and often expose topology and synchronization costs.

Small frequent messages are latency-sensitive; large transfers are bandwidth-sensitive. Collective algorithms change with message size and process count. Hybrid MPI+OpenMP can reduce rank count and memory duplication, but thread scaling and NUMA placement must be measured.

Design

Draw the communication graph. Nearest-neighbor exchange can benefit from topology-aware placement; global all-to-all can saturate bisection bandwidth; repeated all-reduce can become the scaling wall. Reduce synchronization and communication volume before assuming hardware is the only fix.

Decision rules

Operations

Capture MPI debug output selectively, use microbenchmarks to isolate the fabric, and compare application profiles with network counters. Verify that each node has the expected interface, driver, provider, security-group rules, and placement.

Failure modes

• Launching more ranks than physical cores without intentionally testing oversubscription.
• Changing MPI version, compiler, and instance type simultaneously and losing causal evidence.
• Using a network bandwidth headline to predict small-message collective latency.

Key points

• Bind ranks and threads deliberately to sockets, cores, and NUMA memory; unbound processes can migrate and contend unpredictably.
• Oversubscription may be useful for development but distorts production performance measurements.
• Use the MPI implementation and network provider supported by the platform; record versions and transport selection.
• Benchmark point-to-point and collectives at representative process counts and message sizes.

Example — Launch and bind an MPI job

# Inside a Slurm allocation
export OMP_NUM_THREADS=2
srun --ntasks=32 \
     --cpus-per-task=2 \
     --cpu-bind=cores \
     ./mpi_solver --mesh mesh.bin

# Inspect placement and environment
srun --ntasks-per-node=1 bash -lc 'hostname; lscpu | grep NUMA; env | grep -E "SLURM|FI_PROVIDER"'

Related labs

• Configure and verify an EFA cluster (lab-efa-cluster)
• Diagnose an HPC performance regression (lab-hpc-diagnosis)

Sources

• Open MPI Documentation — Parallel computing
• Elastic Fabric Adapter — HPC networking
• Slurm Documentation — HPC scheduler

Course: HPC · Schedulers & Cluster Services — Tracks: HPC — Level: AWS HPC — ~40 min

Choose an AWS HPC orchestration model by scheduler requirement, lifecycle ownership, customization, elasticity, integration, and operational skill.

Objectives

• Differentiate AWS PCS, AWS ParallelCluster, AWS Batch, and self-managed clusters.
• Identify which control-plane and compute responsibilities remain with the customer.
• Choose a service from scheduler compatibility, customization, elasticity, and operational constraints.

Mental model

AWS Parallel Computing Service provides a managed service for running and scaling Slurm environments while customers configure networking, storage, queues, compute node groups, identities, and software. AWS ParallelCluster is an open-source cluster management tool that creates and updates AWS infrastructure from configuration.

AWS Batch provides managed job queues, scheduling, and compute environments for batch workloads that do not require a traditional shared Slurm environment. A self-managed cluster offers maximum control but requires the team to own scheduler availability, upgrades, security, images, scaling integration, and recovery.

Design

List scheduler APIs and plugins the workload requires, cluster lifetime, image/software model, queue shapes, elastic scaling behavior, storage integration, observability, network placement, and who will operate upgrades and failures. Then choose the highest-level service that preserves hard requirements.

Decision rules

Operations

Treat cluster configuration and images as versioned artifacts, monitor scheduler and scaling events, test node bootstrap, pin compatible software, and rehearse upgrades. Keep user home, shared application data, and durable results separate from replaceable compute nodes.

Failure modes

• Selecting a managed service while assuming all workload software and security configuration are provider responsibilities.
• Keeping critical scheduler state or results only on disposable compute nodes.
• Building a permanent cluster for a queue that could scale to zero between campaigns.

Key points

• Use PCS when managed Slurm control-plane operation and durable cluster environments align with requirements.
• Use ParallelCluster when infrastructure-as-code cluster lifecycle and deep configuration flexibility fit the team.
• Use Batch for queued containerized or script jobs that can use Batch semantics instead of Slurm workflows.
• Self-manage only when requirements justify the additional operational burden and expertise.

Example — Service selection matrix

Need managed Slurm service             → AWS PCS
Need config-driven Slurm clusters         → AWS ParallelCluster
Need managed independent job queues       → AWS Batch
Need Kubernetes-native batch/HPC          → EKS + scheduler/operator patterns
Need unsupported custom control plane     → self-managed, with explicit ops budget

For every option, validate: networking, storage, images, identity, licenses, quotas, observability, and recovery.

Related labs

• Choose an HPC orchestration model (lab-hpc-service-choice)
• Schedule and inspect Slurm jobs (lab-slurm-queue)

Sources

• AWS Parallel Computing Service User Guide — HPC
• AWS ParallelCluster User Guide — HPC
• High Performance Computing on AWS — HPC

Course: HPC · Compute & Accelerators — Tracks: HPC — Level: AWS HPC — ~42 min

Match CPU architecture, memory, accelerator, local storage, network bandwidth, licensing, and placement to measured application phases and capacity reality.

Objectives

• Select instance families from compute, memory, network, storage, GPU, and architecture requirements.
• Use cluster placement groups and capacity planning for tightly coupled work.
• Benchmark price-performance and time-to-solution rather than comparing vCPU count alone.

Mental model

HPC performance depends on the whole node: core architecture and frequency, vector capability, memory capacity and bandwidth, NUMA topology, local scratch, EBS bandwidth, network, and accelerators. Software build and license terms can exclude otherwise attractive instances.

A cluster placement group packs compatible instances close together to improve low-latency network performance. It is a placement strategy, not a capacity guarantee; large single-shape requests can fail when a zone lacks contiguous capacity.

Design

Profile one representative run, then benchmark a shortlist under identical conditions. Calculate cost per completed case and deadline attainment. For tightly coupled work, test complete multi-node scale rather than extrapolating from single-node results.

Decision rules

Operations

Track launch failure, node heterogeneity, thermal or frequency behavior where observable, NUMA placement, accelerator utilization, ECC errors, and application efficiency. Keep a validated fallback matrix rather than substituting instance types blindly.

Failure modes

• Comparing instance types with different compiler flags or libraries.
• Selecting the most GPUs without measuring host-device transfer and kernel utilization.
• Assuming cluster placement guarantees any requested fleet size.

Key points

• Compute-optimized families suit CPU-bound work; memory-optimized families suit large working sets; accelerated families suit supported GPU/accelerator code; HPC families target tightly coupled performance profiles.
• Graviton can improve price-performance for compatible ARM64 software, but binaries and libraries must support the architecture.
• Instance store provides high local scratch performance on supported types but is ephemeral.
• Capacity reservations or blocks, flexible instance lists, queue separation, and Region/AZ choice can reduce launch risk.

Example — Benchmark result table

Candidate   Runtime  Nodes  Cost/node-h  Job cost  Deadline
C-family     52m      8       1.00         6.93     miss
HPC-family   31m      8       1.55         6.41     pass
GPU-family   18m      4       3.10         3.72     pass

The fastest node is not automatically the best job cost, and the lowest hourly price may miss the deadline. Validate software licensing and capacity availability before choosing.

Related labs

• Configure and verify an EFA cluster (lab-efa-cluster)
• Choose an HPC orchestration model (lab-hpc-service-choice)

Sources

• Amazon EC2 User Guide — Compute
• Elastic Fabric Adapter — HPC networking
• AWS Well-Architected Framework — HPC Lens — HPC

Course: HPC · MPI & Networking — Tracks: HPC — Level: AWS HPC — ~43 min

Understand when Elastic Fabric Adapter improves MPI or distributed training, what OS-bypass changes, and how placement, software providers, and security configuration complete the path.

Objectives

• Explain EFA and the Scalable Reliable Datagram interface at a conceptual level.
• Identify instance, image, driver, libfabric/MPI, placement, and security requirements.
• Benchmark latency, bandwidth, and collectives to verify that the application benefits.

Mental model

Elastic Fabric Adapter is a network interface for supported EC2 instances that can provide lower and more consistent inter-instance communication for compatible tightly coupled applications. It exposes normal IP networking and an OS-bypass path through libfabric for supported communication libraries.

EFA is not a universal accelerator. Independent batch jobs with little inter-node communication gain little. Benefit depends on compatible instances, drivers, libfabric provider, MPI or distributed-training stack, cluster placement, and a communication pattern that is actually network-sensitive.

Design

Classify message size, frequency, collective mix, node count, and sensitivity to jitter. Build a controlled A/B test on supported instances, keeping software and placement fixed. Use EFA when the measured time-to-solution or scaling efficiency justifies it.

Decision rules

Operations

Verify interface attachment, provider output, security-group rules, placement, library loading, and benchmark results on every image revision. Monitor failed node initialization and preserve known-good image versions.

Failure modes

• Attaching EFA but launching an MPI build that uses only a TCP transport.
• Spreading nodes without placement control and expecting consistent low latency.
• Using EFA for a queue of independent single-node tasks and expecting throughput improvement.

Key points

• Use an EFA-enabled AMI or install compatible EFA drivers and libraries; validate with provider and MPI diagnostics.
• Place nodes in a cluster placement group and a common security-group design that permits required EFA traffic.
• EFA traffic for the OS-bypass path is within a VPC and is not routed like ordinary internet traffic.
• Benchmark application collectives and full workloads, not only TCP throughput.

Example — EFA validation sequence

# Confirm the interface and libfabric provider
fi_info -p efa

# Confirm MPI build/version
mpirun --version

# Run a point-to-point or collective microbenchmark in the scheduler allocation
srun --nodes=2 --ntasks-per-node=1 ./osu_latency
srun --nodes=4 --ntasks-per-node=8 ./osu_allreduce

# Then compare the real application with identical data and process placement.

Related labs

• Configure and verify an EFA cluster (lab-efa-cluster)
• Diagnose an HPC performance regression (lab-hpc-diagnosis)

Sources

• Elastic Fabric Adapter — HPC networking
• Open MPI Documentation — Parallel computing
• AWS ParallelCluster User Guide — HPC

Course: HPC · Parallel Storage & Data — Tracks: HPC — Level: AWS HPC — ~46 min

Design the HPC data path across S3, FSx for Lustre, EBS, EFS, instance store, and archival storage using concurrency, file size, metadata, throughput, and lifecycle evidence.

Objectives

• Recognize data, metadata, checkpoint, scratch, home, software, and result access patterns.
• Use FSx for Lustre and S3 data repositories in suitable stage/compute/export workflows.
• Diagnose small-file, metadata, client-concurrency, striping, and shared-path bottlenecks.

Mental model

An HPC workflow usually has several storage roles. Object storage holds durable source and result data. A parallel file system provides a shared POSIX namespace and high aggregate throughput during computation. Instance store can provide per-node scratch. EFS can serve shared home or lighter NFS patterns. EBS can hold node-local block data or specific service state.

Aggregate throughput requires parallelism from storage servers, clients, and application I/O. Many tiny files can be metadata-bound even when bulk bandwidth is high. One serial reader can keep a parallel file system idle.

Design

Draw data stages: ingest, preprocess, active compute, checkpoint, postprocess, publish, archive. Quantify bytes, file count, read/write ratio, concurrency, target throughput, metadata rate, retention, and data-transfer window for each stage. Keep durable source and final results outside ephemeral scratch.

Decision rules

Operations

Measure client throughput, metadata operations, I/O size, open/close rate, cache effects, server saturation, queue wait caused by staging, and export completion. Test restart from checkpoints before relying on Spot or long campaigns.

Failure modes

• Provisioning a fast parallel file system while reading data through one process.
• Writing millions of tiny files and blaming network bandwidth for metadata delay.
• Terminating scratch storage before confirmed result export to durable storage.

Key points

• FSx for Lustre can link to S3 data repositories and support lazy import or explicit data movement patterns, depending on configuration and workflow.
• Choose deployment and throughput settings from persistence, scratch, capacity, and performance requirements; verify current service options in official documentation.
• Use large sequential I/O, collective I/O, striping, file aggregation, and sufficient clients where the application permits.
• Checkpoints require a frequency that balances lost compute, write overhead, retention, and restart validation.

Example — Stage–compute–export workflow

S3 durable inputs
   ↓ import / hydrate
FSx for Lustre active dataset
   ↔ many compute nodes read/write in parallel
   ↓ checkpoints + final results
S3 result prefix with versioning/lifecycle
   ↓
archive or downstream analytics

Node-local instance store: temporary spill and intermediates only.

Related labs

• Stage, benchmark, and export HPC data (lab-fsx-stage)
• Survive a Spot interruption (lab-spot-checkpoint)
• Diagnose an HPC performance regression (lab-hpc-diagnosis)

Sources

• Amazon FSx for Lustre User Guide — HPC storage
• Amazon S3 User Guide — Storage
• AWS Well-Architected Framework — HPC Lens — HPC

Course: HPC · Elasticity & Operations — Tracks: HPC — Level: AWS HPC — ~41 min

Turn queue demand into elastic capacity while balancing wait time, start time, throughput, price, interruption, reservations, licenses, and storage lifecycle.

Objectives

• Design queue-aware scale-out and idle scale-in behavior.
• Use On-Demand, Spot, commitments, reservations, and capacity planning for different job classes.
• Calculate job cost, throughput cost, utilization, and checkpoint economics.

Mental model

Elastic HPC converts pending jobs into compute nodes and returns idle nodes after work. The scheduler request determines the required shape; the cloud scaling system determines how to acquire it. Queue policy, bootstrap time, image readiness, and capacity availability all affect user wait time.

Spot can lower cost for flexible jobs but capacity may be interrupted. Diversified instance types, capacity-optimized allocation, checkpoint/restart, retry limits, and separate queues for critical work turn interruption into a designed event.

Design

Classify queues by deadline, interruption tolerance, instance constraints, and data locality. Give each queue an allowed capacity strategy. Model the expected checkpoint interval from interruption rate, checkpoint cost, and lost work, then validate with controlled interruption.

Decision rules

Operations

Track node utilization, queue wait by reason, launch failures, Spot interruption rate, retry waste, checkpoint duration, idle timeout, storage cost after scale-in, and license usage. Build cost dashboards per project and job.

Failure modes

• Using Spot for a multi-day job that cannot checkpoint or restart.
• Scaling nodes to zero while leaving expensive scratch data indefinitely.
• Diversifying to instance types with incompatible memory, network, accelerator, or software behavior.

Key points

• Measure queue wait, instance launch/bootstrap, execution, checkpoint, retry, and export as separate time components.
• Use stable commitments for a sustained baseline only after observing utilization and campaign patterns.
• Scale-to-zero saves compute but shared file systems, scheduler services, licenses, and retained data may continue to cost money.
• Optimize cost per useful completed job, not only node-hour rate.

Example — Checkpoint trade-off

Job runtime without interruption: 12 hours
Checkpoint duration: 4 minutes
Checkpoint interval: 30 minutes
Average lost work after random interruption: ~15 minutes

Expected interruption cost includes:
- lost compute since last checkpoint
- checkpoint write overhead
- queue/relaunch delay
- data rehydration
- failed-run probability near deadline

Compare total expected job cost and deadline risk with On-Demand, not Spot price alone.

Related labs

• Survive a Spot interruption (lab-spot-checkpoint)
• Choose an HPC orchestration model (lab-hpc-service-choice)

Sources

• AWS Well-Architected Framework — HPC Lens — HPC
• Amazon EC2 User Guide — Compute
• AWS Cost Management — Cost

Course: HPC · Elasticity & Operations — Tracks: HPC — Level: AWS HPC — ~42 min

Operate shared research and engineering platforms with reproducible images, least privilege, protected data, scheduler accounting, telemetry, patching, quotas, and incident-ready runbooks.

Objectives

• Separate platform, project, user, scheduler, and workload security responsibilities.
• Build reproducible software environments and auditable job provenance.
• Design telemetry for scheduler health, node bootstrap, jobs, storage, cost, and security.

Mental model

An HPC platform is multi-tenant even when all users belong to one organization. Scheduler partitions, accounts, QOS, UNIX identities, IAM roles, security groups, file permissions, encryption, and data classification must align. Administrative login to a head node should not imply broad data or AWS permissions.

Reproducibility requires more than source code: compiler and library versions, container or image digest, module environment, input dataset version, scheduler request, random seed, architecture, and output checksum may all matter.

Design

Define administrative roles, project boundaries, data classes, software supply chain, network access, and evidence retention. Make the job submission path attach project identity and provenance automatically rather than relying on user memory.

Decision rules

Operations

Alarm on scheduler unavailability, failed node joins, queue age, filesystem capacity/latency, repeated job failure, accelerator errors, budget anomalies, unauthorized API calls, and loss of telemetry. Exercise recovery of the scheduler, shared data, and image pipeline.

Failure modes

• Giving users long-lived AWS access keys inside home directories.
• Allowing mutable module or container tags to change during a study.
• Collecting node CPU metrics but no scheduler reason, application log, or storage signal.

Key points

• Prefer Session Manager or controlled bastion patterns over broad SSH exposure; use federation and short-lived credentials.
• Build signed/versioned images or containers and validate bootstrap before promoting them to production queues.
• Collect scheduler accounting, job stdout/stderr, node and accelerator metrics, storage telemetry, CloudTrail, and cost allocation metadata.
• Separate immutable source data, writable project data, scratch, home, software, and result permissions.

Example — Job provenance record

{
  "job_id": "18427",
  "project": "climate-a",
  "git_commit": "4d8a9f1",
  "container_digest": "sha256:example",
  "input_manifest": "s3://datasets/v7/manifest.json",
  "instance_type": "hpc7g.16xlarge",
  "nodes": 8,
  "tasks_per_node": 64,
  "compiler": "gcc-13",
  "mpi": "openmpi-5",
  "started_at": "2026-07-16T09:00:00Z"
}

Related labs

• Diagnose an HPC performance regression (lab-hpc-diagnosis)
• Instrument and diagnose a backlog (lab-observability)
• Repair an IAM policy (lab-iam-policy)

Sources

• AWS Well-Architected Framework — HPC Lens — HPC
• Amazon CloudWatch User Guide — Operations
• AWS CloudTrail User Guide — Governance
• IAM User Guide — Security

Course: HPC · Architecture Capstone — Tracks: HPC — Level: Capstone — ~48 min

Assemble identity, networking, scheduler, elastic compute, EFA, shared software, parallel storage, object data, observability, and cost controls into a defensible architecture.

Objectives

• Build an end-to-end architecture from workload and organizational requirements.
• Explain every service boundary, failure mode, data path, and scaling signal.
• Create a validation plan for performance, security, recovery, cost, and operations.

Mental model

A reference architecture is a starting hypothesis, not a universal template. A typical AWS HPC environment uses federated identity, a VPC with controlled access, a Slurm-based orchestration service, elastic compute node groups, EFA and cluster placement for tightly coupled queues, FSx for Lustre for active parallel data, S3 for durable datasets and results, and centralized logs and cost allocation.

Independent job queues may use AWS Batch instead. Home directories may use EFS, software may be baked into images or delivered through a shared file system, and license servers may remain on premises through resilient hybrid connectivity. Each choice follows a workload requirement.

Design

Work through five views: workload decomposition, data path, control and identity, failure/recovery, and cost. Then build experiments for the uncertain assumptions—scaling knee, EFA benefit, file-system throughput, bootstrap time, Spot interruption behavior, and recovery timing.

Decision rules

Operations

Run acceptance tests for identity, job submission, node scale-out, MPI communication, storage throughput, checkpoint/restart, result export, node termination, scheduler recovery, budget alarms, and audit evidence. Record baselines and regression thresholds.

Failure modes

• Building one queue and one instance type for every workload shape.
• Optimizing the compute fleet while data staging dominates total turnaround time.
• Drawing redundant components without defining health detection, failover, data readiness, and operator action.

Key points

• Separate login/control, compute, storage, and durable data lifecycles.
• Use multiple queue/compute shapes for different coupling, accelerator, deadline, and interruption classes.
• Keep durable input and output in S3; hydrate active data into the compute storage tier and export before teardown.
• Connect observability, job accounting, tagging, budgets, and project identity so performance and cost can be analyzed per workload.

Example — Architecture checklist

Identity: IAM Identity Center → project roles → no static keys
Network: private compute subnets, endpoints, controlled admin path
Scheduler: PCS or ParallelCluster Slurm queues by workload class
Compute: elastic node groups, placement/EFA for MPI, Spot for restartable jobs
Storage: EFS/home, FSx for Lustre/active data, instance store/scratch, S3/durable
Data: manifest, hydrate, validate, checkpoint, export, lifecycle
Operations: CloudWatch, CloudTrail, scheduler accounting, image versions, runbooks
Cost: project tags, queue policy, idle scale-in, budgets, cost per completed job

Related labs

• Choose an HPC orchestration model (lab-hpc-service-choice)
• Configure and verify an EFA cluster (lab-efa-cluster)
• Stage, benchmark, and export HPC data (lab-fsx-stage)
• Survive a Spot interruption (lab-spot-checkpoint)
• Diagnose an HPC performance regression (lab-hpc-diagnosis)

Sources

• AWS Well-Architected Framework — HPC Lens — HPC
• AWS Parallel Computing Service User Guide — HPC
• AWS ParallelCluster User Guide — HPC
• Elastic Fabric Adapter — HPC networking
• Amazon FSx for Lustre User Guide — HPC storage

Files: examples/terraform/two-az-vpc/ — A small two-Availability-Zone VPC exercise.

Two-Availability-Zone VPC exercise

This small Terraform exercise creates:

• one VPC;
• two public and two private subnets across the first two available Availability Zones;
• an internet gateway and public route table;
• isolated private route tables; and
• an S3 gateway endpoint for private S3 traffic.

It deliberately omits EC2 instances and NAT gateways. That keeps the exercise focused on packet paths and avoids creating hourly NAT charges merely to demonstrate topology.

Commands

terraform init
terraform fmt -check
terraform validate
terraform plan -out cloudforge.plan
terraform apply cloudforge.plan
terraform destroy

Use a sandbox account, review the plan, and verify the Region has at least two available Availability Zones. Provider and service behavior can change; confirm current documentation before production use.

terraform/two-az-vpc/main.tf

provider "aws" {
  region = var.aws_region

  default_tags {
    tags = {
      Project   = "CloudForgeAcademy"
      ManagedBy = "Terraform"
    }
  }
}

data "aws_availability_zones" "available" {
  state = "available"
}

locals {
  availability_zones = slice(data.aws_availability_zones.available.names, 0, 2)
  public_cidrs       = ["10.64.10.0/24", "10.64.20.0/24"]
  private_cidrs      = ["10.64.110.0/24", "10.64.120.0/24"]
}

resource "aws_vpc" "this" {
  cidr_block           = var.vpc_cidr
  enable_dns_support   = true
  enable_dns_hostnames = true

  tags = { Name = var.name }
}

resource "aws_internet_gateway" "this" {
  vpc_id = aws_vpc.this.id
  tags   = { Name = "${var.name}-igw" }
}

resource "aws_subnet" "public" {
  count = 2

  vpc_id                  = aws_vpc.this.id
  availability_zone       = local.availability_zones[count.index]
  cidr_block              = local.public_cidrs[count.index]
  map_public_ip_on_launch = false

  tags = { Name = "${var.name}-public-${count.index + 1}" }
}

resource "aws_subnet" "private" {
  count = 2

  vpc_id            = aws_vpc.this.id
  availability_zone = local.availability_zones[count.index]
  cidr_block        = local.private_cidrs[count.index]

  tags = { Name = "${var.name}-private-${count.index + 1}" }
}

resource "aws_route_table" "public" {
  vpc_id = aws_vpc.this.id
  tags   = { Name = "${var.name}-public" }
}

resource "aws_route" "internet" {
  route_table_id         = aws_route_table.public.id
  destination_cidr_block = "0.0.0.0/0"
  gateway_id             = aws_internet_gateway.this.id
}

resource "aws_route_table_association" "public" {
  count = 2

  subnet_id      = aws_subnet.public[count.index].id
  route_table_id = aws_route_table.public.id
}

resource "aws_route_table" "private" {
  count = 2

  vpc_id = aws_vpc.this.id
  tags   = { Name = "${var.name}-private-${count.index + 1}" }
}

resource "aws_route_table_association" "private" {
  count = 2

  subnet_id      = aws_subnet.private[count.index].id
  route_table_id = aws_route_table.private[count.index].id
}

# This exercise intentionally omits NAT gateways. Add only when a private
# workload genuinely requires outbound internet access, then evaluate cost and
# resilience implications. Prefer service endpoints for supported AWS traffic.
resource "aws_vpc_endpoint" "s3" {
  vpc_id            = aws_vpc.this.id
  service_name      = "com.amazonaws.${var.aws_region}.s3"
  vpc_endpoint_type = "Gateway"
  route_table_ids   = aws_route_table.private[*].id

  tags = { Name = "${var.name}-s3" }
}

terraform/two-az-vpc/variables.tf

variable "aws_region" {
  description = "AWS Region for the exercise."
  type        = string
  default     = "eu-west-1"
}

variable "name" {
  description = "Prefix applied to resource Name tags."
  type        = string
  default     = "cloudforge-two-az"
}

variable "vpc_cidr" {
  description = "CIDR block for the VPC."
  type        = string
  default     = "10.64.0.0/16"
}

terraform/two-az-vpc/outputs.tf

output "vpc_id" {
  value = aws_vpc.this.id
}

output "availability_zones" {
  value = local.availability_zones
}

output "public_subnet_ids" {
  value = aws_subnet.public[*].id
}

output "private_subnet_ids" {
  value = aws_subnet.private[*].id
}

output "s3_gateway_endpoint_id" {
  value = aws_vpc_endpoint.s3.id
}

terraform/two-az-vpc/versions.tf

terraform {
  required_version = ">= 1.6.0"

  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = ">= 5.0"
    }
  }
}

File: examples/cloudformation/resilient-web-skeleton.yaml — Security, durability, and resilient architecture patterns.

An educational two-AZ web tier skeleton with an ALB and Auto Scaling group. These are original teaching artifacts, not production-ready turnkey stacks: use a sandbox account with budgets and least-privilege access, inspect plans and change sets before creating resources, replace placeholders (AMI IDs, subnet IDs, account IDs, bucket names), and tear down resources after practice.

AWSTemplateFormatVersion: '2010-09-09'
Description: Educational two-AZ web tier skeleton with an ALB and Auto Scaling group.

Parameters:
  AmiId:
    Type: AWS::EC2::Image::Id
    Description: A current AMI available in the deployment Region.
  InstanceType:
    Type: String
    Default: t3.micro
    AllowedValues: [t3.micro, t3.small, t3.medium]
  AllowedIngressCidr:
    Type: String
    Default: 0.0.0.0/0
    Description: Narrow this range for non-public practice environments.

Resources:
  Vpc:
    Type: AWS::EC2::VPC
    Properties:
      CidrBlock: 10.42.0.0/16
      EnableDnsSupport: true
      EnableDnsHostnames: true
      Tags:
        - Key: Name
          Value: cloudforge-web

  InternetGateway:
    Type: AWS::EC2::InternetGateway

  GatewayAttachment:
    Type: AWS::EC2::VPCGatewayAttachment
    Properties:
      VpcId: !Ref Vpc
      InternetGatewayId: !Ref InternetGateway

  PublicSubnetA:
    Type: AWS::EC2::Subnet
    Properties:
      VpcId: !Ref Vpc
      AvailabilityZone: !Select [0, !GetAZs '']
      CidrBlock: 10.42.10.0/24
      MapPublicIpOnLaunch: true

  PublicSubnetB:
    Type: AWS::EC2::Subnet
    Properties:
      VpcId: !Ref Vpc
      AvailabilityZone: !Select [1, !GetAZs '']
      CidrBlock: 10.42.20.0/24
      MapPublicIpOnLaunch: true

  PublicRouteTable:
    Type: AWS::EC2::RouteTable
    Properties:
      VpcId: !Ref Vpc

  DefaultRoute:
    Type: AWS::EC2::Route
    DependsOn: GatewayAttachment
    Properties:
      RouteTableId: !Ref PublicRouteTable
      DestinationCidrBlock: 0.0.0.0/0
      GatewayId: !Ref InternetGateway

  SubnetARouteAssociation:
    Type: AWS::EC2::SubnetRouteTableAssociation
    Properties:
      SubnetId: !Ref PublicSubnetA
      RouteTableId: !Ref PublicRouteTable

  SubnetBRouteAssociation:
    Type: AWS::EC2::SubnetRouteTableAssociation
    Properties:
      SubnetId: !Ref PublicSubnetB
      RouteTableId: !Ref PublicRouteTable

  LoadBalancerSecurityGroup:
    Type: AWS::EC2::SecurityGroup
    Properties:
      GroupDescription: Permit HTTP to the educational load balancer
      VpcId: !Ref Vpc
      SecurityGroupIngress:
        - IpProtocol: tcp
          FromPort: 80
          ToPort: 80
          CidrIp: !Ref AllowedIngressCidr

  InstanceSecurityGroup:
    Type: AWS::EC2::SecurityGroup
    Properties:
      GroupDescription: Permit HTTP only from the load balancer
      VpcId: !Ref Vpc
      SecurityGroupIngress:
        - IpProtocol: tcp
          FromPort: 80
          ToPort: 80
          SourceSecurityGroupId: !Ref LoadBalancerSecurityGroup

  LoadBalancer:
    Type: AWS::ElasticLoadBalancingV2::LoadBalancer
    Properties:
      Scheme: internet-facing
      SecurityGroups: [!Ref LoadBalancerSecurityGroup]
      Subnets: [!Ref PublicSubnetA, !Ref PublicSubnetB]

  TargetGroup:
    Type: AWS::ElasticLoadBalancingV2::TargetGroup
    Properties:
      VpcId: !Ref Vpc
      Port: 80
      Protocol: HTTP
      HealthCheckPath: /
      TargetType: instance

  Listener:
    Type: AWS::ElasticLoadBalancingV2::Listener
    Properties:
      LoadBalancerArn: !Ref LoadBalancer
      Port: 80
      Protocol: HTTP
      DefaultActions:
        - Type: forward
          TargetGroupArn: !Ref TargetGroup

  LaunchTemplate:
    Type: AWS::EC2::LaunchTemplate
    Properties:
      LaunchTemplateData:
        ImageId: !Ref AmiId
        InstanceType: !Ref InstanceType
        SecurityGroupIds: [!Ref InstanceSecurityGroup]
        MetadataOptions:
          HttpTokens: required
          HttpEndpoint: enabled
        UserData:
          Fn::Base64: !Sub |
            #!/bin/bash
            set -euxo pipefail
            dnf install -y httpd || yum install -y httpd
            printf '<h1>CloudForge resilient web exercise</h1>\n' > /var/www/html/index.html
            systemctl enable --now httpd

  AutoScalingGroup:
    Type: AWS::AutoScaling::AutoScalingGroup
    Properties:
      VPCZoneIdentifier: [!Ref PublicSubnetA, !Ref PublicSubnetB]
      MinSize: '2'
      DesiredCapacity: '2'
      MaxSize: '4'
      HealthCheckType: ELB
      HealthCheckGracePeriod: 120
      TargetGroupARNs: [!Ref TargetGroup]
      LaunchTemplate:
        LaunchTemplateId: !Ref LaunchTemplate
        Version: !GetAtt LaunchTemplate.LatestVersionNumber

Outputs:
  Endpoint:
    Value: !Sub 'http://${LoadBalancer.DNSName}'

File: examples/cloudformation/secure-results-bucket.yaml — Security, durability, and resilient architecture patterns.

A secure, versioned result bucket — the reference shape for the CloudForge IaC analyzer exercise. These are original teaching artifacts, not production-ready turnkey stacks: use a sandbox account with budgets and least-privilege access, inspect plans and change sets before creating resources, replace placeholders (AMI IDs, subnet IDs, account IDs, bucket names), and tear down resources after practice.

AWSTemplateFormatVersion: '2010-09-09'
Description: Secure, versioned result bucket used by the CloudForge IaC analyzer exercise.

Parameters:
  ProjectName:
    Type: String
    Default: cloudforge
    AllowedPattern: '[a-z0-9-]+'

Resources:
  ResultsBucket:
    Type: AWS::S3::Bucket
    DeletionPolicy: Retain
    UpdateReplacePolicy: Retain
    Properties:
      BucketEncryption:
        ServerSideEncryptionConfiguration:
          - ServerSideEncryptionByDefault:
              SSEAlgorithm: AES256
      PublicAccessBlockConfiguration:
        BlockPublicAcls: true
        IgnorePublicAcls: true
        BlockPublicPolicy: true
        RestrictPublicBuckets: true
      VersioningConfiguration:
        Status: Enabled
      LifecycleConfiguration:
        Rules:
          - Id: ArchiveOlderResults
            Status: Enabled
            Transitions:
              - StorageClass: STANDARD_IA
                TransitionInDays: 30
              - StorageClass: GLACIER_IR
                TransitionInDays: 90
      Tags:
        - Key: Project
          Value: !Ref ProjectName

Outputs:
  BucketName:
    Value: !Ref ResultsBucket
  BucketArn:
    Value: !GetAtt ResultsBucket.Arn

File: examples/iam/project-prefix-policy.json — Least-privilege and explicit-deny policy reasoning.

A scoped Allow on a single project prefix combined with an explicit Deny on insecure transport. Read the statements, predict the evaluation outcome for in-scope and out-of-scope requests, then verify with the policy simulator.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ProjectObjects",
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject"
      ],
      "Resource": "arn:aws:s3:::research-results/project-a/*"
    },
    {
      "Sid": "DenyInsecureTransport",
      "Effect": "Deny",
      "Action": "s3:*",
      "Resource": "*",
      "Condition": {
        "Bool": {
          "aws:SecureTransport": "false"
        }
      }
    }
  ]
}

File: examples/cli/read-only-baseline.sh — Read-only AWS CLI discovery commands.

A read-only discovery baseline for a sandbox account: the script never creates, modifies, or deletes resources, so it is safe to run while learning the CLI surface.

#!/usr/bin/env bash
set -euo pipefail

# Read-only discovery commands for a sandbox account. The script never creates,
# changes, or deletes resources. Configure a least-privilege AWS CLI profile first.
PROFILE="${AWS_PROFILE:-default}"
REGION="${AWS_REGION:-eu-west-1}"

aws --profile "$PROFILE" --region "$REGION" sts get-caller-identity
aws --profile "$PROFILE" --region "$REGION" ec2 describe-availability-zones \
  --filters Name=state,Values=available \
  --query 'AvailabilityZones[].{Name:ZoneName,Id:ZoneId}'
aws --profile "$PROFILE" --region "$REGION" ec2 describe-vpcs \
  --query 'Vpcs[].{VpcId:VpcId,Cidr:CidrBlock,Default:IsDefault}'
aws --profile "$PROFILE" --region "$REGION" s3api list-buckets \
  --query 'Buckets[].Name'
aws --profile "$PROFILE" --region "$REGION" cloudformation list-stacks \
  --stack-status-filter CREATE_COMPLETE UPDATE_COMPLETE \
  --query 'StackSummaries[].{Name:StackName,Updated:LastUpdatedTime}'

Files: examples/hpc/ — Slurm, MPI, checkpointing, and ParallelCluster examples.

A Slurm parameter-sweep job array, an MPI hello-world (source plus its two-node launch script), a checkpoint-restart batch job, and an educational ParallelCluster configuration. These are original teaching artifacts, not production-ready turnkey stacks: use a sandbox account with budgets and least-privilege access, inspect plans and change sets before creating resources, replace placeholders (AMI IDs, subnet IDs, account IDs, bucket names), and tear down resources after practice.

hpc/slurm-job-array.sh

#!/usr/bin/env bash
#SBATCH --job-name=parameter-sweep
#SBATCH --array=0-15%4
#SBATCH --nodes=1
#SBATCH --ntasks=1
#SBATCH --cpus-per-task=4
#SBATCH --mem=8G
#SBATCH --time=00:20:00
#SBATCH --output=logs/%x-%A_%a.out
#SBATCH --error=logs/%x-%A_%a.err

set -euo pipefail
mkdir -p logs results

SEEDS=(11 17 23 31 41 47 59 67 71 79 83 97 101 107 109 127)
SEED="${SEEDS[$SLURM_ARRAY_TASK_ID]}"

printf 'job=%s task=%s host=%s seed=%s cpus=%s\n' \
  "$SLURM_JOB_ID" "$SLURM_ARRAY_TASK_ID" "$(hostname)" "$SEED" "$SLURM_CPUS_PER_TASK"

# Replace the following line with the actual application invocation.
python3 - <<PY > "results/run-${SLURM_ARRAY_TASK_ID}.json"
import json, math
seed = ${SEED}
value = sum(math.sin((seed + i) / 1000) ** 2 for i in range(100_000))
print(json.dumps({"seed": seed, "metric": value}))
PY

hpc/mpi_hello.c

#include <mpi.h>
#include <stdio.h>
#include <stdlib.h>

int main(int argc, char **argv) {
    int rank = 0;
    int size = 0;
    char processor[MPI_MAX_PROCESSOR_NAME];
    int processor_length = 0;

    if (MPI_Init(&argc, &argv) != MPI_SUCCESS) {
        fprintf(stderr, "MPI_Init failed\n");
        return EXIT_FAILURE;
    }

    MPI_Comm_rank(MPI_COMM_WORLD, &rank);
    MPI_Comm_size(MPI_COMM_WORLD, &size);
    MPI_Get_processor_name(processor, &processor_length);

    printf("rank %d of %d on %s\n", rank, size, processor);

    MPI_Barrier(MPI_COMM_WORLD);
    if (rank == 0) {
        printf("all ranks reached the barrier\n");
    }

    MPI_Finalize();
    return EXIT_SUCCESS;
}

hpc/run-mpi.sh

#!/usr/bin/env bash
#SBATCH --job-name=mpi-hello
#SBATCH --nodes=2
#SBATCH --ntasks-per-node=4
#SBATCH --time=00:05:00
#SBATCH --exclusive
#SBATCH --output=mpi-%j.out

set -euo pipefail

module load mpi 2>/dev/null || true
mpicc -O2 -Wall -Wextra -o mpi_hello mpi_hello.c

# The launcher and EFA/libfabric variables depend on the installed MPI stack.
# Confirm the current AWS EFA guidance for the selected AMI and MPI version.
srun --mpi=pmix ./mpi_hello

hpc/checkpoint-job.sh

#!/usr/bin/env bash
#SBATCH --job-name=checkpoint-demo
#SBATCH --nodes=1
#SBATCH --ntasks=1
#SBATCH --time=00:30:00
#SBATCH --signal=B:USR1@60
#SBATCH --requeue
#SBATCH --output=checkpoint-%j.out

set -euo pipefail

CHECKPOINT_DIR="${CHECKPOINT_DIR:-$PWD/checkpoints}"
CHECKPOINT_FILE="$CHECKPOINT_DIR/${SLURM_JOB_NAME}.state"
mkdir -p "$CHECKPOINT_DIR"

step=0
if [[ -f "$CHECKPOINT_FILE" ]]; then
  step="$(<"$CHECKPOINT_FILE")"
  printf 'resuming from step %s\n' "$step"
fi

checkpoint_and_requeue() {
  printf '%s\n' "$step" > "$CHECKPOINT_FILE.tmp"
  mv "$CHECKPOINT_FILE.tmp" "$CHECKPOINT_FILE"
  printf 'checkpointed step %s for job %s; requesting requeue\n' "$step" "$SLURM_JOB_ID"
  scontrol requeue "$SLURM_JOB_ID"
  exit 0
}
trap checkpoint_and_requeue USR1 TERM

while (( step < 180 )); do
  # Substitute one recoverable unit of real work here.
  sleep 1
  ((step += 1))
  if (( step % 15 == 0 )); then
    printf '%s\n' "$step" > "$CHECKPOINT_FILE.tmp"
    mv "$CHECKPOINT_FILE.tmp" "$CHECKPOINT_FILE"
    printf 'durable checkpoint: step %s\n' "$step"
  fi
done

rm -f "$CHECKPOINT_FILE"
printf 'completed all %s steps\n' "$step"

hpc/parallelcluster-config.yaml

# Educational AWS ParallelCluster configuration. Verify schema, instance
# availability, AMI support, quotas, and subnet design against current docs.
Region: eu-west-1
Image:
  Os: alinux2023
HeadNode:
  InstanceType: c7i.large
  Networking:
    SubnetId: subnet-REPLACE_HEAD
  Ssh:
    KeyName: REPLACE_KEYPAIR
  LocalStorage:
    RootVolume:
      Size: 40
Scheduling:
  Scheduler: slurm
  SlurmQueues:
    - Name: cpu-ondemand
      CapacityType: ONDEMAND
      Networking:
        SubnetIds:
          - subnet-REPLACE_COMPUTE
        PlacementGroup:
          Enabled: true
      ComputeResources:
        - Name: compute
          InstanceType: hpc7g.16xlarge
          MinCount: 0
          MaxCount: 8
      ComputeSettings:
        LocalStorage:
          EphemeralVolume:
            MountDir: /scratch
    - Name: cpu-spot
      CapacityType: SPOT
      Networking:
        SubnetIds:
          - subnet-REPLACE_COMPUTE
      ComputeResources:
        - Name: flexible-spot
          Instances:
            - InstanceType: c7i.12xlarge
            - InstanceType: c7i.16xlarge
          MinCount: 0
          MaxCount: 16
SharedStorage:
  - MountDir: /shared
    Name: shared-fsx
    StorageType: FsxLustre
    FsxLustreSettings:
      StorageCapacity: 1200
      DeploymentType: SCRATCH_2
Monitoring:
  DetailedMonitoring: true
  Logs:
    CloudWatch:
      Enabled: true
      RetentionInDays: 30

Course: SAA · High-Performing Architectures — Tracks: SAA — Level: SAA-C03 — ~42 min

Choose relational, key-value/document, warehouse, search, graph, time-series, and cache services by data model, access pattern, correctness, and operations.

Objectives

• Select RDS/Aurora, DynamoDB, Redshift, OpenSearch, Neptune, Timestream, and ElastiCache from access patterns.
• Differentiate Multi-AZ, read replicas, global data patterns, backup, and cache strategies.
• Identify connection, partition, index, hot-key, and cache-consistency risks.

Mental model

Relational databases are strong when transactions, constraints, and joins define correctness. DynamoDB is strong when predictable key-based access, horizontal scale, and managed operation dominate. Redshift targets analytical warehousing; OpenSearch targets search/log analytics; Neptune graph relationships; Timestream time-series data.

A cache is a derived copy that improves latency or protects a backend. Cache-aside lets the application load misses, write-through updates cache with writes, and TTL bounds staleness. DAX accelerates compatible DynamoDB reads; ElastiCache provides Redis or Memcached engines for application caching patterns.

Design

Write the exact reads and writes, transaction boundaries, consistency, item size, growth, latency, and geographic needs. Avoid using a cache to hide a fundamentally wrong database model. Plan connection pooling or RDS Proxy for bursty serverless access to relational engines.

Decision rules

Operations

Monitor connections, lock waits, replica lag, free storage, cache hit rate, evictions, DynamoDB throttles, consumed capacity, hot partitions, and query latency. Test failover and verify applications reconnect correctly.

Failure modes

• Sending writes to a read replica.
• Using a low-cardinality DynamoDB partition key that concentrates traffic.
• Caching sensitive or mutable data without invalidation and access controls.

Key points

• RDS Multi-AZ provides availability; read replicas provide read scaling and can support regional recovery patterns.
• Aurora replicas share distributed storage and can serve reads; Aurora global database addresses cross-Region read and recovery patterns.
• DynamoDB on-demand adapts to variable traffic; provisioned capacity supports explicit capacity management and auto scaling.
• Partition-key choice must distribute traffic; global secondary indexes add alternate queries and independent capacity/cost considerations.

Example — Access-pattern-first data model

Access patterns:
1. Get order by order ID
2. List customer orders newest first
3. Find pending orders by fulfillment region

DynamoDB candidate:
PK=ORDER#<id>, SK=METADATA
GSI1PK=CUSTOMER#<id>, GSI1SK=<timestamp>#<order-id>
GSI2PK=STATUS#PENDING#<region>, GSI2SK=<timestamp>

Validate cardinality, traffic distribution, consistency, and item size before selecting.

Related labs

• Assemble a serverless order flow (lab-serverless-orders)
• Repair a fragile web architecture (lab-resilient-web)

Sources

• Amazon RDS User Guide — Databases
• Amazon DynamoDB Developer Guide — Databases

Course: Cloud & AWS Foundations — Tracks: CLF · SAA · HPC — Level: Foundation — ~24 min

Replace the 'someone else’s computer' shortcut with a precise model of on-demand access, measured use, elasticity, managed responsibility, and programmable infrastructure.

Objectives

• Explain the essential characteristics of cloud computing without tying them to one vendor.
• Distinguish IaaS, PaaS, managed services, and SaaS by responsibility boundary.
• Recognize when elasticity, global reach, or managed operations creates business value.

Mental model

Cloud computing is an operating model: resources are requested through an interface, delivered from a shared provider pool, scaled with demand, and metered. The most useful question is not where the server sits, but which responsibility, scaling, and failure decisions have moved to the provider.

NIST describes five essential characteristics—on-demand self-service, broad network access, resource pooling, rapid elasticity, and measured service. AWS turns those characteristics into APIs for compute, storage, databases, networking, analytics, and many higher-level capabilities.

Design

Exam scenarios often hide the relevant cloud characteristic inside a business statement. Translate 'launch in minutes' to on-demand provisioning, 'serve a seasonal spike' to elasticity, 'avoid maintaining database software' to a managed service, and 'pay only while a job runs' to measured consumption.

Decision rules

Operations

A cloud adoption fails when procurement speed improves but governance, identity, tagging, observability, and cost accountability do not. Build those controls as part of the platform rather than as an approval queue after deployment.

Failure modes

• Treating every managed service as automatically cheaper without modeling request, storage, transfer, and operational costs.
• Confusing high availability with backup; redundant live components do not protect against deletion or logical corruption.
• Lifting a fixed-capacity architecture unchanged and expecting elasticity to appear automatically.

Key points

• Elasticity changes capacity in response to demand; scalability is the ability of a design to handle growth.
• Managed does not mean responsibility-free. You still own data classification, access decisions, configuration, and workload behavior.
• Consumption pricing can reduce idle capital, but only when teams measure, right-size, and turn off unused capacity.
• Cloud-native design treats infrastructure, policy, deployment, and observability as programmable systems.

Example — Translate a requirement into cloud characteristics

Requirement: process 20,000 simulation jobs during a three-day research window.

Cloud characteristics:
- on-demand self-service: provision workers through an API
- rapid elasticity: scale the worker fleet with the queue
- measured service: pay for worker time and storage consumed
- resource pooling: select capacity from the provider fleet

Architecture implication:
Submit work to a durable queue, add stateless workers, store results outside each worker, and scale to zero after completion.

Related labs

• Draw the responsibility boundary (lab-shared-responsibility)
• Choose the cost and support tool (lab-cost-support)

Sources

• The NIST Definition of Cloud Computing — Cloud foundations
• AWS Well-Architected Framework — Architecture
• AWS Pricing — Cost

Course: Cloud & AWS Foundations — Tracks: CLF · SAA · HPC — Level: Foundation — ~25 min

Use AWS failure boundaries deliberately: choose a Region for legal and latency constraints, multiple Availability Zones for workload resilience, and edge services for global delivery.

Objectives

• Differentiate Regions, Availability Zones, edge locations, and Local Zones by purpose.
• Explain why multi-AZ is a workload design rather than a property of every service.
• Choose a deployment geography using data residency, latency, service availability, and disaster-recovery needs.

Mental model

A Region is an independent geographic area. An Availability Zone is a distinct infrastructure location within a Region, connected to other zones through high-bandwidth, low-latency links. Edge locations bring selected services closer to users, while Local Zones extend certain regional services near a metro area.

AWS services have different scopes. IAM and Route 53 are examples of globally oriented services; VPCs and many service control planes are regional; subnets and EC2 instances are zonal. Scope determines both failure behavior and how resources are referenced.

Design

Start geography decisions with constraints: where data may reside, where users and data sources are located, which services and capacity are available, and what failure the business must survive. Then decide whether the workload needs one Region with multiple AZs, a paired disaster-recovery Region, or active service in multiple Regions.

Decision rules

Operations

Test failure at the boundary you claim to tolerate. A multi-AZ label is insufficient if DNS, NAT, storage mounts, databases, or deployment tooling still depend on one zone. For cross-Region recovery, test data freshness, credential availability, DNS convergence, quotas, and runbook timing.

Failure modes

• Creating two subnets in the same Availability Zone and calling the design multi-AZ.
• Using a single NAT gateway for private workloads in several zones without accepting the cross-zone dependency and data-processing cost.
• Assuming every service or instance family is available in every Region and zone.

Key points

• A multi-AZ architecture places independent capacity in at least two zones and removes single-zone dependencies from the request path.
• A second Region addresses a broader failure and compliance boundary, but adds data-replication, consistency, routing, and cost decisions.
• Service availability, quotas, instance types, and pricing can differ by Region.
• CloudFront and Route 53 can improve global user experience without running the entire application in every Region.

Example — Inspect Regions and Availability Zones

aws ec2 describe-regions --all-regions \
  --query 'Regions[].{Name:RegionName,Status:OptInStatus}'

aws ec2 describe-availability-zones \
  --region eu-west-1 \
  --query 'AvailabilityZones[].{Zone:ZoneName,ZoneId:ZoneId,State:State}'

Related labs

• Build a two-AZ VPC skeleton (lab-two-az-vpc)
• Repair a fragile web architecture (lab-resilient-web)

Sources

• AWS Global Infrastructure — Architecture
• AWS Well-Architected Framework — Architecture

Course: Identity & Shared Security — Tracks: CLF · SAA · HPC — Level: Core — ~32 min

Connect the security responsibility boundary to concrete IAM decisions: human federation, workload roles, temporary credentials, policy evaluation, and layered guardrails.

Objectives

• Assign common security tasks to AWS or the customer for IaaS and managed services.
• Separate authentication from authorization and human identities from workload identities.
• Apply least privilege with roles, short-lived credentials, explicit guardrails, and policy analysis.

Mental model

AWS is responsible for security of the cloud: the facilities, hardware, foundational network, and managed-service infrastructure. Customers are responsible for security in the cloud: identities, data, resource configuration, workload code, and operating systems where they control them. The exact boundary moves by service.

IAM answers who or what may perform which action on which resource under which conditions. Authentication establishes identity. Authorization evaluates policies. Roles provide temporary credentials and are the default identity mechanism for workloads and federated access.

Design

Work backward from a principal’s exact job. Define the required API actions, resources, and conditions; supply them through a role; constrain privilege escalation paths; and record access through CloudTrail. At organization scale, use account boundaries and SCPs as guardrails while keeping workload policies precise.

Decision rules

Operations

Review unused permissions and last-accessed data, validate policies before deployment, alert on privileged changes, and test both expected access and expected denial. Emergency roles need tightly controlled activation, strong logging, and a post-use review.

Failure modes

• Using the root user for routine administration or leaving it without MFA and protected recovery controls.
• Granting Action: * and Resource: * because a workload initially failed with least privilege.
• Assuming an identity-based Allow defeats an explicit Deny from another applicable policy layer.

Key points

• Use an external identity provider and IAM Identity Center for workforce access rather than creating long-lived IAM users for every person.
• Attach roles to EC2, Lambda, ECS tasks, EKS workloads, and HPC nodes instead of storing access keys in code or images.
• An explicit Deny overrides an Allow; absence of an applicable Allow produces an implicit deny.
• MFA, separation of duties, permissions boundaries, SCPs, and resource policies solve different layers of the authorization problem.

Example — A workload role scoped to one result prefix

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": ["s3:GetObject", "s3:PutObject"],
    "Resource": "arn:aws:s3:::research-results/project-a/*"
  }]
}

Related labs

• Draw the responsibility boundary (lab-shared-responsibility)
• Repair an IAM policy (lab-iam-policy)
• Harden a result bucket (lab-secure-s3)

Sources

• Shared Responsibility Model — Security
• IAM User Guide — Security
• Policy Evaluation Logic — Security

Course: Cloud & AWS Foundations — Tracks: CLF · SAA · HPC — Level: Core — ~27 min

Use the six Well-Architected pillars as a review system rather than a memorized list, and make trade-offs explicit through workload context and measurable outcomes.

Objectives

• Name and apply the six Well-Architected pillars.
• Convert a broad architectural concern into a review question and measurable risk.
• Explain why architecture decisions are contextual trade-offs rather than universal best answers.

Mental model

The AWS Well-Architected Framework organizes review around operational excellence, security, reliability, performance efficiency, cost optimization, and sustainability. Each pillar contains design principles and questions that expose risk before risk becomes an incident.

A review is not a compliance badge. It is a structured conversation about workload purpose, failure tolerance, security boundaries, operational capability, performance demand, cost, and environmental efficiency. Improvement items should be prioritized by business impact and effort.

Design

When two options both appear valid, identify the pillar tension. A larger instance may improve performance but reduce utilization. Synchronous cross-Region writes may improve data protection but add latency and cost. The right answer satisfies the stated requirement with the fewest unrequested complexities.

Decision rules

Operations

Run reviews at meaningful change points and after incidents, not once at project launch. Track risks as owned backlog items, verify remediation, and revisit assumptions when usage, regulations, team capability, or service features change.

Failure modes

• Calling a system reliable because components are redundant without testing dependency and data recovery.
• Optimizing unit price while ignoring engineering effort, transfer, support, and failure cost.
• Treating security as a perimeter product rather than identity, data, workload, detection, and response layers.

Key points

• Operational excellence: run, observe, learn, and improve through automation and small reversible changes.
• Security: maintain strong identity, traceability, layered controls, data protection, and prepared incident response.
• Reliability: recover from failure, test recovery, scale with demand, and automate change.
• Performance efficiency, cost optimization, and sustainability all require measurement rather than intuition.

Example — Turn a vague concern into a review item

Concern: "The batch platform should be reliable."

Review question: What failures must the platform tolerate without losing accepted jobs?
Metric: accepted jobs with durable state / total accepted jobs
Target: 100% durable acceptance; RPO 0 for queue state
Test: terminate workers and one Availability Zone during a controlled run
Improvement: keep job state in a multi-AZ managed queue, make workers idempotent, and externalize checkpoints.

Related labs

• Repair a fragile web architecture (lab-resilient-web)
• Optimize without breaking requirements (lab-cost-optimize)
• Diagnose an HPC performance regression (lab-hpc-diagnosis)

Sources

• AWS Well-Architected Framework — Architecture
• AWS Well-Architected Framework — HPC Lens — HPC

Course: Cloud Operations & IaC — Tracks: CLF · SAA · HPC — Level: Core — ~29 min

Understand AWS as an API platform and use repeatable, reviewable automation for infrastructure and operations.

Objectives

• Explain how the Console, CLI, SDKs, and IaC tools reach AWS service APIs.
• Use profiles, Regions, output filtering, and dry-run or change-review mechanisms safely.
• Describe idempotence, state, drift, and lifecycle implications of declarative infrastructure.

Mental model

The AWS Management Console, CLI, SDKs, CloudFormation, and third-party infrastructure-as-code tools are different clients of AWS service APIs. Learning the resource model and API vocabulary transfers across interfaces.

Infrastructure as code describes desired resources in versioned text, then delegates creation and updates to a deployment engine. CloudFormation manages resources as a stack. A template’s Resources section is required; parameters, mappings, conditions, outputs, and metadata support reuse and control.

Design

Use the console to explore and visualize, the CLI for focused operations and scripting, SDKs inside applications, and IaC for durable environment definitions. The exam typically asks which approach improves consistency, repeatability, auditability, or speed across environments.

Decision rules

Operations

Make deployments observable: record stack events, surface failed resources, detect drift, and split extremely large stacks along ownership and lifecycle boundaries. For CI/CD, use workload identity rather than storing permanent credentials in the pipeline.

Failure modes

• Running a command in the wrong account or Region because context was implicit.
• Committing keys, passwords, or decrypted secrets in a template or state file.
• Assuming an IaC tool will safely infer every migration for a resource with persistent data.

Key points

• Use named profiles or federated sessions and always make the account and Region visible before changing resources.
• Prefer declarative, idempotent automation over one-off console sequences for repeatable environments.
• Review change sets or plans, protect stateful resources, detect drift, and keep secrets out of templates and repositories.
• Automation does not remove the need for quotas, dependency ordering, rollback planning, and observability.

Example — Minimal CloudFormation structure

AWSTemplateFormatVersion: '2010-09-09'
Description: Encrypted result bucket
Resources:
  ResultsBucket:
    Type: AWS::S3::Bucket
    DeletionPolicy: Retain
    UpdateReplacePolicy: Retain
    Properties:
      BucketEncryption:
        ServerSideEncryptionConfiguration:
          - ServerSideEncryptionByDefault:
              SSEAlgorithm: AES256
      PublicAccessBlockConfiguration:
        BlockPublicAcls: true
        IgnorePublicAcls: true
        BlockPublicPolicy: true
        RestrictPublicBuckets: true

Related labs

• Secure a CloudFormation template (lab-cloudformation)
• Build a two-AZ VPC skeleton (lab-two-az-vpc)

Sources

• AWS CLI Command Reference — Tools
• AWS CloudFormation User Guide — Infrastructure as code
• AWS CloudFormation Workshop — Workshop

Course: Cloud Networking — Tracks: CLF · SAA · HPC — Level: Core — ~38 min

Build a packet-level model of VPCs, subnets, routes, gateways, security groups, NACLs, DNS, endpoints, and hybrid connectivity.

Objectives

• Trace a packet through DNS, routes, gateways, security groups, and network ACLs.
• Distinguish public and private subnets by routing rather than by name.
• Choose VPC peering, Transit Gateway, PrivateLink, VPN, or Direct Connect based on connectivity shape.

Mental model

A VPC is a regional, logically isolated network. A subnet belongs to one Availability Zone. Route tables decide the next hop for destination prefixes. An internet gateway enables internet routing for public IPv4 addresses; a NAT gateway gives private IPv4 workloads outbound internet access without accepting unsolicited inbound connections.

Security groups are stateful and attach to network interfaces. Network ACLs are stateless subnet controls. Route tables do not authorize traffic, and security groups do not create a path. Successful connectivity requires DNS resolution, a route in each direction, permissive controls, and a listening application.

Design

Select the connection pattern by topology and trust boundary. Peering is direct and non-transitive. Transit Gateway centralizes many VPC and hybrid connections. PrivateLink publishes a service privately without full network adjacency. Site-to-Site VPN uses encrypted internet paths; Direct Connect provides dedicated connectivity and is often paired with VPN for resilience.

Decision rules

Operations

Troubleshoot in order: resolve the name, confirm source and destination addresses, inspect routes on both sides, verify security groups, verify NACLs, check the target listener and health, then use VPC Flow Logs and service logs. Avoid changing several layers at once because it hides the root cause.

Failure modes

• Calling a subnet private while its route table still sends default traffic to an internet gateway.
• Opening a security group when the route, NACL, DNS, or application listener is the actual failure.
• Using one NAT gateway across zones without considering availability and cross-zone processing charges.

Key points

• A public subnet has a route to an internet gateway; an instance also needs a public address and security policy that permits the traffic.
• Use VPC endpoints to reach supported AWS services privately and reduce NAT dependency or exposure.
• Prefer security-group references for application tiers because they describe identity-like relationships rather than changing IP lists.
• Overlapping CIDR ranges block simple routed connectivity and should be prevented through address planning.

Example — Create a two-AZ VPC skeleton

aws ec2 create-vpc --cidr-block 10.40.0.0/16 --tag-specifications 'ResourceType=vpc,Tags=[{Key=Name,Value=academy}]'
aws ec2 create-subnet --vpc-id vpc-001 --cidr-block 10.40.1.0/24 --availability-zone eu-west-1a
aws ec2 create-subnet --vpc-id vpc-001 --cidr-block 10.40.2.0/24 --availability-zone eu-west-1b
aws ec2 create-internet-gateway
aws ec2 attach-internet-gateway --internet-gateway-id igw-001 --vpc-id vpc-001
aws ec2 create-route-table --vpc-id vpc-001

Related labs

• Build a two-AZ VPC skeleton (lab-two-az-vpc)
• Repair a fragile web architecture (lab-resilient-web)
• Configure and verify an EFA cluster (lab-efa-cluster)

Sources

• Amazon VPC User Guide — Networking
• Amazon Route 53 Developer Guide — Networking
• Amazon CloudFront Developer Guide — Networking

Course: Storage, Data & Integration — Tracks: CLF · SAA · HPC — Level: Core — ~36 min

Choose storage by access semantics, sharing model, latency, throughput, durability, lifecycle, and data-gravity constraints—not by a generic 'fast storage' label.

Objectives

• Differentiate object, block, file, archive, and parallel-file access patterns.
• Map S3, EBS, EFS, FSx, instance store, and archival tiers to workload requirements.
• Design for encryption, backup, versioning, lifecycle, replication, and data transfer.

Mental model

Storage services expose different semantics. S3 stores objects addressed by key through APIs. EBS presents block devices to compute in an Availability Zone. EFS presents a managed NFS file system to many clients. FSx provides managed file systems for specific protocols and performance profiles. Instance store is temporary storage physically attached to a host.

Durability, availability, latency, IOPS, throughput, and consistency are different dimensions. A durable object may not be immediately cheap to retrieve from an archive tier; a low-latency block volume is not automatically shareable; a high-throughput file system may require parallel clients and large request sizes to reach its target.

Design

Start with the interface the application requires, then quantify capacity, read/write pattern, concurrency, latency, IOPS, throughput, durability, recovery, and retention. Lifecycle cold data, compress where appropriate, avoid unnecessary copies, and place compute near large datasets.

Decision rules

Operations

Monitor bytes, request rates, queue depth, latency, throughput, burst balance, and error rates. Test restoration, not only backup creation. For large migrations, compare online transfer, acceleration, DataSync, and offline appliances against the time and bandwidth window.

Failure modes

• Selecting storage from capacity alone and discovering the request or throughput pattern is the real constraint.
• Treating S3 prefixes as directories with full POSIX rename and locking semantics.
• Keeping all data in the hottest tier because no owner defined retention and recovery requirements.

Key points

• Use S3 for durable object data, static assets, data lakes, backups, and decoupled exchange when file-system semantics are unnecessary.
• Use EBS for instance-attached boot and transactional block workloads; select volume type and provisioned performance from measured demand.
• Use EFS for shared Linux file access and FSx variants when a workload requires a specialized protocol or parallel performance.
• Backups and replicas solve different problems; versioning and object lock can protect against overwrite or deletion patterns.

Example — Protect an S3 result bucket

aws s3api create-bucket --bucket academy-results-123 --region eu-west-1 --create-bucket-configuration LocationConstraint=eu-west-1
aws s3api put-public-access-block --bucket academy-results-123 --public-access-block-configuration BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true
aws s3api put-bucket-encryption --bucket academy-results-123 --server-side-encryption-configuration '{"Rules":[{"ApplyServerSideEncryptionByDefault":{"SSEAlgorithm":"AES256"}}]}'
aws s3api put-bucket-versioning --bucket academy-results-123 --versioning-configuration Status=Enabled

Related labs

• Harden a result bucket (lab-secure-s3)
• Select storage from access patterns (lab-storage-selection)
• Stage, benchmark, and export HPC data (lab-fsx-stage)

Sources

• Amazon S3 User Guide — Storage
• Amazon EBS User Guide — Storage
• Amazon EFS User Guide — Storage
• Amazon FSx for Lustre User Guide — HPC storage

Course: Compute Foundations — Tracks: CLF · SAA · HPC — Level: Core — ~34 min

Select compute from workload shape, control requirements, scaling unit, runtime duration, startup tolerance, hardware needs, and operational ownership.

Objectives

• Compare EC2, containers, Lambda, and managed batch patterns.
• Match instance families and purchasing models to measured workload behavior.
• Design stateless scaling, immutable deployment, health checks, and graceful interruption handling.

Mental model

EC2 provides virtual machines and the broadest control over operating system, network, accelerator, and runtime. Containers package processes and dependencies while an orchestrator manages placement and lifecycle. Lambda runs functions in response to events with a constrained execution model. Batch systems queue work and schedule it onto suitable capacity.

The scaling unit matters. An instance scales a whole machine, a task or pod scales a container group, a function scales invocations, and a batch scheduler scales queued jobs. Choose the unit that aligns with workload isolation and demand.

Design

Prefer the highest-level compute abstraction that meets hard requirements. Drop to instances when the workload needs specialized networking, drivers, long-lived processes, privileged access, or precise placement. Use containers for portable long-running services and functions for event-driven units within their runtime model.

Decision rules

Operations

Measure CPU, memory, network, disk, accelerator utilization, queue wait, startup time, and request latency. Right-sizing from CPU alone can be wrong when memory, network, EBS bandwidth, or licensing limits the workload. Keep workloads disposable by externalizing durable state.

Failure modes

• Scaling instances while keeping sessions or critical files only on local disks.
• Using Spot for an uncheckpointed, non-restartable job with a strict completion deadline.
• Choosing an instance family by vCPU count while ignoring memory bandwidth, network, accelerator, or software licensing.

Key points

• General-purpose, compute-, memory-, storage-, accelerated-, and HPC-optimized families target different resource ratios and hardware capabilities.
• Auto Scaling needs a launch definition, health signals, capacity bounds, and a scaling policy; the application must tolerate instance replacement.
• On-Demand capacity prioritizes flexibility, Savings Plans or reservations reward commitment, and Spot trades price for interruption risk.
• Serverless reduces infrastructure operations but still requires concurrency, timeout, retry, idempotency, and cost design.

Example — Launch a tagged instance through the CLI

aws ec2 run-instances \
  --image-id ami-example \
  --instance-type t3.micro \
  --subnet-id subnet-private-a \
  --security-group-ids sg-app \
  --iam-instance-profile Name=academy-app-role \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=academy-worker},{Key=Environment,Value=lab}]'

Related labs

• Repair a fragile web architecture (lab-resilient-web)
• Assemble a serverless order flow (lab-serverless-orders)
• Survive a Spot interruption (lab-spot-checkpoint)

Sources

• Amazon EC2 User Guide — Compute
• AWS Lambda Developer Guide — Compute
• Containers on AWS — Compute

Course: Storage, Data & Integration — Tracks: CLF · SAA · HPC — Level: Core — ~37 min

Model data and integration by access pattern, consistency, coupling, fan-out, ordering, retry, and failure recovery.

Objectives

• Choose relational, key-value/document, cache, and object data stores from access patterns.
• Differentiate queues, pub/sub topics, event buses, and workflow orchestration.
• Design retries, dead-letter handling, idempotency, and back-pressure.

Mental model

A database choice begins with access patterns and correctness, not service popularity. Relational engines support schemas, joins, and transactions. DynamoDB targets key-value and document access at scale when keys and indexes are designed around known queries. Caches trade freshness and complexity for lower latency and backend load.

Integration services create temporal and deployment boundaries. A queue buffers work for consumers. A topic fans one publication to multiple subscribers. An event bus routes events by attributes. A workflow service coordinates steps and state. These are not interchangeable labels.

Design

Ask what must be queried, at what scale and latency, with what consistency and transaction scope. For integration, decide whether the producer needs a response now, how long work may wait, whether all consumers receive it, whether order matters, and how failure is retried or isolated.

Decision rules

Operations

Monitor queue age, depth, receive count, consumer errors, database connections, latency, throttling, cache hit rate, replication lag, and storage growth. Retry with bounded exponential backoff and jitter. Alarm on age and failure, not only raw queue length.

Failure modes

• Replacing every synchronous call with a queue without considering user-facing response requirements.
• Retrying a non-idempotent write indefinitely and creating duplicate charges or orders.
• Choosing DynamoDB before defining partition keys and expected queries.

Key points

• RDS Multi-AZ is primarily availability; read replicas are primarily read scaling and can also support recovery patterns.
• DynamoDB partition and sort keys determine item placement and query capability; scans are not a substitute for data modeling.
• At-least-once delivery requires idempotent consumers or deduplication where duplicated effects are unacceptable.
• Dead-letter queues preserve failed messages for diagnosis; they do not fix poison messages automatically.

Example — Decoupled order flow

Client → API Gateway → Lambda → DynamoDB
                         └→ SQS order-events → worker
                                              ├→ idempotency check
                                              ├→ process payment
                                              └→ write result

Alarm on ApproximateAgeOfOldestMessage.
Move repeatedly failing messages to a dead-letter queue.
Use an order ID as an idempotency key.

Related labs

• Assemble a serverless order flow (lab-serverless-orders)
• Instrument and diagnose a backlog (lab-observability)

Sources

• Amazon RDS User Guide — Databases
• Amazon DynamoDB Developer Guide — Databases
• Application Integration on AWS — Integration

Course: Cloud Operations & IaC — Tracks: CLF · SAA · HPC — Level: Core — ~34 min

Separate workload telemetry from API audit, build actionable signals, and use account structure plus policy guardrails to manage cloud at scale.

Objectives

• Differentiate metrics, logs, traces, events, configuration history, and API audit records.
• Use CloudWatch, CloudTrail, Config, Organizations, and Systems Manager for distinct operational questions.
• Design alarms and account boundaries around ownership, blast radius, and business outcomes.

Mental model

Observability is the ability to infer internal state from emitted signals. Metrics summarize behavior over time, logs describe discrete records, traces connect work across components, and events represent state changes. CloudTrail answers who called which AWS API; CloudWatch monitors workload and service telemetry.

Governance creates safe freedom through identity, account structure, policy, standards, and visibility. AWS Organizations groups accounts and supports consolidated billing and service control policies. Separate accounts provide stronger resource, quota, billing, and blast-radius boundaries than tags alone.

Design

Begin with service-level objectives and failure modes, then choose signals that reveal them early. For governance, map business units, environments, regulated workloads, and shared services into an account hierarchy, then apply guardrails that prevent unacceptable actions without blocking normal delivery.

Decision rules

Operations

Test alerts against controlled failure, include runbook context, control alert noise, and review data retention and cost. Prevent blind spots by monitoring telemetry pipelines themselves. Use delegated administration and least privilege for centralized operations.

Failure modes

• Creating hundreds of threshold alarms without an owner or response action.
• Using CloudTrail as an application-performance monitoring system.
• Putting every environment in one account and relying only on tags for isolation.

Key points

• Alarm on user or workload impact—latency, error rate, saturation, queue age, failed jobs—not every raw metric.
• Centralize security and audit data with retention and access controls that workload administrators cannot silently disable.
• Use accounts for meaningful isolation and tags for allocation, search, automation, and ownership inside those boundaries.
• Configuration history and API history answer different questions; neither replaces application logs and traces.

Example — Create an alarm on queue age

aws cloudwatch put-metric-alarm \
  --alarm-name orders-oldest-message-high \
  --namespace AWS/SQS \
  --metric-name ApproximateAgeOfOldestMessage \
  --dimensions Name=QueueName,Value=orders \
  --statistic Maximum --period 60 --evaluation-periods 5 \
  --threshold 300 --comparison-operator GreaterThanThreshold

Related labs

• Instrument and diagnose a backlog (lab-observability)
• Diagnose an HPC performance regression (lab-hpc-diagnosis)

Sources

• Amazon CloudWatch User Guide — Operations
• AWS CloudTrail User Guide — Governance
• AWS Organizations User Guide — Governance

Course: CLF · Cloud Concepts — Tracks: CLF — Level: CLF-C02 — ~28 min

Connect AWS cloud value propositions to real operating outcomes: agility, elasticity, global reach, resilience, managed operations, and variable expense.

Objectives

• Distinguish capital expense, variable expense, total cost, and economies of scale.
• Map business requirements to cloud benefits without assuming every migration saves money.
• Recognize common AWS Cloud design principles in foundational scenarios.

Mental model

Cloud economics replaces some up-front procurement with metered consumption and lets organizations provision in smaller increments. The provider aggregates demand across many customers, while each customer can trade commitment, flexibility, and interruption tolerance through purchasing models.

The value is broader than unit price. Teams can shorten provisioning cycles, experiment with smaller reversible investments, reach additional Regions, use managed capabilities, and align capacity more closely with demand. Total cost still includes architecture, people, migration, data transfer, support, licensing, and risk.

Design

Translate each scenario to the benefit it actually states. A faster experiment is agility, a global launch is geographic reach, lower maintenance is managed operations, scaling down after a campaign is elasticity, and replacing a capital purchase with usage billing is variable expense.

Decision rules

Operations

Track unit economics such as cost per request, customer, job, or experiment. A monthly bill alone does not show whether usage created value. Pair financial ownership with tags, budgets, anomaly detection, and engineering metrics.

Failure modes

• Equating pay-as-you-go with automatically low cost while leaving idle resources running.
• Buying long commitments before measuring a workload’s stable baseline.
• Treating migration as a hosting move with no process, security, or architecture change.

Key points

• Trade fixed expense for variable expense when uncertain demand makes long-term peak capacity inefficient.
• Benefit from economies of scale when provider purchasing and operational scale are reflected in service pricing and capability.
• Stop guessing capacity by measuring demand and using elastic or serverless designs.
• Increase speed and agility by automating provisioning and making experiments disposable.

Example — A simple value comparison

Traditional peak design:
- buy for 1,000 requests/s
- average demand: 180 requests/s
- procurement lead time: 8 weeks

Elastic cloud design:
- baseline capacity for normal traffic
- scale on queue depth or request load
- deploy through an automated pipeline

Measure:
- cost per 1,000 requests
- lead time for a safe release
- percentage of capacity actively used
- revenue or research output protected during peaks

Related labs

• Choose the cost and support tool (lab-cost-support)
• Optimize without breaking requirements (lab-cost-optimize)

Sources

• AWS Certified Cloud Practitioner (CLF-C02) Exam Guide — Certification
• AWS Pricing — Cost
• AWS Cost Management — Cost
• AWS Well-Architected Framework — Architecture

Course: CLF · Cloud Concepts — Tracks: CLF — Level: CLF-C02 — ~27 min

Frame cloud adoption as coordinated business, people, governance, platform, security, and operations change—not a server-copy project.

Objectives

• Explain the purpose of the AWS Cloud Adoption Framework perspectives.
• Recognize common migration strategies and when each is appropriate.
• Identify migration tools and the role of discovery, dependency mapping, and validation.

Mental model

The AWS Cloud Adoption Framework organizes transformation capabilities across Business, People, Governance, Platform, Security, and Operations perspectives. It helps expose nontechnical dependencies such as skills, ownership, financial controls, and operating models before migration waves begin.

Migration strategies range from retire and retain through rehost, relocate, replatform, repurchase, and refactor. The strategy is workload-specific. A low-change rehost can accelerate a data-center exit; a refactor can unlock elasticity but requires more engineering and validation.

Design

Choose the least disruptive strategy that satisfies the business outcome and timeline. Do not refactor because it sounds modern; refactor when the resulting capability—scalability, deployment speed, resilience, or reduced operations—justifies the change.

Decision rules

Operations

Pilot a representative wave, establish rollback, measure cutover, and update the wave plan from evidence. After migration, right-size, remove temporary transfer resources, validate backup and monitoring, and decommission the source safely.

Failure modes

• Migrating before identifying upstream and downstream dependencies.
• Moving workloads into an account with no logging, identity standard, network design, or cost ownership.
• Declaring success while the old environment still runs and doubles cost.

Key points

• Discovery establishes inventory, utilization, dependencies, licensing, business criticality, and data constraints.
• A landing zone provides account structure, identity, networking, logging, and governance for migration waves.
• AWS Application Migration Service supports server migration; Database Migration Service supports many database moves; DataSync and transfer appliances address data movement patterns.
• Migration completion requires testing functionality, performance, security, operations, recovery, and cutover/rollback—not only copying bytes.

Example — Strategy selection worksheet

Workload: internal document system
Constraint: vendor support ends in 12 months
Usage: stable, low growth
Differentiation: none
SaaS fit: strong

Candidate strategy: repurchase
Validation:
- identity federation and access roles
- data export/import and retention
- legal and residency review
- integration replacement
- user acceptance and rollback
- source decommission date

Related labs

• Choose a disaster-recovery strategy (lab-dr-strategy)
• Choose the cost and support tool (lab-cost-support)

Sources

• AWS Cloud Adoption Framework — Transformation
• AWS Certified Cloud Practitioner (CLF-C02) Exam Guide — Certification

Course: CLF · Security & Compliance — Tracks: CLF — Level: CLF-C02 — ~33 min

Recognize AWS security services, compliance responsibilities, encryption choices, audit evidence, and support resources at the foundational level.

Objectives

• Distinguish compliance of the cloud from customer workload compliance.
• Map common security needs to AWS services and features.
• Identify where to obtain AWS compliance reports, security guidance, and abuse support.

Mental model

AWS compliance programs and infrastructure controls can support a customer’s compliance goals, but the customer must configure services, identities, data handling, logging, and applications to meet its own obligations. Certification of a service provider does not automatically certify a workload.

Security capabilities form layers: IAM and federation for identity, KMS and service encryption for data protection, WAF and Shield for web and denial-of-service protections, GuardDuty and Security Hub for detection and posture, Inspector for vulnerability management, Macie for sensitive S3 data discovery, and CloudTrail/Config for evidence.

Design

Use the requirement wording. 'Who called an API?' points to CloudTrail. 'Which resources drifted from rules?' points to Config. 'Block SQL injection patterns at the web edge' points to WAF. 'Discover sensitive data in S3' points to Macie. 'Find suspicious account activity' points to GuardDuty.

Decision rules

Operations

Enable evidence and detection before incidents. Centralize CloudTrail, protect log stores, define Config rules or conformance packs, triage findings, and test incident contacts. Keep account contact information and abuse/security escalation paths current.

Failure modes

• Assuming encryption alone prevents an overprivileged principal from reading data.
• Confusing security groups with AWS WAF or Shield.
• Treating an AWS compliance report as proof that the customer application is compliant.

Key points

• AWS Artifact provides on-demand access to AWS compliance reports and selected agreements.
• KMS manages encryption keys and integrates with many services; Secrets Manager and Parameter Store address secret/configuration storage patterns.
• AWS Shield Standard is included for common network and transport-layer DDoS protection; WAF filters web requests by rules.
• Compliance scope, data classification, retention, key control, and access review remain customer decisions.

Example — Requirement-to-service map

API audit history                 → AWS CloudTrail
Resource configuration compliance  → AWS Config
Web request filtering               → AWS WAF
DDoS protection                     → AWS Shield
Threat detection                    → Amazon GuardDuty
Security posture aggregation        → AWS Security Hub
Sensitive S3 data discovery         → Amazon Macie
Vulnerability management            → Amazon Inspector
Compliance reports                  → AWS Artifact

Related labs

• Draw the responsibility boundary (lab-shared-responsibility)
• Harden a result bucket (lab-secure-s3)
• Instrument and diagnose a backlog (lab-observability)

Sources

• Shared Responsibility Model — Security
• IAM User Guide — Security
• AWS CloudTrail User Guide — Governance

Course: CLF · Technology & Services — Tracks: CLF — Level: CLF-C02 — ~42 min

Build a compact decision map across compute, storage, database, networking, analytics, integration, AI/ML, and developer services.

Objectives

• Recognize the primary use of common in-scope AWS services.
• Differentiate services that appear similar by interface and responsibility model.
• Avoid service-name memorization by translating requirements into resource patterns.

Mental model

Foundational service selection becomes manageable when services are grouped by the resource or outcome they provide. EC2 is virtual-machine compute, Lambda is event-driven function compute, ECS/EKS orchestrate containers, and Elastic Beanstalk deploys applications on managed environment patterns. S3 is object storage, EBS block storage, and EFS shared NFS file storage.

RDS and Aurora are managed relational databases; DynamoDB is a managed key-value/document database; ElastiCache provides in-memory caching. VPC creates private networks, Route 53 provides DNS and routing, CloudFront is a CDN, API Gateway manages APIs, and Elastic Load Balancing distributes traffic.

Design

Reduce every question to an interface. Does the application need objects, blocks, files, rows, key lookups, messages, events, streams, DNS, caching, or compute execution? Then identify how much infrastructure control versus managed operation is required.

Decision rules

Operations

Use service health dashboards, CloudWatch, CloudTrail, Trusted Advisor, documentation, re:Post, and AWS Support according to the issue. Service choice also affects quotas, Regions, encryption options, integration behavior, and billing dimensions.

Failure modes

• Selecting EBS when many instances need a shared file system.
• Selecting SNS when a single worker pool needs durable competing consumption and back-pressure.
• Selecting a database only by popularity without query and consistency requirements.

Key points

• SQS queues messages, SNS publishes to subscribers, EventBridge routes events, and Step Functions orchestrates workflows.
• Redshift is a data warehouse; Athena queries data in S3; Glue supports data integration/catalog patterns; Kinesis handles streaming data patterns.
• SageMaker supports building and operating machine-learning workflows, while AI services expose prebuilt capabilities for specific use cases.
• CloudFormation provisions infrastructure, CodePipeline coordinates delivery, CloudWatch monitors, and CloudTrail audits AWS API activity.

Example — One-line service map

VMs → EC2                 Containers → ECS/EKS/Fargate
Functions → Lambda          Batch jobs → AWS Batch
Objects → S3                Blocks → EBS
Shared files → EFS          Specialized files → FSx
Relational → RDS/Aurora     Key-value/document → DynamoDB
Cache → ElastiCache         Warehouse → Redshift
Queue → SQS                 Pub/sub → SNS
Events → EventBridge        Workflow → Step Functions
DNS → Route 53              CDN → CloudFront
Metrics/logs → CloudWatch   API audit → CloudTrail

Related labs

• Select storage from access patterns (lab-storage-selection)
• Assemble a serverless order flow (lab-serverless-orders)
• Build a two-AZ VPC skeleton (lab-two-az-vpc)

Sources

• AWS Certified Cloud Practitioner (CLF-C02) Exam Guide — Certification
• AWS Documentation — Reference
• Application Integration on AWS — Integration

Course: CLF · Billing & Support — Tracks: CLF — Level: CLF-C02 — ~34 min

Understand the tools and organizational mechanisms used to estimate, allocate, monitor, optimize, and obtain help for AWS usage.

Objectives

• Differentiate pricing dimensions, calculators, bills, Cost Explorer, Budgets, and anomaly detection.
• Explain consolidated billing and cost allocation in AWS Organizations.
• Select an AWS support or technical resource for a described need.

Mental model

AWS service cost is usually a combination of dimensions such as runtime, requests, capacity, storage, data processing, and data transfer. The AWS Pricing Calculator estimates a proposed design. The bill and cost-and-usage data describe actual charges. Cost Explorer analyzes trends and forecasts, while Budgets compares actual or forecast values to thresholds.

AWS Organizations can combine account billing while preserving account-level isolation. Tags and cost categories help allocate shared spend. Savings Plans and reservations apply discounts under different commitment models; Spot uses spare capacity with interruption risk.

Design

Choose the tool from the verb. Estimate a future architecture with Pricing Calculator. Explore historical spend with Cost Explorer. Notify on a threshold with Budgets. Detect unusual spend with Cost Anomaly Detection. Allocate cost with tags, accounts, and cost categories.

Decision rules

Operations

Assign financial owners, require cost-allocation metadata, alert early, review anomalies, and link spend to workload metrics. Support-plan features and exam policies can change, so verify current details on official AWS pages when making a purchasing or exam-day decision.

Failure modes

• Using a budget alert as an automatic guarantee that resources stop consuming money.
• Ignoring data transfer and managed-service request dimensions in estimates.
• Placing all teams in one account solely to simplify the bill.

Key points

• Cost Explorer is for analysis and forecasting; Budgets is for threshold-based tracking and notifications.
• Cost and Usage Reports provide detailed billing data for advanced analysis.
• AWS Trusted Advisor provides checks across cost, performance, security, fault tolerance, service limits, and operational excellence, with availability depending on support context.
• Documentation, re:Post, Knowledge Center, Support Center, account teams, and specialized services solve different help needs.

Example — A practical FinOps loop

Estimate → tag/account structure → deploy → measure → allocate → alert → optimize

Estimate: AWS Pricing Calculator
Analyze: Cost Explorer
Detailed export: Cost and Usage Report
Threshold: AWS Budgets
Unusual behavior: Cost Anomaly Detection
Recommendations: Cost Optimization Hub / Trusted Advisor / service tools
Commitment: Savings Plans or reservations after baseline measurement

Related labs

• Choose the cost and support tool (lab-cost-support)
• Optimize without breaking requirements (lab-cost-optimize)

Sources

• AWS Pricing — Cost
• AWS Cost Management — Cost
• AWS Organizations User Guide — Governance
• AWS Certified Cloud Practitioner (CLF-C02) Exam Guide — Certification

Course: CLF · Exam Reasoning — Tracks: CLF — Level: CLF-C02 — ~26 min

Turn a long service scenario into a small set of explicit requirements, eliminate category errors, and select the least complex qualifying answer.

Objectives

• Extract constraint, outcome, and service category from a certification question.
• Use elimination based on responsibility model, interface, and stated priorities.
• Review missed questions by misconception rather than memorizing option text.

Mental model

Most foundational questions test category recognition and responsibility boundaries, not obscure configuration. Mark the decisive nouns and verbs: managed SQL database, durable queue, object storage, audit API calls, estimate cost, distribute content globally, or protect web requests.

Qualifiers determine the answer: minimum administration, lowest cost, highest availability, short-lived credentials, global users, unpredictable traffic, or detailed billing. An option that solves an unasked problem can be technically impressive and still wrong.

Design

Use a four-pass method: restate the desired outcome, list hard constraints, classify the service category, and compare only answers in that category. On review, record the missing concept—such as queue versus topic or audit versus monitoring—not the letter of the answer.

Decision rules

Operations

Practice in timed sets, but spend more review time than answer time. Group errors by domain, repeat the related lab, then explain aloud why each distractor fails. The mock exam in this academy uses original questions and should supplement—not replace—official AWS practice resources.

Failure modes

• Choosing a familiar service before reading the final optimization phrase.
• Assuming more services always means a more resilient answer.
• Memorizing practice-question wording instead of understanding the underlying interface and responsibility boundary.

Key points

• Identify the resource type first, then the AWS service, then any feature or pricing model.
• Eliminate options from the wrong category before comparing close alternatives.
• Prefer managed or serverless choices when the scenario explicitly minimizes operations and no hard requirement needs lower-level control.
• For multi-select questions, verify every selected option independently satisfies part of the requirement.

Example — Question reduction

Scenario words:
"global users", "static images", "reduce latency", "minimum changes to origin"

Outcome: faster global delivery
Data type: cacheable objects
Constraint: keep existing origin
Category: content delivery network
Best-fit pattern: CloudFront in front of the origin

Reject:
- larger database: wrong layer
- Direct Connect: private hybrid link, not global edge delivery
- more IAM users: unrelated

Related labs

• Select storage from access patterns (lab-storage-selection)
• Choose the cost and support tool (lab-cost-support)
• Choose a disaster-recovery strategy (lab-dr-strategy)

Sources

• AWS Certified Cloud Practitioner (CLF-C02) Exam Guide — Certification
• AWS Skill Builder — Training

Course: SAA · Secure Architectures — Tracks: SAA — Level: SAA-C03 — ~37 min

Design workforce and workload access across accounts with federation, roles, organizations, permission guardrails, and centralized evidence.

Objectives

• Design human access with federation and temporary credentials.
• Design cross-account workload access with roles and resource policies.
• Use Organizations, OUs, SCPs, account boundaries, and centralized logging appropriately.

Mental model

An AWS account is an administrative, billing, quota, and resource boundary. A multi-account environment separates workloads by environment, business purpose, and risk while shared identity, logging, networking, and security accounts provide common capabilities.

IAM Identity Center commonly brokers workforce access into roles in each account. Workloads assume roles or use resource policies for cross-account access. Service control policies define the maximum available permissions for member accounts; they do not grant permissions by themselves.

Design

Separate duties and blast radius first, then make access paths explicit. A production operator should enter through a federated permission set, assume only the role required, and leave an audit trail. Cross-account data access should identify both the trusted principal and the permitted resource/action scope.

Decision rules

Operations

Continuously review external trust, unused roles, privileged permission sets, SCP effects, and break-glass access. Test both positive and negative access paths in a nonproduction OU before broad policy rollout.

Failure modes

• Expecting an SCP Allow to grant access without an identity or resource policy.
• Sharing one administrative IAM user across accounts.
• Centralizing logs in an account that workload administrators can modify or delete.

Key points

• Use roles and temporary sessions for humans, services, and automation; avoid static keys.
• Centralize CloudTrail and security findings in protected accounts with delegated administration where supported.
• Apply SCPs as broad guardrails, then use identity and resource policies for workload-specific access.
• Use external IDs for relevant third-party role-assumption scenarios and conditions for context-aware access.

Example — Cross-account role trust

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": {"AWS": "arn:aws:iam::111122223333:role/analytics-reader"},
    "Action": "sts:AssumeRole",
    "Condition": {"StringEquals": {"sts:ExternalId": "approved-workflow"}}
  }]
}

Related labs

• Repair an IAM policy (lab-iam-policy)
• Instrument and diagnose a backlog (lab-observability)

Sources

• IAM User Guide — Security
• Policy Evaluation Logic — Security
• AWS Organizations User Guide — Governance

Course: SAA · Secure Architectures — Tracks: SAA — Level: SAA-C03 — ~39 min

Layer network segmentation, private service access, inspection, hybrid connectivity, DNS, web protection, and origin controls without confusing path and authorization.

Objectives

• Place public, private application, and isolated data resources into appropriate network tiers.
• Select endpoints, NAT, peering, Transit Gateway, PrivateLink, VPN, and Direct Connect.
• Protect public entry points with CloudFront, WAF, Shield, TLS, and restricted origins.

Mental model

A secure network design minimizes direct reachability, but private addressing alone is not security. Routing, security groups, NACLs, endpoint policies, load balancer listeners, identity policies, TLS, and application authentication each control a different part of the path.

Hybrid architecture has two planes: connectivity and name resolution. Site-to-Site VPN creates encrypted tunnels over the internet, Direct Connect provides dedicated private connectivity, Transit Gateway provides hub routing, and Route 53 Resolver endpoints support hybrid DNS patterns.

Design

Trace every required flow and every prohibited flow. For each, document source identity/address, DNS name, next hops, encryption, authorization, inspection, target, and return path. Choose centralized inspection only when its routing complexity and failure impact are justified.

Decision rules

Operations

Monitor tunnel state, route changes, resolver queries, flow logs, load balancer logs, WAF logs, certificate renewal, and endpoint usage. Test alternate paths and avoid asymmetric routing through stateful appliances.

Failure modes

• Putting database subnets on a route to an internet gateway because security groups are restrictive.
• Assuming Direct Connect is encrypted by default for all traffic.
• Leaving an S3 or load balancer origin directly reachable when CloudFront is intended as the only entry.

Key points

• Expose load balancers or APIs rather than individual application instances whenever possible.
• Use interface or gateway endpoints for private access to supported AWS services and scope endpoint policies where appropriate.
• Restrict an S3 or custom origin so users cannot bypass CloudFront security and caching controls.
• Design redundant VPN or Direct Connect paths and propagate only intended routes.

Example — Three-tier traffic intent

Internet → CloudFront + WAF → public ALB
ALB security group → application security group on private subnets
Application security group → database security group on isolated subnets
Private workloads → S3 gateway endpoint
Private outbound updates → zonal NAT gateways
On premises → redundant VPN / Direct Connect → Transit Gateway
Hybrid DNS → Route 53 Resolver inbound/outbound endpoints

Related labs

• Build a two-AZ VPC skeleton (lab-two-az-vpc)
• Repair a fragile web architecture (lab-resilient-web)

Sources

• Amazon VPC User Guide — Networking
• Amazon CloudFront Developer Guide — Networking
• Amazon Route 53 Developer Guide — Networking

Course: SAA · Secure Architectures — Tracks: SAA — Level: SAA-C03 — ~38 min

Protect data across its lifecycle with classification, access control, encryption, key policy, secret handling, immutability, replication, and tested recovery.

Objectives

• Differentiate service-managed, AWS-managed, and customer-managed encryption key choices.
• Design secure object, block, file, and database access with least privilege and private paths.
• Combine backup, versioning, replication, retention, and immutability for the stated threat.

Mental model

Encryption at rest protects stored media and service-managed copies; encryption in transit protects network traffic. Authorization still determines who can request decrypted data. KMS key policies, IAM policies, grants, encryption context, and service integration shape key access.

Recovery controls are threat-specific. Backups address loss and corruption, versioning preserves object history, replication creates another copy, and immutability controls such as Object Lock can resist deletion for a retention period. None is a universal substitute for the others.

Design

Begin with data classification and threat model. Define who may access plaintext, where data may travel, who controls keys, what deletion or corruption must be recoverable, and the required RPO/RTO. Then choose service controls and independent administrative boundaries.

Decision rules

Operations

Audit key usage, failed decrypts, public-access changes, backup jobs, vault policy, replication status, and restore tests. Plan for key deletion carefully because deleting a key can make encrypted data unrecoverable.

Failure modes

• Encrypting data while granting broad decrypt and data-read permissions to the same principals.
• Replicating corrupted data and assuming the replica is a clean backup.
• Taking snapshots without verifying application-consistent restoration within the RTO.

Key points

• Use customer-managed KMS keys when independent key policy, rotation, grants, or audit control is required.
• Use Secrets Manager for managed secret storage and supported rotation patterns; never place plaintext secrets in AMIs, code, user data, or templates.
• Block public access on S3 and grant narrow identity/resource policy access, preferably through private network paths where required.
• AWS Backup can centralize policy and vault controls across supported services; test restore time and application consistency.

Example — Bucket policy condition requiring TLS

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "DenyInsecureTransport",
    "Effect": "Deny",
    "Principal": "*",
    "Action": "s3:*",
    "Resource": [
      "arn:aws:s3:::research-results",
      "arn:aws:s3:::research-results/*"
    ],
    "Condition": {"Bool": {"aws:SecureTransport": "false"}}
  }]
}

Related labs

• Harden a result bucket (lab-secure-s3)
• Repair an IAM policy (lab-iam-policy)
• Secure a CloudFormation template (lab-cloudformation)

Sources

• IAM User Guide — Security
• Amazon S3 User Guide — Storage
• Amazon EBS User Guide — Storage

Course: SAA · Resilient Architectures — Tracks: SAA — Level: SAA-C03 — ~40 min

Use queues, topics, events, workflows, load balancing, stateless compute, health checks, and idempotency to contain failure and absorb demand.

Objectives

• Design synchronous and asynchronous boundaries from latency and consistency requirements.
• Use ELB, Auto Scaling, SQS, SNS, EventBridge, and Step Functions in distinct roles.
• Build safe retry, dead-letter, idempotency, and back-pressure behavior.

Mental model

Loose coupling reduces assumptions between components. Load balancers decouple clients from instance addresses; queues decouple producer rate from consumer rate; topics decouple a publisher from multiple subscribers; event buses decouple event sources from routing rules; workflows externalize coordination state.

Scalability requires a signal and a safe scaling unit. Web tiers scale from request or utilization metrics, workers often scale from queue depth or age, and databases require independent read/write capacity decisions. Stateless processes are replaceable because durable state lives elsewhere.

Design

Keep user-facing synchronous paths short. Move optional or long work behind durable acceptance. Choose the integration primitive by consumer relationship: competing workers, multiple subscribers, content-based routing, or explicit workflow state.

Decision rules

Operations

Monitor queue age, DLQ growth, consumer error, execution duration, load balancer target health, Auto Scaling activity, and throttling. Test partial failure, duplicate events, slow consumers, and unavailable dependencies.

Failure modes

• Using queue length alone when message age reveals user impact better.
• Retrying immediately across many clients and amplifying an outage.
• Keeping user sessions on individual instances behind an Auto Scaling group.

Key points

• Use SQS visibility timeout long enough for normal processing and extend it for variable work; use DLQs for repeated failure analysis.
• Standard queues prioritize throughput and at-least-once delivery; FIFO queues add ordering and deduplication constraints where needed.
• SNS pushes fan-out notifications, EventBridge routes events by pattern, and Step Functions coordinates multi-step stateful flows.
• Make consumers idempotent because retries, timeouts, and duplicate delivery can repeat work.

Example — Serverless order architecture

API Gateway → Lambda (validate + persist order) → DynamoDB
                                       └→ EventBridge: OrderAccepted
                                           ├→ SQS payment queue → worker
                                           ├→ SNS notification topic
                                           └→ Step Functions fulfillment

Controls: idempotency key, bounded retries, DLQ, queue-age alarm, trace ID.

Related labs

• Assemble a serverless order flow (lab-serverless-orders)
• Instrument and diagnose a backlog (lab-observability)

Sources

• Application Integration on AWS — Integration
• AWS Lambda Developer Guide — Compute
• Amazon DynamoDB Developer Guide — Databases

Course: SAA · Resilient Architectures — Tracks: SAA — Level: SAA-C03 — ~42 min

Separate component availability from workload recovery and select a strategy from explicit RTO, RPO, failure scope, consistency, and cost requirements.

Objectives

• Differentiate Multi-AZ, backup/restore, pilot light, warm standby, and multi-site patterns.
• Translate RTO and RPO into replication, automation, and capacity decisions.
• Design health checks, failover, data recovery, and regular recovery testing.

Mental model

High availability keeps a workload operating through expected component or zone failures. Disaster recovery restores service after a larger or more destructive event. RPO is the maximum acceptable data loss measured in time; RTO is the maximum acceptable time to restore service.

Backup and restore has the lowest steady-state footprint and usually the longest recovery. Pilot light keeps critical data and core services ready. Warm standby runs a scaled-down full environment. Multi-site active/active serves traffic from more than one site and requires the most complex data and routing design.

Design

Define the failure scope and business objectives first. Select the least expensive strategy that demonstrably meets RTO and RPO. Consider data consistency, write ownership, dependency availability, failback, and how operators decide that primary service is truly unavailable.

Decision rules

Operations

Schedule game days, restore real backups into isolated environments, measure DNS and application readiness, validate data integrity, and practice failback. Keep runbooks and automation under version control.

Failure modes

• Calling read replicas backups when logical corruption can replicate.
• Failing DNS to a Region whose database, secrets, or quotas are not ready.
• Choosing active/active without a conflict and consistency model for writes.

Key points

• RDS Multi-AZ protects database availability in-Region; cross-Region replicas or backups serve broader recovery requirements.
• Route 53 health checks and routing policies can direct traffic, but application health and data readiness determine whether failover is safe.
• Automate infrastructure recreation and keep quotas, images, secrets, certificates, DNS, and dependencies ready in the recovery Region.
• A recovery strategy is valid only after timed end-to-end tests.

Example — Recovery strategy matrix

Backup & restore  | low steady cost | RTO hours      | RPO backup interval
Pilot light       | low-medium cost | RTO tens of min | RPO replication lag
Warm standby      | medium cost     | RTO minutes     | RPO replication lag
Multi-site        | high cost       | RTO near zero   | RPO near zero*

*Depends on the data architecture and consistency model.

Related labs

• Choose a disaster-recovery strategy (lab-dr-strategy)
• Repair a fragile web architecture (lab-resilient-web)

Sources

• Disaster Recovery of Workloads on AWS — Reliability
• AWS Well-Architected Framework — Architecture
• Amazon RDS User Guide — Databases

Course: SAA · High-Performing Architectures — Tracks: SAA — Level: SAA-C03 — ~39 min

Match S3, EBS, EFS, FSx, instance store, caching, transfer, and lifecycle features to access patterns and measurable performance dimensions.

Objectives

• Choose storage by semantics, throughput, IOPS, latency, sharing, and durability.
• Optimize S3 access, transfer, replication, and lifecycle patterns.
• Select EBS types and EFS/FSx modes from measured demand.

Mental model

Storage performance is a product of the service, selected configuration, client concurrency, request size, network path, and data layout. IOPS measures operations, throughput measures bytes per second, and latency measures completion time. Workloads can be limited by any one of them.

S3 scales object requests and supports multipart upload, byte-range reads, transfer acceleration, replication, lifecycle classes, and intelligent tiering. EBS volume types target different IOPS/throughput patterns. EFS and FSx provide file semantics with distinct protocol and performance profiles.

Design

Write the access pattern: object size, request rate, read/write ratio, concurrency, file sharing, metadata intensity, durability, and recovery. Then choose a service and test with realistic clients. For cost, place each data class in the lowest-cost tier that still meets retrieval and resilience requirements.

Decision rules

Operations

Measure request latency, throttling, EBS queue length, throughput percentage, EFS burst/throughput behavior, cache hit rate, transfer errors, and lifecycle outcomes. Benchmark the application rather than only a synthetic tool.

Failure modes

• Provisioning more IOPS while the instance’s EBS bandwidth remains the bottleneck.
• Archiving frequently accessed objects and paying retrieval and minimum-duration costs.
• Using instance store as the sole location for irreplaceable state.

Key points

• Use S3 Transfer Acceleration for suitable long-distance uploads over the public internet; use DataSync for managed online transfers and Snow Family when network transfer is impractical.
• gp3 decouples provisioned IOPS and throughput from capacity within service limits; io2 targets high-performance, durable provisioned IOPS patterns.
• Instance store offers high local performance but is ephemeral and must not be the only copy of durable data.
• Lifecycle transitions must account for minimum storage duration, retrieval latency, and request charges.

Example — Storage decision shorthand

Durable objects / data lake       → S3
Boot or transactional block        → EBS
Ephemeral local scratch             → instance store
Shared Linux NFS                    → EFS
Windows SMB                         → FSx for Windows
High-throughput HPC POSIX           → FSx for Lustre
Long-term archive                   → S3 Glacier classes
Repeated hot reads                  → CloudFront / ElastiCache / application cache

Related labs

• Select storage from access patterns (lab-storage-selection)
• Harden a result bucket (lab-secure-s3)

Sources

• Amazon S3 User Guide — Storage
• Amazon EBS User Guide — Storage
• Amazon EFS User Guide — Storage

Course: SAA · High-Performing Architectures — Tracks: SAA — Level: SAA-C03 — ~39 min

Choose execution and scaling models from runtime, portability, hardware, latency, operations, interruption, and capacity constraints.

Objectives

• Select EC2 families and purchasing models for a workload profile.
• Choose ECS, EKS, Fargate, Lambda, Elastic Beanstalk, and Batch appropriately.
• Design Auto Scaling signals, health checks, warm-up, and interruption tolerance.

Mental model

The compute spectrum trades control for managed operation. EC2 exposes machine choices and placement. ECS and EKS orchestrate containers; Fargate supplies serverless container capacity. Lambda supplies event-driven function execution. Elastic Beanstalk provides an application platform over AWS resources. Batch schedules queued jobs onto compute environments.

Scaling must follow the constrained resource. CPU can be useful for homogeneous services, but request count, latency, queue age, concurrency, memory, network, or custom business metrics may better represent demand. Predictive scaling complements—not replaces—dynamic feedback.

Design

Use the simplest runtime that meets hard constraints. Avoid choosing Kubernetes solely for containers. Match instance architecture and accelerator to software support, and align scaling with downstream capacity so a compute fleet does not overwhelm a database or external API.

Decision rules

Operations

Monitor pending tasks, placement failure, instance launch errors, warm-up, Lambda throttles, duration, downstream saturation, and Spot interruption signals. Ensure termination lifecycle hooks and graceful shutdown preserve in-flight work.

Failure modes

• Scaling web servers on CPU while requests are blocked on a saturated database.
• Using Lambda for a workload that exceeds its execution model without decomposition.
• Using one instance type in a constrained zone and creating avoidable capacity risk.

Key points

• Mixed-instance Auto Scaling groups improve capacity flexibility; capacity-optimized Spot allocation can reduce interruption risk.
• Target tracking maintains a metric near a target; step scaling changes capacity in defined increments; scheduled scaling handles known demand.
• Lambda concurrency, cold starts, package size, timeout, VPC networking, retries, and downstream limits are architecture concerns.
• Container choice depends on Kubernetes requirement, AWS-native simplicity, server management preference, and workload portability.

Example — Scaling signal selection

HTTP service      → ALB request count per target + p95 latency
Queue workers     → oldest message age / messages per worker
Lambda consumer   → concurrency + duration + throttles
Batch fleet       → runnable jobs + queue wait
Memory service    → custom memory saturation metric
GPU inference     → accelerator utilization + request queue

Always verify the downstream dependency can absorb the scale-out.

Related labs

• Repair a fragile web architecture (lab-resilient-web)
• Assemble a serverless order flow (lab-serverless-orders)
• Optimize without breaking requirements (lab-cost-optimize)

Sources

• Amazon EC2 User Guide — Compute
• Containers on AWS — Compute
• AWS Lambda Developer Guide — Compute

Files: examples/python/ — Dependency-free scaling calculations.

Two dependency-free Python 3 scripts: an Amdahl-law speedup and parallel-efficiency calculator, and a strong-scaling summary over worker:seconds measurements. Run them locally to build intuition before sizing real clusters.

python/amdahl.py

#!/usr/bin/env python3
"""Calculate Amdahl-law speedup and parallel efficiency without dependencies."""

from __future__ import annotations

import argparse


def speedup(serial_fraction: float, workers: int) -> float:
    if not 0 <= serial_fraction <= 1:
        raise ValueError("serial_fraction must be between 0 and 1")
    if workers < 1:
        raise ValueError("workers must be at least 1")
    return 1.0 / (serial_fraction + (1.0 - serial_fraction) / workers)


def main() -> None:
    parser = argparse.ArgumentParser()
    parser.add_argument("--serial", type=float, default=0.05, help="serial fraction, 0 through 1")
    parser.add_argument("--workers", type=int, nargs="+", default=[1, 2, 4, 8, 16, 32, 64])
    args = parser.parse_args()

    print("workers,speedup,efficiency_percent")
    for workers in args.workers:
        value = speedup(args.serial, workers)
        efficiency = 100.0 * value / workers
        print(f"{workers},{value:.4f},{efficiency:.2f}")


if __name__ == "__main__":
    main()

python/strong_scaling.py

#!/usr/bin/env python3
"""Summarize strong-scaling measurements from worker:seconds pairs."""

from __future__ import annotations

import argparse


def parse_measurement(value: str) -> tuple[int, float]:
    try:
        workers_text, seconds_text = value.split(":", 1)
        workers = int(workers_text)
        seconds = float(seconds_text)
    except (ValueError, TypeError) as exc:
        raise argparse.ArgumentTypeError("expected WORKERS:SECONDS") from exc
    if workers < 1 or seconds <= 0:
        raise argparse.ArgumentTypeError("workers and seconds must be positive")
    return workers, seconds


def main() -> None:
    parser = argparse.ArgumentParser()
    parser.add_argument(
        "measurements",
        nargs="+",
        type=parse_measurement,
        help="pairs such as 1:812 2:421 4:224 8:131",
    )
    args = parser.parse_args()
    rows = sorted(args.measurements)
    baseline_workers, baseline_seconds = rows[0]

    print("workers,seconds,speedup,parallel_efficiency_percent")
    for workers, seconds in rows:
        ideal_relative_workers = workers / baseline_workers
        measured_speedup = baseline_seconds / seconds
        efficiency = 100.0 * measured_speedup / ideal_relative_workers
        print(f"{workers},{seconds:.3f},{measured_speedup:.4f},{efficiency:.2f}")


if __name__ == "__main__":
    main()

Exam: AWS Certified Cloud Practitioner (CLF-C02) — Level: Foundational — Official AWS certification

Build cloud literacy, understand AWS value and responsibility boundaries, recognize core services, and reason about billing, pricing, and support.

Domain weights

Weighted mock exams

Original scenario questions aligned to the official CLF-C02 domain weights. This is practice material, not an exam dump.

Exam: AWS Certified Solutions Architect – Associate (SAA-C03) — Level: Associate — Official AWS certification

Design secure, resilient, high-performing, and cost-optimized AWS architectures by choosing appropriate service patterns and trade-offs.

Domain weights

Weighted mock exams

Original architecture scenarios balanced across the official SAA-C03 domains. Explanations focus on why alternatives fail.

Exam: Cloud & HPC Architect (ACADEMY-HPC) — Level: Specialization — Academy specialization track (not an AWS certification)

Learn vendor-neutral parallel-computing concepts and map them to AWS compute, Slurm orchestration, EFA networking, and parallel storage.

Domain weights

Weighted mock exams

A custom competency assessment informed by the AWS HPC Lens and official Slurm/Open MPI documentation. It is not an AWS certification exam.