AWS News Blog
Stop the CNAME chain struggle: Simplified management with Route 53 Resolver DNS Firewall Starting today, you can configure your DNS Firewall to automatically trust all domains in a resolution chain (such as aCNAME, DNAME, or Alias chain). Let’s walk through this in nontechnical terms for those unfamiliar with DNS. Why use DNS Firewall? DNS Firewall provides protection for outbound DNS requests fro
CloudFront + nginx(http_image_filter_module) + S3 を使って画像変換サーバを構築する - 本日も乙
珍しく(初めて?)AWSネタです。 仕事でAWSのVPCを構築しているのですが、画像を取り扱うサーバが欲しいとの要望がありました。 画像を表示するだけならCloudFront+S3だけで強力な画像(CDN)サーバを構築することができるのですが、今回は画像サイズもリアルタイムで変換して表示してほしいとのことでした。 幸いにも社内で以前、nginxのhttp_image_filter_moduleを使って画像変換している実例(実サーバ)があるのでそれを参考に構築してみました。 構成図 簡単な図です。 今回やりたかったこと ユーザが独自ドメインとマッピングされたCloudFrontにアクセスすると、CloudFrontに画像がキャッシュされていればその画像を返します もし画像がキャッシュされていなければELB・EC2インスタンス経由でS3にある画像を取得します EC2インスタンスにhttp_im
リアルタイム通信環境の(一部)構成紹介 : DSAS開発者の部屋
こんにちは。 今回は、当社で稼働させているリアルタイム通信環境について、ご紹介させて頂きます。 ご紹介する環境に対する要件は、以下となります。 ・ゲーム内の期間限定イベントで使用し、イベント開催中のみサーバを稼働 ・リアルタイム通信。プロトコルは、websocket を使用 ・同じチームに所属するユーザを同じサーバへ接続 ・とりあえずいっぱいスケールできるように(笑 最後の要件は冗談で、実際にはちゃんとした数値を頂いているのですが、このような環境構築を依頼されましたので、AWS 上で以下にあるような構成を考えてみました。 構成図 ※ 主要なサーバのみを抜粋 ELB 外部のクライアントから、websocket な接続を受け付けます。 http(s) モードでは、websocket の通信確立に必要なヘッダが消去されてしまうため、tcp モードを使用しています。 tcp モードを有効にすると、
AWS ELBの社内向け構成ガイドを公開してみる 負荷分散編 – Cross-Zone Routingを踏まえて ｜ DevelopersIO
ども、大瀧です。 最近、お客さまからの問い合わせからElastic Load Balancing(ELB)の負荷分散について調べ社内資料としてまとめる機会がありました。せっかくなので、ブログ記事として公開してみます。内容は随時アップデートしますので、ツッコミ・ご指摘があればぜひお願いします！ 負荷分散の仕組み ELBは、クライアントのリクエストを受け付けEC2インスタンスにトラフィックを転送するために、2種類の負荷分散を組み合わせて動作します。 スケーラビリティと冗長性のために、ELBはロードバランサの機能を提供するノードを複数動作させるはたらきがあり、クライアントから複数のノードへアクセスを分散させるためにDNSラウンドロビン、ノードからEC2インスタンスへのトラフィック転送を分散させるためにLeast Connsという手法を用いています。 DNSラウンドロビン DNSラウンドロビンはそ
cloudpackブログ - (ELBとからめて)Hostヘッダでの振り分けをHAProxyでやってみる
本記事の構成はELBのIPアドレスが変更になった場合に問題が発生する可能性があるので 対策しておく必要があります。 HAProxyをDNS名で指定したバックエンドのIPアドレスが変わったらリロードするの記事が 参考になるかもしれません。 直接ではありませんが、Cloud Design Pattern（CDP）の「Multi Load Balancerパターン」に関する記事です。 このパターンの「利点」に下記のような複数SSL(HTTPS)に関する記載がありますが、ワイルドカード証明書を 利用する場合は、一つのELBで複数のSSL(HTTPS)サイトをまとめることも可能です。 同一のEC2で複数のSSL（HTTPS）を利用する場合も、SSL（HTTPS）ごとに ELBを用意することで可能となる。 図にすると下記のようになります。 上図は下記のようにDNS名ごとに別々のEC2に振り分けるところ
suz-lab.com - suz lab リソースおよび情報
This webpage was generated by the domain owner using Sedo Domain Parking. Disclaimer: Sedo maintains no relationship with third party advertisers. Reference to any specific service or trade mark is not controlled by Sedo nor does it constitute or imply its association, endorsement or recommendation.
Amazon Elastic Load Balancing (ELB)の内部構造および拡張・障害時の動き - プログラマでありたい
諸般の理由により、AWSの各サービスの挙動を改めて復習中です。まずは、Amazon Elastic Load Balancing 、通称ELBについてです。ELBの内部の動作については、公開されている公式ドキュメントが割とあります。是非一度しっかりと目を通しておくとよいですよ。少なくともAWSマイスターシリーズのELBについては、読んでおくべきです。簡潔にかつ詳しく説明されているので、理解が格段に進むでしょう。というところで、現段階で私が理解しているELBのアーキテクチャをまとめてみました。 ELBの内部構造 ELBは、ELBエンドポイントとELBインスタンス（仮称）によって構成されます。ELBインスタンス（仮称）の正式名称は知らないので、その名前で呼ぶことにします。ELBインスタンスには、グローバルIPが付与されます。ELBエンドポイントは、myLB-xxx.elb.amazonaws.
ELB で AutoScaling を試す〜 awscli を使って〜 - ようへいの日々精進XP
はじめに ELB で配下のインスタンスを AutoScaling を使って立ち上げたり、落としたりする とりあえず試した際のコマンドをメモ 詳細は適宜アップデートしていく 参考 autoscaling AWSのVPCでAuto Scalingを試した記録 ELB & CloudWatch & AutoScaling - AWSマイスターシリーズ Auto Scalingの薄い資料 Aws st 20130617-auto_scaling Load Balancing with Auto Scaling Dynamic Scaling 構成図 こちらを参考に以下のような構成で試してみた。 キーワード こちらの資料の 47 ページ目が個人的には解りやすかった。 Launch Configuration 起動するインスタンスのパラメータを指定する AMI やインスタンスタイプ等を指定 インスタン
今更 VPC で 複数の AZ をまたいだ ELB を試す（1） - ようへいの日々精進XP
はじめに 今更 AWS の ELB の概要についてメモ まずはマネージメントコンソールから VPC を作って VPC 内のインスタンスに対して ELB でトラフィックを割り振ってみる 尚、構成は可用性を考慮して複数の AZ にインスタンスを設置する 出来ればその ELB を aws cli を使って構築する記事はこちら... ELB とは AWS において EC2 へのアプリケーショントラフィックをロードバランスするサービス 複数の AZ にまたいでトラフィックをバラシングすることが出来る 構成された EC2 インスタンスに障害を検知した場合には自動的に正常なインスタンスにトラフィックを割り振ることが出来る ぱっと見は普通のロードバランスだけど、AWS ならではなのはマルチ AZ に対応していたり、他の AWS と合わせることで高い可用性を持った環境を構築することが出来る。（と思う） 参考
AWS ELBを使う際に注意すべきこと | Basicinc Enjoy Hacking!
AmazonWebServiceのELBは、とても簡単にサーバ分散化できる素晴らしいサービスなんだけど、ちょっとしたことに注意しないと、とんでもない目に遭う。というか、マニュアルとかにちゃんと書かれているから、読めよって話なんだけど。 AZ毎のEC2インスタンスは同じにする！ 初めてELBを運用していた当初、どうもEC2インスタンスによってアクセスに偏りがあるな…と思ってたら、ELBはまず登録されているAZの数でトラフィックを分けて、その中から各EC2に振り分ける挙動だった。つまり、AZ_AにEC2が1個／AZ_BにEC2が10個あると、総トラフィックの約50%をAZ_AのEC2インスタンス1個が引き受けるという地獄に…。 マニュアルにも書かれています…。 着信トラフィックはロードバランサーで有効になっているすべてのアベイラビリティゾーン間で均等に負荷分散されるので、各ゾーンのインスタンス
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
