AWSサービス一覧をカテゴリ別に整理｜CLIで数と利用状況を確認する手順

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

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

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

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

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

一覧そのものも、公式が常に正しいとは限りません。概要ドキュメントには、製品ページが既に閉じたサービスが載ったままの箇所がありました。一覧は「候補を洗い出す地図」として使い、採否は個別ドキュメントとCLIの結果で決める、という順番を守ると読み違えが減ります。

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

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

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

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

この分類は等価ではありません。コンピューティングやマネジメントとガバナンスには十数個のサービスがぶら下がる一方、量子テクノロジーや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認証の手順にまとめてあります。

カテゴリ別に見るAWSサービス一覧と主要サービスの役割早見表

「aws サービス一覧」で調べる人の多くが欲しいのは、全サービス名の羅列ではなく「このカテゴリなら、まずどれを見ればよいか」の当たりです。ここでは公式の各カテゴリページに載っているサービスから、受託開発の案件で名前が挙がる頻度の高いものを抜き出しました。掲載順や表記は2026年9月時点の概要ドキュメントに合わせています。

Web開発案件で触る確率が高い6カテゴリの主要サービスと役割の早見表

先に挙げた6カテゴリは、Webシステムや業務システムを1本立てるとほぼ必ず登場します。各カテゴリの全件は公式ページで確認でき、コンピューティングには仮想マシン・コンテナ・サーバーレス・エッジの系統が、データベースにはリレーショナル・キーバリュー・インメモリ・グラフなど用途別のサービスが並びます。

コンテナは概要ドキュメント上で独立したカテゴリを持つ一方、ECSやFargateはコンピューティングのページにも載っています。1つのサービスが複数のカテゴリに顔を出すため、カテゴリ別の件数を足し合わせても総数にはなりません。ECSとEKSのどちらに寄せるかはECSの仕組み・起動タイプ・EKSとの違いの解説で、ファイル共有の選び分けはEFSとS3・EBS・FSxの違いの解説で個別に掘り下げています。

セキュリティ・アイデンティティ・コンプライアンスのページは20を超えるサービスを並べていますが、初期構成で設定まで踏み込むのはIAM、IAM Identity Center、KMS、WAFあたりです。GuardDutyやSecurity Hub CSPMは、本番運用に入る前の段階で有効化を決める位置づけになります。

生成AI・分析・アプリ統合など要件が出てから足すカテゴリの代表サービス

残りのカテゴリは、要件が出た時点で候補を見に行けば足ります。ただし「どのカテゴリを見に行くか」の当たりが無いと、似た名前のサービスを取り違えます。代表例を要件の言葉から逆引きできる形にまとめました。

機械学習とAIのページでは、SageMakerが「Amazon SageMaker AI」の表記で載り、エージェント開発のKiroも同じ枠に並んでいます。名前だけで検索すると旧称の記事に当たりやすいカテゴリなので、公式ページの表記を正として控えておくことが、名称の取り違えを防ぐ方法です。生成AIの呼び出しから試す場合はAmazon Bedrockの料金・モデル・APIの始め方が入口になります。分析とアプリケーション統合も、それぞれ公式ページに全件が載っています。

AWSサービス一覧をCSVに書き出して社内の採用可否台帳にする手順

一覧を読んで終わりにせず、社内で「使ってよいサービス」を決める台帳に落とすと、案件ごとの選定会議が短くなります。service-quotasのサービス名と、東京リージョンで提供されている識別子を1つのCSVにまとめる例です。

# 1. サービスコードと表示名をCSVに書き出す（見出し行つき）
aws service-quotas list-services \
  --query 'Services[].[ServiceCode,ServiceName]' --output text \
  | awk -F'\t' 'BEGIN{print "service_code,service_name"} {printf "%s,\"%s\"\n", $1, $2}' \
  > aws_services.csv

# 2. 東京リージョンで提供されているサービス識別子を1行1件で保存する
aws ssm get-parameters-by-path \
  --path /aws/service/global-infrastructure/regions/ap-northeast-1/services \
  --query 'Parameters[].Value' --output text \
  | tr '\t' '\n' | sort > tokyo_services.txt

# 3. サービスコードが東京の一覧にあれば tokyo=yes を付ける
awk -F',' 'NR==FNR{t[$1]=1; next} FNR==1{print $0",tokyo,decision"; next} {print $0","(($1 in t)?"yes":"check")","}' \
  tokyo_services.txt aws_services.csv > aws_service_catalog.csv

3つ目の突き合わせは完全には一致しません。service-quotasのサービスコードとSSMパラメータの識別子は、同じサービスでも綴りが揃っていない場合があるためです。checkが付いた行は、SSM側の識別子を目で確かめてからyesへ直します。decision列には「標準採用」「要相談」「不採用」のような社内区分を手で入れていく運用が、実務では回しやすいものでした。

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

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

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

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

表の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のグローバルインフラパラメータは、リージョン配下にサービスを、サービス配下にリージョンを、双方向で持っています。パラメータストアそのものの仕組みや料金はSystems Manager（SSM）の機能一覧と料金の解説で扱っています。

# 東京リージョンで提供されているサービス識別子を出す
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つで大半の改称は捕まえられました。

公式の概要ドキュメントにも提供を終えたサービスが残る事例と見分け方

公式の一覧でさえ、個別サービスの終了に追随しきれていない箇所があります。マネジメントとガバナンスのページには、2026年9月25日時点でもOpsWorksが掲載されています。ところが同じ日に確かめると、OpsWorksの製品ページはAWSのトップページへ転送され、ユーザーガイドの入口URLは404を返しました。一覧に載っていることは、いま新規に使えることの証明にはなりません。

見分け方は、一覧から拾ったサービスの製品ページと公式ドキュメントへ実際にアクセスすることです。転送先がトップページになる、ドキュメントが見つからない、の2つはどちらも採用を止める合図になります。先に紹介したCSV台帳に「最終確認日」の列を足し、四半期ごとに製品ページの応答を確かめ直す運用にしておくと、終了済みのサービスを新規案件に持ち込む事故を防げます。

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

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

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

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

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

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

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

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

よくある質問

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

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

数え方によって変わるため、サービス総数を単一の数字で答えることは困難です。クォータ管理の対象を数えるaws service-quotas list-servicesと、グローバルインフラのパラメータに載る識別子では母集団が違い、件数も一致しません。公式の概要ドキュメントも、23のカテゴリ別にサービスを列挙してはいるものの総数は明示していません。1つのサービスが複数カテゴリに載るため、カテゴリごとの件数を足しても総数にはならない点にも注意が要ります。数字を覚えるより、必要なときに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へ移ったように名称ごと変わる例もあるため、サービス名で公式ドキュメントに当たり直す手順を挟んでください。公式の概要ドキュメント自体にも、OpsWorksのように製品ページが閉じたサービスが残っている箇所があるので、採用前には製品ページの応答まで確かめると確実です。

関連記事

• AWS CLIの導入と運用｜v2の設定・SSO認証・v1サポート終了への移行手順：この記事のコマンドを動かす前提となるCLIの設定と認証。
• AWS Cost Explorerとは？コスト可視化・分析の仕組みと料金・使いどころを実装者目線で解説：サービス別の課金内訳を画面側で深掘りする方法。
• AWS Organizationsとは？マルチアカウント管理・SCP/RCP・一括請求の仕組みと設計判断を実装者目線で解説：複数アカウントをまたいで棚卸しするときの土台。
• AWS Systems Manager（SSM）とは？機能一覧・料金・Session Managerの使いどころ：提供リージョンの確認に使うパラメータストアの仕組み。
• AWS ECSとは？コンテナの仕組み・起動タイプ・料金・EKSとの違い【2026年版】：コンテナカテゴリの主要サービスを選び分ける判断。
• クラウドとは？AWSとは何かを仕組み・料金・移行の判断まで事業者向けに解説：サービス選定の前段にあたる、クラウド利用そのものの判断。
• インフラ構築（AWS・Google Cloud・Azure）：構成設計から運用の切り分けまでの受託メニュー。