Complete Amazon EC2 Launch Timeline: From Pending to Application Ready

Launching an Amazon EC2 instance is a sequence of events, not a single instant. AWS first creates and prepares the virtual machine, the instance enters pending, the operating system boots, launch automation runs, services start, and only then is the application ready to receive traffic.

This is Part 43 of the AWS Cloud Practitioner Study Notes. Part 42 explained the EC2 lifecycle states. This article focuses on what happens inside the launch sequence and why EC2 running does not necessarily mean application ready.

The complete launch timeline

Launch Instance
        ↓
AWS creates and prepares the VM
        ↓
Pending
        ↓
Operating system boots
        ↓
Cloud-init or EC2Launch runs
        ↓
User data executes, if provided
        ↓
systemd, Docker, or kubelet starts services
        ↓
EC2 state becomes Running
        ↓
Application passes its health check
        ↓
Load balancer sends traffic

The exact boot agents and order vary by AMI and operating system. Linux images commonly use cloud-init, while Windows AMIs use EC2Launch or related agents. User data and application startup are therefore operating-system and image dependent.

Phase 1: AWS creates the instance

When you launch an instance, AWS applies the launch configuration you selected. This can include:

• AMI and instance type
• VPC, subnet, and private IP configuration
• Security groups
• EBS root and data volumes
• An IAM instance profile
• User data
• Key pair or another connection method
• Public IPv4 configuration, if enabled

AWS then creates the virtual machine and prepares the underlying infrastructure. At this stage, your application is not running yet. The instance does not become reachable merely because the launch request was accepted.

Phase 2: Pending

The instance enters the pending state after launch. AWS is preparing the instance for boot, including the virtual machine, storage, networking, and selected configuration.

Launch request accepted
        ↓
Pending
        ↓
Virtual machine begins booting

While the instance is pending, it is not ready for normal SSH, RDP, application traffic, or reliable service testing. The pending state means that EC2 is preparing the instance; it does not mean that the operating system or application is ready.

Phase 3: Operating-system boot

The selected AMI boots its operating system. A simplified Linux sequence is:

Firmware or bootloader
        ↓
Linux kernel
        ↓
systemd and core services
        ↓
Network and operating-system configuration

Windows follows its own boot process. The important point is that EC2 infrastructure preparation and operating-system boot are different layers:

AWS infrastructure
→ creates and connects the VM

Operating system
→ starts the kernel and system services

An instance can be visible as running while the operating system is still finishing boot tasks or while the application is still starting.

Phase 4: Cloud-init or EC2Launch

Linux AMIs commonly use cloud-init to perform first-boot configuration. Depending on the distribution and AMI, cloud-init can help configure the hostname, SSH access, network settings, packages, and user data.

Windows AMIs use EC2Launch, EC2Launch v2, or other Windows-specific launch agents. These agents perform image and instance initialization and process Windows user data according to the configured execution rules.

Do not assume every AMI uses exactly the same agent or boot order. When troubleshooting, identify the operating system, AMI, launch agent, and relevant logs.

Phase 5: User data executes

User data is information or a script supplied when the instance is launched. It is commonly used for automated bootstrapping, such as installing packages, writing configuration files, or starting an application.

Example Linux user data:

#!/bin/bash
dnf install -y nginx
systemctl enable --now nginx

The launch sequence then looks like:

Linux boots
        ↓
Cloud-init reads user data
        ↓
Nginx is installed
        ↓
Nginx starts
        ↓
Application endpoint becomes available

By default, Linux user-data scripts and cloud-init directives run only during the first boot cycle. You can configure later execution, but do not assume that a normal reboot automatically reruns the original user data.

User data adds work to the boot process. A long package installation or container image download can therefore make the instance take longer to become application-ready even after EC2 reports running.

Phase 6: Application services start

If the application is already installed in the AMI, a service manager such as systemd may start it during boot. For example:

[Service]
ExecStart=/usr/local/bin/my-api
Restart=always

The application startup path may be:

systemd
        ↓
Nginx, Redis, or monitoring agent
        ↓
Go API or Java service
        ↓
Application listens on port 8080

The service can still be starting after the EC2 instance state becomes running. A process listening on a port also does not automatically mean that it is ready to serve real requests; it may still be loading configuration, connecting to a database, or warming caches.

Docker and Kubernetes examples

Docker on EC2

If Docker is installed in the AMI or by user data, the sequence might be:

Operating system boots
        ↓
Docker daemon starts
        ↓
Compose, systemd, or user data starts the container
        ↓
Container starts the application
        ↓
Application health check passes

Downloading a large image or waiting for a dependency can delay readiness.

EC2 as a Kubernetes node

If the EC2 instance is part of a Kubernetes cluster:

EC2 launches
        ↓
Linux boots
        ↓
kubelet starts
        ↓
Node joins the cluster
        ↓
Pods are scheduled
        ↓
Containers start
        ↓
Readiness probes pass

The node being running does not mean that its pods are ready. Kubernetes readiness probes and service routing provide a higher-level application readiness signal.

Where the Instance Metadata Service fits

The EC2 Instance Metadata Service is available through the local endpoint 169.254.169.254. It can provide instance information and temporary credentials for an attached IAM role.

During application startup, an AWS SDK may use the default credential provider chain:

Application starts
        ↓
AWS SDK needs credentials
        ↓
SDK queries IMDS when appropriate
        ↓
Temporary IAM-role credentials returned
        ↓
SDK calls S3, SQS, Secrets Manager, or another AWS service

Applications should normally use the AWS SDK rather than manually retrieving and managing credentials. Production EC2 instances should prefer IMDSv2 and least-privilege IAM roles.

Phase 7: EC2 reports Running

The running state means that the EC2 instance has started booting and is operating as a virtual machine. It is not an application health signal.

These are separate questions:

Is the virtual machine powered on?
→ EC2 instance state: Running

Is the operating system healthy?
→ EC2 status checks and operating-system monitoring

Is the application ready for users?
→ Application health check and dependency checks

AWS runs automated status checks on running instances. These checks help detect problems with the underlying system, the instance, and attached EBS volumes. A passing EC2 status check still does not guarantee that your application is functioning correctly.

Phase 8: Application readiness and traffic

In production, an Application Load Balancer normally performs a target health check before routing traffic to an EC2 target. A useful readiness endpoint should check the application and, where appropriate, critical dependencies.

EC2 state: Running
        ↓
Application process starts
        ↓
Application binds to port
        ↓
Health check succeeds
        ↓
ALB marks target healthy
        ↓
ALB routes user traffic

This prevents a newly launched instance from receiving production traffic while it is still installing packages, loading a large application, connecting to a database, or recovering cached state.

A complete production example

Imagine an Application Load Balancer routes requests to a Go API on EC2, and the API uploads files to S3:

Launch request
        ↓
EC2 pending
        ↓
EBS and networking prepared
        ↓
Linux boots
        ↓
cloud-init processes user data
        ↓
Go binary and configuration are loaded
        ↓
AWS SDK obtains IAM-role credentials through IMDS
        ↓
Go API listens on :8080
        ↓
ALB health check succeeds
        ↓
ALB routes traffic

A practical Go service might be installed as a systemd unit while its AWS SDK obtains credentials automatically. The service should expose a health endpoint that reflects real readiness rather than returning success before its required dependencies are available.

Troubleshooting a launch that is not ready

If EC2 shows running but the application is unavailable, check in layers:

1. Confirm EC2 instance and system status checks.
2. Confirm the operating system booted successfully.
3. Check cloud-init or EC2Launch logs.
4. Check whether user data completed or failed.
5. Check service-manager status, such as systemctl status.
6. Confirm the process is listening on the expected port.
7. Verify security-group and network ACL rules.
8. Confirm the application can reach required dependencies.
9. Test the health endpoint locally and through the load balancer.
10. Check the ALB target health reason if the target remains unhealthy.

Typical failure points include a package repository timeout, a user-data syntax error, an application crash, a missing IAM permission, an incorrect port, or a security-group rule that does not allow the load balancer to connect.

Common exam and interview questions

When does an EC2 instance first enter the pending state?

After launch, and again after starting a stopped instance.

Does running mean the application is ready?

No. It means the virtual machine has started. The application may still be booting or failing its health check.

When does user data usually run?

During the initial boot cycle by default. It can be configured for later boots, but that is not the default behavior.

What starts an application that is already installed in the AMI?

Usually the operating system’s service manager, such as systemd, or another configured startup mechanism.

How does an EC2 application access AWS services without hardcoded keys?

Use an attached IAM role and let the AWS SDK obtain temporary credentials through IMDS.

What should route traffic to a new instance only after the application is ready?

An appropriate load-balancer target health check, combined with an application readiness endpoint.

Final memory map

Launch
  ↓
Pending: AWS prepares the VM
  ↓
OS boot: kernel and system services start
  ↓
cloud-init / EC2Launch: image initialization
  ↓
User data: optional bootstrapping
  ↓
systemd / Docker / kubelet: service orchestration
  ↓
Running: VM is operational
  ↓
Health check passes: application is ready
  ↓
Traffic is allowed

The key principle is: EC2 Running is an infrastructure state; application readiness is a separate operational state.

Sources

• Launch an Amazon EC2 instance
• Run commands when you launch an EC2 instance with user data
• Amazon EC2 instance state changes
• Status checks for Amazon EC2 instances
• Use the Instance Metadata Service