【要約】リプレイ機能付きオセロを作って、AWS（EC2/RDS）にデプロイしてみた [Qiita_Trend] | Summary by TechDistill
> Source: Qiita_Trend
Execute Primary Source
// Problem
インフラエンジニアが、アプリの実装やデプロイフローを把握できていない課題がある。インフラの知識があっても、アプリのライフサイクルを理解するのは容易ではない。具体的には以下の点が挙げられる。
- ・インフラ構築の知識はあるが、アプリの動作プロセスが不明。
- ・ローカルとクラウドの差異（接続設定や環境変数）の理解不足。
- ・AWSリソース、特にRDSの運用に伴うコスト管理の難しさ。
// Approach
開発者がアプリの実装からデプロイまでを完結させるため、段階的な構築アプローチを採用している。ローカルでの動作確認を経て、クラウド環境へ移行する構成である。
- ・ローカル環境：Node.jsとDockerを用いたMySQLの構築。
- ・インフラ構築：VPC、サブネット、IGWを含むネットワーク設計。
- ・デプロイ：EC2へのNode.js導入と、環境変数を用いたDB接続設定。
- ・DB構築：RDSへのMySQLクライアント経由でのテーブル作成。
// Result
開発者がアプリをAWS上に稼働させ、Webサービスとして公開することに成功した。これにより、インフラとアプリの連携に関する理解が深まった。
- ・EC2とRDSを連携させた動的なWebアプリケーションの実現。
- ・環境変数を用いたセキュリティベストプラクティスの実践。
- ・AWSリソースの停止・削除に関する運用上の注意点の明確化。
Senior Engineer Insight
> 学習用としては非常に体系的で優れた構成である。しかし、実戦投入の観点では、EC2をパブリックサブネットに配置する構成は避けるべきだ。本番環境ではALBをフロントに置き、EC2をプライベートサブネットへ隔離し、SSM Session Managerで管理するのが鉄則である。また、RDSの自動起動仕様によるコスト増は、運用フェーズで致命的なリスクになり得る。リソースの「停止」ではなく「削除」を徹底する意識が重要だ。