#はじめに
この記事は、実務未経験の大学生がロールプレイング形式でアーキテクチャの設計、構築を行うといった記事です。
よろしければ＜準備編＞もご覧くださいませ。

#前提条件の確認（ロールプレイング中）

インフラエンジニアは4人
4人でインフラの構築、運用を行なっていかなければならない
- 自動化が重要
構築までの期間は1ヶ月

#問題点
現環境の構築に携わったエンジニアにヒアリングを行い、現環境の問題点を整理しました。
Well-Architected フレームワークを元にアーキテクチャを考えた時に、現時点でのアーキテクチャでは以下の様な問題点が挙げられます。

###セキュリティ

通信にSSLが適用されていない
セキュリティグループが適切に設定されていない（全てがフルオープンになっている）
DDos等の一般的なセキュリティ対策を行なっていない
データの暗号化が行われていない
リソースに対する権限管理が曖昧である
DBの接続情報など、設定ファイルにハードコーディングされている

###信頼性

静的ファイルの保存先がEBSになっている
各リソースのスケーリングが行われていない
障害復旧の手順が決まっていない

###運用の優秀性

リソースの監視が行われていない
ログの収集、分析を行なっていない
デプロイが手動で行われている
パッチ適用、メンテナンスが手動で行われている

###コスト最適化

リソースのコストを把握出来ない

###パフォーマンス

DBのキャパシティ、パフォーマンスに対する懸念がある

#改善案
以上の問題点より、具体的な改善案を提案しました。

以下具体的な改善案です。

##セキュリティ

#####通信にSSLが適用されていない

ACM
- CloudFront、ALBに証明書の関連付けを行いHTTPS化を行う

#####セキュリティグループが適切に設定されていない（全てがフルオープンになっている）

VPC
- 通信の範囲に応じてSubnetを作成
- NAT Gatewayの作成、Route Tableを定義する
- セキュリティグループを用いて必要最小限のアクセスのみを許可する
Systems Manager
- Session Managerを用いてSSHログインを行う
Config
- セキュリティグループのSSH全開放をAWS Configによる自動修復によって修正する

#####DDos等の一般的なセキュリティ対策を行なっていない

CloudFront
- ディストリビューションの作成
- 特定地域からのアクセスをブロックする
- CloudFrontからのアクセスのみを許可（オリジンへの直接アクセスを禁止）
Inspector
- 脆弱性を評価
- Slackに通知を行う
AWS WAF
- WebACLの作成

#####データの暗号化が行われていない

RDS
- 通信の暗号化
KMS
- RDSのデータを暗号化
- EBSのボリュームを暗号化

#####リソースに対する権限管理が曖昧である

IAM
- IAMロールの管理、リソースへの適用

#####DBの接続情報など、設定ファイルにハードコーディングされている

Systems Manager
- Parameter Storeを用いてデータベースへの接続情報を保存、管理

###信頼性

#####静的ファイルの保存先がEBSになっている

S3
- サーバー間でのファイルの共有が可能、コスト、可用性、耐障害性の観点から静的ファイルの保管をS3で行う

#####各リソースのスケーリングが行われていない

ALB
- ターゲットグループの作成
- ALBの作成
- AutoScalingの有効化（検討）
- AutoHealingの有効化（検討）
Cloudwatch
- AutoRecoveryの有効化(検討)

#####障害復旧の手順が決まっていない

フェイルオーバー
- Route53
  - ヘルスチェックの有効化
  - フェイルオーバールーティングの実装
- CloudFront
  - カスタムエラーレスポンスとしてSorry Pageを実装
DRとしてパイロットライト
- VPC
  - インターリージョンvpcピアリングの実装
- RDS
  - クロスリージョンレプリカの配置
  - Lambdaを用いてマスターDBへの昇格を制御
- Cloudformation
  - 別リージョンにスタックをコピー
  - AMIのマッピング
スナップショット、AMIの管理
- AWS Backup
  - RDSのスナップショット
  - EBSのスナップショット
  - ゴールデンイメージの管理
  - バックアップイベントをSlackに通知

##運用の優秀性

#####リソースの監視体制が不十分

Cloudwatch
- RDSのメトリクスを監視
- EC2インスタンスのメトリクスを監視
  - CloudWatch Agentのインストール
- ELBのメトリクスを監視
- Cloudfrontのメトリクスを監視
- Cloudwatch Syntheticsを用いてサービス状況を監視
Personal Health Dashboard
- AWSの障害をSlackに通知
RDS
- イベントサブスクリプションによるRDSのイベントを通知
Trusted Advisor
- セキュリティの現状、不要なリソースの確認を行う
Security Hub /
- Security Standardの有効化
- Slackに通知を行う
GuardDuty /
- Slackに通知を行う

#####ログの収集、分析を行なっていない

S3
- VPC FlowLogの作成、S3にログの収集
- CloudFrontのアクセスログをS3に収集
- ELBのアクセスログをS3に収集
Athena/QuickSight
- アクセスログをAthena+QuickSightで分析&可視化
Systems Manager
- Session Managerの操作ログの収集
EC2
- ログの正当性を担保する為にTime Sync Serviceで時刻同期を行う
CloudWatch Logs
- ログの収集、ロググループの作成
- メトリクスフィルタによるログの監視
- CloudWatch Logs Insightsによるログの分析
Kinesis Firehose
- AWS WAFのログの収集

#####デプロイが手動で行われている

Code3兄弟
- Code3兄弟を用いたCI/CDパイプラインの構築

#####パッチ適用が手動

Systems Manager
- SSM Agentのインストール
- Patch Managerを用いたパッチの自動化
- RunCommand、State Managerを用いた再起動、メンテナンスの自動化

###コスト最適化

#####リソースのコストを把握出来ない

Cost Explorer
- コスト分配タグの設定
- CostExplorerを用いて、コストを確認
IAM（Organization）
- リソースに対して、コスト管理の為のタグ付けの強制
Budgets
- 予算を設定し、コストの管理を行う
- Slackへの通知

###パフォーマンス

#####DBのキャパシティ、パフォーマンスに対する懸念がある

RDS
- リードレプリカの配置
- MySQLをAuroraMySQLに移行
- クラスターエンドポイント、リーダーエンドポイントの実装(検討)
- 容量のスケーリングの有効化
ElastiCache
- Auroraと併用し、クエリ結果をキャッシング

#感想
アーキテクチャの設計が完了しました！
あとはこれを構築するだけです　（...だけ？）

アーキテクチャ図に3時間はかかっております