オンプレ運用からクラウドへ移るときにつまずいたこと

私はオンプレミスのサーバ・ネットワーク運用を約5年担当したあと、2023年からAWS移行案件の担当に移りました。

この記事は、その移行のときに実際につまずいたことを書いたものです。理論的には知っていたのに実際に動くと詰まった話、オンプレの感覚を持ち込んでしまって修正が必要だった話を正直に書きます。

「オンプレとクラウドの違い」という話は、調べれば技術的な説明がたくさん出てきます。ただ「知っているのに詰まる」という経験は、技術説明だけでは伝わらない部分があります。私が詰まったポイントを具体的に書くことで、これから移行を考えている人の参考になればと思います。

つまずいた点1：責任共有モデルの「感覚」

知識として知っていたが腹落ちしていなかった

責任共有モデル（Shared Responsibility Model）は、AWS認定の試験でも重要な概念として出てきます。「インフラの物理層はAWSが責任を持ち、その上のOSやアプリは利用者の責任」という概念は、SAAの勉強で学んでいました。

しかし移行担当になって実際に仕事をし始めると、この「分担」が腹落ちしていなかったことに気づきました。

どこで詰まったか

最初に詰まったのは、EC2インスタンスのゲストOS管理です。オンプレで物理サーバを担当していたとき、サーバの状態を把握するのは私たちの役目でした。「このサーバのディスク使用量が増えているから対応する」という判断を、監視の数値を見て自分たちで行います。

クラウドに移行したとき、「EC2は仮想マシンで、ゲストOSの管理は私たちの責任だ」と理解していました。しかし実際には、「ハイパーバイザの障害に起因する問題なのか、ゲストOS上の問題なのか」の切り分けが最初は難しかったです。

たとえばインスタンスのレイテンシが上がったとき、「これはEC2インスタンス（AWS管理の物理基盤側）の問題か、ゲストOS（私たちの責任範囲）の問題か」という判断の根拠をどこに求めるかが最初はあやふやでした。AWSのサポートに問い合わせると「お客様側のOSの問題です」と返ってきたこともあります。

どう乗り越えたか

責任共有モデルを「どこからどこまでは自分たちで調べる、どこからはAWSに確認する」という具体的な手順に落とし込む作業をしました。具体的には、よくある問題パターンに対して「最初に確認する場所」を事前にリストアップしました。

CloudWatchのメトリクスで確認できること・AWS Healthダッシュボードで確認できること・AWSサポートに問い合わせるべき範囲、という棲み分けを整理したことで、障害対応の初動が速くなりました。

つまずいた点2：従量課金でコストが可変になること

「使った分だけかかる」の感覚のなさ

オンプレでは、サーバの費用は固定費です。機器を購入するか借りるかの費用が決まっていて、「使いすぎたから費用が増えた」という事態は起きにくい。コスト管理は「予算の枠内で収める」という管理です。

AWSに移行すると、コストは従量課金になります。リソースを多く作れば、その分コストが積み上がります。これは「分かっている」ことでしたが、実際のコスト管理は最初かなり難しかったです。

どこで詰まったか

最初に困ったのは、テスト環境のコストです。移行担当になって最初のプロジェクトでは、テストのためにEC2インスタンスをいくつか作りました。テストが終わって次のフェーズに進んだとき、止めたつもりのインスタンスが実は停止状態になっていなかったものがあり、思ったよりコストが積み上がっていました。

「停止（Stop）」と「終了（Terminate）」の違いを理解していても、うっかり停止状態にしてしまうことは起きます。停止状態のEC2はインスタンス料金はかかりませんが、EBSボリュームの費用はかかります。この細かい費用の構造が、オンプレの「机上でコストを把握する」感覚では見えにくかったです。

また、同期でAWS担当になったメンバーがNATゲートウェイのデータ転送コストを意識せずに設計して、予想より高いコストが出たという話もありました。NATゲートウェイはデータ転送量に応じて料金がかかります。オンプレの感覚だと「ルーターを設置した費用」で止まりますが、クラウドでは「通過させたデータ量に応じた費用」が加算されます。

どう乗り越えたか

まずAWS Cost Explorerで毎週コストを確認する習慣を作りました。コストの傾向を継続的に見ることで、意図しない増加に気づけるようになりました。

次に、Budget Alertsを設定して「月のコストがこの金額を超えたらアラートを受け取る」という仕組みを作りました。これにより「コストが想定を超えている」ことを能動的に確認する前に気づけるようになりました。

資料として使うタグ設計も重要だと感じました。リソースにタグを付けてプロジェクト・環境（dev/stg/prod）を識別できるようにすることで、「このコストはどの環境のものか」という追跡がしやすくなりました。

つまずいた点3：権限を「借りる」という考え方

オンプレの「権限を持つ」とは違う

オンプレの環境では、管理者権限というのは「持つもの」です。rootやadministratorの権限を持っているユーザーが、必要なことを実行できる状態を作ります。権限の範囲を細かく分けることはやっていましたが、「必要な操作をするために必要な権限だけを一時的に取得する」という動き方は一般的ではありませんでした。

AWSのIAMは、「最小権限の原則（Principle of Least Privilege）」を基本とした設計思想を持っています。必要な操作に対して必要な権限だけを付与し、不要な権限は持たないという考え方です。

どこで詰まったか

最初に詰まったのは、IAMロールの使い方です。「EC2インスタンスからS3にアクセスしたい」というケースで、最初は「IAMユーザーを作ってアクセスキーをインスタンスに渡す」という方法を試みました。オンプレの「認証情報を設定して使う」という感覚から来た発想です。

しかしこれはセキュリティ上の問題がある方法で、より適切なのはEC2インスタンスにIAMロールをアタッチする方法です。インスタンスメタデータから一時的な認証情報を取得するという仕組みです。「ロールはインスタンスが持つもの」というより「インスタンスがロールを引き受けてその権限を一時的に使う」という考え方が、最初はピンと来なかったです。

また、あるタスクのためにIAMポリシーを作るとき、「とりあえずこの辺の権限を全部付けておけば動くだろう」という動き方をしてしまったことがありました。レビューで「この権限は本当に必要ですか」と指摘を受けて、必要な権限を絞り込む作業をした経験があります。

どう乗り越えたか

IAM PolicyのシミュレーターとIAM Access Analyzerを使う習慣をつけました。「この権限が必要かどうか」を確認するツールを使うことで、不要な権限を付けないための確認ができるようになりました。

また、SCP（Service Control Policy）やPermission Boundaryの概念も学びました。IAMの設計は組織レベルで考えることがあり、最小権限の実現は個々のポリシー設計だけでなく、組織レベルのガードレール設計が組み合わさります。

つまずいた点4：リソースが「宣言的に」作られること

「手順書で操作する」から「状態を宣言する」へ

オンプレの構成管理は「手順書で操作する」形が多いです。「サーバAにsshして、このコマンドを実行して、この設定ファイルを変更する」という手順です。Ansibleなどで自動化することもありますが、基本的な思想は「操作の手順を記述する」という命令型です。

AWS環境のIaC（Infrastructure as Code）、特にTerraformやCloudFormationは「状態を宣言する」という宣言型の思想を持っています。「このVPCを、このサブネット構成で、このルートテーブルを持つ状態にする」と宣言すると、ツールがその状態になるように操作してくれます。

どこで詰まったか

最初に戸惑ったのは、Terraformで「変更の差分」を確認する作業です。terraform planを実行すると「この変更を加えると、現在の状態からこう変わります」というレポートが出ます。これを読んで「意図した変更か」を確認することが、オペレーションの重要なステップです。

最初のうちは、このplanの内容を正確に読めていませんでした。「destroyとcreateが出ているけど、これは既存リソースが一回削除されて再作成される意味か？」という読み取りが正確にできず、いくつかの変更で意図しない影響を出してしまったことがありました。

既存のコードを引き継いだとき、変数名やモジュール構造が分かりにくくて、「このコードを変更するとどこに影響するか」の把握が難しかったという経験もあります。

どう乗り越えたか

Terraformのterraform planの出力を丁寧に読む習慣をつけました。特に ~ update in-place、-/+ destroy and then create、+ create の違いを理解して、変更前に意図した操作かを確認するようにしました。

既存コードを読むときは、全体を一度に把握しようとするのではなく、「このリソースはどこで定義されているか」「この変数の値はどこから来ているか」をたどって局所的に理解していく方法が有効でした。

チームの中でTerraformの使い方を統一するルールを整備したことも効きました。モジュールの分け方・変数の命名規則・stateファイルの管理方法を揃えることで、コードの読みやすさが改善されました。

つまずいた点5：障害対応の切り分け先が変わること

物理から論理へ、切り分けの出発点が変わる

オンプレの障害対応では、「物理層から確認する」という手順が一般的でした。ケーブルは抜けていないか、NICのリンクは上がっているか、電源は入っているか、ということから始まります。物理的な状態を確認してから論理的な設定に移るという流れです。

クラウドでは物理層に直接触れません。「この仮想マシンのNICは正常か」という確認はCloudWatchのネットワークメトリクスや、インスタンスのシステムログを確認するという形になります。

どこで詰まったか

最初に詰まったのは、EC2インスタンスへのSSH接続ができないという問題の切り分けです。オンプレでSSHできないとき、確認する順番は「物理ネットワーク→IPの到達性→sshd設定」でした。クラウドでこれに対応する切り分けは「セキュリティグループの設定→NACLの設定→ルートテーブル→EC2インスタンスの状態→sshd設定」という順番になります。

切り分けの対象が変わるだけでなく、「AWSの設定」と「OS側の設定」という2層の確認が必要で、最初は「どの設定を変えれば解決できるか」の見当をつけるのに時間がかかりました。

また、RDSへの接続ができないという問題で、「RDSのエンドポイントは正しいか」「セキュリティグループはEC2からの接続を許可しているか」「VPCのサブネット設定が正しいか」という複数の設定を順番に確認していく場面もありました。オンプレなら「物理的に同じネットワークにいるか」で確認できていたものが、クラウドでは複数の論理的なレイヤーを確認する必要があります。

どう乗り越えたか

よくある問題パターンに対する切り分けチェックリストを作りました。「EC2にSSHできない場合の確認順序」「RDSに接続できない場合の確認順序」といった形で、初動の手順を言語化しました。

最初はこのチェックリストをそのままなぞる形で切り分けをして、徐々にパターンを覚えていきました。チェックリストがあることで、焦った状態でも見落としが減りました。

AWS Trusted AdvisorやAWS Configを使ったチェックの仕組みも学びました。設定の不整合を事前に検出する仕組みを持つことで、障害が起きる前に問題を把握できる場面が増えました。

オンプレ経験が活きたこと

つまずいた点を書いてきましたが、オンプレ経験が活きた部分も多くありました。

ネットワークの基礎

VPCの設計をするとき、サブネットの分け方・ルートテーブルの設計・NATゲートウェイの使い方を理解するうえで、オンプレでのVLAN設計やルーティングの知識が直接活きました。

「プライベートサブネットに置いたEC2がインターネットに出るためにNATゲートウェイが必要」という構成は、オンプレでの「プライベートアドレスのサーバがインターネットに出るためにNATルーターを経由する」という構成と対応しています。概念の対応関係が分かると、新しい知識の習得が速くなります。

サーバの動作原理の理解

EC2インスタンスで問題が起きたとき、プロセスの状態・メモリの使用状況・ディスクのIOといった指標を確認する場面があります。このときに物理サーバの運用で培ったサーバの動作原理の知識が使えます。

「このプロセスがCPUを食っているのはなぜか」「メモリが枯渇している原因は何か」という調査のアプローチは、物理でも仮想でも基本は同じです。

障害対応の経験

何か問題が起きたとき、焦らずに切り分けを進めるという姿勢はオンプレの障害対応で訓練されたものです。「まずログを見る」「次にネットワークの到達性を確認する」という手順化された動きは、クラウドでも有効です。

AWSでは確認する場所が変わりますが、「まず確認できる情報を集めて、それを元に仮説を立てて、仮説を検証する」という基本的なアプローチは同じです。

移行を振り返って

AWS移行担当になってから2年以上が経ちました。今振り返ると、最初の3〜6ヶ月は「クラウドの考え方に慣れる」期間でした。

技術的なつまずきは、調べれば解決できることが多かったです。問題になったのは「なぜそういう設計思想になっているか」の理解でした。責任共有モデルも、最小権限の考え方も、宣言的なIaCも、「そうする理由」が分かると腹落ちするのが速くなりました。

クラウドへの移行を考えているインフラエンジニアへのアドバイスとして書くなら、「オンプレとの違いを恐れすぎず、基礎の対応関係を探しながら学ぶ」ということです。違う部分はありますが、全部が別物というわけではありません。

クラウドエンジニアへの転職で準備したことはクラウドエンジニアへの転職で準備したことに詳しく書きました。また、AWS資格の取得が実際にどう役立ったかについては「AWS資格は意味ない」と言われる理由を分解するに整理しています。

年収への影響を考えている方はAWS資格で年収は上がるのかもあわせてご覧ください。

クラウドへの移行でやっておくべきこと

実際に移行担当になってから「やっておけばよかった」と感じた準備を書きます。同じ状況の方の参考になれば思います。

AWSのドキュメントの読み方を先に習得する

AWSの公式ドキュメントは量が多く、最初は「どこに何が書いてあるか」が分からなくて困りました。Blackbeltの資料・Well-Architected FrameworkのPillar別ガイド・サービスのFAQページという3種類のドキュメントの位置づけを把握しておくと、調べ物の出発点として使いやすくなります。

Blackbeltは各サービスの概要と代表的な設計パターンがまとまっており、サービスを初めて使う前に読む資料として機能します。Well-Architected Frameworkは設計判断の根拠として引用できるため、「なぜその設計にしたか」を説明する際に使えます。FAQは具体的な仕様・制限・課金の仕組みについて確認する際に手早く調べられます。

Terraformの基本構文を先に押さえる

私がAWS移行担当になったときの環境ではTerraformでリソースを管理していました。Infrastructure as Codeの概念自体は理解していましたが、実際のコードを読んで構成を把握できるようになるまでには時間がかかりました。

Terraformの基本構文（resource・variable・output・module）とterraform planの出力の読み方を先に習得しておくと、既存のコードを読んで構成を理解する作業が速くなります。社内環境がCDKやCloudFormationであっても同様で、IaCのコードを「読める状態」にしておくことが移行担当として動く上での前提になります。

terraform planが「何が変わるか」を教えてくれるため、変更の意図と計画の結果を照合する習慣をつけることで、意図しない変更を防ぐことができます。最初のうちはレビュアーに確認してもらいながら操作することを勧めます。

コスト管理の仕組みを早めに理解する

先の節でも触れましたが、クラウドのコスト管理は独立した知識領域として早めに習得しておく価値があります。Cost ExplorerとBudgetsの基本的な使い方・タグ設計によるコスト配分・リザーブドインスタンスとオンデマンドの使い分けは、移行後すぐに役立つ知識です。

私がコスト面で最初につまずいたのはNATゲートウェイのデータ処理料金でした。プライベートサブネット間の通信が不必要にNATゲートウェイを経由している設計になっており、想定より多くのコストが発生している状況でした。設計を見直してサブネット間の通信経路を適切に整理するだけで、毎月のコストが下がりました。

Cost Explorerで過去のコスト推移を定期的に確認し、どのサービスにいくらかかっているかを把握する習慣をつけることで、予期しないコスト増加に早く気づけます。Budget Alertsを設定して閾値を超えたらメールで通知を受ける仕組みにしておくことも基本です。

AWS認定と移行実務の関係

移行担当としての実務とAWS認定の学習には、重複する部分が多くあります。

SAAで学ぶVPC・EC2・RDS・IAMの設計概念は、移行案件で最初に触れるサービス群と一致しています。移行案件に入る前にSAAを取得しておくと、「この構成はSAAで学んだ設計パターンだ」という接続ができます。私はSAAを取得してから移行案件に本格参加した順番でしたが、試験で得た体系的な知識が実務の文脈理解を早めたという実感があります。

SAPについては移行案件での経験が試験に直接役立ちました。マルチアカウント構成やDisaster Recoveryの設計パターン、オンプレとクラウドのハイブリッド構成は、実務で似たような課題に取り組んだ経験があるため、問題の意図が把握しやすくなりました。SAPはAssociateより難易度が高いですが、移行担当として2年以上実務を積んだ後に取ると、試験の問いが「実際に判断したことのある設計の問題」として見えてきます。

AWS認定がオンプレからクラウドへの移行でどう役立つかという観点は「AWS資格は意味ない」と言われる理由を分解するにも整理しています。資格を「知識の体系を確認する手段」として捉えると、移行期間中の学習の補助線として機能します。AWS認定の種類と取得順序についてはAWS認定はどれから取るかも参考にしてください。

まとめ

• 責任共有モデルは「知っている」と「腹落ちしている」に差がある。具体的な切り分け手順として落とし込むことで実用になった
• 従量課金のコスト管理はオンプレの固定費感覚と根本的に違う。Budget AlertsとCost Explorerで継続的に監視する習慣が重要
• IAMの権限は「借りる」という考え方で、最小権限を意識した設計が基本。最初は不要な権限を広めに付けてしまいがちだった
• IaCの宣言的な構成管理は「手順書で操作する」という命令型の感覚とは違う。terraform planを丁寧に読む習慣をつけることが安全な操作の基本
• 障害対応の切り分け先がAWSの管理範囲と自分の責任範囲で分かれる。よくある問題パターンのチェックリストを作ることで初動が速くなった
• オンプレの経験は基礎として活きる部分が多い。ネットワーク・サーバ・障害対応の知識はクラウドでも使える