This Guidance helps customers understand the concepts of implementing a cell-based architecture. This architecture shows fault isolation between cells, which are independent replicas of the system. Customers can use this Guidance to prevent outages caused by a software bug, failed deployment, or overload, ultimately reducing the impact to end-customers.
Architecture Diagram
Step 1
Clients connect to the routing layer. The routing layer redirects the client to the assigned cell using an HTTP redirect.
Step 2
Routing information (user to cell mapping) is stored in Amazon DynamoDB. There is a fixed number of independent clusters that store copies of the data. For new users, the cell router pushes the new user information to all clusters.
Step 3
The architecture is divided into a large number of independent cells of fixed size. The cells contain all application logic and storage.
Step 4
Each cell has monitoring and Alerting using Amazon CloudWatch. It reports its health on a variety of metrics.
Step 5
There is also a central dashboard which contains aggregated information (such as number of cells with errors and without errors).
Step 6
Cell creation and update is automated using AWS Step Functions, AWS CodePipeline, AWS CodeDeploy, and AWS CloudFormation. Updates are first deployed to a canary cell. Disaster recovery for cells is fully automated.
Step 7
Changes are streamed from all cells to a central data lake, where they can be queried using SQL in Amazon Athena.
Step 8
A rebalancer can move users between cells, and also create new cells as needed. After a successful move, it updates the user-to-cell assignment. The old cell retains a marker to redirect clients to the new cell. (Not pictured in the diagram.)
Step 1
Clients connect to the routing layer. The routing layer redirects the client to the assigned cell using an HTTP redirect.
Step 2
Routing information (user to cell mapping) is stored in Amazon DynamoDB. There is a fixed number of independent clusters that store copies of the data. For new users, the cell router pushes the new user information to all clusters.
Step 3
The architecture is divided into a large number of independent cells of fixed size. The cells contain all application logic and storage.
Step 4
Each cell has monitoring and Alerting using Amazon CloudWatch. It reports its health on a variety of metrics.
Step 5
There is also a central dashboard which contains aggregated information (such as number of cells with errors and without errors).
Step 6
Cell creation and update is automated using AWS Step Functions, AWS CodePipeline, AWS CodeDeploy, and AWS CloudFormation. Updates are first deployed to a canary cell. Disaster recovery for cells is fully automated.
Step 7
Changes are streamed from all cells to a central data lake, where they can be queried using SQL in Amazon Athena.
Step 8
A rebalancer can move users between cells, and also create new cells as needed. After a successful move, it updates the user-to-cell assignment. The old cell retains a marker to redirect clients to the new cell. (Not pictured in the diagram.)
Well-Architected Pillars
The AWS Well-Architected Framework helps you understand the pros and cons of the decisions you make when building systems in the cloud. The six pillars of the Framework allow you to learn architectural best practices for designing and operating reliable, secure, efficient, cost-effective, and sustainable systems. Using the AWS Well-Architected Tool, available at no charge in the AWS Management Console, you can review your workloads against these best practices by answering a set of questions for each pillar.
The architecture diagram above is an example of a Solution created with Well-Architected best practices in mind. To be fully Well-Architected, you should follow as many Well-Architected best practices as possible.
-
Operational ExcellenceRead the Operational Excellence whitepaper
By isolating faults to business service partitions, this Guidance promotes operational excellence by ensuring that the business can continue to run services. This aligns fault isolation with individual users or sets of users. In contrast to the more traditional approach, which has users in the same failure domain of a single business system, this new approach has users in different failure domains.
-
SecurityRead the Security whitepaper
Any use of cryptography is kept at a minimum with the intention of it being replaced for production use. Randomly generated API keys and JSON Web tokens are used for authentication.
-
ReliabilityRead the Reliability whitepaper
This Guidance implements the Well-architected best practice of a cellular architecture.
-
Cost OptimizationRead the Cost Optimization whitepaper
To ensure cost optimization, only the smallest AWS Fargate container instance types are used. Deployment and workflows run on AWS CodeCommit and AWS Step Functions to minimize compute cost. Monitoring uses synthetic canaries that are started only when needed.
Related Content
Disclaimer
The sample code; software libraries; command line tools; proofs of concept; templates; or other related technology (including any of the foregoing that are provided by our personnel) is provided to you as AWS Content under the AWS Customer Agreement, or the relevant written agreement between you and AWS (whichever applies). You should not use this AWS Content in your production accounts, or on production or other critical data. You are responsible for testing, securing, and optimizing the AWS Content, such as sample code, as appropriate for production grade use based on your specific quality control practices and standards. Deploying AWS Content may incur AWS charges for creating or using AWS chargeable resources, such as running Amazon EC2 instances or using Amazon S3 storage.