Azure 逻辑应用的限制和配置信息Limits and configuration information for Azure Logic Apps

本文介绍使用 Azure 逻辑应用创建和运行自动化工作流的限制和配置的详细信息。This article describes the limits and configuration details for creating and running automated workflows with Azure Logic Apps. 对于 Power Automate,请参阅 Power Automate 中的限制和配置For Power Automate, see Limits and configuration in Power Automate.

定义限制Definition limits

下面是针对单个逻辑应用定义的限制:Here are the limits for a single logic app definition:

名称Name 限制Limit 注释Notes
每个工作流的操作数Actions per workflow 500500 要对此限制进行扩展,可根据需要添加嵌套工作流。To extend this limit, you can add nested workflows as needed.
操作的允许嵌套深度Allowed nesting depth for actions 88 要对此限制进行扩展,可根据需要添加嵌套工作流。To extend this limit, you can add nested workflows as needed.
每个订阅每个区域的工作流数Workflows per region per subscription 1,0001,000
每个工作流的触发数Triggers per workflow 10 个10 在代码视图中工作时,而不是在设计器中工作时When working in code view, not the designer
Switch 作用域事例限制Switch scope cases limit 2525
每个工作流的变量数Variables per workflow 250250
actiontrigger 的名称Name for action or trigger 80 个字符80 characters
每个表达式的字符数Characters per expression 8,1928,192
description 的长度Length of description 256 个字符256 characters
最大 parametersMaximum number of parameters 5050
最大 outputsMaximum number of outputs 1010
trackedProperties 的最大大小Maximum size for trackedProperties 16,000 个字符16,000 characters
内联代码操作 - 最大代码字符数Inline Code action - Maximum number of code characters 1,024 个字符1,024 characters

对于 100,000 字符限制,请使用 Visual Studio Code 创建逻辑应用。For a 100,000 character limit, create your logic apps with Visual Studio Code.

运行持续时间和保留期历史记录限制Run duration and retention history limits

下面是针对单个逻辑应用运行的限制:Here are the limits for a single logic app run:

名称Name 多租户限制Multi-tenant limit 注释Notes
运行持续时间Run duration 90 天90 days 运行持续时间是使用运行开始时间以及在开始时工作流设置“运行历史记录保留期(天)”中指定的限制计算的。Run duration is calculated by using a run's start time and the limit that's specified in the workflow setting, Run history retention in days at that start time.

若要更改默认限制,请参阅更改存储中的运行持续时间和历史记录保留期To change the default limit, see Change run duration and history retention in storage.

存储中的运行历史记录保留期Run history retention in storage 90 天90 days 当运行的持续时间超过当前运行历史记录保留期限制时,将从存储的运行历史记录中删除该运行。If a run's duration exceeds the current run history retention limit, the run is removed from the runs history in storage. 无论运行是完成还是超时,都会始终使用运行开始时间和工作流设置“运行历史记录保留期(天)”中指定的当前限制来计算运行历史记录保留期。Whether the run completes or times out, run history retention is always calculated by using the run's start time and the current limit specified in the workflow setting, Run history retention in days. 无论先前的限制如何,将始终使用当前限制来计算保留期。No matter the previous limit, the current limit is always used for calculating retention.

若要更改默认限制以及了解详细信息,请参阅存储在存储中更改持续时间和运行历史记录保留期To change the default limit and for more information, see Change duration and run history retention in storage. 若要提高最大限制,请联系逻辑应用团队,就你的要求获取帮助。To increase the maximum limit, contact the Logic Apps team for help with your requirements.

最小重复间隔Minimum recurrence interval 1 秒1 second
最大重复间隔Maximum recurrence interval 500 天500 days

更改存储中的运行持续时间和历史记录保留期Change run duration and history retention in storage

同一设置控制工作流可以运行的最大天数,并控制在存储中保留运行历史记录的最大天数。The same setting controls the maximum number of days that a workflow can run and for keeping run history in storage. 若要更改这些属性的默认值或当前限制,请执行以下步骤。To change the default or current limit for these properties, follow these steps.

  • 对于多租户 Azure 中的逻辑应用,90 天默认限制与最大限制相同。For logic apps in multi-tenant Azure, the 90-day default limit is the same as the maximum limit. 只能减小此值。You can only decrease this value.

  • 对于集成服务环境中的逻辑应用,可以降低或提高 90 天默认限制。For logic apps in an integration service environment, you can decrease or increase the 90-day default limit.

例如,假设你将保留期限制从 90 天减少到 30 天。For example, suppose that you reduce the retention limit from 90 days to 30 days. 将从运行历史记录中删除 60 天的运行。A 60-day-old run is removed from the runs history. 如果将保持期从 30 天增至 60 天,则已经保留了 20 天的运行将在运行历史记录中继续保留 40 天。If you increase the retention period from 30 days to 60 days, a 20-day-old run stays in the runs history for another 40 days.

重要

当运行的持续时间超过当前运行历史记录保留期限制时,将从存储的运行历史记录中删除该运行。If a run's duration exceeds the current run history retention limit, the run is removed from the runs history in storage. 若要避免丢失运行历史记录,请确保保留期限制始终大于运行的最长持续时间。To avoid losing run history, make sure that the retention limit is always more than the run's longest possible duration.

  1. Azure 门户搜索框中,找到并选择“逻辑应用”。In the Azure portal search box, find and select Logic apps.

  2. 找到并选择选择逻辑应用。Find and select your logic app. 在逻辑应用设计器中打开逻辑应用。Open your logic app in the Logic App Designer.

  3. 在逻辑应用的菜单中选择“工作流设置”。On the logic app's menu, select Workflow settings.

  4. 在“运行时选项”下,从“运行历史记录保留天数”列表中选择“自定义” 。Under Runtime options, from the Run history retention in days list, select Custom.

  5. 拖动滑块更改所需的天数。Drag the slider to change the number of days that you want.

  6. 完成后,在“工作流设置”工具栏上选择“保存”。 When you're done, on the Workflow settings toolbar, select Save.

如果为逻辑应用生成了 Azure 资源管理器模板,则此设置将显示为工作流资源定义中的属性,如 Microsoft.Logic 工作流模板参考中所述:If you generate an Azure Resource Manager template for your logic app, this setting appears as a property in your workflow's resource definition, which is described in the Microsoft.Logic workflows template reference:

{
   "name": "{logic-app-name}",
   "type": "Microsoft.Logic/workflows",
   "location": "{Azure-region}",
   "apiVersion": "2019-05-01",
   "properties": {
      "definition": {},
      "parameters": {},
      "runtimeConfiguration": {
         "lifetime": {
            "unit": "day",
            "count": {number-of-days}
         }
      }
   }
}

并发、循环和拆分限制Concurrency, looping, and debatching limits

下面是针对单个逻辑应用运行的限制:Here are the limits for a single logic app run:

名称Name 限制Limit 说明Notes
触发器并发Trigger concurrency - 若并发控制已关闭,则无限制- Unlimited when the concurrency control is turned off

- 在启用并发控制时,默认限制为 25(启用并发后无法撤消)。- 25 is the default limit when the concurrency control is turned on, which you can't undo after you enable concurrency. 可以将默认值更改为介于 1 与 50(含)之间的值。You can change the default to a value between 1 and 50 inclusively.

此限制描述可以在同一时间或并行运行的逻辑应用实例的最大数。This limit describes the highest number of logic app instances that can run at the same time, or in parallel.

注意:启用并发后,解除数组批处理的 SplitOn 限制会降低到 100 个项。Note: When concurrency is turned on, the SplitOn limit is reduced to 100 items for debatching arrays.

若要将默认限制更改为介于 1 到 50 之间(含)的值,请参阅更改触发器并发限制按顺序触发实例To change the default limit to a value between 1 and 50 inclusively, see Change trigger concurrency limit or Trigger instances sequentially.

最大等待运行数Maximum waiting runs - 未启用并发时,最小等待运行数是 1,最大数目是 50。- Without concurrency, the minimum number of waiting runs is 1, while the maximum number is 50.

- 启用并发时,最小等待运行数是 10 加上并发运行(触发器并发)数。- With concurrency, the minimum number of waiting runs is 10 plus the number of concurrent runs (trigger concurrency). 可以将最大数更改为多达 100 个(含)。You can change the maximum number up to 100 inclusively.

此限制描述当逻辑应用已在运行最大数量并发实例时,可等待运行的最大逻辑应用实例数。This limit describes the highest number of logic app instances that can wait to run when your logic app is already running the maximum concurrent instances.

若要更改此默认限制,请参阅更改等待的运行限制To change the default limit, see Change waiting runs limit.

Foreach 数组项Foreach array items 100,000100,000 此限制描述“for each”循环可以处理的最大数组项数。This limit describes the highest number of array items that a "for each" loop can process.

可以使用查询操作筛选更大数组。To filter larger arrays, you can use the query action.

Foreach 并发Foreach concurrency 20 是并发控制关闭时的默认限制。20 is the default limit when the concurrency control is turned off. 可以将默认值更改为介于 1 与 50(含)之间的值。You can change the default to a value between 1 and 50 inclusively. 此限制是可同时或并行运行的最大“for each”循环迭代数。This limit is highest number of "for each" loop iterations that can run at the same time, or in parallel.

若要将默认限制更改为介于 1 到 50 之间(含)的值,请参阅更改“for each”并发限制按顺序运行“for each”循环To change the default limit to a value between 1 and 50 inclusively, see Change "for each" concurrency limit or Run "for each" loops sequentially.

SplitOn 项SplitOn items - 未启用触发器并发时为 100,000- 100,000 without trigger concurrency

- 启用触发器并发时为 100- 100 with trigger concurrency

对于返回数组的触发器,可指定一个表达式,它使用将数组项拆分或解除批处理到多个工作流实例进行处理的“SplitOn”属性,而不是使用“Foreach”循环。For triggers that return an array, you can specify an expression that uses a 'SplitOn' property that splits or debatches array items into multiple workflow instances for processing, rather than use a "Foreach" loop. 此表达式引用要用于为每个数组项创建和运行工作流实例的数组。This expression references the array to use for creating and running a workflow instance for each array item.

注意:启用并发后,SplitOn 限制会降低到 100 个项。Note: When concurrency is turned on, the SplitOn limit is reduced to 100 items.

Until 迭代Until iterations - 默认值:60- Default: 60

- 最大值:5,000- Maximum: 5,000

吞吐量限制Throughput limits

下面是针对单个逻辑应用定义的限制:Here are the limits for a single logic app definition:

多租户逻辑应用服务Multi-tenant Logic Apps service

名称Name 限制Limit 说明Notes
操作:每 5 分钟执行的次数Action: Executions per 5 minutes 默认限制为 100,000,最大限制为 300,000。100,000 is the default limit, but 300,000 is the maximum limit. 若要更改此默认限制,请参阅处于预览阶段的在“高吞吐量”模式下运行逻辑应用To change the default limit, see Run your logic app in "high throughput" mode, which is in preview. 或者,你可根据需要在多个逻辑应用之间分配工作负荷。Or, you can distribute the workload across more than one logic app as necessary.
操作:并发出站调用Action: Concurrent outbound calls ~2,500~2,500 你可减少并发请求数,或根据需要减少持续时间。You can reduce the number of concurrent requests or reduce the duration as necessary.
运行时终结点:并发入站调用Runtime endpoint: Concurrent inbound calls ~1,000~1,000 你可减少并发请求数,或根据需要减少持续时间。You can reduce the number of concurrent requests or reduce the duration as necessary.
运行时终结点:每 5 分钟读取调用Runtime endpoint: Read calls per 5 minutes 60,00060,000 此限制适用于从逻辑应用的运行历史记录获取原始输入和输出的调用。This limit applies to calls that get the raw inputs and outputs from a logic app's run history. 可根据需要在多个应用中分发工作负荷。You can distribute the workload across more than one app as necessary.
运行时终结点:每 5 分钟调用调用Runtime endpoint: Invoke calls per 5 minutes 45,00045,000 可根据需要在多个应用中分发工作负荷。You can distribute workload across more than one app as necessary.
每 5 分钟的内容吞吐量Content throughput per 5 minutes 600 MB600 MB 可根据需要在多个应用中分发工作负荷。You can distribute workload across more than one app as necessary.

网关限制Gateway limits

Azure 逻辑应用支持通过网关执行写入操作(包括插入和更新)。Azure Logic Apps supports write operations, including inserts and updates, through the gateway. 但是,这些操作存在有效负载大小限制However, these operations have limits on their payload size.

HTTP 限制HTTP limits

下面是单个传出或传入 HTTP 调用的限制:Here are the limits for a single outgoing or incoming HTTP call:

超时Timeout

某些连接器操作会进行异步调用或侦听 Webhook 请求,因此,这些操作的超时时间可能会长于以下限制。Some connector operations make asynchronous calls or listen for webhook requests, so the timeout for these operations might be longer than these limits. 有关详细信息,请参阅特定连接器的技术详细信息以及工作流触发器和操作For more information, see the technical details for the specific connector and also Workflow triggers and actions.

名称Name 多租户限制Multi-tenant limit 注释Notes
出站请求Outbound request 120 秒120 seconds
(2 分钟)(2 minutes)
出站请求的示例包括 HTTP 触发器进行的调用。Examples of outbound requests include calls made by HTTP triggers.

提示:对于运行时间较长的操作,请使用 异步轮询模式until 循环Tip: For longer running operations, use an asynchronous polling pattern or an until loop. 在调用其他具有可调用终结点的逻辑应用时,若要绕过超时限制,可改用内置的 Azure 逻辑应用操作(可在“内置”下的连接器连接器中找到)。To work around timeout limits when you call another logic app that has a callable endpoint, you can use the built-in Azure Logic Apps action instead, which you can find in the connector picker under Built-in.

入站请求Inbound request 120 秒120 seconds
(2 分钟)(2 minutes)
入站请求的示例包括请求触发器和 webhook 触发器收到的请求。Examples of inbound requests include calls received by request triggers and webhook triggers.

注意:要使原始调用方能够获得响应,则除非以嵌套工作流的形式调用其他逻辑应用,否则必须在限制内完成响应的所有步骤。Note: For the original caller to get the response, all steps in the response must finish within the limit unless you call another logic app as a nested workflow. 有关详细信息,请参阅调用、触发器或嵌套逻辑应用For more information, see Call, trigger, or nest logic apps.

消息大小Message size

名称Name 多租户限制Multi-tenant limit 注释Notes
消息大小Message size 100 MB100 MB 若要解决此限制问题,请参阅使用分块处理大型消息To work around this limit, see Handle large messages with chunking. 但是,某些连接器和 API 可能不支持分块,甚至不支持默认限制。However, some connectors and APIs might not support chunking or even the default limit.

- 连接器(如 AS2、X12 和 EDIFACT)具有自己的 B2B 消息限制- Connectors such as AS2, X12, and EDIFACT have their own B2B message limits.

使用分块的消息大小Message size with chunking 1 GB1 GB 此限制适用于本机支持分块或可以在其运行时配置中启用分块的操作。This limit applies to actions that either natively support chunking or let you enable chunking in their runtime configuration.

有关分块的详细信息,请参阅使用分块处理大型消息For more information about chunking, see Handle large messages with chunking.

字符限制Character limits

名称Name 说明Notes
表达式计算限制Expression evaluation limit 131,072 个字符131,072 characters @concat()@base64()@string() 表达式的长度不能超过此限制。The @concat(), @base64(), @string() expressions can't be longer than this limit.
请求 URL 字符限制Request URL character limit 16,384 个字符16,384 characters

重试策略Retry policy

名称Name 限制Limit 说明Notes
重试次数Retry attempts 9090 默认值为 4。The default is 4. 若要更改默认值,请使用重试策略参数To change the default, use the retry policy parameter.
重试最大延迟Retry max delay 1 天1 day 若要更改默认值,请使用重试策略参数To change the default, use the retry policy parameter.
重试最小延迟Retry min delay 5 秒5 seconds 若要更改默认值,请使用重试策略参数To change the default, use the retry policy parameter.

身份验证限制Authentication limits

如果逻辑应用从使用请求触发器开始,并启用 Azure Active Directory 开放式身份验证 (Azure AD OAuth) 来授权对请求触发器的入站调用,则应遵循以下限制:Here are the limits for a logic app that starts with a Request trigger and enables Azure Active Directory Open Authentication (Azure AD OAuth) for authorizing inbound calls to the Request trigger:

名称Name 限制Limit 说明Notes
Azure AD 授权策略Azure AD authorization policies 55
每个授权策略的声明Claims per authorization policy 1010

自定义连接器限制Custom connector limits

下面介绍对可通过 Web API 创建的自定义连接器的限制。Here are the limits for custom connectors that you can create from web APIs.

名称Name 多租户限制Multi-tenant limit 注释Notes
自定义连接器数Number of custom connectors 每个 Azure 订阅 1,0001,000 per Azure subscription
自定义连接器的每分钟请求数Number of requests per minute for a custom connector 每分钟每个连接 500 个请求500 requests per minute per connection

托管标识Managed identities

名称Name 限制Limit
每个逻辑应用的托管标识Managed identities per logic app 系统分配的标识或 1 个用户分配的标识Either the system-assigned identity or 1 user-assigned identity
每个区域的每个 Azure 订阅中具有托管标识的逻辑应用数量Number of logic apps that have a managed identity in an Azure subscription per region 1,0001,000

每个集成帐户的项目限制Artifact limits per integration account

下面介绍对每个集成帐户层的项目数量限制。Here are the limits on the number of artifacts for each integration account tier. 有关定价费率,请参阅逻辑应用定价For pricing rates, see Logic Apps pricing. 若要了解集成帐户的定价和计费工作原理,请参阅逻辑应用定价模型To learn how pricing and billing work for integration accounts, see the Logic Apps pricing model.

备注

免费层仅用于探索场景,不用于生产场景。Use the Free tier only for exploratory scenarios, not production scenarios. 此层限制吞吐量和使用情况,并且不具有服务级别协议 (SLA)。This tier restricts throughput and usage, and has no service-level agreement (SLA).

项目Artifact 免费Free 基本Basic StandardStandard
EDI 贸易协议EDI trading agreements 1010 11 1,0001,000
EDI 参与方EDI trading partners 2525 22 1,0001,000
地图Maps 2525 500500 1,0001,000
架构Schemas 2525 500500 1,0001,000
程序集Assemblies 1010 2525 1,0001,000
证书Certificates 2525 22 1,0001,000
批处理配置Batch configurations 55 11 5050

项目容量限制Artifact capacity limits

项目Artifact 限制Limit 说明Notes
AssemblyAssembly 8 MB8 MB 若要上传大于 2 MB 的文件,请使用 Azure 存储帐户和 blob 容器To upload files larger than 2 MB, use an Azure storage account and blob container.
映射(XSLT 文件)Map (XSLT file) 8 MB8 MB 若要上传大于 2 MB 的文件,请使用 Azure 逻辑应用 REST API - 映射To upload files larger than 2 MB, use the Azure Logic Apps REST API - Maps.

注意:映射可以成功处理的数据或记录量取决于 Azure 逻辑应用中的消息大小和操作超时限制。Note: The amount of data or records that a map can successfully process is based on the message size and action timeout limits in Azure Logic Apps. 例如,如果使用 HTTP 操作,则根据 HTTP 消息大小和超时限制,在操作能够在 HTTP 超时限制内完成的情况下,映射最多可以处理达到 HTTP 消息大小限制的数据量。For example, if you use an HTTP action, based on HTTP message size and timeout limits, a map can process data up to the HTTP message size limit if the operation completes within the HTTP timeout limit.

架构Schema 8 MB8 MB 若要上传大于 2 MB 的文件,请使用 Azure 存储帐户和 blob 容器To upload files larger than 2 MB, use an Azure storage account and blob container.

吞吐量限制Throughput limits

运行时终结点Runtime endpoint 基本Basic StandardStandard 说明Notes
每 5 分钟读取调用Read calls per 5 minutes 30,00030,000 60,00060,000 此限制适用于从逻辑应用的运行历史记录获取原始输入和输出的调用。This limit applies to calls that get the raw inputs and outputs from a logic app's run history. 你可根据需要在多个帐户之间分配工作负荷。You can distribute the workload across more than one account as necessary.
每 5 分钟调用调用Invoke calls per 5 minutes 30,00030,000 45,00045,000 你可根据需要在多个帐户之间分配工作负荷。You can distribute the workload across more than one account as necessary.
每 5 分钟跟踪调用Tracking calls per 5 minutes 30,00030,000 45,00045,000 你可根据需要在多个帐户之间分配工作负荷。You can distribute the workload across more than one account as necessary.
阻止并发调用Blocking concurrent calls ~1,000~1,000 ~1,000~1,000 对于所有 SKU 均相同。Same for all SKUs. 你可减少并发请求数,或根据需要减少持续时间。You can reduce the number of concurrent requests or reduce the duration as necessary.

B2B 协议(AS2、X12、EDIFACT)消息大小B2B protocol (AS2, X12, EDIFACT) message size

以下消息大小限制适用于 B2B 协议:Here are the message size limits that apply to B2B protocols:

名称Name 多租户限制Multi-tenant limit 注释Notes
AS2AS2 v2 - 100 MBv2 - 100 MB
v1 - 25 MBv1 - 25 MB
适用于解码和编码Applies to decode and encode
X12X12 50 MB50 MB 适用于解码和编码Applies to decode and encode
EDIFACTEDIFACT 50 MB50 MB 适用于解码和编码Applies to decode and encode

禁用或删除逻辑应用Disabling or deleting logic apps

禁用逻辑应用后,任何新运行都不会实例化。When you disable a logic app, no new runs are instantiated. 所有正在进行的和挂起的运行将继续进行,直到完成,这可能要花费一些时间才能完成。All in-progress and pending runs continue until they finish, which might take time to complete.

删除逻辑应用后,任何新运行都不会实例化。When you delete a logic app, no new runs are instantiated. 所有正在进行和挂起的运行都将取消。All in-progress and pending runs are canceled. 如果有成千上万个运行,取消操作可能需要很长时间才能完成。If you have thousands of runs, cancellation might take significant time to complete.

防火墙配置:IP 地址和服务标记Firewall configuration: IP addresses and service tags

Azure 逻辑应用用于传入和传出调用的 IP 地址由逻辑应用所在的区域决定。The IP addresses that Azure Logic Apps uses for incoming and outgoing calls depend on the region where your logic app exists. 同一区域中的所有逻辑应用都使用相同的 IP 地址范围。All logic apps in the same region use the same IP address ranges. 某些 Power Automate 调用(例如 HTTP 和 HTTP + OpenAPI 请求)直接通过 Azure 逻辑应用服务执行并来自此处列出的 IP 地址。Some Power Automate calls, such as HTTP and HTTP + OpenAPI requests, go directly through the Azure Logic Apps service and come from the IP addresses that are listed here. 要详细了解 Power Automate 使用的 IP 地址,请参阅 Power Automate 中的限制和配置For more information about IP addresses used by Power Automate, see Limits and configuration in Power Automate.

提示

为帮助你更简单地创建安全规则,可选择性地使用服务标记,而不是为每个区域指定逻辑应用 IP 地址,如此部分中稍后所述。To help reduce complexity when you create security rules, you can optionally use service tags, rather than specify the Logic Apps IP addresses for each region, described later in this section. 这些标记适用于可使用逻辑应用服务的区域:These tags work across the regions where the Logic Apps service is available:

  • LogicAppsManagement:表示逻辑应用服务的入站 IP 地址前缀。LogicAppsManagement: Represents the inbound IP address prefixes for the Logic Apps service.
  • LogicApps:表示逻辑应用服务的出站 IP 地址前缀。LogicApps: Represents the outbound IP address prefixes for the Logic Apps service.
  • 对于 Azure 中国世纪互联,固定或保留 IP 地址不可用于自定义连接器托管连接器(例如,Azure 存储、SQL Server、Office 365 Outlook 等)。For Azure China 21Vianet, fixed or reserved IP addresses are unavailable for custom connectors and managed connectors, for example, Azure Storage, SQL Server, Office 365 Outlook, and so on.

  • 若要支持逻辑应用通过 HTTPHTTP + Swagger 和其他 HTTP 请求直接发出的调用,请根据逻辑应用所在的区域,使用逻辑应用服务所用的所有入站出站 IP 地址对防火墙进行设置。To support the calls that your logic apps directly make with HTTP, HTTP + Swagger, and other HTTP requests, set up your firewall with all the inbound and outbound IP addresses that are used by the Logic Apps service, based on the regions where your logic apps exist. 这些地址显示在本部分的“入站”和“出站”标题下,并按区域进行排序。These addresses appear under the Inbound and Outbound headings in this section, and are sorted by region.

  • 若要支持托管连接器发出的调用,请根据逻辑应用所在的区域,使用这些连接器所用的全部出站 IP 地址对防火墙进行设置。To support the calls that managed connectors make, set up your firewall with all the outbound IP addresses used by these connectors, based on the regions where your logic apps exist. 这些地址显示在本部分的“出站”标题下,并按区域进行排序。These addresses appear under the Outbound heading in this section, and are sorted by region.

  • 如果逻辑应用无法访问使用防火墙和防火墙规则的 Azure 存储帐户,则可通过各种选项来启用访问权限If your logic apps have problems accessing Azure storage accounts that use firewalls and firewall rules, you have various options to enable access.

    例如,逻辑应用不能直接访问使用防火墙规则的存储帐户,因此存在于同一区域中。For example, logic apps can't directly access storage accounts that use firewall rules and exist in the same region. 但是,如果允许区域中托管连接器的出站 IP 地址,则逻辑应用可以访问其他区域中的存储帐户,除非你使用 Azure 表存储或 Azure 队列存储连接器。However, if you permit the outbound IP addresses for managed connectors in your region, your logic apps can access storage accounts that are in a different region except when you use the Azure Table Storage or Azure Queue Storage connectors. 若要访问表存储或队列存储,则可改用 HTTP 触发器和操作。To access your Table Storage or Queue Storage, you can use the HTTP trigger and actions instead. 有关其他选项,请参阅访问防火墙后的存储帐户For other options, see Access storage accounts behind firewalls.

后续步骤Next steps