ablog

不器用で落着きのない技術者のメモ

04. CloudFront 経由で Amazon S3 でホストされた静的ウェブサイトを公開する

CloudFront の設定

  • マネジメントコンソールで CloudFront にアクセスする。
  • [Create Distribution] をクリック、[Get Started] をクリック、以下の通り入力し、[Create Distribution] をクリック。
    • Origin Domain Name: portfolio.yoheia.com.s3.amazonaws.com
    • Origin ID: S3-portfolio.yoheia.com
    • Origin Custom Headers
      • Header Name: Referer
      • Value: 119a46ec6677cfb90e1704250a5db941 ※任意の文字列
  • SSL Certificate: Default CloudFront Certificate (*.cloudfront.net)
  • Default Root Object: index.html

S3 バケットの設定

{
    "Version": "2012-10-17",
    "Id": "CloudFront",
    "Statement": [
        {
            "Sid": "Allow get requests originating from Cloudfront.",
            "Effect": "Allow",
            "Principal": "*",
            "Action": [
                "s3:GetObject",
                "s3:GetObjectVersion"
            ],
            "Resource": "arn:aws:s3:::portfolio.yoheia.com/*",
            "Condition": {
                "StringLike": {
                    "aws:Referer": "119a46ec6677cfb90e1704250a5db941" ★ CloudFront で設定した RefererValue 
                }
            }
        }
    ]
}

参考

Amazon S3 でホストされている静的ウェブサイトを公開するには、次のいずれかの設定を使用して CloudFront ディストリビューションをデプロイできます。

  • アクセスがオリジンアクセスアイデンティティ (OAI) で制限されたオリジンとして、REST API エンドポイントを使用する
  • 匿名 (パブリック) アクセスを許可して、ウェブサイトのエンドポイントをオリジンとして使用する
  • アクセスが Referer ヘッダーで制限されたオリジンとして、ウェブサイトのエンドポイントを使用する
  • AWS CloudFormation を使用して REST API エンドポイントをオリジンとしてデプロイし、OAI と CloudFront を指すカスタムドメインによってアクセスを制限する

2 つのエンドポイントタイプの詳細については、ウェブサイトエンドポイントと REST API エンドポイントの主な相違点を参照してください。

CloudFront を使用して Amazon S3 でホストされた静的ウェブサイトを公開する
Key difference REST API endpoint Website endpoint
Access control Supports both public and private content Supports only publicly readable content
Error message handling Returns an XML-formatted error response Returns an HTML document
Redirection support Not applicable Supports both object-level and bucket-level redirects
Requests supported Supports all bucket and object operations Supports only GET and HEAD requests on objects
Responses to GET and HEAD requests at the root of a bucket Returns a list of the object keys in the bucket Returns the index document that is specified in the website configuration
Secure Sockets Layer (SSL) support Supports SSL connections Does not support SSL connections
Website endpoints - Amazon Simple Storage Service

Restricting Access to a Specific HTTP Referer
Suppose that you have a website with a domain name (www.example.com or example.com) with links to photos and videos stored in your Amazon S3 bucket, DOC-EXAMPLE-BUCKET. By default, all the Amazon S3 resources are private, so only the AWS account that created the resources can access them. To allow read access to these objects from your website, you can add a bucket policy that allows s3:GetObject permission with a condition, using the aws:Referer key, that the get request must originate from specific webpages. The following policy specifies the StringLike condition with the aws:Referer condition key.

{
  "Version":"2012-10-17",
  "Id":"http referer policy example",
  "Statement":[
    {
      "Sid":"Allow get requests originating from www.example.com and example.com.",
      "Effect":"Allow",
      "Principal":"*",
      "Action":["s3:GetObject","s3:GetObjectVersion"],
      "Resource":"arn:aws:s3:::DOC-EXAMPLE-BUCKET/*",
      "Condition":{
        "StringLike":{"aws:Referer":["http://www.example.com/*","http://example.com/*"]}
      }
    }
  ]
}
Bucket Policy Examples - Amazon Simple Storage Service

03. 独自ドメインで S3 の静的ウェブサイトホスティングを公開する

設定

  • マネジメントコンソールで作成したドメイン名(yoheia.com)をクリックする。

f:id:yohei-a:20210117162941p:plain

  • [レコードを作成] をクリックする。

f:id:yohei-a:20210117162946p:plain

f:id:yohei-a:20210117162953p:plain

確認

02. Route 53 で独自ドメインを取得する

Route 53 でのドメイン登録すると15分ほどで完了して使えるようになった。

  • マネジメントコンソールで Route 53 にアクセスする。

f:id:yohei-a:20210117152811p:plain

f:id:yohei-a:20210117150303p:plain

  • 連携先を入力する。

f:id:yohei-a:20210117151618p:plain

  • 入力情報を確認して、注文を完了する。

f:id:yohei-a:20210117151623p:plain

  • 入力したメールアドレスに確認メールが届くので、

f:id:yohei-a:20210117152021p:plain

  • リンクをクリックして verification を完了する。

f:id:yohei-a:20210117152227p:plain

f:id:yohei-a:20210117153505p:plain

01. Amazon S3 でウェブサイトを公開する

アカウントレベルの設定
  • アカウントレベルで S3 のブロックパブリックアクセスをオフに設定する。
S3 バケットの作成と設定
コンテンツを S3 にアップロード・公開
  • S3 バケット portfolio.yoheia.com の直下に GitHub - yoheia/yoheia.github.io at gh-pages のファイルをアップロードする。
  • アップロードしたコンテンツを全て選択して、[アクション]-[公開する]をクリック。
    • これを実行しないと、アクセスしても 403 エラーになる。
確認

AWS アカウント作成後にすぐやるセキュリティ対策

ルートアカウント

  • ルートユーザーの他要素認証の有効化
  • Amazon S3 のブロックパブリックアクセスをアカウントレベルで有効化
  • CloudTrail を有効化
  • AWS Config を有効化(マネージドルールは選択しない)
  • AWS GuardDuty を有効化
  • AWS SSO、AWS Organizations を有効化
    • 権限をセット、グループ、ユーザーを作成
    • ユーザーのMFAを有効化
  • AWS Budgets で AWS 利用料のアラートメール設定

メンバーアカウント

  • Organizations でメンバーアカウントを作成する。
  • ルートアカウントでログインして、上記の設定を行う(「AWS SSO、AWS Organizations を有効化」除く)。

base64 エンコーディングされたバイナリデータは元より大きくなる

メールの添付ファイルが元のファイルよりもサイズが大きくなる理由
RFC 2045 で定義されている Multipurpose Internet Mail Extensions(MIME)の仕様には、バイナリからテキストへのいくつかのエンコーディングの 1 つとして「base64」が示されています。 MIMEbase64 エンコーディングは、プライバシー強化メール(PEM)の RFC 1421 バージョンのエンコーディングに基づき、PEM と同じ 64 文字のアルファベットおよびエンコーディングカニズムを使用し、出力のパディングには同様に「=」記号を用います。

MIME では、base64 エンコーディングされた行に対して固定長は規定されていませんが、76 文字の最大長は規定されています。 また、余分なアルファベット文字は、規格に準拠したデコーダですべて無視されなければならないことも規定しています。ただし、ほとんどの実装では CR/LF の改行ペアを使用して符号化された行を区切ります。

このため、MIME 準拠の base64 エンコーディングされたバイナリ データの実際の長さは、通常、元のデータ長の約 137 % になります。ただし、非常に短いメッセージの場合、ヘッダーのオーバーヘッドのせいでオーバーヘッドが大幅に増える可能性があります。 Base64 エンコーディングされたバイナリ データの最終的なサイズは、おおよそで元のデータ サイズの 1.37 倍に 814 バイト(ヘッダー用)を加えたサイズと等しくなります。

メールの添付ファイルが元のファイルよりもサイズが大きくなる理由 - Cisco

ALB と Lambda のリクエストサイズの最大値

  • Lambda の呼び出しペイロードは最大 6MB(同期の場合)
  • ALB はターゲットが Lambda の場合にリクエストボディは最大 1MB

参考

リソース Quota
呼び出しペイロード (リクエストとレスポンス) 6 MB (同期)
256 KB (非同期)
AWS Lambda のクォータ - AWS Lambda

HTTP 413: Payload too large
ターゲットは Lambda 関数で、リクエストボディが 1 MB を超えています。

Application Load Balancer のトラブルシューティング - Elastic Load Balancing