Você abre o Salesforce e uma funcionalidade está lenta, indisponível ou retorna um erro. Ao mesmo tempo, você percebe relatos de um problema na AWS. É tentador concluir que "o Salesforce roda na AWS, então a AWS deve ser a causa". Às vezes, isso pode estar parcialmente correto, mas a dependência real é mais complexa. O Salesforce usa a AWS extensivamente, principalmente por meio do Hyperforce , enquanto alguns ambientes e serviços do Salesforce usam outras infraestruturas. Um incidente na AWS pode, portanto, afetar algumas cargas de trabalho do Salesforce sem necessariamente interromper todos os clientes ou todos os produtos do Salesforce.
A questão prática não é simplesmente se a Salesforce usa a AWS. Ela usa. A questão útil é qual parte do seu serviço Salesforce está hospedada em qual região ou serviço da AWS ele depende e se o problema está na Salesforce, na AWS, na sua própria integração ou no caminho de rede entre eles . Este guia explica essa dependência desde as verificações mais simples até os detalhes arquitetônicos mais complexos e, em seguida, mostra como verificar sua própria situação.
O Hyperforce é a arquitetura de infraestrutura de nuvem pública da Salesforce para fornecer aplicativos da Salesforce em ambientes de nuvem regionais. A Salesforce descreve o Hyperforce como a infraestrutura por trás do Customer 360 e utiliza provedores de nuvem pública para expandir a disponibilidade regional, a residência de dados, os controles de segurança e a escalabilidade.
A partir de setembro de 2026, a Salesforce afirma que o Hyperforce estará disponível na Amazon Web Services em diversos países e também está se expandindo para o Google Cloud Platform. Essa distinção é importante: "A Salesforce usa a AWS" é verdade, mas "toda organização da Salesforce roda exclusivamente na AWS" não é. A Salesforce ainda opera alguma infraestrutura própria gerenciada pela própria Salesforce, e serviços individuais podem ser executados em infraestrutura separada da organização principal.
As orientações atuais da Salesforce sobre a localização da infraestrutura estão disponíveis na Ajuda do Salesforce: Onde está localizada minha instância do Salesforce? . A Salesforce também explica seu modelo Hyperforce de forma mais abrangente nas informações gerais e perguntas frequentes sobre o Hyperforce .
A dependência é substancial, mas complexa. A AWS tem sido um importante provedor estratégico de nuvem para a Salesforce há anos, e a AWS descreve as empresas como tendo uma parceria estratégica global. A Salesforce usa a infraestrutura da AWS para implantações do Hyperforce e também integrou produtos da Salesforce com serviços da AWS, como o Amazon Connect e o Amazon Bedrock.
Para o cliente, ajuda separar o relacionamento em três camadas:
| Camada | O que depende da AWS | O que isso significa na prática |
|---|---|---|
| Camada de hospedagem do Salesforce | Uma organização ou serviço do Salesforce pode ser executado no Hyperforce hospedado em uma região da AWS. | Um problema regional ou de infraestrutura subjacente da AWS pode afetar a disponibilidade do Salesforce para essa carga de trabalho hospedada. |
| Camada de produto-serviço do Salesforce | Alguns complementos ou serviços de suporte do Salesforce podem ser executados na AWS separadamente da organização principal do Salesforce. | Uma funcionalidade pode falhar mesmo quando o núcleo do CRM permanece íntegro. |
| Camada de integração do cliente | Sua empresa pode conectar o Salesforce às suas próprias cargas de trabalho da AWS, APIs, Amazon Connect, pipelines de dados ou redes privadas. | O problema pode estar na sua conta da AWS ou no seu caminho de rede, mesmo que o Salesforce esteja funcionando normalmente. |
Esse modelo em camadas é fundamental para a resolução de problemas. Uma página de status que indica que "o Salesforce está operacional" não comprova que sua integração hospedada na AWS esteja funcionando corretamente. Por outro lado, um evento genérico da AWS não comprova que sua instância específica do Salesforce esteja afetada.
A Salesforce afirma que as instâncias do Hyperforce utilizam um modelo ativo/ativo em três Zonas de Disponibilidade dentro da região relevante. Uma Zona de Disponibilidade (AZ) é uma localização isolada dentro de uma região da AWS. Em um design ativo/ativo, a capacidade do aplicativo opera em várias zonas, em vez de manter uma zona ociosa como um servidor de espera frio. A Salesforce afirma que o tráfego é distribuído entre servidores de aplicativos ativos nas três zonas e a replicação do banco de dados mantém a consistência entre as zonas.
Essa arquitetura visa reduzir a dependência de uma única zona de disponibilidade. Se uma zona de disponibilidade apresentar um problema localizado, o projeto pode ajudar o serviço a continuar funcionando nas outras zonas. No entanto, uma arquitetura com múltiplas zonas de disponibilidade não elimina todas as possíveis falhas. Um problema de serviço em toda a região, uma falha no plano de controle, uma interrupção na rede, uma falha de software, uma falha de dependência ou um incidente no nível da aplicação ainda podem afetar a disponibilidade.
Portanto, o modelo mental correto é: o Salesforce na AWS foi projetado para ser resiliente dentro de uma região da AWS, mas ainda possui dependências de infraestrutura que podem ser relevantes durante eventos de maior porte na AWS .
É aqui que muitas investigações de incidentes falham. A Salesforce observa explicitamente que certos serviços podem ser executados em infraestrutura separada, mesmo integrados à organização do cliente. Por exemplo, a documentação da Salesforce para Sales Engagement, Einstein Activity Capture, Salesforce Inbox e Einstein Conversation Insights afirma que esses serviços são hospedados em infraestrutura da AWS separada da infraestrutura principal da Salesforce da organização.
Isso significa que um usuário poderia se deparar com uma situação como:
A Salesforce documenta essa separação em seu guia de migração para o Hyperforce, que inclui o Sales Engagement, o Einstein Activity Capture, o Salesforce Inbox e o Einstein Conversation Insights .
Comece consultando as informações oficiais de status e confiança da Salesforce. Descubra o status da sua instância específica do Salesforce em vez de confiar em relatórios genéricos que indicam que "o Salesforce está fora do ar". A Salesforce explica como identificar a instância de uma organização em Exibir informações da instância da sua organização do Salesforce .
Na Configuração do Salesforce, use a caixa Busca rápida para localizar Informações da empresa e, em seguida, procure o campo Instância . O Salesforce observa que prefixos de instância de duas letras, como AP0, indicam infraestrutura própria gerenciada pelo Salesforce, enquanto prefixos de três letras, como GBR10, indicam infraestrutura Hyperforce.
Uma instância do Hyperforce não é automaticamente sinônimo de AWS para sempre. A Salesforce afirma que o Hyperforce está disponível na AWS e está se expandindo para o Google Cloud Platform. Sua documentação recomenda que os clientes que precisam determinar se uma instância específica do Hyperforce está na AWS ou no GCP entrem em contato com o Suporte ao Cliente da Salesforce.
Isso é cada vez mais importante para a correlação de incidentes. Você não deve associar "Hyperforce" a "AWS" apenas com base na palavra em si.
Se você confirmou que sua organização ou o serviço Salesforce afetado está sendo executado na AWS, identifique a região. A documentação de localização atual da Salesforce lista as regiões do Hyperforce e seus respectivos provedores de nuvem pública. Por exemplo, a Salesforce lista regiões do Hyperforce com suporte da AWS em locais como Sydney, Mumbai, Tóquio, Singapura, Londres, Frankfurt, Canadá Central e diversas regiões dos EUA.
Em seguida, compare o incidente do Salesforce com as informações oficiais de integridade da AWS relevantes para essa região e serviço. Evite tratar um problema em uma região da AWS como evidência de um problema em uma região não relacionada do Salesforce.
Se o Salesforce em si estiver funcionando corretamente, inspecione seu caminho de integração. As dependências típicas do lado do cliente incluem gateways de API, funções Lambda, Amazon Connect, bancos de dados, filas, endpoints privados, VPNs, DNS e controles de rede corporativa. Uma falha em um desses componentes pode aparecer para os usuários como um "problema do Salesforce", pois o erro ocorre dentro de um fluxo de trabalho do Salesforce.
Um teste útil é perguntar: a mesma operação do Salesforce pode ser executada com sucesso sem chamar nosso serviço da AWS? Se sim, a estrutura principal da organização pode estar íntegra, enquanto o caminho de integração está falhando.
Algumas organizações usam o AWS Direct Connect , uma conexão de rede privada com a AWS, para atender aos requisitos de rede do Hyperforce na AWS. A Salesforce documenta um caso de uso para rotear determinado tráfego de e-mail do Hyperforce por meio do AWS Direct Connect para organizações com requisitos de conectividade privada, conformidade ou residência de dados.
Isso cria mais uma camada de dependência. Quando há conectividade privada envolvida, um incidente pode ficar entre o usuário e o Salesforce, em vez de dentro do próprio Salesforce. A documentação relevante do Salesforce é " Roteamento de e-mail por meio do AWS Direct Connect para Hyperforce" .
A Salesforce descreve o Hyperforce como projetado para operar em vários provedores de nuvem pública. Isso reduz a premissa arquitetônica de que um único hiperescalador deva ser a base permanente para todas as cargas de trabalho da Salesforce. A documentação da Salesforce para 2026 afirma que o Hyperforce está disponível na AWS e que o suporte ao Google Cloud Platform está sendo introduzido em regiões selecionadas, sujeito às divulgações do roadmap da Salesforce.
Para os clientes, isso não significa que uma organização Salesforce existente migrará automaticamente da AWS para o Google Cloud durante uma interrupção da AWS. O suporte a várias nuvens diz respeito principalmente a onde a Salesforce pode implantar e operar sua plataforma. Você não deve presumir que haverá failover entre provedores, a menos que a Salesforce o documente explicitamente para o serviço que você utiliza.
A relação não se limita apenas à hospedagem de infraestrutura. A AWS e a Salesforce descrevem uma parceria estratégica mais ampla em torno de dados, IA, recursos de central de atendimento, integração e aquisição. A página oficial de parcerias da AWS destaca as integrações que envolvem produtos da Salesforce e tecnologias da AWS, incluindo IA generativa e recursos de gerenciamento de dados. Você pode conferir essa relação na página oficial de parcerias entre AWS e Salesforce .
Isso é importante durante as revisões de arquitetura porque existem duas questões de dependência diferentes:
Essas duas dependências têm proprietários, caminhos de monitoramento, procedimentos de recuperação e equipes de suporte diferentes.
Quando os usuários relatarem que o Salesforce está indisponível ou parcialmente indisponível, siga estas verificações na ordem indicada:
Você sabe que seu diagnóstico está ficando mais sólido quando as evidências se alinham em todas as camadas. Se o Salesforce Trust reportar um incidente para sua instância específica e o recurso afetado corresponder aos sintomas, o lado do Salesforce está fortemente implicado. Se o Salesforce estiver funcionando corretamente, mas seus testes de integração com a AWS falharem no mesmo período, a dependência da AWS do lado do cliente é uma pista mais provável. Se apenas um complemento do Salesforce for afetado, enquanto as funções principais do CRM permanecerem normais, investigue a infraestrutura e o status desse serviço separadamente.
Não se limite a dizer que "a AWS teve uma interrupção" ou que "o Salesforce estava fora do ar". A resposta confiável vem da compatibilidade entre sua instância, seu produto, sua região e seu caminho de integração .
A Salesforce tem uma forte dependência da AWS, principalmente porque muitas implementações do Hyperforce e serviços de suporte são executados na infraestrutura da AWS. Mas essa dependência não é universal nem unidimensional. A Salesforce também opera infraestrutura própria, está expandindo o Hyperforce para vários provedores de nuvem pública e pode hospedar serviços individuais separadamente da organização principal do cliente.
Para as equipes de operações, a melhor abordagem é tratar o Salesforce e a AWS como um grafo de dependências, em vez de uma única plataforma. Identifique onde a estrutura principal da organização é executada, mapeie os serviços do Salesforce hospedados separadamente, documente cada integração da AWS gerenciada pelo cliente e monitore cada camada de forma independente. Isso proporciona um caminho muito mais rápido desde a constatação de que "o Salesforce está com problemas" até o componente específico que realmente precisa de atenção.
Um guia prático para 2026 sobre IA, sensores para casas inteligentes, monitoramento remoto, segurança contra quedas, privacidade e como a tecnologia pode apoiar o envelhecimento no próprio lar sem substituir os cuidados.
Descubra como as cidades podem transformar dados de mobilidade, uso do solo, clima e comunidade em bairros mais seguros, verdes e acessíveis a pedestres, sem priorizar a tecnologia em detrimento das pessoas.
Compare os principais programas de engenharia aeroespacial e de UAVs (Veículos Aéreos Não Tripulados) para drones, autonomia, controles, operações de UAS (Sistemas de Aeronaves Não Tripuladas) e pesquisa de pós-graduação, com atualizações verificadas para 2026.
A practical guide to AI-powered surgical robotics: current capabilities, levels of autonomy, precision benefits, limits, regulation, and evaluation criteria.
O investimento em CCUS está aumentando, mas será que a captura de carbono pode reverter as emissões globais? Veja onde funciona, quais são os limites de escala e quais evidências são relevantes.
Compare seven global programs for digital supply chains, logistics, analytics, global trade, and operations, with practical guidance on choosing the right fit.
Aprenda como as interfaces cérebro-computador decodificam sinais neurais para restaurar a comunicação e o movimento, quais foram as conquistas de estudos recentes e o que ainda limita o uso das BCIs.
Veja como os drones comerciais combinam sensores, IA de ponta, baterias, comunicações e software de controle de voo — e como a autonomia ainda depende da missão e da regulamentação.
Compare sete opções de mestrado em baterias e armazenamento de energia de alta qualidade, considerando materiais, sistemas, pesquisa, experiência no setor, flexibilidade, idioma e custo-benefício.
Aprenda como a massa da carga útil, os limites da bateria, as condições climáticas, a eficiência da propulsão e a arquitetura da aeronave influenciam a autonomia dos UAVs industriais — e como melhorá-la.
