When a Salesforce page slows down or an integration stops delivering records, teams often ask a simple question: “Is AWS down, or is Salesforce down?” That question is understandable, but it can lead to the wrong investigation. Salesforce is a software provider, AWS is a cloud infrastructure provider, and the relationship between them changes depending on the Salesforce product, org, region, network path, and integration design.
A verified update gives the relationship useful context. Salesforce Help published an updated Hyperforce FAQ on August 4, 2026. It says Hyperforce is available on Amazon Web Services (AWS), with Google Cloud Platform availability planned from late 2026, and that Salesforce manages infrastructure placement using technical and operational factors. The same FAQ says some products or features may initially be available on Hyperforce on AWS while they are not yet available on GCP. This does not mean every Salesforce service is hosted on AWS, that every customer chooses the underlying provider, or that an AWS incident automatically becomes a Salesforce incident. This guide explains the dependency in those layers, using information checked on September 16, 2026.
“Dependency” can describe several different relationships. The most important distinction is between a managed service dependency and a customer-created integration:
| Layer | What is connected | Who usually controls it | What a failure may look like |
|---|---|---|---|
| Salesforce application | CRM products, APIs, identity, metadata, and business logic | Salesforce | Login failures, API errors, slow pages, or unavailable features |
| Hyperforce infrastructure | Salesforce application stacks deployed on public-cloud infrastructure | Salesforce manages the placement; the cloud provider operates its underlying services | Regional capacity, networking, storage, or infrastructure effects |
| Customer integration | Salesforce connected to AWS services such as applications, data stores, or event pipelines | Your integration and operations teams, with provider-specific controls | Timeouts, authentication errors, missing events, or failed writes |
| Network path | Internet, private connectivity, DNS, firewalls, routing, or Direct Connect | Customer, telecom, AWS, and Salesforce depending on the path | Only one office, VPC, region, or application cannot connect |
| Data and compliance | Where data is stored, processed, backed up, and transferred | Shared across product configuration, contracts, and architecture | Residency questions, blocked transfers, or an audit finding |
The table is a troubleshooting model, not a statement that every Salesforce product uses every AWS component. Check the product-specific documentation and your order configuration before making an architectural or compliance decision.
No. Hyperforce is Salesforce’s infrastructure architecture. Salesforce describes it as a public-cloud architecture managed as code, designed to support global delivery, data residency, security, scalability, and agility. AWS is one public-cloud provider on which Hyperforce is available. The platform name, the Salesforce product, and the underlying cloud provider are therefore different parts of the stack.
The updated Salesforce FAQ says Salesforce manages infrastructure placement based on technical and operational factors. For a customer, that means an org running on Hyperforce should not be treated like an AWS account where the customer chooses an Availability Zone, changes an EC2 instance, or opens a security group. Salesforce operates the managed SaaS environment. Your team can still have AWS dependencies around it—for example, a data pipeline, private connection, event consumer, or application hosted in your AWS account—but those are separate from Salesforce’s own infrastructure placement.
Salesforce also notes that services not hosted on Hyperforce continue to operate as before, and that product availability can differ by public-cloud provider. For current product and provider details, consult the Salesforce Hyperforce FAQ and migration guide. Treat that page as versioned operational guidance rather than a permanent promise: Salesforce says the document is informational and subject to change.
This is the closest thing to a direct infrastructure dependency. If a particular Salesforce org and product are placed on Hyperforce on AWS, an incident in a relevant AWS region or service could become one factor in Salesforce availability. But the actual customer-facing failure may be caused by Salesforce application code, a Salesforce control plane, a dependency in another region, a routing problem, or a product-specific service. Seeing AWS as the underlying provider is not enough to identify the root cause.
This is often the dependency customers notice first. A Salesforce org may send data to an AWS-hosted service, receive events from a queue, call an API in a VPC, read from a data platform, or use an AWS service as part of an application workflow. In this design, Salesforce can be healthy while your AWS endpoint, credentials, network route, or event consumer is failing. The reverse is also possible: AWS can be healthy while the Salesforce API or authentication layer is unavailable.
Salesforce Private Connect е модел за междуоблачна интеграция за свързване на организация на Salesforce с AWS услугите на клиента. AWS Direct Connect е опция за мрежова свързаност, която може да осигури път от локална среда към AWS и, чрез публичен виртуален интерфейс, към Hyperforce. Те не са взаимозаменяеми контроли.
Съвместното ръководство на Salesforce и AWS посочва, че Salesforce Express Connect не е съвместим с Hyperforce и описва AWS Direct Connect с публичен виртуален интерфейс като опция за някои клиенти, които се нуждаят от директна свързаност с Hyperforce. То също така разграничава Private Connect, който свързва организация на Salesforce с услугите на AWS на клиента. Прочетете ръководството на AWS за достъп до Hyperforce с Direct Connect, преди да променяте мрежовата архитектура. Все още трябва да се проверят изискванията за наличност, маршрутизация и договор за вашата организация.
Не. Инцидент в Salesforce и инцидент в AWS могат да се припокриват, но не са синоними. Salesforce публикува състоянието на услугата чрез своя сайт за доверие, докато AWS публикува състоянието на услугата и специфични за акаунта събития чрез AWS Health. Започнете с услугата, която не работи, и точния регион или екземпляр, вместо да приемате, че най-големият доставчик в стека е отговорен.
Използвайте това сравнение по време на инцидент:
| Наблюдаван симптом | Първо място за оглеждане | Тълкуване за тестване |
|---|---|---|
| Всички потребители на Salesforce не могат да влизат или да използват няколко продукта едновременно. | Salesforce Trust, инстанция на организацията и канал за поддръжка на Salesforce | Прекъсване на услугата в целия Salesforce или на ниво екземпляр |
| Само една интеграция, поддържана от AWS, се проваля | Журнали на приложенията, AWS Health, идентификационни данни, DNS и показатели за крайни точки | Проблем с интеграцията на клиента или услугата AWS |
| Само един офис или виртуален компютър не може да се свърже със Salesforce | Маршрути, правила за защитна стена, DNS, директно свързване и конфигурация на надеждни IP адреси | Проблем с мрежовия път или локалната конфигурация |
| Потребителският интерфейс на Salesforce работи, но планираната синхронизация блокира | Ограничения на API, OAuth токен, дълбочина на опашката, повторни опити и регистрационни файлове за интеграция | Зависимост от работния процес или API, а не от наличността на ядрото |
| Един продукт или функция не е наличен | Документация за състоянието и изданието на Salesforce, специфична за продукта | Проблем на ниво компонент, поддръжка или зависимост от функция |
Това разграничение влияе върху ескалацията. Ако Salesforce Trust съобщи за инцидент, засягащ вашия екземпляр, съберете номера на инцидента и избягвайте да правите разрушителни промени в конфигурацията. Ако Trust е ясен, но вашата AWS крайна точка показва грешки, запазете идентификаторите на заявките и проучете AWS страната. Ако и двете изглеждат здрави, сравнете директен тест на Salesforce API, тест на AWS крайна точка и пълния път на интеграция; все още е възможен проблем между здрави услуги.
Hyperforce може да промени къде се хостват приложенията и данните на Salesforce, но „регионален“ не означава „всеки байт остава в една държава във всяка ситуация“. Salesforce казва, че данните за клиентите обикновено се съхраняват в държавата, където се намира организацията, когато използваните услуги са достъпни там. Също така предупреждава, че някои продукти може да имат компоненти в различни държави или да включват интеграции с услуги, които все още не са в Hyperforce.
Това предупреждение е важно, когато AWS е част от дизайна. Трябва да картографирате поне четири местоположения: организацията Salesforce и нейния оперативен регион Hyperforce, региона AWS, съдържащ свързаната услуга или данни, местоположението на интеграционните работници и лог файловете, и местоположението на резервните копия или копия за възстановяване след бедствие. Регион AWS, избран от вашия екип, не отменя продуктовата архитектура на Salesforce, а опцията за местоживеене на данни на Salesforce не поставя автоматично вашите външни данни от AWS в същия регион.
Използвайте общия преглед на инфраструктурата за публичен облак на Salesforce Hyperforce и документацията за доверие и съответствие на вашата организация, за да валидирате продуктите, регионите и ангажиментите, които се отнасят за вашата среда. За регулирани данни, екипите по поверителност, сигурност и правни въпроси трябва да прегледат действителните условия на услугата, вместо да разчитат на обща архитектурна диаграма.
Устойчивостта започва с избягването на единична синхронна верига за всяко бизнес действие. Ако транзакция в Salesforce трябва да изчака AWS услуга, дефинирайте какво се случва, когато AWS услугата е бавна или недостъпна. В зависимост от бизнес процеса, опашка, повторен опит с експоненциално отсрочване, ключ за идемпотентност, прекъсвач, път на неизпратени съобщения или ръчно съгласуване може да са по-безопасни от повтарящите се синхронни извиквания.
Използвайте ограничен брой повторни опити. Повторен опит, който продължава, докато Salesforce или AWS са влошени, може да увеличи трафика и да превърне кратък инцидент в по-голямо натрупване на неизпълнени задачи. Запишете оригиналната заявка, броя на повторните опити, кода на отговора и окончателното разпореждане. Осигурете безопасността на дублиращите се доставки, преди да активирате автоматичното възпроизвеждане на събитията.
Разделете целите за възстановяване за страната на Salesforce от целите за страната на AWS. Архивирането на база данни на AWS не възстановява конфигурацията на организацията на Salesforce, а опцията за възстановяване на Salesforce не възстановява външно AWS приложение. Salesforce описва възможността за възстановяване след бедствие извън региона за сигурно архивиране на екземпляр във вторичен регион на Hyperforce, но наличността и договорният обхват трябва да бъдат проверени за продуктите и изданието, които използвате. Не представяйте тази опция като универсален план за превключване при срив.
Не кодирайте твърдо предположения за диапазони от IP адреси в публичния облак, разположението на доставчиците или поведението на продуктите в дългосрочен runbook. Прегледайте текущата документация на Salesforce и AWS след миграция към Hyperforce, стартиране на нов регион, промяна в свързаността или основно издание за интеграция.
Полезен резултат не е просто „Salesforce използва AWS“. Полезният резултат е ограничено твърдение, като например: „Организацията на Salesforce е достъпна, AWS е в добро състояние, но интеграционният работник не може да разреши частната крайна точка“ или „Salesforce Trust съобщава за проблем с екземпляр, така че нашите повторни опити от страна на AWS се задържат“. Това ниво на прецизност казва на следващия екип какво да промени – и какво да не променя.
Salesforce и AWS са тясно свързани в някои части от съвременната облачна архитектура, особено когато Hyperforce работи на AWS или когато клиент умишлено интегрира Salesforce с услуги на AWS. Връзката не е единична зависимост от типа „всичко или нищо“. Това е набор от управляван хостинг, приложни услуги, мрежови пътища, местоположения на данни и изградени от клиента интеграции.
За текущо планиране използвайте ЧЗВ за Salesforce Hyperforce от 4 август 2026 г. като отправна точка, след което проверете конкретните продукти и региони във вашата организация. За реагиране при инциденти тествайте всеки слой поотделно и запазете доказателства, преди да промените конфигурацията. Целта не е да се елиминира всяка зависимост; целта е да се знае коя зависимост съществува, кой я притежава, как се проявява повредата и как бизнесът се възстановява, без да се създава втори проблем.
Прегледайте забележителните прекъсвания на Salesforce през 2025 г., какви са били неуспешните действия, колко дълго са продължили избрани инциденти и практическите уроци за устойчивост, които екипите могат да приложат.
Build a practical Salesforce downtime continuity plan with impact analysis, RTO/RPO targets, manual workarounds, integration controls, and recovery checks.
Learn how to contact Salesforce Support during a major outage: check Trust Status, choose the right channel, open a strong case, and track recovery.
Отстраняване на неизправности при влизане в Salesforce Workbench, REST Explorer, изчакване, 503, версия на API и ограничаване на грешките по време на престой с практичен диагностичен контролен списък.
StoreForce issues can disrupt scheduling, timekeeping, and employee workflows. Learn how to assess impact, keep stores operating, verify recovery, and know when to escalate.
Разберете основните причини за широко разпространените прекъсвания на работата в облака, как се натрупват повреди, какво да проверите първо и как да проектирате по-устойчив план за възстановяване.
Ако Datorama или Marketing Cloud Intelligence изглеждат неработещи, използвайте този контролен списък, базиран на доказателства, за да проверите прекъсването, да защитите качеството на отчитането и да разберете кога данните отново са надеждни.
A practical look at how Heroku outages can affect deployed apps, dynos, routing, databases, deploys, Heroku Connect, logs, and recovery.
Understand how Salesforce and AWS connect through Hyperforce, integrations, networking, data residency, outages, and shared operational responsibilities.
Прекъсването на AWS не означава автоматично, че Salesforce не работи. Научете как Hyperforce, регионите, инстанциите и Salesforce Trust определят дали вашата организация е засегната.
