Office 365 SaaS Networking Day 2 Session 2

Agenda Network Connectivity to SaaS and IaaS ExpressRoute in the Context of SaaS and IaaS Understanding Office 365 Connectivity Inbound and Outbound Flows Key Challenges and Considerations Design Considerations

… in lieu of an introduction… Our goal is great Office 365 cloud service experience for customers Cloud ready customer network connectivity is a key enabler for this goal There is strong correlation between service experience and connectivity between end users and service Connectivity to the cloud is a distributed, end to end proposition that spans layers of the stack, different parts of enterprise topologies and requires tight collaboration between customer teams/organizations Key to success: understanding what different elements of SaaS cloud connectivity are/are not and choosing the right tools meeting customer requirements to solve the right problems

Cloud Connectivity Layers Application Cloud services endpoints and URLs On-premises application services topologies (including hybrid) Application and client requirements (e.g. QoS, latency) Security Network perimeter controls (network zones, firewalls, proxies, etc) Inbound and outbound flow policies Transport Internet OnNet ISP peering - https://www.microsoft.com/peering ExpressRoute peering - https://azure.microsoft.com/services/expressroute/

Understanding Connectivity to SaaS vs. IaaS Principle: Type of cloud service defines type of required connectivity SaaS (e.g. Office 365, CRM Online, etc) IaaS (e.g. Azure VM/VNET) Customers consume features Primarily user facing Focused on user collaboration experiences across boundaries Optimized for standardization Multi-tenant service endpoints Public interfaces Per tenant isolation at the application level Cloud controlled URLs and IPs (O(100s) - rate of change is high) Customers build solutions Primarily IT facing Focused on customer specific solutions within boundary Optimized for customization Multi-tenant infrastructure Private (and public) interfaces Per tenant isolation is at the infrastructure virtualization and network levels Customer controlled URLs and IPs (O(1s): rate of change is low) Cloud ready customer connectivity to SaaS and IaaS: common infrastructure investments, common framework, differentiated setup Both Internet and ExpressRoute are capable of provide connectivity to SaaS and IaaS through one common framework, but end to end setup, optimization and customer security controls, will depend on the target service

ExpressRoute and Microsoft Clouds 8/29/2018 2:53 AM ExpressRoute and Microsoft Clouds Within ExpressRoute circuit, there are several distinct routing domains Customers often treat IaaS (1) and SaaS (2) routing steams differently from security/connectivity perspective Networking for #1 (Private peering) Networking for #2 (Public peering) Private endpoints/IPs Public endpoints/IPs Target networks instanced and isolated per customer Target network shared across customers and services Extension of customer Intranet External to customer Intranet Typical #IP prefixes: O(100’s) O(1’s) Typical # IP Prefixes: O(1’s) O(100’s) “There's something very important I forgot to tell you. Don't cross the streams.” [Spengler] Key design question: how are #1 and #2 handled and where they are terminated on the customer side? © Microsoft Corporation. All rights reserved.

Connecting to Office 365 – Mindset Type of connectivity is defined by type of the cloud service Connectivity type (path) doesn’t change the nature of the service Level of trust in the service is fundamental Level of desired [network/security] controls is driven by the level of trust Office 365 is not the Internet. It is an extension of your core services. Microsoft controls Office 365 (features, security, compliance, SLAs) You control Office 365 (where from and who can connect to your Office 365 data, what goes in and out, what is and is not allowed) Accessing Office 365 through the Internet is not the same as allowing uses access Internet Different cloud services and components may have different level of trust in customer’s view Review Office 365 architecture and components to drive your own assessment Many controls are natively available within Office 356 features set, so you don’t have to build them all at the network layer Control Depth, Cost, Complexity Level of Trust Office 365 Services Generic Internet Destination Managed Intranet Resource

Understanding Connectivity to Office 365 SaaS Direct Connectivity Key points: For Office 365 services #4 is a subset of #2 above. See http://aka.ms/o365endpoints Office 365 experience comes from many places and is always a combination of connections over #1, #2, #3 and optionally #4

Key Considerations for Office 365 in the ExpressRoute Context Starting point is always #1, #2, #3 Office 365 services are optimized for Internet based delivery and require #1, #2, #3, even if ExpressRoute is in place ExpressRoute offers an alternate network path (#4) for a subset of Office 365 flows that follow #2 Based on dynamic BGP advertisements of specific subnets with Office 365 services Allows customers to design a more preferred connectivity path for supported Office 365 services Architecturally, from on-premises network perspective ExpressRoute for SaaS is a (dynamic) ‘path override’ Can be done at layer 3 (routing) or layer 7 (proxying), depending on customer on-premises network

Key Considerations for Office 365 in the ExpressRoute Context Connectivity type (path) doesn’t change the nature of the service it connects to Public endpoints remain public, even if the path to them is over dedicated circuit Office 365 is a global service Tenant location is mostly a ‘data at rest’ concept Collaboration experiences may direct user connections to service endpoints outside of user or customer tenant locations ExpressRoute for Office 365 requires premium SKU Office 365 relies on outbound (On-PremisesCloud) and inbound (CloudOn-Premises) flows Both need to be planned separately as they have different dependencies and often different customer requirements (based on the level of trust)

Inbound traffic (Cloud  On-Premises) 8/29/2018 2:53 AM Inbound traffic (Cloud  On-Premises) Inbound traffic: endpoints that you configure on-premises that Office 365 may need to establish connections to. Examples include: ADFS/STS for credential validation for clients that don’t support federated authentication natively Exchange Server Hybrid deployments E-Mail from Exchange Online tenants to on-premises hosted domains SharePoint Online sending E-mail to an on-premises host SharePoint Federated Hybrid Search/BCS Skype for Business Hybrid and/or Skype for Business Federation Skype for Business Cloud Connector Inbound flows have higher risk of breaking if ExpressRoute is enabled and end to end topology requirements are not met Adding inbound flows into ExpressRoute scope is generally more complex and additional requirements apply. Default recommendation: leave them over Internet © 2013 Microsoft Corporation. All rights reserved. Microsoft, Windows, and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

Key Considerations for Office 365 in the ExpressRoute Context Presence of both #2 and #4 represents routing path duality between customer networks and Microsoft networks Path asymmetry is a common failure mode during ExpressRoute deployment and runstate Enterprise customer and Microsoft networks are both distributed Public vs. ExpressRoute path distance/latency needs to be looked at as an NxM matrix High availability considerations should include MTBF, MTTR and blast radius for the full spectrum of micro and macro failure modes Customer topology designs for ExpressRoute connectivity to Office 365 must not reduce end to end service availability

Path Symmetry Outbound flows Inbound flows 8/29/2018 2:53 AM Path Symmetry Outbound flows Must ensure that the outbound NAT does not use the same IP blocks for multiple network paths. Otherwise response packets will not be returned. The NAT IP pool advertised to Microsoft must not be advertised to the Internet. This will break connectivity to other Microsoft services. Inbound flows Must ensure that inbound traffic is responded to on the same network route as the request was received on. Must not be ‘Internet and ExpressRoute’ or ‘ExpressRoute circuit 1 and ExpressRoute circuit 2’ You should NAT traffic destined to IP addresses within your network from Microsoft. * NAT in all of these discussions = source IP NAT © 2013 Microsoft Corporation. All rights reserved. Microsoft, Windows, and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

Network Design Considerations for ExpressRoute for Office 365 8/29/2018 2:53 AM Network Design Considerations for ExpressRoute for Office 365 Have explicit problem statements and design goals based on requirements An implementation project is required Plan for service access to be split between ExpressRoute and Internet Plan client LAN routing (Client PAC / Default Route / Proxy Servers / Explicit Route Advertisements) Plan and Design the depth and the breadth of propagation for IP prefixes received from ExpressRoute Plan for bandwidth, security, high availability and failovers Plan deployment in detail Plan for network cutovers Stage the network and service onboarding Include testing and a rollback plan Asynchronous route preparation Do not use the same NAT pool for Internet and ExpressRoute SNAT all inbound connections from Microsoft © 2013 Microsoft Corporation. All rights reserved. Microsoft, Windows, and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

Summary Network Connectivity to SaaS and IaaS ExpressRoute in the Context of SaaS and IaaS Understanding Office 365 Connectivity Inbound and Outbound Flows Key Challenges and Considerations Design Considerations

© 2016 Microsoft Corporation. All rights reserved © 2016 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.