CDP:High Availability NATパターン - AWS-CloudDesignPattern
解決したい課題 システム構成をセキュアにするため、インターネットに公開する必要がないサーバーは、インターネットとの直接的な通信ができないネットワークセグメント（プライベートサブネット）に配置する構成にする場合が多い。 この場合、プライベートサブネットから外部へのアウトバウンド通信はNATサーバーやプロキシーサーバーを経由するが、このサーバーに障害が発生すると、プライベートサブネットのサーバーからアウトバウンド通信が行えなくなり、システム全体の障害につながる。このため、単一障害点（SPOF）にならないように、冗長化が必須である。 クラウドでの解決/パターンの説明 NATサーバー/プロキシーサーバーの冗長化を行う。障害発生時の迅速なフェイルオーバーと、より高い冗長性の確保のため、複数のデータセンターに複数のNATサーバー/プロキシーサーバーを配置し、単一障害点とならないようにする。 また、障害
Vyattaを使ってAmazon VPC内に独自NAT環境を作る
このブログでクラウド関連の話題というと、ほとんどRackspace Cloudばかりなのですが… 今回のエントリは珍しくAWSをテーマにしてみたいと思います。 Twitterを見ているとVyattaが最近アツく、個人的にも書籍を購入したのでAmazon VPCと連携させたいです。 AWSではVPCネットワークから外部へ接続するためのNATアドレッシングインスタンスが提供されておりますが、こちらをVyattaに置き換えて使ってみるという事です。 今回はNATを構成するだけですが、Vyattaは機能が豊富で様々な可能性をVPCに付け加える事が出来そうです。 ちなみに先日Vyatta社からアナウンスされた6.3のAMIはSubscription Editionということなので、今回はVyatta Core6.1のAMIを使用しています。 [ネットワーク構成] [VPCの設定] VPC内にはVya
NATインスタンスを冗長構成にしてみた - log4moto
Wizardによる標準構成のVPCにおいてNATインスタンスはSPOFであり、インスタンス障害や、単一AZの障害、AZ間接続障害によっても両AZのインターネット接続性が損なわれる可能性がある。そこで、NATインスタンスをAZ毎に用意し、障害発生時にfailoverする仕組みを考えてみた。 方針 なるべくAWSの１リージョン内で完結し、別リージョンや外部に監視用ホストなどをおかない 瞬間的にフェイルオーバーはおこなわず、毎分ごとにインターネット上のターゲットIPへの疎通を確認し、障害と思われる状態になったらフェイルオーバーを行う 疎通が回復したと思われた場合には、元の状態に戻す 構成 非常にわかりづらい図になっていますが、構成要素としては Subnet x 4 (Public, Private を AZ毎に１つずつ) NATインスタンス x 2 (AZ毎に１つずつ、当然ElasticIPも1
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Amazon AWS VPC IPTables and NAT route port
