インフラエンジニアがクラウドへ転職するには、オンプレ経験を捨てるのではなく、ネットワーク、OS、認証、監視、バックアップの知識をクラウドの責任境界へ置き換えます。転職先は「クラウド案件」という名称ではなく、運用、構築、移行、設計のどこを担当できるかで選びます。未経験分野は資格だけで埋めず、構成図・検証手順・正常時と異常時の結果で補います。
このページはクラウドエンジニア転職完全ガイドの各論です。転職の進め方を最初から確認する場合はそちらへ。
オンプレ経験はクラウド転職で生かせる？
生かせます。IP設計、ルーティング、OS、ログ、冗長化、バックアップ、変更管理はクラウドでも必要です。ただし、機器やサーバーを直接管理する範囲が減り、API、IAM、マネージドサービス、従量課金の考え方が加わります。
| オンプレの経験 | クラウドで対応する考え方 | 追加で学ぶ点 |
|---|---|---|
| VLAN・ルーター・FW | VPC/VNet、Subnet、Route、仮想FW | クラウド側の経路、NAT、接続サービス |
| AD・アカウント管理 | クラウドIAM、フェデレーション、ロール | 一時認証、最小権限、サービス間権限 |
| 物理・仮想サーバー | 仮想マシン、コンテナ、サーバーレス | イメージ、自動置換、マネージド化 |
| 監視サーバー・ログ | クラウド監視、集中ログ、監査ログ | API操作とリソース変更の追跡 |
| バックアップ装置 | スナップショット、オブジェクト保管、管理サービス | 保持、リージョン、復元試験、費用 |
この記事は、オンプレ環境の経験しかない人がクラウドエンジニアへ移るケースを想定しています。サーバーやネットワークを物理・仮想環境で触ってきた経験は、そのままクラウドで使えます。変わるのは責任の境界で、物理ハードウェアと仮想化基盤は事業者側が見るようになり、利用者側にIAM、ネットワーク設定、データ、復旧が残ります。
クラウド転職で不足しやすい知識は何？
オンプレ経験者が補うべきなのは、サービス名の暗記ではなく、責任共有、IAM、コードによる変更、費用管理です。AWS、Azure、Google Cloudで名称は違っても、設計時の問いは共通します。
責任共有とマネージドサービス
どこまでクラウド事業者が管理し、どこから利用者が設定・更新・保護するかをサービスごとに確認します。仮想マシンとマネージドデータベースでは、利用者が触れるOSやバックアップ機能が異なります。
IAMと自動化
人の管理者権限だけでなく、アプリや自動化が使う権限を分けます。GUIで一度作るだけでなく、Terraformや各社のテンプレート機能で差分をレビューし、同じ構成を再現できる考え方が必要です。
従量課金と廃止
導入費だけでなく、稼働時間、データ転送、ログ保管、バックアップ、サポートを継続費用として見ます。作成手順と同時に、停止・削除・保持データの確認手順も設計します。
クラウド転職ではどの職種を狙う？
現在の経験に近い入口を選ぶと、クラウド未経験でも既存スキルを説明しやすくなります。サーバー運用経験者ならクラウド運用・移行、ネットワーク経験者ならクラウド接続やネットワーク設計から接続できます。
| 求人タイプ | 主な工程 | 生かせる経験 | 追加で示すもの |
|---|---|---|---|
| クラウド運用 | 監視、変更、障害、バックアップ | 運用、ログ、手順、障害対応 | クラウド監視とIAMの検証 |
| クラウド構築 | 詳細設計、構築、試験 | サーバー・NW構築、試験 | IaC、構成図、変更差分 |
| クラウド移行 | 調査、方式、移行、切替 | 現行調査、移行、切り戻し | 依存関係と移行方式の比較 |
| クラウド設計 | 要件、方式、非機能設計 | 設計、顧客調整、非機能要件 | 可用性、セキュリティ、費用の設計 |
| プラットフォーム・SRE | 標準化、自動化、信頼性改善 | 運用改善、開発連携 | CI/CD、IaC、可観測性 |
クラウド移行はどの順番で進む？
移行はサーバーをコピーする作業ではありません。対象アプリケーションを選び、依存関係と要件を確認し、移行方式、試験、切り戻し、監視まで準備します。
- 現行調査：サーバー、通信、データ、利用時間を確認
- 依存関係整理：DNS、認証、外部接続、ジョブを可視化
- 移行方式選定：再配置、再プラットフォーム化、再設計などを比較
- 設計・構築：権限、ネットワーク、監視、バックアップを準備
- 試験・切替：性能、障害、データ、戻し条件を確認
- 監視・改善：安定化、費用、不要資産を見直す
AWSの公式移行ガイダンスでも、対象の選定・優先順位付け、移行ランブック、セキュリティ手順、展開・試験・監視が扱われています。詳細はAWS Prescriptive Guidanceのアプリケーション移行で確認できます。
クラウド未経験者は何から学ぶ？
最初に一社のクラウドを選び、通信、権限、監視の三つを小さな構成で確認します。複数クラウドを同時に触るより、設計から削除まで一巡させるほうが実務の流れを説明できます。
- ネットワーク、Linux、DNS、HTTPの基礎を確認する
- 無料枠や学習環境の課金条件とMFAを設定する
- 仮想ネットワークと仮想マシンを構築する
- 管理権限とアプリ用権限を分ける
- 監視・ログを設定し、正常時の値を保存する
- 異常を一つ作り、切り分けと復旧を記録する
- リソースを削除し、課金停止を確認する
クラウドのポートフォリオには何を載せる？
完成画面だけではなく、要件と判断を載せます。採用側が見たいのは、なぜその構成を選び、どの試験で確認し、失敗をどう直したかです。
- 架空要件と対象利用者
- 構成図、通信方向、IPまたは名前解決
- IAMの主体と許可する操作
- IaCまたは設定手順
- 正常系・異常系の試験表
- ログ・メトリクスと切り分け
- 概算費用と削除手順
作り方は、インフラ転職向けポートフォリオの構成図・手順書例を土台にできます。
求人票と面接で確認すること
「クラウド比率100％」「クラウドネイティブ」といった表現だけでは、担当工程を判断できません。既存環境の運用だけか、新規設計やIaCへ関われるかを質問します。
- 利用クラウド、主要サービス、オンプレとの接続方式
- 運用・構築・設計・移行の業務割合
- コンソール操作とIaCの割合、レビュー方法
- アプリチームとインフラチームの責任境界
- 障害対応、夜間待機、変更作業の頻度
- クラウド未経験者が担当した初回案件と、その後の工程
AWSに絞る場合は、AWS経験が評価される担当工程と求人も確認してください。
職務経歴書でオンプレ経験をどう変換する？
「クラウド未経験」とだけ書かず、共通する設計要素と新しく検証した範囲を分けます。オンプレの実績をクラウド実績へ言い換えるのではなく、転用できる判断を説明します。
伝わりにくい例
オンプレサーバーの運用経験を生かし、クラウドエンジニアとして成長したいです。
共通点と不足分が分かる改善例
【記載例】オンプレ環境でLinuxサーバーの変更、ログ確認、バックアップ・復元試験を担当しました。クラウドではAWSの個人検証で、IAMロール、VPC、EC2、CloudWatchを構成し、通信不可時にDNS、ルート、SG、OS待受の順で確認する手順を作成しています。業務でのAWS経験はないため、まずはクラウド運用・構築補助から担当範囲を広げたいと考えています。
これは説明用の架空例です。個人検証を業務経験と表現せず、実際の担当内容へ置き換えてください。
クラウド転職でよくある失敗は？
失敗は、技術選定より前に求人と自分の現在地を取り違えることで起きます。次の状態なら応募前に条件を確認し直します。
- 資格取得だけで設計求人へ応募し、実務との差を説明できない
- 「クラウド案件」の実態がアラート監視だけだった
- オンプレ経験を古いと決め付け、共通知識を整理していない
- マネージドサービスの責任範囲を確認していない
- 学習環境を放置し、想定外の課金が続いた
- サービス一覧を並べ、構成や通信を説明できない
現行の通信と運用を消さずに書き出す
オンプレからクラウドへ移る案件では、まず現行構成の通信と運用を消さずに書き出します。僕が確認するのは、サーバー台数より、DNS、認証、バッチ、外部接続、監視、バックアップの依存関係です。ここを飛ばしてサービスを置き換えると、移行後に「夜間ジョブだけ届かない」「監査ログが不足する」といった問題が残ります。クラウド経験として価値があるのは、作成画面を操作したことより、現行のどの制約をどのサービスで満たし、どの試験で確認したかです。ネットワークとサーバーの経験を横断して考える方法は、設計構築チャンネルのネットワーク・サーバーのキャリア解説でも扱っています。
オンプレの経験を面接でどう翻訳するかはクラウドエンジニア転職の面接で具体例を挙げています。
まとめ：オンプレ経験をクラウドの設計要素へ変換する
クラウド転職では、既存のネットワーク・OS・監視・変更管理を土台にし、責任共有、IAM、IaC、費用を補います。求人名ではなく担当工程を確認し、個人検証と業務経験を分けて、構成図・試験・切り分けで実力の範囲を示してください。
