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.
A Salesforce Private Connect egy felhőalapú integrációs minta, amely egy Salesforce szervezetet csatlakoztat az ügyfél AWS szolgáltatásaihoz. Az AWS Direct Connect egy hálózati kapcsolódási lehetőség, amely elérési utat biztosíthat egy helyszíni környezetből az AWS-be, és egy nyilvános virtuális interfészen keresztül a Hyperforce-ba. Ezek nem felcserélhető vezérlők.
A Salesforce és az AWS közös útmutatója szerint a Salesforce Express Connect nem kompatibilis a Hyperforce-szal, és az AWS Direct Connectet egy nyilvános virtuális felülettel opcióként írja le azon ügyfelek számára, akiknek közvetlen kapcsolatra van szükségük a Hyperforce-hoz. Megkülönbözteti a Private Connectet is, amely egy Salesforce szervezetet csatlakoztat az ügyfél AWS szolgáltatásaihoz. A hálózati architektúra módosítása előtt olvassa el az AWS útmutatóját a Hyperforce Direct Connecttel történő eléréséről . A szervezet elérhetőségét, útválasztását és szerződéses követelményeit továbbra is ellenőrizni kell.
Nem. Egy Salesforce és egy AWS incidens átfedésben lehet, de nem szinonimák. A Salesforce a Trust webhelyén teszi közzé a szolgáltatás állapotát, míg az AWS az AWS Health oldalon teszi közzé a szolgáltatás állapotát és a fiókspecifikus eseményeket. Kezdjük a hibás szolgáltatással és az érintett pontos régióval vagy példánnyal, ahelyett, hogy feltételeznénk, hogy a veremben lévő legnagyobb szolgáltató a felelős.
Használja ezt az összehasonlítást egy incidens során:
| Megfigyelt tünet | Első hely, ahol keresni kell | Értelmezés a teszteléshez |
|---|---|---|
| A Salesforce összes felhasználója nem tud bejelentkezni vagy több terméket használni. | Salesforce Trust, szervezeti példány és Salesforce támogatási csatorna | Salesforce-szintű vagy példányszintű szolgáltatáskimaradás |
| Csak egy AWS által támogatott integráció hibásodott meg | Alkalmazásnaplók, AWS Health, hitelesítő adatok, DNS és végponti metrikák | Ügyfélintegrációs vagy AWS szolgáltatási probléma |
| Csak egy iroda vagy VPC nem tudja elérni a Salesforce-t | Útvonalak, tűzfalszabályok, DNS, közvetlen kapcsolat és megbízható IP-konfiguráció | Hálózati elérési út vagy helyi konfigurációs probléma |
| A Salesforce felhasználói felület működik, de az ütemezett szinkronizálás elakad. | API-korlátok, OAuth-token, várólista-mélység, újrapróbálkozások és integrációs naplók | Munkafolyamat- vagy API-függőség a mag elérhetősége helyett |
| Egy termék vagy funkció nem érhető el | Termékspecifikus Salesforce állapot és kiadási dokumentáció | Komponens szintű probléma, karbantartás vagy funkciófüggőség |
Ez a megkülönböztetés befolyásolja az eszkalációt. Ha a Salesforce Trust a példányodat érintő incidenst jelent, gyűjtsd össze az incidens számát, és kerüld a destruktív konfigurációs változtatásokat. Ha a Trust tiszta, de az AWS végpont hibákat mutat, őrizd meg a kérésazonosítókat, és vizsgáld meg az AWS oldalt. Ha mindkettő egészségesnek tűnik, hasonlíts össze egy közvetlen Salesforce API tesztet, egy AWS végpont tesztet és a teljes integrációs útvonalat; az egészséges szolgáltatások közötti probléma továbbra is lehetséges.
A Hyperforce megváltoztathatja a Salesforce alkalmazások és adatok tárolási helyét, de a „regionális” nem azt jelenti, hogy „minden bájt minden helyzetben egy országban marad”. A Salesforce szerint az ügyféladatokat általában abban az országban tárolják, ahol a szervezet található, ha a használt szolgáltatások ott elérhetők. Azt is figyelmezteti, hogy egyes termékeknek lehetnek különböző országokban található összetevői, vagy olyan szolgáltatásokkal való integrációkat tartalmazhatnak, amelyek még nem szerepelnek a Hyperforce-on.
Ez a kikötés fontos, ha az AWS a terv része. Legalább négy helyszínt kell leképezni: a Salesforce szervezetet és annak Hyperforce működési régióját, a csatlakoztatott szolgáltatást vagy adatokat tároló AWS régiót, az integrációs munkatársak és naplók helyét, valamint a biztonsági mentések vagy katasztrófa utáni helyreállítási másolatok helyét. A csapat által kiválasztott AWS régió nem írja felül a Salesforce termékarchitektúráját, és a Salesforce adattárolási beállítása nem helyezi automatikusan a külső AWS adatokat ugyanabba a régióba.
A Salesforce Hyperforce nyilvános felhőinfrastruktúra áttekintését és szervezete megbízhatósági és megfelelőségi dokumentációját használva ellenőrizheti a környezetére vonatkozó termékeket, régiókat és kötelezettségvállalásokat. Szabályozott adatok esetén az adatvédelmi, biztonsági és jogi csapatokkal a tényleges szolgáltatási feltételeket tekintse át, ahelyett, hogy egy általános architektúradiagramra hagyatkozna.
A rugalmasság azzal kezdődik, hogy minden üzleti művelethez el kell kerülni egyetlen szinkron láncot. Ha egy Salesforce tranzakciónak várnia kell egy AWS szolgáltatásra, akkor határozza meg, mi történik, ha az AWS szolgáltatás lassú vagy nem érhető el. Az üzleti folyamattól függően a várakozási sor, az exponenciális várakozással történő újrapróbálkozás, az idempotencia kulcs, a megszakító, a kézbesítetlen levelek elérési útja vagy a manuális egyeztetés biztonságosabb lehet, mint az ismételt szinkron hívások.
Használjon korlátozott újrapróbálkozásokat. Az újrapróbálkozások, amelyek a Salesforce vagy az AWS gyenge teljesítménye mellett is folytatódnak, megsokszorozhatják a forgalmat, és egy rövid incidenst nagyobb várakozássá alakíthatnak. Jegyezze fel az eredeti kérést, az újrapróbálkozások számát, a válaszkódot és a végső döntést. Az események automatikus visszajátszásának engedélyezése előtt tegye biztonságossá a duplikált kézbesítést.
Különítse el a Salesforce oldal helyreállítási célkitűzéseit az AWS oldal célkitűzéseitől. Az AWS adatbázis biztonsági mentése nem állítja vissza a Salesforce szervezet konfigurációját, és a Salesforce helyreállítási opciója nem állít vissza külső AWS alkalmazást. A Salesforce leír egy régión kívüli katasztrófa-helyreállítási funkciót egy másodlagos Hyperforce régióban lévő példány biztonságos biztonsági mentéséhez, de az elérhetőséget és a szerződéses hatókört ellenőrizni kell a használt termékek és kiadások esetében. Ne mutassa be ezt az opciót univerzális feladatátvételi tervként.
Ne fixen kódoljon be feltételezéseket a nyilvános felhőbeli IP-tartományokról, a szolgáltatók elhelyezéséről vagy a termékek viselkedéséről egy hosszú élettartamú runbookba. Tekintse át az aktuális Salesforce és AWS dokumentációt Hyperforce migráció, új régió bevezetése, csatlakozási változás vagy jelentős integrációs kiadás után.
Egy hasznos eredmény nem egyszerűen az, hogy „A Salesforce AWS-t használ”. A hasznos eredmény egy korlátozott utasítás, például: „A Salesforce szervezet elérhető, az AWS egészséges, de az integrációs munkatárs nem tudja feloldani a privát végpontot”, vagy „A Salesforce Trust példányhibát jelent, ezért az AWS-oldali újrapróbálkozásainkat felfüggesztettük”. Ez a pontossági szint megmondja a következő csapatnak, hogy mit kell megváltoztatnia – és mit nem.
A Salesforce és az AWS szorosan összekapcsolódik a modern felhőarchitektúra egyes részein, különösen ott, ahol a Hyperforce az AWS-en fut, vagy ahol az ügyfél szándékosan integrálja a Salesforce-t az AWS szolgáltatásaival. A kapcsolat nem egyetlen „mindent vagy semmit” függőség. Ez egy felügyelt tárhely, alkalmazásszolgáltatások, hálózati útvonalak, adathelyek és ügyfél által készített integrációk halmaza.
A jelenlegi tervezéshez használja a 2026. augusztus 4-i Salesforce Hyperforce GYIK-et kiindulópontként, majd ellenőrizze a szervezetében található konkrét termékeket és régiókat. Az incidensekre adott válaszok esetében tesztelje az egyes rétegeket külön-külön, és őrizze meg a bizonyítékokat a konfiguráció módosítása előtt. A cél nem az összes függőség kiküszöbölése; az a cél, hogy tudjuk, melyik függőség létezik, kié a tulajdonosa, hogyan jelenik meg a hiba, és hogyan áll helyre a vállalkozás anélkül, hogy második problémát okozna.
Gyakorlati útmutató az otthoni energiatároláshoz: működés, kWh és kW, LFP és más akkumulátortechnológiák, napelem-kompatibilitás, biztonság és választási szempontok.
Budapesti októberi útlezárások és közlekedési változások: Erzsébet híd, Budafoki út, MÁV-vágányzárak, maraton, parkolás és aktuális kerülők.
Budapest 2026. októberi zárvatartásai: FSZEK, múzeumok, Magyar Posta, fővárosi ügyfélszolgálatok és kormányablakok, október 23-i eltérésekkel és online lehetőségekkel.
Így ellenőrizd a budapesti hulladékszállítást 2026 októberében: október 23., cím szerinti kukanaptár, zöldhulladék, lomtalanítás, pótszállítás és hulladékudvarok.
A 2026/2027-es tanév hivatalos rendje alapján: utolsó tanítási nap, őszi szünet, visszatérés, október 23., helyi eltérések és iskolai munkanapok Budapesten.
Hivatalos 2026. októberi családi pótlék- és nyugdíjfizetési dátumok Magyarországon, banki jóváírás, postai kézbesítés és késés esetén ellenőrzendő lépések.
Ukrajna 1–0-ra nyert Budapesten a 2026-os Nemzetek Ligája B2-es nyitómeccsén. Összefoglaljuk Sikan gólját, a magyar helyzeteket és a hajrát.
Gyakorlati útmutató az MI biztonságos használatához: adatvédelem, tényellenőrzés, csalások felismerése és fontos döntések emberi kontrollal.
Kamat, hozam, lejárat, árfolyam és kockázatok: gyakorlati útmutató ahhoz, mit ellenőrizz kötvényvásárlás előtt, példákkal és ellenőrzőlistával.
Mekkora hatótávra van szüksége, és mikor éri meg az elektromos autó? Ismerje meg a WLTP korlátait, a töltés és a költségek számítását, valamint a használt autók ellenőrzését.
