API GatewayのIP制限設定ガイド｜リソースポリシーの書き方

API GatewayでIPアドレスによるアクセス制限をかける標準的な方法は、REST APIの「リソースポリシー」に aws:SourceIp 条件を書くことです。

ただし、着手する前に必ず確認すべき制約があります。

この記事では、REST APIでの設定手順、HTTP APIでの代替手段、そしてつまずきやすいポイントを解説します。

IP制限そのものの仕組みと、許可リスト方式で運用するときの前提はIP制限（IPアドレス制限）とは？仕組みと設定方法を解説にまとめています。

リソースポリシーによるIP制限の書き方

特定のIPアドレスだけを許可する

もっともよく使うのが、許可リスト方式です。次のポリシーは「すべて許可したうえで、指定したIPアドレス以外からのアクセスを拒否する」形になります。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": "*",
      "Action": "execute-api:Invoke",
      "Resource": "execute-api:/*"
    },
    {
      "Effect": "Deny",
      "Principal": "*",
      "Action": "execute-api:Invoke",
      "Resource": "execute-api:/*",
      "Condition": {
        "NotIpAddress": {
          "aws:SourceIp": ["203.0.113.0/24", "198.51.100.10/32"]
        }
      }
    }
  ]
}

ポイントは2つ目のステートメントの NotIpAddress です。「指定したIP以外なら拒否」という意味になり、これで許可リスト方式が実現します。

特定のIPアドレスからのアクセスを拒否する

逆に、特定のIPアドレスだけをブロックしたい場合は IpAddress を使います。

{
  "Effect": "Deny",
  "Principal": "*",
  "Action": "execute-api:Invoke",
  "Resource": "execute-api:/*",
  "Condition": {
    "IpAddress": {
      "aws:SourceIp": ["192.0.2.0/24"]
    }
  }
}

NotIpAddress（許可リスト）と IpAddress（拒否リスト）の取り違えは事故のもとです。保存する前にどちらの意味になっているか必ず読み返してください。

設定手順

HTTP APIでIP制限をかけたい場合

HTTP APIはリソースポリシーもAWS WAFも使えないため、次のいずれかで代替します。

CloudFrontを前段に置く構成はCloudFrontのIP制限設定ガイドで解説しています。

つまずきやすい落とし穴

デプロイし直さないと反映されない

もっとも多い「設定したのに効かない」の原因です。 リソースポリシーは保存しただけでは有効になりません。必ずAPIを再デプロイしてください。

プライベートAPIでは書き方が変わる

VPCエンドポイント経由でのみ公開するプライベートAPIの場合、条件に使うのは aws:SourceIp ではなく aws:SourceVpce（VPCエンドポイントID）や aws:SourceVpc です。プライベートAPIに aws:SourceIp を書いても意図した動作になりません。

そもそも社内ネットワークからしか使わないAPIであれば、インターネットに公開せずプライベートAPIにするほうが安全です。IP制限は「インターネットに公開したうえで、入口を絞る」ための手段だと整理しておくとよいでしょう。

前段にCloudFrontやALBがいるとIPが変わる

API Gatewayの前にCloudFrontやロードバランサーを置いている場合、aws:SourceIp で見えるのはその手前のサービスのIPアドレスになることがあります。利用者本来のIPアドレスで判定したい場合は、前段側でIP制限をかけるか、ヘッダーの値を使った判定を検討します。

許可するIPアドレスが変わってしまう

設定以前の問題として、許可リストに登録したグローバルIPアドレスが固定でなければ運用できません。

社内から呼ぶAPIをIP制限で守る場合、オフィス回線が動的IPだと番号が変わるたびに全社員がAPIを叩けなくなります。テレワークの開発者がいれば、自宅回線のIPアドレスを1件ずつポリシーに書き足す運用になり、そう長くは続きません。

ロリポップ！固定IPアクセスのようなVPN型の固定IPサービスを使うと、回線を変えずに開発メンバー全員のアクセス元IPアドレスを1つに揃えられます。リソースポリシーに書くCIDRも1つで済み、入退社のたびにポリシーを触る必要がなくなります。

⇒【ロリポップ！固定IPアクセス】 月額490円（税込539円）〜、すぐに使えて最大2ヶ月間無料！

API GatewayのIP制限に関するよくある質問

自分のAPIがREST APIかHTTP APIかはどこで確認できますか？

API Gatewayのコンソールの API 一覧に、APIごとの種類（REST / HTTP / WebSocket）が表示されています。HTTP APIの場合はリソースポリシーのメニュー自体が現れません。

リソースポリシーを設定したのに制限が効きません。

APIを再デプロイしていない可能性が高いです。リソースポリシーは保存だけでは反映されません。それでも効かない場合は、IpAddress と NotIpAddress を取り違えていないか、プライベートAPIに aws:SourceIp を使っていないかを確認してください。

ステージごとに違うIP制限をかけられますか？

かけられます。リソースポリシーの Resource にステージを含めたARN形式（例：execute-api:/prod/*）を指定すれば、ステージ単位で条件を変えられます。

IP制限とAPIキーはどちらを使うべきですか？

用途が違うため、併用するのが基本です。IP制限は「どこから来たか」、APIキーやIAM認証は「誰が来たか」を確認する仕組みです。IP制限だけでは、許可されたネットワーク内の誰でもAPIを叩けてしまいます。

IPv6からのアクセスも制限できますか？

できます。aws:SourceIp はIPv6のCIDR表記も受け付けます。IPv4だけを登録していると、クライアントがIPv6で接続した場合にブロックされるため、両方を登録するか、どちらで接続されるかを確認してください。

まとめ

API GatewayのIP制限は、REST APIならリソースポリシーに NotIpAddress ＋ aws:SourceIp を書くのが標準的な方法です。設定後の再デプロイを忘れないでください。

HTTP APIはリソースポリシーもAWS WAFも使えないため、Lambdaオーソライザー・CloudFrontの前段配置・REST APIへの作り替えのいずれかを選ぶことになります。この違いを知らずに着手すると手戻りが大きくなります。

そして、許可リストに書くIPアドレスが固定されていることが大前提です。AWS関連ではCloudFrontのIP制限設定ガイド、AWSで固定IPを設定する方法もあわせてご覧ください。

⇒【ロリポップ！固定IPアクセス】 月額490円（税込539円）〜、すぐに使えて最大2ヶ月間無料！