Well-Architected Framework #
1リージョンに付き 2つ以上のAZを利用する #
- 3つ以上はコスト効率が低下
- DB や EC2 を2つ以上の AZ に配置する
- 冗長性があるためダウンタイムを
- S3 でバックアップをリージョンで保存できる。 AZ にS3はない
VPC は1つの VPCでアーキテクチャを設計するのが基本 #
- 1つのVPCに1つのシステムを配置するのが基本
- 2つのVPCを使うのは開発環境、本番環境のように環境を分ける
ネットワークの分割 #
- マルチVPC方式
1つのVPCで複数のサブネットを分けることでネットワークを分ける - マルチアカウント方式
アカウントごとにVPCを作る
サブネット #
推奨 #
- サブネットのサイズは /24 以上の大きさが推奨されている
- 1 つのAZに対してパブリック・プライベートサブネットを 1 つずつ作成するのが基本
- よくあるのは 1 つのリージョンに 2 つの AZを配置し、各 AZ にパブリック・プライベートサブネットを 1 つずつ作る方法
- プライベートサブネットにはより多くのIPアドレスを配置する
- 一般的にプライベートサブネットにより多くのリソースを配置するため
インターネットの接続での分類 #
- パブリックサブネット
- トラフィックが Internet Gateway にルーティングされる
- インターネットとのアクセス制御に利用する
- プライベートサブネット
- トラフィックが Internet Gateway にルーティングされない
- インターネットから隔離することでセキュリティを高める
マルチリージョンの活用 #
- DB の RR を別リージョンに配置して、DB アクセスを分散する
Well-Architected Framework #
- AWS でインフラを構築するためのベストプラクティス。
6 つの設計原則 #
Reliability (信頼性) #
ポイント #
- インフラの障害復旧の自動化
- 復旧手順をテストで検証
- 需要変化に応じて水平スケーリングする
- キャパシティの推測をやめてオートスケーリングする(Auto Scaling など)
- モニタリングと自動化をする(Cloudwatch など)
対応領域 #
- 基盤 (IAM, VPC, Auto Scaling, ELB, CloudFormation) = 冗長性を保つ
- 変更管理(CloudTrail, AWS Config) = AWS のリソースの変更を管理
- 障害管理 = CloudWatch
Performance Efficiency (パフォーマンス効率) #
ポイント #
- システム要件を満たすリソースを効率化(e.g., 最適なインスタンスタイプを選ぶなど)
- システム要件やAWSの変化に応じてインフラを逐一効率化する
- 先端技術の一般化
- グローバル化
- サーバレス
- 頻繁に実験
対応領域 #
- コンピューティング(Auto Scaling, Lambda) = 効率よいパフォーマンスをスケーリング
- ストレージ(EBS, S3, Glacier, EFS) = 最適なストレージを選ぶ
- データベース(RDS, Dynamo DB, OpenSearch, Aurora, Redshift) = 最適なDBを選ぶ
- 容量と時間のトレードオフ(Cloudfront, ElastiCache) = キャッシュを使ってパフォーマンスをあげる
Security (安全性) #
設計事項 #
- 全レイヤーでセキュリティを摘要
- アクセス追跡・モニタリングの実施
- 条件ドリブンのアラート
- AWS 責任共有モデルに基づく対象範囲の保護に集中
- セキュリティのベストプラクティスの自動化
- ソフトウェアのセキュリティ設定
- セキュリティ対策してある AMI を作り、新サーバーに自動で摘要
- インフラ全体をテンプレ化して管理
対応領域 #
- データ保護(ELB, EBS, S3, RDS, KMS) = ELB でトラフィックを安全に、 ストレージは KMS で暗号化する
- 権限管理(IAM, MFA) = ユーザー管理
- インフラ保護(VPC) = ネットワークセキュリティ
- 検出制御(CloudTrail, CloudWatch, AWS GuardDuty, Amazon Inspector) = 常にモニタリング
Cost Optimization (コスト最適化) #
設計事項 #
- 不必要なリソース削減
- 費用の状況を確認
- マネージドサービスで運用コスト削減
- オンプレなどの固定コストをクラウドの変動コストに変換
- 使えば使うほど安くなるものを使う
- オンプレを完全撤廃
対応領域 #
- 需要と供給の一致(Auto Scaling)
- コスト効率の高いリソース(Reserved Instance, Spot Instance, Trusted Advisor)
- 支出の認識(CloudWatch, 見積もりツール)
- 継続的な最適化(AWS 最新情報, Trusted Advisor)
Operational Excellence (運用上の優秀性) #
計画変更や事故発生時の対応手順が自動化された文書化、テスト、レビューをされていること
設計事項 #
- コードに基づく運用実施
- 対応手順を定期的に変更する
- 予期せぬイベントへの応答テスト
- 運用イベントと障害から学ぶ
- 運用手順を常に最新のものにする
対応領域 #
- 準備(CloudFormation, Code シリーズ, Runbook, Playbook)
- 運用(System Manager, ServiceCatalog, CloudTrail, AWS Artifact, AWS GuardDuty, CloudWatch, AWS Config, API Gateway)
- 進化: 継続的な改善のために時間とリソースを割り当てる
Sustainability (持続可能性) #
設計事項(Trusted Advisor、ホワイトペーパーに書かれる) #
- 影響の把握
- サステナビリティ目標の設定
- 使用率の最大化
- コスト効率とかぶっている
- 効率的な新しいハード・ソフトウェアの提供を予測して設計する
- 新しいものの方が効率がよいので、設計の中で新しいものに変えやすくする
- マネージドサービスの使用
- サステナビリティのベストプラクティスを自動化する。
- e.g., S3 の intelligent tiering で効率のよいストレージに自動で格納してもらう
- クラウドワークロードのダウンストリームの影響を軽減
- AWS 側でアップグレードする必要性を減らす
AWS側の対応 #
- サーバー使用率
- 電力と冷却の効率
- カスタムデータセンターの設計
- 2025年までに100%再生可能エネルギーで AWS を運用
ユーザーの対応領域 #
- 効率的なストレージ技術の使用
- コード効率化(アルゴリズム、プログラミング言語)
- 効率的なデプロイ / スケーリング
- 効率的なアプリケーションデザイン
- データの効率的なデザイン活用
例: EC2(web server), RDS の構成 #
ポイント #
- WEB サーバーはプライベートサブネットに置くことでセキュリティを高める
- AZ を 2 つ、そして各 AZ にプライベート・パブリックサブネットを 1 つずつ作成
- EC2 インスタンス, RDS を各 2 台作成することで冗長性を高める
- S3 に RDS のバックアップを保存する
- NAT Gateway を各パブリックサブネットに 1 つずつ設置することで、どちらかに障害が起きてもサービス停止を防げる
例: オンプレと VPC を VPN 接続 #
ポイント #
- VPN Customer gateway が 2 つあり、冗長化されている
- VPN Customer gateway の接続が切れたら、もう一方の VPN Customer Gateway に自動的に接続を切り替える設定をすることで、サービス停止を防ぐ
例: 開発・検証・本番環境を構築する #
ポイント #
- 各環境に 1 つずつ VPC を作る
- こうすることで環境が互いに影響を与えづらくなる