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 er et cross-cloud-integrationsmønster til at forbinde en Salesforce-organisation med en kundes AWS-tjenester. AWS Direct Connect er en netværksforbindelsesmulighed, der kan give en sti fra et lokalt miljø til AWS og, via en offentlig virtuel grænseflade, til Hyperforce. De er ikke udskiftelige kontroller.
Den fælles vejledning fra Salesforce og AWS siger, at Salesforce Express Connect ikke er kompatibel med Hyperforce, og beskriver AWS Direct Connect med en offentlig virtuel grænseflade som en mulighed for nogle kunder, der har brug for direkte forbindelse til Hyperforce. Den skelner også mellem Private Connect, som forbinder en Salesforce-organisation til en kundes AWS-tjenester. Læs AWS-vejledningen for at få adgang til Hyperforce med Direct Connect, før du ændrer netværksarkitekturen. Tilgængelighed, routing og kontraktkrav skal stadig kontrolleres for din organisation.
Nej. En Salesforce-hændelse og en AWS-hændelse kan overlappe hinanden, men de er ikke synonymer. Salesforce offentliggør servicestatus via sit Trust-websted, mens AWS offentliggør servicetilstand og kontospecifikke hændelser via AWS Health. Start med den service, der fejler, og den præcise region eller instans, der er involveret, i stedet for at antage, at den største udbyder i stakken er ansvarlig.
Brug denne sammenligning under en hændelse:
| Observeret symptom | Første sted at kigge | Fortolkning til test |
|---|---|---|
| Alle Salesforce-brugere kan ikke logge ind eller bruge flere produkter | Salesforce Trust, organisationsinstans og Salesforce supportkanal | Salesforce-dækkende eller instansniveau-tjenesteafbrydelse |
| Kun én AWS-baseret integration mislykkes | Applikationslogfiler, AWS Health, legitimationsoplysninger, DNS og slutpunktsmålinger | Kundeintegration eller AWS-serviceproblem |
| Kun ét kontor eller én VPC kan ikke nå Salesforce | Ruter, firewallregler, DNS, Direct Connect og konfiguration af betroede IP-adresser | Problem med netværkssti eller lokal konfiguration |
| Salesforce-brugergrænsefladen fungerer, men en planlagt synkronisering går i stå | API-grænser, OAuth-token, kødybde, genforsøg og integrationslogfiler | Workflow- eller API-afhængighed snarere end kernetilgængelighed |
| Ét produkt eller én funktion er ikke tilgængelig | Produktspecifik Salesforce-status og udgivelsesdokumentation | Problem på komponentniveau, vedligeholdelse eller funktionsafhængighed |
Denne sondring påvirker eskalering. Hvis Salesforce Trust rapporterer en hændelse, der påvirker din instans, skal du indsamle hændelsesnummeret og undgå at foretage destruktive konfigurationsændringer. Hvis Trust er tydelig, men dit AWS-slutpunkt viser fejl, skal du bevare anmodnings-ID'er og undersøge AWS-siden. Hvis begge ser ud til at være sunde, skal du sammenligne en direkte Salesforce API-test, en AWS-slutpunktstest og den fulde integrationssti; et problem mellem sunde tjenester er stadig muligt.
Hyperforce kan ændre, hvor Salesforce-applikationer og -data hostes, men "regional" betyder ikke, at "hver byte forbliver i ét land i enhver situation". Salesforce siger, at kundedata generelt gemmes i det land, hvor organisationen er placeret, når de tjenester, der er i brug, er tilgængelige der. De advarer også om, at nogle produkter kan have komponenter i forskellige lande eller inkludere integrationer til tjenester, der endnu ikke er på Hyperforce.
Denne advarsel er vigtig, når AWS er en del af designet. Du skal kortlægge mindst fire placeringer: Salesforce-organisationen og dens Hyperforce-driftsområde, den AWS-region, der indeholder den tilsluttede tjeneste eller data, placeringen af integrationsmedarbejdere og logfiler, og placeringen af sikkerhedskopier eller gendannelseskopier efter nedbrud. En AWS-region valgt af dit team tilsidesætter ikke Salesforces produktarkitektur, og en Salesforce-dataopholdsmulighed placerer ikke automatisk dine eksterne AWS-data i samme region.
Brug oversigten over Salesforce Hyperforce public-cloud-infrastrukturen og din organisations dokumentation for tillid og overholdelse af regler til at validere de produkter, regioner og forpligtelser, der gælder for dit miljø. For regulerede data bør du få teams inden for privatliv, sikkerhed og juridiske tjenester til at gennemgå de faktiske servicevilkår i stedet for at stole på et generelt arkitekturdiagram.
Modstandsdygtighed begynder med at undgå en enkelt synkron kæde for hver forretningshandling. Hvis en Salesforce-transaktion skal vente på en AWS-tjeneste, skal du definere, hvad der sker, når AWS-tjenesten er langsom eller utilgængelig. Afhængigt af forretningsprocessen kan en kø, et nyt forsøg med eksponentiel backoff, en idempotensnøgle, en afbryder, en sti til dødt brev eller en manuel afstemning være sikrere end gentagne synkrone kald.
Brug begrænsede genforsøg. Et genforsøg, der fortsætter, mens Salesforce eller AWS er nedbrudt, kan mangedoble trafikken og forvandle en kortvarig hændelse til en større efterslæb. Registrer den oprindelige anmodning, antallet af genforsøg, svarkoden og den endelige afvikling. Sørg for, at duplikatlevering er sikker, før du aktiverer automatisk afspilning af hændelser.
Adskil gendannelsesmål for Salesforce-siden fra mål for AWS-siden. En sikkerhedskopi af en AWS-database gendanner ikke en Salesforce-organisationskonfiguration, og en Salesforce-gendannelsesmulighed gendanner ikke en ekstern AWS-applikation. Salesforce beskriver en Out of Region Disaster Recovery-funktion til sikker sikkerhedskopiering af en instans i en sekundær Hyperforce-region, men tilgængelighed og kontraktmæssigt omfang skal verificeres for de produkter og den udgave, du bruger. Præsenter ikke denne mulighed som en universel failover-plan.
Undlad at hardcode antagelser om IP-intervaller i den offentlige cloud, udbyderplacering eller produktadfærd i en langtidsholdbar runbook. Gennemgå den aktuelle Salesforce- og AWS-dokumentation efter en Hyperforce-migrering, en lancering af en ny region, en ændring af forbindelsen eller en større integrationsudgivelse.
Et nyttigt resultat er ikke blot "Salesforce bruger AWS." Det nyttige resultat er en afgrænset sætning såsom: "Salesforce-organisationen kan nås, AWS er sund, men integrationsarbejderen kan ikke løse det private slutpunkt," eller "Salesforce Trust rapporterer et instansproblem, så vores AWS-sidede forsøg tilbageholdes." Dette præcisionsniveau fortæller det næste team, hvad de skal ændre – og hvad de ikke skal ændre.
Salesforce og AWS er tæt forbundet i dele af den moderne cloudarkitektur, især hvor Hyperforce kører på AWS, eller hvor en kunde bevidst integrerer Salesforce med AWS-tjenester. Forholdet er ikke en enkelt alt-eller-intet-afhængighed. Det er en stak af administreret hosting, applikationstjenester, netværksstier, dataplaceringer og kundebyggede integrationer.
Brug Salesforce Hyperforce FAQ fra 4. august 2026 som udgangspunkt for den aktuelle planlægning, og bekræft derefter de specifikke produkter og regioner i din organisation. For hændelsesrespons skal du teste hvert lag uafhængigt og bevare beviser, før du ændrer konfigurationen. Målet er ikke at eliminere alle afhængigheder; det er at vide, hvilken afhængighed der findes, hvem der ejer den, hvordan fejl opstår, og hvordan virksomheden genopretter sig uden at skabe et andet problem.
Gennemgå bemærkelsesværdige Salesforce-nedbrud i 2025, hvad der fejlede, hvor længe udvalgte hændelser varede, og de praktiske erfaringer om modstandsdygtighed, som teams kan anvende.
Byg en praktisk Salesforce-plan for kontinuitet i nedetid med konsekvensanalyse, RTO/RPO-mål, manuelle løsninger, integrationskontroller og genoprettelsestjek.
Lær, hvordan du kontakter Salesforce Support under et større nedbrud: Tjek tillidsstatus, vælg den rigtige kanal, åbn en stærk sag, og spor gendannelse.
Fejlfind Salesforce Workbench login, REST Explorer, timeout, 503, API-version og begræns fejl under nedetid med en praktisk diagnostisk tjekliste.
StoreForce issues can disrupt scheduling, timekeeping, and employee workflows. Learn how to assess impact, keep stores operating, verify recovery, and know when to escalate.
Forstå de vigtigste årsager til udbredt nedetid i skyen, hvordan fejl opstår i flere omgange, hvad man skal kontrollere først, og hvordan man designer en mere robust genopretningsplan.
Hvis Datorama eller Marketing Cloud Intelligence ser ud til at være nede, kan du bruge denne evidensbaserede tjekliste til at verificere nedbruddet, beskytte rapporteringskvaliteten og vide, hvornår data er troværdige igen.
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.
Et AWS-nedbrud betyder ikke automatisk, at Salesforce er nede. Lær, hvordan Hyperforce, regioner, instanser og Salesforce Trust afgør, om din organisation er berørt.
