>
>
公開日
最終更新日
AWSはAmazonが提供するクラウドサービスで、国内のIaaS・PaaS利用企業においてAWSが広く普及しているとする調査があります。
アマゾン ウェブ サービスは、物理サーバーを購入せず、仮想サーバー、ストレージ、データベース、ネットワーク、分析、生成AIなどを必要な分だけ利用できる基盤です。一方で、AmazonのEC通販サイトとAWSは役割が異なります。初めてAWSの導入・検討を行う企業の情報システム担当者が、製品名だけで判断すると、コスト増加や設定漏れにつながります。
本記事では、Amazon Web Servicesとは何かという基本から、EC2・S3・RDS・Lambdaの使い分け、Azure・Google Cloudとの比較、責任共有モデル、AWS Budgetsによる高額請求対策、国内企業の活用事例までを解説します。
この記事を読む前に、自社の状況を確認してください。
・新規クラウド構築を検討中の場合は「AWSとは」「AWSで利用できる主要サービス」「AWS導入前の確認事項」を参照します。
・オンプレミスからの移行を検討中の場合は「AWS移行とモダナイゼーションの進め方」「AWS導入時の注意点と失敗パターン」を参照します。
・生成AIの業務活用のみを検討中の場合は「Amazon Bedrockの概要と用途」および「セゾンテクノロジー」「中外製薬」の事例を参照します。
AWSとは
AWSはAmazonが提供するクラウド基盤であり、物理サーバーを購入せずITリソースを利用できるサービスです。
本記事のポイント
AWSとAmazonのEC通販事業は同じAmazonグループのサービスですが、利用目的と契約対象が異なります。
AWSは仮想サーバーだけでなく、ストレージ、データベース、ネットワーク、セキュリティ、生成AIまで扱うクラウド基盤です。
クラウド導入の成否はサービス数ではなく、既存資産、運用体制、データ要件、総保有コストで決まります。
利用開始時は権限管理、ログ、予算通知を先に整えることで設定ミスと意図しない請求を抑えられます。
クラウドコンピューティングの基本
クラウドコンピューティングとは、サーバー、保存領域、ネットワーク、データベース、アプリケーション実行環境などのIT資源を、ネットワーク経由で利用する仕組みです。情シス部門は機器の調達、設置、更新を待たず、管理画面やAPIから環境を準備できます。
オンプレミスでは、企業がサーバー本体、設置場所、電源、空調、ハードウェア保守を管理します。AWSでは物理データセンターや基盤設備をAWSが管理し、利用企業はアプリケーション、データ、アクセス権限、設定を管理するとAWSは説明しています（AWS責任共有モデル: ）。利用するサービスによって管理範囲が変わるため、同ページで対象サービスの区分を確認し、自社の設計・統制範囲を確定します。設備投資を抑えやすい反面、利用時間やデータ量に応じて請求額が変動する点が特徴です。
AmazonのEC通販事業との違い
AmazonのEC通販事業は、商品を探して購入するための消費者向け・法人向けの販売サービスです。AWSは、企業がWebシステムや業務システムを動かすためのクラウドサービスです。Amazonで商品を購入するアカウントと、AWSアカウントでクラウド環境を管理することは別の行為です。
両者はAmazonが提供するサービス群という関係にありますが、AWSを契約してもEC通販の出品・受注管理機能が付くわけではありません。逆に、Amazonで買い物をする企業がAWSのサーバーやデータベースを利用できるわけでもありません。社内説明では「Amazonは事業者名、AWSはIT基盤サービス」と整理すると誤解を防げます。
IaaS・PaaS・マネージドサービスの違い
AWSでは、仮想サーバーを利用者が管理するIaaS、データベースなどの運用作業をAWSへ一部任せるマネージドサービス、プログラム実行基盤を利用するサーバーレスサービスを選べます。Amazon EC2は仮想サーバーの代表例であり、OSやミドルウェアの管理範囲が比較的大きいサービスです。Amazon RDSはデータベースのバックアップや障害対応の一部をAWSが担うマネージドサービスです。
サービスの管理範囲が広がるほど、情シス部門が担う定常作業は減らせます。ただし、データ分類、ユーザー権限、ネットワーク公開範囲、アプリケーションの安全性は利用企業の責任として残ります。運用要員が限られる場合は、EC2だけで構成する前に、RDSやLambdaなどのマネージドサービスで管理対象を減らせるか検討します。
国内外における利用状況
国内のPaaS・IaaS利用企業におけるAWSの利用状況は、調査主体・調査時点・調査対象を確認したうえで判断します。総務省が公表する令和6年版情報通信白書soumu.go.jpは、日本のPaaS・IaaS利用企業においてAWSが利用企業の半数以上を占めると紹介しています。AWSを扱える技術者、導入パートナー、学習コンテンツが国内に多い背景を把握する材料として参照できます。
世界クラウドインフラサービス市場のシェアを比較する際は、調査会社、対象四半期、市場の定義をそろえて確認します。総務省の令和7年版情報通信白書soumu.go.jpは、2024年第2四半期時点の世界クラウドインフラサービス支出額シェアとして、Amazonが約32%、Microsoftが23%、Googleが12%と紹介しています。市場シェアは性能や価格の優劣を直接示すものではありませんが、複数社の選択肢を比較する際の市場構造を把握する参考になります。
AWSで利用できる主要サービス
初めてのAWS選定では、EC2、S3、RDS、Lambdaの役割を理解し、自社システムの処理・保存・データベース・自動化へ対応付けます。
AWSは200を超えるサービス群を提供していますが（AWS公式サービス一覧に基づく。サービス数は随時変動します）、すべてを覚える必要はありません。まずは「処理する」「保存する」「データを管理する」「イベントに応じて動かす」「利用状況を監視する」という役割で分けると、構成の全体像を把握できます。
サービス | 主な役割 | 適する用途 | 利用企業側の管理項目 |
|---|---|---|---|
Amazon EC2 | 仮想サーバー | 既存業務アプリ、常時稼働する処理 | OS、パッチ、インスタンスサイズ、停止管理 |
Amazon S3 | オブジェクトストレージ | バックアップ、ログ、画像、分析データ | 公開設定、保存期間、暗号化、取り出し頻度 |
Amazon RDS | マネージドデータベース | Webシステム、業務システム | DB設計、権限、性能、バックアップ方針 |
AWS Lambda | サーバーレス実行環境 | 通知、定期処理、ファイル変換、API処理 | コード、実行時間、同時実行数、例外処理 |
Amazon Bedrock | 生成AI基盤 | 要約、検索拡張生成、文書抽出 | 入力データ、アクセス制御、出力評価、ログ |
Amazon EC2の概要と用途
Amazon EC2は、CPU、メモリ、OSなどを選んで仮想サーバーを起動するサービスです。既存の業務アプリケーションを大きく作り替えずに移行したい場合や、独自のミドルウェアが必要な場合に候補になります。
EC2は自由度が高い一方で、稼働中のサーバーに対する料金、OSの更新、脆弱性対応、バックアップ、監視を利用企業が管理します。開発環境を夜間・休日に使わない場合は、起動し続ける設計を避け、停止の自動化を前提に見積もります。
Amazon S3の概要と用途
Amazon S3は、ファイルをオブジェクトとしてバケットに保存するストレージサービスです。バックアップ、アクセスログ、画像、帳票、データ分析用ファイルの保管に使われます。AWSの公式ドキュメントは、S3の主要なストレージクラスについて、高い設計耐久性を実現するよう設計していると案内しています。ストレージクラスによって可用性や災害耐性の条件が異なるため、利用目的に応じてAWS公式のストレージクラス比較表（Amazon S3公式ドキュメント「Amazon S3 ストレージクラスの使用」内の比較表）で各クラスの仕様を確認します。比較表に記載されている可用性・最小保存期間・取り出し料金の条件を基に、バックアップや配信用途に最適なクラスを選択します。
耐久性はデータを失いにくくする設計上の指標であり、利用者の削除操作や誤公開を防ぐものではありません。S3では、パブリックアクセスブロック、バケットポリシー、暗号化、保存期間のライフサイクル設定をセットで設計します。デジタル庁の資料digital.go.jpでも、S3 BucketはBucket Policyによってアクセス制御できると説明されています。
Amazon RDSの概要と用途
Amazon RDSは、リレーショナルデータベースを運用するためのマネージドサービスです。バックアップ、障害検知、ソフトウェア更新の一部をAWSが担うため、サーバーへ直接ログインしてデータベースを保守する作業を減らせます。
RDSを使っても、SQLの性能、データの正確性、利用者権限、アプリケーション改修は自動化されません。停止許容時間が短い業務システムでは、可用性構成と復旧試験を決め、バックアップが存在するだけで復旧可能と判断しない運用にします。
AWS Lambdaの概要と用途
AWS Lambdaは、イベントに応じてプログラムを実行するサーバーレスサービスです。ファイルのアップロードを検知して形式変換する処理、毎朝の集計、外部サービスへの通知、APIの一部処理などに向きます。
常時稼働するサーバーを持たずに済むため、断続的な処理では費用を抑えやすくなります。ただし、実行回数、実行時間、メモリ割り当て、外部接続の設計次第では費用や性能が変わります。長時間のバッチ処理や特殊な実行環境が必要な処理は、EC2やコンテナサービスも比較対象に含めます。
Amazon Bedrockの概要と用途
Amazon Bedrockは、複数の基盤モデルをAPIから利用し、文書要約、社内文書検索、情報抽出、AIエージェントなどを構築するための生成AI基盤です。AWSのデータ保護に関する公式文書は、Amazon Bedrockにおける顧客のプロンプトや生成結果の取り扱いについて説明しています。ただし、顧客自身がデータを用いてモデルをカスタマイズする機能など、利用形態によって条件が異なるため、適用するユースケースに応じてAWS公式のデータプライバシーFAQで最新の条件を確認します。
社内文書を扱う場合は、利用リージョン、IAMによる権限制御、操作ログ、入力を許可する情報区分、出力内容の確認者を決めます。根拠文書を表示でき、利用履歴を取得できるなら限定部門の検証へ進みます。回答根拠を追えない場合は、機密情報を含む問い合わせ対応へ広げず、公開済み文書の要約から始めます。
AWSを選ぶメリットと導入条件
AWSの利点は、調達速度、拡張性、マネージドサービス、国内リージョンを組み合わせてIT基盤を構成できる点です。
調達速度と初期投資の抑制
オンプレミスでは、サーバーの見積もり、稟議、発注、納品、設置、初期設定が必要です。クラウドでは、承認済みの構成を短時間で用意できるため、検証環境や新規システムの立ち上げを早められます。
ただし、AWSは「導入すれば安くなる」サービスではありません。常時稼働するEC2、データ転送、ストレージの取り出し、商用ソフトウェア、サポート契約などを含めて費用を算定します。設備購入費だけを比較対象にすると、移行後の請求額を過小評価します。
需要変動への対応
アクセス数やデータ量が変動するシステムでは、必要な処理能力を増減できることがAWSの利点になります。繁忙期だけ処理能力を増やし、通常時は縮小する設計にすれば、最大負荷向けの設備を恒常的に保有する必要がありません。
一方、サービスクォータ、IPアドレス、データベース接続数、外部APIの上限は別途管理します。月末やキャンペーン時に負荷が集中するシステムでは、想定ピーク時の処理量を測定し、上限を超える場合は構成変更または緩和申請を行う前提で計画します。
マネージドサービスによる運用範囲の縮小
RDS、Lambda、Amazon Bedrockのようなマネージドサービスを使うと、物理設備や一部ミドルウェアの管理をAWSへ移せます。情シス部門は、ハードウェア障害の対応よりも、業務部門の利用支援、権限管理、データ品質、復旧計画に時間を配分できます。
管理範囲はサービスごとに異なります。EC2ではOS更新が利用企業の管理範囲に残りますが、Lambdaでは実行基盤の管理範囲が小さくなります。夜間対応やパッチ適用の負担が課題なら、月額単価だけでなく、作業時間を含む運用費で比較します。
国内リージョンと制度対応
AWSは日本で東京リージョンと大阪リージョンを提供しています。国内の別地域にバックアップや待機環境を置けるため、国内利用者への応答性能と広域災害対策を両立しやすい構成です。
AWSのISMAP登録状況は変動する場合があります。利用予定のリージョンやサービスが登録範囲に含まれるかどうかは、ISMAP管理機関の公式サイト（）で公表されているクラウドサービスリストで最新状況を照合します。ISMAPは、内閣サイバーセキュリティセンター（NISC）、デジタル庁、総務省、経済産業省が運営する政府情報システム向けのセキュリティ評価制度です（ISMAP公式サイト: で制度概要と登録クラウドサービスリストを確認できます）。
ISMAP登録は利用企業の設定不備を補うものではありません。調達要件で対象サービスの登録が必要な場合は、利用予定サービスが範囲に含まれるかを照合します。対象に含まれる場合は自社の権限、ログ、暗号化、委託先管理を設計し、含まれない場合は利用サービスの変更または追加統制を判断します。
市場成長と選定時の位置付け
総務省の令和7年版情報通信白書soumu.go.jpは、2024年の日本のパブリッククラウドサービス市場規模が前年比26.1%増の4兆1,423億円に達したと紹介しています。クラウド利用は一部の先進企業だけの取り組みではなく、基幹業務、データ活用、業務アプリケーションの選択肢として広がっています。
市場規模の成長だけでAWS採用を決める必要はありません。既存システムとの接続、障害時の復旧目標、データ保管条件、利用部門の要求を満たせるかを優先します。要件を満たさないサービスを市場シェアだけで選ぶと、後工程で設計変更が発生します。
AWS・Azure・Google Cloudの比較と選定基準
他社クラウド選定では既存の社内資産であるWindows環境やGoogle Workspaceとの親和性を最優先に比較します。
AWS、Microsoft Azure、Google Cloudはいずれも、コンピューティング、ストレージ、データベース、ネットワーク、生成AIを提供しています。製品名の知名度だけでなく、認証基盤、既存ライセンス、データ分析環境、運用担当者の知識、通信費を同じ条件で比較します。
比較軸 | AWS | Microsoft Azure | Google Cloud |
|---|---|---|---|
仮想サーバー | Amazon EC2 | Azure Virtual Machines | Compute Engine |
オブジェクトストレージ | Amazon S3 | Azure Blob Storage | Cloud Storage |
マネージドDBの例 | Amazon RDS、Aurora | Azure SQL Database | Cloud SQL、AlloyDB |
サーバーレスの例 | AWS Lambda | Azure Functions | Cloud Run functions（名称・位置付けはGoogle Cloud公式ドキュメントで最新状況を確認してください。確認した内容によって選定対象サービスが変わります） |
生成AI基盤 | Amazon Bedrock | Azure AI Foundry | Vertex AI |
比較の起点 | サービス選択肢、AWS運用経験、国内パートナー | Windows Server、Microsoft 365、Entra ID | Google Workspace、BigQuery、データ分析基盤 |
既存資産との親和性
Windows Server、SQL Server、Microsoft 365、Entra IDを中心に運用している企業は、Azureとの認証統合やライセンス条件を含めて比較します。Google WorkspaceやBigQueryが業務の中心なら、Google Cloudにデータ基盤を集約することで連携を単純化できる場合があります。
AWSは、幅広いサービスを組み合わせたい場合、既にAWSを扱える委託先がいる場合、複数のOSやデータベースを併用している場合に比較の軸になります。AWS運用経験が社内・委託先にあるなら教育期間を抑えられます。経験者がいないなら、構築支援と運用引き継ぎの範囲を見積もりに含めます。
料金比較の考え方
クラウド料金は仮想サーバーの単価だけでは比較できません。コンピューティング、ストレージ、バックアップ、データベース、データ転送、監視、サポート、商用ライセンス、移行作業、教育費を合算します。
例えば、オンプレミスの月額運用費が100万円で、AWSの利用料が80万円であっても、移行作業を月額換算して20万円、追加監視を10万円、教育を5万円と見込む場合、初年度の月額換算は115万円です。移行費用がなくなり、稼働実績を基に最適化した後に利用料が70万円になる見込みなら、初年度と平常年度を分けて承認判断を行います。この試算は説明用の例であり、自社の実測値で置き換えます。
ネットワークとデータ転送の比較
大量のデータをインターネットへ配信するシステム、リージョン間でバックアップを複製するシステム、複数クラウド間でデータ連携するシステムでは、データ転送費が大きな比較項目になります。月額利用料を比較する際は、クラウドへの入力、インターネットへの出力、リージョン間、可用性ゾーン間、他クラウド間の通信を分けます。
通信ログから月間の転送量を取得できる場合は、その実績を料金試算に使います。取得できない場合は、一定期間の実測値を基に、通常月と繁忙月の2パターンを作ります。動画、画像、ログなどの大容量データを扱うなら、処理費より先に転送経路を整理します。
クラウド選定チェックリスト
候補サービスを同じ条件で評価するために、以下の項目を調達・開発・運用担当者で確認します。規制やデータ所在地の必須条件は、合計点が高くても満たさなければ候補から外します。
既存資産：OS、データベース、認証基盤、SaaS、ネットワークと接続できるかを確認します。
データ所在地：本番データ、バックアップ、ログ、サポート経路が社内規程に合うかを確認します。
運用体制：障害対応、変更管理、権限棚卸しを社内または委託先で実施できるかを確認します。
可用性：復旧時間目標と復旧時点目標を構成・契約・試験で満たせるかを確認します。
総保有コスト：利用料以外に、通信、監視、教育、移行、人件費を含めて比較します。
撤退可能性：データを標準形式で取り出し、別環境で復元できるかを確認します。
比較結果が僅差なら、同じ低リスク業務を候補クラウドで検証し、構築時間、月額換算費用、復旧時間、担当者の作業時間を測定します。監査ログとバックアップ復元を確認できれば本番候補へ進み、どちらかが不足する場合は構成を修正して再検証します。
▲ 既存の社内資産と目的に応じた適切なクラウドサービスの選定フロー
AWS導入における国内企業の活用事例
国内企業の事例では、AWSはインフラ移行だけでなく、データベース運用、社内ナレッジ検索、生成AIによる業務支援に使われています。
事例の成果は、対象業務、利用者数、既存環境、データ品質によって変わります。情シス部門では、事例の数値をそのまま採用せず、自社の月間処理件数、処理時間、確認作業へ置き換えて検証します。
GMOペイメントゲートウェイのマネージドサービス活用
業種・規模：決済サービスを提供する国内企業です。AWS Customer Storiesには、GMOペイメントゲートウェイがAWSのマネージドサービスを利用した開発により、運用コストを20％低減したとする事例の背景・施策・成果が掲載されています。対象システムと測定条件は、同事例ページで確認してください。
この事例は、仮想サーバーをそのまま増やすだけでなく、管理対象を減らせるサービスへ置き換えることで運用コストを見直した例です。自社で同様の検討をする場合は、機器費用だけでなく、パッチ適用、バックアップ確認、障害対応にかかる時間を移行前後で比較します。
セゾンテクノロジーの生成AI活用
業種・規模：データ連携・ITサービスを提供する国内企業です。AWS Customer Storiesには、セゾンテクノロジーがAmazon Bedrockを活用し、社内での検証アンケートにおいて高い評価と業務効率の向上を確認したとする事例の背景・施策・成果が掲載されています。具体的な数値と測定対象・測定方法は同社の事例ページで確認できます。この数値はAWSが公表するベンダー発信の成果値です。
生成AIの効果は、回答を出す時間だけでなく、人が確認・修正する時間を含めて評価します。問い合わせ内容と回答根拠を記録できる場合は、正答率、修正率、処理時間を月次で測定します。根拠の追跡ができない場合は、顧客対応や契約判断のような影響が大きい業務へ直接適用しません。
中外製薬の生成AIアシスタント開発
業種・規模：製薬企業です。AWS Customer Storiesには、中外製薬がAmazon Bedrockを活用した生成AIアシスタントを開発し、多数の社内利用者が活用する基盤を短期間で構築したとする事例の背景・施策・成果が掲載されています。利用者数や開発期間などの詳細はAWSが公表するベンダー発信の情報であり、開発条件の詳細は同社の事例ページで確認できます。
利用者が多い生成AI基盤では、モデル性能だけでなく、利用規約、情報区分、部署別のアクセス権、利用ログ、問い合わせ窓口を整える必要があります。部門ごとの文書を扱う場合は、閲覧権限のない情報を検索結果へ含めない設計を先に検証します。
KDDIのデータベース基盤移行
業種・規模：通信事業を展開する国内企業です。AWS Customer Storiesには、KDDIがAmazon Aurora PostgreSQLを活用したデータ照会基盤により、最大処理性能を毎秒4,000トランザクションから8,000トランザクションへ向上させ、1時間のバッチ処理を20分へ短縮し、データベース運用費用を約50％削減したとする事例の背景・施策・成果が掲載されています。これらの数値はAWSが公表するベンダー発信の成果値であり、測定条件や対象システムは同社の事例ページで確認できます。
データベース移行では、同じ処理性能が得られるかをSQL、接続数、データ量、可用性構成の条件をそろえて確認します。性能試験で復旧目標と応答時間を満たせれば本番移行へ進み、満たせない場合はインデックス、クエリ、インスタンス構成を見直します。
AWS移行とモダナイゼーションの進め方
AWS移行は全サーバーをそのまま移す作業ではなく、廃止、維持、再ホスト、マネージド化、再設計をシステムごとに選ぶ取り組みです。
移行対象の棚卸し
移行の初期段階では、サーバー台数ではなく、業務、利用者、データ、外部連携、責任者、停止可能時間を一覧化します。利用されていないシステムを移行対象から外せば、移行費と将来のクラウド利用料を同時に削減できます。
棚卸しでは、システム名、業務責任者、利用時間、CPUとメモリの実測値、データ容量、OS、データベース、外部接続先、復旧時間目標、復旧時点目標、現行費用を記録します。責任者や利用状況が不明なシステムは削除せず、通信状況を観測して利用実態を確認してから廃止判断を行います。
移行方針の分類
移行方針は、利用していないシステムを廃止するRetire、当面は現状維持するRetain、配置先を移すRelocate、SaaSへ置き換えるRepurchase、アプリケーションを大きく変えずに移すRehost、データベースなどをマネージド化するReplatform、クラウド向けに再設計するRefactorに分けられます。
データセンター退去など期限が短い場合はRehostを選ぶことがあります。ただし、移行後も高性能なEC2を24時間動かし続ける構成が固定化すると、クラウドの費用最適化は進みません。Rehostを選ぶ場合は、移行後にサイズ最適化やRDS化を判断する時期も移行計画へ含めます。
導入フェーズの目安
初めてAWSを導入する場合は、低リスクなシステムで設計と運用を検証してから対象を広げます。以下の表は、担当者が各段階で何を判断するかを整理したものです。
フェーズ | 実施内容 | 次へ進む判断基準 |
|---|---|---|
棚卸し | 資産、依存関係、データ区分、費用、責任者を整理します。 | 停止可能時間と責任者を特定できています。 |
基本設計 | アカウント、権限、ネットワーク、ログ、予算通知を設計します。 | 管理者権限、通知先、監査ログの保存方針を決めています。 |
限定検証 | 低リスクなワークロードで性能、費用、復旧を測定します。 | 予算上限と復旧目標を実測で満たしています。 |
段階移行 | 依存関係の少ないシステムから本番移行します。 | 切り戻し手順を実行でき、未解決の重大課題がありません。 |
最適化 | サイズ変更、停止自動化、保存期間、割引契約を見直します。 | 利用量と費用の基準値を取得しています。 |
移行後の最適化
移行直後の利用料は、オンプレミス時代の余裕を持たせたサイジングを引き継ぐため、高くなりやすい状態です。実測値を基に、使われていないEBS、停止忘れのEC2、古いスナップショット、必要以上のログ保存、過大なデータベース構成を洗い出します。
可用性を下げるだけのコスト削減は行いません。利用率が低いEC2を縮小しても、月末処理時に性能が不足するなら、サイズ縮小ではなくAuto Scalingや処理分散を選びます。削減額ではなく、1取引当たり費用や1ユーザー当たり費用など、業務量と結び付く指標で継続評価します。
▲ システム棚卸しから最適化までに辿るAWS移行の4ステップ
AWS導入時の注意点と失敗パターン
AWSで起きやすい失敗は、責任共有モデルの誤解、既存構成の単純移行、従量課金の監視不足、データ転送費の見落としです。
責任共有モデルの誤解
AWSを利用しても、AWS内のデータ、IAM権限、OS、アプリケーション、公開設定が自動的に安全になるわけではありません。AWSはデータセンター、物理サーバー、ネットワーク基盤など「クラウド自体」の保護を担い、利用企業は「クラウド内」の設定とデータを保護します。
EC2では、ゲストOSの更新やミドルウェア設定が利用企業の管理範囲に残ります。RDSやLambdaではAWSが担う範囲が増えますが、データの分類、アクセス権限、アプリケーションの入力制御は利用企業が設計します。ルートユーザーを日常業務で使うこと、共有アカウントで管理者権限を渡すこと、S3を安易に公開することは避けます。
Lift and Shiftによるコスト増加
オンプレミスのCPU、メモリ、サーバー台数をそのままEC2へ移すと、利用率が低い環境に対して継続課金が発生します。オンプレミスは将来の増加を見込んで余裕を持たせることが多く、その余剰をクラウドへ持ち込むとコスト増につながります。
移行前にはCPU、メモリ、ディスク、通信量を一定期間測定します。平均CPU利用率が低くても、月末だけ負荷が高いなら、単純な縮小ではなく、Auto Scalingやバッチ処理の時間分散を検討します。安定した常時負荷と変動負荷、断続処理を分けて構成を選ぶと、過剰な固定費を抑えられます。
意図しない料金急増
高性能インスタンスの起動忘れ、プログラムの無限実行、大量ログの保存、侵害された認証情報の悪用、生成AI APIの想定外利用によって、請求額が急増する場合があります。俗にクラウド破産と呼ばれることがありますが、実務では原因別に検知・連絡・停止手順を分けます。
AWS Budgetsは、コスト、使用量、Savings Plansなどに予算を設定し、しきい値に達したときに通知できるサービスです。Budgetsは通知を送る設定が基本ですが、AWSはAWS Budgets ActionsによってIAMポリシーの適用やリソースの停止を構成できると説明しています（AWS Budgets Actionsの詳細はAWS公式ドキュメント「Configuring AWS Budgets actions」で確認できます。対象リソース種別や制約条件はドキュメントの記載を基に設計します）。ただし、本番環境を予算超過だけで自動停止すると業務停止につながるため、自動アクションを設定する場合は開発環境と本番環境で対象と動作を分けて設計します。
AWS Budgetsによる初期コスト通知
初回のAWSアカウント作成後は、リソースを増やす前に予算通知を設定します。通知を受け取る担当者が不在なら、設定だけでは料金事故を防げません。共有メールアドレス、情シス責任者、利用部門の所有者を通知先に含め、連絡後の担当を決めます。
予算単位を決めます。全社、AWSアカウント、プロジェクト、環境ごとに月額予算を分けます。タグで部門やシステムを識別している場合は、タグ単位の予算も設定します。
実績コストの通知を設定します。月額予算の50％、80％、100％に到達した通知を設定します。50％で利用状況を確認し、80％で原因調査と対応方針を決め、100％で責任者へエスカレーションします。
予測コストの通知を設定します。月末予測が予算の100％を超える通知を設定します。実績が100％へ達する前に、急増したサービスや利用者を特定できます。
対応手順を環境別に分けます。所有者が明確な開発環境は、停止可能なEC2や検証環境を自動停止の対象にします。本番環境は停止せず、利用部門責任者と情シス部門が費用・業務影響・継続可否を判断します。
月次で予算を見直します。新規システムの開始、繁忙期、割引契約、利用部門の追加に応じて、予算と通知先を更新します。
データ転送費とログ費用
インターネットへのデータ送信、リージョン間複製、可用性ゾーンをまたぐ通信、他クラウドとのデータ連携は、見積もりから漏れやすい費目です。大量配信やバックアップ複製がある場合は、EC2やRDSの料金より先にデータ経路を図示します。
ログも保存期間が長く、出力量が大きいと費用に影響します。監査上必要なログと、短期間の障害調査だけに使うログを分けます。保存要件を満たす期間が決まればライフサイクル設定を適用し、決まらない場合は無期限保存を前提にせず、法務・監査担当を交えて保管年数を定めます。
▲ AWS責任共有モデルにおける利用者とAWSの管理責任範囲
AWS導入前の確認事項
初めてAWSを導入する企業は、本番システムを移す前に、責任者、データ、復旧、権限、費用の5項目を文書化します。
導入時に設定を急ぐと、管理者権限の共有、バックアップ未確認、通知先漏れ、所有者不明のリソースが残ります。以下のチェックリストは、限定検証へ進む前に情シス部門が確認する項目です。
確認項目 | 確認内容 | 判断の分岐 |
|---|---|---|
業務責任者 | システム停止や費用増加を判断する責任者を決めます。 | 責任者を特定できれば検証対象にします。特定できなければ移行対象から外します。 |
データ区分 | 個人情報、機密情報、公開情報を分類します。 | 利用条件を満たせれば対象データを扱います。満たせなければ匿名化または対象外とします。 |
アカウント管理 | 管理者、多要素認証、日常利用アカウント、退職者対応を決めます。 | 個人識別と権限棚卸しができれば運用を開始します。できなければ共有利用を止めます。 |
ログと監視 | 操作ログ、障害通知、保存期間、一次対応者を決めます。 | 通知を受けて対応できれば本番候補にします。対応者がいなければ監視設計を見直します。 |
復旧計画 | 復旧時間目標、復旧時点目標、バックアップ、切り戻しを定義します。 | 復元試験で目標を満たせれば移行します。満たせなければ構成を変更します。 |
費用管理 | 予算、タグ、Budgets通知、利用部門別の請求確認を決めます。 | 所有者と予算超過時の対応が決まれば利用を拡大します。決まらなければ検証環境に限定します。 |
初期アカウント統制
最初に、ルートユーザーの多要素認証を有効化し、日常作業には個人を識別できる権限を使います。管理者権限を持つユーザーを必要最小限にし、利用部門には業務に必要な範囲だけを付与します。
複数のシステムや部門で利用する場合は、本番、開発、検証を同じアカウント内で混在させず、障害・請求・権限の影響を分けます。すべてを最初から複雑なマルチアカウント構成にする必要はありませんが、本番データを扱う前に、誰がどの環境を管理するかを明確にします。
限定検証の評価基準
限定検証では、機密性の低い業務を選び、構築時間、月額費用、処理性能、障害時の復旧時間、担当者の運用時間を測定します。生成AIを検証する場合は、回答の正確さだけでなく、根拠表示、誤回答時の修正手順、入力データの取り扱いも評価対象に含めます。
検証の結果、費用、復旧、アクセス制御の基準を満たせれば、依存関係の少ない次のシステムへ対象を広げます。基準を満たせない場合は、移行対象を拡大せず、構成、運用手順、サービス選定のいずれに原因があるかを切り分けます。
導入後の運用会議
AWSは導入後も利用量と構成が変化します。月次で、予算差異、未使用リソース、所有者不明のタグ、重大なセキュリティ通知、バックアップ復元結果、利用部門からの変更要求を確認します。
コスト削減だけを評価基準にすると、性能や可用性を下げる判断につながります。業務システムなら1処理当たり費用、データ分析なら1ジョブ当たり費用、生成AIなら問い合わせ1件当たり費用のように、利用量と費用を結び付けて管理します。
まとめ
AWSはAmazonが提供するクラウドサービスであり、AmazonのEC通販事業とは目的が異なります。仮想サーバーのEC2、ストレージのS3、データベースのRDS、イベント処理のLambdaを組み合わせることで、業務システム、バックアップ、データ活用、生成AI基盤を構築できます。
導入判断では、AWS・Azure・Google Cloudの機能数だけを比べず、既存の認証基盤、ライセンス、データ所在地、復旧目標、通信費、運用体制を同じ条件で評価します。明日から取り組む最初の一歩は、移行候補システムを1件選び、責任者、データ区分、月額予算、復旧目標、外部連携先を一覧にすることです。その後、AWS Budgetsの通知と権限・ログの初期統制を整え、低リスクな環境で費用と復旧を実測します。
本記事の内容に誤り等がございましたら、こちらからご連絡ください。
監修
Admina Team
情シス業務に関するお役立ち情報をマネーフォワード Adminaが提供します。
SaaS・アカウント・デバイスの管理を自動化し、IT資産の可視化とセキュリティ統制を実現。
従業員の入退社対応や棚卸し作業の工数を削減し、情報システム部門の運用負荷を大幅に軽減します。
中小企業から大企業まで、情シス・管理部門・経営層のすべてに頼れるIT管理プラットフォームです。
