Cloud engineering / AWS Infrastructure Lifecycle
AWS Infrastructure Lifecycle
Make every resource accountable.
A CLI-driven EC2 lab with reviewable offline plans, explicit execution, account and network checks, recoverable state and ownership-based cleanup. Historical AWS screenshots provide context; new lifecycle tests exercise the control logic without provisioning resources.
AWS Infrastructure Lifecycle / Architecture
01 / The question
How can a small cloud lab remain inspectable and recoverable?
Infrastructure work continues after an instance launches. This lab connects configuration, identity checks, resource creation, monitoring and cleanup, while recording the instance identity before later stages can fail.
My contributionImplemented the lifecycle runner, account and network guards, state persistence and offline failure tests; reconciled the documentation with the files actually provided.
02 / System walkthrough
From input to evidence.
The stages of the implementation and its verification boundary.
- 01
Review configuration
Supply an approved account, region, Amazon Linux image, subnet, key pair and a security group limited to the administrator IPv4 /32.
- 02
Inspect an offline plan
The default command prints arguments and makes no AWS calls. This is not AWS API DryRun validation.
- 03
Execute deliberately
Explicit execution checks account identity, security-group ingress and supported image metadata before launching one instance.
- 04
Track and retire
Save state, wait for running, configure a CPU alarm; cleanup checks account and tags before termination and alarm removal.
03 / Engineering decisions
Why the implementation matters.
State survives partial failure
The instance ID is saved before the waiter and alarm calls, so later failures do not lose the cleanup target.
Ownership is explicit
Both Project and RunId tags must match the saved account, region and run before cleanup can proceed.
Security settings are concrete
Launch arguments require IMDSv2, encrypted root EBS and a narrow SSH source. No IAM grants or MFA changes are automated.
04 / Results & interpretation
What the checks establish.
Offline command construction and mocked AWS responses were tested. No new cloud provisioning, IAM changes or termination occurred.
Offline lifecycle contracts
14 passedTests reject account mismatches, foreign tags, open SSH, unsupported administrator ranges and missing ingress; they check recovery state and cleanup ordering.
Historical execution
PreservedOriginal EC2, SSH, IAM and CloudWatch screenshots remain available as historical evidence.
New AWS deployment
Not executedThe new runner has not been verified against live AWS resources. The offline plan and mocked calls establish code behavior only.
05 / Scope & limitations
Scope & limitations.
- Cloud integration remains separateCurrent IAM permissions, AMI availability, network reachability and successful live cleanup require an authorized account run.
- A single-instance labNo high availability, autoscaling, private-subnet design, comprehensive IAM policy or production security assessment is claimed.
- Cost and cleanup boundariesThe runner terminates its tagged instance and deletes its run alarm. Existing keys, subnets and security groups are retained; other charges must be checked separately.
06 / Next iteration
Where I would take it next.
The next technical priorities for this project.
Capture a controlled live run
Use an approved sandbox account, record a sanitized lifecycle transcript and verify the final instance and alarm states.
Move toward declarative infrastructure
Introduce reviewed Terraform or CloudFormation after the intended network and identity model is established.
07 / Code & reproducibility
Explore the implementation.
Source, execution commands, verification reports and architecture are documented in the linked GitHub project.
- lifecycle.py — offline plans and explicit lifecycle execution
- test_lifecycle.py — account, network, recovery and ownership contracts
- config.example.json — intentionally nonfunctional example identifiers
- screenshots/ — preserved historical EC2, SSH, IAM and CloudWatch evidence
Original architecture diagrams describe the implementation and its verification boundary. They are explanatory diagrams, not screenshots of a deployed system.