Need a Suggestion Regarding AWS? Use These 7 Questions Before You Pick a Service

“Need suggestion regarding AWS” is a common opening line on Reddit, but it is not a complete question. AWS offers more than 200 services, and a blanket recommendation can be worse than none. The right suggestion depends on your workload, traffic shape, team skills, data model, budget, and compliance requirements.

The best AWS suggestion is a method, not a service

Before choosing between EC2, Lambda, ECS, or EKS, go through the [AWS Well-Architected Framework](https://docs.aws.amazon.com/wellarchitected/latest/framework/welcome.html). Its six pillars—operational excellence, security, reliability, performance efficiency, cost optimization, and sustainability—exist because no single service wins in every situation.

Use these seven questions to turn a vague AWS question into a clear architecture choice.

1. Is the workload stateful or stateless?

Stateless workloads are the best fit for [AWS Lambda](https://aws.amazon.com/lambda/) or containers on [Amazon ECS with AWS Fargate](https://aws.amazon.com/ecs/). They scale horizontally, restart safely, and do not depend on local disk.

Stateful workloads should separate state from compute. Store sessions in [Amazon ElastiCache](https://aws.amazon.com/elasticache/) or [Amazon DynamoDB](https://aws.amazon.com/dynamodb/), files in [Amazon S3](https://aws.amazon.com/s3/), and relational data in [Amazon RDS](https://aws.amazon.com/rds/). This separation makes compute disposable and simplifies scaling.

2. What does the traffic pattern look like?

If traffic is spiky or event-driven, serverless services such as Lambda, SQS, and EventBridge reduce idle capacity risk. You pay for usage instead of reserved instances.

If traffic is steady and predictable, EC2 or ECS with Savings Plans can be simpler and cheaper. AWS Savings Plans can reduce compute costs compared to on-demand pricing, but they require a commitment. Use the [AWS Pricing Calculator](https://calculator.aws/) to compare before committing.

3. Who is on call?

A small team with limited infrastructure experience should bias toward managed services. RDS, DynamoDB, S3, CloudFront, and Fargate remove many operational burdens: patching, capacity planning, replication, and backup.

A team that already operates Kubernetes may choose [Amazon EKS](https://aws.amazon.com/eks/), but only if the platform value outweighs the control-plane and node-management overhead. Do not adopt Kubernetes because a Reddit thread says it is the industry standard.

4. What is the data model?

Relational data with complex joins and transactions belongs in RDS for PostgreSQL or MySQL. High-scale key-value or document data with unpredictable access patterns fits DynamoDB. Full-text search or log analytics may require [Amazon OpenSearch Service](https://aws.amazon.com/opensearch-service/). Unstructured objects, backups, and static assets belong in S3.

Do not force one database to do all three jobs.

5. How much cold-start latency can you tolerate?

Lambda has improved cold starts, but startup time still varies by language, package size, and VPC networking. If your API is on a critical path and every millisecond matters, run warm containers on Fargate or EC2 behind an Application Load Balancer. If your system can tolerate occasional startup latency, Lambda can reduce operational overhead.

Provisioned concurrency can reduce Lambda cold starts for predictable peaks, but it adds cost.

6. What does the budget actually look like?

Do not build a multi-account landing zone for a $50 monthly bill. Early-stage products usually need one or two accounts, an S3 bucket, a managed database, and a deploy pipeline. Use [AWS Cost Explorer](https://aws.amazon.com/aws-cost-management/aws-cost-explorer/) and [AWS Compute Optimizer](https://aws.amazon.com/compute-optimizer/) to review spending after the first 30 days.

A useful rule: optimize after you understand the bill, not before you have traffic.

7. Are there compliance or data-residency constraints?

Check the [AWS Compliance Programs](https://aws.amazon.com/compliance/programs/) page for standards such as HIPAA, PCI DSS, and GDPR. Some services are in scope for specific programs only in specific regions. If your customers require data residency, that constraint alone may eliminate many service choices.

A practical default for a typical product

For a new web application or API with moderate traffic:

**Frontend and static assets:** S3 + CloudFront

**Application compute:** AWS Fargate or Lambda behind an Application Load Balancer

**Database:** RDS PostgreSQL or DynamoDB depending on the data model

**Background jobs:** SQS + Lambda

**Observability:** CloudWatch Logs, Metrics, and Alarms

**Secrets and config:** AWS Secrets Manager or Systems Manager Parameter Store

This stack is not the right answer for every product, but it is a reasonable starting point when the team is small and traffic is unclear.

How to ask a better AWS question

Instead of asking for a single suggestion, include enough context for a useful answer:

What does the app do?

What is the expected request volume and growth rate?

Is the workload stateless or stateful?

Does the team have experience running infrastructure?

What is the budget range?

Are there compliance or data-residency requirements?

What has already been tried?

A specific question gets a specific recommendation. For example, “We are running a stateless Node.js API with 50 requests per second and a two-person team—should we use Lambda or Fargate?” is answerable. “Need suggestion regarding AWS” is not.

The decision loop we use at Sapior

At Sapior, we treat AWS architecture choices as product decisions, not cloud trivia. Start with the workload, separate state from compute, prefer managed services, estimate cost early, deploy with infrastructure as code, and review the system after 30 days. The AWS Well-Architected Framework gives you a shared language for that review.

The next time someone asks you for an AWS suggestion, ask one question first: what are you building? The service choice follows from there.