AWS / Basic: cloud scope and core boundaries / Lesson 4
EC2 compute and storage lifecycle
Separate instance identity, guest operation, attached data, scaling policy, and recovery evidence before managing virtual machines.
On this page
Lesson goals
- Explain the assumptions, responsibilities, and trade-offs of ec2 compute and storage lifecycle.
- Interpret both examples and distinguish declared intent from verified evidence.
- Diagnose the listed failures and justify the worked decisions without using a real AWS account, credential, or service.
An instance is a configured compute boundary
An EC2 instance combines an approved image, instance type, network placement, identity, storage, and guest configuration. Instance families and architectures serve different workload needs; a name or small size is not proof of compatibility or low total cost. Confirm operating-system support, software architecture, required performance, Region availability, and service quotas before selection. The first synthetic launch record separates those inputs without supplying an AMI or invoking EC2. Customer ownership includes guest patching, application behavior, credential handling, and recovery. A running instance is only one layer of evidence, not proof that the application is healthy.
workload: synthetic-booking-api
image_identity: approved-lab-image-reference
architecture: explicitly-matched-to-software
placement: reviewed-subnet-and-AZ
workload_role: narrow-reviewed-role
data: separate-reviewed-storage-contract
health: guest-plus-user-path-evidence
These are fictional design references, not valid EC2 launch parameters or a resource creation request. No image or credential is retrieved.
Distinguish system and application health
EC2 status information, guest telemetry, load-balancer target health, and user-path checks answer different questions. A successful boot can coexist with missing configuration, wrong permissions, a closed listener, or a saturated backend. Use safe logs and metrics to identify the failing boundary before rebooting or changing instance type. Keep the selected account, Region, instance reference, image revision, and time in approved evidence. Avoid interactive administrative access as the default diagnostic step, since it changes the trust and audit boundary and may obscure reproducibility. This lesson does not connect to an instance or inspect a real guest.
Treat storage lifetimes explicitly
EBS volumes are separate block-storage resources with placement and attachment constraints; ordinary volumes are associated with an AZ. Instance store has different persistence behavior and should not be the only copy of durable data. Stop, restart, and termination are not interchangeable, and deletion behavior for attached EBS depends on configuration such as DeleteOnTermination. The second matrix separates recoverable data from a disposable instance. Snapshots need consistency, retention, permissions, and key access; creating a snapshot is not proof of application recovery. Confirm exact storage and instance-mode behavior in current documentation before a real lifecycle action.
component lifecycle question
compute instance replaceable from approved inputs?
EBS data volume retained or deleted under exact configuration?
instance-store data disposable or regenerated?
snapshot consistent, accessible, and restore-tested?
application operation safe retry or reconciliation after interruption?
An instance action has several consequences with different owners. The matrix supplies no universal persistence or billing guarantee and performs no lifecycle action.
Manage identity and replacement rather than pets
Use a reviewed workload role where appropriate instead of storing access keys on disk. Instance metadata access has security implications; prefer the documented IMDSv2 and least-privilege identity design rather than fetching credentials in diagnostics. An Auto Scaling group can replace unhealthy capacity according to its policy, so manually stopping one managed instance may not be a lasting repair. Keep image creation and configuration repeatable and preserve state outside disposable compute when required. Address identity and network names can also change across lifecycle events; clients should use the intended discovery contract rather than hardcoded ephemeral addresses.
Plan capacity and cleanup with data protection
Include temporary rollout capacity, failure headroom, scaling delays, quotas, and dependency limits in the compute plan. Stopping compute does not automatically remove every storage, address, snapshot, or related charge. Before any authorized cleanup, identify ownership and the recovery contract so cost reduction does not delete the only useful data copy. No launch, stop, reboot, termination, metadata query, image retrieval, or administrative command is executed here. Synthetic records and offline reasoning establish concepts only; actual performance, billing, and lifecycle effects must be verified for the selected account, service mode, and platform under explicit authorization.
Common errors and fixes
Instance termination unexpectedly deletes data
- Why it happens
- Attachment deletion policy and backup state were not reviewed.
- How to fix it
- Use the approved recovery process and inspect retained evidence.
- Prevent it next time
- Review exact storage lifecycle before destructive actions.
A running instance is called a healthy service
- Why it happens
- Boot status replaced application outcomes.
- How to fix it
- Check configuration, listener, dependencies, and user behavior.
- Prevent it next time
- Separate infrastructure and service acceptance checks.
Manual instance repair is undone by scaling
- Why it happens
- The owning group still enforces declared replacement policy.
- How to fix it
- Repair the reviewed image or group configuration.
- Prevent it next time
- Record ownership before changing managed instances.
Check your understanding
1. Why should durable booking data not live only in instance store?
Show worked solution
Its persistence contract differs from durable independent storage and important lifecycle events can remove it. Classify it as disposable unless a reviewed recovery design establishes otherwise. Keep authoritative data and verified recovery copies under explicit storage and consistency controls.
2. An Auto Scaling group replaces a manually stopped instance. Is the platform necessarily malfunctioning?
Show worked solution
No. It may be enforcing its declared desired capacity and health policy. Inspect the group’s ownership and intended contract, then change reviewed desired state through the authorized workflow if appropriate. Repeating manual stops does not resolve a controller-versus-human conflict.
Key takeaways
- An EC2 instance combines an approved image, instance type, network placement, identity, storage, and guest configuration.
- EBS volumes are separate block-storage resources with placement and attachment constraints; ordinary volumes are associated with an AZ.
- Include temporary rollout capacity, failure headroom, scaling delays, quotas, and dependency limits in the compute plan.