本記事は、次の記事を前提に記載しております。
まだ読まれていない方は、ぜひご一読くださいませ。
【AWS超入門】 EC2を使ってWordPressを立ち上げてみよう
AMIとは、インスタンスをまるごとバックアップしたもので、簡単にコピーを作成できることを上記の記事でお話させていただきました。
今回は、上記の記事で立ち上げたWordPressをもとに、
AWSのネットワークに関する基本的な知識を身につけていただきたく執筆しました。
立ち上げたWordPressがAWS上ではどのようなネットワーク構成となっているのか。
そしてどのようなAWSサービスが関連しているのか。
本記事をお読みいただくことで、AWSのネットワークに関する基礎知識が学べます。
まずは作成したWordPressのシステム構成をみてみよう
作成されたAWS上にあるWordPressのシステム構成は、以下の図のような構成となります。
この構成はAWSでは超基本的な構成でして、AWSのネットワーク周りを学ぶには最適です。
上記の構成をもとに、それぞれの要素をご説明させていただきます。
AWSの基本的なネットワーク要素を学ぼう
VPC（Virtual Private Cloud）
AWSアカウント専用の仮想ネットワークです。
この仮想ネットワーク内にEC2などのAWSリソースを起動することになります。
アカウント専用のネットワークですから、
他のアカウントのネットワークとは論理的に切り離されています。
ですので、VPCが別ならば基本的に通信はできませんし(※)、ネットワーク負荷の干渉といったこともありません。
完全に自身専用のネットワーク空間になるわけです。
※VPCピアリング等のサービスを使うことで通信させることも可能です。
AWSのサービスにはEC2のようにVPCの中で利用するものもありますが、
S3やCloudWatchのようにVPCの外で利用するものもあります。
AWSでシステム構成を考える際、そのサービスはVPCの中で使われるものなのか、それとも外で使われるものなのかを把握することも重要です。
アベイラビリティゾーン(AZ)
≒データセンターと思ってよろしいかと思います。
※データセンターとは物理サーバーが、いーーーっぱいある不思議な空間です。
なぜ＝ではなく、≒と使ったのかというと、アベイラビリティゾーンは複数のデータセンターを含んでいることがあるからです。
AWSは、どこにどのようなデータセンターがあるか特定できないようになっています。
詳しくは、以下の記事をご一読いただきたいのですが、セキュリティ上の問題が主な理由です。
AWSへ移行してセキュリティは問題無いのか？と思っている人へ
サブネット
サブネットとはVPCの中に、さらに仕切りを入れて分けた領域のことです。
サブネットはアベイラビリティゾーンと1:1の関係になります。
そしてEC2などのVPC内に起動するリソースのほとんどは、このサブネットの中で起動します。
別々のアベイラビリティゾーンのサブネットを作成し、それぞれにEC2を立てると、簡単に国内DR(Disaster Recovery)が組めちゃいます。
どういうことかというと、１つのアベイラビリティゾーンが災害によってダウンしても、別のアベイラビリティゾーンが生き残っているのでシステム全体としては止まらないということです。
DRが簡単に、そして安くできるという点がAWS等のパブリッククラウドの大きなメリットの一つです。
インターネットゲートウェイ
VPCの外はインターネット領域です。
VPCから一歩踏み出てインターネットと通信する場合、通信データは必ずこのインターネットゲートウェイを通ります。
インターネットゲートウェイとは、その名の通りVPCの中と外をつなぐ門の役割を果たします。
逆に言うと、インターネットゲートウェイがなければVPCの外とデータをやりとりすることはできません。
ルーターとルートテーブル
インターネットゲートウェイ、EC2があっても、それらは単なる点であってネットワーク上ではつながっていません。
通信データが通る”道”が無い状態です。
道がなければEC2とインターネットゲートウェイとの通信が行えません。
インターネットゲートウェイを通ることができないため、EC2は外の世界(インターネット)と通信することができません。
ですから、EC2からインターネットゲートウェイへの道を作る必要があります。
その役割をするのがルートテーブルです。
ルートテーブルは、VPCに備え付けられている我々ユーザーからは目に見えないルーターによって管理されています。
ちなみに、前回作成したWordPressはルートテーブルをいじらなくてもインターネット経由でアクセスができましたね？
これは、デフォルトでインターネットゲートウェイにつながるルートテーブルがあらかじめ用意されており、何も設定しなくても、そのデフォルトルートテーブルが使われるようになっていたからです。
セキュリティグループ
ルートテーブルによって道が作られましたが、それは単なる道であるため、どんなデータでも通ることができてしまいます。
セキュリティグループは、その道の上で、どのようなデータを通すか(または通さないのか)を判別する門番のような役割を担っています。
そのためセキュリティグループは、別名Firewallとも言われています。
セキュリティグループは、例えばEC2はどことどのようなアクセスをさせるのかといったアクセス制御を設定する重要な部分となります。
セキュリティグループにはインバウンド（受信側）とアウトバンド（送信側）の２種類の設定があります。
特にどのようなアクセスを受けるかといったインバウンド設定は重要です。
前回の記事では、以下のようなセキュリティグループが自動で作成されました。
▼インバウンド設定
HTTP通信：送信元(0.0.0.0/0) ※どこからでもOK
SSH通信：送信元(0.0.0.0/0) ※どこからでもOK
HTTPS通信：送信元(0.0.0.0/0) ※どこからでもOK
一般ユーザーが外部からサーバーへアクセスしてブログを読むのですから、HTTP通信、HTTPS通信についてはどこからでもアクセスを許可する必要があるでしょう。
ですが、SSH(※)については”どこからでもOK”というのはセキュリティ的に問題です。
どこからでもOKとしてしまうと、悪意を持った人に対してサーバーを乗っ取るハードルを下げてしまうからです。
ですので、SSHは送信元を自分のIPアドレスにするなどして設定変更をするのがよろしいかと思います。
※SSHはサーバにログインして遠隔操作を行うプロトコルです。
前回は簡単にWordPressが作成できましたが、実は上記のような細かな設定の上に成り立っております。
規模が大きくなればなるほど、このような設定は複雑になります。
今回はAWS初心者にはぜひとも習得していただきたいネットワークに関してご紹介させていただきました。
以上、hidesanでした！