【学習メモ】AWSの基礎をがっつり理解しにかかる〜#5-1 AWS基礎〜
概要
現在勤めている会社のチーム内で「AWS SAA」の資格を取得しにいこうという目標が挙がったので、約 1 年前に取得しました。
しかし、私自身は業務で触ることはあまりなかったので、資格は持っているものの、AWS の知識に自信がありません。
次の会社では触る機会が増えそうなので、ここで基本的なことをもう一度学習し直そうという試みです!
この記事で触れるサービス
- IAM
- VPC(およびネットワーク関連)
- EC2
- S3
- RDS
- Lambda
AWS 基礎まとめ
IAM
IAM とは
IAM(Identity and Access Management)とは、ユーザーやユーザー権限を管理するためのもの。IAM を使用することで、ユーザー、セキュリティ情報、アクセス権限、などを集中管理することができる。
IAM で管理できる Object
- User
- Groups
- Policies
- Roles
デフォルトのユーザー権限
- AWS アカウントを作成した際に作成されるルートユーザーはデフォルトで admin 権限を持っている。
- 一方、ルートユーザー以外の新規で作成されたユーザーはデフォルトで何も権限を持っていないため、どの AWS サービスにもアクセスできない。
ポリシー
ポリシーとはどのリソースに対してアクセスを許可するかを定義したもの。このポリシーをユーザー、グループ、ロール(AWS リソースなど)にアタッチすることによって、「誰が」「どのリソース」に「どうゆう操作」が許可されるかを設定できる。(要は権限を与えられる)
ポリシーは以下のように JSON で定義されている。
基本的なプロパティについては以下
- Effect:アクセスの許可(Allow) or 拒否(Deny)
- Action:AWS のサービスに対して行われる API コールを指定
- Resource:ポリシールールの対象となるエンティティの範囲を指定
IAM ユーザー
ユーザーに直接 IAM ポリシー(権限)をアタッチすることができる。ユーザーに権限を付与する場合、以下のグループでも可能であるが、ユーザーに個別の権限を与えたい場合は、直接ポリシーをアタッチする。
IAM グループ
グループに IAM ポリシーをアタッチすることで、そのグループに所属するユーザーの権限を管理できる。
ユーザー毎にポリシーのアタッチをする必要がないので、手間が省ける。
これは IAM ユーザーに直接ポリシーをアタッチしていたものと比較すると、間接的なポリシーのアタッチになる。
IAM ロール
例えば、EC2 にデプロイしたアプリケーションから S3 に対してアクセスしたい場合、EC2 には直接 IAM ポリシーをアタッチできない。
この場合は、IAM ロールに必要な権限を設定しておき、EC2 に IAM ロールをアタッチする。(IAM ポリシーの直接のアタッチはユーザーしかできない。)
VPC(およびネットワーク関連)
VPC とは
Amazon Virtual Private Cloud。要は AWS 上で利用する仮想ネットワークのこと。
公式ドキュメントでは以下のように記述されている
- Amazon Virtual Private Cloud (Amazon VPC) を使用すると、論理的に隔離されている定義済みの仮想ネットワーク内で AWS リソースを起動できます。仮想ネットワークは、お客様自身のデータセンターで運用されていた従来のネットワークによく似ていますが、AWS のスケーラブルなインフラストラクチャを使用できるというメリットがあります。
Amazon VPC とは? - Amazon Virtual Private Cloud
Internet Gateway とは
ネットワークをインターネットに接続するためのもの。要は VPC に InternetGateway(IGW)をアタッチすることでインターネットとの通信が可能になる。逆に VPC に IGW がアタッチされていない状態だとその VPC 内のリソースは外部との通信ができない状態となる。
補足
- 1 つの VPC に対して、IGW は 1 つしかアタッチできない。
- もし、VPC 内に利用されている AWS リソース(EC2 など)がある場合は、IGW を VPC からデタッチすることはできない。(先に AWS リソースを削除する必要がある。)
ルートテーブルとは
サブネットまたはゲートウェイからのネットワークトラフィックの経路を判断する際に使用される。要はルーティング機能を提供してくれる。
ルートテーブルの例
後のサブネットのところで記述しますが、上記はパブリックサブネットのルートテーブルの例です。
(パブリックサブネットとプライベートサブネットのルートテーブルについては、こちらで記述してます。)
補足
-
ルートテーブルはサブネットを複数関連付けることができる。
-
サブネットには 1 つのルートテーブルしか関連付けることはできない。
- 要は 1 対多の関係になっている。
ルートテーブル 1 ——— * サブネット
- 要は 1 対多の関係になっている。
-
ルートテーブルは 1 つの VPC に対しては複数作成できる。
-
ルートテーブルにサブネットが関連づけられている場合、そのルートテーブルは削除できない。
NACLs とは
Network Access Control Lists(ネットワーク ACL)。サブネットのインバウンドトラフィックとアウトバウンドトラフィックを制御するファイアウォールとして機能する任意指定のセキュリティレイヤー。要はファイアウォールだけど、任意なので、必ず設定しないといけないものではない点に注意。
ネットワーク ACL はステートレス。つまり、インバウンドを許可してもアウトバウンドは自動で許可してくれない。(例:ポート 80 でアウトバウンドを許可し、リクエストを送信できるようにしても、インバウンドを許可していなかったら、レスポンスが到達しない)
インバウンド、アウトバウンドルールの例
上記の例では、インバウンド、アウトバウンドともに 1 行目で全てのトラフィックを許可しています。
この例では 2 行目のルールが適用されることはありませんが、全てのルールに該当しなかった場合に、*
のルールが適用されます。(基本的に拒否となる)
補足
-
ネットワーク ACL はサブネットを複数関連付けることができる。
-
サブネットには 1 つのネットワーク ACL しか関連付けることはできない。
- ルートテーブル同様に 1 対多の関係になっている。
ネットワークACL 1 ——— * サブネット
- ルートテーブル同様に 1 対多の関係になっている。
-
ネットワーク ACL はルールの番号付きリストが含まれ、低い番号から順番に評価される。(ルールに該当した場合、以降のルールは無視される)
-
ネットワーク ACL で許可されたトラフィックがサブネットに入った後は、セキュリティグループによって、トラフィックを制御できる。
サブネットとは
VPC 内のサブセクション。要は VPC の IP アドレスレンジで VPC を複数のセクションに分割できるものがサブネット。同じ VPC で、サブネットは 1 つの AZ に 1 つだけ作成が可能。(パブリックとプライベートでそれぞれ 1 つ)
補足
サブネットは以下の 3 つの特徴がある
- 特定の VPC に属する(VPC のサブセットとなるのがサブネット)
- AZ を跨ぐことはできない(単一の AZ に属する)
- IP アドレスのレンジがある
パブリック IPv4 アドレスの自動割り当て
「パブリック IPv4 アドレスの自動割り当て」がはい
となっていた場合、そのサブネットで起動される全てのインスタンスパブリック IPv4 が提供される。
これを有効にするためには
- サブネットを選択
- 「アクション」→「サブネットの設定を編集」
- IP アドレスの自動割り当て設定の項目から「パブリック IPv4 アドレスの自動割り当てを有効化」にチェックする
パブリックサブネットとプライベートサブネット
パブリックサブネットとプライベートサブネットの違いは、インターネットと接続できるか。具体的にはそのサブネットの「ルートテーブル」を確認し、IGW への接続が許可されているか否かで決まる。
パブリックサブネットとプライベートサブネットの確認方法
- パブリックサブネットのルートテーブル
上記の図は 0.0.0.0/0(10.0.0.0/16 以外の全ての送信先)の対象がインターネットゲートウェイに向いているので、パブリックサブネットと言える。
- プライベートサブネットのルートテーブル
上記の図では、インターネットゲートウェイに向いているテーブルがないので、プライベートサブネットと言える。
その代わりに 2 行目のルールが NAT ゲートウェイに向いているので、アウトバウンドのみ可能となる。(インターネット側からの通信はできないが、サブネット側からインターネットへの通信は可能となる。要は一方通行の通信の通信でプライベートな領域であることに変わりはない)
サブネットをパブリックサブネットにする。(IGW への接続を許可する)
サブネットにインターネットゲートウェイ(IGW)をアタッチするには、まず VPC に IGW をアタッチする必要があります。
- インターネットゲートウェイの画面から IG を作成
- 作成した IG にチェック
- 「アクション」→「VPC」にアタッチ
- 「使用可能な VPC」でアタッチしたい VPC を選択
- 「インターネットゲートウェイのアタッチ」
次に、ルートテーブルを作成し、サブネットに関連付けします。
- ルートテーブルの画面に移動 →「ルートテーブルを作成」
- ルートテーブル設定で任意の名前、関連づけたいサブネットが含まれる VPC を選択 → ルートテーブルを作成
- 作成したルートテーブルのページ下部の「ルート」→ 「ルートを編集」(デフォルトで VPC ネットワーク内への通信が許可されている)
- ルートを追加
- 全ての送信先(0.0.0.0/0)を作成した IGW に向ける
- サブネットの画面に移動 → 対象サブネットの「ルートテーブル」から「ルートテーブルの関連付けを編集」
- 作成したルートテーブル ID を紐付けて保存
これでパブリックサブネットと呼ばれる状態になりました!
AWS ネットワーク図
上記で解説したリソースがどうゆう関係になっているか図にしたものが以下
補足
セキュリティグループについて、ここで記述しなかったのは、セキュリティグループはサブネットレベルではなく、インスタンスレベルで動作するため。
EC2
Amazon Elastic Compute Cloud。もはや説明は不要と思いますが、AWS 上で起動できるコンピューター(わかりやすく言えばデスクトップ PC)。
もちろん、お好きなスペックでスケーラブルにインスタンスを起動できる。EC2 を使用することで仮想サーバーが起動できる。
- 契約形態
- オンデマンドインスタンス
- 秒単位で使用するインスタンスに対して料金が発生する。最も高価になるが、不要になったらすぐに削除できる。
- 前払いや長期間の使用が予測できず、柔軟性を重視する場合に使用
- 予測不能な作業負荷があっても中断できないアプリケーションに使用
- 初めて EC2 で開発またはテストするアプリケーションに使用
- リザーブドインスタンス
- 1~3 年の期間、特定のインスタンス設定を継続契約する場合。定められた期間契約する必要があるが、料金は節約できる。
- 定常的に使用するアプリケーションに使用
- スポットインスタンス
- オークションのような形式で未使用のインスタンスをリクエストすることで大幅なコスト削減が可能。その代わり、急に停止される可能性がある。
- 開始および終了時間が柔軟なアプリケーション
- 緊急で追加のキャパシティーが必要なユーザー(ビットコインのマイニングのように必要な場合にのみパワーを要する場合など)
- オンデマンドインスタンス
AMI
Amazon Machin Image。EBS に格納される、暗号化されたマシンイメージ(Docker でいうところの image みたいなもの)。
AMI に含まれるものは、ソフトウェア、データベース、ミドルウェア、ウェブサーバーなどのアプリケーションレイヤーも含むことができる。
EBS
Elastic Block Store。EC2 インスタンスで使用できるスレージボリューム。
特定の AZ 内で作成でき、その AZ 内のインスタンスにアタッチ、デタッチできる。(AZ を超えての使用は不可。)
※ただし、アタッチ、デタッチができるのはカスタムボリュームだけ。 - EBS にはルートボリュームとカスタムボリュームがある。ルートは PC でいうところの内臓のボリューム、カスタムは外付けボリュームのイメージ
EC2 インスタンスの有効期限とは無関係に存続できる。(例えば、A という EC2 インスタンスにアタッチされてた EBS に対して、A のインスタンスが停止されたとしても EBS を残り続けるということ)
セキュリティグループ
セキュリティグループは関連づけられたリソースに対して、インバウンド、アウトバウンドのトラフィックを制御するためのもの。
NACL との違い
-
NACL
- サブネットレベルでの適用
- ルールは許可 or 拒否
- 番号付きリストの小さいものから順に評価され、該当するものが即座に適応される。(適用以降のルールは無視される)
- ステートレス(インバウンドで入ってきたものを覚えていない。よって、アウトバウンドでも許可してあげないと入ってはくるが、返さないという状態になる)
-
セキュリティグループ
- インスタンスレベル(EC2)
- ルールは明示的な許可のみ(許可されていないものは全て拒否)
- インスタンスに関連づけられている全てのセキュリティグループの全てのルールを評価する。
- ステートフル(インバウンドで入ってきたものを覚えている。よって、インバウンドで入ってきたものはアウトバウンドでも自動的に許可される)
NACL、セキュリティグループのイメージ図
セキュリティグループのデフォルトの状態は
- デフォルトのセキュリティグループ
- 全てのインバウンド、アウトバウンドが許可
- 新規に作成したセキュリティグループ
- 全てのインバウンドは拒否、全てのアウトバウンドが許可
となっている。
パブリック IP とプライベート IP
ネットワークのお話になりますが、パブリック IP とプライベート IP について
-
プライベート IP
- インターネットから到達できない IP アドレス
- 使用用途は同じネットワーク内(ローカルネットワーク)での通信に使用される。
-
パブリック IP
- インターネットから到達可能な IP アドレス
EC2 インスタンスにも自動でパブリック IP の割り当ての可否を決められる。
終了保護
EC2 インスタンスは不要になったらいつでも終了できる。終了したインスタンスのリソースは解放され、再起動することは不可能です。
便利な反面、意図せず終了した場合、とんでもないことになってしまいます。
EC2 インスタンス作成時に、「高度な詳細」から「終了保護」を有効化することで意図しない修了を防ぐことができます。
インスタンスのログ取得
起動中の EC2 インスタンスのログを取得するには、アクション > モニタリングとトラブルシューティング > システムログを取得
から取得することができます。
S3
Simple Storage Service。インターネット用のストレージサービス
バケットとは
- S3 に格納されるオブジェクトのコンテナ。全てのオブジェクトはバケット内に格納される。
- ルートレベルのフォルダーをバケットと呼ぶ
- サブフォルダーのことをフォルダーと呼ぶ
- バケット名は全て小文字かつ、グローバルでユニークな名前
オブジェクトとは
- S3 に格納される基本エンティティ。オブジェクトはオブジェクトデータとメタデータで構成される。
Regions とは
- S3 で作成したバケットを保存する地理的なリージョンを選択。地理的に近いリージョンを選択することでパフォーマンスを最適化する。
DB
AWS では、RDBMS と NoSQL で以下の 2 つにサービスが分かれる。
RDS
AWS 上で構築するリレーショナル DB のこと。
以下の RDBMS が構築可能
- Amazon Aurora
- MySQL
- PostgreSQL
- Oracle
- Microsoft SQLServer
DynamoDB
AWS 上で構築する NoSQL のこと。
完全マネージド型の NoSQL データベースサービスであり、高速かつシームレスな拡張性が特徴。
Lamdba
Lamdba とは、サーバーをプロビジョニングしたり管理したりする必要がなくコードを実行できるコンピューティングサービス。
いわゆるサーバーレスというもので、サーバーの管理等は AWS 側でやってくれるためユーザーはコードを用意するだけで良い。
Lamdba の特徴は
- 必要時のみにコードを実行し、小規模から大規模なリクエストまで自動的にスケーリングする
- 使用時間のみ課金対象となるため、コードが実行中でなければ料金は発生しない
- サーバーの管理はユーザーは全くする必要がない
Discussion