Amazon EKSのシステム開発は、業務課題と責任範囲を整理し、PoCでEKSの適性を確かめてから本番を発注する流れで進めます。
そのうえで、RFPと契約条件を固めて委託先へ依頼すると、運用まで見通した構築につながります。
▼全体ガイドの記事
・Amazon EKSのシステム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
Amazon EKSの発注前に決めること
発注の前に、EKSで何を作るかだけでなく、どの業務で使うか、どの水準で動かすか、障害時とコストの判断を誰が持つかも決めておきます。条件がそろっていると、会社ごとの見積もりを比べやすくなります。
対象となるのは、AmazonのECサイトではなく、AWSのAmazon Elastic Kubernetes Serviceを使うシステム開発です。
EKSで解決する業務課題の絞り込み
「EKSの構築をお願いします」とだけ伝えると、委託先は必要なサービス数や運用体制を判断できません。まず、導入で変えたい業務を具体的に示します。
- 独立リリース：複数のマイクロサービスを別々にリリースする
- ピーク対応：繁忙時だけ処理能力を増やす
- 既存資産の移行：Kubernetes資産をAWSへ移す
成果指標には、リリース頻度と障害からの復旧時間を使います。ピーク時の応答時間や運用担当者の作業時間も、あわせて評価に使うと、導入効果を判断しやすくなります。
発注条件に入れるEKS・ECS・Lambdaの比較
高度なスケジューリングや多数のマイクロサービスが必要な場合は、EKSが候補になります。さらに、Kubernetes標準のマニフェストやGPU、既存クラスターの活用が必要な場合にも、EKSが候補に入ります。
単一のWeb APIや小規模なバッチを少人数で運用する場合は、ECSやLambdaのほうが、学習対象と障害箇所を減らせる可能性があります。
RFPには、EKS案に加えてECSやLambda案も入れ、費用、運用負荷、将来の拡張性を比べられるようにします。こうして比べると、技術ありきの発注を防げます。
AWS・委託先・自社の責任境界
AWSはEKSのコントロールプレーンを管理します。一方で、アプリの可用性、コンテナイメージ、データは発注者側に残ります。
- 発注者側の範囲：VPC設定、IAM、監視、バックアップ、運用判断
- EKS Auto Mode：ノード、ロードバランサー、ストレージなどの管理範囲が広がっても、アプリとデータの責任は変わりません
- 委託先の範囲：構築に加えて、バージョンアップや脆弱性対応、夜間障害やAWSへの問い合わせ、運用教育まで含むか
Amazon EKSの発注形態の選び方
発注形態は、要件がどこまで確定しているか、自社に技術者がいるか、業務側が参加できる時間があるか、既存システムがどれほど複雑かで選びます。
全工程を一括で委託する方法もあります。一方で、PoCから運用まで工程を分けると、要件定義や本番構築、移行の区切りごとに判断しながら投資を進めやすくなります。
どの方式でも、自社が決めることと委託先が実行することを、表にまとめておきます。
企画から運用までの一括外注
一括外注は、社内にAWSやKubernetesの経験者が少なく、業務整理から運用設計まで任せたい場合に向きます。
- 統括範囲：一社が要件定義から教育までを統括し、会社間の責任分界を減らす
- 移行時の体制：既存VMやオンプレミスの移行では、全体PMが課題を追いやすくする
統括工程には、要件定義、VPCとIAM、EKSが入ります。アプリやCI/CD、監視も含まれ、テストや移行、教育まで一社で担います。
発注者が業務の判断まで委託すると、現場が使わない機能や、データ品質を無視した構成が残るおそれがあります。
発注者側には、業務責任者、データ管理者、セキュリティ判断者を置きます。そのうえで、週次で優先順位と未決事項、追加費用の見込みを確認します。
PoCと本番を分ける段階発注
EKSの採用可否や性能が不明なら、代表サービスを一つ選んでPoCを発注し、その結果を見て本番構築へ進みます。
- 代表サービスをコンテナ化し、デプロイ手順を作る
- 負荷測定、ログとアラート、権限分離を検証する
- 障害復旧、月額AWS利用料、残課題を確認する
- 本番化の再見積条件を決める
合格条件は、クラスターを作れたことではなく、本番で必要な品質を測れることに置きます。そうすれば、識別子の不一致やデータ移行の難しさを早期に見つけられます。想定外の通信量や運用負担も、PoCの段階で見えてきます。
段階発注は、初期費用を抑えるだけでなく、本番の手戻りを減らすリスク管理にもなります。また、PoCが不合格ならECSなどへ切り替える条件も、契約書や発注書に記載します。
基盤・アプリ・運用を分けるハイブリッド発注
複数社に分ける発注は、専門性を集めやすい一方、会社間の調整が必要です。
- 会社の分担：AWS基盤はクラウド専門会社、アプリは業務システム会社が担当する
- 運用の分担：監視やヘルプデスクは運用会社が担う
- 障害時の注意：EKSとアプリの境界では原因調査の責任が曖昧になりやすい
複数社に発注する場合は、共通設計書を用意します。そこには、全体アーキテクチャやAPI仕様、環境構成を書きます。さらに、監視項目や受け入れテスト、一次窓口も記載します。
発注者が全体PMを担えない場合は、一社を統括会社にし、他社との調整も契約に含めます。価格だけで分けると、会議や障害の切り分け、仕様調整、責任確認が増えます。その結果、一括で発注するより高くなることもあります。
Amazon EKSのRFPと要件整理の内容
RFPは機能の一覧ではなく、各社を同じ条件で比べるための文書です。業務課題、利用者、既存資産を整理し、性能やセキュリティ、運用の条件を添えます。納品物と予算条件も、そろえて示します。
必須要件と希望要件、対象外、発注者が提供する情報は、分けて書きます。未確定の事項は空欄にせず、各社に仮定と追加費用を明示してもらいます。
業務フローと利用者の具体化
業務フローと利用者は、役割、業務条件、データ管理に分けて整理します。
- 利用者：開発者、業務担当者、運用担当者、セキュリティ担当者、管理者
- 利用者ごとの役割：見る情報、操作、判断を整理する
- 業務条件：きっかけ、処理、完了条件、例外時の対応
- データ管理：業務ルールや正解データは発注者が持つ
要件は、「月末の請求処理を止めず、失敗時は30分以内に担当者へ通知する」のように具体的に書きます。「安定稼働」のような抽象的な表現は避けます。
マスタの所有部署と更新頻度、削除や訂正の承認者を整理します。個人情報の利用目的も、あわせてまとめます。さらに、データ移行の照合方法もRFPに含めておけば、データの認識違いを減らせます。
アプリ・ネットワーク・データの前提
見積条件をそろえるため、既存環境、利用量、EKS構成の前提を提示します。
- 既存環境：アプリ、依存関係、ソース、実行環境、DB、外部API、コンテナ化の可否
- 利用量：ピーク時のアクセス数と1日あたりの処理量
- EKS構成：VPC、複数AZ、プライベートサブネット、Ingress、ECR、EBS・EFS・RDS
構成のどこまでを開発費に含めるかは、先に明確にします。性能要件は、レイテンシーや同時利用者数、エラー率で表します。デプロイ時間やRTO、RPO、ログ保存期間も、性能要件の一部として書きます。
監視は、CPU使用率だけでなく、Podの再起動やノード不足まで定義します。デプロイの失敗や主要業務の成功率も、監視の対象に含めます。定義がないままだと、性能試験や運用設計が別料金になる可能性があります。
権限・セキュリティ・法令対応の要件
権限、データ、運用の観点から、セキュリティと法令対応を要件に落とし込みます。
- 権限・保護：IAM最小権限、EKSアクセスエントリ、Pod Identity、KMS暗号化、イメージスキャン、監査ログ、脆弱性対応
- データ・法令：バックアップ、秘密情報、個人情報の保存地域、委託先管理、監査証跡、漏えい連絡体制
- 運用条件：権限申請の承認者、ログ確認者、脆弱性対応期限
自社サービスの法令対応は、AWSの機能に加えて自社でも整理します。特に、個人情報などは自社のデータ分類と結び付けます。
納品直前の確認では、設計変更や追加費用が生じやすいため、要件を運用手順と受け入れテストに含めます。また、脆弱性対応の期限は、何営業日以内かを明記します。
Amazon EKSの開発で選ぶ契約形態
契約形態は、要件が固まっているか、成果物を検収できるか、仕様変更が多いかで選びます。
EKS構築費を一つの金額にまとめると、未確定の非機能要件や移行条件が追加請求につながりやすくなります。一方で、要件定義とPoC、本番構築、保守を分けて契約する方法もあります。
請負契約の成果物と検収条件
請負契約では、成果物の完成と検収を重視します。クラスターの構築完了だけを理由に検収しないよう、条件を細かく決めておきます。
- 成果物：設計書、TerraformやCDKなどのIaC、Kubernetesマニフェスト
- 運用資料：CI/CD、監視設定、テスト結果、Runbook、復元手順、教育資料
- 検収：負荷試験、障害復旧、権限レビュー、ロールバックの実演
要件変更が多い案件で請負範囲を広げると、変更のたびに調整が必要になります。そのため、未確定事項や変更手順を契約書に書いておきます。
追加費用の単価や納期への影響、発注者側の遅延があった場合の扱いも、あわせて明記します。
準委任契約の体制と作業範囲
準委任契約は専門家の業務遂行を重視し、作業量や成果の形が変わりやすい工程に向きます。
- 対象工程：要件整理、アーキテクチャ検討、移行計画、運用改善、内製化支援
- 体制管理：稼働日数、役割、会議体、報告、対応時間、作業記録を確認する
- 成果の合意：レビュー記録、課題、決定事項、構成案、PoC結果、次工程の見積条件
何の作業に時間を使ったかを管理します。知識を残す場合は、ペア作業やレビュー参加も契約範囲に含めます。
保守運用契約のDay 2対応水準
保守運用契約では、対応範囲とサービス水準を定め、Auto Modeの管理範囲を踏まえて役割を分けます。
- 定常作業：EKS・Kubernetes、ノード、イメージの更新、脆弱性対応、監視
- 運用報告：障害一次対応、AWS利用料の確認、月次レポート、再発防止
- 時間と水準：24時間365日監視の有無、通知時間帯、一次切り分け、復旧目標
Auto Modeはノードのパッチやライフサイクル管理を広げますが、アプリの可用性や監視設計までは自動化しません。
24時間365日の監視を付ける場合は、エスカレーションや報告書、再発防止の範囲も確認します。
平日日中の問い合わせで足りるシステムには、過剰な契約を付けないことがTCOを抑える判断になります。
Amazon EKSのシステム開発費用とAWS利用料の相場
費用は、開発会社への初期費用、AWS月額利用料、稼働後の保守費用に分けて考えます。クラスター構築費だけでは、ネットワークやノード、ストレージの差が見えません。さらに、ロードバランサーやログ、転送量、運用設計の差も、その金額からは読み取れません。
ここで示す開発費は、EKSの公式な定価ではありません。リサーチノートとクラウド基盤案件の構成要素から算出した目安です。
開発・PoC・移行の費用レンジ
費用と期間は、案件条件によって変わる推定のレンジです。固定価格を断定するものではありません。
- 学習・PoC：100万〜300万円、1〜2か月。単一サービスの環境を想定
- 標準的な本番基盤：500万〜1,500万円、3〜6か月。2〜3AZなどを含む
- 既存システム移行：1,500万〜5,000万円、6〜12か月。複数サービスなどが影響
- 大規模構成：5,000万円〜1.5億円以上、12〜24か月となる可能性
PoCでは、コンテナ化と開発用クラスター、最低限のCI/CDを整えたうえで、負荷や障害復旧を検証します。ただし、本番SLAや大規模な監視は含みません。
本番基盤では、IAMやECR、ロードバランサーなどを見積もります。ノードやログ、メトリクス、バックアップ、デプロイ手順も、見積もりの対象です。
移行では、データ同期や段階リリース、性能試験が費用に影響します。障害訓練や運用引き継ぎも、費用に影響します。
大規模構成の例は、金融や医療級の統制が必要な案件、マルチアカウントやマルチリージョンの構成、数十サービス以上の規模です。
クラスター以外も加算されるAWS利用料
AWS利用料は、クラスターのサポート水準やクラスター以外のリソースにも左右されます。
- 標準サポート：1クラスター時間0.10米ドル。月730時間で約73米ドル
- 円換算例：1米ドル150円なら約1万1,000円。コントロールプレーンのみ
- 拡張サポート：1クラスター時間0.60米ドル。730時間で約438米ドルの例
- Auto Mode例：EC2費用1,046.82米ドルと管理費125.62米ドルで、合計約1,172米ドル
EC2またはFargateが別途かかるほか、EBSやNAT Gatewayも発生します。また、ロードバランサーやパブリックIPv4、データ転送、CloudWatchも別途発生します（出典: AWS公式「Amazon EKSの料金」、2026年確認）。
実額は、リージョンやインスタンスタイプ、稼働時間で変わります。通信量やログ量によっても変わります。そのため、AWS料金と開発会社費用は分けて見積もります（出典: AWS公式「Amazon EKSの料金」、2026年確認）。
保守費とTCOを含む予算
TCOを予算に組むときは、保守範囲と公開事例を、自社の条件と分けて考えます。
- 保守費：開発費の10〜20％程度で仮置きできるが、含める業務で変わる
- 予算内訳：開発、AWS、保守、追加改修、社内教育を分け、1年目と2年目以降を比較
- 事例の扱い：MiroやAdaの成果は規模や移行前の方式が異なり、そのまま当てはめない
保守の対象には、24時間365日監視やアプリ改修、バージョンアップがあります。脆弱性対応や障害訓練、AWSのコスト最適化なども対象になります。
Miro事例では、コンピュート費の80％削減と、開発者の保守負荷の60〜70％削減が報告されています。Ada事例では、コンピュートコストを15％削減し、アップグレード期間を最大5か月から5日に短縮した実績があります（出典: AWS公式Miro・Ada導入事例、2024年公開）。
自社で同じ数値が出るとは限らないため、PoCで現状との差を測って確かめます（出典: AWS公式Miro・Ada導入事例、2024年公開）。
Amazon EKSの委託先選定と見積比較のポイント
委託先には、EKSの構築経験に加えて、アプリのコンテナ化やAWSネットワーク、IAMの扱いも確認します。Kubernetesの更新や可観測性、セキュリティの経験も選定の材料です。FinOpsや運用引き継ぎの経験も、見ておくと役立ちます。
委託先は、AWS認定の有無や会社規模だけでなく、事例の近さで比べます。自社に近いサービス数やデータ量、規制、運用時間帯の事例を、見せてもらいます。
公開できない事例でも、課題や担当範囲、成果物を説明できる会社は比較しやすくなります。体制や運用期間まで説明できるかも、比べる際の観点になります。
委託先へのDay 2運用の質問
Day 2運用の担当範囲を見極めるため、候補会社に次の点を質問します。
- 更新：EKSの更新担当者と頻度
- 障害：ノードとアプリの切り分け方法
- 脆弱性：コンテナを何時間以内に更新するか
- 夜間対応：通知を受ける担当者
- 引き継ぎ：IaCとRunbookの渡し方
Auto Modeを提案された場合は、AWSの管理範囲とアプリ側の責任を説明してもらいます。ノードへの直接アクセス制限や、追加の管理費も、あわせて確認します。
2026年は、EKS Auto Modeの自動化やEKS Capabilities、Provisioned Control Planeなど、選べる機能が増えています。
Provisioned Control Planeでは、AWSが2026年3月に99.99％のSLAと8XL階層を発表しました。大規模AIやHPC向けの選択肢も広がっていますが、必要な規模でなければ、費用と設計の複雑さが増します。
新機能を使う理由と使わない理由の両方を提案できる会社を選びます（出典: AWS公式「Amazon EKS announces 99.99% Service Level Agreement and new 8XL scaling tier」、2026年3月）。
工程・成果物・除外項目を横並びにした見積書の比較
見積書は、総額だけでなく工程と成果物を並べて比べます。除外項目や各社の前提も、そろえて確認します。
- 工程：要件定義、基本・詳細設計、基盤、アプリ、移行、テスト、教育、運用開始
- 工程ごとの条件：人数、期間、成果物、検収、前提、対象外作業を確認する
- 別料金：試験、診断、復元、AWS設定、監視、夜間対応、更新、追加環境を確認する
- 比較条件：同じRFP、サービス数、データ量、RTO、RPOを各社に渡す
- 価格差：安い会社には対象外とリスク、高い会社には必要・省略可能な作業を聞く
見積の透明性や変更ルールに加えて、担当者の経験や納品後の支援も評価します。これらを比べておくと、発注後の追加費用を抑えやすくなります。
納品物と内製化支援の選定基準
納品物には、再現できる構成資料と運用手順を含めます。権利や管理情報も、あわせて渡してもらいます。
- 構成資料：アーキテクチャ図、構成パラメーター、IaC、マニフェスト
- 実行・権限：CI/CD、IAM、監視定義、アラート判断基準、テスト結果
- 運用手順：復元、障害対応Runbook、費用確認、アップグレード計画
- 契約前の確認：リポジトリ所有権、AWS管理者、秘密情報の保管、ライセンス
管理画面での手作業だけに頼ると、担当者が交代したあとに再現できなくなります。内製化を目指す場合は、自社の担当者も設計レビューやペア作業、障害訓練に加わります。
アップグレードの実演にも加わります。引き継ぎ期間と問い合わせ窓口、保守終了後の対応、追加改修単価を、事前に明らかにしておきます。こうしておくと、特定の担当者や会社への依存を減らせます。
よくある質問（FAQ）
発注の前によく出る疑問は、費用の分け方、責任範囲、運用の引き継ぎに関するものです。
Amazon EKSのシステム開発費用はいくらですか？
PoCは100万〜300万円、標準的な本番基盤は500万〜1,500万円です。既存システムのコンテナ化と移行は1,500万〜5,000万円が目安です。
金額は、要件やサービス数、データ移行によって変わります。SLAや監視、セキュリティ、運用時間も影響します。ここでの金額は推定のレンジで、AWS利用料と開発会社費用は分けて見積もります。
EKS Auto Modeを使えば運用担当者は不要ですか？
いいえ、運用担当者は不要になりません。Auto Modeは、ノードやロードバランサー、ストレージ、ネットワークなどの管理範囲を広げられます。
アプリやコンテナ、データは、利用者側に残ります。VPC設定やアクセス権限、監視、障害時の業務判断も、利用者側の担当です。
発注時には、AWSが担う範囲と、委託先または自社が担うDay 2運用を分けて確認します。
請負契約と準委任契約はどちらがよいですか？
成果物と検収条件を固めやすい本番構築は、請負契約が候補になります。一方で、要件整理やPoC、運用改善など作業内容が変わりやすい工程は、準委任契約が候補です。
どちらの契約でも、成果物と作業範囲、変更管理を明記します。納期や検収、追加費用、責任分界も、あわせて書いておきます。
要件定義は準委任、確定した本番構築は請負、と分ける組み合わせもあります。
Amazon EKSの委託先は何社に相談すべきですか？
同じRFPで2〜4社程度に相談します。価格だけでなく、質問の質やEKS以外の案も比べます。運用と引き継ぎの説明、見積の透明性も確認します。
候補が多い場合は、公開事例、AWSやKubernetesの専門性、対応可能な運用時間帯で絞り込みます。最終候補には、詳細見積とPoC計画を依頼します。
Amazon EKSのシステム発注・外注・委託方法まとめ
発注では、EKSで解決したい業務課題と、ECSやLambdaではなくEKSを選ぶ理由を整理します。次に、PoCや本番構築、移行、保守のどこまでを委託するかを決めます。
RFPには、業務フローやサービス数、データを記載します。さらに、性能や権限、セキュリティ、RTOとRPOを書き、運用時間帯と納品物も加えます。
構築後の運用まで比べる発注先の選定
委託先には、EKSの構築経験に加えて、構築後の運用まで確かめます。更新や監視、障害対応、コスト最適化の経験に加え、セキュリティやデータ移行、内製化支援の実績も見ます。
見積書は、工程や成果物、対象外作業を比べます。AWS利用料や保守費、変更単価も並べ、価格の理由を質問します。
高機能な構成よりも、現場が運用でき、事業のKPIを改善できる構成を優先します。
小さなPoCと明確な成功条件
PoCでは成功条件を定め、その結果を本番の見積条件と運用設計に反映します。
- 測定：代表サービスでデプロイ、スケール、ログ、権限、障害復旧、費用を確認する
- 発注者の体制：業務責任者と運用責任者を置く
- 目標：安定稼働、開発速度、復旧時間、総保有コストにつなげる
▼全体ガイドの記事
・Amazon EKSのシステム開発の完全ガイド
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。