AWS導入支援を探すと、支援会社の一覧と「選び方のポイント」が並んだ記事が多く見つかります。ただ、発注前に知っておきたいのは、支援会社が初期構築で実際に何を作り、納品されたものが正しく動いているかをどう確かめるかです。この記事では、AWS導入支援の工程と費用の構造、初日に組まれるランディングゾーンの構成、成果物をAWS CLIで検収するコマンド、支援会社への権限の渡し方、委託と自社構築の分かれ目までを、2026年10月時点のAWS公式ドキュメントに沿って整理します。
まとめ：AWS導入支援を頼む前に決めておく5つの線引き
先に結論です。AWS導入支援を依頼する前に、次の5点を自社で決めておくと、見積もりの比較と納品後の検収がぶれません。
- 依頼する工程を「設計・構築・移行・運用」のどこまでにするかを先に決める。移行と運用は別契約になることが多い
- 初期構築の成果物は、OU構成・権限セット・組織の証跡・脅威検知・予算アラートの5点を最低ラインとして指定する
- 納品物はコンソールの画面写真ではなく、IaCのコードとCLIで再確認できる設定値で受け取る
- 支援会社には管理アカウントのルートやIAMユーザーを渡さず、IAM Identity Centerの権限セットで期限付きのアクセスを渡す
- AWS側の基盤費用は小さい。Control Tower本体は無料で、費用の大半は支援会社の作業費と、その後に動かすワークロード側にかかる
以降で、工程と費用、構成、検収コマンド、権限の渡し方、判断基準の順に掘り下げます。
AWS導入支援の作業を設計・構築・移行・運用の4工程で整理する
「AWS導入支援」という言葉は支援会社ごとに指す範囲が違います。比較の前に、工程の単位で分解しておきます。
支援会社が提供する作業と主な成果物を設計・構築・移行・運用で比べる一覧表
多くの支援会社のメニューは、次の4工程に分けて読むと比較しやすくなります。
| 工程 | 主な作業 | 主な成果物 |
|---|---|---|
| 設計 | 要件整理・アカウント分割・権限設計 | 設計書・OU構成図・権限表 |
| 構築 | ランディングゾーン・ネットワーク・監視 | IaCコード・パラメータ一覧 |
| 移行 | 既存システムやデータの載せ替え | 移行計画・切り替え手順書 |
| 運用 | 監視・障害対応・パッチ・コスト確認 | 運用手順書・月次報告 |
見積もりを並べたときに金額が大きく違う場合、たいていは工程の範囲が揃っていません。移行の進め方と7Rの選び方はAWS移行とは？7R戦略と移行ツール・費用と見送り判断を発注者視点で解説、運用フェーズの委託範囲はAWS運用保守の委託範囲と費用｜監視・障害対応・パッチ適用の判断基準で扱っています。この記事は「設計」と「構築」の工程に焦点を当てます。
支援会社の作業費とAWSに払う基盤費用の請求先の違いと料金の内訳
AWS導入支援の費用は、支援会社に払う作業費と、AWSに払う利用料の2本立てです。作業費は時間単価型、初期構築のパック型、プロジェクト一括型のいずれかで提示されることが多く、会社ごとに単価も含まれる作業も違います。
一方、初期構築で組む基盤のAWS利用料は小さい金額です。AWS Control Towerの料金ページによると、Control Tower本体に追加料金は無く、AWS OrganizationsとIAM Identity Centerも追加料金なしで使えます。課金されるのは裏で動くAWS Config、CloudTrail、CloudWatch、SNS、S3などです。同じページの料金例では、5つの検知コントロールを有効にした小規模な構成で月3.75ドル、25アカウント・3リージョンの構成で月60.625ドルと示されています。初期構築の見積もりが高く見えても、その大半は人の作業費であり、AWS側の基盤費用ではありません。
導入支援が最初に組むランディングゾーンのOUとアカウント構成
導入支援の構築工程で最初に作られるのが、複数のAWSアカウントを束ねる土台です。ここが設計どおりかどうかで、後から足すシステムの安全性が決まります。
初期構築で役割ごとに分ける推奨OUとアカウントの配置・拡張の基準
AWSのホワイトペーパーRecommended OUs and accountsは、アカウントをまとめる単位（OU）を役割ごとに分けるよう推奨しています。基礎になるのは、セキュリティとガバナンス用のアカウントを置くSecurity OUと、共有ネットワークなどを置くInfrastructure OUです。業務システムは本番と非本番を含めてWorkloads OUへ、実験や検証用はSandbox OUへ置きます。
同じページには、すべてのOUを最初から作る必要はなく、要件に応じて広げればよいとも書かれています。中小規模の初期構築なら、Security・Workloads（本番と検証をアカウントで分ける）・Sandboxの3つで始め、ネットワークを共有する段階でInfrastructureを足す構成で十分です。支援会社の設計書に、OUごとに何を置き、どのポリシーを当てるかが書かれているかを確認してください。OUとSCPの設計はAWS Organizationsとは？マルチアカウント管理・SCP/RCP・一括請求の仕組みと設計判断を実装者目線で解説が前提になります。
Control Towerで組む構成と自前のIaCで組む構成の違い
ランディングゾーンの組み方は大きく2つです。1つはAWS Control Towerを使う方法で、公式ドキュメントでは、Organizations・Service Catalog・IAM Identity Centerを束ねて1時間以内にランディングゾーンを構築できると説明されています。コントロール（ガードレール）は予防・検知・プロアクティブの3種類があり、Account Factoryで新しいアカウントを決まった設定のまま払い出せます。
もう1つは、Control Towerを使わずOrganizationsとTerraformなどのIaCで同等の構成を組む方法です。自由度は高いものの、保守の責任はすべて利用者側に残ります。支援会社がどちらで組むのかは、見積もりの段階で必ず確認してください。Control Towerで組んだ環境は、後からOUや共有アカウントを手で変えるとドリフト（想定構成とのずれ）として検知されます。この運用上の制約を引き継ぎ時に説明されていないと、社内の担当者が設定を変えたときに更新が止まる原因になりますので、事前に説明を受けてください。Control Tower自体の仕組みと料金の実額はAWS Control Towerとは？ランディングゾーン4.0の仕組み・料金の実額と導入判断をCLI例つきで解説にまとめています。
導入支援の成果物をAWS CLIで検収する手順：OU・権限セット・証跡
納品時の報告書やコンソールの画面写真だけでは、設定が今も有効かは分かりません。管理アカウントにCLIでログインし、設定値を自分の目で確かめます。AWS CLI v2の導入とSSO認証はAWS CLIのインストールと運用｜OS別の導入手順・v2の設定・SSO認証・v1サポート終了への移行を済ませた状態から始めます。
OUとアカウントの配置をorganizationsコマンドで一覧にする
まず、ルートの下にどのOUがあり、各OUにどのアカウントが入っているかを出します。設計書のOU構成図と突き合わせるための一覧です。
# ルートIDを取得する
ROOT_ID=$(aws organizations list-roots --query 'Roots[0].Id' --output text)
# ルート直下のOUを一覧にする
aws organizations list-organizational-units-for-parent \
--parent-id "$ROOT_ID" --query 'OrganizationalUnits[].[Id,Name]' --output table
# OUごとに所属アカウントを一覧にする
for OU in $(aws organizations list-organizational-units-for-parent \
--parent-id "$ROOT_ID" --query 'OrganizationalUnits[].Id' --output text); do
echo "== $OU"
aws organizations list-accounts-for-parent --parent-id "$OU" \
--query 'Accounts[].[Id,Name,Status]' --output text
done設計書にあるのに存在しないOUや、Sandboxに置くはずの検証アカウントが本番と同じOUに入っている状態は、この一覧で見つかります。足りないOUはcreate-organizational-unitで--parent-idと--nameを指定して作れます。
IAM Identity Centerの権限セットとアカウント割り当てを確かめる
IAM Identity Centerは、社員が1つのサインインで複数のアカウントへ入るための仕組みです。導入支援では、管理者・開発者・閲覧者などの権限セットと、それをどのグループにどのアカウントで割り当てるかが成果物になります。
INSTANCE_ARN=$(aws sso-admin list-instances --query 'Instances[0].InstanceArn' --output text)
# 作成済みの権限セットを名前つきで一覧にする
for PS in $(aws sso-admin list-permission-sets --instance-arn "$INSTANCE_ARN" \
--query 'PermissionSets[]' --output text); do
aws sso-admin describe-permission-set --instance-arn "$INSTANCE_ARN" \
--permission-set-arn "$PS" \
--query 'PermissionSet.[Name,SessionDuration]' --output text
done出力されるのは、権限セットの名前と、それぞれに設定されたセッション時間です。管理者権限のセッションが長すぎないか、設計書の権限表にない権限セットが残っていないかを見ます。権限セットの設計の考え方はAWS IAM Identity Centerとは？権限セット設計とCLI認証・IAMとの使い分けを実装者目線で解説で詳しく扱っています。
組織の証跡とGuardDutyの委任管理者が有効かを確認する
操作の記録と脅威の検知は、導入支援の成果物として最低限入っているべき2つです。組織の証跡のドキュメントによると、組織の証跡は管理アカウントか委任管理者のアカウントから作り、メンバーアカウントの利用者は証跡を見られても、削除やログ記録の停止はできません。
# 組織の証跡があり、記録が止まっていないかを確かめる
aws cloudtrail describe-trails \
--query 'trailList[?IsOrganizationTrail].[Name,HomeRegion,IsMultiRegionTrail,S3BucketName]' \
--output table
aws cloudtrail get-trail-status --name <証跡名> --query 'IsLogging'
# GuardDutyの委任管理者アカウントを確かめる（リージョンごとに実行）
aws guardduty list-organization-admin-accounts --region ap-northeast-1IsOrganizationTrailが真の証跡が1本も出なければ、各アカウントの記録が組織として集約されていません。GuardDutyは公式ドキュメントにある通りリージョン単位のサービスで、委任管理者もGuardDutyを使うリージョンごとに指定が必要です。東京リージョンだけ確認して終わると、大阪リージョンが空白のまま残ります。同じページでは、管理アカウントを委任管理者にする構成は推奨しないと書かれているので、委任管理者がSecurity OUのアカウントになっているかも見てください。証跡の設計と料金はCloudTrailとは？証跡設計と料金実額・Lake新規受付終了後の構成をCLIで解説、検知結果の集約はAWS Security Hubとは？CSPMとの違い・料金と有効化手順を実装者目線で解説が続きの手順になります。
メンバーアカウントのルート認証情報を一元管理に切り替えるコマンド
見落とされやすいのがメンバーアカウントのルートユーザーです。ルートユーザーのドキュメントによると、Organizationsでルートアクセスを一元管理にすると、メンバーアカウントのルートのパスワードやアクセスキーを削除でき、その後に組織で作ったアカウントは最初からルートの認証情報を持ちません。有効化は一元管理の手順ページにあるとおり、次の3つのコマンドで行います。
# IAMとOrganizationsの信頼されたアクセスを有効にする
aws organizations enable-aws-service-access --service-principal iam.amazonaws.com
# メンバーアカウントのルート認証情報の削除と、特権タスクの実行を許可する
aws iam enable-organizations-root-credentials-management
aws iam enable-organizations-root-sessions
# 有効になった機能を確かめる
aws iam list-organizations-features導入支援で作ったアカウントごとにルートのメールアドレスとパスワードを支援会社が控えている状態は、引き継ぎ後のリスクになります。各コマンドの引数はCLIリファレンスで確認できます。
支援会社に渡すアクセス権限と引き継ぎの範囲を契約前に決めておく項目
技術的な構成が正しくても、支援会社のアクセスが残ったままだったり、コードを受け取っていなかったりすると、運用に入ってから困ります。契約前に決めるべき点を2つに絞ります。
支援会社に権限セットで期限付きの閲覧アクセスを渡すコマンドの実例
支援会社の担当者へ管理アカウントのルートやIAMユーザーのアクセスキーを渡す運用は避けます。IAM Identity Centerに支援会社用のグループを作り、作業範囲に合わせた権限セットを割り当てれば、契約終了時に必要なのはグループの割り当てを外す操作だけです。create-permission-setの--session-durationはISO 8601形式で指定します。検収期間に閲覧権限だけを渡す例です。
# 閲覧専用で4時間のセッションに制限した権限セットを作る
PS_ARN=$(aws sso-admin create-permission-set --instance-arn "$INSTANCE_ARN" \
--name PartnerReadOnly --session-duration PT4H \
--query 'PermissionSet.PermissionSetArn' --output text)
aws sso-admin attach-managed-policy-to-permission-set \
--instance-arn "$INSTANCE_ARN" --permission-set-arn "$PS_ARN" \
--managed-policy-arn arn:aws:iam::aws:policy/ReadOnlyAccess
# 支援会社用グループに、対象アカウントで割り当てる
aws sso-admin create-account-assignment --instance-arn "$INSTANCE_ARN" \
--target-id 111122223333 --target-type AWS_ACCOUNT \
--permission-set-arn "$PS_ARN" \
--principal-type GROUP --principal-id <支援会社グループのID>create-account-assignmentは、権限セットをアカウントへ反映する処理を伴います。構築作業の期間だけ管理者相当の権限セットを割り当て、検収後は閲覧専用へ切り替える運用にすると、誰がいつ何をしたかもCloudTrailで追えます。
引き継ぎで受け取る成果物とAWSの責任共有モデルに基づく責任の境界
AWSの責任共有モデルでは、クラウドそのもののセキュリティはAWSが、クラウドの中に置く設定やデータのセキュリティは利用者が担います。支援会社に構築を任せても、利用者側の責任が支援会社へ移るわけではありません。引き継ぎでは、少なくとも次の4つを受け取る契約にしておきます。
- ランディングゾーンとネットワークを再現できるIaCのコードと、環境ごとのパラメータ
- OU・権限セット・SCPの一覧と、それぞれを置いた理由を書いた設計書
- アカウント追加、権限の付け外し、障害時の連絡先を書いた運用手順書
- 支援会社のアクセスを外したことを示す記録（割り当て解除後のCLI出力など）
予算アラートも初期構築のうちに入れておくと、引き継ぎ直後の請求の想定外を防げます。設定のコマンドはAWS Budgetsの設定手順：予算アラート・SNS通知・予算アクションをCLIで実装するにまとめています。
AWSパートナーとMAPの使いどころと委託・自社構築の判断基準
最後に、支援会社の探し方と、そもそも委託すべきかを判断します。
Partner Solutions Finderと移行向けプログラムMAPの位置づけ
AWSのパートナー企業は、公式の検索ページAWS Partner Solutions Finderで探せます。比較まとめ記事の掲載順ではなく、AWSが登録しているパートナーの中から候補を拾い、各社が公開している実績を自社の要件と突き合わせるほうが、要件に合う会社に当たりやすくなります。
既存システムの移行を伴う場合は、AWSの移行支援プログラムMAP（Migration Acceleration Program）も候補になります。公式ページでは、評価（Assess）・準備（Mobilize）・移行とモダナイズ（Migrate and Modernize）の3段階で、移行分野の認定を持つAWSパートナーの知見と資金面の投資を提供すると説明されています。対象になる規模や条件は案件ごとに決まるため、移行を伴う見積もりでは、支援会社にMAPの適用可否を最初に聞いてください。移行全体の段取りはクラウド移行の進め方｜7Rの選び方から費用試算・切り替えまでの手順を発注者視点で解説で整理しています。
初期構築を導入支援に委託すべき条件と自社だけで組める場合の判断基準
判断を言い切ります。次の3つのうち2つ以上に当てはまるなら、初期構築は導入支援に委託したほうが早く安全です。1つ目は、アカウントを部門やシステムごとに分けて今後も増やしていく計画がある場合。2つ目は、個人情報や決済など監査で操作記録の提出を求められるデータを扱う場合。3つ目は、社内にAWSの権限設計を経験した担当者がいない場合です。
反対に、1つのアカウントで検証用のシステムを1つ動かすだけなら、導入支援は過剰です。IAM Identity Centerでの管理者作成、ルートユーザーの多要素認証、予算アラートの3つを自社で設定すれば足ります。社内にAWSの経験者がいて、OrganizationsとIaCで組める場合も、委託は設計レビューだけに絞る選択が合います。
見送るべきなのは、移行するシステムの要件が固まっていない段階で構築まで一括発注するケースです。要件が動けばOU構成や権限設計がやり直しになり、作業費が二重にかかります。まず設計工程だけを依頼し、設計書が固まってから構築を発注する2段階の契約が安全です。要件整理から初期構築、引き継ぎ後の運用までまとめて相談したい場合は、インフラ構築（AWS・Google Cloud・Azure）で対応しています。
よくある質問
AWS導入支援について検索されている質問に、AWS公式の記載をもとに答えます。
AWS導入支援の費用は何で決まりますか？
支援会社の作業費が大半を占め、依頼する工程（設計・構築・移行・運用）の範囲とアカウント数で決まります。AWS側の基盤費用は小さく、Control Tower本体は無料で、料金ページの例では小規模構成で月3.75ドル、25アカウント・3リージョンで月60.625ドルです。見積もりを比べるときは、まず工程の範囲を揃えてください。
AWS導入支援を頼まずに自社で始めることはできますか？
自社で始めることは可能です。1つのアカウントで小さく始めるなら、IAM Identity Centerでの管理者作成、ルートユーザーの多要素認証、予算アラートの3つを設定すれば最低限の守りは整います。アカウントを増やす計画があるか、監査で操作記録を求められる場合は、初期設計だけでも外部に見てもらうほうが手戻りが減ります。
AWS導入支援の成果物として何を受け取ればよいですか？
ランディングゾーンを再現できるIaCのコード、OU・権限セット・SCPの一覧と設計理由、運用手順書、支援会社のアクセスを外した記録の4つです。画面写真の報告書だけでは、設定が今も有効かを確かめられません。本文のCLIコマンドで納品後に自分で確認してください。
支援会社にはどのようにAWSのアクセス権を渡せばよいですか？
IAM Identity Centerに支援会社用のグループを作り、作業範囲に合わせた権限セットを割り当てます。ルートユーザーやIAMユーザーのアクセスキーは渡しません。契約が終わったら割り当てを外すだけで済み、作業中の操作はCloudTrailに記録されます。
AWS Control Towerは導入支援に必須ですか？
必須ではありません。Control TowerはOrganizations・Service Catalog・IAM Identity Centerを束ねてランディングゾーンを短時間で組めますが、OUや共有アカウントを手で変えるとドリフトとして検知される制約があります。自由度を優先するならOrganizationsとIaCで組む方法もあります。どちらで組むかは見積もりの段階で確認してください。
関連記事
- AWS Control Towerとは？ランディングゾーン4.0の仕組み・料金の実額と導入判断をCLI例つきで解説：導入支援で使われるランディングゾーンの仕組みと料金。
- AWS Organizationsとは？マルチアカウント管理・SCP/RCP・一括請求の仕組みと設計判断を実装者目線で解説：OUとSCPの設計の前提。
- AWS IAM Identity Centerとは？権限セット設計とCLI認証・IAMとの使い分けを実装者目線で解説：支援会社と社員に渡す権限セットの設計。
- AWS移行とは？7R戦略と移行ツール・費用と見送り判断を発注者視点で解説：移行工程まで依頼するときの方式選び。
- AWS運用保守の委託範囲と費用｜監視・障害対応・パッチ適用の判断基準：初期構築の後に続く運用の委託範囲。
