AWSをCLIで理解したい！ める(@mel________27) 2026/02/28 JAWS-UG 名古屋 

Who am I？ 名前：める(@mel________27) 所属：三重県の某SIer 入社に伴って三重県へ来たので、三重県民は12年目 業務：インフラエンジニア 好きなサービス：AWS Cloud9、AWS CloudShell、AWS IAM 

はじめての…… 実は、はじめてのJAWS-UG参加、名古屋支部でした！！！（調べたところ、2018年） 本日、はじめてオフラインでのLTです！ 

AWSをCLIで理解したい！ なぜCLIか？ ・手順を作成する場合、GUIの変更を考慮しなくてよい ・GUIだとある程度何となくでも操作できる＆ バックグラウンドで自動で作成してくれるリソースもある →いざトラブルがあったときに、なんとなく作ったリソースで、対応できるのか？ 、、、というのはある程度建前で、AWSを学ぼうと（ちゃんと）し始めた当初 JAWS-UG CLI専門支部のハンズオンに出会ったことによる （そもそも、業務でLinuxサーバはさわるため、bashとの親和性はあったかも） 

やったこと① 「Amazon Web Services基礎からのネットワーク＆サーバー構築」の書籍を ひととおり操作のうえで、コマンドでの動作に書き直した 

やったこと② Network Firewallを構築するにあたり、下記の手順をCLI化して、そのまま業務活用 https://github.com/harunobukameda/AWS-Network-Firewall 

やったこと③ Transit Gatewayを理解するために手順をCLI化し、これも一部業務活用 https://catalog.us-east-1.prod.workshops.aws/workshops/e0d1c19d-c80b-4695-a3fc- 5c4a25132f47/ja-JP/ 

業務での活用① 実際の構築作業・設定変更などの運用作業について、CLIで手順化したうえで実行。 ・Direct Connectの設定 ・Transit Gatewayの設定／Recource Access Managerでの共有 ・Site-To-Site VPNの設定 ・Route 53 Resolverの設定 ・EC2の作業 ・IMDSのv1→v2への変更 ・終了保護の一括設定 ・IAMロールの作成 

業務での活用② 作業手順の提供・フォローの依頼があった場合、CLIでの手順を提供して実行してもらう →GUIのアップデートに追随しなくていい ※ただし、作業対象者が最低限AWS CLIの実行環境を整備できることが前提。 このため作業対象者によっては、GUIベースでの手順を展開することもある。 （CloudShellがあればCloudShellでよいが、CloudShellが使えない環境があるので） 

業務での活用③ トラブルシュート対応 指定のルートが追加されているか確認してほしい時、下記のコマンドの実行結果を提示依頼 # aws ec2 describe-subnets ¥ --filters Name=vpc-id,Values=${VPC_ID} --query "Subnets[].SubnetId" --output text | while read subnetid do for subnet in `echo ${subnetid}`; ¥ do ¥ routetableid=$( aws ec2 describe-route-tables ¥ --filters Name=association.subnet-id,Values=${subnet} ¥ --query "RouteTables[].RouteTableId" --output text ¥ ) && echo ${routetableid} && aws ec2 describe-route-tables ¥ --filters Name=vpc-id,Values=${VPC_ID} Name=route-table-id,Values=${routetableid} ¥ --query "RouteTables[].Routes[?DestinationCidrBlock == ¥`${ADD_ROUTE_CIDR}¥`]" ¥ ; ¥ done done 

サービス理解にあたりよかったこと 画面での操作以上にドキュメントを読み込むので、理解が深まる（気がする） 特にIAM周りは、はじめたての頃にめちゃくちゃ詰まった 初学者のタイミングでしっかり詰まって解決の過程で理解につながったのがよかった IAMポリシー、IAMロール、信頼ポリシー（信頼されたエンティティ）、 インスタンスプロファイル など 

業務利用にあたってよかったこと 類似の操作をたくさんしたいときに楽ができる（forやwhileでくりかえす） 事前に変数を設定したCLIスクリプトを作成しておくことで 作業時の入力ミスやオプションの指定ミスを防げる VPC IDやインスタンス IDが設定に必要な場合、タグ名から値を取得することで選択誤りが減る 作業ログをテキストで残せる（GUIのハードコピーを取らなくていい） オプションの設定意図がわかる＆きかれてもある程度答えることができる 必要な権限が作業コマンドと紐づくので、作業にかかる最小権限のロール作成を目指せる 

やっていてつらいこと オプションの形式によって、うまく指定できないことがある（入れ子になっているときなど） サービスによってはfilterオプションがあるようなものもあるが、 当該オプションがなく、JMASPATHのクエリで何とかするしかないものもある サービスによって、作成済みリソースのARNをオプションに指定する必要があるものの コマンドの出力結果には出てこないものもある（どうして……） →ARNの形式を読み解き、固定文字列とIDなどを組み合わせる形で設定 画面での構築より、（一回だけ、などであれば）めちゃ時間はかかる 

CLI vs IaC 業務利用にかかり、CloudFormationやCDKを利用するにかかる学習コスト → 現時点での作業要員（自分含む）としてはbashの方が適性が高い とはいえ、構築頻度の高いものは、Yamlで作成することもある CDKまではまだハードルが高い 上記に関連し、IaCで作成したリソースをメンテナンスするコスト →何をどこで設定しているかわからず、結局使い捨てになる Replacementが発生するかどうかの判断 CLIのスクリプトも、できるだけリソース単位で作成する →少し面倒だが、他への応用が利く（変数だけ変えて部分的に使う、など） 

今後の展望 オプションの指定方法は模索中 →事前にすべてJSONに出力しておいて、ログとセットでJSONを保存しておく……？ 作業準備の手間は増えるが、実際の変更・構築作業の短縮 →最近はJAWS-UG CLI専門支部では変数設定をテキスト化しておく手順になっているので その方がいいのかも？ あとからの視認性も含めて検討したい スクリプトの作成の効率化 →現状Markdownファイルに書いているが、もう少し効率化したい （CLI専門支部ではSphinxで手順の作成を自動化しているようなので、 そのような形が理想。実行時に扱いやすい形は？） 

まとめ AWS CLIはいいぞ！ 遠回りかもしれないが、小手先のものでない深い理解をしていきたい