yuuki oosaka

AWS高すぎ問題

現在円安で1ドル142円前後となっている。1ドル110円台にAWSは安い！とか思ってコスト削減を狙って社内システムをコストをかけて移行した企業は、円安により30%以上値上がりした結果、AWSへの移行を後悔されていると思う。

とはいっても改めてサーバーを社内システムにも戻すわけにはいかない。どのような対策が考えられるだろうか。

想定するアーキテクチャー（こうした構成がたくさんある想定）：

enyasu

①EC2を利用せずフルサーバーレス（SPA/S3/APIGateway/Lamda/Dynamodb）にアーキテクチャーを変更する

enyasu

JavaやASP.NETなどのWebアプリケーションは高価なインスタンスを必要とするEC2やBeanstalk、RDSなどのインスタンスで動かさざるを得ない。プログラムを根本的に書き換えることでインスタンスを利用しないフルサーバーレスアプリケーション（SPA/S3/APIGateway/Lamda/Dynamodb）を変更する。

メリット：大幅なコスト削減、信頼性の向上が可能。サーバーレスでは利用量に応じた支払いになる。一般的な業務アプリケーションの利用時間（年の1/4程度でリソース利用率30%）からするとサーバーにかかわるコストは1/10程度のコストまで削減可能
デメリット：アプリケーション再作成への初期投資がかかりすぎる。また、サーバーレスアーキテクチャーに通じたSEの調達も困難。
対象：更改タイミングなどが来ているアプリケーションの場合などにオススメ

②Autoscalingアーキテクチャーに変更して、サーバーをできる限り落とす。また、思い切ってSPOTインスタンスにしてしまう

enyasu

EC2の契約は通常の契約から大幅に割り引いた（90-80%値引き）SPOTインスタンスというものが存在する。SPOTインスタンスでサーバーを起動することでコストを大幅に削減することができる。ただし、SPOTインスタンスはAWSの要求によりサーバーが停止されるという大きなデメリットが存在する。これに対応するためサーバー停止時に再度起動するなどのAutoscalingアーキテクチャーの導入、停止をユーザーに検知させないためのALBを導入する。

メリット：EC2インスタンス利用量のコスト削減が可能。
デメリット：停止をユーザーに検知させないためALB利用のためのサーバー構成変更が必要。インスタンス停止イベントを受け取り、ALBへドレインする処理の追加の必要。
対象：複数サーバーでの分散が可能なWEBシステムにオススメ。一般的なWEBシステムではロードバランス可能な構成になっていることが多いので、こうした対策を導入するのは非常に容易なハズ

③DBサーバーのキャパシティをAutoscalingで可変にする。

enyasu

AWSのRDSサービスは利用量に応じた拡張を行う機能（Autoscaling）が存在している。これを利用してDBのキャパシティを固定せず、利用量がひくときはDBのキャパシティを開放することでコストを削減する。

メリット：RDS利用量のコスト削減が可能。
デメリット：特になし。あえて言うのであればDB構成変更のための試験が必要なくらい。
対象：全システムで導入すべき構成。

④DBサーバーのキャパシティをAurolaServlerlessで可変にする。

enyasu

AWSのRDSサービスは利用量に応じた拡張を行うサービス、AurolaServerlessが存在している。これを利用してDBのキャパシティを固定せず、利用量がひくときはDBのキャパシティを開放することでコストを削減する。

メリット：RDS利用量のコスト削減が可能。
デメリット：特になし。あえて言うのであればDB構成変更のための試験が必要なくらい。
対象：全システムで導入すべき構成。

結論

他にも様々なサーバー要件に従いコスト削減が可能なパターンがあると思うが、AWSでは工夫次第で様々な方法でコスト削減が可能な構成をとることができる。こうしたタイミングだけでなく、初期設計の段階でもコスト削減を考慮した構成を検討することで、様々なシステムのAWS化を推進することができるだろう。

例）全パターンを混ぜたサーバーコストが1/3程度になる想定の構成

enyasu