【AWS経験者向け】GCPからAWSリソースを操作するハイブリッド構成
はじめに：単一クラウドの壁を越える
皆さん、こんにちは！「30日間でGCPをマスターするAWSエンジニアの挑戦」シリーズ、26日目へようこそ。
これまでの連載で、私たちはAWSとGCPそれぞれのサービスと設計思想を比較してきました。AWSの圧倒的なサービスラインナップとGCPのシンプルさ、どちらにも独自の強みがあることが分かったはずです。
しかし、現実のビジネスでは、どちらか一方を選ぶのではなく、両方のクラウドを組み合わせてそれぞれの得意分野を活かすマルチクラウド戦略が一般的になってきています。例えば、AWSの既存インフラでWebサービスを運用しながら、GCPの強力なAI/MLサービスを使ってデータを分析するといったユースケースです。
この記事では、GCPからAWSのリソースを安全に、かつ効率的に操作するハイブリッド構成に焦点を当てます。特に、AWSエンジニアにとって最大の課題となる認証・認可とネットワーク接続の解決策を、GCPの視点から徹底的に解説します。
ハイブリッド構成の代表的なユースケース
GCPの強みとAWSの既存インフラを組み合わせることで、以下のようなハイブリッド構成が実現できます：
1. データ分析パイプライン
- シナリオ: AWS S3に保存された膨大なログデータを、GCPのBigQueryで高速に分析したい。
- 解決策: GCPからS3にアクセスして、データをBigQueryに取り込み、分析を実行します。BigQueryのサーバーレスな分析能力を、AWSの既存データレイクと連携させます。
2. 機械学習パイプライン
- シナリオ: AWSで構築したデータパイプラインと、GCPのVertex AIを組み合わせて、高度な機械学習ワークフローを実現したい。
- 解決策: AWSのデータをGCPに転送し、Vertex AIでモデルを学習・デプロイ。推論結果をAWSシステムに返却します。
3. 災害復旧（DR）戦略
- シナリオ: AWSをプライマリ環境とし、GCPをセカンダリ環境として災害復旧体制を構築したい。
- 解決策: 定期的にAWSのデータをGCPにバックアップし、障害時にはGCPでサービスを継続します。
課題1: 認証・認可の解決策 - Workload Identity Federation
GCPからAWSリソースを操作する際の最初の課題は、認証情報の安全な管理です。
従来の方法の問題点
AWSでは、IAMユーザーのアクセスキーとシークレットキーを生成し、それをGCP環境に保存してAWS CLIやSDKでアクセスする方法が一般的でした。しかし、この方法には以下の問題があります：
- 認証情報が平文でGCP環境に保存される
- キーローテーションの管理が困難
- 認証情報漏洩のリスクが高い
- 複数の環境でキー管理が複雑化
GCPのモダンな解決策：Workload Identity Federation
GCPでは、この課題をWorkload Identity Federationで解決します。これは、GCPのサービスアカウントが、AWSの**IAMロールを引き受ける（AssumeRole）**仕組みです。
仕組みの概要
-
AWS側の設定：
- S3へのアクセス権限などを持つIAMロールを作成
- IAMロールの信頼ポリシーに、GCPの認証情報を信頼する設定（OIDC Identity Provider）を追加
-
GCP側の設定：
- サービスアカウントを作成
- Workload Identity Poolを作成し、AWSのIAMロールとマッピング
-
連携の実現：
- GCPのCompute Engineなどのリソースにサービスアカウントをアタッチ
- 自動的にAWSの一時的な認証情報を取得してリソースにアクセス
セキュリティ上のメリット
- 永続的な認証情報が不要: アクセスキーやシークレットキーを保存する必要がない
- 一時的な認証情報: STS（Security Token Service）による短期間有効なトークンを使用
- 細かい権限制御: 必要最小限の権限のみを付与可能
- 監査ログの充実: どのサービスアカウントがいつアクセスしたかを詳細に追跡
課題2: ネットワーク接続の解決策
GCPとAWSのVPCネットワークを接続することも、ハイブリッド構成の重要な要素です。
接続オプションの比較
| 接続方法 | 特徴 | 用途 |
|---|---|---|
| VPN接続 | インターネット経由、暗号化通信 | 開発・テスト環境、低トラフィック |
| 専用線接続 | 物理的な専用回線 | 本番環境、高トラフィック、低レイテンシ要求 |
具体的な設定方法
AWS側：
- VPN接続またはDirect Connectを設定
- ルートテーブルにGCP側のCIDRを追加
- セキュリティグループでGCP側からのアクセスを許可
GCP側：
- Cloud VPNまたはCloud Interconnectを設定
- VPCネットワークのルートにAWS側のCIDRを追加
- ファイアウォールルールでAWS側からのアクセスを許可
GCPのアドバンテージ
GCPのVPCネットワークはグローバルなため、AWSの複数のリージョンと接続する場合でも、GCP側では単一のVPCネットワークで対応できます。これは、AWSでVPCピアリングを多数設定する必要がある場合と比較して、運用を大幅に簡素化できます。
実践ハンズオン：GCPからAWS S3を操作する
Workload Identity Federationを使って、GCPのCompute EngineからAWS S3バケットにアクセスする具体的な手順を解説します。
【AWS側の設定】
- IAMロールの作成：
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:ListBucket"
],
"Resource": [
"arn:aws:s3:::my-hybrid-bucket",
"arn:aws:s3:::my-hybrid-bucket/*"
]
}
]
}
- 信頼ポリシーの設定：
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Federated": "arn:aws:iam::123456789012:oidc-provider/sts.googleapis.com"
},
"Action": "sts:AssumeRoleWithWebIdentity",
"Condition": {
"StringEquals": {
"sts.googleapis.com:sub": "service-account-unique-id"
}
}
}
]
}
【GCP側の設定】
- サービスアカウントの作成：
gcloud iam service-accounts create hybrid-access-sa \
--display-name="Hybrid Access Service Account"
- Workload Identity Poolの作成：
gcloud iam workload-identity-pools create aws-pool \
--location="global" \
--display-name="AWS Pool"
- Workload Identity Pool Providerの作成：
gcloud iam workload-identity-pools providers create-aws aws-provider \
--workload-identity-pool="aws-pool" \
--account-id="123456789012" \
--location="global"
【動作確認】
Compute Engineインスタンスで以下のコマンドを実行：
# AWS CLIの設定（Workload Identity Federation使用）
export AWS_ROLE_ARN="arn:aws:iam::123456789012:role/gcp-hybrid-role"
export AWS_WEB_IDENTITY_TOKEN_FILE="/tmp/gcp_token"
# GCPの認証情報からAWSのトークンを取得
gcloud auth print-access-token > /tmp/gcp_token
# S3へのアクセス確認
aws s3 ls s3://my-hybrid-bucket
監視とログ管理
ハイブリッド構成では、両方のクラウドプラットフォームにまたがる監視が重要です。
推奨される監視戦略
- GCP側: Cloud Monitoring、Cloud Loggingを使用
- AWS側: CloudWatch、CloudTrailを使用
- 統合: 外部のログ集約ツール（Datadog、Splunk等）を検討
セキュリティ監査のポイント
- クロスクラウドアクセスのログを定期的に確認
- 異常なアクセスパターンの検知
- 権限の定期見直し（最小権限の原則）
コスト最適化のベストプラクティス
ハイブリッド構成では、データ転送コストが重要な要素となります。
コスト削減のポイント
-
データ転送の最適化：
- 必要最小限のデータのみを転送
- 圧縮やバッチ処理の活用
- リージョン選択の最適化
-
リソース使用量の監視：
- 両方のクラウドでコスト監視を設定
- 不要なリソースの定期的な棚卸し
-
予約インスタンスの活用：
- 長期利用が確実なリソースは予約割引を活用
まとめ：ハイブリッド構成のメリットと注意点
GCPとAWSを組み合わせたハイブリッド構成は、それぞれのクラウドの強みを活かし、ベンダーロックインを回避できる強力な戦略です。
| 側面 | メリット | 注意点 |
|---|---|---|
| 技術 | それぞれのクラウドの得意分野（GCPのAI/ML、AWSのEC2）を活かせる | 認証、ネットワーク、監視など運用が複雑化する |
| ビジネス | ベンダーロックインを避け、リスクを分散できる | 各クラウドの専門知識を持つ人材が必要 |
| コスト | 最も安価なサービスを組み合わせてコスト最適化が可能 | データ転送料金が高額になる可能性がある |
| セキュリティ | 多層防御によるセキュリティ強化 | 複数環境のセキュリティ管理が複雑 |
成功のためのポイント
- セキュリティファースト: Workload Identity Federationのようなモダンな認証方法を積極的に活用
- 段階的な導入: 小規模な検証から始めて、徐々に適用範囲を拡大
- 運用体制の整備: 両方のクラウドに精通したチームの構築
- 継続的な最適化: 定期的なコスト・パフォーマンス見直し
次回は、これまでの学習内容を総括し、AWSエンジニアがGCPに移行する際にハマりがちな「落とし穴」を10個厳選して解説します。お楽しみに！
この記事が役に立ったという方は、ぜひ「いいね」や「ストック」をお願いします！
シリーズ記事一覧
- [【1日目】はじめの一歩！AWSエンジニアがGCPで最初にやるべきこと]
- [【2日目】GCPのIAMはAWSとどう違う？「プリンシパル」と「ロール」の理解]
- [【3日目】VPCとVPCネットワーク：GCPのネットワーク設計思想を理解する]
- [【4日目】S3とCloud Storage：オブジェクトストレージを徹底比較]
- [【5日目】RDSとCloud SQL：マネージドデータベースの運用管理の違い]
- [【6日目】EC2とCompute Engine：インスタンスの起動から課金モデルまで]
- [【7日目】1週間のまとめ：AWSとGCP、それぞれの得意なことと設計思想]
- [【8日目】EKSとGKE：Kubernetesのマネージドサービスを比較体験！]
- [【9日目】Dockerイメージをどこに置く？ECRとArtifact Registryを比較]
- [【10日目】LambdaとCloud Functions：イベント駆動型サーバーレスの実装]
- [【11日目】API GatewayとCloud Endpoints：API公開のベストプラクティス]
- [【12日目】Cloud Run：サーバーレスでコンテナを動かすGCPの独自サービスを試してみよう]
- [【13日目】AWS FargateとCloud Run：コンテナ運用モデルの根本的な違い]
- [【14日目】2週間のまとめ：GCPのコンテナ・サーバーレス技術はなぜ優れているのか？]
- [【15日目】RedshiftとBigQuery：データウェアハウスのアーキテクチャと料金体系]
- [【16日目】BigQueryをハンズオン！クエリを書いてデータ分析を体験]
- [【17日目】AthenaとBigQuery：データレイクに対するアプローチの違い]
- [【18日目】SageMakerとVertex AI：機械学習プラットフォームの比較]
- [【19日目】BigQuery MLでSQLだけで機械学習モデルを作ってみよう]
- [【20日目】Cloud SQLのレプリカ設定とパフォーマンスチューニング]
- [【21日目】GKE IngressとService Meshの比較]
- [【22日目】CloudWatchとCloud Monitoring：ログとメトリクスの監視設定]
- [【23日目】AWS BackupとGCPのバックアップ戦略：スナップショットとリージョン]
- [【24日目】AWS CloudFormationとGCP Cloud Deployment Manager：IaCのベストプラクティス]
- [【25日目】AWSのEFSとGCPのFilestore：共有ファイルストレージの活用法]
- [【26日目】AWSとの連携：GCPからAWSリソースを操作するハイブリッド構成]（この記事）
- [【27日目】GCP移行時にAWSエンジニアがハマりがちな落とし穴10選]