AWSエンジニアへの転職｜現在地で変わる入口と3つの到達点

AWSに移りたいと考えたら

社内でクラウドへの移行の話が出ている。求人を眺めているとAWSという文字が目に入る。資格を取るとよいらしいと聞いて、Cloud Practitionerという名前まではたどり着いた。けれども、そこから先が決まりません。

決まらない理由は、判断に必要な材料が2つ欠けているからです。ひとつは、今の自分の経験がどこまで通用するのか。もうひとつは、AWSを扱えるようになった先に何があるのか。この2つが見えないまま資格の勉強を始めると、取り終えたときに次の一手が分からないという状態になります。

足りないものは、今どんな仕事をしているかで変わります。サーバやネットワークの運用を担当している場合、オンプレミスの基盤構築をしている場合、アプリケーション開発をしている場合——この3つでは、AWSに近づくために埋めるものがそれぞれ違います。そして向かう先も1つではありません。どこから入るかと、どこへ向かうか。この組み合わせで進み方が決まります。

経験者向けのITエンジニア転職サービスの比較については、以下の記事で整理しています。

参考記事：ITエンジニアにおすすめの転職エージェント10選｜経験者向けに比較

入口は現在地で3つに分かれる

AWSへの移り方は、今どの仕事をしているかで変わります。足りないものが人によって違うので、まず自分がどの入口にいるかを特定するところから始めます。

サーバ・ネットワークの運用から

仮想サーバ、ストレージ、ネットワークという考え方は、そのまま通用します。EC2もVPCも、名前が変わっただけで概念としては馴染みのあるものです。ここから入る人にとって、クラウドの知識そのものは大きな壁になりません。

足りないのは、その運用をコードで書き直す経験のほうです。手順書に沿って画面を操作して環境を作るやり方から、構成をコードとして書いて再現できる形にするやり方へ、発想を切り替える必要があります。もしあなたが今サーバやネットワークの運用を担当しているなら、最初に埋めるのはここです。AWSの新しいサービスを次々に覚えるより、今やっている作業をコードで再現してみるほうが、選考で話せる材料になります。

オンプレミスの基盤構築から

既存システムをクラウドへ移す案件が、そのまま入口になります。移行の仕事では、移す先のクラウドを知っている人だけでなく、移す元の構成を理解している人が必要になるからです。オンプレミスの経験は不利ではなく、前提として働きます。

移行の仕事が実際にどこで発生しているかも見ておきましょう。総務省の令和7年版情報通信白書によると、2024年時点で80.6%の企業がクラウドサービスを利用しています。すでに使っている企業が多いということは、これから移す仕事だけでなく、移した後の運用や作り直しの仕事も各所で動いているということです。今の勤務先に移行の話が出ているなら、それは自分から手を挙げられる場面です。

足りないのは、移行後の設計思想です。オンプレミスの構成をそのままクラウドに置き換えるだけでは、クラウドを使う意味が出ません。何を置き換え、何を作り直すかを判断できるようになることが、次の段階になります。

アプリケーション開発から

コードは書けるが、その下の土台が薄いという状態です。デプロイ先としてAWSを触ったことはあっても、ネットワークの設計やOSの設定を自分で決めた経験がない、という形が多くなります。

この場合は、順序が逆になります。AWSのサービスを覚える前に、ネットワークとOSの基礎を埋めるほうが結果的に早く進みます。サブネットをどう分けるか、通信をどこで止めるか、権限をどう設計するか——こうした判断は、クラウドであってもオンプレミスであっても考え方が共通しているためです。書ける力はそのまま強みになるので、土台が入れば運用の自動化に進みやすくなります。

到達点は3つの系統に分かれる

AWSを扱う仕事の先は3つの方向に分かれます。これは分類の提案ではなく、AWS自身が認定の階層として公開しているものです。

AWSの公式ブログ「AWS認定の上位・下位関係を理解して効率的に認定を更新しましょう」では、認定にFoundational、Associate、Professional、Specialtyの4カテゴリがあるとしたうえで、Specialtyを除く3つに階層関係が定義されていると説明されています。その階層は、次の3つの系統として整理されています。

下位はどの系統もCloud Practitionerで共通しています。Generative AI Developer系だけ、これに加えてAI Practitionerも下位に含まれます。つまり入口の1段はどの方向でも同じで、分かれるのは中位から先だということです。

この3本の柱が、そのまま進む方向の選択肢になります。それぞれがどんな仕事に対応するのかを見ていきます。

設計に進む（Solutions Architect系）

要件を聞いて全体像を組み立てる方向です。どのサービスをどう組み合わせるか、可用性とコストのどちらを優先するか、将来の変更にどこまで備えるか——こうした判断を担います。

この方向に進む人が普段考えているのは、個別の設定値ではなく構成の理由です。なぜこの構成にしたのかを説明できることが仕事の中身になります。

運用と自動化に進む（DevOps Engineer系）

構築と運用をコードで自動化し、開発と運用のあいだをつなぐ方向です。環境の構築を手作業から解放し、変更を安全に反映できる仕組みを作ります。

DevOps Engineer系の中位にCloudOps、Developer、SysOps Administratorという複数のAssociateが置かれているとおり、この方向には運用寄りと開発寄りの入り方があります。どちらから入っても上位で合流する形になっています。

データと機械学習に進む（Generative AI Developer系）

データ基盤や機械学習の実行環境を扱う方向です。データを集めて整える仕組みと、それを使うモデルの動く場所を用意します。

Generative AI Developer系の中位にData EngineerとMachine Learning Engineerが置かれており、データを運ぶ側と使う側の両方が入口になります。

基盤側の職務が労働市場でどう位置づけられているかも見ておきましょう。厚生労働省の職業情報提供サイト（job tag）の「システムエンジニア（基盤システム）」の職業詳細によると、就業者数は656,770人（令和2年国勢調査）、平均年齢は38.3歳、平均年収は889万円、労働時間は173時間（いずれも令和7年賃金構造基本統計調査）、有効求人倍率は2.28（令和6年度ハローワーク求人統計データ）です。有効求人倍率が1を大きく上回っているということは、ハローワークの集計では求人が求職者を上回っている状態を指します。

なお、この職業詳細の別名にはインフラエンジニアやITアーキテクトが含まれており、仕事の内容としても「ハードウェアに直接触れずクラウド上に仮想的なシステムを構築することが増えている」と記されています。基盤側の仕事の中身そのものが、クラウド側へ寄ってきているということです。

インフラエンジニアという職種全体のキャリアの広がりについては、以下の記事で整理しています。

参考記事：インフラエンジニアの転職戦略｜未経験からの挑戦と経験者のキャリアパス

資格は経路のどこで効くか

認定は「どれを取るか」ではなく「どの系統に進むか」で選びます。AWSが系統ごとに上位・下位の関係を定義している以上、自分が向かう系統の階層をたどるのが素直な選び方になります。

設計に進むならSolutions Architect系、運用と自動化に進むならDevOps Engineer系、データと機械学習に進むならGenerative AI Developer系。この対応が先にあって、その中で今の実力に合う段を選ぶ、という順序です。方向が決まっていない状態で下位から順に取り始めると、途中で「この先どこへ向かうのか」という問いに戻ることになります。

更新の仕組みも知っておくと、計画が立てやすくなります。同じ公式ブログには「上位認定を更新した場合に下位認定も更新されるのは、その下位認定をすでに取得している場合に限ります」と記されています。つまり、上位を更新すれば自動的に下位まで面倒を見てくれるわけではなく、すでに持っているものだけが対象です。あわせて、失効した認定は自動更新されないとも書かれています。

経験をどう積み増すか

経験は転職してから積むものではありません。今の職場にいるあいだに積み始められます。むしろ、積んでから動くほうが選択肢が広がります。

移行案件に手を挙げる

既存システムをクラウドへ移す案件が社内にあるなら、そこに関わるのが最短です。移行では移す元の構成を理解している人が必要とされるため、今の職場での立ち位置がそのまま有利に働きます。

関わるときは、担当した範囲を後から説明できる形で記録しておいてください。どのシステムを、どういう理由で、どこまで移したのか。この3点があると、選考で話す材料になります。

検証環境を自分で作る

規模は小さくてかまいません。自分で構成を組んで、実際に動かしてみることです。仕事で任される範囲が限られていても、この部分は自分の裁量で進められます。

大事なのは、組んだ理由を説明できる状態にしておくことです。なぜこのサービスを選んだのか、なぜこの構成にしたのか。手順をなぞっただけの環境と、判断を伴って組んだ環境とでは、話せることの量が変わります。

運用をコードに置き換える

今、手作業で行っている設定や構築の一部を、コードで再現できる形に変えてみます。全部を置き換える必要はなく、繰り返し発生している作業を1つ選べば十分です。

この経験は、設計に進む系統でも運用に進む系統でも共通して効きます。構成をコードで表現できるということは、構成を言葉で説明できるということでもあるためです。面接で構成の話をするときに、この経験があるかどうかで説明の解像度が変わります。

相談先の選び方

経路が決まったら、その系統の求人を扱っている相談先を選びます。確認の観点は単純で、自分が向かう方向の職種名をそのサービスが扱っているかどうかです。

マイナビ転職ITエージェント

株式会社マイナビが運営する、IT・Webエンジニア向けの転職支援サービスです。

対象職種として、SE・システムエンジニア、アプリケーションエンジニアのほか、インフラエンジニア、ネットワークエンジニア、クラウドエンジニア、セキュリティエンジニア、社内SE、システム運用・保守などが挙げられています。クラウドエンジニアという職種名が明示されているため、設計や運用の系統に進む場合に話が通りやすくなります。

支援の内容としては、キャリアアドバイザーが疑問に答えたうえで、応募書類の添削と面接対策を行うとされています。面接日程の調整や給与などの条件交渉の代行にも対応します。対応エリアは全国で、夜間や土曜の相談も受け付けています。登録から転職に至るまで費用はかからないと公式サイトに明記されています。

ひとつ線引きをしておきます。サービスに登録しても、進む方向が定まっていなければ、紹介された求人を評価できません。設計に近い仕事なのか、運用の自動化に近い仕事なのか、判断する軸がないまま話を聞いても、条件面だけで比べることになります。先に方向を1つ決めてから相談するほうが、話が早く進みます。

まとめ

AWSを扱うエンジニアへの移り方について、要点を振り返ります。入口は現在地で3つに分かれ、サーバ・ネットワークの運用からならコードで書き直す経験が、オンプレミスの基盤構築からなら移行後の設計思想が、アプリケーション開発からならネットワークとOSの基礎が、それぞれ足りないものになります。到達点も設計・運用の自動化・データと機械学習という3つの系統に分かれ、その分かれ方はAWSが認定の階層として公開しています。認定はその系統に対応させて選ぶもので、経験の代わりにはなりません。そして経験は、転職を決める前に今の職場で積み始められます。

今日できることを1つ挙げるなら、3つの系統のうち自分が進みたい方向を1つ選んで、その理由を3行で書き出してみてください。書けなければ、まだ選ぶ段階ではないということです。その場合は資格の勉強を始める前に、3つの方向の仕事内容をもう少し調べるほうが、遠回りに見えて早く進みます。