Když se stránka Salesforce zpomalí nebo integrace přestane poskytovat záznamy, týmy si často kladou jednoduchou otázku: „Je AWS mimo provoz, nebo Salesforce mimo provoz?“ Tato otázka je pochopitelná, ale může vést k nesprávnému vyšetřování. Salesforce je poskytovatel softwaru, AWS je poskytovatel cloudové infrastruktury a vztah mezi nimi se mění v závislosti na produktu Salesforce, organizaci, regionu, síťové cestě a návrhu integrace.
Ověřená aktualizace poskytuje tomuto vztahu užitečný kontext. Salesforce Help zveřejnila aktualizované FAQ k Hyperforce 4. srpna 2026. Uvádí se v nich, že Hyperforce je dostupný na Amazon Web Services (AWS) a dostupnost na Google Cloud Platform je plánována od konce roku 2026 a že Salesforce spravuje umístění infrastruktury pomocí technických a provozních faktorů. Ve stejných FAQ se uvádí, že některé produkty nebo funkce mohou být zpočátku dostupné na Hyperforce na AWS, zatímco na GCP ještě nejsou. To neznamená, že každá služba Salesforce je hostována na AWS, že si každý zákazník vybírá základního poskytovatele nebo že incident AWS se automaticky stává incidentem Salesforce. Tato příručka vysvětluje závislosti v těchto vrstvách s využitím informací ověřených 16. září 2026.
„Závislost“ může popisovat několik různých vztahů. Nejdůležitější rozdíl je mezi závislostí spravované služby a integrací vytvořenou zákazníkem:
| Vrstva | Co je propojeno | Kdo to obvykle ovládá | Jak může vypadat selhání |
|---|---|---|---|
| Aplikace Salesforce | Produkty CRM, API, identita, metadata a obchodní logika | Salesforce | Selhání přihlášení, chyby API, pomalé stránky nebo nedostupné funkce |
| Infrastruktura hypersíly | Aplikační stacky Salesforce nasazené na infrastruktuře veřejného cloudu | Salesforce spravuje umístění; poskytovatel cloudu provozuje své podkladové služby | Vlivy regionální kapacity, sítí, úložiště nebo infrastruktury |
| Integrace zákazníků | Salesforce připojený ke službám AWS, jako jsou aplikace, datová úložiště nebo kanály událostí | Vaše integrační a provozní týmy s kontrolními mechanismy specifickými pro daného poskytovatele | Časové limity, chyby ověřování, chybějící události nebo neúspěšné zápisy |
| Síťová cesta | Internet, soukromé připojení, DNS, firewally, směrování nebo přímé připojení | Zákazník, telekomunikace, AWS a Salesforce v závislosti na zvolené trase | Nelze se připojit pouze jedna kancelář, VPC, region nebo aplikace. |
| Data a dodržování předpisů | Kde jsou data uložena, zpracovávána, zálohována a přenášena | Sdíleno napříč konfigurací produktu, smlouvami a architekturou | Otázky týkající se bydliště, zablokované převody nebo zjištění z auditu |
Tato tabulka představuje model pro řešení problémů, nikoli prohlášení, že každý produkt Salesforce používá všechny komponenty AWS. Před rozhodnutím o architektuře nebo shodě s předpisy si zkontrolujte dokumentaci k produktu a konfiguraci objednávky.
Ne. Hyperforce je architektura infrastruktury Salesforce. Salesforce ji popisuje jako architekturu veřejného cloudu spravovanou jako kód, navrženou pro podporu globálního doručování, uchovávání dat, zabezpečení, škálovatelnosti a agility. AWS je jedním z poskytovatelů veřejného cloudu, u kterého je Hyperforce k dispozici. Název platformy, produkt Salesforce a podkladový poskytovatel cloudu jsou tedy různé části stacku.
Aktualizované Často kladené otázky k Salesforce uvádějí, že Salesforce spravuje umístění infrastruktury na základě technických a provozních faktorů. Pro zákazníka to znamená, že organizace běžící na Hyperforce by neměla být považována za účet AWS, kde si zákazník vybere zónu dostupnosti, změní instanci EC2 nebo otevře bezpečnostní skupinu. Salesforce provozuje spravované prostředí SaaS. Váš tým může mít stále závislosti na AWS – například datový kanál, soukromé připojení, příjemce událostí nebo aplikaci hostovanou ve vašem účtu AWS – ale ty jsou oddělené od vlastního umístění infrastruktury Salesforce.
Společnost Salesforce rovněž poznamenává, že služby, které nejsou hostovány na platformě Hyperforce, nadále fungují jako dříve a že dostupnost produktů se může lišit v závislosti na poskytovateli veřejného cloudu. Aktuální informace o produktech a poskytovatelích naleznete v dokumentu Často kladené otázky a průvodce migrací k platformě Salesforce Hyperforce . Tuto stránku považujte spíše za provozní pokyny s verzí, než za trvalý slib: Společnost Salesforce uvádí, že dokument je informativní a může se změnit.
Toto se nejvíce blíží přímé závislosti na infrastruktuře. Pokud je konkrétní organizace a produkt Salesforce umístěn na Hyperforce na AWS, incident v relevantní oblasti nebo službě AWS by se mohl stát jedním z faktorů ovlivňujících dostupnost Salesforce. Skutečné selhání ze strany zákazníka však může být způsobeno kódem aplikace Salesforce, řídicí rovinou Salesforce, závislostí v jiné oblasti, problémem se směrováním nebo službou specifickou pro produkt. Považání AWS za základního poskytovatele nestačí k identifikaci hlavní příčiny.
Toto je často závislost, které si zákazníci všimnou jako první. Organizace Salesforce může odesílat data do služby hostované na AWS, přijímat události z fronty, volat API ve VPC, číst z datové platformy nebo používat službu AWS jako součást pracovního postupu aplikace. V tomto návrhu může být Salesforce v pořádku, i když váš koncový bod AWS, přihlašovací údaje, síťová trasa nebo příjemce událostí selhávají. Je také možný opačný postup: AWS může být v pořádku, i když rozhraní Salesforce API nebo ověřovací vrstva nejsou k dispozici.
Salesforce Private Connect je model integrace napříč cloudy pro propojení organizace Salesforce se službami AWS zákazníka. AWS Direct Connect je možnost síťového připojení, která může poskytnout cestu z místního prostředí do AWS a prostřednictvím veřejného virtuálního rozhraní do Hyperforce. Nejedná se o zaměnitelné ovládací prvky.
Společné pokyny společností Salesforce a AWS uvádějí, že Salesforce Express Connect není kompatibilní s Hyperforce a popisuje AWS Direct Connect s veřejným virtuálním rozhraním jako možnost pro některé zákazníky, kteří potřebují přímé připojení k Hyperforce. Také rozlišuje Private Connect, který propojuje organizaci Salesforce se službami AWS zákazníka. Před změnou architektury sítě si přečtěte pokyny AWS pro přístup k Hyperforce pomocí Direct Connect . Pro vaši organizaci je stále třeba zkontrolovat dostupnost, směrování a smluvní požadavky.
Ne. Incident Salesforce a incident AWS se mohou překrývat, ale nejsou synonyma. Salesforce zveřejňuje stav služby prostřednictvím svého webu Trust, zatímco AWS zveřejňuje stav služby a události specifické pro účet prostřednictvím AWS Health. Začněte se službou, která selhává, a přesnou oblastí nebo instancí, které se to týká, spíše než předpokládejte, že za to nese odpovědnost největší poskytovatel v databázi.
Použijte toto srovnání během incidentu:
| Pozorovaný příznak | První místo, kam se podívat | Interpretace k testování |
|---|---|---|
| Všichni uživatelé Salesforce se nemohou přihlásit ani používat více produktů. | Salesforce Trust, instance organizace a kanál podpory Salesforce | Narušení služeb v rámci celé Salesforce nebo na úrovni instance |
| Selže pouze jedna integrace podporovaná AWS | Protokoly aplikací, AWS Health, přihlašovací údaje, DNS a metriky koncových bodů | Problém s integrací zákazníka nebo službou AWS |
| Pouze jedna kancelář nebo VPC se nemůže spojit se Salesforce | Konfigurace tras, pravidel firewallu, DNS, přímého připojení a důvěryhodné IP adresy | Problém se síťovou cestou nebo lokální konfigurací |
| Uživatelské rozhraní Salesforce funguje, ale plánovaná synchronizace se zasekává. | Omezení API, token OAuth, hloubka fronty, opakované pokusy a integrační protokoly | Závislost na pracovním postupu nebo API spíše než dostupnost jádra |
| Jeden produkt nebo funkce není k dispozici | Dokumentace k stavu a vydání produktu Salesforce | Problém na úrovni komponenty, údržba nebo závislost funkce |
Toto rozlišení ovlivňuje eskalaci. Pokud systém Salesforce Trust nahlásí incident ovlivňující vaši instanci, shromážděte číslo incidentu a vyhněte se provádění destruktivních změn konfigurace. Pokud je systém Trust jasný, ale váš koncový bod AWS vykazuje chyby, uchovejte ID požadavků a prozkoumejte stranu AWS. Pokud se obě služby zdají být v pořádku, porovnejte přímý test Salesforce API, test koncového bodu AWS a úplnou integrační cestu; problém mezi funkčními službami je stále možný.
Hyperforce může změnit, kde jsou hostovány aplikace a data Salesforce, ale „regionální“ neznamená, že „každý bajt zůstává v každé situaci v jedné zemi“. Salesforce uvádí, že zákaznická data jsou obvykle uložena v zemi, kde se organizace nachází, pokud jsou tam dostupné používané služby. Také varuje, že některé produkty mohou mít komponenty v různých zemích nebo zahrnovat integrace se službami, které dosud na Hyperforce nejsou.
Toto upozornění je důležité, pokud je součástí návrhu AWS. Musíte namapovat alespoň čtyři umístění: organizaci Salesforce a její provozní region Hyperforce, region AWS, který obsahuje připojenou službu nebo data, umístění integračních pracovníků a protokolů a umístění záloh nebo kopií pro zotavení po havárii. Region AWS vybraný vaším týmem nepřepíše architekturu produktu Salesforce a možnost rezidentnosti dat Salesforce automaticky neumístí vaše externí data AWS do stejného regionu.
K ověření produktů, regionů a závazků, které se vztahují na vaše prostředí, použijte přehled infrastruktury veřejného cloudu Salesforce Hyperforce a dokumentaci o důvěryhodnosti a shodě s předpisy vaší organizace. V případě regulovaných dat nechte týmy pro ochranu osobních údajů, zabezpečení a právní oddělení zkontrolovat skutečné podmínky služby, a nespoléhejte se na obecný diagram architektury.
Odolnost začíná tím, že se pro každou obchodní akci vyhnete jedinému synchronnímu řetězci. Pokud transakce Salesforce musí čekat na službu AWS, definujte, co se stane, když je služba AWS pomalá nebo nedostupná. V závislosti na obchodním procesu může být fronta, opakování s exponenciálním odkladem, klíč idempotence, jistič, cesta k nedoručeným zprávám nebo ruční odsouhlasení bezpečnější než opakovaná synchronní volání.
Používejte omezené počet opakovaných pokusů. Opakovaný pokus, který pokračuje i během degradace Salesforce nebo AWS, může znásobit provoz a z krátkého incidentu udělat větší nevyřízené záležitosti. Zaznamenejte si původní požadavek, počet opakovaných pokusů, kód odpovědi a konečné vyřízení. Před povolením automatického přehrávání událostí zajistěte bezpečnost duplicitního doručení.
Oddělte cíle obnovy pro stranu Salesforce od cílů pro stranu AWS. Záloha databáze AWS neobnoví konfiguraci organizace Salesforce a možnost obnovy Salesforce neobnoví externí aplikaci AWS. Salesforce popisuje funkci obnovy po havárii mimo oblast pro bezpečné zálohování instance v sekundární oblasti Hyperforce, ale dostupnost a smluvní rozsah musí být ověřeny pro produkty a edici, které používáte. Neprezentujte tuto možnost jako univerzální plán pro převzetí služeb při selhání.
Nezakódujte pevně předpoklady o rozsahech IP adres veřejného cloudu, umístění poskytovatelů nebo chování produktů do dlouhodobého runbooku. Po migraci Hyperforce, spuštění nové oblasti, změně konektivity nebo vydání hlavní integrace si projděte aktuální dokumentaci Salesforce a AWS.
Užitečným výsledkem není jen „Salesforce používá AWS“. Užitečným výsledkem je ohraničený výrok, například: „Organizace Salesforce je dostupná, AWS je v pořádku, ale integrační pracovník nemůže vyřešit soukromý koncový bod“ nebo „Salesforce Trust hlásí problém s instancí, takže naše opakované pokusy na straně AWS jsou pozastaveny.“ Tato úroveň přesnosti říká dalšímu týmu, co má změnit – a co ne.
Salesforce a AWS jsou v některých částech moderní cloudové architektury úzce propojeny, zejména tam, kde Hyperforce běží na AWS nebo kde zákazník záměrně integruje Salesforce se službami AWS. Tento vztah není založen na jediné závislosti typu „všechno, nebo nic“. Jde o souhrn spravovaného hostingu, aplikačních služeb, síťových cest, datových umístění a integrací vytvořených zákazníkem.
Pro aktuální plánování použijte jako výchozí bod Často kladené otázky k Salesforce Hyperforce ze 4. srpna 2026 a poté ověřte konkrétní produkty a regiony ve vaší organizaci. Pro reakci na incidenty otestujte každou vrstvu nezávisle a před změnou konfigurace uchovejte důkazy. Cílem není eliminovat každou závislost; jde o to vědět, která závislost existuje, kdo ji vlastní, jak se projevuje selhání a jak se podnik zotaví, aniž by vznikl druhý problém.
Zrychlete Windows 11 bezpečně: startup, úložiště, aktualizace, režim napájení, Správce úloh a ochrana Windows Security s jasnými kompromisy.
Zjistěte, čím se Anthropic liší, jak funguje Claude a co skutečně znamenají modely Opus, Sonnet a Haiku. Přehled ověřených faktů, limitů i praktických kroků.
Zjistěte, kolik stojí Starlink v Česku, jak funguje a kdy se vyplatí. Přehled tarifů, omezení, instalace a srovnání s optikou i 5G.
World Space Week 2026 probíhá 4.–10. října s tématem Rocket Revolution. Vysvětlujeme jeho původ, časté omyly a technologie, které mění kosmonautiku.
Zjistěte, co bude v Praze otevřeno či zavřeno v říjnu 2026, zejména 28. října. Přehled knihoven, muzeí, pošt, úřadů a online služeb.
Přehled říjnových výluk v Praze: metro Flora, vlaky u Smíchova, tramvaje, autobus 101, opravy Katovické, Cínovecké a Kbelské. Ověřeno k 29. 9. 2026.
Praktický přehled svozu odpadu v Praze v říjnu 2026: jak ověřit termín podle adresy, co se mění 28. října, kam s bioodpadem, objemným odpadem a nevyvezenou popelnicí.
Přehled školních prázdnin a uzavření škol v Praze v říjnu 2026: poslední školní den, státní svátek 28. října, podzimní prázdniny 29.–30. října, návrat 2. listopadu a ředitelské volno.
Přesný přehled výplat důchodů ČSSZ v říjnu 2026, víkendové posuny, dopad svátku 28. října, pravidla pro nemocenské dávky a postup při zpoždění.
Zkontrolujte otevírací dobu veřejných služeb v Londýně v říjnu 2026: ověřené výjimky knihoven a muzeí, rozdíly v pobočkách pošty, přístup ke službám rady a které online úkoly jsou stále k dispozici.
