ヘッドウォータース
👻

ターミナルで Azure / AWS / GCP をまとめて扱う「Cloud‑Native Shell」について

Iwaki
に公開
AWS
Google Cloud
Azure
インフラ
architecture
tech

1ターミナルで Azure / AWS / GCP をまとめて扱う「Cloud‑Native Shell」について

作成日: 2025-11-10

目的: ローカル or クラウド上の 1つのシェル から、Azure/AWS/GCPに安全にログインし、IaC・Kubernetes・日常運用をシームレスに行うための最小セットを、コピペで再現できるようにまとめます。

全体像（3つの選択肢）

  1. ローカル端末に統合CLI環境を作る（推奨）
    • aws / az / gcloud + 認証まわり（aws-vault / ADC / az login）を揃え、direnvでディレクトリごとに自動切替。
  2. クラウドのホスト型シェルをベースにする
    • 例: Azure Cloud Shell / Google Cloud Shell / AWS CloudShell。中に他クラウドCLIを追加して疑似・統合も可能（Azure Cloud ShellにAWS CLIを追加 など）。
  3. コンテナ/Dev Containerで“同じ開発シェル”を共有
    • VS Code Dev Containers / Docker イメージに必要ツールを同梱し、チームで再現性の高いシェルを共有。

インストール（macOS/Linux想定）

# 共通: パッケージ類（例: Homebrew on macOS）
# macOS
/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

brew install   awscli azure-cli google-cloud-sdk direnv   kubectl kubectx   tfenv pulumi   fzf jq yq

# (任意) プロンプトにクラウド情報を出す
brew install starship
echo 'eval "$(starship init bash)"' >> ~/.bashrc  # または zsh
  • kubectx/kubens は K8s のコンテキスト/Namespace切替を爆速にします。
  • tfenv は Terraform のバージョン切り替え、pulumi はマルチクラウドIaC。
  • starship はプロンプトに AWS_PROFILE などを表示でき、誤操作の防止に役立ちます。

認証の基本セット

AWS（aws-vault で安全に）

brew install --cask aws-vault  # または brew install aws-vault
# ~/.aws/config 例
cat >> ~/.aws/config <<'EOF'
[profile dev]
region=ap-northeast-1
output=json
EOF

# セットアップ（最初の1回）: キーチェーン/Keyringに保存
aws-vault add dev

# 使うとき（カレントシェルに一時クレデンシャルを供給）
aws-vault exec dev -- aws sts get-caller-identity
  • aws-vault は OS の安全なキーストアに長期キーを保管し、一時クレデンシャルで操作します。

GCP（ADC: Application Default Credentials）

# gcloud CLI のログイン（gcloud 用）
gcloud auth login

# SDK/ライブラリ/terraform 等から使える ADC をセット
gcloud auth application-default login

# 確認
gcloud auth application-default print-access-token
  • gcloud auth login は gcloud CLI 用、gcloud auth application-default login は ADC を作成します（使い分けが重要）。

Azure（az login とサブスクリプション選択）

az login  # ブラウザで認証
az account list -o table
az account set --subscription "<SUBSCRIPTION_NAME_OR_ID>"
az account show -o table

ディレクトリ単位で“自動切替”する（direnv）

プロジェクトごとにクラウドやアカウントが違うと、手動エクスポートのミスが致命傷になりがち。direnv でディレクトリに入るだけで安全に切替します。

# シェル起動時に direnv を有効化（bash の例）
echo 'eval "$(direnv hook bash)"' >> ~/.bashrc

# プロジェクト直下に .envrc を置く例（AWS+GCP+Azure）
cat > .envrc <<'EOF'
# 安全: 明示したものだけエクスポート
set -a

# AWS は aws-vault 経由で一時クレデンシャルを注入
# 実行シェルをラップする場合
# use aws-vault dev

# 直接プロファイルを指す（必要に応じて）
export AWS_PROFILE=dev
export AWS_REGION=ap-northeast-1

# GCP: ADC へのパスを切替（複数プロジェクト用に ADC を分けている場合）
export GOOGLE_APPLICATION_CREDENTIALS="$HOME/.config/gcloud/application_default_credentials.json"

# Azure: 既定サブスクリプションを固定したい場合の補助（必要に応じて）
export AZURE_DEFAULTS_GROUP=my-rg
export AZURE_DEFAULTS_LOCATION=japaneast

set +a
EOF

direnv allow  # 初回のみ
  • ディレクトリ移動だけで AWS_PROFILE や GOOGLE_APPLICATION_CREDENTIALS が自動で切替。
  • aws-vault と組み合わせると、常に短命トークンで運用できます。

Kubernetes を複数クラウドで扱う

# コンテキスト一覧
kubectx

# 切替
kubectx eks-dev          # 例: AWS の EKS
kubectx aks-staging      # 例: Azure の AKS
kubectx gke-prod         # 例: GCP の GKE

# Namespace も素早く
kubens
kubens kube-system
  • kubectx / kubens で入力ミスを減らし、誤クラスター操作を防ぎます。

IaC の利用例（Terraform / Pulumi）

Terraform（宣言型）

# providers.tf
terraform { required_providers = {
  aws     = { source = "hashicorp/aws",    version = "~> 5.0" }
  azurerm = { source = "hashicorp/azurerm", version = "~> 4.0" }
  google  = { source = "hashicorp/google",  version = "~> 6.0" }
}}

provider "aws"    { region = "ap-northeast-1" }
provider "azurerm"{ features = {} }
provider "google" { project = "my-proj", region = "asia-northeast1" }
  • 同一ワークフローで複数クラウドを計画/適用でき、CI/CD にも載せやすい。

Pulumi（汎用言語で記述）

// Pulumi (TypeScript) 例
import * as aws from "@pulumi/aws";
import * as azure from "@pulumi/azure-native";
import * as gcp from "@pulumi/gcp";

const bucket = new gcp.storage.Bucket("assets");
const rg     = new azure.resources.ResourceGroup("rg");
const queue  = new aws.sqs.Queue("q");
  • 既存のプログラミング言語で条件分岐・ループ・テストを活用できます。

1画面で整理するときに注意する点

  • プロンプトに今のアカウント/サブスクを表示（Starship の aws/gcloud/azure モジュール）。
  • 読み取り専用プロファイルと管理者プロファイルを分ける（aws-vault exec readonly -- ...）。
  • MFA/SSO/OIDC連携を有効化し、長期キーを廃止。GCP は ADC、Azure は Entra ID 経由の az login を徹底。

ホスト型 Cloud Shell を“統合端末”として使う

  • 各クラウドはブラウザ内シェルを提供（Azure/Google/AWS）。
  • 例: Azure Cloud Shell に AWS CLI を追加して“ほぼ統合”を実現するワークアラウンドがあります。
  • Google Cloud Shell もブラウザ上でのファイル操作/アップロードや、エディタと連携が可能。

参考リンク

  • 各社 Cloud Shell の比較解説（Seroter, 2021）
  • Azure Cloud Shell に AWS CLI を導入する実例（Qiita 記事）
  • GCP の Application Default Credentials（ADC）の公式解説
  • Azure CLI の公式ログインガイド（サブスクリプション選択含む）
  • direnv で GCP/AWS の設定をディレクトリごとに切替（Zenn/Developers Blog）
  • aws-vault 公式
  • kubectx/kubens 公式
  • Terraform でマルチクラウド管理の解説（2025）
  • Pulumi 公式（マルチクラウド IaC）

簡易確認手順

# 1) CLI 入れる
brew install awscli azure-cli google-cloud-sdk direnv kubectx

# 2) 認証する
aws-vault add dev && aws-vault exec dev -- aws sts get-caller-identity
gcloud auth login && gcloud auth application-default login
az login && az account set --subscription "<YOUR_SUB>"

# 3) プロジェクト直下に .envrc を作る → direnv allow
#    → cd するだけで AWS_PROFILE / ADC などが自動で切替

注意点

  • gcloud auth login だけでは ADC が設定されない → gcloud auth application-default login も実行。
  • aws configure の長期キーは使わない（aws-vault で短命化/MFA化）。
  • Azure はサブスクリプション選択を忘れがち → az account set を明示。
ヘッドウォータース
ヘッドウォータース

株式会社ヘッドウォータースのテックブログです。 AIエージェント、生成AI、LLM、Azureのサービスや資格、IoT、XR系などData&AIとApp modernizeに関して幅広く投稿します！

Discussion