In this video blog post I covered the serving layer step of building your Modern Data Warehouse in Azure. There are certainly some decisions to be made around how you want to structure your schema as you get it ready for presentation with whatever your business intelligence tool of choice, for this example I used Power BI, so I discuss some of the areas you should focus on:
What is your schema type? Snowflake or Star, or something else?
Where should you serve up the data? SQL Server, Synapse, ADLS, Databricks, or Something Else?
What are your Service level agreements for the business? What are your data processing times?
Can you save cost by using an option that’s less compute heavy?
I’d like to discuss the recently announced Azure Firewall service that is now just released in GA. Azure Firewall is a managed, cloud-based network security service that protects your Azure Virtual Network resources. It is a fully stateful PaaS firewall with built-in high availability and unrestricted cloud scalability.
It’s in the cloud and Azure ecosystem and it has some of that
built-in capability. With Azure Firewall you can centrally create,
enforce and log application and network connectivity policies across
subscriptions and virtual networks, giving you a lot of flexibility.
It is also fully integrated with Azure Monitor for log analytics.
That’s big because a lot of firewalls are not fully integrated with log
analytics which means you can’t centralize these logs in OMS, for
instance, which would give you a great platform in a single pane of
glass for monitoring many of the technologies being used in Azure.
Some of the features within:
Built in high availability, so there’s no additional load balances that need to be built and nothing to configure.
Unrestricted cloud scalability. It can scale up as much as you need
to accommodate changing network traffic flows – no need to budget for
your peak traffic, it will accommodate any peaks or valleys
It has application FQDN filtering rules. You can limit outbound
HTTP/S traffic to specified lists of fully qualified domain names
including wildcards. And the feature does not require SSL termination.
There are network traffic filtering rules, so you can create, allow
or deny network filtering rules by source and destination IP address,
port and protocol. Those rules are enforced and logged across multiple
subscriptions and virtual networks. This is another great example of
having availability and elasticity to be able to manage many components
at one time.
It has fully qualified domain name tagging. If you’re running
Windows updates across multiple servers, you can tag that service as an
allowed service to come through and then it becomes a set standard for
all your services behind that firewall.
Outbound SNAT and inbound DNAT support, so you can identify and
allow traffic originating from your virtual network to remote Internet
destinations, as well as inbound network traffic to your firewall public
IP address is translated (Destination Network Address Translation) and
filtered to the private IP addresses on your virtual networks.
That integration with Azure Monitor that I mentioned in which all
events are integrated with Azure Monitor, allowing you to archive logs
to a storage account, stream events to your Event Hub, or send them to
Another nice thing to note is when you set up an express route or a
VPN from your on premises environment to Azure, you can use this as your
single firewall for all those virtual networks and allow traffic in and
out from there and monitor it all from that single place.
This was just released in GA so there are a few hiccups, but if none of the service challenges effect you, I suggest you give it a try. It will only continue to come along and get better as with all the Azure services. I think it’s going to be a great firewall service option for many.