När en Salesforce-sida blir långsammare eller en integration slutar leverera poster ställer team ofta en enkel fråga: "Lägger AWS nere, eller ligger Salesforce nere?" Den frågan är förståelig, men den kan leda till fel undersökning. Salesforce är en mjukvaruleverantör, AWS är en molninfrastrukturleverantör, och förhållandet mellan dem ändras beroende på Salesforce-produkt, organisation, region, nätverksväg och integrationsdesign.
En verifierad uppdatering ger relationen användbar kontext. Salesforce Help publicerade en uppdaterad Hyperforce FAQ den 4 augusti 2026. Den säger att Hyperforce är tillgängligt på Amazon Web Services (AWS), med Google Cloud Platform planerad till att vara tillgängligt från slutet av 2026, och att Salesforce hanterar infrastrukturplacering med hjälp av tekniska och operativa faktorer. Samma FAQ säger att vissa produkter eller funktioner initialt kan vara tillgängliga på Hyperforce på AWS medan de ännu inte är tillgängliga på GCP. Detta betyder inte att varje Salesforce-tjänst finns på AWS, att varje kund väljer den underliggande leverantören eller att en AWS-incident automatiskt blir en Salesforce-incident. Den här guiden förklarar beroendet i dessa lager med hjälp av information som kontrollerades den 16 september 2026.
”Beroende” kan beskriva flera olika relationer. Den viktigaste skillnaden är mellan ett beroende för en hanterad tjänst och en kundskapad integration:
| Lager | Vad som är kopplat | Vem brukar styra det | Hur ett misslyckande kan se ut |
|---|---|---|---|
| Salesforce-applikation | CRM-produkter, API:er, identitet, metadata och affärslogik | Salesforce | Inloggningsfel, API-fel, långsamma sidor eller otillgängliga funktioner |
| Hyperforce-infrastruktur | Salesforce-applikationsstackar distribuerade på publik molninfrastruktur | Salesforce hanterar placeringen; molnleverantören driver sina underliggande tjänster | Regionala kapacitets-, nätverks-, lagrings- eller infrastruktureffekter |
| Kundintegration | Salesforce ansluten till AWS-tjänster såsom applikationer, datalager eller händelsepipelines | Era integrations- och driftteam, med leverantörsspecifika kontroller | Timeouts, autentiseringsfel, saknade händelser eller misslyckade skrivningar |
| Nätverksväg | Internet, privat anslutning, DNS, brandväggar, routing eller direktanslutning | Kund, telekom, AWS och Salesforce beroende på sökvägen | Endast ett kontor, en VPC, en region eller en applikation kan inte ansluta |
| Data och efterlevnad | Var data lagras, bearbetas, säkerhetskopieras och överförs | Delas mellan produktkonfiguration, kontrakt och arkitektur | Frågor om bosättning, blockerade överföringar eller ett revisionsresultat |
Tabellen är en felsökningsmodell, inte ett påstående om att varje Salesforce-produkt använder varje AWS-komponent. Kontrollera den produktspecifika dokumentationen och din orderkonfiguration innan du fattar ett beslut om arkitektur eller efterlevnad.
Nej. Hyperforce är Salesforces infrastrukturarkitektur. Salesforce beskriver den som en publik molnarkitektur som hanteras som kod, utformad för att stödja global leverans, datalagring, säkerhet, skalbarhet och flexibilitet. AWS är en publik molnleverantör där Hyperforce är tillgänglig. Plattformsnamnet, Salesforce-produkten och den underliggande molnleverantören är därför olika delar av stacken.
Den uppdaterade Salesforce FAQ säger att Salesforce hanterar infrastrukturplacering baserat på tekniska och operativa faktorer. För en kund innebär det att en organisation som körs på Hyperforce inte ska behandlas som ett AWS-konto där kunden väljer en tillgänglighetszon, ändrar en EC2-instans eller öppnar en säkerhetsgrupp. Salesforce driver den hanterade SaaS-miljön. Ditt team kan fortfarande ha AWS-beroenden runt sig – till exempel en datapipeline, privat anslutning, händelsekonsument eller applikation som finns i ditt AWS-konto – men dessa är separata från Salesforces egen infrastrukturplacering.
Salesforce noterar också att tjänster som inte finns på Hyperforce fortsätter att fungera som tidigare, och att produkttillgängligheten kan variera beroende på leverantör av publika molntjänster. För aktuell produkt- och leverantörsinformation, se Salesforce Hyperforce FAQ och migreringsguide . Behandla den sidan som versionsbaserad operativ vägledning snarare än ett permanent löfte: Salesforce säger att dokumentet är informativt och kan komma att ändras.
Detta är det närmaste man kan komma ett direkt infrastrukturberoende. Om en viss Salesforce-organisation och produkt placeras på Hyperforce på AWS, kan en incident i en relevant AWS-region eller tjänst bli en faktor i Salesforces tillgänglighet. Men det faktiska kundvända felet kan orsakas av Salesforce-applikationskod, ett Salesforce-kontrollplan, ett beroende i en annan region, ett routningsproblem eller en produktspecifik tjänst. Att se AWS som den underliggande leverantören räcker inte för att identifiera grundorsaken.
Detta är ofta det beroende som kunderna först märker. En Salesforce-organisation kan skicka data till en AWS-värdbaserad tjänst, ta emot händelser från en kö, anropa ett API i en VPC, läsa från en dataplattform eller använda en AWS-tjänst som en del av ett applikationsarbetsflöde. I den här designen kan Salesforce vara felfri medan din AWS-slutpunkt, autentiseringsuppgifter, nätverksrutt eller händelsekonsument misslyckas. Det omvända är också möjligt: AWS kan vara felfri medan Salesforce API eller autentiseringslagret inte är tillgängligt.
Salesforce Private Connect är ett molnöverskridande integrationsmönster för att ansluta en Salesforce-organisation till en kunds AWS-tjänster. AWS Direct Connect är ett nätverksanslutningsalternativ som kan tillhandahålla en väg från en lokal miljö till AWS och, via ett publikt virtuellt gränssnitt, till Hyperforce. De är inte utbytbara kontroller.
Den gemensamma vägledningen från Salesforce och AWS säger att Salesforce Express Connect inte är kompatibelt med Hyperforce, och beskriver AWS Direct Connect med ett publikt virtuellt gränssnitt som ett alternativ för vissa kunder som behöver direkt anslutning till Hyperforce. Den skiljer också på Private Connect, som ansluter en Salesforce-organisation till en kunds AWS-tjänster. Läs AWS-vägledningen för att komma åt Hyperforce med Direct Connect innan du ändrar nätverksarkitekturen. Tillgänglighet, routing och kontraktskrav måste fortfarande kontrolleras för din organisation.
Nej. En Salesforce-incident och en AWS-incident kan överlappa varandra, men de är inte synonymer. Salesforce publicerar tjänststatus via sin Trust-webbplats, medan AWS publicerar tjänstens hälsa och kontospecifika händelser via AWS Health. Börja med den tjänst som inte fungerar och den exakta regionen eller instansen som är inblandad, snarare än att anta att den största leverantören i stacken är ansvarig.
Använd denna jämförelse under en incident:
| Observerat symptom | Första stället att titta på | Tolkning för att testa |
|---|---|---|
| Alla Salesforce-användare kan inte logga in eller använda flera produkter | Salesforce Trust, organisationsinstans och Salesforce supportkanal | Salesforce-omfattande eller instansnivåtjänststörning |
| Endast en AWS-stödd integration misslyckas | Applikationsloggar, AWS Health, inloggningsuppgifter, DNS och slutpunktsstatistik | Kundintegration eller problem med AWS-tjänsten |
| Endast ett kontor eller en VPC kan inte nå Salesforce | Rutter, brandväggsregler, DNS, direktanslutning och betrodd IP-konfiguration | Problem med nätverkssökväg eller lokal konfiguration |
| Salesforce-gränssnittet fungerar men en schemalagd synkronisering stannar | API-gränser, OAuth-token, ködjup, återförsök och integrationsloggar | Arbetsflödes- eller API-beroende snarare än kärntillgänglighet |
| En produkt eller funktion är inte tillgänglig | Produktspecifik Salesforce-status och releasedokumentation | Problem på komponentnivå, underhåll eller funktionsberoende |
Denna skillnad påverkar eskalering. Om Salesforce Trust rapporterar en incident som påverkar din instans, samla in incidentnumret och undvik att göra destruktiva konfigurationsändringar. Om Trust är tydligt men din AWS-slutpunkt visar fel, bevara förfrågnings-ID:n och undersök AWS-sidan. Om båda verkar vara felfria, jämför ett direkt Salesforce API-test, ett AWS-slutpunktstest och den fullständiga integrationsvägen; ett problem mellan felfria tjänster är fortfarande möjligt.
Hyperforce kan ändra var Salesforce-applikationer och data lagras, men "regional" betyder inte att "varje byte stannar i ett land i varje situation". Salesforce säger att kunddata generellt lagras i det land där organisationen är belägen när de tjänster som används är tillgängliga där. De varnar också för att vissa produkter kan ha komponenter i olika länder eller inkludera integrationer med tjänster som ännu inte finns på Hyperforce.
Den förbehållsregeln är viktig när AWS är en del av designen. Du måste mappa minst fyra platser: Salesforce-organisationen och dess Hyperforce-driftsregion, AWS-regionen som innehåller den anslutna tjänsten eller data, platsen för integrationsarbetare och loggar, och platsen för säkerhetskopior eller katastrofåterställningskopior. En AWS-region som valts av ditt team åsidosätter inte Salesforces produktarkitektur, och ett Salesforce-dataresidentalternativ placerar inte automatiskt dina externa AWS-data i samma region.
Använd översikten över Salesforce Hyperforces publika molninfrastruktur och din organisations dokumentation om förtroende och efterlevnad för att validera de produkter, regioner och åtaganden som gäller för din miljö. För reglerad data, låt integritets-, säkerhets- och juridiska team granska de faktiska servicevillkoren istället för att förlita sig på ett generellt arkitekturdiagram.
Motståndskraft börjar med att undvika en enda synkron kedja för varje affärsåtgärd. Om en Salesforce-transaktion måste vänta på en AWS-tjänst, definiera vad som händer när AWS-tjänsten är långsam eller otillgänglig. Beroende på affärsprocessen kan en kö, ett nytt försök med exponentiell backoff, en idempotensnyckel, en kretsbrytare, en sökväg för oåtkomliga meddelanden eller manuell avstämning vara säkrare än upprepade synkrona anrop.
Använd begränsade återförsök. Ett återförsök som fortsätter medan Salesforce eller AWS är nedgraderat kan mångfaldiga trafiken och förvandla en kort incident till en större eftersläpning. Registrera den ursprungliga begäran, antalet återförsök, svarskoden och den slutliga lösningen. Säkerställ leverans av duplicerade försök innan du aktiverar automatisk uppspelning av händelser.
Separera återställningsmål för Salesforce-sidan från mål för AWS-sidan. En säkerhetskopia av en AWS-databas återställer inte en Salesforce-organisationskonfiguration, och ett återställningsalternativ för Salesforce återställer inte en extern AWS-applikation. Salesforce beskriver en funktion för katastrofåterställning utanför regionen för en säker säkerhetskopiering av en instans i en sekundär Hyperforce-region, men tillgänglighet och avtalsenligt omfattning måste verifieras för de produkter och den utgåva du använder. Presentera inte det alternativet som en universell redundansplan.
Hårdkoda inte antaganden om IP-intervall, leverantörsplacering eller produktbeteende i publika moln i en långlivad runbook. Granska den aktuella Salesforce- och AWS-dokumentationen efter en Hyperforce-migrering, en ny regionlansering, en anslutningsändring eller en större integrationsrelease.
Ett användbart resultat är inte bara ”Salesforce använder AWS”. Det användbara resultatet är ett begränsat uttalande som: ”Salesforce-organisationen är nåbar, AWS är felfritt, men integrationsarbetaren kan inte lösa den privata slutpunkten” eller ”Salesforce Trust rapporterar ett instansproblem, så våra AWS-sideförsök väntar.” Den precisionsnivån talar om för nästa team vad som ska ändras – och vad som inte ska ändras.
Salesforce och AWS är nära sammankopplade i delar av den moderna molnarkitekturen, särskilt där Hyperforce körs på AWS eller där en kund avsiktligt integrerar Salesforce med AWS-tjänster. Relationen är inte ett enda allt-eller-inget-beroende. Det är en stapel av hanterad hosting, applikationstjänster, nätverksvägar, dataplatser och kundbyggda integrationer.
För aktuell planering, använd Salesforce Hyperforce FAQ från den 4 augusti 2026 som utgångspunkt och verifiera sedan de specifika produkterna och regionerna i din organisation. För incidentrespons, testa varje lager oberoende och bevara bevis innan du ändrar konfigurationen. Målet är inte att eliminera varje beroende; det är att veta vilket beroende som finns, vem som äger det, hur ett fel uppstår och hur verksamheten återhämtar sig utan att skapa ett andra problem.
Granska anmärkningsvärda Salesforce-avbrott under 2025, vad som misslyckades, hur länge utvalda incidenter varade och de praktiska lärdomar om motståndskraft som team kan tillämpa.
Skapa en praktisk Salesforce-plan för kontinuitet i driftstopp med konsekvensanalys, RTO/RPO-mål, manuella lösningar, integrationskontroller och återställningskontroller.
Lär dig hur du kontaktar Salesforce Support under ett större avbrott: kontrollera förtroendestatus, välj rätt kanal, öppna ett starkt ärende och spåra återställningen.
Felsök Salesforce Workbench-inloggning, REST Explorer, timeout, 503, API-version och begränsa fel under driftstopp med en praktisk diagnostisk checklista.
StoreForce issues can disrupt scheduling, timekeeping, and employee workflows. Learn how to assess impact, keep stores operating, verify recovery, and know when to escalate.
Förstå de främsta orsakerna till utbredda driftstopp i molnet, hur fel uppstår i flera steg, vad man ska kontrollera först och hur man utformar en mer motståndskraftig återställningsplan.
Om Datorama eller Marketing Cloud Intelligence verkar vara nere, använd den här evidensbaserade checklistan för att verifiera avbrottet, skydda rapporteringskvaliteten och veta när data är tillförlitliga igen.
A practical look at how Heroku outages can affect deployed apps, dynos, routing, databases, deploys, Heroku Connect, logs, and recovery.
Förstå hur Salesforce och AWS kopplas samman via Hyperforce, integrationer, nätverk, datalagring, avbrott och delat driftsansvar.
Ett AWS-avbrott betyder inte automatiskt att Salesforce ligger nere. Lär dig hur Hyperforce, regioner, instanser och Salesforce Trust avgör om din organisation påverkas.
