Building modern enterprise applications with ASP.NET in the cloud requires consideration of application architecture, cloud services, and deployment models. This article outlines how to develop and deploy ASP.NET applications (including MVC web apps, Blazor interactive UIs, and Web API services) on leading cloud platforms. It highlights key cloud features (like auto-scaling, CI/CD, containerization, and serverless functions) and compares Azure, AWS, and Google Cloud for hosting ASP.NET solutions. This guide is for technical decision-makers to plan a scalable, and compliant enterprise ASP.NET cloud architecture.
Belitsoft is a cloud-native ASP.NET software development company that provides end-to-end product-development and DevOps services with cross-functional .NET & cloud engineers.
Types of ASP.NET Applications to Build
ASP.NET Core MVC
The Model-View-Controller framework is a scalable pattern for building dynamic web applications with server-rendered HTML UI. An ASP.NET MVC app returns views (HTML/CSS) to browsers and is ideal for internal web portals or customer-facing websites. MVC can also expose APIs, but its primary role is delivering a self-contained web application (UI + logic).
ASP.NET Core Web API
A Web API project provides RESTful HTTP services and returns data (JSON or XML) for client applications. This is the preferred approach when building backend services for single-page applications (Angular, React, Vue), mobile apps, or B2B integrations. Unlike MVC, Web API projects do not serve HTML pages – they deliver data via endpoints to any authorized client. You can mix MVC and API in one project, but if a UI is not needed at all, a pure Web API project is a good choice.
Blazor Applications
Blazor is a modern ASP.NET Core framework for interactive web UIs in C# (alternative to JavaScript front-ends). Blazor can run on the server (Blazor Server) or in the browser via WebAssembly (Blazor WebAssembly).
Blazor is ideal when you want a single-page application and prefer .NET for both client and server logic. It reuses .NET code on client and server and integrates with existing .NET libraries.
Blazor improves developer productivity for .NET teams. (For comparison, Razor Pages – another ASP.NET option – also provides server-rendered pages, but Blazor is more dynamic on the client side.)
Cloud Services & Features to Prioritize
Successful ASP.NET cloud architectures rely on managed services that provide scalability, reliability, and efficiency out-of-the-box.
Automatic Scaling
Autoscaling adjusts capacity on demand. Enable elastic scaling so the application can handle fluctuations in load. Cloud platforms offer auto-scaling for both PaaS and container workloads.
For example, Azure App Service can automatically adjust instance counts based on CPU or request load, and AWS Auto Scaling groups or Google Cloud’s autoscalers can do similarly for VMs or containers.
Designing stateless application components is important – if the app keeps little or no session state in-memory, new instances can spin up or down seamlessly. Use health checks and load balancers to distribute traffic across instances.
CI/CD Pipelines
A continuous integration/continuous deployment pipeline is required for enterprise projects.
Automated build and release pipelines ensure that every code change goes through build, test, and deployment stages consistently
All major clouds support CI/CD: Azure offers Azure DevOps pipelines and GitHub Actions, AWS provides CodePipeline/CodeBuild, and GCP has Cloud Build. These services (or third-party tools like Jenkins) automate compiling the .NET code, running tests, containerizing apps if needed, and deploying to staging or production.
Investing in DevOps automation and infrastructure-as-code reduces errors and speeds up delivery. For example, Azure DevOps or GitHub Actions can build and deploy an ASP.NET app to Azure App Service or AKS with every commit, including running tests and security scans. CI/CD lets you release updates often and reliably, and makes rollbacks easy.
Containerization
Containerize ASP.NET applications using Docker to gain portability and consistency across environments.
A container image bundles the app and its runtime, ensuring it runs the same on a developer’s machine, in testing, and in production. Containerization is especially useful for microservices or when moving legacy .NET Framework apps to .NET in Linux containers.
All cloud platforms have container support: Azure App Service can deploy Docker containers, AWS offers Elastic Container Service (ECS) and Fargate, and Google Cloud Run or GKE run containers without custom infrastructure.
Kubernetes is widely used to orchestrate containers – Azure Kubernetes Service (AKS), Amazon EKS, and Google GKE are managed Kubernetes offerings to run containerized .NET services at scale.
Kubernetes provides features like service discovery, self-healing, and rolling updates, but also adds complexity. If your application consists of many microservices or requires multilanguage components, Kubernetes is a powerful choice.
For simpler needs, consider PaaS container services (Azure App Service for Containers, AWS App Runner, or Cloud Run) which allow running container images without managing the full Kubernetes control plane.
Containers wrap .NET apps so they run the same everywhere, and orchestration tools manage scaling and resilience — things like automatic restarts and traffic routing during updates.
Serverless Functions
Serverless computing allows running small units of code on demand without managing any servers.
For ASP.NET, this means using Functions-as-a-Service to run .NET code for individual tasks or endpoints. Azure Functions supports .NET for building event-driven pieces – an HTTP-triggered function to handle a form submission or a timer-triggered job for nightly data processing, etc. AWS Lambda similarly supports .NET for serverless functions, and Google Cloud Functions can be used via .NET runtimes (or run .NET code in a container with Cloud Run for a serverless effect).
These services automatically scale and charge based on execution rather than idle time. Serverless is ideal for sporadic or bursty workloads like processing messages from a queue, image processing, or lightweight APIs. For example, an e-commerce app might offload PDF report generation or thumbnail image processing to an Azure Function that spins up on-demand.
By using serverless, you gain extreme elasticity (including scale-to-zero when no requests) and fine-grained cost control (pay only for what you use). Combine serverless with event-driven design (using queues or pub/sub topics) to decouple components and improve resilience through asynchronous processing.
Managed Backing Services
Beyond compute, prioritize cloud-managed services for databases, caching, and messaging in your architecture.
Cloud providers offer database-as-a-service (Azure SQL Database, Amazon RDS for SQL Server or Aurora, Google Cloud SQL/Postgres, etc.) so you don’t manage VMs for databases.
Use distributed caches (Azure Cache for Redis or AWS ElastiCache) instead of in-memory caches on app servers, so that new instances have immediate access to cached data.
Likewise, use managed message brokers (Azure Service Bus, AWS SQS/SNS, Google Pub/Sub) for reliable inter-service communication and to implement asynchronous processing. These services are built to scale, highly available, and maintained by the provider, freeing your team from patching.
Monitoring and Diagnostics
Enable logging, monitoring, and tracing. Cloud-native monitoring tools like Azure Application Insights for .NET apps provide distributed tracing, performance metrics, and error logging with minimal configuration, Amazon CloudWatch with X-Ray for tracing on AWS, or Google Cloud Operations suite for GCP. These provide real-time telemetry on system health and user activity.
Set up alerts on key metrics (CPU, error rates, response times) and use centralized log search. In production, a monitoring setup helps quickly pinpoint issues – tracing a slow API request across microservices in Application Insights, etc. This is critical for meeting enterprise reliability requirements.
Cloud Deployment Models for ASP.NET Applications
Deciding on the right deployment model is a fundamental architectural choice. ASP.NET applications can be deployed using Platform as a Service, Infrastructure as a Service, or container-based solutions, each with pros and cons. Often a combination is used in enterprise solutions (for example, using PaaS for the web front-end and Kubernetes for a complex back-end). Below we outline the main models.
Platform-as-a-Service (PaaS)
PaaS offerings allow you to deploy applications without managing the underlying servers.
For ASP.NET, the prime example is Azure App Service – a fully managed web app hosting platform. You simply publish your Web App or API to App Service and Microsoft handles the VM infrastructure, OS patching, load balancing, and auto-scaling for you.
Azure App Service has built-in support for ASP.NET (both .NET Framework and .NET Core/5+), including easy deployment from Visual Studio, integration with Azure DevOps pipelines, and features like deployment slots (for staging), custom domain and SSL support, and auto-scale settings.
AWS offers a comparable PaaS in AWS Elastic Beanstalk, which can deploy .NET applications on AWS-managed IIS or Linux with .NET Core. Elastic Beanstalk simplifies provisioning of load-balanced EC2 instances and auto scaling for your app, with minimal manual configuration. Google Cloud’s closest equivalent is App Engine (particularly the App Engine Flexible Environment which can run containerized .NET Core apps). However, Google now often recommends Cloud Run (a container-based PaaS) as a simpler alternative for new projects.
When to use PaaS
PaaS is ideal for most web applications and standard enterprise APIs. It accelerates development by removing the OS and server maintenance.
For example, an internal business web app for a bank or manufacturer can run on Azure App Service and benefit from built-in high availability and scaling without a dedicated infrastructure team.
PaaS supports continuous deployment – developers can push updates via Git or CI pipeline and the platform deploys them.
The trade-off is slightly less control over the environment compared to VMs or containers, but for .NET apps the managed environment is usually well-optimized.
In Azure App Service, you can still configure .NET version, scalability rules, and use deployment slots for zero-downtime releases.
Similarly, AWS Elastic Beanstalk provides configuration for instance types and scaling policies, but handles the heavy lifting of provisioning.
PaaS is a productivity booster that covers most needs for web and API apps, unless you have custom OS dependencies or very specific networking needs.
Infrastructure-as-a-Service (IaaS)
With IaaS, you manage the virtual machines, networking, and OS yourself on the cloud. All three major clouds provide easy ways to create VMs (Azure Virtual Machines, Amazon EC2, Google Compute Engine) with Windows or Linux images for .NET.
In this model, you could deploy an ASP.NET app to a Windows Server VM (perhaps running IIS for a traditional .NET Framework app) or to a Linux VM with .NET Core runtime. IaaS offers maximum control – you configure the OS, you install any required software or dependent services, and you manage scaling (perhaps via manual provisioning or custom scripts). However, this also means more maintenance overhead: you must handle OS updates, scaling out/in, and ensuring high availability via load balancers, etc.
When to use IaaS
Pure IaaS is typically chosen for legacy applications or scenarios requiring custom server configurations that PaaS cannot support.
For example, if an enterprise has an older ASP.NET Framework app that relies on specific COM components or third-party software that must be installed on the server, it might need to run on a Windows VM in Azure or AWS.
You might also choose VMs if you need full control over networking (custom network appliances or domain controllers in the environment) or if you’re lifting-and-shifting a whole environment to cloud.
In modern cloud strategies, IaaS is often a stepping stone – many organizations first rehost their VMs on cloud, then gradually migrate to PaaS or containers for easier management.
While you can achieve great performance and security with IaaS, it requires cloud engineering expertise to set up auto-scaling groups, manage images, use infrastructure-as-code for consistency, etc. Whenever possible, cloud architects recommend PaaS over IaaS for web apps to reduce management burden, unless specific requirements dictate otherwise.
Container & Kubernetes Deployments
Containers can be seen as a middle ground between pure PaaS and raw VMs. Using Docker containers, you package the app and its environment, which guarantees consistency, and then you have choices in how to run those containers.
Managed Container Services
Both Azure and AWS offer simplified container hosting without needing a full Kubernetes setup. Azure App Service for Containers allows you to deploy a Docker image to the App Service platform – giving you the benefits of PaaS (easy deployment, scaling, monitoring) while letting you use a custom container ( if your app needs specific OS libraries or you just prefer Docker workflows).
AWS App Runner is a similar service that can directly run a web application from a container image or source code repo, automatically handling load balancing and scaling.
Google Cloud Run is another service in this category – it runs stateless containers and can scale them from zero to N based on traffic, effectively a serverless containers approach. These services are great for microservices or apps that need custom runtimes without the complexity of managing Kubernetes. They are often cheaper and simpler for small to medium workloads, and you pay only for resources used (Cloud Run even scales to zero on no traffic).
Kubernetes (AKS, EKS, GKE)
For large-scale microservices architectures or multi-container applications, a Kubernetes cluster offers the most flexibility.
Azure Kubernetes Service (AKS), Amazon Elastic Kubernetes Service (EKS), and Google Kubernetes Engine (GKE) are managed services where the cloud provider runs the Kubernetes control plane and you manage the worker nodes (or even those can be serverless in some cases).
With Kubernetes, you can run dozens or hundreds of containerized services (each could be an ASP.NET Web API, background processing service, etc.), and take advantage of advanced scheduling, service meshes, and custom configurations.
Kubernetes excels if your system is composed of many independent services that must be deployed and scaled independently – a common case in complex enterprise systems or SaaS platforms.
It also allows scenarios when some services are in .NET, others maybe Python or Java, etc. - all on one platform.
The trade-off is operational complexity: running Kubernetes requires cluster maintenance, monitoring of pods/nodes, and knowledge of container networking, which is why some enterprises only adopt it when needed.
When considering containers vs other models, ask how much control and flexibility you need.
If you simply want to “lift and shift” an on-premises multi-tier .NET app, Azure App Service or AWS Beanstalk might do it with minimal changes.
But if you plan a modern microservice design from the ground up, containers orchestrated by Kubernetes provide maximum flexibility (at the cost of more management). Many enterprise solutions use a mix: for example, an e-commerce SaaS might host its front-end Blazor server app on Azure App Service, use Azure Functions for some serverless tasks, and run an AKS cluster for background processing microservices that require fine-grained control.
Enterprise Use Cases and Examples
Internal Business Application (Manufacturing or Corporate ERP)
Many enterprises build internal web applications for employees – such as an inventory management system for a manufacturing company or an internal CRM/ERP module. In this scenario, security and integration with corporate systems are key.
An ASP.NET Core MVC app could be deployed on Azure App Service with a VNet integration to securely connect to on-premises databases (via VPN or ExpressRoute). Using Azure Active Directory for authentication allows single sign-on for employees (similarly, AWS IAM Identity Center or GCP Identity-Aware Proxy could be used if on those clouds).
For a manufacturing firm, the app might need to ingest data from IoT devices or factory systems – an architecture could include an IoT Hub (in Azure) or IoT Core (AWS) feeding data to a backend API.
The web app itself can use a tiered architecture: a Web API layer for data access and an MVC or Blazor front-end for the UI.
Autoscaling might not be heavily needed if usage is predictable (office hours), but the design should still handle spikes (end-of-month processing, etc.) by scaling out or up.
Given its internal, compliance is usually about data protection and perhaps SOX if it deals with financial records. All cloud resources for this app should likely reside in a specific region close to the corporate HQ or factory locations (for low latency).
For example, a European manufacturer might host in West Europe (Netherlands) region to ensure data stays in the EU. Backup/DR: They might use a secondary region in the EU for redundancy. Key best practices applied: use managed services like Azure SQL for the database (with Transparent Data Encryption on), App Insights for monitoring usage by employees, and infrastructure-as-code to be able to reproduce dev/test instances of the app easily.
Software-as-a-Service (SaaS) Platform (Healthcare SaaS)
Consider a startup or enterprise unit providing a SaaS product for healthcare providers – for example, a patient management system or telehealth platform delivered as a multi-tenant web application. Here, multi-tenancy and data isolation are critical.
An ASP.NET solution might use a single application instance serving multiple hospital customers, with row-level security per tenant in the database or separate databases per tenant. Cloud choices like Azure SQL elastic pools or AWS’s multi-tenant database patterns can help.
This SaaS could be built based on microservices architecture for different modules (appointments, billing, notifications) – implemented as ASP.NET Web APIs running in containers orchestrated by AKS or EKS, for example, to allow independent scaling of each module.
Front-end could be Blazor WebAssembly for a client, served from Azure Blob Storage/Azure CDN or AWS S3/CloudFront (since Blazor WASM is static files plus an API backend).
For a healthcare SaaS, regulatory compliance (HIPAA) is a top priority: you’d ensure all services used are HIPAA-eligible and sign BAAs with the cloud provider.
Data encryption and audit logging is mandatory – every access to patient data should be logged (using App Insights or AWS CloudTrail logs).
The SaaS might need to operate in multiple regions: US and EU versions of the service for respective clients, to address data residency concerns. You could deploy separate instances of the platform in Azure’s US regions and EU regions, or use a single global instance if legally allowed and implement data partitioning logic.
Auto-scaling is critical here because usage might vary widely as customers come on board. Using Azure Functions or AWS Lambda could be an effective way to handle certain workloads in the SaaS – processing medical images or PDFs asynchronously as a function, rather than tying up the web app.
CI/CD must be very rigorous for SaaS: with frequent updates, automated testing and blue-green deployments (perhaps using deployment slots or separate staging clusters) will ensure new releases don’t interrupt service. Another best practice is to implement tenant-specific encryption or keys if possible, so that each client’s data is isolated (Azure Key Vault can hold separate keys per tenant).
The cloud platform comparison factor here: Azure’s strong integration with enterprise logins might help if your SaaS allows customers to use their hospital’s Active Directory for SSO.
On the other hand, AWS’s emphasis on scalability and its reliable infrastructure might appeal for global reach. In practice, both Azure and AWS have large healthcare customers, and both have healthcare-specific offerings (Azure has the Healthcare API FastTrack, AWS has health AI services) that could enhance the SaaS.
The decision might come down to which cloud the development team is more adept with and where the majority of target customers are (some European healthcare organisations might prefer Azure due to data sovereignty assurances by EU-based Microsoft Cloud for Healthcare initiatives).
B2B API Service (Finance Trading API or Supply Chain Integration)
In this case, an enterprise offers an API that external business partners or clients integrate with. For example, a financial company might expose market data or trading operations via a RESTful API, or a manufacturing company might provide an API to suppliers for inventory updates. Reliability, performance, and security (especially authentication/authorization and rate limiting) are key here.
An ASP.NET Web API project is a natural fit to create the HTTP endpoints. This could be hosted on a scalable platform like Azure App Service or in AWS EKS if containerized. Often, an API gateway is used in front: Azure API Management or AWS API Gateway can provide a single entry point, with features like request throttling, API keys/OAuth support, and caching of frequent responses.
For a finance API, you might require client certificate authentication or JWT tokens issued via Azure AD or an IdentityServer – implement robust auth to ensure only authorized B2B clients access it.
Because this is external-facing, a Web Application Firewall and DDoS protection (which Azure and AWS include by default at some level) should be in place.
In terms of cloud specifics, if low latency is critical (electronic trading), you might choose regions carefully and possibly even specific services optimized for performance (AWS has placement groups, Azure has proximity placement, etc., though those matter more for internal latency).
A trading API could be latency-sensitive enough to consider an on-premises edge component, but assuming cloud-only, one might choose the cloud region closest to major financial hubs (New York or London, for example).
For manufacturing supply chain APIs, latency is less critical than reliability – partners must trust the API will be up.
Here multi-region active-active deployment might be warranted: run the API in two regions with a traffic manager that fails over in case one goes down, to achieve near 24/7 availability. Data behind the API (like inventory DB or market data store) would then need cross-region replication or a highly available cluster.
.NET’s performance with JSON serialization is very good, but you can further speed up responses with caching - frequently requested data can be cached in Redis so the API call returns quickly.
Monitoring for a B2B API must be very granular – use Application Insights or CloudWatch to track every request, and possibly create custom dashboards for API usage by each partner (this helps both in capacity planning and in showing value to partners).
In terms of compliance, a finance API may need to log extensively for audit (like MiFID II in EU for trade logs) – ensure those logs are stored securely (perhaps in an append-only storage or a database with write-once retention).
Manufacturing APIs might have less regulatory burden but could involve trade secrets, so ensuring no data leaks and using strong encryption is important.
When supporting external partners, also consider providing a sandbox environment – here cloud makes it easier: you can have a duplicate lower-tier deployment of the API for testing, isolated from prod but easily accessible to partners for integration testing.
Deployment automation helps spin up such environments on demand.
Finally, documentation is part of the deployment – using OpenAPI/Swagger with ASP.NET, you can expose interactive docs, and API Management services often provide developer portal capabilities out of the box.
How Belitsoft Can Help
Belitsoft is your cloud-native ASP.NET partner. We supply full-stack .NET architects, cloud engineers, QA specialists, and DevOps professionals as a blended team, so you get code, pipelines, and monitoring from a single partner. Our "startup squads" feature product-minded developers who code, test, and deploy — no hand-holding required.
We provide cross-functional .NET and DevOps teams that design, build, and operate secure, scalable applications. Whether you need to migrate a 20-year-old intranet portal, launch a healthcare SaaS platform, or deliver millisecond-latency trading APIs, Belitsoft brings the expertise to match your goals.
Top comments (0)