皆さんこんばんわ！
ここ一週間メンタル不調の鬱で寝込んでいたポンコツエンジニアのGONです。
更新を待ってくれていた方（いないか..）
いきなりですが、食料品の消費減税のニュース見ましたか？
きたる来年2027年4月。
なんと2年間限定で引き下げられるという謎の食料品の消費減税。
どうやら、
大日本帝国の高市様が税率を2029年4月に1%から8%に戻すタイミングで、
中低所得者への現金給付を検討いるらしいです。
**低所得者のワイ「ヨシッ、高市ナイスぅう、現金バッチコーイ！」**とぐびぐび祝杯を挙げて飲んでいたら、ふと
..ん？なんかおかしくね？
えっと..食料品の消費税を一旦1％まで下げておきながら、
2年後には一気に8％へ戻し..？
その負担増を現金給付で和らげる..？
それって..
・・・いや、もうなんでもいいや、酒飲もう・・
とにかく、みなさん今年も残りわずか３か月半ほど。
くじけずに頑張っていきましょう！
さて、前回までは私のうだつのあがらない人生を賭けた求人サービスを支える
『PHP』『PostgreSQL』『AWS』の選定理由や、
データベースのセキュリティ実践レクチャー、
ネットワーク設計のポイントなどなど書かせていただきましたね。
好評だったので今回もなんだか
めっちゃ調子に乗って
『初心者が最初に押さえておくべきAWS運用の基礎と落とし穴回避術』
について、偉そうにならないように語らせていただきます！
まずね、私がAWSを学び始めたばかりの頃は
AWSって便利なんだろうけどさ
まぁサービス項目が多すぎて何から手をつければいいかわからず、
「なんかこれドン・キホーテいるみたいだな..」
と置き去りにされた感じになったもので、
糞上司から「おい、早く設定終わらせろや！」のオーダーがあるたびに、
よくわからない動機や息切れが起きてしまい、
「おい！ジェフ・ベゾスさんよぉ！W不倫とかしてねーで、ワイみたいなADHDのポンコツエンジニアでもわかりやすいマニュアルとか整備してくださいよぉ。あんたかつてのハングリーさはどこいったんだよぉ！？」
と他責思考になり、情緒不安定な状態でした。
そこで今回は、私と同じ悩める初心者エンジニアの方に向けて、
現場で実際にWebサービスを安定稼働させるために必須となるAWS基礎のキホンについて、
さぞ、お忙しいジェフ・ベゾス様の代わりに、私めが図解を交えながら初心者向けに分かりやすく解説します！
1. 「VPC」と「サブネット」の役割を住み分けよう
AWSでインフラを作るとき、すべての土台となるのが VPC（Virtual Private Cloud） です。
AWS上に自分専用の仮想ネットワーク領域を確保するイメージです。
ジェフ・ベゾス様も結婚生活25年間の土台に自分専用の仮想ネットワーク領域を確保していましたよね。
そして、そのVPCを用途ごとに区切るのが サブネット（Subnet） です。
初心者がまず絶対に押さえておくべきなのは、「Public」 と 「Private」 の分離です。
[ インターネット ]
│
▼ (Internet Gateway経由)
┌──────────────────────────────────────────────┐
│ VPC │
│ │
│ [ Public Subnet ] (外から見える領域) │
│ ├── ALB (ロードバランサー) │
│ └── NAT Gateway │
│ │
│ [ Private Subnet ] (外から隔離された領域) │
│ ├── Web/App Server (EC2 / ECS) │
│ └── Database (RDS) │
│ │
└──────────────────────────────────────────────┘
なぜ分けるのか？
-
Public Subnet: 外からの通信を受け付けるロードバランサー（ALB）などを配置。
-
Private Subnet: アプリ本体やデータベース（RDS）を配置し、インターネットから直接IPアドレスを叩けないようにする。
「Webサーバだから直接グローバルIPをつけてPublicに置く」
という構成も動くには動きます。
が、セキュリティの観点からは
「外と直接話すのはALB（※）だけ、アプリやDBはPrivateへ」
が良いでしょう。
このあたりを理解していないと、我らがジェフ・ベゾス様のように親密なテキストメッセージやプライベート写真を傍受された挙句、４兆円とられる離婚トラブルに発展するリスクもあります。（0.001％でも金をオイラに分けてくれよベゾスさん..）
※ALB：Application Load Balancerの略です。AWSが提供する、OSI参照モデルのレイヤー7（アプリケーション層）で動作する負荷分散（ロードバランシング）サービスです。
2. Security Group（セキュリティグループ）の最小権限ルール
セキュリティグループは、いわば「EC2やRDSの門番」です。
仮想ファイアウォールとして、どのポートへのインバウンド（受信）通信を許可するかを設定します。
初心者がやりがちな一番危険な設定がこちらです。
【NG設定】
Type: SSH (22)
Port: 22
Source: 0.0.0.0/0 (全世界からアクセス可能)
これをしてしまうと、世界中のbotから24時間365日ブルートフォース攻撃（総当たり攻撃）を受け続けることになります。
我らがジェフ・ベゾス様もわきが甘く、タブロイド紙から総当たり攻撃を食らっていました。
正しい設計パターン
Webトラフィック（HTTP/HTTPS）と内部通信、管理用通信をしっかり分けます。
① ALB用 Security Group
Inbound: HTTPS (443) Source: 0.0.0.0/0
② アプリサーバ用 Security Group
Inbound: HTTP (80/8080) Source: ALBのSecurity Group ID
③ RDS用 Security Group
Inbound: PostgreSQL (5432) Source: アプリサーバのSecurity Group ID
④ SSH/管理用
Inbound: SSH (22) Source: 自社/自宅の固定IP or Session Manager利用
このように「IPアドレス」ではなく「別のセキュリティグループID」を送信元（Source）に指定することで、IPが変わっても柔軟かつ安全に通信を制御できます。
3. S3の「パブリックアクセスのブロック」は命綱
静的ファイル（画像・PDF・ログなど）の保存先として超優秀な Amazon S3。
しかし、過去に数々の企業で「機密データが誰でも見られる状態になっていた」というインシデントが起きています。
私もこのS3の設定ミスしそうになったことがありましたが、その時はなんとか他責思考で乗り切りました。
なぁジェフ・ベゾスさんよぉ。ワイみたいなポンコツエンジニアがS3でこういう上司にぶっ殺されるようなセキュリティ設定ミスったら自動で制御してくれる仕組みとか作ってくださいよぉ..ワイは悪くないんだよぉ
ということで、S3を利用する際は、以下の原則を徹底しましょう。
┌──────────────────────────────────────────┐
│ S3 バケット │
│ ├── [Block Public Access] → ON (基本) │
│ │ │
│ └── アクセス経路 │
│ ├── アプリから: IAM Role で読み書き │
│ └── ユーザーへ公開: CloudFront 経由 │
└────────────────────────────────────────────┘
ポイント
-
「パブリックアクセスをすべてブロック」を有効化する
バケット作成時のデフォルト設定ですが、安易に外さないようにしましょう。外す時は少なくともポンコツエンジニアではない人にダブルチェックしてもらいましょう。 -
画像をWeb公開したい場合でもS3は非公開に保つ
CloudFront（CDN）を前段に置き、OAC（Origin Access Control） を使って「CloudFrontからしかS3を読めない」構成にするのが安全です。
4. IAMの運用ルール：ルートアカウントは封印せよ
AWSアカウントを作ったときの最初のメールアドレスとパスワードでログインするアカウントを ルートユーザー と呼びます。
このルートユーザーは、AWS上のすべての権限（課金、削除、設定変更など）を持つ「全知全能の神アカウント」です。
[ ルートユーザー ]
│
├── MFA（多要素認証）を設定して鍵をかける
└── 普段の業務では一切使わない！(封印)
│
▼ 普段の作業用
[ IAM Identity Center / 個別IAMユーザー ]
│
└── 必要最小限の権限（Least Privilege）を付与
初心者が最初にやるべきIAM設定チェックリスト
これはジェフ・ベゾスに代わって私が作りましたので必ずチェックしましょう。
-
ルートユーザーにハードウェアトークンや認証アプリ（Authenticator）で MFA を設定したか？
-
ルートユーザーのアクセスキー（Access Key ID / Secret Key）を作成していないか？（もしあれば即座に削除）
-
開発者ごとに個別のIAMアカウントを作成しているか？
-
プログラムからAWSを叩く場合、アクセスキー直書きではなく IAM Role を使っているか？
5. 請求アラートとCloudWatchで「クラウド破産」を防ぐ
AWS初心者が最も恐れるのが「月末の請求書を見て青ざめる」パターンです。
放置されたEC2の巨大インスタンス、消し忘れたNAT Gateway、意図しないループ処理による転送量爆発……。
これらを未然に防ぐために、環境を作ったら真っ先に請求アラートを設定しましょう。
[ AWS利用料 ] ──(閾値超過: 例 $10)──▶ [ CloudWatch Alarm ]
│
▼
[ Amazon SNS ]
│
▼
[ メール / Slack通知 ]
設定手順の目安
- AWS Budgets（またはCloudWatch Billing Alarms） を有効化。
- 「想定月額の50%」「80%」「100%」など、段階的にアラート閾値を設定。
- 開発初期は「$5」「$10」といったごく少額の段階で通知が飛ぶようにしておくと、消し忘れにすぐに気付けます。
まとめ：基礎の積み重ねが強いサービスをつくる
クラウドはボタンひとつでサーバーが立ち上がる便利なもの。
ですが、その裏側にある「ネットワークの境界線」「権限の分離」「コストと監視」を理解しているかどうかが、サービスの堅牢性を大きく左右します。
・通信は必要な経路だけを通す（VPC / Subnet / Security Group）
・データは安易に世界へ公開しない（S3 Block Public Access）
・権限は最小限に絞る（IAM Role活用、ルート封印）
・見えないところで動かさず、常に監視する（CloudWatch / Budgets）
これらは派手な技術ではありません。
でも、今後AIや最新フレームワークが出てきても省略できない泥臭い「土台」ではないかと思います。
そんなAWS創始者のジェフ・ベゾスと並ぶほどの髪の薄さを誇る私めが
AWSの堅牢なインフラとセキュリティをベースに、試行錯誤して作り上げた
安心・安全に運営している求人マッチングサービスは以下になります。
▼求人マッチングサービス【ヴェテラン】
https://veteran-work.com/
エンジニアのみなさま、
企業の採用ご担当者のみなさま、
ぜひ、使ってみてくださいっ！！！
「個人開発のときのおすすめ構成ってある？」
「ここのサブネット設計はどう組んでるの？」
「ジェフ・ベゾスになんか恨みでもあるの？」
など、ご質問やご意見・ツッコミなどいただけますとモチベーションが爆上がりします！
本日もお疲れ様でした。
明日も一日を丁寧に生きていきましょう。
