Cost optimisation - Firewall Basic SKU

[jonnyry]

Is it possible to use the Azure Firewall Basic SKU to reduce the running cost in non production environments?

I know this has previously been discussed here #2723 - it reads like the main blocker at the time was the inability to deallocate the firewall Basic SKU.

I've just tested out deallocation and allocation of the policy on a Basic SKU Firewall and it now appears to be possible:

@marrobi @tamirkamara Is there a finer point in the allocation/deallocation that I might have missed? Were there any other blockers to using the Basic SKU?

[marrobi]

Should work fine. It's in the bundle, just dont think it's exposed.

Would be good to have an config value to configure it.

[jonnyry]

The Basic SKU Firewall is specifically excluded from deallocation in the start/stop script:

https://github.com/microsoft/AzureTRE/blob/1ffb09baf37f4599adfd65b4259fdda7564da408/devops/scripts/control_tre.sh#L70-L77

If there aren't any other blockers then hopefully its just a case of:

• modifying the start/stop script to allow deallocation of the Basic SKU
• plus surfacing a FIREWALL_SKU environment variable

[marrobi]

Yes, that would make a lot of sense. Great if you can contribute it.

[jonnyry]

It's on my list! Just need to figure out how parameters get passed into the resource processor :-D

[marrobi]

https://github.com/microsoft/AzureTRE/blob/main/resource_processor%2Fresources%2Fcommands.py#L58

As long as the parameter matches the config key, it should just need adding to the config object.

[marrobi]

Example: https://github.com/microsoft/AzureTRE/blob/main/resource_processor%2Fshared%2Fconfig.py#L24

[jonnyry]

Am I right in thinking the firewall is not deployed via the resource processor when the TRE is initially deployed? (since its the only shared service that's gets deployed on initial TRE deployment)

But then if the firewall is updated subsequently (e.g. via the TRE UI), this would update would take place via the resource processor?