Shoeisha Technology Media

CodeZine(コードジン)

記事種別から探す

AWSネットワークにおけるベストプラクティス ~ AWSのバックボーンネットワークに関するDeepな話(3)

AWSの深いところ見せちゃいます! by AWSクラウドサポートエンジニア 第3回

  • LINEで送る
  • このエントリーをはてなブックマークに追加

 こんにちは。アマゾンウェブサービス(AWS)サポートの有賀と申します。好きなサービスはAmazon Virtual Private Cloud(VPC)です。これからAWSサポートの各メンバーがそれぞれ「今一番AWSユーザーに伝えたいこと」を連載の形でお届けしていきます。筆者の担当する本稿では、AWSの「ネットワーク」について見ていきます。今回は、AWSのネットワークにおけるベストプラクティスや、過去に発生した問題をご紹介します。

目次

 本稿でお伝えするのは下記の第3回の内容です。全3回に渡って解説していきます。

  • AWSのネットワークの物理的な側面 ⇒ 第1回
  • AWSのネットワークの論理的な側面 ⇒ 第2回
  • AWSのネットワークにおけるベストプラクティス ⇒ 第3回
  • AWSのネットワークにおいて過去に発生した問題の事例 ⇒ 第3回

 必ずしもAWSの使い方といった内容ではないので、今日すぐに使える知識にはならないかもしれませんが、AWSのネットワークがどのようにできているかをご理解いただくことで、AWSをより効果的・効率的に使っていただく際の参考にしていただけると思います。

AWSのネットワークにおけるベストプラクティス(1)

 初めに、お客さまにAWSをお使いいただいている中で、しばしば発生する誤解や問題を避けるためのベストプラクティスをご紹介します。主なお題は次の通りです。

  • セキュリティグループとネットワークACL
  • VPCの制限
  • EC2インスタンスの監視
  • 複数ENIの利用

 なお、英語のドキュメントではありますが、AWSを使う場合のネットワークに関するより包括的なベストプラクティスもまとまっていますのでご紹介しておきます(例えば「VPCのCIDRのサイズは/16にして、各サブネットは/24で使うのが一般的だ」などです)。

セキュリティグループとネットワークACL

 Amazon VPCにおけるパケットフィルタリングには「VPC のセキュリティ」にある通り、「セキュリティグループ」と「ネットワークACL(アクセスコントロールリスト)」の2つがあります。

 上記ドキュメントには「VPCインスタンスはセキュリティグループでのみ保護できます。ただし、第2保護レイヤーとしてネットワークACLを追加することができます。」と書かれていますがイマイチ分かりにくいです。

 この違いを簡単に説明すると、「セキュリティグループ」はEC2インスタンス(の外)で実行されるホスト単位のファイアウォールのようなものであり、「ネットワークACL」は先に出てきた概念的な「VPCルーター」(各サブネットのデフォルトゲートウェイです)の各サブネットにつながるインターフェースに設定されるファイアウォール(ACL)のようなもの、となります。

セキュリティグループ

Security Group
Security Group

 セキュリティグループが通常のホスト単位のファイアウォールと少し違うところは、インバウンドの場合に送信先、アウトバウンドの場合に送信元、がそれぞれ設定できないところです。たとえばLinuxにおけるiptablesでは当然どちらも設定できますが、EC2インスタンスの場合は当該インスタンスが送信先/送信元であることが自明であるため設定できません(ただし、NATインスタンスのようにルーター相当の機能をEC2インスタンスが提供する場合は自明ではなくなりますが、そのような例は例外です)。

 一方、ホスト単位のファイアウォールと同じなところは、デフォルト拒否(許可するものだけ列挙する)とか、ステートフルであるといったところになります。

ネットワークACL

Network ACL
Network ACL

 ルーターのACLを設定したことがある方には、ネットワークACLは分かりやすいかと思います。たとえば、セキュリティグループとは異なり、ステートフルではなかったり、ルールの順番を設定できたり、といったところはルーターのACLと似ています。一方、ネットワークACLではセキュリティグループと同じく、自明である送信先、送信元は設定できません。

 なお、「VPCルーター」のインターフェースに設定されるファイアウォールみたいなものと、と言いましたが、それ故に同じサブネット内のインスタンス間の通信にはネットワークACLは影響がありません。あくまでVPCルーターを経由するような通信だけが対象となります。

セキュリティグループとネットワークACLの使い分け

 ここはある程度筆者の私見になってきますが、ネットワークACLではある程度緩く制限をして、セキュリティグループでより厳しく制限すると管理し易いかと思います。

 ネットワークACLの推奨ルール例は「VPCに推奨されるネットワークACLルール」というドキュメントで紹介されています。

 通常のファイアウォールのルールと同じように、必要なポートだけ空けてそれ以外は閉じる、という基本的な方針ですが、セキュリティグループとは違いステートフルではないので戻りのパケットの考慮が必要など、結構面倒です(特に「一時ポート」までちゃんと考慮し始めると大変です)。

 ですので、当該セグメントのインスタンスすべてに共通する通信だけを大きくネットワークACLで許可し、各インスタンスへのアクセスはセキュリティグループで細かく制限する、という方法によって、比較的安全で楽に運用できるかと思います。

 なお、上で「共通する通信」と書きましたが、そのためには当該サブネットに存在するインスタンスのサービスはなるべく揃っていた方がルールを書きやすいため、そういったところも考慮しつつ、VPC内のネットワーク設計をするとよいでしょう。


  • LINEで送る
  • このエントリーをはてなブックマークに追加

著者プロフィール

  • 有賀 征爾(アマゾン ウェブ サービス ジャパン株式会社)(アリガ セイジ)

     AWSクラウドサポートエンジニア。大学院にてインターネット分野の研究をした後、大手通信キャリアにて国際インターネットバックボーンの設計・構築・運用に携わる。その後、国内インターネットバックボーンの設計にも携わり、IPv6、セキュリティサービス等の開発などを担当する。2015年春にクラウドサポートエ...

バックナンバー

連載:AWSの深いところ見せちゃいます! by AWSクラウドサポートエンジニア
All contents copyright © 2005-2017 Shoeisha Co., Ltd. All rights reserved. ver.1.5