Azure Services Configuration

In this section, you will find documentation on how to configure and deploy specific Azure services in a way that is compatible with the TAMU-managed network design and meets the requirements outlined in the Network Design page.

A pre-requisite for deploying resources to the TAMU-managed network in Azure is understanding the network design and creating the necessary subnets in your spoke VNets. See the Network Design and Creating Subnets pages.

Scope

In-Scope Services

A service is generally required to be connected to the TAMU-managed network if it is a workload-hosting, compute, or application-facing Azure service that either:

  • Is accessible from the public internet,
  • Can initiate outbound network connections,
  • Runs customer-controlled code, scripts, containers, or jobs,
  • Provides interactive access to an execution environment, or
  • Is deployed into, or integrated with, a customer-managed virtual network.

The following is a non-exhaustive list of common Azure services that are in scope for this network policy:

ServiceDocumentation
Azure App ServiceConnect App Service to the TAMU network
Azure Application GatewaysConnect App Gateway to the TAMU network
Bastion HostsUse Bastion with the TAMU network
Azure Container AppsConnect Container Apps to the TAMU network
Azure Container InstancesConnect Container Instances to the TAMU network
Azure FunctionsConnect Functions to the TAMU network
Azure Kubernetes Service (AKS)Connect AKS to the TAMU network
Azure Load BalancersConnect a load balancer to the TAMU network
Azure Virtual MachinesConnect a VM to the TAMU network

Tip

Missing connection docs for your service? Contact the Cloud Services team to request documentation for connecting your service to the TAMU-managed network. Or, if you have already figured it out, contribute your documentation and share it with the team!

Out-of-Scope Services

Some Azure services may not be directly subject to this policy if they do not host customer code, do not expose a workload endpoint, and do not initiate customer-controlled network traffic. However, they may still require review if they need to be publicly accessible or connect to in-scope workloads.

Examples that may require separate evaluation include:

  • Storage accounts
  • Key Vaults
  • Azure SQL Database
  • Cosmos DB
  • Event Hubs
  • Service Bus
  • Log Analytics workspaces
  • Managed identity and Azure control-plane services
  • Azure DevOps and GitHub-hosted agents
  • Azure AI services (e.g., Azure OpenAI, Cognitive Services)
  • Azure Data Factory and Synapse Analytics
  • Azure Logic Apps and Power Automate
  • Azure Monitor and Application Insights

Always evaluate the specific requirements and risks of each service in the context of your overall architecture and security posture, and consult with the Cloud Services team if you have any questions about whether a particular service is in scope or how to configure it appropriately.