EC2

オンプレとAWSの比較

オンプミス環境の構築リスク
1. スペックの見積もり誤り
  - リソースの過不足による不要な費用負担が発生する可能性が高い
  - 機材の購入が必要となるため大がかりな変更作業とものによっては多額の費用がかかる
2. 機材の調達に時間がかかる
  - 社内の手続き、営業経由での発注など時間がかかる
AWSに変更した場合
1. スペックの見積もり誤り
  - 見積もり自体は必要だが、サービスイン後でもインスタンスの性能、数で調整が可能
  - 見積もり誤りから大きな費用損害が発生する可能性は低い
2. 機材の調達に時間がかかる
  - WEBから作成できるので迅速に調達できる

また繁忙期に合わせて増設、閑散期には減少するような運用であったり、期間限定で必要となる検証環境の用意などもAWSであれば容易に対応が可能。
オンプレでは機器を調達する都合上、どうしても余裕を持った機器選定を行う必要があるので、本来は不要なリソースをマージンとして抱える必要がある。

性能の考え方

EC2でインスタンスを構築する際、インスタンスタイプという形でインスタンスのスペックを選択できる
先頭の文字がインスタンスファミリーを示し、何に最適化されているか示しています
後ろの数字は世代を表し、基本的に大きいものが最新となる。

|種類|名前文字|特徴|
|:--|:--|:--|　　　　　　　　　　　　　　　　
|汎用|A,T,M|バランスの取れたコンピューティング、メモリ、ネットワークのリソースを提供し、多様なワークロードに使用できる|
|メモリ最適化|R,X,Z,U|メモリ内の大きいデータセットを処理するワークロードに対して高速なパフォーマンスを実現する|
|高速コンピューティ|P,G,F|ハードウェアアクセラレーター (コプロセッサ) を使用して、浮動小数点計算、グラフィックス処理、データパターン照合などの機能を、CPU で実行中のソフトウェアよりも効率的に実行する|
|ストレージ最適化|I,D,H|ローカルストレージの大規模データセットに対する高いシーケンシャル読み取りおよび書き込みアクセスを必要とするワークロード用に設計されています。
ストレージ最適化インスタンスは、数万 IOPS もの低レイテンシーなランダム I/O オペレーションをアプリケーションに提供するように最適化されいる|

インスタンスの性能を決めるほかの要素としてはEBS(Elastic Block Store)がある
EC2作成時にEBS最適化オプションを有効にすると、EBS用の帯域を通常のネットワーク帯域とは別に確保することができる
ネットワーク帯域、あるいはEBS用の帯域がディスクI/Oによって圧迫され遅延が発生する場合の対策として有効

難点として、EBS最適化オプションはすべてのインスタンスタイプで利用できる設定ではない
検討中のインスタンスタイプが対応しているかは公式で都度、確認すること

料金について

AWSは下記3つの利用形態がある

長期間の利用を約束することで利用料を大きく削減できるリザーブドインスタンス
- システムが安定稼働しており、そのまま稼働してほしい場合はこちらが安い
入札形式だが一時的に安く利用できるスポットインスタンス
- 安いので検証環境などで利用できる
従量課金型のオンデマンドインスタンス
- システムの構築段階はこちらを利用することが多い

オンデマンドインスタンス

基本的にEC2は従量課金型のサービスになる
これはオンデマンドインスタンスという利用形態になり、かかるコストは下記2点を基準にして決まる

インスタンスがRunning状態だった時間
- 詳細は公式のインスタンスライフサイクルの表を参照
- 【注意】EC2が停止中でもEBSの費用はかかります
  - 公式にも予想外の料金の回避という資料がありますので注意しましょう。、、
    - EC2とは違うけど、ElastiCacheを停止し忘れて1日で5千円近い出費をくらった私です…orz
Running状態だったインスタンスのインスタンスタイプ、AMI、起動リージョン

スポットインスタンス

AWSが時点で余らせたEC2リソースを入札方式で安く利用する方式
自分の予算額でスポットインスタンスに入札しておくと、必要になったタイミングでオークションが実施され、自分の入札額で購入できる場合はインスタンスを利用できる。
但し、AWS側の余剰リソースがなくなるとインスタンスが自動的に中断される。
稼働時間がAWS次第なので、本番環境として使うより、検証環境などとして利用することに向いている。

リザーブドインスタンス

長期間の利用を約束することで大きな割引を得られる利用形態