AWSの勉強を始めると、多くの人が最初につまずきます。
- サービス名が多すぎる
- どれが重要なのか分からない
- 覚えても、結局使いどころが分からない
でもこれは、やり方が間違っているわけではありません。
問題はただ一つ。サービス名から理解しようとしていることです。
サービス名を覚える前に「地図」を持つ
AWSを理解するときに必要なのは、知識ではなく地図です。
- どんな役割のサービス群があって
- その中に、どんなサービス名がぶら下がっているのか
この順番が逆になると、必ず迷子になります。
AWSサービスは「役割」で分類すると一気に楽になる
AWSのサービスは機能ではなく役割で分けるとシンプルです。
大枠は、たった4つ。
① 計算する（Compute）
役割はそのまま。
- プログラムを動かす
- 処理を実行する
という領域。
アプリケーションが「実際に動く場所」を担当します。
② 保存する（Storage）
- データを置く
- データを残す
- データを取り出す
ための領域。
- ファイル
- データ
- バックアップ
など、消えてはいけない情報を扱います。
③ つなぐ（Network）
- システム同士をつなぐ
- システム同士を分ける
- 外と通信させる
ための領域。
- インターネット
- 社内システム
- 他サービス
との交通整理をする役割です。
④ 守る（Security）
- 誰が使えるか
- どこまで触れるか
- どう守るか
を決める領域。
セキュリティは「最後に足すもの」ではなく、最初から前提にある役割です。
なぜこの分類で考えると営業が楽になるのか
営業として重要なのは、「どのサービスがすごいか」ではなく「どの役割が必要か」を整理することです。
たとえば、「AWSを使いたい」と言われたとき、いきなりサービス名を考える必要はありません。
まずは、
- 処理を動かしたいのか（計算）
- データを置きたいのか（保存）
- 外部とつなぎたいのか（通信）
- 権限を管理したいのか（守る）
この 役割レベル で話を整理する。
それだけで、
- 会話が噛み合う
- エンジニアとも話しやすい
- 無理に詳しくならなくていい
状態が作れます。
サービス名は「ラベル」に過ぎない
ここが、とても大事な視点です。
EC2、S3、VPC…
これらはすべて、役割に付けられた“名前（ラベル）”です。
つまり、サービス名を覚えること自体に本質的な価値はありません。
重要なのは、
そのサービスが
どの役割を担当している部品なのか
です。
EC2 / S3 は地図のどこにいるのか
ここで、これから読む個別サービスの位置づけだけ整理します。
- EC2
→ 「計算する」役割の中の一つ
（処理を動かす部品） - S3
→ 「保存する」役割の中の一つ
（データを置く部品）
これ以上、今は知る必要はありません。
ここで全部を覚えなくていい理由
この段階で、
- すべてのサービスを覚える
- 料金や設定まで理解する
必要はありません。
AWSは、
- 必要になった役割から
- 必要なサービスだけ
- 深掘りする
前提で作られています。
IT営業としての立ち位置に戻ると
IT営業に求められるのは、構造を整理できる人です。
- 「今はどの役割の話か」
- 「このサービスはどこに位置するか」
これを言語化できるだけで、AWSの会話は一気に楽になります。
さいごに
この記事は個別サービスに入る前の地図の記事です。
次の記事からは、「EC2」「S3」といったサービスを、この 地図の中の一部 として1本ずつ整理していきます。
地図を持った状態で読むEC2 / S3は、もう別物です。
コメント