Introduction

On-Demand Instances in Amazon EC2 let you launch virtual machines without long-term commitment. They are the default choice when you need capacity quickly, want predictable pay-as-you-go billing, or are still experimenting with instance sizing. Creating one is straightforward, but getting the networking, IAM, and shutdown behavior right matters more than clicking the launch button.

What an On-Demand Instance Actually Is

An On-Demand Instance is a normal EC2 instance billed according to usage rather than through a reserved pricing agreement. In practical terms, you choose an Amazon Machine Image, an instance type, storage, network placement, and access settings, then launch it.

Typical reasons to use On-Demand capacity include:

• development and testing
• burst workloads
• temporary batch jobs
• early production environments before usage is stable

If the workload becomes steady and predictable, you can later compare other pricing models. But creation and day-to-day operation still start with the same EC2 launch process.

Launching From the AWS Console

In the AWS console, the workflow is usually:

1. open the EC2 service
2. choose Launch instance
3. select an image such as Amazon Linux or Ubuntu
4. choose an instance type such as t3.micro
5. pick a key pair or decide to use Systems Manager
6. configure network, subnet, and security group rules
7. review storage and launch

The purchase model is effectively On-Demand unless you explicitly use another capacity or pricing path. For new users, the main operational decisions are not about the pricing checkbox. They are about access and security.

For example, a Linux instance that you plan to SSH into usually needs inbound port 22 from a trusted IP range, not from the whole internet.

Launching With the AWS CLI

The CLI is often better for repeatable infrastructure steps or documentation. A minimal launch command looks like this:

1aws ec2 run-instances \
2  --image-id ami-0123456789abcdef0 \
3  --instance-type t3.micro \
4  --count 1 \
5  --key-name my-keypair \
6  --security-group-ids sg-0123456789abcdef0 \
7  --subnet-id subnet-0123456789abcdef0

This creates one On-Demand EC2 instance using the specified AMI, key pair, security group, and subnet.

You can make the command more useful by adding tags:

1aws ec2 run-instances \
2  --image-id ami-0123456789abcdef0 \
3  --instance-type t3.micro \
4  --count 1 \
5  --key-name my-keypair \
6  --security-group-ids sg-0123456789abcdef0 \
7  --subnet-id subnet-0123456789abcdef0 \
8  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=web-dev-1}]'

Tags make cost tracking, cleanup, and automation much easier later.

Access and IAM Matter Immediately

A new instance is only useful if you can manage it safely. The two big decisions are:

• how you log in
• what AWS permissions the instance itself gets

For human access, SSH key pairs are common for Linux, while Systems Manager Session Manager avoids opening SSH at all. For application access to AWS services, attach an IAM role to the instance instead of hardcoding credentials.

That role-based pattern is important if the instance needs S3, CloudWatch, Secrets Manager, or other AWS APIs.

Stopping Versus Terminating

Many cost surprises come from misunderstanding lifecycle actions. Stopping an instance shuts down compute billing for many instance families, but attached EBS storage can still cost money. Terminating an instance destroys it, and depending on your volume settings, may also delete the root volume.

That means cleanup should be deliberate. If the instance is truly temporary, plan the termination path in advance.

A Good Minimal Practice Set

Even for a quick On-Demand launch, do these things:

• use a restrictive security group
• attach an IAM role instead of storing AWS keys
• add a Name tag and ownership tags
• choose the right region and subnet intentionally
• document how the instance will be stopped or terminated

Those habits matter more than the mechanics of opening the EC2 launch wizard.

Common Pitfalls

The most common mistake is leaving SSH open to 0.0.0.0/0 when only a small trusted IP range needs access.

Another mistake is launching an instance successfully but forgetting IAM permissions for the workload. The operating system is running, but the application cannot access S3, secrets, or logs.

Developers also often stop an instance and assume all charges are gone. EBS volumes, Elastic IPs, and other attached resources may still cost money.

Finally, do not treat instance launch as separate from cleanup. On-Demand is flexible partly because you can remove unused instances quickly, but only if you actually terminate what you no longer need.

Summary

• On-Demand EC2 instances are the default pay-as-you-go way to launch compute capacity.
• You can create them from the AWS console or with aws ec2 run-instances.
• Secure access, IAM roles, and tagging matter as much as the launch itself.
• Restrictive security groups are safer than broad inbound rules.
• Understand the difference between stopping and terminating so you control cost.