I have a static web app(SPA) deployed in S3 and I am serving the app using CloudFront and routing the domain using Route53. Now, I want the Route53 and cloudFront to have maximum TTL in their respective caches. There is a similar question like this, but it is out-dated.
My questions:
Does setting the CloudFront cache to one year(365 days) is good and when any new updates to S3 occurs, we can invalidate the cache using the API or console?
Assuming that the Alias record does not change often, setting the Route53 NS cache to 2 days(48 hours) is correct? If we have to change, then do we need to be pre-cautious and wait for 2 days to reflect.
I believe that setting the Route53 and CloudFront cache to maximum will give the best experience(Low latency) to the users. Please correct me If am wrong.
Q1: if you are pretty sure your object does live that long, then it might be OK to use the CloudFront cache for 1 year. You can always invalidate your objects using the Web console or by using a script like this:
#!/bin/sh
aws configure set preview.cloudfront true
INVALIDATION_ID=$(date +"%S")
INVALIDATION_JSON="{
\"DistributionId\": \"<YOUR_DISTRIBUTION_ID>\",
\"InvalidationBatch\": {
\"Paths\": {
\"Quantity\": 1,
\"Items\": [
\"/*\"
]
},
\"CallerReference\": \"$INVALIDATION_ID\"
}
}"
aws cloudfront create-invalidation --cli-input-json "$INVALIDATION_JSON"
Please note, if you need to invalidate, then you CANNOT invalide the users browser cache. So I would only choose a high setting like that for files, of which I am absolutely certain they won't change (in example, Videos).
I found it useful to chose my cache time according to what Google recommends. You'll find some input here.
However, I would not cache an SPA so hard: you will have changes pretty often there, I assume.
Q2: I think it is general best practice to put Route 53 TTL to a higher number. Just remember you cannot switch DNS so fast then. Usually before a DNS switch, just lower the TTL to a lower number a few days in advance. As you are using AWS, with Alias-Resources this should not be a problem that much, the DNS switches are done without hassle.
Generally speaking, I agree with your approach. You sacrifice some flexibility, but it's usually worth it.