大手メディア企業が、AWS Organizations上でコンテンツ配信プラットフォームを運営しています。アーキテクチャは以下の通りです：コンテンツ管理アカウント（CMS、メタデータDB）、ストレージアカウント（S3、数十PBの映像コンテンツ）、配信アカウント（CloudFront、MediaPackage）、分析アカウント（Redshift、Athena）。現在の課題は、 ①ストレージアカウントのS3バケットにある映像ファイルを配信アカウントのCloudFrontからOriginAccessControlでセキュアにアクセスしたいが、クロスアカウントのOAC設定で問題が発生している、 ②分析アカウントのAthenaがストレージアカウントのS3データをクロスアカウントでクエリしようとしているが、AWS Glue Data Catalogがアカウントをまたいで参照できていない、 ③コンテンツ管理アカウントがストレージアカウントにS3 Select APIでデータを読み書きする際のコスト最適化。最適なクロスアカウントアクセス設計はどれですか？（2つ選択）
CloudFrontのOAC（Origin Access Control）を使用するには、配信アカウントのCloudFrontディストリビューションのOACをストレージアカウントのS3バケットポリシーで許可する必要がある。バケットポリシーにCloudFrontサービスプリンシパル（cloudfront.amazonaws.com）をPrincipalとし、aws:SourceArnでCloudFrontディストリビューションARNを指定してクロスアカウントアクセスを許可する。 および 分析アカウントのAthenaからストレージアカウントのS3データをクロスアカウントでクエリするには、ストレージアカウントにGlue Crawlerを実行してデータカタログを作成し、Resource Access Manager（RAM）でGlue Data Catalogリソースを分析アカウントと共有する。分析アカウントではリソースリンクを使用して共有カタログを参照する。 CloudFront OACはクロスアカウントのS3バケットをオリジンとして使用できます。S3バケットポリシーでcloudfront.amazonaws.comをPrincipalとし、aws:SourceArnでCloudFrontディストリビューションARNを条件に指定することでセキュアなクロスアカウントアクセスが実現できます。 Glue Data CatalogのRAM共有はGlue/Athenaのクロスアカウントデータカタログ参照の推奨方法で、分析アカウントにリソースリンクを作成して共有カタログを参照できます。 選択肢Bはサポートされていないという前提が誤りです。OACはクロスアカウントのS3バケットに正式対応しており、二段階CloudFront構成は不要で管理の複雑さを増すだけです。 選択肢Dは不正確です。Lake FormationのクロスアカウントアクセスはRAMリソース共有を内部的に使用するため、「GlueクロスアカウントのRAM共有は不要」という断言は誤りです。またLake Formationの追加設定と権限管理の複雑さも生じます。 選択肢Eはリアルアーキテクチャに合っていません。Transit GatewayはVPC間ルーティングを提供しますが、S3はグローバルサービスであり、クロスアカウントのS3バケットアクセス制御はバケットポリシーやIAMロールで行います。S3 Intelligent-TieringはストレージコストのTier自動化であり、クロスアカウントアクセス設計の解決策にはなりません。