「AWS経験はある。でも、フリーランス案件でどこまで任せてもらえるのか分からない」。サービス名を増やしても、この迷いは意外と消えません。
フリーランスのAWS案件で必要なスキルを考えるなら、見るべきは知っているサービスの数より、AWS上の変更を安全に進め、リリース後まで追えるかです。
ネットワーク、IAM、IaC、監視、CI/CD、設計判断。これらを別々の暗記科目にせず、「自分がどこまで仕事として持てるか」に変換してみましょう。
AWS経験年数より「任せられる範囲」を見る
2026年9月3日に確認したフリーランス向けAWS案件の掲載例では、AWSだけでなく、Terraform、CloudFormation、CI/CD、ログ・メトリクス・トレースによる監視、障害対応まで一緒に求める案件が見られます。
たとえば、フルスタック案件ではAWS/GCP上のインフラ運用、Terraform CloudによるIaC管理、CI/CDの最適化、オブザーバビリティまで担当範囲に含まれていました。別のAWS基盤構築案件では、CloudFormationやTerraformに加え、IAM、WAF、Security Hub、GuardDuty、CloudWatchが利用環境として挙げられています。
もちろん、掲載例をそのまま「市場全体の必須条件」とは扱えません。ただ、AWS案件を探すときに「EC2を触ったことがある」だけでは仕事の深さを表しにくい理由は見えてきます。
| 経験の表し方 | 仕事として見える範囲 |
|---|---|
| AWSを触った | 既存環境でコンソールやログを確認できる |
| AWSを変更できる | 影響範囲を確認し、小さな変更を安全に反映できる |
| AWSを運用できる | 監視・障害切り分け・復旧まで追える |
| AWSを設計できる | 要件とトレードオフを踏まえて構成理由を説明できる |
スキルアップの方向に迷ったら、自分が今どの行まで説明できるかを確認すると、次の課題が見つけやすくなります。
通信と権限を説明できると障害調査が変わる
AWSで「アプリがつながらない」とき、原因はアプリコードだけとは限りません。VPC、サブネット、ルート、Security Group、IAM、DB側の設定など、境界をまたいで確認する場面があります。
VPCは通信経路を図にできるところまで
AWSのVPCでは、サブネットがルートテーブルと関連付けられ、各ルートの宛先とターゲットによってトラフィックの行き先が決まります。
用語を覚えるだけでなく、「ブラウザからALBへ入り、アプリからRDSへ到達するまで、どの経路と制御を通るか」を説明できると、接続トラブルの切り分けに使える知識になります。
IAMは“動かすために広く付ける”から卒業する
AWSのIAMベストプラクティスでは、ワークロードで一時的な認証情報を使うこと、MFA、ルートユーザーの保護、最小権限、未使用のユーザー・ロール・権限・認証情報の見直しなどが推奨されています。
現場で価値が出るのは、ポリシーJSONを暗記することではありません。「この処理に必要な権限は何か」「このロールを広げると何ができるようになるか」を説明し、必要以上の権限を避けられることです。
IaCは「環境を作る技術」より変更管理の技術
コンソール操作だけで環境を変更すると、誰が何を変えたのか追いづらくなります。そこで効いてくるのがInfrastructure as Code（IaC）です。
AWS CloudFormationのベストプラクティスでは、テンプレートをコードとして扱い、バージョン管理、コードレビュー、自動テストを行うことが推奨されています。Change Setで更新前の差分を確認することも案内されています。
- 既存のTerraform / CloudFormationを読んで、何が作られるか追う
- 小さな変更で、差分と影響範囲をレビューする
- 反映前にplanやChange Setを確認する
- 失敗した場合のロールバックや復旧方法を確認する
ここまでできると、「IaCを学習した」ではなく「インフラ変更をレビュー可能な形で扱える」と説明できます。案件面談でも、こちらのほうが担当できる仕事を具体化しやすくなります。
リリース後を追える人はAWS経験を説明しやすい
インフラを作ったあと、アプリは実際に動き始めます。そこで必要になるのが、状態を観測して異常へ気づき、原因へ近づく力です。
Amazon CloudWatchは、AWSリソースやAWS上のアプリケーションをリアルタイムで監視し、メトリクス、アラーム、ダッシュボード、ログなどで運用状態を把握するためのサービスです。CloudWatch Alarmでは、メトリクスを監視し、条件を超えたときに通知やアクションを実行できます。
「CloudWatchを使えます」という説明を、仕事の流れへ変えてみます。
- 異常を示すメトリクスやログを確認する
- アプリ、ネットワーク、IAM、DBのどこに原因がありそうか分ける
- 仮説ごとに確認方法を決める
- 復旧後、必要ならアラームやダッシュボードを見直す
この一連を話せれば、「構築経験」だけでは見えなかった運用力まで伝わります。
CI/CDまで追うとアプリとAWSがつながる
Webエンジニアなら、インフラ専任でなくてもデプロイ経路は理解しておきたいところです。自分のPull Requestが、どこでテストされ、どの認証でAWSへ接続し、どの環境へ反映されるのか。ここが見えると、障害時の確認範囲も変わります。
AWS CodePipelineでは、ソフトウェア変更がリリースまで進む自動化ワークフローを、ステージとアクションで構成します。実際の案件ではGitHub Actionsなど別のCI/CD基盤を使うこともありますが、見るべき考え方は共通です。
| 確認する場所 | 説明できるとよいこと |
|---|---|
| Source | どのブランチ・変更を起点にするか |
| Build / Test | 何を検証し、失敗時にどこを見るか |
| Deploy | どの環境へ、どの権限で反映するか |
| Post-deploy | 疎通・ログ・メトリクスをどう確認するか |
AWSを「インフラの箱」として見るより、開発から運用までの経路として追えるほうが、アプリエンジニアにも使いやすい実務スキルになります。
設計では正解探しよりトレードオフを説明する
設計へ担当範囲を広げると、「何のAWSサービスを使うか」だけでは決められない場面が増えます。
AWS Well-Architected Frameworkは、運用上の優秀性、セキュリティ、信頼性、パフォーマンス効率、コスト最適化、持続可能性の6本の柱でアーキテクチャを評価します。設計では、これらを要件に合わせて考える必要があります。
たとえば可用性を高めれば、構成や費用が増えることがあります。運用を自動化すれば、初期の設計・実装が複雑になることもあります。Well-Architectedの考え方も、単一の“正解構成”を覚えるためではなく、判断の利点と欠点を整理するために使うと実務へつながります。
面談で「なぜこの構成にしましたか？」と聞かれたとき、サービス名ではなく「要件」「選択肢」「採用理由」「残るリスク」を話せる状態が、一段上のAWS経験です。
スキルシートはAWSの年数を書くだけでは足りない
「AWS 3年、EC2・RDS・S3・CloudWatch」。これだけでは、閲覧しただけなのか、設計や変更まで担当したのか分かりません。
伝わりにくい書き方
AWSを3年間使用。EC2、RDS、S3、CloudWatch、IAMを経験。
担当範囲が見える書き方
既存AWS環境のWeb APIを担当。Terraformの既存コードを修正し、Security Group・IAMロールの変更差分をレビュー。リリース後はCloudWatch Logsとメトリクスを使って障害切り分けまで対応。
これは説明例です。実際のスキルシートには、自分が本当に担当した内容だけを書きます。架空の成果や数字を足す必要はありません。
技術名の横に工程・変更内容・判断・運用を置くと、次の案件で何を任せられるのかが伝わりやすくなります。
資格は知識の地図として使う
AWS認定の学習は、触れていない領域を体系的に知るきっかけになります。ただし、資格を取っただけで本番変更や障害対応を任せられるとは限りません。
資格学習で得た知識は、手元の検証環境や現在の案件構成と結びつけます。「このVPCはなぜこのサブネット構成なのか」「このIAMロールはなぜ必要か」と、自分の環境へ戻して考えると知識が実務へ接続しやすくなります。
資格をゴールにせず、理解できていない領域を発見するチェックポイントとして使うのが扱いやすい方法です。
案件面談前は6つの質問に答えてみる
質問集を暗記するより、自分のAWS経験を説明できるか確かめるほうが準備になります。たとえば、次の問いに自分の案件を使って答えてみてください。
- アプリからDBまで、通信経路を説明できるか
- IAM権限を変更したとき、何を根拠に範囲を決めたか
- Terraform / CloudFormationの変更前に何を確認したか
- 障害時、CloudWatchで何を見て原因候補を絞ったか
- コードがAWSへデプロイされるまでの経路を説明できるか
- 可用性・セキュリティ・コストが競合したとき、何を優先したか
全部に答えられなくても問題ありません。空欄になった質問が、そのまま次に深める実務テーマになります。
AWS経験を5行にして次の課題を決める
フリーランスAWS案件で必要なスキルは、サービス名の暗記だけでは整理できません。ネットワークと権限を理解し、IaCで変更を管理し、監視から障害を切り分け、CI/CDの経路を追い、設計理由を説明する。こうして仕事の範囲へ変えると、自分の現在地が見えてきます。
今日やるなら、直近の案件について「構成」「変更したもの」「権限・セキュリティ」「監視・障害対応」「デプロイ」の5行を書き出してみてください。
空欄があれば、そこを次の案件までに一つ埋める。新しいAWSサービスを闇雲に増やすより、任せられる範囲を一段広げるほうが、スキルシートにも面談にもつながります。
