-
Notifications
You must be signed in to change notification settings - Fork 1.5k
Description
Community Note
- Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
- Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request
- If you are interested in working on this issue or have submitted a pull request, please leave a comment
A blueprint based on this blog - https://aws.amazon.com/blogs/containers/life360s-journey-to-a-multi-cluster-amazon-eks-architecture-to-improve-resiliency/
What is the outcome that you are trying to reach?
Blueprint to improve resiliency and reduce data transfer costs for Amazon EKS workloads
Describe the solution you would like
This bulkhead architecture approach uses cells to ensure a failure in one cell doesn't affect others. This approach reduces inter-AZ data transfer costs, improve EKS application availability and resilience against AZ-wide failures. This design moves away from a multi-AZ Amazon EKS cluster solution, to a single AZ Amazon EKS cluster solution, with multiple Amazon EKS clusters per Region within each AZ. This essentially turns each Amazon EKS cluster into a cell in the bulkhead pattern. These individual single AZ Amazon EKS clusters are called as cells, and the aggregation of cells in each region a supercell.