Service Selection as an Architecture Decision

Goal

Now that the first AWS boundaries are visible, service selection can become a design decision instead of a product-matching exercise.

The durable idea is:

Choose AWS services by workload responsibility, not by name recognition.

The Short Version

A weak service-selection conversation asks:

What is the AWS service for this?

A stronger conversation asks:

Workload need
  -> responsibility boundary
  -> options
  -> trade-offs
  -> recommendation
  -> risks and operating plan

Service names are still important. Architects need vocabulary. But vocabulary is not the design method.

Start With Workload Shape

Workload shape includes how the system behaves.

Ask:

• Is the workload user-facing, internal, batch, event-driven, streaming, analytical, or operational?

• Does it need low latency, high throughput, scheduled processing, or asynchronous work?

• Is the traffic steady, spiky, seasonal, or unpredictable?

• Does the team need operating-system control, container portability, managed runtime simplicity, or event-driven execution?

• What data does it read and write?

• What failure modes are acceptable?

• How will it be deployed and changed?

These questions narrow options before service names dominate the discussion.

Compare Options by Responsibility

When comparing services, focus on trade-offs.

This turns a service list into an architecture conversation.

Good Answers Include Trade-Offs

In architecture conversations, a good recommendation rarely sounds like:

Use this service because it is best.

It sounds more like:

Given these constraints, I would choose this option because it reduces these risks and fits this operating model. The trade-offs are these, and I would watch these signals after release.

That answer shows judgment.

Example: Compute Choice Framed Early

Suppose a team needs to run a customer portal.

A shallow discussion might ask:

• Should we use EC2?

• Should we use containers?

• Should we use Lambda?

A better discussion asks:

• Is this an existing app that expects a server?

• Does the team already use containers?

• Does the workload need long-running processes?

• Is request latency predictable?

• Does the app need background jobs?

• Who will own patching, scaling, deployment, and observability?

• Can the team accept event-driven constraints?

Only after that should the conversation compare EC2, containers, serverless functions, or a managed application platform.

Service Selection Is Also De-Selection

Good architects explain what they are not choosing.

For example:

• "I would not start with Kubernetes unless the team needs that control and can operate it."

• "I would not use a public database endpoint by default."

• "I would not split into many accounts before ownership and guardrails are clear."

• "I would not force serverless if the workload is a long-running process with complex local state."

• "I would not choose multi-region active-active unless the business requirement justifies the complexity."

De-selection shows that the recommendation is based on constraints rather than fashion.

Scenario: A Better First Conversation

A stakeholder asks:

Which AWS services should we use for our new customer portal?

A useful response is:

I can recommend services after we frame the workload. First I want to understand the user journey, data sensitivity, expected traffic, availability target, compliance constraints, integration needs, team skills, deployment model, and operating ownership. Then we can compare compute, data, networking, identity, observability, and cost options. The goal is not only to launch the portal; it is to run it safely and improve it over time.

That response buys the architecture conversation time to become useful.

Common Mistakes

• Treating service mapping as architecture.

• Choosing the most powerful option when a simpler managed option fits.

• Choosing the simplest option while ignoring constraints it cannot satisfy.

• Forgetting team skill and operating model.

• Giving a recommendation without naming trade-offs or risks.

If Someone Asks You

How do you choose AWS services?

A good answer is:

I start with the workload shape and responsibility boundary. Then I compare options by control, operations, security, reliability, cost, team skill, deployment model, and future change. AWS service names matter, but the recommendation should explain why the service fits the responsibility and what trade-offs the team accepts.

What You Should Remember

Service selection is a trade-off explanation.

Questions to Check Your Understanding

1. Why is "What is the AWS equivalent?" not enough for service selection?

2. Which trade-offs should you compare before recommending a service?

3. Why should a recommendation include what you are not choosing?