S3 Presigned URL
通常は非公開のS3オブジェクトへ、一定時間だけアクセスさせたい場合にPresigned URLを利用できます。
Private S3 Object
↓
Presigned URL発行
↓
User
↓
一定時間だけアクセス
Presigned URLの生成方法と権限
Presigned URLは、
AWS SDK
AWS CLI
などを利用して生成できます。
Application
↓
AWS SDK
↓
Presigned URL生成
↓
Userへ返す
Presigned URLで許可できる操作は、URLを生成したIAM Principalが持つ権限の範囲内です。
Presigned URLの有効期限
IAM Userなどの長期認証情報
SigV4を利用したPresigned URLは、AWS SDK / CLIなどで最大7日まで設定できます。
IAM User
+
SigV4
↓
Presigned URL
最大7日
IAM Role / STSなどの一時認証情報
一時認証情報を利用した場合、Presigned URLは元になった一時認証情報より長く有効にはできません。
Presigned URL
設定上の期限
→ 7日
Role Session
→ 6時間で失効
結果
→ Role Session失効時に
Presigned URLも利用不可
S3 Event Notification
S3へのオブジェクトUploadなどをきっかけに、別の処理を開始できます。
画像Upload
↓
S3
↓
Event Notification
↓
Lambda
↓
画像Resize
SQS FIFO QueueやSNS FIFO Topicは、S3 Event Notificationの直接通知先として利用できません。
EventBridge連携
S3 BucketでEventBridgeへのイベント送信を有効化すると、
S3
↓
EventBridge
↓
Event Pattern
├→ Target A
├→ Target B
└→ Target C
という構成を作れます。
EventBridgeでは、
- 柔軟なEvent Pattern
- 複数TargetへのRouting
- 多数のAWSサービスとの連携
などができます。
S3 Versioning
Versioningを有効にすると、同じObject Keyの過去Versionを保持できます。
file.txt
↓
Version 1
更新
↓
Version 2
更新
↓
Version 3
誤って上書き・削除した場合の復旧などに利用できます。
Delete Marker
Version IDを指定せずにオブジェクトを削除すると、基本的にDelete Markerが追加されます。
DELETE file.txt
↓
Delete Marker
過去Versionそのものが即座に消えるわけではありません。
Delete Markerを削除すると、以前のVersionを再びCurrent Versionとして見える状態に戻せます。
Version 2
↓
Delete Marker
↓
削除されたように見える
Delete Marker削除
↓
Version 2が再び見える
一方、Version IDを指定して削除すると、そのVersion自体を削除します。
VersioningをSuspendした場合
一度有効化したVersioningを完全なDisabled状態へ戻すことはできません。
Enabled
↓
Suspended
とできます。
Suspendedにしても、すでに存在するVersionは保持されます。
Version 1
Version 2
Version 3
↓
Versioning Suspend
↓
既存Versionは残る
Suspended状態で新しく保存されるオブジェクトには、通常の一意なVersion IDではなくnull Versionが使用されます。
さらに、Suspended中に同じKeyへ再びUploadすると、
file.txt
Version ID = null
↓
同じKeyへ再Upload
↓
新しいnull Versionで置き換え
という挙動になります。
Lifecycle
古いオブジェクトやVersionを自動的に別Storage Classへ移動したり、削除したりできます。
S3 Standard
↓
一定期間
↓
IA / Glacier系
↓
一定期間
↓
削除
古いObjectを自動移行
古いVersionを自動削除
→ Lifecycle
S3の暗号化
S3では保存データを暗号化できます。
代表的なのが、
SSE-S3
SSE-KMS
です。
現在のAmazon S3では、新しくUploadされるオブジェクトはServer-Side Encryptionによって自動的に暗号化され、デフォルトではSSE-S3が使用されます。
SSE-KMS
AWS KMSのKeyを利用して暗号化します。
Object
↓
KMS Key
↓
暗号化
KMSを利用する場合は、S3 PermissionだけではなくKMS側のPermissionも重要です。
S3 GetObject
→ Allow
kms:Decrypt
→ Deny
↓
暗号化Objectを読めない
SSE-KMSとThrottling
SSE-KMSではKMS APIを利用するため、大量アクセスではKMS側のRequest Quotaも考える必要があります。
大量のS3 Request
↓
大量のKMS Request
↓
KMS Quota
↓
Throttlingの可能性
SSE-KMSを強制する
Bucket PolicyのConditionを利用して、指定した暗号化方式を使用していないUploadを拒否できます。
例えば、
s3:x-amz-server-side-encryption
に、
aws:kms
を要求することでSSE-KMSを強制できます。
さらに、特定のKMS Keyを利用させたい場合は、
s3:x-amz-server-side-encryption-aws-kms-key-id
をConditionとして利用できます。
CloudFront + OAC
S3のコンテンツをCloudFrontから配信する場合、S3 BucketをPublicにする必要はありません。
現在はOrigin Access Control（OAC） を利用する構成が推奨されます。
User
↓
CloudFront
↓
OAC
↓
Private S3
S3 Bucket Policy側でもCloudFront Service Principalからのアクセスを許可します。
Principal
→ cloudfront.amazonaws.com
Condition
→ 対象CloudFront Distribution ARN
User
↓
CloudFront Distribution
↓
OAC
↓
Bucket Policyで許可
↓
Private S3
CloudFront Signed URL / Signed Cookie
Private Contentへのアクセスを制限できます。
Signed URL
個別のPrivate ContentへのURLを渡したい場合に利用します。
Private Content
↓
CloudFront
↓
Signed URL
↓
User
例えば、
有料動画
限定Download
会員限定コンテンツ
などです。
Signed Cookie
複数のPrivate Contentへのアクセスをまとめて許可したい場合に利用できます。
また、既存URLを変更したくない場合にも適しています。
個別FileへのURLを渡す
→ Signed URL
複数Fileへのアクセス
URLを変更したくない
→ Signed Cookie
8. Trusted Key Group
CloudFrontではTrusted Key Groupを利用する方法が推奨されます。
Public Key
↓
CloudFrontへ登録
↓
Key Groupへ追加
↓
Cache Behaviorで
Trusted Key Groupとして指定
対応するPrivate KeyはApplication側で安全に保管します。
Key Rotation
Key Groupには複数のPublic Keyを含められるため、新旧のKeyを一時的に併用しながらKey Rotationできます。
新Public Key追加
↓
新旧Public Keyを一時併用
↓
Applicationを新Private Keyへ変更
↓
旧Public Keyを削除
CloudFront Cache
CloudFrontはOriginから取得したコンテンツをEdge LocationへCacheします。
User
↓
CloudFront Edge
↓
Cache HIT
↓
Response
Cacheがなければ、
User
↓
CloudFront
↓
Cache MISS
↓
S3
↓
CloudFrontへCache
↓
User
となります。
これによってLatencyやOrigin負荷を低減できます。
Cache Key
CloudFrontはCache Keyを利用して、どのRequestを同じCacheとして扱うか判断します。
基本となるURL Pathに加え、Cache Policyの設定によって、
Query String
Header
Cookie
などをCache Keyへ含められます。
Cache Key
→ Path
+
必要に応じて
Query String / Header / Cookie
設定
→ Cache Policy
TTL
Cacheをどの程度保持するかはTTLによって制御できます。
Origin側から、
Cache-Control
Expires
などを利用してCache期間を制御できます。
更新頻度が高い
→ TTLを短く
更新頻度が低い
→ TTLを長く
といった設計ができます。
Cache Invalidation
S3のオブジェクトを更新しても、CloudFrontに古いCacheが残っている場合があります。
S3
→ new index.html
CloudFront
→ old index.html
すぐに古いCacheを無効化したい場合はInvalidationを利用します。
例えば、
/index.html
/images/*
のようにPathを指定できます。
Versioned File Name
style.v1.css
↓
更新
↓
style.v2.css
とFile Nameを変更します。
CloudFrontから見ると異なるCache Keyになるため、新しいオブジェクトとして取得できます。
現在のCacheをすぐ消す
→ Invalidation
頻繁な静的File更新
→ Versioned File Name
Cache保持期間を調整
→ TTL
と整理します。
Multipart Upload
大容量ファイルをS3へUploadする場合はMultipart Uploadを利用できます。
Large File
↓
Part 1
Part 2
Part 3
Part 4
↓
並列Upload
↓
S3で結合
100MB以上程度の大容量オブジェクトではMultipart Uploadを検討します。
メリットは、
並列Upload
失敗したPartだけ再送
大容量Fileを効率的にUpload
です。
S3 Transfer Acceleration
遠距離からS3へ高速にファイルを転送したい場合はS3 Transfer Accelerationを利用できます。
遠距離Client
↓
AWS Edge Location
↓
AWS Global Network
↓
S3
Transfer AccelerationはCloudFrontでも利用されるAWSのEdge Networkを活用しますが、CloudFront Distributionを作成してコンテンツを配信する機能とは別物です。
世界中のUserへContent配信
→ CloudFront
遠距離からS3への転送を高速化
→ S3 Transfer Acceleration
と区別します。
CORS
Web Browser上のApplicationから異なるOriginのS3 Resourceへ直接アクセスする場合は、CORS設定が必要になることがあります。
Web Application
example.com
↓
S3
bucket.s3.amazonaws.com
S3 Bucket側で、
AllowedOrigins
AllowedMethods
AllowedHeaders
ExposeHeaders
などを設定します。
重要なのは、CORSは認証・認可そのものではないことです。
IAM / Bucket Policy
→ Accessを許可するか
CORS
→ BrowserがCross-Origin Requestを
許可するか
Lambda@Edge / CloudFront Functions
CloudFrontでは、Edge側でRequestやResponseを加工することもできます。
CloudFront Functions
Lambda@Edge
CloudFront Functions
軽量で高速な処理に向いています。
Header操作
URL Rewrite / Redirect
簡単なRequest処理
User
↓
CloudFront
↓
CloudFront Functions
↓
Request加工
Lambda@Edge
より高度な処理が必要な場合に利用できます。
CloudFront
↓
Lambda@Edge
↓
より高度な処理
HTTPS
CloudFrontを利用してHTTPSでコンテンツを配信できます。
独自DomainでHTTPSを利用する場合はACM CertificateをCloudFrontへ設定できます。
User
↓ HTTPS
CloudFront
↓
S3
CloudFront
+
独自Domain
+
HTTPS
→ ACM