AWS CLIで置いて・立てて・片付けるまでを通しでやってみよう(総合演習)
ここまでの AWS レッスンで学んだコマンドをひとつの流れにつないで、クラウド上に作ったものを最後まで片付けます。
やることは「認証情報を設定する → ファイルを置く場所を作る → サーバーを立てる → 権限を渡す → 全部消す」。AWSを触る日は、この順序を毎回なぞることになります。
最後の「全部消す」を、この演習では省きません。AWSは作ったものが動いている間ずっと課金されます。消し方まで含めて手が動くようになって、はじめて安心して触れる——それがこの演習のいちばんの狙いです。
ページの一番下に本物の疑似ターミナルがあります。読むだけで終わらせず、必ず自分で打ってみてください。状態はコマンドをまたいで続くので、上から順に打てばそのまま完走できます。
ここは学習用の疑似環境です。本物のAWSアカウントには一切つながっておらず、料金も発生しません。安心して間違えてください。
完成イメージ
最後まで進むと、こう表示されるところまで作ります。下の実行結果は、このページを作るときに実際にコードを走らせて得たものです。
$ aws s3 ls
$ aws ec2 describe-instances
{
"Reservations": []
}
STEP 1認証情報を設定して、自分が誰かを確かめる
🎯 このステップのゴール: aws configure で鍵とリージョンを登録し、sts get-caller-identity で反映を確認する
aws --versionでCLIが入っていることを確かめたら、まずaws configureです。
これを済ませるまで、他のコマンドは全部失敗します。試しに先にaws s3 lsを打つとUnable to locate credentialsと返ってきます。AWS CLIは「誰として操作するのか」が決まらないと、何ひとつ実行しません。
aws configureが聞いてくるのは4つ。アクセスキーID・シークレットアクセスキー・既定のリージョン・出力形式です。
リージョンは「どこの国のデータセンターを使うか」。日本ならap-northeast-1(東京)を選びます。近いほど通信が速く、リージョンが違うと同じアカウントでも別の場所に作られて、あとから探して見つからなくなります。「作ったはずのものが一覧に出ない」の原因は、たいていリージョン違いです。
aws configure listで設定内容を確認します。鍵は末尾4文字しか表示されません——画面共有しても漏れないように、AWS側がそうしています。
仕上げがaws sts get-caller-identity。「いま自分は誰として操作しているのか」を返してくれるコマンドで、Arnにユーザー名が出ます。権限まわりで詰まったら、まずこれを打つ——思っていたのと違うユーザーで動いていた、というのはよくある話です。
aws --version aws configure aws configure list aws sts get-caller-identity
$ aws --version
aws-cli/2.15.30 Python/3.11.8
$ aws configure
AWS Access Key ID [None]: AKIAIOSFODNN7EXAMPLE
AWS Secret Access Key [None]: ****************EXAMPLE
Default region name [None]: ap-northeast-1
Default output format [None]: json
(認証情報が保存されました)
$ aws configure list
Name Value Type Location
---- ----- ---- --------
profile <not set> None None
access_key ****************MPLE shared-credentials-file
secret_key ****************MPLE shared-credentials-file
region ap-northeast-1 config-file ~/.aws/config
$ aws sts get-caller-identity
{
"UserId": "AIDACKCEVSQ6C2EXAMPLE",
"Account": "123456789012",
"Arn": "arn:aws:iam::123456789012:user/learner"
}
STEP 2S3にファイルの置き場所を作る
🎯 このステップのゴール: バケットを作り、ファイルをアップロードして、中身を一覧で確かめる
aws s3 mb s3://prodou-demo-2026でバケットを作ります。mbはmake bucketの略です。
バケット名には、他のサービスに無い厳しい制約があります。——世界中で重複しない名前でなければなりません。自分のアカウント内ではなく、全AWS利用者を通じて唯一である必要があります。testやimagesが通らないのはこのためで、日付や組織名を混ぜるのが定石です。
大文字とアンダースコアも使えません。小文字・数字・ハイフンだけです。バケット名がURLの一部になるから、という理由があります。
aws s3 lsでバケットの一覧、aws s3 cp ./index.html s3://prodou-demo-2026/でアップロードです。cpの向きは、ローカルからS3へも、S3からローカルへも書けます。s3://を左右どちらに置くかで決まります。
最後にaws s3 ls s3://prodou-demo-2026。バケット名を付けると、そのバケットの中身が出ます。付けないとバケット一覧——同じlsでも見えるものが変わるので、意識して打ち分けてください。
aws s3 mb s3://prodou-demo-2026 aws s3 ls aws s3 cp ./index.html s3://prodou-demo-2026/ aws s3 ls s3://prodou-demo-2026
$ aws s3 mb s3://prodou-demo-2026 make_bucket: prodou-demo-2026 $ aws s3 ls 2026-08-13 10:00:00 prodou-demo-2026 $ aws s3 cp ./index.html s3://prodou-demo-2026/ upload: ./index.html to s3://prodou-demo-2026/ $ aws s3 ls s3://prodou-demo-2026 2026-08-13 10:00:00 2048 index.html
STEP 3通信の入口を用意して、サーバーを1台立てる
🎯 このステップのゴール: セキュリティグループを作ってから、EC2インスタンスを起動する
サーバーを立てる前に、aws ec2 create-security-groupでセキュリティグループを作ります。
これはサーバーの前に立つ門番です。「どこからの、どの番号への通信を通すか」を決めます。既定では外からの通信をすべて拒否するので、Webサーバーなら80番と443番を開ける、という設定を後から足していきます。
順番に理由があります。セキュリティグループはrun-instancesのときに指定するもので、先に無いと割り当てられません。だから門を先に作り、それからサーバーを置きます。
aws ec2 describe-security-groupsを打つと、いま作ったweb-sgと、最初からあるdefaultの2つが並びます。
そしてaws ec2 run-instances。--image-idがOSのひな型(AMI)、--instance-typeがマシンの大きさです。t3.microはいちばん小さい部類で、学習や小さな検証に使われます。
返ってきたInstanceId——i-で始まる文字列を、必ず控えてください。止めるのも消すのも、この先は全部このIDで指定します。aws ec2 describe-instancesを打つとStateがrunning——ここから課金が始まっています。
aws ec2 create-security-group --group-name web-sg --description "web servers" aws ec2 describe-security-groups aws ec2 run-instances --image-id ami-0abcdef1234567890 --instance-type t3.micro aws ec2 describe-instances
$ aws ec2 create-security-group --group-name web-sg --description "web servers"
{
"GroupId": "sg-0000000003c6ef362"
}
$ aws ec2 describe-security-groups
{
"SecurityGroups": [
{
"GroupId": "sg-0123456789abcdef0",
"GroupName": "default"
},
{
"GroupId": "sg-0000000003c6ef362",
"GroupName": "web-sg"
}
]
}
$ aws ec2 run-instances --image-id ami-0abcdef1234567890 --instance-type t3.micro
{
"Instances": [
{
"InstanceId": "i-0123456789abcdef0",
"InstanceType": "t3.micro",
"State": {
"Name": "running"
}
}
]
}
$ aws ec2 describe-instances
{
"Reservations": [
{
"Instances": [
{
"InstanceId": "i-0123456789abcdef0",
"InstanceType": "t3.micro",
"State": {
"Name": "running"
}
}
]
}
]
}
STEP 4名前を付けて、止めて、また動かす
🎯 このステップのゴール: タグで見分けが付くようにし、stop と start で課金を止めたり再開したりする
ここから先は、コマンドにインスタンスIDを書きます。この演習環境では、上から順に打っていればページと同じi-0123456789abcdef0が出ているのでそのまま使えます。ただし本物のAWSでは、IDは起動のたびにランダムに発行されます。実際の現場では、run-instancesやdescribe-instancesの出力に出たIDをコピーして次のコマンドに貼る——AWS CLIの作業は、ほぼこれの繰り返しです。
まずaws ec2 create-tagsでタグを付けます。Key=Name,Value=web01と書くと、管理画面の「名前」欄にこれが出ます。
タグを軽く見ないでください。EC2は増えるとIDだけでは何が何だか分からなくなります。NameのほかにEnv=productionやOwner=team-aを付けておくと、タグごとに料金を集計できます。「どのプロジェクトがいくら使ったか」が答えられるかどうかは、ここで決まります。
実行しても何も表示されません。これで正常です——本物のAWS CLIも、タグ付けが成功したときは沈黙します。確かめたいならdescribe-instancesを打ちます。
次にaws ec2 stop-instances。CurrentStateがstoppingで返り、少し待つとstoppedになります。
ここが料金の話でいちばん大事なところです。stoppedの間はサーバー本体の時間課金は止まります。ただしディスク(EBS)の料金は止まりません。中身が保存されているからです。「止めたのに請求が来る」の正体はこれで、完全に止めたいなら次のステップのterminateまで進む必要があります。
aws ec2 start-instancesで再開できます。停止と再開を繰り返しても、中のデータは残ります。使わない夜間だけ止める、という運用が成り立つのはこのおかげです。
aws ec2 create-tags --resources i-0123456789abcdef0 --tags Key=Name,Value=web01 aws ec2 stop-instances --instance-ids i-0123456789abcdef0 aws ec2 describe-instances aws ec2 start-instances --instance-ids i-0123456789abcdef0
$ aws ec2 create-tags --resources i-0123456789abcdef0 --tags Key=Name,Value=web01
$ aws ec2 stop-instances --instance-ids i-0123456789abcdef0
{
"StoppingInstances": [
{
"InstanceId": "i-0123456789abcdef0",
"CurrentState": {
"Name": "stopping"
},
"PreviousState": {
"Name": "running"
}
}
]
}
$ aws ec2 describe-instances
{
"Reservations": [
{
"Instances": [
{
"InstanceId": "i-0123456789abcdef0",
"InstanceType": "t3.micro",
"State": {
"Name": "stopped"
}
}
]
}
]
}
$ aws ec2 start-instances --instance-ids i-0123456789abcdef0
{
"StartingInstances": [
{
"InstanceId": "i-0123456789abcdef0",
"CurrentState": {
"Name": "pending"
},
"PreviousState": {
"Name": "stopped"
}
}
]
}
STEP 5作業用のユーザーを作って、必要な権限だけ渡す
🎯 このステップのゴール: IAMユーザーを作り、ロールに読み取り専用のポリシーを付ける
aws iam list-usersを打つと、まだ誰もいません。aws iam create-user --user-name deploy-botで、自動処理用のユーザーを1つ作ります。
なぜ自分のアカウントで済ませないのか。自動デプロイの仕組みに自分の鍵を渡すと、その鍵が漏れたとき、あなたにできること全部ができてしまいます。用途ごとにユーザーを分けておけば、漏れても被害はその用途の範囲に収まり、そのユーザーだけ消せば止められます。
次がaws iam attach-role-policy。ポリシーが「何をしてよいか」を書いた紙、ロールがその紙を持つ立場です。ここではAmazonS3ReadOnlyAccess——S3を読むことはできるが、書き換えも削除もできない権限を渡しています。
IAMの原則は「最小権限」です。迷ったら広い権限を付けたくなりますが、逆にしてください。まず何も渡さず、動かなかった分だけ足していく。AdministratorAccessを付ければ確かに全部動きますが、その鍵が漏れた瞬間にアカウント全体が乗っ取られます。
aws iam list-attached-role-policiesで、いま付いている権限を確認します。権限まわりのエラーが出たときの調べ方はいつも同じ——sts get-caller-identityで「誰か」を確かめ、このコマンドで「何ができるか」を確かめる。この2つでほとんど切り分けられます。
aws iam list-users aws iam create-user --user-name deploy-bot aws iam attach-role-policy --role-name deploy-role --policy-arn arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess aws iam list-attached-role-policies --role-name deploy-role
$ aws iam list-users
{
"Users": []
}
$ aws iam create-user --user-name deploy-bot
{
"User": {
"UserName": "deploy-bot",
"UserId": "AIDA00000000078dde6c4",
"Arn": "arn:aws:iam::123456789012:user/deploy-bot"
}
}
$ aws iam attach-role-policy --role-name deploy-role --policy-arn arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess
$ aws iam list-attached-role-policies --role-name deploy-role
{
"AttachedPolicies": [
{
"PolicyName": "AmazonS3ReadOnlyAccess",
"PolicyArn": "arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess"
}
]
}
STEP 6全部消して、課金を止める
🎯 このステップのゴール: インスタンスを終了し、S3のファイルとバケットを削除して、空の状態に戻す
最後は片付けです。AWSでは、これが最も大事な操作です。
aws ec2 terminate-instancesでインスタンスを完全に削除します。stopとの違いをはっきりさせておきます——stopは一時停止で後から再開でき、中のデータも残ります。terminateは削除で、二度と戻せません。ディスクの中身も一緒に消えます。
確認は聞かれません。打った瞬間に実行されます。IDを打ち間違えて別のサーバーを消した、という事故が本当に起きます——だから本番環境では、削除前に必ずdescribe-instancesでタグを見て、消してよいものか確かめます。ステップ4で付けたNameタグが効いてくるのはこの場面です。
S3も片付けます。aws s3 rmでファイルを消し、aws s3 rbでバケットを削除——rbはremove bucketの略です。
順番が決まっています。中身が残っているバケットは削除できません。だからファイルが先、バケットが後。中身ごと消したいならaws s3 rb --forceですが、これは中のファイルを全部消してから消すので、実行前に必ずlsで確認してください。
aws s3 lsとaws ec2 describe-instancesで確かめます。バケットは1つも無く、Reservationsも空——最初の状態に戻りました。ここまでやって、はじめて課金がゼロになります。
これで完走です。設定 → 置く → 立てる → 権限 → 片付け。AWSで何をするときも、この5つの骨格は変わりません。あとはサービスが増えていくだけです。
ページ下の疑似ターミナルで、ここまでを最初から自分の手で通してみてください。特に片付けは、手が覚えているかどうかで請求額が変わります。
aws ec2 terminate-instances --instance-ids i-0123456789abcdef0 aws s3 rm s3://prodou-demo-2026/index.html aws s3 rb s3://prodou-demo-2026 aws s3 ls aws ec2 describe-instances
$ aws ec2 terminate-instances --instance-ids i-0123456789abcdef0
{
"TerminatingInstances": [
{
"InstanceId": "i-0123456789abcdef0",
"CurrentState": {
"Name": "shutting-down"
},
"PreviousState": {
"Name": "running"
}
}
]
}
$ aws s3 rm s3://prodou-demo-2026/index.html
delete: s3://prodou-demo-2026/index.html
$ aws s3 rb s3://prodou-demo-2026
remove_bucket: prodou-demo-2026
$ aws s3 ls
$ aws ec2 describe-instances
{
"Reservations": []
}
仕上げ自分で最初から打ってみよう
🎯 このステップのゴール: ここまでの流れを、自分の手で最後まで通す
下は本物の疑似ターミナルです。まっさらな状態から始まるので、STEP1のコマンドから順に打って、マージまで辿り着いてください。読んで分かった気になるのと、自分で打てるのとは別物です。
詰まったら上のステップに戻って構いません。resetと打てば最初からやり直せます。
よくある質問
IDがページと違って、コマンドがエラーになります
打った順番がずれています。この演習環境のIDは乱数ではなく、作った順番から決まります。上から順に打っていれば、ページと同じi-0123456789abcdef0が出ているはずです。途中で別のコマンドを挟むと、連番がずれて違う値になります。
どちらにしても直し方は同じです。aws ec2 describe-instancesを打って、いま手元に出ているInstanceIdをコピーして貼り替えてください。
本物のAWSでは、IDは毎回ランダムに発行されます。だから実際の現場では、この「出力のIDを次のコマンドに渡す」手順が必ず要ります。覚えておいて損はありません。
stop と terminate は、結局どちらを使えばいいですか
また使うならstop、もう使わないならterminateです。
stopは一時停止です。サーバー本体の時間課金は止まりますが、ディスク(EBS)の料金は掛かり続けます。中のデータが保存されているためで、startすれば元の状態から再開できます。
terminateは削除です。課金は完全に止まりますが、ディスクの中身ごと消えて元に戻せません。学習で作ったものはterminateまで進めるのが安全です。
バケットが作れません(BucketAlreadyExists と出ます)
バケット名は世界中で重複できません。自分のアカウント内ではなく、全AWS利用者を通じて唯一である必要があります。testやbackupのような一般的な名前は、まず通りません。
組織名・用途・日付を組み合わせてください。また大文字とアンダースコアは使えません——小文字・数字・ハイフンだけです。
作ったはずのリソースが一覧に出てきません
リージョンを確認してください。AWSのほとんどのサービスはリージョンごとに独立していて、東京リージョンで作ったEC2は、バージニアリージョンの一覧には出ません。
aws configure listで現在のリージョンを確かめ、違う場所を見たいときは--region us-east-1のようにコマンドに付けます。
それでも見つからないならaws sts get-caller-identityです。思っていたのと違うアカウントで操作していたことがあります。
この演習で本物のAWSに料金は発生しますか
発生しません。ここは学習用の疑似環境で、本物のAWSには一切つながっていません。認証情報も架空のものです。
本物のアカウントで同じことを試すときは、必ずステップ6の片付けまで実行してください。起動したまま忘れたEC2は、使っていなくても課金され続けます。
🚩 次はこのカテゴリへ
手でコマンドを打ってAWSを作れるようになったら、次はそれを設定ファイルに書く番です。Terraformカテゴリでは、いま打ったのと同じ構成をコードで表して、何度でも同じものを作り直せるやり方を学びます。「あのとき何を打ったか」を思い出さなくて済むようになります。
Terraformのレッスンへ進む