AWSが向こうから来た

オンプレ至上主義だった自分が、AWSを触ることになった話（＋具体例つき考察）

これまでの自分は、いわゆる「オンプレ最高派」だった。
サーバーは自分で用意して、必要ならDockerで環境を切る。それで十分、むしろそれが一番安心――そんな感覚でやってきた。

ところがある日、状況が変わる。

「チャットシステムにBOT機能追加していいよ。AWSで動くから、AWSで動くように作ってね」

……急にきたな、AWS。

しかも渡されたのはNode.jsのサンプルコード。
いやいや、こっちはNode.jsをインストールできないPCなんですが。

とはいえ、JavaScriptは多少わかる。
「読めるなら、書き換えればいいか」ということで、サンプルをベースにPythonへ移植。
リスペクトしつつ、いい感じに“インスパイア”して仕上げてみた。

そのままマージリクエストを投げる。

——が、1日経っても反応なし。

「これは…ダメ出しに困ってるパターンか？」
微妙な空気を感じつつ、その日はAWSのオンラインセミナーへ。

---

AWSセミナーで得た“とりあえず会話できる知識”

正直なところ、AWSはほぼ未経験。
ただ、セミナーに出てみて「これだけ知ってれば会話に入れるな」という最低限の理解は得られた。

よく出てくるやつはこのあたり：

• IAM（アイアム）
• API Gateway（エーピーアイ・ゲートウェイ）
• Lambda（ラムダ）
• S3（エススリー）
• DynamoDB（ダイナモ）
• EC2（イーシーツー）

それぞれのイメージはこんな感じ。

• IAM：権限管理。ミスると普通に事故るやつ
• API Gateway：リクエストを受けて裏の処理に流す受付係
• Lambda：必要なときだけ動く処理本体（動いた分だけ課金）
• S3：安くて無限に置けそうなストレージ
• DynamoDB：RDBじゃないけど爆速なデータベース
• EC2：仮想サーバー（ただし“昔ながら枠”っぽい扱い）

ここで気づいたのがひとつ。

「AWS＝仮想サーバー」じゃなかった。

---

AWSの正体は「サービスの組み合わせ」

AWSの感覚は、むしろ日常で使っている仕組みに近い。

例えば、IFTTTで
「体重計 → アプリ → LINE通知」みたいに連携させるあの感じ。

AWSも同じで、

• API Gatewayで受けて
• Lambdaで処理して
• 必要ならDynamoDBに保存して
• S3にファイルを置く

みたいに、部品をつないでシステムを作る世界だった。

---

【考察①】オンプレとAWSの“発想の違い”

オンプレの発想はこう。

• サーバーを用意する
• OSを入れる
• ミドルウェアを入れる
• アプリを動かす

つまり「箱を用意してから中身を作る」。

一方AWSはこう。

• 必要な機能を選ぶ
• つなぐ
• すぐ動く

つまり「機能を組み合わせる」。

具体例：チャットBOTを作る場合

オンプレの場合

1. サーバー用意
2. Node.js or Python環境構築
3. Webサーバー（nginxなど）設定
4. API受け口作成
5. 常時起動＆監視

→ 小さな機能でも“準備コストが重い”

AWSの場合

1. API Gatewayで受ける
2. Lambdaで処理を書く
3. 必要ならDynamoDBに保存

→ “BOTのロジックだけ”に集中できる

この差はかなり大きい。

---

【考察②】「使わない時間＝コスト0」というインパクト

Lambdaの特徴は「動いたときだけ課金」。

これ、実はかなり強い。

具体例：社内ツール

例えば、1日10回しか使われない社内BOT。

オンプレ or EC2

• 24時間サーバー起動 → 常に課金 or 電気代発生

Lambda

• 呼ばれたときだけ動く → ほぼ無料レベル

→ 「使うか分からない機能」でも気軽に作れる

これは心理的にも大きくて、
“とりあえず作ってみる”ハードルが一気に下がる。

---

【考察③】インフラエンジニアの仕事が変わる感覚

オンプレだと、

• サーバー構築
• ネットワーク設計
• 障害対応

がメインだった。

でもAWSだと、

• サービス選定
• 権限設計（IAM）
• サービス間連携

になる。

具体例：ミスの種類が変わる

• オンプレ：ディスク足りない、ポート開いてない
• AWS：IAMミスってアクセスできない

特にIAMは「動く・動かない」が一瞬で決まるので怖い。

---

【考察④】“小さく作る文化”との相性がいい

AWSは、機能を細かく分ける前提。

これが何に効くかというと、

「小さく試す」文化と相性がいい。

具体例：機能追加

今回のBOT機能もそうだけど、

• まずLambda1個で試す
• 動いたらAPI Gatewayとつなぐ
• 必要ならDB追加

→ 段階的に育てられる

オンプレだと、最初に“全部設計”しがちだけど、
AWSだと“後から足す”前提で動ける。

---

そして、まさかの展開

セミナーが終わり、なんとなくAWSの世界観を理解してワクワクしていたそのとき。

マージリクエストが——承認されていた。

あっさり通った。

ただし、ここで新たな壁。

「エンドポイントどこ？」

ドキュメント（という名の“ブログと取説の中間みたいな何か”）を読み漁り、ようやくURLを特定。

「これで動くはず」

そんな確信とともに、週末へ突入。

---

まとめ：AWSは“インフラ”ではなく“選択肢”

今回の一件で感じたのは、

AWSは「インフラ」じゃなくて、
**“やりたいことを実現するための選択肢の集合”**ということ。

• サーバーを立てる → EC2
• 処理だけ動かす → Lambda
• データ置く → S3 / DynamoDB

必要なものだけ選べばいい。

オンプレ最高派だった自分にとっては、
正直ちょっと悔しいけど、

「これは確かに便利だわ」

と思ってしまった。

そして何より、

「作れるかどうか」ではなく
「どう組み合わせるか」

を考える世界に入った感覚がある。

AWSという新しい“魔法”を覚えた。