KACLS relies on AWS configured using an active-active multi-region serverless architecture, specifically the ALB -> Lambda Target serverless pattern for lowest processing latencies. Encryption is done using KMS with the newer Multi-Region key replicas. Storage via DynamoDb multi-region Global Tables. All infrastructure is defined via AWS CDK v2 Infrastructure as Code.
Only cross regional dependencies are SSM paramaters stored in us-east-1 for communicating DNS Hosted Zone information, and KMS Primary Key information. A us-east-1 outage would prevent deployments during the outage, but not disrupt the service from running fully in other regions.
Aside from the SSM paramaters used to shuttle us-east-1 ARN values out to other regions, all resources are deployed within their own region, and dependencies should be constrained to the region, in the event a region is unavailable, available regions should continue operations, with impacted traffic getting sent to available regions via Route53's latency routing policy.
This might make some resources redundant, namely ACM Certificates or WAF WebACLs, but it offers a clean separation of resource dependencies, in the event of an outage, at the expense of greater operational cost.
There are probably many ways to improve the CDK deployment described below, but I wanted the ability to control how stacks were deployed in each region, so most stacks that depend on other stacks, do so via CFN export/import, rather than passing TS values. From my experience this loose coupling means more orchestrating at deployment time, but provides better flexibility to make changes later.
Generally deployments should go out to us-east-1 first, given AWS' dependency on some components being deployed to us-east-1 first, namely as Route53 Hosted Zone and KMS' Primary Keys.
Deploy the DNS zone in us-east-1
cdk deploy KaclsDomainUsEast1Stack
After completing open the AWS web console and navigate to the zone in AWS Route 53, locate 4 NS records and add them to your DNS registrar's list of nameservers for your domain name. THis might take a while to propagate through the internet.
Then deploy to us-west-2, depends on KaclsDomainUsEast1Stack.
This does not deploy any DNS resources, but does make the hostedZoneID, the hostedZoneARN, and zoneName available in the region as CloudFormation exports
cdk deploy KaclsDomainUsWest2Stack
Deploy the TLS Certs to ACM. First to us-east-1
cdk deploy KaclsCertUsEast1Stack
And again to us-west-2, as we want the regions to be as independent as possible.
cdk deploy KaclsCertUsWest2Stack
Deploy the primary encryption key to us-east-1
cdk deploy KaclsEncKeyUsEast1Stack
And then a key replica to us-west-2
cdk deploy KaclsEncKeyUsWest2Stack
Deploy the VPC needed by the ALB, fist in us-east-1
cdk deploy KaclsVpcUsEast1Stack
Deploy to us-west-2
cdk deploy KaclsVpcUsWest2Stack
Deploy the WebACL for the WAF to us-east-1
cdk deploy KaclsWafUsEast1Stack
And then again to us-west-2
cdk deploy KaclsWafUsWes2Stack
Deploy the Application Load Balancer (ALBv2) to us-east-1
cdk deploy KaclsAlbUsEast1Stack
And then again to us-west-2
cdk deploy KaclsAlbUsWest2Stack
Finally, deploy the API to us-east-1
cdk deploy KaclsApiUsEast1Stack
And then again to us-west-2
cdk deploy KaclsApiUsWest2Stack
...
This is a blank project for CDK development with TypeScript.
The cdk.json file tells the CDK Toolkit how to execute your app.
npm run buildcompile typescript to jsnpm run watchwatch for changes and compilenpm run testperform the jest unit testscdk deploydeploy this stack to your default AWS account/regioncdk diffcompare deployed stack with current statecdk synthemits the synthesized CloudFormation template