転職前、私はAWSを約3年間経験していました。担当していたのは、主に既存環境の運用保守と追加開発です。そのため、転職活動中は「AWSの実務経験がある」と自信を持って伝えていました。
しかし、クラウドエンジニアへ転職してから、同じAWS業務でも扱う範囲が大きく違うことに気づきました。Transit Gateway（TGW）、AWS WAF、CloudFront、API Gateway、コンテナなど、前職では十分に触れられなかったサービスや構成を目にし、特にネットワークとセキュリティの知識不足を感じました。
この記事では、AWSの運用保守を経験していた私が、転職後になぜ知識不足を感じたのか、今振り返って転職前に何を学んでおけばよかったと思うのかを紹介します。
AWS実務経験3年でも、経験は運用保守に偏っていた
転職前のAWS業務では、すでに構築されている環境の運用保守と追加開発を担当していました。日々の作業を通じてAWSへ触れる機会はありましたが、システム全体のアーキテクチャをゼロから考えたり、多数のサービスを比較して構成を決めたりする経験は限られていました。
運用保守の経験は、障害対応や既存環境を安全に変更するうえで役立ちます。一方で、担当範囲が固定されていると「なぜこのサービスが選ばれたのか」「別の構成では何が変わるのか」まで考える機会が少なくなります。
私は転職後、AWS経験の年数だけでは技術の幅を判断できないと実感しました。重要なのは、どのサービスを使ったかだけでなく、どのような要件に対して、どこまで自分で考えたかです。
転職後に初めて触れたサービスと構成
Transit Gateway（TGW）
複数のVPCやネットワークを接続する構成に触れ、単一VPCの中だけではなく、システム全体の通信経路を考える必要があると知りました。接続できているかだけでなく、どこを経由し、どの範囲まで通信を許可するかを整理する力が求められます。
AWS WAFとCloudFront
Webアプリケーションを公開する構成では、コンテンツ配信の速さだけでなく、外部からの不正なリクエストをどこで防ぐかも重要です。WAFやCloudFrontを含む構成を見たことで、インフラ担当者にもWebセキュリティと通信経路の理解が必要だと感じました。
API Gateway
APIを公開・管理する構成に触れ、サーバーやネットワークだけではなく、アプリケーションとの境界も意識するようになりました。認証、アクセス制御、ログ、障害時の切り分けなど、周辺要素を含めて考える必要があります。
コンテナ
コンテナを利用した環境では、仮想マシンを中心に考えていたときとは異なる知識が必要でした。アプリケーションの実行単位、イメージ、ネットワーク、ログ、監視など、構成全体を理解しなければ問題の切り分けが難しくなります。
若手のほうが詳しいと感じたのは「サービスの使われ方」と「構成」
転職後、自分より経験年数の短い若手社員のほうが、各AWSサービスの使われ方や構成をよく理解していると感じる場面がありました。
私は運用保守の経験が長かったため、既存環境の手順や障害対応には慣れていました。一方、若手社員は複数の構成例を知っており、要件に合わせてサービスを組み合わせる考え方を持っていました。
経験年数で比べるのではなく、自分が知らない構成は素直に質問し、資料や構成図を確認することが大切です。転職後は「知っているサービスの数」よりも、「サービス同士の関係を説明できるか」を意識するようになりました。
特に不足を感じた2つの分野
1．ネットワーク
AWSでは、VPC、サブネット、ルート、セキュリティグループ、名前解決、負荷分散、拠点間接続などが互いに関係します。TGWを含む構成では、通信経路を図にして追える力が特に重要だと感じました。
設定項目を覚えるだけでなく、「送信元から送信先まで、どの経路を通るのか」「どこで通信が制御されるのか」を説明できることが、設計やトラブル対応につながります。
2．セキュリティ
運用保守では既存のルールに沿って作業することが中心でしたが、転職後は、なぜその制御が必要なのかを考える場面が増えました。WAF、アクセス権限、公開範囲、ログの残し方など、セキュリティは個別設定ではなく構成全体で考える必要があります。
「動く構成」を作るだけでなく、必要最小限の権限になっているか、外部へ不要に公開されていないか、問題発生時に追跡できるかという視点が不足していました。
転職前に戻れるなら取り組みたい3つのこと
IaCで小さな構成を作る
転職前に戻れるなら、まずIaCを使って小さなAWS環境を自分で作ります。コードで構成を表現すると、各リソースの依存関係や設定項目を意識しやすくなります。最初から大規模な環境を目指さず、VPC、サブネット、ルート、Web公開などの基本構成から始めたいです。
通信経路を構成図に書く
ネットワークは、構成図を書きながら学ぶほうが理解しやすいと感じます。利用者のリクエストがどこを通り、どこで制御され、どのサービスへ届くのかを矢印で追います。障害を想定し、「通信できないときにどこから確認するか」まで考えると実務につながります。
セキュリティを後付けにしない
環境を作った後にセキュリティを追加するのではなく、設計時点から公開範囲、権限、ログ、暗号化を確認する習慣をつけたいです。AWSのベストプラクティスを学び、なぜその設定が推奨されるのかを自分の言葉で説明できる状態を目指します。
資格学習と実務経験は組み合わせると効果的
AWS資格の勉強は、担当業務だけでは触れにくいサービスを体系的に知るきっかけになります。私は転職後にAWS認定ソリューションアーキテクト アソシエイトを取得し、ベストプラクティスをもとに提案を考えやすくなりました。
一方で、資格の知識だけでは実際の構成をイメージしにくい部分もあります。構成図を読む、IaCで作る、通信経路を確認するという練習を組み合わせることで、知識が実務へつながりやすくなります。勉強方法はAWS SAAに2か月で合格した勉強法にまとめています。
クラウド転職で評価されたAWS・OCI・オンプレミスからクラウドへの移行経験については、クラウドエンジニア転職で評価された経験も参考にしてください。
まとめ：AWS経験年数よりも、構成を説明できる力が重要
私は転職前にAWSを約3年間経験していましたが、業務が運用保守と追加開発に偏っていたため、転職後にTGW、WAF、CloudFront、API Gateway、コンテナを含む構成へ触れ、知識不足を感じました。
特に不足していたのは、ネットワークとセキュリティです。転職前に戻れるなら、IaCで小さな環境を作り、通信経路を構成図で整理し、セキュリティを設計時点から考える練習をします。
AWSの実務経験があっても、知らないサービスや構成があるのは当然です。経験年数だけで安心したり落ち込んだりせず、自分の担当範囲を把握して、足りない領域を一つずつ広げることが大切だと実感しています。
