How Oracle Is Lying About AWS’s Internal Data Centers

Executive Summary

  • Oracle has responded to reports of significant outages in the Oracle Cloud by making false claims around co-location.
  • In this article, we review the statements made by Oracle representatives.


Oracle Cloud uses a lower quality 100% co-located strategy for its data centers. This has been leading to downtime, as explained in the article The Problem with the Oracle Cloud and Colocation by Ahmed Azmi of Brightwork Research & Analysis.

“Oracle cloud is entirely made up of leased colocation facilities operated by third-party providers. These third party providers have their own maintenance schedules for systems maintenance, updates, and upgrades. They also experience their own frequent unplanned downtime. Third party downtime adds additional downtime to Oracle’s own planned and unplanned downtimes.”

There are three primary problems, with 100% of Oracle’s internal data centers being co-location facilities.

  1. This provides less quality than the purpose-built facilities of the major cloud service providers like AWS, GCP, and Azure.
  2. Because they not owned by Oracle, Oracle has used this loophole to make its cloud SLA irrelevant as they can always point to the co-location facilities in the case of downtimes.
  3. Oracle did not tell anyone that these facilities were co-located — we needed to find this out through research.

How Oracle Responded to These Facts

Oracle has followed a concerted effort to lie to their customers about the problems with their 100% co-located data centers. This false information has gone out as a broad communication from Oracle’s competitive intelligence. And the logic was presented in debates on LinkedIn, responses for which we have copied in this article for analysis.

“….apart from the building itself, everything done by big red. the claims in the article are totally false.” – Selim Daoud

The comment here defines what a co-located facility is. Nothing in Ahmed’s article said otherwise. And Ahmed’s article is declared entirely false — which is odd, as the claims were supported by complaining customers, one who wrote an article on LinkedIn describing their problems with outages. This was our response.

Selim, This article states that the areas of colocation facilities, which means that Big Red would, of course, do everything. That is what colocation means, and the article did not say otherwise. Colocation facilities are a low-quality way to build the cloud. Secondly, they give Oracle a way out of the SLA. Because they can blame the colocation facility. Therefore, Oracle’s SLA that Oracle resources keep talking about is fake. If you disagree, explain why Oracle does not credit downtime. Or do they credit downtime? If so, please explain. Because that would be news to us.

Thus far its difficult to see how you know if Ahmed’s client was complaining about Oracle cloud outages.

Secondly, you seem to be skirting the issue that colocation is not the same thing as building your own purpose-built facility. AWS takes the cloud seriously and builds and owns purpose-built facilities.

When all Oracle resources talk about the cloud, shouldn’t they tell customers the SLA is not real? The information that these facilities are cheap colocation jobs came from Brightwork, not from Oracle. I doubt that Oracle ever brought up the fact they don’t even own their own data centers to Wall Street. 

I was able to find this article which describes QTS and AWS for colocation. However, it is geared towards customers that want to use QTS data centers for their hybrid cloud.– Shaun Snapp

Selim Daoud then responded with this comment.

“I was referring to this” – Shaun Snapp

And we replied with the following:

“That is a very interesting document actually. Thanks for sharing that. I noticed Equinix on the list. However, my question is how many of the colocation DCs are listed in that document but are outside of the AWS network? I don’t think AWS claims, for instance, Equinix DCs as part of its network. That is this may be a list all of the DCs that AWS interoperates with. I am open to whatever is the correct interpretation. But I don’t know from looking at this list what that interpretation is.” – Shaun Snapp

Selim Daoud had no response to this comment. Either Selim Daoud had no idea what he was talking about, or he was deliberately providing misleading information that was then picked up by Oracle’s competitive intelligence, and is now being spread to Oracle customers. An Accenture Sales Director then shared this same false information in the following comment.

“” – Laura Reyes

Ahmed Azmi then asked Laura about the Oracle outages.

“No, I am asking you about the specific Oracle customer complaints showcased in this post. I am asking about the customers you ignored. How do you explain their complaints? They are saying, in their own words, that Oracle cloud has repeated outages every month and every quarter and they get no service credits for these outages. I am asking you to explain their complaints NOT to talk about Wikileaks. Secondly, we are not talking about occasional outages. Did you read what the customers are saying? We are highlighting a major systemic problem with Oracle’s cloud operations.

These outages are happening every month and the unplanned ones often last for 24 hours.

This doesn’t happen with other cloud vendors. Finally, you talk about fairness to Oracle! How about some fairness to those customers who have to resort to publishing public complaints on social media because they are losing revenue due to outages? We have many SAP customers running SaaS apps on AWS, Azure, and GCP. We almost never hear them complain about outages and when outages happen, they don’t complain because (a) time to recovery is fast and (b) they automatically get credited on their next billing cycle. That’s NOT the case with Oracle cloud. Read the customer testimonials please! ” – Ahmed Azmi

We then have to explain to Laura, as we had said to Salim, that the list they provided were external locations to AWS, not internal.

Laura, You are mixing up internal versus external data centers. AWS has a series of internal data centers that are owned by AWS lock stock and barrel. They are custom designed by AWS. But AWS allow connects to collocated centers but that is for hybrid cloud — these are external locations — they are not mentioned as part of AWS’s overall network. This is the same as connecting to a customer’s hybrid cloud on premises. Oracle Cloud is different. 100% of what they list as internal DCs are collocated. So do you see the distinction? Your analysis of AWS’s outages are also incorrect. AWS is relied upon by many customers. When they have an outage people notice. Almost no one notices when Oracle has an outage because so few people use their cloud, which we covered here.

These topics are beyond the capacity of any salespeople I have ever worked with to understand. This deals with proportions, technology, so your comments on these topics will have a high error rate.– Shaun Snapp

To which Ahmed Azmi added the following.

Most of these are CDNs Shaun Snapp. They’re used to provide local access points or private connectivity. Everyone uses those even outside the tech world. Netflix has many of these all over the world where they provide services.– Ahmed Azmi


The most important thing to note is that while the Oracle resources could not come back with an explanation as to why they were presenting external AWS locations as internal. They included links to a list of AWS facilities. The official AWS domestic facilities are easily viewable at AWS’s global infrastructure page.

On this page, it distinguishes internal and edge locations. Even the most straightforward analysis of the documents shared by the Oracle resources or proponents show that there an enormous number of locations listed. But AWS does not have anywhere near that many internal locations. Notice there is only one internal location in South America — in San Paulo. Below this, the Edge locations and Regional Caches are listed.  

Asia has far more locations than South America. Again, the Edge locations are called out very separately from the internal AWS locations. 

Oracle’s entire argument is based upon the idea that it does not know the difference between internal versus edge locations.

Oracle’s competitive intelligence later took this idea, and distributed this false idea anyway, under the belief that some lie is better than nothing.

  • This brings up the topic of how much Oracle’s competitive intelligence group is part of creating falsehoods that are then repeated by Oracle sales reps.
  • Also, Oracle partner consulting firms are known as passive repeaters for whatever Oracle says. The Oracle consulting partners are likely repeating this lie to their clients.

The fact is that Oracle has no explanation for why all of their data centers are co-location facilities, for why they break all of their cloud SLAs through the co-location issue, or why they have so many outages with Oracle Cloud.

The Problem: A Lack of Fact-Checking of Oracle

There are two fundamental problems around Oracle. The first is the exaggeration of Oracle, which means that companies that purchased from Oracle end up getting far less than they were promised. The second is that the Oracle consulting companies repeat whatever Oracle says. This means that on virtually all accounts, there is no independent entity that can contradict statements by Oracle.

Being Part of the Solution: What to Do About Oracle

We can provide feedback from multiple Oracle accounts that provide practical information around a variety of Oracle products — and this reduces the dependence on biased entities like Oracle and all of the large Oracle consulting firms that parrot what Oracle says. We offer fact-checking services that are entirely research-based, and that can stop inaccurate information dead in its tracks. Oracle and the consulting firms rely on providing information without any fact-checking entity to contradict the information they provide. This is how companies end up paying for items that are exorbitantly priced, exorbitantly expensive to implement. And exorbitantly expensive to maintain.

If you need independent advice and fact-checking that is outside of the Oracle and Oracle consulting system, reach out to us with the form below or with the messenger to the bottom right of the page.

Financial Disclosure

Financial Bias Disclosure

Neither this article nor any other article on the Brightwork website is paid for by a software vendor, including Oracle, SAP or their competitors. As part of our commitment to publishing independent, unbiased research; no paid media placements, commissions or incentives of any nature are allowed.

Search Our Oracle Cloud Content


Software Selection Book


Enterprise Software Selection: How to Pinpoint the Perfect Software Solution Using Multiple Information Sources

Mastering Software Selection

Software selection is a form of forecasting, just as any another purchase decision is a forecast of how successfully the purchased item will meet expectations. Forecasting is necessary because it is not feasible to implement each application under consideration before it is purchased to see how it works in the business.

The Importance of Software Selection

Software selection is the most important part of any software implementation because it is the best opportunity to match the software with the business requirements, which is the most important factor in determining the success of the project. This book explains how to get the right information from the right sources to perform software selection correctly.

What You Can Expect from the Book

Essential reading for success in your next software selection and implementation. Software selection is the most important tasks in a software implementation project, as it is your best (if not only) opportunity to make sure that the right software the software that matches the business requirements is being implemented. Choosing the software that is the best fit clears the way for a successful implementation, yet software selection is often fraught with issues, and many companies do not end up with the best software for their needs. However, the process can be greatly simplified by addressing the information sources that influence software selection.

This book is a how-to guide for improving the software selection process and is formulated around the idea that much like purchasing decisions for consumer products the end user and those with the domain expertise must be included. In addition to providing hints for refining the software selection process, this book delves into the often-overlooked topic of how consulting and IT analyst firms influence the purchasing decision and gives the reader an insider’s understanding of the enterprise software market. By reading this book you will:

  • Learn how to apply a scientific approach to the software selection process.
  • Interpret vendor-supplied information to your best advantage.
  • Understand what motivates a software vendor.
  • Learn how the institutional structure and biases of consulting firms affect the advice they give you, and understand how to interpret information from consulting companies correctly.
  • Make vendor demos work to your benefit.
  • Know the right questions to ask on topics such as integration with existing software, cloud versus on-premise vendors, and client references.
  • Differentiate what is important to know about software for improved “implement-ability” versus what the vendor thinks is important for improved “sell-ability.”
  • Better manage your software selection projects to ensure smoother implementations.


  • Chapter 1: Introduction to Software Selection
  • Chapter 2: Understanding the Enterprise Software Market
  • Chapter 3: Software Sell-ability versus Implement-ability
  • Chapter 4: How to Use Consulting Advice on Software Selection
  • Chapter 5: How to Use the Reports of Analyst Firms Like Gartner
  • Chapter 6: How to Use Information Provided by Vendors
  • Chapter 7: How to Manage the Software Selection Process
  • Chapter 8: Conclusion
  • Appendix a: How to Use Independent Consultants for Software Selection