回答編集履歴
1
他回答・言及しなかった手法についての補足
test
CHANGED
|
@@ -5,3 +5,16 @@
|
|
|
5
5
|
別に「セキュリティアプライアンスなので」というのはあまり考えなくて良いです。
|
|
6
6
|
もう少しきちんとした挙動のSorryページを用意していてそれを使いたいならまた別の工夫が必要になるかもしれません。
|
|
7
7
|
以前はWAFのblock時のレスポンスをいじることができなかったので、前段にCloudFrontをかませてカスタムエラーレスポンスを503にする必要があり、CloudFrontを使っていないサービスでもそのためにわざわざCloudFrontを使ったりしてました。
|
|
8
|
+
|
|
9
|
+
追記
|
|
10
|
+
別回答にてWAFを使わない方法について言及されていますが、自分もそれらのページは一通り見ました。
|
|
11
|
+
その上であえて回答に記載しなかったのは下記の理由です。
|
|
12
|
+
|
|
13
|
+
- 前提として、ALBのターゲットグループにAPI Gatewayを設定することはできない。現状もそのような構成にはなっていない（と、読み取れる）
|
|
14
|
+
- そのため、リスナールールの順位変更によりALBのレスポンスでメンテナンスページを表示する手法を使うメリットがほとんどない
|
|
15
|
+
- 参考にしているページはCloudFront+S3・ALBの構成であり、今回の構成とは異なる
|
|
16
|
+
- 今回のケースだと、このためにわざわざ今回使っていないCloudFrontを用意することになりますが、それよりはAPI Gatewayに対して直接AWS WAFを適用するほうが圧倒的にシンプル
|
|
17
|
+
|
|
18
|
+
AWS WAFがセキュリティアプライアンスだから…というのはさして意味のない区分で、それよりも機能として何ができるのかに目を向けるべきかと思います。
|
|
19
|
+
|
|
20
|
+
ちなみに、他にもRoute53のFailoverを使う方法なども考えられましたが、DNSレコードを弄るとレコードが変なふうにキャッシュされたときに面倒なのでこちらもあえて記載していません（DNS周りにそれほど詳しくないから触りたくないというのはありますが…）。
|