CloudFrontをOACへ移行する順序｜OAIを先に消すと配信停止の恐れ

CloudFrontのS3オリジンをOAIからOACへ移すときは、バケットポリシーで両方式からのアクセスを先に許可し、ディストリビューションを更新してから旧OAIの許可を外す。AWSのS3オリジン移行手順は、この順序によって切り替え中もCloudFrontからバケットへのアクセスを保てると説明している。

旧OAIの許可を先に消すと、更新前の設定で動くCloudFrontからのオリジン要求をS3が拒否し、キャッシュにないコンテンツの配信が止まり得る。移行中に並存させるのはバケットポリシーの許可だ。ディストリビューションの同じオリジンにOAIとOACを同時設定する手順ではない。

対象のオリジンと切り戻し先を確かめる

この手順の対象は、通常のS3バケットをCloudFrontのオリジンにした既存の配信だ。S3のウェブサイトエンドポイントはカスタムオリジンとして扱われ、OACを利用できない。まず対象ディストリビューション、オリジン、現在のOAI、バケットポリシー、関連するキャッシュビヘイビアを特定する。

更新前のディストリビューション設定とバケットポリシーは保存しておく。OACへ切り替えた後に取得が失敗した場合、旧OAIの許可が残っていれば、保存したオリジン設定へ戻せる。OAIそのものを削除する前には、別のディストリビューションでも使われていないか確認が必要だ。

S3のObject Ownershipも確認する。OACを使うS3バケットオリジンには原則として「Bucket owner enforced」が必要で、ACLを使い続ける構成には「Bucket owner preferred」が用意されている。旧OAIへのアクセスをオブジェクトACLで与えている場合も、移行前に実際の許可経路を把握しておきたい。

読み取り専用の配信なら、対象オブジェクトへのs3:GetObjectが中心になる。CloudFront経由のPUTやDELETEを扱うなら、必要な操作と対象を別に整理する。SSE-KMSで暗号化したオブジェクトでは、S3のバケットポリシーに加え、CloudFrontディストリビューションがKMSキーを使えるようキーのポリシーも整える。

旧OAIを残したままバケットポリシーを広げる

最初の変更は、既存のOAI向け許可を維持したまま、OACを使うディストリビューション向けの許可を追加することだ。読み取り配信なら、両方のステートメントで対象オブジェクトへのs3:GetObjectを許可する。両者で異なるのはPrincipalと、OAC側に付ける条件だ。

旧OAI向けのステートメントを残す。Principalには現在のOAIを示すARNを指定し、Resourceは配信対象となるS3オブジェクトのARNにする。
OAC向けのステートメントを追加する。PrincipalのServiceをcloudfront.amazonaws.comとし、ConditionのAWS:SourceArnを対象ディストリビューションのARNに限定する。
保存したポリシーを読み直し、バケット名、AWSアカウントID、ディストリビューションID、対象オブジェクトの範囲を照合する。旧OAI向けステートメントが残っていることも確認する。

この段階では、ディストリビューションはまだOAIを使う。OAC側の許可を先に置くことで、設定が切り替わったエッジからの要求を受けられる一方、旧設定のままのエッジも引き続きS3へ到達できる。既存ポリシーを丸ごと置き換える操作として扱わないことが重要だ。

OACを作成してオリジン設定を切り替える

両方の許可がそろったら、S3オリジン用のOACを作成する。一般的な非公開バケットではSigningBehaviorをalwaysに設定し、作成したOACのIDを控える。コンソールでは対象オリジンの「Origin access」でOACを選ぶ。CLIを使う場合は、取得したディストリビューション設定の対象オリジンにOriginAccessControlIdを指定する。

同じオリジンのOriginAccessIdentityからは旧OAIの値を外す。CloudFrontは、一つのオリジンにOAIとOACが同時に指定された更新を受け付けない。ただし、この時点で外すのはオリジン設定上の関連付けであり、S3バケットポリシーに残したOAI向け許可やOAI自体ではない。

APIやCLIで更新するなら、UpdateDistributionの仕様に従い、取得した最新設定のETagをIfMatchに使う。送信する設定は既存設定に差分として統合されず、全体を置き換える。対象オリジンだけを抜き出さず、ほかのオリジンやビヘイビアを含む構成を基に編集する。

更新後、新しい設定はCloudFrontのエッジへ順次反映される。この間は旧OAIからの要求と新OACからの要求が混在し得るため、バケットポリシーの両許可を維持する。管理画面でOACとの関連付けが見えたことだけを理由に、旧許可を削除しない。

Authorizationを転送する構成は署名設定を分ける

通常はalwaysを選ぶ。この設定ではCloudFrontがS3オリジンへの要求を署名し、閲覧者の要求にAuthorizationヘッダーがあっても、オリジン向けの署名で上書きする。閲覧者が送ったAuthorizationをS3へ渡す必要がある構成だけ、no-overrideを検討する。

AWS CLIのSigningBehavior仕様によると、no-overrideでは閲覧者のAuthorizationがない要求をCloudFrontが署名し、ある要求ではCloudFrontが署名せず、そのヘッダーを転送する。転送には、そのOACに関連するオリジンを使うすべてのキャッシュビヘイビアのキャッシュポリシーにAuthorizationを追加する必要がある。

no-overrideを選ぶ際は、S3が受け取る閲覧者の認証情報で対象オブジェクトにアクセスできる設計か確認する。ヘッダーを転送する設定だけでは、その認証情報に権限が与えられるわけではない。neverはCloudFrontによる署名を止めるため、非公開バケットへCloudFrontの署名でアクセスする通常の移行には適さない。