Since the announcement of the Microsoft/Adobe partnership at Ignite, we at Perficient have been working to make this a first-class offer for our clients. The internet wouldn’t exist if all the world’s computers were isolated from one another. Networking is the foundation of modern day computing, so it’s only logical to start with this topic!
Virtual Networks
When deploying Adobe Experience Manager (AEM), the typical network configuration is to have the public facing Apache dispatcher servers in a web DMZ and then the AEM publish and author instances in separate application DMZ. Network communication, from both the public internet as well as other DMZs are controlled through one or more firewalls.
To realize the same type of security in Azure, the concepts are very similar, but the names may not be very familiar. In Azure, we start with a virtual network. All VMs that are running in Azure for a specific environment reside within this virtual network.
To replicate the functionality of DMZs in the on-premises world, a subnet is created for each zone. A network security group (NSG) is created and assigned to each subnet. NSGs allow both inbound and outbound rules to be set. By default, all inbound traffic that originates from the same virtual network is allowed. NSG rules work on a priority system: a rule with a higher priority (lower number) will override a rule with a lower priority (higher number). The default rule allowing in-bound traffic from the virtual network is a very low priority rule, so it is easy to create a higher priority rule to override it. We want to limit traffic as much as possible, so a rule is created to block all incoming traffic. Any exceptions we need to make to this rule will simply be assigned a higher priority.
When creating VMs, there is an option to assign an NSG to the network interface; we typically do not do this as we rely on the NSG of the subnet to handle all of the rules. This allows us to manage all rules from a single screen for a particular subnet. If there are specific needs that require a VM to have special security rules, then a new NSG should be created for that VM.
Important note: NSG rules are applied when a VM starts. If an NSG rule changes after a VM has already started, it will not be aware of this rule until it has restarted.
IP Addresses
We assign private IP addresses within the virtual network statically. This ensures that each time a VM starts, it receives the same IP address, and that any configuration that relies on those IP addresses remain intact.
Public IP addresses are assigned to VMs that need to be connected to directly from the public internet. If the public IP address is dynamic, then we always assign a DNS name label so that no configuration changes are needed if/when the IP address changes. Pricing can be different for static vs dynamic IP addresses; the needs of the system determine which is the better option.
On-Premises Connectivity
Often there are reasons to want to connect with VMs inside the Azure virtual network with machines that are remote/on-premises. This can be accomplished by assigning each VM a public IP address, but in most cases, this is not desirable as it can compromise the security of the virtual network.
Azure virtual networks support VPN. They support both point-to-site and site-to-site VPNs. Going either route allows you to connect with the virtual network, and directly access the VMs in a highly secure fashion. This allows the access that is needed while not compromising the security of the entire virtual network.
