AWSを運用する企業では、サーバー構築や運用自動化を効率化するために、コマンドラインからAWSサービスを操作できる「AWS CLI」の利用が広がっています。

しかし、AWS CLIを導入したものの、認証設定の管理が属人化し、「開発環境のつもりで本番環境を操作してしまった」「想定外のAWSアカウントへ接続してしまった」といった設定ミスが発生するケースは少なくありません。

特に複数のAWSアカウントや開発・検証・本番環境を運用する企業では、AWS Configure、プロファイル、SSO、AssumeRoleの役割を正しく理解し、認証方式を標準化することが重要です。

本記事では、AWS Configureの基本から、プロファイルによる環境分離、IAM Identity Center（SSO）やAssumeRoleを活用した認証運用までを解説します。

AWS Configureとは？最初に理解すべき基礎知識

AWS Configureの役割とできること

AWS Configureは、AWS CLIで利用する認証情報や基本設定を端末に保存するためのコマンドです。

主に以下の情報を設定します。

• アクセスキーID
• シークレットアクセスキー
• 利用リージョン
• 出力形式（JSON、Tableなど）

設定後は、AWS CLIが保存済みの設定情報を利用してAWSへ接続するため、コマンド実行のたびに認証情報を入力する必要がありません。

ただし、実務では「設定できること」以上に、「どの環境へ、どの権限で接続するか」を管理することが重要になります。

例えば以下のような事象は、設定管理が適切でない環境で実際によく発生します。

• 本番環境に対して誤って変更コマンドを実行する
• 開発環境ではなく別アカウントに接続する
• 権限不足で運用作業が停止する
• リージョン設定ミスによりリソースが見つからなくなる
• 利用者ごとに認証設定が異なり運用ルールが統一されない

そのため企業利用では、AWS Configureを単なる初期設定コマンドとしてではなく、複数環境を安全に運用するための認証管理の入口として捉えることが重要です。

AWS Configureで押さえるべき4つのポイント

複数アカウント環境で設定ミスを防ぐために、まずは以下の4点を理解しておきましょう。

1. AWS Configureは認証情報を登録するコマンド

AWS CLIがAWSへ接続するために必要な認証情報や基本設定を登録します。

2. 認証情報と設定情報は別々に管理される

AWS CLIでは認証情報と接続設定が別ファイルに保存されます。運用ルールを整理するうえで重要な仕組みです。

3. 環境ごとにプロファイルを分ける

開発・検証・本番環境を同じ設定で運用すると誤操作のリスクが高まります。プロファイルを利用して環境を分離することが重要です。

4. 企業利用ではSSOやAssumeRoleが基本

長期アクセスキーの共有ではなく、IAM Identity Center（SSO）やAssumeRoleを利用した認証管理が推奨されます。

AWS CLIの認証の仕組み

AWS CLIは、コマンド実行時に「誰が」「どの権限で」AWSへアクセスするのかを確認し、その認証情報を利用してAWSへリクエストを送信します。

そのため、AWS Configureをはじめとする認証設定が正しく管理されていなければ、AWS CLIは正常に動作しません。

個人検証では単一プロファイルでも問題ない場合がありますが、企業では複数アカウントや複数環境を扱うため、認証方式の使い分けが重要になります。

代表的な構成例は以下の通りです。

• 個人検証：AWS Configure＋単一プロファイル
• 複数環境運用：Named Profile＋--profile
• 組織運用：AWS Configure SSO＋aws sso login
• 権限分離：SSO＋AssumeRole

運用規模が大きくなるほど、アクセスキー中心の運用からSSO・AssumeRole中心の運用へ移行していくのが一般的です。

設定ミスをすると何が起きるのか

AWS Configureの設定ミスは、単なるエラーではなく運用トラブルにつながる可能性があります。

例えば認証情報が設定されていない場合は、以下のようなエラーが発生します。

1 Unable to locate credentials

この状態ではAWS CLIは利用できず、S3やEC2などの操作を実行できません。また、認証情報は正しくても権限が不足している場合は、以下のようなエラーになります。

1 AccessDeniedその他の行を表示する

さらに、複数アカウント環境では認証エラーよりも厄介なケースがあります。それが「接続先を間違える」ケースです。例えば、

• --profile の付け忘れ
• AWS_PROFILE環境変数の誤設定
• デフォルトプロファイルの利用
• リージョン設定の誤り

などにより、本来とは異なる環境を操作してしまうことがあります。

現場では、
「EC2が見当たらない」
「S3バケットが存在しない」
「設定変更したはずなのに反映されない」
と調査した結果、実際は別アカウントや別リージョンへ接続していたというケースも少なくありません。

AWS Configureは単なる初期設定コマンドではなく、複数アカウント環境で安全にAWSを運用するための土台となる仕組みです。

そのため次章からは、実際にAWS Configureで管理される設定ファイルやプロファイルの仕組みについて詳しく見ていきます。

AWS Configureの初期設定手順【コマンド例付き】

事前準備：IAMユーザーとアクセスキー取得

まず、従来型のAWS Configureで設定する場合は、利用者に対応する認証情報が必要です。小規模な検証ではIAMユーザーのアクセスキーを使うことがありますが、企業の本番運用では長期アクセスキーの常用は慎重に扱うべきです。AWS公式でも、長期資格情報より短期資格情報の活用が推奨されています。

• 個人検証: 一時的にIAMユーザーで開始
• 組織利用: AWS IAM Identity Centerを第一候補にする
• 複数アカウント: ロール前提の設計にする
• 自動実行環境: 可能ならロールや外部認証連携を優先する

AWS Configureの実行方法

最も基本的な設定は、次のコマンドです。実行すると、アクセスキーID、シークレットアクセスキー、デフォルトリージョン、デフォルト出力形式の入力を求められます。ここで入力した内容は、CLIが以後の実行で参照する基本値になります。

aws configure

複数環境で分けたい場合は、名前付きプロファイルを作成します。

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

入力項目の意味とおすすめ設定

AWS Configureで聞かれる4項目は、意味を理解して入力することが大切です。特にリージョンと出力形式は「とりあえず」で設定されやすい項目ですが、チーム運用では標準値をそろえておくと混乱を減らせます。

項目	役割	典型値	実務上のおすすめ
Access Key ID	呼び出し元の識別	AKIA…	長期常用は避ける
Secret Access Key	署名生成に使う秘密鍵	非公開文字列	Git管理禁止
region	既定の送信先AWSリージョン	ap-northeast-1	チーム標準を固定
output	CLI結果の表示形式	json / table / text	自動化はjson推奨

• 自動化やスクリプトでは出力形式はjsonを基本にする
• 日本企業の一般的な利用ではリージョンは東京を起点に設計しやすい
• 本番用認証情報をdefaultに置かない
• アクセスキーは導入用の暫定手段と考える

設定後の確認コマンド（動作チェック）

設定後は、必ず疎通確認を行います。もっともよく使われる確認コマンドがaws sts get-caller-identityです。現在どのアカウント・どの認証主体で動いているかを確認できます。

aws sts get-caller-identity
aws sts get-caller-identity --profile dev

さらに、設定確認には次の3つが有効です。

aws configure list
aws configure get region --profile dev
aws configure set region ap-northeast-1 --profile dev

aws configure listは現在有効な設定値と、その参照元を見られるため、優先順位の確認に役立ちます。aws configure getは現在値の確認、aws configure setは設定変更に向いています。これらを覚えると、ファイルを直接開かずに保守しやすくなります。

設定ファイルの仕組みと保存場所【図解】

credentialsファイルの役割と注意点

~/.aws/credentialsは、アクセスキーやセッショントークンなど、機密性の高い認証情報を保存するファイルです。AWS公式でも、認証情報はこのファイルに保存することが推奨されています。平文で保存されるため、端末管理や権限設定が非常に重要です。

• ~/.aws/credentialsは機密情報の保管場所
• 共有ストレージやGitに置かない
• 端末のアクセス権を見直す
• 不要なキーは速やかに削除または無効化する

configファイルの役割と違い

~/.aws/configは、リージョン、出力形式、SSO設定、ロール設定など、機密性の低い構成情報を保存するファイルです。credentialsと役割が異なるため、両者を混同しないことが大切です。

実務では、認証そのものはcredentialsまたはSSOキャッシュが担い、実行時の振る舞いはconfigが決める、と整理すると分かりやすくなります。特にAssumeRoleでは、role_arn、source_profile、必要に応じてcredential_processなどをconfigに記述します。

比較項目	~/.aws/credentials	~/.aws/config
主な用途	認証情報の保存	動作設定の保存
代表項目	access key, secret key	region, output, role_arn
機密性	高い	相対的に低い
SSO設定	基本的に持たない	持つ
ロール設定	基本的に持たない	持つ

実際のファイル例と編集方法

基本的なファイル例は次のようになります。

# ~/.aws/credentials
[default]
aws_access_key_id = XXXXXXXXXXXXXXXXXXXX
aws_secret_access_key = XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

[dev]
aws_access_key_id = XXXXXXXXXXXXXXXXXXXX
aws_secret_access_key = XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

# ~/.aws/config
[default]
region = ap-northeast-1
output = json

[profile dev]
region = ap-northeast-1
output = json

[profile prod-admin]
role_arn = arn:aws:iam::123456789012:role/AdminRole
source_profile = dev
region = ap-northeast-1
output = json

AssumeRoleを使う場合、role_arnは「どのロールを引き受けるか」、source_profileは「そのロールを引き受ける元になる認証情報は何か」を表します。より高度な連携では、外部認証基盤から資格情報を取得するcredential_processも使えます。

また、設定の優先順位も重要です。AWS公式では、コマンドラインオプション、環境変数、ロール、SSO、credentials、configの順に優先される仕組みが示されています。つまり、--profileや--regionを付ければ、ファイル設定よりそちらが優先されます。環境変数ではAWS_PROFILEやAWS_DEFAULT_REGIONがよく使われます。

複数アカウント管理の基本｜プロファイルの使い方

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

複数アカウントや複数環境を扱うなら、default一本で運用しないことが基本です。環境ごと、用途ごとにプロファイルを分けると、誤操作を防ぎやすくなります。

aws configure --profile dev
aws configure --profile stg
aws configure --profile prod-readonly

このように分けておけば、同じ端末でも安全に切り替えられます。特に情シスや運用担当では、閲覧専用と管理権限を分けるだけでも事故防止効果が高まります。

プロファイルの切り替え方法

切り替え方法は大きく2つです。1つはコマンドごとに--profileを付ける方法、もう1つはAWS_PROFILE環境変数で既定を切り替える方法です。短い作業なら--profile、一定時間同じ環境を使うならAWS_PROFILEが便利です。

aws s3 ls --profile dev
export AWS_PROFILE=dev
export AWS_DEFAULT_REGION=ap-northeast-1

• 単発コマンドは--profile
• 連続作業はAWS_PROFILE
• 本番操作は明示指定を原則化
• シェル初期化ファイルへの固定書き込みは慎重に行う

よくある設計パターン

BtoBの現場では、プロファイルの命名規則まで含めて標準化しておくと、引き継ぎや自動化がしやすくなります。おすすめは「環境-権限-用途」の順に付ける方法です。例としてdev-readonly、stg-operator、prod-adminのような形です。

• dev、stg、prodの3環境で分離
• 本番は読み取り専用と管理権限を分離
• defaultは使わず、明示的な名前を使う
• 個人名より役割名を優先する

初心者も理解しやすいAssumeRoleの基本

AssumeRoleは、今持っている認証情報を使って、別の権限セットを一時的に引き受ける仕組みです。たとえば、普段は開発アカウントにログインしつつ、必要時だけ本番アカウントの読み取りロールへ入る、といった使い方ができます。恒久的な高権限キーを配らずに済むため、安全性が高まります。

[profile prod-readonly]
role_arn = arn:aws:iam::123456789012:role/ReadOnlyRole
source_profile = dev
region = ap-northeast-1
output = json

AssumeRoleを理解するうえで重要なのは、「元の資格情報」と「引き受け先のロール」を分けて考えることです。前者がsource_profile、後者がrole_arnです。実務では、SSOで得た認証を入口にしてAssumeRoleする設計もよく使われます。

セキュリティを強化する設定方法

IAM Identity Center（SSO）の設定とメリット

組織利用でまず検討したいのが、AWS IAM Identity Centerを使ったSSO構成です。AWS CLIではaws configure ssoで設定を作成し、aws sso loginで実際のログインを行います。これにより、長期アクセスキーを配布せず、期限付きの短期認証情報を取得できます。

aws configure sso
aws sso login --profile corp-dev

SSO運用の利点は、セキュリティだけではありません。人の異動、権限変更、監査対応にも向いています。誰にどのアカウントのどのロールを許可するかを集中的に管理しやすいからです。また、トークンは期限管理されるため、漏えい時のリスクを下げられます。

一方で、SSOセッションは永久ではありません。期限切れ後はaws sso loginの再実行が必要です。古い設定方式より、トークン更新に対応した現在のSSOトークン構成を使う方が実務では扱いやすいといえます。

アクセスキー運用のリスクと対策

長期アクセスキーは、有効期限が明確でないぶん便利に見えます。しかし、端末紛失、設定ファイル流出、退職者アカウントの残存など、企業では管理負荷が高くなります。AWS公式でも、長期資格情報は推奨度が低い扱いです。

• 可能な限りSSOへ移行する
• 長期キーは最小限の用途に限定する
• MFAを併用して本人性を高める
• キーの棚卸しとローテーションを定期化する

認証情報の安全な管理方法

安全な管理で大切なのは、「認証方式」「保管場所」「権限範囲」を別々に設計することです。たとえば、開発端末ではSSO、本番作業ではAssumeRole、CI/CDでは実行基盤ロールというように、利用シーンごとに分離すると管理しやすくなります。

また、実務上は運用標準の文書化も重要です。誰がどのプロファイルを作るか、defaultを使ってよいか、AWS_PROFILEの利用を許可するか、aws configure listによる確認を必須化するか、といったルールを決めておくと、属人化を防げます。

参考として、実際の企業事例では、アクセスキー中心の運用からSSOやAssumeRoleを活用した運用へ移行することで、認証情報の管理を一元化し、運用負荷の軽減やセキュリティ強化につながるケースが報告されています。特にAWS公式の顧客事例においても、IAM Identity Center（旧AWS SSO）の導入により、複数アカウントにまたがるアクセス管理を一元化し、運用の簡素化と統制強化を実現したとされています（※1）。

このように、認証運用を標準化することは、利便性とセキュリティを両立させる現実的な手段です。単一アカウント・長期アクセスキーに依存した運用から脱却し、SSOやロールベースの認証へ移行することで、管理負荷の軽減だけでなく、誤操作や認証情報漏洩といったリスクの低減にもつながります。

※参照1：AWS Identity Services お客様事例

やってはいけないNG例

よくあるNGは、技術的には動くが、運用として危険なパターンです。たとえば、本番管理者権限をdefaultに置く、~/.aws/credentialsを手作業で配布する、個人端末に共通キーを保存する、といった方法です。短期的には早く見えても、監査や障害時に大きな負債になります。

方式	安全性	運用性	向いている場面	注意点
長期アクセスキー	低め	手軽	個人検証の最小構成	漏えい影響が長い
SSO	高い	高い	組織の標準運用	再ログインが必要
AssumeRole	高い	中〜高	権限分離・複数アカウント	元資格情報の整理が必要

【そのまま使える】よくあるエラーと対処法

認証エラー

認証エラーで最初に見るべきなのは、設定の有無ではなく「今どの認証情報が読まれているか」です。aws configure listを実行すると、現在値と参照元が分かるため、defaultを読んでいるのか、AWS_PROFILEを読んでいるのか、設定ファイルか環境変数かを切り分けやすくなります。

• aws configure listで認証情報の有無を見る
• --profileの付け忘れを確認する
• AWS_PROFILEの値を確認する
• ~/.aws/credentialsと~/.aws/configの配置を確認する

AccessDenied系なら、認証できているが権限不足です。aws sts get-caller-identityで主体を確認し、その主体に必要なIAMポリシーやロール許可があるかを見直します。必要に応じて--debugを付けると、どのAPIで失敗しているかを追いやすくなります。

設定ミス・リージョンエラー

リージョン関連のトラブルは、認証より見落とされやすい論点です。AWS CLIでは、--region、環境変数、設定ファイルの順で値が決まります。たとえばAWS_DEFAULT_REGIONがシェルに残っていると、~/.aws/configの設定よりそちらが使われることがあります。

• aws configure get region --profile 対象名
• echo $AWS_DEFAULT_REGION
• コマンド実行時の--region指定有無
• リソースが存在するリージョンとの一致確認

CLIが動かないときのチェックリスト

最後に、CLI全般のチェックリストをまとめます。認証だけに絞らず、CLIそのもののバージョンや時刻同期も見ておくと、無駄な調査を減らせます。AWS CLIは署名に時刻を使うため、端末時刻が大きくずれていると失敗することがあります。

症状	主な原因	確認ポイント	対処
Unable to locate credentials	認証情報未設定	aws configure list	設定追加、–profile確認
AccessDenied	権限不足	Caller identity	ポリシー/ロール見直し
リソースが見つからない	リージョン違い	AWS_DEFAULT_REGION	正しいリージョン指定
sso login失敗	セッション期限切れ等	aws sso login再実行	SSO再認証
コマンド未認識	CLI古い/未導入	aws --version	更新・再導入

運用現場では、このチェックリストをそのまま手順書に組み込むのがおすすめです。よくある失敗を再検索せずに切り分けられるようにしておくと、問い合わせ対応の工数削減につながります。

まとめ

AWS Configureは、単なる初期設定コマンドではありません。AWS CLI認証運用の起点として、プロファイル、~/.aws/credentials、~/.aws/config、--profile、AWS_PROFILE、AWS_DEFAULT_REGION、SSO、AssumeRoleまで一貫して設計することが重要です。

特に企業利用では、長期アクセスキー中心の運用から、aws configure ssoとaws sso loginを軸にした短期認証情報中心の構成へ移行することで、安全性と再現性を高めやすくなります。

まずは、現在のCLI設定をaws configure listで棚卸しし、環境ごとのプロファイル命名規則と優先順位の運用ルールを整理してみてください。複数アカウントや本番運用を見据えるなら、SSOとAssumeRoleを前提にした標準化が有効です。

AWS CLIの設定方針や認証運用の見直しを進めたい場合は、テクノプロへご相談ください。