When we start with Microsoft Foundry, the portal can create a project and a Foundry resource for us with basic default settings. This is a good way to try Foundry in a lab. For a team or a company environment, an Azure administrator should first decide how the resource will be accessed and what network the workloads will use.

In this post, I will create the Foundry resource from the Azure portal, review the network choices, and then create a project. I will not deploy a model or build an agent. The aim is to understand the setup choices before the team starts using Foundry.

Resource and project

Think of the Foundry resource as the parent. It can contain one or more projects. A project keeps the work for one task or team together. Some settings, such as connections and network controls, are managed at the resource level and can affect its projects.

Storage, Key Vault, and Azure AI Search are separate Azure resources. They have their own permissions and network settings. Creating a Foundry resource does not automatically make those services private.

Before we start

You need an active Azure subscription and permission to create a Foundry resource. Foundry Account Owner or Foundry Owner are examples of roles that can allow resource creation at subscription or resource group scope. If you are setting this up for a team, you also need permission to assign roles, such as Owner.

Before opening the portal, decide which users or services need access, whether the Foundry endpoint should be public or private, and whether future agent workloads need to use a virtual network. Some network choices affect how the resource is created, so check your organization’s requirements first.

Choose the inbound access

Inbound access means how users and tools connect to the Foundry resource. The Azure portal provides these main choices:

• All networks: The public endpoint can be reached over the internet. Users still need to sign in and have the right permissions. This is the simplest option for a personal lab, but it does not restrict access by network.
• Selected networks: Allow only selected IP addresses or virtual networks to reach the public endpoint. This is useful when your team has known network ranges.
• Disabled: Block public network access. Users connect through a private endpoint in a virtual network. You also need working private DNS and a network path from the user’s machine to that virtual network, for example through VPN or ExpressRoute.

Choose the outbound network for agents

Outbound access is a separate decision. It controls how agent workloads reach data and other services. If this first resource will only be used to explore the portal, you might not need outbound network injection yet. If your agents must reach private services, plan this before creating the resource.

• No VNet injection: The agent workload does not use a subnet in your virtual network. This is the simplest setup, but it does not put agent traffic inside your own network boundary.
• Your own virtual network (VNet injection): Agent traffic is injected into a subnet that you manage. This gives your network team control over routes and access to private services. The subnet must be delegated to Microsoft.App/environments and be /27 or larger. You also need to plan the required Storage, Azure AI Search, and Cosmos DB resources for the Standard Agent setup. Their private endpoints are created separately.
• Managed virtual network: Microsoft manages the network for agent traffic. You can allow internet outbound or restrict outbound to approved destinations. The Azure portal does not currently create this managed network. Resource creation uses az rest or Bicep/Terraform; the managed-network settings use the related Azure CLI commands or templates. An Azure Firewall can add cost when FQDN rules are used.

These are not three buttons in one place. The portal supports creating a resource with your own VNet injection. Managed virtual network is a different deployment path. Check current region support and limitations before choosing it.

Create the Foundry resource in Azure portal

In the Azure portal, search for Foundry and at the Microsoft Foundry menu, select Create.

On Basics, select the subscription, resource group, region, and a resource name. For a first lab, a separate resource group makes cleanup easier. The Name of the Foundry must be unique.

On Networking, choose the inbound access option that matches the decision above. If you disable public access, add a private endpoint and select the virtual network and subnet that users will connect from.

If you chose your own VNet for agent traffic, configure VNet injection as part of this setup. Use the delegated subnet prepared by your network team. Managed virtual network follows a separate deployment path and is not created by this portal flow.

For the Lab I disabled the Network Access and create a Private Endpoint with the default required Private DNS Zones, one for Cognitive Services, one for OpenAI and one for AI Services.

Review the settings and create the resource. When the portal offers project creation, enter the first project name and finish the deployment.

RBAC: who can manage and who can build?

Azure RBAC controls what each identity can do and at which scope. Foundry Account Owner or Foundry Owner can be used for resource management. Developers who only need to build and test in a project can use Foundry User.

Creating resources and assigning roles are separate permissions. If the account that creates the resource cannot assign roles, an Owner or another administrator may need to grant Foundry User access to the project members and the project identity.

Access to the Foundry project does not automatically give access to connected Storage, Key Vault, or Search resources. Give the Foundry identity only the roles it needs on each service.

Check the setup

• Confirm that the Foundry resource and project are in the expected subscription, resource group, and region.
• Check the resource’s inbound network setting and confirm the private endpoint is approved if you chose private access.
• From a connected client network, check that the Foundry endpoint resolves to the private endpoint IP when private access is used.
• Confirm that project users have Foundry User at the intended scope.
• Check that connected resources have their own access and network settings.

No model is deployed in this post. Before adding one, check the model’s regional availability, quota, and pricing. If you use managed virtual network with FQDN outbound rules, include the managed firewall cost in your estimate.

A quick lab with the Foundry portal

For a short personal lab, you can start at Microsoft Foundry, select Create new project, and use the basic options. The portal creates a Foundry resource for you. You can choose the resource group and location in the advanced options.

This is the fastest way to explore the portal, but it uses basic default settings and does not walk through the full networking choices above. Use the Azure portal or the required IaC path when you need to apply your organization’s network and security design.

What comes next?

We now have a Foundry resource and project, and we have chosen how users and future agent workloads can connect. A follow-up post can deploy a first model and look at quota, cost, and cleanup.

References

• Create a project in Microsoft Foundry
• How to configure network isolation for Microsoft Foundry
• Configure managed virtual network for Microsoft Foundry projects
• Microsoft Foundry architecture
• Role-based access control for Microsoft Foundry

Pantelis Apostolidis

The post Microsoft Foundry for Azure Admins: Create a Resource and Project appeared first on Apostolidis Cloud Corner.