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 obrazac integracije između oblaka za povezivanje Salesforce organizacije s AWS uslugama klijenta. AWS Direct Connect je opcija mrežne povezivosti koja može pružiti put od lokalnog okruženja do AWS-a i, putem javnog virtualnog sučelja, do Hyperforcea. To nisu zamjenjive kontrole.
Zajedničke smjernice Salesforcea i AWS-a navode da Salesforce Express Connect nije kompatibilan s Hyperforceom i opisuju AWS Direct Connect s javnim virtualnim sučeljem kao opciju za neke korisnike kojima je potrebna izravna povezivost s Hyperforceom. Također razlikuju Private Connect, koji povezuje Salesforce organizaciju s AWS uslugama korisnika. Pročitajte AWS smjernice za pristup Hyperforceu s Direct Connectom prije promjene mrežne arhitekture. Zahtjevi za dostupnost, usmjeravanje i ugovor i dalje se moraju provjeriti za vašu organizaciju.
Ne. Incident u Salesforceu i incident u AWS-u mogu se preklapati, ali nisu sinonimi. Salesforce objavljuje status usluge putem svoje stranice za povjerenje, dok AWS objavljuje stanje usluge i događaje specifične za račun putem AWS Healtha. Počnite s uslugom koja ne radi i točnom regijom ili instancom o kojoj je riječ, umjesto da pretpostavite da je odgovoran najveći pružatelj usluga u stogu.
Koristite ovu usporedbu tijekom incidenta:
| Uočeni simptom | Prvo mjesto za pogledati | Interpretacija za testiranje |
|---|---|---|
| Svi korisnici Salesforcea ne mogu se prijaviti ili koristiti više proizvoda | Salesforce Trust, instanca organizacije i kanal podrške Salesforcea | Prekid usluge na razini cijelog Salesforcea ili instance |
| Samo jedna integracija koju podržava AWS ne uspijeva | Zapisnici aplikacija, AWS Health, vjerodajnice, DNS i metrike krajnjih točaka | Problem s integracijom korisnika ili uslugom AWS |
| Samo jedan ured ili VPC ne može dosegnuti Salesforce | Rute, pravila vatrozida, DNS, izravno povezivanje i konfiguracija pouzdane IP adrese | Problem s mrežnom putanjom ili lokalnom konfiguracijom |
| Salesforce UI radi, ali zakazana sinkronizacija se zaustavlja | API ograničenja, OAuth token, dubina reda čekanja, ponovni pokušaji i zapisnici integracije | Ovisnost o tijeku rada ili API-ju, a ne dostupnost jezgre |
| Jedan proizvod ili značajka nije dostupan | Dokumentacija o statusu i izdanju Salesforcea specifična za proizvod | Problem na razini komponente, održavanje ili ovisnost značajke |
Ova razlika utječe na eskalaciju. Ako Salesforce Trust prijavi incident koji utječe na vašu instancu, prikupite broj incidenta i izbjegavajte destruktivne promjene konfiguracije. Ako je Trust čist, ali vaša AWS krajnja točka pokazuje pogreške, sačuvajte ID-ove zahtjeva i istražite AWS stranu. Ako se oboje čini ispravnim, usporedite izravni Salesforce API test, AWS krajnja točka i potpuni put integracije; problem između ispravnih usluga je i dalje moguć.
Hyperforce može promijeniti gdje se hostiraju Salesforce aplikacije i podaci, ali „regionalno“ ne znači „svaki bajt ostaje u jednoj zemlji u svakoj situaciji“. Salesforce kaže da se podaci o korisnicima općenito pohranjuju u zemlji u kojoj se organizacija nalazi kada su usluge koje se koriste tamo dostupne. Također upozorava da neki proizvodi mogu imati komponente u različitim zemljama ili uključivati integracije s uslugama koje još nisu na Hyperforceu.
To upozorenje je važno kada je AWS dio dizajna. Morate mapirati barem četiri lokacije: Salesforce organizaciju i njezinu Hyperforce operativnu regiju, AWS regiju koja sadrži povezanu uslugu ili podatke, lokaciju integracijskih radnika i zapisnika te lokaciju sigurnosnih kopija ili kopija za oporavak od katastrofe. AWS regija koju odabere vaš tim ne nadjačava arhitekturu Salesforce proizvoda, a opcija prebivališta podataka Salesforcea ne smješta automatski vaše vanjske AWS podatke u istu regiju.
Koristite pregled infrastrukture javnog oblaka Salesforce Hyperforce i dokumentaciju o povjerenju i usklađenosti vaše organizacije kako biste provjerili proizvode, regije i obveze koje se primjenjuju na vaše okruženje. Za regulirane podatke, neka timovi za privatnost, sigurnost i pravni timovi pregledaju stvarne uvjete usluge umjesto da se oslanjaju na opći dijagram arhitekture.
Otpornost počinje izbjegavanjem jednog sinkronog lanca za svaku poslovnu radnju. Ako Salesforce transakcija mora čekati AWS uslugu, definirajte što se događa kada je AWS usluga spora ili nedostupna. Ovisno o poslovnom procesu, red čekanja, ponovni pokušaj s eksponencijalnim odustajanjem, ključ idempotentnosti, prekidač strujnog kruga, put mrtvih slova ili ručno usklađivanje mogu biti sigurniji od ponovljenih sinkronih poziva.
Koristite ograničene ponovne pokušaje. Ponovni pokušaj koji se nastavlja dok je Salesforce ili AWS degradiran može umnožiti promet i pretvoriti kratki incident u veći zaostatak. Zabilježite izvorni zahtjev, broj ponovnih pokušaja, kod odgovora i konačno rješenje. Osigurajte dupliciranu isporuku prije omogućavanja automatske reprodukcije događaja.
Odvojite ciljeve oporavka za Salesforce stranu od ciljeva za AWS stranu. Sigurnosna kopija AWS baze podataka ne vraća konfiguraciju Salesforce organizacije, a opcija oporavka Salesforcea ne vraća vanjsku AWS aplikaciju. Salesforce opisuje mogućnost oporavka od katastrofe izvan regije za sigurnu sigurnosnu kopiju instance u sekundarnoj Hyperforce regiji, ali dostupnost i ugovorni opseg moraju se provjeriti za proizvode i izdanje koje koristite. Nemojte predstavljati tu opciju kao univerzalni plan prebacivanja u slučaju kvara.
Nemojte u dugotrajni runbook ugrađivati pretpostavke o rasponima IP adresa javnog oblaka, postavljanju pružatelja usluga ili ponašanju proizvoda. Pregledajte trenutnu dokumentaciju za Salesforce i AWS nakon migracije Hyperforcea, pokretanja nove regije, promjene povezivosti ili velikog izdanja integracije.
Koristan rezultat nije jednostavno „Salesforce koristi AWS“. Koristan rezultat je ograničena izjava kao što je: „Salesforce organizacija je dostupna, AWS je ispravan, ali integracijski radnik ne može riješiti privatnu krajnju točku“ ili „Salesforce Trust prijavljuje problem s instancom, pa su naši ponovni pokušaji na strani AWS-a zadržani.“ Ta razina preciznosti govori sljedećem timu što treba promijeniti, a što ne.
Salesforce i AWS su usko povezani u dijelovima moderne cloud arhitekture, posebno tamo gdje Hyperforce radi na AWS-u ili gdje korisnik namjerno integrira Salesforce s AWS uslugama. Odnos nije jedna ovisnost tipa "sve ili ništa". To je skup upravljanog hostinga, aplikacijskih usluga, mrežnih putova, lokacija podataka i integracija koje je izgradio korisnik.
Za trenutno planiranje, kao početnu točku koristite Salesforce Hyperforce FAQ od 4. kolovoza 2026., a zatim provjerite specifične proizvode i regije u svojoj organizaciji. Za odgovor na incidente, testirajte svaki sloj neovisno i sačuvajte dokaze prije promjene konfiguracije. Cilj nije eliminirati svaku ovisnost; cilj je znati koja ovisnost postoji, tko je vlasnik, kako se kvar pojavljuje i kako se poslovanje oporavlja bez stvaranja drugog problema.
Pregledajte značajne prekide rada Salesforcea u 2025. godini, što je zakazalo, koliko su dugo trajali odabrani incidenti i praktične lekcije o otpornosti koje timovi mogu primijeniti.
Izradite praktičan plan za kontinuitet zastoja u Salesforceu s analizom utjecaja, ciljevima RTO/RPO, ručnim rješenjima, kontrolama integracije i provjerama oporavka.
Naučite kako kontaktirati Salesforce podršku tijekom većeg prekida: provjerite status povjerenja, odaberite pravi kanal, otvorite snažan slučaj i pratite oporavak.
Rješavanje problema s prijavom u Salesforce Workbench, REST Explorerom, timeoutom, 503, verzijom API-ja i ograničavanje pogrešaka tijekom zastoja pomoću praktičnog dijagnostičkog popisa za provjeru.
Problemi sa StoreForceom mogu poremetiti raspoređivanje, evidenciju vremena i tijekove rada zaposlenika. Naučite kako procijeniti utjecaj, održati trgovine u funkciji, provjeriti oporavak i znati kada eskalirati problem.
Razumjeti glavne uzroke raširenih prekida rada u oblaku, kako se kvarovi kaskadno prenose, što prvo provjeriti i kako osmisliti otporniji plan oporavka.
If Datorama or Marketing Cloud Intelligence seems down, use this evidence-based checklist to verify the outage, protect reporting quality, and know when data is trustworthy again.
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.
Prekid rada AWS-a ne znači automatski da je Salesforce u kvaru. Saznajte kako Hyperforce, regije, instance i Salesforce Trust određuju je li vaša organizacija pogođena.
