クラウドエンジニアの求人を見ていると、AWS、Azure、IaCなどの言葉が並びます。全部を覚えてから応募するべきなのか、今のサーバーやネットワークの経験が使えるのか、迷う方もいると思います。
サービス名より先に、応募先で何を作り、何を維持するのかを見ましょう。クラウドでもネットワーク、権限、監視、復旧の仕事はあります。今ある経験をどこへつなげるか、順に整理します。
サービス名より、担当する工程と成果物を見る
同じAWSの求人でも、既存環境の監視、新規環境の構築、構成の設計では担当が違います。管理画面で操作することと、必要な設定を判断することも別です。
要件を整理する人、設計する人、設定を変更する人、試験する人がどう分担するかを聞きます。構成図、設定差分、監視項目、復旧手順など、自分が作る資料が分かれば仕事を想像しやすくなります。
| 担当 | 仕事の例 | 応募で説明するもの |
|---|---|---|
| 運用 | 監視、権限申請、変更、障害調査、費用確認 | 調査記録、手順、変更と復旧の結果 |
| 構築・試験 | リソース作成、設定、移行、正常・異常の確認 | 設定、構成図、試験表、証跡 |
| 設計 | 要件から構成、権限、可用性、監視、復旧、費用を決める | 採用理由、代替案、制約、レビュー |
| リーダー | 工程、変更判断、課題、品質、顧客・他担当との調整 | 判断した範囲、管理した成果物と結果 |
求人に「構築」とあっても、最初から全部を任されるとは限りません。最初の作業例と、レビューの流れを確認しましょう。
クラウドに移しても、利用者の管理は残る
EC2の説明例では、物理サーバーや基盤側をAWSが管理し、利用者はゲストOS、アプリ、データ、権限などを管理します。自分でOSを動かすサービスでは、パッチや監視も考えます。
S3では利用者がゲストOSを管理しません。それでも、保存するデータ、アクセス権限、公開範囲、暗号化の設定など、利用者が決める部分は残ります。
| オンプレの経験 | クラウドへ持ち込める力 | 追加で学ぶこと |
|---|---|---|
| ネットワーク | 宛先、経路、DNS、制御、戻り通信 | VPC、サブネット、ルート、SG、NACL |
| サーバー | OS、ログ、サービス、パッチ、復元 | イメージ、マネージドサービス、責任分担 |
| 運用保守 | 影響確認、変更前後比較、中止・切り戻し | IAM、API、ログ連携、利用量と費用 |
| 設計・構築 | 要件、方式、設定、試験、引継ぎ | サービス制約、可用性、IaC、費用設計 |
この分担を責任共有モデルと呼びます。どのサービスでも同じ分担になるわけではありません。サービスを選ぶときは、管理が減る部分と自分たちが担う部分を確認します。
「クラウドだから運用は不要」と考えると、障害時の担当や復旧の準備が抜けます。求人でも、どのサービスのどの範囲を担当するかまで聞きます。
ネットワークとOSの基礎を、権限・監視へつなげる
VPC、サブネット、経路を読むには、IPとルーティングの基礎が役立ちます。サーバーでプロセスやログを調べた経験は、クラウド上のVMを調べる場面にもつながります。
そこへIAM、監視、費用、IaCを足します。IAMは「誰が、どの対象へ、何をできるか」を制御する仕組みです。通信の許可と、操作する権限は別々に確認します。
| 基礎 | 検証で説明したいこと |
|---|---|
| ネットワーク | どこからどこへ接続し、経路と制御がどこにあるか |
| OS・サービス | サービス起動、待受、ログ、容量、利用者の処理 |
| IAM | 誰・何が、どの対象へ、どの操作を行えるか |
| 監視・復旧 | 異常を何で検知し、誰が対応し、何をもって復旧とするか |
| IaC・Git | 設定差分、レビュー、適用、状態の管理、失敗時の対応 |
小さなWeb環境なら、公開するポート、管理用の接続、ログの保存先、削除する対象を決めてから作ります。表示できたら終わりではなく、止めたときの通知や復旧も試します。
IaCのplanは変更予定を読む材料です。予定どおりの差分でも、利用者の処理が動くとは限らないので、変更後の試験を用意します。
最初のクラウドと資格は、応募先に合わせる
AWS、Azure、Google Cloudを同時に広く学ぶより、候補求人が使う一つから始める方法があります。既存環境とどう接続し、誰が運用しているかも確認します。
AWSの設計・構築を学ぶならSolutions Architect – Associate、運用を学ぶならCloudOps Engineer – Associateが候補です。どちらも学習範囲と担当が合うかで選びます。
| 求人で確認すること | 確認する理由 |
|---|---|
| 使うクラウドとサービス | 会社全体の実績と、募集部署の仕事を分ける |
| 運用・構築・設計の担当 | サービス名と、自分が作る成果物をつなげる |
| 変更・レビューの仕組み | 本番の操作だけ任される配属を避ける |
| オンコール・現地作業 | クラウド求人でも夜間対応や接続先の現地作業はあり得る |
| 初回配属と教育 | 資格取得後にどの業務へ入るかを確かめる |
CloudOps Engineer – Associateは旧SysOps Administrator – Associateの後継名称です。既に取得したSysOpsの資格名が自動的に置き換わるわけではありません。書類には実際に取得した正式名称を書きます。
資格学習に合わせ、構成図、権限の理由、試験結果を残すと、何を理解して作ったかを説明できます。資格の数だけで経験を表そうとしなくて大丈夫です。
個人検証と実務を分けて、求人へ伝える
未経験なら、作成した環境の目的と構成、試験したことを個人検証として書きます。オンプレミスの経験があるなら、監視、バックアップ、変更、復旧のうち、クラウドでも使える行動を探します。
検証では利用料を確認し、予算や通知、削除の手順を用意します。無料枠があるというだけで、作成するものすべてが無料になるとは判断しません。
| これまでの経験 | 最初の準備 | 応募時に残す証拠 |
|---|---|---|
| IT実務未経験 | OS・ネットワークと小さなクラウド検証 | 個人検証と明記した図・設定・試験結果 |
| 運用保守経験 | 今の調査・変更をクラウド固有の設定へ対応させる | 自分の担当と、IAM・監視・復旧の検証 |
| 構築・設計経験 | 既存要件をサービスへ置き換え、制約と費用を比較 | 方式比較、移行、試験、運用へ渡す資料 |
- 目的と確認する処理を一つ決める。
- 接続・権限・ログ・復旧を含む構成を図にする。
- 正常時と異常時の期待結果を先に書く。
- 変更、再作成、復元を検証用の範囲で確認する。
- 使わなくなったリソースと費用を確認し、結果を残す。
求人では本番の変更権限、レビュー、障害時の連絡、待機、費用管理まで確認します。リモート勤務も、初期の出社や案件ごとの条件を含めて聞きます。
今の経験一つと、応募先で増やしたい担当一つを並べてみましょう。その間を埋める検証が決まれば、学習も書類も具体的になります。
確認に使った公式資料
