GCP から AWS への移行｜データ転送とIAMの再設計でハマるポイント

Google Cloud Platform（GCP）から Amazon Web Services（AWS）への移行は、単なるサーバーの引っ越しではありません。プロジェクト単位の管理体系からアカウント単位の管理体系への転換、そして「プロジェクト横断」が標準的なGCPと「デフォルト拒否」が基本のAWSという、セキュリティ思想のギャップを埋める作業が本質です。

本記事では、GCPからAWSへの移行プロジェクトにおいて、特にエンジニアが直面しやすい「データ転送の技術的障壁」と「IAM（Identity and Access Management）の再設計」に焦点を当て、実務上のハマりどころと回避策を網羅的に解説します。

1. データ転送の「詰まりどころ」と最適解

クラウド間移行で最大のボトルネックとなるのがデータ転送です。特にGCPからAWSへの移行では、下り外向きネットワーク転送（Egress）料金のコストインパクトを無視できません。

1.1. AWS DataSyncを用いたGCSからのオンライン転送

Cloud Storage（GCS）から Amazon S3 への移行において、最も推奨されるのは AWS DataSync の活用です。DataSyncは、GCSをソースとして直接指定できるようになっており、転送のスケジューリング、整合性チェック、帯域制限をマネージドで行えます。

• ハマりポイント： GCSの「バケットレベルのアクセス」設定。AWS DataSyncからアクセスする場合、GCS側で適切なサービスアカウントを作成し、HMACキーを発行する必要があります。
• 公式情報： AWS DataSync 公式ドキュメントによれば、転送データ1GBあたりの利用料は0.0125USD（2024年時点の東京リージョン）ですが、これとは別にGCP側のEgress料金が発生することを忘れてはいけません。

1.2. BigQueryデータの移行：Parquet経由の「S3バケットへの着地」

BigQueryから Amazon Redshift や Athena への移行では、一度 GCS へ Avro または Parquet 形式でエクスポートする必要があります。特に、スキーマ情報を保持できる Parquet 形式は、AWS側でのクロール（AWS Glue等）と相性が非常に良いです。

データ基盤の移行に関しては、こちらの記事で紹介しているようなモダンデータスタックの考え方が非常に参考になります。

高額なCDPは不要？BigQuery・dbt・リバースETLで構築する「モダンデータスタック」ツール選定と公式事例

1.3. データ転送コスト（Egress料金）の試算

GCPのEgress料金は、インターネット経由の場合、10TB以上の転送で1GBあたり 0.08USD〜0.12USD 程度かかります（リージョンによる）。100TBの移行であれば、ネットワーク料金だけで1万ドル以上のコストが発生する計算です。

2. 権限設計（IAM）の再構築：ハマりやすい構造の決定的な違い

GCPユーザーがAWSに移行して最も困惑するのが「IAMの階層構造」です。

2.1. 「リソース階層」の読み替え

GCPは「組織 ＞ フォルダ ＞ プロジェクト」というツリー構造を持ち、上位階層の権限が下位に継承されます。一方、AWSは「AWS Organizations」による組織管理はあるものの、基本的には「アカウント」が強固な境界線となります。

• GCP: プロジェクトをまたいだリソース操作が比較的容易。
• AWS: アカウントをまたぐ場合は「AssumeRole（ロールの引き受け）」という明示的なアクションが必須。

2.2. Google Workspaceを活用したSAML連携

GCPを利用している企業の多くは Google Workspace（Cloud Identity）をID基盤としています。AWS移行後も、IAMユーザーを個別に作成するのはセキュリティリスクが高い（退職者の削除漏れ等が発生する）ため、AWS IAM Identity Center を用いたシングルサインオン（SSO）の設定が必須です。

アカウント管理の自動化については、以下の記事で解説している「プロビジョニングの自動化」の概念がAWS環境でもそのまま適用できます。

SaaS増えすぎ問題と退職者のアカウント削除漏れを防ぐ。Entra ID・Okta・ジョーシスを活用した自動化アーキテクチャ

2.3. サービスアカウントを「IAM Role」と「OIDC」で置き換える

GCPの「サービスアカウントキー（JSON形式）」をダウンロードしてサーバーに配置する運用は、AWSでは厳禁です。AWSでは IAM Role を使用し、EC2やLambdaに対して一時的な認証情報を付与します。

もし、GCP上のリソース（Cloud Run等）からAWSのリソース（S3等）にアクセスする必要がある場合は、IAM Roles Anywhere や OIDC（OpenID Connect） を利用したキーレス認証を設計してください。

3. 【比較表】GCP vs AWS 主要サービス対応表

移行先の選定に迷った際のクイックリファレンスです。名称は似ていても仕様が大きく異なるものに注釈を入れています。

4. ネットワークとセキュリティの再設計

4.1. VPC設計の大きな違い

GCPのVPCは「グローバルリソース」であり、一つのVPC内に異なるリージョンのサブネットを含めることができます。対して、AWSのVPCは「リージョンリソース」です。マルチリージョン展開をする場合、AWSではリージョンごとにVPCを作成し、VPC Peering や Transit Gateway で接続する必要があります。

4.2. セキュリティグループの運用

GCPのファイアウォールルールは「タグ」ベースで適用するのが一般的ですが、AWSでは セキュリティグループ（SG） を使用します。
SGの最大の特徴は「ステートフル」であることです。戻り通信を明示的に許可する必要はありませんが、インスタンス1台にアタッチできるSGの数や、1つのSGあたりのルール数には上限（デフォルトで60等）があるため、GCP時代よりも細粒度な設計が求められます。

インフラの最適化と同時に、既存のSaaSコストやオンプレミス負債の整理を行うことも、移行プロジェクトの投資対効果を高める重要なステップです。

SaaSコストとオンプレ負債を断つ。バックオフィス＆インフラの「標的」と現実的剥がし方（事例付）

5. 移行ステップガイド：要件定義からカットオーバーまで

移行を確実に進めるための推奨ステップです。

1. インベントリ収集： 現在GCPで使用しているプロジェクト、サービスアカウント、API利用状況、データ容量をすべてリストアップする。
2. AWSランディングゾーンの構築： AWS Organizations、IAM Identity Center、Control Towerを使用し、マルチアカウント管理の土台を作る。
3. PoC（概念実証）： 最も依存関係の少ないシステムを一つ選び、DataSyncでの転送とIAM Roleによる動作確認を行う。
4. データ移行の先行実施： 蓄積された履歴データ（BigQueryやGCS）を先行して転送し、差分更新のみをカットオーバー時に行う体制を作る。
5. DNS切り替えと監視の開始： Cloud DNSから Amazon Route 53 への切り替え。同時に CloudWatch でのメトリクス監視が正常に動いているか確認する。

実務者へのアドバイス：

GCPの Cloud Logging は非常に強力で、適当にログを吐き出しても柔軟に検索できますが、AWS CloudWatch Logs は「ロググループ」と「ログストリーム」の設計をしっかり行わないと、調査時に苦労します。ログの保持期間（Retention）の設定もデフォルトでは「無期限」になるため、コスト管理の観点から必ず設定を見直してください。

6. まとめ：インフラの負債を解消する移行へ

GCPからAWSへの移行は、単なるプラットフォームの変更ではなく、組織のガバナンスを再定義する機会です。特にデータ転送においては、AWS DataSync のようなマネージドサービスをフル活用して運用負荷を下げることが成功の鍵となります。また、IAMの再設計では「誰が・どのロールで・何をするか」をGoogle Workspaceと連携させながら定義し直すことで、GCP時代よりもセキュアな環境を構築することが可能です。

移行の詳細は、常に AWS 公式ドキュメント および Google Cloud 公式ドキュメント の最新の仕様を確認しながら進めてください。特に料金体系は頻繁にアップデートされるため、事前の試算がプロジェクトの成否を分けます。