【 はじめに 】
つい先日、AWS初心者の僕がインフラ設計/構築の担当者になった、、。
「何事も経験だ!」と、自分から手を挙げたものの、覚えることが多すぎやしないかと困惑しつつ、
これも自分の伸びしろだと、、まだまだ伸びる証拠だとポジティブに捉えて、
勉強を進めていきたいと思います。
「 "成功" より "成長" に囚われろ
！ 」 By Keisuke Honda
【 目次 】
- 現状の課題とその解決策
- 対象読者の皆さん
- お願い
- 本題
4-1. リージョン (Region)
4-2. アベイラビリティーゾーン (AZ:Availability Zone)
4-3. VPC (Virtual Private Cloud)
4-4. サブネット(Subnet)
4-5. インターネットゲートウェイ (Internet Gateway)
4-6. デフォルトゲートウェイ (Default Gatewaya)
4-7. ルーター (Router)
4-8. ルートテーブル (Route Table)
4-9. NAT (NAT Gateway)
4-10. 踏み台サーバー (Bastion Server)
4-11. セキュリティグループ (Security Group)
4-12. ElasticIP
4-13. VPCエンドポイント
4-14. IAM (Identity and Access Management)
4-15. ACL (Access Control List)
- その他
- 最後に
【 1. 現状の課題とその解決策 】
作業を開始してから2週間程度が経過した時点で、このまま場当たり的に知識を身に着けて行くのは、
かなり効率が悪いということに気が付いた。もちろん現場で起こっている課題を解決しながら、
場当たり的に問題解決能力を知識を身に着けていくことも重要だと思う。
しかしながら、この局面 (AWSのサービスを全く知らない。インフラに関しての知識はゼロ。)
においては、クラウドの基礎知識を体系的に一からきちんと知識を身に着けていく戦法が有効だと考える。
理由は、下記の通り。
- 各単語の関係性についても合わせて学習することにより、単語の忘却曲線をより緩やかにすることができる。
現状の課題 (1) : 単発だと結構すぐに忘れてしまう。 - クラウドの全体像を把握するスピードが早くなるので、効率よく知識を吸収することができる。
現状の課題 (2) : 基礎知識を短期間で習得できるので、後々応用が効きやすい。 - いきなりAWSコンソール画面を触って間違えてしまうといったような無駄が無くなる。
現状の課題 (3) : 基礎がないので、想定していないミスをするケースも。。(痛い目に合うのも大事だけどｗ)
上記のような理由より、自分の知識を蓄積し、常にアップデートしていくため手段 (備忘録) として、
Qiitaに思考プロセス等を書き残していこうと思う。
(他の人がこれを読むことで勉強になるかどうかは分からないですが、、。)
【 2. 対象読者のみなさん 】
- 業務でインフラを担当することになったけど、どうしたら良いのかイマイチ分からない人
- インフラ構成図を見て一通り内容を理解しておきたい人
- AWSインフラに興味があるけど、触ったことがない人 etc ..
【 3. お願い 】
もし、本記事の内容に「誤り・誤字」があれば、遠慮なくお気軽にご指摘いただければ幸いです。
それでは、AWSでのインフラ構築担当になってまず最初に覚えたワード15選について、
筆者が参考にしたサイト、各概念の分かりやすい表現をPickUp
!しながら、
ご説明させていただこうと思います。
読んでいただいた方のお役に立てるような記事にしたいと思っていますので、
どうぞ最後までお付き合いください 
!!!
【 4. 本題 】AWS初心者がインフラ設計/構築を理解するために、まず最初におさえるべき専門用語 15選
まずは、「AWSって何なの？」ってところから。
00. AWSの基本概念
AWSは、「Amazon Web Service」の略なんだけど、AWSとは？
と何も見ずに語れるほどの知識はないので、この部分に関しては後日アップデートする予定です。
[ 2017/10/13(Fri)時点での、筆者のAWSへ対する認識 ]
クラウドコンピューティングのリソースを提供していて、その上に様々なサービスを乗っけて、
誰でも簡単に？使った分だけの費用(従量課金)でインフラ環境を構築できるサービスってイメージ。
クラウドコンピューティングのリソースというのは、
世界各地にあるAWSが保有しているデータセンターのことなんだけど、、
まず最初に、
「どの地域 [リージョン(Region)] の」コンピューティングリソースを使用するのか？
ということを決めないといけない。
1. リージョン (Region)
リージョン(Region) 自体は「範囲、領域」を持つ英単語
Amazon クラウドコンピューティングリソースは世界各地の多くの場所でホストされており、
これらの世界各地の拠点、物理的に離れている領域のことをリージョン(Region)と言います。
2017/10/12(木)時点で、世界中に16個ものリージョン(Region)が存在します。
(以下、「AWS公式サイト」より引用。)
※今後、さらに5つのリージョンが追加される予定みたいです。(2017/10/12時点)
・中国
・フランス
・香港
・スウェーデン
・米国 (2番目のAWS GovCloudリージョン)
初めてAWSサービスに触れられる方は、とりあえず何も考えずに、
アジアパシフィック(東京リージョン)を選ばれることをお勧めいたします。
※別途リージョン選択についての細かな部分について紹介する記事を書こうと思います。
[参考サイト]
各リージョン内にはかならず2つ以上のアベイラビリティーゾーン (≒データセンター)と呼ばれる拠点があります。
続いては、そのアベイラビリティーゾーンについてご紹介したいと思います。
2. アベイラビリティーゾーン (AZ : Availability Zone)
アベイラビリティーゾーンを物凄く分かりやすく、簡単に言うと、、。
東京リージョン（物理的に離れた地域）= 東京という都市(場所)に、3つの独立したデータセンター(拠点)が存在し、
この各々のデータセンターのことを「アベイラビリティーゾーン(AZ)」と言います。
* 1つのリージョン内に2つ以上のアベイラビリティーゾーン(データセンター)が存在するので、
インフラ設計をする際は、複数のアベイラビリティーゾーン(Multi-AZ)を活用することにより、
構築するインフラ/アプリケーションの耐障害性を向上させることができます。
「リージョンとアベイラビリティゾーンに関する概念について」
各リージョンは完全に独立しています。各アベイラビリティーゾーンも独立していますが、
同じリージョン内のアベイラビリティーゾーン同士は低レイテンシーのリンクで接続されています。
「リージョンとアベイラビリティーゾーン」より引用
3. VPC (Virtual Private Cloud)
AWSクラウドの論理的に分離した領域 (セクション) を、誰でも簡単に用意することができます。
下図のようなイメージです。
この VPC (Virtual Private Cloud) を活用すると、自分で定義した仮想ネットワーク内に
AWSリソース (ex. EC2,RDS) を起動させることができます。
※ VPC (Virtual Private Cloud) のIPアドレスは、以下規則で指定することができます。
- VPC全体で1つのIPアドレスを持つ
- サブネットでIPアドレス空間を分割する
[ ※注意 ]
ネットワークアドレスは作成後変更不可なので、あらかじめ20ビット以下など、
ある程度のレンジを持つアドレスを設定しておくのが無難です。
[参考サイト]
- インフラエンジニアに贈るAmazon VPC入門 #1 概要とルーティング
4. サブネット(Subnet [Public, Private])
サブネットとは、大きなネットワーク (≒VPC) を
複数の小さなネットワークに分割して管理する際の管理単位となる小さなネットワーク (≒サブネット) のこと。
※下図のようなイメージ。
自分で定義したネットワーク(VPC)を複数のネットワークに分割するために使用します。
具体的には、各インスタンスの役割ごとにグループ化 (サブネットに分割) し、
ルートテーブルをアタッチする際などに使われることが多い (きめ細やかなアクセスコントロールが可能) です。
[ パブリックサブネット ] と [ プライベートサブネット ] の違いについて
まずは、下図をご覧ください！
上図の通り、インターネットからVPCインスタンスに接続する ためには、
インターネットゲートウェイ (次項で説明) を用意する必要があります。
そして、VPCネットワーク内にあるルーターを介して、各サブネット内のインスタンスへ通信が行われます。
この時、各サブネットにアタッチされているルートテーブル (経路制御表) の内容に沿って、
インターネットからのアクセスを許可するのか、許可しないのかを判断します。
上記の違いで、パブリックサブネット, プライベートサブネットの区別をしています。
- インターネット(外部ネットワーク)からのアクセスを許可したサブネットを「パブリックサブネット」
- VPC内部の通信のみ許可しているサブネットを「プライベートサブネット」
[参考サイト]
- VPC初心者がハマりやすいポイントをまとめてみた
5. インターネットゲートウェイ (Internet Gateway)
インターネットゲートウェイは、VPCのインスタンスとインターネットとの間の通信を可能にする
VPCコンポーネント。
こちらのインターネットゲートウェイの役割は大きく2つあります。
1. VPCネットワークのルートテーブルに、インターネットへルーティングが可能な宛先を追加すること。
2. パブリックIPv4アドレスが割り当てられているインスタンスに対して、ネットワークアドレス変換(NAT)を行うこと。
※ 2に関して、筆者自身これだけでは理解できなかったので、
公式サイトの説明を元に少し掘り下げて解説します。
インターネットゲートウェイには、NAT (Network Address Translation) ( 後ほど、9.にて解説 ) と呼ばれる機能があります。
インターネットゲートウェイはインスタンスに代わって1 対 1 の NAT を論理的に行います。
ここで言う1対1というのは、「パブリックIPv4アドレス」と「プライベートIPアドレス」のことです。
[ Outbound通信時 (VPC→インターネット) ]
(通常) : プライベートIPv4アドレス → パブリックIPv4
(ElasticIP) : プライベートIPv4アドレス → ElasticIPアドレス
そのため、トラフィックが VPC サブネットから出てインターネットへ向かうとき、返信アドレスフィールドは、インスタンスのプライベート IP アドレスではなくパブリック IPv4 アドレスまたは Elastic IP アドレスに設定されます。
[ Inbound通信時 (インターネット→VPC) ]
(通常) : パブリックIPv4 → プライベートIPv4アドレス
(ElasticIP) : ElasticIPアドレス → プライベートIPv4アドレス
逆に、インスタンスのパブリック IPv4 アドレスまたは Elastic IP アドレス宛てのトラフィックは、その送信先アドレスがインスタンスのプライベート IPv4 アドレスに変換されてから、VPC に配信されます。
_このようにインターネットに接続するために必要なネットワークアドレスの変換(NAT)の役割も、インターネットゲートウェイが果たしてくれます。_
[参考サイト]
- インターネットゲートウェイ (公式サイト)
- 知識0から、AWSのEC2でウェブサーバーを構築するまで
6. デフォルトゲートウェイ (Default Gateway)
所属するLANなどの内部ネットワーク (AWS上のサブネットもしくは、VPC) から、
外部にあるネットワーク(他のサブネットもしくは、インターネット)に通信を行う場合の
出入り口の役割を果たすよう設定されているルーターやコンピューターのことです。
デフォルトゲートウェイは、
ネットワーク上でプロトコル(規約)が異なる複数のデータを相互に変換し通信を可能
にします。
[参考サイト]
- デフォルトゲートウェイ - OCN
7. ルーター(Router)
IP(Internet Protocol)で通信する端末は、まず最初に通信相手が自分と同じネットワーク(同一サブネット内)に
属する端末かどうかを調べ、自身の属するネットワーク外への通信であれば、ルーター(Router)を経由して
通信を行います。
[参考サイト]
- ルーティングの基本動作を見てみよう
8. ルートテーブル (経路制御表:ルーティングテーブル)
ルーターや端末が保持するパケットの配送先に関する経路情報。
VPCの各サブネットをルートテーブル
ルートテーブルの生成・管理方式には、下記2種類が存在します。
・Static Routing (スタティックルーティング)
経路情報を各ルーター内に手動で設定する手法で、
この経路情報は基本的にルート・テーブルより消えることがありません。
・Dynamic Routing (ダイナミックルーティング)
「RIP(Routing Information Protocolo)」「OSPF(Open Shortest Path First)」
「BGP(Border Gateway Protocol)」などのルーティング・プロトコルを用いて、
ルーターが経路情報を自動的に学習する手法で、この経路情報は動的に更新されます。
[参考サイト]
- ルーティング・プロトコルの役割を理解する
9. NAT (NAT Gateway)
NATとは、Network Address Translationの略称であり、IPアドレスを変換する技術です。
一般的には、プライベートIPアドレスをグローバルIPアドレスに変換する技術とされています。
ex.
企業LAN内のクライアントPCがインターネットに接続する場合に、プライベートIPアドレスを
グローバルIPアドレスに変換する必要があります。
この時に必要になる仕組みが、NAT(NAT:Network Address Translation)です。
10. 踏み台(Bastion)サーバー
メンテナンスの為の接続経路用途で用意されるサーバーのことを指します。
具体的には、アプリサーバー自体が外部(インターネット)から直接SSH接続を受け付けること自体、セキュリティの観点からもよろしくないので、外部からのSSH接続は、アプリサーバーとは別の専用サーバーが受け付けるべきです。そして、そのサーバーからアプリサーバーにSSH接続するといった二段階接続の構えを取ることでセキュアな環境を実現することができます。この時に用意するサーバーが上記の踏み台(Bastion)サーバーとなります。
また、踏み台サーバーは管理者が使用する時間帯以外は停止状態にしておくことにより、
部外者が勝手に侵入するといった心配もなくなるので、セキュアな構成を実現できる仕組みとなります。
11. セキュリティグループ
異なるセキュリティグループに属するインスタンスと通信を行う際に、
トラフィックの制御を行う仮想ファイアウォールとして機能します。
※セキュリティグループはサブネット単位ではなく、インスタンス単位で設定する必要があります。
また、インスタンスを起動 ( 新規作成 ) する際には、対象のインスタンスと1つ以上のセキュリティグループとの
関連付けが必須となります。
[参考サイト]
- Linux インスタンスの Amazon EC2 セキュリティグループ (公式サイト)
- Amazon VPCにおけるセキュリティグループの役割
12. ElasticIP
インターネットからアクセス可能なパブリック IPv4 アドレス。
インスタンスにパブリック IPv4 アドレスがない場合、Elastic IP アドレスとインスタンスを関連付けて
インターネットとの通信を有効にする仕組み。
ex.
ローカルコンピュータからインスタンスに接続するなど。
[参考サイト]
- ElasticIPアドレス (公式サイト)
13. VPCエンドポイント
VPC のインスタンスがプライベート IP アドレスを使用して、
他のサービス (S3, RDS等) のリソースと通信できる仕組み。
[参考サイト]
- S3 VPCエンドポイントを利用するメリット
01. アクセスポリシー
AWSでのアクセスポリシーオプション (アクセス制御 ) は、大きく2つに分類されます。
- リソースベース(S3のバケットやオブジェクトに対して)のポリシー
- ユーザーポリシー
どのようなアクセス制御をしたいかによって、
リソース自体に閲覧等の権限を付けるもの (リソースベースのポリシー)、
ユーザー単位で操作可能範囲を決めるもの (ユーザーポリシー)など、
柔軟性の高いアクセスポリシー設定が可能です。
本記事では、それぞれ代表的なものを一つずつ紹介したいと思います。
14. IAM (Identity and Access Management) 【 ユーザーポリシー 】
ユーザーに対して、AWSへのアクセスを安全に制御するための仕組み。 AWSコンソール画面から設定が可能で、
IAM (Identity and Access Management) の利用自体が課金対象になることはありません。 (基本無料)
IAMを使用することにより、下記のようなケースでアクセス制御を行うことができます。
- どのユーザーがAWSリソースを使用できるか？
- (リソースを使用できる場合)どのような方法で使用することが可能か？
[参考サイト]
- IAMとは
15. ACL (Access Control List) 【 リソースベースのポリシー 】
リソースごとに少しずつ設定方法が異なるみたいですが、今回はS3()のバケットやオブジェクト
に対してのアクセス管理について紹介したいと思います。
各リソースには、サブリソースとして、ACLをアタッチする必要があります。
このACLによって、アクセスが許可されるAWSアカウントまたはグループと、アクセスの種類が定義されます。
当該リソースに対するリクエストを受信すると、Amazon S3はアタッチされたACLの内容を調べて、
リクエスト送信者がACLの内容を満たしているか判断します。
[参考サイト]
- アクセスコントロールリスト(ACL)の概要
- S3のアクセスコントロールまとめ
[ 筆者失敗談 ]
[※注意！] するほどでもない話。
もし、AWSのアカウントを取得されている方でこれからEC2インスタンスを生成するという方、
S3に新しいバケットを作られるという方はですね、今一度AWSコンソール画面右上のリージョン設定を
ご確認いただくことをお勧めいたします。
僕は気が付いたら、米国西部 (オレゴン) のリージョンでEC2インスタンスを立ち上げていて、
他のEC2インスタンス(東京リージョンで作成済み)がコンソール画面で確認できないので凄く焦りましたｗ
みなさんはこんな凡ミスはしないとは思いますが、一応ここに間違えた人間がいるので、記載しておきます。
【 最後に 】
今後記事内容をアップデートしていきながら、自分自身もAWSへの知見を深められたらなと思います。
最後までお読みいただき、ありがとうございました (^^)/