Browse 21 articles by topic or keyword.
My CloudOps agent remembered which environment I preferred. Then I changed that preference to an environment its deployment tool did not support. The result clarified a useful boundary: memory can preserve context, but current facts still need a current source.
My first CloudOps agent refused to say whether production was healthy because it had no operational data. I added a deterministic Lambda through Amazon Bedrock AgentCore Gateway, tested the complete tool path, fixed a protocol mistake, and learned why a grounded answer is only as reliable as its underlying source.
I deployed a managed AgentCore Harness and asked whether production was healthy. Its refusal was the correct result for this experiment: the agent had a model and a prompt, but no authoritative operational data. The deployment and trace made that boundary concrete.
I moved the application and delivery contract from my home k3s server to temporary EKS infrastructure. The workload stayed familiar, but AWS introduced new decisions around networking, identity, compute and load balancing. I tested the complete path, measured drift correction and then removed the environment.
I first built an always-on k3s lab, then discovered that a successful rollback could leave its saved YAML behind. After designing a safer GitOps path, I implemented it and tested three real behaviors: drift correction, a correctly deployed bad release, and durable recovery through a Git revert.
My Kubernetes rollback restored Version 2, but it did not update the YAML that still declared Version 3. I corrected the file manually, then designed a delivery process in which Git recorded the chosen version and the cluster followed it automatically.
I wanted a staging server that was more realistic than local Docker but smaller than a full AWS platform. I used Terraform and Docker Compose to build one on a $7 Lightsail plan, then measured deployment, application recovery, instance reboot recovery, cost, and cleanup.
I wanted a persistent Kubernetes environment without an always-on managed-cluster bill or compromising the Docker workloads already running on my Debian home server. I chose k3s, defined explicit resource boundaries, disabled components that conflicted with the host, and validated the design through deployment, networking, rollout, rollback, and desired-state checks.
My Terraform drift pipeline could detect an EC2 tag change and remove it automatically, but the evidence was scattered across temporary logs. I added a DynamoDB audit trail, a read only Lambda API, and a CloudFront dashboard so the system could remember and display every classified drift event.
I added a tag directly to an EC2 instance in AWS, then ran my Terraform drift detector. The change was classified as LOW, Lambda started a separate remediation build, and Terraform removed the tag automatically.
My Terraform drift detector could send an email, but it could not explain what changed or how serious it was. I changed the SNS message into structured JSON, delivered it to SQS for audit processing, and used Lambda to classify every resource change by severity.
Terraform could reproduce my infrastructure, but it could not warn me when someone changed AWS manually. I built a CodeBuild job that runs Terraform plan, handles the drift exit code correctly, reads shared configuration from SSM, and sends an SNS email when the real infrastructure no longer matches the code.