AWS Solution Architect

Sample architecture decision — B2B SaaS

Summary

Use a small multi-account landing zone, a regional multi-AZ application stack, managed PostgreSQL, private object storage, and a queue-backed worker path. This meets the stated launch goals with a manageable operating model. The 99.9% target is a design objective, not a demonstrated SLA.

Assumptions and questions

• One initial AWS Region; customer data residency and recovery geography are not specified.
• 800 requests/second is peak steady load and 5x bursts are brief; validate request mix, concurrency, payload size, and read/write ratio.
• p95 <300 ms is an API objective; downstream dependencies and client network time are outside direct control.
• Ask for RPO/RTO, tenant isolation requirements, retention, encryption/key ownership, expected document sizes, and email provider constraints.

Proposed shape

Accounts: Separate production workloads from nonproduction; use dedicated security/log archive and shared services accounts as team maturity warrants. Centralize audit logs. Apply organization guardrails and billing tags. Keep a documented break-glass path.
2.

Network: Two or more Availability Zones with public ingress only at a managed load balancer or API edge. Place application tasks, workers, and database in private subnets. Define egress explicitly; compare NAT with appropriate VPC endpoints after measuring paths and cost. Avoid overlapping CIDRs and record DNS ownership.
3.

API and compute: Start with a container service on a managed orchestrator and autoscaling behind an application load balancer. Keep stateless API tasks separate from queue workers. Use health checks, bounded concurrency, request timeouts, graceful draining, and deployment rollback. Evaluate serverless if traffic shape and runtime support favor it.
4.

Data: Use managed PostgreSQL with Multi-AZ failover, encryption, automated backups, point-in-time recovery, connection pooling, and tested restore procedures. Define read scaling only after measuring bottlenecks. Store documents in private S3 buckets with Block Public Access, versioning or lifecycle rules based on recovery needs, server-side encryption, and narrowly scoped access.
5.

Async work: Place email/report jobs on a durable queue; make consumers idempotent, set visibility and retry behavior deliberately, route repeated failures to a DLQ, and alert on age and backlog. Keep customer-facing API responses independent of slow jobs.
6.

Security: Federate workforce access with short-lived roles; separate task roles from execution roles; grant least privilege by resource and action. Use managed secret storage, key policies, TLS, audit trails, security findings ownership, and rate limits. Never place static admin keys in the application.
7.

Operations: Instrument request latency, error rate, saturation, queue age, database connections, and business completion. Define SLO burn alerts and a runbook. Deploy via reviewed IaC through staged environments, canary or gradual rollout, automated smoke checks, and a tested rollback path.

Recovery and validation

First agree on RPO/RTO. Multi-AZ addresses some zonal failures but is not multi-Region disaster recovery. Test database restore and document recovery at least once before production; only add cross-Region replication/failover if the objectives justify its cost and operational complexity. Load-test representative read/write mixes and burst behavior, test downstream throttling and queue recovery, validate tenant authorization, and confirm current service limits and regional availability.

Cost drivers to measure

Compute baseline and burst capacity, database class/storage/IO, NAT and cross-AZ traffic, object retention and requests, logs/metrics retention, queue throughput, and any cross-Region replication. Use a workload unit such as cost per active tenant or completed report.

Next steps

Confirm RPO/RTO, data region, tenant isolation, and traffic mix; then create a threat model, deployment diagram, IaC module plan, load-test profile, and acceptance criteria. This is a design example only: nothing has been deployed or inspected in an AWS account.