どーも。shihopowerデス。今回は「クロス」系の機能をまとめてみました。SAP対策をしていて、「クロス…」という機能が選択肢に出てきた際に、「あれ、このサービスにクロス〇〇といった機能ってあったっけ」となって自信をもって選択肢を選べないということがありました。
「クロス」とつく機能と対応するサービスを調べてみると自分が想像していたよりもたくさんあることが分かりました。
本記事では、それらを カテゴリ別 に整理し、各機能の定義・存在意義・ユースケースをまとめました。
以下のように表にまとめてみたのですが、この表を丸暗記するのではなく、ざっと目を通してこのサービスにこういう機能があるんだなくらいに把握しておけばよいのではないかなと思っています。
目次
- クロスアカウント（Cross-Account）
- クロスリージョン（Cross-Region）
- クロスオリジン（Cross-Origin / CORS）
- クロスサービス（Cross-Service）
- クロスゾーン（Cross-Zone）
- その他のクロス系
1.クロスアカウント（Cross-Account）
複数のAWSアカウントをまたいでリソースを操作・共有する機能群です。マルチアカウント戦略を採用する組織において特に重要です。
| サービス / 機能名 | 定義 | 存在意義 | ユースケース |
|---|---|---|---|
|
AWS Backup クロスアカウント管理 |
AWS Organizations配下の複数アカウントのバックアップを一元管理する機能 | 各アカウントが個別にバックアップを管理すると設定漏れや監査困難が生じるため、組織全体で一貫したバックアップポリシーを強制適用できる | 金融システムで本番・開発・検証アカウントのRDSバックアップを管理アカウントから統制し、コンプライアンス要件を満たす |
|
AWS RAM クロスアカウントリソース共有 |
VPCサブネット・Transit Gateway・Route 53 Resolver等のリソースを別アカウントと共有する | 同じリソースを複数アカウントに重複作成するとコスト増・管理煩雑化を招くため、一度作成したリソースを安全に共有する | 共有VPCサブネットをネットワーキングアカウントで管理し、アプリアカウントのECSタスクをその中に配置してネットワークの一元管理を実現 |
|
Amazon S3 クロスアカウントレプリケーション |
あるアカウントのS3バケットを別アカウントのバケットに自動同期する機能（SRR/CRRと組み合わせ可） | データを別アカウントに分離することでランサムウェアや誤操作による全滅リスクを回避する | 本番アカウントのログをセキュリティ専用アカウントに自動複製し、改ざんを防いで監査ログを保全する |
|
AWS CloudFormation StackSets（クロスアカウント/クロスリージョン展開） |
単一のCloudFormationテンプレートを複数アカウント・複数リージョンに同時デプロイする機能 | 組織全体に同一のインフラ構成を手動展開すると人為ミスが発生するため、一括自動展開で一貫性を担保する | Organizations全アカウントにAWS Configルール・CloudTrail・IAMベースラインをLanding Zone構築時に一括展開 |
|
Amazon ECR クロスアカウントイメージ共有 |
ECRプライベートリポジトリのコンテナイメージを他アカウントからプル可能にするリソースポリシー機能 | 各アカウントに同じイメージをプッシュすると管理・ストレージコストが増大するため、単一の信頼できるレジストリから配布する | 共通のベースイメージを共有サービスアカウントで管理し、マイクロサービスの各チームアカウントから参照 |
|
AWS CodePipeline クロスアカウントパイプライン |
あるアカウントのパイプラインが別アカウントのリソース（S3・Lambda・CFn等）に対してアクション実行する | ツールアカウント（CI/CD）とワークロードアカウント（本番）を分離しつつ、継続的デプロイを実現する必要がある | DevOpsアカウントのパイプラインから本番アカウントのCloudFormationスタックをデプロイし、権限分離とデプロイ自動化を両立 |
|
Amazon EventBridge クロスアカウントイベントバス |
あるアカウントのイベントバスに発行されたイベントを別アカウントのイベントバスに転送する | マルチアカウント構成でサービス間をイベント駆動で疎結合に連携するには、アカウント境界を越えたイベント配信が必要 | 注文サービスアカウントの「注文完了」イベントを在庫・請求・通知の各アカウントに同時配信し、サービス間の直接依存を排除 |
|
AWS KMS クロスアカウントキー共有 |
KMSキーポリシーで他アカウントのIAMエンティティに暗号化・復号権限を付与する | 別アカウントが暗号化したデータにアクセスする場合、キー自体を複製すると管理が分散するため、一元管理しつつ権限のみ委譲する | 共有S3バケットのKMSキーをデータ提供アカウントで管理し、データ利用アカウントのIAMロールに復号権限を付与 |
|
Amazon RDS クロスアカウントスナップショット共有 |
RDSスナップショットを他のAWSアカウントに共有し、そのアカウントでリストア可能にする | DRや移行時に別アカウントへデータを渡す際、ダンプファイルのやり取りよりスナップショット共有の方が高速・安全 | 本番アカウントのスナップショットをDRアカウントに共有し、障害時に別リージョン・別アカウントで迅速にリストア |
|
AWS Organizations + SCP クロスアカウントポリシー管理 |
組織全体または特定OUに対してサービスコントロールポリシー（SCP）で権限の上限を設定する | 各アカウントが独立してIAMを管理すると意図しない権限昇格やリソース作成が発生するため、組織レベルのガードレールが必要 | 全アカウントで特定リージョン外のリソース作成を禁止するSCPを適用し、データレジデンシー要件（国内限定）を強制 |
|
Amazon Route 53 クロスアカウントDNS委任 |
プライベートホストゾーンを別アカウントのVPCに関連付け、クロスアカウントでDNS解決を行う（RAM経由） | DNS管理を中央のNetwork/DNSアカウントに集約しながら、各ワークロードアカウントのVPCでも内部DNSを利用できるようにする | 共有サービスアカウントで管理するapi.internal.example.comを各ビジネスユニットアカウントのVPCからも名前解決可能にする |
2.クロスリージョン（Cross-Region）
AWSの複数リージョンをまたいでデータや処理を連携する機能群です。DR（災害対策）・低レイテンシ・データ冗長化に活用されます。
| サービス / 機能名 | 定義 | 存在意義 | ユースケース |
|---|---|---|---|
|
Amazon S3 クロスリージョンレプリケーション（CRR） |
S3バケットのオブジェクトを別リージョンのバケットに自動複製する機能 | 単一リージョン障害によるデータ消失リスクを排除し、DR要件やデータ地理的配置要件に対応するため | 東京リージョンのS3バケットをシンガポールに自動複製し、アジア太平洋ユーザーへのレイテンシ低減とDRを同時実現 |
|
AWS Backup クロスリージョンバックアップ |
AWS Backupのバックアッププランで、バックアップを別リージョンにコピーするルールを設定する | リージョン全体の障害・自然災害時でもデータ復旧できるよう、物理的に離れた場所にバックアップを保持する必要がある | 東京の全RDS・EFS・DynamoDBバックアップを大阪にコピーし、RPO 24時間以内のDR要件を満たす |
|
Amazon RDS / Aurora クロスリージョンリードレプリカ / 自動バックアップ |
RDSのリードレプリカまたは自動バックアップを別リージョンに作成・保持する機能 | 読み取り負荷の地理分散、またはリージョン障害時のDRフェイルオーバー先として別リージョンのDBが必要 | 東京のAurora MySQLからシンガポールにリードレプリカを作成し、東南アジアユーザーの読み取りクエリのレイテンシを削減 |
|
Amazon DynamoDB グローバルテーブル |
DynamoDBテーブルを複数リージョンで双方向にレプリケートし、どのリージョンからも読み書きできる | グローバルサービスで低レイテンシの読み書きを各リージョンで実現し、リージョン障害にも耐える高可用性DBが必要 | グローバル展開のゲームサービスで、プレイヤーのセッションデータを最寄りリージョンに書き込み、全リージョンで同期 |
|
Amazon CloudFront クロスリージョンオリジン / オリジンフェイルオーバー |
CloudFrontのオリジンにプライマリ・セカンダリを設定し、障害時に自動的に別リージョンのオリジンに切り替える | CDN自体は世界に分散しているが、オリジンが単一リージョンだと障害時にコンテンツを配信できなくなるため | 東京をプライマリ、大阪をセカンダリオリジンとして設定し、東京リージョン障害時も静的サイトの配信を継続 |
|
AWS CloudFormation StackSets クロスリージョン展開 |
単一テンプレートを複数リージョンに同時デプロイする機能（アカウントと組み合わせ可） | マルチリージョン構成のインフラを手動で各リージョンに展開すると一貫性が失われ、ドリフトが発生しやすい | グローバルサービスのVPC・セキュリティグループ・IAMベースラインを東京・バージニア・フランクフルトに一括展開 |
|
Amazon ECR クロスリージョンレプリケーション |
ECRリポジトリ内のコンテナイメージを他リージョンのECRに自動複製する | マルチリージョンのEKS/ECSクラスターが各リージョンのECRからイメージをプルすることでレイテンシと転送コストを削減 | us-east-1でビルドしたイメージをap-northeast-1に自動レプリカし、東京のEKSノードが高速にイメージ取得 |
|
AWS CodePipeline クロスリージョンアクション |
パイプラインのあるステージで別リージョンのリソース（Lambda・CFn・S3等）にアクションを実行する | マルチリージョンデプロイを単一パイプラインで管理し、デプロイシーケンスの一貫性と可視性を確保するため | us-east-1のパイプラインで東京・シンガポール・フランクフルトのCloudFormationスタックを順番にデプロイし、段階展開を実現 |
|
Amazon EventBridge クロスリージョンイベントルーティング |
あるリージョンのEventBridgeバスから別リージョンのバスにイベントを転送するルールを設定する | マルチリージョン構成でイベント駆動アーキテクチャを構築する際、イベントをリージョン間で伝播する必要がある | プライマリリージョンの「インフラ障害検知」イベントをDRリージョンのEventBridgeに転送してフェイルオーバー処理を自動起動 |
|
Amazon Route 53 クロスリージョンフェイルオーバー |
Route 53のヘルスチェックと組み合わせて、プライマリリージョンの障害時にDNSを自動でセカンダリに切り替える | DNSレベルでフェイルオーバーすることでアプリ変更なしにトラフィックをバックアップリージョンに誘導できる | api.example.comを東京にルーティングし、ヘルスチェック失敗時に大阪のALBへ自動切り替えしてRTO最小化 |
|
AWS KMS マルチリージョンキー |
KMSキーのキーマテリアルを複数リージョンで同期し、同一キーIDで暗号化・復号できる機能 | リージョン間でデータを移動する際、暗号化したまま復号・再暗号化なしに転送できる効率的なDRが実現できる | 東京で暗号化したS3オブジェクトをCRRで大阪にレプリカし、大阪で同じキーを使って復号、DRドリルを高速化 |
|
AWS Systems Manager クロスリージョンパラメータ参照 |
Systems Manager Parameter StoreのパラメータをARN指定で別リージョンから参照できる | マルチリージョン展開のアプリで設定値を統一管理しつつ、リージョン間の設定ドリフトを防ぐ | グローバル展開のLambda関数が各リージョンのパラメータを読みつつ、共通設定値は中央リージョンのパラメータを参照 |
3.クロスオリジン（Cross-Origin / CORS）
ブラウザのSame-Origin Policyを安全に回避するための設定です。フロントエンドとバックエンドのドメインが異なるWebアプリで必須となります。
| サービス / 機能名 | 定義 | 存在意義 | ユースケース |
|---|---|---|---|
|
Amazon S3 CORS（クロスオリジンリソースシェアリング） |
S3バケットへのHTTPリクエストを許可するオリジン・メソッド・ヘッダーをバケットポリシーで定義する | ブラウザはデフォルトで異なるオリジンへのXHR/Fetchをブロックするため、S3を直接オリジンとするWebアプリは明示的な許可が必要 | example.comのSPAがS3バケットに直接アップロード（署名付きURL）する際に、CORSでPUTメソッドとContent-Typeヘッダーを許可 |
|
Amazon API Gateway CORS（クロスオリジンリソースシェアリング） |
API GatewayのリソースにOPTIONSメソッドを追加し、Access-Control-Allow-*ヘッダーを返すよう設定する | フロントエンドとバックエンドAPIのドメインが異なる場合（例：app.com → api.example.com）、CORSプリフライトが通過しないとAPIコールが失敗する | ReactアプリがAPI Gatewayを呼び出す際にCORSを有効化し、ブラウザのSame-Origin Policyを安全に回避 |
|
AWS AppSync CORS設定 |
AppSyncのGraphQL APIエンドポイントに対してCORSポリシーを設定し、ブラウザからの直接アクセスを制御する | GraphQL APIをブラウザのJSから直接呼び出す際、CORSが未設定だとブラウザがリクエストをブロックしAPIが利用できない | ReactやVue.jsで構築したダッシュボードがAppSync APIに直接クエリ・ミューテーションを発行できるようCORSを設定 |
4.クロスサービス（Cross-Service）
AWSの複数サービスを連携・統合する機能群です。サービス間の疎結合やオーケストレーションを実現します。
| サービス / 機能名 | 定義 | 存在意義 | ユースケース |
|---|---|---|---|
|
AWS Step Functions クロスサービス連携（SDK統合） |
Step FunctionsのステートマシンからLambda・ECS・DynamoDB・SNS等の複数サービスをSDK統合で直接呼び出す | 複数サービスをまたぐ複雑なビジネスロジックをLambdaで繋ぐ「オーケストレーターLambda」はコスト・複雑性が高く、Step Functionsの直接統合が効率的 | 注文処理ワークフローで在庫確認（Lambda）→決済（外部API）→配送依頼（ECS）→通知（SNS）を状態管理しながら順次実行 |
|
Amazon EventBridge Pipes クロスサービスイベントパイプ |
SQS・DynamoDB Streams・Kinesis等のソースをLambdaでフィルタ・変換し、EventBridge・SNS・Step Functions等のターゲットに接続するフルマネージドパイプ | イベントを受け取って変換し別サービスに渡すグルーコードのLambdaを書かずに、ローコードでイベントパイプラインを構築できる | DynamoDB StreamsのCDCイベントをEventBridge Pipesでフィルタリング・整形し、EventBridgeバス経由で複数Lambdaにファンアウト |
|
AWS Glue クロスサービスデータカタログ連携 |
Glue Data CatalogをAthena・Redshift Spectrum・EMR・Lake Formationから共通メタデータストアとして参照する | 各分析サービスがスキーマ定義を個別に持つと重複管理・不整合が発生するため、単一のカタログを共有ソースとする | S3上のデータレイクのスキーマをGlue Crawlerで自動定義し、AthenaとRedshift Spectrumで同じカタログを使って同一データを分析 |
5.クロスゾーン（Cross-Zone）
AWSのアベイラビリティゾーン（AZ）をまたいでトラフィックを分散する機能です。AZ間の負荷偏りを防ぎ、可用性を高めます。
| サービス / 機能名 | 定義 | 存在意義 | ユースケース |
|---|---|---|---|
|
ALB / NLB / CLB クロスゾーン負荷分散 |
ELBが受け取ったトラフィックを、自身が属するAZだけでなく全AZのターゲットに均等分散する設定 | AZ間でターゲット数が不均等な場合（例：AZ-a 2台、AZ-b 1台）、クロスゾーンなしだとAZ-bのインスタンスに2倍の負荷がかかる | オートスケールでAZ間のインスタンス数が動的に変化するECS環境で、クロスゾーンを有効化してリクエストを均等分散しホットスポットを防ぐ |
|
AWS Global Accelerator クロスゾーンルーティング |
Global Acceleratorのエンドポイントグループ内で、複数AZのエンドポイントにヘルスチェック結果に基づいてトラフィックを分散する | 単一AZ障害時でも他AZに自動的にルーティングすることで、グローバルエンドポイントの可用性を維持する | グローバルユーザー向けAPIで東京リージョンの複数AZにGlobal Acceleratorでクロスゾーン分散し、AZ障害時も高可用性を確保 |
6.その他のクロス系
上記カテゴリに収まらない、クロスアカウント・クロスリージョンを支える基盤的な機能群です。
| サービス / 機能名 | 定義 | 存在意義 | ユースケース |
|---|---|---|---|
|
AWS STS クロスアカウントロール引き受け（AssumeRole） |
あるアカウントのIAMエンティティが別アカウントに定義されたIAMロールを一時的に引き受けて操作を行う | クロスアカウントアクセスの基盤技術。長期的な認証情報を共有せずに、必要最小限の権限を持つ一時的な認証情報を動的に取得できる | CI/CDシステムのIAMロールがdev・staging・prodの各アカウントのロールをAssumeRoleで順次引き受け、デプロイを実行 |
|
AWS Transit Gateway クロスアカウント/クロスリージョンVPC接続 |
Transit Gatewayを複数アカウント（RAM共有）または複数リージョン（ピアリング）に接続し、ハブ&スポーク型のネットワークを構築する | VPC Peeringはフルメッシュが必要で管理が複雑になるため、Transit GatewayをハブにするとO(n)のルート管理でスケールする | 大手企業の100以上のVPCをTGWで接続し、共有サービスVPC（DNS・NTP・監視）への経路を一元管理 |
|
Amazon VPC Peering クロスアカウント/クロスリージョンVPCピアリング |
2つのVPC間にプライベートなIPルーティングを確立する1対1の接続（同一・別アカウント・別リージョン対応） | インターネットを経由せずにVPC間でプライベート通信が必要な場合の最もシンプルな接続手段 | SaaS提供側VPCと顧客VPCをピアリングし、顧客はプライベートIPでSaaSのサービスエンドポイントに直接アクセス |
|
AWS PrivateLink クロスアカウントエンドポイント共有 |
VPCエンドポイントサービスを作成し、別アカウントのVPCからInterface Endpoint経由でプライベートにアクセスする | VPCピアリングと異なりネットワーク全体を共有せず、特定サービスのエンドポイントのみを安全に公開できる（最小権限の原則） | ISVがSaaS APIをPrivateLinkで公開し、顧客は自社VPC内のプライベートIPでAPIにアクセスでき、インターネット露出なしにSaaSを利用 |
7.まとめ
AWSの「クロス」機能は大きく 5つの軸 に分類できます。
| カテゴリ | 主な目的 | 代表機能 |
|---|---|---|
| クロスアカウント | セキュリティ境界を保ちながらリソース共有・一元管理 | RAM, STS AssumeRole, SCPなど |
| クロスリージョン | DR・低レイテンシ・データ冗長化 | S3 CRR, RDSリードレプリカ, Route 53フェイルオーバーなど |
| クロスオリジン（CORS） | ブラウザのSame-Origin PolicyをWebアプリ用に安全に緩和 | S3 CORS, API Gateway CORSなど |
| クロスサービス | 複数AWSサービスの疎結合・オーケストレーション | Step Functions, EventBridge Pipesなど |
| クロスゾーン | AZ間の負荷均等化と可用性向上 | ELBクロスゾーン負荷分散など |
特に マルチアカウント・マルチリージョン構成 を設計する際は、クロスアカウントとクロスリージョンの機能を組み合わせて活用することが重要です。
本記事がどなたかの参考になれば幸いです。