Pulumiでマルチクラウド（AWS & GCP）インフラを統合管理する実践アーキテクチャ
こんにちは。テックリードの私だ。
日々のインフラ開発において、「AWSのVPCとGCPのVPCをセキュアに直結したい」「フロントエンドはAWS、データ分析基盤はGCPで適材適所に配置したい」といった要件に直面したことはないだろうか。
ここでHCL（Terraform）やYAMLの山に絶望するのは終わりだ。
今回は、Pulumiを用いてAWSとGCPを同一のプログラム（TypeScript / Pythonなど）で統合管理し、開発スピードを極限まで高める実践アーキテクチャを解説する。
マルチクラウドの複雑性をコードの表現力でねじ伏せ、明日からチーム全員の生産性を劇的に引き上げるためのノウハウを凝縮した。さあ、深淵へ入ろう。
—
1. マルチクラウド運用の課題とPulumiの優位性
混沌極まるマルチクラウドの現状
AWSのCloudFormation / CDK、GCPのDeployment Manager / Terraform……。クラウドごとに異なるツールや言語を強制されるのは、エンジニアの認知負荷を無駄に高めるだけであり、セキュリティポリシーの統一やコードのDRY（Don’t Repeat Yourself）原則の崩壊を招く。
なぜPulumiなのか？
Pulumiは、宣言型インフラストラクチャを汎用プログラミング言語（TypeScript, Python, Go, C#など）で記述できる。
これにより、以下のような圧倒的な優位性が生まれる。
- 言語の統一: AWSもGCPも、同一のプロジェクト内でシームレスに記述・連携できる。
- 強力な抽象化とロジック: 制御構文（`for`, `if`）や関数、クラスを用いた洗練されたリソース定義。
- 型安全（Type Safety）: IDEの補完機能により、存在しないプロパティや誤った型を指定した瞬間にエラーを検知。
—
2. 同一プロジェクト内でAWSとGCPのリソースを連携させるコード例
百聞は一見にしかず。AWSのVPC内に生成した演算リソース（ECS/EKSなど）から、GCP側のBigQueryやCloud Storage（GCS）へセキュアにアクセスするアーキテクチャを想定したTypeScriptコードを見てほしい。
プロジェクト構成（ベストプラクティス）
.
├── Pulumi.yaml
├── Pulumi.dev.yaml
├── Pulumi.prod.yaml
├── package.json
├── tsconfig.json
└── index.ts
実装コード (`index.ts`)
import as pulumi from “@pulumi/pulumi”;
import as aws from “@pulumi/aws”;
import as gcp from “@pulumi/gcp”;
// 1. 設定情報の取得
const config = new pulumi.Config();
const environment = pulumi.getStack(); // “dev” または “prod”
const awsRegion = config.require(“awsRegion”);
const gcpProject = config.require(“gcpProject”);
const gcpRegion = config.require(“gcpRegion”);
// ———————————————————
// AWS リソース定義: セキュアなVPCとプライベートサブネット
// ———————————————————
const awsVpc = new aws.ec2.Vpc(`main-vpc-${environment}`, {
cidrBlock: “10.100.0.0/16”,
enableDnsHostnames: true,
enableDnsSupport: true,
tags: { Name: `vpc-${environment}`, Environment: environment },
});
const awsSubnet = new aws.ec2.Subnet(`main-subnet-${environment}`, {
vpcId: awsVpc.id,
cidrBlock: “10.100.1.0/24”,
availabilityZone: `${awsRegion}a`,
tags: { Name: `subnet-${environment}` },
});
// ———————————————————
// GCP リソース定義: データ分析用のGCSバケット
// ———————————————————
const gcsBucket = new gcp.storage.Bucket(`analytics-bucket-${environment}`, {
name: `my-org-analytics-${environment}-${gcpProject}`,
location: gcpRegion,
forceDestroy: environment !== “prod”, // 本番以外は強制削除を許可
uniformBucketLevelAccess: true,
cors: [{
origins: [“https://example.com”],
methods: [“GET”, “HEAD”],
responseHeaders: [“”],
maxAgeSeconds: 3600,
}],
});
// ———————————————————
// マルチクラウドの連携: GCPバケットへのアクセス権をAWS側のIAMに紐付ける
// ———————————————————
// 注: 実際にはAWS OIDC Identity ProviderをGCP IAMに登録する設定を行う
const gcpServiceAccount = new gcp.serviceaccount.Account(`aws-connector-${environment}`, {
accountId: `aws-connector-${environment}`,
displayName: `Service Account for AWS workloads in ${environment}`,
});
// GCPバケットの読み取り権限をGCPサービスアカウントに付与
const bucketBinding = new gcp.storage.BucketIAMMember(`bucket-viewer-${environment}`, {
bucket: gcsBucket.name,
role: “roles/storage.objectViewer”,
member: pulumi.interpolate`serviceAccount:${gcpServiceAccount.email}`,
});
// ———————————————————
// エクスポート（Outputs）
// ———————————————————
export const awsVpcId = awsVpc.id;
export const gcpBucketName = gcsBucket.name;
export const gcpServiceAccountEmail = gcpServiceAccount.email;
このコードの美しさは、AWSのVPCオブジェクトとGCPのバケット・サービスアカウントが同一のグラフ上で管理され、依存関係が自動解決される点にある。
—
3. 共通設定と環境ごとのパラメータ管理（Stackの活用）
マルチクラウド環境において、環境差異（dev/staging/prod）の管理は頭痛の種だ。Pulumiの Stack と Config 機構を使えば、これを美しく解決できる。
設定ファイルのベストプラクティス (`Pulumi.dev.yaml`)
暗号化が必要な機密情報（DBパスワードやAPIトークンなど）は、`pulumi config set –secret` を用いることで、ソルト付きAES-256で暗号化され、Gitリポジトリに安全にコミットできる。
encryptionsalt: v1:xxxxxx… # Pulumiによって自動生成される暗号化ソルト
config:
# AWS関連パラメータ
aws:region: ap-northeast-1
my-multicloud-project:awsRegion: ap-northeast-1
# GCP関連パラメータ
gcp:project: my-company-dev-gcp
gcp:region: asia-northeast1
my-multicloud-project:gcpProject: my-company-dev-gcp
my-multicloud-project:gcpRegion: asia-northeast1
# 機密情報の例（暗号化済み）
my-multicloud-project:dbPassword:
secure: v1:YYYYYY…==
—
4. 障害に強いインフラ構成のコード設計
プロダクション環境で最も恐れるべきは、「デプロイ失敗によるインフラの破損」や「マルチクラウド間でのデッドロック」だ。障害に強いコードを書くための鉄則を授ける。
1. 暗黙的依存関係の過信を禁ず (`dependsOn`)
クロスクラウド間の連携では、Pulumiのエンジンが推論できない暗黙の依存関係が存在することがある。明示的な `dependsOn` オプションを用いて、確実にリソース作成順序を制御せよ。
2. プレビュー（`pulumi preview`）のCI/CD強制
本番適用前に必ず差分を確認するパイプラインを構築する。
3. 冪等性の破壊を防ぐ命名規則
リソース名に `environment` やランダムサフィックス（`pulumi.random.RandomString`）を組み込み、名前の衝突によるデプロイ失敗を予防する。
—
🛠 プロの生産性を爆上げする開発環境ハック
ここからは、チーム全体の生産性を10倍にする「隠された実務テクニック」を公開する。
1. 開発スピードを劇的に高めるキーボードショートカット (VSCode)
- `Cmd + Shift + P` (Mac) / `Ctrl + Shift + P` (Win) -> “Pulumi: Refresh Stack”:
クラウド側の実状態とStateファイルの乖離を瞬時に同期。
- インテリセンスの活用:
TypeScriptの型定義のおかげで、`aws.ec2.VpcArgs` と打ち込むだけで、必要なパラメータがすべてサジェストされる。ドキュメントを行ったり来たりする時間はもう終わった。
2. 絶対入れるべき神プラグイン (VSCode / IDE)
- Pulumi Visualizer (拡張機能):
コードから生成されるリソースグラフを視覚的にツリー表示。複雑な依存関係が一目でわかる。
- SonarLint / ESLint (TypeScript用):
Pulumiコード特有の非同期処理（Promise）のし忘れや、不正なプロパティ定義をビルド前に静的解析で検知するルールをチームで共有せよ。
3. チーム開発で役立つ設定の共有化ルール
- `Pulumi.yaml` はチームの憲法:
プロジェクト名やランタイム設定は必ずGit管理し、個人の環境差異は `Pulumi.
- Secrets Providerの統一:
チーム開発では、デフォルトのPulumi Serviceバックエンド、または AWS KMS / HashiCorp Vault などの外部Secrets Providerを必ず指定し、暗号化の鍵をチーム全員で安全に共有する体制を築くこと。
—
結びにかえて
Pulumiによるマルチクラウド運用は、単なる「ツール選びの好み」ではない。それは、インフラを「単なる設定ファイルの集合」から「美しくテスト可能なアプリケーションコード」へと昇華させるパラダイムシフトだ。
AWSとGCPの壁をコードの力でシームレスに繋ぎ、強靭でモダンなインフラストラクチャをあなたの手で構築してほしい。チームの未来の生産性は、今日のあなたのコードにかかっている。