フューチャー技術ブログ公開のAWS設計ガイドラインを読み解く：クラウドアーキテクチャのベストプラクティス

2025年12月15日DB,インフラ,セキュリティ,データベース,命名規則

お疲れ様です！IT業界で働くアライグマです！

「AWSの設計って、結局どこまでやればいいんだろう…」
「Well-Architectedフレームワークは読んだけど、実際のプロジェクトでどう適用すればいいかわからない」

こんな悩みを抱えているエンジニアやPjMの方は多いのではないでしょうか。

先日、フューチャー技術ブログで「AWS設計ガイドライン」が公開され、大きな話題になりました。
このガイドラインは、実際のプロジェクトで培われたベストプラクティスを形式知化したもので、AWS Well-Architectedフレームワークを補完する実践的な内容になっています。

私自身、PjMとして複数のAWSプロジェクトに関わってきましたが、設計フェーズで「どこまで作り込むか」の判断に迷うことが多々ありました。
このガイドラインは、そうした判断の拠り所として非常に有用です。

本記事では、公開されたAWS設計ガイドラインの要点を整理し、実際のプロジェクトでどう活用できるかをPjM視点で解説します。

Contents

1. AWS設計ガイドラインの全体像と背景
- 1.1. ガイドライン策定の目的
- 1.2. Well-Architectedフレームワークとの関係
2. ネットワーク設計のベストプラクティス
3. IAM設計と権限管理のパターン
- 3.1. IAMロールの設計方針
- 3.2. IAMポリシーの粒度設計
4. 運用設計とコスト最適化
- 4.1. 監視・ログ設計のベストプラクティス
- 4.2. コスト最適化の設計パターン
5. まとめ
- 5.1. 厳しめIT女子アラ美による解説ショート動画はこちら

AWS設計ガイドラインの全体像と背景

フューチャー技術ブログで公開されたAWS設計ガイドラインは、同社の有志メンバーによって作成されたもので、実際のプロジェクト経験に基づくベストプラクティスを体系化しています。

ガイドライン策定の目的

このガイドラインが作られた背景には、以下のような課題がありました。

暗黙知の形式知化：ベテランエンジニアの頭の中にある設計ノウハウを、チーム全体で共有できる形にする
設計品質の底上げ：プロジェクトごとに設計品質がばらつくのを防ぎ、一定水準を担保する
レビュー効率の向上：設計レビュー時の観点を明確にし、レビューの質と速度を両立させる

私がPjMとして関わったプロジェクトでも、設計フェーズで「この設計で本当に大丈夫か」という不安を抱えることがありました。
特に、AWSの経験が浅いメンバーがいるチームでは、設計の妥当性を判断する基準が曖昧になりがちです。

このガイドラインは、そうした状況で「まずここを押さえておけば大きく外さない」という指針を提供してくれます。

Well-Architectedフレームワークとの関係

AWS公式のWell-Architectedフレームワークは、クラウドアーキテクチャの設計原則を6つの柱（運用上の優秀性、セキュリティ、信頼性、パフォーマンス効率、コスト最適化、持続可能性）で整理した包括的なガイドです。

一方、今回公開されたガイドラインは、Well-Architectedフレームワークを前提としつつ、より具体的な設計判断に踏み込んでいます。
「VPCのCIDRブロックはどう設計するか」「IAMポリシーはどこまで細かく設定するか」といった、実装レベルの指針が含まれているのが特徴です。

AWS設計の基本を体系的に学びたい方には、実践Terraform　AWSにおけるシステム設計とベストプラクティスがおすすめです。Terraformを使ったインフラ構築を通じて、AWSのベストプラクティスを実践的に学べます。

関連記事として、AWSアンチパターン設計・運用ガイドも参考になります。

ネットワーク設計のベストプラクティス

ガイドラインの中でも特に重要なのが、VPCを中心としたネットワーク設計です。
ネットワーク設計は後から変更しにくい部分なので、最初の設計が重要になります。

VPC設計の基本方針

ガイドラインでは、VPC設計について以下のような方針が示されています。

CIDRブロックの余裕：将来の拡張を見越して、十分な大きさのCIDRブロックを確保する（/16推奨）
サブネット分割の考え方：パブリック/プライベートの分離、AZ分散、用途別の分離を基本とする
マルチアカウント戦略：本番/開発/ステージングでアカウントを分離し、セキュリティ境界を明確にする

私のプロジェクト経験では、CIDRブロックを小さく設計してしまい、後からサブネットを追加できなくなったケースがありました。

ケーススタディ：CIDR設計の失敗と改善

あるECサイトのAWS移行プロジェクトで、私はPjMとして設計レビューに参加していました。

状況（Before）：当初、VPCのCIDRブロックを/24（256個のIPアドレス）で設計していました。
サービス開始時点では、EC2インスタンス10台、RDS 1台、ElastiCache 1台程度の小規模構成で、使用IPアドレスは約50個だったため、十分だと判断していたのです。

行動（Action）：サービス開始から8ヶ月後、月間PVが10万から80万に増加し、オートスケーリングでインスタンス数が10台から最大40台に増加。
さらにマイクロサービス化の要件が追加され、新しいサブネットが5つ必要になりました。
しかし、/24のCIDRブロックでは新規サブネットを切り出す余地がなく、VPCの再構築が必要になりました。

結果（After）：VPC移行に約3週間（工数15人日）、追加コスト約150万円が発生しました。
この経験から、私のチームでは新規VPC設計時に必ず/16（65,536個のIPアドレス）を確保するルールを設けました。
以降の5プロジェクトでは、同様の問題は発生していません。

「今は小規模だから」と思っても、サービスが成長したときに困らないよう、最初から余裕を持った設計にしておくことが重要です。

セキュリティグループとNACLの使い分け

ネットワークセキュリティの設計では、セキュリティグループとネットワークACL（NACL）の使い分けが重要です。

# セキュリティグループの設計例
SecurityGroup:
  # アプリケーション層
  AppSecurityGroup:
    Inbound:
      - Protocol: TCP
        Port: 443
        Source: ALBSecurityGroup  # ALBからのみ許可
    Outbound:
      - Protocol: TCP
        Port: 5432
        Destination: DBSecurityGroup  # DBへのみ許可

  # データベース層
  DBSecurityGroup:
    Inbound:
      - Protocol: TCP
        Port: 5432
        Source: AppSecurityGroup  # アプリからのみ許可
    Outbound:
      - Protocol: -1
        Destination: 0.0.0.0/0  # 必要に応じて制限

ガイドラインでは、セキュリティグループを主軸とし、NACLはサブネット単位での追加的な制御に使うことが推奨されています。
セキュリティグループはステートフルで管理しやすく、NACLはステートレスで設定が複雑になりがちだからです。

VPC設計の詳細については、AWSオンボーディングテンプレートVPCガイドで詳しく解説しています。

インフラ設計の基礎を固めたい方には、インフラエンジニアの教科書が参考になります。

IAM設計と権限管理のパターン

IAM（Identity and Access Management）は、AWSセキュリティの根幹をなす部分です。
ガイドラインでは、最小権限の原則を守りつつ、運用しやすいIAM設計のパターンが紹介されています。

IAMロールの設計方針

ガイドラインで推奨されているIAMロールの設計方針は以下のとおりです。

サービスごとにロールを分離：Lambda、ECS、EC2など、サービスごとに専用のIAMロールを作成する
環境ごとにポリシーを分離：本番/開発で異なるポリシーを適用し、開発環境での誤操作が本番に影響しないようにする
タグベースのアクセス制御：リソースタグを活用して、動的にアクセス制御を行う

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject"
      ],
      "Resource": "arn:aws:s3:::my-bucket/*",
      "Condition": {
        "StringEquals": {
          "aws:ResourceTag/Environment": "${aws:PrincipalTag/Environment}"
        }
      }
    }
  ]
}

上記の例では、プリンシパル（実行者）のEnvironmentタグと、リソースのEnvironmentタグが一致する場合のみアクセスを許可しています。
これにより、開発環境のロールが本番環境のリソースにアクセスすることを防げます。

IAMポリシーの粒度設計

IAMポリシーをどこまで細かく設定するかは、セキュリティと運用負荷のトレードオフになります。

私のプロジェクト経験では、最初から細かすぎるポリシーを設定してしまい、新機能追加のたびにポリシー修正が必要になったケースがありました。
ガイドラインでは、以下のようなアプローチが推奨されています。

初期フェーズ：やや広めの権限で開始し、CloudTrailでアクセスログを収集する
安定フェーズ：IAM Access Analyzerを使って、実際に使われている権限を分析する
最適化フェーズ：分析結果に基づいて、不要な権限を削除していく

このアプローチにより、「権限が足りなくて動かない」というトラブルを避けつつ、段階的に最小権限に近づけることができます。

セキュリティ設計の詳細は、Kubernetesセキュリティ強化ガイドも参考になります。

IAMやセキュリティの設計パターンを深く学びたい方には、ゼロトラストネットワーク［実践］入門がおすすめです。

運用設計とコスト最適化

設計ガイドラインでは、構築時の設計だけでなく、運用フェーズを見据えた設計についても言及されています。

監視・ログ設計のベストプラクティス

運用を見据えた監視・ログ設計のポイントは以下のとおりです。

CloudWatch Logsの集約：複数サービスのログを一元管理し、横断的な分析を可能にする
メトリクスの標準化：カスタムメトリクスの命名規則を統一し、ダッシュボードの再利用性を高める
アラート設計：アラート疲れを防ぐため、重要度に応じた段階的なアラート設計を行う

私のプロジェクトでは、アラートを細かく設定しすぎて、オンコール担当者が疲弊してしまったことがありました。
ガイドラインでは、「即時対応が必要なもの」「翌営業日対応でよいもの」「傾向監視のみ」といった分類を明確にすることが推奨されています。

コスト最適化の設計パターン

AWSのコスト最適化は、設計段階から考慮しておくことが重要です。

リザーブドインスタンス/Savings Plans：安定稼働するワークロードには、1年または3年のコミットメントで割引を適用する
スポットインスタンスの活用：バッチ処理やCI/CDなど、中断耐性のあるワークロードにはスポットインスタンスを活用する
オートスケーリングの適切な設定：需要に応じてリソースを増減させ、過剰プロビジョニングを防ぐ

# オートスケーリング設定例
AutoScalingGroup:
  MinSize: 2
  MaxSize: 10
  DesiredCapacity: 2

  ScalingPolicies:
    # CPU使用率に基づくスケーリング
    - PolicyType: TargetTrackingScaling
      TargetTrackingConfiguration:
        PredefinedMetricSpecification:
          PredefinedMetricType: ASGAverageCPUUtilization
        TargetValue: 70.0
        ScaleInCooldown: 300
        ScaleOutCooldown: 60

コスト最適化の詳細については、AWS Lambdaサーバーレスコスト最適化で詳しく解説しています。

運用設計やコスト管理を体系的に学びたい方には、Kubernetes完全ガイド第2版が参考になります。Kubernetesの運用ノウハウは、AWSのマネージドサービス運用にも応用できます。