Amazon AthenaでELBのログを調査するときに使ったSQL | DevelopersIO
はじめに 今まではログの調査の際にはS3にあるELBのログをローカルに落としてgrepしたりしてましが、 Athenaを使ってログを解析してみましたので今回は調査のときに使ったSQLをご紹介します。 ご紹介するSQLを使えばあとは少し変えるだけでいろいろな調査が可能かと思います。 Athenaデータベース、テーブルの準備 Athenaを使用する際の手順は以下ブログを参考にしてください。 Amazon AthenaでELBログをSQLで解析する #reinvent 調査に使用したSQL ELB毎のリクエスト数を調べる SELECT elb_name, count(*) AS request_count FROM elb_logs GROUP BY elb_name ORDER BY request_count DESC; 特定の時間内でのリクエスト数を調べる SELECT elb_name,
CLB/ALB の障害調査依頼を受けた時に確認していること | DevelopersIO
記事を書こうと思ったきっかけ サポートへの問い合わせが EC2 に次いで多いのが "CLB/ALB の障害調査依頼" だから CLB/ALB の障害調査依頼では「アクセスが遅延していた」もしくは「50X エラーが発生していた」ので調査して欲しい旨のお問い合わせをいただくことが多いです。特徴としては、それが CLB/ALB の問題なのか EC2 などバックエンドの問題なのかが切り分けされていない場合が多くみられます。どちらが原因か両方を追う必要があるため確認する項目は多いですが、CLB/ALB 側のいくつかの CloudWatch メトリクスを確認することで CLB/ALB かバックエンドの問題かの切り分けは概ね可能だと思います。 もちろん CLB/ALB はマネージドサービスであるため最終的には AWS への確認が必要になる場合もありますが、自分である程度原因を切り分けてから問い合わせを行
Classic Load Balancer の移行 - Elastic Load Balancing
翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 Classic Load Balancer の移行 Elastic Load Balancing は、Application Load Balancer、Network Load Balancer、Gateway Load Balancer、Classic Load Balancer などのロードバランサーをサポートします。各ロードバランサータイプの機能の違いの詳細については、Elastic Load Balancing 製品の比較を参照してください。 VPC 内の既存の Classic Load Balancer をApplication Load Balancer またはNetwork Load Balancer に移行することもできます。 Classic Lo
[ELB] マイグレーションウィザードでCLBをALBに移行して設定差分を確認する | DevelopersIO
こんにちは、菊池です。 先月のアップデートにて、CLBから、ALBまたはNLBへワンステップで移行可能な、マネージメントコンソールの移行ウィザードが公開されました。 New One-step Migration Wizard to Migrate a Classic Load Balancer CLB を ALB、NLB に簡単に移行可能なウィザードが追加されました 従来のELB（Elastic Load Balancing v1）であるClassic Load Balancer（CLB）を、新しいELB（Elastic Load Balancing v2）であるALB（Application Load Balancer）またはNLB（Network Load Balancer）に簡単に移行することができます。 今回はHTTP/HTTPSリスナーをもつCLBを、ALBに移行して、元のCLB
![[ELB] マイグレーションウィザードでCLBをALBに移行して設定差分を確認する | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/b87e732c82c8791fc86eac4689996b0481f8d3db/height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2015%2F02%2Felb.png)
ELBのアクセスログを可視化し、超絶手軽に分析する[QuickSight,Athena] | DevelopersIO
コンニチは、千葉です。 QuickSightとAthenaを使って、色々な視点からELBのログを分析してみました。 SQLをガンガンかける人は、Athenaのみで完結する場合もあるかもしれませんが、グラフで直感的に見るメリットもあると思います。 準備 手順サマリです。以下でやっていきます。 AthenaにてELBログテーブルを作成する QuickSightにて、データセットを作成する QuickSightにて分析する AthenaにてELBログ用のテーブルを作成する Amazon AthenaでELBログをSQLで解析する #reinvent こちらのエントリを参考に、Athenaにテーブルを作成します。 QuickSightにて、データセットを作成する マネージメントコンソールからQuickSightへ移動し、[New Analyze]から[New DataSet]で新しいデータセットを
![ELBのアクセスログを可視化し、超絶手軽に分析する[QuickSight,Athena] | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/2fa55da21da59730bd35238aa38fac0331bb63ac/height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2016%2F06%2Fquicksight.png)
Amazon AthenaでELBログをSQLで解析する #reinvent | DevelopersIO
西澤です。目新しさの無いエントリーですが、溜め込んだELBログを解析する必要があったので試してみることにしました。Amazon Athenaは東京リージョンでは使えないので、OregonリージョンのAthenaから、東京リージョンのS3バケットをデータソースとして検証しました。 と言ってもほぼ下記ページにやり方は詳しく載っていますので、公式ページを見ていただく形でも構いません。 Analyzing Data in S3 using Amazon Athena | AWS Big Data Blog Athenaでデータベースを作成する データベースエンジニアで無い担当者からすると、専用のSQLクライアントを用意すること無く、AWS Management Console上で全ての操作が完結するというのは大変嬉しいです。GUIで操作することもできますが、テーブルを作成するデータベースを先に別に
CloudFront-ELB-EC2構成でApacheのディレクトリ名補完リダイレクト時の問題をAWS側で可能な限り対応してみた | DevelopersIO
CloudFront-ELB-EC2構成でApacheのディレクトリ名補完リダイレクト時の問題をAWS側で可能な限り対応してみた CloudFront-ELB-EC2な構成でEC2上のApacheがディレクトリ名のスラッシュを補完するためのリダイレクトレスポンスを返す際に、リダイレクト先ドメインが変わってしまう、リダイレクト先のプロトコルが変わってしまう、という問題に遭遇しました。CloudFrontのHostヘッダ転送、HTTPSリダイレクト機能を用いてAWS側のみで対応する方法を検討してみました。 はじめに 清水です。先日以下のようなCloudFront-ELB-EC2な構成で、EC2上のApacheがディレクトリ名のスラッシュを補完するためのリダイレクトレスポンスを返したときに発生する問題と出くわしました。解決策をできる限りAWS側で対応する方法を検討してみたのでまとめてみます。 A
Nginxを利用してCloudFront対応のWordPressを環境を最適化してみた | DevelopersIO
はじめに AWSチームのすずきです。 先日紹介させて頂いた、CloudFront、ELB、EC2を利用したWordPress環境。 ELBやEC2のパブリックIPアドレスを知り得た第三者により WordPressの実行環境が直接攻撃される事があった場合、DDoSなどの被害を受けやすいリスクがありました。 今回、この対策としてNginxをリバースプロキシとして導入し、 CloudFrontを経由と、正しい認証情報を持つ管理者のリクエストのみWordPress環境に中継、 他の不正なアクセスは遮断する方法を紹介させていただきます。 構成図 環境 OSは、Amazon Linux2のAMI (amzn2-ami-hvm-2.0.20190508-x86_64-gp2) を利用しました。 CloudFront、ELB、EC2の各リソースは、以下の環境を一部変更して利用します。 CloudFront
ELB(https) + nginx でヘルスチェックがこける問題 - Qiita
SSL が必要な簡単なページを稼働させる際に、ELB の無料の SSL 証明書を利用した時にハマったお話 構成 簡単な図です。 ec2 の前段に ELB HTTPS(SSL) は ELB が対応 ec2 へのアクセスは http http -> https へのリダイレクトは nginx 側で対応 ec2 は一台のみ 問題が起きた設定 http://qiita.com/snoguchi/items/f5ccb67592f87942480d はじめに、こちらの記事を参考に以下のように設定しました。 server { listen 80 default_server; listen [::]:80 default_server; server_name example.com; # 利用するドメインを設定 # アクセスが http なら https としてリダイレクト if ($http_x_
[新機能] AWS Elastic Load Balancing(ELB)のタイムアウト値を変更する | DevelopersIO
ども、大瀧です。 本日、AWSで使用できるロードバランササービス、ELBでタイムアウト値変更のオプションが追加されました。これまでは、AWSサポートに個別に連絡しAWS側で変更するという手続きでしたが、ユーザー側で自由に設定できるようになりました!!また、上限も以前は17分でしたが、今回のアップデートでなんと最大60分まで設定できます。 ELBのタイムアウト値とは ELBは、ロードバランサのサービスとして一般に言うリバースプロキシの機能を持ちます。処理の流れを以下に示します。 ELBはクライアントからのリクエストを受信し、EC2インスタンスに転送する EC2インスタンスはELBが転送したリクエストに対応する処理を実行する EC2インスタンスはレスポンスとしてELBに処理の結果を返送する ELBはEC2インスタンスのレスポンスをクライアントに転送する 今回のタイムアウト値は、上記手順の2と3
![[新機能] AWS Elastic Load Balancing(ELB)のタイムアウト値を変更する | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/495673edbefe7b7bc5e6e9e54b2565989b893342/height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2013%2F09%2Faws1.png)
AWS CLI を使って ELB のセキュリティポリシーを最新に更新する | DevelopersIO
aws-cli好きの菅野です。 今回のお話は、ELBで「HTTPS/SSLリスナー」を利用している方が対象となります。 「HTTPS/SSLリスナー」を利用する場合、SSLプロトコルや暗号化方式をパッケージ化した「事前定義されたセキュリティポリシー」を利用されていると思いますが、皆さんの中にはELBを作成した時に設定したままになっている方がいらっしゃるのではないでしょうか？ 今回はaws-cliを使ってELBのセキュリティポリシーを更新しましょうというお話です。 なぜ更新が必要なのか SSLさえ使っていれば安心〜と思っている方がもしいらっしゃったらお気をつけください。 SSLに使われている暗号化方式も誰かが日々解読を試みていて、解読された場合は通信内容が盗み見できてしまいます。 AWSはこういった脆弱性に対し、解読された暗号化方式を外したり、より難解な暗号化方式を追加したパッケージを用意し
ELBのSSLセキュリティポリシーからRC4が除外されました | DevelopersIO
はじめに 2/12に、AWSのディスカッションフォーラムにて以下のアナウンスが行われました。 Announcement: Elastic Load Balancing releases security update to disable RC4 ELBにSSL証明書を組み込む際、Cipherの選択を行います。そこで設定するSSLセキュリティポリシーがアップデートされ、SSL CiphersからRC4を除外した「ELBSecurityPolicy-2015-02」がデフォルトで選択されることになりました。 SSL/TLS通信についてのおさらい ここでSSL/TLS通信について、WebブラウザとWebサーバの関係性に絞ってざっくりとおさらいしてみましょう。 (1)まずユーザーPCはWebブラウザでWebサーバに接続します。このやり取りでどのようなプロトコル(SSLやTLSなど)で暗号化通信を
Classic Load Balancer のアクセスログの有効化 - Elastic Load Balancing
ロードバランサーのアクセスログを有効にするには、ロードバランサーがログを格納する Amazon S3 バケットの名前を指定する必要があります。また、バケットに書き込むための Elastic Load Balancing アクセス権限を付与するバケットポリシーをこのバケットにアタッチする必要があります。
クラシックロードバランサー の SSL/TLS 証明書 - Elastic Load Balancing
フロントエンドリスナーに HTTPS (SSL or TLS) を使用する場合、ロードバランサーに TLS/TLS 証明書をデプロイする必要があります。インスタンスにリクエストを送信する前に、ロードバランサーはこの証明書を使用して接続を終了し、クライアントからのリクエストを復号します。 SSL および TLS プロトコルは、X.509 証明書 (SSL/TLS サーバー証明書) を使用して、クライアントとバックエンドアプリケーションの両方を認証します。X.509 証明書は、認証機関 (CA) によって発行された IDENTITY デジタル フォームで、識別情報、有効期間、パブリックキー、シリアルナンバー、発行者のデジタル署名が含まれます。 証明書の作成には、AWS Certificate Manager または SSL や TLS プロトコルをサポートする OpenSSL などのツールを使
ELBからの通信で408が多発する - Qiita
ELB1 - - [31/Jul/2014:05:44:20 +0000] "-" 408 - "-" "-" ELB2 - - [31/Jul/2014:05:44:21 +0000] "-" 408 - "-" "-" ELB1 - - [31/Jul/2014:05:45:11 +0000] "-" 408 - "-" "-" ELB2 - - [31/Jul/2014:05:45:13 +0000] "-" 408 - "-" "-" ELB1 - - [31/Jul/2014:05:46:03 +0000] "-" 408 - "-" "-" ELB2 - - [31/Jul/2014:05:46:05 +0000] "-" 408 - "-" "-" ELB1, ELB2はそれぞれELBのIPアドレス 408...request timeoutか・・・（＝"＝ 調査：ググる 最
「ELBからの通信で408が多発する」件で、結局どうすべきか調べたのでまとめた - 双六工場日誌
少し前にQiitaにこんなエントリが載っていました。問題としては、ELB配下に配置したApacheサーバで、レスポンスコード408で中身のないログが数秒おきに出続けるというものです。 AWS - ELBからの通信で408が多発する - Qiita この現象は、自分のところでも出ていて、このエントリにあるように公式フォーラムを見ても解決せず、原因がわからず困っていました。このエントリを見て、自分でも検証してみましたが、事象の分析としては、このQiitaのエントリにある内容の通りみたいです。 TCPコネクションを張ったあと、HTTPデータが来ないため、mod_reqtimeoutがDoSと判定して、apacheがコネクションを終了させている。 この件をググって見つけたのですが、qpstudyのリーダーこと、@iaraさんも2年前にこれを取り上げていますね。 Cloudpack night03
AWS News Blog
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
Amazon ELBをうまくつかうには、KeepAliveを有効にしよう。Timeoutは60秒よりだいぶ長くしよう。その背景。
Amazon ELBをうまくつかうには、KeepAliveを有効にしよう。Timeoutは60秒よりだいぶ長くしよう。その背景。 鯖管のメモ帳: AWSのELBでHealthyHostCountが0になるという記事の中で ■AWSのELBとApacheを使う際の注意点 ・Timeoutは120以上が推奨 ・ApacheのKeepAliveは有効にすべし。ELBとの接続効率があがる。 という形ですでにやるべきことは書いてあるのが、なぜそうなるか。。(いそがしい人は後は読まなくてok！) 根本的な理由としては、ELBはTCPを単にリレーしているのではなくて、アプリケーションレイヤのプロキシであることによるものが大きい。ELBはバックエンドのEC2との間で無通信の場合でも60秒はセッションを維持する。 ELBはTCP Persistent Connectionを提供し、webサーバとの間のTCP
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
