Deschideți Salesforce și o funcție este lentă, indisponibilă sau returnează o eroare. În același timp, observați rapoarte despre o problemă AWS. Este tentant să concluzionăm că „Salesforce rulează pe AWS, deci AWS trebuie să fie cauza”. Uneori, acest lucru poate fi direcțional corect, dar dependența reală este mai nuanțată. Salesforce utilizează AWS pe scară largă, în special prin Hyperforce , în timp ce unele medii și servicii Salesforce utilizează altă infrastructură. Prin urmare, un incident AWS poate afecta unele sarcini de lucru Salesforce fără a întrerupe neapărat toți clienții Salesforce sau toți produsele Salesforce.
Întrebarea practică nu este pur și simplu dacă Salesforce utilizează AWS. Chiar o face. Întrebarea utilă este ce parte a serviciului dvs. Salesforce este găzduită unde, de ce regiune AWS sau serviciu depinde și dacă problema este în Salesforce, AWS, propria integrare sau calea de rețea dintre ele . Acest ghid explică această dependență, de la cele mai simple verificări până la detalii arhitecturale mai profunde, apoi arată cum să verificați propria situație.
Hyperforce este arhitectura de infrastructură de cloud public a Salesforce pentru livrarea aplicațiilor Salesforce în medii de cloud regionale. Salesforce descrie Hyperforce ca infrastructura din spatele Customer 360 și utilizează furnizori de cloud public pentru a extinde disponibilitatea regională, rezidența datelor, controalele de securitate și scalabilitatea.
Începând cu septembrie 2026, Salesforce declară că Hyperforce este disponibil pe Amazon Web Services în mai multe țări și se extinde și pe Google Cloud Platform. Această distincție contează: „Salesforce folosește AWS” este adevărat, dar „fiecare organizație Salesforce rulează doar pe AWS” nu este. De asemenea, Salesforce operează în continuare o parte din infrastructura first-party gestionată de Salesforce, iar serviciile individuale pot rula pe o infrastructură separată de organizația principală.
Îndrumările actuale ale Salesforce privind amplasarea infrastructurii sunt disponibile în secțiunea Ajutor Salesforce: Unde se află instanța mea Salesforce?. Salesforce explică, de asemenea, modelul său Hyperforce mai amplu în secțiunea Informații generale și Întrebări frecvente despre Hyperforce de la Salesforce .
Dependența este substanțială, dar stratificată. AWS a fost un furnizor strategic major de cloud pentru Salesforce timp de ani de zile, iar AWS descrie companiile ca având un parteneriat strategic global. Salesforce utilizează infrastructura AWS pentru implementările Hyperforce și a integrat, de asemenea, produse Salesforce cu servicii AWS precum Amazon Connect și Amazon Bedrock.
Pentru un client, este util să separe relația în trei straturi:
| Strat | Ce depinde de AWS | Ce înseamnă din punct de vedere operațional |
|---|---|---|
| Stratul de găzduire Salesforce | O organizație sau un serviciu Salesforce poate rula pe Hyperforce găzduit într-o regiune AWS. | O problemă de infrastructură regională sau subiacentă AWS poate deveni relevantă pentru disponibilitatea Salesforce pentru sarcina de lucru găzduită respectivă. |
| Stratul de produs-serviciu Salesforce | Unele suplimente sau servicii de asistență Salesforce pot rula pe AWS separat de organizația Salesforce principală. | O funcționalitate poate eșua chiar și atunci când CRM-ul de bază rămâne funcțional. |
| Stratul de integrare a clientului | Compania dumneavoastră poate conecta Salesforce la propriile sarcini de lucru AWS, API-uri, Amazon Connect, conducte de date sau rețele private. | Problema poate fi în contul AWS sau în calea de rețea chiar și atunci când Salesforce funcționează normal. |
Acest model stratificat este cheia depanării. O pagină de stare care spune „Salesforce este operațional” nu dovedește că integrarea găzduită de AWS este sănătoasă. În schimb, un eveniment AWS general nu dovedește că instanța dvs. particulară de Salesforce este afectată.
Salesforce afirmă că instanțele Hyperforce utilizează un model activ/activ în trei zone de disponibilitate din regiunea relevantă. O zonă de disponibilitate, sau AZ, este o locație izolată în interiorul unei regiuni AWS. Într-un design activ/activ, capacitatea aplicației operează în mai multe zone, în loc să mențină o zonă inactivă ca standby rece. Salesforce afirmă că traficul este distribuit pe serverele de aplicații active din toate cele trei zone, iar replicarea bazei de date menține consecvența între zone.
Această arhitectură este menită să reducă dependența de orice zonă de disponibilitate unică. Dacă o zonă de disponibilitate are o problemă localizată, designul poate ajuta serviciul să continue în celelalte zone. Însă o arhitectură cu mai multe zone de disponibilitate nu elimină toate modurile de defecțiune posibile. O problemă de serviciu la nivel de regiune, o problemă a planului de control, o întrerupere a rețelei, o eroare de software, o eroare de dependență sau un incident la nivel de aplicație pot afecta în continuare disponibilitatea.
Deci, modelul mental corect este: Salesforce pe AWS este conceput să fie rezistent într-o regiune AWS, dar are în continuare dependențe de infrastructură care pot fi importante în timpul evenimentelor AWS mai mari .
Aici eșuează multe investigații ale incidentelor. Salesforce menționează în mod explicit că anumite servicii pot rula pe o infrastructură separată, integrându-se în același timp cu organizația clientului. De exemplu, documentația Salesforce pentru Sales Engagement, Einstein Activity Capture, Salesforce Inbox și Einstein Conversation Insights precizează că aceste servicii sunt găzduite pe infrastructura AWS separat de infrastructura Salesforce Core a organizației.
Asta înseamnă că un utilizator ar putea vedea o situație precum:
Salesforce documentează această separare în ghidul său de migrare Hyperforce pentru Sales Engagement, Einstein Activity Capture, Salesforce Inbox și Einstein Conversation Insights .
Începeți cu starea oficială a Salesforce și informațiile despre încredere. Găsiți starea instanței dvs. Salesforce specifice, în loc să vă bazați pe rapoarte generice care arată că „Salesforce nu funcționează”. Salesforce explică cum să identificați instanța unei organizații în secțiunea Vizualizați informațiile despre instanță pentru organizația dvs. Salesforce .
În configurarea Salesforce, utilizați caseta Căutare rapidă pentru a localiza Informații despre companie , apoi căutați câmpul Instanță . Salesforce notează că prefixele de instanță din două litere, cum ar fi AP0, indică o infrastructură proprie gestionată de Salesforce, în timp ce prefixele din trei litere, cum ar fi GBR10, indică o infrastructură Hyperforce.
O instanță Hyperforce nu este automat sinonimă cu AWS pentru totdeauna. Salesforce spune că Hyperforce este disponibil pe AWS și se extinde la Google Cloud Platform. Documentația sa sfătuiește clienții care trebuie să stabilească dacă o anumită instanță Hyperforce se află pe AWS sau GCP să contacteze Asistența Clienți Salesforce.
Acest lucru este din ce în ce mai important pentru corelarea incidentelor. Nu ar trebui să asociați „Hyperforce” cu „AWS” doar din cuvântul în sine.
Dacă ați confirmat că organizația sau serviciul Salesforce afectat rulează pe AWS, identificați regiunea. Documentația actuală a locației Salesforce listează regiunile Hyperforce și furnizorul lor de cloud public. De exemplu, Salesforce listează regiunile Hyperforce susținute de AWS în locații precum Sydney, Mumbai, Tokyo, Singapore, Londra, Frankfurt, Canada Centrală și mai multe regiuni din SUA.
Apoi, comparați incidentul Salesforce cu informațiile oficiale AWS Health relevante pentru regiunea și serviciul respectiv. Evitați să tratați o problemă dintr-o regiune AWS ca dovadă pentru o regiune Salesforce fără legătură.
Dacă Salesforce în sine este funcțional, verificați calea de integrare. Dependențele tipice din partea clientului includ gateway-uri API, funcții Lambda, Amazon Connect, baze de date, cozi, endpoint-uri private, VPN-uri, DNS și controale de rețea corporativă. O eroare a uneia dintre aceste componente poate apărea pentru utilizatori ca o „problemă Salesforce”, deoarece eroarea apare în interiorul unui flux de lucru Salesforce.
Un test util este să ne întrebăm: Poate aceeași operațiune Salesforce să aibă succes fără a apela serviciul nostru AWS? Dacă da, organizația principală ar putea fi sănătoasă în timp ce calea de integrare eșuează.
Unele organizații utilizează AWS Direct Connect , o conexiune de rețea privată în AWS, pentru a susține cerințele de rețea pentru Hyperforce pe AWS. Salesforce documentează un caz de utilizare pentru rutarea anumitor trafic de e-mail Hyperforce prin AWS Direct Connect pentru organizațiile cu cerințe de conectivitate privată, conformitate sau rezidență a datelor.
Aceasta creează un alt strat de dependență. Când este implicată conectivitate privată, un incident poate sta între utilizator și Salesforce, mai degrabă decât în interiorul Salesforce-ului. Documentația relevantă a Salesforce este „ Direcționarea e-mailurilor prin AWS Direct Connect pentru Hyperforce” .
Salesforce descrie Hyperforce ca fiind conceput să funcționeze pe mai mulți furnizori de cloud public. Acest lucru reduce presupunerea arhitecturală că un hyperscaler trebuie să fie substratul permanent pentru toate sarcinile de lucru Salesforce. Documentația Salesforce din 2026 precizează că Hyperforce este disponibil pe AWS și că suportul pentru Google Cloud Platform este introdus în anumite regiuni, sub rezerva dezvăluirilor din foaia de parcurs a Salesforce.
Pentru clienți, acest lucru nu înseamnă că o organizație Salesforce existentă trece automat de la AWS la Google Cloud în timpul unei întreruperi a serviciului AWS. Asistența multi-cloud se referă în principal la locul în care Salesforce își poate implementa și opera platforma. Nu ar trebui să presupuneți o reluare între furnizori, cu excepția cazului în care Salesforce o documentează explicit pentru serviciul pe care îl utilizați.
Relația nu se referă doar la găzduirea infrastructurii. AWS și Salesforce descriu un parteneriat strategic mai amplu în jurul datelor, inteligenței artificiale, capacităților centrelor de contact, integrării și achizițiilor. Pagina oficială de parteneriat AWS evidențiază integrările care implică produse Salesforce și tehnologii AWS, inclusiv inteligență artificială generativă și capacități de gestionare a datelor. Puteți consulta această relație pe pagina oficială de parteneriat AWS și Salesforce .
Acest lucru este important în timpul revizuirilor de arhitectură, deoarece există două întrebări diferite privind dependența:
Aceste două dependențe au proprietari, căi de monitorizare, proceduri de recuperare și echipe de asistență diferite.
Când utilizatorii raportează că Salesforce nu este disponibil sau este parțial defect, parcurgeți aceste verificări în ordine:
Știi că diagnosticul tău devine mai puternic atunci când dovezile se aliniază pe mai multe niveluri. Dacă Salesforce Trust raportează un incident pentru instanța ta exactă și caracteristica afectată corespunde simptomelor, partea Salesforce este puternic implicată. Dacă Salesforce este sănătos, dar testele tale de integrare AWS eșuează în aceeași fereastră de timp, dependența AWS din partea clientului este o pistă mai bună. Dacă este afectat un singur add-on Salesforce, în timp ce funcțiile CRM de bază rămân normale, investighează infrastructura și starea separată a serviciului respectiv.
Nu vă opriți la „AWS a avut o întrerupere” sau „Salesforce a analizat situația”. Răspunsul sigur vine din potrivirea instanței, a produsului, a regiunii și a căii de integrare .
Salesforce are o dependență profundă de AWS, în special pentru că multe implementări Hyperforce și servicii de asistență rulează pe infrastructura AWS. Însă dependența nu este universală sau unidimensională. Salesforce operează, de asemenea, infrastructură first-party, extinde Hyperforce pe mai mulți furnizori de cloud public și poate găzdui servicii individuale separat de organizația principală a clientului.
Pentru echipele de operațiuni, cea mai bună abordare este de a trata Salesforce și AWS ca un grafic de dependențe, mai degrabă decât ca o singură stivă. Identificați unde rulează organizația principală, mapați serviciile Salesforce găzduite separat, documentați fiecare integrare AWS gestionată de client și monitorizați fiecare strat independent. Aceasta vă oferă o cale mult mai rapidă de la „Salesforce este defect” la componenta specifică care necesită cu adevărat atenție.
Investițiile în CCUS sunt în creștere, dar poate captarea carbonului să inverseze emisiile globale? Vedeți unde funcționează, ce limitează scara și ce dovezi contează.
Compare seven global programs for digital supply chains, logistics, analytics, global trade, and operations, with practical guidance on choosing the right fit.
Aflați cum interfețele creier-computer decodifică semnalele neuronale pentru a restabili comunicarea și mișcarea, ce au realizat studiile recente și ce limitează încă utilizarea BCI.
Vedeți cum dronele comerciale combină senzorii, inteligența artificială de la margine, bateriile, comunicațiile și software-ul de control al zborului - și unde autonomia depinde încă de misiune și reglementări.
Compare seven strong battery and energy storage master's options by materials, systems, research, industry exposure, flexibility, language, and cost trade-offs.
Learn how payload mass, battery limits, weather, propulsion efficiency, and aircraft architecture shape industrial UAV endurance—and how to improve it.
Compare leading biomedical engineering programs for smart medical devices, including design, bioelectronics, AI, cybersecurity, clinical training, and regulation.
Creați un plan practic de continuitate pentru perioadele de nefuncționare ale Salesforce, cu priorități clare, fluxuri de lucru de rezervă, verificări de recuperare, criterii de testare și limite realiste.
Problemele StoreForce pot perturba programul, pontajul, schimbările de ture și comunicarea în magazin. Aflați cum să diagnosticați problema, să mențineți operațiunile de vânzare cu amănuntul în mișcare și să verificați recuperarea.
Aflați cum să contactați asistența Salesforce în timpul unei întreruperi majore, să alegeți canalul potrivit, să pregătiți un caz util și să faceți urmărire fără a crea tichete duplicate.
