小さい会社のAWS環境を設計してみる｜何から考えればいい？
今回は、小さい会社のクラウド環境をAWSで設計するとしたら、何から考えて、どのように構成を決めるのかを考えてみます。
単純にAWSのサービスを並べるのではなく、
「社員20人程度の会社から、AWS環境を作ってほしいと言われた」
という想定で、実際に設計するときの流れに沿って考えていきます。
今回想定する会社
今回は、以下のような会社を想定します。
- 従業員10〜30人程度
- コーポレートサイトを運営している
- 業務用のWebシステムがある
- 専任のインフラ担当者はいない
- できるだけ運用コストを抑えたい
- 最低限のセキュリティは確保したい
小さい会社では、複雑な構成を作っても運用できなければ意味がありません。
そのため今回は、「安全性を確保しつつ、なるべくシンプルにする」ことを基本方針にします。
まず何から始めるのか
「AWS環境を作ってほしい」と言われても、いきなりVPCやEC2を作るわけではありません。
まずは、何をAWSで動かすのか、誰が利用するのか、どの程度の可用性やセキュリティが必要なのかを確認します。
例えば、今回の会社では次のように整理します。
| 確認すること | 今回の想定 |
|---|---|
| 動かすもの | コーポレートサイト、業務用Webシステム |
| 利用者 | 一般ユーザー、社員 |
| データ | DB、アップロードファイル |
| 公開範囲 | Webはインターネット公開、DBは非公開 |
| 可用性 | 一時的な停止は許容するが、長時間停止は避けたい |
| バックアップ | DBや重要なファイルは復旧できるようにする |
| セキュリティ | HTTPS、アクセス制御、操作ログを実施 |
| 運用 | 専任担当者がいないため、なるべく管理を減らす |
こうした要件を確認してから、AWSの構成を考えていきます。
PJごとに切り分けて考える
次に、会社全体を1つのAWS環境として考えるのではなく、PJ（システム）ごとに切り分けます。
今回であれば、
会社
├─ コーポレートサイトPJ
└─ 業務システムPJ
のように分けます。
コーポレートサイトと業務システムでは、利用者やデータ、必要なセキュリティ、障害時の影響などが異なるためです。
さらに必要であれば、PJの中を本番環境と開発環境に分けます。
業務システムPJ
├─ production
└─ development
まずPJごとに要件を整理し、その単位で必要なAWSサービスや構成を考えていきます。
PJごとにAWSサービスを選ぶ
PJを切り分けたら、それぞれの要件に合わせてAWSサービスを選びます。
例えばコーポレートサイトが静的なサイトであれば、
Internet
↓
Route 53
↓
CloudFront
↓
S3
のような構成が考えられます。
一方、業務用Webシステムでは、
Internet
↓
Route 53
↓
CloudFront
↓
ALB
↓
ECS / EC2
↓
RDS
＋ S3
といった構成が考えられます。
同じ会社のシステムでも、PJの要件によって必要なAWSサービスや構成は変わります。
「AWS環境だからEC2やRDSを用意する」のではなく、必要な機能から利用するサービスを決めます。
ネットワークを設計する
PJごとのAWS構成が決まったら、VPCやSubnetなどのネットワークを考えます。
例えば業務システムPJでは、次のような構成を考えます。
VPC
├─ Public Subnet
│ └─ ALB
│
└─ Private Subnet
├─ ECS / EC2
└─ RDS
インターネットからアクセスされるALBはPublic Subnetへ配置し、直接公開する必要がないアプリケーションやRDSはPrivate Subnetへ配置します。
特に、RDSをインターネットへ直接公開しないことが重要です。
Security Groupについても、必要な通信だけを許可します。
Internet
↓ HTTPS
ALB
↓ Application Port
ECS / EC2
↓ 3306
RDS
このように、どこからどこへの通信を許可するのかを整理します。
セキュリティを設計する
次に、AWSへのアクセスや各リソースのセキュリティを考えます。
最低限、以下のような対策を行います。
- MFAを設定する
- IAMを必要な権限に制限する
- Security Groupで必要な通信だけを許可する
- S3を不用意にPublicにしない
- HTTPSを利用する
- CloudTrailでAWSの操作履歴を確認できるようにする
必要に応じてGuardDutyやSecurity Hubなどを利用し、不審な挙動やセキュリティ上の問題を確認できるようにします。
また、PJが増えてきた場合は、AWSアカウント自体をPJや環境ごとに分けることも検討します。
バックアップを設計する
次に、障害や操作ミスが発生した場合にデータを復旧できるようにします。
RDSでは自動バックアップを設定し、重要なS3データについてはバージョニングを検討します。
EC2やEBSなどもバックアップが必要であれば、AWS Backupを利用してまとめて管理できます。
単に「バックアップを取る」だけではなく、何日前まで戻せればよいのか、どのくらい保存するのかもPJごとに決めます。
監視と通知を設計する
システムを作っても、障害に気付けなければ対応できません。
CloudWatchを利用して、CPU使用率、エラー、アプリケーションやAWSリソースの状態などを監視します。
異常を検知した場合は、SNSなどを利用してメールやSlackなどへ通知できるようにします。
専任のインフラ担当者がいない場合は、常にAWSコンソールを確認するのではなく、問題が起きたときに担当者へ通知される仕組みを作っておくことが重要です。
PJごとに運用方法を決める
AWS環境を作った後は、誰がどのように管理するのかも決めておきます。
| 項目 | 決めておくこと |
|---|---|
| デプロイ | 誰が、どの方法で実施するか |
| 監視 | 何を監視するか |
| 通知 | 誰に通知するか |
| バックアップ | どのくらい保存するか |
| 障害対応 | 誰が最初に確認するか |
| AWS変更 | コンソールかTerraformか |
同じ会社でもPJによって重要度や担当者が違うため、運用についてもPJ単位で考えます。
Terraformを利用する場合は、AWSコンソールで直接変更するのではなく、基本的にはTerraform側を変更してAWSへ反映します。
小さい会社だからこそ「やりすぎない」
AWSでは、セキュリティや可用性を高めようとすると、いくらでも複雑な構成を作ることができます。
しかし、小さい会社では予算だけでなく、運用できる人数も限られています。
そのため、「技術的に高度な構成」ではなく「実際に運用できる構成」を考えることも重要です。
例えば、最初から複雑なKubernetes環境や大規模なマルチアカウント構成を導入するのではなく、必要になった段階で拡張できるようにしながら、最初はシンプルな構成から始めます。
ただし、シンプルにすることと、すべてのPJを同じ環境へまとめることは別です。
構成はシンプルにする。ただし、PJごとの境界は意識する。
という考え方で設計します。
まとめ
小さい会社のAWS環境を設計するときは、いきなりVPCやEC2を作るのではなく、まず会社がAWSで何を動かしたいのかを整理します。
そのうえで、
要件確認 → PJごとに切り分ける → PJごとにAWSサービスを選ぶ → ネットワーク → セキュリティ → バックアップ → 監視・運用
という順番で考えていきます。
特に重要なのは、会社全体を1つの構成として考えるのではなく、PJごとに要件や構成を考えることです。
コーポレートサイトと業務システムでは、必要な可用性、セキュリティ、バックアップ、監視なども異なります。
PJごとの境界を意識しながら、コスト・セキュリティ・運用負荷のバランスを取り、実際に運用できる構成を作ることが重要です。
次回は、今回考えた業務システムPJを例に、実際にVPCやSubnetなどを作成していきます。