AWS Well-Architected Framework – Design Principles

 1. Scalability

• Scaling Horizontally – an increase in the number of resources
• Scaling Vertically –  an increase in the specifications of an individual resource

2. Disposable Resources Instead of Fixed Servers

• Instantiating Compute Resources – automate setting up of new resources along with their configuration and code
• Infrastructure as Code – AWS assets are programmable. You can apply techniques, practices, and tools from software development to make your whole infrastructure reusable, maintainable, extensible, and testable.

3. Automation

• Serverless Management and Deployment – being serverless shifts your focus to automation of your code deployment. AWS handles the management tasks for you.
• Infrastructure Management and Deployment – AWS automatically handles details, such as resource provisioning, load balancing, auto scaling, and monitoring, so you can focus on resource deployment.
• Alarms and Events – AWS services will continuously monitor your resources and initiate events when certain metrics or conditions are met.

4. Loose Coupling

• Well-Defined Interfaces – reduce interdependencies in a system by allowing various components to interact with each other only through specific, technology agnostic interfaces, such as RESTful APIs.
• Service Discovery – applications that are deployed as a set of smaller services should be able to be consumed without prior knowledge of their network topology details. Apart from hiding complexity, this also allows infrastructure details to change at any time.
• Asynchronous Integration – interacting components that do not need an immediate response and where an acknowledgement that a request has been registered will suffice, should integrate through an intermediate durable storage layer.

• Distributed Systems Best Practices – build applications that handle component failure in a graceful manner.

5. Services, Not Servers

• Managed Services – provide building blocks that developers can consume to power their applications, such as databases, machine learning, analytics, queuing, search, email, notifications, and more.
• Serverless Architectures – allow you to build both event-driven and synchronous services without managing server infrastructure, which can reduce the operational complexity of running applications.

6. Databases

• Choose the Right Database Technology for Each Workload
• Relational Databases provide a powerful query language, flexible indexing capabilities, strong integrity controls, and the ability to combine data from multiple tables in a fast and efficient manner.
• NoSQL Databases trade some of the query and transaction capabilities of relational databases for a more flexible data model that seamlessly scales horizontally. It uses a variety of data models, including graphs, key-value pairs, and JSON documents, and are widely recognized for ease of development, scalable performance, high availability, and resilience.
• Data Warehouses are a specialized type of relational database, which is optimized for analysis and reporting of large amounts of data.
• Graph Databases uses graph structures for queries.
  • Search Functionalities
    • Search is often confused with query. A query is a formal database query, which is addressed in formal terms to a specific data set. Search enables datasets to be queried that are not precisely structured.
    • A search service can be used to index and search both structured and free text format and can support functionality that is not available in other databases, such as customizable result ranking, faceting for filtering, synonyms, and stemming.

7. Managing Increasing Volumes of Data

• Data Lake – an architectural approach that allows you to store massive amounts of data in a central location so that it’s readily available to be categorized, processed, analyzed, and consumed by diverse groups within your organization.

8. Removing Single Points of Failure

• Introducing Redundancy
  • Standby redundancy – when a resource fails, functionality is recovered on a secondary resource with the failover process. The failover typically requires some time before it completes, and during this period the resource remains unavailable. This is often used for stateful components such as relational databases.
  • Active redundancy – requests are distributed to multiple redundant compute resources. When one of them fails, the rest can simply absorb a larger share of the workload.

• Detect Failure – use health checks and collect logs
• Durable Data Storage
  • Synchronous replication – only acknowledges a transaction after it has been durably stored in both the primary storage and its replicas. It is ideal for protecting the integrity of data from the event of a failure of the primary node.
  • Asynchronous replication – decouples the primary node from its replicas at the expense of introducing replication lag. This means that changes on the primary node are not immediately reflected on its replicas.
  • Quorum-based replication – combines synchronous and asynchronous replication by defining a minimum number of nodes that must participate in a successful write operation.
• Automated Multi-Data Center Resilience – utilize AWS Regions and Availability Zones (Multi-AZ Principle). (See Disaster Recovery section)
• Fault Isolation and Traditional Horizontal Scaling – Shuffle Sharding

9. Optimize for Cost

• Right Sizing – AWS offers a broad range of resource types and configurations for many use cases.
• Elasticity – save money with AWS by taking advantage of the platform’s elasticity.
• Take Advantage of the Variety of Purchasing Options – Reserved Instances vs Spot Instances (See AWS Pricing)

10. Caching

• Application Data Caching – store and retrieve information from fast, managed, in-memory caches.
• Edge Caching – serve content by infrastructure that is closer to viewers, which lowers latency and gives high, sustained data transfer rates necessary to deliver large popular objects to end users at scale.

11. Security

• Use AWS Features for Defense in Depth – secure multiple levels of your infrastructure from network down to application and database.
• Share Security Responsibility with AWS – AWS handles security OF the Cloud while customers handle security IN the Cloud.
• Reduce Privileged Access – implement Principle of Least Privilege controls.
• Security as Code – firewall rules, network access controls, internal/external subnets, and operating system hardening can all be  captured in a template that defines a Golden Environment.
• Real-Time Auditing – implement continuous monitoring and automation of controls on AWS to minimize exposure to security risks.

12. Cloud Architecture Best Practices

There are various best practices that you can follow which can help you build an application in the AWS cloud. The notable ones are:

1. Decouple your components – the key concept is to build components that do not have tight dependencies on each other so that if one component were to fail for some reason, the other components in the system will continue to work. This is also known as loose coupling. This reinforces the Service-Oriented Architecture (SOA) design principle that the more loosely coupled the components of the system are, the better and more stable it scales.
2. Think parallel – This internalizes the concept of parallelization when designing architectures in the cloud. It encourages you to implement parallelization whenever possible and to also automate the processes of your cloud architecture.
3. Implement elasticity – This principle is implemented by automating your deployment process and streamlining the configuration and build process of your architecture. This ensures that the system can scale in and scale out to meet the demand without any human intervention.
4. Design for failure – This concept encourages you to be a pessimist when designing architectures in the cloud and assume that the components of your architecture will fail. This reinforces you to always design your cloud architecture to be highly available and fault-tolerant.