what do you know about Azure Automation? In this post, I’ll fill you in
on this cool, cloud-based automation service that provides you the
ability to configure process automation, update management and system
configuration, which is managed across your on-premises resources, as
well as your Azure cloud-based resources.
Azure Automation provides complete control of deployment operation
and decommissions of workloads and resources for your hybrid
environment. So, we can have a single pane of glass for managing all our
resources through automation.
Some features I’d like to point out are:
It allows you to automate those mundane, error-prone activities that
you perform as part of your system configuration and maintenance.
You can create Notebooks in PowerShell or Python that help you
reduce the chance for misconfiguration errors. And it will help lower
operational costs for the maintenance of those systems, as you can
script it out to do it when you need instead of manually.
The Notebooks can be developed for on-premises or Azure resources
and they use Web Hooks that allow you to trigger automation from things
such as ITSM, Dev Ops and monitoring systems. So, you can run these
remotely and trigger them from wherever you need to.
On configuration management side, you can build these desired state
configurations for your enterprise environment. This will help you to
set a baseline for how your systems will operate and will identify when
there’s a variance from the initial system configuration, alerting you
of any anomalies that could be problematic.
It has a rich reporting back end and alerting interface for full
visibility into what’s happening in your Windows and Linux systems –
on-premises and in Azure.
Gives you update management aspects (in Windows and Linux) to help
you define the aspects of how updates are applied, and it helps
administrators to specify which updates will be deployed, as well as
successful or unsuccessful deployments and the ability to specify which
updates should not be deployed to systems, all done through PowerShell
or Python scripts.
It can share capabilities, so when you’re using multiple resources
or building those Notebooks for automation, it allows you to share the
resources to simplify management. You can build multiple scripts but use
the same resources over and over as references for things like
role-based access control, variables, credentials, certificates,
connections, schedules and access to source control and PowerShell
modules. You can check these in and out of source control like any kind
of code-based project.
Lastly, and one of the coolest features in my opinion, where these
are templates you’re deploying out in your systems, everyone has some
similar challenges. There’s a community gallery where you can go and
download templates others have created or upload ones you’ve created to
share. With a few basic configuration tweaks and review to make sure
they’re secure, this is a great option for making the process faster by
finding an existing script and cleaning it up and deploying it in your
systems and environment.
So, there’s a lot you can do with this service and I think it’s worth
checking out as it can make your maintenance and management much
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.
In today’s post I’d like to talk about site to site networking service. Azure already has a site to site VPN service, but the Azure Virtual WAN is a newer service currently in Preview. This networking service is optimized for branch to service connectivity and offers the capability to use partner devices currently supplied by preferred partners (currently Riverbed and Cisco) or the ability to manually configure this connectivity with your environment.
Azure Virtual WAN has some big differences to consider:
Automated set up and configuration of these devices by preferred partners makes much easier to configure them. You simply set up these connections which you can export directly from the device into Azure and it automatically sets it up for you.
It is designed for large scalability and more through-put. The site to site service is great for smaller workloads but this new service opens the pipe and allows the data to crank through much faster.
It’s designed as a Hub and Spoke model. The Hub being Azure and the Spoke being your branch office – all managed within Azure.
Let’s look at the 4 main components of this service:
The Virtual WAN Service itself – This asset is where the resources are collected, and it represents a virtual overlay of the Azure network. Think of it as a top down view of the connectivity between all the components in Azure and in your offices.
A site represents the on premises VPN device and its settings. I mentioned those preferred devices from Riverbed and Sysco (with more to come) and if you’re using a supported device, you can easily drop that configuration into Azure.
The hub is the connection point in Azure for those sites. The site connects to the hub and the virtual WAN is overlooking all of these components.
The hub virtual network connection allows your connection point for your hub to your virtual network.
So, your hub and your virtual network are connected through that virtual network connection. This allows the communication between your virtual networks in Azure and your site to site virtual WAN.
This offering makes the landscape a bit different with how people are doing connectivity into Azure and connecting their remote offices by consolidating what that network looks like, as well as making it easier by offering these preferred devices.
Again, this is still in Preview but definitely something I would suggest checking out.