はじめに
AWS クラウドプラクティショナーの学習を始めて3日目の初学者です。学習進める中で、AWSの基本的な考え方やサービスについて理解した内容を整理するため、本記事にまとめました。
AWSには単なるクラウドサービスの提供だけでなく、障害を前提とした設計思想やセキュリティ管理の考え方など、クラウドならではの特徴があります。
今回は以下の内容について学習した内容をまとめます。
・AWSクラウドの利点
・AWSクラウドの設計原則
・AWSクラウドエコノミクス
・AWS責任共有モデル
・IAM（アクセス管理）
１. AWSクラウドの利点
AWSクラウドの大きな特徴は、必要な時に必要な分だけリソースを利用できる点です。従量課金制を採用しているため、利用した分だけ料金を支払う仕組みとなっています。
また、利用状況に応じてサーバーやストレージなどのリソースを柔軟に増減できる伸縮性を備えています。これにより、アクセス増減に応じた柔軟な対応が可能になります。
オンプレミス環境では機器の調達や構築に時間がかかりますが、AWSでは短時間で環境を構築できるため、サービス提供までのスピードが速くなり、俊敏性が向上します。
さらに、世界各地にリージョンやアベイラビリティゾーンが展開されていることで、障害に強い構成を組むことができ、可用性と信頼性の高いシステム構築が可能になります。単一障害点を避けた設計を行うことで、安定したサービス提供を実現できます。
このようにAWSクラウドは、コスト面だけでなく、伸縮性・俊敏性・可用性・信頼性といった観点でも大きなメリットがあります。
２. AWSクラウドの設計原則
AWSでは、障害が発生することを前提とした設計が推奨されています。この考え方はDesign for Failureと呼ばれ、システムの一部に障害が発生しても全体のサービスを継続できるように設計することが重要です。
Design for Failureの重要な考え方の1つとして疎結合化があります。システム同士を密結合にせず、依存関係を弱めることで、１つのシステムに障害が発生しても他の部分へ影響を最小限に抑えることができます。
さらに処理方式として同期処理と非同期処理を適切に使い分けることも重要です。同期処理は「処理を依頼する側が相手の処理結果を待つ必要がある」処理方法を指しますが、処理の遅延が全体に影響する可能性があります。一方で非同期処理は、「相手の処理結果を待たずに自分の処理を継続させる」処理方法となり、システム間の依存を減らします。システムのパフォーマンス向上を重視する必要がある場合、非同期処理を選択した方が、良い設計となることが多いです。
３. AWSクラウドエコノミクス
AWSのクラウドエコノミクスとは、クラウドコンピューティングの経済的位側面に基づく考え方です。
AWSではサーバーなどの設備を自分で持つ必要がなく、必要な分だけ利用して、その利用量に応じて料金を支払います。そのため、大きな初期投資が不要になり、使っていない設備にお金をかける無駄も減らせます。さらに、利用状況に応じて簡単にリソースを増やしたり減らしたりできるため、効率よく運用できます。
クラウドとオンプレミスの費用を比較するときは、単純に月額料金だけを見るのではなく、TCO（Total Cost of Ownership：総所有コスト）という考え方が重要になります。TCOとは、システムの導入から運用、保守、廃止までにかかるすべての費用を合計したものです。AWSでは、設備購入費やデータセンター維持費などが不要になり、運用の負担も軽減できるため、結果としてTCOを下げやすいという特徴があります。
４. AWS責任共有モデル
AWSでは、クラウド上のシステムのセキュリティを「責任共有モデル」という考え方で管理しています。これは、AWSとユーザーがそれぞれ担当する範囲を分け、その範囲のセキュリティを各自が責任を持って管理する仕組みです。
AWSの責任範囲は、「クラウドそのもののセキュリティ」です。具体的には、データセンターの建物や設備の管理、ネットワーク機器、サーバー、ストレージなどの物理的なインフラや仮想化基盤の保護を行います。また、利用するサービスによっては、OSやミドルウェアの更新やパッチ適用などもAWSが管理します。
一方、ユーザーの責任範囲は「クラウド上で利用するもののセキュリティ」です。具体的には、データの管理、アクセス権限の設定、アプリケーションの管理、セキュリティ設定などを行います。ただし、ユーザーの責任範囲は利用するサービスによって異なります。
例えば、EC2のようなIaaSサービスでは、AWSは物理サーバーや仮想化基盤まで管理しますが、ゲストOSの更新、セキュリティパッチの適用、アプリケーション管理、セキュリティグループの設定などはユーザーが行います。
一方、LambdaやS3などのマネージドサービス（PaaSに近いサービス）では、AWSがOSやミドルウェアの管理まで担当するため、ユーザーは主にアプリケーションやデータ管理に集中できます。
５. IAM（アクセス管理）
AWSでは、「AWSアカウント」が利用の基本単位となり、作成時には「ルートユーザー」が自動的に作成されます。ルートユーザーは、そのアカウント内のすべてのAWSリソースに対して完全な権限を持っています。そのため権限が非常に強く、普段の作業で利用することは避け、必要な場合のみ使用することが推奨されています。
通常は、IAM（Identity and Access Management）を利用してアクセス管理を行います。IAMはAWSリソースへのアクセス権限を管理するサービスで、利用者ごとにIAMユーザーを作成し、必要な権限を付与できます。また、複数のIAMユーザーをIAMグループとしてまとめ、グループ単位で権限を設定することもできます。権限はIAMポリシーによって管理され、必要な作業に必要な範囲だけ権限を与える「最小権限の原則」が推奨されています。
IAMには「IAMロール」という機能もあり、AWSサービスやアプリケーションに権限を付与できます。例えば、EC2にS3へのアクセス権を持つIAMロールを設定すると、アクセスキーを保存しなくても安全にS3へアクセスできます。
さらに、複数のAWSアカウントを利用する場合は、「AWS Organizations」を利用することで、アカウントの権限管理や請求管理を一元化できます。組織単位（OU）ごとに異なるポリシーを適用することも可能です。
つまりAWSでは、ルートユーザーは最小限に利用し、普段はIAMユーザーやIAMグループを使用して、適切な権限とセキュリティ設定で安全に管理することが重要です。
まとめ
今回の学習を通して、AWSは単にサーバーをクラウド上で利用するサービスではなく、可用性や拡張性、セキュリティを考慮した設計思想が重要であることを理解できました。
特に「Design for Failure」や責任共有モデル、IAMによるアクセス管理はAWSを利用する上で欠かせない考え方だと感じました。
今後も学習した内容を整理しながらAWSへの理解を深めていきたいと思います。
最後までお読みいただきありがとうございました。