Salesforcen ja AWS:n välisen riippuvuuden ymmärtäminen

Kun Salesforce-sivu hidastuu tai integraatio lakkaa toimittamasta tietueita, tiimit kysyvät usein yksinkertaisen kysymyksen: "Onko AWS alhaalla vai onko Salesforce alhaalla?" Tämä kysymys on ymmärrettävä, mutta se voi johtaa väärään tutkimukseen. Salesforce on ohjelmistotoimittaja, AWS on pilvi-infrastruktuurin tarjoaja, ja niiden välinen suhde muuttuu Salesforce-tuotteen, organisaation, alueen, verkkopolun ja integraatiosuunnittelun mukaan.

Vahvistettu päivitys antaa suhteelle hyödyllisen kontekstin. Salesforce Help julkaisi päivitetyn Hyperforce-UKK:n 4. elokuuta 2026. Siinä sanotaan, että Hyperforce on saatavilla Amazon Web Servicesissä (AWS), ja Google Cloud Platformin saatavuuden on tarkoitus alkaa vuoden 2026 lopulla, ja että Salesforce hallitsee infrastruktuurin sijoittelua teknisten ja toiminnallisten tekijöiden avulla. Samassa UKK:ssa sanotaan, että jotkin tuotteet tai ominaisuudet saattavat aluksi olla saatavilla Hyperforcessa AWS:ssä, mutta ne eivät ole vielä saatavilla GCP:ssä. Tämä ei tarkoita, että jokainen Salesforce-palvelu olisi isännöity AWS:ssä, että jokainen asiakas valitsisi taustalla olevan palveluntarjoajan tai että AWS-tapauksesta tulisi automaattisesti Salesforce-tapaus. Tämä opas selittää näiden kerrosten riippuvuudet käyttäen 16. syyskuuta 2026 tarkistettuja tietoja.

Mitä Salesforce–AWS-riippuvuus oikeastaan ​​tarkoittaa?

”Riippuvuus” voi kuvata useita eri suhteita. Tärkein ero on hallitun palvelun riippuvuuden ja asiakkaan luoman integraation välillä:

Taulukko on vianmääritysmalli, ei väitä, että jokainen Salesforce-tuote käyttää jokaista AWS-komponenttia. Tarkista tuotekohtainen dokumentaatio ja tilauksesi kokoonpano ennen arkkitehtuuriin tai vaatimustenmukaisuuteen liittyvän päätöksen tekemistä.

Onko Hyperforce sama asia kuin AWS?

Ei. Hyperforce on Salesforcen infrastruktuuriarkkitehtuuri. Salesforce kuvailee sitä koodina hallittavana julkisen pilven arkkitehtuurina, joka on suunniteltu tukemaan globaalia toimitusta, datan säilytystä, tietoturvaa, skaalautuvuutta ja ketteryyttä. AWS on yksi julkisen pilven tarjoaja, jolla Hyperforce on saatavilla. Alustan nimi, Salesforce-tuote ja taustalla oleva pilvipalveluntarjoaja ovat siis pinon eri osia.

Päivitetyssä Salesforcen usein kysytyissä kysymyksissä sanotaan, että Salesforce hallitsee infrastruktuurin sijoittelua teknisten ja toiminnallisten tekijöiden perusteella. Asiakkaan kannalta tämä tarkoittaa, että Hyperforcea käyttävää organisaatiota ei tule kohdella AWS-tilinä, jossa asiakas valitsee saatavuusvyöhykkeen, muuttaa EC2-instanssia tai avaa käyttöoikeusryhmän. Salesforce ylläpitää hallittua SaaS-ympäristöä. Tiimilläsi voi edelleen olla AWS-riippuvuuksia ympärillään – esimerkiksi dataputki, yksityinen yhteys, tapahtumakäyttäjä tai AWS-tililläsi isännöity sovellus – mutta ne ovat erillään Salesforcen omasta infrastruktuurin sijoittelusta.

Salesforce huomauttaa myös, että Hyperforcen ulkopuolella isännöidyt palvelut toimivat edelleen kuten ennenkin ja että tuotteiden saatavuus voi vaihdella julkisen pilven tarjoajan mukaan. Ajankohtaiset tuote- ja palveluntarjoajatiedot löytyvät Salesforcen Hyperforcen usein kysytyistä kysymyksistä ja siirto-oppaasta . Käsittele kyseistä sivua versioituina toimintaohjeina, äläkä pysyvänä lupauksena: Salesforcen mukaan asiakirja on tiedottava ja voi muuttua.

Mitkä osat suhteesta ovat suoria?

Salesforce saattaa suorittaa tiettyjä Hyperforce-työkuormia AWS:ssä

Tämä on lähimpänä suoraa infrastruktuuririippuvuutta. Jos tietty Salesforce-organisaatio ja -tuote sijoitetaan Hyperforceen AWS:ssä, asiaankuuluvan AWS-alueen tai -palvelun häiriö voi olla yksi tekijä Salesforcen saatavuudessa. Mutta varsinainen asiakkaaseen kohdistuva vika voi johtua Salesforcen sovelluskoodista, Salesforcen ohjaustasosta, riippuvuudesta toisella alueella, reititysongelmasta tai tuotekohtaisesta palvelusta. AWS:n näkeminen taustalla olevana palveluntarjoajana ei riitä perimmäisen syyn tunnistamiseen.

Yrityksesi voi yhdistää Salesforcen AWS:ään

Tämä on usein riippuvuus, jonka asiakkaat huomaavat ensimmäisenä. Salesforce-organisaatio voi lähettää dataa AWS-isännöityyn palveluun, vastaanottaa tapahtumia jonosta, kutsua API:a VPC:ssä, lukea data-alustalta tai käyttää AWS-palvelua osana sovelluksen työnkulkua. Tässä rakenteessa Salesforce voi olla toimintakunnossa, vaikka AWS-päätepiste, tunnistetiedot, verkkoreitti tai tapahtuman kuluttaja vikaantuu. Myös päinvastainen on mahdollista: AWS voi olla toimintakunnossa, vaikka Salesforce-API tai todennuskerros ei ole käytettävissä.

Yksityinen yhteys ja suora yhteys ratkaisevat erilaisia ​​ongelmia

Salesforce Private Connect on pilvipalveluiden välinen integrointimalli Salesforce-organisaation yhdistämiseksi asiakkaan AWS-palveluihin. AWS Direct Connect on verkkoyhteysvaihtoehto, joka voi tarjota polun paikallisesta ympäristöstä AWS:ään ja julkisen virtuaalisen rajapinnan kautta Hyperforceen. Ne eivät ole keskenään vaihdettavia ohjausobjekteja.

Salesforcen ja AWS:n yhteisohjeistus sanoo, ettei Salesforce Express Connect ole yhteensopiva Hyperforcen kanssa, ja kuvaa AWS Direct Connectin julkisella virtuaalirajapinnalla vaihtoehtona joillekin asiakkaille, jotka tarvitsevat suoran yhteyden Hyperforceen. Se erottaa myös Private Connectin, joka yhdistää Salesforce-organisaation asiakkaan AWS-palveluihin. Lue AWS:n ohjeet Hyperforcen käyttämiseen Direct Connectilla ennen verkkoarkkitehtuurin muuttamista. Saatavuus, reititys ja sopimusvaatimukset on silti tarkistettava organisaatiollesi.

Aiheuttaako AWS-käyttökatkos automaattisesti Salesforcen käyttökatkoksen?

Ei. Salesforce-tapaus ja AWS-tapaus voivat olla päällekkäisiä, mutta ne eivät ole synonyymejä. Salesforce julkaisee palvelun tilan Trust-sivustonsa kautta, kun taas AWS julkaisee palvelun kunnon ja tilikohtaiset tapahtumat AWS Healthin kautta. Aloita vikaantuvasta palvelusta ja tarkasta alueesta tai instanssista, joka siihen liittyy, sen sijaan, että olettaisit pinon suurimman palveluntarjoajan olevan vastuussa.

Käytä tätä vertailukohtaa tapahtuman aikana:

Tämä erottelu vaikuttaa eskalointiin. Jos Salesforce Trust raportoi instanssiisi vaikuttavasta tapahtumasta, kerää tapahtumanumero ja vältä haitallisten kokoonpanomuutosten tekemistä. Jos Trust on kunnossa, mutta AWS-päätepisteesi näyttää virheitä, säilytä pyyntötunnukset ja tutki AWS-puolta. Jos molemmat näyttävät olevan kunnossa, vertaa suoraa Salesforce API -testiä, AWS-päätepistetestiä ja koko integraatiopolkua; ongelma terveiden palveluiden välillä on edelleen mahdollinen.

Miten datan sijainti muuttaa riippuvuutta?

Hyperforce voi muuttaa Salesforce-sovellusten ja -datan sijaintia, mutta "alueellinen" ei tarkoita, että "jokainen tavu pysyy yhdessä maassa joka tilanteessa". Salesforcen mukaan asiakasdataa säilytetään yleensä organisaation sijaintimaassa, kun käytössä olevat palvelut ovat saatavilla siellä. Se varoittaa myös, että joillakin tuotteilla voi olla komponentteja eri maissa tai integraatioita palveluihin, joita ei vielä ole Hyperforcessa.

Tämä varoitus on tärkeä, kun AWS on osa suunnittelua. Sinun on kartoitettava vähintään neljä sijaintia: Salesforce-organisaatio ja sen Hyperforce-toiminta-alue, yhdistettyä palvelua tai dataa sisältävä AWS-alue, integraatiotyöntekijöiden ja lokien sijainti sekä varmuuskopioiden tai palautuskopioiden sijainti. Tiimisi valitsema AWS-alue ei korvaa Salesforcen tuotearkkitehtuuria, eikä Salesforcen datan sijaintivaihtoehto automaattisesti sijoita ulkoisia AWS-tietojasi samaan alueeseen.

Käytä Salesforce Hyperforce -julkisen pilven infrastruktuurin yleiskatsausta ja organisaatiosi luotettavuus- ja vaatimustenmukaisuusdokumentaatiota validoidaksesi ympäristöösi soveltuvat tuotteet, alueet ja sitoumukset. Säänneltyjen tietojen osalta pyydä tietosuoja-, tietoturva- ja lakitiimejä tarkistamaan todelliset palveluehdot yleisen arkkitehtuurikaavion sijaan.

Millaista joustavuutta Salesforce–AWS-arkkitehtuurin tulisi sisältää?

Resilienssi alkaa yhden synkronisen ketjun välttämisestä jokaiselle liiketoimintatoiminnolle. Jos Salesforce-tapahtuman on odotettava AWS-palvelua, määritä, mitä tapahtuu, kun AWS-palvelu on hidas tai ei ole käytettävissä. Liiketoimintaprosessista riippuen jono, uudelleenyritys eksponentiaalisella peruutuksella, idempotenssi-avain, katkaisija, kuollut kirje -polku tai manuaalinen täsmäytys voivat olla turvallisempia kuin toistuvat synkroniset kutsut.

Käytä rajoitettuja uudelleenyrityksiä. Uudelleenyritys, joka jatkuu Salesforcen tai AWS:n toimintahäiriön aikana, voi moninkertaistaa liikenteen ja muuttaa lyhyen tapahtuman suuremmaksi jonoksi. Kirjaa ylös alkuperäinen pyyntö, uudelleenyritysten määrä, vastauskoodi ja lopullinen käsittelytapa. Varmista, että kaksoiskappaleet ovat turvassa ennen kuin otat käyttöön tapahtumien automaattisen toiston.

Erota Salesforce-puolen palautustavoitteet AWS-puolen tavoitteista. AWS-tietokannan varmuuskopiointi ei palauta Salesforce-organisaation kokoonpanoa, eikä Salesforcen palautusvaihtoehto palauta ulkoista AWS-sovellusta. Salesforce kuvaa alueen ulkopuolisen katastrofipalautuksen ominaisuuden toissijaisen Hyperforce-alueen instanssin turvalliseen varmuuskopiointiin, mutta saatavuus ja sopimuksen laajuus on varmistettava käyttämillesi tuotteille ja versioille. Älä esitä tätä vaihtoehtoa yleisenä vikasietoisena suunnitelmana.

Mitä operatiivisen tiimin tulisi dokumentoida?

• Järjestelmäkartta: Salesforce-organisaatio, tuotteet, API-päätepisteet, AWS-palvelut, jonot, tietokannat, DNS-nimet ja verkkopolut.
• Omistajuuskartta: mikä tiimi omistaa Salesforce-kokoonpanon, AWS-resurssit, integraatiokoodin, identiteetin, sertifikaatit ja toimittajan eskaloinnin.
• Riippuvuuskartta: mitkä työnkulut voivat keskeyttää, mitkä voivat jonottaa ja mitkä vaativat välittömiä ihmisen toimia.
• Aluekartta: Salesforce-organisaation sijainti, Hyperforce-toimittajan tiedot, jos ne on dokumentoitu, AWS-alueet, varmuuskopioiden sijainnit ja rajat ylittävät siirrot.
• Tapahtumatodisteet: UTC-aikaleimat, Salesforce-instanssi, AWS-tili ja -alue, pyyntötunnukset, tapahtumatunnukset, tilasivut ja puhdistetut lokit.
• Palautustesti: dokumentoitu testi, joka varmistaa, että tietueita ei ole kahdennettu, puutu, järjestetty uudelleen tai kirjoitettu väärään ympäristöön uudelleenyhteyden muodostamisen jälkeen.

Älä koodaa pitkäaikaiseen runbookiin oletuksia julkisen pilven IP-alueista, palveluntarjoajien sijoittelusta tai tuotteen toiminnasta. Tarkista Salesforcen ja AWS:n nykyinen dokumentaatio Hyperforce-migraation, uuden alueen julkaisun, yhteysmuutoksen tai merkittävän integraatiojulkaisun jälkeen.

Miten tunnistat viallisen kerroksen nopeasti?

1. Kirjoita ylös epäonnistuneen toiminnon tarkka nimi, käyttäjä, organisaatio, aikaleima, päätepiste ja alue.
2. Tarkista Salesforce Trustista kyseinen instanssi ja tuote ja tarkista sitten AWS Healthista kyseinen tili ja alue.
3. Suorita turvallinen, vain luku -tilassa oleva testi toisesta verkosta tai ympäristöstä, jos käytäntö sen sallii.
4. Vertaile Salesforce-käyttöliittymän toimintaa, Salesforce-API:n toimintaa, suoraan AWS-päätepistettä ja kokonaisvaltaista työnkulkua.
5. Luokittele tulos Salesforce-palveluksi, AWS-palveluksi, asiakasverkoksi, todennukseksi, integraatiologiikaksi tai dataongelmaksi.
6. Eskaloi tapaus todisteiden kera ja keskeytä automaattiset uudelleenyritykset, jos ne lisäävät kuormitusta tai luovat kaksoiskappaleita.

Hyödyllinen tulos ei ole yksinkertaisesti ”Salesforce käyttää AWS:ää”. Hyödyllinen tulos on rajoitettu lause, kuten: ”Salesforce-organisaatio on tavoitettavissa, AWS on terve, mutta integraatiotyöntekijä ei pysty ratkaisemaan yksityistä päätepistettä” tai ”Salesforce Trust raportoi instanssiongelmasta, joten AWS-puolen uudelleenyritykset ovat odottamassa”. Tämä tarkkuustaso kertoo seuraavalle tiimille, mitä muuttaa – ja mitä ei.

Lopputulos

Salesforce ja AWS ovat läheisesti kytköksissä toisiinsa modernin pilviarkkitehtuurin osissa, erityisesti silloin, kun Hyperforce toimii AWS:ssä tai kun asiakas integroi Salesforcen tarkoituksella AWS-palveluihin. Suhde ei ole yksittäinen kaikki tai ei mitään -riippuvuus. Se on pino hallittuja hosting-palveluita, sovelluspalveluita, verkkopolkuja, datan sijainteja ja asiakkaan rakentamia integraatioita.

Käytä nykyistä suunnittelua varten lähtökohtana 4. elokuuta 2026 julkaistua Salesforce Hyperforce -usein kysyttyä ja tarkista sitten organisaatiosi tietyt tuotteet ja alueet. Tapahtumiin reagointia varten testaa jokainen kerros erikseen ja säilytä todisteet ennen kokoonpanon muuttamista. Tavoitteena ei ole poistaa kaikkia riippuvuuksia; tarkoituksena on tietää, mikä riippuvuus on olemassa, kuka sen omistaa, miten vika ilmenee ja miten liiketoiminta toipuu aiheuttamatta toista ongelmaa.

Viralliset viitteet

• Salesforce Hyperforcen usein kysytyt kysymykset, migraatio-opas ja tietoturvan yleiskatsaus
• Salesforce Hyperforcen julkisen pilven infrastruktuurin ja datan säilytyksen yleiskatsaus
• AWS Direct Connect -ohjeet Salesforce Hyperforcelle
• Salesforcen luottamustila
• AWS-palvelun tilan hallintapaneeli