はじめに
2025年11月、AWS CLI v2.32.0で新コマンド「aws login」がリリースされました。これまでCLIを使うにはアクセスキーを発行してaws configureで設定するか、IAM Identity Center（SSO）を使う必要がありましたが、この新機能を使えば、ブラウザでログイン済みのAWSマネジメントコンソールのセッションをそのままCLIに引き継げるようになりました。
今回は、このaws loginコマンドとTerraformを組み合わせて、東京リージョンにVPCを構築する手順を紹介します。
aws loginコマンドとは
aws loginは、ブラウザベースでAWS CLIの認証を行う新機能です。
従来の方法では、IAMユーザーのアクセスキー・シークレットキーを発行して、ローカルの~/.aws/credentialsに保存する必要がありました。この方法だと、長期的な認証情報がローカルに残り続けるため、セキュリティ上の懸念がありました。
aws loginを使えば、AWSマネジメントコンソールにログイン済みのブラウザで承認するだけで、一時的な認証情報が取得できます。アクセスキーを発行・保存する必要がなくなるため、より安全にCLIを利用できます。
前提条件
この記事では、以下の環境を前提としています。
- AWS CLI v2.32.0以降がインストール済み
- Terraformがインストール済み
- AWSマネジメントコンソールにログインできるIAMユーザーが存在する
- VSCodeがインストール済み
環境構築の流れ
今回の構築手順は以下の通りです。
- AWS CLIのバージョンを確認する
-
aws loginコマンドで認証する - Terraformの設定ファイルを作成する
- Terraformでリソースをデプロイする
AWS CLIのバージョン確認
aws loginコマンドはAWS CLI v2.32.0以降で利用可能です。まずはバージョンを確認しましょう。VSCodeの統合ターミナル（Ctrl + @またはCmd + @）を開いて、以下のコマンドを実行します。
aws --version
aws-cli/2.32.7 Python/3.13.9 Windows/11 exe/AMD64
バージョンが2.32.0未満の場合は、AWS CLIをアップデートしてください。
aws loginコマンドで認証する
それでは、aws loginコマンドを実行してみましょう。
aws login
環境変数や設定ファイルでデフォルトリージョンが設定されていない場合は、初回のみリージョンの指定を求められます。
No AWS region has been configured. The AWS region is the geographic location of your AWS resources.
If you have used AWS before and already have resources in your account, specify which region they were created in. If you have not created resources in your account before, you can pick the region closest to you: https://docs.aws.amazon.com/global-infrastructure/latest/regions/aws-regions.html.
You are able to change the region in the CLI at any time with the command "aws configure set region NEW_REGION".
AWS Region [us-east-1]:
東京リージョンを指定します。
AWS Region [us-east-1]: ap-northeast-1
するとOSのデフォルトブラウザが自動で起動します。もしブラウザが開かない場合は、ターミナルに表示されるURLを手動で開きます。
Attempting to open your default browser.
If the browser does not open, open the following URL:
https://<認証用URL>
ブラウザ側では、すでにAWSマネジメントコンソールにログイン済みであれば、そのセッション（IAMユーザーやスイッチロール先）を選択できます。普段使っているIAMユーザーでログインしていれば、その権限でCLIが使えるようになります。
認証に成功すると、ブラウザに「Authentication successful」のようなメッセージが表示されます。ターミナルには以下のように表示されます。
Updated profile default to use arn:aws:iam::<AWSアカウントID>:user/<IAMユーザー名> credentials.
これで認証完了です。認証が成功したか確認してみましょう。
aws sts get-caller-identity
以下のような出力が返ってくれば成功です。
{
"UserId": "AIDAXXXXXXXXXXXXXXXXX",
"Account": "123456789012",
"Arn": "arn:aws:iam::123456789012:user/your-iam-user"
}
Terraform用のプロファイル設定
現時点では、Terraform AWS Providerはaws loginで取得した認証情報を直接読み取ることができません。これは認証情報の保存形式の違いによるもので、GitHub上では機能リクエストが出されていますが、現時点ではcredential_processを使った回避策が必要です。
AWS CLIの設定ファイル（%USERPROFILE%\.aws\config）に以下を追記します。
[profile terraform]
credential_process = aws configure export-credentials --profile default --format process
region = ap-northeast-1
この設定により、Terraformがterraformプロファイルを使う際に、aws loginで取得したdefaultプロファイルの認証情報を自動的に取得できるようになります。
Terraformプロジェクトの作成
あらかじめ、任意の場所にaws-vpc-demoフォルダを作成しておきます。VSCodeでFile > Open Folderから作成したフォルダを開き、Terraformの設定ファイルを作成していきます。
main.tf
プロバイダー設定とVPCリソースを定義します。aws loginで認証済みの場合、プロファイル指定なしでdefaultプロファイルの認証情報が使用されます。
# ==============================================================================
# Terraformの基本設定
# ==============================================================================
terraform {
# Terraformのバージョン制約
# 1.0.0以上のバージョンが必要
required_version = ">= 1.0.0"
# 使用するプロバイダーの定義
required_providers {
aws = {
source = "hashicorp/aws" # プロバイダーのソース（HashiCorp公式）
version = "~> 6.28.0" # https://registry.terraform.io/providers/hashicorp/aws/latestから確認できる
}
}
}
# ==============================================================================
# AWSプロバイダーの設定
# ==============================================================================
provider "aws" {
region = "ap-northeast-1" # リソースを作成するリージョン（東京）
profile = "terraform" # 使用するAWS CLIプロファイル名
}
# ==============================================================================
# VPCの作成
# ==============================================================================
resource "aws_vpc" "demo" {
# ----------------------------------------------------------------------------
# 必須パラメータ
# ----------------------------------------------------------------------------
# VPCのIPアドレス範囲（CIDR表記）
# /16 = 65,536個のIPアドレスが使用可能
cidr_block = "10.0.0.0/16"
# ----------------------------------------------------------------------------
# オプションパラメータ（デフォルト値を明示的に指定）
# ----------------------------------------------------------------------------
# インスタンスのテナンシー属性
# "default" = 共有ハードウェア上で実行（通常はこれを使用）
# "dedicated" = 専用ハードウェア上で実行（コストが高い）
instance_tenancy = "default"
# DNSサポートの有効化
# true = VPC内でAmazon提供のDNSサーバーを使用可能
# false = DNSサポートを無効化
enable_dns_support = true
# DNSホスト名の有効化
# true = パブリックIPを持つインスタンスにパブリックDNSホスト名を割り当て
# false = パブリックDNSホスト名を割り当てない（デフォルト）
enable_dns_hostnames = true
# IPv6 CIDRブロックの自動割り当て
# true = AmazonのIPv6アドレスプールから/56のCIDRブロックを割り当て
# false = IPv6を使用しない（デフォルト）
assign_generated_ipv6_cidr_block = false
# ----------------------------------------------------------------------------
# タグ設定
# ----------------------------------------------------------------------------
# リソースを識別・管理するためのタグ
tags = {
Name = "demo-vpc" # リソース名（AWSコンソールで表示される）
Environment = "development" # 環境種別（development/staging/production等）
ManagedBy = "terraform" # 管理ツール（手動変更を防ぐ目印）
}
}
VPCリソースの設定では、デフォルト値であっても明示的に指定しています。本番環境では「設定ファイルを見ればすべての設定値がわかる」状態にしておくことが重要です。デフォルト値に依存していると、Terraformやプロバイダーのバージョンアップでデフォルト値が変わった際に、意図しない変更が発生する可能性があります。
outputs.tf
作成したリソースの情報を出力するための設定です。
# ==============================================================================
# 出力値の定義
# terraform apply完了後に表示される値を定義する
# 他のTerraformモジュールから参照したり、確認用に使用する
# ==============================================================================
# VPCのID
# 形式: vpc-xxxxxxxxxxxxxxxxx
# サブネットやセキュリティグループ作成時に参照する
output "vpc_id" {
description = "作成されたVPCのID"
value = aws_vpc.demo.id
}
# VPCのCIDRブロック
# main.tfで指定したIPアドレス範囲が出力される
output "vpc_cidr" {
description = "VPCのCIDRブロック"
value = aws_vpc.demo.cidr_block
}
# VPCのARN（Amazon Resource Name）
# AWSリソースを一意に識別するための識別子
# 形式: arn:aws:ec2:ap-northeast-1:123456789012:vpc/vpc-xxxxxxxxx
output "vpc_arn" {
description = "VPCのARN"
value = aws_vpc.demo.arn
}
# VPCのオーナーID（AWSアカウントID）
# このVPCを所有するAWSアカウントの12桁のID
output "vpc_owner_id" {
description = "VPCを所有するAWSアカウントID"
value = aws_vpc.demo.owner_id
}
# デフォルトセキュリティグループのID
# VPC作成時に自動的に作成されるセキュリティグループ
# 通常は使用せず、用途別にセキュリティグループを作成することを推奨
output "default_security_group_id" {
description = "VPCのデフォルトセキュリティグループID"
value = aws_vpc.demo.default_security_group_id
}
# メインルートテーブルのID
# VPC作成時に自動的に作成されるルートテーブル
# サブネットに明示的なルートテーブルを関連付けない場合、このテーブルが使用される
output "main_route_table_id" {
description = "VPCのメインルートテーブルID"
value = aws_vpc.demo.main_route_table_id
}
Terraformの実行
ファイルの作成が完了したら、VSCodeのターミナルからTerraformを実行します。
# 初期化（プロバイダーのダウンロード）
terraform init
成功すると以下のようなメッセージが表示されます。
Terraform has been successfully initialized!
次に、実行計画を確認します。
# 実行計画の確認
terraform plan
作成されるリソースの一覧が表示されます。今回はVPC1つだけなので、シンプルな出力になります。
Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the
following symbols:
+ create
Terraform will perform the following actions:
# aws_vpc.demo will be created
+ resource "aws_vpc" "demo" {
+ arn = (known after apply)
+ cidr_block = "10.0.0.0/16"
+ default_network_acl_id = (known after apply)
+ default_route_table_id = (known after apply)
+ default_security_group_id = (known after apply)
+ dhcp_options_id = (known after apply)
+ enable_dns_hostnames = true
+ enable_dns_support = true
+ enable_network_address_usage_metrics = (known after apply)
+ id = (known after apply)
+ instance_tenancy = "default"
+ ipv6_association_id = (known after apply)
+ ipv6_cidr_block = (known after apply)
+ ipv6_cidr_block_network_border_group = (known after apply)
+ main_route_table_id = (known after apply)
+ owner_id = (known after apply)
+ tags = {
+ "Environment" = "development"
+ "ManagedBy" = "terraform"
+ "Name" = "demo-vpc"
}
+ tags_all = {
+ "Environment" = "development"
+ "ManagedBy" = "terraform"
+ "Name" = "demo-vpc"
}
}
Plan: 1 to add, 0 to change, 0 to destroy.
Changes to Outputs:
+ default_security_group_id = (known after apply)
+ main_route_table_id = (known after apply)
+ vpc_arn = (known after apply)
+ vpc_cidr = "10.0.0.0/16"
+ vpc_id = (known after apply)
+ vpc_owner_id = (known after apply)
出力の中で(known after apply)と表示されている項目がありますが、これは「リソースが実際に作成されるまで値がわからない」という意味です。例えば、VPCのidやarnはAWSがリソースを作成するときに自動的に割り当てる値なので、planの段階では知ることができません。applyを実行してAWS上にVPCが実際に作成されると、その時点で値が確定します。
cidr_block = "10.0.0.0/16"やenable_dns_hostnames = true、tagsなど、こちらがmain.tfで指定した値はplanの時点で表示されています。一方、id、arn、owner_id、default_security_group_idなどはAWSが作成時に割り当てる値なので(known after apply)となります。
内容を確認して問題なければ、実際にリソースを作成します。
# リソースの作成
terraform apply
確認メッセージが表示されるので、yesと入力してEnterを押します。
Do you want to perform these actions?
Terraform will perform the actions described above.
Only 'yes' will be accepted to approve.
Enter a value: yes
数秒〜数十秒でVPCが作成されます。
Apply complete! Resources: 1 added, 0 changed, 0 destroyed.
Outputs:
default_security_group_id = "sg-xxxxxxxxxxxxxxxxx"
main_route_table_id = "rtb-xxxxxxxxxxxxxxxxx"
vpc_arn = "arn:aws:ec2:ap-northeast-1:123456789012:vpc/vpc-xxxxxxxxxxxxxxxxx"
vpc_cidr = "10.0.0.0/16"
vpc_id = "vpc-xxxxxxxxxxxxxxxxx"
vpc_owner_id = "123456789012"
applyが完了すると、プロジェクトフォルダにterraform.tfstateというファイルが作成されます。これはTerraformが管理しているリソースの現在の状態を記録したファイルで、JSON形式で書かれています。Terraformはこのファイルを参照して、次回のplanやapply時に「現在の状態」と「設定ファイルで定義された状態」を比較し、差分を検出します。
terraform.tfstateはTerraformにとって非常に重要なファイルです。このファイルを削除してしまうと、Terraformは既存のリソースを認識できなくなり、同じリソースを再作成しようとしてエラーになったり、既存リソースを管理できなくなったりします。チーム開発ではS3などのリモートバックエンドに保存するのが一般的ですが、今回のようなデモ用途ではローカルで問題ありません。
作成したリソースの確認
AWSマネジメントコンソールでVPCが作成されていることを確認できます。また、CLIからも確認可能です。
aws ec2 describe-vpcs --filters "Name=tag:Name,Values=demo-vpc"
リソースの削除
デモ用のリソースなので、確認が終わったら削除しておきましょう。
terraform destroy
確認メッセージでyesと入力すれば、作成したVPCが削除されます。
destroyを実行すると、プロジェクトフォルダにterraform.tfstate.backupというファイルが作成されます。これはdestroy実行前の状態を保存したバックアップファイルです。万が一誤ってdestroyを実行してしまった場合でも、このバックアップファイルがあれば、どのリソースが存在していたかを確認できます（ただし、AWS上のリソース自体は削除されているため、復元するには再度applyが必要です）。
destroy完了後のterraform.tfstateは、管理対象のリソースがない空の状態になります。
まとめ
今後に活用できそうなこと
aws loginコマンドとTerraformの組み合わせは、以下のような場面で活用できそうです。
まず、セキュリティの向上という点では、長期的なアクセスキーをローカルに保存する必要がなくなります。これまで~/.aws/credentialsに書いていたアクセスキーが漏洩するリスクを減らせるのは大きなメリットです。
使ってみた感想
実際に使ってみて一番良かったのは、アクセスキーを発行しなくて済むことですね。以前は新しい環境をセットアップするたびに「アクセスキー発行して...コピーして...設定して...」という作業があって、その度に「これ本当に安全なのかな」という気持ちがありました。aws loginならその心配がないので、精神的にも楽になりました。
Terraformとの相性も良くて、credential_processの設定さえしておけばそのまま使えるのが嬉しいポイントです。現時点ではTerraformがaws loginの認証情報を直接読み取れないため回避策が必要ですが、一度設定してしまえば後は意識することなく使えます。
一方で気になった点としては、セッションの有効期限があることです。認証情報は15分ごとに自動更新されますが、全体のセッションは最大12時間で切れるため、それ以降は再度aws loginを実行する必要があります。長時間のTerraform作業中にセッションが切れるとapplyが途中で失敗する可能性があるので、作業前に認証状態を確認しておくと良さそうです。