【AWS】VPC環境構築ノウハウ社内資料 2014年4月版 | DevelopersIO
よく訓練されたApple信者、都元です。 以前、【AWS】VPC環境の作成ノウハウをまとめた社内向け資料を公開してみるという記事を書きましたが、そこから半年経ち、状況も変わって来ましたのでアップデートを行いたいと思います。 以前のエントリーを読んだ方は、忙しい場合は下記の「2013年10月版からのアップデート」だけを読むといいかもしません。 VPCを利用する理由 AWSは、あらゆる規模のプロジェクトに対応するインフラを提供しています。前述のサーバ数千台規模のプロジェクトしかり、1台構成しかり。大規模プロジェクトであれば当然、オンプレミスと同様にネットワークインフラについての設計を綿密に行う必要がありますが、では、中小規模のプロジェクトにおいてはネットワークの設計をする必要はないのでしょうか。 AWSでは、VPCという「ネットワーク環境」を構築するサービスを提供しています。しかもVPCの利用
Amazon VPC Peeringの技術的考察と留意点 | DevelopersIO
大事なことなのでもう1回言います。今回のVPC Peeringは、2つのVPC間のL3ネットワーク通信を提供します。 ...言わんとするところ、伝わったでしょうか。伝わりにくいですかね?(笑)説明としては上の文章でいいのですが、思い浮かぶイメージと実現できることにはそれなりに隔たりがあるので、そこを理解いただきたいというのが今回のエントリーの狙いです。VPC Peeringの仕組みを自分なりに考察(≒妄想)し、そこから見えてくる留意点を紹介してみます。以下に要点をまとめます。 ルーティングの設計はユーザーが行う。 Peeringなので、2VPC間以外のルーティングを取り持つことはできない。 Peering経由でIGW/VGWは利用できない。 ルーティングの設計はユーザーが行う Peeringの設定は、VPCの[Peering Connections]画面で、作成・管理します。ただ、このPe
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
はじめてのAmazon VPC - 2. 外部インターネットと接続する(NATインスタンスを使う) - 元RX-7乗りの適当な日々
前回のエントリ「はじめてのAmazon VPC - 1. ルーターからVPCへVPN接続する」の続きです。(今更シリーズ) Amazon VPCでは、各サブネットでのアクセスコントロールを柔軟に設定できたり、自ネットワークからVPNトンネルをはって接続できるなど、よりセキュアなネットワーク構成を意識できることもあり、VPC内で起動したサーバ(Amazon EC2インスタンス)は、場合によっては外部インターネットに出て行くことが出来ないケースがあります。 しかし、サーバから外部の必要なものをダウンロードしたり、外部リポジトリや外部APIアクセスしたい場合、Amazon S3等のVPC外のAWS各サービスに接続したい場合(パブリックネットワークからしかアクセスできない)などもあるでしょう。 もちろん、そこはVPCでの設定次第となりますので、今回は、前回作成したAmazon VPC網内で起動した
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
