【AWS CLF学習1日目】クラウドとは？AWSの長所と利点を整理する

2026年5月28日2026年5月29日

どうもPナッツです。
5月28日分のテキスト学習が終わったので自分なりに重要そうな箇所をまとめたいと思います。

クラウドとは

クラウドはインターネット経由で仮想サーバやデータベース、ストレージ等を利用出来るサービスの総称。
料金は使った分だけ請求という感じ（従量課金制）

今まではオンプレミスで運用するやりかたが主流だったので、機器の台数や性能を計算するという段階が必要だった。

オンプレミスとは・・・サーバやネットワーク、ソフトウェアなどの設備を自分たちで導入・運用するやり方）

当然計算ピッタリの結果になるわけもなく、性能不足だったり性能過剰だったりでビジネス的に損失になることが多くあった。
クラウドコンピューティングを利用することでサーバやストレージ等インターネットで即追加減少を反映出来るのでオンプレミスで起きていた問題（性能不足による機会損失や性能過剰によるリソースのつぎこみすぎ）を解決出来るようになった。

感想
自分は機器の準備やら計算やらで躓いて事業終わらせてしまいそうだから好きな時に増減できるのはありがたい。料金が使っただけなのもいいですよね。固定費とかボディーブローのように効いてきそうだし。従量課金もサービスを多くすれば費用がやばいことになりそうだから丁度いいところがどこなのかは常に考えておく必要がありそうですね。

AWSを使う事の利点

Amazon Web Serviseもそのクラウドサービスの1種で世界中の企業で利用されているらしい。
AWSを使ったクラウドコンピューティングには6つのメリットがある

　1.設備投資が変動費である
　今までのオンプレミスとは違ってサーバやデータセンターに初期投資する必要がないので最小限のコストでビジネスを始める事が出来る。
　新規事業に限らず、既存システムの総所有コスト（TCO：Total Cost of Ownership)を削減できる

備考：TCOには人件費、データセンター費用、電気代、ソフトウェアライセンス費用、保守費用が含まれる

　2.データセンターの運用保守が不要
　AWSのサービス料金には運用費用や保守費用など全部こみ込みで含まれているので機器更新にかかる費用などを考える必要がない。
　そのため本来の業務に集中できるようになる。
　
　3.キャパシティ予測不要
　オンプレミスでは考える必要があったピーク時に耐えるための性能計算が必要ない。
　クラウドでは必要に応じてその場でスケールアップ、スケールダウンを行うなど柔軟にスケーリング出来る。

　4.料金が安い
　多くの企業が利用する巨大インフラをAWS側でまとめて運用しているため、結果的にコストを抑えやすくなっている
　ちょっと別の話題ですけど、投資信託のオルカンやSP500が人気な理由の1つもこれで、多くの人が利用（購入している）ので運用のコストが減っているんですよね。
　僕が社長だったら料金変えずにお金むしり取っちゃいそうですが、AWS様はお優しいですねｗ
　
　5.オンプレミスと比べてスピード感がある
　1とか3でも記載していますが、ITリソースを柔軟にかつ素早く調達出来るので組織の動きもオンプレとは段違いになります。
　なので早く新しいビジネスを市場にだすことが出来るということですね。
　
　6.数分でデプロイ
　AWSは世界中にリージョンを設けているので、突飛な場所でも数クリックでwebサーバを構築出来ちゃう。
　オンプレとは違って現地に行ったり調査・手続きが必要ないのはすごく楽ですよね。
　災害対策として別のリージョンにも数分でシステムを再構築できるわけですね。

リージョンとは・・・3つ以上のアベイラビリティゾーンをまとめている地域の事。日本には大阪と東京にリージョンがある。
アベイラビリティゾーン（AZ）とは・・・複数のデータセンターがまとまっている地域のこと。

▼イメージ図

6つの柱

AWS Well-ArchitectedフレームワークとはAWSとそのパートナー社がシステム設計と運用の経験から得た知見を6つの柱に基づいてまとめたベストプラクティス集。

意味が分からんのでAIにまとめてもらいました笑
要するに「AWSでシステムを作るとき、どう設計すれば“良い構成”になるのか？」を整理した設計指針のこと。

1.運用上の優秀性（Operational Excellence）の柱

システムを効率よく運用・改善できるようにする考え方。

主な目的
自動化
障害対応
継続的改善

2.セキュリティ（Security）の柱

システムやデータを安全に保護する考え方。

主な目的
不正アクセス防止
権限管理
情報漏洩対策

3.信頼性（Reliability）の柱

障害が起きても安定して動き続けられるようにする考え方。

主な目的
障害対策
可用性向上
復旧対策

4.パフォーマンス効率（Performance Efficiency）の柱

必要な性能を効率よく発揮できるようにする考え方。

主な目的
高速化
スケール対応
リソース最適化

5.コスト最適化（Cost Optimization）の柱

無駄なコストを減らして最適な料金で運用する考え方。

主な目的
AWS料金削減
無駄リソース削除
適切なサイズ選定

6.サステナビリティ（Sustainability）の柱

環境負荷を抑えながら効率的に運用する考え方。

主な目的
電力削減
リソース効率化
環境配慮

AWS Well-Architected Toolという便利なツールもあるらしいです。
これを使うことで上記の行動指針にのっとって評価して改善するための支援をしてくれるらしい

感想
たぶんこの6つの柱は超重要ですね。
これを覚えるのも大事ですが今後設計を行うとき等、常にこの指針に沿ったものになっているかを考えるということが大事になってきそうだと感じました。

クラウドアーキテクチャの設計原理

オンプレとは異なる原理原則が4つ紹介されてます。

　1.故障に備えた設計
　故障に備えた設計（Design for Failure）が重要。
　上記の考え方から単一障害点（Single Point Of Failure SPOF)をなくす考え方が大切
　例えば・・・1つのデータセンターのみで運用しない、1つのハードウェアで構成しない
　
　2.コンポーネントの分離
　クラウドはサービス指向アーキテクチャの原則に従っている、つまりコンポーネントを疎結合にするということ。

疎結合とは・・・「お互いに依存しすぎない設計」のこと。　

例えば１つのコンポーネントで障害が起きた時に全部のコンポ―ネントが止まったら最悪ですよね、これを無くそうみたいな考え方です。
　
こうした「1つ止まると全部止まる問題」を簡単に解決してくれるのがAmazon SQSです。です。
コイツが非同期かつ疎結合を行ってくれるらしいです。神サービス。

▼具体的に画像にしてもらいました

また、マイクロサービスアーキテクチャをもちいることでコンポーネントの分離を促進することが出来るのでこの考え方もクラウドではかなり重要そうです。

マイクロサービスアーキテクチャとは・・・「機能を小さく分割して独立させる設計」の事

▼分かりやすくした画像

　3.弾力性の実装
　オンプレと比べてクラウドは弾力性または伸縮性がある。
　要するにスケールアウト、スケールインが容易に出来るという事です！
　
　▼スケールアウト、スケールインを説明した画像

4.並列化の考慮
ロードバランサ―を組み合わせて並列処理を行うのが重要
スケーリングについても、弾力性と並列化を組み合わせることで、アクセス量に応じて柔軟に処理性能を変えられるらしいです。
高負荷時にはスケールアウト、低負荷時にはスケールインを行うことで、無駄なコストを抑えつつ安定した運用ができるとのことでした。

感想
疎結合という考え方は設計段階でもよく出てきますし、PG段階でもデータの渡し方などで意識する部分だと思います。
今回、SQSを使うことで処理を分離できるという考え方がかなり面白いと感じました。
また、弾力性や並列処理とも相性が良さそうで、「負荷が増えた時にどう耐えるのか」という部分にも関わってくるのかなと思っています。
ただ、障害が起きてから対応するのでは遅いので、どこで異常を検知するのか、どのタイミングで対処するのかも重要になりそうです。
この辺りは今後もっと理解を深めたい部分です。