All
SaaS管理
デバイス管理
セキュリティ対策
脅威・インシデント
IT基盤・インフラ
情シス業務・組織形成
AI / テクノロジー
プロダクト
イベントレポート
その他
ガバナンス

新着記事

もっと見る

>

>

AWS(アマゾンウェブサービス)とは?特徴や他社比較を解説

AWS(アマゾンウェブサービス)とは?特徴や他社比較を解説

AWS(アマゾンウェブサービス)とは?特徴や他社比較を解説

AWS(アマゾンウェブサービス)とは?特徴や他社比較を解説

公開日

最終更新日

アマゾン ウェブ サービス(Amazon Web Services)とは、Amazonが提供するクラウドコンピューティングサービスの総称です。サーバーを購入せずに、コンピューティング、ストレージ、データベース、生成AIなどのIT資源を必要な分だけ利用できます。

一方、AWSは導入するだけでコストやセキュリティの問題が解決する製品ではありません。本記事では、初めてクラウドを選定する情報システム担当者や、オンプレミスからの移行、生成AIの業務利用を検討する企業に向けて、2025~2026年の市場データ、サービスの選び方、Azure・Google Cloudとの比較、国内事例、移行手順、失敗回避策を解説します。

AWSの基本概要や特徴、他社サービスとの比較、安全な導入に向けた初期ステップと運用のポイントを整理して解説するインフォグラフィック。

AWS(アマゾン ウェブ サービス)とは

AWSとは、Amazonが世界各地のデータセンターから200種類以上のITサービスを提供するクラウドプラットフォームです。

本記事のポイント

  • AWSは世界のクラウドインフラ市場で最大規模のシェアを維持しています。

  • Amazon BedrockやAmazon Q Developerにより、社内データを利用した生成AI開発までAWS上で進められます。

  • 料金は従量課金が基本ですが、データ転送、サポート、為替、リソースの消し忘れまで含めた管理が必要です。

  • クラウド選定では製品名ではなく、既存ライセンス、運用スキル、データ保管場所、可用性、総保有コストを比較します。

AWSとクラウドコンピューティングの基本

クラウドコンピューティングとは、サーバー、ストレージ、ネットワーク、データベース、ソフトウェアなどのIT資源を、ネットワーク経由で利用する仕組みです。企業は物理機器を購入して設置する代わりに、管理画面やAPIから必要な環境を短時間で用意できます。

AWSはIaaSだけを提供するサービスではありません。仮想サーバーのように利用者がOSを管理するサービス、データベース運用の一部をAWSへ任せるマネージドサービス、プログラムの実行基盤、分析、機械学習、生成AI、セキュリティ監視まで含みます。どこまでAWSへ運用を任せるかによって、利用者の作業範囲と料金が変わります。

自社設備で稼働するオンプレミスでは、機器調達、設置場所、電源、保守、更新計画を自社で管理します。AWSでは物理設備をAWSが管理するため、企業はアプリケーションやデータへ人員を振り向けやすくなります。ただし、24時間稼働する仮想サーバーを既存構成のまま移すと、オンプレミスより費用が増える場合があります。クラウド化とコスト削減は同義ではありません。

世界・国内市場におけるAWSの位置付け

Synergy Research Groupは、2025年公表の四半期別クラウドインフラサービス市場調査(対象:IaaS・PaaS・ホスティング型プライベートクラウドの合算売上)で、AWSのシェアをおおむね28~29%、Microsoftを20~21%、Googleを13~14%の範囲と集計しています。同社はこの調査結果をプレスリリース形式で四半期ごとに公表しており、最新号はSynergy Research Group公式サイトの「Cloud Infrastructure Services」カテゴリで参照できます。四半期や集計対象によって数値は動きますが、AWSは同調査で首位を維持しています。

日本市場におけるAWSのシェアについては、AWSが日本政府向け情報ページでIDC Japanの2023年調査を引用した数値を掲載していますが、調査の定義や集計範囲によって数値は異なります。調達判断に使う場合は、同一定義で最新年度を集計した調査レポートを直接参照してください。

IDC Japanは2025年発表の国内クラウド市場予測で、2024年の市場規模を9兆7,084億円、2029年を19兆1,965億円(約19兆2,000億円)、2024年から2029年までの年平均成長率を14.6%と予測しています。AWSだけの売上ではなく国内クラウド市場全体の予測ですが、クラウド移行、データ分析、生成AI投資が継続する判断材料になります。

2026年のAWSを取り巻く変化

生成AIの活用状況については、IDC Japanが2025年に公表した国内生成AI市場予測で、2024年の国内生成AIソフトウェア市場が前年比90%超の成長を記録し、2026年以降は用途が実証実験から業務実装へ移行すると分析しています。同予測によると、業務実装の代表用途として、問い合わせ要約、契約書からの情報抽出、社内文書を参照する検索拡張生成(RAG)、開発支援が挙げられており、成果を処理時間や処理件数で定量測定できる用途に投資が集中する傾向があります。これは市場全体の傾向であり、個別企業の導入優先度は自社の業務量、対象部門、既存データ品質によって異なります。AWSではAmazon Bedrockが生成AI基盤、Amazon Q Developerが開発支援を担います。

AWSは2024年1月、日本の東京・大阪リージョンへ2023年から2027年までに2兆2,600億円を投資する計画を発表しました。AWSの日本経済効果レポートは、この投資が日本のGDPへ5兆5,700億円寄与し、年間平均で3万人を超える雇用を支えると試算しています。この数値はAWSによる経済モデル上の推計であり、国内設備の増強規模を把握する材料として扱います。

企業規模別の想定読者と検討範囲

必要な統制は従業員数やAWSアカウント数によって変わります。最初から大企業向けの複雑な構成を採用するのではなく、今後2年間の利用部門とシステム数を基準に設計します。

企業規模の目安

最初に整える範囲

判断基準

50名未満

請求担当者、管理者の多要素認証、予算通知、検証用アカウント

単一システムの検証なら小さく開始し、本番データを入れる前にバックアップと権限を設計します。

50~300名

開発・本番環境の分離、SSO、ログ集約、タグ規則、月次FinOps会議

複数部門が利用するなら、個人単位の管理ではなく組織単位のアカウント統制へ移ります。

300名超

マルチアカウント管理、統制ポリシー、セキュリティ監視、調達・法務との連携

監査対象や海外拠点があるなら、データ所在地、復旧目標、例外承認まで文書化します。

AWSはITインフラ全体を置き換える選択肢ですが、一度に全システムを移す必要はありません。小規模企業は単一ワークロード、中堅企業はアカウント分離、大企業は組織統制から着手すると、後から設計を作り直す範囲を抑えられます。

AWSで解決できる業務課題

AWSでできることはサービス名の利用ではなく、Webシステム運用、データ活用、生成AI、災害対策などの業務課題をクラウド上で解決することです。

Webシステムと業務アプリケーションの運用

アクセス数が変動するECサイト、会員サイト、業務アプリケーションでは、必要な処理能力を短時間で増減できます。通常時は小さな構成で運用し、キャンペーンや繁忙期だけサーバーを増やせば、最大アクセスを想定した機器を常時保有せずに済みます。

仮想サーバーだけでなく、ロードバランサー、コンテナ、サーバーレスを組み合わせられます。既存アプリケーションをほぼ変えずに移す場合は仮想サーバーが候補となり、処理が発生したときだけ動かせる機能ならサーバーレスが候補です。選択基準は流行ではなく、常時稼働時間、応答時間、改修可能性、運用担当者のスキルです。

バックアップと事業継続

社内サーバーのバックアップをAWSへ保存すれば、拠点の火災や機器故障と異なる場所にデータを保管できます。東京と大阪の国内2リージョンを利用する構成では、国内にデータを置きながら広域災害へ備えられます。

ただし、別リージョンへ複製しただけでは事業継続計画は完成しません。復旧時間目標、復旧時点目標、切り替え手順、DNS、認証基盤、復旧担当者まで決めます。年1回以上の復旧試験で目標時間を満たせれば本番運用へ進み、満たせなければ対象システムを絞るか構成を修正します。

データ分析と意思決定

販売、在庫、顧客接点、Web行動などのデータをS3へ集約し、分析サービスや可視化サービスへ接続できます。データを部門ごとの表計算ファイルに分散させず、更新日時、所有者、保存期間を付けて管理できる点が利点です。

一方、データを集めるだけでは分析品質は上がりません。顧客IDや商品コードの定義が部門ごとに違う場合は、先にデータ辞書と責任者を決めます。月次集計を翌営業日までに出す用途と、秒単位の検知用途では構成と費用が異なるため、必要な鮮度を数値で決めます。

生成AIと社内ナレッジ活用

Amazon Bedrockを使うと、基盤モデルを利用した文書要約、検索拡張生成、問い合わせ回答、情報抽出などをAWS上に構築できます。社内規程を検索する場合は、モデルへ文書を丸ごと学習させるのではなく、質問に関係する文書を検索して回答時に参照させる設計が一般的です。

生成AIの導入条件は、回答精度だけではありません。入力可能な情報区分、ログ保存、アクセス制御、誤回答時の確認者、出力を業務へ反映する範囲を決めます。回答根拠を表示でき、監査ログを取得できるなら限定部門の検証へ進み、どちらかを満たせなければ機密情報を含まない文書要約に用途を絞ります。

開発と運用の自動化

Amazon Q Developerは、コードの説明、修正案、テスト、AWS環境の調査などを支援します。継続的なビルドやデプロイにはAWS CodePipeline、CodeBuild、CodeDeploy、GitHubなどを組み合わせ、Infrastructure as Codeによって環境設定もコードとして管理できます。

AWS CodeCatalystは2025年11月7日以降、新規顧客が利用できなくなります。AWSの公式発表によると、既存顧客向けサービスは段階的に終了し、代替としてAWS CodePipelineおよびAmazon CodeWhisperer(現Amazon Q Developer)への移行が案内されています。新規の開発基盤としてCodeCatalystは選定対象から外します。既存利用者は、AWSが提供する「CodeCatalyst移行ガイド」(AWS公式ドキュメント)で対象アカウントの終了日と移行手順を確認し、CodePipelineまたはGitHub ActionsなどのCI/CDプラットフォームへ切り替えます。クラウドサービスをまたいで開発する企業では、特定クラウドだけで完結しないリポジトリと認証の設計も選択肢です。

AWSの代表的なサービス

AWSのサービス選定では、EC2、S3、RDS、Lambdaを基礎とし、生成AIにはAmazon Bedrock、コスト管理にはAWS Budgetsを組み合わせます。

AWSはAWS公式の製品一覧で200種類を超えるサービスを案内しています。名称を暗記するより、コンピューティング、保存、データベース、連携、生成AI、コスト管理という役割で把握すると、構成を比較しやすくなります。

サービス

主な役割

適する用途

主な注意点

Amazon EC2

仮想サーバー

既存アプリケーション、常時稼働処理

OS、パッチ、稼働時間、インスタンスサイズを利用者が管理します。

Amazon S3

オブジェクトストレージ

バックアップ、ログ、画像、データレイク

公開設定、保存クラス、リクエスト、取り出し、転送に料金が発生します。

Amazon RDS

マネージドデータベース

業務システム、Webサービス

エンジン、可用性構成、バックアップ保持期間で費用が変わります。

AWS Lambda

サーバーレス実行環境

イベント処理、API、定期処理

実行時間、メモリ、同時実行数、外部接続を設計します。

Amazon Bedrock

生成AI基盤

要約、検索拡張生成、AIエージェント

モデル、リージョン、入出力トークン、ガードレールを確認します。

AWS Budgets

予算監視

月次予算、利用量、割引契約の監視

通知は請求やリソースを自動停止する機能ではありません。

Amazon EC2の仮想サーバー

Amazon Elastic Compute Cloudは、AWS上で仮想サーバーを作成するサービスです。CPU、メモリ、ストレージ、OSの組み合わせを選べるため、既存システムを移しやすい一方、サーバーの起動中は利用が少なくても料金が発生します。

24時間稼働する安定負荷にはSavings Plansやリザーブドインスタンスを比較し、夜間や休日に使わない開発環境は自動停止の対象にします。割引率だけで契約すると、システム廃止や構成変更後もコミットメントが残るため、過去8~12週間の利用実績を基準に契約量を決めます。

Amazon S3のストレージ

Amazon Simple Storage Serviceは、ファイルをオブジェクトとしてバケットへ保存するサービスです。AWSのAmazon S3公式FAQは、S3 Standardを含む複数のストレージクラスについて、年間99.999999999%のデータ耐久性を実現するよう設計していると説明しています。この数値は設計上の耐久性であり、可用性の保証値や個別ファイルの消失確率を直接示すものではありません。

S3全体の保存容量は拡張できますが、1オブジェクトの最大サイズは5TBです。大きなファイルはマルチパートアップロードを利用します。データ量だけでなく、APIリクエスト、保存クラスからの取り出し、インターネットへの転送でも料金が変わるため、バックアップでは保存期間と復元頻度を先に決めます。

Amazon RDSのデータベース

Amazon Relational Database Serviceは、MySQL、PostgreSQL、MariaDB、Oracle Database、SQL Serverなどを利用できるマネージド型データベースです。バックアップ、障害検知、パッチ適用の一部をAWSが担うため、利用者はアプリケーションとデータ設計へ集中できます。

フルマネージドでも運用が不要になるわけではありません。SQLの性能、ユーザー権限、保存データ、バージョンアップ時の動作確認は利用者が管理します。可用性が必要ならマルチAZ構成、読み取り負荷が高いならリードレプリカを検討し、復旧試験で目標を満たせる構成を採用します。

AWS Lambdaの実行環境

AWS Lambdaは、サーバーを常時管理せず、イベントに応じてコードを実行するサービスです。ファイルがS3へ置かれたときの変換、API処理、定時集計、通知連携などに利用できます。処理がない時間の実行料金を抑えやすいため、断続的な処理と相性が良いサービスです。

料金にはリクエスト数、実行時間、割り当てメモリなどが影響します。長時間処理、常時高負荷、特殊なOS設定が必要な処理では、コンテナやEC2の方が管理しやすい場合があります。「サーバーレスなら必ず安い」と判断せず、月間実行回数と平均実行時間で試算します。

Amazon Bedrockと生成AIのデータ保護

Amazon Bedrockは、複数の基盤モデルをAPIから利用し、検索拡張生成やAIエージェントを構築するためのサービスです。AWSはAmazon Bedrockのデータ保護に関する公式文書(「Data protection in Amazon Bedrock」、AWSドキュメント・最終更新日はページ末尾で確認)で、プロンプトと生成結果を基盤モデルの学習に使用せず、モデル提供者へ配布しないと説明しています。

この仕様だけで社内規程への適合が決まるわけではありません。利用リージョン、CloudTrailへのAPI操作ログ出力、AWS KMSによる暗号鍵管理、IAMポリシーで制限するモデルアクセス権、および入力を許可する情報区分を設計します。AWSマネジメントコンソールの「Amazon Bedrock」→「モデルアクセス」画面で利用可能なモデルとリージョンを確認し、設計時点のカタログを基準として記録します。監査ログとアクセス制御が自社の情報セキュリティ規程の要件を満たす設定で構成できた場合は機密区分に応じた検証へ進み、満たせない場合は個人情報や機密情報を除いた匿名化データのみを対象とします。

AWS Budgetsとコスト管理

AWS Budgetsは、月額費用、使用量、予約やSavings Plansの利用状況に予算を設定し、しきい値到達時に通知する機能です。50%、80%、100%の3段階に加え、予測額が100%へ到達する通知を設定すると、月末の超過前に対応できます。

通知だけではリソースは停止しません。開発環境はタグを条件に自動停止し、本番環境は自動停止せず担当者へエスカレーションするなど、業務影響で処理を分けます。請求担当者だけでなく、休日も確認できる共有先へ通知し、異常時に誰が何を止められるかまで決めます。

WebシステムにおけるAWSの代表的サービスの構成イメージ

Webシステムでは、CloudFrontやロードバランサーを入口にし、EC2またはLambdaで処理し、RDSとS3へデータを保存する構成が基本例です。実際の構成は可用性、応答時間、データ量、運用人数を基準に決めます。

AWS・Azure・Google Cloudの比較と選定基準

AWS、Microsoft Azure、Google Cloudの選定では、市場シェアではなく、既存環境、担当者のスキル、ネットワーク費用、規制、AI・データ基盤の要件を同じ条件で比較します。

主要クラウドの対応関係

Amazon Web Servicesを他社クラウドと比較すると、各社ともコンピューティング、ストレージ、データベース、サーバーレス、生成AIを提供しています。AWSは選択肢とパートナー網、AzureはMicrosoft製品との統合、Google CloudはGoogleのデータ分析技術との連携が判断材料になりますが、単純な得意・不得意だけでは決められません。

比較項目

AWS

Microsoft Azure

Google Cloud

運営会社

Amazon

Microsoft

Google

世界シェアの目安

約28~29%

約20~21%

約13~14%

仮想サーバー

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

生成AI基盤

Amazon Bedrock

Azure AI Foundry

Vertex AI

判断材料

サービスの選択肢、運用実績、国内パートナー

Windows Server、Microsoft 365、Entra IDとの統合

BigQuery、Google Workspace、AI・データ基盤との連携

市場シェアはSynergy Research Groupが2025年に公表した四半期調査の範囲を丸めた目安です。売上の集計範囲や四半期で変わるため、シェアの差をそのまま性能差として扱いません。

既存ライセンスと運用スキルの比較

Windows Server、SQL Server、Microsoft 365、Entra IDを中心に運用している企業では、Azureのライセンス特典と認証統合を含めた見積もりが必要です。一方、AWSの運用経験者が社内や委託先に多い場合は、教育と移行にかかる時間を抑えられます。Google WorkspaceやBigQueryを既に利用している企業では、Google Cloudへデータを集約した方が構成を単純化できる場合があります。

製品単価だけでなく、教育時間を費用へ換算します。例えば担当者5名が40時間の研修を受け、社内人件費を1時間5,000円と置くと、初期教育だけで100万円です。既存スキルを生かせるクラウドは、月額料金が同程度でも初年度の総保有コストを下げられます。

ネットワークとデータ転送の比較

クラウド内へデータを入れる料金は低く設定される場合が多い一方、インターネットや別リージョンへ出す転送料は構成によって増えます。月100TBの映像を外部へ配信するシステムと、社内から数GBの帳票を参照するシステムでは、同じ比較表を使えません。

比較時は、利用者からクラウド、クラウドからインターネット、リージョン間、可用性ゾーン間、他クラウド間の通信量を分けます。現在の通信ログから月間GB数を取得できれば各社の料金計算へ進み、取得できなければ1週間の実測値を月間へ換算して上限と下限の2パターンを作ります。

クラウド選定要件チェックリスト

候補を同じ条件で評価するため、次の各項目を0~2点で採点します。要件を満たさない場合は0点、追加開発や運用変更で満たす場合は1点、そのまま満たす場合は2点です。配点は企業側で変え、規制やデータ所在地の必須条件は点数にかかわらず足切り条件にします。

  1. 既存資産:OS、データベース、ライセンス、SaaS、認証基盤と接続できますか。

  2. 運用体制:社内担当者または委託先が24時間の障害対応と変更管理を実施できますか。

  3. データ所在地:保存、バックアップ、ログ、サポートアクセスが社内規程を満たしますか。

  4. 可用性:必要な復旧時間目標と復旧時点目標を構成と契約で満たせますか。

  5. 総保有コスト:計算、保存、通信、監視、サポート、教育、移行作業を含めていますか。

  6. セキュリティ:SSO、多要素認証、暗号化、監査ログ、脆弱性管理を既存運用へ組み込めますか。

  7. 生成AI:利用したいモデル、リージョン、データ保護、評価方法を満たしますか。

  8. 撤退可能性:データを標準形式で取り出し、別環境で復元できますか。

Microsoft製品との統合が必須ならAzureを比較の軸にし、幅広いサービスと国内パートナーを優先するならAWSを軸にします。BigQueryやGoogle Workspaceとの連携が中核ならGoogle Cloudを軸にします。複数クラウドの併用は障害分散だけで決めず、運用担当者、監視、契約、データ同期を二重化できる場合に限ります。

主要クラウド(AWS・Azure・GCP)の特徴と強みの比較

比較結果が僅差なら、機密性の低い同一ワークロードを2~4週間検証し、構築時間、月額換算費用、障害復旧時間、担当者の作業時間を計測します。カタログ上の機能数より、自社条件で再現できた結果を最終判断に使います。

主要クラウド3社(AWS・Azure・Google Cloud)の特徴と選定基準の比較

▲ 主要クラウド3社(AWS・Azure・Google Cloud)の特徴と選定基準の比較

AWSの具体的な活用・導入事例

AWSの国内事例では、インフラ移行だけでなく、生成AIによる要約、社内ナレッジ検索、契約書分析など、成果を業務時間で測る導入が増えています。

事例の数値は各社固有の業務量、既存環境、対象部門を前提とします。自社へ適用する際は、1件あたりの処理時間、月間件数、確認作業を置き換えて効果を試算します。

大丸松坂屋百貨店のコンタクトセンター効率化

通話の自動要約を既存業務へ組み込み、繁忙期の後処理時間を削減した事例です。

  • 業種・規模:百貨店・小売、大企業

  • 導入時期:AWSが2025年に公式事例を公開しています。本番開始月は公式事例の記載範囲で確認します。

  • 課題:問い合わせ後に担当者が通話内容を記録する作業が発生し、繁忙期の応答率を下げる要因になっていました。

  • 施策:Amazon Connectの通話データとAmazon Bedrockを連携し、生成AIが通話内容を要約する仕組みを構築しました。

  • 成果:AWSは公式事例で、繁忙期に1件当たり約10秒の処理時間を短縮し、月間約28時間を削減したと紹介しています。

自社で月1万件の通話がある場合、1件10秒の短縮は約27.8時間に相当します。ただし、要約の確認時間が別途発生するため、導入前後で後処理時間の中央値と修正率を測ります。

タキヒヨーの生成AIによる業務工数削減

複数部門が共通の生成AI基盤を利用し、文書作成とデザイン関連業務を効率化した事例です。

  • 業種・規模:繊維専門商社、大企業

  • 導入時期:AWSが2025年に公式事例を公開しています。対象部門ごとの開始時期は公式事例の記載範囲で確認します。

  • 課題:部門ごとに知識や作業手順が分かれ、文書作成やアイデア出しが担当者へ集中していました。

  • 施策:Amazon BedrockとAWSの生成AIアプリケーション基盤GenUを利用し、社内向けの生成AI環境を整備しました。

  • 成果:AWSは公式事例で、4部門合計で月450時間の工数を削減し、デザイン業務では1作品当たり約2時間を短縮したと紹介しています。

月450時間の削減効果を判断する際は、生成AIの利用時間だけでなく、人が出力を検証する時間も差し引きます。部門別に利用回数と修正時間を記録できるなら対象を拡大し、記録できない場合は代表業務を3つに絞って効果を測ります。

鴻池運輸の現場ナレッジ共有

拠点ごとに分散していた非構造化情報を、生成AIと検索技術で横断利用した事例です。

  • 業種・規模:物流・製造アウトソーシング、大企業

  • 導入時期:AWS公式事例の公開時点で運用されています。個別機能の開始時期は公式事例の対象期間に従います。

  • 課題:全国拠点で現場の呼称や文書形式が異なり、他拠点の改善事例や自動化ノウハウを検索しにくい状態でした。

  • 施策:Amazon Bedrock、Amazon Kendra、Amazon Auroraを使い、非構造化文書を検索して回答する基盤を構築しました。

  • 成果:AWSは、表記ゆれを吸収しながら拠点横断で情報を探せるようになり、現場の課題解決事例を全社で再利用できるようになったと紹介しています。

この用途では、回答数より検索成功率と根拠文書への到達時間を評価します。拠点名、設備名、略称の辞書を整備しないまま文書を投入すると、同じ意味の情報が別物として扱われるため、検索対象の棚卸しを先に行います。

大成の契約書管理AIエージェント

非エンジニアを含む社内チームが、契約書から必要情報を抽出するAI機能を構築した事例です。

  • 業種・規模:ビルメンテナンス・ビルトータルソリューション企業

  • 導入時期:AWSが公開した公式事例の対象時点で検証・実装されています。

  • 課題:契約書を目視し、契約期間や更新条件などを転記する作業に1件数十分を要していました。

  • 施策:Amazon Q DeveloperとAmazon Bedrockを使い、契約情報を抽出するAIエージェントを構築しました。

  • 成果:AWSは公式事例で、手作業では数十分かかっていた抽出作業を数分へ短縮したと紹介しています。

契約書では速度だけでなく、抽出漏れと誤記の割合が判断基準です。人による最終承認を残し、契約金額、解約条件、自動更新など影響の大きい項目で一定の正解率を満たせれば対象を広げます。

KDDIのデータベース基盤移行

オンプレミスのデータ照会基盤をAmazon Auroraへ移し、処理性能と運用費用を改善した事例です。

  • 業種・規模:通信事業、大企業

  • 導入時期:2024年以降のAWS公式事例

  • 課題:データベースの運用コストと、将来の処理量増加に対する拡張性が課題でした。

  • 施策:フロントシステムと基幹システムの間にデータ照会基盤を構築し、中核データベースをAmazon Aurora PostgreSQLへ移行しました。

  • 成果:AWSはKDDIの公式導入事例で、最大処理性能が毎秒4,000トランザクションから8,000へ向上し、1時間のバッチ処理が20分へ短縮され、データベース運用費用を約50%削減したと説明しています。

同じ結果を得るには、データ量、SQL、同時接続数、可用性構成が影響します。移行前のピーク性能と月額運用費を計測し、同一負荷の試験で比較できる場合に本番移行を判断します。

エムケイシステムのサービス再構築

セキュリティ事故後の再開に向け、AWS上へ新しい環境を構築した事例です。

  • 業種・規模:IT・クラウドサービス提供企業

  • 導入時期:2023年

  • 課題:ランサムウェア被害によってオンプレミス環境の主要サービスが停止し、安全な環境での再開が必要でした。

  • 施策:AWSパートナーと専用チームを設け、AWS上にサービス環境を再構築しました。

  • 成果:AWSはエムケイシステムの公式導入事例で、AWSへの移行着手から約10日で新環境を構築したと説明しています。

緊急時の短期構築は通常の移行計画と条件が異なります。平時にはネットワーク、認証、バックアップ、復旧手順をテンプレート化し、事故後に初めて設計を始めない体制を作ります。

AWSを利用するメリットと国内基盤

AWSのメリットは、調達の速さ、需要に応じた拡張、マネージドサービス、国内2リージョンを組み合わせ、事業要件に合うIT基盤を短期間で構成できる点です。

調達時間と初期投資の削減

物理サーバーでは見積もり、稟議、納品、設置に数週間から数カ月かかる場合があります。AWSでは承認済みの構成を数分から数時間で作成できるため、新規事業や検証の開始を早められます。設備を一括購入せず、利用量に応じて支払うサービスが多い点も特徴です。

ただし、すべてのサービスが初期費用なしの完全従量課金ではありません。Savings Plansやリザーブドインスタンスでは利用量のコミットメントが発生し、Marketplace製品、サポートプラン、専用回線には別の契約や固定費が含まれる場合があります。初期費用、月額固定費、従量費を分けて見積もります。

拡張性とビジネス速度

CPU、メモリ、ストレージ、サーバー台数を需要に応じて変更できるため、成長率を正確に予測できないサービスでも開始できます。Auto Scalingを設定すれば、負荷に応じた増減を自動化できます。検証環境を本番と同じコードから作れば、環境差による障害も減らせます。

拡張上限がないわけではありません。サービスクォータ、IPアドレス、データベース接続数、同時実行数などの制限があります。負荷試験で想定ピークの1.5~2倍を処理できれば本番へ進み、上限へ到達する場合は事前の緩和申請や構成変更を行います。

マネージドサービスによる運用負荷の軽減

RDS、Lambda、Amazon Bedrockなどを利用すると、物理機器や一部のミドルウェア管理をAWSへ移せます。情報システム部門は、ハードウェア交換よりも、権限、データ、業務継続、利用部門支援へ時間を振り向けられます。

管理を任せる範囲はサービスごとに異なります。EC2ではゲストOSのパッチを利用者が担当し、Lambdaでは実行環境の管理範囲が小さくなります。運用担当者が少ない企業ほど、月額単価だけでなく、夜間対応やパッチ作業を含む人件費を比較します。

東京・大阪リージョンとデータ主権

AWSは日本国内で東京リージョンと大阪リージョンを提供しています。国内利用者との通信遅延を抑え、国内の別地域へバックアップや待機環境を配置できるため、データ保管場所と広域災害対策を両立しやすい構成です。

国内リージョンを選ぶだけで、すべてのデータ処理が国内へ限定されるとは限りません。サポートアクセス、外部SaaS連携、監視エージェント、生成AIモデルの推論リージョン、ログ転送先の各通信経路を設計対象に含めます。確認方法は、AWSマネジメントコンソールの「AWS Artifact」で取得できる準拠証明書、および各サービスのデータ処理補遺(DPA)の適用リージョン欄を照合することです。全経路が国内完結と確認できた場合は機密データを含む検証環境へ進み、1つでも海外経路が残る場合はその経路へ流れるデータを匿名化または暗号化したうえで接続先サービスを変更します。

ガバメントクラウドとISMAP

デジタル庁はAWSをガバメントクラウドのクラウドサービスとして選定しています。また、政府情報システムのためのセキュリティ評価制度であるISMAPでは、登録されたサービスと対象範囲を公開しています。自治体や規制業種では、AWSというブランド名だけでなく、調達対象サービスが登録範囲に含まれるかを照合します。

ガバメントクラウドやISMAPへの対応は、利用者側の設定を代行する制度ではありません。データ分類、IAM、ログ、暗号化、バックアップ、委託先管理は導入組織が設計します。調達仕様とAWSの対象範囲が一致すれば構築へ進み、一致しなければ対象サービスの変更または追加統制を選びます。

AWS移行とモダナイゼーションの進め方

AWS移行は全サーバーをそのまま移す作業ではなく、廃止、維持、再配置、再購入、再ホスト、再プラットフォーム化、再設計をシステムごとに選ぶプロジェクトです。

移行対象の棚卸し

最初にサーバー台数ではなく、業務、利用者、データ、連携先、責任者を一覧化します。利用されていないシステムを移行対象から外せば、移行費用と将来のクラウド料金を同時に削減できます。

最低限の棚卸し項目は、システム名、業務責任者、利用時間、CPUとメモリの実測値、データ容量、OS、データベース、外部連携、停止可能時間、復旧目標、月額費用です。責任者と最終利用日を確認できないシステムは直ちに削除せず、通信を監視したうえで隔離します。

移行方針の7分類

AWS移行では、各システムを次の7種類に分類すると、単純なLift and Shiftへの偏りを防げます。

  1. Retire:利用されていないシステムを廃止します。

  2. Retain:規制、契約、技術的制約によって当面は現状維持とします。

  3. Relocate:仮想化基盤などを大きく変えずに配置先を移します。

  4. Repurchase:既存システムをSaaSや別製品へ置き換えます。

  5. Rehost:アプリケーションを大きく変更せずEC2などへ移します。

  6. Replatform:データベースをRDSへ移すなど、一部をマネージド化します。

  7. Refactor:コンテナ、サーバーレス、イベント駆動などへ再設計します。

短期のデータセンター退去ではRehostが必要になる場合がありますが、移行後にReplatformやRefactorへ進む期限を設定します。期限がないと、24時間稼働する高額なEC2構成が固定化します。

移行フェーズと判断基準

小規模な検証から本番へ段階的に進めると、料金、性能、セキュリティの誤差を早い段階で把握できます。

期間の目安

フェーズ

実施内容

次へ進む条件

1~2週

調査

資産、依存関係、費用、データ区分の棚卸し

責任者と停止可能時間を一覧化できています。

2~4週

基本設計

アカウント、IAM、ネットワーク、ログ、予算の設計

管理者権限、監査ログ、通知先を決定できています。

2~6週

限定検証

低リスクな1システムの移行、性能・復旧・費用の計測

復旧目標と予算上限を実測で満たしています。

4~12週

段階移行

依存関係の少ないシステムから順次移行

切り戻し手順を実行でき、重大な未解決事項がありません。

移行後30~90日

最適化

サイズ変更、停止、割引契約、マネージド化

利用量と費用の基準値を取得できています。

期間はシステム数と規制要件で変わります。50名未満で単一システムなら1~2カ月、50~300名で複数連携があるなら3~6カ月が計画の起点です。300名を超え、基幹システムや複数拠点を含む場合は、年度単位のロードマップと専任の意思決定体制を置きます。

移行前後の費用試算

比較対象には、オンプレミスの機器代だけでなく、保守、電力、設置場所、バックアップ、回線、監視、障害対応、人件費を含めます。AWS側にはコンピューティング、ストレージ、データベース、通信、監視、サポート、ライセンスを含めます。

例えば月額100万円のオンプレミス運用を移す場合、AWS利用料が80万円でも、移行作業20万円、追加監視10万円、教育5万円が継続するなら初年度の月額換算は115万円です。2年目に移行費がなくなり、サイズ最適化で70万円へ下がる計画なら、初年度と平常年度を分けて承認します。

モダナイゼーションの優先順位

すべてをサーバーレスへ作り直す必要はありません。運用障害が多い、変更頻度が高い、需要変動が大きい、ライセンス更新が迫っているシステムから再設計すると効果を測りやすくなります。

反対に、数年以内に廃止するシステム、変更がほぼなく安定稼働するシステム、特殊な機器と密接に連携するシステムは、維持または最小限の再ホストが合理的です。改修費を3年以内の運用削減額で回収できればモダナイゼーションへ進み、回収できなければ廃止時期まで現状維持とします。

既存システムのAWS移行における方針(7R)決定フロー

▲ 既存システムのAWS移行における方針(7R)決定フロー

クラウド特有のリスク・失敗パターンと対策

AWSで起きやすい失敗は、既存構成の単純移行、責任共有モデルの誤解、従量課金の管理不全、データ転送の見落としであり、導入前の設計と継続的なFinOpsで抑えます。

Lift and Shiftによるコスト増加

オンプレミスの物理サーバーと同じCPU、メモリ、台数をEC2へ置き換え、24時間稼働させると、期待した費用削減につながらない場合があります。オンプレミスでは余裕を見て過剰なスペックを購入していることが多く、その値をそのままクラウドへ持ち込むためです。

移行前に少なくとも4週間のCPU、メモリ、ディスク、通信量を測定します。平均CPU使用率が10%未満でも、月末だけ90%になるなら単純な縮小ではなく、自動拡張や処理時間の分散を選びます。常時負荷はSavings Plans、変動負荷はAuto Scaling、断続処理はLambdaやコンテナへ分けます。

責任共有モデルの誤解

AWSを利用しても、クラウド内のデータ、IAM権限、アプリケーション、OS、公開設定が自動的に安全になるわけではありません。AWSはクラウド基盤の物理設備や基盤ソフトウェアを保護し、利用者は選んだサービスに応じてクラウド内の設定とデータを保護します。

AWSは責任共有モデルの公式文書で、AWS側と利用者側の責任範囲を説明しています。EC2ではゲストOSの更新まで利用者が担い、マネージドサービスではAWSが担う範囲が増えますが、データ分類とアクセス権限は利用者側に残ります。

対策は、ルートユーザーの多要素認証、日常利用の禁止、IAM最小権限、S3のパブリックアクセスブロック、暗号化、ログ保存です。Security Hubで設定や検出結果を集約し、GuardDutyで不審な挙動を検知します。重大アラートの通知先と一次対応者を休日も含めて決め、月1回は未対応項目を棚卸しします。

意図しない利用料金の急増

従量課金では、プログラムの無限実行、侵害された認証情報の悪用、高性能インスタンスの消し忘れ、大量ログ、想定外の生成AI呼び出しによって料金が急増します。俗にクラウド破産と呼ばれる事象ですが、実務では「意図しない利用料金の急増」として原因と統制を分けます。

AWS Budgetsには実績50%、80%、100%と予測100%の通知を設定します。さらに、CloudTrailでAPI操作を記録し、CloudWatchやEventBridge、GuardDutyと連携して異常を検知します。CloudTrail単体は操作記録が中心であり、実行回数を即時判定して止める仕組みではありません。

開発環境は夜間停止と上限管理を自動化できますが、本番環境を予算到達だけで停止すると業務障害になります。タグが「開発」で所有者が登録済みなら自動停止し、本番または所有者不明なら担当者と責任者へ通知する処理に分けます。

データ転送費と円安の影響

見積もりで見落としやすい費用が、インターネット向け、リージョン間、可用性ゾーン間などのデータ転送です。バックアップを別リージョンへ複製する構成や、他社クラウドと大量にデータ交換する構成では、コンピューティング費用より転送費が大きくなる場合があります。

AWSのサービス価格は米ドルを基準とするものが多く、請求主体や支払設定によって日本円換算の影響を受けます。円安が進むと、使用量が同じでも円換算額が増える可能性があります。請求書の通貨と換算方法を確認できれば為替変動を含む予算幅を設定し、確認できなければ米ドル建て単価へ社内の保守的な想定レートを掛けて予算化します。

FinOpsによる継続的なコスト最適化

FinOpsとは、財務、技術、事業部門がクラウド利用量と事業価値を継続的に管理する運用です。一度の値下げ作業ではなく、可視化、最適化、運用定着を毎月繰り返します。

  1. 毎日:前日比や異常検知アラートを確認し、急増したサービスとアカウントを特定します。

  2. 毎週:所有者不明、未使用、停止中のリソースと、大容量データ転送を洗い出します。

  3. 毎月:予算差異、部門別利用料、単価指標、Savings Plansのカバー率を確認します。

  4. 四半期:契約量、アーキテクチャ、保存期間、サポートプラン、事業KPIとの関係を見直します。

コスト削減率だけを担当者の評価指標にすると、可用性や性能を落とす判断につながります。1取引当たり費用、1ユーザー当たり費用、問い合わせ1件当たりの生成AI費用など、事業量と結び付けた単価を利用します。

ベンダーロックインと障害対策

Amazon Bedrock、Lambda、DynamoDBなどAWS固有機能を深く利用すると開発速度を上げられる一方、別クラウドへ移す作業は増えます。ロックインを完全に避けるために固有機能を使わない設計は、運用負荷や開発期間を増やす場合があります。

撤退可能性が必要なデータは、標準形式で定期的に書き出し、別環境で復元できるかを試験します。数時間の停止を許容できる社内システムなら単一クラウドの複数AZ構成、停止損失が大きいシステムなら別リージョン、さらに規制や事業継続上の条件がある場合は別クラウドを含む構成へ段階的に広げます。

設定ミスによるクラウド破産(高額請求)が発生するプロセス

料金事故は、誤設定、異常な利用、通知の見落とし、対応権限の不足が連鎖して発生します。予算通知だけで終わらせず、検知後の連絡先、停止判断者、操作手順、再開条件まで運用表へ記載します。

AWS責任共有モデルにおける責任分界点と管理範囲の構成

▲ AWS責任共有モデルにおける責任分界点と管理範囲の構成

よくある質問

AWSの導入前に多い疑問について、料金、他社比較、生成AIのデータ保護、予算管理、クラウドの種類を簡潔に回答します。

Q:AWSサービスとは何ですか?

A:AWSは、Amazonが提供するクラウドサービスの総称です。仮想サーバー、ストレージ、データベース、ネットワーク、セキュリティ、データ分析、生成AIなど200種類を超えるサービスを利用できます。

Q:AWSは何型のクラウドですか?

A:AWSは、複数企業が利用するパブリッククラウドを中心としたクラウドプロバイダーです。専用線やオンプレミス向け機器と組み合わせれば、ハイブリッドクラウドも構成できます。

Q:AWSとAzureはどちらを選ぶべきですか?

A:Windows Server、SQL Server、Microsoft 365、Entra IDとの統合を優先する企業はAzureを比較の軸にします。幅広いサービス、AWS運用者、国内パートナーを活用できる企業はAWSを軸にし、通信費と移行費を含む3年間の総保有コストで決めます。

Q:Amazon Bedrockへ入力したデータはAIの学習に使われますか?

A:AWSは、Amazon Bedrockのプロンプトと生成結果を基盤モデルの学習に利用せず、モデル提供者へ配布しないと説明しています。ただし、社内利用ではログ、利用リージョン、アクセス権、入力可能な情報区分を別途設計します。

Q:AWSのコスト超過を防ぐ最低限の初期設定は何ですか?

A:AWS Budgetsで実績50%、80%、100%と予測100%の通知を設定し、休日も確認できる共有先へ送ります。Budgetsは請求を停止しないため、開発環境の夜間停止、所有者タグ、異常なAPI実行の検知も組み合わせます。

まとめ

AWS導入を成功させるための初期ステップ

AWS導入では、最初に対象業務、データ区分、復旧目標、月額予算を1枚に整理します。次に、影響の小さいシステムを無料利用枠や小規模環境で検証し、AWS Budgetsへ50%・80%・100%の通知を設定します。本番データを入れる前に、ルートユーザーの多要素認証、IAMの最小権限、監査ログ、バックアップ復元を確認します。実測した性能、復旧時間、月額換算費用が基準を満たせれば段階移行へ進み、満たせなければサービス構成または対象業務を見直します。

本記事の内容に誤り等がございましたら、こちらからご連絡ください。

監修

Admina Team

情シス業務に関するお役立ち情報をマネーフォワード Adminaが提供します。
SaaS・アカウント・デバイスの管理を自動化し、IT資産の可視化とセキュリティ統制を実現。
従業員の入退社対応や棚卸し作業の工数を削減し、情報システム部門の運用負荷を大幅に軽減します。
中小企業から大企業まで、情シス・管理部門・経営層のすべてに頼れるIT管理プラットフォームです。