AWS CLI・CloudFormation - AWS

最終更新日: 2026-08-02

TOP(About this memo)) > 一覧(AWS) > AWS CLI・CloudFormation

CodeCommit

AWS CLI

利用ケース

新規AWSアカウントの初期セットアップ(IAMユーザー作成)

新しく作成したAWSアカウントでAWS CLIを使う場合、ルートユーザーの認証情報を直接使うのではなく、IAMユーザーを作成してアクセスキーを発行し、aws configureに設定する方法が一般的。

AWS CLIの認証方法は以下のいずれかを選べる。

方法 利用可否 推奨度
ルートユーザーのアクセスキー 可能 非推奨
IAMユーザーのアクセスキー 可能 一般的
aws login(root/IAMユーザーの一時クレデンシャル、後述) 可能(CLI 2.32.0以降) 個人開発では有力な選択肢
IAM Identity Center(SSO) 可能 推奨(組織・複数アカウント運用向け)

ルートユーザーのアクセスキーでもCLIは利用できるが、ルートユーザーは全権限を持ち誤操作時の影響が最大になるうえ、アクセスキー漏洩時のリスクも大きいため非推奨。以下の構成が現実的。

ルートユーザー
  ↓
IAMユーザー作成
  ↓
アクセスキー発行
  ↓
aws configure

IAMユーザーの作成手順(コンソール)

IAM → Users → Create user

アクセスキーの発行

IAM → Users → 対象ユーザー → Security credentials → Create access key

用途はCommand Line Interface (CLI)を選択する。発行された「Access Key ID」と「Secret Access Key」はaws configureで使うため保存しておく。

aws login

2025年11月に追加された、比較的新しいコマンド。IAM Identity Centerを使わずに、既存のAWS Management Consoleのサインイン情報(ルートユーザー/IAMユーザー/フェデレーションID)をそのまま使って一時的なクレデンシャルを取得できる。長期間有効なアクセスキーを発行・管理する必要がなくなる点が最大のメリット。

aws login

書き込まれる設定はアクセスキーではなく、対象IAMプリンシパルのARNのみ。

[default]
login_session = arn:aws:iam::111122223333:user/terraform-admin
region = ap-northeast-1

IAM Identity Centerのような複数アカウント横断の一元管理はできないが、個人開発で「IAMユーザーは使いたいが長期アクセスキーは避けたい」という場合に、Identity Center/Organizationsを構築するほどではない規模でも使える手軽な選択肢(IMO)。

(出典: Login for AWS local development using console credentials、Simplified developer access to AWS with ‘aws login’)

（参考）AWS CLIでEC2インスタンスの作成

ローカルでの利用

環境変数

プロファイルの設定(デフォルトとして設定される)

$ aws configure
  AWS Access Key ID [None]: {アクセスキー(各自)}
  AWS Secret Access Key [None]: {シークレットアクセスキー(各自)}
  Default region name [None]: (リージョンを指定)
  Default output format [None]: json

確認: aws configure list

アカウントを取り違えていないかは以下でも確認できる。

aws sts get-caller-identity

{
    "UserId": "AIDAxxxxxxxx",
    "Account": "123456789012",
    "Arn": "arn:aws:iam::123456789012:user/terraform-admin"
}

Accountが意図したAWSアカウントIDになっていることを確認する。

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

$ aws configure --profile user1

すでに作成済みのプロファイルを指定すると編集モードになる。 確認: aws configure list --profile user1

プロファイルの確認

cat ~/.aws/credentials
cat ~/.aws/config

プロファイルの切り替え

export AWS_DEFAULT_PROFILE=user1
aws configure list  # 確認

export AWS_DEFAULT_PROFILE=default
aws configure list  # 確認

別アカウントへ切り替える(既存の設定を削除する場合)

プロファイルを使い分けるのではなく、古いAWSアカウントの設定自体を削除して新しいアカウントに一本化したい場合は、~/.aws/credentials・~/.aws/configを削除すればよい。

削除前に念のためバックアップを取っておく。

mkdir -p ~/.aws-backup
cp ~/.aws/credentials ~/.aws-backup/credentials.bak 2>/dev/null
cp ~/.aws/config ~/.aws-backup/config.bak 2>/dev/null

ファイル単位で削除:

rm -f ~/.aws/credentials
rm -f ~/.aws/config

またはAWS CLIの設定ディレクトリごと削除:

rm -rf ~/.aws

削除後にaws configureで新しいアカウントのIAMユーザーのアクセスキーを設定し直す。

コマンド実行時にプロファイルを都度切り替える

その他コマンドメモ

aws iam list-users   # IAMユーザー確認
aws iam list-groups  # IAMグループを確認

EC2インスタンス上で使う場合

aws ec2 describe-instances

補足: 長期アクセスキーを避ける方法

アクセスキーを長期間発行し続ける運用はキー漏洩のリスクがあるため、避けられるなら避けたい(IMO)。選択肢は主に2つ。

個人開発やTerraform学習用途で、複数アカウントを横断する予定が無いなら、IAMユーザー+アクセスキー方式のままでも実用上困らないが、aws loginに切り替えるだけでアクセスキーを持たずに済むため、乗り換えの手間は小さい(IMO)。

CloudFormation

スタック

(例) YAML形式の場合(JSONやYAMLで書ける)

AWSTemplateFormatVersion: '2010-09-09'
Description: 〜〜
Parameters: # 実行時(スタック作成/更新)にユーザー入力を求めるパラメータ(KeyPairの名前や、DBのユーザー名など)
  ...

Resources: # Amazon EC2など、スタックを構成するリソースとプロパティ
  myVPC: # <Logical ID> テンプレート内で一意なID。テンプレート内で他のリソースを参照する際にこのIDを利用
    Type: AWS::EC2::VPC
    Properties: # 各リソースの作成時に指定するプロパティ。リソースタイプによって利用できるプロパティは異なるため、公式ドキュメントを確認しながら指定する
      CidrBlock: 10.0.0.0/16
      Tags:
      - Key: Name
        Value: first-VPC

Outputs: # スタック構築後にAWS CloudFormationから出力される値(DNSやEIPの値など)
  ...

aws cloudformationのような形でCLIから実行できる。WEBコンソールから実施すると再現性がイマイチになるため、CLIに統一するほうが無難(IMO)。以下のようなシェルファイルを用意しておくと便利。

#!/bin/bash

CFN_TEMPLATE=vpc.yml
CFN_STACK_NAME=vpc

aws cloudformation deploy --stack-name ${CFN_STACK_NAME} --template-file ${CFN_TEMPLATE} \
  --parameter-overrides \
  NameTagPrefix=prd \
  VPCCIDR=10.70
This site is open source. Improve this page.