【初心者向け】AWS CloudFrontの「OAI」と「OAC」の違いとは？最新のベストプラクティスを解説
【初心者向け】AWS CloudFrontの「OAI」と「OAC」の違いとは？
AWSを利用してNext.jsやReactの静的サイト（SSG/SPA）をホスティングするため、S3とCloudFrontの設定を調べていたところ、**「OAI」と「OAC」**という似たような用語にぶつかりました。
「どちらを使えばいいの？」「何が違うの？」と疑問に思ったため、AWS初心者の視点から分かりやすく調査した結果をまとめます。
OAIとOACの基本：どちらも「S3を守る」ための機能
まずは共通点からです。静的ファイルをS3に置いてCloudFront（CDN）経由で配信する際、一番やってはいけないのは「S3バケットをそのまま一般公開してしまうこと」です。直接アクセスされると、CDNのキャッシュが効かずに通信料が跳ね上がったり、意図せぬセキュリティリスクが生まれたりします。
そこで、「CloudFrontからのアクセスだけを特別に許可し、それ以外の直接アクセスを遮断する」という仕組みが必要になります。この「特別通行許可証」のような強固な役割を果たすのが、OAIとその後継であるOACです。
1. 昔からある「OAI」 (Origin Access Identity)
OAIは、CloudFrontの初期から長らく提供されてきた従来のアクセス制御機能です。文字通り「オリジン（S3）にアクセスするための身分証明」として機能し、少し古いチュートリアル記事などでは必ずこちらが使われています。
2. 新しくて強い「OAC」 (Origin Access Control)
OACは、2022年末のアップデートで新しく登場した次世代のアクセス制御機能です。セキュリティ構造が根本から見直されており、AWS公式でも現在はこちらを利用することが強く推奨（ベストプラクティス）されています。
なぜOACを使うべきなのか？（3つの主な理由）
では、なぜ今まで動いていたOAIではなく、新しいOACを選ぶべきなのでしょうか。初心者が押さえておくべき決定的な違いは以下の3つになります。
① すべてのAWSリージョンに対応している
OAIは、AWSの設計制限により2022年以降に新設された一部の最新リージョンでは機能をサポートしていません。一方、新しい方式であるOACは、後から追加された地域も含めて世界中のすべてのAWSリージョンで完全動作します。
② KMS（暗号化キー）に対応した高度なセキュリティ
昨今のセキュリティ基準では、S3に保存するデータをAWS KMS（Key Management Service）を用いて暗号化する要件が増えています。深刻なことに、旧方式のOAIはKMSで暗号化されたS3バケットからファイルを読み込むことができませんでした。OACであれば、KMSによるサーバーサイド暗号化（SSE-KMS）の認証プロセスを正しくパスできるため、より強固なセキュリティ要件を満たすことが可能になりました。
③ 動的リクエスト（PUTやDELETE）への完全対応
OAIは、ファイルの取得（GETリクエスト）に特化した設計でした。一方、OACではS3へのアクセス時にAWS標準の強力なリクエスト署名（SigV4）を用いた認証プロセスを採用しています。これにより、アップロード（PUT）や削除（DELETE）など、より高度で動的なAPIリクエストもセキュアにCloudFront経由で行うことが可能になっています。
[!NOTE] 補足：リクエスト署名（SigV4）とは？ AWSの各サービスを利用する際、そのリクエストが「本当に正当な送信元からのものか」を高度な暗号化技術で検証するAWSの標準セキュリティ機能（Signature Version 4）です。簡単に言えば、通信データに「絶対に偽造できない電子ハンコ」を押すような仕組みです。 OAIの時代はこのハンコをCloudFront経由で正しく押すことができなかったため、機密性の高い操作（ファイルのアップロードなど）が制限されていました。OACではCloudFrontが確実にこのハンコを中継・付与できるようになったため、安全にすべての操作ができるようになっています。
OAIからOACへ移行する際の注意点
既存のOAI環境から新しいOACへ移行するのは簡単に見えますが、単に設定を切り替えるだけではサイトが見られなくなってしまう落とし穴があります。私が調査した中で特に重要だと感じた4つの注意点をまとめました。
-
バケットポリシーの書き換えが必要（自動で書き換え可能） OAIからOACに変更すると、S3のアクセス許可ルール（バケットポリシー）をOAC向けに更新する必要があります。CloudFrontの管理画面から提供されるポリシーをコピペするか、画面上のボタンから自動でバケットポリシーを書き換えることができます。更新を忘れるとアクセスエラーになります。
-
S3の Website Endpoint が使えなくなる OACは強固なセキュリティの都合上、S3の「REST APIエンドポイント」に対してのみ機能します。そのため、これまでS3の静的ウェブサイトホスティング機能（Website Endpoint）に向けてCloudFrontを紐づけていた場合は、RESTエンドポイントへ指定を変更する必要があります。
-
index.htmlの自動補完が効かなくなる 上記の「Website Endpoint が使えなくなる」ことの最大の弊害として、URLの末尾が/で終わった時に自動でindex.htmlを表示してくれていたS3の便利機能が失われます。そのため、下層ページ（例:/tech_blog/）に直接アクセスした際にファイルが見つからずエラーになってしまいます。実際に私もこの部分で苦戦しました。一見問題ないように見えてもリロードすると「AccessDenied」や「404 Not Found」等のエラーになるので注意が必要です。 -
CloudFront Functions が必要になる場合がある 失われた
index.htmlの自動補完機能をどうやって補うのかというと、CloudFront Functions（あるいはLambda@Edge）を用いて、リクエストされたURLの末尾にプログラム処理で自動的にindex.htmlを付与する仕組み（URLリライト）を導入する必要があります。特にNext.jsなどのフレームワークで静的エクスポート（SSG）している構成ではほぼ必須の設定となります。index.htmlの自動補完設定については、下記の記事に記載しております。
結論：これから設定するなら絶対に「OAC」
色々と調べた結果、結論としては**「これから新しくS3とCloudFrontを設定するなら、迷わずOACを選ぶべき」**ということがハッキリ分かりました。
ネット上にはまだ古い情報を元にしたOAIの手順記事（2021年以前のものなど）が多く残っています。初めてAWSで静的サイトを構築する人は「記事の通りにやっているのに最新のAWS画面と違う」と混乱する原因になりがちですが、このような機能の歴史的背景を知っておけば安心できます。
既存の環境でOAIを使っていて問題がない場合でも、数回のクリックでOACへ移行させることが可能です。セキュリティや今後の拡張性を考え、私もこれからはOACを標準としてインフラ構築を進めていこうと思います。
参考記事：Amazon CloudFront オリジンアクセスコントロール（OAC）のご紹介 | Amazon Web Services ブログ
関連記事: