CloudFront の OAI から OAC への移行を「Upgrade now」ボタンで実行しよう！
こんにちは！Koty-Mousa 矢坂幸太郎 です！
本日は、CloudFront が S3 オリジンにアクセスする際の認証方式を、従来の OAI から新しい OAC に移行する手順を確認してみましょう！
CloudFront とアクセス制御について
まず、CloudFront は、Webサイトのコンテンツをより早く配信することができるサービスです。
AWS のエッジロケーションと呼ばれる、世界中にあるデータセンターを経由してコンテンツを配信できるようになります。
例えば、東京リージョンの S3 に保存した画像をユーザーに見てもらう際、CloudFront なしだとアメリカやヨーロッパのユーザーも東京まで直接アクセスする必要があります。
しかし、CloudFront を使えば、近くのエッジロケーションからデータを配信できるため、わざわざ遠くまでアクセスする必要がなくなります。
これが CloudFront です。
OAI と OAC
CloudFront が配信するデータを保存している場所を「オリジン」といいます。
このオリジンに S3 バケットを設定する場合、S3バケットポリシーにて CloudFront によるS3の内容の読み取りを許可する必要があります。
※注：バケットを全世界公開すれば理論上 CloudFront もアクセス可能ですが、安全ではありません。
この CloudFront と S3 間のアクセス制御で使用される認証の仕組みが OAI（Origin Access Identity）または OAC（Origin Access Control）です。
OAC は 2022年8月に開始されました
本記事では、従来のOAI から OAC への移行方法をご案内します。
ダウンタイムなく簡単に移行する方法
実は、簡単に移行できる機能が AWS に用意されています。
OAI が設定されている CloudFront のオリジン設定画面
Upgrade to origin access control
This origin is using a legacy access identity (OAI). Upgrade to origin access control (OAC) for improved security with SigV4 authentication and better performance. The migration typically takes less than a minute, and we'll maintain your distribution's service throughout the process.
===== 参考翻訳
オリジンアクセスコントロールへのアップグレードこのオリジンは従来のアクセスアイデンティティ（OAI）を使用しています。SigV4認証による改善されたセキュリティとより良いパフォーマンスのために、オリジンアクセスコントロール（OAC）にアップグレードしてください。移行は通常1分未満で完了し、プロセス中もディストリビューションのサービスを維持します。
この「Upgrade now」ボタンを押すと、次の画面に移動します
Origin access control
切り替え先の OAC を設定します
- Create new OAC automatically
- OAC を新規作成します
- Choose an existing OAC
- すでに作成した OAC から選択します（プルダウンメニューが表示されます）
Bucket policy
「Allow CloudFront to update the bucket policy on your behalf」（CloudFrontがあなたの代わりにバケットポリシーを更新することを許可する）を選択すると、バケットポリシーの変更を行います。
チェックをいれることをおすすめします。
Upgrade steps
「Upgrade now」の手順が表示されています
- 現在のバケットポリシーの確認・評価
- 新しいOACの作成
- バケットポリシーの変更適用
- ディストリビューション設定の更新
「Allow CloudFront to ...」のチェックをいれた状態で「Upgrade now」を押すと、ダウンタイムなしで OAI から OAC への移行が行われます。
バケットポリシーの変更も自動で行われるため、そのまま末尾「変更を保存」をクリックすることで変更を完了できます。
上記のように、OAI から OAC へ変更されたことが確認できます。
しくみ
非常に便利なボタンがついている CloudFront コンソールですが、どのようなしくみで OAI から OAC への移行を行っているのでしょうか。
それでは、この仕組みを見ていきましょう！
「Upgrade now」は何をしているのか
「Upgrade now」をクリックした際の動作を紐解いてみましょう。
まず、「Upgrade now」をクリックした際、次のような CloudTrail 履歴が記録されました
CloudTrail 履歴
※値は置き換えています
{
"eventVersion": "1.11",
"userIdentity": {
"type": "AssumedRole",
"principalId": "AROAXXXXXXXXXXXXX:username",
"arn": "arn:aws:sts::111111111111:assumed-role/username/username",
"accountId": "111111111111",
"accessKeyId": "ASIAXXXXXXXXXXXXX",
"sessionContext": {
"sessionIssuer": {
"type": "Role",
"principalId": "AROAXXXXXXXXXXXXX",
"arn": "arn:aws:iam::111111111111:role/username",
"accountId": "111111111111",
"userName": "username"
},
"attributes": {
"creationDate": "2025-09-29T02:33:12Z",
"mfaAuthenticated": "true"
}
}
},
"eventTime": "2025-09-29T02:36:44Z",
"eventSource": "s3.amazonaws.com",
"eventName": "PutBucketPolicy",
"awsRegion": "ap-northeast-1",
"sourceIPAddress": "XXX.XXX.XXX.XXX",
"userAgent": "[Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/140.0.0.0 Safari/537.36]",
"requestParameters": {
"bucketPolicy": {
"Version": "2008-10-17",
"Statement": [
{
"Sid": "1",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::cloudfront:user/CloudFront Origin Access Identity EXXXXXXXXXXXXX"
},
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::example-bucket-name/*"
},
{
"Sid": "AllowCloudFrontServicePrincipal1",
"Effect": "Allow",
"Principal": {
"Service": "cloudfront.amazonaws.com"
},
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::example-bucket-name/*",
"Condition": {
"StringEquals": {
"AWS:SourceArn": "arn:aws:cloudfront::111111111111:distribution/EXXXXXXXXXXXXX"
}
}
}
],
"Id": "PolicyForCloudFrontPrivateContent"
},
"bucketName": "example-bucket-name",
"Host": "example-bucket-name.s3.ap-northeast-1.amazonaws.com",
"policy": ""
},
"responseElements": null,
"additionalEventData": {
"SignatureVersion": "SigV4",
"CipherSuite": "TLS_AES_128_GCM_SHA256",
"bytesTransferredIn": 589,
"AuthenticationMethod": "AuthHeader",
"x-amz-id-2": "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX",
"bytesTransferredOut": 0
},
"requestID": "XXXXXXXXXXXXXXXX",
"eventID": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
"readOnly": false,
"resources": [
{
"accountId": "111111111111",
"type": "AWS::S3::Bucket",
"ARN": "arn:aws:s3:::example-bucket-name"
}
],
"eventType": "AwsApiCall",
"managementEvent": true,
"recipientAccountId": "111111111111",
"eventCategory": "Management",
"tlsDetails": {
"tlsVersion": "TLSv1.3",
"cipherSuite": "TLS_AES_128_GCM_SHA256",
"clientProvidedHostHeader": "example-bucket-name.s3.ap-northeast-1.amazonaws.com"
}
}
「PutBucketPolicy」として、OAI と OAC 両方を許可するバケットポリシーが設定されていました。
OAI から OAC への移行時、両方を有効化することはできません。どちらか片方のみが有効化されます。
「Upgrade now」ボタンにより作成されるポリシーは、移行時にどちらのオリジンアクセスであってもダウンタイムなく移行できるポリシーとなっています。
仮に、オリジン設定の変更前に、バケットポリシーを OAC のみを許可するポリシーに変更した場合、オリジン設定を OAC を利用するように変更するまでオリジンにアクセスできなくなります。
OAC が新たに作成されるか、選択した OAC が選択されているため、このまま「変更を保存」をクリックすることで、OAC への移行を完了できます。
本当にダウンタイムは発生していないの？【検証】
理論上ダウンタイムが発生していないとはいえ、本当にダウンタイムが発生していないのでしょうか？
実際に確認してみましょう！
オリジンへのアクセスが不可能になっても、キャッシュが残っているため問題なくページが表示される可能性があります。
検証のため、ビヘイビアにマネージドポリシー「CachingDisabled」を設定、「Cache-Control」を「no-cache」に設定、
ブラウザのリロードにはスーパーリロードを使用します。
これにより、アクセスの都度 CloudFront はオリジンへアクセスします
ブラウザ機能拡張により、1秒おきにスーパーリロードを行い、HAR ファイルを取得します。
これにより、アクセス不可が発生していないかどうかを確認することができます。
＝＝＝＝＝
03:02:18: 正常アクセス（移行2秒前）
03:02:20: CloudTrailでUpdateDistribution実行
03:02:23: 正常アクセス（移行3秒後）
以降継続: 全て正常レスポンス
＝＝＝＝＝
ご覧の通り、すべて 200（OK）が返されています。
ダウンタイムなく移行できることがわかりました！
簡単に移行できます！
ご覧いただいたように、「Upgrade now」ボタンにより、簡単にダウンタイムなしで移行できることがわかりました！
ぜひ、新しい OAC を利用して、CloudFront をご利用ください！
Koty-Mousa 矢坂幸太郎 がお伝えしました！
アノテーション株式会社について
アノテーション株式会社はクラスメソッドグループのオペレーション専門特化企業です。サポート・運用・開発保守・情シス・バックオフィスの専門チームが、最新 IT テクノロジー、高い技術力、蓄積されたノウハウをフル活用し、お客様の課題解決を行っています。当社は様々な職種でメンバーを募集しています。「オペレーション・エクセレンス」と「らしく働く、らしく生きる」を共に実現するカルチャー・しくみ・働き方にご興味がある方は、アノテーション株式会社 採用サイトをぜひご覧ください。
