Why a profile comes before a service
In Level 1 you saw every AWS compute service on one page. Now you need a way to choose between them that doesn't depend on whoever argues loudest in the meeting. That is the workload profile: one short document that describes what the workload needs, written in numbers instead of adjectives. Every service lesson after this one checks the service against the same profile.
Think of it as a patient's chart before surgery. The surgeon doesn't start by picking the scalpel. They read blood type, allergies and history first. Some lines on the chart ("allergic to penicillin") rule options out at once. Others only shift the preference.
The rule that matters most: "fast", "big" and "spiky" are not profile entries. "p95 under 200 ms", "14 GiB peak RSS" and "0 to 400 requests per second in 90 seconds" are.
The ten dimensions
Here is the template. Copy it into your repo next to the code it describes.
# workload-profile.yaml: one file per workload, versioned with the code
workload: nightly-risk-sim
owner: quant-platform-team
1_compute:
cpu_vcpu_per_unit: 2 # measured, not guessed
gpu_or_accelerator: none # none | gpu (which model/VRAM) | trainium | inferentia
memory_peak_gib_per_unit: 1.8 # peak RSS, plus headroom later
cpu_arch: any # any | x86_only (e.g. a closed-source x86 binary)
2_parallelism: embarrassingly_parallel # or tightly_coupled (units talk mid-run, e.g. MPI)
3_duration_and_state:
unit_runtime_p50_min: 3
unit_runtime_max_min: 11
state: stateless_with_checkpoint # stateless | checkpointable | long-lived stateful
4_latency: batch_deadline_06:00_UTC # or p95 ms for request/response work
5_scaling:
units_per_run: 40000
shape: scheduled_burst # steady | diurnal | spiky | scheduled_burst
6_os_and_licensing: linux, open-source only
7_data_location: s3 eu-west-2, 300 GB input/night
8_compliance: UK GDPR; data stays in UK region
9_team_skills: strong Python, Docker; no Kubernetes on-call
10_cost_model: opex, minimise $/run; interruptions acceptable
The next section shows how each line works as a filter.
How each dimension rules services in or out
| Dimension | Example gate (checked against the docs) |
|---|---|
| Accelerator | Needs a GPU? AWS points GPU tasks to EC2 and doesn't support them on Fargate. |
| Memory | A Fargate task tops out at 16 vCPU and 120 GiB. A 200 GiB in-memory job needs EC2-backed capacity. |
| Duration | One Lambda invocation can run for at most 15 minutes, and that limit is fixed. Lambda durable functions can span up to a year by checkpointing across invocations, but each step still has to finish within 15 minutes. |
| State | Spot capacity gives a two-minute interruption notice. Work that can checkpoint within that window can use it. A 30-hour run that can't checkpoint can't. |
| Parallelism | Embarrassingly parallel work fans out: an AWS Batch array job takes 2 to 10,000 children per submission. Tightly coupled MPI work needs low-latency networking such as EFA on specific EC2 instance types. |
| OS and licensing | Windows, or software licensed per socket or per core, can push you toward EC2 or Dedicated Hosts. |
| Data location and compliance | Residency rules decide the Region, and sometimes Outposts or Local Zones, before any service is picked. |
| Team skills | No one to run Kubernetes on-call is a real constraint. Treat it like a hard limit, not a preference. |
Gotcha: tight coupling is about whether units talk to each other mid-run, not how many there are. 10,000 independent Monte Carlo paths are embarrassingly parallel. A 64-node fluid-dynamics solver that swaps boundary data every timestep is tightly coupled, even though it's "one job".
Walkthrough: replacing adjectives with numbers
The quant team says the risk job is "memory heavy and slow". You measure one unit instead:
# Run one scenario under GNU time to get wall-clock time and peak memory
/usr/bin/time -v python run_scenario.py --id 17 2> unit17.time
grep -E "Elapsed|Maximum resident" unit17.time
# Elapsed (wall clock) time (h:mm:ss or m:ss): 3:07.44
# Maximum resident set size (kbytes): 1887436 # about 1.8 GiB, not "heavy"
If it already runs on EC2, pull real utilisation instead of trusting memory:
# Peak CPU over the last nightly window, 5-minute buckets
aws cloudwatch get-metric-statistics \
--namespace AWS/EC2 --metric-name CPUUtilization \
--dimensions Name=InstanceId,Value=i-0abc123def4567890 \
--start-time 2026-10-23T01:00:00Z --end-time 2026-10-23T06:00:00Z \
--period 300 --statistics Maximum --output table
# Memory is NOT in AWS/EC2 by default; you need the CloudWatch agent for that.
Run the measurement on at least 20 to 30 units, including the slowest inputs. The longest unit took 11 minutes, and that's the number that matters for the duration gate. It's close enough to Lambda's 15-minute ceiling that a slightly bigger input next quarter breaks it. Write that risk into the profile.
Best practice: record p50 and max for duration and memory. Services fail on the worst case, not the average.
Flagging the deciding dimensions
Most dimensions turn out not to matter for a given workload. For each line, ask: does this remove whole services, or only change the ranking?
For the risk simulation:
- Parallelism = embarrassingly parallel, 40,000 units. This points to fan-out batch tools.
- State = checkpointable + interruptions acceptable. This makes Spot capacity viable, which is the biggest cost lever.
- Duration max 11 min, close to 15. This makes Lambda risky, not ideal.
Accelerator (none), OS (Linux) and compliance (any UK Region) don't separate the candidates here, so you note them and move on.
Compare a second workload: a 64-node MPI crash simulation that runs for 30 hours and uses a licensed solver. Its deciding dimensions are tight coupling, long stateful runs and per-core licensing, and they point somewhere quite different. Same template, different gates.
Trade-off: team skills often decide between two services that both pass the technical gates. Don't hide it as a footnote. A technically better platform that nobody can operate at 3 a.m. is the worse choice.
Key takeaways
- The profile has ten dimensions: compute/accelerator/memory, parallelism, duration and state, latency, scaling, OS and licensing, data location, compliance, team skills and cost model.
- Write numbers (p50 and max), not adjectives. Measure with tools like
/usr/bin/time -vand CloudWatch. - Some lines are hard gates: GPU, more than 120 GiB per task, more than 15 minutes per Lambda invocation, tight coupling, and no tolerance for a two-minute interruption.
- Tightly coupled means units talk during the run, not that there are many of them.
- Finish by marking the two or three dimensions that remove services. Those decide the choice, and the rest refine it.