最近、Qlik から AWS にデータを連携する処理を構築していました。
構成はシンプルで、
- Qlik から S3 に CSV を出力
- AWS Fargate(Batch)で Python 処理 → S3 に結果を書き戻す
- Qlik で結果の CSV を読み込んで可視化
という流れです。
「あれ、リージョン揃えたほうがよくない?」
この構成でひとつ気になったのが、
Qlik が使っているリージョンと、AWS の S3/Fargate のリージョンが違うと料金が上がる
という点。
何の料金がかかるの?
AWS の リージョン間データ転送料(Data Transfer Across Regions) です。
- Qlik Cloud(USリージョン)→ S3(東京リージョン)
- Fargate(US-east-1)→ S3(ap-northeast-1)
こういった リージョンを跨ぐ通信はすべて「データ転送費用」が発生します。
S3 への PUT/GET 自体はリージョン内なら安いのですが、
リージョンを跨いだ瞬間、データ転送料金が乗るためコストが増えます。
Qlik のリージョンってどこ?問題
ところが、Qlik Cloud の管理画面には リージョンが明確に書かれていない。
Qlik の URL が
*******.us.qlikcloud.comとなっているので、us と付いているし USリージョン(us-east-1)っぽい…
しかし 確証を持ちたい。
そこで Qlik にアクセスしてくる IP アドレスから逆引きで調べられないかと思い、
AWS が公開している以下の JSON を利用することにしました:
https://ip-ranges.amazonaws.com/ip-ranges.json
このファイルには AWS 全リージョンの IP 範囲が列挙されています。
AWS の IP → リージョン を調べるツール作った
せっかくなので、ブログ上から使える AWS IP リージョン判定ツールも作りました。
下のフォームに AWS の IP を入れると「どのリージョンのどのサービスなのか」一発で表示されます。
実際に調べた結果
Qlik のアクセスログにあった IP を調べた結果 ↓
- 18.***.***.*** → us-east-1
- 18.***.***.*** → us-east-1
- 34.***.***.*** → us-east-1
(実際のIPは伏せさせていただきます)
すべて us-east-1(バージニア北部) でした。
つまり現在使用している Qlik Cloud (******.us) は US East(N. Virginia) を使っている可能性が高い。
今回の結論
- 使用中環境のQlik Cloud は us-east-1 で動いているっぽい
- なので AWS Batch / Fargate / S3 を US-east-1 に置くと リージョン間のデータ転送コストを抑えられる
- 結果、毎月のコスト削減に繋がる
- ついでに AWS IP リージョン判定ツールも作れたので便利に使える
おわりに
こういう “沼みたいな検証” が、結局いちばん楽しかったりしますよね。
データは嘘をつきませんが、クラウド料金はときどき後ろから刺してきます。
……というわけで、リージョン合わせるだけでけっこう節約できるので、未来の自分のためにもメモしておきます。


