Preface
In Part 1 we discussed the Azure Integration Services stack, its benefits and considerations. In Part 2 we will continue on the enterprise considerations for implementing Azure Integration Services.
The Next sections discuss about the application components and services that make integrations work.
Azure integration Services Considerations
We explored the ingress (incoming traffic) consideration in Part 1; now we will check the considerations for Application and Egress (Outgoing traffic) layers.
Application / Workflow considerations
The application/workflow layer allows you to create and manage business logics and workflows. This provides ability to add custom logic in place to implement a series of actions to be taken before sending a response.
- Disable public access to Logic/Function Apps, Service Bus, Storage Account etc. for security.
- Use Private Endpoints to make the applications (Logic/Function Apps) accessible within the VNET and for traffic originating from APIM.
- Requirement for 5 private endpoints per app ( 1 for the function/logic app, 4 for application blob, queue, file and table storage).
- All 4 storage types (blob, queue, file and table storage) are mandatory for Logic Apps. For function apps usually 2 (blob and file storage) are enough.
- Private DNS is needed to resolve private endpoints internally.
- Enable Managed Identity for Role Based Access Control (RBAC) instead of access keys for resources.
- Implement NSG rules that allow only traffic originating from APIM subnet and Build Agents on the Application
- Logic Apps provide 2 type of connectors (Built In and Managed Connectors).
- Managed connectors require external resources (an API connection resource is also created) and may connect to public cloud.
- Built-In Connectors leverage Native Azure capabilities and don’t need provisioning of external resources.
AIS Infrastructure Design
Azure Integration Services
