這兩篇文章將介紹如何以 CloudFront整合 AWS 幾個常見服務的作法重點提示，預計包含的有以下服務:

• S3
• EC2
• ELB(Application Load Balancer)
• API G/W
• MediaPackage
• MediaTailor

本篇將先介紹前三者，話不多說，讓我們開始吧。

整合 S3 作為 Origin

對於很多人來說，整合 S3 有多種方式，以下列舉幾種較為常見的作法。
方法 1: (推薦) 直接以 OAC/OAI 掛載 S3，如有需要 OAC/OAI 也支援跨帳戶。(A 帳戶的 CloudFront 掛載 B 帳戶的 S3)。
這方法無須關閉 S3 桶(bucket level)以及您帳戶(account level)的「封鎖公開存取」(block public access)。
假設需求: A(AccountID: 1111111) 帳戶的 S3 要允許B 帳戶(Account ID: 22222222) 的 CloudFront Distribution(DistributionID: E3333333333) 透過 OAC 存取。只要修改其中 "Condition" 的判斷條件，將 arn 改為 B 的 CF Distribution 的 ARN 即可，參考樣式如下:

{
    "Version": "2008-10-17",
    "Id": "PolicyForCloudFrontPrivateContent",
    "Statement": 
        {
            "Sid": "AllowCloudFrontServicePrincipal",
            "Effect": "Allow",
            "Principal": {
                "Service": "cloudfront.amazonaws.com"
            },
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::kgg23-ironman-s3/*",
            "Condition": {
                "StringEquals": {
                    "AWS:SourceArn": "arn:aws:cloudfront::22222222:distribution/E3333333333"
                }
            }
        }
}

方法 2: 使用 Static Website Endpoint: 需要因為　Static Website Endpoint 會將訪問者視為"Anonymous"。因此，如果您要提高安全性，可以考慮透過限定 IP Range 的方式來限定只接受哪些 IP 的到訪。CloudFront 會使用的 IP 位置可以參考CloudFront 邊緣伺服器的位置和 IP 地址範圍。
這方法須要關閉 S3 桶(bucket level)以及您帳戶(account level)的「封鎖公開存取」(block public access)。
方法 3: 直接將 Bucket 公開: 如同多次報告的，非常不建議。
這方法須要關閉 S3 桶(bucket level)以及您帳戶(account level)的「封鎖公開存取」(block public access)。以及搭配使用傳統 ACL or 調整 Bucket Policy，設定為允許所有人存取。

方法 2& 3 如果沒有限制好只接受來自 CloudFront 的請求，很可能需要支付被跳過 CloudFront 直接存取 S3 時，S3 將資料傳至 Internet 所造成的 Data Transfer Out 流量費用。(依照 S3 Pricing，傳輸資料到 CloudFront 不收這筆費用)

方法 4: 透過 EC2 掛載 S3 (使用 s3fs 這類第三方軟體 或者由 AWS 推出的 Mountpoint for S3) 先掛載 S3 後再由 EC2 作為 Origin。

EC2

EC2 在 VPC 內，要讓 CloudFront 作為 Origin時，除需要確保 EC2 對外有公網連線能力外，也要注意 CloudFront 僅支持 DNS Name，以及 EC2 需要使用 EIP，避免 EC2重啟後原先的 DNS 紀錄就找不到，或者改被其它 EC2 拿去使用。
同時也建議調整 HTTP Server 的 Log 格式，增加紀錄 Header 中的 x-amz-cf-id (也就是 CloudFront 的 RequestID)，參考的 Log 格式可以如下(for Nginx)

    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$ssl_protocol '
                      '$Host '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent " "$http_x_forwarded_for" '
                      '"$http_x_amzn-trace-id"'
                      '"$http_accept_encoding" '
                      '"$http_x_amz_cf_id"';

並在你自己的 HTTP Server 設定檔中指定日誌檔紀錄時要使用這格式

        access_log /var/log/nginx/kgg23-access.log main;

如果希望進一步透過 SecurityGroup 限制僅接受來自 CloudFront 的連線，可以使用 Managed Prefixlist中的 com.amazonaws.global.cloudfront.origin-facing。
同時，CloudFront 並沒有限制 Origin 的 HTTP/HTTPS 服務一定要在 80/443 Port，可以自由選擇你要的 port (只要有設定好。)
另外，除了透過前一段提到的可以掛載 S3 外，也可以考慮掛載 EFS 服務來讓多台 EC2 共享網站會使用的內容。但，請記得 EFS 的效能是原則上跟著用量增加而提升，如果你的用量不大，直接掛載 S3 並非完全不能接受。

當然，用量不大時，用 EFS 也不會感覺慢到哪去

ELB(Application Load Balancer)

ELB 設定 TargetGroup 時，Listener 使用什麼可以依照您的實際需求，但將 traffic 轉發到 TargetGroup 可以直接使用 HTTP，不一定需要使用 HTTPS。這會讓您在後續進行封包分析時，除了 vpc flow log，還有實際封包內容可以看。(使用 tcpdump/wireshark)。
同時，為了追蹤 CF --> ALB --> EC2 的相關資訊，建議也於 EC2 的 HTTP log 中增加紀錄 ELB Trace-ID 欄位(x-amzn-trace-id)，寫法合併於 EC2 紀錄 x-amz-cf-id 的格式範例中。

ELB 同樣可以使用 Managed Prefix list來限定讓 CloudFront Origin facing通過。
另一方面，讓 CloudFront 回 Origin 時帶著 custom header 搭配 ELB 端的 RequestRouting，讓 ELB 僅轉發帶有特定標頭(以及值)的請求到後端的 TargetGrup，這將可以有效提高安全性。

如果希望做到更極致，也可以考慮讓 ELB 也搭配 WAF、Lambda 等 並自動 rotate 對應 Header，詳情可以參考這安全建議文件。

Okay，那麼前 3個服務我們先寫到這，接下來這幾天，我們繼續看後面幾組服務。