はじめに
まただいぶ時間が空きましたね(笑)
これまで、個人開発アプリをAWS上に公開するためのTerraform Packを作る過程を記事にしてきました。
前回までは、EC2単体でWebアプリを公開する構成や、SSM Session Manager、ALB、HTTPS、Auto Scaling Groupまわりを中心に整理してきました。
今回はそこから一歩進めて、EC2＋DB構成について書きます。
Webアプリを少し本格的に作ろうとすると、ほぼ確実にDBが必要になります。
ユーザー情報を保存したり、投稿データを残したり、問い合わせ履歴や注文状態を管理したり。
DBが入るだけで、一気に「ちゃんとしたアプリ感」が出ます。
ただ、最初は正直こう思っていました。
DBを追加すればいいだけでしょ？
ところが実際にTerraformで構成を作り始めると、思ったより考えることが多かったです。
特に悩んだのが、アプリケーション用EC2をどこに置くかです。
Public Subnetに置くのか
Private Subnetに置くのか
NAT Gatewayを使うのか
このあたりで、かなり頭を抱えました。
今回は、個人開発向けのEC2＋DB構成で、なぜ Public構成 と Private＋NAT構成 の両方を用意したのかを整理します。
今回作ったEC2＋DB構成
今回のEC2＋DB構成では、DBとして以下を選べるようにしました。
- RDS MySQL
- RDS PostgreSQL
- DynamoDB
さらに、アプリケーション側のネットワーク構成として、以下の2パターンを用意しました。
- 低コスト構成：Public構成
- セキュア構成：Private＋NAT構成
組み合わせとしては、合計6構成です。
| アプリ構成 | DB |
|---|---|
| Public構成 | RDS MySQL |
| Public構成 | RDS PostgreSQL |
| Public構成 | DynamoDB |
| Private＋NAT構成 | RDS MySQL |
| Private＋NAT構成 | RDS PostgreSQL |
| Private＋NAT構成 | DynamoDB |
最初は「DB付きなら全部Private Subnetでよくない？」と思っていました。
ただ、個人開発向けとして考えると、必ずしもそれだけが正解ではありませんでした。
全体構成のイメージ
今回の構成をざっくり整理すると、以下のような形です。
少し立体的に見ると、Web公開の入口、アプリケーション層、DB層、外部API連携がそれぞれ分かれます。
Webアプリでは、ユーザーからのアクセスだけでなく、アプリケーション側から外部へ通信したい場面があります。
例えば、決済APIを叩いたり、外部サービスと連携したり、OSパッケージを更新したり。
この「外へ出る通信」をどう扱うかで、Public構成とPrivate＋NAT構成の違いが出てきます。
Public構成とは
Public構成では、アプリケーション用EC2をPublic Subnetに配置します。
この構成では、EC2がPublic Subnetにいるため、Internet Gatewayを経由して外部へ通信できます。
ここで大事なのは、Public Subnetに置く = 何でも外部公開する ではないということです。
実際にはSecurity Groupで通信元やポートを制御します。
例えば、アプリケーションEC2への通信はALBからのHTTP通信に限定し、人間の接続はSSM Session Managerを利用してSSHポートを開けない、といった形です。
Public構成のメリット
Public構成のメリットは、主にコストと分かりやすさです。
- NAT Gatewayが不要
- 構成が比較的シンプル
- 外部APIへ通信しやすい
個人開発では、月額コストがかなり重要です。
NAT Gatewayは便利ですが、常時起動するとそれなりに料金がかかります。
まだ売上がない段階や、ポートフォリオ用途で公開したい段階だと、この固定費が地味に重いです。
「AWSを使いたいけど、毎月の料金が怖い」
これは個人開発あるあるだと思います。
自分もまさにそこを気にしながら構成を考えていました。
Public構成の注意点
一方で、Public SubnetにアプリEC2を置く以上、設計を雑にすると危険です。
特に気をつけるべきなのはこのあたりです。
- SSHを開けず、SSM Session Managerを使う
- Security GroupでALBからの通信に限定する
- DBはPublicにしない
Public構成は「何も考えなくてよい構成」ではありません。
あくまで、コストと運用負荷を抑える代わりに、Security GroupやSSMなどで最低限の安全性を確保する構成です。
Private＋NAT構成とは
Private＋NAT構成では、アプリケーション用EC2をPrivate Subnetに配置します。
ユーザーからの入口はALBに集約し、アプリケーションEC2はインターネットから直接到達できない場所に置きます。
EC2から外部APIやパッケージ取得などを行いたい場合は、NAT Gatewayを経由します。
Private＋NAT構成のメリット
Private＋NAT構成のメリットは、アプリケーションEC2をインターネットから直接触らせないことです。
- 公開入口をALBに集約できる
- EC2へ直接到達されにくい
- 本番運用向けとして説明しやすい
構成としてはこちらの方がきれいです。
ユーザーアクセスはALBで受ける。
アプリケーションEC2はPrivate Subnetに置く。
DBもPrivate Subnetに置く。
外部通信が必要な場合だけNAT Gatewayを使う。
この流れは、いかにも本番構成という感じがします。
Private＋NAT構成の注意点
一方で、NAT Gatewayにはコストがかかります。
個人開発でまだ売上がない状態だと、ここがかなり気になります。
また、構成としてもPublic構成より理解する要素が増えます。
Public Subnet、Private Subnet、Route Table、NAT Gateway、ALB、Security Group、DB Subnet。
学習としては非常に良いのですが、最初から全員にこの構成を強制すると、個人開発者には少し重くなると感じました。
Public構成とPrivate＋NAT構成の違い
2つを並べると、違いはかなり分かりやすくなります。
Public構成は、EC2がPublic Subnetにいるため外部通信しやすいです。
Private＋NAT構成は、EC2をPrivate Subnetに置きつつ、外部通信はNAT Gateway経由にします。
どちらもDBはPrivate側に置く想定です。
アプリEC2の置き場所と、外部通信の出し方が大きな違いです。
なぜ両方用意したのか
理由は、個人開発では セキュリティだけでなくコストも要件になる からです。
業務システムや大規模サービスであれば、Private Subnetにアプリを置き、NAT Gatewayを使い、監視や冗長化もしっかり入れる判断が自然だと思います。
ただ、個人開発の場合は事情が違います。
まだ売上がない段階で、毎月のAWS利用料だけが増えていくと、かなりしんどいです。
せっかくアプリを作っても、維持費が理由で止めたくなることもあります。
だからこそ、個人開発では「理想構成」だけではなく、「続けられる構成」も大事だと考えました。
| 構成 | 向いているケース |
|---|---|
| Public構成 | 低コストで始めたい、まず公開したい |
| Private＋NAT構成 | セキュリティを重視したい、本番運用を意識したい |
どちらが常に正解、という話ではありません。
扱うデータ、サービス規模、予算、運用できる人のスキルによって、選ぶべき構成は変わります。
そのため、今回のEC2＋DB構成では、あえて両方を用意しました。
DBをMySQL / PostgreSQL / DynamoDBから選べるようにした理由
DBも1種類に固定しませんでした。
MySQLは情報が多く、個人開発でも扱いやすいRDBです。
PostgreSQLは、PostgreSQL前提のアプリや、少し高度な機能を使いたい場合に選びやすいです。
DynamoDBは、注文管理や状態管理のようにアクセスパターンがある程度決まっている場合に向いています。
逆に、DynamoDBはRDBのようなJOINや柔軟な検索を前提にすると難しくなります。
なので、「DBなら何でも同じ」という扱いにはしませんでした。
利用者が作りたいアプリに合わせて選べるようにしたかった、というのが理由です。
DB付き構成で特に気をつけたこと
DB付き構成では、DBを追加するだけで考えることが一気に増えます。
特に気をつけたのはこの3つです。
- DBをPublicにしない
- Security Groupで接続元を絞る
- 接続手順と料金目安を用意する
アプリEC2がPublic構成であっても、DBまでPublicにする必要はありません。
基本的にはDBはPrivate Subnet側に置き、アプリケーションからのみ接続させる方針です。
また、DBのSecurity Groupでは、アプリケーションEC2からの接続だけを許可します。
MySQLなら3306、PostgreSQLなら5432です。
そして、DB付き構成は「作れた」だけでは足りません。
利用者が自分のアプリからDBへ接続できる必要があります。
そのため、接続手順、サンプルCRUD、料金目安も用意しました。
正直ここはかなり地味ですが、商品として考えるとかなり大事だと思っています。
実際に検証したこと
今回、EC2＋DB構成ではPublic構成とPrivate＋NAT構成、それぞれでMySQL、PostgreSQL、DynamoDBを検証しました。
合計6構成です。
検証では、Terraform applyが成功すること、EC2からDBへ接続できること、サンプルCRUDが動くこと、配布用ZIPに必要ファイルが含まれていることを確認しました。
特にDB接続まわりは、ドキュメントだけでは不安だったので、実際にAWS上で動かして確認しました。
「理論上できるはず」と「実際に接続できた」は、やっぱり安心感が違います。
個人開発では「正解」より「選べること」が大事
今回かなり感じたのは、個人開発向けのAWS構成では、必ずしも1つの正解に寄せきらない方がよいということです。
セキュリティだけを考えるなら、Private Subnetに寄せた構成を標準にしたくなります。
ただ、個人開発ではコストが重くなると続けられません。
逆に、コストだけを考えて簡単な構成にしすぎると、本番運用として不安が残ります。
だから今回は、低コストで始めたい人向けのPublic構成と、セキュリティを重視したい人向けのPrivate＋NAT構成を分けました。
個人開発では、アプリの種類も、予算も、技術レベルも、人によってかなり違います。
だからこそ、構成を選べるようにしておくことが大事だと思いました。
まとめ
今回は、個人開発向けのEC2＋DB構成で、Public構成とPrivate＋NAT構成を分けた理由を書きました。
Public構成は、低コストで始めやすく、外部API連携もしやすい構成です。
一方で、Security GroupやSSMを使って、EC2やDBを雑に公開しない設計が必要です。
Private＋NAT構成は、アプリケーションEC2をPrivate Subnetに置けるため、本番運用向けとして説明しやすい構成です。
ただし、NAT Gatewayのコストや構成理解の難しさがあります。
個人開発では、常に一番セキュアな構成だけが正解とは限りません。
もちろんセキュリティは大事です。
ただ、それと同じくらい、継続できるコスト感も大事です。
今回のEC2＋DB構成では、そのバランスを取るために、Public構成とPrivate＋NAT構成の両方を用意しました。
おまけ
今回の考え方をもとに、個人開発者向けのTerraform Packとして、EC2＋DB構成を作っています。
DBはMySQL、PostgreSQL、DynamoDBから選択できるようにし、ネットワーク構成も低コスト構成とセキュア構成を選べるようにしました。
まだまだ改善しながらですが、個人開発者がAWS上でアプリを公開しやすくなるように、少しずつ整備しています。
毎回思いますが、AWSは「作る」より「どう説明して、どう続けられる構成にするか」の方が難しいですね(笑)
宜しければホームページに構成図などを記載しているので見に来てください。