AWSエンジニアのフリーランス案件の仕事内容｜案件の種類別の1日・1か月の流れ

フリーランスのAWSエンジニアの仕事は、構成を決め、コードで作り、本番で安定して動くように手を入れ続けることです。ただし、新しい環境を作る案件か、既存のシステムを移す案件か、動いている環境を守り育てる案件かで、1日の時間の使い方も、話す相手も、手元に残る成果物も大きく変わります。

この記事では、AWSの案件を5つの種類に分け、それぞれの1日と1か月の流れ、関わる相手、成果物を整理します。報酬の決まり方はAWSエンジニアの報酬の記事、求められるスキルはAWSで求められるスキルの記事にまとめているので、ここでは「参画したら実際に何をしているか」に絞ります。

AWSの案件は「何を対象に、どの段階を担うか」で決まる

同じ「AWSエンジニア募集」でも、働き方を分けるのは主に次の2つです。

• 対象：これから作る環境か、オンプレミスから移す環境か、すでに動いている環境か
• 段階：構成を決める設計から入るか、決まった構成を作る構築か、運用しながら直す改善か

この2つを掛け合わせると、フリーランスのAWS案件はおおむね次の5種類に分けられます。

以下では、それぞれの流れを典型的な例として紹介します。時間の配分は案件ごとに違うため、目安として読んでください。

新規構築の案件の仕事

1日の流れ（例）

朝は、前日に出したプルリクエストへのレビューの指摘を確かめ、IaCのコードを直します。午前中はアプリの開発チームと打ち合わせをして、必要なデータベースの性能や、外部との接続の要件を聞き取ります。午後は検証環境で構成を作って動きを確かめ、実行計画（変更内容の差分）を添えてレビューに出します。夕方は、設計書の更新や、決まったことの記録に時間を使います。

1か月の流れ（例）

• 月初：今月作る範囲と、開発チームが環境を使い始める時期をすり合わせる
• 毎週：設計レビューと進捗の共有。権限や接続の申請など、発注元の手続きが要るものを早めに出す
• 月の半ば：検証環境から本番相当の環境へ広げ、性能や障害時の切り替えを試す
• 月末：作った構成を設計書とコードの両方で示し、次の範囲の計画を決める

成果物

構成図、設計書（ネットワーク・権限・バックアップ・監視の方針）、IaCのコード、パラメータの一覧、構築の手順や確認の記録などです。AWSが公開している設計の考え方であるWell-Architectedの観点で、設計の理由を説明する資料を求められることもあります。

移行の案件の仕事

調査と方式の検討の時期

移行の案件は、最初の数週間が調査です。既存のサーバーの構成、使っているミドルウェア、ほかのシステムとのつながり、夜間の処理の流れを、資料と聞き取りで洗い出します。そのうえで、そのまま移すのか、マネージドなサービスに置き換えるのかを、システムごとに案として示します。

リハーサルと切り替えの時期

方式が決まった後は、移行の手順を作り、リハーサルを繰り返します。データの移し替えにかかる時間を測り、切り替えの当日の作業表と、元に戻す判断の基準を決めます。本番の切り替えは業務を止めにくい夜間や休日になることが多く、この時期は稼働の時間帯が通常と変わります。

成果物

現状調査の結果、移行方式の比較、移行計画とスケジュール、手順書、リハーサルの記録、切り戻しの基準、切り替え後の確認表などです。移行の案件では、作業そのものより「どう移すかを決めた理由」を説明する資料の重みが増します。

運用・改善の案件の仕事

1日・1か月の流れ（例）

朝は、夜間のアラートや処理の結果を確かめ、対応が要るものを振り分けます。日中は、開発チームからの環境の変更依頼に応えたり、うるさすぎるアラートや見落としの多い監視を直したりします。月の単位では、費用の推移を見て無駄な資源を減らす案を出したり、障害の振り返りを書いて再発を防ぐ仕組みを入れたりします。

運用の案件では、障害が起きたときの連絡体制に入るかどうかで働き方が大きく変わります。夜間や休日の待機がある場合の扱いは待機の報酬の記事で解説しています。信頼性の目標を決めて運用を組み立てる働き方に近づくと、SREの仕事内容と重なる部分が増えます。

成果物

運用手順書、監視とアラートの設定、障害の報告書と振り返り、費用の分析と削減の提案、定期的な更新作業の記録などです。

基盤整備・統制の案件の仕事

1日・1か月の流れ（例）

複数の事業やチームがAWSを使う会社で、アカウントの分け方、権限の付け方、ログの集め方、守るべき設定のルールを整える案件です。1日の多くは、情報システム部門やセキュリティ担当との打ち合わせ、各チームからの例外の相談への対応、ルールを自動で確かめる仕組みづくりに使います。1か月の単位では、ルールを適用するアカウントを段階的に広げ、適用後に困ったことを各チームから集めて直します。

成果物

アカウントの構成と命名のルール、権限の設計、ログと監査の仕組み、ガードレール（守るべき設定を自動で止めたり知らせたりする仕組み）の定義、各チーム向けの利用ガイドなどです。技術よりも、各チームに納得して使ってもらう説明に時間がかかるのが特徴です。

開発チーム内のインフラ担当の仕事

自社サービスを作るチームに入り、アプリのエンジニアと並んでインフラを受け持つ案件です。コンテナの実行環境、デプロイの自動化（CI/CD）、検証環境の用意などを整え、開発者が自分でリリースできる状態を目指します。

1日の中では、チャットで届く「環境が動かない」「このサービスを使いたい」といった相談への対応が多くなります。スプリントのような短い周期で計画と振り返りに参加し、インフラの作業もチームの計画に載せて進めます。成果物は、コンテナの定義、パイプラインの設定、開発者向けの手順、インフラの変更の記録などです。

どの案件にも共通する仕事

種類が違っても、次の仕事はほぼすべてのAWS案件にあります。

1. 変更をレビューに出す：本番に入れる前に、コードと実行計画を見せて合意を取る
2. 権限と手続きを先に動かす：アカウントや接続の申請は時間がかかるため、作業の前に出しておく
3. 記録を残す：なぜその構成にしたかを、設計書やチケットに残す
4. 費用を意識する：作った資源の費用が後から問題にならないよう、見積もりや削除の予定を伝える

フリーランスならではの仕事として、自分の稼働の記録と報告もあります。切り替えや障害の対応で稼働が延びた月は、精算の条件と照らし合わせて早めに伝えます。

関わる相手と、その相手に出すもの

働く場所については、IaCでの構築や設計の見直しはリモートで進めやすい一方、閉じたネットワークからしか入れない環境や、切り替えの当日には出社を求められることがあります。詳しくはAWSのリモート案件の記事をご覧ください。

よくある質問

AWSの案件では、自分で手を動かして構築することが多いですか？

多くの案件で、設計だけでなくIaCのコードを書いて構築するところまで担います。基盤整備や移行の上流では、資料づくりや調整の割合が高くなり、手を動かす時間が減ることもあります。どこまで自分で作る想定かは、参画前に確かめておきましょう。

運用の案件は夜間や休日の対応がありますか？

障害の連絡体制に入る案件では、夜間や休日の連絡や対応が求められることがあります。体制に入らず日中の改善だけを担う案件もあるため、待機の有無と、そのときの精算の扱いを契約前に確かめることが大切です。

参画して最初の1か月は何をすることが多いですか？

アカウントと権限の受け取り、構成図とIaCのコードの読み込み、変更の手順と会議体の確認から始めるのが一般的です。初月の進め方はAWSエンジニアの参画初月にやることで詳しく解説します。