AWS経験はインフラエンジニア転職で評価されますが、マネジメントコンソールを触っただけでは十分ではありません。IAM、VPC、コンピューティング、監視、バックアップのうち、何を設計・変更・確認し、障害時にどう切り分けたかを説明できることが条件です。資格は知識の範囲を示し、構成図やコマンド結果は実際に手を動かした範囲を補います。
このページはインフラエンジニア転職完全ガイドの各論です。転職の進め方を最初から確認する場合はそちらへ。
AWS経験は転職でどこまで評価される？
評価は「AWSを使った年数」ではなく、担当工程と判断の深さで変わります。同じEC2経験でも、起動停止だけを担当した人と、ネットワーク・権限・監視・復旧まで設計した人では狙える求人が異なります。
| 経験レベル | 実施内容 | 狙いやすい担当 | 不足しやすい点 |
|---|---|---|---|
| 操作 | EC2起動停止、定型監視、手順実行 | クラウド運用、監視 | 構成理由、変更判断 |
| 変更・構築 | VPC、SG、IAM、監視設定、試験 | 構築、運用改善 | 非機能要件、方式比較 |
| 設計 | 可用性、権限、バックアップ、ログ、費用を設計 | クラウド設計、移行 | 複数案件での再現性 |
| 改善・自動化 | IaC、継続監視、コスト最適化、標準化 | プラットフォーム、SRE、CCoE支援 | アプリ側との責任境界 |
AWS案件で必要な技術は何？
サービス名を暗記するより、通信、権限、可用性、観測、復旧を一つのシステムとして説明できることが大切です。求人票では、次の技術領域をどの工程で使うかまで確認します。
| 技術領域 | 代表的なAWS要素 | 実務での確認 |
|---|---|---|
| 認証・認可 | IAM、IAM Identity Center、ロール | 誰が、何に、どの操作を許可されるか |
| ネットワーク | VPC、Subnet、Route Table、Security Group、NACL | 通信経路、入口・出口、名前解決 |
| コンピューティング | EC2、Auto Scaling、Lambda、ECS | 配置、スケール、障害時の置き換え |
| データ・バックアップ | S3、EBS、RDS、AWS Backup | 保護対象、保持、復元手順、暗号化 |
| 監視・記録 | CloudWatch、CloudTrail、VPC Flow Logs | 検知、原因調査、監査証跡 |
| 自動化・費用 | CloudFormation、Terraform、Cost Explorer | 変更の再現性、差分、継続費用 |
責任共有モデルを実務でどう考える？
AWSがクラウド基盤そのものを保護し、利用者は選んだサービスに応じてOS、データ、権限、ネットワーク設定などを管理します。EC2ではゲストOSの更新やセキュリティグループも利用者側の責任に含まれるため、「クラウドだからパッチや設定確認が不要」にはなりません。
責任の境界はサービスによって変わります。最新の区分は、AWS公式の責任共有モデルで確認してください。
IAM・VPC・監視は実務のどこで使う？
この3領域は、アクセス制御、通信制御、事象の確認を担います。個別設定ではなく、利用者の操作とパケットの流れを追って設計します。
IAMは人とシステムの権限を分ける
人の作業、EC2からS3へのアクセス、CI/CDからのデプロイは別の主体です。長期アクセスキーを配る前提にせず、一時的な認証情報、MFA、最小権限を検討します。AWS公式のIAMのセキュリティベストプラクティスでは、一時的な認証情報、MFA、最小権限、未使用権限の見直しなどが示されています。
VPCは往路と復路を確認する
利用者からALB、EC2、データベースへ届く経路と、戻り通信を図にします。ルートテーブル、セキュリティグループ、NACLだけでなく、DNS名がどのIPへ解決されたかも確認対象です。
監視は検知後の行動まで設計する
CPU使用率のアラームを作るだけでは運用になりません。通知先、初動、確認するログ、復旧条件、エスカレーション先を決めます。CloudTrailはAPI操作、CloudWatchはメトリクスやログ、VPC Flow Logsはネットワークフローというように、証跡の役割を分けます。
AWSの検証成果物はどう作る？
小規模なWeb構成でも、目的、構成、設定、試験、削除まで記録すれば、操作経験を説明できます。実在企業の構成を模倣せず、学習用の架空要件を明記します。
- 「外部公開するWebサーバー1台」など検証要件を書く
- VPC、サブネット、ルート、セキュリティグループを構成図にする
- 権限をロールへ分け、不要な公開設定を避ける
- 正常時のHTTP応答、DNS、ルート、ログを記録する
- 許可ルールを外した異常系で、どこに証跡が残るか確認する
- 費用が発生するリソースを削除し、削除確認を残す
# AWS CLIの読み取り例。学習用アカウントと最小権限で実行してください
aws sts get-caller-identity
aws ec2 describe-route-tables --filters "Name=vpc-id,Values=vpc-xxxxxxxx"
aws ec2 describe-security-groups --group-ids sg-xxxxxxxx
出力にはアカウントIDなどが含まれるため、公開前に必ず伏せます。権限変更やリソース削除のコマンドは、成果物用に安易に実行しません。
AWS資格と実務経験はどう分けて伝える？
AWS認定はサービスの概念や設計原則を学んだ証拠にはなりますが、本番変更や障害対応を担当した証明にはなりません。職務経歴書では「資格」「個人検証」「業務経験」を別欄にします。
| 区分 | 証明できること | 証明できないこと |
|---|---|---|
| 資格 | 試験範囲の知識を学習した | 本番設計・変更を担当した |
| 個人検証 | 自分で構成し、結果を確認した | 組織の制約下で運用した |
| 業務経験 | 担当工程、判断、関係者、結果 | 担当外の設計やチーム全体の成果 |
AWS経験者が狙える求人は？
経験の深さに合わせ、クラウド運用、構築、移行、設計、自動化の求人を選びます。「AWS案件」とだけ書かれた求人では、実際の工程を判断できません。
| 求人タイプ | 担当工程 | 評価される経験 | 確認質問 |
|---|---|---|---|
| クラウド運用 | 監視、変更、障害、バックアップ | CloudWatch、ログ、復旧手順 | 定型監視と改善業務の割合はどのくらいですか |
| AWS構築 | 詳細設計、構築、試験 | VPC、IAM、EC2、IaC | パラメータと試験項目は誰が作りますか |
| 移行支援 | 調査、設計、移行、切替 | オンプレ、依存関係、切り戻し | 移行方式の選定を担当しますか |
| クラウド設計 | 要件、方式、非機能設計 | 可用性、セキュリティ、費用 | 顧客要件と設計レビューの担当範囲はどこですか |
職務経歴書ではAWS経験をどう書く？
サービス一覧ではなく、要件、構成、担当工程、判断、確認結果を書きます。Well-Architected Frameworkの六つの柱は設計を見直す観点になりますが、案件で実際に検討した項目だけを実績として記載します。六つの柱はAWS公式のWell-Architected Frameworkで確認できます。
伝わりにくい例
AWS（EC2、S3、VPC、IAM、CloudWatch）を使用したクラウド環境の構築を担当。
役割と結果が分かる改善例
【記載例】検証環境のWeb基盤でVPC、Public/Private Subnet、ALB、EC2、CloudWatchを構築。EC2はPrivate Subnetへ配置し、管理操作はIAMロールへ分離した。ALBヘルスチェック異常時に、対象ポート、SG、アプリ待受、ログの順で確認する試験手順を作成した。
これは個人検証の書き方を示す架空例です。本番案件として記載せず、業務経験とは明確に分けてください。
サービス名より通信と責任の境界から確認する
AWS案件でも、サービス名より通信と責任の境界から確認します。たとえばALBのヘルスチェックが失敗したとき、EC2が停止していると決め付けず、ターゲット状態、ポート、セキュリティグループ、アプリの待受、OSログを順に見ます。設計時には、その確認に必要なメトリクスとログが最初から取れるかも決めます。コンソール画面を操作した記憶ではなく、「どの正常値と比較し、どこで原因を分けたか」を残すと、別案件でも使える経験になります。設計から構築までの流れは、設計構築チャンネルの設計構築の実務フロー解説も参考になります。
まとめ：AWS経験は担当工程と判断で示す
AWS経験を転職へ生かすには、IAM、VPC、監視、バックアップなどを、要件と確認結果に結び付けます。資格、個人検証、業務経験を分け、求人では「AWSを使うか」ではなく、設計・変更・障害対応のどこを担当できるかを確認してください。
