# On-Demand Instance

> Source: Courseiva IT Certification Glossary — https://courseiva.com/glossary/on-demand-instance

## Quick definition

An On-Demand Instance is like renting a car for a few hours: you get a complete virtual computer in the cloud, you pay only for the time it is running, and you can stop anytime without penalty. You have full control over the software installed, but you are responsible for its security and configuration. It is the most flexible but often the most expensive way to run a cloud server if used continuously.

## Simple meaning

Imagine you need a powerful computer to run a big project, but you do not want to buy one. In the physical world, you might rent a computer from a shop by the hour. An On-Demand Instance works exactly like that, but in the cloud. Cloud providers like Amazon Web Services (AWS), Microsoft Azure, or Google Cloud have huge warehouses filled with powerful servers. They let you create a virtual computer, called an instance, on their servers. With an On-Demand Instance, you can start that virtual computer whenever you want, use it for as long as you need (even just a few minutes), and then shut it down. You get billed only for the time the instance was running, usually by the second or by the hour. This is great for unpredictable workloads, like testing a new application, running a short data analysis job, or handling a sudden spike in website traffic. You do not have to sign a contract or pay anything upfront. However, if you leave the instance running all day every day, the cost can add up quickly compared to other options like Reserved Instances, which offer discounts for committing to use them for one or three years. In the cloud, an On-Demand Instance also comes with a pre-configured operating system (like Windows or Linux), and you can choose how much virtual CPU, memory, and storage you want. Think of it like ordering a pizza with specific toppings: you pick the size and the ingredients, and it is ready in minutes. You pay for that specific pizza and eat it immediately. If you ordered a different pizza every day, it would be more expensive than buying a month's worth of pizza at a discounted rate. That is the trade-off: flexibility versus cost.

## Technical definition

An On-Demand Instance is a billing and provisioning model offered by cloud service providers (CSPs) such as AWS, Microsoft Azure, and Google Cloud Platform (GCP). In this model, a virtual machine (VM) is launched, used, and terminated on a per-second or per-hour basis with no upfront payment or long-term commitment. The instance runs on a hypervisor (like Xen or KVM) that abstracts the physical hardware of a host server, allocating virtual CPU cores, RAM, and sometimes dedicated GPU or FPGA resources from a shared resource pool. The operating system and any application software are deployed from a pre-configured machine image (AMI in AWS, custom image in Azure, or public image in GCP). The instance is given a private IP address on the cloud's virtual network, and optionally a public IP address for internet access. The user can connect via SSH (for Linux) or RDP (for Windows). Security groups or network security groups act as a virtual firewall to control inbound and outbound traffic. The billing meter runs continuously from the moment the instance state changes to 'running' until it is stopped or terminated. Even if the instance is idle with no CPU load, it still accrues charges because the resources are reserved for that instance. When the instance is stopped (not terminated), the compute charges stop but storage costs for the attached volumes (EBS on AWS, managed disks on Azure) continue. When terminated, the instance is destroyed and all ephemeral data is lost. This model is ideal for development and test environments, short-term batch processing, disaster recovery drills, and applications with highly variable or unknown traffic patterns. From a networking perspective, each instance is associated with a virtual network interface card (vNIC) that connects to a virtual local area network (VLAN) implemented in software. The cloud provider's orchestration layer uses APIs to handle provisioning, monitoring, and decommissioning. The hypervisor enforces resource isolation between different customers' instances, ensuring that one tenant cannot access another's memory or CPU cycles. The On-Demand model is the default pricing option and serves as the baseline against which other pricing models (Reserved Instances, Spot Instances, Savings Plans) are compared. IT professionals must understand that while On-Demand offers maximum flexibility, it is also the least cost-effective for steady-state workloads. Many enterprises combine On-Demand instances for burst capacity with Reserved Instances for baseline load. Cloud cost management tools, such as AWS Cost Explorer or Azure Cost Management, help track On-Demand spending and recommend ways to optimize.

## Real-life example

Think of On-Demand Instances like renting a storage unit for a short time. Suppose you are moving to a new apartment. Your new place is not ready yet, but you need to move out of your current place today. You have a lot of boxes that need to be stored for just one week. You go to a storage facility and rent a small room for exactly one week. You pay for that week, you put your boxes inside, and you have a lock and key (like having admin access). At the end of the week, you empty the room and return the key. You are not charged for the next week. You did not sign a year-long contract. You did not buy the room. You just paid for the time you used it. Now imagine you need to store boxes for a different project every few days. You could keep renting that same room on and off, but every time you start a new rental, you pay the daily rate. That is fine for short, unpredictable storage needs. But if you know you will need storage for a full year, the storage company offers a discount if you sign a long-term lease. That is a Reserved Instance. And sometimes, the storage company has empty rooms that they rent out at a huge discount, but they can ask you to leave with only a few minutes' notice if someone else reserves it. That is a Spot Instance. In this analogy, the On-Demand Instance is the most flexible option: you can get a room (a virtual server) whenever you need it, you pay only for the time you occupy it, and you can leave at any moment without penalty. The downside is the highest hourly rate. In the cloud world, this flexibility is vital for startups that do not know their future usage, for running temporary experiments, or for handling unexpected traffic surges on a website. For example, if your e-commerce site gets 10,000 visitors on a normal day but 100,000 on Black Friday, you can launch dozens of On-Demand Instances just for that one day and shut them down afterward, paying only for that single day of extra compute power.

## Why it matters

The On-Demand Instance model is a cornerstone of cloud computing because it fundamentally changes how organizations think about IT infrastructure. Before cloud, if you needed a new server, you had to purchase physical hardware, wait weeks for delivery, rack it, configure it, and install software. That was a huge upfront capital expense. With On-Demand Instances, you can provision a server in minutes with a few clicks or an API call. This agility allows businesses to experiment rapidly, scale applications up or down based on real-time demand, and avoid over-provisioning for peak loads. For developers, On-Demand Instances enable creating isolated test environments that can be spun up for a feature branch and destroyed when the feature is merged, dramatically reducing the cost of CI/CD pipelines. For small businesses, it means they can run enterprise-grade applications without buying expensive hardware. However, the ease of launching On-Demand Instances also introduces a risk: cost sprawl. It is very common for a team to launch an instance for a quick test, forget about it, and leave it running for months, accumulating charges. IT professionals must implement governance policies, such as setting maximum instance lifetimes, using automation to stop idle instances, and setting up budget alerts. Understanding On-Demand Instances is also essential for cloud architecture design. For example, architects often design auto-scaling groups that use On-Demand Instances as the base capacity during a scaling event, ensuring that new instances are always available when demand spikes. On-Demand Instances serve as the fallback option when Spot Instances are interrupted. In security contexts, each On-Demand Instance can be hardened individually, placed in private subnets, and have specific security groups applied, giving administrators granular control over the attack surface. Finally, the On-Demand model is central to cloud financial operations (FinOps), where teams track and allocate costs to specific projects or departments by tagging instances. Without understanding On-Demand Instances, cloud cost optimization is impossible.

## Why it matters in exams

On-Demand Instances are a fundamental concept tested across major cloud certification exams, including the AWS Certified Solutions Architect, AWS Developer, AWS SysOps Administrator, Microsoft Azure Administrator (AZ-104), Azure Solutions Architect (AZ-305), Google Associate Cloud Engineer, and Google Professional Cloud Architect. The term is categorized under 'Billing and Security' because it directly relates to cost management and the pay-as-you-go security model. In AWS exams, you are expected to know that On-Demand Instances have no upfront cost, no minimum term, and are billed per second (60-second minimum) for Linux instances and per hour for Windows. You must also understand how On-Demand compares to Reserved Instances, Spot Instances, and Savings Plans in terms of use cases and cost trade-offs. Typical exam questions present a scenario: a company has a workload with unpredictable usage that cannot be interrupted. The correct answer is often On-Demand Instances because they provide the highest availability and flexibility. Another scenario: a company wants to run a batch processing job that can tolerate interruptions and wants the lowest cost. Spot Instances would be the correct choice. The exam also tests the relationship between On-Demand Instances and EC2 instance states: running, stopped, and terminated. For example, a question might ask when billing stops. The answer is when the instance is stopped or terminated (actually, billing stops when the instance enters the 'stopped' or 'terminated' state, but EBS volume charges continue for stopped instances). In the AWS Certified Cloud Practitioner exam, you will be asked to identify the characteristics of On-Demand pricing from a list of facts. In Azure exams, the equivalent term is 'Pay-as-you-go VMs,' and you must understand that you pay per second for compute and per GB for storage. Google exams refer to 'Predefined machine types' with per-second billing. The exams also cover how On-Demand Instances integrate with auto-scaling, elastic load balancing, and monitoring services like CloudWatch or Azure Monitor. Security questions may involve ensuring that On-Demand Instances are launched with the correct IAM roles, placed in the appropriate VPC/subnet, and secured with security groups. You could be given a configuration where an On-Demand Instance is publicly accessible and asked to identify the security risk or recommend a fix. Mastering On-Demand Instances will help you answer cost optimization, scalability, and security questions correctly.

## How it appears in exam questions

Exam questions about On-Demand Instances typically fall into four categories: scenario-based selection, cost comparison, state transition knowledge, and security configuration. In scenario-based questions, you are given a business requirement and asked to choose the most suitable pricing model. For example, 'A startup is developing a new mobile app and expects highly variable traffic. They need the ability to scale up quickly and do not want to commit to any long-term contract. Which EC2 purchasing option should they use?' The correct answer is On-Demand Instances. Distractors might include Reserved Instances (which require commitment) or Spot Instances (which can be interrupted). Another question: 'A company runs a critical database that must be available 24/7 and cannot be interrupted. They want to minimize costs but have predictable usage. Which option should they choose?' This points to Reserved Instances, not On-Demand. Cost comparison questions often present a table or chart and ask you to calculate the savings of Reserved Instances over On-Demand. For instance, 'An On-Demand t3.large instance costs $0.0832 per hour. How much would it cost to run it for one full year (8,760 hours) under On-Demand, compared to a 1-year Reserved Instance with a 40% discount?' You need to compute and compare. State transition questions test your knowledge of when billing occurs. Example: 'An administrator stops an EC2 On-Demand Instance at 10:30 AM and then starts it again at 11:15 AM. The instance was running continuously from 9:00 AM. When does billing stop and restart?' The answer: billing stops at 10:30 AM (when it enters stopped state) and resumes at 11:15 AM. Some learners mistakenly think billing stops at the termination state only. Security configuration questions might ask: 'You launch an On-Demand Instance using a public AMI. After the instance is running, you discover it is accessible from the internet on port 22. Which AWS service would you use to restrict access to specific IP addresses?' The answer is a security group. Finally, you might see troubleshooting questions: 'An On-Demand Instance fails to launch because the instance limit for the region has been exceeded. What is the likely cause and solution?' The cause is a service limit for On-Demand Instances, and the solution is to request a limit increase or launch in a different region. These questions require you to understand not just what an On-Demand Instance is, but how it behaves in real AWS environments.

## Example scenario

Scenario: You work for a small e-commerce company that sells handmade crafts. Your website runs on a single server (an EC2 On-Demand Instance in AWS). Most of the year, the website gets around 200 visitors per day, which the single instance handles easily. However, during the holiday season in December, traffic spikes to 5,000 visitors per day for about two weeks. You need to handle this extra load without slowing down the site. 

Your boss says we should buy a second server for the holiday rush. You explain that instead of buying, you can launch additional On-Demand Instances just for December. You go to the AWS console and launch two more instances, each with the same configuration as your main server. You attach them to an Application Load Balancer, which distributes incoming traffic across all three instances. You pay for these two extra instances only for the two weeks they are running. When January arrives, you terminate the extra instances. The total cost for the extra capacity is a few hundred dollars, compared to thousands if you had purchased physical servers or committed to Reserved Instances for a full year. 

Now imagine one of the extra instances had a configuration mistake: it was launched with a public IP address and a security group that allowed SSH from anywhere (0.0.0.0/0). This is a security risk because attackers from the internet could try to break into that instance. To fix it, you modify the security group to allow SSH only from your office IP address. You also make sure that the instance is only in the public subnet if it needs to be accessed directly; otherwise, you place it in a private subnet. This scenario shows how On-Demand Instances give you the agility to scale up for short-term needs, but also require careful security planning. You also learn that you must tag instances (e.g., 'Environment: Holiday-Scaling') so that when December ends, you can easily identify and terminate the temporary instances without accidentally shutting down your main server.

## Common mistakes

- **Mistake:** Thinking that billing stops immediately when you stop an On-Demand Instance.
  - Why it is wrong: While compute charges do stop when the instance enters the 'stopped' state, you still incur charges for any attached storage volumes (like EBS) and any elastic IP addresses not associated with a running instance.
  - Fix: Remember: stopping stops compute billing, but storage and some network resources still cost money. To avoid all charges, you must terminate the instance (which deletes the instance and its root volume unless you have configured otherwise).
- **Mistake:** Believing that On-Demand Instances are always the cheapest option for any workload.
  - Why it is wrong: On-Demand is the most expensive per-hour pricing model. For workloads that run 24/7 for months or years, Reserved Instances or Savings Plans can offer significant discounts (40-70%) compared to On-Demand.
  - Fix: Analyze your usage patterns. If an instance runs for more than 25% of the month, consider Reserved Instances or a Savings Plan to reduce costs.
- **Mistake:** Assuming that all On-Demand Instances in the same region have the same price.
  - Why it is wrong: Pricing varies by instance type (e.g., t3.micro vs. c5.4xlarge) and by operating system (Linux is cheaper than Windows), and even by availability zone in some cases.
  - Fix: Always check the current pricing page for the specific instance type and OS in the region you are using. Use the AWS Pricing Calculator for accurate estimates.
- **Mistake:** Thinking that you can stop an On-Demand Instance and then start it again without losing any data.
  - Why it is wrong: Only data on attached EBS volumes (which are persistent block storage) survives a stop/start cycle. Any data stored on the instance store (ephemeral storage) is lost when the instance stops or terminates.
  - Fix: Always store critical data on EBS volumes or external databases, not on the instance's local ephemeral storage, if you plan to stop the instance.
- **Mistake:** Believing that On-Demand Instances are automatically highly available.
  - Why it is wrong: An On-Demand Instance runs in a single availability zone (AZ). If that AZ experiences an outage, your instance goes down. The pricing model does not guarantee high availability.
  - Fix: To achieve high availability, launch instances in multiple availability zones and use a load balancer or auto-scaling group. On-Demand is just the billing model, not an availability guarantee.

## Exam trap

{"trap":"The exam might state that an On-Demand Instance is being used for a production database that requires 99.99% uptime, and then ask which additional measure should be taken to ensure high availability.","why_learners_choose_it":"Learners may think that because On-Demand Instances are 'always available' from a provisioning perspective, they are also fault-tolerant. They might choose an answer like 'launch a larger instance type' or 'add more RAM,' ignoring the need for redundancy across AZs.","how_to_avoid_it":"Remember that On-Demand is a pricing model, not a reliability feature. For high availability, you need architectural patterns such as multi-AZ deployments, auto-scaling, and load balancing. Always read the scenario for uptime requirements before selecting an answer."}

## Commonly confused with

- **On-Demand Instance vs Reserved Instance:** A Reserved Instance requires a one-year or three-year commitment in exchange for a significant discount (up to 72%) compared to On-Demand. On-Demand has no commitment. Reserved Instances are best for steady-state, predictable workloads, while On-Demand is for unpredictable or short-term needs. (Example: If you run a web server 24/7 for a whole year, a Reserved Instance would be cheaper. If you only need a server for two weeks to run a simulation, On-Demand is better.)
- **On-Demand Instance vs Spot Instance:** A Spot Instance uses spare compute capacity and offers the largest discounts (up to 90%), but can be terminated (interrupted) with only a two-minute warning if AWS needs the capacity back. On-Demand Instances cannot be interrupted by AWS. Spot Instances are ideal for fault-tolerant or batch workloads, not for critical services. (Example: For rendering a 3D animation that can be paused and resumed, use Spot Instances. For your company's customer-facing website, use On-Demand Instances.)
- **On-Demand Instance vs Dedicated Host:** A Dedicated Host provides a physical server fully dedicated to your use, giving you visibility and control over the underlying hardware. On-Demand Instances run on shared physical hardware with other customers (multitenancy). Dedicated Hosts are used for compliance or licensing requirements, while On-Demand is the general-purpose option. (Example: If your software license is tied to a specific physical server, use a Dedicated Host. Otherwise, use On-Demand Instances for cost efficiency.)
- **On-Demand Instance vs Savings Plan:** A Savings Plan is a flexible pricing model where you commit to a certain amount of compute usage (measured in $/hour) for one or three years, and in return you get a discount on any instance type within a certain family. Unlike Reserved Instances, you can change instance types. On-Demand is the default pay-per-use without any commitment. (Example: If you know you will spend at least $100 per month on EC2, a Savings Plan would give you a lower rate than pure On-Demand, even if you change instance types.)

## Step-by-step breakdown

1. **Choose an AMI** — You start by selecting a machine image that contains the operating system and any pre-installed software. This can be a public image (like Amazon Linux, Ubuntu, Windows Server) or a custom image you created. The image determines the OS, kernel, and default configuration.
2. **Select an Instance Type** — You choose the size of the virtual server, defined by the family (e.g., general purpose t3, compute optimized c5) and size (e.g., micro, large, xlarge). Each type has a specific number of vCPUs, amount of RAM, and network performance. The instance type directly affects cost and performance.
3. **Configure Instance Details** — You specify the number of instances, the network (VPC), subnet, and whether to assign a public IP. You also set IAM role, shutdown behavior (stop or terminate), and monitoring options. You can add user data scripts to run on first boot.
4. **Add Storage** — You define the storage volumes. You can attach one or more Elastic Block Store (EBS) volumes for persistent storage, or use instance store volumes for temporary data. You also set the size, volume type (gp3, io1), and whether to delete the volume on termination.
5. **Configure Security Group** — You create or select a security group that acts as a virtual firewall. You define inbound rules (which IPs and ports can reach the instance) and outbound rules. This is critical for security. A mistake here could expose the instance to the internet.
6. **Review and Launch** — You review all settings, including the cost estimate per hour. You then launch the instance. AWS provisions it in a few seconds to minutes. You receive a key pair (for SSH/RDP access) if not using an existing one. The instance enters 'running' state and billing starts.
7. **Connect and Use** — You connect to the instance via SSH (Linux) or RDP (Windows) using its public or private IP. You install applications, configure services, and use it just like a physical server. You can stop, start, reboot, or terminate the instance from the console or CLI.

## Practical mini-lesson

Let's walk through a real-world practical use of On-Demand Instances: setting up a temporary development environment for a team project.

Suppose you are a developer working on a new feature for a web application. You need a server that mimics the production environment, but you only need it for a week while you test the feature. Instead of using the shared development server, you decide to spin up an On-Demand Instance in AWS. You choose an Amazon Linux 2 AMI because it is free and close to the production OS. You select a t3.medium instance type, which balances cost and performance. You configure it with 20 GB of gp3 EBS storage. You place it in the same VPC and subnet as the production environment, but in a test security group that only allows inbound SSH from your office IP address (port 22) and inbound HTTP from a load balancer for testing. You launch the instance. Within two minutes, it is running. You SSH into it, install Docker, clone the application repository, and run the application in a container. You test the new feature alongside other changes. The instance runs for five days. At the end of the week, you stop the instance to save compute costs, but you keep it around in case you need to test more. Two weeks later, the feature is approved and merged. You then terminate the instance. The total cost is around $15 for compute and $1 for storage (since you stopped it and only paid for storage). This is vastly cheaper and more convenient than buying new hardware or reserving a server. 

A critical practical aspect is tagging. You should tag the instance with 'Environment: Dev', 'Project: Feature-X', and 'Owner: YourName'. This helps in cost reporting and ensures you can find the instance later. Another practical consideration: set a CloudWatch alarm that notifies you if the instance has been running for more than 7 days, so you don't forget to terminate it and incur unnecessary costs. Finally, you should always consider security: never assign a public IP unless absolutely necessary. In this scenario, you could use a bastion host or a VPN to connect privately. If you must use a public IP, restrict inbound SSH to your specific IP. This practical lesson shows the agility of On-Demand Instances, but also the discipline required to manage them effectively.

## Memory tip

OD = Only pay during use, no Deposit.

## FAQ

**Can I convert an On-Demand Instance to a Reserved Instance later?**

Yes, you can purchase a Reserved Instance that covers the same instance type and region, and it will automatically apply to your running On-Demand Instance, reducing the cost. You don't need to stop or migrate the instance.

**Is there a difference in performance between On-Demand and Reserved Instances?**

No. The performance is identical. A Reserved Instance is simply a billing discount; the underlying hardware is the same. You get the same CPU, memory, and network performance.

**Do On-Demand Instances include any data transfer allowances?**

No. Data transfer out to the internet is charged separately at standard rates. Some providers include a small free tier (e.g., 100 GB per month for the first year), but after that, you pay per GB. Data transfer into the cloud is usually free.

**What happens if I exceed my On-Demand Instance limit?**

AWS sets an On-Demand Instance limit per region (default is 20 running instances, but this varies by instance type). If you try to launch more, you will get an error (InstanceLimitExceeded). You can request a limit increase via the AWS Support Center.

**Can I run an On-Demand Instance for less than one hour?**

Yes. For most instance types and operating systems, you are billed per second with a minimum of 60 seconds. So if you run an instance for 30 seconds, you are billed for 60 seconds. Some older instances or Windows may still use per-hour billing.

**Is my On-Demand Instance automatically backed up?**

Not by default. You must manually create snapshots of the attached EBS volumes or set up an automated backup plan using AWS Backup. The instance itself is not protected from accidental termination or failure.

## Summary

On-Demand Instances are the foundational building block of cloud computing elasticity. They allow you to provision virtual servers in minutes, pay only for the time you use them, and release them when done. This model is ideal for development, testing, short-term workloads, and handling unpredictable traffic spikes. However, the convenience comes at a cost: On-Demand is the most expensive per-hour pricing option, making it unsuitable for long-running, steady-state workloads without cost optimization. Understanding On-Demand Instances is critical for cloud certification exams, as questions frequently test your ability to choose the right pricing model based on workload characteristics, know the billing nuances (when charges start and stop), and apply proper security configurations. To succeed in exams, remember that On-Demand is about flexibility, not discount. Pair it with other models like Reserved Instances and Spot Instances to achieve both cost efficiency and performance. In practice, always tag your On-Demand Instances, set budget alerts, and implement lifecycle policies to avoid orphaned instances that waste money. Master this concept, and you will have a solid foundation for more advanced cloud topics like auto-scaling, load balancing, and cloud financial management.

---

Practice questions and the full interactive page: https://courseiva.com/glossary/on-demand-instance