@@ -245,7 +245,8 @@ There are two ways to configure AWS: using an access key or using the default cr
245245??? info "Custom security group"
246246 By default, ` dstack ` creates and manages its own security group per project (opening SSH to ` 0.0.0.0/0 `
247247 and allowing all traffic within the group so multi-node clusters work out of the box).
248- To use a security group you manage yourself instead, set ` security_group_id ` :
248+ To use a security group you manage yourself instead, set ` security_group_name ` if you create a
249+ security group with the same name in every configured region's VPC:
249250
250251 ```yaml
251252 projects:
@@ -255,12 +256,30 @@ There are two ways to configure AWS: using an access key or using the default cr
255256 creds:
256257 type: default
257258
258- security_group_id: sg-0a1b2c3d4e5f6g7h8
259+ security_group_name: my-security-group
259260 ```
260261
261- When `security_group_id` is set, `dstack` attaches it to instances as-is and never adds, removes, or modifies
262- its rules. You're responsible for SSH reachability (from wherever the `dstack` server and users connect from)
263- and, for multi-node clusters, for allowing traffic between instances in the group.
262+ If your security groups have different names (or IDs are more convenient) per region, use
263+ `security_group_ids` instead:
264+
265+ ```yaml
266+ projects:
267+ - name: main
268+ backends:
269+ - type: aws
270+ creds:
271+ type: default
272+
273+ security_group_ids:
274+ us-east-1: sg-0a1b2c3d4e5f6g7h8
275+ us-west-2: sg-1b2c3d4e5f6g7h8i9
276+ ```
277+
278+ Regions not covered by `security_group_ids` fall back to `security_group_name` if set, or to
279+ dstack's auto-created security group otherwise. Either way, `dstack` attaches the security group
280+ to instances as-is and never adds, removes, or modifies its rules. You're responsible for SSH
281+ reachability (from wherever the `dstack` server and users connect from) and, for multi-node
282+ clusters, for allowing traffic between instances in the group.
264283
265284 You can also override this per fleet or run using the `security_group` profile property.
266285
@@ -469,7 +488,8 @@ There are two ways to configure Azure: using a client secret or using the defaul
469488??? info "Custom network security group"
470489 By default, ` dstack ` creates and manages its own network security group (opening SSH to the internet
471490 and allowing all traffic within the group so multi-node clusters work out of the box).
472- To use a network security group you manage yourself instead, set ` network_security_group ` :
491+ Azure NSG names must be unique within a resource group regardless of region, so a custom NSG is
492+ configured per location via ` network_security_group_ids ` :
473493
474494 ```yaml
475495 projects:
@@ -478,12 +498,16 @@ There are two ways to configure Azure: using a client secret or using the defaul
478498 - type: azure
479499 creds:
480500 type: default
481- network_security_group: my-network-security-group
501+ regions: [westeurope, eastus]
502+ network_security_group_ids:
503+ westeurope: my-network-security-group-we
504+ eastus: my-network-security-group-eus
482505 ```
483506
484- When `network_security_group` is set, `dstack` attaches it to instances as-is and never adds, removes, or
485- modifies its rules. You're responsible for SSH reachability and, for multi-node clusters, for allowing
486- traffic between instances in the group.
507+ Locations not covered by `network_security_group_ids` fall back to dstack's auto-created network
508+ security group. Either way, `dstack` attaches the network security group to instances as-is and
509+ never adds, removes, or modifies its rules. You're responsible for SSH reachability and, for
510+ multi-node clusters, for allowing traffic between instances in the group.
487511
488512 You can also override this per fleet or run using the `security_group` profile property.
489513
@@ -1136,7 +1160,8 @@ There are two ways to configure OCI: using client credentials or using the defau
11361160??? info "Custom network security group"
11371161 By default, `dstack` creates and manages its own network security group per project (opening SSH to
11381162 ` 0.0.0.0/0` and allowing all traffic within the VCN so multi-node clusters work out of the box).
1139- To use a network security group you manage yourself instead, set `network_security_group_id` :
1163+ OCI network security groups are region-scoped, so a custom NSG is configured per region via
1164+ `network_security_group_ids` :
11401165
11411166 ` ` ` yaml
11421167 projects:
@@ -1145,12 +1170,15 @@ There are two ways to configure OCI: using client credentials or using the defau
11451170 - type: oci
11461171 creds:
11471172 type: default
1148- network_security_group_id: ocid1.networksecuritygroup.oc1..aaaaaaaa
1173+ network_security_group_ids:
1174+ eu-frankfurt-1: ocid1.networksecuritygroup.oc1..aaaaaaaa
1175+ us-ashburn-1: ocid1.networksecuritygroup.oc1..bbbbbbbb
11491176 ` ` `
11501177
1151- When `network_security_group_id` is set, `dstack` attaches it to instances as-is and never adds, removes,
1152- or modifies its rules. You're responsible for SSH reachability and, for multi-node clusters, for allowing
1153- traffic between instances in the group.
1178+ Regions not covered by `network_security_group_ids` fall back to dstack's auto-created network
1179+ security group. Either way, `dstack` attaches the network security group to instances as-is and
1180+ never adds, removes, or modifies its rules. You're responsible for SSH reachability and, for
1181+ multi-node clusters, for allowing traffic between instances in the group.
11541182
11551183 You can also override this per fleet or run using the `security_group` profile property.
11561184
0 commit comments