Open marco-pace opened 1 year ago
Great feature! I was having the same issue, and your solution can resolve it. Can't wait to see it on master branch
Hi @grudge61 and thanks for submitting this PR !
These limits are indeed painful if all your workloads are hosted on the same AWS account. At later stage, you might consider splitting in multiple AWS account. This does not incur any additional costs, ensure you avoid resource collision, prevent accidental deletion and some other benefits.
In your current state, are all policies and cloudfront functions resulting from multiple uses of the website Lift construct within the same serverless service file ? If so, a preferred pattern would be the singleton pattern, used by CDK for exemple for the custom resource required to configure cloudwatch log retention period. In such pattern, only a single root resource is provisioned in the Cloudformation template to be used multiple times. Here is an exemple of such implementation : https://github.com/aws/aws-cdk/blob/main/packages/%40aws-cdk/aws-logs/lib/log-retention.ts#L127-L135
I'd be much more prone to efficiently provision resources for anyone deploying multiple website this way. WDYT ?
When you deploy a server-side website with lift it will create a new Cache policy, a new Origin request policy and a CloudFront function every time; and most of times these resources are the same.
AWS has a limit of 20 Cache policies and Origin request policies and 100 CloudFront Functions per AWS account; and these limits are not increaseble (more info here).
When you have a really huge amount of applications running in an AWS account, this can be a big limitation.
To solve this problem, one could envisage reusing these resources by specifying their IDs in the configuration of the website construct.
Example Config