>
>
公開日
最終更新日
AWS EC2の料金はインスタンスだけでなく、EBS、パブリックIPv4、データ転送、ロードバランサーなどの合計で決まります。
本記事は、クラウド移行、AWSの予算管理、セキュリティ統制を担当する情シス担当者を対象としています。EC2の月額費用を見積もりたい場合や、オンデマンド、Savings Plans、リザーブドインスタンス、スポットの違いを整理したい場合に、そのまま社内検討へ使える判断基準を示します。初期構築のチェックリストも掲載しているため、料金の把握から安全な運用設計まで一続きで確認できます。
Amazon EC2の基本概念と2026年の最新動向
本記事のポイント
Amazon EC2は必要な時間と性能に応じて利用できるAWS上の仮想サーバーです。
EC2料金はコンピューティング料金だけでは決まらず、EBSやIPアドレスなども加算されます。
本番環境では複数のアベイラビリティーゾーンとロードバランサーを組み合わせて冗長化します。
EC2、コンテナ、サーバーレスはOS制御と運用体制を基準に選び分けます。
Amazon EC2は必要に応じて柔軟にリソースを伸縮できるクラウド上の仮想サーバーです。
Amazon EC2とインスタンスの定義
Amazon Elastic Compute Cloud、略してAmazon EC2とは、AWSが提供するIaaS型のコンピューティングサービスです。EC2インスタンスとはAWS上で起動する仮想サーバー1台の単位であり、CPU、メモリ、OS、ネットワーク、ストレージを用途に合わせて構成します。
物理サーバーの購入とは異なり、インスタンスはAWSマネジメントコンソールやAPIから起動、停止、再起動、終了できます。ただし、「停止」は一時的に電源を切る操作、「終了」はインスタンスを削除する操作です。終了後は元に戻せないため、バックアップの取得状況を判定してから実行します。
AMI・EBS・VPCとの関係
EC2は単独で完結せず、OSのテンプレートであるAMI、仮想ディスクのEBS、ネットワークを分離するVPCなどと組み合わせて動作します。
構成要素 | 役割 | 情シスが管理する項目 |
|---|---|---|
EC2インスタンス | アプリケーションやミドルウェアを実行する仮想サーバー | 性能、稼働時間、OSパッチ、台数 |
AMI | OSや初期設定を含む起動用テンプレート | 更新日、脆弱性、共有範囲、世代管理 |
Amazon EBS | EC2に接続する永続ブロックストレージ | 容量、性能、暗号化、スナップショット |
VPC | サブネットや経路を含む論理ネットワーク | IP設計、ルート、外部接続、通信分離 |
セキュリティグループ | インスタンス単位の仮想ファイアウォール | 許可ポート、接続元IP、不要ルール |
EBSはインスタンスを停止しても保持されるため、停止中も容量料金が残ります。AMIから同じ構成を再作成できるようにしておけば、障害復旧や検証環境の展開を標準化できます。
クラウド市場とAWSの利用状況
総務省の令和7年版情報通信白書のクラウドサービス市場（第2部第1章第8節）では、2024年第2四半期の世界クラウドインフラサービス支出額におけるAmazonのシェアを約32％、Microsoftを23％、Googleを12％と掲載しています。また、2024年の日本のパブリッククラウドサービス市場規模は前年比26.1％増の4兆1,423億円と記載されています。これらの数値・定義・調査手法は同白書の第2部第1章第8節（総務省Webサイト）で直接確認できます。
同白書が扱う市場にはEC2以外のサービスも含まれるため、この数値をEC2単体のシェアとは解釈できません。一方、総務省令和7年版情報通信白書が引用するIDC Japanのデータによれば、日本のIaaS・PaaS利用企業においてAWSの採用比率が半数を超えると紹介されています。調査母数・対象企業・調査時点の詳細は同白書の該当ページで確認できます。情シス部門にとってEC2の料金管理、アクセス制御、バックアップ設計は汎用性の高い実務領域です。
▲ OSの管理権限と運用要件に応じたコンピューティングサービスの選定フロー
Amazon EC2の導入メリットとコスト削減効果
EC2の導入によりサーバー調達の迅速化と運用コストの最適化を同時に実現できます。
サーバー調達期間の短縮
EC2ではAMI、インスタンスタイプ、ネットワークを指定して仮想サーバーを起動できるため、機器の選定、発注、搬入、設置を待つ必要がありません。開発環境を短期間だけ用意し、検証終了後に削除する運用にも対応できます。
ただし、起動が速いことと社内統制を省略できることは別です。アカウント、VPC、IAMロール、タグ、ログ保存先を先に標準化できるなら利用部門へセルフサービス化し、標準化できない段階では情シスの承認を通して作成します。
冗長化と伸縮性
EC2ではAuto Scaling Groupを使い、負荷やスケジュールに応じてインスタンス数を増減できます。アクセスをApplication Load Balancerで複数台へ振り分ければ、1台の障害時に正常なインスタンスへ通信を継続できます。
EC2自体に、単一インスタンスを自動的にマルチAZ化する設定はありません。冗長化する場合は、異なるアベイラビリティーゾーンのサブネットに複数のEC2を配置し、ロードバランサー、Auto Scaling、データ層の冗長化を組み合わせます。
ライトサイジングとアーキテクチャ変更
CPUやメモリの実績値を基にインスタンスタイプを縮小すれば、過剰なスペックへの支出を減らせます。インスタンスタイプの変更では通常、停止を伴うため、許容停止時間、AMIとOSの互換性、ネットワーク性能、拡張ネットワーク用ドライバーを事前に判定します。
ARMベースのGravitonへ移行する場合も、単純なタイプ変更だけで完了するとは限りません。使用しているOS、コンテナイメージ、ライブラリがARM64に対応しているなら検証へ進み、対応していないバイナリがあるならx86を維持します。
国内企業における削減実績
AWSが公開するロコガイド「トクバイ」の導入事例（aws.amazon.com）では、Amazon ECSとスポットインスタンスの活用により、インフラコストを約3割、EC2にかかるコストを約6.5割削減したと紹介されています。中断可能な処理をスポットへ分離し、すべてをオンデマンドで稼働させない設計が成果につながっています。
AWSが公開するバンダイナムコオンラインの公式事例（aws.amazon.com）では、Graviton搭載EC2とスポットインスタンスの採用によってインフラコストを約32％削減したと記載されています。また、AWSが公開する日本食研のAWS移行事例（aws.amazon.com）では、日中のバッチ処理時間を約80％、夜間処理時間を約50％短縮したと紹介されています。これらは個別環境の結果ですが、CPUアーキテクチャ、購入方式、処理時間を分けて評価する際の比較材料になります。
Amazon EC2の料金体系と月額費用の目安
EC2料金はインスタンスの時間単価に稼働時間を掛け、EBS、パブリックIPv4、データ転送、関連サービスの費用を加えて算出します。
EC2料金を構成する費目
AWS EC2には一律の月額料金がなく、選択したリージョン、OS、インスタンスタイプ、稼働時間、購入方式によって価格が変わります。請求総額を見積もる際は、次の費目を分けて計算します。
費目 | 料金が決まる主な条件 | 見落としやすい点 |
|---|---|---|
コンピューティング | インスタンスタイプ、OS、リージョン、稼働時間 | 停止中は原則としてインスタンス使用料が止まりますが、休止ではEBSが残ります |
Amazon EBS | ボリューム種別、容量、追加IOPS、スループット | EC2を停止しても課金が継続します |
パブリックIPv4 | 割り当てられたアドレス数と時間 | 未使用のElastic IPだけでなく、使用中を含むパブリックIPv4全般が対象です |
データ転送 | 転送方向、転送量、リージョン間・AZ間通信 | インターネットへの送信やAZをまたぐ通信を分けて集計します |
関連サービス | ロードバランサー、NAT Gateway、CloudWatchなど | EC2を停止しても関連リソースの料金は自動では止まりません |
AWSのAmazon EC2オンデマンド料金では、中国とGovCloudを除くサービスとリージョンを集計し、インターネットへのデータ転送アウトを毎月100GBまで無料と案内しています。無料枠を超えた分や、リージョン間・AZ間の通信は別の単価で計算します。
主要インスタンスタイプの月額費用
東京リージョンでLinuxを720時間連続稼働させる条件では、t3.mediumのコンピューティング料金は月額約6,200円が目安です。次の表は1ドル156円、オンデマンド料金、月720時間で算出した概算で、消費税、EBS、IPアドレス、データ転送、CPUクレジットの追加料金は含みません。単価の根拠はAWSのAmazon EC2オンデマンド料金ページ（東京リージョン・Linux・オンデマンド欄）で確認でき、価格改定があった場合は同ページの最新単価で再計算します。AWS Pricing Calculatorを使うとリージョン・OS・インスタンスタイプを指定して合計額を試算できます。表の月額目安は1ドル156円の社内概算であり、実際のAWS請求額はドル建てで確定し、適用される為替レート・消費税・AWS税設定によって変動します。予算化する際はAWSマネジメントコンソールの請求ダッシュボードまたはAWS Pricing Calculatorで円換算後の概算を改めて算出します。
インスタンスタイプ | vCPU | メモリ | 想定時間単価 | 月額目安 | 主な用途 |
|---|---|---|---|---|---|
t3.micro | 2 | 1GiB | 約0.0136ドル | 約1,530円 | 小規模な検証、監視、踏み台 |
t3.small | 2 | 2GiB | 約0.0272ドル | 約3,060円 | 開発環境、小規模Webサーバー |
t3.medium | 2 | 4GiB | 約0.0544ドル | 約6,200円 | 社内システム、開発・検証環境 |
m6i.large | 2 | 8GiB | 約0.1248ドル | 約14,020円 | 汎用アプリケーションサーバー |
c6i.large | 2 | 4GiB | 約0.1071ドル | 約12,030円 | CPU負荷の高い処理、バッチ |
t3系は平均CPU使用率が低い用途に適したバースト可能インスタンスです。Unlimitedモードでベースラインを長時間超えるとCPUクレジット料金が加算される場合があるため、継続的にCPUを使う処理ではm系やc系との総額を比較します。
t3.mediumの目安は、NTT東日本による2026年1月時点のEC2料金試算も約6,200円と算出しています。具体的な契約時にはAWSのAmazon EC2オンデマンド料金ページ（東京リージョン・Linuxタブ）で単価を再確認し、表の単価から変更されていれば最新単価で再計算、変更されていなければこの目安を予算案に使います。
EBSとパブリックIPv4を含む試算
t3.mediumを月720時間稼働させる場合、コンピューティング料金約6,200円に加え、EBSとパブリックIPv4などが発生します。パブリックIPv4は1アドレス当たり0.005ドル／時間なので、720時間では3.60ドル、1ドル156円換算で約562円です。
EBSのgp3はリージョンにより1GB・月当たり0.08ドルから利用できます（東京リージョンは2025年時点で0.096ドル/GB・月）。容量・追加IOPS・スループットの各単価はAWSのAmazon EBS料金表（aws.amazon.com/ebs/pricing/）で確認でき、プロビジョンドIOPSや追加スループットを設定している場合は基本容量料金とは別に加算されます。つまり、EC2インスタンス料金が約6,200円でも、請求額を6,200円だけで予算化してはいけません。参考として、t3.mediumを1台・東京リージョン・月720時間稼働させ、Application Load Balancer（ALB）1台、NAT Gateway 1台、インターネット送信100GB超を加えた場合の概算は次のとおりです。コンピューティング約6,200円、EBS（gp3 30GB）約374円、パブリックIPv4約562円、ALB（約0.027ドル/時間＋LCU料金）約3,000円台、NAT Gateway（約0.062ドル/時間＋データ処理料金）約7,000円台以上となり、合計は月2万円を超える場合があります。実際の見積もりはAWS Pricing Calculatorで構成を入力して算出し、ALBとNAT Gatewayの有無で総額が大きく変わることを確認した上で構成を選定します。
EC2の購入方式と割引条件
購入方式は、予測できる最低使用量と中断許容性を基準に選びます。
購入方式 | 契約・割引の特徴 | 適する用途 | 主な注意点 |
|---|---|---|---|
オンデマンド | 長期契約なしの従量課金 | 新規システム、短期検証、変動する処理 | 常時稼働を続けると割引方式より高くなります |
Savings Plans | 1年または3年の時間当たり使用額を契約し、条件により最大72％割引 | 一定量が継続する本番環境 | 未使用の契約額も支払い対象です |
リザーブドインスタンス | 1年または3年の契約で条件により最大72％割引 | 構成が安定したEC2、特定AZの容量確保 | Regional RIとZonal RIでは容量予約の扱いが異なります |
スポットインスタンス | AWSの余剰容量を利用し、オンデマンド比で最大90％割引 | 再実行可能なバッチ、CI/CD、分散処理 | 取得不能や中断へ対応する設計が前提です |
AWS Savings Plansの公式料金案内（aws.amazon.com/savingsplans/pricing/）では、1年または3年の使用量コミットメントによる最大72％割引の条件を説明しています。リザーブドインスタンスの割引率・条件はAWSのリザーブドインスタンス料金ページ（aws.amazon.com）で確認でき、特定のアベイラビリティーゾーンでキャパシティーを予約したい場合など、Savings Plansとは異なる用途があります。
AWSのスポットインスタンス公式案内（aws.amazon.com/ec2/spot/）は最大90％の割引を示していますが、常時稼働を保証する方式ではありません。処理を途中から再開でき、複数のインスタンスタイプやアベイラビリティーゾーンを候補にできるならスポットを組み込み、中断できない単一サーバーはオンデマンドか契約型割引を使います。
料金プランの選定順序
初回の料金設計では、最初から全量を長期契約せず、次の順序で利用実績と契約量を分けます。
新規環境をオンデマンドで開始し、時間帯別のCPU、メモリ、稼働台数を収集します。
停止できる開発環境には稼働スケジュールを設定し、不要な時間を先に削減します。
継続する最低使用量だけをSavings PlansまたはRIの候補にします。
中断後に再実行できる処理をスポットへ分離します。
月次でEBS、パブリックIPv4、データ転送を含む総額を予算と照合します。
Amazon EC2への安全な接続手順と初期設定
適切なセキュリティグループ設定とアクセス制御の実施により安全な運用環境を構築できます。
EC2インスタンスの作成手順
EC2の初期構築では、OSや性能の選択より先に接続経路と管理権限を決めます。作成後に公開範囲を狭めるのではなく、最初から必要な通信だけを許可します。
AMIの選択：サポート期間と更新方法が明確なOSを選び、古い社内AMIはパッチ適用日を判定します。
インスタンスタイプの選択：初期値は想定負荷だけで過大にせず、CloudWatchの計測後に変更できる構成にします。
IAMロールの割り当て：アプリケーションへ固定アクセスキーを保存せず、必要最小限の権限を持つロールを使います。
ネットワークの設定：外部公開が不要ならプライベートサブネットへ置き、パブリックIPv4を割り当てません。
ストレージの設定：EBSを暗号化し、容量、バックアップ、DeleteOnTerminationを用途別に設定します。
ログと予算の設定：OSログ、CloudTrail、CloudWatch、AWS Budgetsの通知先を運用担当へ結び付けます。
SSHとSession Managerの接続方式
管理用接続は、要件を満たせるならAWS Systems Manager Session Managerを使うと、SSHポートやパブリックIPv4を公開せずに操作できます。直接SSHを使う場合は、ポート22の接続元を社内の固定IPまたはVPNのCIDRだけに制限します。
接続方式 | インターネット公開 | 認証・記録 | 選定条件 |
|---|---|---|---|
直接SSH | パブリックIP利用時は必要 | 秘密鍵とOSログを管理 | 接続元IPを固定できる短期検証 |
Session Manager | 受信ポートは不要 | IAMで制御し操作ログを保存可能 | SSM Agentと必要な通信経路を用意できる環境 |
踏み台サーバー経由 | 踏み台だけを限定公開 | 踏み台と接続先の両方を管理 | 既存のSSH運用を維持しながら公開点を集約する環境 |
Session Manager用のVPCエンドポイントを構成できるならプライベート通信を選び、構成できない場合はNAT Gatewayなどの送信経路とその料金を含めて比較します。NAT Gatewayは接続管理を簡素化できますが、時間料金とデータ処理料金が加わるため、IPv4料金だけを減らす目的で置き換えると総額が上がる場合があります。
初期構築チェックリスト
本番投入の判定では、次の項目がすべて満たされている場合だけ公開へ進み、未達項目がある場合は非公開の検証環境へ戻します。
確認項目 | 合格条件 | 未達時の判断 |
|---|---|---|
セキュリティグループ | SSHやRDPの接続元が固定IP、VPN、管理ネットワークに限定 | インターネット公開を止めて接続経路を再設計 |
IAMロール | 固定キーを置かず、必要なAPIだけを許可 | アプリケーション権限を分離して再テスト |
EBS暗号化 | ルートとデータボリュームが暗号化済み | 暗号化スナップショット経由で再作成 |
DeleteOnTermination | 一時ディスクは有効、保存対象は無効と用途別に設定 | 削除時のデータ保持要件を確定してから運用 |
メタデータサービス | アプリケーション互換性を確認した上でIMDSv2を必須化 | 互換性を修正するまで外部公開を保留 |
バックアップ | 取得周期、保持期間、復元試験の担当が設定済み | 終了操作を禁止し、復元試験を先に実施 |
監視と予算 | 障害通知と予算超過通知の受信者が登録済み | 通知先のない環境は本番利用へ進めない |
▲ セキュリティと運用性を考慮したEC2インスタンスの初期設定手順
Amazon EC2を中心としたシステム構成パターン
EC2はロードバランサー、Auto Scaling、RDS、S3、CloudFrontと役割を分離することで可用性と保守性を高められます。
Webシステムの役割分離
Webシステムでは、インターネットからの通信をApplication Load Balancerで受け、異なるアベイラビリティーゾーンのEC2へ分散します。Auto Scaling Groupで正常なインスタンス数を維持すれば、障害が発生した1台を自動的に置き換えられます。
画像、動画、静的HTMLはAmazon S3へ置き、Amazon CloudFrontから配信すると、EC2のネットワーク負荷と台数を抑えられます。データベースはAmazon RDSやAuroraへ分離すれば、アプリケーションサーバーの交換時にデータを巻き込まず、バックアップやフェイルオーバーも別の方針で管理できます。
ただし、RDSやロードバランサーには個別の料金が発生します。単一の検証環境まで本番と同じ構成にすると固定費が増えるため、本番は可用性を優先し、停止可能な検証環境は構成を簡略化するなど、環境ごとに目的を分けます。
EC2・ECS/Fargate・Lambdaの使い分け
実行基盤は、単純な時間単価ではなく、OSへの依存、処理時間、状態管理、運用担当者の対応範囲を同じ軸で比較します。
比較軸 | Amazon EC2 | Amazon ECS／AWS Fargate | AWS Lambda |
|---|---|---|---|
料金モデル | インスタンスの稼働時間と関連リソース | 割り当てたvCPU・メモリと実行時間 | リクエスト数と実行時間 |
OS管理 | 利用者がパッチや設定を管理 | FargateではホストOS管理が不要 | サーバーとOSの管理が不要 |
自由度 | OS、ミドルウェア、エージェントを広く変更可能 | コンテナイメージ内を制御可能 | 対応ランタイムと実行制限内で設計 |
長時間処理 | 常駐サービスや長時間バッチに対応 | 常駐コンテナやバッチに対応 | 短時間のイベント処理向け |
状態管理 | EBSや共有ストレージを接続可能 | 外部DBや共有ストレージへ分離 | 原則として外部サービスへ分離 |
既存システム移行 | OS依存が強いリフト移行に適合 | コンテナ化できるアプリに適合 | 機能単位へ分割できる処理に適合 |
運用要件 | OS運用ができる体制 | コンテナのビルドと監視ができる体制 | イベント設計と分散監視ができる体制 |
Windowsサービス、独自ドライバー、既存の監視エージェントなどOS制御が必須ならEC2を選びます。アプリケーションをコンテナ化でき、ホストOSのパッチ作業を減らしたいならECSとFargateを選びます。アクセスが断続的で、短時間のイベント処理へ分割できるならLambdaを選びます。
構成選定の判断フロー
情シス部門では、次の順序で技術要件と運用コストを切り分けると、サービス名を先に決める失敗を避けられます。
OS、ドライバー、ライセンス、GPU、固定IPなどの必須要件を列挙します。
常時稼働か、定期バッチか、イベント発生時だけの処理かを分類します。
アプリケーションがローカルディスクへ保持している状態をDBやオブジェクトストレージへ分離できるか判定します。
OSパッチ、コンテナ管理、サーバーレス監視のうち、社内で担当できる範囲を確定します。
要件を満たす候補だけで、コンピューティング、ネットワーク、監視、人手による運用を含む総コストを比較します。
▲ WebシステムにおけるEC2を中心としたマルチAZ冗長化と役割分離構成
Amazon EC2の運用における代表的な失敗パターンと対策
EC2運用の代表的な失敗は、停止後も残る課金、過大なインスタンス、公開範囲の設定ミス、中断を考慮しないスポット利用です。
停止後も続くストレージとIPの課金
EC2を停止すると、通常はインスタンスのコンピューティング料金が止まりますが、接続中のEBS、保持中のスナップショット、関連するロードバランサーやNAT Gatewayなどは残ります。停止を「請求全体の停止」とみなす運用は避けます。
2024年2月以降、AWSは割り当てられたパブリックIPv4アドレスへ1個当たり0.005ドル／時間を課金しています。対象は未使用のElastic IPだけではなく、実行中のEC2へ自動割り当てされたIPを含むパブリックIPv4全般です。なお、EC2を通常停止（Stop）すると自動割り当てのパブリックIPv4は解放されますが、Elastic IPはインスタンスに関連付けたまま停止すると課金が継続します。また、休止（Hibernate）状態ではコンピューティング料金は発生しませんが、EBSやElastic IPの料金は残ります。詳細はAWS公式ブログのパブリックIPv4料金変更で確認できます。
外部からの直接接続が不要ならパブリックIPv4を外し、Session Managerやプライベート接続へ切り替えます。一方、NAT Gatewayを追加すると別料金が生じるため、複数IPの削減額よりNATの料金が大きい場合は、料金だけを理由に置き換えません。
EC2終了後に残る関連リソース
DeleteOnTerminationが無効なEBSは、インスタンスを終了しても残って課金されます。スナップショット、AMI、Elastic IP、ロードバランサー、NAT Gateway、CloudWatch Logsも、EC2の終了操作だけでは一括削除されません。
削除前に復元要件があるならスナップショットまたはAMIを取得し、復元試験後にEC2を終了します。削除後は「EC2が消えたか」ではなく、同じタグ、VPC、システム名にひも付く課金対象を請求明細から照合し、不要な関連リソースだけを削除します。
オンプレミス構成の過大な引き継ぎ
オンプレミスでピーク負荷に合わせたサーバーを、そのまま24時間オンデマンドで稼働させると、クラウド移行後に支出が増える場合があります。CPU、メモリ、ディスクIO、ネットワークを計測し、通常時とピーク時を分けてインスタンスタイプを選びます。
平日の日中45時間だけ必要な開発環境なら、1週間168時間の常時稼働と比べてコンピューティング稼働時間を約73％減らせます。ただし、EBSやパブリックIPv4の料金は同率では減らないため、「EC2全体の請求が73％下がる」とは見積もりません。
過剰なネットワーク公開
SSHの22番ポートやRDPの3389番ポートを0.0.0.0/0へ開放すると、インターネット上の任意の接続元から到達可能になります。管理ポートは固定IP、VPN、踏み台、Session Managerのいずれかへ限定し、公開が必要なHTTPSだけをロードバランサーで受けます。
AWSの責任共有モデルでは、AWSがクラウド基盤を管理し、利用者がEC2上のOS、アプリケーション、IAM、ネットワーク設定を管理します。自動更新が業務アプリケーションと両立するならパッチ適用を自動化し、両立しない場合は検証環境、承認、本番適用の期限を運用表へ設定します。
スポット中断を考慮しない本番利用
スポットインスタンスの注意点は中断通知だけではありません。必要な容量を取得できない場合、価格とキャパシティーが変動する場合、再実行時に二重処理が起きる場合もあります。
ジョブの途中経過を外部ストレージへ保存でき、再実行しても結果が重複しないならスポットを使えます。単一のデータベースや停止を許容できないサーバーはスポットだけで構成せず、オンデマンドや契約型割引と組み合わせます。
Amazon EC2に関するよくある質問
EC2の料金、停止、削除、スポット利用に関する疑問へ、情シス担当者が判断に使える条件とともに回答します。
Q. AWS EC2とは何か
A. AWS EC2とは、CPU、メモリ、OS、ストレージなどを選んで利用するクラウド上の仮想サーバーです。物理機器を購入せずに起動・停止・削除でき、利用時間と関連リソースに応じて料金を支払います。
Q. EC2インスタンスの月額料金
A. EC2には全インスタンス共通の固定月額料金はありません。東京リージョンのLinux版t3.mediumを720時間稼働させる場合はコンピューティング料金が月約6,200円の目安ですが、EBS、パブリックIPv4、データ転送などが別途加算されます。
Q. EC2停止中の料金
A. 停止中は通常、インスタンスのコンピューティング料金が止まりますが、EBS、スナップショット、パブリックIPv4などの料金は残ります。請求を減らす場合は、停止操作だけでなく、関連リソースの利用状況を費目別に判定します。
Q. スポットインスタンスの本番利用
A. 中断後に自動再実行でき、状態をEC2の外へ保存している処理なら本番でも利用できます。停止できない単一サーバーやデータベースをスポットだけで構成する方法は避け、オンデマンドと組み合わせます。
Q. EC2を完全に削除する方法
A. 復元用のAMIやスナップショットを取得した後、対象インスタンスを終了します。その後、残存EBS、スナップショット、AMI、Elastic IP、ロードバランサー、NAT Gateway、ログを請求明細と照合し、保存要件のないものを個別に削除します。
Q. EC2とFargateの選択基準
A. OSや独自エージェントを管理する必要がある場合はEC2を選び、コンテナ化済みでホストOSの管理を減らしたい場合はFargateを選びます。時間単価だけでなく、パッチ適用や障害対応にかかる運用範囲も比較対象にします。
まとめ
Amazon EC2運用の次の一手
Amazon EC2は短時間で仮想サーバーを用意でき、性能や台数を柔軟に変更できる一方、料金とセキュリティを利用者側で管理するサービスです。月額費用はインスタンス料金だけで判断せず、EBS、パブリックIPv4、データ転送、関連サービスまで含めて算出します。
明日から着手する最初の一歩は、現在の請求明細をコンピューティング、EBS、IPv4、データ転送に分けることです。その後、停止中のEBSと不要なIPを洗い出し、常時稼働する最低使用量だけをSavings PlansやRIの検討対象にします。新規構築では、公開前チェックリストを承認手順へ組み込むと、料金超過と設定ミスを同時に減らせます。
本記事の内容に誤り等がございましたら、こちらからご連絡ください。
監修
Admina Tam
情シス業務に関するお役立ち情報をマネーフォワード Adminaが提供します。
SaaS・アカウント・デバイスの管理を自動化し、IT資産の可視化とセキュリティ統制を実現。
従業員の入退社対応や棚卸し作業の工数を削減し、情報システム部門の運用負荷を大幅に軽減します。
中小企業から大企業まで、情シス・管理部門・経営層のすべてに頼れるIT管理プラットフォームです。
