Home > Articles

The Realities and Opportunities of Cloud-Based Compute Services That Your Cloud Provider Will Not Tell You About

Cloud pioneer and long-time CTO David Linthicum covers public cloud computing processors, which are usually referred to as central processing units (CPUs), how to pick the platforms needed to operate those processors, and how to obtain the best value from your cloud provider.

This chapter is from the book

There are no secrets to success. It is the result of preparation, hard work, and learning from failure.

— Colin Powell

Now that we’ve covered storage, let’s cover compute. This topic is a bit more complex. In addition to choosing public cloud computing processors, which are usually referred to as central processing units (CPUs), we must pick the platforms needed to operate those processors. The platforms themselves require choices, including operating systems, memory configurations, network connections, and even the need to define some physical storage that needs to exist.

In this chapter, we focus on what these services are, how to understand them, how to pick them, and how to obtain the best value from your cloud provider. We also look at some concepts you need to understand before you pick compute services. These concepts include how cloud hosting works, and how to understand your own requirements so you don’t under- or overbuy. Additionally, we discuss how to find the best deals with known discount approaches, such as leveraging reserved instances or leveraging processors that are considered “off-brand.” Finally, we review some traditional options that we often forget about in the haze of cloud computing migrations. Again, the focus is to provide you with inside information on what to leverage and how to think pragmatically about cloud-based compute.

The Trade-offs of Multitenancy

When you leverage CPUs via a cloud service, you typically share those CPUs with other cloud computing tenants. You get the services that you contract for, but you’re not the only client leveraging that physical resource. You could even be multiplexed across many virtual compute servers and be serviced by several CPUs, memory configurations, and input/output management subsystems.

The problem is that you really don’t know what goes on behind the scenes in terms of how a public cloud provider deals with its tenancy. Providers debated extensively about multitenancy approaches when cloud computing first started. Multitenancy choices in those days were—and still are—“share all,” “share some,” and “share nothing” approaches.

My first cloud consulting firm focused on creating all three types of multitenancy architectures for new and existing software companies looking to become SaaS cloud providers. They needed the ability to deliver multiuser types of services, as well as the ability to deal with resource sharing that includes CPUs, memory, storage, and so on.

It was not unusual during the early days of cloud computing to have traditional software companies approach multitenancy in rather unorthodox ways—especially when they received requests from new or existing clients that wanted to be on a SaaS or other type of cloud. Rather than leverage a true multitenant automated platform, many traditional software providers simply bolted a new server onto the rack of their so-called cloud provider services. They would assign a name and IP, and the client leveraged only that server while leveraging the provider’s “cloud.” This is a classic example of a traditional service disguised to look like a cloud service.

Today, most of us recognize this “bolt-on” model as silly and wasteful. At the time, most clients never understood this was happening. While it’s not a true multitenant architecture, it was an approach that many used to break into cloud computing, and it formed many cloud users’ understanding of a “share nothing” approach.

Although we could pick apart multitenant approaches as we did during the early years of cloud computing, they worked for the most part, and the issues that arose are long since resolved. Most public cloud providers now offer solid multitenant services that optimize performance, even though they multiplex your use of a public cloud across many different physical resources. There are still some multitenant trade-offs to consider:

  • Performance can be “bursty.” In many cases this is the bursty nature of most Internet connections, in that performance will speed up and slow down based on the demand on the network resources. You can see the same type of performance patterns by looking at the performance of a cloud platform. When asked to do processor-intensive tasks, certainly when there’s not enough memory and CPU power allocated, you’ll see performance that seems as if it’s starting and stopping.

  • It’s difficult to predict the performance of deeper types of platform use, such as threading. A thread is a flow of execution of tasks found in processes, also called a thread of execution or thread of control. Most advanced operating systems support threading. Here you will see many of the same issues occur as previously discussed, including bursty performance. Also, launched threads may not succeed if the processor was busy for some reason, or if the application expected the thread to return faster than it did.

  • Many applications that are ported to the clouds using a lift-and-shift approach where a minimum amount of redevelopment occurs. Because the application was not developed and tested on a multitenant platform, its performance can be unpredictable.

Of course, the severity of these trade-offs depends on the cloud provider you use and how the provider specifically approaches multitenancy. These issues need to be worked out beforehand, worked around, or properly fixed after the migration. Many of these trade-offs result in more migration costs for enterprises.

The Realities of Resource Sharing

When it comes to understanding multitenancy, it’s important to understand that all public cloud providers have a different approach to tenancy. What one public cloud provider says may not apply to other providers—even if they say basically the same thing. Public cloud providers consider their approach to multitenancy proprietary to their IP. Although you get some overviews around how a provider approaches tenancy, what occurs in the background or in the native public cloud system that you can’t see is really what determines how the provider carries out multitenancy.

In some cases, you can insist that the public cloud provider reveal how multitenancy is carried out, typically around compliance audits that you need to support. For example, say you’re a government contractor who plans to place government systems on a public cloud provider. These systems may, as part of an audit, insist that the contractor and provider reveal the mechanisms behind multitenancy for a specific cloud they will leverage. You’ll find that some cloud providers are candid, having had to address this issue before. Others are not as forthcoming. If the provider won’t reveal the specific details and mechanisms behind how it approaches multitenancy, and if this won’t meet the needs of the audit, you need to determine that up front or face having to move off that cloud because it was later determined to be noncompliant with an audit.

The moral of this story is that you determine these details up front. Understand what the requirements are for your specific situation and if you need to have a detailed understanding of how the multitenant system manages resources. Figure that out before moving assets to that cloud.

The good news is that, for most use cases, high-level explanations will suffice. In the cases with special audit requirements, it’s usually best to leave these systems in the enterprise data center and save yourself the hassle.

Putting the legal issues aside for now, it’s helpful to understand the basic approaches and mechanisms that public cloud providers leverage for their public clouds, especially compute. These include

  • Shared is often the default and thus the approach that most cloud customers use, no matter whether they understand the concept or not. Shared means several public cloud computing accounts may share the same physical hardware. For most uses, this type of multitenancy approach is fine, and you won’t even know you’re sharing resources. However, performance issues such as the trade-offs we’ve described previously will come into play if you have special high-end requirements. As you may have guessed, a Shared model is typically the least expensive because you use fewer physical resources, all of which are shared. Figure 3-1 shows what the high-level architecture looks like, where a single physical resource is shared by many tenants. Note: The way you share resources—and how they are shared—is specific to the cloud provider’s multitenant services.

  • Dedicated Instance is when your instance (that is, running your applications) runs on single-tenant hardware. This approach typically works better for special higher-end requirements, such as applications that tend to saturate the CPUs and other resources. For all practical purposes, it’s as if you host your application on your own server that nobody else uses. Of course, this approach is more costly than the Shared model because you leverage physical hardware that others cannot leverage. Also, you rarely know the physical location of hardware. The provider allocates different servers for your use, and you are typically not assigned a dedicated server.

  • Dedicated Host is when your instance runs on a physical server with all its capacity dedicated to your use. You have complete control over this isolated server. Functionally, it’s as if you purchased a server, installed it within your data center, and now have exclusive use of it. In many instances, the cloud provider may even let you know where it’s physically located, although those policies differ from cloud provider to cloud provider. This is the costliest of all the sharing options listed here.


FIGURE 3-1 Resource sharing for most public clouds means that you share physical resources with many tenants or companies like yourself that need to access compute services. This is often the least expensive approach because the cloud provider can share a few resources with many tenants. As far as the tenants are concerned, they leverage a virtual resource that functions much like a dedicated server.

Costs Versus Consistency

The trade-off with compute models comes down to cost versus consistency. You either pay less to leverage physical servers that are shared with others, or you pay more for the luxury of dedicated hardware to ensure greater consistency. Figure 3-2 depicts the typical cost curve that most enterprises will encounter when purchasing compute resources from a large public cloud provider. None of this should be shocking, considering that as public cloud providers’ costs go up, they will pass the cost for the additional hardware resources, such as storage and compute, on to their customers.


FIGURE 3-2 As a rule, costs rise as you share fewer resources in the cloud. However, at some point, the cost begins to level out but never becomes completely flat, or diminishing.

The real question then becomes, What would compel you to use nonshared resources, and how would it even justify the extra costs? In truth, many of those who insist on dedicated instances, and even those who reserve a physical server in a public cloud, typically have no need for them. The extra cost is a classic waste of money.

In many instances, customers pay much more to use a public cloud provider’s dedicated resources than if they owned their own physical server, even with data center rental and maintenance factored into the equation.

In too many instances, I see this become a kind of ego play, in that someone wants to elevate the importance of their workloads to a point where they lose sight of the real goal, which is to get to the true value of cloud computing. The objective is to pay less to securely share most resources and still gain the soft values of cloud computing.

There are a few instances when it’s the right move to elevate workloads and data, when the needs for consistency and control outweigh the cost factors. However, most arguments for uninterrupted performance or security concerns with shared resources prove unfounded or, more often, available within a shared model option. We’re well into our 15th year of leveraging IaaS clouds and pretty much understand what shared and nonshared resources can do, and the cost trade-offs.

Despite the history and provable facts, I still see enterprises demand and deploy nonshared resources for the consistency and control reasons just mentioned. This will lead to a sizable reduction in the value that cloud computing brings to the business. In many instances, it will then lead to cloud computing having negative value that is completely avoidable. Carefully consider the business case and the technical realities before deciding that your workloads are much too important to mingle with others.

Cross-Partition and Cross-Tenant Hacks

It was not long after cloud computing became a thing that alarms began to sound around the possibility that other tenants could reach into your compute instance and grab your data or interrupt your processing. This is called a cross-channel attack, a cross-partition attack, or a cross-tenant attack. For our purposes, we’ll use the terms interchangeably.

These “cross” concerns came from some valid realities, including the fact that you are indeed running on the same physical servers. It’s logical to assume that if something were left misconfigured or a vulnerability overlooked that could be exploited, then someone or some program could purposefully reach through a logical partition and cause problems.

Experiments proved that this scenario could potentially occur, but only if there were a vulnerability on the multitenant system that was known to black hats, and thus could subsequently be exploited. The chances of that occurring, even though there was a chance, were much less than other security risks that typical applications and/or data sets encounter on a traditional platform. So, by moving to cloud, you lower your security risk. The chances that you’ll be hacked tenant-to-tenant are pretty much nonexistent.

The real issue here is that multitenant just seems scary. Your application that processes sensitive, often proprietary data, runs within the same memory set and CPU as other companies’ applications and data. Your cotenants could be a competitor, an illegal business, or the government.

Figure 3-3 depicts the types of attacks that tenants find of most concern, namely, a tenant being able to reach into the workspace of another tenant running on the same physical server. Or a tenant reaching across to another tenant running on another physical compute server.


FIGURE 3-3 In the early days of cloud computing, many feared cross-channel, cross-tenant, and cross-partition hacks, or reaching to compute and storage spaces controlled by another tenant—either within the same physical CPU and platform services, or between physical CPUs and other platform services. Much of this concern has been eliminated, but it’s still wise to ask your public cloud provider how this will be managed.

Cross-channel attacks are a false concern for the following reasons:

  • The public cloud providers became aware of this concern years ago and built specific security measures into their systems to isolate resources used by specific tenants. Of course, providers all do this differently, but they all have their own mechanisms to detect any cross-channel intrusions.

  • The data that resides within each tenant partition is encrypted at rest and in flight. If, for some reason, a tenant could reach into another partition, the data is worthless given that it’s encrypted. Most public cloud providers encrypt everything to remove this security vulnerability. You maintain your private key, and even the cloud provider can’t see your data without it.

  • The nail in the cross-channel risk coffin is that tenants can’t launch a machine instance on a specific machine, say, a specific machine where their target runs their data. Lacking the ability to choose the physical server that the tenant will run on, at least in a shared multitenant deployment, means no tenant can leverage standard approaches to access other tenant instances, such as making use of Level 3 memory cache exploitations.

Nothing I say here pushes these possibilities off as a nonthreat, only that there are many other things that should rank higher on your list of concerns in terms of cloud security. In this instance, it’s okay to say, “Nothing to see here.”

Keep in mind that when you play the cloud security game, it’s not about creating an invulnerable security layer. Ultimately, nothing is invulnerable. It’s about removing as much risk as you can, and then prioritizing and paying attention to the more likely threats.

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information

To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.


Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.


If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information

Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.


This site is not directed to children under the age of 13.


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information

If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information

Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents

California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure

Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact

Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice

We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020