Understanding Azure Container Instances: Use Cases and Best Practices

Azure Container Instances is the fastest way to run a container in Microsoft Azure when you do not want to manage virtual machines or stand up a full orchestration layer. It is a serverless container hosting option built for short-lived jobs, bursty workloads, test runs, and simple services that need to start quickly and shut down cleanly. If you are deciding between ACI, AKS, and Azure App Service, the key question is operational depth: how much control do you really need?

Service	Azure Container Instances (ACI)
Best fit	Short-lived, bursty, or simple container workloads
Container support	Linux and Windows containers
Management model	Serverless container execution with minimal infrastructure overhead
Common integrations	Azure Container Registry, Azure Key Vault, Azure Storage, Azure Monitor
Deployment methods	Azure CLI, ARM/Bicep, Terraform, Azure Portal
Primary constraint	Not a full orchestration platform for complex microservices

Teams often reach for ACI when they want to test an image, run a one-off job, or expose a lightweight service without building a platform first. That makes it a strong fit for developers, DevOps engineers, and data teams that need containers to run now, not after a cluster is designed and tuned.

The practical rule is simple: Azure Container Instances is excellent when the workload is short-lived, bursty, or isolated. It is the wrong tool when you need service discovery, rolling upgrades, persistent platform governance, or a long-term home for many interdependent services.

What Azure Container Instances Are and How They Work

Azure Container Instances is a service that runs a container image for you without requiring you to provision or maintain the underlying host. You define the image, the resource requirements, the network exposure, and any storage or environment settings, and Azure launches the container directly. For many teams, that is the difference between deploying in minutes and spending half a day building supporting infrastructure.

The execution model is straightforward. You build an image, push it to a registry, and create an ACI container group that references that image. The group is the unit of deployment, which means one or more containers can share the same lifecycle, IP address, network namespace, and mounted storage. Microsoft documents this model in Microsoft Learn.

How container groups behave

A container group is the smallest deployable unit in ACI, and that matters because everything inside the group starts and stops together. If you deploy a single container, the group still exists as the management boundary. If you deploy multiple containers, they can communicate over localhost inside the same group, which is useful for sidecar patterns, log shippers, or tightly coupled helper processes.

This is also where teams sometimes overestimate ACI. A group is not a Kubernetes pod with the same ecosystem around it. It gives you shared lifecycle and shared networking, but not the scheduling, policy, and multi-service control plane that a full orchestrator provides. That distinction is why ACI is often a landing zone, not a permanent platform.

Linux and Windows container support

ACI supports both Linux and Windows Containers, which helps when you are migrating older workloads or have application dependencies tied to a specific OS stack. A Linux container is usually the simplest choice for modern cloud-native services, but Windows support matters when you are dealing with legacy .NET applications, IIS-based components, or migration paths that were built on Windows Server.

That flexibility is practical, not theoretical. If your organization has an application that runs in a Windows container today, ACI can be a stepping stone while the team evaluates longer-term hosting options. If you are using the CompTIA Cloud+ (CV0-004) course to build operational cloud skills, this is exactly the kind of architecture decision that shows up in real support and troubleshooting work.

Azure Container Instances gives you the speed of a container launch without asking you to become the owner of a cluster.

Core integrations that make ACI usable in production-like workflows

ACI becomes much more practical when you pair it with the rest of the Azure platform. A container image is usually stored in Container Registry, secrets come from Azure Key Vault, files land in Azure Storage, and logs flow into Azure Monitor. Those components are what move ACI from “demo container” to “repeatable workload.”

Keep the terminology clean when you design. Container image is the packaged application, CPU and memory allocation define the runtime resources, networking defines how traffic reaches the group, and public versus private exposure controls whether the service is reachable from the internet or only inside your Azure network. Those details determine both security and reliability.

• Fast startup helps with test runs and short jobs.
• Ephemeral execution reduces idle cost for workloads that do not need to stay online.
• Minimal management removes host patching and VM administration from the equation.
• Integration points make ACI more secure and repeatable when used with Azure services.

For the official service description and deployment guidance, Microsoft’s main documentation is the right reference point: Azure Container Instances documentation.

What Are the Best Use Cases for Azure Container Instances?

Azure Container Instances is strongest when the workload is short, focused, and easy to define. If you can describe the job in one sentence, ACI is often a good candidate. If the job needs a full platform, traffic management, and complex scaling logic, it usually belongs somewhere else.

Temporary APIs and proof-of-concept services

Teams often use ACI to stand up a temporary API for a demo, customer review, or internal validation. The benefit is speed: you can push a container, expose a port, and get a working endpoint without provisioning a VM or designing an orchestrator. This is especially useful when product teams need to test a concept before deciding whether it deserves a permanent home.

A practical example is a temporary image-processing service that receives a file, performs a transformation, and returns a result. That service may only need to exist for a sprint or two. ACI handles that scenario cleanly because the operational overhead stays low and the runtime can disappear when the work is done.

Batch processing and scheduled jobs

ACI works well for Batch Processing tasks such as report generation, nightly cleanup, and one-off data transformation. These workloads are often bursty by nature. They need compute for a short window, then they should stop. That is exactly the pattern where pay-for-what-you-use makes sense.

Think about a finance team that needs to generate PDF statements once a day, or a data engineer who runs a transformation pipeline after a source system closes. ACI can run the job, write output to storage, and exit. The workload is simple, predictable, and a poor fit for always-on infrastructure.

CI/CD-related workloads

Build agents, integration test runners, and disposable pipeline jobs are another strong fit. ACI lets you create a clean, isolated container for each run, which is useful when a pipeline must avoid host contamination or conflicting dependencies. You get a fresh environment each time, which improves repeatability.

That matters when you need a test runner for browser tests, security scans, or a custom validation step that should not live on a shared long-running agent. The container can start, execute the task, and terminate. There is no need to keep capacity idle between pipeline runs.

Event-driven and burst workloads

Webhooks, file processing, and short-lived event handlers are classic ACI use cases. A service can spin up quickly, process the request, and terminate or scale out manually for a narrow time window. For example, an inbound file-drop system can trigger a container to parse files, validate records, and write results to storage.

This pattern is appealing when workload volume spikes unpredictably. If the task is not meant to stay online all day, ACI avoids the overengineering that often comes with a platform built for permanent load.

Use ACI when the value is in execution speed, not in long-term service management.

Migration-friendly workloads

ACI is also useful for teams moving from on-premises systems to Azure in stages. A legacy containerized service may not be ready for a full Kubernetes migration, but it can often run in ACI while the team evaluates next steps. That gives you a simpler landing zone for modernization without forcing an immediate platform redesign.

The best fit is usually a workload that already runs in a container, has limited internal dependencies, and does not require complex availability behavior. In that case, ACI provides a reasonable bridge between traditional hosting and a more advanced cloud operating model.

Microsoft’s own cloud container guidance is helpful when you compare runtime models, and the broader container ecosystem guidance from Cloud Native Computing Foundation is also useful for understanding how lightweight container execution differs from orchestrated platforms.

When Is Azure Container Instances the Wrong Choice?

Azure Container Instances is the wrong choice when the workload needs orchestration, resilience patterns, or broad platform control. The service is intentionally lightweight, and that lightness becomes a problem once your application behaves like a distributed system rather than a single container job.

Complex orchestration needs

If you need service discovery, rolling deployments, horizontal pod-style scaling, or pod-level policy management, ACI is not the right foundation. That is where Kubernetes-based designs, including Azure Kubernetes Service (AKS), are stronger. AKS gives you scheduling, service abstractions, persistent control over many services, and better support for mature operational patterns.

A good rule: if the question sounds like “how do these ten services talk to each other, survive restarts, and roll forward safely?” you are probably not in ACI territory. ACI can host containers, but it does not replace a platform engineered for complex service orchestration.

Traditional web apps and platform-hosted websites

If your application is a conventional web app that mainly needs HTTP hosting, authentication integration, deployment slots, and app-centric workflows, Azure App Service may be a better fit. App Service is built for web workloads, while ACI is built for container execution. That distinction matters when the team wants platform features without managing the plumbing.

For example, a marketing website, a line-of-business portal, or a straightforward API with standard web hosting needs may be easier to operate in App Service than in ACI. The container image might still be useful, but the service model is different.

Stateful or long-running connected services

Long-running services that rely on persistent local state, heavy inter-service communication, or fine-grained lifecycle controls can become awkward in ACI. You can mount storage, but that does not make ACI a durable application platform. A service that behaves like a stateful cluster member needs a different model.

That is especially true for workloads that require advanced autoscaling, persistent cluster governance, or traffic shaping during rolling upgrades. ACI is intentionally simple, and that simplicity becomes a limitation when the workload is not simple anymore.

For broader container platform guidance, Microsoft’s Azure Architecture Center is a good reference, and NIST guidance on cloud computing roles and service models helps frame the operational tradeoffs: NIST Cloud Computing Program.

What Architecture and Deployment Decisions Matter Most?

Azure Container Instances can be simple to deploy and still be badly designed. The biggest mistakes usually come from container grouping, port exposure, sizing, image choice, and region selection. Those decisions affect security, performance, and cost more than people expect.

Single-container group or multi-container group?

Choose a single-container group when the workload is self-contained and one process owns the lifecycle. That is the default for most jobs. Choose a multi-container group when the containers truly need to live and die together, share localhost networking, or share storage and logging behavior.

A common multi-container pattern is a main application container plus a small helper container that handles logging, telemetry forwarding, or file preparation. If the containers are loosely coupled, separate them. If they depend on each other at startup and shutdown, group them.

Networking, ports, and exposure

Port exposure is not a checkbox to rush through. If you publish a port publicly, you are making the service reachable from the internet. That may be exactly what you want for a short-lived API, but it should be a deliberate choice, not a default. In private workloads, keep the service isolated and access it through controlled Azure networking paths.

DNS naming also matters because it influences reachability and troubleshooting. If a consumer system needs stable access, design the endpoint naming and network path early. Renaming and redeploying later is more annoying than doing it right the first time.

CPU, memory, and image size

Right-sizing CPU and memory is one of the fastest ways to improve ACI behavior. Too little memory can cause container crashes or slow startup. Too much memory wastes money and can mask poor application behavior. For CPU-heavy jobs, start with a realistic benchmark and increase only when you have evidence that the job is CPU-bound.

Image size matters too. Smaller images usually start faster, pull faster, and fail less often during deployment. Use minimal base images where possible, remove build tooling from runtime images, and avoid stuffing diagnostics or cache files into the image. Private image storage through Azure Container Registry is usually the safer choice for production-like use.

Region and deployment method

Choose the Azure region based on latency, compliance, and proximity to the services the container depends on. A job that reads from a storage account, calls a database, and writes artifacts should live close to those dependencies. Otherwise, you pay for avoidable latency and sometimes extra bandwidth.

Deployment method matters for repeatability. The Azure Portal is fine for one-time experiments, but Azure CLI, ARM/Bicep, and Terraform are better when you need version control and consistent rebuilds. Operational teams should treat ACI definitions like code, not click-ops.

1. Define the workload shape first: short job, API, or helper process.
2. Decide whether containers must share the same lifecycle.
3. Size CPU and memory from actual test runs, not guesses.
4. Keep images small and pull them from a private registry.
5. Pick the deployment method your team can repeat under pressure.

For container image hardening and base image guidance, official vendor documentation is the safest source, and container group documentation is the best place to verify the service behavior.

How Do You Secure Azure Container Instances?

Security for Azure Container Instances starts with the assumption that the container is not trusted just because it is in your subscription. You still need secret handling, network isolation, identity controls, and image hygiene. ACI reduces infrastructure work, but it does not reduce the need for basic container security discipline.

The first rule is simple: do not embed secrets in the image. That includes connection strings, API keys, passwords, certificates, and tokens. If a secret is baked into the image or stored in plain text environment variables, anyone with access to the image or deployment metadata can potentially retrieve it.

Use Key Vault and private registry delivery

Store secrets in Azure Key Vault and reference them securely during deployment or runtime. That keeps sensitive values outside the container image and gives you a cleaner rotation path. If the workload needs a database password today and a rotated one tomorrow, you should not have to rebuild the image for that change.

Use private image delivery through Azure Container Registry whenever possible. Public registries are fine for some open-source development scenarios, but production-like deployments should pull from controlled storage with access policies and audit trails. A private registry also helps reduce the risk of dependency drift and accidental exposure.

Reduce network exposure and limit privileges

Keep public exposure to the minimum required ports. If the service does not need inbound traffic from the internet, do not publish it. If it only needs internal access, place it on private networking paths and limit who can reach it.

Apply least privilege to both deployment and runtime access. The identity that deploys the container should only have the permissions needed to create, update, and read the required Azure resources. The workload itself should have only the access needed to complete its task. ACI is safer when identity boundaries are clear.

Harden the runtime assumptions

Review what the container assumes about its environment. Does it require outbound internet access? Does it depend on a writable path? Does it need a specific port? Does it fail if a certificate chain is missing? These are not trivial details. They are the reasons container jobs fail after an apparently successful deployment.

Also limit open ports and control outbound dependencies where possible. A container that can reach anything and everything is harder to secure and troubleshoot. If the workload is a file processor that only needs storage and a queue, then the network should reflect that narrow need.

A secure container is usually the result of removing unnecessary access, not adding more tools.

For identity and access guidance, Microsoft’s documentation is the right reference, and OWASP Docker Top 10 is useful for container-specific security risks. For broader cloud risk management, NIST SP 800 guidance remains a solid baseline: NIST SP 800 publications.

How Should You Handle Storage and Data in ACI?

Storage in Azure Container Instances needs careful planning because container-local files should be treated as temporary. ACI can restart, be redeployed, or disappear after a job finishes. If your application cannot tolerate that, it needs external storage, not wishful thinking.

Use ephemeral storage for scratch files, working directories, and transient state. Use attached persistent storage when the job must read or write data that survives the container lifecycle. The most common durable option is Azure File Shares, which can be mounted into the container group and shared by containers in that group.

When to use ephemeral storage

Ephemeral storage is a good fit for decompression, temporary conversion output, sorting, and intermediate files that exist only while the job is running. A report generator may create temporary CSV files before producing a PDF. A file converter may unpack assets into a working directory and then delete them after completion.

That pattern is efficient and often safer than writing data to durable storage too early. If the data is only useful during execution, keep it local and discard it afterward. That keeps the storage architecture simple.

When to use Azure File Shares

Use Azure File Shares when you need persistence across restarts, artifact retention, or a shared workspace for containers in the same group. This is common in processing pipelines where the input lands in storage, the container transforms it, and the output must remain available for later systems or users.

Mount the share securely and verify that the application can handle permission differences, path conventions, and startup timing. Many storage failures are actually application assumptions that were never tested against mounted volumes.

Design around restart and redeployment

The container should be able to start fresh and still operate correctly. That means configuration is externalized, input is fetched from durable storage or a queue, and output is written somewhere outside the container. If a redeployment wipes the local file system, the workload should still be recoverable.

For example, a document conversion pipeline might read source files from a share, process them, and write finished artifacts to another share or storage path. If the container dies halfway through, the input still exists, and the job can restart cleanly without corrupting the source data.

For Azure storage behavior, use the official guidance from Azure Storage documentation.

How Do You Monitor and Troubleshoot Azure Container Instances?

Monitoring Azure Container Instances matters because the service hides the underlying host. That is convenient until something fails and you have no server to log into. In ACI, observability is not optional; it is how you figure out whether the image is broken, the port is wrong, the memory is too low, or the identity lacks access.

Azure Monitor and Log Analytics are the primary tools for tracking container logs, runtime behavior, and failure patterns. Use them to capture application output, system events, and operational context that would normally live on a VM. Microsoft’s Azure Monitor documentation is the starting point for that setup.

What to track

Focus on container exit codes, restart patterns, resource consumption, startup time, and failure reasons. These signals tell you whether the issue is application logic, resource exhaustion, or deployment configuration. A container that exits with code 137, for example, often points to an out-of-memory condition or forced termination.

• Exit codes tell you how the container stopped.
• Restart frequency helps identify unstable workloads.
• CPU and memory trends show whether sizing is correct.
• Startup duration reveals image or dependency issues.
• Log output exposes app-level failures and missing settings.

Common troubleshooting failures

Image pull failures often come from registry permissions, wrong image tags, or network access problems. Port mismatches happen when the application listens on one port but the deployment exposes another. Configuration mistakes are common when environment values are missing or formatted incorrectly.

Permission issues usually show up when the container tries to read a storage mount, access a Key Vault secret, or call another Azure service without the right role assignment. The fastest path to diagnosis is to verify one dependency at a time rather than guessing at the whole stack.

Build a simple monitoring workflow

For development environments, start with console logs and a quick check of exit status. For staging, add retention in Log Analytics and alerts for failed runs. For production-like jobs, define alerts for unexpected restarts, repeated exits, and runtime spikes that could turn into cost problems.

A small workflow can go a long way: deploy the container, confirm it starts, watch logs for the first run, verify storage access, and then add alerts once the workload is stable. That sequence catches most issues before they become recurring incidents.

For cloud logging practices, Microsoft’s monitoring docs are the authoritative source, and industry container monitoring guidance can help frame common signal types, though Azure Monitor remains the native tool for ACI.

How Do You Optimize Performance and Cost in Azure Container Instances?

Performance and cost in Azure Container Instances are tightly linked because you pay for the resources you allocate and the time the container runs. That means oversized CPU and memory settings are not just inefficient; they are a direct cost issue. If a job runs for ten minutes with double the memory it needs, you pay for that mistake every single run.

The main cost drivers are CPU, memory, and runtime duration. Short-lived workloads tend to work well in ACI because they do not sit idle between tasks. That is the core economic advantage over always-on services.

Right-size the workload

Start with realistic testing. Run the container with a conservative CPU and memory allocation, watch how it behaves, and increase only when the workload shows real pressure. If the service spends most of its time waiting on I/O, extra CPU may not help much. If it performs heavy transformation, insufficient CPU will stretch runtime and increase the bill anyway.

Do not guess based on the smallest test file. Test normal and worst-case inputs. The resource profile that handles a 5 MB file may fail on a 500 MB file, and the “cheap” configuration becomes expensive when it repeatedly crashes and restarts.

Keep images small and runtime tight

Small images generally deploy faster because there is less to pull and unpack. They also reduce the chance of dependency clutter and old packages sneaking into production-like environments. Remove build tools, package caches, and unnecessary libraries from the final image.

Use ACI for on-demand execution instead of leaving a service idle. If a workload only runs for a few minutes every hour, a container that starts when needed is usually more economical than a service sitting ready all day.

Control waste and measure actual demand

Delete unused deployments when jobs are complete. Teams often leave test container groups around long after they have stopped providing value. That is easy money to save. Track actual runtime demand and compare it to your initial sizing assumptions.

For cost-aware cloud operations, the Azure Container Instances pricing page is the official reference for current billing details. For broader cloud economics, BLS computer and information technology occupations is useful for labor context, while Azure pricing determines the infrastructure side.

Azure Container Instances vs. AKS vs. Azure App Service

Azure Container Instances vs. AKS vs. Azure App Service comes down to operational complexity, scalability, and control. Each service solves a different problem, and the wrong choice usually shows up as either too much platform overhead or too little capability.

ACI is the fastest path for lightweight containers and temporary jobs. AKS is stronger for resilient multi-service container platforms. App Service is often the easiest choice for web applications that want container support without managing infrastructure directly.

How to think about the decision

If you need orchestration, choose AKS. If you need web hosting, choose App Service. If you need quick container execution, choose ACI. That simple framing is often enough to filter the first pass of architecture discussion.

Team maturity also matters. A team that already operates Kubernetes well can justify AKS for broader control. A team that mostly needs isolated containers for jobs and tests may get more value from ACI because the learning curve is lower and the maintenance burden is lighter.

Need orchestration	AKS is usually the right fit because it handles service coordination, scaling, and recovery patterns better.
Need web hosting	Azure App Service is usually the better option for standard web apps and APIs with app-centric workflows.
Need quick container execution	Azure Container Instances is the best fit when the workload is temporary, isolated, or bursty.

When to pick Azure Container Instances

Pick ACI when the workload is a job runner, disposable test environment, temporary API, or a simple container that must launch quickly. ACI shines when you want the result of containerization without the overhead of managing a cluster or a web hosting platform.

It is also a strong choice when your team wants to validate a containerized design before deciding whether it deserves a bigger platform. That makes it useful for proof-of-concept work and migration landing zones.

When to pick AKS or App Service

Pick AKS when the application is multi-service, highly available, or operationally mature enough to justify cluster management. Pick App Service when the goal is standard web delivery and the team wants built-in hosting features rather than container-level flexibility.

For decision support, Microsoft’s official documentation on Azure compute choices is helpful, and the AKS documentation provides the deeper platform comparison.

What Are the Most Common Deployment Mistakes?

Deployment mistakes in Azure Container Instances are usually boring, which is exactly why they happen so often. Teams overprovision resources, expose unnecessary ports, ship bloated images, or forget that ACI is not durable infrastructure. None of those mistakes are dramatic on their own, but together they create flaky deployments and avoidable cost.

Resource and image hygiene mistakes

Overprovisioning CPU and memory is a common mistake because it feels safe. It is safer to measure actual demand and increase only when needed. Shipping a bloated image is another common problem because it slows pulls, increases attack surface, and makes updates sluggish.

Use current base images, remove build artifacts from runtime images, and test startup behavior before you promote a deployment. A container that runs locally but takes too long to initialize in Azure is telling you something important about its dependency chain.

Configuration and storage mistakes

Missing environment values and incorrect ports are easy to miss in a quick test and painful in a live run. Storage mount failures are another recurring issue, especially when applications assume local file-system behavior that does not exist once storage is mounted from Azure File Shares.

Make sure the application can start with its real runtime settings, not just its defaults. A container image that only works when hand-held by the developer is not ready for repeatable deployment.

Operational mistakes

Ignoring logs is one of the fastest ways to make ACI feel unreliable. If a container exits and nobody looks at the logs, the team learns nothing. Treating ACI like durable infrastructure is just as bad. The service is meant for simple execution, not for hiding application-state responsibility.

Cleanup matters too. Delete test groups, old images, and unused deployments after validation. That keeps the environment tidy and reduces confusion when you return to the workload later.

1. Confirm the image starts locally with production-like settings.
2. Verify ports, environment values, and storage mounts.
3. Check registry access and identity permissions.
4. Run a small non-production deployment first.
5. Review logs, exit codes, and runtime duration before scaling use.

For deployment reliability concepts and operational governance, the NIST Cybersecurity Framework is useful for control thinking, even when the workload is a container job rather than a traditional server.

How Do You Build a Repeatable ACI Workflow?

A repeatable Azure Container Instances workflow starts with the image and ends with a clean deployment definition that your team can rerun without guessing. If the process only works when one person remembers the right settings, it is not a workflow. It is tribal knowledge.

Local build, registry push, and deployment

Start by building the container locally and validating that it runs with the same configuration you expect in Azure. Then push the image to Azure Container Registry and reference that exact tag in the ACI deployment. Tag discipline matters because “latest” is convenient and terrible for repeatability.

A lightweight pattern looks like this: build locally, test locally, push to registry, deploy to a small ACI group, verify logs, then expand only after the service behaves the way you expect. That sequence keeps failures small and easy to isolate.

Validate before you scale up

Use a small non-production container group first. Check that the container can reach its dependencies, write to storage, read secrets, and exit cleanly. If the workload is a job, make sure the exit code is meaningful and the output lands where operators expect it.

That validation step catches most of the mistakes that would otherwise show up during a production-like run. It also gives you a repeatable checklist for future deployments.

Document the operational contract

Document resource settings, secret handling, ports, storage mounts, and monitoring expectations. That documentation is not busywork. It is the difference between an ACI deployment that can be repeated by any engineer and one that depends on memory.

If the workload is part of a larger Azure container strategy, define where ACI stops and where AKS or App Service begins. Clear boundaries reduce platform sprawl and make future decisions easier.

For repeatable infrastructure patterns, ARM templates, Bicep, and Terraform are the main infrastructure-as-code options teams commonly standardize on.

Conclusion

Azure Container Instances is a practical serverless container service for workloads that need to run quickly and cleanly without the overhead of VM management or full orchestration. It is strongest for temporary services, burst jobs, CI/CD tasks, and migration-friendly workloads that do not justify a permanent platform.

Use ACI when simplicity and speed matter more than platform depth. Choose AKS when you need orchestration, resilience, and control across many services. Choose Azure App Service when your workload is really a web app that wants a web platform, not just a container runtime.

The best ACI deployments are deliberate. They use secure image delivery, externalized secrets, storage designed for restart, and monitoring that tells you what the container is actually doing. That discipline turns ACI from a convenience tool into a reliable operational option.

Pick Azure Container Instances when you need quick container execution with minimal ops; pick AKS when you need orchestration and advanced platform control.

Microsoft®, Azure®, Azure Container Instances, Azure Container Registry, Azure Key Vault, Azure Storage, Azure Monitor, Azure App Service, Azure Kubernetes Service, and Windows Containers are trademarks or registered trademarks of Microsoft Corporation. CompTIA® and Cloud+™ are trademarks of CompTIA, Inc.