Design principles for building/deploying applications on Azure IaaS with FastTrack engineers

>> Hey, everybody My name is Jason Beck and I’m a FastTrack for Azure Engineer Today we’re going to be working with design principles for building and deploying applications on Azure with FastTrack Engineers So, to get started The first thing we should do is talk about FastTrack for Azure and what it is FastTrack for Azure is a Customer Success Program that works with customers to confidently build their solutions in Azure So, a lot of the benefits that they can gain from working with us is they get direct assistance from Azure Engineers, when customers already have their own partners which commonly they do, we’ll actually work with the partners in conjunction to make sure that the customer solutions are successful in the Cloud And then we really want to make sure that we bring the best practices and the tooling that we can bring for the customer to make sure that their experience in on-boarding to the Cloud or even maturing in the Cloud is as best as possible So, if you have heard of the FastTrack brand before, FastTrack is used in other services for the Microsoft 365, Windows, formally Office 365 and EMS and dynamics as well Whenever we work with our customers we like to identify and to some key phases So in the beginning we want to make sure that we can work with the customer in developing a plan that is best for them And then as we start working with them, someone like myself, a FastTrack Engineer, will actually educate them and go through a profit concept to make sure that they feel confident to build solutions in Azure, and then from there the FastTrack team will then take a backseat and then maybe the partner steps forward or the customer steps forward, and they really continue down the road to bring their solutions into production For some of this sessions, the takeaways and objectives we have are really talking about understanding the key elements around Governance, and why Governance is going to be so important for Azure, and then how would you walk through a setup for looking at a Line Of Business Application and bringing it to Azure So let’s start off with Setting the Stage When you first start bringing a Line Of Business Application into the Cloud, it typically comes from some business initiative first It’s very common to say the business has tasked I.T that we need to be in the Cloud by a certain date And a lot of these are going to be driven by business decisions and business considerations, common things that we see are things around availability, reliability, performance and things of this nature As this starts going down and this is maybe their Cloud Strategy for the customer, at a certain point it does turn around and bring up an I.T centric conversation This is where it really starts going down to the application teams and these teams are then starting to think about, hey how do we manage things like Storage? What is our security posture going to be like? How do we recover our resources in any sort of a disaster and what is our backup story? And this is when it turns into a little bit more of a technical conversation, and then overall you really have to start taking a step back and looking at all the considerations that really can come into play Another important one is Vendor Considerations as on premises they might be using specific vendors for specific solutions And then coming to the Cloud they might need to ensure that the supportability is still there, or they have an opportunity to look into new areas as well So these are all very common things that we see and something that we like to highlight As we look here, there’s a lot of things that really come up for an example of a Line Of Business Application So through the session today we’re going to walk through different areas of this starting from the Subscriptions, looking at Resource Groups, Naming, Networking, Storage and things like that, and we’ll take each one one by one, and go through some considerations So this is going to be the steps that we’re going to walk through for our Line Of Business Application So we’re going to start in the very beginning with Azure Governance, going to Naming Convention, Resource Groups, Connectivity, Storage, Identity, Security, and then close with Virtual Machines When we take a look at Azure Governance, this is really talking about balancing the line of what type of control that you have in your environment, and then also balancing the ability to leverage Cloud Computing This is a fine line that you should walk Something important to understand around Azure Governance is there is no one solution that’s going to work for all customers, and this is something that really should be tailored to each customer, how they operate, and what type of Cloud Computing needs that they require So we will cover things in the very beginning about subscription Management and what exists above a subscription That is going to be very important to look out for things like Chargeback,

Overall Management and the lifetime of your resources in Azure As we go into other things we’ll first touch on things like Naming Standards, which will be effective everywhere We’ll talk about Policies that you can enforce in your subscription to make sure that you can adhere to what is defined We’ll talk about Resource Tags and how they can be leveraged to do things like Chargeback for cost Management, overall metadata for your resources We’ll talk about Resource Groups, and how they can be used and leveraged to optimize your Operational Standpoint in Azure We’ll talk about Role Based Access Control for who has access to Azure, and how can they make actions We’ll talk about Resource Locks, about when you want to make sure that you don’t accidentally delete or change something We’ll talk about Automation, and how it can be used to really take a step away from manual actions and step by step through the GUI for example And then we’ll talk about some of the security aspects that is provided through Azure security center So let’s first start talking about Azure Subscriptions So, for a lot of people who have worked in Azure or have only gotten a little bit of a taste, you’re likely have been working inside of an Azure Subscription There are many things to think about when you’re working in an Azure Subscription, and then also understanding that you can have multiple subscriptions and how they can be isolated and also work together for different scenarios This is something that will vary based on the customer and then there are certain things that can make big impact in this Examples could be something for security and compliance, where you might want to have subscriptions for production, and then you might want to have an isolation to have subscriptions for non production These will also roll up into higher level contracts, including Azure Accounts, Azure Departments and then your overall Azure Enrollment When you take a look at this This is something where there are certain drivers to create new subscriptions As you’re working with many large commercial subscriptions, something that comes up is also the Azure Subscription Limits The subscription itself is going to be a boundary for Technical Service Limits, and as these limits are being approached, this is something that you want to keep your eye on in terms of your current quota to ensure that you don’t hit any of these limits, and you’re forced to do any sort of rip and replace to expand in your Azure Landscape So, these are some of the examples for how subscription models can grow, but there are a lot of other key factors in here where Chargeback is very important, the security isolation being able to manage everything, ensuring that you’re adhering to any compliance, and then of course since you’re working in the Cloud you want to be flexible and nimble, and ensure that you’re planning for future growth, and then planning to understand that there are services that do not even exist yet, that you might want to incorporate in the future Now let’s move on to naming conventions Naming conventions are commonly adopted on-premises and these are things that you can adopt in Azure as well Whenever we work with customers we want to ensure that they have developed a naming convention or they have modified what they have brought from on-premises And there’s a couple of key factors on why we want to recommend this First and foremost, you cannot rename your resources in Azure So, whenever you start creating things and they’re going to be long lived resources that live in your production environment, the name is going to stick So, picking that wisely and ensuring that it’s very readable is going to be very important Another area is as you build your Azure subscription and you think about your chargeback model, all of your resources will be on your Azure bill that comes And whenever you’re working with finance to better help them have an idea for the costs that have come out of your Azure subscription, the name will be much more influential and it will be much better if you make it humanly readable Another aspect of this is as you continue to grow resources in Azure, you might have a lot of resources to start looking through management and overall when you’re looking at things when you might have a production subscription versus a non-production subscription, including something like the environment of prod or non-prod, or development or test can be really important and very useful to make sure that you don’t inadvertently touch or change something that is in production when you didn’t mean to So, there’s a lot of good value out of good naming And this is something where we have to use good naming conventions because this is something that Microsoft Karelian not enforce on our customers So, for customers that have a very good grasp of their naming and they just need to make some adjustments for Azure, that is a great story

But some customers that we work with, they don’t have a good story for naming conventions and they want to have an opportunity to start from scratch or hear the Microsoft recommendations for what we would put a position on naming conventions So, for this let’s take a moment and I will navigate into our public documentation to see what Microsoft recommends So, taking a look here this is going to be on our Microsoft docs websites So, this is going to be public documentation available to anybody And in here, we have naming conventions that we have outlined for many of the resources that we have in Azure and this is a good starting point for any customer who is coming to Azure for the first time and they want a good starting point for naming standards So, in here you can see examples for naming your subscriptions There are other areas where you want to be very keen on how your naming is because there are certain restrictions where you’re working with a resource that is using a public namespace that is associated with DNS So, an example here would be a storage account and there will be a public URL associated with the storage account And in this situation you need to make sure that the naming is unique across all customers in Azure So, this is something that they probably don’t have to work with in an on-premises environment and going through here, this can help them really understand and really get a good outline for some of these scenarios that might not exist otherwise So, now let’s take a step and look at the resource groups So, resource groups are going to be logical containers for management to help organize and group resources in your Azure subscription When you think about some of the driving principles for resource groups, there’s a couple of rules that you need to follow Every resource in an Azure subscription must exist in a single resource group So, that means that you can’t have one resource that’s in multiple resource groups and you can’t have and as a resource that does not belong to any resource group You also cannot nest resource groups So, whenever you think about an azure subscription if the subscription is the top level resource, your resource groups will be your second level and then your resources will be your third and bottom most part of the tier that you have to work with When you think about the resource groups it’s not just going to be about organizing your resources So, this is something where you want to be able to think intelligently about your application, and you might have one application gets their own resource group, and every time a new application comes onboard they get their own resource group, and then each one will be separated from each other Other scenarios where some customers have very large environments and very large applications, each tier might have their own resource group And depending on how your customer works and how big they are, this model might change and you might need to make modifications as necessary There are other things that will also influence how you want to use resource groups Things include like tagging and RBAC policies and locks So tagging is when you can enable key value pairs that can be associated with your resources and your resource groups So, an example could be adding a tag for your cost center at the resource group level, so your chargeback model understands all of these resources are going to be charged back internally for the customer to a specific cost center Other areas will include RBAC This is going to be the role based access control to ensure who has the correct permissions inside of that resource group So, rather than giving subscription wider access or resource level access, we see it work very effectively when assigning the RBAC roles and assignments at the resource group level This is something that we also notice work well for Azure policies to enforce certain policies in your subscription and specifically in the resource groups for things like service curation, regional availability for your services and your application So, some of these could be restricting you only deploying resources in a couple Azure regions in the United States or a couple of regions in Australia, only being allowed to deploy certain VM skews in VM sizes and then finally using locks at the resource group level is also very effective So, a lock is a mechanism that can be used for your resources to prevent automatic deletion and preventing any changes to your resources as well So, for example if you lock a resource group and say, do not delete, then that means if someone is in the portal or they’re working in a script and they attempt to delete the resources, it will actually get an error that says” Your resources are locked and you are not allowed to delete them until the lock is removed” So, this is a very good safety measure and something that should be used in any production environment or any environment that does not have any changes in the foreseeable future It’s a good safety mechanism and something very easy for customers to use for their resource groups

So, now let’s take a look at how you can apply the resource scripts to the architecture that we saw before So, if we start here you can absolutely put all of the resources showing here on the left in a single resource group There’s nothing in Azure that will stop you from doing it, but for the most part we would likely recommend having a different resource group structure, something more like what is shown on the right side of the screen where we group more of the infrastructure components including things like Active Directory, Jump Boxes, VPNs into a single resource group which could be the core, services resource group And then we might have a separate resource group for the database and all the supporting resources for the database in which it can include the load balancers, the network security groups which are defined by the database team, and then you might have the rest of the application separated out into its own resource group as well for maybe the presentation layer, any caching layer or indexing or a searching layer This can change and vary a little bit, but overall this is a good example of how it can be used in two different ways but we want to recommend more than likely the approach on the right side So, to recap some ideas for the resource groups in terms of good recommendations would be to again apply the tags, want to make sure you apply RBAC if you want to align to any least privileged access model applying locks and also applying policies to your resource groups as well So, now let’s take a step and let’s go into the connectivity To really get the tires moving, you really don’t need to start thinking about how do you connect to these services in the cloud And this really opens up the network connectivity question and then it really brings in the IP space consideration Do they get their own IPs? Is Microsoft going to give them their own and they can’t choose? And this is where you should really start talking about your virtual networks and the hybrid connectivity models So, let’s take a moment, pause from the slide and let’s jump to some of the documentation here and we can show you some of the reference architectures that we can have to start driving this conversation So, if we come to the reference architecture Park portion of the Azure documentation, these are going to include a variety of reference architectures for a lot of different things in Azure So, as you go through here you’ll see a variety of recommendations for deploying Windows VMs, Linux VMs, hybrid connectivity, identity management and a variety of other things, and this is a great place to start with your customers as this is really solution centric and really can help give you good pros and cons and why one solution might be good for another one As it comes with the network, we like to start over here on the hybrid network and in here it’ll show you a variety of different connection options from bring your on-premises workloads to Azure So, in here you can see things like VPN We have express route. This is some other topologies in here And this is where you really start thinking about your virtual network in Azure as something that is an extension of the customer’s data center as they bring their own IP ranges and they bring them to the Azure regions of their choice So, in here this is when you want to start thinking about a hybrid connection like a VPN which is like a site to site VPN where they can connect their on-premises resources to their extended data center in Azure So, if we go in here and select on a VPN as an example, you can see here there is their on-premises network on the left which includes their gateway There is a Azure environment on the right and this is something where this is illustrated as a Visio diagram where you can download this And overall, as you go through this this will just walk through different areas of the architecture and it will identify things, and then it will give recommendations and pros and cons for why this architecture might be good for their environment So, as you go through here, there is lots of good information here and at the very bottom you can actually deploy this in the customer’s environment and it will give you the templates and everything that is used to actually build out this entire architecture We strongly recommend that this is a good place to start All the recommendations that we have we don’t want to keep internally, we want to publish them so customers can also consume them And this is definitely a great place to start as the virtual network is typically kind of the tip of the iceberg as you start thinking about the technical implementation of your Azure environment So, as we hop back to the slides, we can go through and take a look at some of these network typologies that exist in Azure So, a very common one that we see is a hub and spoke configuration, where you have a hub virtual network, and this hub virtual network will include a lot of the shared services including your VPN, possibly DNS, or Active Directory, or any other shared service that has been leverage by other applications in Azure And then you’ll connect other virtual networks through VNet peering, and each VNet peered virtual network will then be a spoke,

and each spoke can be its own environment or its own application And this is a model that we’ve seen adopted widely because it’s good for high bandwidth, good for low latency It can incorporate a good model for scale and then it also does play into a good consideration for how can you have an isolation of environments which also encompasses across subscriptions So, for example, you can have the hub virtual network in a centralized production Azure subscription and then you might have a development and test spoke virtual network, which is in a different Azure subscription So, in here, this can really start opening up a lot of network typologies and different structures like this, and this is something that we’ve seen work well for small environments and also large environments When you start looking at the virtual networks, some of the things you have to first think about is the actual addressing in the address space for everything that you use There’s a few principles that need to be followed and a big one is that there cannot be any IP overlap for what they have on-premises and what they have in Azure We also recommend that customers really start thinking about the future and planning for growth as the virtual network can definitely become a bottleneck if you don’t accommodate for any future growth and you run out of the IPs that you have When you think about your virtual network, you want to carve them out using multiple subnets So, as you’re bringing an application into Azure, you might have multiple tiers of that application, and we typically see each tier or role of the application separated in its own subnet And we will go into some other tools in a moment about how we can control the traffic between them as well Other areas to include would be the gateway subnet Whenever you’re creating a VPN appliance and you want to enable that hybrid connectivity, we recommend using the gateway subnet of at least a slashed 27 in CIDR notation and then place it at the end of your virtual network IP range This is something that we have just seen work well for most customers, and the gateway as a slashed 27 is something that they can start out with because in the future if they ever want to use a different network typology that requires a larger subnet, this is going to be the largest size that we require today As you look in your virtual network when you have different subnets, there are certain ways that you want to control the traffic in your Azure environment Normally, when you look at this, the first thing you want to think about are your firewall rules And we have network security groups and network security group rules And these are going to be five tuple rule sets that you can assign to your VMs and your subnets to specifically allow and deny certain traffic So, this is going to be a replacement virtual firewall for your customer What are the allowed traffic rules that you want to enable? And then you can follow up with the more general denying of rules Overall, when we see this implemented, if we see it work rather well when applying the networks security group rules to a specific subnet and then all network interface cards attached to VMs in that subnet will then have to follow along these NSG rules In another sense, if you want to look at the routing, we have user-defined routes And these can be used for different type of network architectures and Azure that particularly come up when you start working with network virtual appliances A few words of caution when using the user-defined routes, there is a concept of Forced Tunneling, where you want to force all Internet bound traffic back on-premises to do any sort of inspection This is something that is supported in Azure but we want to make sure that customers understand the implication of what the Azure’s traffic path looks like and what type of performance they might hit Another area for user-defined routes is specifying them on the gateway subnets As this is possible to potentially block or stop traffic inadvertently if there are any mistakes made as this could be a single point of failure from any hyperconnectivity that you have between your on-premises environment and Azure So, to quickly summarize, all of the contracts are going to be software defined as some of the typologies might be a little bit different compared to on-premises Whenever you’re looking at those different areas separating between network security groups and subnets and everything, it’s not really going to be using one over another for a security decision, it’s about which one is going to be the easiest for them to manage and overall still being effective Particularly with the network, there is a lot of opportunities for defense-in-depth and so we would strongly consider them using things like network security groups and then also using the gusta OS firewall Other areas can be using a DMZ model in Azure and having perimeter subnets and identifying trusted zones As we go forward, then you want to start

talking to your customer about storage When looking at your storage particularly around virtual machines, the first thing you really have to take a look at are the storage types that are available to you So, you have standard storage and you have premium storage Your standard storage is going to be your traditional spinning hard disk and then your premium storage is going to be your solid state disks So, the product group recommendation here is that all production workloads should be using premium storage whenever possible And when customers first come to Azure, this is something that they have to make a decision on whenever they’re creating their virtual machines So, when you look at your OS disk and then you look at your data disks, you have to make sure that the workload running on that machine is going to be performant enough from the storage perspective It’s very common for customers to come to us and say, “I have a very IO intensive workload and it requires a lot of IOPS.” But, then there are other scenarios where you want to make sure the customer is also thinking in terms of throughput for storage So, IOPS throughput together are what really are going to shape your storage profile for your virtual machines and help you get you onto the right track when getting aligned Other areas that you want to consider and something to just kind of note are going to be on data replication For virtual machines in Azure, when you have the opportunity, we want to make sure that you’re using locally redundant storage For managed disks, you don’t have locally redundant storage as an option anymore as Geo redundant storage is probably not going to be the best solution for you for a disaster recovery scenario And we have other solutions and services that are better suited for that When working with the storage in your machines making sure that you install your application and put your application data on data drives and not putting it on the OS disk And then also not putting any data on the D drive whenever you build an azure virtual machine The D drive is going to be the temporary disk in Azure And the temporary disk is used for the page file on Windows and also the swap file for Linux for higher performance, and it’s a free disk for the customer to use Since this is an ephemeral drive, this is non persistent data, and we want to make sure that customers don’t put any good information in here because when they reboot the machine, they will quickly learn that all of that data will be lost So, something where there is a separation between the IT infrastructure team compared to the application team ensuring that the application teams for the people that are actually working inside the operating systems understand that they should not be using the D drive as it is labeled temporary drive even though they might not know that their virtual machine is in Azure Another consideration is just ensuring that they know that there is a disk caching option on your virtual machines For a lot of customers, you can use the default options that Azure has provided, but depending on your workload, you might want to change these to possibly achieve higher performance When looking at your disks, I mentioned before that there are managed and unmanaged disks, and this is something where unmanaged disks is a service that has been out for a very long time and managed disks has been something that has come up a little bit more recently in the history of Azure So, unmanaged disks is going to be where you have your virtual machines and you have your disks for your VMs and they’re placed in storage accounts and storage accounts are for customers to create They can add disks in there and they have full control over everything in the storage account So, for virtual machines, customers have to also take in consideration for capacity planning and making sure that they don’t hit any threshold on the storage account for the maximum number of IOPS that a storage account can handle, for example So, this capacity planning and additional control over the storage accounts for virtual machine management has been something that was rather difficult for customers to do over the past few years So, managed disks is really where the customer only has to specify the disk, the size, what performance they want, whether it’s standard or premium and then the VM that they want to attach it to After that, Microsoft will manage the storage account availability behind the scenes and then we can ensure that the availability sets are going to be aligned with compute and storage, and this will overall make and reduce the burden of managing the storage accounts for customers The recommendation from Microsoft is definitely to use managed disks when possible So, to do a quick recap, the temporary drive truly is temporary We really want them to use managed disks And when we talked about that temporary drive, it’s possible to actually remap the D drive to use a different drive letter if they want to but this is something that we typically don’t recommend as this becomes a lot of extra work to take up Overall, if a customer is already using the D drive as a common drive letter on-premises, we typically recommend them to adopt using the D drive in Azure to reduce the friction and make it easier to expand in the cloud Whenever you’re working with disks that are larger than four terabytes, which is the current Azure maximum,

then we recommend using some sort of storage spaces or raid or LVM to make sure that you can create larger volumes for those disks When you’re thinking about protecting your data, we recommend using the Azure Recovery Services Vault as it provides a couple of different services for data retention for backup and disaster recovery and Azure Site Recovery, which is the disaster recovery tool is also going to be another option for them when thinking about disaster recovery for managed sites of their VMs Now, let’s transition to Identity Identity, is going to be typically a pretty big topic when customers go to the Cloud for the first time When you think about your Application and a customer is bringing a new line of Business Application in Azure and they want to use a Modern Identity Store Then they can use Azure Active Directory, and this is what we typically call something for Modern Authentication and for a Modern Application So, this opens up those two different areas, where Azure Active Directory is going to be for the Modern Authentication, where the Active Directory is just going to be an extension of their existing Active Directory, or potentially building a new force for Active Directory in Azure So, with this topic, let’s take a moment and jump back to the Azure documentation and highlight where we have some really good resources around Identity So, we are back to the “Reference Architecture” section, and this is going to be an area which is highlighting a lot of content around Identity And you’ll notice here that there is going to be a lot of information around Identity because there are a lot of different scenarios that we want to make sure customers are aware of So, the first one, integrating with Azure Active Directory is very key and Azure Active Directory is also the Identity Store which is also backing Office 365 and Microsoft Online Services When you are also thinking about your Customer’s Servers in Azure and how the servers are going to join the Active Directory Domain, then it’s very common to see customers extending their on premises Active Directory Infrastructure to Azure So this is something where we would expect the customer to build Domain Controllers they would define a new site in Azure, and then they’ll continue on as usual So depending on what your needs are, the customer should definitely be very clear and concise on the decisions that they make for Identity as these are things that are typically going to be very impactful and be very long running in terms of the decision making In overall there are some areas that you can look at in Azure, where you can potentially make some Optimization So, whenever you are looking at Active Directory Domain Services, then consider that there are potentially some alternatives So, there is a platform as a service for Active Directory Domain Services, other areas we want to think about one Business Applications in the Azure Network and they’re making calls back on premises can be very high latency and potential to degrade a performance So, this is where you really want to start thinking about building a Domain Controllers in Azure for every region that you’re located Other areas that can come up are just really thinking about when your Identity Traffic is causing a bottleneck on your Network and understanding that if you have a VPN in place that you want to make sure that your understanding what Traffic is replicating between each Site that you have And obviously very important to make sure that you always secure that your Domain Controllers These are going to be very sensitive assets to your customers environments and we do want to acknowledge that and make sure that they’re following best practices around securing them as well As Identity is definitely a good dovetail into security, there are commonly two different perspectives that we take for security One of them is, Protecting Your Identity, and another one is going to be, Protecting Your Network So, talking about the Identity This is something where it’s extremely important to protect the Identity for the users to have access to the Azure Portal If that user is an administrator in the Azure Portal and their identity is compromised, they have the ability to be very destructive in your Azure environment They could potentially access your VMS, potentially log into them, reset Passwords Even worse they could delete the Resources, Deprovisioning things or create new things in the environment that you don’t want Protecting that Identity by using tools and services like Azure, Active Directory Privileged Identity Management for good monitoring and alerting from anomalous activity and also following best practices of enabling Multi-Factor Authentication for all users that access the Azure Portal Emphasizing the security controls around Identity are going to be very important And then the other half of the security that we commonly talk about is going to be,

Protecting From The Network Perspective So overall when you are looking at your Infrastructure in the Cloud, we really want to talk about minimizing the exposure to the Internet for any of your applications As customers are going to the Cloud it’s very common for them to develop POCs in Azure And when you do that you want to deploy those in a frictionless manner and it’s very common to build VMS and have public endpoints so they’re accessible over the Internet So this might include having RTP or SSH, wide open on the Internet using the Default Ports and this is something where they are definitely prone to potential attacks So this is where you can use services like Azure Security Center to help drive recommendations and identify any Virtual Machines or any services in your environment that might be at risk because they are exposed to the Internet And this is just one of the areas that we strongly emphasize because we see it as a very large security risk and there are easy ways to circumvent this potential risk Other areas include using a Jump Box for remote connections rather than connecting directly using VPN appliances and private connections When actually accessing the VMS and Azure you can use Network Virtual Appliances to do any sort of Traffic scans or Pocket filtering that you need to And then making sure that you’re using things like Network Security Groups to manage Inbound and Outbound Traffic flows So these are going to be your Stateful Azure Firewalls that you can use in your environment If you want to use End-to-end Encryption, well you can use IP set policies and other HTTPS Encryption Policies for your Application Other areas that we want to mention that are also important for customers to also use if needed are going to be around Disk Encryption If a customer does require their Disks to be Encrypted then we do have Azure Disk Encryption as a service for them to leverage and then we also want to make sure that their are Virtual Machines and Azure still are using Anti-Malware Make sure that they’re using agents up there, whether they have the same on premises or if they want to adopt a new Anti-Malware agent for their machines and Azure just because their machines are in a secure Data Centre like Azure doesn’t mean that they should stop thinking about the security and agents that they run in their Virtual Machines as well So, here is a longer list of security recommendations that we have, not necessarily trying to read off of everything in here But overall Access Control for the customers and their environments is going to be very important, and if you do need to use anything for passwords make sure that you’re using them correctly by any Automation Script by using secure Strings so they’re obfuscated And if you have to store them, use a Password Manager or you can store them in “Azure Key Vault” if you would like as well Making sure that your Access Control has a good model for your environment to make sure that you’re not granting administrator privileges for all of your users Maybe granting them at a research group level rather than a subscription level and then also being able to grant read reader access when that makes sense as well Other areas include for the Security, go back to the Networking area where you talked about the Network Security Groups You could potentially use Network Virtual Appliances for Subnet Isolation, Packet Filtering packet inspection, and things like that Something that can be very useful, are using policies in Azure to make sure that you’re adhering to certain security postures that you have defined So certain things is could be around Data Sovereignty and only allowing you to deploy services in certain regions to ensure that your data doesn’t exist in certain countries Other things can be preventing the ability to create public IP addresses and attaching them to VMS that are in your secure zones or trusted zones So these are things where, although you want to set these policies in place for users to not make any mistakes, it’s also good for you to just set up your own protection to make sure that if anybody is going to do something malicious even if they have the access to do it, the policy will deny them as well Something else to also call out here, what I mentioned before is the Multi-factor authentication and the Privileged Identity Management, which are things that can be included as part of Azure Active Directory And overall, when you’re thinking about security, a lot of customers want to do security testing And they want to do penetration testing and Fuzz testing and many different things that they want to make sure that their application is resilient on Azure For most of our security testing, we allow customers to go ahead and do any testing that they need to The only thing that we post online, any distributed denial of service testing on your applications in Azure This is something that we defined in our rules of engagement, in our terms and conditions, which are posted publicly online and something that we strongly encourage you to send to your customer,

because we want them to test their application But we want to make sure that they’re testing it in the ways that we expect them to, because we don’t want to inadvertently shut anything down on their behalf So now let’s take a moment and talk about designing Virtual Machines And when you start looking about Virtual Machines, this is typically a big gateway into what your workloads are actually going to be running in the Cloud So, a lot of the customers they already have many Virtual Machines On-Premises and they’re talking about migrating them to Azure And one of the first things that always comes up is, how do you size your virtual machines? And this is something that’s very important because Azure is going to provide you a lot of different compute SKUs And within the SKUs, you have many different sizes available to you So when a customer first comes to Azure, this can be something where you have a lot of options And you really want to help them go down the right path in terms of picking the ones that are going to fit their needs So for example, if a customer says, “Hey, I have an application and these VMs, they require two cores in eight gigabytes of memory.” And if you look in the Azure documentation, we have several VMs that have two cores and eight gigs of memory And when you go on that, we also want to highlight that there are differences between the VM skews So, for example, we have the D-Series Virtual Machines which are our general purpose virtual machines But then if you look at the same metrics for CPU and memory on the N-Series VM, you’re really not going to be getting the same thing because the N- Series are going to be backed by Nvidia graphics cards and that’s going to be for a different use case So making sure that your customer knows which CPU families are going to be available to you and being able to go down which path for different use cases is going to be the first step on sizing for their VMs The next one is also about right sizing In Azure, we don’t have the ability to custom tune the number of Virtual CPUs and memory that you have for your machines The customer has to choose from the predefined list that we have for them So although the list is very large, if they’re looking for something very specific around four cores and 13 gigabytes of memory We really want to make sure that the customer is talking about how many of your resources do you actually require Because some customers do over allocate On-premises and they might not be incentivized to rightsize it the best they can On-prem So when you go to Azure, a lot of customers see value in shutting down their Virtual Machines And that is something where you can get a good cost saving, that is a very obvious one Another one is also rightsizing it to what they actually require and you can see a lot of cost benefit in the long run as well Doing this is something non-trivial for customers and they might need assistance in terms of tooling that we have, and we have Azure Migrate, which is a service which you can deploy in your On-premises environment and it will scan your VMware, VMs, and develop a profile and rightsize the VMs for Azure So this is something where you can help work with your customer on this and help enable them to make sure that they have a good environment where they feel comfortable for the sizing of their VMs as they move to Azure Beyond sizing, availability is going to be very important And this is really where your customer is going to be able to receive an SLA on the uptime of their Virtual Machine So when we look at availability, we definitely want to make sure that they’re using Managed Disks to make sure that they’re highly available from a compute and storage perspective And then we want to make sure that they understand the different options for how they get an SLA Typically, we always want to have a customer deploying two or more virtual machines in an availability set to receive an SLA of 99.95 And if a customer is in a situation where they can’t deploy their application with two virtual machines and they can only use one, then this is when you can use a virtual machine only using premium storage And then you will get an SLA of 99.9 And so, as you see there will be a release with availability zones to also get an increased SLA in the future So this is something where we want our customers to be ahead of as we want to make sure that their availability and resiliency is definitely top of mind for their application Also thinking about your Virtual Machines, this is also going to play in terms of your virtual network as you’re going to be working with your private and your public addresses And when you’re thinking about your Virtual Machines, all of your VMs are going to get a private IP address and then you want to identify which machines are going to be eligible for a public IP address and which ones should not And this is going to help get your design going for your customers Virtual Machines Other areas that you want to consider in terms of what are the specific settings that are required for Azure and some areas in here are really going to be about the location, the resource group, the disk sphere VMs Why do you want to think about a storage account for your VMs as well?

As I mentioned earlier you don’t have to use storage accounts to manage your disks for VMs, but you still might use storage accounts for your logs, for example So you might have your diagnostics logs in your boot diagnostics stored to a storage account to make sure that you can still gather your performance metrics across your machines So although the customer doesn’t have to manage the storage account for their Virtual Machine disks anymore, they will likely still have a storage account for their logs Other areas include the network in terms of what Virtual Network and what subnet it goes into, the availability set And then also for high availability and then distribution of traffic, their VM might be placed in a load balancer and they’ll be in a load balance set with other machines Specific things around the Virtual Machine itself are going to be the name of the Virtual Machine, which will be the name of the VM resource and this will also typically be the hostname or the computer name of the actual server And then other areas will include the image which includes the publisher, the offer, and the SKU, which is going to be the option that they choose in the Azure portal for what operating system that they’re using For example, if you’re deploying a Windows server, then Microsoft is going to be the publisher there and then you can build a Windows Server 2016 data center and then it will likely come with the latest patches that have come out So depending on what they’re deploying they could be using Linux distribution as well, and overall we recommend using the gallery images that are available by the respective publisher, but in certain scenarios they might require a custom image where they have to create it themselves So although that is an option for them, they do have to go through the traditional image in patch management for those VMs So we typically like to see customers use the ones directly out of the gallery Of course you have to choose the size, the additional disks, and then going back and picking your private versus public IP addressing So now let’s start talking about the deployments in Azure So, when a customer gets to the point where they’re deploying their Virtual Machines and they’re deploying at scale, we typically don’t like them seeing deploying them through the portal The portal is going to be a great place for them to start in terms of their on-boarding for the first time and they’re going through POCs and they’re learning After that, we typically like to see them automating a lot of this process It reduces the ability of human error and it will likely save them a lot of time and enable a lot more functionality when using any sort of automated tool sets So examples in here can be using Azure PowerShell, the Azure CLI, ARM templates, or any other automated platform where you hit the Azure Rest API to deploy these Azure resources There are other very common tool sets around like Desired State Configuration, or other partner tools which are common to Chef and Puppet to help configure VMs in terms of a post provisioning process As I mentioned before we recommend using the Microsoft images rather than creating your own when a customer requires it Whenever you’re looking at your deployment you also need to consider your Azure enrollment all up And this goes back to the subscription management and everything that lives above this And this is just understanding that when you’re deploying things in Azure for the first time and they’re going to be in your production environment and going to be long lived, it’s good to understand who your enterprise administrators are, who your service administrators are, and knowing that the enterprise administrators are going to be the people at the very top who have the access to create the Azure accounts and delegate access to the Azure account owners, which are then the people who will be able to then create Azure subscriptions and then be able to specify the service administrator which is going to be a sole owner of that Azure subscription So, making sure that they’re following those patterns and practices and ensuring that they have a good model going forward, is going to be essential before they start deploying everything into their production environments in Azure Something else that’s very important that we called out is making sure that your customer is aware of the service limits that are tied to your Azure subscriptions as some customers might not hit these limits anytime soon And you will notice that a lot of the limits in Azure are being increased to very very high numbers which are potentially hard to achieve but we definitely have a lot of very large customers and they will probably be in a situation where they will hit these limits So this is something that you want to make sure your customer is out in front of as they don’t really want to get back into a corner where they’ve hit a hard limit and they have to make a change which is potentially very disruptive So these limits are posted publicly online and this is something that we want to make sure that you share with your customers and that you incorporate into your design whenever building and deploying your applications To take a quick review of one of what we’ve done Hopefully this will enable you to ask the correct questions for your customers to really understand what they’re trying to do for the line

of business applications, and then you can really help drive some of the key elements around governance and the other technical areas that will help them thinking in a cloud first world, and then help modify, or move, or build new applications in the cloud in their Azure environment Overall, we really want the customer to really think about this as a methodical process that they can reuse every time that they’re building and Azure especially for the first time and then also as they’re bringing new applications on board Thank you very much