Lesson 2: The Standard Analytics Profile

Profile the workload before you pick a service

Most bad analytics choices begin with a service name: "let's use Redshift" or "just put Athena on it". That's like a doctor writing the prescription before asking about symptoms. The standard analytics profile is the history you take first. It's one short document with ten answers. It describes the workload and names no service. Once it's filled in, many services drop out on their own and the choice gets much simpler.

You'll reuse this profile in every service lesson that follows. Each service gets judged against the same ten answers.

The ten questions

Gotcha: for concurrency, record the peak, not the headcount. 400 licensed users might mean 40 queries at once at 09:00 on Monday and almost nothing at 15:00. Sizing for 400 wastes money, and sizing for the average leaves the Monday-morning peak queuing.

Walkthrough: profiling a sample workload

Northwind Outdoor is a retailer with 120 stores. Keep the profile as a YAML file in the repo, next to the infrastructure code, so changes go through review.

# analytics-profile.yaml: describes the need, names no service
workload: northwind-sales-and-fraud
sources:
  - {name: orders_postgres, volume_per_day: 40GB, arrival: batch_nightly}
  - {name: pos_events,      volume_per_hour: 3M events (~1.5KB each), arrival: stream}
retention: 3 years raw, 7 years aggregates
freshness:
  sales_dashboards: "by 07:00 daily"   # batch is fine
  fraud_alerts: "< 10 seconds"         # needs streaming
concurrency: {dashboards_peak: 60, adhoc_sql_peak: 5}
users: {analysts: 25, engineers: 4, scientists: 3}
open_format: {required: iceberg, reason: "partner team reads tables with Spark"}
governance: {pii_columns: [email, phone], column_masking: true, lineage: required_for_audit}
residency: {region: eu-west-2, basis: "customer contract: UK only"}
skills: {sql: strong, spark: basic, kafka: none}
cost_model: {preference: predictable_monthly, cap_gbp: 15000}
# Tag every line HARD or PREF in the next step

Hard constraints vs preferences

Use one test on each line: if a service misses this, do we walk away, or just work harder or pay more? Walking away makes it a hard constraint. Working harder makes it a preference.

• Hard: residency set by law or contract, a latency SLA such as fraud under 10 seconds, a required open format, and mandatory PII masking.
• Preference: "we know SQL better than Spark" (people can learn), and "predictable bill" (can be traded against features).

Hard constraints filter: they remove options. Preferences rank what's left. Expect pressure to mark everything HARD. If everything is hard, you have no room to trade, so push back and ask "what happens if we miss it?"

Check hard constraints against facts, not memory. To see whether a service runs in your required Region, query the public parameters AWS publishes:

# List the services AWS reports in eu-west-2 (London), then filter for the ones you care about
aws ssm get-parameters-by-path \
  --path /aws/service/global-infrastructure/regions/eu-west-2/services \
  --query "Parameters[].Value" --output text | tr '\t' '\n' | grep -E '^(athena|redshift|kinesis|firehose)

Feature support needs the same care. Take open formats: Athena reads and writes Iceberg tables. For Delta Lake tables it only reads them, they must be registered in AWS Glue, and it supports neither Delta time travel nor INSERT/UPDATE/DELETE. Redshift has supported writing to Iceberg tables since November 2025, aimed at append-only workloads. A line reading "Delta, with writes from SQL" therefore rules out some pairings before you've compared a single price.

From profile to shortlist

Next, map the answers onto the service groups from Level 1.

For Northwind this gives a shortlist across streaming (fraud under 10 s), warehouse or query engine (60 concurrent dashboards), integration (nightly Postgres), catalogue and governance (masking plus lineage) and BI. The Iceberg requirement means each candidate must read and write Iceberg, and London residency means each one must run in eu-west-2. Those hard filters get applied first, and Kafka-heavy options lose points because the team has no Kafka skills.

Best practice: date the profile and add a named owner. Freshness and volume answers go stale quickly. When someone says "we need real time now", update the profile first, then revisit the choice.

Key takeaways

• Write the profile before naming any service, and keep it as a reviewed file in the repo.
• Every answer needs a number or a named fact. "Fast" and "lots" don't count.
• Record peak concurrency, not total users.
• Hard constraints (residency, latency SLAs, required open formats, mandatory masking) filter options out. Preferences (skills, cost style) rank the ones that remain.
• Check hard constraints against current documentation, such as Regional availability and per-engine open-format support.
• Each profile signal points to one or more Level 1 service groups, and together they form the shortlist.