Hi, I’m David 🌮

A Terraform pipeline should do more than run plan and apply. Production infrastructure needs controlled auth, one writer at a time, plans people can review, approval gates, post-deploy checks, and a clear recovery plan. I built that workflow with GitHub Actions and Azure. It uses OpenID Connect (OIDC) instead of a stored Azure client secret. It pins third-party actions to reviewed commits and applies a saved Terraform plan. I also kept a clear line between what the pipeline can prove and what the app architecture has to prove on its own. ...

Terraform and Azure DevOps automation concept. Infrastructure as code gets a lot more useful when you add real controls around it. That means deployment governance, isolated environments, secure auth, policy enforcement, remote state, and central monitoring. I designed an enterprise-style Azure delivery platform around Terraform, Azure DevOps YAML pipelines, and GitOps principles. Creating Azure resources was the easy part. I wanted a controlled process to define, review, validate, approve, deploy, and audit changes across dev, staging, and production. ...

I used Terraform and the AWS provider to create an Ubuntu EC2 instance. First I set up authentication. Then I split the project into small Terraform files. I reviewed the plan and created the instance. I ran a second plan to confirm nothing changed. When I was done, I destroyed it. I built this in 2023. The screenshots and pinned provider version are from then. For a new project, check the current Terraform AWS provider docs and use short-lived AWS credentials where you can. ...

Building Active Directory Across Multiple Azure VNets I built a small Active Directory environment in Azure. It has one Windows Server Domain Controller and three Windows client VMs spread across three virtual networks. I wanted domain logins and DNS to work across all the VNets. Every endpoint had to join the same domain, and traffic had to work both ways. Here’s the layout: cu-domain.local | Domain Controller + Endpoint 1 VNet1: 10.0.0.0/16 / \ VNet peering VNet peering / \ VNet2: 10.1.0.0/16 VNet3: 10.2.0.0/16 Endpoint 2 Endpoint 3 The names and address ranges are just what I picked. For production I’d follow the company’s naming standards and avoid .local. I’d run more than one Domain Controller. And I’d lock down admin access instead of opening RDP to the whole internet. ...

Building AWS WorkSpaces with Managed Microsoft AD and a Windows File Share I built an AWS environment where Amazon WorkSpaces users log in through AWS Managed Microsoft AD. From their WorkSpace they reach a private, domain-joined Windows EC2 server. That server does two jobs. It runs the Active Directory admin tools, and it hosts a basic SMB file share on an extra EBS volume. Here’s the finished design: Amazon WorkSpace | | AWS Managed Microsoft AD authentication v Private VPC subnets in two Availability Zones | | RDP for administration / SMB for file access v Domain-joined Windows EC2 server + EBS data volume Service availability, bundles, prices, and supported zones change. Check the current AWS docs and pricing before you build this. ...

Azure Site Reliability Engineering Agent goes after the first part of an incident. That’s the part where you gather evidence, check service health, line up telemetry, read code, and figure out where to look next. I set it up, connected it to my code and telemetry, and pushed it through a few real tests. This post covers setup, governance, investigations, and automation. Note: Azure SRE Agent became generally available in March 2026. When I tested it, several features were still in preview or changing. That includes networking, hooks, role behavior, and parts of the incident workflow. Treat product details here as what I saw at the time, not permanent behavior. ...

Normal monitoring tells you a service failed. I wanted mine to fix it too. I built a pipeline that collects Nginx failure logs from EC2 and sends them to Amazon Bedrock for a diagnosis. The diagnosis maps to an approved fix. Then AWS Systems Manager runs that fix without any SSH session. The setup uses an Amazon Linux 2023 EC2 instance, Nginx, CloudWatch Logs, Lambda, Amazon Bedrock, and SSM Run Command. ...

One setting won’t fix an AWS bill. Steady compute, batch jobs, always-on databases, overspend, and sudden spikes all need different controls. I combined five of them into one design: Compute Savings Plan + Spot-based batch capacity + RDS Reserved Instance + AWS Budgets + Cost Anomaly Detection The goal was to cut predictable costs and add guardrails. Those guardrails make overspend easier to spot. One of them even blocks new spend automatically. ...

AWS bills rarely blow up because of one bad architecture choice. They drift. Temporary resources become permanent. Non-production environments never shut down. Nobody owns the untagged stuff. Multiple accounts have no central view. I built a framework around four habits to fix that: 1. Resource attribution with tags 2. Cost visibility and budget alerts 3. Preventive controls with Service Control Policies 4. Continuous optimization with Trusted Advisor and Compute Optimizer The scenario I designed this for is a US SaaS company. Its monthly AWS bill went from $18,500 to $26,000 with no launch and no traffic spike. The cause was forgotten EC2 capacity, an RDS instance left over from a retired workload, unattached Elastic IPs, and almost no ownership tags. ...

I built a segmented AWS environment that keeps the app servers off the public internet. A bastion host is the only way in for admin work. A NAT Gateway gives outbound access. Ansible configures two Nginx servers. An Application Load Balancer (ALB) serves the app. The architecture I built. What I built The main pieces: A custom VPC using 10.0.0.0/16 Public and private subnets An Internet Gateway and NAT Gateway Separate public and private route tables One Ubuntu bastion host Two private Ubuntu EC2 web servers Ansible running from the bastion host An HTTP target group and an internet-facing ALB I kept the environment small. An internet-facing ALB needs subnets in at least two Availability Zones, which you can see in the ALB screenshots. One of those subnets, in us-east-1c, isn’t shown being created. For a resilient production design I’d put the ALB in two public subnets and the app servers in private subnets across the same two zones. ...