仕組みの名前より、利用する場面を先に
この記事はクラウド構成を検討する前の整理を扱います。会社のAWS構成、認証・評価の取得、個別サービスの選定、料金試算や設定手順を示すものではありません。
使う人、使う時間帯、扱う情報、必要な結果を書きます。「安くしたい」「止めたくない」のような希望は、どの場面で何を保ちたいのかまで具体化してください。
要件を整理するための問い
| 要件を整理するための問い | 自分の場面で考えること | 残す材料 |
|---|---|---|
| 運用 | 状態を誰がどう確かめ、変更をどう振り返るか。 | 確認する記録と、日々の判断・連絡の流れ。 |
| 保護 | 扱う情報と操作を、どの範囲へ分けるか。 | 必要な利用者、操作、確認先の一覧。 |
| 継続 | 利用できなくなったとき何が困り、何から戻すか。 | 影響する作業と、復旧を確かめる条件。 |
| 性能 | どの利用場面で、どの待ち時間や処理量を確かめるか。 | 対象と条件をそろえた確認方法。 |
| 費用 | 何が使用量を増やし、どの単位で把握するか。 | 利用の前提と、見積もりで確認する項目。 |
| 資源の使い方 | 必要な成果に対して、余分な処理や保存がないか。 | 品質を保つ条件と、変更前後に比べる記録。 |
公式の観点を、自分の問いへ置き換える
AWS Well-Architected フレームワークは、運用上の優秀性、セキュリティ、信頼性、パフォーマンス効率、コスト最適化、持続可能性の六つの柱で構成されています。
上の表は、その観点を検討メモの問いに置き換えた編集例です。公式の評価項目そのものでも、要件を満たしたという判定でもありません。実装や個別サービスの情報は、公式資料の対象と更新内容を別に確認してください。
希望を、確認できる条件へ変える
一つの構成で全てを良くできると決めず、条件の関係を残します。
- 使う場面を一つ選ぶ
代表的な作業と、その結果を受け取る人を定めます。通常時だけでなく、利用が増える場面や使えない場合も書き出します。
- 確かめ方を決める
何を記録すれば判断できるかを考えます。希望値、現状の記録、未確認の条件を分けてください。
- 選択の理由を残す
比較する案と、重視する条件を記します。変更後は同じ確認条件で見直し、想定と違った点を次の検討へ残します。
検討の入口で迷ったら
公式の六つの柱を並べれば、設計できたことになりますか。
観点を並べることは問いを見つける入口です。具体的な構成に対して、どの条件をどう確かめるか、未確認の点は何かまで整理する必要があります。
最初から正確な料金を決められますか。
利用量、運用条件、対象サービスなど、見積もりに必要な前提を先に整理します。この記事では金額を示さず、個別の試算はその時点の公式情報と実際の利用条件で確認する事項として扱います。