When a Salesforce page slows down or an integration stops delivering records, teams often ask a simple question: “Is AWS down, or is Salesforce down?” That question is understandable, but it can lead to the wrong investigation. Salesforce is a software provider, AWS is a cloud infrastructure provider, and the relationship between them changes depending on the Salesforce product, org, region, network path, and integration design.
A verified update gives the relationship useful context. Salesforce Help published an updated Hyperforce FAQ on August 4, 2026. It says Hyperforce is available on Amazon Web Services (AWS), with Google Cloud Platform availability planned from late 2026, and that Salesforce manages infrastructure placement using technical and operational factors. The same FAQ says some products or features may initially be available on Hyperforce on AWS while they are not yet available on GCP. This does not mean every Salesforce service is hosted on AWS, that every customer chooses the underlying provider, or that an AWS incident automatically becomes a Salesforce incident. This guide explains the dependency in those layers, using information checked on September 16, 2026.
“Dependency” can describe several different relationships. The most important distinction is between a managed service dependency and a customer-created integration:
| Layer | What is connected | Who usually controls it | What a failure may look like |
|---|---|---|---|
| Salesforce application | CRM products, APIs, identity, metadata, and business logic | Salesforce | Login failures, API errors, slow pages, or unavailable features |
| Hyperforce infrastructure | Salesforce application stacks deployed on public-cloud infrastructure | Salesforce manages the placement; the cloud provider operates its underlying services | Regional capacity, networking, storage, or infrastructure effects |
| Customer integration | Salesforce connected to AWS services such as applications, data stores, or event pipelines | Your integration and operations teams, with provider-specific controls | Timeouts, authentication errors, missing events, or failed writes |
| Network path | Internet, private connectivity, DNS, firewalls, routing, or Direct Connect | Customer, telecom, AWS, and Salesforce depending on the path | Only one office, VPC, region, or application cannot connect |
| Data and compliance | Where data is stored, processed, backed up, and transferred | Shared across product configuration, contracts, and architecture | Residency questions, blocked transfers, or an audit finding |
The table is a troubleshooting model, not a statement that every Salesforce product uses every AWS component. Check the product-specific documentation and your order configuration before making an architectural or compliance decision.
No. Hyperforce is Salesforce’s infrastructure architecture. Salesforce describes it as a public-cloud architecture managed as code, designed to support global delivery, data residency, security, scalability, and agility. AWS is one public-cloud provider on which Hyperforce is available. The platform name, the Salesforce product, and the underlying cloud provider are therefore different parts of the stack.
The updated Salesforce FAQ says Salesforce manages infrastructure placement based on technical and operational factors. For a customer, that means an org running on Hyperforce should not be treated like an AWS account where the customer chooses an Availability Zone, changes an EC2 instance, or opens a security group. Salesforce operates the managed SaaS environment. Your team can still have AWS dependencies around it—for example, a data pipeline, private connection, event consumer, or application hosted in your AWS account—but those are separate from Salesforce’s own infrastructure placement.
Salesforce also notes that services not hosted on Hyperforce continue to operate as before, and that product availability can differ by public-cloud provider. For current product and provider details, consult the Salesforce Hyperforce FAQ and migration guide. Treat that page as versioned operational guidance rather than a permanent promise: Salesforce says the document is informational and subject to change.
This is the closest thing to a direct infrastructure dependency. If a particular Salesforce org and product are placed on Hyperforce on AWS, an incident in a relevant AWS region or service could become one factor in Salesforce availability. But the actual customer-facing failure may be caused by Salesforce application code, a Salesforce control plane, a dependency in another region, a routing problem, or a product-specific service. Seeing AWS as the underlying provider is not enough to identify the root cause.
This is often the dependency customers notice first. A Salesforce org may send data to an AWS-hosted service, receive events from a queue, call an API in a VPC, read from a data platform, or use an AWS service as part of an application workflow. In this design, Salesforce can be healthy while your AWS endpoint, credentials, network route, or event consumer is failing. The reverse is also possible: AWS can be healthy while the Salesforce API or authentication layer is unavailable.
Salesforce Private Connect is a cross-cloud integration pattern for connecting a Salesforce org with a customer’s AWS services. AWS Direct Connect is a network connectivity option that can provide a path from an on-premises environment to AWS and, through a public virtual interface, to Hyperforce. They are not interchangeable controls.
The joint Salesforce and AWS guidance says Salesforce Express Connect is not compatible with Hyperforce, and describes AWS Direct Connect with a public virtual interface as an option for some customers that need direct connectivity to Hyperforce. It also distinguishes Private Connect, which connects a Salesforce org to a customer’s AWS services. Read the AWS guidance for accessing Hyperforce with Direct Connect before changing network architecture. Availability, routing, and contract requirements still need to be checked for your org.
No. A Salesforce incident and an AWS incident can overlap, but they are not synonyms. Salesforce publishes service status through its Trust site, while AWS publishes service health and account-specific events through AWS Health. Start with the service that is failing and the exact region or instance involved, rather than assuming the largest provider in the stack is responsible.
Use this comparison during an incident:
| Observed symptom | First place to look | Interpretation to test |
|---|---|---|
| All Salesforce users cannot log in or use multiple products | Salesforce Trust, org instance, and Salesforce support channel | Salesforce-wide or instance-level service disruption |
| Only one AWS-backed integration fails | Application logs, AWS Health, credentials, DNS, and endpoint metrics | Customer integration or AWS service issue |
| Only one office or VPC cannot reach Salesforce | Routes, firewall rules, DNS, Direct Connect, and trusted IP configuration | Network-path or local configuration issue |
| Salesforce UI works but a scheduled sync stalls | API limits, OAuth token, queue depth, retries, and integration logs | Workflow or API dependency rather than core availability |
| One product or feature is unavailable | Product-specific Salesforce status and release documentation | Component-level issue, maintenance, or feature dependency |
This distinction affects escalation. If Salesforce Trust reports an incident affecting your instance, collect the incident number and avoid making destructive configuration changes. If Trust is clear but your AWS endpoint shows errors, preserve request IDs and investigate the AWS side. If both appear healthy, compare a direct Salesforce API test, an AWS endpoint test, and the full integration path; a problem between healthy services is still possible.
Hyperforce can change where Salesforce applications and data are hosted, but “regional” does not mean “every byte stays in one country in every situation.” Salesforce says customer data is generally stored in the country where the org is located when the services in use are available there. It also warns that some products may have components in different countries or include integrations to services that are not yet on Hyperforce.
That caveat is important when AWS is part of the design. You need to map at least four locations: the Salesforce org and its Hyperforce operating region, the AWS region holding the connected service or data, the location of integration workers and logs, and the location of backup or disaster-recovery copies. An AWS region selected by your team does not override Salesforce’s product architecture, and a Salesforce data-residency option does not automatically place your external AWS data in the same region.
Use the Salesforce Hyperforce public-cloud infrastructure overview and your organization’s Trust and Compliance Documentation to validate the products, regions, and commitments that apply to your environment. For regulated data, have privacy, security, and legal teams review the actual service terms rather than relying on a general architecture diagram.
Resilience begins with avoiding a single synchronous chain for every business action. If a Salesforce transaction must wait for an AWS service, define what happens when the AWS service is slow or unavailable. Depending on the business process, a queue, retry with exponential backoff, idempotency key, circuit breaker, dead-letter path, or manual reconciliation may be safer than repeated synchronous calls.
Use bounded retries. A retry that continues while Salesforce or AWS is degraded can multiply traffic and turn a short incident into a larger backlog. Record the original request, the retry count, the response code, and the final disposition. Make duplicate delivery safe before enabling automatic replay of events.
Separate recovery objectives for the Salesforce side from objectives for the AWS side. A backup of an AWS database does not restore a Salesforce org configuration, and a Salesforce recovery option does not restore an external AWS application. Salesforce describes an Out of Region Disaster Recovery capability for a secure backup of an instance in a secondary Hyperforce region, but availability and contractual scope must be verified for the products and edition you use. Do not present that option as a universal failover plan.
Do not hard-code assumptions about public-cloud IP ranges, provider placement, or product behavior into a long-lived runbook. Review the current Salesforce and AWS documentation after a Hyperforce migration, a new region launch, a connectivity change, or a major integration release.
A useful result is not simply “Salesforce uses AWS.” The useful result is a bounded statement such as: “The Salesforce org is reachable, AWS is healthy, but the integration worker cannot resolve the private endpoint,” or “Salesforce Trust reports an instance issue, so our AWS-side retries are being held.” That level of precision tells the next team what to change—and what not to change.
Salesforce and AWS are closely connected in parts of the modern cloud architecture, especially where Hyperforce runs on AWS or where a customer deliberately integrates Salesforce with AWS services. The relationship is not a single all-or-nothing dependency. It is a stack of managed hosting, application services, network paths, data locations, and customer-built integrations.
For current planning, use the August 4, 2026 Salesforce Hyperforce FAQ as the starting point, then verify the specific products and regions in your org. For incident response, test each layer independently and preserve evidence before changing configuration. The goal is not to eliminate every dependency; it is to know which dependency exists, who owns it, how failure appears, and how the business recovers without creating a second problem.
Review notable Salesforce outages in 2025, what failed, how long selected incidents lasted, and the practical resilience lessons teams can apply.
Build a practical Salesforce downtime continuity plan with impact analysis, RTO/RPO targets, manual workarounds, integration controls, and recovery checks.
Learn how to contact Salesforce Support during a major outage: check Trust Status, choose the right channel, open a strong case, and track recovery.
Troubleshoot Salesforce Workbench login, REST Explorer, timeout, 503, API-version, and limit errors during downtime with a practical diagnostic checklist.
StoreForce issues can disrupt scheduling, timekeeping, and employee workflows. Learn how to assess impact, keep stores operating, verify recovery, and know when to escalate.
Understand the main causes of widespread cloud downtime, how failures cascade, what to check first, and how to design a more resilient recovery plan.
If Datorama or Marketing Cloud Intelligence seems down, use this evidence-based checklist to verify the outage, protect reporting quality, and know when data is trustworthy again.
A practical look at how Heroku outages can affect deployed apps, dynos, routing, databases, deploys, Heroku Connect, logs, and recovery.
Understand how Salesforce and AWS connect through Hyperforce, integrations, networking, data residency, outages, and shared operational responsibilities.
An AWS outage does not automatically mean Salesforce is down. Learn how Hyperforce, regions, instances, and Salesforce Trust determine whether your org is affected.
