「オンプレのインフラは分かる。でもAWSになった途端、何から手をつければいいのか分からない」——転職を機にオンプレからAWSのインフラに移った私自身が、まさにそう感じた一人でした。
この記事では、実務でAWSをキャッチアップする中で実際に詰まった4つの壁を「詰まった順」に並べ、どう向き合ったかを正直に書きます。オンプレ経験はあるけれどクラウドはこれから、という方の地図になれば。
壁① ネットワーク：オンプレ感覚が一番裏切られる場所
最初の、そして今も一番手強い壁がネットワークでした。私が具体的につまずいたのは、EKSの構成です。Podをプライベートサブネットに置き、NLB／ALBを挟んで、さらに
CloudFront経由でアクセスさせる——この経路で、トラフィックがどこからどこへ流れているのかが、最初はまったく掴めませんでした。
「CloudFront → ロードバランサー → プライベートサブネットのPod」という流れを自分で図に描けるようになるまで、何度も手が止まりました。正直に言うと、今でも完全に腹落ちした自信はありません。でも逆に言えば——ここ
を自分の言葉で説明できるようになれば、AWSネットワークの大半は怖くなくなります。VPCは読むだけでは掴めないので、手を動かして試すのが結局の近道でした。
壁② IAM・権限設計：オンプレに無い概念で手が止まる
次に手が止まったのが権限まわりです。オンプレには無かった考え方が次々に出てきます。アカウントをまたいで制御するSCP（サービスコントロールポリシー）、IAMロール、IAMポリシー、さらにサービスごとに存在する個別のポリシー——「どの権限が、どのレイヤーで効いているのか」が、最初はまるで整理できませんでした。
ここはサービスごとに場当たりで覚えると必ず混乱します。一度、全体像を体系的に頭に入れるのが、遠回りに見えて最短でした。
壁③ 課金・コスト管理：止め忘れ＝請求の恐怖
オンプレの「買い切り」感覚で一番痛い目を見たのがコストです。実際に私が請求でヒヤッとしたのは2回あります。
- EKSの延長サポート料金：クラスターを止めていない（使い続けている）状態で、Kubernetesのバージョンが標準サポート期限を過ぎてしまい、自動的に延長サポート（Extended
Support）の料金が上乗せされ、想定外の請求が来ました。 - CloudWatch Logsの蓄積：ログを溜め続けていたら、保存料が積み上がって請求額が跳ね上がっていました。
どちらも「動いていれば課金され続ける」というクラウドの大原則を、痛みで覚えた瞬間でした。教訓は明確です——バージョンのサポート期限管理・ログの保持期間設定・予算アラート（Budgets）は、最初に
仕込んでおくべきです。
壁④ マネージド／サーバレスの発想転換：「サーバーを建てる」思考からの脱却
最後は技術というより「頭の切り替え」でした。象徴的だったのは、管理画面から数クリックでEC2のサーバーが立ち上がった瞬間。「あっ、これがクラウドか」と。オンプレなら機材の調達から始まる作業が、数十秒
で終わる。
この体験以降、「サーバーを建てる」前提で考えるのをやめ、「使えるマネージドサービスは何か」から発想するようになりました。この転換ができると、設計のスピードと選択肢が一気に変わります。
まとめ：詰まった順＝学ぶべき順のロードマップ
オンプレ出身者の最短ルートは、結局「詰まった順」に学ぶことだと思います。
- ネットワーク（VPC）で全体の地図を掴む
- IAM／権限で「誰が何をできるか」を整理する
- コスト（課金・サポート期限・ログ保持）で事故を防ぐ
- マネージド前提の発想に切り替える
そして私自身は、こうして実務でぶつかった「穴」を、AWS資格の勉強で体系的に埋めました。実際に使った教材や勉強法はAWS SAA合格体験記にまとめています。
そして、そもそも私がオンプレからクラウドインフラへ転職した経緯は、オンプレからクラウドへ転職した実体験に書いています。
とくにネットワークとコストは、新規構築の現場でつまずきやすいポイントです。EKSを新規構築したときに実際に詰まった具体例は、オンプレ出身がEKSを新規構築して詰まった落とし穴｜ネットワーク疎通とコスト見積もりで深掘りしています。