気づいたらAWSの請求額が数百ドルを超えてた。ということはよくある。

そこで、なるべくお金がかからないように運用する方法を即効性がある運用編、開発編、セキュリティ編、その他編に分けて解説する。

運用編

基本的に運用編に書いてある内容を実践すれば、ほぼ課金されることはない。マウスクリックだけで簡単に実践できるので、ぜひともやっておきたい。

インスタンスを多重起動しない

まず、前提としてEC2やRDS等のインスタンスを多重起動してはいけない。

無料利用枠だから大丈夫？そんなわけない。確かにAWSを利用し始めて、1年間は確かに無料利用枠というものがある。

例えば、EC2であれば一ヶ月に750時間の無料稼働時間が用意されている。ただ、これはインスタンス2つで稼働してしまえば、2つのインスタンスが750時間の無料利用枠を消費していくので、月半ば辺りになれば課金が始まる。

つまり、2つのインスタンスを24時間稼働しっぱなしにして、無料扱いになるのは375時間、15日と12時間少しほどしかない。この多重起動するインスタンスが3つ、4つになるとどうなるだろうか？

このようにインスタンスが多重起動されていると、無料でいられる期間は10日、1週間、5日とどんどん短くなっていくので、多重起動はやめたほうがよい。

使わなくなったインスタンスは停止・終了する

常に1つのインスタンスだけ運用するのであれば問題はないが、いずれ2つのインスタンスを同時に動かさないといけないときが来る。その時のためにも、使っていないインスタンスはなるべく停止もしくは終了させたほうが良いだろう。

インスタンスを停止すると、割り当てられているIPアドレスが切り替わり、SSHのセキュリティをやり直さないといけないのが面倒であれば、いっそのことセキュリティ無くてもいいと思う。

SSHのセキュリティはsshd_configから公開鍵認証方式だけ許可をして、パスワードによる認証を拒否させた上で、ポート番号を適当なものに書き換えるなどだけでも十分セキュリティは堅い。定期的に停止させてしまうのであれば、IPアドレスによるAWSのセキュリティまでやらなくても大丈夫だろう。もしくは、課金される可能性はあるものの、ElasticIPを使って停止しても変わらないIPアドレスを割り当てる等の方法もある。

ただし、ElasticIPを割り当てている状態で、EC2を停止してしまうと、1時間につき0.005ドルかかる。そのため、ElasticIPを使っている状態の場合、EC2インスタンスの多重起動をやめるようにする。

終了した場合、記録されているデータは全て削除されるが、起動状態と停止状態を見間違えてしまうこともあるので、もうそのデータは使わない、もしくはすぐに再現できる状況であれば終了でもいいだろう。

無料利用枠を選ぶ

EC2やRDSを使う時、無料利用枠を選んでインスタンスを作成する。もしこの無料利用枠を選択しなかった場合、インスタンス作成と同時に即課金が始まるので十分注意する。

また、無料利用枠でも750時間を超過すると普通に課金されてしまうので、前項の繰り返しになるがインスタンスの多重起動は厳禁で。

Amazonの課金警告メール(英語)に注意する

無料利用枠を利用している状態で、上限の750時間に近づいた場合、AWS側からメールが届く。ただ、これは英語で書かれているため、ほとんどの人が気づかずに放置してしまうことが多い。

そしてこのメール、本当に直前(無料利用枠の85%使い切った時)にしかメールされない。だからメールが届いていることに気づいたときには、既に数ドル課金されてしまっていたということは珍しくない。

そのため、AWS登録に使ったメールアドレスの受信ボックスは常にチェックしておく。警告メールのドメインはamazon.comなので迷惑メールに振り分けられないように対処する。

Route53を使って独自ドメインを割り当てない

AWSで独自ドメインを割り当てるには、Route53を使用する必要がある。

これはホストゾーンの作成1件につき、一ヶ月で0.55ドルの課金が発生する。

無料利用枠期間中であったとしても、課金が始まってしまう。

そのため、可能な限り、独自ドメインを割り当てるのは、制作したウェブアプリを公開する直前にとどめておいたほうが無難と思われる。

ElasticIPでIPアドレスを取得したまま、インスタンスに未割り当てで放置しない

ElasticIPを使用することで、固定のIPアドレスを取得する事ができる。

だが、この固定IPアドレスをインスタンスに未割り当ての状態で放置してしまうと、僅かだが課金が発生してしまう。

無料利用枠期間中であったとしても、課金が始まってしまう。

そのため、ElasticIPでIPアドレスを取得したらすぐにインスタンスに割り当てるか、インスタンスに割り当てない場合はIPアドレスを解放する

毎日課金状況をチェックする

現在の課金状態は請求書で確認できる。

また、今後コストがどれぐらいかかるかはコスト管理にて確認できる

無料利用枠を選び、インスタンスの多重起動さえやらなければ課金される要素はほぼないが、念の為に1日1回は確認しておいたほうが良いだろう。利用料金等が改定されたり、セキュリティが破られて外部に不正利用され課金されるというケースも少なからずある。

開発編

開発編は利用料金には直結しないが、サーバーの負荷を減らすことで、課金しなくても使いやすくさせる。

【S3対策】アップロードできる最大容量とリクエストの制限

アップロードできるファイル要領とリクエストには制限をかけておく。

S3は無料利用枠としてストレージが5GBしか用意されていない。さらに、2万GETリクエスト、2千POSTリクエストしかリクエストできない。

つまり、S3に保存されているストレージが5GBを超えた場合、あるいは2万GETリクエスト、もしくは2千POSTリクエストが実行された場合、課金される。5GB以上のファイルをアップロードされた場合や、メディアファイルをS3に保管して、F5を2万回以上連打されるだけで課金されてしまうのだ。

さらに、15GBのデータの送信が行われるだけでも課金される。

こういった問題を防ぐためには、サーバーサイドでアップロードできるファイル容量の制限、リクエストの送信制限を行う必要がある。

【RDS対策】保存するデータ、レコード数の制限

RDSは20GBまでしか保存してくれない。とは言え普通に使っていればDBの使用容量が20GBを超過してしまうことはあまりないが、本格的な運用の事を考えるのであれば保存するデータに制限をかけたほうが良いだろう。

例えば、DBにデータを保存する時、一定量のレコードがあれば、超過したレコードは削除するなどが有効だ。他にも第三者に見られても問題ないデータはCookieにデータを保存させる方法も良いだろう。

もっとも、RDSはあえて使わず、EC2の中にDBのミドルウェアをインストールさせ、格納するという方法でも良いかも知れない。課金の面で管理しやすくなる。

【EC2対策】常駐スクリプトはなるべく動かさない

EC2でcrontabなどを使ってバッチ処理を実行したり、常駐スクリプトを走らせるなどは控えたほうが良いだろう。確かに実行するだけであればお金はかからないが、レスポンスは確実に遅くなる。

無料利用枠として利用できるt2.microのCPU性能はIntel Atom C2550の4分の1以下である。( 参照元:https://www.servethehome.com/testing-aws-t2-instances-linuxbench-benchmark/ )

これはRaspberry Pi4の5分の1とほぼ同じである。Raspberry Pi Zeroとかと大して変わらない。これほどの低性能なサーバーに無理をさせすぎるのは厳禁。

【EC2対策】処理の最適化(リストの内包表記、ループ時に関数実行しない等)

サーバーサイドの処理はなるべく最適化させる。これでレスポンスの遅さはある程度改善されるだろう。

例えばPythonであれば、リストの内包表記を使う。

word    = [ "","aaa","bbb","","","ccc"]
words   = [ a for a in word if a != "" ]

他にもループするたびにオブジェクトを作ったり、関数を実行したりしないようにする。

length  = len(word)
for i in range(length):
    print(word[i])

セキュリティ編

セキュリティを強化することで、不正利用を防ぐだけでなく、リクエスト数を低減させ課金されないようにすることができる。

SSHログイン用のシークレットキー等の適切な保管

当たり前だが、SSHログイン用のシークレットキーの保管は適切に。AWSアカウントのパスワード、APIなども適切に保管しておく。

くれぐれもGitHubにプッシュしてクラウド破産しないように。

ウェブアプリにアクセスできるIPアドレスの制限

S3はリクエスト数に上限がある。故にストレージにアクセスするEC2及びS3に直接アクセスできるIPアドレスには制限を加えておくべきである。

その他編

他にもAWSを使う上で安く済ませる方法などを並べる。

開発段階の性能テストがしたいだけならVirtualBoxを使う

これから公開する予定のウェブアプリがどれぐらいの性能を要求しているのかわからない時、いきなりEC2にデプロイして性能テストをするのではなく、VirtualBoxを使ったほうが良いだろう。

確かにネットワークの構造やリージョンなど、EC2とVirtualBox上のOSでは違うかも知れないが、ある程度の環境や性能をEC2に合わせることはできる。その上で大まかに必要な性能を考慮した上でEC2のプランを決めるのが妥当だと言える。

ウェブアプリにとってオーバースペックなプランを指定したとして、フルに使われていなくても高額料金が請求されるので、必要十分な性能に合わせるのはコストカットの上でも重要。

どれぐらいのリクエストが想定され、どれぐらいの性能が要求されるのか。これはローカルのVirtualBoxで予め確認しておいたほうが良い。

結論

このようにAWSには課金関係の罠が多い。

ウェブアプリをデプロイしたあとの管理をしっかり行わないと気づいた頃には利用料金がとんでもない状況になってしまう事はよくある。

そして定額制ではないので、利用料金が予測しにくい。利用料金予測機能などがあるが、こんなものを作るぐらいだったら利用料金を従量課金制ではなく定額制にしてもらいたいものだ。ただ、これは稼働率や性能を中心に考慮した結果であり、どうしてもサイトを落としたくない場合には有効ではある。(もっとも昨今のAWSは障害が頻発しているようだが)

もし、月の利用料金を一定に保ちたい、あるいは運用費用を中心に考慮したい場合はHerokuを使うと良いだろう。Webサーバーはホビープランであれば7ドルの課金で済む。