Performance is one of the most persistent challenges for technical teams — regardless of size, sector, or technology stack. In traditional on-premises environments, optimising for performance can be cumbersome and expensive. One of the great innovations of cloud infrastructure is its ability to scale dynamically, enabling consistent performance, cost efficiency, and responsiveness to demand.
This is where the AWS Well-Architected Framework becomes invaluable. It’s one of the most comprehensive collections of best practices for teams undergoing cloud transformation. Within that framework, the AWS Performance Pillar plays a vital role.
What Is the Performance Efficiency Pillar?
AWS defines it as:
“The performance efficiency pillar focuses on the efficient use of computing resources to meet requirements and how to maintain that efficiency as demand changes and technologies evolve.”
This is the fourth part of our series exploring each of the Well-Architected pillars.
1. Selection: Choosing the Right Architecture
At the heart of performance efficiency is a fundamental question:
“How do you select the best-performing architecture?”
The answer isn’t to simply throw technology at the problem. It starts with understanding your users and their needs. Use methods like domain-driven design to break problems into domains and establish clear boundaries. Only then can you begin to design an architecture that truly serves its purpose.
We’ve each faced this moment — selecting an architecture that could define a system’s trajectory for the next 10 or even 20 years. It’s a moment that carries weight. The temptation is to rush to something that “works”, but a short pause at the beginning pays dividends later.
2. Mental Models and Future Evolution
A clear and consistent mental model is crucial. Think of it like a drawing of a car — engine, wheels, steering wheel — something everyone understands. Your system architecture should feel the same: understandable and explainable.
But simplicity isn’t static. Systems must evolve. Ask yourself: can the architecture grow with your needs? Or have you painted yourself into a corner?
That’s one of the strengths of cloud-native and serverless-first thinking. It supports fast development, modular design, and allows you to plug in managed services. An event-driven approach, in particular, enables easy future adjustments and scalability.
3. Should You Build It?
Another critical consideration: build, buy, or rent?
Not every problem requires a custom-built solution. You need to assess:
- Is this component part of your core intellectual property?
- Could a managed service do the job?
- Would it be easy to replace or upgrade later?
Wardley Mapping can help. For example, if you need global storage — don’t build it. Use S3.
We’ve found a serverless-first mindset extremely helpful here. Whether it’s DynamoDB, Aurora Serverless, or something further along the serverless spectrum, ask:
- Is there a managed service that fits our needs?
- If not, what’s the next best (still scalable) option?
This applies across storage, compute, networking, and databases.
4. Reviewing and Adapting
The cloud moves fast. AWS releases new services regularly. To stay performant, your system needs to be able to adapt without falling apart.
Think in terms of two-way doors: changes that can be reversed. Avoid one-way decisions that lock you in.
Mapping your architecture helps. Know your stack. Understand where components sit in their evolution. When something new emerges, you’ll be able to immediately assess whether it’s worth adopting.
We’ve been through this ourselves. At one point, we were using SNS and SQS for eventing. It worked well — until EventBridge came out. We had designed for adaptability, and transitioning to EventBridge lowered latency and streamlined our system. That’s the value of building with flexibility in mind.
5. Monitoring and Trade-Offs
Monitoring for performance is fairly straightforward — but it must be intentional. Equally important are the trade-offs.
A great example: using AWS Lambda Power Tuner to balance memory and compute. It helps find the sweet spot between cost and performance.
Key questions:
- Is the level of performance you’re aiming for truly necessary?
- Would a one-second response time be sufficient?
- Are you over-engineering when “good enough” would do?
Sustainability is a factor too. Don’t overuse compute for the sake of shaving milliseconds unless it adds real value.
6. Avoid Over-Optimisation
Finally, a word of caution: don’t over-optimise.
It’s easy to get carried away tweaking for the last 5% of performance. But is it worth the engineering time? Often, the gains don’t justify the effort — especially as your system matures.
Yes, slim down bloated Lambdas. Trim unnecessary code. But also recognise when it’s good enough, and move on to higher-value tasks.
Wrapping Up
The AWS Performance Pillar and efficiency isn’t about chasing raw speed — it’s about smart choices. Choices that are:
- User-focused
- Cost-aware
- Scalable
- Evolvable
One of the biggest perks of going serverless or managed? The provider does the heavy lifting. Cold starts improve. Inter-service performance improves. Infrastructure gets faster — and you benefit automatically.
So take time at the start. Build for change. Review regularly. And let your architecture evolve with your business.
Serverless Craic from The Serverless Edge
Check out our book, The Value Flywheel Effect
Follow us on X @ServerlessEdge
Follow us on LinkedIn
4 thoughts on “AWS Well-Architected Framework: Performance Efficiency Pillar”