AWS Builder Center

Builder Center

Your AWS Architecture Is on Trial ⚖️ — What Would You Remove?

Your AWS Architecture Is on Trial ⚖️ — What Would You Remove?

Imagine a student app serving just 200 users but using 10 AWS services. Is that good architecture or pure overengineering? Take the role of the architect, remove what you think is unnecessary, and defend your decision in the comments.

Your AWS Architecture Is on Trial ⚖️ — What Would You Remove?

Imagine you are reviewing a new campus app before its first launch.
The app lets students:
  • Create an account
  • Upload event posters
  • Register for events
  • Receive notifications
  • Search events
The team has built this architecture:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
Students
↓
Amazon CloudFront
↓
Amazon S3
↓
Amazon API Gateway
↓
AWS Lambda
↓
Amazon DynamoDB

Supporting services:
Amazon Cognito
Amazon SQS
Amazon EventBridge
Amazon ElastiCache
Amazon OpenSearch Service
The app currently has only 200 users.
Everything works.
The team says:
“We built it this way because we wanted the architecture to be scalable from day one.”
And now the architecture is on trial. ⚖️

The Case Against It

Some of these services may have a clear job.
Some may become useful later.
But the real question is:
Do we need all of them right now?
For example:
Amazon S3 + CloudFront
Makes sense for serving static frontend content.
API Gateway + Lambda
A reasonable serverless API pattern.
DynamoDB
Could be a good fit for event and registration data depending on the access patterns.
Amazon Cognito
Useful when the application needs user authentication.
So far, the architecture looks reasonable.
But then we add:
Amazon SQS
Do we actually have background work that needs buffering or asynchronous processing?
Amazon EventBridge
Are we really coordinating multiple event-driven workflows?
ElastiCache
Do we have a real caching problem yet?
OpenSearch
Do 200 users really need a dedicated search platform?
This is where architecture becomes interesting.
A service is not automatically a good decision just because it is powerful.

My Rule

I like to ask one question before adding another box to an architecture diagram:
“What real problem does this service solve today?”
Not next year.
Not when the app has millions of users.
Today.
If there is no clear answer, I would hesitate to add it.

The Better Architecture?

For the first release, I might keep the core path simple:
1
2
3
4
5
6
7
8
9
10
11
Students
↓
CloudFront
↓
S3
↓
API Gateway
↓
Lambda
↓
DynamoDB
Then add other services only when the application gives us a reason.
For example:
Need asynchronous processing? → Consider SQS.
Need event-driven workflows? → Consider EventBridge.
Need caching because latency or load demands it? → Consider ElastiCache.
Need advanced search capabilities? → Consider OpenSearch.
The important idea is not:
“Use fewer AWS services.”
It is:
“Use each service intentionally.”

The Architecture Trial 🔨

Here is the fun part.
You are the architect.
You inherit the original 10-service architecture for a 200-user application.
You may remove only THREE services.
Which three would you remove first?
A) SQS
B) EventBridge
C) ElastiCache
D) OpenSearch
E) Cognito
F) CloudFront
G) API Gateway
H) Lambda
I) DynamoDB
J) S3
And there is one more question:
Would you rather start simple and add services later, or design for future scale from day one?
I’m genuinely curious where other builders draw the line between “future-proof” and “overengineered.”
Drop your 3 choices + your reason in the comments. 👇
#AWS #AWSBuilderCenter #CloudArchitecture #CloudComputing #Serverless
# cloud-concepts# aws-builders# aws-certification# aws-cloudformation# aws-community
Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.
Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article