タグ

vpcとNetworkに関するclavierのブックマーク (11)

  • Amazon VPC設計時に気をつけたい基本の5のこと | DevelopersIO

    EC2やECS、RDSなどといったサービス利用時にAmazon VPC(以下よりVPC)が合わせて必要になります。 VPCの設計はCIDRとテナンシーの選択のみとシンプルですが、案外迷ってしまいます。 私が設計時に気をつけている5点をまとめてみました。 RFC1918準拠のIPアドレス範囲から指定する IPアドレスの範囲はrfc1918に準拠した範囲を指定することを推奨します。 少し難しく聞こえますが、下記のIPアドレス範囲から指定するということです。 10.0.0.0 - 10.255.255.255 (10/8 プレフィックス) 172.16.0.0 - 172.31.255.255 (172.16/12 プレフィックス) 192.168.0.0 - 192.168.255.255 (192.168/16 プレフィックス) よく見るプライベートIPアドレス範囲ですね。 16ビット以上で

    Amazon VPC設計時に気をつけたい基本の5のこと | DevelopersIO
  • AWS導入前に知っておきたかった「VPC設計」 - Qiita

    1.はじめに 以前、「AWSアカウント設計」について記事を出しました。 今回は、このアカウントを作った後避けては通れない「VPC設計」について書いていきます。 VPCは設計をせずに作成することも可能ですが、 「どこのVPCにEC2を構築すれば良いのか?」とか「管理が大変!」等の壁にぶつかり、 後々後悔することがあるので、事前に設計することをおすすめします。 今回は、アカウントを複数作成することを考慮した上で 『環境ごとにアカウントを分けたパターン』 『システム・環境ごとにアカウントを分けたパターン』 の2パターンで考えていこうと思います!! 私個人的におすすめな構成ですので、参考になれば幸いです。 2.VPC設計 2-1.環境ごとにアカウントを分けたパターン このパターンのアカウントの分け方は以下の図のようになっています。 図.2.1.1.環境ごとにアカウント分割パターン そして以下の図の

    AWS導入前に知っておきたかった「VPC設計」 - Qiita
  • 俺が考える最強のネットワーク構成 〜AWS試験の9冠はVPCをこう考える〜/akiba-aws-vpc

    2018年6月7日に開催したAKIBA.AWS 第8回の資料です。

    俺が考える最強のネットワーク構成 〜AWS試験の9冠はVPCをこう考える〜/akiba-aws-vpc
  • AWSのネットワーク設計をサボらないでちゃんとやる

    新規事業の立ち上げにAWSを選択する こういう状況はままあるでしょう。最安というわけではないけれど、将来どんな開発が必要になるか全く想像できない新規事業立ち上げフェーズにおいて、多種多様なPaaSを提供してくれるAWSはとても魅力的。 さて、いざ、EC2インスタンスを立ち上げてアプリケーションをデプロイするわけだが、みなさん、ちゃんとネットワーク設計していますか?まさかデフォルトVPCでサービス運営なんてしてないですよね? というわけでネットワーク設計をして、VPCを設定していくわけだが、何を作ればよいか決まっている事業フェーズならともかく、新規事業立ち上げフェーズでは「将来どんな機能が必要になるかわからない」という前提でネットワーク設計をしておかなければいけない。そこで、「例えばこんな設計はどうでしょう」という提案をしてみる。 IPレンジ設計 まずはVPCとサブネットを使ってIPレンジを

    AWSのネットワーク設計をサボらないでちゃんとやる
  • AWSで最低限セキュアな構成を組む - Qiita

    最低限セキュアな構成とは 「最低限セキュアな構成」を次のように定義する。 Webサーバーやデータベースサーバーが直接、インターネットに公開されていない。 公開・非公開に関わらず、特定のポートのみインバウンドを受け付けている。 非公開のサブネットは特定のサブネットからのみインバウンドを受け付けている。 踏み台サーバーは必要な時のみ存在している。 この定義を満たす構成は次のようになる。 構築手順 ざっくりと以下の手順を踏む。 VPCの構築 パブリックSubnetの構築 Subnetの構築 Internet Gatewayの構築 Route tableの構築 プライベートSubnetの構築 Subnetの構築 パブリックSubnetにNATインスタンスを構築 Elastic IPのアロケートとNATインスタンスへの結び付け Route tableの構築 Auto Scaling Groupのため

    AWSで最低限セキュアな構成を組む - Qiita
  • t2.microでNATインスタンスを作る - aws memo

    2015/12/18追記 マネージドNATが出たので、わざわざNATを建てずにこちらをまず検討すると良いと思う。 Amazon Web Services ブログ: 【新機能】マネージドNATゲートウェイが利用可能に ーーー t2.microでNATインスタンスを建てようとするも、NAT用AMIは PVしかない(2014年7月11日時点)という理由で諦めてる人向けのメモ。 (NATインスタンスの建て方自体は、このページ末尾のSlideshareを参考に) 基的にやることはPVもHVMも変わらず、 ip_forward有効にしているLinuxを起動 EC2の設定で src/dst checkをdisabledにしておく routing tableを適切に設定しておく これさえキチンとしていれば、たいていのLinuxで( Vyatta等を含む)動作するので、HVMかPVかはそもそも関係ない。(

    t2.microでNATインスタンスを作る - aws memo
  • AWS Solutions Architect ブログ

    とはいえ、VPCは物理的な線があり、NICがあるいわゆる物理環境と違うのも事実です。そしてAWSがサポートしていないことがいくつかあることがわかっています。それはIPv6対応であり、Multicast対応であり、イーサネットフレームのコピーであったりします。そんなことを実現するために、トンネリングがしばしば使われます。 その方法は多数知られています。パケットをいじる以上、そのいじり方に応じてトレードオフがあり、それぞれの目的のために実装も異なります。標準化されている方法としては、IP-in-IP (rfc1853)、Generic Routing Encapsulation (rfc2784)が、よく使われています。また、ネットワークデバイスの仮想化技術として知られるTUNとTAPもよく使われています。乱暴ですが、これらをまとめると次のようになります。

  • AWS Solutions Architect ブログ

    AWSソリューションアーキテクトの安川 (@thekentiest)です。 前の荒木 (@ar1)の投稿で、トンネル技術を使えばいろんなEC2-ClassicやEC2-VPCでサポートしていないプロトコルでも利用可能であるという話がありました。その投稿でも触れられていたとおり、トンネリングを使えばIP Multicast/BroadcastもEC2インスタンス間でやりとりする(しているかのように上位レイヤのアプリケーションに思わせる)ことができるので、トンネリングを使ってIP Multicast/Broadcastを前提としたアプリケーションやミドルウェアを動かす例も多く見られます。 トンネリングは汎用的で、様々なプロトコルを動作させる目的で使える点は優れています。しかし、通信のオーバーヘッドが伴うのはもとより、特定のノード間でトンネリングをする設定をしないといけないので、その部分が煩雑で

  • [Amazon VPC]ハードウェアVPN接続のMTUとTCP MSSの最適値を探す | DevelopersIO

    さて、Management Consoleの[VPN Connections]画面から、各機器に合わせた設定ファイルをダウンロード出来ることは上記の記事でご説明しました。 この設定ファイルの内容を見てみると、ちょっと気になる部分があります。例えばGeneric Vendorだと... IPSec ESP (Encapsulating Security Payload) inserts additional headers to transmit packets. These headers require additional space, which reduces the amount of space available to transmit application data. To limit the impact of this behavior, we recommend t

    [Amazon VPC]ハードウェアVPN接続のMTUとTCP MSSの最適値を探す | DevelopersIO
  • NATインスタンス冗長化の深淵な話 - (ひ)メモ

    AWS Casual Talks#1を開催しました - まめ畑 http://d.conma.me/entry/2013/11/02/140136 に参加して『NATインスタンス冗長化の深淵な話』というLTをしてきました。 Redunduncy of NAT instance on AWS/VPC from Masaaki HIROSE これまで何度か発表をしてきましたが、私の人生で一番気が重いプレゼンとなりました。 ニッチな話題の会でオオトリを努めるとネタが被って社会は厳しいという見のようなLTでしたね。今後ともご指導ご鞭撻の程、よろしくお願いいたします。 あと、何人かの方にきかれたフォントですが、ここの怨霊フォントと吐き溜フォントです。 暗黒工房 ホラーフォント :怨霊、オバケ、吐き溜

    NATインスタンス冗長化の深淵な話 - (ひ)メモ
  • カジュアルにVPC作った結果がこれだよ!

    20200722 AWS Black Belt Online Seminar AWSアカウント シングルサインオンの設計と運用

    カジュアルにVPC作った結果がこれだよ!
  • 1