2026.09.22 aws

AWSのサービスを数え方から選ぶ｜CLIで一覧と利用状況を確認する手順

Q: AWSのサービスは全部でいくつありますか？

数え方によって変わるため、サービス総数を単一の数字で答えることは困難です。クォータ管理の対象を数える aws service-quotas list-services と、グローバルインフラのパラメータに載る識別子では母集団が違い、件数も一致しません。公式の概要ドキュメントも、カテゴリ別にサービスを列挙してはいるものの総数は明示していません。数字を覚えるより、必要なときにCLIで引き直す手順を持っておくほうが実務では使えます。

Q: 使っていないサービスに課金されていないか確認する方法は？

Cost ExplorerのGetCostAndUsageを --group-by Type=DIMENSION,Key=SERVICE で呼び、サービス別の金額を出すのが最短です。停止中や空のリソースは課金に出ないため、Resource Explorerでリージョン横断のリソース検索を併用します。この2つを組み合わせると、請求に出るものと出ないものの両方を拾えます。

AWSのサービス一覧を眺めても、自分の案件でどれを使うかは決まりません。決め手になるのは3つの問いです。公式はサービスをどう分類しているのか。いま自分のアカウントで何が動いていて、どこに課金されているのか。そのサービスは東京リージョンで使えるのか。この記事では、公式ドキュメントのカテゴリ分類を起点に、aws service-quotas list-servicesとSSMのグローバルインフラパラメータで一覧を機械的に取り出し、Cost ExplorerとResource Explorerで利用実態を洗い出すまでをコード付きで整理しました。一覧記事が陳腐化する改称・統合への追随手順も添えます。

まとめ｜AWSのサービス選定はカテゴリ分類と利用実態の把握から

AWSのサービスは、AWSの概要ドキュメントで20を超えるカテゴリに分けて並べられています。全部を覚える前提は捨ててよく、実務で先に固まるのは計算・保管・データベース・ネットワーク・権限の5系統です。この5つで骨格を作り、残りは要件が出てから足すほうが構成は崩れません。

「何種類あるか」を数字で覚える意味は薄いものでした。数える主体によって答えが変わるからです。クォータ管理の対象を数えるservice-quotas list-servicesと、グローバルインフラのパラメータに載る識別子では件数が一致しません。暗記ではなく、必要なときにCLIで引き直す経路を持っておくほうが実務では効きます。

選定で最後に効くのはリージョンの提供状況でした。東京（ap-northeast-1）に無いサービスを前提に設計すると、設計書の段階では通っても構築で止まります。提供状況はSSMのパラメータで引けるため、選定の初期にコマンド1本で潰せる論点です。

AWS概要ドキュメントが並べる20超のカテゴリと分類粒度の実際

まず公式がどう区切っているかを押さえます。第三者のまとめ記事ではなく、AWS自身の分類を基準にしたほうが、サービス名が変わったときの追随が楽になります。

コンピューティングから量子テクノロジーまでの分類と粒度の偏り

AWSの概要ドキュメントは、分析、アプリケーション統合、ブロックチェーン、ビジネスアプリケーション、クラウド財務管理、コンピューティング、Customer Enablement、コンテナ、データベース、デベロッパーツール、エンドユーザーコンピューティング、フロントエンドウェブおよびモバイル、ゲームテクノロジー、IoT、機械学習とAI、マネジメントとガバナンス、メディア、移行と転送、ネットワークとコンテンツ配信、量子テクノロジー、Satellite、セキュリティ・アイデンティティ・コンプライアンス、ストレージといった単位でサービスを並べています。

この分類は等価ではありません。コンピューティングやマネジメントとガバナンスには十数個のサービスがぶら下がる一方、量子テクノロジーやSatelliteは数個です。カテゴリ名を上から順に読んでいく学習法が続かないのは、この偏りが理由でした。案件で触る確率が高いのは、コンピューティング、ストレージ、データベース、ネットワークとコンテンツ配信、セキュリティ・アイデンティティ・コンプライアンス、マネジメントとガバナンスの6カテゴリに集中します。クラウドそのものの仕組みや費用構造から押さえたい場合は、クラウドとAWSの仕組み・料金・移行判断の解説を先に読むと、カテゴリの意味が繋がります。

service-quotasとSSMパラメータでサービス識別子を数える手順

サービスの数は、公式の宣伝文句を引用するより自分で数えたほうが確実です。数え方は2通りあります。service-quotasのlist-servicesはクォータ管理の対象サービスをServiceCodeとServiceNameの組で返し、Systems Managerのグローバルインフラパラメータはリージョン展開されているサービス識別子をパス配下に持っています。

# 1. クォータ管理の対象サービスを数える（ページングは自動）
aws service-quotas list-services --query 'length(Services)'

# 2. サービスコードと表示名を一覧にする
aws service-quotas list-services \
  --query 'Services[].[ServiceCode,ServiceName]' --output text

# 3. グローバルインフラのパラメータからサービス識別子を取り出す
aws ssm get-parameters-by-path \
  --path /aws/service/global-infrastructure/services \
  --query 'Parameters[].Name | sort(@)' --max-items 500 --output text

2つの結果は一致しません。1つ目はクォータの概念があるサービスだけ、3つ目はリージョン単位で展開されている識別子だけを返すためです。どちらも「AWSのサービス総数」そのものではない点が、記事ごとに「200以上」「324個」と数字が食い違う理由を理解する手がかりです。--page-sizeは1〜100の範囲で指定でき、件数の多いパス配下を引くときは--max-itemsと併用します。CLIそのものの導入やSSO認証の設定はAWS CLI v2の設定とSSO認証の手順にまとめてあります。

EC2・S3・RDSなど最初に押さえる中核サービスと役割の切り分け

数を数えた次は、どこから触るかです。案件の初期構成は、実際には十数個のサービスで組み上がります。

計算・保管・データベースの3層で見る最小構成と要件別の代替サービス

Webシステムを1本立てる最小構成は、計算・保管・データベースの3層に、ネットワークと権限を足した形に落ち着きます。層ごとに既定の選択肢と代替があり、要件によって入れ替えます。

層	既定の選択肢	代替	入れ替える条件
計算	Amazon EC2	AWS Lambda / Amazon ECS	常時稼働でない処理、コンテナ前提の開発体制
保管	Amazon S3	Amazon EFS / Amazon FSx	POSIX互換のファイル共有が要る場合
データベース	Amazon RDS	Aurora / DynamoDB	書き込み集中、キーバリューで足りる参照系
ネットワーク	Amazon VPC	—	入れ替え不可（全構成の土台）
権限	AWS IAM	—	入れ替え不可（全構成の土台）

表のAuroraはAmazon Aurora、DynamoDBはAmazon DynamoDBを指します。VPCとIAMに代替が無いのは、他のサービスがこの2つの上に乗るからです。逆に言えば、サービス選定で迷ったときに最初に確認するのは「そのサービスをVPC内に置けるか」「どのIAMポリシーで制御するか」の2点でした。この2点が曖昧なサービスは、後から監査要件に引っかかります。

サーバーレスとEC2のどちらを既定にするかを稼働率と開発体制で分ける条件

「まずLambdaで」と始めて詰まる典型は、常時稼働のワークロードをリクエスト課金で回し続けるケースです。判断は稼働率で切ります。日中だけ動く社内システムやイベント駆動のバッチはサーバーレス側、24時間リクエストが途切れないAPIや、常駐プロセスが状態を持つ処理はEC2やECS側に寄せたほうが、費用と運用の両面で読みやすくなります。

もうひとつの分岐は開発体制です。ローカルでコンテナを動かしてテストする習慣がないチームにECSを渡すと、デプロイのたびに手が止まります。サービスの優劣ではなく、そのチームが日常的に再現できる実行環境かどうかで決める。検証段階なら、AWSの無料枠と6か月の期限の境界を確認したうえで、課金が発生しない範囲で両方を試すほうが早く決着します。

アカウント内で実際に動いているサービスをCLIで洗い出す手順

引き継いだアカウントや、数年運用してきた環境で最初にやることは棚卸しです。コンソールのサービス一覧を上から開いて回る方法は、リージョンの数だけ作業が増えるため現実的ではありません。

サービス別の課金内訳をget-cost-and-usageで出す手順

何が動いているかを把握する手がかりは、課金の内訳です。GetCostAndUsage APIはTimePeriod・Granularity・Metricsを必須に取り、GroupByのDIMENSIONにSERVICEを指定するとサービス単位の金額に割ってくれます。Granularityに指定できるのはDAILY・MONTHLY・HOURLYの3つ、MetricsはUnblendedCostやAmortizedCostなどから選びます。

# 先月1か月をサービス別に割って、金額の大きい順に読む
aws ce get-cost-and-usage --region us-east-1 \
  --time-period Start=2026-08-01,End=2026-09-01 \
  --granularity MONTHLY \
  --metrics UnblendedCost \
  --group-by Type=DIMENSION,Key=SERVICE \
  --query 'ResultsByTime[0].Groups[].[Keys[0],Metrics.UnblendedCost.Amount]' \
  --output text

終了日は期間に含まれないため、8月分を見るならEndは9月1日を指定します。出力を金額順に並べると、たいてい上位5サービスで請求の大半を占め、下のほうに「誰も説明できない数ドル」が残ります。この残りが棚卸しの対象でした。UsageQuantityは単位が混ざるため、集計するならUsageTypeでフィルタしてから使います。画面側での深掘りや分析の仕組みはAWS Cost Explorerのコスト可視化と料金の解説にまとめました。

Resource Explorerで作成済みリソースを横断検索する設定

課金が出ないリソースは費用の一覧に現れません。停止中のEC2インスタンス、空のDynamoDBテーブル、作りかけのIAMロールなどです。ここを拾うのがAWS Resource Explorerで、名前・タグ・IDといったメタデータでリソースを検索できます。

設定はインデックスの作り方だけ覚えれば足ります。リージョンごとにローカルインデックスを有効化し、リージョンをまたいで検索したい場合はアグリゲーターインデックスを置く。ビューの作成、リージョンの有効化、検索そのものに料金はかかりません。ただしResource Explorerがインベントリを構築する過程で利用者に代わってAPIを呼ぶため、その呼び出し分の料金が発生する場合があると公式ドキュメントは注記しています。複数アカウントをまたぐ棚卸しでは、AWS Organizationsのマルチアカウント管理と一括請求の枠組みと合わせて、どのアカウントから検索するかを先に決めておきます。

東京リージョン未提供サービスの確認手順とデータ保管条件による代替構成の決め方

提供状況の確認は、設計の最初に済ませる工程です。ここを飛ばすと、構築フェーズで「東京には無い」と判明して構成ごと引き直しになります。

SSMパラメータでサービスの提供リージョンを引く手順と注意点

一覧表を目視で追う方法もありますが、コマンドで引いたほうが確実です。Systems Managerのグローバルインフラパラメータは、リージョン配下にサービスを、サービス配下にリージョンを、双方向で持っています。

# 東京リージョンで提供されているサービス識別子を出す
aws ssm get-parameters-by-path \
  --path /aws/service/global-infrastructure/regions/ap-northeast-1/services \
  --query 'Parameters[].Value' --max-items 500 --output text

# 逆に、あるサービス（例: ssm）が使えるリージョンを引く
aws ssm get-parameters-by-path \
  --path /aws/service/global-infrastructure/services/ssm/regions \
  --query 'Parameters[].Value' --output text

# サービスのリージョンエンドポイントを確認する
aws ssm get-parameter \
  --name /aws/service/global-infrastructure/regions/ap-northeast-1/services/ssm/endpoint \
  --query 'Parameter.Value'

注意点が2つあります。ひとつは、このパス配下を引けるリージョンが限られること。公式ドキュメントはus-east-1・us-west-2・ap-northeast-1・eu-west-1などを挙げており、対象外のリージョンで作業しているときは--regionで明示します。もうひとつは、パラメータに載るのがサービス単位である点です。サービスは提供されていても特定の機能や生成AIのモデルだけ東京に無い、という段差はここには出ません。機能単位の可否はリージョン別のサービス提供表と各サービスのドキュメントで裏を取ります。

東京リージョンに無いサービスを使う場合の選択肢とデータ保管の判断条件

東京に無いと分かったときの手は3つです。別リージョンで動かす、東京にある別サービスで代替する、提供開始を待つ。判断はデータの置き場所で切ります。

別リージョン実行：処理対象が公開データやログで、個人情報を含まない場合に採る。レイテンシと、リージョン間のデータ転送料金が増える点を見積もりに入れる。
東京の別サービスで代替：契約や社内規程でデータの国内保管が条件になっている場合は、こちらしか通らない。機能が8割でも代替を選ぶ。
提供開始を待つ：公式に東京展開の告知がある場合に限る。告知が無い段階で「そのうち来る」を前提にスケジュールを組むと、リリース日が人質になる。

3つ目を採る判断は慎重にしたほうがよいものでした。展開時期の見通しが立たないまま待つ構成は、待っている間ずっと代替案の検討コストを払い続けることになります。

サービス一覧が陳腐化する改称・終了の実例と公式情報への追随手順

サービス一覧を扱う記事やスライドは、公開した瞬間から古くなります。名前が変わる、機能が別サービスへ吸収される、新規受付が止まる。この3種類が主な変化です。

QuickSightのQuick Suite統合に見る改称の追い方と確認先

実例として分かりやすいのがAmazon QuickSightです。Amazon Quickの公式ドキュメントによれば、QuickSightはAmazon Quickへと引き継がれ、BIの機能はQuick Suiteを構成する「Amazon Quick Sight」として存続しています。同じ枠組みにQuick Flows、Quick Automate、Quick Index、Quick Researchが並ぶ構成です。既存のQuickSight API・SDK・統合は変更なく動作すると明記されているため、実装をすぐ書き換える必要はありません。

追随の実務は単純です。2026年9月時点で旧ドキュメントのURL（quicksight配下）へアクセスすると新しいquick配下へ転送されるため、社内資料のリンクが転送されているかどうかで改称を検知できます。リンク切れやリダイレクトを定期的に洗う運用を持っておくと、記事や設計書の更新漏れを機械的に拾えます。加えて、サービス名で検索して公式ドキュメントのトップに当たり、タイトルが変わっていないかを確認する。この2つで大半の改称は捕まえられました。

新規サービスを採用しない3条件と運用要件から見る既存構成で足りる場面の判断

サービスが多いことは、採用する理由になりません。使わない判断を条件付きで決めておくと、選定の会議が短くなります。

東京未提供・運用担当が1人・監査要件で新規採用を見送る3つの条件

次の3条件のどれかに当たるなら、そのサービスは採用しないほうが総コストは下がります。第一に、東京リージョンで提供されておらず、かつ扱うデータに個人情報が含まれる場合。国内保管の要件と衝突するため、機能の良し悪し以前に選べません。第二に、運用担当が実質1人で、そのサービスの障害対応手順を書ける人が他にいない場合。属人化した構成は、担当者の異動でそのまま塩漬けになります。

第三に、監査やセキュリティ要件でログの保全期間が決まっているのに、そのサービスのログがCloudTrailのデータイベントに対応していない場合。後から「誰がいつ触ったか」を出せない構成は、監査の指摘で作り直しになります。3条件のいずれにも当たらないなら、新しいサービスを試す判断は妥当でした。

マネージドサービスを外してEC2上で自前運用に戻す契約・保守の判断基準

マネージドサービスが常に正解とは限りません。戻す判断が正当化されるのは、バージョンの固定が契約上の要件になっている場合です。マネージド側は保守期限に合わせて強制的にバージョンが上がるため、検証済みの特定バージョンで止め続ける要件とは相性が悪い。この条件下ではEC2上で自前運用に戻すほうが、要件を満たしたまま運用できます。

逆に、費用が理由でマネージドを外す判断はほぼ失敗します。RDSをEC2上のデータベースへ置き換えると月額は下がりますが、バックアップ・フェイルオーバー・パッチ適用の手順を自分たちで作ることになり、人件費で逆転する。判断の分かれ目は「運用手順を書いて維持できる人が社内にいるか」の一点でした。どの層を任せてどこを自社で持つかの切り分けから相談したい場合は、AWS・Google Cloud・Azureのインフラ構築支援で構成の設計から引き受けています。

よくある質問

「aws サービス」で検索したときに続けて調べられている論点を5つ取り上げます。

AWSのサービスは全部でいくつありますか？

数え方によって変わるため、サービス総数を単一の数字で答えることは困難です。クォータ管理の対象を数えるaws service-quotas list-servicesと、グローバルインフラのパラメータに載る識別子では母集団が違い、件数も一致しません。公式の概要ドキュメントも、カテゴリ別にサービスを列挙してはいるものの総数は明示していません。数字を覚えるより、必要なときにCLIで引き直す手順を持っておくほうが実務では使えます。

最初に覚えるべきAWSサービスはどれですか？

Amazon VPC、AWS IAM、Amazon EC2、Amazon S3、Amazon RDS、Amazon CloudWatchの6つから入ると、Webシステムの標準構成が組めます。VPCとIAMはどの構成にも入る土台なので、この2つの理解が浅いまま他のサービスを増やすことは、権限設計が破綻する原因です。サーバーレスやコンテナは、この6つで一度構成を作った後に比較したほうが判断しやすくなります。

使っていないサービスに課金されていないか確認する方法は？

Cost ExplorerのGetCostAndUsageを--group-by Type=DIMENSION,Key=SERVICEで呼び、サービス別の金額を出すのが最短です。停止中や空のリソースは課金に出ないため、Resource Explorerでリージョン横断のリソース検索を併用します。この2つを組み合わせると、請求に出るものと出ないものの両方を拾えます。

東京リージョンで使えないサービスはどう調べますか？

aws ssm get-parameters-by-path --path /aws/service/global-infrastructure/regions/ap-northeast-1/servicesで、東京リージョンに展開されているサービス識別子の一覧が取れます。サービス側から引くならservices/{識別子}/regionsのパスです。ただしパラメータはサービス単位のため、機能やモデル単位の可否はリージョン別のサービス提供表と各サービスのドキュメントで確認します。

AWSのサービス一覧はどこを見れば最新ですか？

AWSの概要ドキュメントのカテゴリ別ページが公式の分類で、提供状況はリージョン別のサービス提供表が一次情報です。第三者がまとめた一覧記事は、改称や統合に追随していない場合があります。QuickSightがAmazon Quick SuiteのQuick Sightへ移ったように名称ごと変わる例もあるため、サービス名で公式ドキュメントに当たり直す手順を挟んでください。