こんにちは。miyoshiです。
AWSクラウドプラクティショナーの勉強を進めています。
この記事も学んだことの学習メモとして投稿しています。自分の学びの振り返りでもあり、学びの共有ができたらと思います。
1. はじめに
RailsエンジニアとしてWebアプリ開発をしてきた自分が、AWSクラウドプラクティショナーの学習を進める中で、
「AWS Organizations」というサービスに出会い、インフラ設計の重要性を強く感じた話をまとめます。
Railsエンジニア視点で、
- AWS Organizationsが何をするものか
- Railsに例えるとどんな役割か
- インフラはウォーターフォール的に設計ではないか
を学習メモとして共有します。
2. AWS Organizationsとは？
AWS Organizationsは、複数のAWSアカウントを一元管理するサービスです。
✅ 主な役割
- アカウントの統合管理
- サービス制御ポリシー（SCP）による利用制限
- 請求をまとめて管理（Consolidated Billing）
✅ イメージ図
[マスターアカウント]
|
---------------------------------
| | |
アカウントA アカウントB アカウントC
（開発環境） （本番環境） （検証環境）
3. Railsに例えると？
自分が理解したときの感覚では、以下のように例えるとわかりやすかったです。
-
AWS Organizations：Railsでいう
routes.rbやアプリ全体の「設計図」
→ どのアカウント（＝アプリ）にどんなルールを適用するかを決める部分 -
EC2やS3など：Railsでいう
ViewやModel（実際に使うリソース部分）
つまり、
ビュー（EC2やS3）を安全に使うために、最初にバックエンド（Organizationsでの管理やルール）が必要
というイメージです。
4. ここで感じたこと
学習を進めて感じたことは以下の通りです。
✅ インフラは「セキュリティ・運用設計」が最優先
→ EC2やS3を立てる前に、「どのアカウントが何をできるか」を最初に決めることが重要。
✅ インフラ設計はウォーターフォール的な部分が大きい
→ Railsアプリのように「後で変えればいいや」とはいかない。
初期設計をミスると、後から大規模修正が必要になる。
✅ この設計こそがインフラエンジニアの技術が問われる部分
→ OrganizationsやIAM、CloudTrailなどで「予防・検知・防御」を最初に設計するのが肝。
5. Webアプリ開発との違い
自分の中ではこう整理できました。
| 項目 | Webアプリ開発（Rails） | インフラ設計（AWS） |
|---|---|---|
| 開発スタイル | アジャイル向き（小さく作って改善） | 初期設計が重要（ウォーターフォール寄り） |
| 後からの変更 | 容易（リファクタやデプロイで修正可） | 難しい（停止や移行が必要） |
| 最重要ポイント | ユーザー体験の改善 | セキュリティ・運用設計 |
この違いを意識することで、
「安心してデプロイできるのは、インフラ側でセキュアな設計がされているから」
と強く感じました。
6. まとめ
- AWS Organizationsは「ただの管理ツール」ではなく、セキュアなインフラ運用の土台
- アプリ開発の前にインフラ設計をしっかり固めることが大切
- Railsエンジニアとして、インフラ学習を通じて「安心して動くWebアプリは、見えないインフラ設計のおかげ」と実感
✅ 次のステップ
次は「予防・防御・検知・対応・復旧を担うAWSサービス」も整理して学習する予定です。
💬 おわりに
Railsエンジニアがインフラを学ぶと、
「アプリ開発の裏側で、いかにインフラ設計が重要か」を実感します。
同じようにクラウドプラクティショナーを学んでいる方の参考になれば嬉しいです！