--- title: "Amazon EC2とは？仕組み・インスタンスタイプと料金モデル・採用判断を実装者目線で解説" url: "https://www.issoh.co.jp/tech/details/15424/" published: 2026-07-21 updated: 2026-10-01 categories: ["AWS"] publisher: "株式会社一創" --- # Amazon EC2とは？仕組み・インスタンスタイプと料金モデル・採用判断を実装者目線で解説 Amazon EC2（Elastic Compute Cloud）は、必要なときに必要なスペックの仮想サーバーを分単位で借りられるAWSの中核サービスです。この記事では、Nitro・AMI・EBS・セキュリティグループといった構成要素、インスタンスタイプの命名規約とGraviton5世代の選び方、オンデマンドからスポットまで5つの料金モデルを、2026年9月時点のAWS公式ドキュメントで裏を取りながら整理しました。AWS CLIで1台起動して停止するまでのコマンドも載せています。ECS FargateやLambda、Lightsailとの使い分け、そしてEC2を採用すべき条件と見送るべき場面の判断基準まで、実装者が構成設計で迷う論点を具体的な数値で示します。 ## まとめ：Amazon EC2の仕組み・料金モデルと採用判断の要点 Amazon EC2は、AWSのデータセンター上に仮想サーバー（インスタンス）を立ち上げ、OSからミドルウェア、アプリケーションまで自分で制御できるIaaS型のサービスです。物理サーバーの調達や増設を待たずに、数分でスペックを決めて起動し、不要になれば停止・削除して費用を止められます。CPUやメモリの構成は数百種類のインスタンスタイプから選び、Graviton（ARM）系を選べば同等性能で単価を下げられます。2026年9月時点の最新世代はGraviton5（m9g・c9g・r9g）です。GCPで同等の仮想サーバーを借りるなら、[Compute Engineとは？の解説](https://www.issoh.co.jp/tech/details/15665/)が対応するサービスです。 料金はオンデマンド、Savings Plans、スポット、キャパシティ予約、専有ホストの5モデルがあり、稼働パターンに合わせて組み合わせると総額が大きく変わります。定常稼働のWebサーバーやデータベースには向き、断続的なイベント処理はLambda、コンテナ運用はECS Fargateへ寄せたほうが安くなる場面もあります。判断に迷う実装者は、本記事後半の採用条件と見送り条件を自社のワークロードに当てはめてください。 ## Amazon EC2の仕組みと仮想サーバーを構成する主要コンポーネント EC2を設計に落とし込むには、インスタンス単体だけでなく、それを支えるイメージ・ストレージ・ネットワークの部品群を一体で押さえます。ここを曖昧にしたまま起動すると、データが消える構成や外部から到達できない構成を作り込みやすくなります。 ### Nitro Systemとインスタンスという仮想サーバーの実体 EC2のインスタンスは、AWSが用意した物理サーバー上で動く仮想マシンです。最新の世代はNitro Systemという専用ハードウェアが仮想化とネットワーク処理をオフロードし、ホスト側のオーバーヘッドを抑えつつ物理サーバーに近い性能を引き出せる仕組みです。Nitro自体も世代を重ねており、2026年6月提供開始のM9g／M9gdは第6世代Nitro Systemと新設のNitro Isolation Engineを載せています。どのタイプがNitroに載るかは[Nitroインスタンスの一覧](https://docs.aws.amazon.com/ec2/latest/instancetypes/ec2-nitro-instances.html)で引けます。 1台のインスタンスは起動・停止・再起動・削除というライフサイクルで管理します。停止中はコンピューティング料金が止まる一方、EBSボリュームには課金が続く点を設計時に区別しましょう。状態遷移と課金の対応は[インスタンスライフサイクルのドキュメント](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-lifecycle.html)にあります。仮想サーバーやインスタンスという概念そのものの整理は、[インスタンスとは何かを領域別に解説した記事](https://www.issoh.co.jp/tech/details/13576/)で確認できます。 ### AMI・EBS・キーペアで決まる起動構成とデータ永続化の勘所 インスタンスの起動元になるのがAMI（Amazon Machine Image）で、OSと初期ソフトウェアを固めたテンプレートです。AMIの作成・コピー・登録解除の手順とスナップショットの料金は、[AWS AMIの作成・共有・登録解除のCLI手順](https://www.issoh.co.jp/tech/details/17998/)で扱っています。データの保存先はEBS（Elastic Block Store）というネットワーク接続型のブロックストレージが基本で、インスタンスを停止・削除してもEBSを残せばデータは保持されます。永続用途の起点は、IOPSとスループットを容量と切り離して指定できる汎用SSDのgp3です。タイプごとの上限値は[EBSボリュームタイプの公式表](https://docs.aws.amazon.com/ebs/latest/userguide/ebs-volume-types.html)にあります。EBSのスナップショットや料金モデルの詳細は、[Amazon EBSとは何かを実装者目線で解説した記事](https://www.issoh.co.jp/tech/details/15440/)で確認できます。AMIに載せるOSの世代を決めるときは、[Amazon Linux 2027とAL2023の違いと移行判断](https://www.issoh.co.jp/tech/details/17710/)もあわせて確認すると、旧世代インスタンスで起動できない条件を先に避けられます。 逆に、インスタンス内蔵のインスタンスストア（一時ディスク）は停止で中身が消えるため、永続データを置いてはいけません。停止・休止・終了のいずれでもデータが失われることは[インスタンスストアの寿命に関する公式ドキュメント](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-store-lifetime.html)が明記しています。ログイン用のSSH鍵はキーペアとして管理し、秘密鍵は再発行できないので確実に保管します。 ### セキュリティグループ・VPC・Elastic IPで組む通信経路 EC2は必ずVPC（仮想ネットワーク）の中に配置され、そこへの通信可否をセキュリティグループという仮想ファイアウォールで制御します。セキュリティグループはインスタンス単位で許可ルールを積む方式で、既定では受信が全て遮断され送信は全許可という挙動が[VPCセキュリティグループのドキュメント](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-security-groups.html)に定義されています。必要なポートだけを送信元IPを絞って開けるのが原則です。 固定のグローバルIPが要る場合はElastic IPを割り当てます。ここは料金体系が変わった箇所で、いまはインスタンスに紐付けた使用中のアドレスもアイドルのアドレスも、1個あたり0.005 USD／時が課金されます（[Amazon VPCの料金](https://aws.amazon.com/vpc/pricing/)・2026年9月時点）。730時間換算で月およそ3.6 USDです。この通信設計を誤ると、到達できない、あるいは全開放で危険という両極端にはまりやすい領域です。 ## Amazon EC2のインスタンスタイプ体系と命名規則・Gravitonの選び方 EC2で最初に迷うのがインスタンスタイプの選定です。数百種類ありますが、命名規則とカテゴリの考え方さえ掴めば、ワークロードから逆算して候補を数個に絞れます。 ### 汎用・コンピューティング特化・メモリ特化などカテゴリの考え方 インスタンスは用途別に5カテゴリへ分かれます。バランス型の汎用（General Purpose）、CPU比率の高いコンピューティング特化（Compute Optimized）、大容量メモリのメモリ特化（Memory Optimized）、高IOディスクのストレージ特化（Storage Optimized）、GPUなどを積む高速コンピューティング（Accelerated Computing）です。Webアプリやマイクロサービスなら汎用、機械学習の推論や動画エンコードはコンピューティング特化か高速コンピューティング、インメモリDBやキャッシュはメモリ特化、というのが選定の初手になります。 | カテゴリ | 代表ファミリー | 向くワークロード | | ----------- | ------- | ---------------- | | 汎用 | M・T・Mac | Webサーバー・API・中小DB | | コンピューティング特化 | C | バッチ・推論・エンコード | | メモリ特化 | R・X | インメモリDB・キャッシュ | | ストレージ特化 | I・D | 高IOのDB・分散ストレージ | | 高速コンピューティング | P・G・Inf | 学習・生成AI・グラフィックス | ### ファミリー＋世代＋プロセッサ接尾辞で読むインスタンス名の文法 インスタンス名は「ファミリー＋世代＋プロセッサ接尾辞＋サイズ」で構成されます。たとえば`m7g.large`なら、汎用のM・第7世代・Graviton（g）・largeサイズという意味です。接尾辞のgはAWS製のGraviton（ARM）、iはIntel、aはAMDを示し、dはローカルNVMe SSD付き、nはネットワーク強化を表します。サイズはlarge・xlarge・2xlargeと上がるほどvCPUとメモリが倍々で増えるため、まず必要なメモリ量からサイズを当たり、プロセッサでコストと互換性を調整する順序が実務的です。 公式の定義では、1文字目が系列、2文字目が世代、3文字目以降がオプション、ピリオドの後ろがサイズという並びになっています（[EC2インスタンスタイプの命名規約](https://docs.aws.amazon.com/ec2/latest/instancetypes/instance-type-names.html)）。オプション文字はプロセッサ以外にも割り当てられていて、eはストレージやメモリの追加、zは高クロック、bはブロックストレージ向けの性能強化、flexはFlexインスタンス、qはQualcommの推論アクセラレータを指します。サイズ側の`metal`はベアメタルで、仮想化層を挟まず物理サーバーをそのまま使う指定です。 ### Graviton（ARM）採用のコスト効果とx86からの移行判断 2026年9月時点の最新世代はGraviton5です。汎用のm9g・m9gd、コンピューティング特化のc9g・c9gd、メモリ特化のr9g・r9gdが一般提供されています。AWSは[M9g／M9gdの提供開始（2026年6月10日）](https://aws.amazon.com/about-aws/whats-new/2026/06/ec2-m9g-m9gd-instances-graviton5-processors-available/)で、Graviton4搭載のM8g／M8gd比で計算性能が最大25%、データベースで最大30%、Webアプリケーションと機械学習で最大35%速いと示しました。プロセッサ側は192コア・キャッシュ5倍・コア間レイテンシ最大33%低減という仕様です。 コスト面では、同等のx86ベースEC2と比べて価格が最大20%低く、消費電力は最大60%少ないと[AWS Gravitonの公式ページ](https://aws.amazon.com/ec2/graviton/)が公表しています。標準的なランタイム（Node.js・Python・Go・Java・Ruby）で動くアプリはARM対応が進んでおり、新規構築ならまずGravitonを第一候補に置くと総額を下げられます。ARM非対応のネイティブ拡張や商用ミドルウェアに依存する場合だけ、x86系（i／a接尾辞）を選ぶ切り分けです。ただし[R9g／R9gdの提供開始](https://aws.amazon.com/about-aws/whats-new/2026/08/amazon-ec2-r9g-and-r9gd-memory-optimized-instances-are-now-available/)が米国3リージョンとフランクフルトからだったように、Graviton5世代はリージョンが順に広がります。東京前提の案件では見積り前に提供状況を確認してください。 ## AWS CLIでEC2インスタンスを起動して停止するまでの実行手順 ここからは手を動かす部分です。コンソールのウィザードは項目が多く、どの設定が課金に効くのか見えにくいので、CLIの引数で最小構成を押さえます。 ### run-instancesとユーザーデータで1台起動する最小パラメータ 起動に要る引数は、AMI・インスタンスタイプ・キーペア・セキュリティグループ・サブネットの5つです。あわせてルートボリュームと名前タグを渡しておくと、あとから探す手間が減ります。指定できる引数の全体は[run-instancesのCLIリファレンス](https://docs.aws.amazon.com/cli/latest/reference/ec2/run-instances.html)にあります。 ``` aws ec2 run-instances \ --image-id ami-0abcdef1234567890 \ --instance-type m9g.large \ --key-name my-keypair \ --security-group-ids sg-0123456789abcdef0 \ --subnet-id subnet-0123456789abcdef0 \ --user-data file://user-data.sh \ --block-device-mappings "DeviceName=/dev/xvda,Ebs={VolumeSize=30,VolumeType=gp3}" \ --tag-specifications "ResourceType=instance,Tags=[{Key=Name,Value=web-01}]" ``` 渡している`user-data.sh`は起動時に一度だけ実行されるスクリプトで、cloud-initがrootとして走らせます（[ユーザーデータの仕様](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/user-data.html)）。次の4行を置けば、起動と同時にNginxが80番で応答します。 ``` #!/bin/bash dnf -y install nginx systemctl enable --now nginx echo "hello from EC2" | tee /usr/share/nginx/html/index.html ``` ### インスタンスの停止と削除でEC2の課金を止める確認コマンド手順 停止でコンピューティング料金は止まりますが、EBSとパブリックIPv4は残ったまま課金が続きます。放置されたCloud9環境の裏でこの状態が続いている例は、[AWS Cloud9の棚卸しと移行をCLIで進める手順](https://www.issoh.co.jp/tech/details/17722/)で扱っています。検証環境を畳むときは、インスタンス、ボリューム、アドレスの順に棚卸しします。 ``` # 起動中インスタンスをID・タイプ・状態だけで一覧する aws ec2 describe-instances \ --filters Name=instance-state-name,Values=running \ --query "Reservations[].Instances[].[InstanceId,InstanceType,State.Name]" \ --output table # 停止（コンピューティング料金は止まる。EBSの課金は続く） aws ec2 stop-instances --instance-ids i-0123456789abcdef0 # どこにも付いていないEBSボリュームを洗い出して削除する aws ec2 describe-volumes \ --filters Name=status,Values=available \ --query "Volumes[].[VolumeId,Size,VolumeType]" --output table aws ec2 delete-volume --volume-id vol-0123456789abcdef0 # 未関連付けのパブリックIPv4（Elastic IP）を解放する aws ec2 describe-addresses \ --query "Addresses[?AssociationId==null].[AllocationId,PublicIp]" --output table aws ec2 release-address --allocation-id eipalloc-0123456789abcdef0 ``` インスタンスを削除しても、既定ではルート以外のボリュームが残ります。請求のEC2-Other項目が想定より大きいときは、statusがavailableの孤児ボリュームと未関連付けのElastic IPを疑ってください。2024年2月からは使用中のEIPにも課金されるため、[Elastic IPの料金と遊休EIPをCLIで洗い出す手順](https://www.issoh.co.jp/tech/details/17995/)で全リージョンの一覧を取ってから整理すると漏れがありません。 ## Amazon EC2の5つの料金モデルとコスト削減の実務ポイント EC2のコストは、同じインスタンスでも購入オプションの選び方で数倍変わります。稼働パターンを読み、モデルを組み合わせるのがコスト設計の起点です。[公式の料金ページ](https://aws.amazon.com/ec2/pricing/)はこの5つに加え、GPUを日付指定で先に押さえる機械学習向けのCapacity Blocks for MLも並べています。課金の粒度は全オプション共通で1秒単位・最低60秒です。 ### オンデマンド・Savings Plans・リザーブドの使い分け オンデマンドは秒単位（最小60秒）の従量課金で、先払いも長期契約も不要なため、検証や短期のスパイク対応に向きます。定常稼働が読める本番環境では、1年または3年の使用量コミットで効くSavings Plansに寄せます。割引率は2種類で差があり、リージョンやインスタンスファミリーをまたいで使えるCompute Savings Plansが最大66%、特定の条件に固定するEC2 Instance Savings Plansが最大72%です（[Savings Plansの料金](https://aws.amazon.com/savingsplans/compute-pricing/)・2026年9月時点）。 構成が固まらないうちに72%側へ寄せると、ファミリーを変えた瞬間にコミットが浮きます。まずCompute側で66%を取り、稼働タイプが固まってからEC2 Instance側へ差し替える順序が安全です。従来型のリザーブドインスタンスも同様の割引ですが、柔軟性の高いSavings Plansを基本に据え、常時動かす土台部分をコミットで固める設計が定石になります。 | 購入オプション | 割引の目安 | 向く用途 | | ------------- | ---------- | ------------ | | オンデマンド | 割引なし（従量） | 検証・短期・スパイク | | Savings Plans | 最大66〜72%削減 | 定常稼働の本番 | | スポット | 最大90%割引 | 中断可の並列処理 | | キャパシティ予約 | 枠の確保（別途課金） | 需要期の確実な確保 | | 専有ホスト | 物理占有・BYOL | ライセンス持込・要件対応 | ### スポットインスタンスでコストを削るバッチ処理と中断リスクへの備え スポットインスタンスは、AWSの余剰キャパシティをオンデマンド比 最大90%引きで使える仕組みです。ただしキャパシティが逼迫すると2分前の通知で中断されるため、途中で止まってもやり直せる処理に限って使います。具体的には、分散バッチ、CI/CDのビルド、機械学習の学習ジョブ、動画エンコードなどが好適です。 中断時の挙動は終了・停止・休止から選べます。休止を指定した場合だけは処理が即座に始まるので、2分の猶予がありません（[スポットインスタンスの中断通知](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-instance-termination-notices.html)）。通知はEventBridgeとメタデータの両方に出ます。公式が勧めるチェック間隔は5秒で、IMDSv2からは次のように読みます。 ``` TOKEN=$(curl -X PUT "http://169.254.169.254/latest/api/token" \ -H "X-aws-ec2-metadata-token-ttl-seconds: 21600") curl -s -H "X-aws-ec2-metadata-token: $TOKEN" \ http://169.254.169.254/latest/meta-data/spot/instance-action # 中断予定が無い間は HTTP 404 が返る # 返り値の例: {"action": "stop", "time": "2026-09-06T08:22:00Z"} ``` actionを受け取ったらチェックポイントを保存して離脱する、Auto Scalingでスポットとオンデマンドを混在させる。この2つを組み込めば、本番のコストを大きく圧縮できます。 ### Auto ScalingとELBで台数を伸縮させる運用コストの考え方 EC2は1台で固定運用するより、Auto Scalingで負荷に応じて台数を増減させ、ELB（ロードバランサー）で振り分ける構成にすると、過剰なスペックを常時抱えずに済みます。スポットとオンデマンドの比率は[混在インスタンスグループ](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-mixed-instances-groups.html)の設定で、オンデマンドの基数と割合として宣言する方式です。ELBの前段でドメイン名からトラフィックを振り分ける役割は、[Amazon Route 53とは？の解説](https://www.issoh.co.jp/tech/details/15471/)で扱うDNSルーティングが担います。 夜間や閑散期に台数を絞れば、その分の料金は圧縮できます。稼働後は[AWSのオブザーバビリティ実装を解説した記事](https://www.issoh.co.jp/tech/details/15297/)のようにCloudWatchで使用率を可視化し、実測に基づいてインスタンスサイズと台数を見直すと、コストを適正な水準に保てます。感覚で大きめのサイズに固定せず、メトリクスを見て縮める運用がEC2のコスト管理の勘所です。 ## Amazon EC2を採用すべき条件と各サービスとの使い分け ここで示す採用判断は明確です。EC2は自由度が高い反面、OSの管理やパッチ適用といった運用責任も伴うため、ワークロードによってはマネージド寄りの選択肢のほうが安く速くなります。EC2を自動で構成し標準的なWebアプリを手早く載せるPaaSの選択肢は[AWS Elastic Beanstalkの仕組みと採用判断を解説した記事](https://www.issoh.co.jp/tech/details/15610/)で確認できます。自社システムのどこにEC2を差し込むかを、条件付きで見極めてください。 ### Amazon EC2の採用が効くワークロードの条件と設計の勘所 採用が効くのは、OSやミドルウェアを自分で制御したい、定常的にサーバーが稼働する、既存のオンプレ資産をそのまま持ち上げたい、という条件が重なるときです。具体例は、常時稼働のWeb・APIサーバー、リレーショナルデータベース（RDSで足りない要件がある場合）、商用ミドルウェアやレガシーアプリのリフト、GPUを使う学習基盤といった用途が当てはまります。こうしたAWS上のインフラ構築を自社に取り入れるなら、[AWSを含むクラウドインフラ構築の相談窓口](https://www.issoh.co.jp/service/system/aws/)で構成の妥当性やコスト設計を相談するとよいでしょう。EC2は[クラウドネイティブの構成技術を整理した記事](https://www.issoh.co.jp/column/details/12999/)で言うところの土台のコンピューティング層に当たり、この上にコンテナやサーバーレスを重ねていく起点になります。マネージドのRDSで足りない要件をEC2上の自前DBで補うか判断する際は、[Amazon RDSの仕組みと料金・採用判断を解説した記事](https://www.issoh.co.jp/tech/details/15426/)と読み比べると選定しやすくなります。 ### ECS Fargate・Lambda・Lightsailへ寄せるべき場面 コンテナを動かしたいがサーバー管理をしたくないならECS Fargate、断続的なイベント処理で常時課金を避けたいならLambda、小規模サイトを定額で手早く立てたいならLightsailが向きます。EC2でこれらを無理に代替すると、運用負荷や過剰なスペック確保でかえって高コストになりがちです。それぞれの分岐点は、[FargateとEC2の違いを解説した記事](https://www.issoh.co.jp/tech/details/3304/)、[LambdaとEC2の使い分けを解説した記事](https://www.issoh.co.jp/tech/details/15407/)、[LightsailとEC2の違いを解説した記事](https://www.issoh.co.jp/tech/details/3383/)で数値を追って確認できます。 ### Amazon EC2を見送るべき場面とはまりやすい失敗パターン 見送るべきなのは、稼働がまばらで常時サーバーを起動しておく必要がない処理、コンテナ化済みでオーケストレーションだけ任せたいワークロード、そしてインフラ運用に人手を割けない小規模チームの定型用途です。これらをEC2で抱えると、パッチ適用やスケーリング設計の運用コストが積み上がります。もう1つの失敗パターンは、永続データをインスタンスストアに置いて停止時に消失させる、あるいはセキュリティグループを全開放して公開してしまう構成です。データはEBSやS3へ逃がし、通信は必要最小限のポートに絞る——この2点を前提に組めば、EC2の自由度を安全に扱えます。 ## よくある質問 Amazon EC2の導入検討で実装者から多く挙がる質問を、一次情報に基づいて簡潔に整理します。 ### Amazon EC2とAWS Lambdaはどちらを選ぶべきですか？ 常時稼働してトラフィックを継続的にさばくならEC2、断続的でスパイクの大きいイベント処理なら常時課金のないLambdaが基本の分岐です。OSやミドルウェアを細かく制御したい場合や15分を超える長時間処理はEC2が向き、稼働がまばらな非同期処理はLambdaが総額で有利になります。ワークロードの稼働率と実行時間を軸に選定してください。 ### EC2の料金を安く抑えるにはどうすればよいですか？ 定常稼働する土台はSavings Plans（またぎが利くCompute側で最大66%、条件を固定するEC2 Instance側で最大72%）で削り、中断可能なバッチはスポットで最大90%引きを狙うのが基本です。あわせてGraviton（ARM）系への移行で単価を下げ、Auto Scalingで閑散時の台数を絞ると総額が下がります。まずCloudWatchで使用率を実測し、過剰なサイズを縮めるところから始めるのが確実です。使用率からの適正サイズ提案を自動化するなら、[AWS Compute Optimizerの推奨](https://www.issoh.co.jp/tech/details/15632/)で候補を棚卸しすると早くなります。 ### インスタンスを停止すると料金はかかりませんか？ インスタンスを停止するとコンピューティング料金は止まりますが、アタッチされたEBSボリュームには保存分の料金が発生し続けます。パブリックIPv4アドレスも、使用中かアイドルかを問わず1個0.005 USD／時が課金対象です。完全に費用を止めるには、EBSやスナップショットまで含めて削除するか、不要なリソースを解放する必要があります。EC2にマウントする共有ファイルストレージが要る場合は、[Amazon FSxとはの記事](https://www.issoh.co.jp/tech/details/15463/)で選び分けを確認できます。 ### インスタンスタイプはどう選べばよいですか？ まず必要なメモリ量からサイズの目安を決め、次に用途でカテゴリを絞ります。Web・APIは汎用（M・T系）、CPU負荷の高い処理はコンピューティング特化（C系）、大容量メモリはメモリ特化（R系）が起点です。2026年9月時点ならGraviton5世代のm9g・c9g・r9gが各カテゴリの新顔で、ARM非対応の依存がある場合のみx86系を選ぶと、コストと互換性のバランスが取れます。 ### EC2とオンプレミスのサーバーは何が違いますか？ オンプレは物理サーバーの調達・設置・保守を自社で担うのに対し、EC2は数分でスペックを決めて起動し、不要になれば止めて費用を抑えられます。ハードウェアの故障対応やデータセンター運用はAWS側が担うため、利用者はOSより上のレイヤーへ集中できる点が違いです。一方でOSのパッチ適用や構成管理は利用者の責任範囲に残るため、その運用体制は自前で用意します。 ## 関連記事 - [クラウドネイティブとは？CNCFの定義・構成技術と導入判断を解説](https://www.issoh.co.jp/column/details/12999/)：EC2が土台となるクラウドネイティブ全体の構成技術を整理した上位概念の記事 - [AWS Fargateとは？EC2との違い・料金を解説](https://www.issoh.co.jp/tech/details/3304/)：コンテナ運用でEC2とFargateのどちらを選ぶかの判断軸 - [AWS Lambdaとは？仕組み・料金体系と採用判断を解説](https://www.issoh.co.jp/tech/details/15407/)：断続的なイベント処理でEC2とサーバーレスを使い分ける基準 - [AWS Lightsailとは？EC2との違い・料金・始め方を解説](https://www.issoh.co.jp/tech/details/3383/)：小規模サイトでEC2とLightsailのどちらが適するかの比較 - [インスタンスとは？クラウドの仮想サーバーを領域別に解説](https://www.issoh.co.jp/tech/details/13576/)：EC2インスタンスの前提となる仮想サーバーの概念整理 - [リザーブドインスタンスの購入判断と適用条件｜AWS CLIで割引を試算する手順](https://www.issoh.co.jp/tech/details/17757/)：オンデマンド以外の料金モデルで長期稼働分の支出を下げる判断まで進めたい場合に --- 出典: [Amazon EC2とは？仕組み・インスタンスタイプと料金モデル・採用判断を実装者目線で解説]()（株式会社一創）