Why write a profile before picking a service?
If you've worked on a few AWS accounts, you'll have seen it go wrong. Someone turns on a service because a blog post liked it, and six months later the auditor asks something it can't answer. For example: "Who can decrypt customer records, and where are the keys held?" The service was fine. Nobody had written down what the workload actually needed.
A security profile fixes that. It is one short document that sets out a workload's security needs in the same ten parts every time. Think of it as a building survey done before you hire builders. Every service lesson in this course answers some of its parts, and the selection scorecard at the end of the course is built straight from it. Write it once, keep it in the repo, and keep it up to date.
The ten parts
| # | Part | The question it answers |
|---|---|---|
| 1 | Identities | Who and what signs in: workforce (staff, contractors), customer (end users of your app), workload (Lambda functions, containers, CI pipelines)? |
| 2 | Privilege and access model | How is access granted, reviewed and removed? Roles, attributes, just-in-time? |
| 3 | Data classification | What data exists and how sensitive is it (public, internal, confidential, regulated)? |
| 4 | Encryption and key control | Who creates, holds and can revoke the keys? |
| 5 | Compliance and residency | Which frameworks apply, and where may data and operators sit? |
| 6 | Detection and response | What threats must be spotted, how fast, and who responds? |
| 7 | Logging and audit | What must be recorded, kept for how long, and kept safe from tampering? |
| 8 | Zero trust posture | Does network location count as trust, or is every request checked against identity and device? |
| 9 | Team skills | What can your team actually run at 3 a.m.? |
| 10 | Cost model | What drives the bill: per user, per key, per API call, per GB ingested? What is the budget? |
Part 1 trips people up most. Customer identity is a different problem from workforce identity, with different scale, user experience and pricing. Workload identity is the one teams forget, even though in most accounts machines outnumber people.
Worked example: profiling a customer portal
Take a sample workload: Ledgerly, an invoicing portal for small European businesses. It has about 40 staff, 60,000 customer accounts and a containerised backend. Here is its profile as YAML, kept next to the code:
# security-profile.yaml: one file per workload, reviewed each quarter
workload: ledgerly-portal
owner: platform-team
reviewed: 2026-10-29
parts:
identities:
workforce: "40 staff sign in through the corporate IdP with MFA; no long-lived access keys"
customer: "60k accounts, about 25k monthly active; email and password plus social sign-in"
workload: "ECS tasks and CI pipeline use short-lived role credentials only"
must: true
privilege_access:
requirement: "Role-based; production access is time-boxed and reviewed every 90 days"
must: true
data_classification:
requirement: "Invoices and bank details = confidential; marketing pages = public"
must: true
key_control:
requirement: "Customer managed keys we can disable; keys held outside AWS = NOT required"
must: true
compliance_residency:
requirement: "GDPR; customer data stored only in EU Regions"
must: true # a legal gate, not a preference
detection_response:
requirement: "Alert on credential misuse within 15 min; on-call responds within 1 h"
must: false
weight: 4 # 1-5: matters a lot in scoring, but is not a gate
logging_audit:
requirement: "All API activity kept 1 year, tamper-evident, in a separate account"
must: true
zero_trust:
requirement: "Staff reach admin tools without a VPN, checked per request"
must: false
weight: 2
team_skills:
requirement: "Strong on Terraform and AWS; no HSM or PKI specialists"
must: false
weight: 3
cost_model:
requirement: "Security tooling at most 8% of the AWS bill"
must: false
weight: 3
Notice two habits here.
Every requirement can be tested. "Strong encryption" can't be tested. "Customer managed keys we can disable" can. If a reviewer can't answer yes or no for a given service, rewrite the requirement.
Must-haves and nice-to-haves are kept apart. A must-have is a gate: a service that fails it is out, however well it scores elsewhere. EU-only residency is a legal duty for Ledgerly, so it is a gate. A nice-to-have only adds weight in scoring. VPN-less admin access would be good, but missing it doesn't rule a service out.
Gotcha: Teams tend to mark everything as a must-have. If eight of ten parts are gates, either nothing passes or you start quietly ignoring gates. A good test: "Would we fail an audit, break a contract or break the law without this?" If the answer is no, it's a weight.
Putting numbers on the cost model
The cost model is far more useful once you write down the unit each service charges by. The list prices below were checked in October 2026 for us-east-1. They are dated examples, not quotes:
Key control: customer managed KMS key = $1.00/key/month
+ $0.03 per 10,000 symmetric requests (20,000 free/month)
Customer IdP: Cognito Essentials = 10,000 MAU free, then $0.015/MAU
Ledgerly: (25,000 - 10,000) x $0.015 = about $225/month
The unit tells you what makes the bill grow. Customer sign-ins grow with monthly active users (MAU), key costs grow with the number of keys and API calls, and detection costs grow with events and gigabytes ingested. Write the unit into part 10 and the scorecard later takes care of itself.
Key control and residency: the gates people underestimate
Two must-haves change the shortlist more than any other.
- "Keys held outside AWS." Some regulated workloads must show that keys stay entirely under their own control, outside the cloud. AWS KMS supports this with an external key store, which links KMS to a key manager you run. The trade-off is that latency, durability and availability now depend on your own hardware. Ledgerly states plainly that it does not need this, which keeps its options open.
- "Data and operations stay in the EU." Choosing EU Regions covers where the data is stored. Some buyers also want operations kept in the EU. The AWS European Sovereign Cloud, generally available since January 2026 with its first Region in Brandenburg, Germany, is built for that stricter case. Write down which version you need. "EU storage" and "EU-operated" lead to different shortlists.
Mapping the profile to what comes next
The profile also works as a reading map for the rest of the course:
Identities, privilege -> IAM, IAM Identity Center, Organizations, Cognito, Verified Permissions
Key control -> KMS and CloudHSM; Secrets Manager; Certificate Manager
Data classification -> Macie
Detection and response -> GuardDuty, Security Hub, Inspector, Detective
Logging and audit -> CloudTrail, AWS Config, Security Lake
Compliance, cost, skills -> every lesson's limits, pricing and "who operates what" sections
As you work through each service lesson, check it against your profile and ask which parts it answers, which gates it passes and how its pricing unit fits part 10.
Key takeaways
- A security profile has ten fixed parts: identities, privilege and access, data classification, key control, compliance and residency, detection and response, logging and audit, zero trust, team skills and cost model.
- Identities come in three kinds: workforce, customer and workload. Don't leave out workload.
- Write each requirement so a service clearly passes or fails it.
- Must-haves are gates that rule a service out. Nice-to-haves carry a weight that only affects the score.
- Record the pricing unit (per MAU, per key, per request, per GB) so costs can be compared later.
- Keep the profile in version control. Every later lesson and the final scorecard reuse it.