An EC2 instance never goes alone. To launch it, you always need three pieces that always accompany it: an AMI (which disk it starts from), a key pair (how you enter securely), and a Security Group (what traffic you allow). Understanding these three is essential before launching your first server.

AMI stands for Amazon Machine Image. It is a template that contains the operating system and, optionally, pre-installed software, from which your instance is created.

Analogy: An AMI is like a cake mold or a factory photo of a computer. When you launch an instance, AWS "makes a copy" of that image and starts it up. If you launch 10 instances from the same AMI, all 10 start up identically.

What an AMI contains:

• The operating system (Amazon Linux, Ubuntu, Windows Server…).
• Initial configurations.
• Optionally, already installed software (a web server, your application, etc.).

Types of AMIs you will find:

Pro tip: Creating your own AMI with your software already installed makes launching new instances instant and repeatable. This is key for autoscaling (Chapter 13): instead of installing everything at each startup, you start from an image that's already ready. Tools like Packer (from HashiCorp, same as Terraform) are used to build AMIs automatically.

To enter your instance (via SSH on Linux or RDP on Windows) you need to authenticate. AWS uses key pairs based on public key cryptography.

A key pair has two parts:

• Public key: AWS stores it inside the instance. It's like a lock.
• Private key: you download it and only you have it. It's the key that opens that lock.

How it works when you connect:

1. You launch an instance and associate a key pair with it.
2. AWS places the public key inside.
3. To connect, you use your private key. The lock (public) only opens with that specific key (private).

⚠️ Critical security rule: AWS lets you download the private key only once when you create it. If you lose it, you cannot recover it and you will lose access to the instances that depend on it. Store it in a safe place and never upload it to a Git repository or share it via chat or email.

A Security Group is a virtual firewall that controls what network traffic can enter and leave your instance. It is your first and most important line of defense.

Analogy: It's like the bouncer at a nightclub with a list. Only those on the list are allowed in; everyone else is blocked.

Key features of Security Groups:

• They work with inbound rules and outbound rules.
• They only allow whitelists (allow): you define what is allowed; everything else is blocked by default.
• They are stateful: if you allow an incoming connection, the outgoing response is automatically allowed. You don't have to duplicate rules.

Example rules for a web server:

⚠️ Very common beginner mistake: opening port 22 (SSH) or 3389 (RDP) to 0.0.0.0/0 (all internet). That means anyone in the world can try to access your server. Always limit administrative access to your IP or a trusted network. It's one of the most exploited security flaws.

0.0.0.0/0 means "any IP address on the internet." It's fine for public web ports (80/443), but dangerous for admin ports.

When you launch an instance, you define all three at once:

• The AMI decides what the instance is based on.
• The key pair decides who can enter.
• The Security Group decides what network traffic is allowed.

• AMI: template (operating system + software) from which the instance is created. Creating your own AMIs makes deployment fast and repeatable.
• Key pair: public/private key pair to connect securely. The private key is downloaded only once; store it well and never share it.
• Security Group: virtual firewall with inbound/outbound rules, whitelist type, and stateful.
• Mistake to avoid: opening SSH (22) or RDP (3389) to the entire internet. Always limit it to your IP.

In the next subchapter we will see the lifecycle of an instance: the different states (running, stopped, terminated) and what each one implies, including for billing.