At runtime, an Agent may need to call public network models and public network APIs, or access private network resources such as private network databases and internal APIs. When employees or programs access Team collaboration, you also need to determine whether to connect over the public network or a private network. AgentCore separately configures the Workspace network that Agents use to access resources and the collaboration network that clients use to connect to the collaboration service. The two configurations are saved independently and are not automatically synchronized. For each configuration, select and enable public network access, VPC access, or the collaboration access method based on your business scenario. AgentCore networking configuration applies to both platform-managed Harness Agents and high-code Agents.
Choose a configuration method for your business scenario
The Workspace network selects the VPC that an Agent uses to access business resources, and the Agent's network toggles determine whether the Agent uses that VPC and whether it accesses the public network. The collaboration network determines whether clients connect to the Team collaboration service over the public network or through a specified VPC. The two configurations are saved separately. Modifying the Workspace VPC does not automatically change the network configuration of collaboration that is already enabled, and vice versa.
| Business scenario | Configuration method |
| At runtime, the Agent accesses public network resources such as public network models and public network APIs | Configure Agent public network access |
| At runtime, the Agent accesses private network resources such as private network databases, internal APIs, and private network models or tools | Configure Agent VPC access |
| Employees or programs access the Team collaboration service | Configure Team collaboration access |
If an Agent needs to query private network databases and call public network models, you can enable public network access and VPC access at the same time.
Prepare network resources
All three types of network configuration are completed in a Workspace. Before you begin, make sure that the following resources and requirements are ready:
The target Workspace is created. Public network access, VPC access, and Team collaboration access for an Agent are all configured in the Workspace that the Agent belongs to.
Select the VPC where your business resides. Prefer the VPC where the private network resources, such as the target database or internal APIs, reside. If the target is in another VPC or an off-cloud network, establish network connectivity first, and check the forward and return routes and domain name resolution.
Prepare vSwitches that cover different zones. A Workspace requires at least two vSwitches, and the vSwitches must cover at least two zones. To enable private network access for collaboration, you also need to select two vSwitches in different zones.
Reserve available IP addresses on the vSwitches. When you bind a VPC to the Workspace and enable private network access for collaboration, the related network connectivity resources occupy vSwitch IP addresses. Leave room for existing business growth and network resource expansion.
Meet the available IP threshold for collaboration private network access. When you enable private network access for collaboration, each vSwitch must have at least 31 available IP addresses, and the counts cannot be combined. This requirement applies only to the remaining IP addresses before creation.
Plan non-overlapping CIDR blocks. When you create CIDR blocks, avoid overlaps with the CIDR blocks of the VPCs, office networks, or data centers that need to be interconnected. For details about the planning method, see VPC Network Planning.
Private network clients can connect to the collaboration VPC. Before an office computer uses the collaboration private endpoint, it must connect to the collaboration VPC and be able to resolve collaboration private domain names.
Configure Agent public network access
This method applies when an Agent accesses public network resources such as public network models and public network APIs. Multiple Agents can share the public egress of the Workspace they belong to. If the target service uses a source IP address whitelist, first add the Current Workspace Public Egress IP shown on the page to the whitelist of the target service.
Procedure
Log on to the AgentCore console, and select the region and Workspace.
Choose Agent, and create an Agent or edit an existing Agent.
In Network Configuration, turn on Allow Default Network Interface to Access Public Network, submit, and wait for the creation or update to complete.
Have the Agent call the target public network service once and confirm that the request succeeds.
If the request is rejected, check in order whether Allow Default Network Interface to Access Public Network is turned on, whether the creation or update is complete, and whether the IP address in the whitelist of the target service matches the Current Workspace Public Egress IP shown on the page. Finally, verify the source address against the access records on the target side.
Configure Agent VPC access
This method applies when an Agent accesses private network resources such as private network databases, internal APIs, and private network models or tools.
Procedure
Log on to the AgentCore console, select the region and Workspace, and go to the Overview page of the target Workspace.
Click Bind VPC, select a VPC and vSwitches, submit, and wait for the binding to complete. You can also complete the binding when you create a Workspace. For details, see Manage Workspace.
Create or edit an Agent. In Network Configuration, turn on Allow VPC Access, submit, and wait for the update to complete. The Agent uses the VPC configured for the Workspace it belongs to.
In the console of the target service or the corresponding cloud service, configure settings such as security groups, access whitelists, and access account permissions to prevent Agent access requests from being blocked.
Have the Agent query test data or call an internal API once, and check the returned results.
If the connection fails, check the Agent's VPC toggle, the target port, and the security group or whitelist in order, and finally check business authentication.
If the Agent is required to access only the private network, turn off Allow Default Network Interface to Access Public Network, and check whether the Agent can still access the public network through a NAT Gateway or a proxy in the business VPC. If it can, the private network restriction is not fully in effect.
Modifying the Workspace VPC affects the Agents that use the VPC. After the change, wait for the update to complete, and verify again that access to databases, models, and tools works as expected.
Configure Team collaboration access
This section configures the network that employees or programs use to connect to the Team collaboration service. For the activation process and connection point descriptions, see Set Up Team Collaboration. Choose an access method based on the location of the client:
| Client scenario | Collaboration network configuration |
| Use collaboration over the Internet | Turn on Public Network Access |
| Allow collaboration only over the enterprise private network | Turn on VPC Access, select a VPC and vSwitches, and turn off Public Network Access |
| Support collaboration from both public network and private network clients | Turn on both Public Network Access and VPC Access |
Procedure
In the left-side navigation pane of the target Workspace, choose Team Collaboration. When you enable collaboration for the first time, choose the network method based on the preceding table; turn on at least one of Public Network Access and VPC Access.
If you need private network access, select the VPC for collaboration and two vSwitches in different zones. Verify one by one that the available IP addresses of each vSwitch meet the requirements in Prepare network resources, and complete the activation as prompted on the page.
After activation, choose Provisioning → Connection Points to view the web and API addresses for collaboration clients. Public network clients use the public endpoint, and clients that are connected to the collaboration VPC use the private endpoint.
Connect to the collaboration service from a client, and test sending and receiving messages.
If you need to turn off public network access later, first test the connection and message sending and receiving through the private endpoint. Then, in Provisioning → Network Configuration, turn off public network access.
If VPC access is not configured for collaboration, keep public network access turned on to prevent the collaboration service from becoming inaccessible.
FAQ
Do Agents occupy VPC IP addresses?
You do not need to reserve IP addresses for each Agent. When a Workspace is connected to a VPC and private network access is enabled for collaboration, the related network connectivity resources occupy vSwitch IP addresses.
What is the difference between the Workspace network and the collaboration network? Are changes synchronized?
The Workspace network determines which VPC an Agent uses to access business resources and whether the Agent accesses the public network. The collaboration network determines whether clients connect to the collaboration service over the public network or through a specified VPC. For the scope of the two network types, see Choose a configuration method for your business scenario. The two configurations are saved separately. Modifying the Workspace VPC does not automatically change the network configuration of collaboration that is already enabled, and vice versa. The Workspace VPC is filled in as the default configuration only when you configure the collaboration VPC.
How do I view the remaining IP addresses of a vSwitch? What does "at least 31 IP addresses" mean?
In the VPC console, select the region, and choose vSwitches. Find the vSwitches used by AgentCore and view the current number of available IP addresses. This number is only the remaining IP address requirement before creation and does not mean that 31 IP addresses are necessarily occupied after activation. For the complete statement of the available IP requirement, see Prepare network resources.
After I turn off public network access for collaboration, can the Agent still access public network models?
Yes, provided that public network access is turned on for the Agent itself. The collaboration public network toggle only affects whether clients can connect to the collaboration service over the public network.
After a VPC is bound to the Workspace, how do business systems invoke the Agent?
The Workspace VPC configuration is used for Agents to access business resources. When a business system invokes an Agent, it uses the service address and authentication information provided by the Agent. The Workspace public egress IP is used for outbound whitelists and cannot be used as the invocation address. For a high-code Agent, you can view the invocation address and authentication information in External Channel Configuration → Direct Access on the product page, and then send requests from the caller's network. For instructions, see High-Code Agent Deployment and Usage Guide.