DevOpsツールとベストプラクティスの習得 - DevOpsナレッジハブ DevOpsツールとベストプラクティスの習得 - DevOpsナレッジハブ

複数のAWS CLIプロファイルを効率的に設定および管理する方法

AWS CLI名前付きプロファイルを使用して、複数のAWSアカウントと環境を効率的に管理する方法を学びます。このガイドでは、AWS認証情報と設定のさまざまなセットを設定、切り替え、および保護するためのステップバイステップの手順を提供します。生産性とセキュリティを向上させるためのプロファイル管理をマスターして、クラウドワークフローを最適化します。

複数のAWS CLIプロファイルを効率的に設定・管理する方法

AWS CLIプロファイルを使用すると、アカウント、ロール、リージョン、出力形式を分離して管理できます。開発環境、ステージング環境、本番環境を同じラップトップで管理する場合、プロファイルを使用することで、誤ったAWSアカウントに対してコマンドを実行するのを防ぐことができます。

目標はシンプルです。意図したアカウントを明確にし、長期有効な認証情報を可能な限り減らし、破壊的なコマンドを実行する前に簡単な確認を行えるようにすることです。

AWS CLI設定ファイルのセットアップ

AWS CLIは、プロファイル設定を2つの共有ファイルに保存します。

  • ~/.aws/credentials：アクセスキーとセッション認証情報用。
  • ~/.aws/config：リージョン、出力形式、ロール設定、その他のCLIオプション用。

Windowsでは、同じファイルが%USERPROFILE%\.aws\にあります。

デフォルトプロファイル

--profileオプションなしでaws configureを実行すると、[default]の設定が書き込まれます。CLIは、別のプロファイルが指定されておらず、関連する環境変数による上書きがない場合、このプロファイルを使用します。

# ~/.aws/credentials のデフォルトプロファイルの例
[default]
aws_access_key_id = YOUR_DEFAULT_ACCESS_KEY
aws_secret_access_key = YOUR_DEFAULT_SECRET_KEY

# ~/.aws/config のデフォルトプロファイルの例
[default]
region = us-east-1
output = json

名前付きプロファイルの作成

aws configure --profileを使用して名前付きプロファイルを作成できます。

aws configure --profile dev
aws configure --profile prod

ファイルを直接編集することもできます。~/.aws/credentialsでは、プレーンなプロファイル名を使用します。

~/.aws/credentials:

[default]
aws_access_key_id = YOUR_DEFAULT_ACCESS_KEY
aws_secret_access_key = YOUR_DEFAULT_SECRET_KEY

[prod]
aws_access_key_id = YOUR_PROD_ACCESS_KEY
aws_secret_access_key = YOUR_PROD_SECRET_KEY

[dev]
aws_access_key_id = YOUR_DEV_ACCESS_KEY
aws_secret_access_key = YOUR_DEV_SECRET_KEY

~/.aws/configでは、名前付きプロファイルにprofile プレフィックスを使用します。

~/.aws/config:

[default]
region = us-east-1
output = json

[profile prod]
region = us-west-2
output = text

[profile dev]
region = eu-central-1
output = json

重要な詳細：

  • ~/.aws/configでプロファイルを定義する場合、プロファイル名の前にprofile を付ける必要があります（例：[profile prod]）。これは、プロファイル名のみを使用する~/.aws/credentials（例：[prod]）とは異なります。
  • [default]プロファイルは、名前付きプロファイルの親として自動的に機能しません。prodにリージョンが必要な場合は、[profile prod]の下にregionを設定するか、別の方法で指定します。

プロファイルの切り替え

名前付きプロファイルを設定したら、AWS CLIコマンドで--profileオプションを指定して使用できます。

例： 本番アカウントのS3バケットを一覧表示する場合：

aws s3 ls --profile prod

例： 開発アカウントのEC2インスタンスを記述する場合：

aws ec2 describe-instances --profile dev

危険なコマンドを実行する前に、自分が誰であるかを確認します。

aws sts get-caller-identity --profile prod

これにより、CLIが使用している認証情報のアカウントIDとARNが返されます。

環境のデフォルトプロファイルの設定

毎回--profileと入力するのは面倒です。現在のシェルセッションにAWS_PROFILEを設定できます。

Linux/macOS:

export AWS_PROFILE=prod

# これで、コマンドはデフォルトで'prod'プロファイルを使用します
aws s3 ls
aws ec2 describe-instances

解除するには：

unset AWS_PROFILE

Windows コマンドプロンプト:

set AWS_PROFILE=prod

# これで、コマンドはデフォルトで'prod'プロファイルを使用します
aws s3 ls

解除するには：

set AWS_PROFILE=

Windows PowerShell:

$env:AWS_PROFILE = "prod"

# これで、コマンドはデフォルトで'prod'プロファイルを使用します
aws s3 ls

解除するには：

Remove-Item Env:\AWS_PROFILE

コマンドラインオプションは環境変数よりも優先順位が高くなります。AWS_PROFILE=devが設定されていても、aws s3 ls --profile prodを実行すると、コマンドはprodを使用します。

複数のAWSアカウントをプロファイルで管理する

プロファイルは以下の場合に役立ちます。

  • 開発環境と本番環境の分離： 安全性のために開発環境と本番環境を分離します。
  • 異なるチーム/プロジェクト： 異なるチームやプロジェクトのリソースと権限を分離します。
  • クロスアカウントアクセス： 複数のアカウントのリソースを管理する必要がある管理者や開発者の場合。

ベストプラクティス：IAMロールの使用

すべてのアカウントに長期有効なアクセスキーを保存することは避けてください。一般的なパターンは、1つのソースプロファイルまたはSSOプロファイルを保持し、ターゲットアカウントにロールを引き受けることです。

ロール引き受けの場合、次のようにプロファイルを設定します。

# ~/.aws/config

[profile dev-role]
role_arn = arn:aws:iam::ACCOUNT_ID:role/ROLE_NAME
source_profile = default
region = us-east-1
output = json

--profile dev-roleを指定してコマンドを実行すると、CLIはdefaultプロファイルを使用してAWS STSを呼び出し、ロールを引き受け、一時的な認証情報をコマンドに使用します。

組織がIAM Identity Centerを使用している場合、プロファイルはアクセスキーの代わりにSSO設定を使用する場合があります。

[profile sandbox]
sso_start_url = https://example.awsapps.com/start
sso_region = us-east-1
sso_account_id = 123456789012
sso_role_name = DeveloperAccess
region = us-east-1
output = json

その後、次のコマンドで認証します。

aws sso login --profile sandbox

高度な設定オプション

認証情報とリージョン以外にも、プロファイルは他のAWS CLI設定を指定できます。

  • output：json、text、table
  • region：例：us-east-1
  • s3.max_concurrent_requests：S3操作の並列リクエスト数。
  • s3.max_queue_size：S3マルチパートアップロードのキューサイズ。
  • cli_binary_format：AWS CLI v2でバイナリパラメータがどのように解釈されるか。

例：特定のプロファイルのS3設定を構成する

インデントの間違いを避けるために、aws configure setを使用します。

aws configure set s3.max_concurrent_requests 20 --profile s3-optimized
aws configure set s3.max_queue_size 10000 --profile s3-optimized

これにより、~/.aws/configのプロファイルの下にS3設定が書き込まれます。

# ~/.aws/config

[profile s3-optimized]
region = us-east-1
output = json
s3 =
    max_concurrent_requests = 20
    max_queue_size = 10000

ヒントとベストプラクティス

  • わかりやすいプロファイル名を使用する： プロファイル名は、それが表すアカウントや環境を明確に示すものにします（例：prod-admin、dev-web、sandbox-research）。
  • 認証情報を保護する： ~/.aws/credentialsファイルをバージョン管理にコミットしないでください。長期有効なアクセスキーの保存を避けるために、可能な限りクロスアカウントアクセスにはIAMロールを使用します。
  • アクセスキーを定期的に確認する： アクセスキーを使用する必要がある場合は、定期的にローテーションし、古いキーを無効にします。
  • 環境変数を活用する： 一時的な切り替えや、特定のアカウントをターゲットにする必要があるCI/CDパイプラインでは、AWS_PROFILEを使用します。
  • 認証情報の環境変数に注意する： AWS_ACCESS_KEY_ID、AWS_SECRET_ACCESS_KEY、AWS_SESSION_TOKENは、プロファイルの認証情報を上書きする可能性があります。CLIが誤ったIDを使用しているように見える場合は、これらをクリアします。
  • 影響範囲に基づいてプロファイルに名前を付ける： prod-readonly、prod-admin、sandbox-devのような名前は、mainやtestのような曖昧な名前よりも安全です。

実践的なポイント

頻繁に触れるすべてのアカウントとロールにプロファイルを使用し、本番リソースを変更する前にaws sts get-caller-identityで確認します。長期有効なアクセスキーよりもSSOベースまたはロールベースのプロファイルを優先し、コマンドが誤ったアカウントをターゲットにしているように見える場合は環境変数に注意してください。