Start with the product boundaries
Before selecting AWS services, identify the domain boundaries, trust boundaries, data flows and operational needs. A clean application model usually leads to a simpler cloud model.
Prefer managed services where they remove real operational work
Serverless and managed services can reduce infrastructure overhead, but they should be selected because they fit the workload — not because every architecture needs to look serverless.
Identity and permissions are foundational
Authentication, authorisation, service roles, secrets and privileged operations should be designed early. Retrofitting these after the product grows is usually more difficult.
Asynchronous processing improves resilience
Queues and event-driven patterns help separate slow, bursty or failure-prone work from user-facing transactions. They also make retries and operational behaviour easier to reason about.
Observability is part of the product
Logs, metrics, alerts and traceable request flows matter as soon as real users depend on the system. Production teams need to answer what failed, why it failed and who or what was affected.
Design for change, not theoretical scale
A good architecture supports the next stage of the product without creating unnecessary complexity for a scale that may never arrive.