1. はじめに

今回は、仮想案件をもとに、自分なりにAWSの設計をしてみました。

これまで、他の人が設計した内容をもとに構築した経験はありましたが、要件から自分で考えて設計する経験はほとんどありませんでした。
そのため、設計する力と自分で考える力を身につけることを目的に、今回の実習を行いました。

実習は、Claudeに仮想案件を提示してもらい、それに対して自分で構成を考え、最後にフィードバックをもらう、という流れで進めました。

まずは、比較的シンプルな要件から始めました。

2. 実習

レベル1

仮想案件 :

こんにちは。私たちは小さなスタートアップで、会社紹介のウェブサイトを作ろうと思っています。ページ数は多くなく(会社紹介、サービス紹介)、ログイン機能やデータベースは特に必要ありません。また、通信はHTTPSを使用したいです。訪問者もそれほど多くない見込みですが、コストはできるだけ抑えたいです。AWSでどのように構成すればよいでしょうか?

自分の設計:

EC2にNginxをインストールし、Webサーバーとして利用する構成を考えました
ALB、NAT Gatewayを使用
Route 53で独自ドメインを設定
HTTPS化にはACMを使用

設計理由:

Webサイトを作るということで、まずWebサーバーが必要だと考えました。
そのため、なんとなく「EC2にLinuxとNginxを構築すればよいのではないか」と考えました。

フィードバック

良かった点

Route 53で独自ドメインを設定することや、ACMを利用してHTTPS化するという考え方自体は、正しい方向性でした

指摘された問題点

静的Webサイトのため、EC2は不要
EC2を使用しないため、ALBも不要
静的コンテンツはS3に配置することで、よりシンプルかつ低コストに構成可能
S3のコンテンツをHTTPSで配信するため、CloudFrontを利用
プライベートサブネット内にリソースがないため、NAT Gatewayも不要

改善後の構成
フィードバックをもとに、以下の構成に変更しました。

Route 53 → CloudFront → S3

Route 53：独自ドメインの名前解決
CloudFront：HTTPS通信、コンテンツ配信
ACM：SSL/TLS証明書
S3：静的コンテンツの保存

EC2、ALB、NAT Gatewayは使用せず、シンプルで低コストな構成としました。

レベル2

仮想案件 :

こんにちは。今回は社内で使う簡単な掲示板を作りたいと思っています。社員がログインして、お知らせや自由掲示板に投稿したり、コメントを付けたりできるようにしたいです。社員数は50人程度です。画像添付もできるようにしたいです。予算はそれほど厳しくありませんが、過剰な構成は避けたいです。

自分の設計:

EC2を2台構成とし、1台をAppサーバー(Linux)、もう1台をDBサーバー(PostgreSQL)として構築する構成を考えました。

社内利用のため、IGW・NAT Gatewayは不要と判断
社内LANとの接続にはSite-to-Site VPNを使用
画像などの添付ファイルはS3に保存
Appサーバーは1台のため、セッション共有は考慮しない
AWS Backupで日次バックアップを取得し、2～3世代を保存
App・DBサーバーを同じプライベートサブネットに配置

設計理由

社内システムのため、インターネットからのアクセスは不要と考え、社内LANとの接続にはSite-to-Site VPNを採用しました。
また、投稿やコメントなどの動的な処理とデータ保存が必要なため、AppサーバーとDBサーバーが必要だと考えました。
小規模なため、まずはEC2でシンプルに構築すればコストを抑えられるのではないかと考えました。
画像などの添付ファイルについては、EC2ではなくS3に保存する構成としました。

フィードバック

良かった点

社内LANからSite-to-Site VPN経由でアクセスする構成は、社内専用システムという要件に合っていた
添付ファイルをS3に保存する考え方は適切だった
AWS Backupによる日次バックアップも考慮できていた

指摘された問題点

IGW・NAT Gatewayを使用しないため、EC2からS3へのアクセスにはS3 Gateway Endpointを利用する
DBをEC2上に構築するだけでなく、運用負荷を抑えるためRDS(Single-AZ)を利用する方法も検討する
App用とDB用でサブネットを分離し、Security Groupによって必要な通信のみを許可する

改善後の構成
フィードバックをもとに、以下の構成に変更しました。

社内LAN → Site-to-Site VPN → App EC2 → RDS

App EC2：プライベートサブネットに配置
RDS（PostgreSQL）：DB用プライベートサブネットに配置
S3：画像などの添付ファイルを保存
S3 Gateway Endpoint：EC2からS3へプライベートにアクセス
AWS Backup：バックアップを取得
Security Group：App → DBなど、必要な通信のみを許可

インターネットから直接アクセスできない、社内利用向けのシンプルな構成としました。

レベル3

仮想案件 :

こんにちは。私たちはオンラインショップを運営しようとしています。一般顧客向けのサービスなので、トラフィックの変動が大きいと思います — 普段は少ないですが、セール期間中は急激に増える可能性があります。会員登録・ログイン機能があり、商品検索、カート、決済まで含まれます。そして私たちが一番心配しているのは、セール中にサイトがダウンすると売上に直接影響するので、それだけは絶対に避けたいということです。予算はトラフィックに応じて柔軟に使いたいです。

自分の設計

App：ECS Fargate
DB：RDS
セッション情報：ElastiCache for Redis
ALB、ACM、WAFを使用
マルチAZ構成

設計理由

セールなどによってアクセス数が大きく変動するため、ECS Fargateを採用し、必要に応じてタスク数を増減できる構成を考えました。

また、複数のタスクでセッション情報を共有できるよう、ElastiCache for Redisを採用しました。

インターネット公開システムのため、ALBでトラフィックを分散し、ACMによるHTTPS化、WAFによるWebアプリケーションへの攻撃対策を行います。

さらに、可用性を高めるため、複数AZを利用する構成としました。

フィードバック

良かった点

FargateとAuto Scalingを利用する考え方は、アクセス数が大きく変動する要件に適していた
Redisにセッション情報を分離することで、複数タスクでセッションを共有できるよう考慮できていた
マルチAZ構成は、可用性を重視する要件に合っていた

指摘された問題点

RDSはFargateのように、アクセス増加に合わせてコンピューティングリソースを簡単に水平スケールする仕組みではないため、DB側の負荷対策も検討する必要がある
静的コンテンツについては、S3 + CloudFrontを利用することで、ALBやFargateへの負荷を軽減できる
決済処理は自社ですべて構築するのではなく、外部の決済代行サービスとAPI連携する方法も検討する

改善後の構成
フィードバックをもとに、以下の構成を考えました。

User → CloudFront(WAF連携) → ALB → ECS Fargate → RDS

CloudFront + S3：静的コンテンツの配信
ALB：Fargateへのトラフィック分散
ECS Fargate：アプリケーションを実行
ECS Service Auto Scaling：アクセス量に応じてタスク数を増減
RDS（Multi-AZ）：データベース
ElastiCache for Redis：セッション情報を保存
ACM：HTTPS通信
WAF：Webアプリケーションへの攻撃対策
外部決済サービス：API経由で決済処理

アクセス増加に対してアプリケーションをスケールできるようにし、複数AZを利用することで、セール時にもできるだけサービスを継続できる構成としました。

3. 感想・学んだこと

今回実際にやってみて、知っているAWSサービスでも、要件を見たときにすぐに選択肢として出てくるとは限らないと感じました。

Level 1では、Webサイトが必要だからWebサーバーが必要だと思い、規模も小さいのでEC2を使えばいいかなと考えていました。そのため、S3は候補にも出てきませんでした。
静的コンテンツにS3を利用すること自体は知っていましたが、実際に設計しようとすると、その知識がすぐに出てこなかったです。

Level 2では、社内システムなのでインターネット接続は不要と考えたところまでは良かったのですが、IGWやNAT Gatewayをなくすことで、EC2からS3にもそのままではアクセスできなくなることまでは考えられていませんでした。
サービスを選ぶだけではなく、サービス同士がどのように通信するのかまで考える必要があると感じました。

Level 3では、AWS内の構成ばかり考えていて、決済機能を外部の決済サービスとAPI連携することは全く考えていませんでした。
AWSサービスだけではなく、外部サービスとの連携も含めてシステム全体を考える必要があると感じました。

今回の実習を通して、AWSサービスについて知識として知っていることと、実際の要件に合わせて設計に使うことは別だと感じました。

4. 次にやること

今回は比較的シンプルな仮想案件を複数使って、AWSサービスの選択や基本的な構成を考える練習をしました。

次回は、複数の案件を簡単に設計するのではなく、一つの仮想案件に対して、要件を確認しながら、もう少し時間をかけて設計してみたいと思います。