AWSとは

この講座では、クラウドサービスとAWSの基本について学びます。

• クラウドサービスとオンプレミスの違い
• クラウドの3つの特徴（経済性・拡張性・利便性）
• AWSの概要と特徴
• サービス提供形態（SaaS・PaaS・IaaS）と責任共有モデル
• マネージドサービスとサーバレスアーキテクチャ
• リージョンとアベイラビリティゾーンの仕組み
• AWSの操作手段（マネジメントコンソール・AWS CLI・IaC）
• リソースの識別（ARN・タグ）

1. クラウドサービスとは

AWSを説明する前に、クラウドサービスについて解説します。

クラウドとは、インターネットを経由して、必要なときに必要な機能だけを「借りて」使うことができるサービスの総称です。

1.1 オンプレミスとクラウドの違い

従来は、サーバやネットワーク機器などの設備を、個人や企業が自前で購入し、自社の建物内に設置・管理するのが一般的でした。これをオンプレミスと呼びます。機器の購入費だけでなく、設置スペースの確保や、故障時の対応など「維持管理の手間」がかかるのが常識でした。

一方、クラウドは、クラウド事業者が保有するデータセンターの設備を、インターネット経由で「相乗り（シェア）」する形で利用します。自分で設備を持つ必要がないため、面倒なメンテナンスは事業者に任せ、「必要な時に、必要な分だけ」すぐに使い始めることができます。

1.2 クラウドサービスの例

クラウドサービスは現代人の生活に深く浸透しており、私たちが普段何気なく使っているサービスの多くも、実はクラウドサービスの一種です。

iCloud / Googleフォト

iPhoneやAndroidなどのデータを保存するサービスです。インターネットを通じてスマートフォンの中のデータをクラウド上に保存するため、他のスマートフォンやPCからでも同じデータを見ることができます。

YouTube / Netflix

現代人の生活の一部と言っても過言ではない有名な動画配信サイトです。従来はビデオやブルーレイなどの「物理媒体（モノ）」を手元に置き、専用のレコーダーで再生していましたが、現在はサービス提供者のサーバに格納された動画データを、インターネット経由で再生する形に変わりました。

Google Workspace / Microsoft 365

各種業務ソフトをクラウド上で利用したり、ファイルを複数人で共有・編集したりできる、ビジネス向けのクラウドサービスです。

このように、プライベートから仕事に至るまで、クラウドサービスは私たちの生活に密接に関わっています。

2. クラウドの特徴

クラウドサービスには、主に3つの特徴があります。

2.1 経済性

1つ目はコストの削減、経済性です。

従来は、システム導入時に将来の最大負荷を見越して機器を購入する必要があり、多額の初期費用（固定費）が発生していました。また、稼働後の保守・運用にも人件費などのコストがかかり続けました。

一方、クラウドは初期投資が不要で、利用した分だけ料金を支払う「従量課金制」が一般的です。これにより、設備投資（CapEx）を運用費（OpEx）に転換し、無駄なコストを抑えてキャッシュフローを最適化することができます。

2.2 拡張性（スケーラビリティ）

2つ目は拡張性（スケーラビリティ）です。

従来は、物理的なサーバのスペックや台数が固定されていたため、急なアクセス増加に対応できずシステムダウンしたり、逆に閑散期には過剰な設備が無駄になったりしていました。

一方、クラウドはビジネスの状況に合わせて、サーバの性能や台数を柔軟に増減（スケーリング）させることができます。キャンペーン時の急な負荷増にも即座に対応でき、常に最適なリソース量でシステムを稼働させることが可能です。また、必要がなくなったらサーバを削減し、リソースを無駄にしないようにできます。

2.3 利便性

3つ目は利便性です。

従来は、セキュリティやネットワークの物理的な制約により、社内の特定のPCや場所からしかシステムやデータにアクセスできない環境が一般的でした。

一方、クラウドはインターネット環境さえあれば、場所やデバイスを問わずに同じ環境へアクセスできます。これにより、在宅勤務や移動中・出張先での業務が可能となり、多様な働き方や迅速な意思決定を実現します。

3. AWSとは

AWS（Amazon Web Services）は、ネットショッピングでおなじみのAmazonが提供するクラウドサービスです。

「なぜ通販会社のAmazonが、ITインフラであるクラウドサービスを提供しているのか？」と疑問に思うかもしれません。

実は、AWSはAmazonが自社のビジネスを拡大させる中で培ったインフラ運用のノウハウや技術を、外部の顧客も利用可能なサービスとして標準化・外販したものです。

現在では「クラウドサービスといえばAWS」と言われるほど、世界中で最も利用されているサービスとして確固たる地位を築いています。

4. AWSの特徴

数あるクラウドサービスの中でAWSが選ばれる理由となる、3つの大きな特徴について解説します。

4.1 高いシェア率

1つ目の特徴は高いシェア率です。

利用者が圧倒的に多いため、インターネット上には技術情報やトラブル解決のノウハウが豊富に蓄積されています。「困ったときに検索すればすぐに答えが見つかる」という点は、AWSを使う上で非常に大きなメリットです。

また、多くの人が使うことで「規模の経済」が働きます。AWSが一括して大量のサーバを調達・運用することでコストを下げ、それが利用料金の「値下げ」という形で利用者に還元され続けています。

4.2 豊富なサービス数

2つ目の特徴は豊富なサービス数です。

AWSは単なるサーバの貸し出しだけではなく、実に200以上のサービスを提供しています。

ネットワークを作るVPC、仮想サーバのEC2、データを保存するS3、データベースのRDSなど、あらゆる用途に対応できるパーツが揃っており、これらを組み合わせることで、どのようなシステムでも柔軟に構築することができます。

4.3 安定したインフラ

3つ目の特徴は安定したインフラです。

AWSは世界の主要都市にデータセンターを構築しており、それらは高度に冗長化されています。

万が一、特定の場所で災害や障害が発生しても、他の地域やデータセンターでシステムを稼働し続けることができるため、非常に信頼性の高いインフラ基盤を利用することができます。

5. クラウドの基本用語

5.1 サービス提供形態（SaaS / PaaS / IaaS）

クラウドにおけるサービスの提供形態としてSaaS、PaaS、IaaSの3つがあり、それぞれの形態によって提供される範囲が異なります。

SaaS（Software as a Service）

SaaSは、インフラ基盤および、その上で動作するソフトウェアをすべて提供する形態です。

すべてが用意されているため、すぐに利用でき、管理コストが軽減できるというメリットがありますが、その分細かい設定は事業者が行うため、ユーザ側は変更できないことが多いというデメリットもあります。

Microsoft 365やGoogle Workspace、Salesforceといった、ブラウザからすぐ使える業務系のクラウドサービスはSaaSに分類されます。

PaaS（Platform as a Service）

PaaSは、アプリケーションを動かすための「土台」は準備されているものの、その上で動作するアプリケーションは利用者側で用意する形式です。

サーバ設定などのインフラはサービス提供事業者が用意するため利用者側で管理が不要です。

後ほど説明するサーバレスアーキテクチャや、Herokuのような開発プラットフォーム、kintoneのようなノーコードツールなどが該当します。

IaaS（Infrastructure as a Service）

IaaSは、インフラ基盤を借りて、OSから上の設定をすべて利用者側で行うサービス形態です。

利用者が自由に設定できる反面、それらの管理をすべて利用者の責任で行う必要があります。

例えば仮想サーバを提供するAmazon EC2は、IaaSの代表的な例の一つです。

5.2 責任共有モデル

クラウドを利用する上で最も重要なセキュリティの考え方である責任共有モデルについて解説します。

クラウド環境のセキュリティは、AWSにすべて任せられるわけではなく、AWSと利用者がそれぞれの担当範囲について責任を持つことで成立します。

AWSの責任範囲

まず、AWSはクラウド自体のセキュリティに責任を持ちます。

具体的には、データセンターなどの物理的な施設、サーバやネットワーク機器などのハードウェア、そしてそれらを動かすための仮想化基盤の管理です。これらが物理的に破壊されたり、インフラレベルで侵入されたりしないように守るのはAWSの役割です。

利用者の責任範囲

一方で、利用者はクラウド内のセキュリティに責任を持ちます。

具体的には、自身が作成したアプリケーション、自身がインストールしたOSのアップデートやセキュリティパッチの適用、ネットワークの通信設定、作成したアカウントやパスワードの管理、そして保存するデータの暗号化などです。たとえAWSの建物が頑丈でも、利用者がパスワードを簡単なものに設定して侵入されてしまった場合、それは利用者の責任となります。

提供形態ごとの考え方

また、この責任の境界線は、先ほど説明したサービス提供形態によって変動します。

例えば、IaaSであるAmazon EC2を使う場合は、OSの設定から利用者が管理するため、利用者の責任範囲が広くなります。逆に、SaaSやPaaSを利用する場合は、OSやミドルウェアの管理をAWSが行うため、利用者の責任範囲は狭くなり、データの管理や権限設定などに集中することができます。

これらを理解し、利用者がどの部分の責任を負うべきかを意識して、設定や作業を行うことが求められます。

6. AWSが提供するサービスの種類

AWSは、EC2のように基本的な仮想サーバを提供するだけではなく、マネージドサービスやサーバレスアーキテクチャといった、より運用を自動化した高度なサービスも提供しています。

6.1 マネージドサービス

マネージドサービスとは、本来であれば利用者が行うべきサーバの運用や管理といった手間のかかる作業を、AWSが代行してくれるサービスの総称です。

例えば、「EC2」のような仮想サーバを提供するサービスは、自由度が高い反面、OSのセキュリティパッチの適用や、定期的なデータのバックアップ、障害が起きた時の復旧作業などを、すべて自分たちで行う必要があります。これは非常に手間がかかる作業であり、これを「アンマネージド」な状態と呼びます。

一方、データベースを提供する「Amazon RDS」や、ストレージを提供する「Amazon S3」などのマネージドサービスを利用すると、これらの「OSやミドルウェア層」の面倒な管理作業をAWSが肩代わりしてくれます。例えばデータベースが必要な場合、従来のようにサーバを用意してデータベースソフトをインストールするのではなく、Amazon RDSを使えば、AWSの画面上でいくつかの設定をするだけで、すぐに利用可能なデータベースが用意されます。

また、ストレージについてもAmazon S3を利用することで、サーバの構築やディスク容量の管理といったメンテナンスを一切気にすることなく、簡単な設定だけですぐにデータの保存を開始できます。

これにより、利用者はサーバのメンテナンスをする時間を減らし、本来注力すべきアプリケーションの開発や、ビジネスの価値を高める作業に集中することができます。

6.2 サーバレスアーキテクチャ

マネージドサービスをさらに進化させた形態であるサーバレスアーキテクチャについて解説します。

通常のマネージドサービス（RDSなど）では、OSの管理は不要になりますが、まだ「どのくらいの性能のサーバを使うか」といったサーバの選定や数は利用者が意識する必要があります。対してサーバレスは、文字通り「サーバの存在そのものを意識しなくて良い」という仕組みです。実際には裏側でサーバが動いていますが、容量の確保やスケーリングは完全に自動で行われるため、利用者はコードやコンテナを用意するだけで済みます。

代表的なサービスとして、AWS LambdaとAWS Fargateの2つが挙げられます。

AWS Lambda

これはプログラムの「コード」を実行することに特化したサービスです。従来のようにサーバを24時間起動しておく必要はなく、データの保存やアクセスといった何らかのイベントが発生した瞬間だけ自動的にプログラムが起動し、処理が終われば終了します。料金は「コードが動いていた時間（ミリ秒単位）」に対してのみ発生するため、待ち時間のコストがゼロになり、非常に経済的です。

AWS Fargate

これは「コンテナ」と呼ばれる技術を利用するためのサーバレスサービスです。通常、コンテナを利用する場合でも、その土台となる仮想サーバ（EC2）の管理が必要でしたが、Fargateを使えば、土台の管理を一切気にすることなく、コンテナを動かすことだけに集中できます。Webサイトのように長時間稼働し続けるアプリケーションを、管理の手間なく動かしたい場合に適しています。

これらサーバレスアーキテクチャを活用することで、インフラ管理の手間を極限まで減らし、アプリケーションの開発そのものにリソースを集中させることができます。

7. AWSの基本用語と重要概念

AWSの基本的な用語と、重要な概念について解説します。

7.1 AWSアカウント

まずは、AWSを利用する際に最初に作成が必要となる単位である「AWSアカウント」について説明します。

AWSアカウントの役割

AWSを利用するとき、最初にAWSアカウントを作成します。AWSアカウントの役割についてみていきます。

AWSアカウントは、「リソースの入れ物」として機能します。EC2やRDSといったAWSリソースは、必ずAWSアカウントに紐づく形で作成されます。つまり「アカウントAのEC2インスタンス」「アカウントBのRDSインスタンス」のように紐付けられます。

そのため、セキュリティ上の境界線のベースは、AWSアカウントとなります。アカウントAで作ったリソースは、特別な権限を与えない限り、アカウントBでは参照することができません。

また、AWSの利用料金は、この「AWSアカウント」単位で集計され、請求されます。

アカウントとユーザの違い

AWSアカウントは「ユーザの単位」と受け取られがちですが、ユーザとは厳密には異なります。どちらかというと「目的」にあわせてアカウントを作り、必要があればその中にユーザを作って、管理していきます。

AWSアカウントを作ると「ルートユーザ」という特権ユーザが作られ、それでログインできます。しかしAWSではセキュリティ上、そのルートユーザは日常的には使わず、別途「IAM」という機能で作ったユーザや権限を利用することを推奨しています。

主な使い分け

AWSアカウントは「目的」ごとに作成することが推奨されています。

そのため、例えば「開発」「検証」「本番」のように環境に合わせてアカウントを作ったり、「ログ管理」「監査」「共有サービス」のような機能ごとに作ることも一般的です。

また、AWS Organizationsという機能で、複数のAWSアカウントをまとめて管理することもできます。

7.2 リージョンとアベイラビリティゾーン（AZ）

AWSの基本用語の中で最も重要な、リージョンとアベイラビリティゾーン（AZ）について解説します。

アベイラビリティゾーン

アベイラビリティゾーンは、AZと表現されることも多いですが、AWSが管理するデータセンターを、一定の単位でまとめたものです。各AZは、互いに一定の距離が保たれており、もし一つのAZで障害が起きても、別のAZで処理を継続することで、システムを止めることなく稼働させることができます。

このように、複数のAZに分散してインフラを構成することをマルチAZと呼びます。Amazon EC2やRDSなどのサービスは、ユーザの設定によりマルチAZを組むことができます。また、マネージドサービスの一部は、ユーザが意識しなくても自動で複数のAZに分散されるものもあります。

リージョン

リージョンは、複数のAZをひとまとめにしたより大きな規模で、国や地域ごとに設定される、AWSのデータセンターの管理単位の一つです。日本には東京リージョン、大阪リージョンが存在します。また、現在、東京リージョンの中には4つのAZが存在しています。

マルチAZである程度の可用性は担保できますが、国家規模の災害や、リージョン自体が障害で停止したときは、利用することができなくなります。そこで、複数のリージョンにまたがってインフラを構築する「マルチリージョン」の考え方もあります。

しかし、一般的にマルチリージョン構成をとるには事前の準備が必要であり、すべてのサービスが標準で対応しているわけではありません。例えばEC2インスタンスはリージョンをまたいで構成することはできないため、別のリージョンにも個別にサーバを構築するなどの対策が必要です。RDSの場合、災害対策として別のリージョンにデータの複製を作成する機能があります。またS3は、標準では「リージョン内の複数AZ」にデータがコピーされる仕組みであり、別のリージョンへ自動でバックアップされるわけではありません。リージョン障害に備える場合は、別のリージョンへデータをコピーする設定を別途行う必要があります。

このように、マルチAZ構成は信頼性を高めるために基本的に推奨されており、多くのマネージドサービスでは設定だけで簡単に導入できます。一方で、コストや運用の手間が増えるマルチリージョン構成まで採用するケースはそれほど多くなく、極めて重要なデータのバックアップや、大規模な災害対策として限定的に利用されるのが一般的です。

エッジロケーション

リージョンやアベイラビリティゾーンとは異なる拠点であるエッジロケーションについて解説します。

エッジロケーションは、AWSのデータセンター施設の一種ですが、リージョンのように大規模な計算資源を持つものではなく、主にデータをユーザに素早く届けるための「配送拠点」のような役割を果たします。リージョンは世界に数十箇所ですが、エッジロケーションは世界中に400箇所以上と、圧倒的に多く設置されています。

代表的な利用例は、Amazon CloudFrontというCDN（コンテンツデリバリネットワーク）サービスです。通常、海外のリージョンにあるサーバへアクセスすると、物理的な距離があるため通信に時間がかかります。しかし、エッジロケーションを利用すると、画像や動画などのデータを、ユーザの最も近くにあるエッジロケーションに一時的にコピー（キャッシュ）することができます。これにより、ユーザは近場のエッジロケーションからデータを取得できるため、サーバの場所を意識することなく、高速にコンテンツを閲覧することが可能になります。

実際、リージョンはまだ存在していない国も多いですが、エッジロケーションはより多くの国や地域に設置されています。そのため、物理的な距離の壁を越えて、世界中にコンテンツを配信するための非常に重要な拠点と言えます。

8. AWSを利用するためのツールとインターフェース

AWSを利用するためのツールやインターフェースを説明します。

8.1 マネジメントコンソール（GUI）

まず、AWSの操作手段として最も基本的な「マネジメントコンソール」について解説します。

これは、普段使っているGoogle ChromeやEdgeなどのWebブラウザからアクセスできる、AWSの操作画面のことです。AWSアカウントを作成して最初にログインする場所がここになります。GUI（グラフィカル・ユーザ・インターフェース）と呼ばれる通り、画面上のボタンやメニューをマウスでクリックしていくだけで、サーバを立ち上げたり、データベースを作ったりすることができます。視覚的に分かりやすいので、どこに何があるか、今どんな状態かがひと目で分かるのが最大のメリットです。

8.2 AWS CLI / SDK（CUI/プログラム）

画面ではなくコマンドやプログラムで操作する方法として、AWS CLIとSDKについて説明します。

先ほどのマネジメントコンソールは、画面を見ながら直感的に操作できる反面、「同じ操作を何度も繰り返すのが大変」「操作ミスなどの人的ミスが起きやすい」といったデメリットがあります。そこで、文字ベースで命令を送るCUIを使うことで、複数の操作を自動化したり、どのような操作を行うかを事前にチェック（レビュー）してミスを防ぐことが可能になります。

このCUIによる操作には、大きく分けて2つの方法があります。

AWS CLI

AWSが用意した専用のツールで、パソコンのターミナル画面からコマンドを入力することでAWSを操作します。手動でコマンドを叩くこともできますし、スクリプトを書いて自動化することも可能です。

AWS SDK

Software Development Kitの略で、プログラミング言語の中からAWSを操作するための部品セットです。PythonやJavaなど、よく使われる言語向けに用意されており、アプリケーションのプログラムコードの中に「S3にファイルをアップロードする」といったAWSの操作を組み込むことができます。

8.3 Infrastructure as Code（IaC）

近年クラウド構築のスタンダードとなっているIaC（Infrastructure as Code）について解説します。

IaCとは、文字通りインフラの構成を「コード」として記述し、管理する手法のことです。

先ほど説明したマネジメントコンソールは、手動でボタンをクリックして構築する方法でした。また、AWS CLIはコマンドを一つずつ実行する方法でした。これに対してIaCは、「どのようなサーバ構成にしたいか」という「設計図」をコードとして記述します。この設計図をツールに読み込ませることで、AWS上のリソース構築を全自動で行うことができます。

IaCを利用する最大のメリットは、「誰が何度やっても、まったく同じ環境が作れる」という点です。人間が手作業で行うと、どうしても設定ミスや、手順の抜け漏れが発生します。しかし、コードで書かれた設計図があれば、本番環境とまったく同じ構成の検証環境を、ボタン一つですぐに作成することができます。また、コードを履歴管理することで、「いつ、誰が、どこを変更したか」を追跡できるため、セキュリティやガバナンスの面でも非常に有効です。

代表的なツールとして、AWSが標準で提供している「AWS CloudFormation」があります。これはJSONやYAMLといったテキスト形式で設計図を記述します。また、AWS以外のクラウドにも対応している「Terraform」というツールや、普段使っているプログラミング言語でインフラを定義できる「AWS CDK」といったツールも広く利用されています。

現代のクラウド開発において、手動での構築は最小限に留め、可能な限りこのIaCを用いて自動化することが推奨されています。

9. リソースの識別

AWSのリソースを識別するための方法を解説します。この後AWSを実際に扱う際に重要な考え方です。

9.1 IDまたは名称

まず、ほぼすべてのリソースは、IDまたは名称を持っており、これらを元にリソースを識別します。なお、IDで管理するか、名称で管理するかはリソースタイプごとに統一されていません。

例えばEC2は、利用者が付けた名称ではなく、システムが割り当てたIDで管理されるリソースの一つです。またLambdaはIDを持たず、名称で管理されます。逆にセキュリティグループのように、IDと名称の両方を持つリソースタイプもあります。

サービス間の参照をするとき、リソースごとに指定方法が異なるので注意が必要です。

9.2 ARN（Amazon Resource Name）

AWSのほぼすべてのリソースは、ARNという独自の識別子を持っており、これを使ってリソースの識別を行うことができます。

ARNの見た目は少し長く、「arn:aws:ec2:ap-northeast-1:12345...」といった文字列になっています。普段の操作でいちいち入力することはありませんが、例えば「このサーバだけに、この操作を許可したい」といった権限設定をする時や、Terraformなどのコードで管理する時には、必ずこのARNを使って対象を指定することになります。

「AWS上のすべてのモノには、ARNという世界でただ一つのIDが割り振られている」という点を覚えておくとよいでしょう。

9.3 タグ

これは、利用者がリソースに対して自由に貼り付けられる「付箋（ふせん）」のようなものです。ARNやIDはシステムが管理するための識別子ですが、タグは人間が管理しやすくするための目印です。

例えば、EC2インスタンスはランダムなIDで管理されるため、IDだけでは用途が判別しにくいという課題があります。そこで、「Name」というタグを設定して名前を入力することで、コンソール上で擬似的に名前を表示させ、管理しやすくすることができます。

また、複数のリソースをまとめて管理する際にも強力な武器になります。例えば「DevOpsプロジェクトのタグが付いているリソースだけの利用料金を集計する」といった使い方ができるため、コスト管理において非常に重要です。実際の現場では、プロジェクトごとにタグの厳格な命名ルールが決められていることも多く、タグはAWSリソースを効率良く管理するための必須の機能と言えます。

10. まとめ

この講座では、AWSの概要について学びました。

• クラウドサービスは、インターネット経由でコンピュータ機能を「借りて」使うサービス
• AWSは、Amazonが提供する世界最大のクラウドサービス
• クラウドには経済性、拡張性、利便性のメリットがある
• サービス提供形態としてSaaS、PaaS、IaaSの3種類がある
• 責任共有モデルにより、AWS側と利用者側で責任範囲が分かれる
• リージョンとアベイラビリティゾーン（AZ）でデータセンターを分散管理
• マネジメントコンソール、AWS CLI、IaC（Terraform等）でAWSを操作できる
• ARNとタグでリソースを識別・管理する