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 je model integrace napříč cloudy pro propojení organizace Salesforce se službami AWS zákazníka. AWS Direct Connect je možnost síťového připojení, která může poskytnout cestu z místního prostředí do AWS a prostřednictvím veřejného virtuálního rozhraní do Hyperforce. Nejedná se o zaměnitelné ovládací prvky.
Společné pokyny společností Salesforce a AWS uvádějí, že Salesforce Express Connect není kompatibilní s Hyperforce a popisuje AWS Direct Connect s veřejným virtuálním rozhraním jako možnost pro některé zákazníky, kteří potřebují přímé připojení k Hyperforce. Také rozlišuje Private Connect, který propojuje organizaci Salesforce se službami AWS zákazníka. Před změnou architektury sítě si přečtěte pokyny AWS pro přístup k Hyperforce pomocí Direct Connect . Pro vaši organizaci je stále třeba zkontrolovat dostupnost, směrování a smluvní požadavky.
Ne. Incident Salesforce a incident AWS se mohou překrývat, ale nejsou synonyma. Salesforce zveřejňuje stav služby prostřednictvím svého webu Trust, zatímco AWS zveřejňuje stav služby a události specifické pro účet prostřednictvím AWS Health. Začněte se službou, která selhává, a přesnou oblastí nebo instancí, které se to týká, spíše než předpokládejte, že za to nese odpovědnost největší poskytovatel v databázi.
Použijte toto srovnání během incidentu:
| Pozorovaný příznak | První místo, kam se podívat | Interpretace k testování |
|---|---|---|
| Všichni uživatelé Salesforce se nemohou přihlásit ani používat více produktů. | Salesforce Trust, instance organizace a kanál podpory Salesforce | Narušení služeb v rámci celé Salesforce nebo na úrovni instance |
| Selže pouze jedna integrace podporovaná AWS | Protokoly aplikací, AWS Health, přihlašovací údaje, DNS a metriky koncových bodů | Problém s integrací zákazníka nebo službou AWS |
| Pouze jedna kancelář nebo VPC se nemůže spojit se Salesforce | Konfigurace tras, pravidel firewallu, DNS, přímého připojení a důvěryhodné IP adresy | Problém se síťovou cestou nebo lokální konfigurací |
| Uživatelské rozhraní Salesforce funguje, ale plánovaná synchronizace se zasekává. | Omezení API, token OAuth, hloubka fronty, opakované pokusy a integrační protokoly | Závislost na pracovním postupu nebo API spíše než dostupnost jádra |
| Jeden produkt nebo funkce není k dispozici | Dokumentace k stavu a vydání produktu Salesforce | Problém na úrovni komponenty, údržba nebo závislost funkce |
Toto rozlišení ovlivňuje eskalaci. Pokud systém Salesforce Trust nahlásí incident ovlivňující vaši instanci, shromážděte číslo incidentu a vyhněte se provádění destruktivních změn konfigurace. Pokud je systém Trust jasný, ale váš koncový bod AWS vykazuje chyby, uchovejte ID požadavků a prozkoumejte stranu AWS. Pokud se obě služby zdají být v pořádku, porovnejte přímý test Salesforce API, test koncového bodu AWS a úplnou integrační cestu; problém mezi funkčními službami je stále možný.
Hyperforce může změnit, kde jsou hostovány aplikace a data Salesforce, ale „regionální“ neznamená, že „každý bajt zůstává v každé situaci v jedné zemi“. Salesforce uvádí, že zákaznická data jsou obvykle uložena v zemi, kde se organizace nachází, pokud jsou tam dostupné používané služby. Také varuje, že některé produkty mohou mít komponenty v různých zemích nebo zahrnovat integrace se službami, které dosud na Hyperforce nejsou.
Toto upozornění je důležité, pokud je součástí návrhu AWS. Musíte namapovat alespoň čtyři umístění: organizaci Salesforce a její provozní region Hyperforce, region AWS, který obsahuje připojenou službu nebo data, umístění integračních pracovníků a protokolů a umístění záloh nebo kopií pro zotavení po havárii. Region AWS vybraný vaším týmem nepřepíše architekturu produktu Salesforce a možnost rezidentnosti dat Salesforce automaticky neumístí vaše externí data AWS do stejného regionu.
K ověření produktů, regionů a závazků, které se vztahují na vaše prostředí, použijte přehled infrastruktury veřejného cloudu Salesforce Hyperforce a dokumentaci o důvěryhodnosti a shodě s předpisy vaší organizace. V případě regulovaných dat nechte týmy pro ochranu osobních údajů, zabezpečení a právní oddělení zkontrolovat skutečné podmínky služby, a nespoléhejte se na obecný diagram architektury.
Odolnost začíná tím, že se pro každou obchodní akci vyhnete jedinému synchronnímu řetězci. Pokud transakce Salesforce musí čekat na službu AWS, definujte, co se stane, když je služba AWS pomalá nebo nedostupná. V závislosti na obchodním procesu může být fronta, opakování s exponenciálním odkladem, klíč idempotence, jistič, cesta k nedoručeným zprávám nebo ruční odsouhlasení bezpečnější než opakovaná synchronní volání.
Používejte omezené počet opakovaných pokusů. Opakovaný pokus, který pokračuje i během degradace Salesforce nebo AWS, může znásobit provoz a z krátkého incidentu udělat větší nevyřízené záležitosti. Zaznamenejte si původní požadavek, počet opakovaných pokusů, kód odpovědi a konečné vyřízení. Před povolením automatického přehrávání událostí zajistěte bezpečnost duplicitního doručení.
Oddělte cíle obnovy pro stranu Salesforce od cílů pro stranu AWS. Záloha databáze AWS neobnoví konfiguraci organizace Salesforce a možnost obnovy Salesforce neobnoví externí aplikaci AWS. Salesforce popisuje funkci obnovy po havárii mimo oblast pro bezpečné zálohování instance v sekundární oblasti Hyperforce, ale dostupnost a smluvní rozsah musí být ověřeny pro produkty a edici, které používáte. Neprezentujte tuto možnost jako univerzální plán pro převzetí služeb při selhání.
Nezakódujte pevně předpoklady o rozsahech IP adres veřejného cloudu, umístění poskytovatelů nebo chování produktů do dlouhodobého runbooku. Po migraci Hyperforce, spuštění nové oblasti, změně konektivity nebo vydání hlavní integrace si projděte aktuální dokumentaci Salesforce a AWS.
Užitečným výsledkem není jen „Salesforce používá AWS“. Užitečným výsledkem je ohraničený výrok, například: „Organizace Salesforce je dostupná, AWS je v pořádku, ale integrační pracovník nemůže vyřešit soukromý koncový bod“ nebo „Salesforce Trust hlásí problém s instancí, takže naše opakované pokusy na straně AWS jsou pozastaveny.“ Tato úroveň přesnosti říká dalšímu týmu, co má změnit – a co ne.
Salesforce a AWS jsou v některých částech moderní cloudové architektury úzce propojeny, zejména tam, kde Hyperforce běží na AWS nebo kde zákazník záměrně integruje Salesforce se službami AWS. Tento vztah není založen na jediné závislosti typu „všechno, nebo nic“. Jde o souhrn spravovaného hostingu, aplikačních služeb, síťových cest, datových umístění a integrací vytvořených zákazníkem.
Pro aktuální plánování použijte jako výchozí bod Často kladené otázky k Salesforce Hyperforce ze 4. srpna 2026 a poté ověřte konkrétní produkty a regiony ve vaší organizaci. Pro reakci na incidenty otestujte každou vrstvu nezávisle a před změnou konfigurace uchovejte důkazy. Cílem není eliminovat každou závislost; jde o to vědět, která závislost existuje, kdo ji vlastní, jak se projevuje selhání a jak se podnik zotaví, aniž by vznikl druhý problém.
Projděte si významné výpadky Salesforce v roce 2025, co selhalo, jak dlouho trvaly vybrané incidenty a praktické ponaučení z odolnosti, které mohou týmy uplatnit.
Vytvořte praktický plán pro zajištění kontinuity výpadků v Salesforce s analýzou dopadů, cíli RTO/RPO, manuálními řešeními, integračními kontrolami a kontrolami obnovy.
Zjistěte, jak kontaktovat podporu Salesforce během velkého výpadku: zkontrolujte stav důvěryhodnosti, vyberte správný kanál, začněte s důkladným podáním žádosti a sledujte obnovení.
Řešení problémů s přihlášením do Salesforce Workbench, REST Explorerem, časovým limitem, chybou 503, verzí API a omezením chyb během výpadků pomocí praktického diagnostického kontrolního seznamu.
StoreForce issues can disrupt scheduling, timekeeping, and employee workflows. Learn how to assess impact, keep stores operating, verify recovery, and know when to escalate.
Pochopte hlavní příčiny rozsáhlých výpadků cloudu, jak se selhání kaskádovitě šíří, co zkontrolovat jako první a jak navrhnout odolnější plán obnovy.
Pokud se zdá, že Datorama nebo Marketing Cloud Intelligence nefungují, použijte tento kontrolní seznam založený na důkazech k ověření výpadku, ochraně kvality reportů a zjištění, kdy jsou data opět důvěryhodná.
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.
An AWS outage does not automatically mean Salesforce is down. Learn how Hyperforce, regions, instances, and Salesforce Trust determine whether your org is affected.
