全然たいした話ではないのですが、へーって思ったので記録しておきます。 ALB にて外部からの不正アクセスを塞いだ話になります。 はじめに注意 ※追記３ この記事は、知識不足な状態で始まり、知識不足なまま初出した未熟な内容であり、外部の助力によりそれが解決に向かう、という流れになっています。 調査環境がAWSだったために、タイトルがこうなっていますが、実際はALB+ACM単独の問題ではなく、SSL/TLS としての仕様の話になっている、 ということを念頭において、読んでいただければと思います。 ※追記３ここまで 構成と問題点 手動で作成された ALB → EC2 環境があって、ワイルドカードなACM を使って 0.0.0.0:443 のみ開いており、EC2 は Global からのアクセスは遮断してありました。 にも関わらず、不正系なHostヘッダでアクセスされた形跡があり、コイツどこから来
AWS ALB の LCU の料金計算方法のメモ https://aws.amazon.com/jp/elasticloadbalancing/pricing/ から LCU の計算方法が個人的にわかりにくかった(僕の頭が悪いだけなのですが…)ので整理したメモ。 ただし、例 1 しか整理してない。 金額は アジア・パシフィック/東京 リージョンをベースにした。 例1の条件 (a) アプリケーションが 1 秒あたり平均 1 個の新しい接続を受信 (b) それぞれ 2 分間継続する (c) クライアントは毎秒平均 5 つのリクエストを送信 (d) リクエストと応答の合計処理バイト数は毎秒 300 KB (e) クライアントのリクエストをルーティングする 60 個のルールを設定 新しい接続(1秒あたり) LCU は 1 秒あたり 25 個の新しい接続を提供する ← 既定値 アプリケーションは 1
はじめに AWS ALB を使おうとすると、リスナー、ターゲットグループといった設定が登場し、どの設定が何を意味しているのか理解するのが結構たいへんです。 この記事では、そんな ALB の主な設定をまとめます。 全体像 ALB の主な設定の全体像は以下の通りです。 以下、順に説明していきます。 リスナー リスナーは、外部からアクセスするプロトコルやポートの設定です。 ロードバランサに対して、複数のリスナーを設定することができます。 ALB は HTTP と HTTPS に対応しているため、その両方か片方をリスナーとして登録することになります。 リスナールール・条件・アクション リスナーに対して、複数のリスナールールを紐付けることができます。 リスナールールには優先順位の設定があり、順に条件を満たすか判定されます。 条件を満たすと、そのリスナーに対応するアクションが呼び出されます。 アクショ
API Gateway and Application Load Balancer (ALB) are both great ways to route and serve requests from wherever your services live. Both services can be used in tandem with Lambda, EC2, Fargate, and VPCs. However, the trade offs are opaque. Most people believe that API Gateway is under powered and expensive, while ALB is really powerful and cheap. About this price comparison While both services diff
h2 2020-03-08T23:50:58.701251Z app/xxxxxx-prod-alb/xxxxxxxxx 222.222.222.222:64202 - -1 -1 -1 302 - 1254 224 "GET https://example.com:443/action_store HTTP/2.0" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.102 Safari/537.36 Edge/18.18362" ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 - "Root=1-xxxxxxx-xxxxxxxxxxxx" "at.m3.com" "arn:aws:acm:ap-northeast-1
Ingress annotations¶ You can add kubernetes annotations to ingress and service objects to customize their behavior. Note Annotations applied to service have higher priority over annotations applied to ingress. Location column below indicates where that annotation can be applied to. Annotation keys and values can only be strings. Advanced format are encoded as below: boolean: 'true' integer: '42' s
ホストベースルーティングとは httpヘッダのHostフィールドにもとづいたALBへのリクエストを指定したターゲットグループへ ルーティングすることが可能なALBの機能です。 メリットについて ホストベースルーティング設定を使用するメリットは下記のようなものがあげられます。 複数のALBを集約できる(コスト削減) Nginxなどでプロキシサーバを建ててルーティング設定をしていたものをALBで代替できる ユースケース 一つユースケースを取って考えたいと思います。 例えば、WEBサーバ1にはA.comがホストされ、WEBサーバ2にはB.comがホストされているWEBサーバがあるとします。 この2台のWEBサーバへのアクセスにおいて、A.comへのアクセスはWEBサーバ1のみへトラフィックをルーティングし、B.comへのアクセスはWEBサーバ2のみへトラフィックをルーティングしたいといった場合に
【AWS ALB+Nginx+Unicorn】504 Gateway Time-outと、upstream timed out (110: Connection timed out)が発生したときの対処法 - 紙一重の積み重ね
発生した事象 RailsアプリケーションのCSV取り込み処理で504エラーが発生 環境 AWS ALB Nginx Unicorn Rails5.1.1 考えられる原因 AWS ALBのアイドルタイムアウトが短い デフォルトは60秒 最大3600秒まで設定可能 Nginx、Unicornのタイムアウト時間が短い 対策 AWS ALBのタイムアウト時間を設定。 Nginxと合わせて、暫定で360秒に設定。 Nginxにproxy_read_timeoutを設定 proxyサーバからのレスポンスを読み込むためのタイムアウト時間。proxyサーバがこの時間内に何も応答しない場合、接続を閉じる。 defaultは60秒。 Unicornよりも余裕を持たせて、暫定で360秒に設定。 Module ngx_http_proxy_module Unicornにtimeoutを設定 ワーカープロセスのタイ
■概要 AWS上に構築したWordPress環境をSSL化しました。 構成は下記となりALBで終端してALBから先はHTTP通信となります。 ALBのリダイレクト機能とx-forwarded-protoを利用して構築したので WordPressサーバの.htaccessにリダイレクト設定を入れる必要がありません。 また、ACMを利用したのでSSL証明書費用を抑えることができました。 通信プロトコルのシーケンス図は下記です。 ユーザからのアクセスがHTTPでもHTTPSのいずれでもALBとEC2間はHTTP通信となり ユーザへの応答はHTTPSに統一されます。 ■環境 ・WordPress:5.3.x ・MW:apache httpd2.4,php7.x ・OS:Amazon Linux 2 ■やったこと AWSリソースの作成・環境構築、WordPressのインストールは割愛しています。 以
![[AWS]ALB +ACM + EC2でWordPressをSSL化した際の勘所 - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/e7272bdc99c92fa8db70e9a323bea5e96533ce36/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-412672c5f0600ab9a64263b751f1bc81.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk3MiZoPTM3OCZ0eHQ9JTVCQVdTJTVEQUxCJTIwJTJCQUNNJTIwJTJCJTIwRUMyJUUzJTgxJUE3V29yZFByZXNzJUUzJTgyJTkyU1NMJUU1JThDJTk2JUUzJTgxJTk3JUUzJTgxJTlGJUU5JTlBJTlCJUUzJTgxJUFFJUU1JThCJTk4JUU2JTg5JTgwJnR4dC1hbGlnbj1sZWZ0JTJDdG9wJnR4dC1jb2xvcj0lMjMyMTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9NTYmcz0xMjg1ZmEyNTViMDkwZGExMzQxMTZkM2M1ODJiMGRkZQ%26mark-x%3D142%26mark-y%3D57%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZoPTc2Jnc9NzcwJnR4dD0lNDBVcnl5JnR4dC1jb2xvcj0lMjMyMTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9MzYmdHh0LWFsaWduPWxlZnQlMkN0b3Amcz1hYjI4ZTZkMTczZjI4Yzc2MmQ2ZDFlNWUxZTNmYjYwNw%26blend-x%3D142%26blend-y%3D486%26blend-mode%3Dnormal%26s%3D63f3be67f52fa700286cca70214f64ab)
【AWS】ALBに固定のIPアドレスを設定する方法！Global Acceleratorを使ってALBに固定のIPアドレスでアクセスする方法
AWSのALB（Application Load Balancer）を使っていて、ALBに固定のIPアドレスでアクセスしたいな、という場合があると思います。 そんな時、Global Acceleratorというサービスを使うと、簡単にALBに固定IPアドレスでアクセスできるようになります。 ALBに固定IPを追加したい場面 例えばAWSでWEBサービスの環境を構築したいとき、WEBサーバーの前にALBを配置して負荷分散や、SSL化を行うような構成はよくある構成だと思います。 こんな構成をとった場合に、単純にDNSへALBのエンドポイントを登録すればよさそうですが、ここで1つ注意が必要です。 サブドメインを使う場合は問題ないのですが、メインのドメインにALBのエンドポイントをDNSへ登録して紐づけたいという場合には注意しなければなりません。 ドメインに対してCNAMEは登録できない 正しくは
AWS ALBをSSLの終端にしたときに Strict Transport Security ヘッダーが付与されない
現在クラウドリフトの作業をしていて、ECS（またはEC2）の前段にALBを配置し、ALBをSSLの終端としている。 これはAWSでパブリックなアプリケーションを作成する際によく取られる構成だが、HTTP Strict Transport Security（HSTS）は仕様上HTTPSの経路でのみレスポンスに付与される。 この仕様により、ALBをSSLの終端に設定するとレスポンスにHSTSが付与されない。 この問題を解決するためにはECSに乗せているアプリケーション上で、ALBに到達した際のプロトコルを見るように修正する必要があり、その元のプロトコルがX-Forwarded-Proto (XFP) に入ってくる。 この対応を行う上で調べた内容をメモしておく。
AWS構成 ALBとECSを繋げて、ALBのドメイン名からアクセスするようになっています。 実践 1. IP制限をかけたいロードバランサーのRulesを選択 2. Manage rulesを選択 3.+を選択後、ルールの挿入をクリック 4. 送信元IPを選択 制限したいIPアドレスを入力します。 5. 転送先の選択 ECSではターゲットグループを選択します 6. その他のIPアドレスの処理 4番でIPの制限はできたので他のすべてのアドレス(0.0.0.0/0)を追加します 7. テキストの返却 5番ではターゲットグループを選択しましたが、固定レスポンスを返すように設定します。 html/textを選んで タグで囲んでエラーメッセージを入力します。 8. 制限したIP以外でのアクセス ブラウザ上でDNS名を入力して以下のようになれば成功です
AWSのALBとはAWSにはELB（Elastic Load Balancing）という優れたロードバランシング（負荷分散）サービスがありますが、そのELBの4つのサービスの中でも、最も利用されているのが「AWS ALB」です。 AWS ALBは「Application Load Balancer」の略で、使い方としては主にWebサービスの負荷分散を目的に利用されていますが、負荷分散の機能以外にも様々な優れた機能を有しています。 Webサービスはその多くが、一般ユーザが利用しますが、Webサービスの停止や遅延は一般ユーザのサービスへの信頼を損ね、ブランドイメージする壊しかねない大きなリスクがあります。そのため、Webサービスでは負荷分散のロードバランサの設置は必須とも言えます。 とはいえ、オンプレミス環境で、自前でロードバランサを導入、設置するのは大きな負担や負荷を伴います。そこで、様々な
[Terraform AWS]ALBにACMで複数ドメインを指定しようとしたら出たエラー Error creating LB Listener: DuplicateListener: A listener already exists on this port for this load balancer
エラーメッセージからみるに、１つのリスナー・同一ポートには１つしか指定出来ないみたいです。今回、https 443に複数設定しようとしていた為、エラーとなったようです。 対応内容 調べたところ、1個目のhttpsリスナーは aws_lb_listener で、2個目以降のhttpsリスナーは aws_lb_listener_certificate を使用する必要があったようです。 httpのリスナーはaws_lb_listener で大丈夫です。 AドメインとBドメインを1つのALBのhttpsリスナーとする場合のサンプル resource "aws_lb_listener" "alb_listener_http" { load_balancer_arn = aws_lb.alb.arn port = "80" protocol = "HTTP" default_action { type
![[Terraform AWS]ALBにACMで複数ドメインを指定しようとしたら出たエラー Error creating LB Listener: DuplicateListener: A listener already exists on this port for this load balancer](https://cdn-ak-scissors.b.st-hatena.com/image/square/cc614dec2761b7ac5462d94dc58edeced6acc66f/height=288;version=1;width=512/https%3A%2F%2Fnormalblog.net%2Fsystem%2Fwp-content%2Fuploads%2F2019%2F08%2Fterraform-logo.png){kind=logo}
About 社内用のシステムやリリース前の機能を限定公開したい場合新規にログイン機能を実装するのは非効率です。 AWSにはALBの認証機能としてOpenIDConnectをサポートしています。 Facebook,Yahoo,Googleなどを利用している場合、ALBをアプリケーションとして登録するだけで簡単に認証機能が実装できます。 リモートワークが推奨されている昨今、突然社内用の管理画面にログイン機能が必要になってお困りになっている方もいらっしゃるのではないでしょうか？ 今回はGoogleのOauthクライアントIDを利用してOIDCする方法を説明します。 利点 アプリケーション毎に管理機能を実装する必要がなくなる。 認証のフロー ALBにアクセス ログイン状態をGoogleAPIに問い合わせる 非ログイン状態であればGoogleの認証画面を表示、ログイン状態ならALBにリダイレクト A
はじめに AWS ALBのコストを算出する機会があったものの LCUコストの算出がすぐに理解できなかったので、 (https://aws.amazon.com/jp/elasticloadbalancing/pricing/?nc=sn&loc=3) に記載の計算例を見てみることにしました。 そもそもLCUとは？ LCUは「Load Balancer Capacity Units」の略でALBの使用量の単位です。 料金例 ここからALBの料金表に記載の計算例を見ていきます。 ※リージョンはアジアパシフィック(東京)を選択 ※LCUがトラフィックを処理する尺度や既定値の情報に関しては、割愛させて頂きます。 詳細はALBの料金表を参照してください。 ■例1 条件 (1) アプリケーションが 1 秒あたり平均 1 個の新しい接続を受信 (2) それぞれ 2 分間継続すると仮定 (3) クライアン
【AWS】ALBでEC2インスタンス（ターゲットグループ）のヘルスチェックにどうしても失敗する。。 - Qiita
現在個人開発しているRailsアプリがやっと完成し、AWSへのデプロイ作業にチャレンジしました。（ECR × ECS × CircleCIを利用し、gitからmasterブランチへpushするとCIがビルドされ、テストが通ると自動デプロイされるといった感じの構成です） その際、EC2インスタンスへのヘルスチェックが通らずに困り果ててしまったので、ついにプログラミング独学勢？の切り札であるMENTAを利用しました。 そしたら1～2週間程悩んでいた問題が開始わずか10分ほどで解決してしまい、あっけなく終わってしまいました。。調べてもこの解決方法はなかなか見当たらなかった（多分僕の探し方の問題）ので、僕と同じように膨大な時間を無駄にしないためにも、ここに備忘録として残そうと思います！ 今回相談させていただいたメンタ―さん ルビコン＠クラウド(AWS)エンジニアさん ルビコンさんのTwitter
はじめに キャンペーン等でWebサーバに対して想定数以上のアクセスが発生した場合に、Webサーバが高負荷となりレスポンスが悪化することがあると思います。そのような場合には、負荷を低減するために、一定数以上のアクセスを抑止する方法が考えられます。(他には、"Webサーバの前段に高機能のロードバランサを導入しアクセスを抑止"したり、"Webサーバをスケールアウトする"方法もあります) 今回、AWS ALB(Application Load Balancer)及びAWSマネージメントサービスのみでこれを実装してみました。 なお、調査した限り、実際には"一定数以上のアクセスを抑止する"といったことはできませんでした(AWS SA様へも確認済)。代わりの方法として、特定パスに対するアクセスを一時的に抑止することで、Webサイト全体のレスポンス悪化を回避する方法を採用しています。 環境 構成と抑止の挙
はじめに リクエストヘッダーのX-Forwarded-Forは、Webサーバーやアプリ側でアクセス元IPアドレスを取得する手段としてよく使われています。 本記事では、AWS Application Load Balancer(ALB) のX-Forwarded-Forの仕様とX-Forwarded-For使用時のアクセス元IPアドレスの偽装対策について書いています。 ALBのX-Forwarded-Forの仕様 HTTP ヘッダーと Application Load Balancer https://docs.aws.amazon.com/ja_jp/elasticloadbalancing/latest/application/x-forwarded-headers.html ALB - X-Forwarded-Forのヘッダーの仕様 付加 / append ... アクセス元IPを追加
Docker、AWS ALB + ACM（SSL証明書）などの導入方法は割愛します。 構成 Gitlab Omnibus版の構成を理解しくことで適切に設定できるようになります。 ざっくりとした流れはこんな感じです。 クライアント → ALB → ターゲットグループ → EC2 → Gitlabコンテナ（Nginx → gitlab-workhorse → puma → Gitlab） ※参考：【GitLab】アーキテクチャ 前提条件 mattermostの移行は含まれていない（必要な方は別途コメント頂ければ回答可能） pagesの移行は含まれていない（CIでpageをS3に保存し、Nginxで公開するようにした） registoryの移行は含まれていない（ECRを使うようにした） gitリモートのプロトコルはhttpsのみ 下記の説明用にドメイン名はhogefuga.comを用いる 手順
AWS ALB パスベースルーティングを実装してみました。(EC2 + ALB + Apache) - Qiita
はじめに こんんちは、山田です。 今回は、Appliation Load Balancerを用いて、URLのパスごとに接続先のポート番号を変更する方法について記載していきます。 全体構成図 今回使用するAWSリソースは以下の通りです。 AWSリソース名 個数 備考
1. はじめに Lightsailで個人ブログをホスティングしているのですが、メンテナンス時はWordPressの標準機能でメンテナンスページを表示させていました。 今後、LightsailをALBと連携させたいと考えています。 その際、ALB側でメンテナンスページをコントロールできた方がページコントロールの観点から統一性があって良いかなと思い、ALBのリスナールールでメンテナンスページを表示させるようにしようと思いました。 メンテナンスページを表示させる方法は色々ありますが、(CloudFront+S3, 単純にS3から引っ張るetc..)ALBのリスナールールで表示させる方が一番簡単な気がするので、その方法を採用しました。 本記事では単純にALBのリスナールールでメンテナンスページを表示させる方法を公開したいと思います。 2. 概要 ALBのリスナールールを利用し、静的なメンテナンスペ
ZabbixでAWS ALBの監視をする: 前提zabbix3.4 ALBに紐づいているTargetGroupのヘルスチェックが通っているかを確認したい 構成AWS ALBはHealthyHostCountという情報をCloud watchに保存しています。 Cloud Watchからの情報はAPIを経由して取得する必要があります。 なので今回は 1. external scriptsにAPIを打ってzabbix senderでcloud watchの情報を送るスクリプトを配置する 2. zabbix server側でzabbix trapperを使ってzabbix senderで送られた情報をキャッチする 3. そのitemでアラートを出すようにする zabbix trapper等の情報は以下が詳しいです。 https://www.zabbix.com/documentation/3.0
AWS ELBについて AWS Elastic Load Balancerには複数のLoadBalancerタイプが存在する。2021年6月時点で存在するのは以下の4種類 Application Load Balancer（ALB) Network Load Balancer（NLB) Gateway Load Balancer Classic Load Balancer(CLB) このうち新規利用するにあたってはCLBは推奨されておらずALBもしくはNLBを利用することになる。 Gateway Load Balancerはサードパーティのアプライアンスを利用する際に有用ということでALB・NLBと明らかに性格が異なる。 ALBはアプリケーションレイヤー、NLBはトランスポートレイヤーで機能するロードバランサという違いがあるが使おうと思えばどちらでも使えるというユースケースもあるのでその差
初めに 以下の手順に沿って進めます。 1. dockerがインストールされたAmazon LinuxにBASIC認証を作成する 2. BASIC認証で発行された秘密鍵と証明書を使用してALBを起動する 用語や認識など間違いがありましたら教えていただけると幸いです。 手順1 BASIC認証作成 まず初めにopenssl.cnfの253行目subjectAltNameをインスタンスのプライベートアドレスに書き換えます。
結論、１つのALBで複数種類のサーバーをロードバランスできます！ 結論としましては、１つのALBを利用して複数種類のサーバー（例えば、webサーバとAPIサーバー）をロードバランス出来ます。 ALBの転送・リダイレクト・固定レスポンスルールの条件 ALBの条件に、 ホストヘッダー（httpリクエスト時のhostヘッダー。Virtual Hostと同じ意味）パス でルールを分けることが出来、ルールを複数作ることにより、複数種類のサーバーに転送することが出来ます。 条件は、ホストヘッダーかつパスすべてに一致した場合のルールも作成できます。 ルール条件のアクションとしては、 転送先リダイレクト先固定レスポンスを返す ことが出来ます。 例えば、 webサーバーとapiサーバーをホストヘッダーで別の Virtual Host として一つのALBで動作させることも出来ますし、 apiサーバーは/api
AWS ALBからのリクエストだけ許可したい場合のEC2に設定するセキュリティグループのインバウンドルールの設定 - Qiita
概要 下記のような構成の場合、星1と星2の部分にセキュリティグループを設定することが一般的である。 この場合、言わずもがなプライベートサブネット内部のEC2にはALBを通して接続してほしい。（ブラウザからのアクセスの場合） その要望に答えるには星2のセキュリティグループを設定して「ALBからのインバウンドルールのみ許可」してあげれば良い。 「ALBからのインバウンドルールのみ許可」について 簡単にまとめる。 方法 実は非常に簡単である。 「星2のセキュリティグループのインバウンドルールのHTTPSの設定のソース（リクエスト送信元）を星1のセキュリティグループに設定する」だけである。 参考文献でも紹介されているのでぜひご確認いただきたい。 参考文献 Register as a new user and use Qiita more conveniently You get articles
AWS ALB配下のspringbootでStrict-Transport-Securityヘッダーが付与されない - Qiita
発生した問題 ALBにECMのSSL証明書を付けてSSL終端している環境で、spring-bootのアプリケーションにhttpsでアクセスしてもStrict-Transport-Securityヘッダーが付与されませんでした。 環境 spring-boot 3.0.6 spring-security 6.0.3 SpringSecurityの仕様を見るとStrict-Transport-Securityはデフォルトで付与されるようです。 Cache-Control: no-cache, no-store, max-age=0, must-revalidate Pragma: no-cache Expires: 0 X-Content-Type-Options: nosniff Strict-Transport-Security: max-age=31536000 ; includeSubD
AWS EKSのAWS ALB Ingress Controllerを破壊的変更を加えずにAWS Load Balancer ControllerにアップデートかつELBをまとめる方法
AWS EKSのAWS ALB Ingress Controllerを破壊的変更を加えずにAWS Load Balancer ControllerにアップデートかつELBをまとめる方法 2022-07-24 AWS ALB Ingress Controller to AWS Load Balancer Controller自体は割りと簡単 前提 現在面倒をみているプロダクトがEKSv1.19→v1.21にアップデートをした。事業部専属というわけではなくてSREとして別プロダクトばっかりみてたらサポート残り1ヶ月の状態で「あ、やべ。残り一ヶ月でEKS強制アプデ入るわ」となり、やらなくては～となったがプロダクトのフロントエンドの子が「やってみたいです！」というので他のレイヤーに対する熱意◎でまかせたら、会社都合でその子が部署異動で「開発環境はアプデ終わりましたが本番はできませんでした…後はよろ
ALB, CloudFront がインターフェースにある場合のメンテナンス切り替え方法をまとめました。 ALB の場合1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 1
ロードバランサーとは？ ロードバランサーとは、その名前が示す通り、サーバーやネットワークの「負荷（ロード）」を「均等に分散（バランス）」する技術のことです。 インターネットが発展し、Webサイトやアプリケーションのトラフィックが増大するにつれ、ひとつのサーバーだけでその全てを処理することは難しくなってきました。 そこで、ロードバランサーが登場しました。 ロードバランサーの主要な機能としては下記の2つがあります。 負荷分散 クライアント（例えば、ウェブブラウザを使用しているユーザー）からのリクエストがロードバランサーに到達すると、ロードバランサーはそのリクエストを複数のサーバーの中から一つに振り分けます。振り分ける際の基準は、それぞれのサーバーの現在の負荷や性能、設定に依存します。 この仕組みにより、全てのリクエストが一つのサーバーに集中することを防ぎ、全てのサーバーのリソースを有効に活用す
概要 AWS ALBにEC2やFargateなどをぶら下げてサービスを稼働させていて、時々メンテナンス作業のためにサービスを停止し、代わりにメンテナンスページを表示させるようにしたいときがある ここではALB+Lambdaに切り替えることを想定してメンテナンスページを表示させてみた 別解：ALB単独でメンテナンスページを表示させる場合 Lambdaを使わずともALB単独で簡単なメンテナンスページを表示させることも可能である 下記のようにALBのリスナールールの設定で固定レスポンスを返す設定を使えばALB単独でメンテナンスページを表示させることは可能だ しかし、この方法には制約がある レスポンス本文は最大1024文字が上限 HTTPレスポンスヘッダーはカスタマイズできない 画像などで別ファイルを使うには別サーバーを使う必要がある 構成 通常はALBとEC2やFargateを紐付けてサービスを
昨年11月にAmazon Web Service（AWS）のApplication Load Balancer（ALB）で相互TLSがサポートされました。これにより、ALBでのクライアント証明書認証が可能となりました。 そこで今回、弊社のクライアント証明書サービス「マネージドPKI Lite by GMO」で発行しましたテスト用のクライアント証明書を用いて検証しましたので、そのクライアント証明書認証の設定方法とその設定後の結果を紹介します。 初めに 事前準備として、EC2仮想インスタンス2台（Ubuntu + Apache）と、ALBでロードバランシングをおこなう構成を作成しておきます。 非常に簡単ですが、今回は以下の構成になります。 この時点では、クライアントPCとALBはhttpで通信を行っている状態とします。 ALBの相互TLS化 それでは、ALBの相互TLS化と、クライアント証明書
yum install httpdだけだとAWS ALBでHealth check failed with these codes: [403] - Qiita
yum install httpdだけだとAWS ALBでHealth check failed with these codes: [403]ApacheAWSelb 表題だけで初心者がやらかすアレと言われそうなアレですが、やらかしたのでメモ。 EC2インスタンス起動時にユーザーデータで yum install httpd -y 起動したインスタンスのIPアドレスにhttp接続してApacheのテストページが表示されることを確認 Application Load Balanverを作成し、ターゲットグループを作り、このEC2インスタンスを追加 少し待ってターゲットのステータスを見ると unhealthy 原因は単純で、Status Detailに Health check failed with these codes: [403] とある通り、Apacheが403 Forbiddenエ
![yum install httpdだけだとAWS ALBでHealth check failed with these codes: [403] - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/bb69dd8c1c570aebb98eef2cc65cc57ac9e2ec1e/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-412672c5f0600ab9a64263b751f1bc81.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk3MiZoPTM3OCZ0eHQ9eXVtJTIwaW5zdGFsbCUyMGh0dHBkJUUzJTgxJUEwJUUzJTgxJTkxJUUzJTgxJUEwJUUzJTgxJUE4QVdTJTIwQUxCJUUzJTgxJUE3SGVhbHRoJTIwY2hlY2slMjBmYWlsZWQlMjB3aXRoJTIwdGhlc2UlMjBjb2RlcyUzQSUyMCU1QjQwMyU1RCZ0eHQtYWxpZ249bGVmdCUyQ3RvcCZ0eHQtY29sb3I9JTIzMjEyMTIxJnR4dC1mb250PUhpcmFnaW5vJTIwU2FucyUyMFc2JnR4dC1zaXplPTU2JnM9NmEyMThlODg1ZWE5ZmFlODRjZGI5MDE0MzVmODI5YTE%26mark-x%3D142%26mark-y%3D57%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZoPTc2Jnc9NzcwJnR4dD0lNDB0c3VrYW1vdG8mdHh0LWNvbG9yPSUyMzIxMjEyMSZ0eHQtZm9udD1IaXJhZ2lubyUyMFNhbnMlMjBXNiZ0eHQtc2l6ZT0zNiZ0eHQtYWxpZ249bGVmdCUyQ3RvcCZzPTZkM2FlY2FmOWVkZDg4ZTgxYmFhMGZkZDUwYTNjMzlj%26blend-x%3D142%26blend-y%3D486%26blend-mode%3Dnormal%26s%3D0cbd4172547a2bf9ee7a45aa26e0709e)
ALBのログをAthenaで分析する方法は、公式ドキュメントに記載があるのですが、この手順でデータベースを作成すると、日付の条件を入れて検索したいとき、大量のデータをスキャンしてしまい、遅い上にお金がかかるという問題に遭遇します。 そこでおすすめしたいのが、データベース作成時にパーティションを作っておくことです。 ・・・という記事を書こうと思っていたのですが、このドキュメントでもパーティションを利用するようになっていたので、記事の役割が死にました。 なので、この記事は削除しようかとも思ったのですが、パーティションの切り方が公式と違っていたので、一応投稿して供養しておきます。 Athenaテーブルの作成 Athenaで適当なデータベースを選択、または作成したら、以下のクエリを実行してテーブルを作成します。 実際に作成する場合は、SQLのこれらの箇所を修正してください。 LOCATION： '
【AWS】ALBのリスナールールの優先度について【Sorryページ】 - サーバーワークスエンジニアブログ
こんにちは、CI部 柿﨑です。 最近はバドミントンのスマッシュがキレイに打てるようになってきており、楽しくて仕方ありません。 今回はALBのリスナールールの優先度に焦点を当てていきたいと思います。 ※本ブログの執筆時点(2022年7月)での情報となりますので今後、変更されることが予想されます。 ALBのリスナールールの優先度について 勘違いしていたこと 事実 疑問1 疑問2 今回の調査を行うに至った背景 ALBのリスナールールの優先度について 勘違いしていたこと ALBのリスナールールを複数設定するとマネコン上では以下のとおりに優先度が1, 2, 3, 4と表示されます。 このことから優先度の設定は1, 2, 3, 4のように数字を切り詰めた状態でしか設定できず、ネットワークACLのルールのように10, 20, 30, 40と設定することができないと思っていました。 事実 マネコン上では優
はじめに AWSでALB→EC2への疎通がうまくできなかったら、よく4XXか5XXのエラーコードが返してきた経験があります。 4XX、5XXエラーコードは何を指しているか、またそのエラーコードが返してきた際に、 何を優先してトラブルシューティングするかをまとめていきたいです。 4XX、5XXエラーコード 結論から申し上げますと、 4XXはクライアント側エラー 5XXはサーバー側エラー になります。 エラーコードの詳細内容は、下記のサイトをご覧いただければと思います。 HTTP 502: Bad gateway Wikipediaから参考すると、502エラーコードの意味は以下となります。 502 Bad Gateway The server was acting as a gateway or proxy and received an invalid response from the u
概要 AWSでインフラ構築する一部分のメモ 実際にどういう構成で構築するのか次第で柔軟に参考にして頂ければ幸いです。 最終的にできる構成 今回出来上がる構成は以下の通りです Request(https) -> Route53 -> ALB -> EC2 構築の流れ ※前提：「EC2インスタンス有」「ドメイン取得済み(今回はfreenom)」「セキュリティグループ有」 Route53設定 (ネームサーバ) ACMで証明書取得 ALB (httpsリスナー) Route53でドメイン割り当て 1 で「リクエスト -> Route53」の流れを用意 2,3 で「ALB -> EC2」の流れを用意 4 で 「Route53 -> ALB」の流れを用意 のようなイメージです。 Route53 ドメインの設定 AWSマネジメントコンソールでRoute53に進む 「ホストゾーンを作成」を押下 もう一度「
AWS WAF (Web Application Firewall) クラウド上で動作するファイヤーウォール IPアドレスや、国情報、ヘッダーの内容をもとにアクセスを許可、遮断できる Amazon CloudFrontや、Application Load Balancer (ALB)にデプロイして利用できる WAF（Web アプリケーションファイアウォール）とは？| AWS 2016年から後発でALBでも使用できるようになったとこと AWS WAFがALB(Application Load Balancer)で利用出来るようになりました | Developers.IO 目標 日本国内からはEC2にアクセス可能 ALBにWAFを設定し海外からのアクセスを遮断する アーキテクチャ - 構成図 上が目標物、下はCloudfrontを使用するパターン 基本はweb serverの前に置く、よりクラ
概要 ALB で X509 証明書を提示する相互認証クライアントをサポート 今まで mTLS認証を⾏うためには NLB で HTTPS をパススルーして Apache 等 でクライアント認証を⾏う必要がありました 相互認証 (mTLS) パススルー トラストストアで検証
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
AWS ALB+ACMの意外な落とし穴 | 外道父の匠
AWS ALB の LCU の料金計算方法の備忘録 - Qiita
AWS ALB の設定方法は？リスナー？ターゲットグループ？ - 完全に理解した.com
AWS ALB vs API Gateway cost
AWS ALB のアクセスログをJSON形式に整形する - Qiita
Annotation - AWS ALB Ingress Controller
AWS ALBのホストベースルーティング設定について - Clara's Blog
[AWS]ALB +ACM + EC2でWordPressをSSL化した際の勘所 - Qiita
【AWS】ALBでIP制限をかける - Qiita
AWS ALBとは？ELBとの違いや機能・メリットや料金についても解説！
AWS ALBの認証機能でGoogleアカウント認証を設定する (OpenIDConnect) - Qiita
AWS ALB LCUコスト確認まとめ - Qiita
AWS ALBでの流量制限を実装してみました - Qiita
【AWS】ALB利用時のアクセス元IPの偽装対策 (X-Forwarded-For) - Qiita
オンプレ版Gitlab CE OmnibusをAWS+ALB+Docker版に移行メモ - Qiita
【AWS】ALBのみでメンテナンスページを表示させる by CloudFormation - Qiita
ZabbixでAWS ALBの監視をする
2021年6月時点AWS ALBとNLBの機能比較と使い所の検討 - Qiita
DockerのBASIC認証で作成した証明書と秘密鍵をAWS ALBで使用する方法 - Qiita
AWS ALBは複数種類のサーバに転送できるか？例えばwebとapiとか | puti se blog
AWS ALB/CloudFront でのメンテナンス切り替え方法
AWS ALBとは？ ELBとはどう違う？ | 株式会社スタイルズ
AWS ALB + Lambdaでメンテナンスページを作る - Qiita
AWS ALBでのクライアント証明書認証の設定方法
【AWS】ALBのログをAthenaで分析するときの工夫（供養） - White Box技術部
【AWS】ALBに4XX、5XXエラーコードのトラブルシューティングについて - Qiita
【AWS】ALB->ドメイン->SSL証明書 メモ - Qiita
AWS ALBにWAFを設定して海外からのアクセスを遮断してみる - Qiita
AWS ALB で 相互認証(mTLS) をする - Qiita