The Solutions Architect Associate exam guide specifies that 60% of the exam questions may be on the topic of designing highly available, cost efficient, fault tolerant, scalable systems. So this domain is a core focus.

High availability, fault tolerance, and cost efficiency are all fundamental concepts in AWS design. It's rare we have the opportunity to deliver on all three. So let's ensure we understand each of these and the design decision compromises that as architects we may be required to make to design solutions that can deliver on all, or some, of these three states. A core design principle inherent to each of these states is elasticity. Elasticity is the ability to scale up and down to meet requirements. You do not have to guess capacity when provisioning a system in AWS. AWS's elastic services enable you to scale services up and down within minutes. Improving agility and reducing costs as you only pay for what you use. AWS enables you to test provision, go live with solutions faster and more efficiently than with traditional IT infrastructure. Auto Scaling helps you maintain application availability. It allows you to scale your capacity up or down automatically, according to conditions you define. You can use Auto Scaling to help ensure that you are running your desired number of Amazon EC2 instances. The operating scale of AWS means you can keep adding resources as required to meet the demands of your users. A highly available environment aims to have minimal service interruption. A fault tolerant environment aims to have zero service interruption. AWS provides inherent services that make it possible to design for high availability and fault tolerance. However, they need to be implemented correctly to create a highly available, fault tolerant solution. Amazon Simple Storage Service, Amazon Simple Queue Service, and Amazon Elastic Load Balancing have been built with fault tolerance and high availability in mind. Amazon Elastic Cloud Compute and Amazon Elastic Block Store provide specific features such as availability zones, elastic IP addresses and snapshots. However, you need to implement these services correctly to create a highly available system. Exam questions will test your ability to identify the right mix of products to achieve the desired business objective. An AWS certified solution architect needs to have a thorough understanding of the options, benefits, costs, and constraints when designing a solution on AWS. Now the AWS global footprint is a real benefit for AWS customers. And of course, as an architect, it's tempting for us to want to leverage this too, and to make every one of our solutions multi-region, so that we can deliver that truly bulletproof solution and you might find, your first highly available, fault tolerant, white board design describes a full active active solution with huge synchronous databases running in multiple regions. Wouldn't that be great, right? However, there are a number of cost and performance factors for the architect to consider. Running synchronous services is generally quite expensive and latency between regions and inter-region data transfer costs might not create the best outcome for your customer. So you need to be designing for cost optimization as well as performance at every point. And a key tenant of being an AWS architect is to be always checking and rechecking that your design will in fact achieve the best outcome for your customer. Designing for the cloud often means that biggest isn't necessarily best. And decoupling your services and reducing components into loosely coupled units that could run on smaller machines may improve performance and reduce single points of failure. More good news is that you don't necessarily need to run services across multiple regions to achieve a highly available solution. Availability zones are designed to provide fault isolation. So leveraging more than one availability zone within a region can provide very high levels of availability and fault tolerance. You might consider locating services in more than one region where fault tolerance is the priority and cost is not the primary constraint. For many solution designs, you may achieve an acceptable level of fault tolerance at a lower cost using multiple availability zones in one region. One of the key factors in design is determining just what the acceptable level of fault tolerance is. As an architect, you need to ascertain if the customer can be without the system or not. If not, then you need to design for the highest durability possible. If an outage to the system is not actually mission critical, then you need to work out how long the organization could be without this system and when the system is back up, what is the last acceptable point in time to recover to. Now that process is generally called Business Continuity Planning. The AWS well architected framework provides architectural-based practices across four pillars for designing reliable, secure, efficient, and cost effective systems in the cloud. The framework provides a set of questions that allow you to asses an existing or proposed architecture and also a set of AWS best practices for each pillar. Under security, we talk about the ability to protect information, systems, and assets while delivering business value through risk assessments and mitigation strategies. Under reliability, it's the ability of the system to recover from, say, infrastructural service failures, dynamically acquire computing resources to meet demand, and to mitigate disruptions such as misconfigurations or transient network issues. For performance efficiency, we're looking for the ability to use competing resources efficiently to meet system requirements and to maintain that efficiency as demand changes and technologies evolve. Cost optimization, and really we're looking at the ability to avoid or eliminate unneeded cost or sub-optimal resources. Simply shifting an application to AWS will not necessarily immediately improve durability or availability. It's important to redesign your stat for the cloud at every opportunity. So you gain maximum advantage from the scale and services AWS provides. As an AWS solution architect, you should look for ways to decouple services using Simple Queue Service to manage requests between layers deploying Elasticache or Dynamo DB to store and retrieve session data to reduce dependency on service state and increase performance. Perhaps optimizing business workflow using Simple Workflow Service or Lambda for server-less architectures. If we take a design for failure approach we might improve the durability and self-healing of our architecture. We might use Route 53 to support load balances that send traffic to multiple app servers that are using a replicated master slave database. It may make sense to consider adding direct connect to reduce the risk of connectivity failure. And if you are presented with a single point of failure, it's most likely you will need to implement a service to address it. Now high availability aims to provide minimal service interruption and fault tolerance aims to provide no service interruption which is a really high bar and many systems and organizations may be able to tolerate some level of service interruption. Defining this acceptance point should be part of agreeing to recovery time, recovery point objective with your business stakeholders. Exam questions on this topic will generally provide you with the information you need to decide the level of availability and fault tolerance required. So ensure you read the questions carefully.