ちょっと攻めたセッションに参加してきました。笑
本セッションでは、AWSの開発エンジニアの方がGoogle Cloudに移行または併用する際に知っておくべき基本の考え方・リソース構成の違い・ツール比較・移行のdemoが解説されました。

セッション概要

• タイトル
  • From AWS to Google Cloud: Expand your cloud toolkit
• スピーカー
  • Megan O’Keefe
    • Head of Cloud Platform Evaluations,Google Cloud
  • Marco Ferrari
    • Cloud Solutions Architect,Google Cloud
• 概要(公式)
  • Amazon Web Services（AWS）デベロッパーとして、Google Cloud を初めてご利用になる方、あるいはマルチクラウドのスキルをさらに深めたいとお考えの方はいらっしゃいませんか？リソースとアクセス管理からネットワーク、SDK まで、Google Cloud のあらゆる側面を網羅した、駆け足のツアーにぜひご参加ください。ハイパースケーラーの移行を支援する Google Cloud のフレームワークについて解説します。さらに、AWS アプリケーションを Google Kubernetes Engine（GKE）と Cloud SQL に移行する方法（Database Migration Service（DMS）、GKE クラスタの作成、コンテナイメージの移行、CI/CD など）を実演します。このツアーに参加することで、Google Cloud の仕組み、AWS との主な類似点と相違点、そして開始に必要なリソースについて理解を深めることができます。

まとめ

• Google CloudはグローバルVPCやIAMロールの扱いなど、構成思想に独自性がある
• TerraformやDMSなどを活用すれば、AWS→GCPへのマイグレーションも簡単に行える
• EKS→GKEやRDS→Cloud SQLなど、よくある移行パターンに沿ったデモの実施
• 実際のマイグレーションは「段階的」に、かつダウンタイムを抑えて行うことが推奨される

AWSのマネージドコンソールやサービスに慣れ親しんでいる私にとっては、
それぞれの特徴や違いの両方が整理された、とても実用的なセッションでした！

GCPとAWSの共通点と主な違い

共通点

• 両者ともスケーラブルなクラウドプラットフォーム
• IAMによるアクセス制御、CLIやAPIの操作手段あり
• Terraform等のインフラ構成管理ツールが使える

主な違い

• リソース階層の構成：
  • AWS：Organization → OU → Account
  • GCP：Organization → Folder → Project（IAMもFolder単位で制御可能）
• ネットワーク構成：
  • AWS：VPCやSubnetは「リージョンに強く依存」
  • GCP：VPCは「グローバル」、Subnetは「リージョン単位」
• IAMの概念差：
  • AWSの“Role”は「実行主体」だが、GCPでは「権限の束」
  • GCPでは〜Service Accountの扱いが中心

マイグレーション戦略：4段階フレームワークで進める

Migration Frameworkとして4つのフェーズの進め方を推奨。
この辺りはAWSと同じですね。

1. Assess（評価）：アプリと依存関係を棚卸し、ビジネスクリティカル度などを把握
2. Plan（計画）：Landing Zone（IAM, Networking, Project構成など）を準備
3. Deploy（移行）：DMS、Migrate to VMs、Migrate to Containersなどを活用
4. Optimize（最適化）：コスト・性能チューニング、CI/CD改善など

すべてを一括で移行するのではなく、用途に応じてハイブリッド戦略を取ることが推奨。

---

デモ：AWSアプリケーションをGoogle Cloudに“高速マイグレーション”

デモでは、金融系アプリ「Simple Bank」を以下のステップでAWS→GCPへ移行する方法を実演されておりました。

1. RDS → Cloud SQL（Database Migration Service使用）
2. ECR → Artifact Registry（コンテナイメージのリホスティング）
3. EKS → GKE Autopilot（GitHub ActionsとCustomizeでCI/CDを再設計）
4. Terraformによるインフラ構築の自動化

移行後のGKE上でアプリが正常に動作し、データベースにも正しくアクセスできることが確認されました。ダウンタイムの部分は実演されていなかった気がします。

Tips：レガシーシステムやダウンタイム要件にも対応可

セッション終盤では、より複雑なユースケースへの対応として以下も紹介されました：

• CI/CDの再設計が肝となるEKS→GKEの移行
• ゼロダウンタイムを求める場合のサービスメッシュ活用（例：Anthos）
• 設計者不在のレガシーVMをそのままLift & Shiftするケースへの対応

さらに、マルチクラウド前提の構成（例：AWSをDR先として再利用）も紹介され、
移行後の柔軟な運用体制づくりにも言及がありました。

AWS経験者こそ“GCP流”を学ぶ価値がある

このセッションは、AWSエンジニアにとってGoogle Cloudの世界を親しみやすく解き明かしてくれるガイドのような形でした。なので、どっちを使うべきという話ではなく、マルチクラウドも考慮した構成のガイドもありました。

あくまでクラウドは手段なので、その時々の状況で最適な手段を選択できるといいなと思います。
その際に、GCPはAWSと同等、もしくはそれ以上の機能を持ちながらも、
リソース設計やIAMの思想が異なるため、きちんとGCPについても理解しておくことが重要だと感じたセッションでした！