(レポート) NET301: VPCに最近追加された機能について #reinvent

2015.10.10

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

セッションの内容

  • VPCエンドポイント
  • VPC Flow Logs

VPCエンドポイント

解決したい課題

  • AWSの抽象化されたサービス、例えばS3やDynamoDBはパブリックなエンドポイントしか持っていない
  • VPC内からそれらのサービスへの最適なアクセス方法を知りたい

これまでのアクセス方法の比較

|| パブリックIPを付与してIGW経由 | NAT経由 | プロキシ経由 | |:--|:-----------|:------------|:------------| |利点| 高可用性 スケーラブル ポートやCIDRによる制限 |一元的なアクセス制御 全プロトコル対応| 一元的なアクセス制御 スケーラブル セキュリティオプションが多い | |欠点|パブリックIPを持つことによるセキュリティリスク アクセス先のリソースを絞れない| 可用性が低い スケールしない 管理が大変 NAT自体はパブリックなのでセキュリティの問題 |可用性が低い スケールしない 管理が大変 HTTP/HTTPSしか使えない|

VPCエンドポイントによる解決

スクリーンショット 2015-10-09 11.10.57

  • パブリックIPやNAT、プロキシは不要
  • 高可用性
  • スケーラブル
  • セキュリティ制御

セキュリティ制御

  • ルートテーブルにエンドポイントを追加することでアクセスを許可する
  • セキュリティグループによるアウトバウンド制御が可能
  • VPCエンドポイントポリシー スクリーンショット 2015-10-09 11.21.45
  • S3バケットポリシー スクリーンショット 2015-10-09 11.21.57
  • 各ポリシーはAND条件で適用される

速度比較

下記構成でIGW経由、NAT経由、VPCエンドポイント経由のアップロード/ダウンロード速度を比較した。 スクリーンショット 2015-10-09 11.25.32

多重度1の場合

スクリーンショット 2015-10-09 11.29.59 NATよりVPCエンドポイント経由の方が早い

多重度10の場合

スクリーンショット 2015-10-09 11.30.59 VPCエンドポイント経由の方が圧倒的に早い NATの場合、NATサーバがボトルネックになり一定以上は速度が出ない

VPC Flow Logs

VPC内のすべての通信を見ることができる スクリーンショット 2015-10-09 11.33.50

  • 設定が通信をブロックされた原因(セキュリティグループやNACL)
  • トラフィックの分析
  • CloudWatch Logsで確認できる
  • なのでCloudWatch Logsの連携機能(Kinesis等)が使える
  • レコードはENI単位

ログのフォーマットと例

フォーマット スクリーンショット 2015-10-09 11.40.00

スクリーンショット 2015-10-09 11.40.09

活用例

不正なSSHアクセスを検知

SSHアクセス拒否の場合はこのようなレコードが記録されるので、 スクリーンショット 2015-10-09 11.46.56

CloudWatch Logsのフィルターを作り スクリーンショット 2015-10-09 11.47.28

閾値を超えたらアラートが送信されるように設定する。 スクリーンショット 2015-10-09 11.47.48

このようなメールが届く。 スクリーンショット 2015-10-09 11.48.01

感想

VPCエンドポイントによりNATを介さずにAWSサービスにアクセスできるのは嬉しいですね。 今のところS3しかありませんが、今後他のサービスでも増えることを期待しましょう。

VPC Flow Logsは応用範囲が広いように思いました。 CloudWatch LogsからKinesisに流せるので、今回発表されたKinesis Analyticsを使った集計もできそうです。