初めに

お久しぶりです。ぼちぼちブログ投稿を再開していきたいと思います。今回は、LogicApps(Standard)からコネクタを使用してTableStorageへアクセスができないトラブルにハマっていました。私の知見不足が原因で、その点についてSRへ確認しましたのでその情報をここで共有できればと思います。

今回の構成は？

以下、プライベート通信を想定した構成となっています。

■ LogicAppsの構成

Standard構成
Vnet統合
割当てロール（ストレージアカウント共同作成者、ストレージテーブルデータ共同作成者）

■ StorageAccountの構成

ファイアーウォールは有効
プライベートエンドポイントを作成
「信頼されたサービスの一覧」からの通信を許可

どんなエラーが発生したか

状況：ロジックアプリ (Standard)でAzureTableStorageのコネクタの使用時に、テーブルの選択でエラーが表示される。同じ手順で、ロジックアプリ(従量課金)使用時にはエラーは発生しない。
使用したコネクタ：Azure Table Storage(エンティティの取得 (V2))
エラー内容：以下

Error executing the API - https://management.azure.com/subscriptions/(サブスクリプションID)/resourceGroups/(リソースグループ名)/providers/Microsoft.Web/sites/(LogicApps名)/hostruntime/runtime/webhooks/workflow/api/management/dynamicInvoke 詳細な診断情報: x-ms-client-request-id は 'XXXXXX'です。

解消方法

組み込み (built-in) コネクタの [Azure Table Storage] コネクタを使用することで回避可能。
設定方法については以下参考にしてください
MS公式ブログ | built-in (組み込み) タイプのコネクタを利用する

参考資料では「アプリ内」と記載されていますが私の環境では「In-app」と記載されていました。

なぜエラーが発生したのか

コネクタには主に「built-inタイプのコネクタ」と「Azureコネクタ」の２種類があります。プライベートネットワークでの通信を使用してリソースへアクセスする際は、コネクタの選択に注意する必要があります。各コネクタの特徴を以下にまとめておきます。

built-inタイプのコネクタ：今回の前提のように、Vnet統合を使用して実行する場合はプライベートネットワーク経由でTableStorage等のリソースにアクセスをする場合に使用。種類がAzureコネクタと比較して少ないので注意
Azureコネクタ：パブリック経由での通信を行うLogicAppsの構成をとる場合はを使用可能。種類が豊富

それぞれのコネクタの実行環境の違いが、根本の要因です。
以下各コネクタを使用した通信時のイメージ図になります。

(青線)built-inコネクタはAzureLogicAppsホストランタイムと同じ環境で実行されます。そのため、プライベートネットワーク経由での通信が可能です。
(緑線)Azureコネクタは共有環境で実行されます。そのため、マネージドコネクタの送信IPアドレスを介してパブリックネットワーク経由で通信が必要です。

なぜ従量課金プランでは通信できたのか

従量課金プランのLogicAppsからパブリックネットワーク経由でアクセスしていたTableStorageへの通信は、StorageAccountの以下ネットワーク設定によってスルーされており通信ができていました。

「信頼されたサービスの一覧」からの通信を許可

従量課金プランでは「Microsoft.Logic」というリソースタイプで通信をします。このリソースタイプは「信頼されたサービスの一覧」に含まれます。一方でStandardプランの場合は、「Microsoft.Web」というリソースタイプで通信をしますが、こちらは「信頼されたサービスの一覧」には含まれておらず、StorageAccountのファイアーウォールで拒否された形となっておりました。

まとめ

Vnet統合を使用しているLogicAppsについては、基本的にbuilt-Inコネクタを使用しましょうという学びとなりました。また、Standard構成は基盤としてWebappsが動いているということが今回のリソースタイプの一件で良く伝わったかと思います。

参考文献

MSLearn | Azure Logic Apps (Standard) での組み込み操作と Azure コネクタの違い