AWS CLIの利用が広がる一方で、企業のIT部門や情報システム部門では、初期設定だけはできても、その後の認証運用をどう標準化すべきかで悩むケースが少なくありません。

特に複数アカウント・複数環境を扱う現場では、AWS Configure、プロファイル、SSO、AssumeRoleの関係が曖昧なまま運用されがちです。「どこまで設定すれば十分なのか」「アクセスキー運用を続けてよいのか」と疑問をお持ちの方も多いのではないでしょうか。

本記事では、AWS Configureを起点に、AWS CLI認証の基本、設定ファイル、複数環境の設計、IAM Identity Center（SSO）やロール活用まで、実務で迷いにくい考え方を具体的に整理します。

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

AWS Configureの役割とできること

AWS Configureは、AWS CLIで使用する認証情報と基本設定を端末に保存するためのコマンドです。主にアクセスキー、シークレットアクセスキー、リージョン、出力形式を設定します。これにより、毎回コマンドに認証情報を直接記述する必要がなくなり、CLIが設定ファイルを自動的に参照して処理を行えるようになります。

一方で、AWS ConfigureはあくまでCLI認証運用の「入口」に過ぎません。実務では、その先にあるプロファイル設計や認証方式の選択を含めて設計を行わなければ、複数環境での設定ミスや権限事故につながる可能性があります。特に企業環境では、単一アカウント・単一設定のまま運用するケースはほとんど存在せず、複数アカウント・複数ロールを前提とした設計が求められます。

▼AWS Configureを理解するための4つの設計視点

• AWS Configureは認証情報と基本設定を保存するコマンドである
  → CLIがAPIを実行する際に必要な最小限の情報をローカルに保持する仕組み
• 設定情報は~/.AWS/credentialsと~/.AWS/configに分かれて保存される
  → 認証情報と設定情報が分離されており、運用設計の基盤となる
• 本番運用では単一設定ではなくプロファイル設計が必須となる
  → –profileを活用し、開発・検証・本番環境を分離することで誤操作を防ぐ
• 企業利用では長期アクセスキーではなく短期認証情報（SSO・AssumeRole）が基本となる
  → AWS IAM Identity Center（SSO）やAssumeRoleを活用した認証が推奨される

AWS CLIの認証の仕組み

AWS CLIは、実行時に「誰が」「どの権限で」操作するかを認証し、その内容でAPIリクエストに署名してAWSへ送信します。認証情報が正しく設定されていないと、CLIは操作できません。逆に言えば、AWS Configureは単なる便利機能ではなく、AWS CLIが正しく本人確認を行うための前提です。

AWSの公式ドキュメントでは、認証方式として長期アクセスキーだけでなく、IAM Identity Center、ロール、EC2インスタンスプロフィール、外部プロセス連携などが整理されています。特に組織利用では、期限のないアクセスキーより、期限付きの短期認証情報を中心に設計する方が安全です。これは認証情報が漏えいした場合の影響時間を短くできるためです。

• 個人検証の最小構成: AWS Configure + 単一プロファイル
• 複数環境の運用: named プロファイル + –profile
• 組織利用の基本: AWS Configure sso + AWS sso login
• 権限分離が必要な運用: SSOまたはベース資格情報 + AssumeRole

設定しないとどうなるか

代表的な失敗例がUnable to locate credentialsです。
これは、AWS Configure未実行、または認証情報の参照先がずれて「認証情報が見つからない」状態です。一方で、認証情報はあるのに権限が足りない場合はAccessDenied系のエラーになります。

その結果、「誰として操作するか」が決まらないので、AWSへのリクエストが一切通りません。S3のファイル一覧すら取れず、コマンドが即座にエラーで止まります。権限以前の問題で、AWSの入口にすら立てていない状態です。

同じ「動かない」でも原因が違うため、切り分けが必要です。

AWS CLIは認証以外にもリージョン設定に依存します。リソースが東京リージョンにあるのに、誤って別リージョンへ問い合わせると「存在しない」「見つからない」といった誤解を招きます。認証エラーとリージョン設定ミスが混在すると、現場では原因調査に時間を取られがちです。

• –profileを付け忘れ、default設定で実行してしまう
• AWS_PROFILEが想定外の値になっている
• AWS_DEFAULT_REGIONが未設定、または誤設定
• ~/.AWS/credentialsと~/.AWS/configの役割を混同する

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の設定方針や認証運用の見直しを進めたい場合は、テクノプロへご相談ください。