Launch a Secure Amazon EC2 Instance Step by Step

Launching EC2 is easy; launching an instance you can identify, reach, patch, secure, reproduce, and later remove safely takes a little more thought. The current console puts every important choice on one page, so this guide explains the decisions rather than tying you to buttons that AWS may rename.

The launch plan in one minute

1. Choose the AWS account, Region, workload purpose, owner, environment, and budget controls.

1. Select an official, supported AMI whose CPU architecture matches the instance type.

1. Choose capacity based on workload and current account eligibility—not an old tutorial’s SKU.

1. Place the instance in the intended VPC/subnet and expose only required ports to specific sources.

1. Select a connection method; prefer managed/keyless access where suitable, or protect an SSH private key rigorously.

1. Encrypt appropriately sized EBS volumes and define delete-on-termination behavior.

1. Attach a least-privilege IAM instance profile only when software needs AWS APIs.

1. Require IMDSv2, review user data, enable protection/monitoring as required, and launch.

1. Wait for both status checks, connect, patch, verify identity, and record cost/ownership.

What EC2 creates and connects

IAM principal launches
        │
        ▼
EC2 instance ← AMI + instance type + user data
   ├── ENI → subnet → route table → gateway / private path
   │          └── security groups (+ network ACL at subnet)
   ├── EBS root/data volumes → encryption + retention policy
   ├── IAM instance profile → temporary role credentials via IMDS
   ├── key pair / Instance Connect / Session Manager access path
   └── tags, monitoring, logs, alarms, backups and lifecycle controls

Why the surrounding resources matter

• Stopping an instance preserves attached EBS volumes by default; storage and other resources can continue accruing charges.

• Terminating an instance may delete volumes whose delete-on-termination flag is enabled while preserving others. Inspect before acting.

• A security group is stateful and can be shared by multiple resources; changing one rule can affect more than this server.

• An IAM role grants AWS API authority to software on the instance. It is not the Linux login identity.

• A public IP, route, and ingress rule are all required for direct internet reachability; any one missing can be intentional.

1. Choose account, Region and naming

Before opening the launch wizard, confirm the account and Region shown in the console header. EC2 resources, quotas, AMI IDs, key pairs, VPCs, and many pricing dimensions are regional. A correctly launched server in the wrong account or Region is still an operational incident.

• Use separate accounts/environments where your organization’s landing zone requires them.

• Create tags such as Name, Environment, Owner, Application, CostCenter, and DataClassification according to policy.

• Set an AWS Budget and billing alerts before experimentation; alarms inform you but do not automatically stop every charge.

• Record the planned deletion date for labs and use automation to detect unowned/stale resources.

2. Open the launch wizard

In the EC2 console choose Instances → Launch instances. Give the instance a descriptive name, which becomes a tag rather than the Linux hostname contract. For repeatable team or production launches, prefer a versioned launch template or infrastructure as code after validating the first design.

3. Select a trusted Amazon Linux 2023 AMI

• Choose Quick Start → Amazon Linux and select Amazon Linux 2023, or locate the AMI through AWS-owned public parameters/official documentation.

• Verify the publisher/owner is Amazon. A familiar image name is not sufficient evidence for a community AMI.

• Choose x86_64 or arm64 intentionally. Graviton instance families require arm64 software support; x86 instance families require x86_64 images.

• Prefer a current supported image, then patch after launch. Pin and test an approved AMI ID in production automation rather than silently accepting an untested “latest.”

• Minimal images contain fewer packages and may omit tools assumed by tutorials; choose based on the workload and hardening model.

Resolve the current official AMI ID with AWS CLI

$ aws ssm get-parameter \
  --name /aws/service/ami-amazon-linux-latest/al2023-ami-kernel-default-x86_64 \
  --query Parameter.Value \
  --output text \
  --region REGION

What this lookup guarantees—and what it does not

• Replace REGION; AMI IDs are regional even when the public parameter name is consistent.

• The AWS public parameter avoids copying a stale AMI ID from a blog post.

• The result is the current x86_64 AL2023 kernel-default image at lookup time; use the arm64 parameter for compatible Graviton instances.

• “Latest” improves freshness for exploration but can change between deployments. Resolve, record, scan, test, and deliberately promote an exact AMI for controlled environments.

• The CLI needs AWS credentials authorized to read the public parameter; it makes no EC2 resource changes.

4. Choose an instance type

Match vCPU architecture, memory, network/EBS throughput, accelerator/local-storage needs, and burst behavior to the workload. For a disposable lab, filter the wizard by the eligibility labels shown for your account. For production, measure and right-size rather than starting with the smallest selectable type.

• Burstable families use CPU-credit behavior; a low average can hide latency when credits or baseline capacity are insufficient.

• Instance-store data is ephemeral and not a substitute for EBS, object storage, or backups.

• Not every instance type exists in every Availability Zone, supports every AMI architecture, or fits current service quotas.

• Changing instance type generally requires a stop/start for EBS-backed instances and can change placement/public addressing. Plan availability.

• Savings Plans, Reserved Instances, Spot, On-Demand, and account credits solve different cost problems; none makes an unsuitable instance architecture correct.

5. Choose the login and management path

• Systems Manager Session Manager: can provide audited shell access without inbound SSH or a private key when the agent, IAM instance profile, and network path are correctly configured.

• EC2 Instance Connect: delivers short-lived SSH public keys for supported configurations; network reachability or an Instance Connect Endpoint is still required.

• Your own/EC2 key pair: the public key is placed on the instance at first boot and you safeguard the private key. AWS cannot recover a newly generated private key after download.

• No key pair: valid only when another tested access path is in place. Do not discover after launch that the instance is private and unmanageable.

6. Design network settings deliberately

• Select the correct VPC and subnet. A public subnet has a route to an internet gateway, but that alone does not assign a public address or permit ingress.

• Disable automatic public IPv4 for private workloads; use a load balancer, bastion/managed access, NAT for outbound needs, or VPC endpoints according to architecture.

• Create a workload-specific security group instead of reusing a permissive launch-wizard group.

• For SSH, allow TCP 22 only from a trusted IP/CIDR or security group—and only if SSH is your chosen path. Never use 0.0.0.0/0 or ::/0 for administration.

• For a public web server, allow 80/443 at the public load balancer or instance as designed. Database ports normally accept only application security groups, not the internet.

• Custom network ACLs are stateless and must permit return traffic; keep them coarse while security groups express resource-level stateful policy.

A minimal ingress policy model

Public ALB security group
  inbound 443 from approved clients or 0.0.0.0/0 + ::/0 for a public site
  outbound app-port to instance security group
 
Private app-instance security group
  inbound app-port from ALB security group only
  no inbound SSH when Session Manager is used
  outbound only as workload/update dependencies require
 
Direct lab instance (temporary)
  inbound 22 from YOUR_PUBLIC_IP/32 only
  remove rule and terminate resources after the lab

Security-group takeaways

• A security-group reference follows resources even when their IP addresses change and is preferable to broad private CIDRs for many tier-to-tier rules.

• IPv4 and IPv6 rules are separate; adding only 0.0.0.0/0 does not authorize IPv6.

• Outbound restriction requires an inventory of DNS, package repositories, AWS endpoints, logging, time, identity, and application destinations.

• The most permissive matching rule wins; a narrow rule does not override another group’s broader rule on the same ENI.

7. Configure EBS storage

• Size the root volume for OS, updates, logs, temporary work, and application needs; a full root filesystem can make a healthy instance unusable.

• Use EBS encryption with the AWS managed key or an approved customer-managed KMS key. Ensure operators, services, snapshots, and recovery accounts have the required key permissions.

• Choose volume type and provisioned performance from measured workload needs. Capacity, IOPS, and throughput constraints are related but distinct.

• Inspect Delete on termination for every volume. Enable it for disposable roots when appropriate; disable it for data only with an explicit retention/cleanup plan.

• EBS snapshots are incremental backups, not application-consistency magic. Quiesce stateful software or use a coordinated backup method and test restore.

8. Use an IAM role—not static AWS keys

If software on the instance needs S3, CloudWatch, Secrets Manager, or another AWS API, attach an IAM instance profile containing a least-privilege role. AWS SDKs can obtain rotating temporary credentials through the instance metadata service. Do not copy long-lived access keys into the AMI, filesystem, shell profile, or user data.

• Separate human launch permission from the instance role’s application permission.

• Scope actions, resources, conditions, and KMS access; avoid attaching administrator policies “until it works.”

• Changing a role or policy affects running software without rebuilding the AMI, so audit and monitor policy changes.

• Applications must support IMDSv2 token requests when metadata tokens are required.

9. Review advanced details

• Require IMDSv2 only (token required) unless a tested legacy dependency prevents it; plan and measure migration rather than leaving IMDSv1 indefinitely.

• Use metadata hop limit 2 for container environments when AWS guidance applies; otherwise minimize it for the actual network namespace design.

• Do not enable tags in instance metadata unless software needs them and tag contents are safe for processes allowed to query IMDS.

• Treat user data as retrievable instance configuration, not a secret store. Use it for idempotent bootstrapping and fetch secrets through an authorized runtime mechanism.

• Attach detailed monitoring, placement, tenancy, shutdown behavior, capacity reservation, and credit settings only after understanding cost and workload implications.

• Enable termination protection for manually managed critical instances, while remembering it is not a backup and interacts with automation/lifecycle tooling.

User-data example without embedded secrets

#!/bin/bash
set -euo pipefail
 
dnf upgrade -y
dnf install -y httpd
 
printf "%s\n" "EC2 bootstrap completed" > /var/www/html/index.html
systemctl enable --now httpd

Bootstrap takeaways

• Cloud-init normally executes user data as root, so sudo is unnecessary inside this script and every line has privileged impact.

• set -euo pipefail fails on command errors, unset variables, and failed pipeline elements; inspect cloud-init logs if bootstrapping stops.

• Package upgrades can lengthen first boot and introduce untested changes. Production teams often bake and validate patched AMIs instead.

• The script contains no passwords, tokens, or private keys. Retrieve secrets at runtime using an IAM role and a managed secrets service.

• User data usually runs on first launch, not every reboot. Design idempotency and lifecycle explicitly rather than assuming repeated execution.

10. Review, launch and wait for health

Use the Summary panel to recheck Region, AMI publisher and ID, architecture, instance type, subnet/public IP behavior, security rules, key/access path, IAM role, storage encryption/retention, metadata settings, and estimated cost. Choose Launch instance only after the design matches your intent.

$ aws ec2 describe-instance-status \
  --instance-ids INSTANCE_ID \
  --include-all-instances \
  --query "InstanceStatuses[0].{State:InstanceState.Name,System:SystemStatus.Status,Instance:InstanceStatus.Status}" \
  --output table \
  --region REGION

What the status checks cover

• Replace INSTANCE_ID and REGION; instance IDs are regional identifiers.

• System status checks cover AWS infrastructure hosting the instance; instance checks cover reachability of the guest operating system.

• Both checks passing does not prove your application, DNS, TLS, user data, or business health is correct. Add workload-level monitoring.

• The command is read-only but requires ec2:DescribeInstanceStatus; an empty result often means wrong Region/ID or insufficient visibility.

Verify the launched configuration

$ aws ec2 describe-instances \
  --instance-ids INSTANCE_ID \
  --query "Reservations[0].Instances[0].{State:State.Name,AMI:ImageId,Type:InstanceType,Subnet:SubnetId,PrivateIP:PrivateIpAddress,PublicIP:PublicIpAddress,Role:IamInstanceProfile.Arn,IMDSv2:MetadataOptions.HttpTokens,Root:RootDeviceName}" \
  --output table \
  --region REGION

Post-launch audit

• Compare returned values with the approved launch record; do not rely on the instance name tag alone.

• IMDSv2 should report required for a token-required design.

• A missing public IP is expected for private instances and an error only if the approved architecture requires direct public access.

• Inspect attached security groups and volumes separately; the compact query intentionally does not pretend to verify their rules, encryption, or retention.

• Tag, monitoring, backups, patching, log shipping, endpoint protection, and workload deployment still require verification after EC2 reports running.

Connect without weakening the design

• Wait for status checks, then use the planned Session Manager, Instance Connect, SSH, or organization access workflow.

• For AL2023, the default login is commonly ec2-user; custom AMIs and other distributions can use different users. Verify publisher documentation.

• Do not add a global SSH rule because connection fails. Diagnose route, address, source CIDR, security group, NACL, sshd, username, and key independently.

• After first access, verify /etc/os-release, patch state, time synchronization, storage, IMDSv2 compatibility, agent health, and user-data logs.

Stop, start, reboot and terminate are different

• Reboot: restarts the guest while generally keeping placement and addresses assigned to the instance.

• Stop/start: powers off/on an EBS-backed instance; compute billing stops while stopped, but EBS and some associated resources continue billing, and auto-assigned public IPv4 commonly changes.

• Hibernate: preserves RAM to the encrypted root volume only for supported configurations and still incurs storage charges.

• Terminate: permanently deletes the instance and volumes marked delete-on-termination. Other volumes, snapshots, Elastic IPs, load balancers, and related resources can remain.

• Before termination, identify data owners, backups, KMS access, DNS/load-balancer targets, protection settings, automation replacement behavior, and every retained billable resource.

Common launch failures

• Instance type unavailable/incompatible: check Region/AZ capacity, quota, AMI architecture, virtualization, ENA/Nitro requirements, and retry strategy.

• UnauthorizedOperation: use the encoded authorization-message workflow with an authorized administrator; inspect IAM, SCP, permission boundaries, tags, and required launch parameters.

• Pending too long/status check failed: inspect EC2 events, console output/screenshot, volume/KMS access, user data, kernel/boot, network configuration, and AWS service health.

• Cannot connect: confirm the intended access method, route, address/endpoint, source, security group, NACL, login user, key, agent/role, and guest service.

• User data did not work: inspect cloud-init logs, shell syntax, repository/network access, IMDS availability, and idempotency; never debug by echoing secrets.

• Unexpected bill: inventory running/stopped instances, EBS, snapshots, Elastic IPs, NAT gateways, load balancers, data transfer, monitoring, and resources in every Region.

Production handoff checklist

1. Capture owner, purpose, data classification, Region/AZ, AMI provenance, instance type, launch-template/IaC version, and expiry/review date.

1. Verify least-privilege IAM, IMDSv2, network exposure, EBS encryption/retention, KMS recovery access, and managed administrative access.

1. Patch and scan the image; ship system/application logs and metrics; configure alarms and incident routing.

1. Create tested backup/restore and replacement procedures—an instance being “running” is not a resilience strategy.

1. Use Auto Scaling/load balancing/multiple AZs where availability requirements demand them.

1. Record budget/cost attribution and automate cleanup or lifecycle replacement.

Related AWS guides

• After launch, follow safe SSH access to an AWS Linux instance when SSH is the approved path.

• Deploy a web service with Apache on Amazon Linux 2023 EC2.

• Review account setup in registering for AWS Free Tier and credits.

Primary references

• AWS documents the current EC2 launch instance wizard and account-dependent eligibility behavior.

• The EC2 launch parameter reference explains AMI, type, key, network, storage, and advanced settings.

• AWS’s IMDS options guide documents token requirements and precedence.

• The EC2 key-pair guide describes public/private key handling and first-boot placement.