「運用保守の経験しかないけど、AWSエンジニアへ転職できるのだろうか？」
「クラウドの実務経験がないと、転職は難しい？」
このように悩んでいるインフラエンジニアは少なくありません。
結論からいうと、運用保守の経験からAWS・クラウドエンジニアを目指すことは可能です。
ただし、AWS資格を取得するだけでは十分とはいえません。これまでのインフラ経験を整理したうえで、AWSの基礎知識、実際の構築経験、TerraformなどのIaC、ポートフォリオ、職務経歴書まで順番に準備することが重要です。
この記事では、運用保守・オンプレ環境で働いているインフラエンジニア向けに、AWSクラウドエンジニアへ転職するまでの流れをロードマップ形式で解説します。
運用保守からAWSクラウドエンジニアへの転職は可能？
結論からいうと、運用保守からAWSクラウドエンジニアへの転職は十分に狙えます。
特に、すでにインフラエンジニアとしてサーバーやネットワークの運用に携わっている場合、これまで身につけた知識をすべて捨ててゼロから勉強し直すわけではありません。
AWS公式も「AWSクラウドまたはオンプレミスITでの経験が豊富な受験者」にとって、AWS Certified Solutions Architect – Associate（SAA）は理想的な出発点だとしています。
たとえば、これまでの業務で以下のような経験があれば、AWSでも活かせます。
- Linux・Windows Serverの操作
- IPアドレスやサブネットの知識
- DNS
- ファイアウォール
- ロードバランサー
- Webサーバー
- データベース
- ログ監視
- 障害対応
- バックアップ
- セキュリティ
- 手順書・設計書の作成
重要なのは、「運用保守しか経験していない」と考えるのではなく、これまでのインフラ経験をAWS上でどう再現するかという視点を持つことです。
AWS公式：AWS Certified Solutions Architect – Associate
運用保守経験がAWS転職で評価される理由
AWSはクラウドサービスですが、その上で動いているシステムには従来のインフラと共通する考え方が数多くあります。
たとえばオンプレミスでサーバーを扱っていた人なら、AWSではEC2との対応関係を理解しやすくなります。
ネットワーク経験があれば、VPC、サブネット、ルートテーブル、セキュリティグループなどを理解するときにも役立ちます。
監視経験があれば、Amazon CloudWatchを学習するときにも「なぜ監視するのか」という前提知識があります。
つまり、転職活動では単に、
「AWSは未経験です」
と伝えるのではなく、
「オンプレミス環境で○年間、サーバー・ネットワークの運用保守を経験しており、その知識をAWS環境でも活かせるよう学習・構築を進めています」
という形で説明することが重要です。
AWSの実務経験がないことと、インフラ経験がないことは同じではありません。
AWS転職で不足しやすいスキル
一方、運用保守経験だけでは不足しやすい部分もあります。
特に意識したいのが、自分で設計・構築する経験です。
運用保守では、すでに完成した環境を維持する業務が中心になりやすいため、
「なぜこの構成にするのか」
「ゼロから環境を作る場合はどうするのか」
という経験が不足しやすくなります。
そこでAWS転職を目指す場合は、次の4つを重点的に補います。
AWSの基礎知識 → AWS構築経験 → IaC → 成果物として公開
この流れで学習すると、資格勉強だけで終わりにくくなります。
STEP1：AWS SAAを取得する
最初の目標としておすすめなのが、AWS Certified Solutions Architect – Associate（SAA）です。
SAAでは、AWS上で安全性・可用性・コストなどを考慮したシステムを設計するための知識が問われます。
2026年9月時点では、
- 試験時間：130分
- 問題数：65問
- 受験料：150 USD
- レベル：Associate
となっています。
AWS公式：AWS Certified Solutions Architect – Associate
資格だけで転職できるわけではない
ここで注意したいのが、
「SAAを取得＝AWSエンジニアになれる」
ではないことです。
資格はAWSの知識を体系的に学ぶためには非常に役立ちますが、実際にAWS環境を構築した経験とは別です。
そのため、
SAAの勉強とAWSハンズオンを並行する
という進め方がおすすめです。
資格で「知識」を身につけ、ハンズオンで「実際に触った経験」を作ります。
STEP2：AWSのハンズオン環境を作る
次は、自分のAWSアカウントを使って実際に環境を構築します。
最初から難しいシステムを作る必要はありません。
まずは、
VPC → サブネット → EC2 → セキュリティグループ → Webサーバー
という基本構成を自分で作れるようにします。
たとえば次のような環境です。
インターネット
↓
Internet Gateway
↓
VPC
↓
Public Subnet
↓
EC2
↓
Apache / Nginx
これだけでも、
- VPC
- CIDR
- サブネット
- ルートテーブル
- Internet Gateway
- EC2
- セキュリティグループ
- Linux
- Webサーバー
をまとめて学習できます。
AWSの料金には注意する
AWSを個人学習で利用するときは、料金管理も重要です。
2026年9月時点のAWS無料利用枠では、新規ユーザーはサインアップ時に100 USD分のAWSクレジットを受け取ることができ、対象アクティビティによって追加で最大100 USD分、合計最大200 USD分のクレジットを利用できます。
無料プランは、アカウント開設から6か月またはクレジットを使い切った時点のいずれか早い方までです。
料金体系は変更される可能性があるため、実際にAWSを利用するときは必ず最新情報を確認してください。
STEP3：IAM・VPC・セキュリティを理解する
AWS転職を目指すなら、単にEC2を起動できるだけではなく、安全な構成を考えられることも重要です。
特に学習したいのが、
- IAM
- VPC
- Public Subnet / Private Subnet
- Security Group
- Network ACL
- Route Table
- VPC Flow Logs
です。
AWS公式でも、VPCのセキュリティにおいてセキュリティグループによる通信制御、ネットワークACL、IAMによるアクセス管理、VPC Flow Logsによる通信監視などを挙げています。
ルートユーザーを普段使いしない
AWSアカウントを作ったら、セキュリティ設定も学習の一部として扱いましょう。
AWSは、ルートユーザーを必要な作業以外では使用しないこと、MFAを設定すること、ルートユーザーのアクセスキーを作成しないことなどを推奨しています。
「AWSサービスを触れる」だけではなく、なぜその設定が安全なのか説明できる状態を目指します。
STEP4：TerraformでIaCを経験する
AWSの基本的な構築に慣れてきたら、次にTerraformを学習します。
TerraformはInfrastructure as Code（IaC）のツールです。
GUIで一つずつインフラを作るのではなく、設定ファイルによってインフラ構成を定義できます。HashiCorp公式でも、IaCによってインフラ構成をバージョン管理・再利用・共有できることが説明されています。
最初は、
- VPC
- Subnet
- Internet Gateway
- Route Table
- Security Group
- EC2
など、AWSコンソールから一度作った環境をTerraformで再構築してみると理解しやすいです。
HashiCorp公式：Terraform AWSチュートリアル
ここで重要なのは、Terraformの文法を暗記することではありません。
「手作業で作ったAWS環境をコード化するとどうなるのか」
を理解することです。
STEP5：AWSポートフォリオを作る
AWSの実務経験がない場合は、学習した内容をポートフォリオとして見える形にすることをおすすめします。
単に、
「AWSを勉強しました」
と書くより、
「AWS上にWebシステムを構築し、Terraformでコード化しました」
と説明できる方が、何を学習したのか伝えやすくなります。
ポートフォリオの構成例
たとえば次のような構成です。
Route 53
↓
ALB
↓
EC2
↓
RDS
ネットワークは、
VPC
├ Public Subnet：ALB
└ Private Subnet：EC2 / RDS
といった構成を検討できます。
さらに、
- Terraform
- CloudWatch
- IAM
- GitHub
- 構成図
- README
などを組み合わせます。
ただし、いきなり複雑な構成にする必要はありません。
重要なのは、サービス数ではなく、
「なぜこの構成にしたのか説明できること」
です。
GitHubのREADMEも作る
ポートフォリオではコードだけ置くのではなく、READMEに以下を記載すると分かりやすくなります。
- 作成目的
- AWS構成図
- 使用サービス
- Terraformの構成
- セキュリティで意識したこと
- 可用性で意識したこと
- 苦労したポイント
- 改善したいポイント
これによって「AWSを触った」という事実だけでなく、設計時に何を考えたのかを説明できます。
STEP6：運用保守経験を職務経歴書で強みに変える
転職活動では、職務経歴書の書き方も重要です。
避けたいのは、
「サーバーの監視を担当」
「障害対応を担当」
「手順書に沿って作業」
だけで終わらせることです。
同じ業務でも、
何を担当し、どのような環境で、どんな問題に対応し、どう改善したのか
まで整理します。
たとえば、
「Linuxサーバー50台の運用監視を担当。障害発生時のログ調査、一次切り分け、エスカレーションを実施」
というように具体化します。
さらに改善経験があるなら、
「定型作業をシェルスクリプトで自動化し、作業時間を削減」
など、結果まで書けると経験が伝わりやすくなります。
AWS学習も職務経歴書に記載する
業務外の学習についても、
自己研鑽・個人開発
などの項目を作り、
- AWS SAA取得
- AWS個人環境構築
- Terraform
- GitHub
- ポートフォリオURL
などを記載します。
実務経験と個人学習を混同せず、どこまでが業務で、どこからが自己学習なのか明確にすることも大切です。
STEP7：AWS求人を選ぶ
AWS転職で注意したいのが、求人票に「AWS」と書かれているだけで判断しないことです。
AWSを利用している会社でも、自分が担当する業務が監視・運用のみというケースはあります。
設計・構築へ進みたい場合は、
- AWSの設計に携われるか
- AWSの構築に携われるか
- IaCを利用しているか
- Terraformを利用しているか
- CI/CDに携われるか
- クラウド移行案件があるか
- 運用から構築へステップアップできるか
などを確認します。
特に重要なのが、入社後に何を担当するのかです。
「AWS案件あり」という言葉だけではなく、具体的な業務内容まで確認しましょう。
運用保守からAWS転職を目指す90日ロードマップ
ここまでを90日間の学習計画にすると、次のようになります。
1〜30日目：AWS基礎＋SAA
最初の1か月はAWSの基本サービスを学習します。
重点的に学ぶのは、
- IAM
- EC2
- VPC
- S3
- RDS
- ELB
- Auto Scaling
- CloudWatch
- Route 53
などです。
SAAの教材を使いながら、AWSコンソールでも実際にサービスを触ります。
31〜60日目：AWS構築＋Terraform
2か月目は「知っている」状態から「作れる」状態へ進みます。
VPCから自分でネットワークを作り、
VPC → Subnet → EC2 → Webサーバー
まで構築します。
その後、同じ環境をTerraformで作り直します。
Terraformでは、
init → plan → apply → destroy
という基本的な流れを理解します。
61〜90日目：ポートフォリオ＋転職活動
3か月目は、それまで学習した内容を成果物にします。
AWS構成図を作り、TerraformコードをGitHubへ整理し、READMEを書きます。
並行して職務経歴書も修正します。
そして、
ポートフォリオ完成を待たずに求人情報を確認し始める
ことも重要です。
求人を見ることで、
「自分には何が足りないのか」
が具体的に見えてきます。
AWS転職でやらなくていいこと
AWS転職を目指すと、勉強するものが次々と出てきます。
しかし、最初からすべてを学習する必要はありません。
AWSには非常に多くのサービスがあります。
それらを全部覚えてから転職活動を始めようとすると、いつまで経っても応募できません。
まずは、
インフラ基礎 → AWS主要サービス → SAA → ハンズオン → Terraform → ポートフォリオ
まで進めます。
その後、応募したい求人に合わせて不足している技術を追加していく方が効率的です。
運用保守経験は「遠回り」ではない
運用保守を続けていると、
「設計構築を経験してこなかったから遅れている」
と感じることがあるかもしれません。
しかし、運用経験から得られるものもあります。
たとえば、
- 障害時にどこを確認するか
- ログをどう読むか
- 変更作業にどんなリスクがあるか
- バックアップがなぜ必要なのか
- 監視項目をなぜ設定するのか
- 手順を標準化する重要性
といった知識です。
AWSを学ぶときも、
「EC2を起動できた」
で終わらず、
「EC2に障害が発生したらどうするのか」
「ログはどこに保存するのか」
「バックアップはどうするのか」
「アクセス権限はどう管理するのか」
という運用視点を持つことができます。
これは、運用保守を経験してきた人の強みです。
まとめ：運用保守からAWSへ進むなら「資格＋構築＋成果物」
運用保守からAWSクラウドエンジニアへの転職を目指す場合、資格取得だけで終わらせないことが重要です。
おすすめの順番は、
① インフラ経験を棚卸しする
↓
② AWS SAAを勉強する
↓
③ AWS環境を実際に構築する
↓
④ IAM・VPC・セキュリティを理解する
↓
⑤ TerraformでIaCを経験する
↓
⑥ AWSポートフォリオを作る
↓
⑦ 職務経歴書を改善する
↓
⑧ AWS設計・構築に進める求人を探す
です。
運用保守経験を捨ててAWSへ行くのではありません。
これまで身につけたインフラ経験の上にAWS・Terraformなどのクラウドスキルを積み上げるという考え方が重要です。
まずはAWSの基礎を学びながら、自分のAWS環境で小さなシステムを一つ構築するところから始めてみてください。