☰

AWS：如何將多個網域重新導向到另一個網域上的頁面？

tag-icon • tag-icon amazon-web-services amazon-s3 redirect amazon-cloudfront amazon-route53
AWS：如何將多個網域重新導向到另一個網域上的頁面？

我的目標

我有多個網域（例如 10 或 20），我想重定向任何訪客到任何地方在這些頁面上到另一個網域上的一個頁面（例如我的 stackoverflow.com 個人資料頁面）。

這包括

  1. 頂點域使用http（例如http://mydomain01.com）
  2. 頂點域使用https（例如https://mydomain01.com）
  3. 子網域使用http（例如http://www.mydomain01.com或http://blog.mydomain01.com）
  4. 子網域使用https（例如https://www.mydomain01.com或https://blog.mydomain01.com）
  5. 任何路徑（例如http://mydomain01.com/some_path或https://www.mydomain01.com/another/path.html）

加上我所有其他網域（mydomain02.com、mydomain03.com等；每個網域都有上述用例）。

我的研究

  1. 這篇 AWS 文章解釋如何將互聯網流量從一個頂級域重定向到另一個域（我的案例#1）這包括以上列出）使用AWS S3和AWS 路線 53：這適用於http，但不適用於https。
  2. 這篇 AWS 文章解釋瞭如何在多種情況下重定向網路流量（從外觀上看，涵蓋了我的所有案例）這包括以上列出）使用AWS S3,AWS 路線 53和AWS 雲端前：這適用於http和https。 （也討論了使用應用程式負載平衡器，但我想這超出了這裡的範圍...）
  3. 這篇 AWS 文章新增了有關設定 CloudFront 分配以及如何深入了解日誌檔案的更多詳細資訊。
  4. 這篇 AWS 文章記錄使用高級條件重定向的重定向規則：不確定我是否需要去那裡實現我的目標，所以我還沒有真正研究過這一點。

另外，顯然還有很多這樣的問題（參見有關的這個問題的右側）以及有關該主題的其他帖子；其中大多數的問題是它們使用先前版本的 AWS 控制台 UI 的螢幕截圖：大多數內容應該仍然相同，但在我看來，將這些螢幕截圖與當前 UI 相關聯又增加了一層混亂。

AWS（和其他）文件的主要要點：

  1. 我需要在AWS S3中建立一個儲存桶並在其中配置重定向，
  2. 我需要在 AWS CloudFront 中建立一個分配；
  3. 為了在 CloudFront 中使用自訂網域，我需要在 AWS ACM 中建立一個證書，
  4. 我需要在 AWS Route 53 中建立託管區域並在其中配置記錄。

到目前為止我的工作

已安裝最新的 AWS CLI，region並output在 中進行配置~/.aws/config，在 中設定憑證~/.aws/credentials（每個憑證針對每個 AWS 帳戶）；AWS_*環境變數編輯export。

我使用 AWS 區域US East (N. Virginia) (us-east-1)來處理所有事情，以防止因 AWS 資源在某個區域不可用而導致的任何其他問題。

$ aws --version
aws-cli/2.2.23 Python/3.9.6 Darwin/19.6.0 source/x86_64 prompt/off

我省略了任何 shell 提示或>shell 行繼續字符，以便更輕鬆地從本文複製到 shell 中。

設定 S3 儲存桶

警告：這將創建一個「所有公共」儲存桶，沒有任何存取限制。在這種情況下，這應該不重要，因為沒有要保護的儲存桶內容，但這種公共儲存桶通常是一種不好的做法。另外，我使用公共儲存桶來防止存取限制引起的任何其他問題：首先，讓它發揮作用；第二，確保安全。

建立儲存桶

aws s3api create-bucket --bucket mydomain01.com
  • 回覆:
{
    "Location": "/mydomain01.com"
}

設定重定向

aws s3api put-bucket-website --bucket mydomain01.com --website-configuration \
    '{ "RedirectAllRequestsTo": { "HostName": "stackoverflow.com/users/217844/ssc" } }'
  • 沒有反應

問題：S3 儲存桶名稱必須與 apex 網域名稱相符。

使用任何儲存桶名稱，但mydomain01.com（對於我的範例）似乎會失敗，並且沒有任何原因指示。 AWS 文件並沒有真正明確這一點- 事實上，我仍然不確定我是否嚴重誤解了這裡的某些內容，但據我所知，官方AWS 文件實際上在這一點上有些草率- IMO - 至關重要的關鍵點： 例如，#2只是說

  1. 建立具有全域唯一名稱的 S3 儲存桶。

這可能是任何全球唯一的名稱。#1以某種方式提到 - 一旦你知道如何閱讀這些位元...

順便說一句，第 2 篇文章仍然讓我感到困惑

如果您不使用自訂網域...

我為什麼要不是使用自訂域？重點是重定向我的自訂網域，不是嗎？好吧，無論如何…

問題：不得將協定加入主機名前面。

AWS 主控台和 AWS CLI 似乎都不會測試協定（http://或https://）是否已在主機名稱UI 欄位/傳入HostNameJSON 字串。但是，如果在前面添加一個，則重定向會失敗；看測試重定向以下。

問題：AWS S3 控制台 UI 錯誤。

設定重定向後，AWS 控制台會在其 UI 中顯示指向儲存桶 URL ( http://mydomain01.com.s3-website-us-east-1.amazonaws.com) 的可點擊連結（位於儲存桶的最底部）特性選項卡，在靜態網站託管部分。

點擊該連結無法打開該頁面，似乎是因為 AWS 控制台弄亂了 URL 並嘗試打開http://https//stackoverflow.com/users/217844/ssc/，無論協議如何。

測試重定向

  • 使用HTTPie在 shell 中而不是curlorwget因為這就是現在酷孩子們使用的
  • 將瀏覽器中 AWS 控制台的連結複製到 shell
http http://mydomain01.com.s3-website-us-east-1.amazonaws.com/
HTTP/1.1 301 Moved Permanently
Content-Length: 0
Date: Mon, 02 Aug 2021 12:39:09 GMT
Location: http://stackoverflow.com/users/217844/ssc/
Server: AmazonS3
x-amz-id-2: rakAqUMnRraGvo/WkSa6AnbuhWn/9YZX/CAlI/OJQKYoWp/OdQIbyhsvHSwNved3suwMdgglqpE=
x-amz-request-id: C5BBG833Q9TQ9J6X

--> 似乎有效

  • 如果協定被錯誤地加入到主機名稱前面，則測試重定向；請注意損壞的Location網址：
http http://mydomain01.com.s3-website-us-east-1.amazonaws.com/
HTTP/1.1 301 Moved Permanently
Content-Length: 0
Date: Mon, 02 Aug 2021 12:52:10 GMT
Location: http://https://stackoverflow.com/users/217844/ssc/
Server: AmazonS3
x-amz-id-2: Ee2/ob0faTpRdp6mGITdmClozXNmF1Q2oTbPioms8O91VA8n5VA3MoHhveeFz7v2VS65YKFKlDA=
x-amz-request-id: ZJP653R50YD5HSRS

我的問題#1

注意：當我開始寫這篇文章時，我有這些問題；我思考從那時起我就能夠自己回答這些問題（參見測試www子網域記錄以下）。如果我錯了，請有人糾正我：

  1. 問：即使我使用 CloudFront，「儲存桶名稱 == 網域」要求是否適用？
    A：是的。
  2. 問：我是否需要為頂級網域和每個子網域各建立一個儲存桶？所以，在我的例子中
    • mydomain01.com
    • www.mydomain01.com
    • blog.mydomain01.com？
      A：是的。

設定 Route 53 託管區域

建立託管區域

aws route53 create-hosted-zone --caller-reference "$(date '+%Y%m%d-%H%M%S')" --name mydomain01.com
  • 回覆
{
    "Location": "https://route53.amazonaws.com/2013-04-01/hostedzone/Z123456789EXAMPLE0SKX",
    "HostedZone": {
        "Id": "/hostedzone/Z123456789EXAMPLE0SKX",
        "Name": "mydomain01.com.",
        "CallerReference": "20210802-150736",
        "Config": {
            "PrivateZone": false
        },
        "ResourceRecordSetCount": 2
    },
    "ChangeInfo": {
        "Id": "/change/C1234567890SKXEXAMPLE",
        "Status": "PENDING",
        "SubmittedAt": "2021-08-02T13:07:37.860000+00:00"
    },
    "DelegationSet": {
        "NameServers": [
            "ns-1234.awsdns-12.com",
            "ns-5678.awsdns-34.co.uk",
            "ns-1234.awsdns-56.net",
            "ns-5678.awsdns-78.org"
        ]
    }
}
  • 記下Z123456789EXAMPLE0SKX後續步驟中所需的託管區域 ID

為頂級網域建立記錄

{
  "Changes": [
    {
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "mydomain01.com.",
        "Type": "A",
        "AliasTarget": {
          "HostedZoneId": "Z3AQBSTGFYJSTF",
          "DNSName": "s3-website-us-east-1.amazonaws.com",
          "EvaluateTargetHealth": false
        }
      }
    }
  ]
}

問題：必須逐字s3-website-us-east-1.amazonaws.com使用DNSName。

AWS 文件在各種地方都討論了example.comorexample.com.s3-website-us-east-1.amazonaws.com等。mydomain01.com.s3-website-us-east-1.amazonaws.com的逐字值桌子， IEs3-website-us-east-1.amazonaws.com。

問題：不得將協定加入主機名前面。

與上面的問題類似，AWS 控制台和 AWS CLI 都樂意接受添加http://到https://在主機名稱UI 欄位/傳遞為DNSName.至少，這看起來非常控制台中錯誤，例如http\072\057\057mydomain01.s3-website-us-east-1.amazonaws.com.

這兩個問題在 AWS 控制台中都得到了一定程度的緩解，在建立或編輯記錄時可以從下拉方塊中選擇值；使用 AWS CLI 時，您必須仔細檢查傳送的內容。

同樣的陷阱和緩解措施也適用於記錄名稱UI 欄位/ NameJSON 值。

為頂級域建立記錄（續）

  • 使用jq為了進行快速測試，臨時檔案包含有效的 json
jq . < change-batch.apex.json 1> /dev/null
  • 無輸出 --> 有效的 JSON
aws route53 change-resource-record-sets --hosted-zone-id Z123456789EXAMPLE0SKX \
    --change-batch "file://$(pwd)/change-batch.apex.json"
  • 回覆
{
    "ChangeInfo": {
        "Id": "/change/C1234567890EXAMPLESKX",
        "Status": "PENDING",
        "SubmittedAt": "2021-08-02T14:20:09.370000+00:00"
    }
}

測試頂點域記錄

  • 測試http
http http://mydomain01.com
HTTP/1.1 301 Moved Permanently
Content-Length: 0
Date: Mon, 02 Aug 2021 15:06:08 GMT
Location: http://stackoverflow.com/users/217844/ssc/
Server: AmazonS3
x-amz-id-2: EfDtCxif2iV4eInskirSBAOjQS7o9arzJCeZjscF6mW7cwwmm9Nxb7QJT50x2kjdslX2fOxA+lk=
x-amz-request-id: WM7K9TDEF75A6P1V

--> 看起來不錯

  • http用路徑測試
http http://mydomain01.com/some/path
 ... similar output as above ...
  • 測試https
http https://mydomain01.com

http: error: ConnectionError: HTTPSConnectionPool(host='mydomain01.com', port=443):
  Max retries exceeded with url: / (Caused by NewConnectionError('<urllib3.connection.HTTPSConnection object at 0x101a48100>:
    Failed to establish a new connection: [Errno 60] Operation timed out')) while doing a GET request to URL: https://mydomain01.com/
  • （為了可讀性，將響應包裝起來）

--> 逾時（60 秒後？） - 如預期：使用 S3 儲存桶進行重定向不起作用https（請參閱上文）

問題：DNS 更改傳播延遲。

AWS 和谷歌是非常就傳播 DNS 設定變更而言速度很快（如以秒或分鐘為單位），但可能涉及其他「較慢」的名稱伺服器。按照描述繞過它們這裡消除這種混亂的根源。此方法僅適用於 macOS，但該概念對於任何作業系統都是相同的。

問題：瀏覽器快取。

當不在 shell 中而是在瀏覽器中測試 DNS 變更時，瀏覽器可能會從其快取中取得結果。我的大部分工作都使用 Chrome 完成，但使用 Firefox（或 Safari）進行測試，因此我可以在每次測試之前清除整個緩存，以消除潛在的問題 - 無需退出 Google、AWS 等。

www為子網域建立記錄

  • 唯一的差別是NameJSON 值
sed -e 's|mydomain01.com.|www.mydomain01.com.|g' change-batch.apex.json > change-batch.www.json
aws route53 change-resource-record-sets --hosted-zone-id Z123456789EXAMPLE0SKX \
    --change-batch "file://$(pwd)/change-batch.www.json
  • 響應與上方類似

測試www子網域記錄

  • 測試http
http http://www.mydomain01.com
HTTP/1.1 404 Not Found
Content-Length: 363
Content-Type: text/html; charset=utf-8
Date: Mon, 02 Aug 2021 15:28:05 GMT
Server: AmazonS3
x-amz-id-2: MGLcynq1iEGKh+pT6N6iRpCuQSN243q/5zm2Y7rXTnM7iW9nvDokF6s20xEUBr7QiEtBPEzZmII=
x-amz-request-id: TK83G35EMYFR8SKX

<html>
<head><title>404 Not Found</title></head>
<body>
<h1>404 Not Found</h1>
<ul>
<li>Code: NoSuchBucket</li>
<li>Message: The specified bucket does not exist</li>
<li>BucketName: www.mydomain01.com</li>
<li>RequestId: TK83G35EMYFR8SKX</li>
<li>HostId: MGLcynq1iEGKh+pT6N6iRpCuQSN243q/5zm2Y7rXTnM7iW9nvDokF6s20xEUBr7QiEtBPEzZmII=</li>
</ul>
<hr/>
</body>
</html>
  • 我認為這回答了第二個我的問題#1上圖：我需要每個頂點/子網域一個 S3 儲存桶來轉送。

設定 CloudFront 分配

  • 注意：AWS 控制台讓操作變得非常容易索取證書並使用 DNS 進行驗證。

建立證書

  • AWS ACMrequest-certificate文檔
  • 該憑證應該適用於頂點和所有子網域，因此需要向該證書新增另一個名稱/ 經過--subject-alternative-names;看這篇 AWS 文章（上面的藍色框）。
  • 加上引號，*.mydomain01.com這樣 shell 就不會解釋*
aws acm request-certificate --domain-name mydomain01.com --validation-method DNS \
    --subject-alternative-names '*.mydomain01.com'
  • 回覆:
{
    "CertificateArn": "arn:aws:acm:us-east-1:123456789012:certificate/12345678-90ab-cdef-1234-1234567890ab"
}
  • 123456789012是我的 AWS 帳號 ID；之後的所有內容certificate/都只是一個 UUID

獲取證書詳細信息

  • AWS ACMdescribe-certificate文檔
  • 將回應儲存到臨時本地文件；提取ResourceRecord.Name並ResourceRecord.Value使用jq
  • 證明我擁有 AWS Route 53 記錄所需mydomain01.com
  • 或者，使用--query參數aws acm describe-certificate
aws acm describe-certificate \
    --certificate-arn "arn:aws:acm:us-east-1:123456789012:certificate/12345678-90ab-cdef-1234-1234567890ab" \
 > describe-certificate.json

jq -r '.Certificate.DomainValidationOptions[0].ResourceRecord.Name' describe-certificate.json
_1234567890abcdef1234567890abcdef.mydomain01.com.

jq -r '.Certificate.DomainValidationOptions[0].ResourceRecord.Value' describe-certificate.json 
_1234567890abcdef1234567890abcdef.weirdchars.acm-validations.aws.

建立用於憑證驗證的 Route 53 記錄

  • 將由 AWS ACM 自動檢查，一旦找到此記錄，憑證將得到驗證
  • 和以前一樣，使用臨時本地文件change-batch.cert.json，參見例如為頂級網域建立記錄;內容：
{
  "Changes": [
    {
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "_1234567890abcdef1234567890abcdef.mydomain01.com.",
        "Type": "CNAME",
        "TTL": 300,
        "ResourceRecords": [
          {
            "Value": "_1234567890abcdef1234567890abcdef.weirdchars.acm-validations.aws."
          }
        ]
      }
    }
  ]
}
  • 外殼命令：
aws route53 change-resource-record-sets --hosted-zone-id Z123456789EXAMPLE0SKX \
    --change-batch "file://$(pwd)/change-batch.cert.json
  • 回應類似於上面建立記錄時的回應
  • 注意：ACM 可能需要幾分鐘時間來驗證憑證。

建立 CloudFront 分配

  • AWS CloudFrontcreate-distribution文檔
  • 再次強調，CallerReference必須是一個唯一的字串；在 shell 中使用例如date '+%Y%m%d-%H%M%S'建立並複製到文件中；看建立託管區域
  • create-distribution.json和以前一樣，對複雜值使用臨時本地文件；以下內容
  • MinimumProtocolVersion: 從中獲取價值這篇 AWS 文章
  • OriginProtocolPolicy：使用是http-only因為來源（S3 儲存桶）只能做http
  • ViewerProtocolPolicy：redirect-to-https建立此發行版的全部目的是從重定向http到https
  • 注意：我不知道（AWS 文件也沒有告訴）哪些欄位是強制必需的；如果傳送的資料遺失或錯誤，AWS CLI 指令會顯示清晰詳細的訊息。
{
    "CallerReference": "20210802-191725",
    "Aliases": {
        "Quantity": 2,
        "Items": ["mydomain01.com", "*.mydomain01.com"]
    },
    "Origins": {
        "Quantity": 1,
        "Items": [
            {
                "Id": "mydomain01.com.s3.us-east-1.amazonaws.com_20210802-191725",
                "DomainName": "mydomain01.com.s3.us-east-1.amazonaws.com",
                "CustomOriginConfig": {
                    "HTTPPort": 80,
                    "HTTPSPort": 443,
                    "OriginProtocolPolicy": "http-only"
                }
            }
        ]
    },
    "OriginGroups": {
        "Quantity": 0
    },
    "DefaultCacheBehavior": {
        "TargetOriginId": "mydomain01.com.s3.us-east-1.amazonaws.com_20210802-191725",
        "ForwardedValues": {
            "QueryString": false,
            "Cookies": {
                "Forward": "none"
            },
            "Headers": {
                "Quantity": 0
            },
            "QueryStringCacheKeys": {
                "Quantity": 0
            }
        },
        "TrustedSigners": {
            "Enabled": false,
            "Quantity": 0
        },
        "ViewerProtocolPolicy": "redirect-to-https",
        "MinTTL": 0,
        "AllowedMethods": {
            "Quantity": 2,
            "Items": [
                "HEAD",
                "GET"
            ],
            "CachedMethods": {
                "Quantity": 2,
                "Items": [
                    "HEAD",
                    "GET"
                ]
            }
        },
        "SmoothStreaming": false,
        "DefaultTTL": 86400,
        "MaxTTL": 31536000,
        "Compress": false,
        "LambdaFunctionAssociations": {
            "Quantity": 0
        },
        "FieldLevelEncryptionId": ""
    },
    "CacheBehaviors": {
        "Quantity": 0
    },
    "CustomErrorResponses": {
        "Quantity": 0
    },
    "Comment": "",
    "Logging": {
        "Enabled": false,
        "IncludeCookies": false,
        "Bucket": "",
        "Prefix": ""
    },
    "PriceClass": "PriceClass_All",
    "Enabled": true,
    "ViewerCertificate": {
        "ACMCertificateArn": "arn:aws:acm:us-east-1:123456789012:certificate/12345678-90ab-cdef-1234-1234567890ab",
        "MinimumProtocolVersion": "TLSv1.2_2021",
        "SSLSupportMethod": "sni-only"
    },
    "Restrictions": {
        "GeoRestriction": {
            "RestrictionType": "none",
            "Quantity": 0
        }
    },
    "WebACLId": "",
    "HttpVersion": "http2",
    "IsIPV6Enabled": true
}
  • 外殼命令：
  • 注意：新增--no-cli-pager以停用分頁並將回應儲存在臨時本機檔案中以供檢查
aws --no-cli-pager cloudfront create-distribution \
    --distribution-config "file://$(pwd)/create-distribution.json"
 > create-distribution.response.json
  • 回應：一個大型 JSON 結構，主要是與一些分發元資訊一起發送的配置

問題：CloudFront 分發需要一些時間來部署。

在裡面發行版概述，有一個上一次更改字段說部署每次改變後都會持續一段時間；根據螢幕和瀏覽器視窗寬度，此欄位可能會隱藏，因此 UI 可能看起來分佈已啟動並正在運行，但實際上並非如此。

測試分佈

  • DomainName從回應中獲取
jq -r '.Distribution.DomainName' create-distribution.response.json
abcdefghij1234.cloudfront.net
  • 測試http
http http://abcdefghij1234.cloudfront.net
HTTP/1.1 301 Moved Permanently
Connection: keep-alive
Content-Length: 183
Content-Type: text/html
Date: Mon, 02 Aug 2021 20:14:27 GMT
Location: https://abcdefghij1234.cloudfront.net/
Server: CloudFront
Via: 1.1 8640a37b586353bc916562c577770223.cloudfront.net (CloudFront)
X-Amz-Cf-Id: ooT0Y1QvDE7_yoRmb0p0Un2Db6O713rBvudtmz1xer7YwEU0GE8smw==
X-Amz-Cf-Pop: HAM50-C2
X-Cache: Redirect from cloudfront

<html>
<head><title>301 Moved Permanently</title></head>
<body bgcolor="white">
<center><h1>301 Moved Permanently</h1></center>
<hr><center>CloudFront</center>
</body>
</html>

因此，分發版從 - 重定向http://abcdefghij1234.cloudfront.net到https://abcdefghij1234.cloudfront.net- 正如它應該的那樣；這就是它被創建的目的。

  • 測試https
HTTP/1.1 403 Forbidden
Connection: keep-alive
Content-Type: application/xml
Date: Mon, 02 Aug 2021 20:14:35 GMT
Server: AmazonS3
Transfer-Encoding: chunked
Via: 1.1 c3e656776c8a9f0e1ea24405ab1dcc85.cloudfront.net (CloudFront)
X-Amz-Cf-Id: or4SC8urWEv_8c3jDURv5IINwFU1TDVLSQ3_X7tya7Ncz8ujyz0-IQ==
X-Amz-Cf-Pop: HAM50-C2
X-Cache: Error from cloudfront
x-amz-bucket-region: us-east-1

<?xml version="1.0" encoding="UTF-8"?>
<Error>
  <Code>AccessDenied</Code>
  <Message>Access Denied</Message>
  <RequestId>EAST1CM5WJR8QM3S</RequestId>
  <HostId>zF2dJm2vsuSM633NHuzcA5VqrCrNkfYGu31FRmKKIkebuI5+6l5DlVnr4kk9be262hcqktoiROw=</HostId>
</Error>
  • （為方便閱讀而格式化的 xml）

那看起來不太好。不確定這是否是預期的？

更新 AWS Route 53 記錄

  • 從使用 S3 儲存桶變更為使用 CloudFront 分配
  • change-batch.apex.updatejson和以前一樣，透過seding 較早的文件建立一個臨時本機文件change-batch.apex.json
  • 使用UPSERT而不是CREATE：記錄已存在並且必須更新。
  • HostedZoneId：用 替換舊值Z3AQBSTGFYJSTF（對於 S3）Z2FDTNDATAQYW2，一些魔法值取自change-resource-record-sets文件
  • DNSName: 引自change-resource-record-sets文件

指定您建立指派時 CloudFront 指派的網域名稱。

您的 CloudFront 指派必須包含與資源記錄集名稱相符的備用網域名稱。例如，如果資源記錄集的名稱是 acme.example.com，您的 CloudFront 分配必須包含 acme.example.com 作為備用網域之一。

--> 將s3-website-us-east-1.amazonaws.com（對於 S3）替換為abcdefghij1234.cloudfront.net：

sed -e 's|CREATE|UPSERT|g' \
    -e 's|Z3AQBSTGFYJSTF|Z2FDTNDATAQYW2|g' \
    -e 's|s3-website-us-east-1.amazonaws.com|abcdefghij1234.cloudfront.net|g' \
    change-batch.apex.json > change-batch.apex.update.json
  • 文件內容：
{
  "Changes": [
    {
      "Action": "UPSERT",
      "ResourceRecordSet": {
        "Name": "mydomain01.com.",
        "Type": "A",
        "AliasTarget": {
          "HostedZoneId": "Z2FDTNDATAQYW2",
          "DNSName": "abcdefghij1234.cloudfront.net",
          "EvaluateTargetHealth": false
        }
      }
    }
  ]
}
  • 外殼命令
aws route53 change-resource-record-sets \
    --hosted-zone-id Z123456789EXAMPLE0SKX \
    --change-batch "file://$(pwd)/change-batch.apex.update.json"
  • 回應類似於上面建立記錄時的回應

測試頂點域記錄

  • 測試http
http http://mydomain01.com
HTTP/1.1 301 Moved Permanently
Connection: keep-alive
Content-Length: 183
Content-Type: text/html
Date: Mon, 02 Aug 2021 19:08:27 GMT
Location: https://mydomain01.com/
Server: CloudFront
Via: 1.1 2408979685aa1bdb752824d292e63bf7.cloudfront.net (CloudFront)
X-Amz-Cf-Id: Ww60Ol_0fdR8SsgcHeRYUd_de1rVejX6w_wuK80aR21e3IHstB-irA==
X-Amz-Cf-Pop: HAM50-C2
X-Cache: Redirect from cloudfront

<html>
<head><title>301 Moved Permanently</title></head>
<body bgcolor="white">
<center><h1>301 Moved Permanently</h1></center>
<hr><center>CloudFront</center>
</body>
</html>
  • 回應現在來自 CloudFront 而不再來自 S3，因此更新後的 DNS 記錄似乎有效:-)
  • http用路徑測試
http http://mydomain01.com/some/path
 ... similar output as above ...

--> 看起來不錯

  • 測試https
http https://mydomain01.com
HTTP/1.1 403 Forbidden
Connection: keep-alive
Content-Type: application/xml
Date: Mon, 02 Aug 2021 18:53:51 GMT
Server: AmazonS3
Transfer-Encoding: chunked
Via: 1.1 ea89c67081222c8c680e7a37ad75f4f0.cloudfront.net (CloudFront)
X-Amz-Cf-Id: 5prv5_g5zXOX3aRBp2Gq64JJPuwC2o5dHIp9RCAHm6Ls8hK6EFghXw==
X-Amz-Cf-Pop: HAM50-C2
X-Cache: Error from cloudfront
x-amz-bucket-region: us-east-1

<?xml version="1.0" encoding="UTF-8"?>
<Error>
  <Code>AccessDenied</Code>
  <Message>Access Denied</Message>
  <RequestId>T78ASF3FA9QGV4T5</RequestId>
  <HostId>xaEgwEtbeesL4XfxMdxVoPAt9Lpb1ZDM9Fs5W4htBbcWNbV9sMUTjVAPIuWwAQ3Xh1yRhh4b4Ts=</HostId>
</Error>
  • （和以前一樣，為了方便閱讀，XML 被格式化）

注意：此響應來自AmazonS3，而不是CloudFront前一個響應。 S3 儲存桶沒有任何存取限制 - 那麼怎麼可能存在拒絕訪問？

仔細檢查儲存桶權限

aws s3api get-bucket-policy --bucket mydomain01.com

An error occurred (NoSuchBucketPolicy) when calling the GetBucketPolicy operation: The bucket policy does not exist

與空匹配桶政策AWS S3 控制台中的欄位 - 但是根本沒有儲存桶策略真的可以嗎？

現在回頭看測試分佈上面，我看到直接存取的回應abcdefghij1234.cloudfront.net也來自S3，而不是來自CloudFront，所以問題似乎很清楚：

我的問題#2

  1. 為什麼 S3 儲存桶拒絕存取？
  2. S3 儲存桶根本沒有存取策略正常嗎？通常沒有明確允許任何人存取的「公共」儲存桶策略嗎？
  3. 如同每個頂點/子域一個 S3 儲存桶，我是否還需要每個頂點/子網域一個 CloudFront 分配？
  4. 如果是這樣，我想*.mydomain01.com將備用網域添加到憑證（和分發）中並沒有任何意義，不是嗎？我還需要每個發行版一張專用於一個網域的證書，對嗎？

答案1

總的來說，你走在正確的軌道上。僅限一則評論：如果您的網域已使用其他 DNS 服務供應商，則可以省略 Route53。

Q：即使我使用 CloudFront，「儲存桶名稱 == 網域」要求也適用嗎？

不，如果您使用 CloudFront。 CNAME 在 CloudFront 中單獨配置。

Q：我是否需要為頂級網域和每個子網域各建立一個儲存桶？

不，您不需要每個網域/子網域一個儲存桶。

為什麼 S3 儲存桶拒絕存取？

您應該使用您的s3-website-us-east-1.amazonaws.com網域作為 CF 來源。

S3 儲存桶根本沒有存取策略正常嗎？通常沒有明確允許任何人存取的「公共」儲存桶策略嗎？

如果您僅使用儲存桶來重定向流量，則沒有存取策略應該沒問題。

與每個頂點/子網域一個 S3 儲存桶類似，我是否還需要每個頂點/子網域一個 CloudFront 分配？

是的，每個網域/子網域需要一個 CloudFront 分配，因為一個分配最多可以附加一個 ACM 憑證。

如果是這樣，我想*.mydomain01.com將備用網域添加到憑證（和分發）中並沒有任何意義，不是嗎？我還需要每個發行版一張專用於一個網域的證書，對嗎？

新增通配符域確實有意義，因為 CF 發行版也需要處理子網域流量。

如果您還有其他疑問，請加入AWS 聊天並在聊天中@我。

相關內容