Though Shareaholic is hosted in the AWS cloud, we avoid depending on Amazon’s virtualized cloud services whenever possible. If we ever hit a bottleneck in AWS, I want to be able to switch providers without needing to rebuild a core piece of our architecture. I also don’t want our tech team to have to make product and infrastructure sacrifices just so that we conform to AWS standard practices. Load
You can choose one of the predefined security policies for your HTTPS/SSL listeners. You can use one of the ELBSecurityPolicy-TLS policies to meet compliance and security standards that require disabling certain TLS protocol versions. Alternatively, you can create a custom security policy. For more information, see Update the SSL negotiation configuration. The RSA- and DSA-based ciphers are specif
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.
cloudpackエバンジェリストの吉田真吾(@yoshidashingo)です。 Amazon ELB(Elastic Load Balancing)は、HTTP/HTTPSアプリケーションでX-Forwardedやスティッキーセッション、SSLターミナーション、HTTPヘルスチェックといったL7ロードバランシングが主軸で、場合によってTCPやUDPでのL4ロードバランシングも行うことができる、非常に便利で強力でコスト効率がよいロードバランシングサービスです。 ただ、いわゆるURLやCookieの中身やホストヘッダによるロードバランシング機能はありません。ということで、L7ロードバランス機能が豊富なCitrixのNetScalerを使ってみます。 参考資料 AWS資料:AWS環境へのNetscaler活用事例 公開元見当たりません、が、手元にある Citrix Networking fo
AWS Weekly Roundup – AWS AppSync, AWS CodePipeline, Events and More – August 21, 2023 In a few days, I will board a plane towards the south. My tour around Latin America starts. But I won’t be alone in this adventure, you can find some other News Blog authors, like Jeff or Seb, speaking at AWS Community Days and local events in Peru, Argentina, Chile, and Uruguay. If you see […] New – Amazon EC2 H
はじめに 先日お伝えしました通り、ELBのアクセスログが取得出来るようになったのですが、すぐさまfluent-plugin-elb-logというfluentプラグインがリリースされました。さすがfluentd界隈、対応が早いです。 ということで、今回はELBのアクセスログをfluentd経由でElasticsearchに取り込み、それをKibanaで表示したいと思います! セットアップ Elasticsearch Elasticsearchは最新のrpmパッケージを更新サイトから取得し、rpmコマンドでインストールします。 $ wget https://download.elasticsearch.org/elasticsearch/elasticsearch/elasticsearch-1.0.0.noarch.rpm $ sudo rpm -ivh ./elasticsearch-1.
ども、大瀧です。連投します。 今朝がたリリースされた、Route53の新機能(Amazon Route 53 on 2013-05-30)を早速試してみました! 従来のRoute53フェイルオーバー機能、設定方法については、福田さんの記事を参照ください。 Route53の新機能とは 従来、Route53ではEC2インスタンスにHealth Checkを行い、EC2が不調の場合にDNSレコードを書き換えるDNSフェイルオーバー機能がありました。以下のようなイメージです。 ただ、Health Checkのターゲットには、ELB(Elastic Load Balancing)が指定できないという、痛い制限がありました。今回のアップデートは、ELBをHealth Checkのターゲットにできるというものです。 あれ、ちょっと待ってください。Health Checkって、元々ELBがバックエンドのE
Tomcatのセッション管理 Tomcatでクラスター構成にする場合、課題となるのがセッション管理です。ロードバランサーでセッションIDを保持することで、毎回同じサーバーにリクエストが向かうのであれば問題なさそうに見えますが、あるサーバーがダウンしてしまうとセッション情報が消えてしまいます。これを解決する方法として、データベースにセッション情報を保持する方法が一般的ですが、データベースへ負荷が掛かりますし、データベースが落ちたら困ります。何かもっと良い方法は無いかと皆さん思っていたはずです。そこで、AWSですよねー。AWSでは、ElastiCacheやDynamoDBがサービスとして提供されています。ここで、永続化をしっかりやってくれるのはDynamoDBであり、AWS SDK for Javaでの登場が待たれていたわけです。そして、このたび出てきました! スティッキーセッション ロードバ
sudo yum install npm --enablerepo=epel npm install express cat <<EOT >index.js var app = require('express')(); app.get('/*', function(req, res) { if (req.query.wait) { setTimeout(function() { res.write('OK'); res.end(); }, req.query.wait); } else { res.write('OK'); res.end(); } console.log('%s %s %s', new Date(), req.method, req.url); }); app.listen(10080); EOT node index.js $ ab -n 5000 -c 200 ht
ELBが報告するHTTPエラーコード ELBでは様々なエラーコードが発生します。それらはCloudWatchで発生回数を確認することができるのですが、同じようなエラーコードがあり少し紛らわしです。 どのHTTPエラーコードをロードバランサーは返すのか? ロードバランサーは400、405、408、502、503のエラーレスポンスと、登録されているインスタンスが返すあらゆるエラーレスポンスを返します。 CloudWatchで確認可能なHTTPエラーコード ロードバランサーはクライアントに送信されるHTTPレスポンスコードをAmazon CloudWatchにメトリクスとして保存しています。これを用いると、エラーのソースがロードバランサーなのか、バックエンドのインスタンスなのかを確認することができます。CloudWathcの利用に関する情報と利用可能なメトリクスの定義に関しては、Monitor
指定されたAvailabilityZoneでのロードバランサーに登録されたhelthyなEC2インスタンスの数。 unhealthyな閾値を超えてヘルスチェックに失敗していないホストはhealthyだとみなされる。 このmetricを評価する場合、dimensionはLoadBalancerNameとAvailabilityZoneで規定されるはずである。 このmetricは指定されたAvailability Zoneでのhealthyなインスタンスの数を表している。 200でない応答(HTTPやHTTPSでのヘルスチェックの場合)が返ったり、ヘルスチェックを行っている場合にタイムアウトするような接続の問題でインスタンスはunhealthyになることがある。 全てのhealthyなホスト数の合計を得るために、このmetricは各登録されたAvailabilityZoneを取得し、全てのme
こんにちは@oko_changです。 今回は先日対応されたELBのCross-Zone Load Balancingについて書いてみたいと思います。 Elastic Load Balancing Announces Cross-Zone Load Balancing 上記リンクには、今までのELBは各AZのEC2インスタンスへの分散はDNSに依存する部分があり、DNSのキャッシュ次第では各AZへのトラフィック分散が偏ってしまう可能性があったと書かれています。 しかしこのCross-Zone Load Balancingを有効にする事で、DNSのキャッシュを気にすることなく各AZのEC2インスタンスに同じようにトラフィックが分散されるようです。 ※英語なので間違ってたらごめんなさい>< 今回の検証構成 以下のようにシンプルな構成です。 Cross-Zone Load Balancingを有効
AWS News Blog AWS Management Console – Auto Scaling Support Amazon EC2’s Auto Scaling feature gives you the power to build systems that adapt to a workload that varies over time. You can scale out to meet peak demand, and then scale in later to minimize costs. Today we are adding Auto Scaling support to the AWS Management Console. You can now create launch configurations and Auto Scaling groups wi
AWS が Auto Scaling、CloudWatch、Elastic Load Balancing を発表した時は興奮して、すぐに触ってブログに書きました。 Amazon EC2 新機能 Monitoring, Auto Scaling and Elastic Load Balancing を一通り触ってみた Amazon EC2 Auto Scaling をもう少し詳しく見てみた その情報を元にして 「よくわかるAmazonEC2/S3入門」を執筆した のだけど、4年前の情報なのでもう古くオートスケーリングの設定方法も変わったようだったのでしっかり追いつきたいと思って再び触ってみた。 結論的には以前と同じように思った通りの挙動が確認できた。AWS のドキュメントも充実していて理解をだいぶ助けたが、ちょいちょい間違っている点があったり、基本的にパラメータが多くて説明が少ないので、ユー
よく訓練されたアップル信者、都元です。ELBはAWSにおけるWebシステムを構築する場合、ほぼ確実に利用するコンポーネントとして不動の地位を確立しつつあります。 利用方法としては、ELBを作成して配下にWebサーバを配置するだけというお手軽さがあり、非常に利用しやすいのも大きなメリットです。しかし、ELBの詳細な挙動について、しっかり理解できているでしょうか。本エントリではいつも利用しているELBについて、ちょっと深く突っ込んでみました。 ELBのロードバランシング戦略 ELBの配下には複数のAZにまたがるようにインスタンスを配置するのが一般的です。(cf. AWSにおける可用性の考え方) ELBを作成すると、DNS名が付与されますが、クライアントがELBにアクセスする際、まずこのホスト名をIPアドレスに変換するDNSの正引きリクエスト(下図中の緑色の矢印)を行います。digコマンドを使っ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く