On its surface, this pillar is all about speed. It's a well-known fact that website performance has a huge impact on user adoption. Just a few milliseconds can be the difference between a happy user and someone who abandons your site for a competitor.

But the performance efficiency pillar of the Well-Architected Framework goes further than that. It covers the efficient use of computing resources, and how to keep your systems performing at their best as the technology landscape changes and as user demand fluctuates. This pillar is closely related to cost optimization because, in some cases, it's possible to be over-provisioned and paying for resources that you don't need. An efficient system does not necessarily have to be as fast as possible; instead, it should be as fast as it needs to be, using the most optimal resources to accomplish the task at hand.

One of the easiest ways to improve your application's performance and take advantage of the latest technologies is simply to make use of cloud services. AWS offers many services directly related to performance, such as Amazon CloudFront, that would be very difficult for a small technical team to implement on their own. Serverless architectures powered by AWS Lambda offer configurable performance rungs and scalable compute resources at a fraction of the cost of self-hosting your own code on machines that you provision.

With AWS, it's easy to choose the perfect tool for the job to maximize performance. For example, you can experiment with a variety of NoSQL databases, such as Amazon DynamoDB, and compare performance to more traditional databases such as PostgreSQL running on Amazon Aurora. CloudWatch dashboards make it easy to chart your performance so that you can make more informed choices.

Performance efficiency is one of those topics that requires a lot of data so that it can inform us of the best decisions we can make. Make sure that your applications are instrumented to log as much data as possible with regard to performance. Automate your responses to applications that are performing poorly. For example, if a cluster of web servers running on EC2 is struggling to keep up with the load, configure an Auto-Scaling Group to automatically provision new servers until performance falls in line with expectations.

There are EC2 instance types to cover almost every possible performance scenario. Since many applications haven't evolved to containers or serverless functions yet, it is very important for an AWS administrator to understand the plethora of options available. The following is a quick summary of the main EC2 instance types:

• General-purpose: These are the go-to instance types that can handle most typical workloads, and are as follows:
  • A1: ARM-based AWS Graviton processors.
  • T3: Next-generation burstable instances for spiky workloads.
  • M5: The latest generation of standard, general-purpose instances. This should be the default starting point for most applications.
• Compute-optimized: Choose one of these types if your application has excessive CPU requirements:
  • C5: The standard instance type for cost-effective compute-intensive workloads
  • C5n: Similar to C5, but with up to 100 Gbps networking
• Memory-optimized: If your application eats a ton of RAM, choose an instance from this category:
  • R5: Configure an instance for up to 768 GiB.
  • X1e: These instances are made specifically for high-performance databases with extreme memory requirements and attached solid-state disks.
  • High memory: If you run a large SAP HANA installation, choose this instance to configure up to a whopping 12 TiB per machine!
  • Z1d: The Z family offers the highest core frequency available at the time of writing, that is, 4.0 GHz.
• Accelerated computing: Many machine learning tasks require access to Graphical Processing Units (GPUs):
  • P3: The latest generation of GPU instances, offering the best bang for your buck currently offered by any provider.
  • F1: A few specific types of machine learning algorithms perform better with the field-programmable gate arrays (FPGAs) provided by this instance type.
• Storage-optimized: Choose an instance from this category if the main requirement of your application is hard drive space and disk I/O performance:
  • H1: Up to 16 TB of local HDD storage for high-throughput use cases that utilize spinning disks.
  • I3: This family offers Non-Volatile Memory Express (NVMe) drives for high IOPS at a relatively low cost.
  • D2: These instances have the best cost-to-throughput ratio for spinning hard drives, with one 48 TB HDD per instance.

Like any architecture, you should conduct extensive experiments with different instance types under production-equivalent loads to make sure you have made the correct choice.

Of course, there is much more to optimizing performance than choosing the correct instance type, especially if you have moved on to serverless architectures. Evaluate your storage and networking needs, experiment, gather data, and continually refine your choices as the landscape evolves.