# Recommendations
Now that you have a foundational understanding of single cloud, hybrid cloud, and multicloud, this section provides detailed recommendations for choosing a model.
+ [Select a primary, strategic cloud provider](primary-provider.md)
+ [Establish a CCoE](establish-ccoe.md)
+ [Differentiate between SaaS applications and foundational cloud services](saas-apps.md)
+ [Establish security and governance requirements for each cloud service provider](security-governance.md)
+ [Adopt cloud-native, managed services wherever possible and practical](managed-services.md)
+ [Implement hybrid architectures when existing, on-premises investments incentivize continued use](hybrid-architecture.md)
+ [Reserve multicloud only for workloads that can't meet their technical or business requirements through a single cloud provider](multicloud.md)
# Select a primary, strategic cloud provider
Cloud adoption provides a wealth of benefits that are essential to IT modernization, cost-effectiveness, and innovation. However, adopting cloud technologies beyond limited SaaS applications can introduce challenges that educational institutions must carefully plan through to avoid unnecessary cost and complexity. The technological and business changes involved in implementing workloads in the cloud require staff enablement and adjustments to core infrastructure, including networking, security, governance, and operations.
The best approach for addressing these challenges effectively, especially if your organization is in the early stages of its cloud journey, is to select a primary, strategic cloud provider to support the majority of your workloads. Begin with a focused adoption that's centered on that provider so that you can simplify and accelerate the realization of cloud benefits. Selecting a primary cloud provider is not an exclusive, irreversible decision. It enables your organization to evolve your cloud adoption iteratively. You can begin by focusing on a few services and then expand into other cloud services as and where needed, without delaying the overall benefits of the cloud. This approach maximizes your organization's ability to take advantage of a provider's capabilities, concentrate and develop employee skills and third-party partner relationships, and simplify vendor management.
We have seen customers embark on their cloud journey by trying to concurrently adopt multiple cloud providers but later regret that decision and the complexity it introduced. Gartner shares this insight in their article, [6 Steps for Planning a Cloud Strategy](https://www.gartner.com/smarterwithgartner/6-steps-for-planning-a-cloud-strategy), in which step 2 is "Prioritize a primary provider in multicloud architectures."
Each cloud provider introduces different operating and support models, identity and access management, networking, operations, compliance capabilities, and more. **It is better to master one cloud provider's operating model at a time. **You can then incorporate additional cloud services iteratively and incrementally, where rationalized. Many factors can influence your decision to adopt a primary cloud provider, but use the following key questions to guide your choice.
+ **What breadth and depth of services does the provider offer?**
Different cloud providers offer different services. At a minimum, make sure that your primary provider has the capabilities necessary to support all your functional requirements as well as your cross-cutting, operational needs such as security, governance, and automation. Select a provider that delivers these capabilities with a proven track record of innovation and operational excellence. Consider not only your applications, but also your data. Think about future data integration and transfer patterns to limit the cost, latency, and complexity of moving large amounts of data between providers. Choose a provider that has the greatest possible breadth and depth of services to satisfy your current application and data needs, and also to unlock new use cases that can meet your institution's needs as they change over time.
+ **Can the provider support all your security and compliance needs?**
In education, security and compliance are critical to any technology deployment. Choose a cloud provider that is able to meet all your security and compliance needs. Tools such as [AWS Artifact](https://aws.amazon.com/artifact/) can help you evaluate providers by offering a central resource for on-demand access to security and compliance reports. Consider not only the security and compliance of the cloud provider's own infrastructure and services, but also how easy it is for you to architect secure, compliant solutions by using those services. Prefer a provider that offers some combination of prebuilt solutions, quick starts, and prescriptive guidance to accelerate your secure adoption of the cloud.
+ **Does the provider have a robust partner network?**
No organization undergoes cloud transformation alone. To accelerate adoption, you should use the services and expertise of the cloud provider as well as their partner network. This network includes technology partners who provide software that runs on, integrates with, or supports cloud technology, as well as consulting partners who can help you design, build, run, and manage your own applications in the cloud. You will find that many educational technology providers, independent software vendors (ISVs), consultants, and resellers that you already work with are members of the cloud provider's partner network. Prefer a cloud provider that has the most robust network of partners with vetted competencies. Having partners with proven industry and technical expertise is critical.
+ **What support and enablement does the provider offer?**
To successfully adopt any new technology, you need mechanisms to request training and help, including best practice recommendations, configuration guidance, and break-fix problem resolution. Choosing a cloud provider that offers strong support and training options will set you up for success. Explore the provider's official support model and resources as well as any available third-party or community-based resources such as blogs, forums, videos, and how-to guides. Consider not only the provider's technical support programs, but also programs that focus on business and cultural transformation. For example, the [AWS Cloud Adoption Framework (AWS CAF)](https://aws.amazon.com/cloud-adoption-framework/) helps organizations digitally transform by focusing on perspectives that include business processes and people, not just technology. Prefer a cloud provider that offers extensive training options and a proven, reliable support model and community.
# Establish a CCoE
Consider evolving your cloud leadership function through a transformation office or a [Cloud Center of Excellence (CCoE)](https://docs.aws.amazon.com/whitepapers/latest/public-sector-cloud-transformation/building-a-cloud-center-of-excellence-ccoe-to-transform-the-entire-enterprise.html). A CCoE develops and evangelizes an approach for implementing cloud technology at scale across an organization. For successful cloud adoption, design your CCoE to include representatives who can speak for the teams and departments involved. Start small and incrementally evolve the CCoE to meet your needs as you progress through the transformation journey. Your primary cloud provider representatives, such as your AWS account manager and solutions architect, can provide resources to guide you through the creation of your CCoE. A CCoE accelerates your ability to establish subject matter expertise, achieve buy-in, earn trust across your organization, and establish effective guidelines for meeting your mission requirements. There is no single organizational structure that works for every institution, but the following questions will help you design your own CCoE.
+ **Who should you include in your CCoE?**
At its inception, a CCoE might include only a handful of early adopters and cloud champions. The CCoE might remain small, but it should evolve to include champions who can speak for both the business functions and the technical functions that are affected by cloud adoption. Business functions include change management, stakeholder requirements, governance, training, procurement, and communications. These functions are usually represented by members of your institution's administrative and instructional teams. Technical functions include infrastructure, automation, operational tools, security, performance, and availability. These functions are usually represented by members of your institution's IT teams. The CCoE should also seek to involve vendors and partners, as necessary, to provide subject matter expertise. The CCoE is a living organization. Its membership, form, and function will likely change over time, and it might even disband at some point of future maturity.
+ **How does the CCoE interact with its stakeholders?**
The CCoE is in service to other teams and is intended only to inform and enable successful cloud adoption. Look at embedding parts of the CCoE in various departments, schools, and functions. This enables access to a wider range of resources and faster internal feedback. Focus on building partnerships and open lines of communication between stakeholders early on to establish trust within the institution and break down organizational silos. The CCoE should have defined mechanisms for communicating with stakeholders, gathering feedback, and training users. The CCoE's success metrics should reflect such collaboration and communication. If a team is measured only on building technology, more technology will be built, but its use and outcomes will become an afterthought. Your metrics should instead measure things such as the number of teams that become self-sufficient through the CCoE's work, the number of times the CCoE is on the critical path for initiatives, the number of training events held, or the breadth of adoption of the CCoE's output. A well-constructed, trusted CCoE can be a stepping stone to a larger organizational transformation that is built on trust.
+ **How should you establish a CCoE?**
Most organizations start their cloud adoption with specific, targeted pilot projects. Establish a CCoE as part of these projects. A good start is critical in defining the success of the whole journey.
+ **Start with a business problem.** Technology for the sake of technology is a bad strategy. If you are experimenting with cloud technologies, identify a compelling business use case no matter how small it might seem. Then, work back from that use case to set clear goals on how technology can help. Do not implement the solution in a silo. Take constant inputs from business stakeholders before and during project implementation. All successful cloud projects rely on close collaboration with the institutional units that will use the technology.
+ **Start small.** Choose a low-risk project that provides a two-way door. This means that the project is reversible and any mistakes can be quickly corrected. Pilot projects are all about experimentation. Avoiding large-scale, high-risk projects gives you better control over implementation and results. It helps to target specific, definable problems instead of broad-based goals. For example, if automation is the ultimate goal, aim to automate specific tasks instead of entire jobs.
+ **Define and measure the outcome.** Set clear metrics to assess the progress and performance of each project. Define the desired end state well in advance to avoid mismatched expectations among stakeholders. Work closely with business stakeholders and other leaders within the organization to define expectations and measurable gains. It is also important to translate the results into non-technical language. Talk in terms of institutional goals, such as how the project improved retention and reduced churn, how it lowered costs and increased the speed of delivery, and so on.
+ **Start from the comfort zone.** Choose a project within a domain that your institution is familiar with. This way you can ensure that the project has meaningful, understandable goals with real impact. Such a project will build confidence and have greater long-term results for your organization. For example, if you already have expertise in data analytics, you can kickstart your cloud journey while leveraging your existing skill set by starting with an analytics project. Every institution has different expertise and needs to find its unique components to craft a successful digital transformation strategy.
# Differentiate between SaaS applications and foundational cloud services
Most educational institutions have already adopted software as a service (SaaS) applications. SaaS provides your institution with a complete solution that is run and managed by the service provider. Common SaaS applications include productivity applications such as word processing and email, but SaaS options also exist for many mission-critical workloads such as enterprise resource planning (ERP), student information systems (SIS), and learning management systems (LMS). When your institution adopts a SaaS offering, your IT team doesn't have to think about how the service is maintained or how the infrastructure is managed―your users simply consume the service. This delivery model reduces the management burden on your IT staff. Many institutions choose to adopt a "SaaS first" approach in their IT strategy, especially if their IT teams lack the time, resources, or skill sets to sufficiently self-host the same application. Even if you have the resources to self-host, it might still be more cost-effective to adopt a SaaS solution and invest in other projects instead.
When you use SaaS applications, your IT team doesn't have to manage the underlying infrastructure, so where the vendor hosts the application (on-premises data center, your primary cloud provider, or an alternate cloud provider) becomes less important. After you choose a primary, strategic cloud provider, you might opt to use a SaaS offering that's hosted in another cloud provider or on premises, in the vendor's data center. Conversely, even if your SaaS applications are hosted in one cloud provider, you might choose a different primary, strategic cloud provider based on the strength of that provider for your non-SaaS workloads. The distinction between hosting environments is less important for SaaS than it is for self-hosted applications. However, you should still consider the following key questions when evaluating how SaaS fits in with the cloud as part of your IT strategy.
+ **Is the SaaS application highly available and scalable?**
Many vendors have already made the decision to adopt the cloud for their SaaS offerings. In doing so, the vendor is able to achieve the cloud benefits of increased availability and scalability. Furthermore, because the vendor can adopt the shared responsibility model of the cloud instead of managing and maintaining physical infrastructure, they can invest more time and resources into the delivery of new features. Because of these benefits, you should prefer providers that are cloud-first and offer cloud-hosted solutions.
+ **Can the SaaS application meet your security requirements?**
When evaluating SaaS, it is important to know what data the application stores, how that data is used, and which security controls are in place to protect that data. Although you might not have direct control over data storage as you would in your own, self-hosted environment, you should ensure that the vendor has mechanisms and controls in place to handle your data appropriately. Be aware of which security features are built into the SaaS solution and which features require additional configuration. The cloud enables SaaS providers to build more available and scalable solutions, and they can also build more secure solutions because of the [shared responsibility model](https://aws.amazon.com/compliance/shared-responsibility-model/). You should prefer providers that are taking advantage of cloud security tooling and services as part of their solutions.
+ **Who owns the SaaS application data and how can you access it?**
When you use SaaS, you trust the provider to properly handle your institution's data. Be sure to review the terms of service and service-level agreements for SaaS applications to understand contributing factors such as data ownership, availability, and durability. Evaluate the mechanisms for backing up or exporting your data; these are especially important in case you decide to switch providers or the provider ceases service.
+ **Can your other services and self-hosted applications integrate with the SaaS application, regardless of the environment?**
When adopting a SaaS solution, it is easy to assume that services and applications that share the same hosting environment (that is, applications that use the same cloud provider or the same vendor's data center) will have a more seamless integration. However, most SaaS solutions today have broad support for API and third-party integrations, so don't limit yourself to solutions that are hosted in the same environment. If the necessary integrations exist, the solutions don't have to share the same underlying environment. For example, let's say that you're using a SaaS solution such as Google Drive or Microsoft OneDrive for cloud-based student file storage. To provide virtual desktops and application streaming to your students, you might determine that [Amazon WorkSpaces Applications](https://aws.amazon.com/appstream2/) is the best fit for your requirements. Although these services run in different environments, WorkSpaces Applications has native integrations with Google Drive and Microsoft OneDrive, so your students can continue to use their existing storage.
+ **Does the SaaS application support centralized identity management?**
To prevent your IT team from having to manage disparate identity stores and your users from having to remember multiple sets of credentials, make sure that your SaaS solutions support integration with your existing identity management or single sign-on solutions. Fragmented identity management decreases productivity and can lead to bad security practices such as privilege creep and weak passwords. If your desired SaaS solution doesn't support single sign-on or your existing identity store, evaluate whether the business value of adopting the solution outweighs the increased burden on users and staff.
+ **How can you secure network communication with the SaaS application?**
In some cases, you might need a self-hosted application to communicate with a SaaS application. Typically, this communication will be through APIs that are secured with appropriate authentication and authorization mechanisms. However, depending on the hosting environments of the two applications, alternate or additional mechanisms might be required to simplify or secure that communication. For example, if you self-host an application with a cloud provider and need to integrate it with a SaaS application that's hosted on the same cloud provider, the vendor might provide several connection options. You might be able to use cloud-specific peering connections, private APIs, or private interfaces such as [AWS PrivateLink](https://aws.amazon.com/privatelink/) to prevent that communication from traversing the public internet. Similarly, if your on-premises application has a dedicated network connection to a cloud provider through a service such as [AWS Direct Connect](https://aws.amazon.com/directconnect/), you could use that same connection to communicate with SaaS applications that are hosted on the same cloud provider.
# Establish security and governance requirements for each cloud service provider
Educational institutions have a variety of compliance, governance, and cybersecurity objectives that they must achieve. The risks of failing to meet these objectives can include institutional reputation loss, monetary fines, ransoms, sensitive data breaches, intellectual property theft, and degraded or complete loss of mission-critical functions. Because of the [shared responsibility model](https://aws.amazon.com/compliance/shared-responsibility-model/), institutions that adopt cloud services can reduce administrative burden by offloading some of the responsibility for infrastructure security to the cloud service provider. Furthermore, you can benefit from purpose-built, cloud-native security services that offer features that are often unavailable, difficult to manage, or cost-prohibitive in an on-premises deployment. Examples include services such as [AWS WAF](https://aws.amazon.com/waf/) for web application protection, [AWS Shield](https://aws.amazon.com/shield/) for distributed denial of service (DDoS) protection, and [Amazon GuardDuty](https://aws.amazon.com/guardduty/) for threat detection. A successful cloud security and governance strategy allows IT and security teams to focus on building systems that are secure by design, helps the institution rapidly adapt to evolving mission requirements, and provides faculty and researchers with secure environments for ground-breaking learning and innovation. To evaluate your security and governance requirements, consider the following key questions.
+ **Which compliance frameworks must your workloads align to?**
Educational institutions must adhere to many compliance frameworks because of the multitude of stakeholders and workloads they support. These compliance frameworks include the Family Educational Rights and Privacy Act (FERPA), the Health Insurance Portability and Accountability Act (HIPAA), the Federal Risk and Authorization Management Program (FedRAMP), the Cybersecurity Maturity Model Certification (CMMC), the International Traffic in Arms Regulations (ITAR), the Criminal Justice Information Services (CJIS), and the Payment Card Industry Data Security Standard (PCI DSS). In some cases, such as with CMMC, research grant funding isn't released until the relevant workloads are certified as compliant. Each framework is unique and might apply only to a subset of workloads. Make sure that you know which workloads must adhere to which requirements and that you are able to achieve those requirements in each workload's environment. In cloud environments, make sure that you understand your responsibilities compared with the cloud provider's responsibilities. You should have the knowledge, resources, and skill sets that are necessary to achieve and maintain compliance.
+ **Which mechanisms do you have in place to enforce compliance across multiple cloud providers without inhibiting innovation?**
If your academic institution is new to the cloud, we recommend that you select one primary strategic cloud service provider and focus on understanding how to architect, engineer, and operate cloud environments that are secure by design. Ideally, security controls that are automatically embedded within self-service systems allow users to rapidly deploy secure cloud environments with a minimum amount of intervention from IT teams. Focusing on a single provider limits the amount of resources and time you must invest to ensure security and compliance. The most successful institutions select a cloud service provider that can support the majority of compliance requirements, has a robust network of partners, offers prebuilt compliance solutions, and makes secure self-service automation available. If you must ensure security and compliance across multiple cloud providers, additional investment will be required to build the skill sets and resources to manage compliance for each environment. If each cloud provider uses a different foundational environment, or landing zone, you need to understand which compliance standards and requirements each landing zone can support, and this might determine whether certain workloads can be hosted on that provider. You might manage compliance for each provider separately or use custom-built or partner solutions that can centralize management across providers. [AWS Marketplace](https://aws.amazon.com/marketplace) provides turnkey solutions that can also meet your compliance requirements.
+ **How can you assess and control cost and usage across multiple cloud providers?**
If your academic institution is new to the cloud, we recommend that you establish cost visibility and control mechanisms to gain insight into which cloud services are being used, who the cloud resources belong to, what the purpose of those cloud resources are, and what potential cost savings can be achieved by optimizing consumption. Institutions can achieve significant return on investment by partnering with their cloud service provider to migrate and modernize mission-critical systems, because they can negotiate enterprise-level agreements, benefit from volume pricing, and take advantage of the cloud service provider's expertise. If you must control cost and usage across multiple providers, consider how you can aggregate and analyze cost and usage from each provider, either with in-house processes and tooling or by using partner solutions. Many organizations are starting to identify cloud financial operations (FinOps) as a key function and dedicating resources to evangelizing and implementing capabilities for cloud cost management and optimization.
+ **Do you have mechanisms in place to easily manage user permissions over time?**
We recommend that academic institutions understand core stakeholder needs when they first approach the cloud. Users of institutional systems include students, faculty, researchers, IT staff, administration, security, the general public, and third-party collaborators. You should identify the core needs of these users and make sure that you have appropriate mechanisms in place to grant them access to cloud services. Different types of users require different types of access to cloud services. For example, students, faculty, and the general public need access to applications; IT staff, administrators, and security need access to cloud infrastructure; researchers and their third-party collaborators need access to secure research environments; faculty need access to secure teaching environments and might even want to provide students with hands-on access to cloud technologies. You should have tooling in place to [centrally manage these identities](identity-sso.md) in an automated way, and use established processes to identify, grant, and revoke permissions as roles and responsibilities change over time.
+ **Do you have mechanisms in place to appropriately integrate new systems with your identity management solution?**
We recommend that academic institutions make it easy to integrate new systems with their identity management systems. This gives the institution the flexibility to support a variety of mission-critical functions by allowing stakeholders to procure and build systems that can easily be integrated into the identity management system. By simplifying the integration process, stakeholders will be less likely to use their own access control measures, which might not enforce security best practices such as single sign-on, passkeys, and multi-factor authentication (MFA). Make sure that your identity management system can interoperate with the necessary systems through native integrations or industry-standard protocols.
+ **Do you have mechanisms in place to enable effective incident detection and response?**
Educational institutions are frequently the target of cyberattacks and ransomware. To help detect and respond to such incidents effectively, we recommend a bifurcated approach:
+ Focus your efforts on preventative measures in the form of security controls that are automatically embedded in cloud environments.
+ Implement detection capabilities that help cyberincident responders detect, contain, and mitigate security breaches in a timely fashion.
As with compliance, you must ensure that you have the resources, skill sets, and tools to detect, prevent, and respond to events in each environment. By focusing on a single, primary cloud provider, you can limit the resources that are required. Academic institutions that do not have a mature security operations team should look to independent software vendors, managed detection and response providers, and cybersecurity consultants for help in these areas.
# Adopt cloud-native, managed services wherever possible and practical
When you initially consider how to take advantage of cloud services, using infrastructure services and development tools that your teams are familiar with might seem like the best path forward. However, selecting cloud-native managed services, especially serverless options, can greatly reduce cost, effort, and complexity.
Cloud-native, managed services eliminate many of the undifferentiated IT tasks that require time and effort from your staff that could be better spent on mission-focused activities. In addition, as providers improve the capabilities of their services, your solutions naturally inherit incremental improvements in efficiency, security, resilience, performance, and other characteristics. For example, a fully managed database service is a feature-rich relational database management system, but you don't have to provision and manage the underlying server and operating system that the database runs on. This eliminates administrative tasks that are typically required when you maintain a relational database in your own data center or on a self-managed virtual server that you provision in the cloud. The following diagram illustrates this difference.
![\[Comparison of responsibilities for self-managed and fully managed database services\]](http://docs.aws.amazon.com/prescriptive-guidance/latest/strategy-education-hybrid-multicloud/images/db-services.png)
The benefits of eliminating infrastructure management are clear when you compare any cloud-native managed service against a comparable self-managed approach. As a result, whenever you need to deploy components that your purchased or custom-developed applications will run on, you should use cloud-native, managed services to reduce time and effort.
When your team is responsible for building, deploying, or managing solutions in the cloud, use cloud-native, managed services to take full advantage of your cloud provider's differentiated capabilities and innovations. This strategy enables you to select, integrate, and deploy cloud services in a way that reduces the time and effort that these projects require, while increasing their resilience and security. For a successful cloud strategy, consider adopting these cloud-native *building blocks* when you migrate custom solutions to the cloud, develop new solutions in the cloud, or deploy licensed software on the cloud. When you evaluate options for cloud-native, managed services, consider the following key questions.
+ **Do you need to focus more of your staff's time and effort on functionality that's core to your educational mission?**
Managing servers, even virtual ones, requires time and attention to ensure that they remain up to date with system software upgrades and patches. Using managed services that handle these tasks for you lets you direct IT staff time toward activities that align more directly to your institution's mission. For example, if you need to deploy containers, consider a serverless, managed service such as [AWS Fargate](https://aws.amazon.com/fargate/) so that you do not have to configure and maintain servers. By eliminating the need to procure, provision, and manage the underlying infrastructure, you are able to focus instead on delivering new functionality, optimizing performance, and improving user experience. Consider this benefit when you evaluate managed services against self-managed options.
+ **What effort will it take for your team to adopt cloud-native managed services?**
There can be a learning curve to designing and implementing solutions with cloud-native, managed services, but these efforts will be repaid with reductions in cost, time, and complexity over the lifetime of a solution. Because of the on-demand, pay-as-you-go nature of cloud computing, cloud-native services enable you to quickly iterate and experiment in a more agile way while avoiding upfront investments. This leads to increased innovation and shorter project timelines. However, to realize these benefits effectively, consider what might be necessary to adopt and use the service, such as staff training on optimal usage patterns and code refactoring to accommodate service-specific APIs. Even if the service uses industry-standard or open source APIs, you might need to refactor or configure your application to handle feature disparity or version mismatches.
+ **How do you currently deploy and manage infrastructure? Do you need to maintain that level of control?**
There are a variety of ways to host and manage infrastructure in the cloud, including using bare-metal hosts, virtual machines, managed container services, and serverless offerings. Even if you're currently using similar infrastructure, such as virtual machines or containers, in your on-premises environment, consider if an alternate approach would be suitable for certain workloads. For example, instead of running all applications on virtual machines, consider containerizing your applications and take advantage of managed container services such as [Amazon Elastic Container Service (Amazon ECS)](https://aws.amazon.com/ecs/). This might require refactoring, but you can use a tool such as [AWS App2Container](https://aws.amazon.com/app2container/) to simplify and assist with containerization. Taking this a step further, instead of deploying servers or containers for all components, consider fully serverless options. Serverless technologies feature automatic scaling, built-in high availability, and a pay-for-use billing model to increase agility and optimize costs. At the same time, they eliminate the need to manage servers and to plan for capacity. Serverless computing services such as [AWS Lambda](https://aws.amazon.com/lambda/) are core to serverless architectures. Lambda supports common programming languages and allows developers to focus on application code instead of managing infrastructure. Explore these options for each workload, and consider factors such as learning curve, management overhead, cost, and licensing.
+ **Do you have to deploy and manage infrastructure for any licensed software?**
When you deploy and manage licensed software from independent software vendors (ISVs), it might seem logical to mimic your on-premises deployment with cloud infrastructure. For example, you might consider replacing on-premises virtual machines with cloud-hosted virtual machines. Although this is a viable option, consider whether you can replace any components of the architecture with cloud-native, managed services. For example, you might be able to replace a self-managed database server with a fully managed database service that reduces administrative burden while running the same database engine. Many ISVs already use cloud architectures that take advantage of managed services, and might even offer prebuilt templates to simplify deployment. Where possible, you should prefer ISVs that offer prescriptive guidance and support for cloud deployments. Before you deploy licensed software to the cloud, be sure to consult with your ISV to understand how cloud environment licensing might differ from on-premises licensing.
+ **Are you concerned that using a managed service might result in vendor lock-in?**
Many cloud-native, managed services are built to support common industry standards and APIs. For example, analytics services such as [AWS Glue](https://aws.amazon.com/glue/) and [Amazon EMR](https://aws.amazon.com/emr/) are built on industry standard processing and storage frameworks such as Apache Spark and Apache Parquet. [AWS Lambda](https://aws.amazon.com/lambda/) natively supports Java, Go, Microsoft PowerShell, Node.js, C\$1, Python, and Ruby code. [Amazon Relational Database Service (Amazon RDS)](https://aws.amazon.com/rds/) supports multiple versions of common database engines, including SQL Server, Oracle, PostgreSQL, and MySQL. When services have proprietary APIs, native or partner solutions might be available to interact with the APIs by using common, cloud-agnostic protocols. For example, [Amazon Simple Storage Service (Amazon S3)](https://aws.amazon.com/s3/) has a service-specific API for direct integration, but you can also interact with it by using standard storage protocols such as Network File System (NFS), Server Message Block (SMB), and Internet Small Computer Systems Interface (iSCSI) when you use [AWS Storage Gateway](https://aws.amazon.com/storagegateway/). You should still focus on choosing the cloud-native, managed service that best meets your needs while reducing operational overhead to the greatest extent, but you might prefer services that use or make available common industry standards and protocols.
# Implement hybrid architectures when existing, on-premises investments incentivize continued use
Most educational institutions have invested in on-premises data centers of varying scale to host enterprise applications, data storage solutions, end-user computing (EUC) environments, and shared computing resources. All the resources in these data centers are subject to different refresh cycles, where you must consider future growth and provision enough capacity to accommodate peak scale, which might be necessary only a few times a year. As a result, resources often sit idle until the next refresh cycle. Planning for, budgeting, procuring, and deploying new hardware can take weeks, if not months or longer. This lengthy process stifles innovation and can delay learning and research.
Cloud computing solves many of these challenges. The cloud provides on-demand, pay-as-you-go IT resources, so you can more closely match current capacity with actual demands without large, upfront planning and investment. However, if you have already made a significant investment in on-premises hardware and resources, you should seek to utilize those resources efficiently and augment them as needed with cloud technology in a hybrid model.
A successful hybrid cloud strategy takes advantage of existing investments while providing greater agility, scalability, and reliability than those investments alone can support. The following considerations can help you get started.
+ **When you must host a new workload, do you think about cloud first?**
How you use public and private cloud infrastructure together defines your hybrid cloud strategy. A cloud first approach doesn't mean that the cloud is the better choice for all your workloads. However, when you plan for new workloads, evaluate the cloud as the first option, especially for workloads that require new technology or exceed the storage and compute capacity available on premises. Workloads that have transient, inconsistent usage patterns, need fast results, are easily portable, or require the newest hardware are ideal candidates for the scalability and elasticity of the cloud. Also, consider whether the workload would benefit from any cloud-native, managed services that are unavailable on premises, even if you do have available capacity.
+ **Do you understand the TCO of your on-premises environment and partner with your CFO when making new investments?**
We recommend that you understand the true total cost of ownership (TCO) of maintaining your own on-premises data center. There are many hidden costs associated with owning and operating infrastructure on premises, including not just hardware, software, and support, but also facilities, utilities, insurance, and staff hours. These costs can negatively impact staff productivity, operational resilience, and business agility. Evaluate your current licensing structures and their renewal and maintenance periods as well. Partnering with your chief financial officer (CFO) can help you identify all hidden costs when you plan to make new investments. Some licenses might offer Bring Your Own License (BYOL) options in the cloud, or they might be more or less conducive to cloud services. Understanding the true TCO of your current infrastructure helps you prioritize cloud adoption for workloads that have the greatest impact on your organization's total TCO. Your AWS account team has tools readily available to help you better understand your on-premises TCO.
+ **What infrastructure will you need to support hybrid deployments?**
To successfully adopt hybrid models, you will need foundational network, security, and infrastructure tooling. Make sure that you can maintain adequate network connectivity with your cloud provider. This could be through a combination of existing internet connectivity, virtual private networks (VPNs), dedicated connections such as Direct Connect, third-party connectivity providers, or [Internet2](https://internet2.edu/) and regional research and education networks. Make sure that you have unified identity and access management across your on-premises and cloud environments. Establish tools and processes to enforce consistent security, cost, and usage guardrails.
+ **Is your IT staff ready to operate hybrid deployments?**
Cloud services can require specific skill sets that your team might not have. To limit the training and enablement necessary to upskill your IT staff for effective cloud adoption, consider whether the cloud provider offers any services that reuse and build upon existing skill sets across on premises and the cloud. For example, if you use and are familiar with Kubernetes, you might consider using [Amazon Elastic Kubernetes Service (Amazon EKS)](https://aws.amazon.com/eks/) or [Amazon EKS Anywhere](https://aws.amazon.com/eks/eks-anywhere/). If you use and are familiar with NetApp, you might consider using [Amazon FSx for NetApp ONTAP](https://aws.amazon.com/fsx/netapp-ontap/). Similarly, also consider whether any existing partner solutions you use have native integrations or support for cloud environments.
+ **Can you offload long-term storage or low-usage compute from on premises to the cloud?**
Cloud storage provides several cost-effective options for long-term data storage. For example, [Amazon Simple Storage Service (Amazon S3)](https://aws.amazon.com/s3/) offers various storage tiers that are optimized for different use cases. If your institution is required to keep certain data for a long period of time, consider cold storage solutions such as [Amazon Glacier](https://aws.amazon.com/s3/storage-classes/glacier/). Offloading this data into cloud storage can free up valuable high-performance, on-premises storage. Services such as [AWS Storage Gateway](https://aws.amazon.com/storagegateway/) make it easy for on-premises applications to access cloud storage tiers through standard protocols such as SMB, NFS, and iSCSI. Similarly, consider offloading any compute tasks that have infrequent or low usage. If you have on-premises servers that are dedicated to such tasks, you can instead use scalable cloud compute services, where resources are provisioned on demand and you pay only for what you use. Those low-cost, long-term storage and low-usage compute options also make the cloud ideal for backup and disaster recovery. You can use secure, durable, scalable storage and compute in the cloud to protect your data and quickly recover in case of a disaster without having to maintain the necessary storage and compute infrastructure yourself.
+ **Do you have enough capacity on premises to experiment and innovate?**
The lack of elasticity and agility in fixed-size, on-premises environments can limit the services and technology available to your users. If you have strict refresh cycles, new workloads might have to wait until the next cycle for implementation. This operating model can limit experimentation and slow innovation. When you have a new or novel workload that needs to be tested, consider using scalable, elastic cloud services. Cloud resources can be provisioned and deprovisioned on demand and you pay only for what you use, so you can experiment and *fail fast* while minimizing organizational risk.
+ **Do you have unique compliance or performance requirements that compel you to keep data on premises?**
Workloads with strict data residency or latency requirements might dictate that you keep data on premises or as close to your users as possible. For these use cases, you can prioritize the use of existing, on-premises resources. However, consider whether your cloud provider offers edge services or mechanisms to use cloud-based technology on premises. Edge services deliver data processing, analysis, and storage closer to your own endpoints, and enable you to deploy tools outside of standard cloud provider data centers. For example, AWS offers services such as [AWS Local Zones](https://aws.amazon.com/about-aws/global-infrastructure/localzones/) and [AWS Wavelength](https://aws.amazon.com/wavelength/) to deploy applications in specific locations closer to end users. You can also bring cloud services and functionality into your existing data center with services such as [AWS Outposts](https://aws.amazon.com/outposts/), [AWS Storage Gateway](https://aws.amazon.com/storagegateway/), [Amazon ECS Anywhere](https://aws.amazon.com/ecs/anywhere/), and [Amazon EKS Anywhere](https://aws.amazon.com/eks/eks-anywhere/).
# Reserve multicloud only for workloads that can't meet their technical or business requirements through a single cloud provider
*Multicloud* refers to the use of cloud services from multiple (two or more) cloud service providers. Having a multicloud strategy can offer certain benefits, such as the option to unlock the differentiated capabilities of multiple cloud providers or the ability to meet data sovereignty requirements that a single cloud provider might not be able to accommodate. However, for each provider that you use, make sure that you have the proper people, skills, training, and toolsets in place to use that provider effectively. Furthermore, if you want to use a multicloud strategy for a specific workload, you will need additional resources to integrate and interoperate the necessary services from each cloud provider. **We recommend that you consider multicloud only when the benefits outweigh the increased investment.** To determine whether you should choose a multicloud strategy, consider the following key questions.
+ **Do you have the resources and skill sets to navigate services offered by different cloud providers?**
When multiple cloud providers offer various products and services, your staff needs essential skills to navigate each provider's capabilities. Using one cloud provider's services alone can require upskilling and training for your staff, depending on the services and features you are using. If you're considering a multicloud strategy, evaluate your existing resources to determine what additional skill sets you would need to use services from multiple cloud providers effectively. You might have to augment your staff or invest additional time and money in upskilling and training beyond what would be required for a single cloud provider. If you already have individual teams or users who are using different cloud providers, consider the organizational benefits of consolidating them onto a primary cloud provider on a case-by-case basis.
+ **What additional overhead would a particular multicloud architecture introduce?**
A common driver for multicloud is the desire to use a specific managed service from one provider that has capabilities that can be differentiated from the services of another cloud provider. For example, you might want to use one cloud provider for your infrastructure needs and another provider's managed service for domain and directory services. However, even if that single managed service reduces administrative burden and simplifies the management of that architecture component, it could introduce additional overhead for other workloads, such as code refactoring, private connectivity needs, or manual integration work. Identify this additional overhead up front and make sure that it doesn't offset or eclipse the benefits your team stands to gain from the differentiated service.
+ **How will you centralize monitoring and management across cloud providers?**
As you start to deploy applications and functionalities by using resources from different cloud providers, consider how you will tag, monitor, and manage such resources. Each provider will have their own tooling, which you might be able to extend into other environments. For example, you can use [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) to monitor key metrics and logs, create alarms, and visualize your applications and infrastructure across single, hybrid, and multicloud environments. You can also use [AWS Systems Manager](https://aws.amazon.com/systems-manager/) to improve resource visibility and control, quickly diagnose and remediate operational issues, and automate processes such as updating and patching virtual machines across environments. If you have requirements that a provider's tools cannot support, you can explore partner solutions, but these could add additional cost or integration effort.
+ **How can you manage infrastructure as code with automation when using different cloud providers?**
When you run resources in the cloud, automated provisioning and management of resources helps you manage various environments efficiently. The APIs and native automation tools vary across cloud providers. If possible, consider using a common set of orchestration and deployment tools that can accommodate different cloud provider resources. This provides greater flexibility and simplifies operations across multiple clouds. However, it might be simpler to use each provider's native automation separately and establish organizational processes to ensure appropriate usage.
+ **Do you have compliance and regulatory requirements that each cloud provider must satisfy?**
You might have regulatory considerations that dictate how data should be stored and handled. Focus on standardizing policies (such as network traffic, storage, and security) that can be applied automatically to each cloud environment across cloud providers. Consider how your applications will communicate with their data, and host them on the same provider. If your applications and their data are fragmented across providers, it will be difficult to ensure that you are meeting compliance and regulatory requirements. It is often best to have applications as close to data as possible to minimize network latency, maximize data throughput, and limit data egress while simplifying security and access controls.
+ **Are you able to minimize TCO and maximize pricing discounts when you deploy applications across cloud providers?**
It is important to account for the total cost of ownership (TCO) when considering multicloud. Running your applications across multiple cloud providers can increase operational costs and administrative overhead to maintain and manage resources in each environment. Furthermore, spreading usage across multiple providers makes it more difficult to take advantage of a specific provider's volume pricing discounts or enterprise agreements. Take these factors into account when you determine whether the benefits of multicloud warrant the increased TCO.