External Access Integration：Snowpark/UDFから外部サービスを安全に呼ぶ

SnowflakeのUDFやストアドプロシージャから、SaaSのREST APIや自社のAWSサービスを直接呼びたい——そんな要求に応えるのがExternal Access Integrationです。かつてはExternal Functionsで、API GatewayとLambdaによるプロキシを立てる必要がありましたが、いまはSnowpark（Python/Java/Scala）のハンドラコードから、統制付きで外部HTTPSを出せます。本稿では、Network Rule・Secret・外部アクセス統合という構成要素と、その裏側にある「どこへ出てよいか」を厳密に絞るセキュリティ境界の考え方、そしてAWS PrivateLinkとの接続や従来のExternal Functionsとの使い分けを、現場の設計視点で整理します。

01UDFから外部を呼びたい、その「安全な標準」

Snowflakeは本来、データを内側で完結して処理する閉じた環境です。しかし実務では、UDFやストアドプロシージャから外部サービスを叩きたい場面が頻繁に出てきます。住所の正規化や翻訳、外部スコアリングAPIの呼び出し、SaaSからの参照データ取得などです。従来これはExternal Functionsで実現していましたが、Amazon API GatewayとLambdaでプロキシ層を組む必要があり、準備の手間とホップの多さが課題でした。External Access Integrationは、この外部HTTPSアクセスを、Snowparkのハンドラコードから直接、かつ統制付きで行うための仕組みです。AWS上のアカウントでも一般提供されています。

ここで最も大事な前提は、「無制限に外へ出られるわけではない」という点です。どこへ出てよいか（Network Rule）とどの資格情報を使えるか（Secret）を明示的に許可した範囲だけegress（外向き通信）でき、それ以外は既定で拒否されます。いわゆるdeny-by-defaultの設計であり、この思想を理解しないまま機能だけを使うと、統制の緩い抜け道を作りかねません。

024つの構成要素 — Network Rule / Secret / 統合 / UDF

External Access Integrationは、単一のオブジェクトではなく、役割の異なる4つのオブジェクトの組み合わせで成立します。Network RuleはCREATE NETWORK RULEで作り、MODE = EGRESS、TYPE = HOST_PORT、VALUE_LISTに許可する宛先（FQDNとポート、省略時は443）を列挙する「出口の許可リスト」です。SecretはCREATE SECRETで作り、TYPE = GENERIC_STRING（APIキー）、PASSWORD（ユーザー名＋パスワード）、OAUTH2（セキュリティ統合と連携）などの型で、資格情報をコードに書かずSnowflake側に暗号化して保管します。

External Access IntegrationはCREATE EXTERNAL ACCESS INTEGRATIONで作り、ALLOWED_NETWORK_RULESとALLOWED_AUTHENTICATION_SECRETSに上記を束ね、ENABLED = TRUEで有効化する「ゲート」です。作成にはアカウントレベルのCREATE INTEGRATION権限（実務上はACCOUNTADMIN系ロール）が必要です。最後にUDF/手続き側で、CREATE FUNCTION／CREATE PROCEDUREにEXTERNAL_ACCESS_INTEGRATIONS = (...)とSECRETS = ('cred' = my_secret)を指定して初めて、ハンドラが外部へ出られるようになります。

03セットアップの流れとハンドラ側の作法

実装順序はシンプルです。(1) Network Ruleを作成し出口を定義、(2) Secretを作成し資格情報を保管、(3) External Access Integrationで両者をALLOWED_NETWORK_RULES・ALLOWED_AUTHENTICATION_SECRETSに列挙して有効化、(4) UDF/手続きでEXTERNAL_ACCESS_INTEGRATIONSとSECRETSを指定、という流れです。対応ハンドラ言語はPython・Java・Scalaで、コードはSnowparkのサンドボックス内で実行されます。

ハンドラ内で資格情報を取り出すには、Pythonなら_snowflakeモジュールのヘルパを使います。APIキーならget_generic_secret_string('cred')、ベーシック認証ならget_username_password('cred')、OAuth2ならget_oauth_access_token('cred')といった具合です。ここで渡すラベル（'cred'）は、SECRETS = ('cred' = my_secret)で束ねたラベルと一致させる必要があります。資格情報が平文でコードに現れないこの仕組みは、AWSでいうSecrets Managerからの動的取得と同じ発想です。

04セキュリティ境界の考え方 — 二重の許可とdeny-by-default

この機能の統制は「二重の許可」で成り立ちます。あるSecretやNetwork Ruleは、Integrationに列挙され、かつUDF側のEXTERNAL_ACCESS_INTEGRATIONS／SECRETSにも指定されて初めて使えます。片方だけでは実行時エラーになります。そしてハンドラがどこへ出られるかはNetwork Ruleが厳密に規定し、allowlist外の宛先は既定で拒否されます。サンドボックス内のコードが勝手に任意のホストへ接続することはできません。

AWSの統制モデルに引き付ければ、SecretはSecrets Managerの役割、Network RuleはセキュリティグループのegressルールやVPCエンドポイントポリシーに近い発想です。Secretの保管は暗号化され、Business Critical Edition以上ではTri-Secret Secure（顧客管理のKMS鍵を含む鍵階層）で保護できます。IAMの最小権限と同様に、IntegrationとSecretの所有権やGRANT USAGEの付与先を絞り込むことが、実質的なアクセス制御になります。

05AWSとの接続 — PrivateLink・API Gateway・Bedrock

外部先が自社のAWSサービス（API GatewayやLambda）や、AWSのAPIエンドポイントである場合、egressを公衆インターネットに出さずAWS PrivateLink経由に閉じられます。Network RuleのTYPEをPRIVATE_HOST_PORTにし、プライベート接続用のホスト・ポートを指定します。ただしこのプライベート接続はBusiness Critical Edition（以上）が条件となる点に注意が必要です。データを外に出さない統制要件が厳しい案件では、この構成が要になります。

用途としては、自社Lambdaのロジックを呼ぶ、API Gateway越しに社内APIへ問い合わせる、あるいはAmazon Bedrockのランタイムエンドポイントを呼んで特定モデルの推論を得る、といった橋渡しが考えられます。AWSのAPIを直接叩く場合は、ハンドラ側でSigV4署名を行い、鍵はSecretやget_cloud_provider_tokenで受け取ります。なお生成AI用途では、まずSnowflake管理のCortex系機能で要件を満たせないかを先に検討し、専用モデルや自社ロジックが不可欠なときにExternal Accessで外へ橋渡しするのが、統制とコストの両面で無難です。

06External Functionsとの使い分け

External FunctionsとExternal Access Integrationは、似て非なるものです。External Functionsは、Snowflakeがリモートサービスを直接呼ばず、API統合を介してAmazon API Gateway（多くの場合その先のLambda）というプロキシを経由します。ホップが多くレイテンシと運用点が増える一方、AWS側でIAM署名・入力変換・スロットリング・追加認可を挟みたい場合や、すでに構築済みの資産がある場合には依然として有効です。

対してExternal Access Integrationは、Snowparkのハンドラから統制ゲートを通して直接HTTPSを出すため、経路が短く運用点も少なくて済みます。判断軸はシンプルで、AWS側のプロキシで前処理や認可を明示的に挟みたいならExternal Functions、Snowpark内で処理を完結させたいならExternal Access Integration、という切り分けになります。新規設計では後者を基本に据え、プロキシが必要な要件だけExternal Functionsを併用するのが実務的です。

07検証で先に踏んでおいた落とし穴

外部呼び出し系は、単体テストでは見えないコストや統制の穴が、本番規模で初めて顕在化しがちです。私たちはPoC・検証段階で意図的にこれらを踏み抜き、本番投入前に設計へ織り込むようにしています。まずコスト面では、検証環境で、スカラUDFから1行ごとに外部HTTPを呼ぶ実装にすると、行数ぶんの往復でウェアハウス稼働時間が伸び、想定外にクレジットを消費すると分かりました。本番ではベクトル化UDFやバッチ集約で呼び出し回数を圧縮し、タイムアウトとリトライも併せて設計しました。

統制面では、検証段階でNetwork RuleのVALUE_LISTを面倒がって広めに列挙すると、意図しないホストへegressできる状態になると確認できたため、本番では必要最小限のFQDNだけを列挙し、変更をレビュー対象に組み込みました。また、PrivateLink（PRIVATE_HOST_PORT）がBusiness Critical Edition必須であることも検証で先に判明したため、本番設計に入る前にエディション要件を確定させ、手戻りを防ぎました。SecretをIntegrationのALLOWED句やUDFのSECRETS句に紐づけ忘れると実行時エラーになる点も、デプロイ手順のチェックに落とし込み、本番前に必ず検知できるようにしています。

—まとめ

External Access Integrationは、SnowparkのUDF/手続きから外部サービスへ安全に接続するための標準的な仕組みです。要点は、Network Rule・Secret・外部アクセス統合・UDFという4要素で「どこへ出てよいか」「どの資格情報を使えるか」を明示し、それ以外は既定で拒否するdeny-by-defaultの境界設計にあります。AWS上のアカウントでは、PrivateLink（PRIVATE_HOST_PORT、Business Critical以上）でegressを内側に閉じ、API Gateway・Lambda・Bedrockといった資産と橋渡しできます。プロキシで前処理を挟みたい要件はExternal Functionsと使い分け、コストとallowlistの想定は検証段階で先に踏んでおく——この設計規律が、外部連携を安全に運用する近道です。