<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>AWS on Cloudy Mountains</title><link>https://cloudymountains.cloud/tags/aws/</link><description>Recent content in AWS on Cloudy Mountains</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Mon, 30 Mar 2026 13:00:44 +0100</lastBuildDate><atom:link href="https://cloudymountains.cloud/tags/aws/index.xml" rel="self" type="application/rss+xml"/><item><title>aws_oam_sink and aws_oam_link in Terraform: Centralized AWS Observability (Part 2)</title><link>https://cloudymountains.cloud/projects/observability/aws-observability-part-two/</link><pubDate>Mon, 30 Mar 2026 13:00:44 +0100</pubDate><guid>https://cloudymountains.cloud/projects/observability/aws-observability-part-two/</guid><description>&lt;p>In &lt;a href="https://cloudymountains.cloud/projects/observability/aws-observability-part-one/">part one&lt;/a> 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: &lt;strong>metrics&lt;/strong> centralization.&lt;/p>
&lt;p>&lt;a href="https://docs.aws.amazon.com/OAM/latest/APIReference/Welcome.html">CloudWatch cross-account observability&lt;/a> (OAM) requires you to designate a &lt;strong>monitoring account&lt;/strong> (or create one). AWS recommends a dedicated monitoring account. In our case, we used the existing &lt;strong>Shared Services&lt;/strong> account where we already run shared services, so we did not use a separate account.&lt;/p></description></item><item><title>Centralized AWS Observability Architecture: CloudWatch, YACE and Grafana (Part 1)</title><link>https://cloudymountains.cloud/projects/observability/aws-observability-part-one/</link><pubDate>Sun, 25 Jan 2026 13:00:44 +0100</pubDate><guid>https://cloudymountains.cloud/projects/observability/aws-observability-part-one/</guid><description>&lt;p>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.&lt;/p></description></item><item><title>Hugo on S3 and CloudFront with Terraform and GitHub Actions OIDC</title><link>https://cloudymountains.cloud/projects/static-site-s3-cloudfront/</link><pubDate>Fri, 06 Jun 2025 12:20:44 +0100</pubDate><guid>https://cloudymountains.cloud/projects/static-site-s3-cloudfront/</guid><description>&lt;p>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 &lt;strong>Hugo&lt;/strong>, &lt;strong>AWS (S3 + CloudFront)&lt;/strong>, &lt;strong>Terraform&lt;/strong>, &lt;strong>GitHub Actions&lt;/strong>, and &lt;strong>OIDC&lt;/strong> authentication. I’ll show you the challenges that I had and how to solve them properly.&lt;/p></description></item></channel></rss>