LASSIC Media らしくメディア

監修・編集責任者：牛尾 昭昌（株式会社LASSIC 執行役員）

AWSを使うことは決まったが、アカウントを作った後に何から設定すればよいのか分からない。とりあえず動かしてみたら、請求額が想定より大きくなっていた——。初めてAWSを使い始める会社では、こうした戸惑いが起こりがちです。AWS導入支援は、AWSを使い始める段階で、アカウントの分け方や権限、監視、費用の管理といった土台づくりを外部の専門家と一緒に進める支援です。

最初に土台を整えれば、後から作り直す手間を減らせます。ただし万能ではなく、任せきりにすると運用に入ってから社内で判断できなくなることもあります。本記事では、初めてAWSを使う会社の情報システムの担当者に向けて、支援の範囲、頼み方の違い、導入の進め方、支援会社の選び方、そして外部に頼むときに確認したい点を整理します。

AWS導入支援とは

AWSでは、建物や機器、ネットワークといった基盤の保護はAWSが受け持ち、その上で利用者が選んだサービスの設定は利用者が受け持つ、という分担になっています。AWSはこれを「責任共有モデル」と呼び、利用者側の責任を「クラウドにおけるセキュリティ」と説明しています。^*2 AWS導入支援は、この利用者側の初期設定を、使い始める段階で一緒に整える支援です。

• アカウントの設計：本番用と開発用を分けるなど、AWSアカウントをいくつ、どう分けるかを決めます
• 権限：誰がどこまで操作できるかを決め、すべてを操作できる最初のアカウント（ルートユーザー）を守ります
• ネットワーク：VPC（AWSの中に作る、ほかと切り離された社内用のネットワーク）の作り方を決めます
• 監視とログ：システムの状態の見張りと、誰が何を操作したかの記録を用意します
• 費用の管理：月の予算を決め、使いすぎに気づける通知を設定します

どれも、システムを載せた後から直すと手間のかかる部分です。移行の進め方そのものはクラウド移行戦略と移行方式の選び方で扱っています。

支援の頼み方の違い

AWS導入支援は、どこまでを任せるかで中身が変わります。よくある分け方は、設計の相談だけを受ける形、設計から構築まで任せる形、使い始めた後の運用まで任せる形の3つです。運用を誰が受け持つかで選び方が変わります。

運用まで任せる場合でも、権限の承認や予算の決定は社内に残しておくと判断が止まりません。任せきりにすると、退職者の権限や予算超過の扱いを誰が決めるのかが曖昧になりがちです。作業の範囲と一緒に、社内に残す判断も決めておきます。

導入支援の進め方

初めてAWSを使い始めるときは、次の4つの段階で進めると、後からアカウントや権限を作り直さずに済みます。

• ステップ1：使う目的と担当者を決める。何のシステムを載せ、誰が運用するかを先に決めます
• ステップ2：アカウントと権限を整える。ルートユーザーには多要素認証（MFA。パスワードに加えてもう1つの確認を求める仕組み）を設定し、日々の作業には使いません^*3。本番用と開発用はアカウントを分けます^*5
• ステップ3：ネットワークと監視を用意する。VPCを作り、CloudWatch（状態を見張る機能）とCloudTrail（操作の記録を残す機能）を設定します
• ステップ4：費用の管理と見直しの場を決める。AWS Budgets（予算と通知の機能）で月の予算を決め、定期的に設定を見直します

つまずきやすいのはステップ2です。AWSは、ルートユーザーは必要な作業のとき以外は使わないよう強く勧めており、MFAを設定していない場合は、最初のサインインから35日以内に登録が必要です。^*3 社員が使う権限は、IAM Identity Center（社員のアカウントと権限をまとめて管理する機能）で一元管理する形が勧められています。^*4

ステップ3の操作の記録は、何も設定しなくても過去90日分の管理操作を画面で確かめられます。^*7 それより長く残したい場合は、記録を保存先へ送る「証跡」の設定が必要です。ステップ4の予算の情報の更新は1日に3回までで、^*9 使った直後に通知が届くわけではありません。複数のアカウントをまとめて管理する土台の作り方はクラウド基盤のランディングゾーン構築にまとめています。

支援会社の選び方

支援会社を探す手がかりとして、AWSは公式のパートナー制度を設けています。AWSパートナーソリューションファインダーでは、地域・業界・用途、AWSの専門分野（スペシャライゼーション）や認定で支援会社を検索できます。^*11 制度の区分は、AWSの技術を扱える体制を確かめる目安になります。

• サービスパートナーの階層：セレクト・アドバンスト・プレミアの3つがあり、上の階層ほどAWS認定の取得者数などの条件が多くなります^*10
• 専門分野の認定：マネージドサービスプロバイダー（MSP。運用まで受け持つ会社）や、特定の業界・用途に強い会社を示す区分があります^*11
• Well-Architectedの見直し：AWSの設計の考え方に沿って、構築後の設計を一緒に見直せるかどうかも確かめます

AWS Well-Architectedフレームワークは、運用上の優秀性・セキュリティ・信頼性・パフォーマンス効率・コスト最適化・持続可能性の6つの柱で設計を見直す考え方です。^*1 AWSは、この見直しを監査ではなく設計の判断についての話し合いと位置づけています。見直しに使うAWS Well-Architected Toolは無料で使えます。^*12 導入後の工程にこの見直しが入っているかも確かめておきます。

外部に頼むときに確認しておきたい点

AWS導入支援を外部に頼むときは、引き渡した後に自社で回せるかどうかを見積もりの前に確かめておきます。

• 範囲：アカウント・権限・ネットワーク・監視・費用の管理のうち、どこまでを設計し、どこまでを設定するか
• 体制：AWS認定を持つ技術者が設計と構築に入るか。パートナー制度の区分をどう確かめられるか
• 権限の持ち方：ルートユーザーと管理者の権限を誰が持つか。支援会社の権限を作業後にどう外すか
• 検証の方法：引き渡しの前に、権限の設定・監視の通知・予算の通知が想定どおり動くかをどう確かめるか
• 運用後の見直し：使い始めて数か月後に、設計と費用を見直す場を設けるか

特に権限の持ち方は、導入の後に問題になりやすい点です。支援会社へ広い権限を渡したまま運用に入ると、誰が何を変えたのかを追いにくくなります。作業が終わったら権限を外す手順まで、契約の前に決めておきます。

まとめ：AWS導入支援で確かめておきたい3つの点

AWS導入支援を頼むうえで、確かめておきたい点は3つに整理できます。第一に、アカウント・権限・ネットワーク・監視・費用の管理のうち、どこまでを支援の範囲にするかを決めること。第二に、設計の相談・設計と構築・運用までのどの頼み方にするかを、社内で運用を受け持てる人がいるかで選ぶこと。第三に、ルートユーザーや管理者の権限を誰が持ち、作業後に支援会社の権限をどう外すかを決めておくことです。この3点を踏まえておけば、「使い始めたものの、設定の意味が分からず誰も触れない」という事態を避けやすくなります。土台づくりの進め方に迷いがあれば、外部の手を借りるのも一つの選択肢です。

よくある質問

出典

1. *1　参考：Amazon Web Services「AWS Well-Architected フレームワーク」（フレームワークの柱・序章）（https://docs.aws.amazon.com/ja_jp/wellarchitected/latest/framework/the-pillars-of-the-framework.html）。出典：6つの柱（運用上の優秀性・セキュリティ・信頼性・パフォーマンス効率・コスト最適化・持続可能性）と、レビューは監査ではないという位置づけの記述を参照（2026年10月確認）
2. *2　参考：Amazon Web Services「責任共有モデル」（https://aws.amazon.com/jp/compliance/shared-responsibility-model/）。出典：AWSの責任「クラウドのセキュリティ」とお客様の責任「クラウドにおけるセキュリティ」の記述を参照（2026年10月確認）
3. *3　参考：AWS Identity and Access Management ユーザーガイド「AWS アカウントのルートユーザーのベストプラクティス」（https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/root-user-best-practices.html）。出典：ルートユーザーを必要な作業以外で使わないこと、MFAの設定、最初のサインインから35日以内のMFA登録の記述を参照（2026年10月確認）
4. *4　参考：AWS Identity and Access Management ユーザーガイド「IAM でのセキュリティのベストプラクティス」（https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/best-practices.html）。出典：IAM Identity Centerによる一元的なアクセス管理、最小特権のアクセス許可の記述を参照（2026年10月確認）
5. *5　参考：AWS Whitepaper「Organizing Your AWS Environment Using Multiple Accounts」（Benefits of using multiple AWS accounts）（https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/benefits-of-using-multiple-aws-accounts.html）。出典：本番環境と非本番環境でアカウントを分け、環境ごとに異なるセキュリティ管理を適用する記述を参照（2026年10月確認）
6. *6　参考：Amazon VPC ユーザーガイド「Amazon VPC とは?」（https://docs.aws.amazon.com/ja_jp/vpc/latest/userguide/what-is-amazon-vpc.html）。出典：論理的に隔離された仮想ネットワークの説明を参照（2026年10月確認）
7. *7　参考：AWS CloudTrail ユーザーガイド「AWS CloudTrail とは」（https://docs.aws.amazon.com/ja_jp/awscloudtrail/latest/userguide/cloudtrail-user-guide.html）。出典：イベント履歴で過去90日間の管理イベントを確認できること、証跡による保存の記述を参照（2026年10月確認）
8. *8　参考：Amazon CloudWatch ユーザーガイド「Amazon CloudWatch とは」（https://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html）。出典：AWSリソースとアプリケーションのモニタリング、アラームの記述を参照（2026年10月確認）
9. *9　参考：AWS Cost Management ユーザーガイド「AWS Budgets によるコストの管理」（https://docs.aws.amazon.com/ja_jp/cost-management/latest/userguide/budgets-managing-costs.html）。出典：実績と予測の支出に対するアラート、予算情報の更新が1日に3回までであることの記述を参照（2026年10月確認）
10. *10　参考：Amazon Web Services「AWS サービスパートナーティア」（https://aws.amazon.com/jp/partners/services-tiers/）。出典：セレクト・アドバンスト・プレミアの各ティアの説明と、認定取得者数などの要件を参照（2026年10月確認）
11. *11　参考：Amazon Web Services「パートナーとの連携」（https://aws.amazon.com/jp/partners/work-with-partners/）。出典：AWSスペシャライゼーションパートナー（マネージドサービスプロバイダー・コンピテンシー・サービス）と、AWSパートナーソリューションファインダーの検索条件の記述を参照（2026年10月確認）
12. *12　参考：AWS Well-Architected Tool ユーザーガイド「AWS Well-Architected Tool とは」（https://docs.aws.amazon.com/ja_jp/wellarchitected/latest/userguide/intro.html）。出典：ベストプラクティスに沿ってワークロードを測定し推奨事項を示すサービスの説明と、フレームワーク序章の無料のレビューサービスの記述を参照（2026年10月確認）

Tweet