Why write a profile before you pick a service
In Level 1 you saw every AWS container service on one page. The trap now is picking one because you like it. A team that knows Kubernetes reaches for EKS. A team that hates servers reaches for Fargate. Then six months later they find a GPU requirement, or a compliance rule, or an on-call rota that can't keep up.
A workload profile stops that. It's a one-page record of the facts about your system, written down before you look at any service. Think of it like the spec sheet you write before buying a van: payload, range, number of seats, budget. You don't walk into the showroom and then decide what you need to carry.
Every later lesson in this course checks a service against this same profile. So it has to be honest, specific and reusable.
The eight dimensions
| # | Dimension | The question it answers |
|---|---|---|
| 1 | Number of services | How many deployable things, and how they talk to each other |
| 2 | State | Stateless, or does anything keep data on local disk or in memory? |
| 3 | Traffic and scaling | Steady, spiky, scheduled, or scale-to-zero? |
| 4 | GPUs and accelerators | Needed now, needed soon, or never? |
| 5 | Skills and operating model | What your team can actually run, at 3 a.m. too |
| 6 | Portability | Must this run on another cloud or on-premises? |
| 7 | Compliance | Which regulations and audits apply? |
| 8 | Cost model | Steady spend, pay-per-use, committed discounts, budget ceiling |
Each dimension gets an answer and a reason. "Stateless" alone isn't enough. "Stateless: sessions live in ElastiCache, uploads go to S3" can be checked.
Hard constraints vs preferences
This split matters most. A hard constraint knocks a service out completely. A preference only changes its score.
- Hard: compliance obligations, GPU needs, state that must stay on local disk, resource ceilings, and whether a service is available to you at all.
- Soft: portability you'd like, favourite tooling, "we've always used Helm".
Here are some dated examples of hard constraints doing their job, as of October 2026:
- GPUs: AWS Fargate doesn't support GPUs. If the profile says "GPU inference: yes", Fargate is out. On ECS, GPUs run on EC2 or on ECS Managed Instances.
- Availability: App Runner closed to new customers on 30 April 2026. Existing customers can keep using it, but no new features are planned. AWS points new users to Amazon ECS Express Mode. If your account isn't already an App Runner customer, that's a hard "no".
- Retirement: AWS App Mesh support ended on 30 September 2026, so no profile should depend on it.
- Size ceilings: since June 2026 a Fargate task can have up to 32 vCPU and 244 GiB of memory. A task that needs more is a hard constraint against Fargate.
- Compliance: for HIPAA, a service must be on AWS's HIPAA-eligible list and you must sign a Business Associate Agreement. Check the "Services in Scope by Compliance Program" page and record the date you checked it.
Gotcha: teams often mark portability as a hard constraint when it's really a wish. Ask: "Is there a signed contract, regulator or board decision that requires it?" If not, it's a preference. Score it later. Don't filter on it.
Worked example: the profile as a file
Keep the profile as YAML in the repo, next to the infrastructure code. It gets reviewed in pull requests like everything else. Here's a sample system: a booking platform.
# workload-profile.yaml — reviewed 2026-10-29, owner: platform team
system: booking-platform
services:
count: 7 # 5 HTTP APIs, 1 queue worker, 1 nightly batch
reason: "split by team ownership; worker reads SQS"
state:
answer: stateless
reason: "Postgres on RDS, sessions in ElastiCache, files in S3"
hard_constraint: false
traffic:
shape: daily-peak # 08:00-10:00 is 6x the overnight load
peak_rps: 1200
scale_to_zero: false # APIs must answer in < 300 ms, no cold starts
gpus:
answer: none-now
reason: "ML ranking on roadmap for 2027; re-profile then"
hard_constraint: false # becomes true the day ranking ships
skills_and_ops:
k8s_experience: "1 engineer, CKA; 3 others have used kubectl"
on_call: "4 people, 1-week rotation"
sustainable_ops_hours_per_week: 6
model: "provider runs control plane AND nodes"
portability:
answer: preference
reason: "no contract requires it; nice for future M&A"
compliance:
frameworks: [PCI-DSS] # card payments
hard_constraint: true
checked: "AWS Services in Scope page, 2026-10-29"
cost_model:
style: "steady baseline + peak burst"
budget_ceiling_usd_month: 9000
commitments: "open to 1-year Savings Plans"
The hard_constraint flags make the next step easy. Filter on the trues first, then score on everything else.
Estimating the operations work your team can keep up with
This is the dimension people are least honest about. Work it out from real numbers, not from hope:
Team: 4 engineers on the platform rota
Hours per engineer per week: 40
Share protected for platform work: ~15% (the rest is feature work)
-> 4 x 40 x 0.15 = 24 hours/week of platform time
Minus on-call interrupts (from last quarter's pager history): ~8 h
Minus security patching and dependency bumps: ~6 h
Minus incidents and reviews: ~4 h
-> about 6 hours/week left for running a platform
Six hours a week is enough to look after managed services that the provider patches and scales. It isn't enough to run self-managed nodes, upgrade a cluster add-on by add-on, and debug the networking plugin. Be honest about skills in the same way. One certified engineer is a single point of failure. When they're on holiday, nobody else can do the job.
Best practice: take the on-call numbers from your pager or incident tool's history, not from memory. People reliably underestimate interrupts.
Trade-off: a thin operating model costs more per vCPU but less per engineer hour. Write both down. The cost lessons later in the course will weigh them against each other.
Keeping the profile alive
- Date it, and give it an owner.
- Re-profile when something changes a hard constraint: a GPU feature ships, a new regulation applies, the team shrinks.
- Put a date next to every fact about a service ("as of 2026-10"), because limits and availability change.
Key takeaways
- Write the profile before looking at services. Give every dimension an answer and a reason.
- Eight dimensions: services, state, traffic and scaling, GPUs, skills and operating model, portability, compliance, cost model.
- Hard constraints (compliance, GPUs, state, size limits, availability) remove options. Preferences (portability, tooling) only change a score.
- Work out how much operations work you can keep up with from rota size, pager history and protected hours, not from hope.
- Keep the profile as a dated, owned file in version control, and re-profile when a hard constraint changes.