この記事の目的
AWSで冗長構成するときに、見落とされてしまいがちなセキュリティー、ネットワーク周りの設定。冗長化の設定方法は、多くの記事で書かれているので、そちらの記事を見ていただくとして、本記事は、私自身がネットワーク関連の設定をしていて、躓いてしまったところ、躓きやすいところをシェアしていきたいと思います。
今回は、下記構成図の通り、環境を構築したと仮定して、構成図に沿って設定されているかどうか見ていきたいと思います。
構成図
今回、パブリックサブネットにあるインスタンスには、WordPressをインストールしてあります。
VPC関連
VPCとは、AWSクラウド内で論理的に分離したセクションのことです。
VPCは、主に以下のもので構成されています。
・サブネット
・インターネットゲートウェイ
・NATゲートウェイ
・VPCエンドポイント
この時点で上記構成図において、VPC、サブネット、インターネットゲートウェイが適切に設定されているか見ないといけません。
VPC
まず、VPCから見ていきます。
Ipv4 CIDER：10.0.0.0/21
VPC設計時のポイントとしては、広い範囲でアドレス範囲を設定することになります。そうすることによって、運用上、IPアドレスが枯渇してきたり、新たに別のサブネットを追加したい場合などに、VPC内に設置するサブネットの追加で対応することができるようになります。
インターネットゲートウェイ
次に、インターネットゲートウェイ。インターネットゲートウェイは、VPCにアタッチされているか確認します。
サブネット
そして、サブネット。サブネットは、VPC内に設置していきます。サブネット設置の際に、AZ（アベイラビリティーゾーン）という物理的な区分に設置していきます。冗長構成時においては、サブネットの機能ごと（パブリックサブネット、プライベートサブネット）に各AZ（ 1a,1c）に配置していきます。ですので、サブネットは、AZをまたがって設置することはできません。
publicsubnet1は、この構成図の左上の区画です。10.0.0.0/24のIP範囲で アベイラビリティーゾーンは、ap-northeast1a、今回設定したmyvpc内に配置されていることが確認できます。
残りの３つのサブネットも同様に適切に設定されているか見ていきます。
サブネットグループ
RDSをマルチAZ構成にする際に、異なるAZにあるサブネットをグルーピングしてあげる必要があります。
アベイラビリティーゾーン1aに10.0.2.0/24のサブネットとアベイラビリティーゾーン1cに10.0.3.0/24のサブネットがあることが確認できます。
ルートテーブル
ルートテーブルとは、サブネットやゲートウェイなどのルーティングを制御する仕組みのことです。サブネットの主な種類として、パブリックサブネット、プライベートサブネットがありますが、その区分けをこのルートテーブルで設定していきます。
まず、パブリックサブネット１（構成図の左上）のルートテーブルを見ていきます。ルートテーブルは、サブネットに関連づけられているので、該当のサブネットを選択した状態で「ルートテーブル」のタブを開きます。
下にスクロール
送信先10.0.0.0/21、ターゲットlocalは、VPC内での通信を有効にするローカルルートでデフォルトで設定されています。
その下の送信先0.0.0.0/0、ターゲットigw-011834908143ba405は、全てのIPアドレスは、サブネットからインターネットゲートウェイへ通過することを意味しています。
では、プライベートサブネットの場合はどうでしょうか？
構成図の右上のプライベートサブネットを見ていきます。
送信先10.0.0.0/21、ターゲットlocalとなっていることが確認できます。この設定のみがされているということは、VPC内の通信（10.0.0.0/21）は、localに向けられている、つまり、このサブネットからの通信と外部インターネットからの通信はできない、プライベートな空間となっています。なので、プライベートサブネットなのです＾＾：
ELB
今回は、ALBを使用します。ELBは、複数のAZにトラフィックを流して負荷分散することと、ヘルスチェックする機能を持っています。
今回作成されたVPCにアタッチされていること、アベイラビリティーゾーンは1a,1cに設定されていることを確認します。下にスクロールして
ELBにアタッチされているセキュリティーグループを確認します。リンクをクリックして
タイプ、プロトコル、ポート範囲、ソースを確認します。
次にターゲットグループを確認していきます。
左メニュー「ターゲットグループ」→作成されたターゲットグループ名を選択して「Targets」タブを選択
アベイラビリティーゾーン 1aにあるインスタンスとアベイラビリティーゾーン1cにあるインスタンスのステータスが「healthy」であることを確認します。
セキュリティーグループ
セキュリティーグループは、IPアドレス単位で稼働するファイアウォールです。
パブリックサブネット内のセキュリティーグループ
まず、パブリックサブネット１（２）を見ていきます。構成図の左上の区画にあるセキュリティーグループです。
EC2インスタンス→左メニューインスタンス→該当のインスタンスを選択。
「Web-SG-1」という名前のセキュリティグループが「WebServer1」というインスタンスにアタッチされていて、そのセキュリティーグループのインバウンドルールが２つ設定されています。
２つ目の22番ポートはSSH接続用です。１つ目の80番ポートはHTTP接続ですが、ソースが何なのかここでは読み取れないので、セキュリティーグループのリンク先に飛びます。
ソースが「LB-SG-1」ということが確認できます。では、「LB-SG-1」はどんな設定になっているか確認してみましょう。
VPCサービス→左メニューセキュリティーグループ→「LB-SG-1」を選択
全てのIPアドレスを受け入れるという設定になっていますね。
プライベートサブネット内のセキュリティーグループ
今回の構成では、プライベートサブネット内にはRDSを設置していますので、RDSへアタッチされているセキュリティーグループをみていきます。
RDS→左メニュー「データベース」→該当のRDSを選択して、「接続とセキュリティ」タブを開きます。
「RDS -SG-1」というセキュリティーグループのリンクへ飛びます。
タイプ：MYSQL／Aurora ポート範囲：３３０６、ソース：Web-SG-1となっています。MYSQLのポート番号は、デフォルトで３３０６です。
「Web-SG-1」は、「LB-SG-1」からのトラフィックを受け入れを許可するという設定になっていましたね。その「LB-SG-1」は、全てのIPアドレスを受け入れるという設定となっていました。
RDSに設定されているsiteurlの確認
今回、パブリックサブネット内のインスタンスにはWordPressをインストールしていますので、MYSQLにログインして、データベースのsiteurlがELBのDNS名かどうか確認していきます。デフォルト設定でsiteurlがパブリックIPアドレスになっていた場合、インスタンスが停止or休止から再起動したときに、新しいパブリックIPアドレスが割り当てられることとなり、アクセスすることができません。今回の冗長構成では、ELBを配置していますので、ELBのDNS名をMYSQLのsiteurlに使います。構成図では、赤色の線ですね。
まず、パブリックサブネット内のインスタンスにログインします。
MACの方は、ターミナルから
ssh -i キーペア名 ec2-user@インスタンスIPアドレス
次に、MYSQLへログインします。
mysql -h RDSのエンドポイント -u ユーザー名 -p
次にテーブル名を指定します。
USE テーブル名
siteurlの確認です。
SELECT * FROM wp_options WHERE option_name IN ('siteurl', 'home');
赤線の部分がELBのDNS名になっていることが確認できれば、これで一通り終了です。
もし、ELBのDNS名ではない場合は、下記のコマンドで変更できます。
UPDATE wp_options SET option_value = 'http://DNS名' WHERE option_name IN ('siteurl', 'home');
この記事はAWS初学者を導く体系的な動画学習サービス
「CloudTech」の課題カリキュラムで作成しました。
https://kws-cloud-tech.com