在S3，cloudFront和Route53中部署Web应用程序时的最佳实践[关闭]

提问于 2024-05-08T22:44:42+08:00

浏览次

-1

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

我的问题：

将 CloudFront cache 设置为 one year(365 days) 是否正常，当S3发生任何新更新时，我们可以使用API或控制台使缓存无效？
假设Alias记录不经常更改，将 Route53 NS缓存设置为 2 days(48 hours) 是否正确？如果我们必须改变，那么我们需要保持谨慎并等待2天才能反映出来 .

我相信将Route53和CloudFront缓存设置为最大值将为用户提供最佳体验（低延迟） . 请纠正我如果错了 .

1 回答

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"
```
请注意，如果您需要使其无效，则无法使用户浏览器缓存失效 . 所以我只会为文件选择一个高设置，我绝对肯定他们不会改变（例如，视频） .

我发现根据Google建议的选择我的缓存时间很有用 . 你会find some input here .

但是，我不会如此努力地缓存SPA：我假设你经常会有变化 .

Q2: 我认为将Route 53 TTL设置为更高的数字是一般的最佳做法 . 只记得你不能那么快地切换DNS . 通常在DNS切换之前，只需提前几天将TTL降低到较低的数字 . 当您使用AWS时，使用Alias-Resources这不应该是一个问题，DNS交换机没有麻烦 .

一般来说，我同意你的方法 . 你牺牲了一些灵活性，但它通常是值得的 .
回复于 2024-05-08T22:44:42+08:00

相关问题