'Service Bus Namespace' Continues Running Even After `$ make tre-stop`

[BiologyGeek]

Hello team,

Is it expected behavior for the 'Service Bus Namespace' to keep running even after executing the $ make tre-stop command?

This screenshot was captured after running the $ make tre-stop command:

Given that the Premium tier of this service is not inexpensive, is there a way to turn it off or disable it when not needed?

[jonnyry]

It's not possible to temporarily stop the Service Bus (or suspend the billing) without deletion. Thread below when I posed a similar question:

#3782

[BiologyGeek]

It's not possible to temporarily stop the Service Bus (or suspend the billing) without deletion. Thread below when I posed a similar question:

#3782

Thank you @jonnyry!

I deleted the 'Service Bus Namespace', but this resulted in abnormal activity in the 'Log Analytics workspace' and a lot of data ingestion, which caused a higher cost than the Service Bus Namespace itself.

Is there a way to prevent abnormal activity after removing the Service Bus Namespace? @marrobi

[marrobi]

@BiologyGeek I guess the logs are coming from the API web app and resource processor VMSS.

So if you stop both of them, as per the other issue you raised, stopping the web app won't save money, but would hopefully stop these errors being logged.

[marrobi]

It might be someone could look at using standard SKU service bus and having a config for users who don't require the service bus to be on a private network - for example for development purposes.

[jonnyry]

Would it possible to switch out for one of the other (less expensive) queue/event type Azure services... Queue Storage, Event Grid, Event Hubs... are there features/characteristics of the Service Bus that we specifically require?

[marrobi]

I think its session support. @damoodamoo @tamirkamara may be able to advise.

[damoodamoo]

we do require session support for ordered delivery unfortunately. think that's also part of standard SKU though, so a 'dev' switch to allow it to be deployed in standard would probably be the best bet...

[jonnyry]

Thanks @marrobi @damoodamoo

I'm guessing some additional network configuration would be required once the Service Bus SKU was switched to Standard, since the private endpoints & VNET integration are no longer available...

• An outboud app rule in the Firewall to allow access to the Service Bus public FQDN ports 5671, 5672, 443. It would be nice to tie down the source IPs/subnets if possible.
• The adding an IP restriction on the Service Bus for the Firewall's public IP? This appears to be possible via the REST API, even though its not visible in the Azure portal.

Would that do it?

In terms of locking down the source IPs/subnets, am I right in thinking the following components connect to the Service Bus?:

• Resource Processor
• API
• Airlock Processor Function App
• anything else?

[marrobi]

I think that's it.

Re the firewall rules, you can do it in an ARM template ( https://learn.microsoft.com/en-us/azure/service-bus-messaging/service-bus-ip-filtering#use-resource-manager-template ), so if not supported in TF, would think can do it using AzAPI provider.

[marrobi]

think can do it here - https://registry.terraform.io/providers/hashicorp/azurerm/latest/docs/resources/servicebus_namespace#ip_rules

[jonnyry]

Thanks.

Re opening the Azure Firewall outbound to the service bus FQDN, is looking trickier than I first thought -

• a network rule is required rather than application rule since we need to open ports 443,5671,5672
• network rules don't support FQDN resolution, unless you turn on DNS on the Firewall Policy. The TRE has it turned off currently, plus its only supported in Firewalls Standard & Premium - could do this, though it doesn't help in achieving the aim of lowering the SKUs for non prod TRE instances.

Attempted to use a network rule with a Service Tag instead of FQDN:

• Service Bus Service tag is only maintained for the Service Bus Premium:

An network rule on IP does work, however I'm imagining the IP will not stay same for long.

Not sure there's any easy solution to this one!

[marrobi]

Is the purpose of this PR to reduce costs when NOT in production? If so then does the IP filtering matter? As long as the none VNet service buss is only enabled by a clear flag.

[jonnyry]

Is the purpose of this PR to reduce costs when NOT in production?

Yes correct - to reduce the cost of dev/test instances.

Production would use premium SKUs (private endpoints/VNET integration etc).

If so then does the IP filtering matter? As long as the none VNet service buss is only enabled by a clear flag.

I suppose not (or less so anyway). The firewall still needs opening to allow traffic out to the service bus public IP - and would be preferable if it wasn't open to any destination.