AWS Well-Architected Framework — Performance Efficiency Pillar

Let's short detail about the performance efficiency pillar.

What is the main purpose or goal of this pillar?
The main purpose of this pillar focuses on the efficient use of computing resources to meet requirements, and how to maintain efficiency as demand changes and technologies evolve. Using this pillar will allow us to optimize for higher performance and Take a data-driven approach to build a high-performance architecture.

It has mainly four(4) key focus area:
1. Selection
2. Review
3. Monitor and
4. Trade-Off

Selection: The main objective is how to make Optimal Solutions for a system based on the workload. The Selection part has 4 Sections :
1. Compute
2. Storage
3. Database
4. Network
Each section has one or multiple Questions. Let's talk about these questions and all options in detail.

PERF 1. How do you select the best-performing architecture?

Understand the available services and resources : We need to know details about the available service and resources that we are going to use.
For Exmaples —
a. Should we use shared storage or dedicated storage?
b. How does autoscaling work or should we use automatic scaling or not
c. Which management service we should use, how its work, etc.
d. Which ec2 instance we should use or which compute service and how its work
Level of risk (if this best practice is not established): High

Define a process for architectural choices: It has mainly 2 parts -
Define the architectural approach:
a. Are we considering the projects for Desktop, Mobile, and Web?
b. Consulting with other teams, Designing architecture diagrams, and Identifying opportunities for reuse. Also, we can talk with the APN partner about the details and get the guidelines.
Define performance requirements: Use the customer experience to identify the most important metrics. Like, identifying the target, measurement approach, and priority. Maybe we will have some critical user stories, so in that case, we need to Prioritizing those things?
Level of risk : High

Factor cost requirements into decisions: It basically Optimizes the workload components to reduce the cost.
a. Choose the Right size of workload components
b. Enable elasticity to reduce cost
c. Maximize component efficiency.
d. Sometime we use managed databases, in-memory caches, and reverse proxies. So in that case we need think which workload components can be replaced with managed services when ita appropriate
Level of risk: Medium

Use policies or reference architectures: It's basically Establishing a policy for architecture or technology.
Let say we are using a few services that can be managed by AWS or other cloud services. We can also do something by using other services. we need to make a policy to compare and visualize both options so vendors can see and choices and Accordingly can make decisions quickly.

Use the guidance from your cloud provider or an appropriate partner

Benchmark existing workloads: 2 Major things are considered in that section.
Monitor performance during development :
We need to make sure a pipeline performs automatic load tests in our workload in the development phase.
Real-user monitoring:
We need to ensure the page load timing, JavaScript errors, HTTP requests, etc for real-time monitoring. We can collect data using the Cloudwatch RUM.

On going ….