AWS Design Principles Cheat Sheet

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.
  • Key Services: AWS CloudFormation (using templates) and AWS CDK (Cloud Development Kit) (using familiar programming languages) are the primary services for this.

3. Automation

• Serverless Management and Deployment – Being serverless shifts your focus to automating 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 that 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.
  • Key Service: Amazon EventBridge is the modern, serverless event bus that extends and replaces the older CloudWatch Events, enabling you to react to events from AWS services, SaaS applications, and your own applications.

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.
  • Key Service: AWS Lake Formation is a managed service that simplifies the process of building, securing, and managing your data lake.

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 (RIs): Offer significant discounts on EC2 and RDS for a 1- or 3-year commitment to a specific instance type.
  • Savings Plans: A more flexible, modern model. You commit to a dollar-per-hour spend for 1 or 3 years, which automatically applies to EC2, Fargate, and Lambda, offering RI-like discounts without being locked to a specific instance. 
  • Spot Instances: (See AWS Pricing).

10. Caching

• Application Data Caching – Store and retrieve information from fast, managed in-memory caches.
• Edge Caching – Serves 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 the security OF the Cloud while customers handle security IN the Cloud.
• Reduce Privileged Access – Implement the 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 assumes that the components of your architecture will fail. This reinforces you to always design your cloud architecture to be highly available and fault-tolerant. 

13. Test Systems at Production Scale

• In the cloud, you can create a full-scale, production-like test environment on-demand, run your tests, and then decommission it, paying only for the time used. This allows you to verify how your application will perform under real-world load, identify bottlenecks, and build confidence before deploying to production.

14. Allow for Evolutionary Architectures

• This principle states that architectures should be designed to evolve over time. In practice, this means using loosely coupled components (like microservices) and automation, which allows you to update, replace, or add individual components without disrupting the entire system.

15. Drive Architectures Using Data

• Do not make architectural decisions based on feelings or guesses. Use data (logs, metrics, and events) to make informed decisions. This data allows you to understand the “why” behind performance issues or usage patterns, helping you select the right services or scaling strategies.
  • Key Services: Amazon CloudWatch (for metrics), AWS CloudTrail (for API logs), AWS X-Ray (for tracing).

16. Improve Through Game Days

• A “game day” is the practice of regularly running simulations of failure events to test your system’s response (e.g., a failed AZ, a traffic spike, a security breach). By practicing failure, you can uncover hidden flaws, test automated responses, and ensure your team is prepared.
  • Key Service: AWS Fault Injection Simulator (FIS) is a managed service built specifically for running these controlled “game day” experiments.

AWS Six Pillars Cheat Sheet References:

https://d1.awsstatic.com/whitepapers/AWS_Cloud_Best_Practices.pdf
https://www.slideshare.net/AmazonWebServices/best-practices-for-architecting-in-the-cloud-jeff-barr