Qlik Cloud から AWS S3 に接続しようとした際、
IP制限をかけた途端に接続が一切通らなくなるという現象に遭遇しました。
S3のバケットポリシーも正しく設定し、
Qlik公式が公開しているIPレンジをホワイトリストに登録済み。
それでも Qlik Cloud の「Data connection」でテスト接続を実行すると──
「Access Denied」
という冷たいメッセージが返ってくるだけ。
IAMロールやキーの権限を何度見直しても解決せず、
「これはAWS側の設定ミスだろう」と思い込んで数時間を浪費しました。
ところが調べていくうちに、原因は想定外の場所にありました。
なんと、Qlik CloudとS3が同じリージョン内（ap-northeast-1＝東京）にある場合、
Qlik側のネットワーク経路の制約で接続自体ができないという仕様だったのです。
発生した問題
Qlik Cloud の管理画面から、
「Add new connection」→「Amazon S3」 を選び、
アクセスキーとシークレットキー、リージョン、バケット名を指定して接続を作成。
このとき、S3バケット側では次のようなIP制限付きポリシーを設定していました。
補足：
上記の 18.179.0.0/16 および 18.180.0.0/16 は、
Qlik Cloud Japan（東京リージョン）の公式アウトバウンドIPレンジです。
Qlik公式ドキュメント（Qlik Help – IP Addresses）で公開されており、
外部連携（S3・Snowflake・REST APIなど）時に使用される通信元アドレスとして明記されています。
この設定であれば Qlik Cloud からの通信は通るはず――
そう思っていました。
ところが、接続テストを実行すると毎回「Access Denied」。
CloudTrailを確認しても、S3側にはそもそもリクエストが届いていません。
どうやらQlik側で通信がはじかれているようでした。
原因を調べてみた
試しにAWS CloudTrailでログを追ってみると、
リクエストがS3に届いている形跡すらありません。
つまり「Qlik側で接続拒否されている」可能性が浮上。
そこで、Qlikの公式ドキュメントを再確認したところ──
なんと衝撃の記載が。
Qlik CloudとS3バケットが同一リージョン内（例：どちらも ap-northeast-1）にある場合、ネットワーク経路上の制限により接続できません。対応するには、別リージョンのS3を使用する必要があります。
原因：同一リージョン＋IP制限付きだと接続できない
つまりこういうことです
- Qlik Cloud と S3 が 同一リージョン にある場合、AWS内部ネットワーク経由で通信が行われる。
- この経路ではリクエストが固定の外部IPアドレスを持たないため、 S3 側で IP アドレスを条件にしたバケットポリシー（aws:SourceIp など）を設定すると、 ポリシー判定に失敗して Access Denied になる。
- 一方で、別リージョン（例：Qlik＝東京、S3＝大阪）にすると、 通信はパブリックインターネット経由となり、Qlikの外向きIP帯（18.179.0.0/16 など）が正しく評価されるため、 IP制限付きでも接続可能。
| 状況 | 接続可否 |
|---|---|
| Qlik Cloud と S3 が 同一リージョン、IP制限なし | 接続可（通常利用できる） |
| Qlik Cloud と S3 が 同一リージョン、IP制限あり | 接続不可（ヘルプ記載の制限に該当） |
| Qlik Cloud と S3 が 異なるリージョン、IP制限あり | 接続可（パブリック経由で到達可能） |
Qlik Cloud Japan のインフラが AWS 東京リージョン上に構築されており、
同一リージョン内のAWSリソースにダイレクト接続できない仕様になっていたのです。
まとめ：まさかの“リージョン罠”だった
今回の「Access Denied」問題、
結論としては Qlik CloudとS3が同じリージョンにあると、IP制限付きでは繋がらない という仕様の落とし穴でした。
同一リージョンだと、AWSの内部ネットワークを通って通信するんですが、
この経路では 外部IP（18.179.x.x みたいなやつ）が付かない ため、
S3側で「このIPだけ許可」というポリシーを設定しているとブロックされちゃうんですね。
逆に、S3を別リージョン（たとえば 大阪：ap-northeast-3）に置くと、
通信がパブリック経由になって外部IPが正しく評価されるので、
同じポリシーでもちゃんと通るようになります。
結果的にこうなりました
| 状況 | 結果 |
|---|---|
| 東京リージョン × 東京リージョン | ❌ 失敗（IPが評価されずAccess Denied） |
| 東京リージョン × 大阪リージョン | ✅ 成功（パブリック経由でIP制限クリア） |
| IP制限なし | ✅ 問題なし（ただしセキュリティ的には微妙） |
正直、「同じリージョンなら速くて安全でしょ」と思ってたんですが、
まさか逆にそれが原因で通信できないとは……という感じでした。
AWSの内部経路って便利なようで、IP制限と相性が悪いんですね。
今後同じような構成を作る人は、「S3は別リージョンに置くと安定する」って覚えておくと安心です。
