8 Cloud Platforms Forward Deployed Engineers Ship Production AI On

When a forward deployed engineer ships an AI system into a customer, it almost always runs on a cloud platform, and usually the customer's chosen one rather than the engineer's favourite. That constraint shapes the work, because you cannot impose a preferred platform on an enterprise committed to another, so fluency across the major platforms is a practical necessity rather than a luxury. This piece walks through eight cloud platforms and services that forward deployed engineers deploy production AI on, what each offers, and why the ability to work across them matters so much when you build inside environments you do not choose.

Knowing these platforms is part of the deployment reality that defines the role, since deploying into the customer's cloud is where so much forward deployed work actually happens. Building fluency across the major AI cloud platforms, as part of what the Forward Deployed Engineering Program teaches, is what lets you deploy effectively wherever the customer's infrastructure lives, and the program's hands-on work with the leading platforms is built for exactly that.

Key Highlights

• Forward deployed engineers usually deploy on the customer's chosen cloud platform, not their own, so fluency across the major options is a practical necessity.
• AWS Bedrock and Azure OpenAI and AI Foundry are the platforms most enterprises use to run production AI, and the program teaches both directly.
• Google Vertex AI, Amazon SageMaker, and Databricks each offer distinct strengths for different kinds of AI and data work.
• Newer options like Snowflake Cortex and NVIDIA NIM bring AI to where the data or the hardware already lives.
• The ability to deploy across platforms, rather than mastery of one, is what the role actually requires.

AWS Bedrock: managed models on the dominant cloud

AWS Bedrock is Amazon's managed service for building and running generative AI applications, and it matters enormously because so many enterprises run on AWS, which makes Bedrock the natural place to deploy AI for a large share of customers. Bedrock provides access to a range of foundation models through a managed service, letting an engineer build AI applications on AWS without managing the underlying model infrastructure, which fits the common situation of deploying into an AWS-committed enterprise.

For forward deployed engineers, Bedrock's significance is largely about meeting the customer where they are. When a customer has standardised on AWS, deploying their AI on Bedrock means the system lives in the cloud they already use, secure within their existing AWS environment and governance, rather than requiring them to adopt a separate platform. This is exactly the kind of fit-the-customer's-environment consideration that dominates forward deployed technology choices, and it is why Bedrock is so frequently the deployment target. Hands-on work with Bedrock, including the dedicated agentic AI with AWS Bedrock workshop, is worth doing precisely because it is such a common production target, and comfort with it is a practical requirement for deploying into the large population of AWS-based enterprises.

Azure OpenAI and Azure AI Foundry: the Microsoft path

Azure OpenAI brings OpenAI's models into the Microsoft Azure cloud, which is significant because a large share of enterprises, especially larger and more traditional ones, run on Azure and are deeply invested in the Microsoft ecosystem. For these customers, Azure OpenAI is the natural way to use leading models within the cloud and governance framework they already trust, which makes it a frequent deployment target for forward deployed engineers working with Microsoft-centric organisations.

Azure AI Foundry is Microsoft's broader platform for building and deploying AI applications, extending beyond model access to a fuller environment for developing AI solutions on Azure. Together, Azure OpenAI and AI Foundry make the Microsoft cloud a complete path for enterprise AI, and for the many customers committed to Azure, deploying there means fitting into their existing environment rather than asking them to adopt something new. Because Microsoft's enterprise footprint is so large, fluency with the Azure AI path is as important as fluency with AWS, and the two together cover a large majority of enterprise deployments. Hands-on practice with the platform, such as the agentic AI with Azure AI Foundry program, reflects this, because forward deployed engineers need to be equally comfortable deploying on the Microsoft path as on AWS, since which one they use is dictated by the customer rather than by preference.

Google Vertex AI: the data and ML platform

Google Vertex AI is Google Cloud's platform for building, deploying, and managing AI and machine learning, and it is the natural deployment target for the enterprises committed to Google Cloud, completing the trio of major hyperscaler AI platforms. Vertex AI offers a comprehensive environment for AI work on Google Cloud, from model access to training and deployment, with particular strengths reflecting Google's deep machine learning heritage.

For forward deployed engineers, Vertex AI matters for the same reason as Bedrock and Azure: it is where a segment of customers have chosen to run, so deploying there is about meeting those customers in their environment. Google Cloud has also been investing heavily in getting AI into its customers' hands, including through its own forward deployed hiring, which means the platform is a live target for enterprise AI deployment. An engineer who can work across all three major clouds, AWS, Azure, and Google Cloud, can deploy for the great majority of enterprises regardless of which hyperscaler they have committed to, which is exactly the cross-platform fluency the role requires. Vertex AI completes that coverage, and comfort with it rounds out the ability to deploy wherever the customer's infrastructure happens to live.

Amazon SageMaker and Databricks: deeper ML and data platforms

Beyond the managed generative AI services, some forward deployed work runs on platforms built for deeper machine learning and data work. Amazon SageMaker is AWS's comprehensive platform for building, training, and deploying machine learning models, and it appears when a deployment involves more custom or deeper ML work than a managed model service like Bedrock covers. For customers whose needs go beyond calling foundation models into training or deploying custom models, SageMaker is the AWS environment for that deeper work.

Databricks is a unified platform for data and AI, widely used by enterprises for large-scale data work, and increasingly for AI built on top of that data. Because so much enterprise AI is fundamentally data work, and because many enterprises run their data on Databricks, it is a frequent environment for forward deployed engineers building AI on a customer's data at scale. Databricks also hires forward deployed engineers itself, reflecting how central deployment is to turning its platform into value. These platforms matter because forward deployed work is not always about calling a managed model, it often involves deeper data and ML work, and comfort with the platforms built for that, alongside the managed generative AI services, broadens the range of customer environments an engineer can deploy into effectively.

Snowflake Cortex and NVIDIA NIM: AI where the data and hardware live

Two newer options reflect a trend worth understanding: bringing AI to where the data or the hardware already is, rather than moving data to the AI. Snowflake Cortex brings AI capabilities directly into the Snowflake data platform, letting enterprises run AI on their data where it already lives, without moving it out to a separate service. For the many customers whose data sits in Snowflake, Cortex is appealing because it addresses one of the hardest problems in enterprise AI, getting the AI to the data, by putting the AI capabilities right where the data already is, which also eases the data-governance concerns that moving data would raise.

NVIDIA NIM provides optimised ways to run AI models on NVIDIA's hardware, which matters for deployments where performance, control, or on-premise requirements make running models on specific hardware important. For customers with on-premise or performance-sensitive needs, or those running their own GPU infrastructure, NIM offers a path to deploy models efficiently on that hardware. Both of these reflect a broader movement toward deploying AI where the data or the compute already lives, rather than assuming everything runs as a managed cloud service, which matters in the regulated and on-premise environments where forward deployed engineers frequently work. Knowing these options means an engineer can deploy AI in situations where the standard managed-cloud approach does not fit the customer's data-residency or infrastructure constraints, which is exactly the kind of flexibility the role rewards.

Why cross-platform fluency is the real skill

The recurring theme across all eight platforms is that a forward deployed engineer rarely chooses the platform, the customer does, which makes cross-platform fluency, rather than mastery of one, the skill the role actually requires. A customer committed to AWS will want their AI on Bedrock or SageMaker. One committed to Azure will want it on Azure OpenAI or AI Foundry. One on Google Cloud will want Vertex AI. One with data in Snowflake may want Cortex, and one with on-premise hardware may want NIM. The engineer has to be able to deploy effectively wherever the customer already lives.

This is a different kind of expertise from deep mastery of a single platform. It is the ability to be productive across many, to understand the common patterns that transfer between them, and to quickly become effective on whichever one a given customer uses. This cross-platform adaptability is exactly the sort of flexibility that defines forward deployed work more broadly, where you fit into the customer's existing environment rather than imposing your own preferences, whether that is their cloud, their frameworks, or their data stack. An engineer who insists on one platform limits themselves to the customers who happen to use it, while one who can deploy across all the major platforms can serve any customer, which is far more valuable. Building that breadth, rather than narrow depth in one platform, is what the role rewards.

Deployment is where the real difficulty lives

It is worth stressing that choosing the platform is the easy part, and the genuine difficulty of forward deployed cloud work is deploying reliably into the customer's specific configuration of that platform, which is never as clean as the documentation suggests. A customer's AWS or Azure environment is not a fresh account, it is a configured, secured, governed environment with existing resources, access controls, networking rules, and organisational policies that your deployment has to fit into. Getting an AI system running inside that real, constrained environment is where the work actually is, far more than in the choice of platform itself.

This is why platform fluency alone is insufficient, and why the deeper skill is deploying into constrained, pre-configured customer environments. You have to work within the customer's security policies, integrate with their existing resources, respect their networking and access rules, and do all of this without the freedom you would have in your own account. This is the deployment reality that defines forward deployed work, and it is genuinely hard in ways that a tutorial on a clean account never shows, connecting directly to the challenge of building and debugging inside an environment you do not control. The platform is just the ground you build on, and the skill is building reliably on ground that is already occupied and constrained. Developing that deployment capability through the Forward Deployed Engineering Program is what actually prepares you for the role, beyond familiarity with any single platform.

The eight platforms at a glance

To help you orient, here is how the eight platforms map across what they are for.

Read the table keyed to the customer's environment, because that is what determines the platform. The right choice is almost always the one that fits where the customer already runs, and the engineer's job is to be able to deploy effectively on whichever that turns out to be. Cross-platform fluency, not single-platform mastery, is what lets you do that.

The reassuring truth for anyone learning these platforms is that the concepts transfer heavily between them, so becoming genuinely fluent on one makes the others far faster to pick up. The patterns of deploying models, managing infrastructure, handling security, and integrating with existing systems recur across AWS, Azure, and Google Cloud, which means the investment in learning to deploy well is largely portable rather than locked to a single platform. Build deep competence on one, understand the transferable patterns, and adapting to whichever platform a customer uses becomes a matter of days rather than months, which is exactly the cross-platform flexibility the role rewards.

The wider lesson is that the platform is rarely the hard part of a deployment; the hard part is everything specific to the customer's configured, governed, occupied environment, which no platform tutorial prepares you for. That is why the deployment capability at the heart of forward deployed work, the ability to ship reliably into a real customer's constrained cloud, matters far more than familiarity with any single platform, and it is exactly the deployment reality that separates engineers who cross the divide from those who stall at the demo.

The bottom line

Forward deployed engineers ship production AI on the customer's chosen cloud platform, which spans AWS Bedrock, Azure OpenAI and AI Foundry, Google Vertex AI, deeper platforms like Amazon SageMaker and Databricks, and newer options like Snowflake Cortex and NVIDIA NIM that bring AI to where the data or hardware already lives. Each is the right target for customers committed to that environment, and the engineer rarely gets to choose, since the customer's existing infrastructure dictates the platform.

This is why cross-platform fluency, rather than mastery of a single platform, is the skill the role actually requires. An engineer who can deploy effectively across all the major platforms can serve any customer regardless of their infrastructure, while one who insists on a single platform limits themselves to a fraction of the market. Building that breadth, including hands-on command of the leading platforms like AWS Bedrock and Azure AI Foundry that the Forward Deployed Engineering Program teaches directly, is what lets you deploy wherever the customer's environment lives, which is exactly what forward deployed work demands.

Building deployment capability across platforms

Platform fluency is necessary but not sufficient, and the deeper skill is deploying reliably into the constrained, pre-configured environments that real customers run. Developing that capability through agentic AI foundations and the applied work that takes a developer into shipping AI features is what prepares you to deploy wherever the customer's infrastructure lives, on whichever platform they have committed to. The customer chooses the ground, and the engineer's value is the ability to build reliably on it, which is a capability that transfers across every platform rather than being tied to one.

In the end, the platforms come and go and evolve, but the underlying skill, deploying reliable AI into environments you do not fully control, endures, and building that durable capability is what keeps a forward deployed engineer effective no matter which clouds the market favours next.

The engineers who thrive across platforms treat each customer's cloud as simply the ground they build on, focusing their skill on reliable deployment rather than on any one provider's particular conveniences, which is what keeps them effective everywhere.