本稿はAmazon ECSからGoogle Cloud Vertex AI APIをコールする環境の構築を検証したため、知見の共有です。
ECSはCICDパイプラインを構成している環境も多くあるかと思いますが、今回はマネジメントコンソールからの設定を紹介します。

Google Cloudの組織やプロジェクトの権限については今回の説明からは割愛します。
Vertex AIはService Perimeter（サービス境界）とAccess Context ManagerでAWSのNAT GatewayのパブリックIPアドレスのみを通信許可し、セキュリティを強化した構成になります。
ECSからVertex AIのコールの認証はWorkload Identityを使用する方法もありますが、考慮事項が多いため、ここではサービスアカウントキーを利用した認証を想定しています。

すでにECSでアプリケーションが稼働している環境に対する追加を想定した設定になるので、ご留意ください。
尚、筆者はAWSの知見はあるもののGoogle Cloudは今回初めて触れた程度の技術レベルになります。

アーキテクチャ

構築

Google Cloud

Vertex AI APIのサービス有効化

  1. Google Cloudのクラウド管理コンソールからAPIとサービスを選択
  2. APIとサービスを有効にするを選択
  3. Vertex AI API を選択し、有効化する。

Access Context Managerの設定

  1. Google CloudのコンソールからAccess Context Managerを選択
  2. アクセスレベルを作成を選択
  3. IPサブネットワークでパブリックIPを選択し、AWSのNAT GatewayのパブリックIPアドレスを設定する。

VPC Service ControlsでService Perimeter（サービス境界）の設定

  1. Google Cloudのクラウド管理コンソールから新しい境界を選択
  2. サービス境界の詳細を設定する。

サービスアカウントの作成

  1. Google Cloudのクラウド管理コンソールでIAMと管理からサービスアカウントを選択
  2. サービスアカウントを作成する。

サービスアカウントキーの作成

AWS

Secrets Managerでシークレット作成

  1. AWSのマネジメントコンソールからSecrets Managerを選択
  2. 新しいシークレットを保存するを選択
  3. Google Cloudのサービスアカウントキー作成でダウンロードしたJSONを使用してシークレットを設定する。

ECSタスク定義に環境変数を設定

  1. AWSのマネジメントコンソールからElastic Container Serviceを選択
  2. タスク定義から対象のECSタスク定義を選択し、新しいリビジョンの作成を選択
  3. タスク定義に環境変数し、作成したシークレットのARNを設定する。

上記の設定を行うことにより、ECSからVertex AI APIをコールする環境が整います。

テスト

今回はECSからVertex AI APIをコールする設定を行いましたが、Service Perimeter（サービス境界）とAccess Context Managerとの組み合わせによる制限が正しく機能しているかのテストをローカル環境から行いました。
テストの方法をご紹介します。
実際にECSにアプリケーションをデプロイしている場合はECSからテストをしてみてください。

事前準備

  1. ローカルPCにgcloud CLIをインストールする。（参考：gcloud CLIをインストールする)
  2. サービスアカウントキーをgcloud CLIにセットする。
    gcloud auth activate-service-account --key-file={任意のパス}/xxxx-123456789.json

テストパターン

  1. Access Context ManagerでローカルPCのパブリックIPアドレスが許可されている状態でVertex AI APIをコールしドライフラワー専門店の名称の回答があったか。
  2. Access Context ManagerでローカルPCのパブリックIPアドレスが許可されていない状態でVertex AI APIをコールし拒否されたか。

テスト実施

  1. curlコマンドでVertex AI APIをコールして、Gemini 2.0 Flashにドライフラワー専門店の名称を考えてもらう。 
    curl -X POST -H "Authorization: Bearer $(gcloud auth print-access-token)" -H "Content-Type: application/json" https://aiplatform.googleapis.com/v1/projects/{プロジェクト名}/locations/global/publishers/google/models/gemini-2.0-flash-001:generateContent -d $'{
  "contents": {
    "role": "user",
    "parts": [
      {
        "text": "What\'s a good name for a flower shop that specializes in selling bouquets of dried flowers?"
      }
    ]
  }
}'

許可したパブリックIPアドレスでのテスト結果

Gemini 2.0 Flashからドライフラワー専門店の名称の回答がありました。

許可していないパブリックIPアドレスでのテスト結果

VPC Service Controlsで拒否されていることがわかります。

総評

今回の検証は、AWSとGoogle Cloudのサービスを組み合わせ、セキュリティと利便性を両立させたハイブリッドクラウド構成を、Google Cloudの知見がほぼ無い状況から確立できたという点で、個人的には非常に価値のあるものでした。

特に、Google Cloudの強力なセキュリティ機能であるVPC Service Controls（Service Perimeter）とAccess Context Managerを組み合わせて、AWS側のアクセス元IPアドレス（NAT GatewayのパブリックIP）を厳格に制限できた点は、セキュリティ要件の高いシステムを構築する上での重要な知見の1つになると思います。

AWSの視点から見たGoogle Cloudのセキュリティ機能

AWSに慣れている筆者にとって、Google Cloudのセキュリティモデルは新鮮であり、その強力さを実感しました。

観点 AWSでの類似機能 Google Cloud（今回活用した機能） Google Cloudの特筆すべき点
リソースへのアクセス制御 ネットワークACL、セキュリティグループ Access Context Manager IDだけでなく、ロケーション（IPアドレス）やデバイス情報など、より詳細なコンテキストに基づいてアクセスを制御できる柔軟性がある。
サービスレベルのセキュリティ S3などのリソースポリシーとVPCエンドポイントポリシーの組み合わせ VPC Service Controls（Service Perimeter） サービス全体をネットワーク的な境界で保護し、意図しないデータ漏洩を防ぐ仕組みが強力かつ統合されている。

AWSのNAT GatewayのパブリックIPアドレスを信頼できるアクセス元として許可するというアプローチは、セキュリティグループやネットワークACLのインバウンドルールにIPアドレスを制限するAWSの考え方と類似しているため、AWSの知見がスムーズに活かせたポイントと言えます。

検証から得られた主要な学び

ハイブリッドクラウド連携におけるセキュリティモデルの理解

AWSとGoogle Cloudでは、認証・認可の仕組みやネットワークセキュリティの概念に違いがあるため、それぞれのクラウドの特性を理解した上で連携させる必要性を痛感しました。

  • AWS ECS: コンテナを実行する環境として、従来のAWSの知見（VPC、サブネット、NAT Gateway）がスムーズに適用できました。
  • Google Cloud Vertex AI API: アクセス制限の要となるVPC Service Controlsの「Service Perimeter（サービス境界）」と「Access Context Manager」の概念や設定の学習に1〜2時間程度かかったものの、一度設定してしまえば、外部からの不正アクセスに対して非常に強固な防御壁を築けることがわかりました。

Access Context Managerの強力な柔軟性

AWSのセキュリティグループのようなネットワーク層の制御だけでなく、Access Context Managerが提供するアクセスレベルは、IPアドレス（地理情報を含む）、ユーザーID、デバイスの状態など、多角的な要素でアクセスを定義できるため、ゼロトラストの考え方を実現する上で非常に有用です。

トラブルシューティングについて

ハイブリッドクラウド構成では、AWS側の問題なのか、Google Cloud側の問題なのか、あるいは両者の連携部分の問題なのかを切り分ける作業が単一クラウドに比べて複雑になります。
特に、サービス境界内でアクセス拒否が発生した場合、詳細なログを追跡するスキルが求められるとは思いますが、今回の検証では特にトラブルは発生しませんでした。

今後の展望

今回の検証で、ハイブリッドクラウド環境でのセキュアなAI/ML活用基盤の礎ができました。今後は、以下の点を検討することで、より実運用に耐えうる構成を目指せると思います。

  1. より洗練された認証: 今回はIPアドレス制限を用いましたが、将来的にはAWSのWorkload Identity Federation（AWSのIAMロールとGoogle Cloudのサービスアカウントを連携させる仕組み）を導入することで、鍵情報（APIキーなど）を持たずに、よりセキュアかつ動的にVertex AI APIへアクセスする構成を検討できます。
  2. ログとモニタリングの統合: AWSのCloudWatchとGoogle CloudのCloud Logging/Cloud Monitoringを統合的に監視できる仕組み（例：サードパーティ製のモニタリングツール）を導入し、障害発生時の迅速な原因特定を目指します。
  3. Infrastructure as Code (IaC)の適用: 今回構築したAWSとGoogle Cloudの設定をTerraformなどのIaCツールでコード化し、再現性と変更管理の容易性を高めることを推奨します。

参考ドキュメント

VPC Service Controls – サービス境界の概要
Access Context Managerの概要
サービスアカウントの概要
gcloud CLIのインストール
Vertex AIの生成AIの概要
Generative AI on Vertex AI – Documentation – Creative naming