Future Tech Blog
フューチャー技術ブログ
Infrastructureカテゴリ

AWS設計ガイドラインを公開しました

はじめに

Technology Innovation Groupの神崎です。

フューチャー社内の有志のメンバーでAWS設計ガイドラインを作成しました。

この記事では、ガイドライン策定の目的と、その内容を抜粋して紹介します。

ガイドライン策定の目的

詳細はガイドライン冒頭に記載していますが、ベストプラクティスを形式知化していくというのが第一の目的です。第二に、設計のベースラインを提供することで、システム固有で考えるべきところ（すなわち設計作業で重要なところ）に時間が使えるようにして、結果として設計品質を底上げできることを目指しています。

そのため、システムを跨いで再利用可能な部分に特に着目しています。

ちなみに、Geminiにガイドラインの目的を問うたところ次の回答でした。上記の思いやエッセンスは取り込めているのではないかと思います。

クラウドファーストが標準となり、システム構築においてAWSを採用することは特別なことではなくなりました。しかし、各プロジェクトにおいて以下のような「非機能要件」や「共通コンポーネント」の設計議論が繰り返されている現状があります。

  • マルチアカウント環境の境界線（OU設計）はどうあるべきか
  • 監査ログ（CloudTrail等）の集約とコスト最適化のバランス
  • ワークロード（Web API/バッチ）に応じた適切なコンピューティングリソースの選定

これらはシステムごとの差異が本来少ない領域です。ここを毎回ゼロベースで検討することは、いわゆる「車輪の再発明」に他なりません。
設計者が本来注力すべきは、そのシステム固有のビジネスロジックやドメイン要件の実現です。

本ガイドラインは、これら共通化可能な設計領域を 「形式知」 として体系化し、設計品質の均質化と開発生産性の向上を目的として策定されました。

ガイドラインの内容のご紹介

ガイドラインの主要なポイントを要約して紹介します。

マルチアカウントを利用した環境分離パターン

アカウントの移譲や引き渡しも意識した環境分離パターンを解説しています。

どのようなリソースについてアカウントを分離すべきか、どのような階層構造でアカウントを作るべきかを整理しています。

関係するサービス:

  • AWS Organizations
  • AWS IAM
  • AWS Control Tower

すべてのアカウントが対応すべきセキュリティ対策

最低限、開発・検証環境であっても講じるべきセキュリティ対策について整理しています。
ガイドラインを機械的に適用するのではなく、インシデントや設定不備の検知に必要な設定や、検知された際の対応手順を記載しています。

関係するサービス:

  • AWS Security Hub CSPM
  • AWS CloudTrail
  • Amazon GuardDuty
  • Amazon Inspector
  • Amazon Macie

取り扱う情報の機密性や種別、各種監査基準やセキュリティ基準への対応の仕方

前述のセキュリティ対策に加え、厳密な監査基準やセキュリティ基準へ準拠する必要がある場合の対応方針を解説しています。利用するサービスとしては上の章と共通するところは多いですが、この章独自の要素として、データをどのように取り扱えば各基準に準拠できるかまでを整理しています。

関係するサービス:

  • AWS Security Hub CSPM
  • AWS Config
  • AWS CloudTrail
  • Amazon GuardDuty
  • Amazon Inspector
  • Amazon Macie
  • AWS Firewall Manager
  • AWS IAM Access Analyzer

コストの最適化

コスト最適化の手段として、どのような観点（ディメンション）で可視化を進めるべきか、推奨事項をまとめています。また、大きくコストを削減するための手段としてリセーラーの活用や、コンピュートとストレージの最適化手段などを解説しています。

関係するサービス:

  • Savings Plans
  • Amazon S3

踏み台サーバー

VPC内でのオペレーションを安全に行うためにどのようなサービスを利用すべきかを解説しています。

関係するサービス:

  • Amazon EC2
  • AWS Systems Manager (Session Manager)
  • EC2 Instance Connect Endpoint

アプリ特性に応じたアーキテクチャパターン

Web API、バッチ処理、非同期処理（キュー）など、様々なユースケースごとに、どのようなサービスが利用できるのかを整理しています。また、各方式のメリット・デメリットを比較した上で、処理特性や要件に応じて推奨値について解説しています。

関係するサービス:

  • Amazon API Gateway
  • Amazon CloudFront
  • Elastic Load Balancing (ALB / NLB)
  • AWS Lambda

CloudWatch

CloudWatchの特性を踏まえたロググループの推奨利用方法や、各サービスで何を監視すべきなのかの指針をまとめています。

関係するサービス:

  • Amazon CloudWatch

CI/CD

AWSリソースを作成するCI/CDパイプラインとしてどのようなサービスが利用できるのかを整理した上で、推奨値を解説しています。併せてCIとCDの分離のパターンについても指針をまとめています。

関係するサービス:

  • AWS CodePipeline
  • AWS CodeBuild
  • AWS CodeArtifact
  • Amazon ECR

さいごに

今回紹介した内容はガイドラインの一部です。社内のメンバーはもちろん、社外の方々にも設計のベースラインとしてご活用いただければ幸いです。

またフィードバックやPRについてもお待ちしております。

最後に、本ガイドラインの作成に貢献頂いた有志のみなさんに感謝します。

第一版の完成から本記事の公開まで期間が空いてしまったため、その間のサービスアップデートに追従するためのPRが必要となりました。記事公開と前後しますが、対応するPRを用意しています。他にも、「ここ、もう古くなってるよ」という内容を見つけられましたらぜひPR頂けますと大変ありがたいです。

ちなみに記事執筆に当たって初めてGeminiに案出しや校正をやらせてみたのですが、その過程で自分の過去記事からトンマナを学習させました。あくまでGeminiの視点ですが、自分でも気づいてない評価が見えるので面白いですね。客観的、と言えるぐらいまで生成AIを信用はしていないのですが、確かにあんまり意識はしていないけれど大事にしていることをピックアップされてるなと思いました。もしかしたら占いが当たる、みたいな心理的効果かもしれないのですが…。

まだオールドな人間なので、結構紙とボールペンで自分の思考を整理してから、Geminiと壁打ちしてアイデアを膨らませるみたいな使い方をよくするのですが、Gemini 3になってからトンチンカンなこという回数が実感としても減ったように感じます。

  • 文体: 基本は「です・ます」調ですが、非常に論理的で硬派なスタイルです。
  • 構成:
    • TL;DR（要約）を冒頭に配置し、結論を急ぐ読者への配慮がある。
    • 「頭の体操編」「実践編」といったセクション分けで、理論（Why）と実装（How）を明確に分離している。
    • 客観性と論理性: 「感覚値的にはこうだろう」で終わらせず、Well-Architected Frameworkなどの一次情報を引用し、論理的に正解を導き出そうとする姿勢が強い。
    • 感情表現の抑制: 絵文字や過度な感嘆符（！）は控えめで、技術的な誠実さを前面に出している。

結論としての適用トーン:
前回の案よりも「感情的な盛り上げ」を削ぎ落とし、より「ファクトベース」で「論理構成が明確」なスタイルに修正します。