Понимание зависимости между Salesforce и AWS: что на самом деле от чего зависит

Вы открываете Salesforce, и обнаруживаете, что какая-то функция работает медленно, недоступна или выдает ошибку. В то же время вы замечаете сообщения о проблеме с AWS. Заманчиво сделать вывод: «Salesforce работает на AWS, поэтому AWS — причина». Иногда это может быть верно в общих чертах, но реальная зависимость гораздо сложнее. Salesforce активно использует AWS, особенно через Hyperforce , в то время как некоторые среды и сервисы Salesforce используют другую инфраструктуру. Поэтому инцидент с AWS может повлиять на некоторые рабочие нагрузки Salesforce, не обязательно выводя из строя всех клиентов Salesforce или все продукты Salesforce.

Практический вопрос заключается не просто в том, использует ли Salesforce AWS. Использует. Важный вопрос в том, какая часть вашего сервиса Salesforce где размещена, от какого региона или сервиса AWS она зависит и в чем причина проблемы: в Salesforce, AWS, вашей собственной интеграции или сетевом пути между ними . В этом руководстве объясняется эта зависимость, начиная с самых простых проверок и заканчивая более глубокими архитектурными деталями, а затем показано, как проверить вашу собственную ситуацию.

Во-первых, разберитесь, что Salesforce подразумевает под Hyperforce.

Hyperforce — это архитектура инфраструктуры публичного облака от Salesforce, предназначенная для развертывания приложений Salesforce в региональных облачных средах. Salesforce описывает Hyperforce как инфраструктуру, лежащую в основе Customer 360, и использует поставщиков публичных облаков для расширения региональной доступности, размещения данных, контроля безопасности и масштабируемости.

По данным Salesforce, по состоянию на сентябрь 2026 года Hyperforce доступен на Amazon Web Services в нескольких странах, а также расширяется на платформу Google Cloud Platform. Это различие имеет значение: утверждение «Salesforce использует AWS» верно, но утверждение «каждая организация Salesforce работает только на AWS» неверно. Salesforce также по-прежнему использует часть собственной инфраструктуры, управляемой Salesforce, и отдельные сервисы могут работать на инфраструктуре, отдельной от основной организации.

Актуальные рекомендации Salesforce по размещению инфраструктуры доступны в разделе «Справка Salesforce: Где находится мой экземпляр Salesforce?» . Salesforce также объясняет свою более широкую модель Hyperforce в разделе «Общая информация и часто задаваемые вопросы» на сайте Salesforce, посвященном Hyperforce .

Насколько сильна зависимость между Salesforce и AWS?

Зависимость существенная, но многоуровневая. AWS уже много лет является крупным стратегическим поставщиком облачных услуг для Salesforce, и AWS описывает эти компании как имеющие глобальное стратегическое партнерство. Salesforce использует инфраструктуру AWS для развертывания Hyperforce, а также интегрировала продукты Salesforce с сервисами AWS, такими как Amazon Connect и Amazon Bedrock.

Для клиента полезно разделить отношения на три уровня:

Эта многоуровневая модель является ключом к устранению неполадок. Страница состояния, на которой написано «Salesforce работает», не доказывает работоспособность вашей интеграции, размещенной на AWS. И наоборот, крупное событие AWS не доказывает, что затронут именно ваш экземпляр Salesforce.

Почему сбой в работе AWS не означает автоматически, что Salesforce не работает.

Компания Salesforce заявляет, что экземпляры Hyperforce используют модель «активный/активный» в трех зонах доступности в пределах соответствующего региона. Зона доступности (AZ) — это изолированное местоположение внутри региона AWS. В конфигурации «активный/активный» ресурсы приложений распределяются между несколькими зонами, а не оставляют одну зону в режиме ожидания. Salesforce утверждает, что трафик распределяется между активными серверами приложений во всех трех зонах, а репликация базы данных обеспечивает согласованность данных между зонами.

Такая архитектура призвана уменьшить зависимость от какой-либо одной зоны доступности. Если в одной зоне доступности возникает локальная проблема, такая архитектура может помочь сервису продолжать работу в других зонах. Однако многозональная архитектура не исключает всех возможных режимов отказа. Проблемы с сервисом в масштабе всего региона, проблемы на уровне плоскости управления, сбои в сети, ошибки программного обеспечения, сбои зависимостей или инциденты на уровне приложений по-прежнему могут влиять на доступность.

Таким образом, правильная модель мышления такова: Salesforce на AWS спроектирована таким образом, чтобы быть отказоустойчивой в пределах региона AWS, но при этом она имеет зависимости от инфраструктуры, которые могут иметь значение во время крупных событий на AWS .

Некоторые сервисы Salesforce могут выходить из строя независимо от основной организации.

Именно здесь часто возникают ошибки при расследовании инцидентов. Salesforce прямо указывает, что некоторые сервисы могут работать на отдельной инфраструктуре, интегрируясь при этом с организацией клиента. Например, в документации Salesforce для Sales Engagement, Einstein Activity Capture, Salesforce Inbox и Einstein Conversation Insights указано, что эти сервисы размещаются на инфраструктуре AWS, отдельной от основной инфраструктуры Salesforce Core организации.

Это означает, что пользователь может столкнуться с такой ситуацией:

• Вход в Salesforce и основные записи CRM работают в обычном режиме.
• Произошло снижение производительности или ухудшение качества конкретной услуги, связанной с Эйнштейном.
• Проблема связана с отдельной инфраструктурой, а не с основной организацией Salesforce.

Компания Salesforce описывает это разделение в своих рекомендациях по миграции Hyperforce для Sales Engagement, Einstein Activity Capture, Salesforce Inbox и Einstein Conversation Insights .

Начните поиск и устранение неисправностей с самых простых проверок.

1. Перед тем как предполагать, что ответственность несет AWS, проверьте доверие к Salesforce.

Начните с официальной информации о состоянии и доверии Salesforce. Узнайте состояние вашего конкретного экземпляра Salesforce, а не полагайтесь на общие отчеты о том, что «Salesforce не работает». Salesforce объясняет, как определить экземпляр организации, в разделе « Просмотр информации об экземпляре для вашей организации Salesforce» .

В настройках Salesforce воспользуйтесь полем быстрого поиска, чтобы найти раздел «Информация о компании» , а затем найдите поле «Экземпляр» . Salesforce отмечает, что двухбуквенные префиксы экземпляров, такие как AP0, указывают на управляемую Salesforce инфраструктуру собственного производства, а трехбуквенные префиксы, такие как GBR10, указывают на инфраструктуру Hyperforce.

2. Определите, находится ли ваша организация Hyperforce на AWS.

Наличие экземпляра Hyperforce не означает, что он навсегда будет ассоциироваться с AWS. Salesforce заявляет, что Hyperforce доступен на AWS и расширяется на Google Cloud Platform. В документации компании клиентам, которым необходимо определить, находится ли конкретный экземпляр Hyperforce на AWS или GCP, рекомендуется обратиться в службу поддержки клиентов Salesforce.

Это становится все более важным для сопоставления инцидентов. Не следует сопоставлять «Hyperforce» с «AWS», основываясь исключительно на самом слове.

3. Проверяйте конкретный регион AWS только в том случае, если это имеет значение.

Если вы подтвердили, что ваша организация или затронутая служба Salesforce работает на AWS, определите регион. В документации Salesforce по текущим местоположениям указаны регионы Hyperforce и их поставщики публичного облака. Например, Salesforce перечисляет регионы Hyperforce, поддерживаемые AWS, в таких местах, как Сидней, Мумбаи, Токио, Сингапур, Лондон, Франкфурт, Центральная Канада и несколько регионов США.

Затем сравните инцидент с Salesforce с официальной информацией AWS Health, относящейся к этому региону и сервису. Не следует рассматривать проблему в одном регионе AWS как доказательство проблемы в несвязанном регионе Salesforce.

4. Отделите хостинг Salesforce от собственной интеграции с AWS.

Если сама система Salesforce работает исправно, проверьте путь интеграции. Типичные зависимости на стороне клиента включают в себя API-шлюзы, функции Lambda, Amazon Connect, базы данных, очереди, частные конечные точки, VPN, DNS и средства управления корпоративной сетью. Сбой в одном из этих компонентов может восприниматься пользователями как «проблема Salesforce», поскольку ошибка возникает внутри рабочего процесса Salesforce.

Полезным тестом будет задать себе вопрос: может ли та же самая операция Salesforce успешно завершиться без вызова нашего сервиса AWS? Если да, то основная организация может работать нормально, в то время как интеграционный путь не работает.

А что насчет AWS Direct Connect?

Некоторые организации используют AWS Direct Connect — частное сетевое соединение с AWS — для обеспечения сетевых требований Hyperforce на AWS. Компания Salesforce описывает пример использования маршрутизации определенного почтового трафика Hyperforce через AWS Direct Connect для организаций, которым необходимы частное подключение, соответствие нормативным требованиям или размещение данных.

Это создает еще один уровень зависимости. При использовании частного подключения инцидент может происходить между пользователем и Salesforce, а не внутри самой Salesforce. Соответствующая документация Salesforce находится в разделе « Маршрутизация электронной почты через AWS Direct Connect для Hyperforce» .

Почему Salesforce переходит к мультиоблачной модели Hyperforce

Компания Salesforce описывает Hyperforce как решение, разработанное для работы на нескольких публичных облачных платформах. Это снижает архитектурное предположение о том, что один гипермасштабируемый провайдер должен быть постоянной основой для всех рабочих нагрузок Salesforce. В документации Salesforce на 2026 год указано, что Hyperforce доступен на AWS, а поддержка Google Cloud Platform внедряется в отдельных регионах в соответствии с планами развития компании.

Для клиентов это не означает, что существующая организация Salesforce автоматически переключается с AWS на Google Cloud во время сбоя AWS. Поддержка мультиоблачных решений в первую очередь касается того, где Salesforce может развертывать и эксплуатировать свою платформу. Не следует предполагать возможность переключения между провайдерами, если Salesforce явно не документирует это для используемой вами службы.

Как партнерство Salesforce и AWS выходит за рамки простого хостинга

Эти отношения не ограничиваются только предоставлением инфраструктуры. AWS и Salesforce описывают более широкое стратегическое партнерство в области данных, искусственного интеллекта, возможностей контакт-центров, интеграции и закупок. На официальной странице партнерства AWS освещаются интеграции продуктов Salesforce и технологий AWS, включая возможности генеративного ИИ и управления данными. Вы можете ознакомиться с этими отношениями на официальной странице партнерства AWS и Salesforce .

Это важно при проведении архитектурных обзоров, поскольку возникают два разных вопроса, касающихся зависимостей:

• Где работает сама компания Salesforce? Это зависит от хостинга.
• Какие сервисы AWS вы выбрали для подключения к Salesforce? Это зависимость интеграции, которую вы можете контролировать.

Эти две зависимости имеют разных владельцев, пути мониторинга, процедуры восстановления и группы поддержки.

Практический контрольный список инцидентов

Когда пользователи сообщают о недоступности или частичной неисправности Salesforce, выполните следующие проверки в указанном порядке:

1. Уточните, какая именно функция Salesforce затронута, а не просто "Salesforce".
2. Найдите свой экземпляр Salesforce и проверьте его официальный статус доверия Salesforce.
3. Определите, использует ли организация инфраструктуру, управляемую Salesforce, или Hyperforce.
4. Если речь идёт о Hyperforce, проверьте, использует ли соответствующее развертывание AWS.
5. Выбирайте регион AWS только после того, как убедитесь в его актуальности.
6. Проверьте, не является ли функция, вызывающая сбой, отдельным сервисом Salesforce, размещенным независимо от основной организации.
7. Проверьте, не являются ли причиной сбоя ваши собственные интеграции с AWS, частные сети, DNS, API или сервисы контакт-центра.
8. Запишите временные метки и идентификаторы запросов, чтобы служба поддержки Salesforce или AWS могла сопоставить причину сбоя.

Как проверить свой вывод

Понимание того, что ваш диагноз становится более убедительным, проявляется, когда доказательства совпадают на разных уровнях. Если служба поддержки Salesforce сообщает об инциденте именно для вашего экземпляра, и затронутая функция соответствует симптомам, то сторона Salesforce явно причастна к инциденту. Если Salesforce работает исправно, но ваши тесты интеграции с AWS завершаются с ошибкой в ​​тот же период времени, то зависимость от AWS на стороне клиента является более убедительным доказательством. Если затронуто только одно дополнение Salesforce, в то время как основные функции CRM остаются в норме, следует изучить отдельную инфраструктуру и состояние этой службы.

Не останавливайтесь на фразах типа «В AWS произошёл сбой» или «В Salesforce возникла проблема». Надёжный ответ можно получить, сопоставив вашу систему, продукт, регион и путь интеграции .

Итог

Компания Salesforce сильно зависит от AWS, особенно потому, что многие развертывания Hyperforce и поддерживающие сервисы работают на инфраструктуре AWS. Но эта зависимость не является универсальной или одномерной. Salesforce также использует собственную инфраструктуру, расширяет использование Hyperforce на нескольких публичных облачных провайдерах и может размещать отдельные сервисы отдельно от основной организации клиента.

Для операционных команд наилучший подход — рассматривать Salesforce и AWS как граф зависимостей, а не как единую систему. Определите, где работает основная организация, сопоставьте отдельно размещенные сервисы Salesforce, задокументируйте каждую интеграцию AWS, управляемую клиентом, и отслеживайте каждый уровень независимо. Это значительно ускорит процесс от «Salesforce не работает» до выявления конкретного компонента, требующего внимания.