「なぜ RDS ではなく DynamoDB なのか」「なぜマルチリージョンにしないのか」。設計を持つ立場になると、こう聞かれる場面が増えます。答えが「AWS がそう勧めているから」「前のプロジェクトでそうだったから」では、聞いた側は納得できず、判断は見直せません。設計判断を根拠つきで説明できる状態とは、「何を得るために、何を捨てたか」を言える状態です。この記事は、その言い方の型と、AWS Well-Architected フレームワークを「観点の一覧」として使う方法を扱います。
この記事の結論
- 設計に「全部を満たす正解」はありません。判断とは、何かを得るために何かを捨てることで、捨てたものを言えないなら判断ではなく成り行きです。
- クラウドの設計で繰り返し出る天秤は3つ。可用性とコスト、疎結合と複雑さ、マネージドと自由度。
- AWS Well-Architected フレームワークの6本柱は「満たすべき基準」ではなく、見落としを防ぐ観点の一覧として使います。柱同士は引っ張り合うので、どれを優先したかを残します。
- 「なぜそのサービスか」の説明の型は、要件 → 選択肢 → 軸 → 決定 → 捨てたもの → 見直す条件の6つです。
- 判断は ADR に残し、見直す条件が満たされたら新しい ADR で置き換えます。間違いは消さず、変わった理由を残します。
判断とは「何を捨てるか」を決めること
設計の場面で「一番いい構成はどれですか」と聞かれたら、答えは「要件によります」です。これは逃げではなく、事実です。可用性を最大にすればコストが最大になり、変更の速さを最大にすれば統制が最小になります。すべての軸を同時に最大にする構成は存在せず、どの軸を優先するかを決めることが設計です。
判断を人に説明できないのは、たいてい「捨てたもの」を意識していないからです。「DynamoDB を選びました」だけでは、「RDS で得られたはずの何を捨てたのか」が伝わりません。「結合とトランザクションの柔軟さを捨てて、テーブル設計を先に固める代わりに、アクセスパターンが決まっている読み書きの性能とスケールの手間の少なさを取りました」まで言えて、初めて聞いた側は「その捨てたものは、うちの要件で許容できるか」を判断できます。
クラウドの設計で繰り返し出る3つの天秤
THREE TRADE-OFFS繰り返し出る3つの天秤
判断とは、何を得るために何を捨てるかを決めること
-
1.可用性 と コスト
冗長化の段階を上げるほど、止まらなくなり、費用と手間が増える。RTO・RPO を先に置く
-
2.疎結合 と 複雑さ
分けるほど独立して変えられ、部品と通信と障害の起き方が増える。分ける理由が言えるか
-
3.マネージド と 自由度
任せるほど運用が減り、細かい設定の自由が減る。自由度が要る理由が具体的に言えるか
1. 可用性とコスト
サーバーを1台から2台に、1つの AZ から2つの AZ に、1つのリージョンから2つのリージョンに。冗長化の段階を上げるほど、1か所の障害で止まらなくなり、同時にコストと運用の手間が増えます。
THE SCALE可用性とコスト
片方を上げれば、もう片方が下がる
可用性を上げる
- 複数 AZ に置く
- 複数リージョンに置く
- データを同期する
コストと手間が増える
- 台数分の料金
- 複製の遅延
- 切り替えの手順と訓練
支点は要件（RTO・RPO）。それを満たす最小の構成を選ぶ
| 構成 | 何に耐えるか | 増えるもの |
|---|---|---|
| 1 AZ・1台 | 何にも耐えない | なし（学習・検証向け） |
| 複数 AZ・複数台 | 1台の故障、1 AZ の障害 | 台数分の料金、ロードバランサ、データの同期 |
| 複数リージョン | 1リージョンの障害 | ほぼ2倍の料金、データの複製の遅延、切り替えの手順と訓練 |
「どこまで耐えるか」は、止まったときの損失で決めます。1時間止まって失うものが、複数リージョンの年間コストより小さければ、複数リージョンは過剰です。RTO（どれだけ早く戻すか）と RPO（どれだけのデータ損失を許すか）を要件として先に置き、それを満たす最小の構成を選びます。
AVAILABILITY LADDER可用性とコストの天秤
どこまで耐えるかは、止まったときの損失で決める
-
1 AZ
何にも耐えない
学習・検証向け。増えるものは無い
-
複数 AZ
1台の故障・1 AZ の障害に耐える
台数分の料金、ロードバランサ、データの同期
-
複数リージョン
1リージョンの障害に耐える
ほぼ2倍の料金、複製の遅延、切り替えの手順と訓練
2. 疎結合と複雑さ
1つの大きなアプリを、役割ごとに分けて（マイクロサービス）、キューやイベントでつなぐ。分けるほど、1つの変更が全体に波及しにくくなり、部分ごとに拡張できます。同時に、部品の数・部品間の通信・障害の起き方が増え、「どこで遅いか」を追うのが難しくなります。
分ける理由が「独立して変更したいから」「独立して拡張したいから」なら分ける価値があります。「流行っているから」なら、複雑さだけが増えます。小さいチームなら、まず1つのアプリを丁寧に作り、分ける理由が出てきた部分から分けるのが執筆者の判断です。
3. マネージドと自由度
RDS を使えば OS とデータベースの運用を AWS が持ち、自分で EC2 に MySQL を入れれば全部を自分で持ちます。ECS か EKS かで書いた「何を自分で持ちたいか」と同じ天秤です。任せるほど運用は減り、細かい設定と特殊な構成の自由は減ります。
「自由度が要る理由」が具体的に言えないなら、マネージドを選びます。「あとで困るかもしれない」は理由になりません。困ったときに移る道（RDS → EC2 上の MySQL）は残っているからです。
CHECK 1ここまでの確認
「一番いい構成はどれですか」への、この記事の答えはどれ?
答えと解説
答え: 3. 要件による。すべての軸を同時に最大にする構成は無い
判断とは何かを得るために何かを捨てることです。どの軸を優先するかを決めることが設計で、捨てたものを言えないなら判断ではなく成り行きです。
Well-Architected の6本柱は「観点の一覧」として使う
AWS Well-Architected フレームワークは、AWS が公開している設計のベストプラクティス集で、6本の柱で構成されています。
| 柱 | 問い | 引っ張り合う相手 |
|---|---|---|
| 運用上の優秀性 | 変更を安全に速く出し、運用から学べているか | セキュリティ（承認の段階） |
| セキュリティ | データと権限を守れているか | 運用上の優秀性、パフォーマンス |
| 信頼性 | 壊れても回復できるか、必要な量を出せるか | コスト最適化 |
| パフォーマンス効率 | 資源を要件に合わせて効率よく使えているか | コスト最適化、信頼性 |
| コスト最適化 | 不要な費用を避けられているか | 信頼性、パフォーマンス |
| 持続可能性 | 環境への影響を減らせているか | パフォーマンス |
6本を全部満たす設計はありません。柱同士が引っ張り合うからです。だから、フレームワークは「満たすべき基準」ではなく、「この観点を見落としていないか」を確かめる一覧として使います。設計レビューで「セキュリティの柱の観点で、この構成は何を捨てているか」と聞くと、議論が具体的になります。
各柱には「設計原則」と、それを確かめる質問が用意されています。全部に答える必要はなく、自分の要件で優先する柱の質問を先に読み、そこで「捨てている」と分かったものを判断の記録に書きます。柱が5本だった頃の資料は、持続可能性が足された 2021 年より前のものです。
「なぜそのサービスか」を説明する型
説明の型は6つの要素でできています。ECS か EKS かで使った ADR の型と同じです。
WHY THIS SERVICE「なぜそのサービスか」の型
捨てたものと見直す条件まで書いて、初めて判断
-
要件
数字で書く
-
選択肢
最低2つ
-
軸
何で比べたか
-
決定
何を選んだか
-
捨てたもの
空欄なら比べていない
-
見直す条件
いつ再検討するか
「なぜそのサービスか」の6要素
- 要件 — 何を満たす必要があるか。数字で書く（RTO 1時間、月間 1億リクエスト、担当 2名）
- 選択肢 — 検討したもの。最低2つ。1つしか無い判断は判断ではない
- 軸 — 何で比べたか。3つの天秤のどれか、または6本柱のどれか
- 決定 — 何を選んだか
- 捨てたもの — 選ばなかったことで失うもの。ここが空欄なら、比べていない
- 見直す条件 — いつ再検討するか。要件の数字が変わったとき、チームが変わったとき
この型で書くと、聞いた側は「要件の数字はうちも同じか」「捨てたものはうちで許容できるか」の2点で判断でき、説明する側は「なぜ」を毎回思い出さずに済みます。
例: ログの保管先
- 要件: アプリのログを 90 日は検索可能に、1年は保管。月 500 GB。検索するのは障害調査のときだけ。
- 選択肢: CloudWatch Logs のみ / CloudWatch Logs（30日）＋ S3（残り） / OpenSearch。
- 軸: コスト最適化と運用上の優秀性（調査のしやすさ）。
- 決定: CloudWatch Logs に 30 日、その後 S3 に出して 1 年。検索は Logs Insights と Athena。
- 捨てたもの: OpenSearch の高速な全文検索と可視化。31 日以降のログは検索に時間がかかる。
- 見直す条件: 障害調査で 30 日より前のログを月に複数回見るようになったとき。ログ量が月 2 TB を超えたとき。
要件の数字と捨てたものが書いてあるので、半年後に別の人が「OpenSearch にすべきでは」と思ったとき、「見直す条件」に当てはまるかを確かめれば済みます。
CHECK 2ここまでの確認
Well-Architected の6本柱の正しい使い方はどれ?
答えと解説
答え: 2. 見落としを防ぐ観点の一覧として使い、どの柱を優先したかを残す
柱同士は引っ張り合うので、全部を満たす設計はありません。観点の一覧として使い、優先した柱と捨てたものを判断の記録に書きます。
判断を残し、見直す
設計判断の価値は、正解を当てることではなく、あとで見直せることにあります。要件は変わり、サービスは増え、チームは入れ替わります。当時の判断が「なぜ」ごと残っていなければ、次の人は同じ検討をゼロからやり直すか、理由を知らずに変えて壊すかのどちらかになります。
ADR は、コードと同じリポジトリに、番号を付けた短い文書として置きます。見直す条件が満たされたら、古い ADR を消すのではなく、新しい ADR を書いて「これは ADR-012 を置き換える」と記します。判断の履歴を消すと、組織は同じ失敗を繰り返します。
CHECK 3ここまでの確認
「なぜそのサービスか」の6要素で、空欄なら「比べていない」と分かるのはどれ?
答えと解説
答え: 3. 捨てたもの
選ばなかったことで失うものが書けないなら、選択肢を比べていません。「見直す条件」と合わせて書くことで、判断があとで見直せます。
まとめ
設計に全部を満たす正解はなく、判断とは何を捨てるかを決めることです。クラウドの設計では、可用性とコスト・疎結合と複雑さ・マネージドと自由度の3つの天秤が繰り返し出ます。Well-Architected の6本柱は、満たすべき基準ではなく見落としを防ぐ観点の一覧として使い、どの柱を優先したかを残します。「なぜそのサービスか」は、要件・選択肢・軸・決定・捨てたもの・見直す条件の6要素で説明し、ADR に残して置き換えていきます。この型を組織の単位に広げたものが、次のマルチアカウント設計です。
参照ソース
- AWS Well-Architected フレームワーク（AWS ドキュメント） — 6本の柱の定義と、各柱の設計原則の一次情報。2026年9月時点の記載。持続可能性の柱は 2021年12月に追加された
- AWS Well-Architected フレームワーク 信頼性の柱 — RTO・RPO を要件として置き、それを満たす構成を選ぶ考え方の根拠
- AWS Well-Architected フレームワーク コスト最適化の柱 — 可用性とコストのトレードオフを扱う設計原則の根拠
- Architecture Decision Records（adr.github.io） — ADR の型と、古い ADR を置き換える運用の出典
