在S3，CloudFront和Route53中部署Web应用程序的最佳实践

Question

我在S3中部署了一个静态Web应用程序（SPA），并使用CloudFront为应用程序提供服务，并使用Route53路由该域。现在，我希望Route53和CloudFront在其各自的高速缓存中具有最大的TTL。有这样的similar question，但已经过时。

我的问题：

1. 是否CloudFront的缓存设置为1年（365天）是好的，当任何新的更新到S3时，我们可以使用API​​缓存失效或安慰？

2. 假设别名记录不经常改变的Route53 NS缓存设置为2天（48小时）是正确的？如果我们必须改变，那么我们是否需要保持谨慎并等待2天才能反映出来。

我认为将Route53和CloudFront缓存设置为最大值会给用户带来最佳体验（低延迟）。如果我错了，请纠正我。

Answer 1

Q1：如果您非常确定您的对象的寿命很长，那么使用CloudFront缓存可能会持续1年。您可以使用Web控制台始终无效的对象或通过使用脚本是这样的：

#!/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" 

请注意，如果您需要失效，那么你就不能invalide用户的浏览器缓存。所以我只会选择像文件那样的高级设置，其中我绝对肯定他们不会改变（例如，视频）。

我发现根据Google的建议选择我的缓存时间非常有用。你会find some input here。但是，我不会很难缓存一个SPA：我会假设你经常会在那里发生变化。

Q2：我认为将Route 53 TTL设置为更高数字是最佳做法。请记住，您无法如此快速地切换DNS。通常在DNS切换之前，请提前几天将TTL降低到较低的数字。由于您使用的是AWS，对于Alias-Resources，这应该不会成为一个问题，因为DNS交换机没有麻烦。

一般来说，我同意你的方法。你牺牲了一些灵活性，但它通常是值得的。