AWSの基本的な使い方で最初に出てくるものの一つに静的サイトの公開がある。簡単に構築でき、クラウドの魅力を即座に体験できるからだと思う。今回はそんな静的サイトの公開のベストプラクティスを考える。
静的サイト公開構成
静的サイトの公開といったら、初めに思い浮かぶのはS3である。S3にHTMLファイルを配置するだけでサイトの公開ができ、手間もコストもかからないというメリットがある。そのほかに挙げるとすると、EC2・ECSを利用して公開するという方法もある。ほかにもAmplify Hosting等の選択肢もある。それぞれの構成で静的サイトを公開するメリットデメリットをまとめてみた。
今回は以下のような条件の静的サイトを想定して各構成を考えてみる。
・0.3GBのサイト
・10GB/月転送(Getが100,000回)
・10万PV
・コストは東京リージョン想定
S3
S3で静的サイトを公開する場合は、S3に配置しPublicAccessを有効化するでも可能であるが、これだけだとHTTPS通信ができない、キャッシュ制御ができない、WAFが使えない等の不自由がある。そのためCloudFront をつけて初めて「本番運用できる静的サイト」になるといえる。
今回はS3+CloudFrontの構成をS3構成として考える。
メリット
①コストが安い
S3はEC2やECSと比較すると格段にコストが安くなり、ストレージ料金とリクエスト料金が発生する程度である。CloudFrontを導入しても、データ転送量がかかる程度で少量の金額となる。
②構成が単純
S3とCloudFrontを用意するだけど公開できるため、構成が単純で管理がしやすい。※CloudWatchやRoute53等の管理も必要になるが、これはほかの構成でも必要となるため今回の構成では考慮しない。
③運用が簡単
S3はフルマネージドなため、サーバーの管理が不要で、運用の負担を減らすことだできる。
④障害に強い
S3は可用性99.999999999%(11ナイン)とされており、可用性に優れており、万が一S3で障害が発生した場合でもCloudFrontがあるおかげで、キャッシュを返せたり等で応用が利く。
コスト
| 項目 | 基本価格 | 使用量 | 使用価格 |
|---|---|---|---|
| S3ストレージ | 0.025 USD/GB/月 | 0.3GB | 0.0075 USD(約1円) |
| リクエスト料金(S3) | 0.00037 USD / 1,000 リクエスト | 100,000リクエスト | 0.037 USD(約6円) |
| データ転送(S3) | 無料(S3→CloudFront) | 0 | 0USD |
| リクエスト料金(CloudFront) | 0.012 USD / 10,000 リクエスト | 10GB | 0.12 USD(19円) |
| データ転送(CloudFront) | 0.114 USD / GB | 100,000リクエスト | 1.14 USD(182円) |
| 合計 | 1.3045 USD(約208円) |
EC2
EC2での静的サイト公開は、S3に比べるとサーバーを自由にカスタマイズできるという強みがある。S3では実現できない機能も実装できる(認証や複雑なルーティングなど)。動的サイトの公開となると、Lambdaでの処理時間の問題等S3で実現できないことが多くなるためEC2が適していることが多くなるが、静的サイトに限った場合はEC2であるメリットはあまりない。
メリット
①Nginx/Apache等を自由にカスタマイズできる
複雑なリダイレクトやキャッシュの制御といったことを実現できる。認証もできるが、S3にCognitoを実装すると実現できるのでEC2専用のメリットとは言えない。
②SSRの使用ができる
SSR(サーバーサイドレンダリング)ができるため、PHPやNode.js等を使用する場合に優れている。※今回は静的サイトなので使用しない。
③VPC内で閉じたサイトを作れる
VPC内でPrivateNetworkを作成でき、そこにEC2を配置することでPublicに公開されないサイトを作れる。S3側でもPublicAccessを無効にすると似たようなことは可能だが、サイトの条件としてPublicな場所にサイトを配置することそのものが禁止されている場合等はS3が適さない場合がある。
デメリット
①OS・ミドルウェアの管理が必要
EC2は利用者が自らサーバーの管理が必要なため、OSパッチやセキュリティアップデートログローテションといったOS・ミドルウェアの管理が必要となる。
②コストが高い
EC2はアクセス頻度ではなく、使用するEC2の稼働時間によって課金される。静的サイトの場合常時稼働させる必要があるため、コストが高くなりやすい。
③セキュリティリスクの増加
VPC内で閉じたネットワークに配置できるものの、OS・ミドルウェアの管理を利用者がやるため、設定間違いや管理が疎かになった場合セキュリティリスクが増加する。
コスト
| 項目 | 基本価格 | 使用量 | 使用価格 |
|---|---|---|---|
| EC2インスタンス料金(t3.micro) | 0.0104 USD / 時間 | 24時間×30日 | 7.488 USD(1,198円) |
| EBS(gp3) | 0.08 USD / GB / 月 | 20GB | 1.6 USD(256円) |
| ALB使用料 | 0.0225 USD / 時間 | 24時間×30日 | 16.2 USD(2,592円) |
| LCU(Load Balancer Capacity Unit) | 0.008 USD / LCU / 時間 | 24時間×30日(1LCU) | 5.76 USD(922円) |
| データ転送 | 0.114 USD / GB | 10GB | 1.14 USD(182円) |
| 合計 | 32.188 USD(約5,152円) |
ECS
ECSには起動タイプがEC2とFargateの2種類がある。EC2を選択した場合、デプロイやスケール復旧といった面の自動化等でEC2単体よりも利便性は上がるが、コスト面はほとんど変わらないため、今回はFargateを使用した構成で考える。
メリット
①サーバーレスでEC2の管理が不要
EC2の管理が不要なため、OSパッチ等が不要で運用の負担軽減につながる。また、管理不足でセキュリティの脆弱性につながるといったこともなくなる。
②スケールが自動で安定している
Fargateはコンテナ単位でスケールし、タスクを増やすだけでよい。EC2のキャパシティを気にする必要もなく、障害時に自動復旧してくれる。
デメリット
①コストが高い
FargateはvCPUとメモリの使用時間でコストが変動する。部分的に使用する場合は安くなることがあるが、基本のコストが高いためEC2よりも高額になることが多い。
②静的サイトには過剰
Fargateはコンテナを使うものであり、静的サイト公開だけの場合、コンテナを使う必要はない。また、コンテナについての知識も多少は必要になるため、コンテナを理解している人がいない場合は運用等で負荷が上がる可能性がある。
コスト
| 項目 | 基本価格 | 使用量 | 使用価格 |
|---|---|---|---|
| vCPUコスト | 0.04045 USD / vCPU / 時間 | 0.25vCPU × 720h | 7.29 USD(約 1,166 円) |
| メモリコスト | 0.00442 USD / GB / 時間 | 0.5GB × 720h | 1.59 USD(約 254 円) |
| ALB使用料 | 0.0225 USD / 時間 | 24時間×30日 | 16.2 USD(2,592円) |
| LCU(Load Balancer Capacity Unit) | 0.008 USD / LCU / 時間 | 24時間×30日(1LCU) | 5.76 USD(922円) |
| データ転送 | 0.114 USD / GB | 10GB | 1.14 USD(182円) |
| 合計 | 32.0 USD(約5,100円) |
コスト比較
| 構成 | 想定価格 |
|---|---|
| S3+CloudFront | 1.3045 USD(約208円) |
| EC2 | 32.188 USD(約5,152円) |
| ECS(Fargate) | 32.0 USD(約5,100円) |
まとめ
S3を使用した構成が圧倒的にコストが安くなる。動的サイトの公開となるとSSRをしたい、長時間の接続をしたい等の条件がある場合はS3が向かないが、静的サイトの公開においてはS3を使用すのがいいといえる。認証をしたい場合や、簡単な動的サイトである場合でもAmazon CognitoやLambdaを使用することで実現可能。そのため、複雑ではないサイトの公開にはS3が最適といえる。
感想
静的サイトの公開にはS3が最適とはよく言われていると思う。今回ほかの構成と比較してみてやっぱりなという感じ。ただ、S3が向かないケースもあり、100%S3が向いているわけでもないってことを再確認できた。静的サイトと言ったらS3だと思っていいが、なぜS3が最適かというところを理解しておくのは大事ですね。
次回は静的サイト公開用のS3+CloudFrontの設計と構築を実施していこうと思います。お楽しみに、、