Customer-Facing Application Scenario

Goal

This section applies the chapter's responsibility-first model to a realistic starting conversation: a company wants to move a customer-facing application to AWS and asks which services to use.

The durable idea is:

A strong AWS recommendation starts with context, constraints, options, trade-offs, risks, and next steps.

The Scenario

A company runs a customer-facing portal in a traditional hosting environment. Customers use it to view orders, update profile details, download invoices, and contact support. The business wants to move the portal to AWS because the current environment is slow to change, hard to scale during seasonal traffic, and expensive to operate.

The first question from leadership is:

Which AWS services should we use?

That is a fair question. It is just not the first architecture question.

Reframe the Conversation

A better first response is:

Before naming services, I would map the customer journey, data sensitivity, dependencies, traffic pattern, availability target, security requirements, team skills, deployment model, and operating ownership. Then I can recommend AWS services that fit the responsibility boundaries and explain the trade-offs.

This response does three useful things:

1. It respects the need for a recommendation.

2. It avoids premature product selection.

3. It turns the conversation toward architecture judgment.

Architecture Questions to Ask

Start with context:

These questions reveal whether the portal is a simple migration, a modernization effort, a compliance-sensitive platform, or a customer-critical system that needs more careful staging.

A Responsibility Sketch

An early design sketch might look like:

Customer portal on AWS
  -> production AWS account
  -> selected Region close to primary users
  -> public entry point for customers
  -> private application and data paths
  -> IAM roles for app, operations, and deployment
  -> managed data storage based on access pattern
  -> logs, metrics, alarms, backups, and cost ownership
  -> migration path from existing dependencies

This sketch does not commit to every service. It gives the team a map for choosing services.

Possible First Recommendation

After discovery, a recommendation might sound like this:

For the first release, I would keep the architecture simple and choose managed services where they reduce operational burden. I would separate production ownership with an AWS account boundary, deploy in one primary Region with multi-AZ thinking where the workload needs availability, keep customer-facing entry points public but data paths private, use IAM roles rather than long-lived keys, choose compute based on the existing application shape and team skill, choose data services by access pattern, and set up monitoring, logs, alarms, backups, and cost tags from the beginning.

Notice that this is still not a final service list. It is a defensible direction. The service list should come after the team confirms constraints.

Trade-Offs to Explain

A useful architecture answer names trade-offs:

• A faster lift-and-shift may reduce migration risk but preserve old operational habits.

• A deeper modernization may improve scaling and operations but increase delivery risk.

• A single-Region design may be simpler and cheaper, but may not meet disaster recovery needs.

• Multi-region designs can improve resilience but add data consistency, routing, testing, and cost complexity.

• A highly managed service can reduce operations but may require adapting the application.

• More control can help unusual requirements but increases ownership burden.

Trade-offs make the recommendation credible.

Risks and Next Steps

For this portal, next steps might be:

1. Map user journeys and critical business functions.

2. Inventory dependencies and data flows.

3. Decide account, Region, and environment boundaries.

4. Define identity and access model.

5. Sketch public, private, and administrative network paths.

6. Compare compute and data options against workload shape.

7. Define logging, metrics, alarms, backup, recovery, and cost ownership.

8. Run a Well-Architected-style review of the first design.

9. Plan a migration or modernization sequence with rollback.

This gives the team a path from question to design.

Common Mistakes

• Answering with a service list before understanding the workload.

• Migrating the application without fixing ownership, identity, observability, and cost controls.

• Over-engineering global resilience before confirming the business requirement.

• Under-engineering security because the first release is "only a migration."

• Treating the AWS account, Region, and network as setup details instead of architecture decisions.

If Someone Asks You

Which AWS services should we use for this customer portal?

A good answer is:

I would first frame the workload: customer journey, data sensitivity, traffic, identity, dependencies, availability, security, team skills, operations, and cost. Then I would choose AWS services that fit those responsibility boundaries. The recommendation should explain why each service fits, what trade-offs it creates, which risks remain, and what the next validation step is.

What You Should Remember

Architecture recommendations should explain reasoning, not only name products.

Questions to Check Your Understanding

1. Why is the first service list usually premature?

2. Which constraints shape the customer portal architecture?

3. What should an AWS recommendation include besides service names?