AWSを使ったWebシステム案件で、アプリ開発会社とインフラ担当の範囲をどう分けるか
- 2 日前
- 読了時間: 12分
AWSを使ったWebシステムでは、「アプリは開発会社、AWSはインフラ担当」と分けるだけでは、責任分界として十分ではありません。
重要なのは、デプロイ、IAM・シークレット、DB、ログ・監視、障害対応など、アプリとインフラが接する部分を誰がどこまで担当するかを具体化することです。
はじめに：AWSの「責任共有モデル」だけでは、プロジェクト内の分担は決まらない
AWSには「責任共有モデル」があります。
AWSはクラウド基盤そのもののセキュリティを担当し、利用者側は使用するAWSサービスに応じて、OSやアプリケーション、各種設定などのセキュリティを担います。
AWS公式：責任共有
ただし、この責任共有モデルが整理しているのは、基本的にAWSとAWS利用者の間の責任です。
実際のWebシステム開発では、その利用者側がさらに、
元請け
アプリ開発会社
インフラ担当
運用担当
顧客側の情報システム部門
などに分かれます。
そのため、「AWS側はインフラ担当」とだけ決めても、プロジェクト内の責任分界は決まりません。
バックエンド開発全般の責任分界については、誰が決めるのか、誰が作るのか、誰が確認するのか、本番で誰が動くのかという観点から整理した「バックエンド開発を外注するとき、責任分界はどう決めるべきか」で詳しく解説しています。
この記事ではその一般的な整理を繰り返さず、AWS案件で特に曖昧になりやすい、アプリとインフラの接続点に絞ります。
結論：AWSサービス名ではなく、アプリとインフラの「接続点」で分ける
AWS案件の責任分界は、「EC2はインフラ担当」「RDSはインフラ担当」のように、AWSサービスの名前だけで分けない方が実務的です。
たとえばRDSをインフラ担当が構築するとしても、
アプリからどのように接続するのか
接続情報をどう渡すのか
DBユーザーや権限を誰が決めるのか
スキーマ変更を誰が実行するのか
リリース時にDB変更とアプリ配備をどう同期させるのか
障害時にアプリとDBのどちらから調べるのか
といった部分では、アプリ担当との調整が必要です。
つまり、重要なのは「RDSは誰の担当か」ではありません。
アプリとRDSの間で何を受け渡し、誰がどこまで責任を持つかです。
筆者が携わったカーシェア案件、駐車場案件、ウェビナー案件でも、アプリ担当とインフラ担当は分かれていました。
筆者自身はアプリケーション開発を主軸としつつAWSインフラ側も扱えます。また、ウェビナー案件では外部CTOの立場でアプリ・インフラ双方に関与し、両者の要求や制約を踏まえて構成や実装方針をすり合わせていました。
このような案件では、アプリ側の要求をインフラ側が実行できる形へ具体化することが重要です。
たとえば、
この通信経路が必要
この設定値を安全にアプリへ渡したい
このタイミングでDB変更を行いたい
障害調査のため、このログを取得したい
といったアプリ側の事情を、AWS側の設定・権限・運用へ落とし込んで調整します。
アプリとインフラが別担当だから問題になるのではありません。問題になりやすいのは、両者の接続点を誰も明示的に整理していない状態です。
AWS案件で特に曖昧になりやすい5つの接続点
1．アプリの実行環境とデプロイ
最初に整理したいのが、アプリケーションをAWS上でどのように動かし、誰がデプロイするかです。
インフラ担当がECS、EC2、Lambdaなどの実行環境を用意しても、そこへアプリを配置する工程ではアプリ担当との接続が生まれます。
たとえば事前に、
実行環境を誰が作るか
ビルド成果物をどの形式で渡すか
CI/CDを誰が構築するか
デプロイを誰が実行するか
環境変数をどこで設定するか
ロールバックを誰が判断・実行するか
を決めます。
「インフラ担当が環境を作り、アプリ担当がソースコードを納品する」だけでは、本番リリースまでつながらないことがあります。
アプリ成果物をAWS上で動かすまでの受け渡しを一つの接続点として扱うことが重要です。
2．IAM・シークレット・環境設定
IAMやSecrets ManagerはAWS側の設定に見えますが、必要な権限やシークレットの中身を決めるには、アプリケーションの仕様を理解する必要があります。
たとえばアプリが、
S3からファイルを取得する
SQSへメッセージを送る
Secrets ManagerからDB認証情報を取得する
外部API用の認証情報を利用する
のであれば、それに必要な権限やシークレットをAWS側へ設定する必要があります。
AWS Secrets Managerは、DB認証情報やAPIキーなどを管理・取得・ローテーションするためのサービスです。
AWS公式：AWS Secrets Managerとは?
ここで、
「IAMはインフラ担当」
「Secrets Managerもインフラ担当」
とだけ決めてしまうと不十分です。
アプリ担当から、
どのAWSリソースへ
どの操作が必要で
どのシークレットを
どのタイミングで取得するのか
を渡し、それを基にインフラ担当が権限や設定へ落とす、という受け渡しまで決める必要があります。
3．DBインフラとDBスキーマ変更
DBも代表的な接続点です。
RDSやAuroraのインスタンス、ネットワーク、バックアップ、パラメータなどはインフラ担当が管理し、テーブルやインデックスなどアプリケーションに近い領域はアプリ担当が管理する、という分担は考えやすいでしょう。
しかし、実際のリリースでは両者が連動します。
たとえば、
DBスキーマを変更する
新しいアプリをデプロイする
動作確認をする
という手順であれば、DB変更の実行者、タイミング、失敗時の戻し方を事前に決めておく必要があります。
特に本番DBへの直接操作をアプリ開発会社へ許可しない案件では、アプリ側が変更内容を準備し、インフラ側または運用側が実行するといった分担もあります。
重要なのは、DBをどちらの領域に分類するかではなく、アプリ変更とDB変更の境目をどう渡すかです。
4．ログ・監視・アラート
AWS側でCloudWatchを用意していても、どのログを出せば障害を判断できるかはアプリ担当でなければ分からないことがあります。
反対に、アプリがログを出していても、
どこへ集約するか
どの程度保持するか
何を監視対象にするか
どの条件でアラートを出すか
誰へ通知するか
が決まっていなければ、運用で使える監視にはなりません。
AWS Well-Architected Frameworkでも、アプリケーションの状態を把握するため、メトリクス、ログ、トレースなどのテレメトリを実装することが推奨されています。
AWS公式：アプリケーションテレメトリを実装する
ここでは、
「アプリ担当が必要な観測情報を定義し、インフラ担当が収集・監視できる仕組みへつなぐ」
という接続点を意識すると整理しやすくなります。
5．障害時の一次切り分け
開発中は分担できていても、障害が発生すると境界が曖昧になるケースがあります。
「画面が開かない」という一つの現象でも、原因は、
アプリケーションの不具合
DB接続
IAM権限
ネットワーク
CPUやメモリなどのリソース
外部API
AWSサービス側
など複数考えられます。
このとき、「アプリ担当はアプリしか見ない」「インフラ担当はAWSしか見ない」という分担では、原因が境界にある場合に調査が止まりやすくなります。
AWS Well-Architected Frameworkでも、責任やオーナーシップを明確にし、責任の所在が不明な場合に解決する仕組みを持つことが重要とされています。
AWS公式：責任と所有権を管理するためのメカニズムが存在する
障害対応では少なくとも、
最初に誰が問い合わせを受けるか
どこまで一次調査するか
どの条件でアプリ担当へ渡すか
どの条件でインフラ担当へ渡すか
調査に必要なログや権限を誰が持つか
を決めておくと、責任の押し付け合いを防ぎやすくなります。
具体例：「Secrets Managerはインフラ担当」だけでは足りない
責任分界が曖昧になりやすい例として、アプリからSecrets Managerを利用するケースを考えます。
曖昧な切り方
アプリ開発会社：アプリを作る
インフラ担当：Secrets Managerを設定する
これだけでは、実装時に確認事項が残ります。
たとえば、
シークレット名は何か
どの値を保存するのか
JSONのキー構造をどうするか
アプリはどのIAMロールで取得するのか
本番・ステージングで名前をどう分けるのか
値を誰が登録するのか
ローテーション時にアプリ側の変更が必要か
などです。
接続点を整理した切り方
たとえば次のように整理できます。
アプリ担当
アプリから必要となるシークレットの内容を定義する
シークレット取得処理を実装する
必要なIAMアクションをインフラ担当へ提示する
インフラ担当
Secrets Managerのリソースを作成する
IAMポリシー・ロールを設定する
環境ごとのシークレットを配置する
事前に共同で決める
シークレット名
データ構造
環境ごとの管理方法
登録・変更の運用
障害時の確認方法
このようにすると、「Secrets Managerはインフラ」というサービス単位の分担から、アプリとインフラの間で何を渡すのかまで具体化できます。
責任分界表は「接続点」を中心に作る
AWS案件で責任分界表を作る場合、AWSサービスを並べるだけではなく、アプリとインフラの受け渡しが見える形にすると実用的です。
項目 | 誰から誰へ何を渡すか | 事前に決めること |
AWSアカウント・ネットワーク | インフラ担当からアプリ担当へ、利用可能な環境・接続条件を共有 | アカウント、VPC、サブネット、通信制約、本番権限 |
アプリ実行環境 | アプリ担当からインフラ担当へ、必要なランタイム・リソース・通信要件を提示 | 実行方式、バージョン、CPU・メモリ、スケーリング |
ビルド・デプロイ | アプリ担当からインフラ担当へ、ビルド成果物や配備条件を渡す | CI/CD、実行者、デプロイ手順、ロールバック |
IAM・シークレット | アプリ担当からインフラ担当へ、必要な権限・設定値・シークレット要件を渡す | IAMロール、権限範囲、Secrets Manager、環境変数 |
DB | アプリ担当からインフラ担当へ、接続・スキーマ変更・性能要件を渡す | 接続情報、権限、スキーマ変更、実行タイミング |
ログ・監視 | アプリ担当からインフラ担当へ、必要なログ・メトリクス・監視条件を渡す | 出力内容、保存、アラート条件、通知先 |
障害対応 | 一次対応側から各担当へ、現象・ログ・切り分け結果を渡す | 一次窓口、切り分け範囲、エスカレーション条件 |
リリース後運用 | 開発側から運用側へ、運用手順・設定・注意点を引き継ぐ | 設定変更、デプロイ、監視、障害対応、保守範囲 |
この表を作ると、アプリ担当からインフラ担当へ何を渡さなければならないか、逆にインフラ側から何を受け取らなければアプリ開発を進められないかが見えやすくなります。
なお、責任分界を提案書、成果物、対象外範囲、検収条件などへ落とし込む方法については、次の記事で詳しく整理しています。
「開発時」と「リリース後」は分けて確認する
責任分界は、開発中だけ決めればよいわけではありません。
たとえば開発中は、
アプリ開発会社がログを確認する
インフラ担当へ自由に設定変更を依頼できる
という体制でも、リリース後は運用ルールが変わることがあります。
本番では、
AWSコンソールへのアクセス権限を限定する
設定変更を申請制にする
障害の一次窓口を別チームにする
アプリ開発会社は調査依頼を受けてから対応する
といった運用になることもあります。
そのため、責任分界表では、
開発時に誰が行うか
と
リリース後に誰が行うか
を分けて確認した方が安全です。
特に障害対応、デプロイ、DB変更、IAM変更は、開発時と本番運用時で担当が変わりやすい部分です。
分担を細かく決めすぎなくてもよいケースもある
すべてのAWS案件で、詳細な責任分界表を作る必要があるわけではありません。
たとえば、
小規模なPoC
アプリとインフラを同じ会社・同じチームが担当する
社内に標準化されたAWS基盤と運用ルールがある
といった場合は、分担を簡略化できることがあります。
一方で、
アプリとインフラが別担当
本番AWSを顧客側や元請け側が管理する
複数の開発会社が関与する
外部ベンダーへ本番操作権限を付与しない
リリース後の運用担当が開発担当と異なる
という案件では、接続点の整理が重要になります。
筆者が経験したカーシェア案件、駐車場案件、ウェビナー案件のように専門領域ごとに担当が分かれる構成でも、分担そのものが問題なのではありません。
むしろ、それぞれの専門性を活かしつつ、境界をまたぐ要求を誰が整理するかが重要です。
発注前に確認しておきたいAWS固有の項目
AWSを使うWebシステムでアプリ開発部分を外注する場合は、少なくとも次の項目を確認しておくと責任分界を整理しやすくなります。
AWSアカウントは誰が管理するか
本番環境へのアクセス権限を誰に付与するか
VPCやセキュリティグループなどのネットワーク設定は誰が行うか
アプリの実行環境は誰が構築するか
CI/CDやデプロイは誰が構築・実行するか
IAMロールやポリシーに必要な権限を誰が整理するか
シークレットや環境変数をどこで管理するか
DBの構築とスキーマ変更をそれぞれ誰が行うか
アプリログは何を出力し、どこで確認するか
監視・アラートは誰が設計し、誰へ通知するか
障害時の一次切り分けを誰が行うか
リリース後の設定変更・運用を誰が担当するか
Web制作案件などで「フロントエンドは社内で対応できるが、バックエンド部分だけ外注したい」という場合の切り出し方については、こちらの記事も参考にしてください。
また、AWSに限らず、バックエンド開発をどの単位まで成果物として外部へ切り出せるかを整理した記事はこちらです。
既存のAWSインフラ担当がいる案件でも、バックエンド部分を切り出せます
バックエンド開発に特化したシステム開発会社 プレイリーソリューションズ合同会社では、Java / AWSを中心としたバックエンド開発部分だけを切り出した受託開発に対応しています。
既に顧客側や元請け側にAWSインフラ担当がいる案件でも、アプリ側に必要なAWS設定、IAM、DB、ログ、デプロイなどの条件を整理し、インフラ担当とすり合わせながら開発を進めることが可能です。
「AWS基盤は別チームが担当しているが、バックエンド部分を外部へ切り出したい」というSIer・Web開発会社の方は、ご相談ください。
まとめ：AWS案件では「接続点」が見えているかを確認する
AWS案件でアプリ開発会社とインフラ担当の範囲を分けるときは、AWSサービスごとに担当者を決めるだけでは不十分です。
特に確認したいのは、
デプロイ
IAM・シークレット
DB
ログ・監視
障害対応
という、アプリとインフラの接続点です。
それぞれについて、「誰の担当か」だけでなく、誰から誰へ何を渡すのか、どのタイミングで渡すのか、リリース後は誰が対応するのかまで整理すると、開発中や障害時の抜け漏れを減らせます。
アプリとインフラを別の専門担当に分けること自体は問題ではありません。
AWS案件で最初に確認したいのは、両者の間をつなぐ仕事が明確になっているかです。
