Instance families and why they exist. AWS doesn’t sell “one size of computer” — it sells families, each optimized for a different resource ratio. A family name like m5, c6i, or r6g encodes three things: the letter (or letters) tells you the optimization target — m for balanced general purpose, c for compute-optimized (more CPU per dollar), r for memory-optimized (more RAM per dollar), i or d for storage-optimized (fast local disk), and g/gr for GPU-accelerated; the generation number tells you how recent the underlying hardware is; and an optional suffix like g (Graviton/ARM processor), n (enhanced networking), or d (local NVMe storage included) tells you about a specific hardware variant layered onto that family. Choosing the right family is fundamentally a question of which resource your workload actually bottlenecks on — a video transcoding job wants compute-optimized instances, an in-memory cache wants memory-optimized instances, and a typical web application server usually lands comfortably on general purpose.

Instance size as a multiplier, not a separate product. Within a family, sizes like large, xlarge, and 4xlarge scale vCPU count and memory roughly linearly and predictably — a 4xlarge generally has exactly double the vCPUs and memory of a 2xlarge in the same family. This predictability matters operationally: it means capacity planning and cost modeling can treat size changes as simple multiplication rather than researching an entirely new product each time a workload needs to grow.

Purchasing models, beyond just “On-Demand.” On-Demand pricing — paying per second with no commitment — is the default, but it is rarely the cheapest option for a stable production workload. Reserved Instances and Savings Plans trade a one- or three-year spending commitment for a substantial discount. Spot Instances let you bid for AWS’s genuinely spare capacity at discounts that can reach 90%, in exchange for accepting that AWS can reclaim that capacity with only a two-minute warning when it’s needed elsewhere. Dedicated Hosts and Dedicated Instances provide physical isolation for compliance-driven workloads that cannot share underlying hardware with other AWS customers. An intermediate EC2 design almost always blends more than one of these models across a single fleet rather than picking just one for everything.

Graviton and the rise of ARM in the instance catalog. Alongside the traditional x86-based instance types, AWS also offers Graviton instances — identified by a trailing g in the family name, such as m7g or c7g — built on AWS’s own custom-designed ARM processors rather than the x86 architecture most engineers are historically used to. Graviton instances typically offer noticeably better price-performance than their x86 equivalents for workloads that don’t depend on x86-specific binaries, since AWS controls the entire chip design rather than purchasing off-the-shelf processors from a third party. The intermediate-level catch is compatibility: any software with compiled, architecture-specific dependencies needs to be rebuilt for ARM before it can run correctly on a Graviton instance, which is why migration to Graviton is usually treated as a deliberate, tested initiative rather than a blind drop-in swap.

Generations matter more than most people assume. AWS periodically releases new hardware generations within the same family — moving from m5 to m6i to m7i, for instance — each typically offering better price-performance than the last, without requiring any change to the family’s fundamental optimization target. A common intermediate-level cost-optimization exercise is simply auditing a fleet for instances still running on an older generation and evaluating whether a newer-generation equivalent would deliver the same or better performance at a lower hourly cost, entirely independent of any purchasing-model changes.

Network-optimized suffixes within a family. Some family names carry an additional letter tied specifically to networking hardware rather than compute or memory — an n suffix, for example, generally signals a variant tuned for higher network bandwidth relative to its otherwise-identical sibling. These distinctions matter most for workloads that are genuinely network-bound rather than CPU- or memory-bound, such as a fleet of proxy servers or a distributed cache cluster that spends most of its time moving data between nodes rather than computing on it locally.

Why “intermediate” Core Concepts skip the basics deliberately. A genuinely introductory EC2 explanation would spend considerable time on what a virtual machine is and how to launch one through the console — useful groundwork, but not what separates a competent intermediate engineer from a beginner. What actually differentiates intermediate understanding is knowing which of the roughly 750 instance type and size combinations fits a given workload’s real resource profile, understanding that purchasing models are not mutually exclusive choices but ingredients meant to be blended, and recognizing that a “server” on EC2 is really a composition of several independently managed AWS resources rather than one indivisible unit — the exact foundation the remaining chapters build on.

Every running EC2 instance is composed of several distinct AWS-managed components working together, even though they appear to the user as one seamless “server.” The Amazon Machine Image (AMI) is the template — a snapshot of an operating system plus any pre-installed software — that an instance is launched from. The instance itself is the running compute unit, defined by its type (family plus size) and its current state. An Elastic Network Interface (ENI) is the virtual network card attached to the instance, carrying its private IP address, security group associations, and MAC address; an instance can have more than one ENI, which matters for advanced networking setups like dual-homed appliances. Elastic Block Store (EBS) volumes are the persistent, network-attached disks that survive independently of the instance’s own lifecycle. And the instance metadata service is a special, non-routable endpoint (accessible only from inside the instance) that exposes information about the instance to itself, such as its instance ID, IAM role credentials, and user data script.

These components are deliberately decoupled from one another. An EBS volume can be detached from a terminated instance and reattached to a brand-new one. An ENI can, in some configurations, be moved between instances to fail traffic over quickly. This decoupling is precisely what makes EC2 flexible at an architectural level — the “server” you interact with is really a composition of independently managed AWS resources, not a single indivisible physical machine.

Hibernation, a lesser-known middle ground. Beyond the standard stop and terminate actions, certain instance types and AMIs support hibernation, which preserves the entire contents of the instance’s RAM to its root EBS volume before shutting the instance down. On the next start, the instance resumes exactly where it left off, including in-memory application state, rather than going through a full cold boot. This is particularly valuable for workloads with expensive warm-up periods — an in-memory cache that takes many minutes to repopulate, for example — where a full stop-and-restart cycle would otherwise cost significant time.

Enhanced networking hardware, briefly. Beyond the standard Elastic Network Adapter mentioned earlier, certain instance types support the Elastic Fabric Adapter (EFA), a specialized network interface designed for tightly coupled, high-performance computing and machine learning training workloads that depend on extremely low inter-node latency. EFA bypasses much of the traditional operating system networking stack entirely, which is why it’s reserved for a narrower set of specialized instance types rather than being available universally.

Older generations of EC2 instances ran on a traditional software hypervisor — a layer of software on the physical host responsible for carving up CPU, memory, networking, and storage among multiple customers’ virtual machines sharing that hardware. That software hypervisor consumed a meaningful slice of the host’s own CPU and memory just to do its job, and represented a broad software attack surface. The Nitro System is AWS’s replacement architecture: it moves almost all of that virtualization overhead — networking, storage I/O, and security enforcement — off the main CPU and onto dedicated, purpose-built hardware cards plugged directly into the server. What remains as software on the host is a minimal, stripped-down hypervisor whose only real job is allocating CPU and memory to instances.

The practical effect for an intermediate engineer is threefold. First, performance improves, because virtually all of the host’s CPU and memory capacity is now available to actual customer workloads rather than being consumed by hypervisor overhead. Second, networking and storage throughput increase substantially, since I/O is handled by dedicated hardware rather than competing with your workload for the same CPU cycles. Third, security posture improves, because even AWS operators cannot directly access the memory of a running instance — the Nitro Security Chip enforces this isolation at the hardware level, independent of the software hypervisor.

Instance store versus EBS, understood through Nitro. Some instance types include “instance store” volumes — physically attached NVMe storage on the same host as the instance, delivering extremely low latency, but with one critical caveat: instance store data is permanently lost the moment the instance stops or terminates, because it lives on that specific physical server rather than on the network like EBS does. This makes instance store an excellent fit for ephemeral, replaceable data — a local cache, temporary scratch space during a batch job — and a poor fit for anything that needs to survive an instance replacement.

Nitro Enclaves, an isolated compute environment within an instance. Building further on the Nitro System’s hardware-enforced isolation, Nitro Enclaves let a running instance carve out a fully isolated, hardened compute environment with no persistent storage, no interactive access, and no networking beyond a private, local communication channel back to its parent instance. This isolated environment is used to process highly sensitive data — cryptographic key material, personally identifiable information for validation — in a way that keeps it inaccessible even to the parent instance’s own operating system, administrators, or any process running outside the enclave itself. Conceptually, an enclave is a locked room inside an already-secure building, reachable only through one narrow, monitored doorway.

How this compares to a traditional software hypervisor. On a traditional hypervisor architecture, the host operating system itself typically has some level of visibility or access into guest virtual machine memory, and a compromised hypervisor represents a single point of failure for every tenant sharing that hardware. The Nitro System’s hardware-based isolation means that even AWS’s own operators cannot inspect a running instance’s memory, a guarantee that would be architecturally much harder to make with a purely software-based virtualization layer, and one of the main reasons Nitro is frequently cited in AWS compliance and security documentation as a foundational control.

stateDiagram-v2
    [*] --> Pending
    Pending --> Running: Boot completes
    Running --> Stopping: Stop requested
    Stopping --> Stopped: Shutdown complete
    Stopped --> Pending: Start requested
    Running --> ShuttingDown: Terminate requested
    Stopped --> ShuttingDown: Terminate requested
    ShuttingDown --> Terminated
    Terminated --> [*]
        

The distinction between Stopped and Terminated is one of the most operationally important intermediate concepts in EC2. A stopped instance retains its root EBS volume, its private configuration, and (for EBS-backed instances) its instance ID; it can be restarted later, though it will typically receive a new public IP address unless an Elastic IP has been explicitly attached. A terminated instance is gone permanently — its root volume is deleted by default (unless you explicitly configure “delete on termination” to false), and the instance ID can never be reused. Billing also differs sharply: a stopped instance stops accumulating compute charges immediately, though its attached EBS volumes continue to incur storage charges until they too are deleted.

Instance store-backed instances behave differently. An instance whose root volume lives on instance store rather than EBS cannot be stopped at all — only terminated — because there is no persistent, network-attached place to preserve its state while paused. This is a subtle but important distinction when choosing between AMI types at launch time.

User data and the first-boot customization window. When an instance launches, it can be given a “user data” script — a block of shell commands (or, on Windows, PowerShell) that runs automatically on first boot, before the instance is considered fully ready. This is the standard mechanism for bootstrapping a freshly launched instance: installing an application runtime, pulling configuration from a parameter store, registering with a service discovery system, and so on, all without needing to bake every possible variation into a custom AMI ahead of time.

What billing actually tracks across each state. A running instance accrues per-second compute charges continuously. The moment it transitions to stopping and then stopped, compute charges cease immediately, though any attached EBS volumes continue billing for their allocated storage regardless of the instance’s own state, since storage and compute are billed as genuinely separate line items. A terminated instance stops all compute charges permanently, and any EBS volumes configured to delete on termination stop billing as well; volumes explicitly preserved after termination continue to accrue storage charges until someone deletes them directly. This separation is a frequent source of unexpected line items on a monthly bill — a team that diligently stops unused instances every night can still be surprised by ongoing charges for volumes attached to instances that were terminated, not merely stopped, weeks earlier.

Every EC2 instance launches into a subnet inside a Virtual Private Cloud (VPC) — an isolated, customer-defined network space. Whether that instance can reach the public internet depends on the subnet’s route table: a public subnet has a route to an Internet Gateway, while a private subnet does not, and instead typically routes outbound traffic through a NAT Gateway if outbound internet access is needed without allowing unsolicited inbound connections. This public/private split is the foundational building block of nearly every production VPC design: front-facing load balancers and bastion hosts live in public subnets, while application servers and databases live in private subnets, invisible to the internet directly.

flowchart TB
    Internet(["Internet"]) --> IGW["Internet Gateway"]
    IGW --> PubSub["Public Subnet"]
    PubSub --> ALB["Application Load Balancer"]
    ALB --> PrivSub["Private Subnet"]
    PrivSub --> EC2A["EC2 Instance A
ENI + Security Group"]
    PrivSub --> EC2B["EC2 Instance B
ENI + Security Group"]
    PrivSub --> NAT["NAT Gateway"]
    NAT --> IGW
        

Security Groups versus Network ACLs. These are the two firewall layers protecting an instance, and confusing them is one of the most common intermediate-level mistakes. A Security Group operates at the instance’s ENI level, is stateful (meaning a response to an allowed inbound request is automatically allowed back out, with no separate outbound rule needed), and only supports “allow” rules — there is no way to explicitly deny traffic with a security group. A Network ACL operates at the subnet level, is stateless (meaning inbound and outbound rules must both be defined explicitly, since return traffic is not automatically permitted), and supports both “allow” and explicit “deny” rules, evaluated in numbered order. In practice, most teams do the bulk of their access control with security groups and use NACLs sparingly, mainly for blocking specific known-bad IP ranges at the subnet boundary.

Elastic IPs and public IP behavior. By default, a public IP address assigned to an instance is released the moment the instance stops and a new one is assigned on restart. An Elastic IP is a static public IP address you allocate to your account and explicitly associate with an instance or network interface, which remains fixed across stop/start cycles — essential for any system where external DNS records or firewall allowlists depend on a stable, unchanging IP address.

Enhanced networking and placement groups. Modern instance types support Elastic Network Adapter (ENA), delivering higher packet-per-second throughput and lower jitter than older virtualized networking. For workloads sensitive to inter-instance latency — distributed databases, high-performance computing clusters — a cluster placement group packs instances physically close together on the same underlying network fabric to minimize latency, at the cost of a higher chance that a single hardware failure affects multiple instances at once. A spread placement group does the opposite, deliberately placing a small number of critical instances on distinct underlying hardware to minimize the chance that a single failure takes more than one of them down simultaneously.

VPC Endpoints, and why they matter for private subnets. An instance in a private subnet with no route to an Internet Gateway or NAT Gateway still often needs to reach AWS-managed services like S3 or DynamoDB. Rather than routing that traffic out to the public internet and back in, a VPC Endpoint creates a private, direct connection between the VPC and the AWS service, keeping that traffic entirely inside AWS’s own network. Gateway endpoints (for S3 and DynamoDB specifically) work by adding a route table entry; interface endpoints, built on AWS PrivateLink, work by placing an ENI with a private IP directly inside the subnet, extending the same private-connectivity pattern to a much broader range of AWS services.

IPv6 alongside IPv4. A VPC and its subnets can be configured to support IPv6 addressing in addition to the traditional IPv4 addressing most engineers are already familiar with, assigning each instance both an IPv4 and an IPv6 address where enabled. This matters increasingly for workloads that need to interoperate with IPv6-only clients or that are running into the practical exhaustion of available private IPv4 address space within a large, densely populated VPC.

Cross-zone load balancing. By default, an Application Load Balancer distributes traffic evenly across all registered targets regardless of which Availability Zone they sit in, a behavior called cross-zone load balancing. Without it — a configuration more commonly seen on Network Load Balancers, where it’s off by default — traffic is instead distributed evenly across AZs first and only then across the targets within each zone, which can create uneven load if one AZ happens to have noticeably fewer healthy instances than another.

EBS offers several volume types tuned for different access patterns. gp3, the current general-purpose default, provides a predictable baseline of IOPS (input/output operations per second) and throughput that can be tuned independently of volume size — a meaningful improvement over its predecessor, gp2, whose performance scaled directly (and sometimes awkwardly) with the size of the volume itself. io2 Block Express targets the highest-performance tier, suited to demanding production database workloads that need consistently high IOPS with very low latency. st1 (throughput-optimized HDD) and sc1 (cold HDD) are lower-cost, spinning-disk-backed options suited to large, sequential-access workloads like big data processing or infrequently accessed archives, where per-request latency matters far less than raw sequential throughput.

Snapshots as the bridge between EBS and durability. An EBS snapshot is a point-in-time, incremental backup of a volume stored in Amazon S3 behind the scenes. Because snapshots are incremental — each one only stores the blocks that changed since the previous snapshot — they are far more storage-efficient than a naive full copy, even though restoring from any single snapshot reconstructs the complete volume as it existed at that point in time. Snapshots are also the standard mechanism for creating custom AMIs: a golden image is typically built by launching an instance, configuring it exactly as desired, and then creating an AMI, which itself is backed by a snapshot of that instance’s root volume.

Elastic Volumes — changing storage without downtime. A meaningfully useful intermediate capability is the ability to modify a running EBS volume’s size, performance (IOPS and throughput), or even its type entirely, without detaching it or stopping the instance it’s attached to. This means a team that provisioned a gp3 volume too small for a growing dataset can grow it in place, or upgrade a workload from gp3 to io2 for higher sustained IOPS, all while the application continues running against that volume the entire time, with only a brief period where the volume optimizes itself in the background.

Fast Snapshot Restore, and the cold-start problem it solves. A newly created EBS volume restored from a snapshot is normally “lazy-loaded” — its data is fetched from S3 on first access to each block, which can cause noticeably degraded performance during the first period of use as blocks are pulled in on demand. Fast Snapshot Restore pre-warms a snapshot so that any volume created from it delivers full performance immediately, which matters considerably for Auto Scaling Groups that need newly launched instances to reach full performance right away rather than warming up gradually under live production traffic.

Multi-Attach, a narrower but important capability. Certain io1 and io2 volume types support attaching the same volume to multiple instances simultaneously within the same Availability Zone, intended specifically for clustered applications with their own data-consistency mechanism built in at the application layer, such as certain clustered file systems. This is a narrow, specialized capability rather than a general-purpose way to share a filesystem across instances — most shared-storage needs are better served by a dedicated managed file system service instead.

An Auto Scaling Group (ASG) is the component responsible for maintaining a fleet of EC2 instances at a desired size, launching new instances when demand rises or an existing instance fails a health check, and terminating instances when demand falls. It’s defined by a launch template (which specifies the AMI, instance type, and configuration for any new instance it creates) and a set of scaling policies, which can be as simple as a fixed instance count or as sophisticated as a target-tracking policy that automatically adjusts fleet size to keep average CPU utilization near a chosen target.

flowchart LR
    Users(["Incoming Traffic"]) --> ALB["Application Load Balancer"]
    ALB --> TG["Target Group
Health Checks"]
    TG --> ASG["Auto Scaling Group"]
    ASG --> I1["Instance 1"]
    ASG --> I2["Instance 2"]
    ASG --> I3["Instance 3 (scaled out)"]
    CW["CloudWatch Metrics"] --> ASG
        

The Application Load Balancer (ALB) sits in front of the fleet, distributing incoming requests across healthy instances and removing unhealthy ones from rotation automatically based on configurable health checks. Crucially, the ALB and the ASG communicate through a shared target group — when the ASG launches a new instance, it registers that instance with the target group, and the load balancer begins routing traffic to it only once it passes its health check. This separation of concerns — ASG manages fleet size and instance health, ALB manages traffic distribution — is a foundational architectural pattern that shows up throughout AWS’s higher-level services as well.

Scaling policies, briefly compared. A target tracking policy is the simplest and most commonly used approach — you specify a target metric value (like 60% average CPU utilization) and AWS handles the scaling math automatically. A step scaling policy gives more granular control, letting you define different scaling responses at different thresholds of alarm breach severity. A scheduled scaling policy proactively adjusts capacity ahead of known, predictable traffic patterns — scaling up before a daily peak rather than reactively waiting for CPU utilization to climb first.

Lifecycle hooks — pausing an instance mid-transition. Sometimes an instance needs to do work before it’s considered ready to receive traffic, or before it’s actually terminated — pulling application code from a repository, deregistering itself cleanly from a service mesh, or flushing in-flight work before shutting down. A lifecycle hook pauses an Auto Scaling Group’s normal launch or termination process at exactly that point, holding the instance in a wait state until a script or external automation signals that it’s safe to proceed, rather than letting the ASG barrel ahead on its default timeline regardless of whether the instance is truly ready.

Warm pools — solving the cold-start scaling problem. For applications with a lengthy, expensive startup process, waiting for a brand-new instance to fully boot and initialize during a genuine traffic spike can mean real users experience degraded service for several minutes before new capacity actually becomes useful. A warm pool keeps a small number of pre-initialized instances in a stopped or otherwise low-cost state, ready to be started and put into service almost immediately when the Auto Scaling Group needs to scale out, trading a modest ongoing cost for a dramatically faster response to sudden demand.

Mixed instance policies and Spot diversification. Rather than committing an entire Auto Scaling Group to a single instance type, a mixed instances policy lets the group draw from a list of compatible instance types and a blend of On-Demand and Spot capacity simultaneously. This diversification meaningfully reduces the practical risk of Spot Instance interruption — if AWS reclaims capacity for one particular instance type, the group can simply lean more heavily on the other types in its list, rather than the entire fleet being vulnerable to the same single point of Spot capacity contention at once.

Running three instances behind a load balancer does not automatically make a system highly available if all three instances sit in the same Availability Zone (AZ) — a single data-center-level event could take all three down simultaneously. True high availability requires spreading instances across multiple Availability Zones within a region, each of which is a physically distinct, independently powered and networked facility. An Auto Scaling Group configured across multiple subnets in different AZs will, by default, attempt to balance instances evenly across those zones, so that the loss of a single AZ only removes a fraction of total capacity rather than the entire fleet.

EC2 Auto Recovery adds another layer of resilience below the Auto Scaling Group: for underlying hardware failures detected by AWS’s own system-level health checks, a CloudWatch alarm can trigger the automatic recovery of an instance onto new, healthy hardware, preserving its instance ID, private IP address, and EBS volume attachments — useful for stateful workloads that can’t simply be replaced by a fresh instance from an Auto Scaling Group.

Disaster recovery beyond a single region. Multi-AZ resilience protects against the loss of a single data center, but a full region-wide event — rare, but not impossible — requires a deliberate cross-region strategy. A pilot light approach keeps a minimal, low-cost version of critical infrastructure running in a second region, scaled up only when a failover is actually declared. A warm standby approach keeps a scaled-down but fully functional replica continuously running in the second region, reducing failover time further at the cost of ongoing spend in two regions simultaneously. A full multi-region active-active deployment runs production traffic in both regions all the time, offering the fastest possible failover at the highest ongoing cost and architectural complexity. Choosing among these three is fundamentally a trade-off between recovery time, recovery cost, and the actual business impact of extended downtime.

Health check granularity matters. A load balancer’s health check and an Auto Scaling Group’s own EC2 status check answer different questions. The EC2 status check only confirms the underlying instance and network path are functioning; it says nothing about whether the application running on top is actually healthy. Configuring the Auto Scaling Group to use the load balancer’s health check status, rather than relying solely on the EC2-level check, closes an important gap — an instance can pass every infrastructure-level check while its application has silently crashed or deadlocked, and only an application-aware health check will catch that condition and trigger a replacement.

IAM roles for EC2, instead of embedded credentials. An intermediate-level best practice is to never place long-lived AWS access keys directly on an instance or bake them into an AMI. Instead, an instance profile attaches an IAM role to a running instance, and the instance metadata service automatically supplies temporary, short-lived credentials scoped to exactly the permissions that role grants — credentials that rotate automatically behind the scenes without any application code needing to manage them manually.

IMDSv2 and the SSRF problem it solves. The original instance metadata service (IMDSv1) was a simple, unauthenticated HTTP endpoint reachable from inside the instance — which meant that a Server-Side Request Forgery (SSRF) vulnerability in an application running on that instance could potentially be tricked into fetching the instance’s own IAM credentials from the metadata service and leaking them to an attacker. IMDSv2 closes this gap by requiring a session token, obtained through a separate PUT request, before any metadata can be read — a request pattern that a typical SSRF vulnerability, which usually can only force simple GET requests, cannot easily replicate. Enforcing IMDSv2-only access (disabling the older IMDSv1 fallback entirely) is now considered a baseline hardening step for production EC2 fleets.

EBS encryption. Volumes can be encrypted at rest using AWS Key Management Service (KMS), and encryption can be set as an account-level default so that every newly created EBS volume is encrypted automatically without requiring each team to remember to enable it manually. Snapshots taken from an encrypted volume are themselves encrypted, and any volume restored from an encrypted snapshot inherits that encryption automatically, which means encryption, once enabled at the source, effectively propagates itself through the entire backup and restore lifecycle.

Systems Manager Session Manager, replacing direct SSH access. Rather than opening inbound SSH (port 22) or RDP access on a security group — a persistent target for automated internet-wide scanning and brute-force attempts — AWS Systems Manager Session Manager provides a browser- or CLI-based shell session to an instance entirely through the Systems Manager Agent and AWS’s own control plane, with no inbound port needing to be open at all. Access is instead governed purely by IAM permissions, and every session is automatically logged, giving security teams a complete audit trail of who accessed which instance and when, something traditional SSH key management struggles to provide consistently across a large fleet.

Patch management and vulnerability scanning. AWS Systems Manager Patch Manager can automate the process of applying operating system and security patches across a fleet on a defined schedule, reducing the operational burden of manually tracking patch status instance by instance. Amazon Inspector complements this by continuously scanning running instances for known software vulnerabilities and unintended network exposure, surfacing findings that a manual security review would likely take much longer to catch consistently across a large, constantly changing fleet.

By default, EC2 publishes a set of basic CloudWatch metrics — CPU utilization, network in/out, disk read/write operations — at five-minute intervals, at no additional cost. Detailed monitoring increases that resolution to one-minute intervals for an additional charge, which matters for Auto Scaling policies that need to react quickly to sudden load changes rather than waiting up to five minutes to notice a spike.

Where logs actually go. Application and system logs generated inside an instance don’t automatically appear in CloudWatch Logs — the CloudWatch Agent (or a similar log-forwarding tool) must be configured to tail specific log files and stream them centrally. This is a deliberate design choice: AWS doesn’t presume to know which of the potentially thousands of files on a running instance are meaningful logs, so log shipping is opt-in and explicitly configured rather than automatic.

Alarms, and the value of combining several into one. A CloudWatch alarm watches a single metric against a threshold and changes state when that threshold is breached for a defined number of consecutive evaluation periods, which itself can trigger an Auto Scaling action, a notification, or an automated remediation. A composite alarm combines the state of several individual alarms using logical AND/OR rules, which meaningfully reduces alert noise — rather than paging an on-call engineer the instant any single metric flickers briefly, a composite alarm can require, for example, both elevated CPU and elevated request latency simultaneously before it actually fires, filtering out transient blips that don’t represent a real problem.

AWS Config, for tracking configuration drift over time. Beyond real-time metrics and logs, AWS Config continuously records the configuration state of EC2 instances and related resources, and can evaluate that configuration against defined compliance rules — flagging, for example, any instance whose security group unexpectedly allows unrestricted inbound access, or any EBS volume that isn’t encrypted despite an account-wide policy requiring it. This gives an intermediate-level team a historical, queryable record of exactly how a fleet’s configuration has evolved, which becomes invaluable during an incident investigation or a compliance audit.

Rightsizing as a continuous practice, not a one-time exercise. A workload’s real CPU, memory, and network usage tends to drift over time as traffic patterns, feature sets, and dependent services change, which means an instance size chosen correctly a year ago may no longer be well matched to today’s actual load. AWS Compute Optimizer analyzes historical utilization metrics for running instances and produces concrete rightsizing recommendations — often suggesting a smaller instance size within the same family, or occasionally a different family entirely, based on the specific balance of CPU, memory, and network utilization it observes over the analyzed window.

Spot Instances, understood as a genuinely different pricing market. Spot capacity is AWS’s spare, currently-unused compute, offered at a steep discount in exchange for the possibility of reclaiming it with only a two-minute interruption notice when that capacity is needed elsewhere. The discount, and the interruption risk, both vary by instance type, Availability Zone, and time — some pools are consistently stable for months at a time, while others experience frequent interruption during periods of high regional demand. A Spot Fleet or an Auto Scaling Group’s mixed instances policy diversifies across many instance types and pools simultaneously, meaningfully reducing the practical chance that an interruption affects a large fraction of the fleet all at once, since different pools rarely experience capacity pressure at exactly the same moment.

Scheduled shutdowns for non-production environments. Development, staging, and testing environments frequently run twenty-four hours a day even though they’re genuinely used only during business hours. Automating a nightly stop and morning start for these environments — through a simple scheduled Lambda function or an AWS-managed instance scheduler — can eliminate well over half of their compute cost without any impact on the engineers actually using them during working hours, since a stopped instance accrues no compute charges at all.

The hidden cost of unattached and idle resources. A remarkably common source of avoidable spend has nothing to do with running instances at all: unattached EBS volumes left behind after an instance is terminated, unused Elastic IPs sitting idle without being associated with a running instance, and old, forgotten snapshots that nobody has cleaned up in years. None of these show up as prominently on a bill as running compute does, but collectively across a large, long-running AWS account, they can represent a meaningful and entirely avoidable fraction of total spend, which is why periodic resource-cleanup audits are considered a standard operational habit rather than an occasional nice-to-have.

Site-to-Site VPN versus Direct Connect. A company migrating gradually to AWS, or one that needs an ongoing hybrid architecture spanning both on-premises data centers and EC2, typically has two main connectivity options. An IPsec Site-to-Site VPN connection encrypts traffic over the public internet between an on-premises network and a VPC, and can typically be established within hours, making it a natural starting point. AWS Direct Connect instead establishes a dedicated, private physical network connection between an on-premises facility and AWS, bypassing the public internet entirely, offering more consistent latency and higher available bandwidth at the cost of a longer setup process and an ongoing physical circuit cost.

AWS Application Migration Service, for lift-and-shift moves. Rather than manually rebuilding an on-premises server as a new EC2 instance from scratch, AWS Application Migration Service continuously replicates a running on-premises (or other-cloud) server’s disk content to AWS in the background, while the source server keeps running normally in production. When the team is ready to cut over, a test or production launch creates a fully functioning EC2 instance from that continuously replicated data, dramatically shortening the migration window and the associated risk compared with a from-scratch rebuild.

Transit Gateway, for connecting many VPCs at once. As a company’s AWS footprint grows into dozens of separate VPCs — one per team, environment, or business unit — connecting them all directly to each other and to on-premises networks through individual point-to-point VPN or peering connections becomes unmanageable very quickly. AWS Transit Gateway acts as a central hub that every VPC and on-premises connection attaches to once, letting traffic flow between any two attached networks through that single hub rather than requiring a dedicated connection between every possible pair, which would otherwise grow quadratically as the number of VPCs increases.

Large media and streaming platforms typically run compute-optimized (C-family) fleets for video transcoding pipelines, scaling those fleets aggressively with Spot Instances since transcoding jobs are naturally interruption-tolerant and can simply be re-queued if a Spot instance is reclaimed mid-job — a pattern that captures substantial cost savings on a workload that would otherwise run constantly at scale.

Financial trading and analytics platforms, where consistent low-latency inter-instance communication is critical, commonly use cluster placement groups paired with enhanced networking to minimize network hops between tightly coupled compute nodes, accepting the reduced fault-tolerance trade-off in exchange for the latency benefit.

E-commerce platforms facing sharp, predictable seasonal traffic spikes often combine scheduled scaling policies, which proactively add capacity ahead of a known high-traffic event, with target-tracking policies that handle any unexpected additional demand reactively — layering both approaches rather than relying on just one.

SaaS companies running multi-tenant backend services frequently standardize on immutable, AMI-based deployments precisely because it lets many independent engineering teams deploy new versions of their services without ever needing direct SSH access to production instances, reducing both operational risk and audit surface simultaneously.

Online gaming platforms hosting real-time multiplayer game servers often favor spread placement groups for their matchmaking and session-management fleets, prioritizing fault isolation over raw inter-instance latency, while pairing that with warm pools so that a sudden surge of players at a popular event doesn’t leave new game sessions waiting on slow-booting fresh instances.

Healthcare technology companies handling regulated patient data commonly combine Nitro Enclaves for isolating especially sensitive processing steps with strict, centrally managed IAM roles and mandatory EBS encryption defaults, treating the Nitro System’s hardware-level isolation guarantees as a meaningful part of their overall compliance posture rather than a purely optional performance feature.

Companies migrating a large, long-standing on-premises footprint into AWS frequently phase the move deliberately rather than attempting it all at once: an initial wave using Application Migration Service handles straightforward, low-risk lift-and-shift candidates first, a middle wave re-platforms selected workloads onto managed services where it makes sense along the way, and a final wave tackles the handful of tightly coupled, higher-risk systems only once the team has built confidence and operational muscle memory from the earlier, simpler migrations.