Cloudy Mountains

Your AI Agent Is a Contractor. Treat It Like One.

Tue, 22 Sep 2026 10:00:00 +0100

For a big part of my career I was the contractor. Consultancy after consultancy, client after client. And one thing kept surprising me: the team that was supposed to help us was often the least helpful group in the building.

Access requests took weeks. Questions got one-line answers, if any. In meetings we were the outsiders who didn’t know how things worked here, the ones who would break something, the expensive people who needed everything explained twice. Sometimes it was subtle. Sometimes it was not subtle at all.

The AI-Native Internal Developer Platform

Tue, 26 May 2026 10:00:00 +0100

Internal Developer Platforms have a well-known dirty secret: most developers do not use them. The platform team builds something genuinely useful — curated pipelines, Terraform modules, Helm charts, GitOps patterns, cost guardrails — wraps it in a service catalogue, adds a web portal, writes runbooks, and waits. Adoption trickles in, usually driven by mandate rather than enthusiasm.

This is not a technology problem. It is a distribution problem. The platform team solved the right problem and delivered it to the wrong address.

Centralized AWS Observability with OAM and Terraform (Part 2)

Mon, 30 Mar 2026 13:00:44 +0100

In part one we covered the architecture and design behind the centralized observability solution. In this post, we walk through the practical configuration and provide code snippets to build the first part of the solution: metrics centralization.

CloudWatch cross-account observability (OAM) requires you to designate a monitoring account (or create one). AWS recommends a dedicated monitoring account. In our case, we used the existing Shared Services account where we already run shared services, so we did not use a separate account.

Centralized AWS Observability: theoretical justification (part 1)

Sun, 25 Jan 2026 13:00:44 +0100

In this series of blog posts I will describe the journey (or one of the possible ways) of building a comprehensive observability solution for AWS and on-prem workloads. I will provide a step by step guide and how the decisions were made for choosing or not the particular technologies (observability stacks or whatever you call it). I will try to provide as much as possible examples and code snippets. So lets start. First let say a few words about the initial state and the goals that I have to achieve with this solution.

Enforcing AWS AMI images with OPA

Mon, 23 Jun 2025 13:00:44 +0100

In the part 2, we provided examples of how you can enforce AWS tags to ensure compliance and governance within your organization. In this post, we will extend those concepts by demonstrating how you can enforce specific AMI IDs using OPA policies, helping you maintain control over the AMI images used in your infrastructure.

It is critical for all organizations to establish a robust AMI building process to ensure that operating systems are consistently patched for security vulnerabilities. By maintaining control over the AMI lifecycle, organizations can enforce compliance, reduce exposure to risks, and ensure that their infrastructure remains secure and up-to-date. This process not only helps in mitigating potential threats but also aligns with best practices for infrastructure management and governance. This process is typically managed by the Security team, who are responsible for building and maintaining approved AMIs. The “customers” of these AMIs are other teams within the organization, such as Development, Operations, or QA, who rely on these pre-approved images to ensure their workloads meet security and compliance standards.

Enforcing AWS Resource Tags with OPA

Fri, 13 Jun 2025 13:00:44 +0100

In Part 1 of this series, we covered the basics of Policy as Code and how the shift-left approach helps catch infrastructure mistakes early. In this post, we’re putting theory into practice—specifically, how to enforce AWS tagging strategy using Open Policy Agent (OPA) during Terraform plan phase/stage.

This isn’t just about tagging hygiene. Good tagging is foundational for tracking cloud costs, understanding ownership, and avoiding dangerous or expensive mistakes.

Why Tags Matter

Tags seem trivial—until you’re staring at a $1M AWS bill and have no idea where it came from.

Static site with S3 and CloudFront

Fri, 06 Jun 2025 12:20:44 +0100

When I decided to build my own site, I knew I wanted something fast, scalable, and modern — not just in terms of the tech stack, but also in the way it’s managed and deployed. This post walks you through exactly how my site (Cloudy Mountains) is deployed using Hugo, AWS (S3 + CloudFront), Terraform, GitHub Actions, and OIDC authentication. I’ll show you the challenges that I had and how to solve them properly.

First policy as code using OPA

Thu, 15 May 2025 23:58:44 +0100

As I mentioned in my previous blog post, my first OPA policy was just to catch one simple parameter, if we have in the S3 Terrafom module set the force_destroy = true.

Here’s a simple OPA policy that will catch this dangerous configuration:

package terraform.plan

deny[msg] {
 # Find all resources in the plan
 resource := input.resource_changes[_]
 
 # Check if it's an S3 bucket
 resource.type == "aws_s3_bucket"
 
 # Look for force_destroy in the configuration
 resource.change.after.force_destroy == true
 
 msg := sprintf("S3 bucket '%s' has force_destroy set to true. This is dangerous as it allows bucket deletion even when not empty.", [resource.address])
}

This policy works by:

How I Learned the Hard Way That Terraform Needs Policy as Code

Sun, 30 Mar 2025 13:00:44 +0100

At a glance

Context: a cloud consultancy engagement, bootstrapping 15 new AWS accounts for a client with Terraform 0.11/0.12.
Incident: I accidentally deleted the S3 bucket that held the Terraform state for all 15 accounts.
Cost: all 15 accounts were recreated and provisioned again from scratch. Because everything was code, that took less than two days. The real cost was our reputation with the client.
Fix: policy as code. OPA policies evaluated against every terraform plan in CI, failing the pipeline before a dangerous change reaches apply.
Outcome: 15 workload pipelines gated, and every pipeline created after them inherited the same checks.

What went wrong?

A few years ago, while working for a cloud consultancy company, I made a mistake that I will never forget. I accidentally deleted a Terraform state bucket: the S3 bucket that stored the state for bootstrapping 15 AWS accounts, each packed with resources. To make things worse, it belonged to a very tough client.

Using Shift Left paradigm to manage cloud cost

Fri, 31 May 2024 13:00:44 +0100

Introduction

In the fast-evolving world of cloud computing, managing costs effectively has become a crucial aspect of maintaining a sustainable and profitable business. The “Shift left” paradigm, originally a concept in software development, emphasizes the importance of addressing potential issues early in the development process. When applied to AWS cost optimization and management, this approach ensures that cost considerations are integrated into the earliest stages of the development lifecycle.

By shifting cost management left, organizations can avoid unexpected expenses and optimize their cloud spending proactively. This blog post explores the application of the “Shift left” paradigm to AWS cost optimization, focusing on tools like Open Policy Agent (OPA) policies, Infracost, and Terracost. We will delve into how these tools can help estimate and control costs efficiently, ensuring that your AWS resources are both cost-effective and aligned with your financial goals.

CV

Mon, 01 Jan 0001 00:00:00 +0000

Experienced DevOps and Cloud Engineer with over 15 years of experience designing, implementing, and managing scalable, secure, and automated cloud infrastructures. Specialized in AWS architecture, Infrastructure as Code, CI/CD, and container orchestration. Passionate about building resilient systems through automation, GitOps, and modern DevOps practices.