インフラ設計

Amazon EC2 インスタンスの選び方 - インスタンスファミリーと購入オプションの最適化

インスタンスファミリーの特徴と Graviton プロセッサの性能優位性を整理し、オンデマンド・リザーブド・スポットの購入オプションを使い分ける指針を紹介します。

約 1 分で読めます

EC2 の概要

EC2 はクラウド上で仮想サーバーを提供するコンピュートサービスです。数百種類のインスタンスタイプから用途に応じて選択し、数分でサーバーを起動できます。Lambda がイベント駆動のサーバーレスコンピュートであるのに対し、EC2 は OS レベルの制御が必要なワークロードに適しています。Graviton プロセッサ搭載インスタンスで最大 40% のコストパフォーマンス向上を実現します。

インスタンスファミリーと購入オプション

M ファミリー (汎用) は Web サーバーやアプリケーションサーバーに、C ファミリー (コンピュート最適化) はバッチ処理や科学計算に、R ファミリー (メモリ最適化) はインメモリキャッシュやデータベースに適しています。Graviton プロセッサは AWS 独自設計の Arm ベース CPU で、同等の x86 インスタンスと比較して最大 40% のコストパフォーマンス向上を実現します。スポットインスタンスは EC2 の余剰キャパシティを最大 90% 割引で利用でき、2 分前の中断通知で安全に終了処理を実行します。

Graviton インスタンスと最新世代の選定

AWS Graviton プロセッサ搭載のインスタンス (C7g 、 M7g 、 R7g) は、同等の x86 インスタンスと比較して最大 40% のコストパフォーマンス向上を実現します。 Java 、 Python 、 Node.js などの主要ランタイムは Arm64 に対応しており、多くのワークロードで移行が可能です。コンテナワークロードではマルチアーキテクチャイメージをビルドすることで、 x86 と Graviton の両方で実行できます。最新世代のインスタンス (第 7 世代) は前世代と比較してネットワーク帯域幅と EBS スループットが向上しており、同じ性能要件をより小さいインスタンスサイズで満たせるケースがあります。ワークロードの特性に応じて、コンピューティング最適化 (C ファミリー)、メモリ最適化 (R ファミリー)、汎用 (M ファミリー) を選定します。 インスタンス選定に関する詳しい解説はAmazon の関連書籍でも確認できます。

購入オプションとコスト最適化

EC2 の購入オプションはオンデマンド、リザーブドインスタンス (RI)、Savings Plans、スポットインスタンスの 4 種類です。Compute Savings Plans は EC2、Fargate、Lambda に横断的に適用でき、インスタンスファミリーやリージョンの変更にも柔軟に対応します。1 年または 3 年のコミットメントで最大 66% の割引が得られます。スポットインスタンスは最大 90% の割引ですが、2 分前の中断通知に対応する設計が必要です。RI はインスタンスファミリーとリージョンが固定されるため、長期間安定したワークロードに適しています。Cost Explorer の推奨事項で、現在の使用パターンに基づく最適な購入オプションの組み合わせを確認できます。

まとめ

EC2 はインスタンスファミリー、サイズ、購入オプションの組み合わせでワークロードに最適なコンピューティング環境を構築します。Graviton インスタンスでコストパフォーマンスを向上させ、Savings Plans とスポットインスタンスを組み合わせることで、性能要件を満たしながらコストを最適化できます。

関連するサービス

Amazon EC2クラウド上で仮想サーバーを提供するコンピュートサービスAWS Auto ScalingEC2、ECS、DynamoDB などのリソースを需要に応じて自動スケーリングするサービスAmazon EBSEC2 インスタンスに接続して使うブロックストレージサービス

関連する記事

AWS Auto Scaling で実現する需要追従型インフラ - スケーリングポリシーの設計と最適化ターゲット追跡・予測・スケジュールドの 3 種類のポリシーを使い分け、混合インスタンスポリシーでスポットを活用したコスト最適化を実現する手法を紹介します。AWS Compute Optimizer で実現するリソース最適化 - インスタンスのライトサイジングCloudWatch メトリクスを ML で分析し、EC2・Lambda・EBS・ECS Fargate のリソースサイズを最適化する推奨を生成する。Graviton 移行推奨と拡張メトリクスによる精度向上の活用法を解説します。EC2 Image Builder で自動化する AMI パイプライン - ゴールデンイメージの構築とテストゴールデン AMI の構築パイプラインを自動化し、コンポーネントの作成からセキュリティ強化テスト、マルチアカウント配布までを紹介します。

同じテーマの記事

Auto Scaling はなぜスケールアウトは速く、スケールインは慎重なのか - 非対称な判断ロジックの設計意図EC2 Auto Scaling がスケールアウトを即座に実行する一方でスケールインに冷却期間を設ける非対称な設計の理由、フラッピング防止の仕組み、ターゲット追跡スケーリングの内部ロジックを解説します。AWS Auto Scaling で実現する需要追従型インフラ - スケーリングポリシーの設計と最適化ターゲット追跡・予測・スケジュールドの 3 種類のポリシーを使い分け、混合インスタンスポリシーでスポットを活用したコスト最適化を実現する手法を紹介します。AWS の障害ドメイン設計 - AZ・リージョン・パーティションの 3 層構造が守る可用性の仕組みAWS のインフラが AZ (障害隔離)、リージョン (地理的分離)、パーティション (政治的分離) の 3 層で設計されている理由と、各層の障害がどこまで波及するかを具体的な事例とともに解説します。AWS 障害から学ぶ分散システムの原則 - 過去の大規模障害が変えたアーキテクチャS3 障害 (2017)、Kinesis 障害 (2020)、us-east-1 の特殊性など、AWS が公開した障害レポートを題材に、Shuffle Sharding、Static Stability、Cell-based Architecture といった設計原則を解説します。AWS はなぜそこにリージョンを建てるのか - データセンター立地選定の知られざる判断基準AWS がリージョンの立地を決定する際に考慮する電力供給、地政学リスク、データ主権法制、ネットワーク接続性、自然災害リスクなどの判断基準を、具体的なリージョンの事例とともに解説します。AWS の Availability Zone ID はなぜアカウントごとに異なるのか - AZ マッピングの設計意図us-east-1a がアカウントごとに異なる物理 AZ を指す仕組み、AZ ID (use1-az1) が導入された背景、キャパシティの均等分散という設計意図、クロスアカウントでの AZ 指定の注意点を解説します。バッチコンピューティング基盤 - AWS Batch で実現する大規模並列処理AWS Batch を活用した大規模バッチ処理の構築方法を解説します。ジョブキュー、コンピューティング環境の自動スケーリング、Spot インスタンスによるコスト最適化など、科学計算や大規模データ処理に最適なバッチ基盤の設計を紹介します。AWS Batch でバッチコンピューティングを自動化 - ジョブキューとコンピューティング環境の設計AWS Batch によるジョブのスケジューリング、Fargate/EC2 コンピューティング環境の使い分け、スポットインスタンスの活用を解説します。

内容が近い記事・サービス

Amazon EC2AWS が提供するクラウド上の仮想サーバーサービスで、数百種類のインスタンスタイプから用途に最適な構成を選択し、数分でサーバーを起動できるコスト削減戦略 - Savings Plans と Reserved Instances の比較と選択AWS Savings Plans と Reserved Instances (RI) の仕組み・割引率・柔軟性を比較解説。Compute Savings Plans ・ EC2 Instance Savings Plans ・ SageMaker Savings Plans の使い分けと購入戦略を紹介します。AWS Graviton とカスタムシリコン戦略 - 自社設計チップが塗り替えるクラウドの経済性AWS が自社設計した Arm ベースの Graviton プロセッサと、Inferentia・Trainium などの AI 向けカスタムシリコンが、クラウドのコスト構造とパフォーマンスをどう変えているかを Azure・GCP と比較します。AWS 料金モデルの柔軟性 - オンデマンド・RI・Savings Plans・スポットの 4 層構造AWS はオンデマンド、Reserved Instances、Savings Plans、スポットインスタンスの 4 層構造で多様なワークロードに対応します。Azure や GCP の料金モデルと比較し、AWS の柔軟性がコスト最適化にどう寄与するかを解説します。