AWS のアカウントを作って、コンソールで EC2 を1台立てられるようになった。次に読んだ手順に「AWS CLI で aws ec2 describe-instances を実行」と書いてある。画面で押せば済むことを、なぜわざわざ黒い画面で打つのか。aws configure で聞かれるアクセスキーとは何で、どこから出てくるのか。しかも「間違えると本番が消える」と脅される。この記事は、コンソールと CLI が同じところに頼みごとを出していることから始めて、文字で頼む理由・コマンドの形・壊さない最初の1行・認証情報の扱いまでを1本にします。
この記事の結論
- AWS CLI とは、ブラウザの画面で押していることを、ターミナルの文字で AWS に頼む道具です。
- コンソールも CLI も SDK も、最後は同じ「API」に頼みごとを送っています。画面は窓口の1つにすぎません。
- 文字で頼む理由は、同じことを再現できる・やったことが記録に残る・自動化できる・100台に同じことができる、の4つです。
- コマンドの形は「aws サービス 動作 –オプション」。最初の1行は、自分が誰として認識されているかを見る読み取りのコマンドにします。
- 認証情報（アクセスキー）は鍵です。人に長期の鍵を配らず、ロールや IAM Identity Center を使う方向が公式の勧めです。
- CLI は間違えると本番に効くので、describe や list のような「読むだけ」の動作から始めます。
AWS CLI とは。コンソールも CLI も同じ「API」を叩いている
AWS CLI（Command Line Interface）は、AWS への頼みごとをターミナルの文字で出すための道具です。ターミナルの読み方で触った黒い画面に aws から始まる1行を打つと、AWS とは何かで見たコンソールと同じことが起きます。
「同じこと」と言い切れるのには理由があります。AWS の全サービスは、API（Application Programming Interface）という「頼みごとの窓口」を持っています。たとえるなら、役所の申請窓口です。「EC2 を1台立ててください」「S3 の一覧をください」という申請は、全部この窓口に届きます。
コンソールは、この窓口にブラウザの画面をかぶせたものです。ボタンを押すと、裏で画面が API に申請を出しています。CLI は同じ申請を文字で書いて出す。SDK はプログラムの中から出す。窓口は3つあっても、行き着く先の API は1つです。
ONE API, THREE DOORS窓口は違っても
どの窓口からでも、行き着く先は同じ API
画面で押す
- AWS のサービス（EC2・S3・IAM …）
- API — 頼みごとの唯一の入口
- 署名 — 認証情報で「誰の頼みか」を付ける
- 窓口 — コンソール / CLI / SDK
CLI で打つ
- AWS のサービス（EC2・S3・IAM …）
- API — 頼みごとの唯一の入口
- 署名 — 認証情報で「誰の頼みか」を付ける
- 窓口 — コンソール / CLI / SDK
コードで呼ぶ
- AWS のサービス（EC2・S3・IAM …）
- API — 頼みごとの唯一の入口
- 署名 — 認証情報で「誰の頼みか」を付ける
- 窓口 — コンソール / CLI / SDK
自分が見て・触る層裏で動く層
だから CLI で「できること」はコンソールと同じで、むしろ API に直接近いぶん、画面には出ていない細かい指定も書けます。逆に言えば、CLI を覚えることは「AWS が本当はどういう頼みごとを受け付けているか」を覚えることでもあります。
なぜ画面で押さず、文字で頼むのか
画面で押せば済むのに文字で書く理由は4つあり、どれも「1回きりでない仕事」で効いてきます。
- 再現できる。 画面の操作は「どこを押したか」が残らず、翌週同じことをやろうとしても手順が再現できません。文字の1行は、そのまま打てば同じ結果になります。
- 記録に残る。 打った1行をファイルに残せば、「いつ何をしたか」が文字で残ります。Git とは何かの台帳に載せれば、誰がいつ変えたかまで残ります。
- 自動化できる。 1行が動くなら、それを並べた台本（スクリプト）も動きます。毎朝の確認、夜間の停止、障害時の切り替えを、人が画面を押さずに回せます。
- 100台に同じことができる。 画面で100台を1台ずつ設定するのと、1行を100回回すのとでは、かかる時間もミスの数も違います。
CONSOLE VS CLI理解は画面、繰り返しは文字
見て分かるのが画面。残って回せるのが文字
コンソール（画面）
ボタンを押すと、裏で API に申請が出る
- 初めてのサービスの設定項目を眺められる
- 請求の内訳のように「見て理解する」に向く
- どこを押したかが残らず、翌週に再現しにくい
CLI（文字）
同じ申請を1行の文字で出す
- 1行がそのまま記録になり、再現できる
- 並べれば台本になり、人が押さずに回る
- 100台に同じことを、同じ時間でできる
コンソールが劣っているわけではありません。初めて触るサービスの設定項目を眺める、請求の内訳を見る、といった「見て理解する」作業は画面の方が向いています。理解は画面で、繰り返しは文字で。この使い分けが、実務でのふつうの形です。
なお、AWS Certified Cloud Practitioner（CLF-C02）の試験ガイドでも、AWS を操作する方法としてコンソール・CLI・SDK・API・IaC を区別できることが問われます。「全部同じ API に届く」と分かっていれば、この区別は暗記でなく理解になります。
CHECK 1ここまでの確認
コンソールで EC2 を1台立てるのと、CLI で1台立てるのとで、AWS の側から見て違うものはどれ?
答えと解説
答え: 3. 頼みごとを出す窓口だけ。届く API は同じ
コンソールも CLI も SDK も、最後は同じ API に署名付きの頼みごとを送っています。違うのは窓口で、AWS が受け取る内容は同じです。「コンソールも CLI も同じ API を叩いている」の節を読み直してください。
コマンドの形と、最初の1行
CLI の1行は、決まった形をしています。
aws <サービス> <動作> --<オプション> <値>
| 部分 | 意味 | 例 |
|---|---|---|
aws |
道具の名前。すべての行がこれで始まる | aws |
| サービス | 誰に頼むか | ec2 s3 iam sts |
| 動作 | 何をしてほしいか | describe-instances ls get-caller-identity |
| オプション | 条件や対象。無くてもよい | --region ap-northeast-1 --output table |
読み方は「aws さん、ec2 に、インスタンスの説明をお願いします」です。動作の名前は API の名前とほぼ同じなので、CLI のリファレンスを読むことが API を読むことになります。
最初の1行は、壊さないコマンドにします。この記事が勧めるのはこれです。
aws sts get-caller-identity
「自分は、いま誰として AWS に認識されているか」を返すだけの読み取りの動作です。アカウントの番号と、自分の識別子が返ってくれば、認証情報が正しく通って API まで届いた証拠になります。逆に、エラーになるなら「認証情報」か「経路」のどちらかで止まっていて、まだ何も壊していません。
FROM ONE LINE TO JSON1行が返ってくるまで
打った1行は、署名されて API に届き、JSON で返る
-
1行を打つ
aws sts get-caller-identity
-
CLI が翻訳
API の頼みごとの形にする
-
署名して送る
認証情報で「誰から」を付け、HTTPS で
-
サービスが実行
読むだけの動作なら何も変わらない
-
JSON で返る
アカウント番号と自分の識別子
打った1行は、CLI の中で API の頼みごとに翻訳され、認証情報で署名され、HTTPS で AWS に送られます。結果は JSON という形式の文字で返ってきます。JSON の読み方は別の記事で扱いますが、「波括弧で囲まれた、名前と値の組」だと分かっていれば最初は十分です。導入の手順（インストールと aws configure）は改定で変わるので、公式のユーザーガイドを見てください。
CHECK 2ここまでの確認
aws ec2 describe-instances の3つの部分は、順に何を表している?
答えと解説
答え: 2. 道具 → サービス → 動作
aws が道具、ec2 がサービス、describe-instances が動作です。オプションは --region のように後ろに付けます。「コマンドの形」の節を読み直してください。
認証情報は鍵。人に長期の鍵をなるべく配らない
aws configure で聞かれるアクセスキーは、CLI が「この頼みごとは誰からか」を API に示すための鍵です。SSH の秘密鍵と同じで、持っている人はその権限で何でも頼めます。だから扱いも同じです。人に渡さない、ファイルに貼って Git の台帳に載せない、チャットに貼らない。
もう1つ大事なのは、そもそも人に長期の鍵を発行しないという方向です。IAM ユーザーガイドのベストプラクティスは、人のユーザーには長期のアクセスキーではなく、IAM Identity Center などを通した一時的な認証情報を使うことを勧めています。EC2 の上で CLI を動かすなら、鍵を置かず、その1台にロール（役割）を付けて頼みごとをさせます。
アクセスキーでやってはいけない3つ
- ルートユーザーのアクセスキーを作る（アカウントの全権が鍵1つになる）
- 鍵を設定ファイルやコードに書いて、Git の台帳やチャットに載せる
- 使わなくなった鍵を消さずに残す（漏れても気づけない）
なぜ「一時的」が勧められるのか。長期の鍵は、漏れたことに気づくまでずっと使えてしまうからです。一時的な認証情報は数時間で失効するので、漏れても被害が続きません。この「誰に何を許すか」の話は IAM とは何かに続きます。
READ ALSO — 学習中向け・段1 入口
IAM とは何か｜ユーザー・ロール・ポリシーを「誰が・何に・何をしてよいか」で読み解く
CHECK 3ここまでの確認
CLI を使い始めた最初の日に打つコマンドとして、この記事が勧めているのはどれ?
答えと解説
答え: 2. aws sts get-caller-identity（自分が誰として認識されているかを見る）
最初の1行は「何も壊さず、認証情報が正しく通っているかを確かめる」コマンドにします。get-caller-identity は読むだけで、間違っても本番に効きません。「最初の1行」と「読み取り系から始める」の節を読み直してください。
「間違えると本番に効く」から、読み取り系から始める
CLI が怖いと言われる理由は、確認画面が無いことです。コンソールで削除を押すと「本当に消しますか」と聞かれますが、CLI は打った瞬間に API に届きます。そして API は、練習用も本番も区別しません。
だから始め方に順番があります。読む動作から始めて、変える動作はあとにする。動作の名前で見分けられます。
| 種類 | 動作の名前の例 | 何が起きるか | 最初の1週間に |
|---|---|---|---|
| 読む | describe-* list-* get-* ls |
何も変わらない。見るだけ | 好きなだけ打ってよい |
| 作る | create-* run-* put-* |
資源が増える。料金が発生しうる | 練習用の環境で、消し方を先に確かめてから |
| 消す・変える | delete-* terminate-* modify-* |
元に戻せないことがある | 対象を --dry-run や describe で確かめてから |
やることを短く言うと、こうなります。aws sts get-caller-identity で自分が誰かを確かめる。aws ec2 describe-instances で EC2 とは何かで立てた1台が見えることを確かめる。--output table を付けて読みやすくしてみる。その3つが通ったら、次に「作る」に進みます。料金の具体的な数値は公式の料金ページで確認してください。
READ ALSO — 未経験向け・段1 入口
EC2 とは何か｜インスタンス・AMI・EBS・セキュリティグループを「借りた1台」で理解する
まとめ
AWS CLI とは、画面で押していることを文字で AWS に頼む道具です。コンソールも CLI も SDK も同じ API に届いていて、画面は窓口の1つにすぎません。文字で頼むのは、再現できる・記録に残る・自動化できる・100台に同じことができるから。コマンドは「aws サービス 動作 –オプション」の形で、最初の1行は自分が誰かを見る読み取りのコマンドにします。認証情報は鍵で、人に長期の鍵を配らずロールや IAM Identity Center を使う方向が公式の勧め。間違えると本番に効くので、読む動作から始めます。
CLI で「頼みごと」の形が見えると、この先の IAM（誰に何を許すか）も、構成をコードで持つ話も、全部「API に何を頼んでいるか」で読めるようになります。次は IAM とは何かへ進んでください。
参照ソース
- AWS Command Line Interface とは（AWS CLI ユーザーガイド） — CLI がコンソールと同じ機能をコマンドラインから使えるツールであること、スクリプトによる自動化ができることの根拠（2026年9月時点）
- AWS CLI のコマンド構造（AWS CLI ユーザーガイド） — 「aws サービス 動作 オプション」の形の根拠（2026年9月時点）
- get-caller-identity（AWS CLI Command Reference） — 呼び出した認証情報の所有者（アカウント・ユーザーの識別子）を返すだけの読み取りの動作であることの根拠（2026年9月時点）
- AWS CLI の設定と認証情報（AWS CLI ユーザーガイド） — aws configure が認証情報とリージョンを設定すること、IAM Identity Center や EC2 のロールを認証情報の出どころにできることの根拠（2026年9月時点）
- IAM でのセキュリティのベストプラクティス（IAM ユーザーガイド） — 人のユーザーには一時的な認証情報を使うこと、長期のアクセスキーを避けること、ルートユーザーのアクセスキーを作らないことの根拠（2026年9月時点）
- AWS API リクエストの署名（IAM ユーザーガイド） — API への頼みごとが認証情報で署名されて送られることの根拠（2026年9月時点）
