はじめに

今回、普段利用しているAWSについて一から勉強し直すことにしました。
それに伴い、自分なりにまとめた内容をここにまとめていきます。

そもそもAWSとは

AWSサービス開始までの経緯

AWS（Amazon Web Services）は、Amazon社が提供するクラウドサービスです。

元々、Amazon社が自社のサイト、Amazonがどんどん大きくなり、世界有数のECサイトへと成長しました。
しかし、成長する上でさらなるビジネス課題が生まれました。

リコメンド等で活用するために、過去の注文履歴を保存しておきたい。
Amazonアソシエイト(アフィリエイト)プログラムの支払い計算の遅延

これらの他にもビジネスが成長する過程で様々な課題が生まれました。

これらの課題を解決するために、Amazon社は自前でクラウド上でのコンピューティングサービスやサーバを自社のためだけでなく、一般向けにサービスとして提供することとなりました。
こういった経緯で2006年にオンラインストレージのAmazon Simple Storage Service（S3）と、仮想コンピュータであるAmazon Elastic Compute Cloud（EC2）をもって、AWSがサービス開始されました。
＊AWSとしてのサービス開始以前にキューサービスであるAmazon Simple Queue Service(SQS)が2004年に開始されています。

＊クラウドコンピューティング（Wikipediaより）
「クラウド（クラウドサービス、クラウドコンピューティング）」とは、クラウドサービスプラットフォームからインターネット経由でコンピューティング、データベース、ストレージ、アプリケーションをはじめとした、さまざまな IT リソースをオンデマンドで利用することができるサービスの総称です。クラウドサービスでは、必要なときに必要な量のリソースへ簡単にアクセスすることができ、ご利用料金は実際に使った分のお支払いのみといった従量課金が一般的です。

クラウドコンピューティングのサービス形態

クラウドコンピューティングサービスにも様々な形態があります。
左から、オンプレミス、IaaS、PaaS、SaaSといったように分かれます。

オンプレミス

自身で物理的にサーバを用意し、ネットワークからアプリケーションまで全て自前で用意する形態。
個人で導入するにはハードルが高い。

IaaS(Infrastructure as a Service)

仮想サーバやストレージ等のリソースをインターネット経由で提供するサービス形態。
ユーザーはOSより上のレイヤーを管理する必要があります。
物理的なハードウェアを用意する必要がないため、オンプレミスより導入コストが低い傾向にあります。

AWSでのサービス例） EC2

PaaS(Platform as a Service)

データベースやアプリケーションサーバなどのミドルウェアを提供するサービス形態。
IaaSよりも管理する範囲が狭くなり、アプリケーションやデータのみを管理すれば良くなるため、サーバなどのインフラなどを気にすることなく、アプリケーション開発に集中することができます。
OSを管理する必要がないため、セキュリティソフトなどの管理コストも不要となります。

AWSでのサービス例） Lambda、Fargate（サーバレス構成）

SaaS（Software as a Service）

ソフトウェアやアプリケーションの機能をインターネット経由で提供するサービス形態。

サービス例）DropBox、SalesForce、Gmail等
AWSでのサービス例） S3、CloudWatch

今回は、AWSの主要サービスである下記の4サービスについてまとめます。

VPC

まずは、AWSにおいて最初に学ぶべきサービスの一つであるVPCについてです。
VPCとはAmazon Virtual Private Cloudの略で、仮想的なプライベートネットワークを構築できるサービスです。
セキュリティやAWSの全てのサービスに関連してくるものです。

VPCの説明に入る前に、AWSにおける大事な用語であるリージョンとアベイラビリティゾーン、エッジロケーションについて記載します。

リージョン

AWSがサービスを提供している拠点（国と地域）のことを指します。（下記の画像のオレンジの円が該当します。）
2021年3月現在では、24の国・地域にリージョンが展開されています。
日本にはこれまで東京リージョンと大阪ローカルリージョンが展開されていました。
ローカルリージョンとは、後述するアベイラビリティゾーンが通常のリージョンには複数存在しているのに対し、
ローカルリージョンはアベイラビリティゾーンが1つしか展開されていません。

＊2021年3月2日にAWSはこの大阪ローカルリージョンを通常のリージョンに格上げすると発表しました。
これで国内に2つ目となるリージョンが開設されます。

アベイラビリティゾーン

アベイラビリティゾーン（AZ）はAWSが保有するデータセンターです。
前述したとおり、１つのリージョンに複数のAZで構成されています。
東京リージョンには4つのAZ、大阪には3つのAZが用意されており、各AZ間は専用のネットワーク回線で接続されています。
これらの複数のAZを利用した構成をマルチAZ構成と言い、可用性や耐障害性の観点からマルチAZ構成を取ることが推奨されています。

エッジロケーション

エッジロケーションはエッジサーバが存在する地域のことを指します。（下記の画像の青の円が該当します。）
CDNサービスであるCloudFrontやRoute53、AWSWAFで用いられ、コンテンツがキャッシュされる際に用いられます。
日本には、東京と大阪に存在します。
（大阪にはエッジロケーションは存在しますが、エッジキャッシュは存在しません。）

参考：AWSグローバルインフラストラクチャ

また、VPCについて話す上で必要となるIPアドレス、サブネット等のインフラの基本的な知識に関しましては、今回は割愛させていただきます。
ざっくり、
IPアドレス → インターネットにつながっている機器の住所
サブネット → 大きなネットワークを小さい単位で分けて管理しやすくするためのネットワーク
と考えていただければいいかと思います。

また、先にVPCのおいて重要となる単語について軽く説明致します。

ルートテーブル

サブネットに関連付けて使用します。
サブネットから外に出る通信をどこに向けるかを管理するルール・定義です。
ルートと呼ばれるルールで構成されます。
最も明確なルールが優先的に適用されます。
下記の例では10.0.0.0/21のVPC内の通信が優先され、それ以外の通信はインターネットに飛びます。

インターネットゲートウェイ

VPC内のAWSリソースとインターネットを繋げる役割になります。
負荷が高くなった場合も、自動でスケールするため可用性が高い。
サブネットのルートテーブルにて設定し、使用します。
上記のルートテーブルのようにVPC内以外の通信（デフォルト）の宛先が指定されているゲートウェイをデフォルトゲートウェイと呼ぶ
デフォルトゲートウェイにインターネットゲートウェイが設定されているサブネットをパブリックサブネット、デフォルトゲートウェイにインターネットゲートウェイが設定されていないサブネットをプライベートサブネットと呼びます。

NATゲートウェイ

インターネットに接続ができないプライベートサブネットからインターネット接続を可能にするためのゲートウェイ
アウトバウンドは可能だが、インバウンドはできない
自動でスケールするため可用性が高い

ENI(Elastic Network Interface)

仮想ネットワークインタフェース
EC2インスタンスのIPアドレスはENIに付与される
同じAZ内のインスタンスにアタッチ・デタッチすることが可能

ElasticIPアドレス

インスタンスにアタッチ・デタッチが可能
インスタンスが再起動・停止・終了しても変更されない、静的なパブリックIPアドレス

セキュリティグループ

AWSの仮想ファイアウォールサービス
より広い範囲のルールが適用される
インバウンド・アウトバウンドが設定可能
適用範囲はサブネット単位ではなく、インスタンス（ENI）単位で適用
アウトバウンドの返りの通信を考慮する必要がない（ステートフルインスペクション型）

ネットワークACL

サブネット単位で設定するファイアウォール
ルールは番号で管理され、番号が小さい順で評価される。
アウトバウンドの戻りは考慮されない（ステートレスインスペクション型）
セキュリティグループの補助的な利用方法が推奨されています。

上記のような構成の場合、インターネットゲートウェイがアタッチされている10.0.0.0/24のサブネットはパブリックサブネットと呼ばれ、インターネットに接続可能なサブネットとなります。
インターネットゲートウェイがアタッチされていない10.0.2.0/24のサブネットはプライベートサブネットと呼ばれ、インターネット接続が不可能となります。

プライベートサブネットにはセキュリティレベルが高いものを配置するのが良いとされています。
上記の例ではEC2インスタンスを配置していますが、データベースなどを配置します。

プライベートサブネットに配置されているリソースにアクセスするためには、パブリックサブネットにあるEC2インスタンスAに一度ログインした後に、インスタンスAからプライベートサブネットのリソースにログインします。このログインの方法を踏み台、インスタンスAを踏み台サーバと呼びます。

EC2

EC2（Elastic Compute Cloud）とは、AWSが提供する仮想サーバです。
仮想サーバとは、AWSが管理するデータセンター（サーバ）上に個別に利用する論理的なサーバを作成し、利用することです。
上記に記載した、リージョン・AZから自身が利用するエリアを選択し、そこへEC2インスタンスを起動させて利用します。

EC2の料金は、リージョンや後述するインスタンスタイプによって異なるので、公式サイトで確認するようにしてください。

EC2を起動させるにあたって、利用用途にあったサーバを選択する必要があります。
どういった種類があるかを紹介していきます。

AMI

AMI（Amazon Machine Image）はEC2インスタンス作成時に必要な情報となります。
EC2作成時にAMIを指定し、EC2インスタンスを作成します。
このAMIにOSの情報が含まれています。
EC2では、AWS特有のAmazonLinuxを始め、CentOSやWindowsServerなど様々なOSが利用可能です。
＊最近では、EC2のOSにMacOSが登場したことでも話題になりました。

AMIではOSのみならず、ソフトウェアが含まれているAMIも利用できます。
AMIにWordPressが含まれており、すぐにブログが開設できたりもします。

インスタンスタイプ

AMIにて、OSを決めたらこれらを起動するサーバのスペックを選定します。
EC2において、CPUの処理速度やメモリサイズ等のスペックを決める物がインスタンスタイプです。
代表的な例として、無料枠で利用できる下記のt2.microで記載致します。

t：ファミリー名
2：世代番号
micro：インスタンスサイズ

インスタンスタイプを表す文字にはそれぞれ、上記のような意味合いがあります。
ファミリー名は後述します。
基本的には、世代番号は大きいもの、インスタンスサイズは利用用途にあったものを選択しましょう。

では、下記にインスタンスタイプの種類についてざっくり記載します。

t3系テスト向き

t系インスタンスはCPUバーストが可能な汎用インスタンスタイプです。
基本的にテスト環境・開発環境で利用するケースが多いです。
t3系インスタンスにはt3とt3aがありますが、t3はCPUがIntel社製、t3aはCPUがAMD製で10%ほど安価といった特徴があります。

M系汎用タイプ

M系は汎用タイプのインスタンスタイプです。
バランスの取れた、CPUやメモリとなっており、インスタンスタイプで迷った場合は、こちらを選択しておけばいいといったタイプ。

C系コンピューティング最適化

C系はCPUの性能を要する処理に最適化されています。
処理が多いWebサーバや、モデリング、機械学習等に向いています。

R系メモリ最適化

R系はメモリを要する処理に向いているタイプとなります。
高いパフォーマンスが必要なデータベースや、ビッグデータを扱う処理に向いてます。

P系高速コンピューティング

一番の特徴はGPUがついていることです。
3DCGやグラフィックに関連する処理に用いられます。
上記の処理以外にも、機械学習やデータマイニングに向いています。

H系ストレージ最適化

H系はストレージ最適化のタイプとなります。
ストレージの高性能なディスクスループット（読み書き速度）が特徴となります。
16TBの大容量ストレージを利用することも可能です。

EBS

EBS（Elastic Block Store）は、EC2にアタッチして使用する外付けディスクです。
種類に応じてIOPS（読み書き性能）が異なる。
スナップショット（バックアップ）が取得可能です。
＊異なるAZに配置されたEC2にEBSをアタッチすることは不可能

タイプ	種類	説明
SSD	汎用 SSD	EC2作成時にデフォルトで作成される。
SSD	プロビジョンド IOPS SSD	汎用SSDより性能が良い。課金して読み書き性能を自身で指定することができる。
HDD	スループット最適化 HDD	ビッグデータ等を溜め込むためのデータウェアハウスとしての利用に向いている。SSDに比べ安価。
HDD	Cold HDD	保管用。利用頻度が低いデータの保管に利用される。スループット最適化HDDよりも安価。

IAM

IAM（Identity and Access Management）とは、AWSにおける権限管理を行うためのサービスとなります。
まずはIAMにおけるユーザー管理について記載します。

IAMユーザー

AWSを利用するために、最初に作成する際にメールアドレス、パスワード、クレジットカード情報、連絡先情報を登録しアカウントを作成します。
この時にメールアドレスとパスワードを用いてログインするアカウント（ユーザー）のことをルートユーザーと呼びます。
ルートユーザーは全てのAWSリソースに対してフル権限、請求情報の閲覧可能、パスワードの変更が可能といったように、全ての作業を実行できるアカウントとなってます。
但し、ルートユーザーは日常の作業では利用しないようにAWS公式からも推奨されています。

では、どういったユーザーでAWS上で作業を行うかです。

ここで出て来るのが、IAMユーザーです。
IAMユーザーとはAWSアカウントの範囲内で個別に作成し利用するユーザーです。
最初に作成した、ルートユーザーから個別のIAMユーザーを作成し、それぞれのIAMユーザーに必要なだけの権限を付与し作業を行います。
この際に作業担当（開発・テスト・運用）ごとに必要な権限を最小に抑えることで、ミスを防ぎセキュリティレベルを上げることが推奨されています。
この権限を最小に抑えることを最小権限の原則という形でAWSのベストプラクティスとしています。

＊AWS環境構築におけるベストプラクティス集のことをAWS Well-Architected フレームワークという形で公開されていますので、一度目を通すのがいいかと思います。

IAMユーザーは人が利用するものに限らず、プログラムが利用する場合もあります。

人が利用する場合は、マネジメントコンソールへログインするためのパスワードをします。
プログラムが利用する場合は、アクセスキー・シークレットアクセスキーを利用してプログラムからAWSリソースにアクセスします。

AWSマネジメントコンソール

アクセスキーを利用するとどこからでもAWSのリソースの操作が可能となります。
アクセスキーが悪意のある他人に流出して、知らない間に数万〜数十万の請求が来たといった話もよく見かけます。
アクセスキーなんか流出しないだろうと思われるかもしれませんが、よく聞く原因として、
アクセスキーをプログラムのコードにベタ書きして、GitHubに公開されているリポジトリに上げるといったケースが多いようです。
こうならないように、自分は大丈夫とは思わず日頃から本当に公開していいコードかということを気を付けましょう。

IAMグループ

複数のIAMユーザーをまとめ、管理しやすくするためのものです。
IAMユーザーはそれぞれに認証情報を持っているが、IAMグループは正式な認証情報ではありません。

IAMポリシー

AWSリソースを操作できる権限を表したものです。
下記の画像のようにJSON形式の設定ファイルで記述されます。

認証主体（Identity）にアタッチして利用します。
IAMポリシーには管理ポリシーとインラインポリシーがあります。

管理ポリシー
- 管理ポリシーはIAMユーザーやIAMロールにアタッチして利用する独立したIAMのポリシー機能です。
- 管理ポリシーには更にAWS管理ポリシーとカスタマー管理ポリシーに分かれます。
  - AWS管理ポリシー
    - あらかじめAWS側で用意されているポリシーです。
    - フルアクセス権限や、サービス毎のリードオンリー権限等が用意されています。
    - AWS側で管理されているポリシーのため、サービス追加・更新に伴い自動でポリシーが更新されることがあります。
  - カスタマー管理ポリシー
    - ユーザー側で自由に作成・設定ができるポリシーです。
    - 細かい設定を行う場合には、こちらのポリシーを利用しましょう。
インラインポリシー
- 特定のIAMユーザー、IAMグループ、IAMロールに直接付与するポリシーです。
- 基本的には管理ポリシーを利用しますが、特定のユーザーにのみ権限を付与したい場合はインラインポリシーを使います。

IAMロール

IAMポリシーをアタッチして使用します。
IAMロールは複数のIAMポリシーをまとめてアタッチし、権限管理を行います。
スイッチロールという機能を利用することで、別アカウントのAWSリソースの利用が可能となります。

IAM関連の用語について

・アイデンティティ（Identity、ID）
AWSリソースの内、IAMポリシーを割り当てる事ができるもの。

・エンティティ
AWSが認証に利用するリソース

・プリンシパル
AWSリソースにリクエストを出すもの
（IAMグループは正式なプリンシパルではない。）

＊参考資料

RDS

マネージド型データベースサービス
上記、「クラウドコンピューティングのサービス形態」の図のPaasが該当します。
利用するデータベースのアプリケーション・データのみの管理で利用することができます。

下記にRDSの特徴を一部抜粋して記載致します。

選べるデータベースエンジン

RDSでは利用可能なデータベースエンジンが用意されており、ケースに合わせて適切なデータベースエンジンを選択することができます。
AWSが提供しているAuroraを始め、オープンソースのMySQLや商用であるORACLEなども選択可能です。

AWSでは、MySQLやPostgreSQLと互換性があり、MySQLの5倍のスループットが実現可能なAuroraを推奨しています。

マスター - スレーブ構成

マスター - スレーブ構成は、メインで利用するマスターのインスタンスとサブ的な扱いのスレーブを別のAZへ配置する構成です。
マスターのデータを更新した際に、リアルタイムで更新内容をスレーブへ複製（レプリケーション）します。
また、RDSへのアクセスをIPアドレスではなく、エンドポイントでアクセスすることで、マスターに障害を検知した場合でも接続先を自動的にスレーブの方へ更新されます。
この構成を取ることで可用性を高めることができます。

リードレプリカ

リードレプリカは、参照・読み込み用のインスタンスと、更新のインスタンスを分けることで、マスターへの負荷を軽減させようという構成です。

その他

スナップショット

定期スナップショットや、手動でのスナップショットを取得することにより、データを保護します。

パッチ当て機能

時間指定をしてパッチを当てる時間をコントロールし、自動でパッチを適用できます。

パラメータ設定

パラメータグループを使って設定値を変える事ができます。

あとがき

AWSの基本的なサービスについて、ざっくり書くつもりでしたが、思っていた以上に長くなってしまいました。
今回記載したサービスについても、まだまだ書ききれていない機能やサービスがあります。
まだ知らない機能等については、構築・削除が簡単にできるというクラウドサービスの特徴を活かし、学んでいきたいと思います。

他サービスや、今回記載したサービスについても別途記事を書いていきたいと思いますので、間違っている点等がございましたらご指摘いただけますと幸いです。
ここまで読んでいただき、ありがとうございました。

この記事はAWS初学者を導く体系的な動画学習サービス
「AWS CloudTech」の課題カリキュラムで作成しました。
https://aws-cloud-tech.com

AWS主要サービス概要