Enterprise Cloud Architectural Patterns — Part2
Our previous article examined two cloud enterprise architectural patterns: Centralized Hybrid DNS Management and Centralized User Access. Another challenging problem enterprises face when running cloud workloads is geo-distributed applications. Providing a low latency and consistent experience to customers across the globe while maintaining compliance and data residency requirements requires careful evaluation of technology choices and making the right trade-offs. This article provides a few use cases and common architecture patterns to enable these applications.
Geo-distributed Applications
We must define the access points and data layout when designing for geo-distributed applications. In determining these, there are a lot of factors to consider, a few of which are listed below:
- Location of users
- Application data access patterns
- Read consistency and data freshness requirements
- Data locality requirements
- Latency and cost requirements
- Disaster recovery, failover SLAs: RTO and RPO
- Transactional write guarantees
- Data mobility requirements
It is important to run a comprehensive analysis and validate the design against all applicable criteria for your use case. For this article, we are only considering a subset of these as we outline the patterns for a few common scenarios below.
Scenario 1: Static Content
Let's start with a use case where you have static data and must enforce primary access to the buckets in regions based on users' locations. It should also ensure there is a failover path. To achieve this, we provide an active-active configuration for static content in S3 buckets distributed to edge locations via CloudFront served from multiple origins. A lambda edge function decides the mapped primary origin for the user. The cache behavior configuration defines the failover origin to redirect the calls to the healthy region that can serve the content for the user.
Scenario 2: Geo-aware API Access
In our next use case, we have an application that requires strict "local data access." Users should be routed to the deployment in their region for API requests. We are using the Route 53 geolocation routing policy to achieve this requirement. This policy works by mapping the user's or DNS resolver's IP addresses (depending on EDNS0 support) to the locations. Route 53 records define the resolution between location and destination IP addresses. Below, users resolving from the US will be routed to API GW in region us-east-1. Lambda integration of API GW only has access to the data in this region; for compliance reasons, cross-region data access or replication is not allowed.
Scenario 3: Global Data Layout
In this scenario, we need to provide global access to dynamic data with eventually consistent reads.
Note that none of the managed data solutions in AWS provides cross-region synchronous write replication for strong consistency requirements, as this would add high latency to the writes. In AWS, both DynamoDB and Aurora global options provide eventual consistency with asynchronous replications. The Aurora Global database with write forwarding also provides a “read-after-write” consistency for secondary regions at the expense of latency.
For our use case, we will use DynamoDB Global tables and Aurora global database for NoSQL and SQL stores, respectively.
In the case of Global DynamoDB tables, reads and writes can happen in any region, and writes asynchronously get replicated. This can cause conflicts; DynamoDB global tables resolve with the last writer wins reconciliation.
In the case of the Aurora Global database, the writes can happen only in the primary region. Readers in the secondary can receive write requests and forward them to the primary region if "write forwarding" is enabled. The replication happens only from the primary region to the secondary regions asynchronously at the storage layer.
Recap
This article looked into considerations for geo-distributed applications and cloud design patterns to satisfy requirements for a few scenarios. We hope you find this article helpful.
