标签：#Cloud

AWS released a public preview of the GuardDuty investigation agent, which correlates findings, 90-day activity logs, and resource topologies into structured reports with risk ratings, confidence scores, and MITRE ATT&CK classification. It is reachable through the AWS MCP Server, so investigations can run from agentic tooling. Preview quotas cap usage at 10 investigations per account per day. By Steef-Jan Wiggers

When I first looked at Solon Cloud, I expected another opinionated microservice framework—the kind that tells you exactly which registry, which config center, and which message queue to use. What I found instead was a different philosophy: a set of interface standards with swappable plugin implementations . You write your code against the interfaces, and switching from local development to production Cloud is a YAML change, not a code rewrite. Let me walk through how it works. The Core Idea: An Anti-Corruption Layer Solon Cloud isn't a single product. It's a collection of 13 service interfaces backed by a plugin ecosystem. The official docs call it a "通用防腐层" (general anti-corruption layer), and the name fits. Here's the architecture: Your Business Code ↓ (uses CloudClient or annotations) ┌─────────────────────────────────────┐ │ Solon Cloud Interfaces │ │ (CloudConfigService, CloudEvent, │ │ CloudDiscoveryService, ...) │ ├─────────────────────────────────────┤ │ Plugin: local │ Plugin: water │ │ Plugin: nacos │ Plugin: consul │ │ Plugin: ... │ │ └─────────────────────────────────────┘ Your code depends on the interfaces. The plugins implement them. You swap the dependency and the YAML config—the code stays untouched. The 13 Service Interfaces From the official family page, Solon Cloud defines these capability interfaces: Interface Purpose CloudConfigService Distributed configuration CloudDiscoveryService Service registration & discovery CloudEventService Distributed event bus CloudFileService Distributed file storage CloudI18nService Distributed i18n CloudIdService Distributed ID generation CloudJobService Distributed scheduled jobs CloudListService Distributed whitelist/blacklist CloudLockService Distributed locking CloudLogService Distributed logging CloudMetricService Distributed metrics CloudTraceService Distributed tracing CloudBreakerService Circuit breaker Each interface has a corresponding configuration namespace ( solon.cloud.@@.xxx ) and a set of plugin im

The same parser, four times Over the last year I kept running into the same shape of problem: A docs site generator that wanted Markdown chapters turned into navigation JSON. A RAG ingestion script where each Markdown file needed to become a list of text chunks plus its frontmatter metadata. An n8n flow that took Markdown emails and extracted only the tasklists. A static-site backend that accepted user Markdown and needed to validate structure before persisting. Each one is small on its own. But every time I reached for a different library — remark here, gray-matter there, marked once, a hand-rolled regex once too many — and every time one of them broke on the same edge cases: Nested GFM tasklists where the checked state was silently lost YAML frontmatter that included quoted booleans (parsed as strings, not booleans) Tables whose headers contained spaces (regex parsers treated them as one key) Code blocks containing Markdown — re-parsed as Markdown instead of fenced code So I built one endpoint that does it once, properly. What it returns POST /v1/parse takes a Markdown body ( text/markdown ) or a JSON envelope ( application/json ) and returns one stable JSON shape: { "success" : true , "data" : { "title" : "Project Alpha" , "frontmatter" : { "title" : "Project Alpha" , "status" : "shipping" }, "headings" : [ { "level" : 1 , "text" : "Project Alpha" , "id" : "project-alpha" } ], "sections" : [ { "heading" : { ... }, "children" : [ ... ], "content" : [ ... ] } ], "lists" : [ { "ordered" : false , "items" : [ "ship MVP" , "write README" ] } ], "tasklists" : [ { "items" : [ { "text" : "ship MVP" , "checked" : true } ] } ], "tables" : [ { "headers" : [ "Module" , "Status" ], "rows" : [{ "Module" : "API" , "Status" : "Done" }] } ], "codeBlocks" :[ { "lang" : "js" , "value" : "..." } ], "links" : [ { "text" : "..." , "url" : "https://..." } ], "paragraphs" :[ "..." ], "ast" : null } } The sections tree is the part I care most about. It's not just a flat list of headings

Cloud migration used to be a simple pitch: move off your servers, save money, scale on demand. For Indian enterprises today, the decision is more layered. Compliance rules have tightened. Cloud bills have grown unpredictable. And the assumption that a global hyperscaler is automatically the right fit is being questioned more often, especially by mid-size companies with real workloads and real budgets on the line. If your organisation is planning a migration, here's what actually matters before you sign a contract. Start with why you're migrating Most migrations get justified with one of three reasons: cost, scale, or compliance. Rarely all three at once, and the reason should shape the plan. If cost is the driver, look closely at your current spend. Bandwidth charges, storage tiers, and auto-scaling fees add up in ways that rarely match the sticker price teams budgeted for. If scale is the driver, the question is whether your workload actually needs the breadth a hyperscaler offers, or whether you're paying for hundreds of services you'll never touch. If compliance is the driver, data residency and audit requirements should be the first filter, not an afterthought. Data residency and compliance For Indian businesses, DPDP Act requirements, along with RBI and SEBI guidelines for regulated sectors, increasingly dictate where data can legally sit. This isn't a checkbox. It determines your shortlist of providers before pricing even enters the conversation. Confirm three things with any provider: where the datacentres physically are, whether the billing entity is India-registered, and whether the provider can produce compliance documentation on request, not just a marketing claim. A provider that can name the datacentre city and the entity name without hesitation has usually done the legwork. One that answers in generalities probably hasn't. The real cost of a migration Sticker price is the easiest number to compare and the least useful one. The real cost includes egress

We had a gitflow pipeline that looked clean on paper: develop feeds a release branch, the same build artifact promotes through dev, qa, sit, uat, and prod, and once prod is green we tag the commit on main. Textbook. Then a production bug showed up on a Tuesday afternoon, and the diagram stopped mattering. The standard gitflow answer is to branch a hotfix off the tag, PR it back into release, run it through the pipeline, and once it's proven in UAT, merge to main and cherry-pick the same commit back into develop. We built exactly that. It works. Until you ask the question nobody wants to answer out loud: release still has whatever was mid-flight when you cut the last tag. Untested code. Feature work three sprints deep in QA, sitting on the same branch you're now supposed to route your hotfix through. So the real question we ended up arguing about wasn't "how do we release a hotfix." It was "do we trust the release branch enough to put a hotfix through it." Most of the time, the honest answer is no. The gate everyone obsesses over is the wrong one Five environments, five sign-offs, a change ticket for each one: that's the smell people point at first when a pipeline feels slow. It's real. It's just not the dangerous one. A slow gate costs you time. A gate you route around because you didn't trust your own process costs you an incident. Here's what we landed on after the argument: release the hotfix directly from the hotfix branch, not through release. On Azure, that means deploying to the UAT slot, smoke-testing against production data shape, then toggling the slot. Same infrastructure, same config, none of release's baggage riding along. Once it's live, cherry-pick the commit into both develop and main, retag, and let the normal pipeline catch up on its own schedule whenever it gets there. That's a smaller number of gates (one real test in the slot, one human sign-off) that actually mean something, instead of five theatrical ones inherited from a process built for pla

Nota: ✋ This post was originally published on my blog wiki-cloud.co Introduction Artificial intelligence is evolving at an unprecedented pace and is transforming how people and businesses interact with technology. Over the past few years, much of the focus has been on generative AI models, which can create text, images, code, audio, and other types of content from natural language instructions. These capabilities have marked a significant and transformative shift in how we perform many tasks, allowing AI to move from a specialized technology to an accessible tool for millions of users. However, we are entering a new stage. Artificial intelligence models are no longer limited to simply answering questions or generating content. They can now be autonomous, understand objectives, analyze context, decide what steps to take, use tools, consult different sources of information, connect with APIs, execute actions, and collaborate with other specialized agents to complete more complex tasks. This evolution is giving rise to what is known as agentic artificial intelligence, an approach in which AI systems can act with a greater level of autonomy and actively participate in business, technical, and operational processes. Instead of simply offering a recommendation, an agent can search for information, validate data, coordinate different activities, and execute a sequence of actions aimed at achieving a specific goal. Within this new scenario appears Google Agent Development Kit , also known as Google ADK , is an open-source framework developed and designed by Google to facilitate the creation, evaluation, and deployment of artificial intelligence agents. ADK provides developers with a structure for defining agent behavior, connecting them to language models and external tools, managing sessions and memory, coordinating multi-agent systems, and evaluating their performance before deploying them to production. Thanks to this code-based approach, Google ADK allows you to build e

1. Introdução: Conectando IaC e Automação Nos artigos anteriores desta série, exploramos a poderosa combinação de Terraform e YAML para gerenciar configurações de infraestrutura em múltiplos ambientes, desde os conceitos básicos até padrões avançados de deep merge e modularização. No entanto, a verdadeira força da Infraestrutura como Código (IaC) se manifesta quando integrada a um pipeline de Integração Contínua e Entrega Contínua (CI/CD). É no CI/CD que a promessa de provisionamento automatizado, consistente e seguro da infraestrutura se torna realidade. Este artigo se aprofundará na implementação prática desses conceitos em um projeto real de CI/CD. Abordaremos a estrutura ideal do repositório, as etapas essenciais de um pipeline, estratégias de branching, considerações de segurança e as melhores práticas para garantir que sua infraestrutura seja implantada de forma eficiente e confiável. 2. Estrutura do Repositório para CI/CD Eficaz Uma estrutura de repositório bem definida é crucial para a organização e automação em um ambiente de CI/CD. Ela deve refletir a separação entre código Terraform e dados YAML, além de acomodar múltiplos ambientes e serviços. . (root do repositório) ├── README.md ├── .github/workflows/ # Ou .gitlab-ci/, .azure-pipelines/, etc. │ └── terraform.yml ├── terraform/ # Código Terraform genérico e módulos │ ├── main.tf │ ├── variables.tf │ ├── outputs.tf │ └── modules/ │ ├── vpc/ │ │ ├── main.tf │ │ └── variables.tf │ └── webserver/ │ ├── main.tf │ └── variables.tf └── config/ # Dados de configuração YAML por ambiente/serviço ├── global.yaml ├── environments/ │ ├── dev/ │ │ ├── base.yaml │ │ └── services/ │ │ ├── webapp.yaml │ │ └── database.yaml │ ├── staging/ │ │ ├── base.yaml │ │ └── services/ │ │ ├── webapp.yaml │ │ └── database.yaml │ └── prod/ │ ├── base.yaml │ └── services/ │ ├── webapp.yaml │ └── database.yaml └── services/ ├── defaults/ │ ├── webapp.yaml │ └── database.yaml └── overrides/ ├── webapp-prod.yaml └── database-dev.yaml Exp

Most of us run kubectl apply -f dozens of times a day without thinking about the machinery it sets in motion. But when something breaks, a Pod stuck in Pending , a Service that won't route, a Deployment that never converges, understanding that machinery is the difference between guessing and debugging. In this article, I'll map the end-to-end flow onto the actual Kubernetes architecture, so you can see not just what happens, but which component is responsible at every step. The Architecture at a Glance Kubernetes is split into two planes: Control plane: the brain. It makes decisions: what should exist, where it should run, and whether reality matches intent. Worker nodes: the muscle. They run your actual workloads and report back. Here's the full picture, with the request flow numbered: (1) apply YAML → API Server (5) Kubelet asks runtime to start container (2) spec persisted in etcd (6) runtime pulls image & runs it (3) controller reconciles spec (7) CNI assigns Pod IP, joins network (4) scheduler assigns a node (8) Kubelet reports status back Now let's walk through the flow, component by component. Step 1: The Cluster Exists Before Your App Does A Kubernetes cluster is the combination of a control plane and a set of worker nodes. The control plane components (API Server, etcd, Controller Manager, Scheduler) can run on dedicated nodes or, in managed offerings like RKE2/EKS/GKE/AKS, be entirely abstracted away from you. Either way, they're always there, always watching. Step 2: You Declare Intent in YAML You don't tell Kubernetes how to run your app, you describe what you want. Typically that's a set of manifests: Deployment: how many replicas, which image, update strategy Service: a stable virtual endpoint in front of ephemeral Pods ConfigMap/Secret: configuration decoupled from the image This declarative model is the foundation of everything that follows. Kubernetes' whole job is to close the gap between your declared state and reality. Step 3: kubectl apply -f Hi

Amazon EKS has recently introduced support for Kubernetes version rollbacks, letting practitioners revert a cluster's control plane to its previous Kubernetes version within 7 days of an upgrade if issues arise. The feature reduces the risk of in-place cluster upgrades by giving teams a safety net to recover quickly from problematic updates. By Renato Losio

1. Introdução: Rumo à Infraestrutura como Código de Nível Empresarial Nos artigos anteriores desta série, estabelecemos os fundamentos da separação de código e dados no Terraform com YAML (Artigo 1) e exploramos técnicas intermediárias de modularização e provisionamento dinâmico (Artigo 2). Agora, no terceiro e último artigo, mergulharemos em padrões avançados que são essenciais para gerenciar infraestruturas complexas e escaláveis em ambientes corporativos. O foco será em como lidar com hierarquias de configuração intrincadas, mesclar dados de forma inteligente e integrar essa abordagem em fluxos de trabalho de CI/CD. À medida que a infraestrutura cresce, a necessidade de abstração e automação se torna ainda mais crítica. Este artigo abordará: Deep Merge de Configurações: Como combinar dados de múltiplos arquivos YAML de forma hierárquica, onde configurações mais específicas sobrescrevem as mais genéricas. Gerenciamento de Múltiplos Arquivos YAML: Estratégias para organizar e carregar configurações de diferentes escopos (global, ambiente, serviço, região). Integração com CI/CD: Como automatizar o processo de implantação de infraestrutura usando essa abordagem em pipelines de integração contínua e entrega contínua. 2. Deep Merge de Configurações: Mesclando Dados Hierarquicamente Um dos maiores desafios ao gerenciar configurações em múltiplos níveis (global, ambiente, serviço) é a necessidade de mesclar mapas de formaprofunda, onde valores de níveis mais baixos (mais específicos) sobrescrevem ou complementam valores de níveis mais altos (mais genéricos ou padrões). A função merge nativa do Terraform realiza uma mesclagem superficial, o que significa que ela apenas mescla o primeiro nível de chaves, e se uma chave existir em ambos os mapas, o valor do segundo mapa prevalece. Para mapas aninhados, isso não é suficiente. [1] 2.1. O Desafio do merge Superficial Considere a seguinte estrutura de configuração: config/global.yaml : webserver : instance_type : t2.micro min_s

1. Introdução: Elevando a Abstração no Terraform No Artigo 1 desta série, exploramos os fundamentos da separação de código e dados no Terraform utilizando arquivos YAML e a função yamldecode . Aprendemos a carregar configurações básicas por ambiente, o que já representa um avanço significativo na organização de projetos de Infraestrutura como Código (IaC). No entanto, à medida que a infraestrutura se torna mais complexa, a simples leitura de um arquivo YAML pode não ser suficiente para manter a modularidade e evitar a duplicação de código. Este segundo artigo aprofundará nas técnicas intermediárias, focando em como combinar a flexibilidade do YAML com os poderosos recursos de modularização do Terraform. Abordaremos a passagem de configurações YAML para módulos, o uso do meta-argumento for_each para provisionamento dinâmico de recursos e módulos, e a aplicação de funções como lookup e condicionais para lidar com a variabilidade e opcionalidade dos dados de configuração. 2. Modularização com Dados YAML A modularização é um pilar fundamental para a construção de infraestruturas escaláveis e manuteníveis no Terraform. Módulos permitem encapsular um conjunto de recursos relacionados, tornando-os reutilizáveis em diferentes partes do seu projeto ou em outros projetos. Ao combinar módulos com dados YAML, podemos criar componentes de infraestrutura altamente configuráveis. 2.1. Estrutura de Projeto com Módulos Vamos expandir a estrutura de diretórios do Artigo 1 para incluir um módulo de exemplo: . (root do projeto) ├── main.tf ├── variables.tf ├── outputs.tf ├── environments/ │ ├── dev.yaml │ ├── staging.yaml │ └── prod.yaml └── modules/ └── webserver/ ├── main.tf ├── variables.tf └── outputs.tf 2.2. Definindo o Módulo webserver O módulo webserver será responsável por provisionar uma instância de servidor web (por exemplo, uma instância AWS EC2). Ele receberá suas configurações como variáveis de entrada. modules/webserver/variables.tf : variable "instance_type" { descripti

Airbus selected Scaleway as its sovereign cloud provider after a tender that scored protection against non-European extraterritorial legislation alongside technical capability. Airbus frames it as complementing multi-cloud, not exiting AWS. Practitioners note the pattern is spreading past hyperscalers to small US SaaS vendors, and that sovereignty claims still require verifiable controls. By Steef-Jan Wiggers

The headline going around is that Spark 4.2 can retire your vector database. That's half true, which is the most dangerous kind of true. Spark did add real vector search, and for some workloads it genuinely removes a whole system from your stack. For others, you'd regret dropping your vector DB. Here's the honest version. The short answer If your vectors already live in your data platform and your searches are batch or analytical, Spark 4.2 can absolutely replace a separate vector database. If you're serving live, low-latency retrieval for a chatbot or search box, you probably still want a dedicated one. It's a "depends on the workload" answer, and the details matter. What Spark 4.2 actually added Spark 4.2 brought vector search into plain SQL. No bolt-on library, no separate engine. The new primitives include vector distance and similarity functions, vector normalization, vector aggregation like sum and average, and the headline one, NEAREST BY, a top-K ranking join that finds the closest matches by distance. In practice that means you can store embeddings in a Spark table and run a similarity search with SQL you already know. Those operations cover the real use cases: retrieval, recommendations, entity resolution, and candidate generation. Databricks is openly framing this as Spark becoming an AI serving layer, not just a batch engine. Why this is a big deal The value isn't that Spark invented vector search. Plenty of tools do it. The value is that you can keep your retrieval pipeline on one platform. Think about the normal setup today. Your data sits in a lakehouse or warehouse. To do vector search, you spin up a separate vector database, then build a pipeline to copy and sync embeddings into it, and keep the two in step forever. That's a second system to run, secure, pay for, and debug at 2 a.m. Spark 4.2 lets you skip that for a lot of cases. The embeddings stay where your data already is, and the search runs right there. Fewer moving parts is a real win, and i

Moonshot launched Kimi K3, and within 48 hours it had to stop taking new subscribers. Not because the model flopped, but because too many people wanted it. That's a strange kind of problem to have, and it's telling you something important about where AI's real bottleneck now sits. What actually happened Less than two days after Kimi K3 went live, Moonshot froze new subscriptions. The reason was blunt: demand had eaten through its available GPU capacity. In the company's own words, the model got "far more love than we expected," and in 48 hours usage pushed close to the limit of what its hardware could serve. Moonshot handled it reasonably. Existing users kept their access, and the company said it would expand capacity and reopen signups in batches. It also split its plans into two tiers, a general Kimi Membership for web and app use, and a separate Kimi Code Membership aimed at programming work. That split is a hint about which users are burning the most compute. Why the model drew that kind of demand Kimi K3 isn't a minor release. It's an open-weight model at 2.8 trillion parameters, and it reportedly beat Anthropic's Fable 5 and OpenAI's GPT-5.6 Sol on front-end coding tests. Open, cheap, and competitive on real coding is exactly the combination developers pile onto. So they did. The real story: the bottleneck moved Here's the part worth internalizing. For years the hard, expensive problem in AI was training. That's where the giant compute bills and the headlines were. Kimi K3's freeze shows the constraint shifting to inference, the cost of actually running the model for users, every request, every day. Agentic workloads are why. When an AI agent runs a coding task for minutes or hours instead of answering a single prompt, each user consumes far more compute than a chatbot ever did. Multiply that by a viral launch and you hit a GPU wall fast. Moonshot didn't run out of ideas. It ran out of chips to serve the ideas. Why this matters even if you never touch Kimi Thi

Hetzner is experimenting with LLM inference. That is not a sentence I expected to write, but I think it is pretty interesting :) Before anyone moves their production AI workloads to Hetzner: this is very much an experiment . There is no billing, no SLA, no production guarantee, and currently only one model. Hetzner says it wants to learn whether people actually want this, how the system scales, which features matter, and what kind of load it can handle. So this is not a finished product launch. It is Hetzner putting something early in front of users and seeing what happens. I really like that approach. What Is Hetzner Inference? Hetzner Inference is an OpenAI-compatible API running on Hetzner's own infrastructure. You create an API token in the Experiments dashboard, point an OpenAI client at Hetzner's base URL, and use it like most other inference APIs. Right now, the only available model is Qwen/Qwen3.6-35B-A3B-FP8 . It is a 35-billion-parameter Mixture-of-Experts model with 3 billion active parameters. It accepts text and images, has a 262K context window, and uses FP8-quantized weights. That is a perfectly reasonable model for an experiment. It is small enough to serve without a ridiculous GPU cluster, but still useful enough to test the API with real workloads. Hetzner also published a short tutorial for connecting OpenCode to the API , if you want to try it without writing any code. I Tried It Because the API is OpenAI-compatible, there is almost nothing special about the integration: pip install openai from openai import OpenAI client = OpenAI ( base_url = " https://inference.hetzner.com/api/v1 " , api_key = " YOUR_TOKEN " , ) response = client . chat . completions . create ( model = " Qwen/Qwen3.6-35B-A3B-FP8 " , messages = [ { " role " : " user " , " content " : " Explain why the sky is blue in one sentence. " } ], extra_body = { " chat_template_kwargs " : { " enable_thinking " : False , } }, ) print ( response . choices [ 0 ]. message . content ) The enabl

Eae gente bonita, beleza? Depois de um longo período, resolvi voltar aqui e continuar compartilhando...

Google just made multi-region Cloud Run significantly easier. Here is the full picture; what changed, what it means in practice, and how to build it right. Most teams discover they need multi-region architecture the hard way and sadly, during an outage. Whether you're running a global e-commerce platform, a real-time gaming API, or a financial services application, users expect your service to be available whenever they need it. There is a conversation that happens in almost every engineering team at some point. It usually starts with a post-mortem. A regional Google Cloud outage or a Cloud Run service that hit a cold start spike, or a single-region deployment that could not handle the latency demands of users spread across Lagos, Nairobi, and London simultaneously, caused enough pain that someone finally asked: why are we only deployed in one region? The answer is usually one of three things: it felt complex, it felt expensive, or no one had prioritised it yet. In July 2026, Google moved Cloud Run Service Health to General Availability and the timing was hard to miss. Six days earlier, a power cut at Google's Netherlands data centre had knocked three services offline. The GA release brings automatic cross-region failover to Cloud Run with what Google describes as a two-step setup: add a readiness probe, set minimum instances to at least 1. The load balancer does the rest. This article covers the full architecture, what Service Health is, how readiness probes underpin it, how to set up the Global Load Balancer correctly, and how to test that failover actually works. It also covers the production details. What changed: Service Health and readiness probes Before Service Health, multi-region Cloud Run required you to implement a /health endpoint in your application and configure a separate HTTPS health check at the load balancer level. This worked, but it had a significant gap. The load balancer's health check only knew whether the Cloud Run service endpoint was respon

Claude Opus/Sonnet Voice Mode, Open-Weight Model Cost Savings, & GitHub AI Agent Security Today's Highlights This week's top stories focus on major commercial AI model updates, practical tools for cost-effective LLM deployment, and critical security vulnerabilities in AI-powered developer tools. Anthropic expands its multimodal voice capabilities to more powerful Claude models, while a new 'Show HN' project promises significant cost reductions with open-weight models. Claude’s voice mode is now available for Opus and Sonnet (The Verge AI) Source: https://www.theverge.com/ai-artificial-intelligence/970065/anthropic-voice-mode-claude-opus-sonnet-haiku-ai Anthropic has rolled out its voice mode capability to its more powerful Claude Opus and Sonnet models, extending a feature previously exclusive to the faster, lighter Haiku model. This enhancement allows developers to integrate advanced multimodal conversational AI into their applications, enabling real-time voice interactions with a higher degree of intelligence and nuance than previously possible. For instance, developers can now build voice agents that not only understand complex spoken queries but also provide sophisticated, context-aware responses, leveraging the deep reasoning and comprehensive knowledge base of Opus and Sonnet. This update significantly expands the potential for developers to create more natural and intuitive user experiences across various domains, from customer service and educational tools to interactive creative assistants. By making Opus and Sonnet accessible via voice, Anthropic is addressing a key demand for richer human-computer interaction, pushing the boundaries of what commercial AI APIs can offer in terms of multimodal capabilities. This move facilitates the creation of next-generation applications where seamless voice interaction is paramount, without sacrificing the underlying intelligence of the AI model. Comment: This is a huge step for building more capable voice-first applicat

In my research on the topic of Azure and Cloud, Gemini mentioned the Cloud Resume Challenge , which I looked into and picked up a copy of the book for. This post will outline my steps as I work through it 😁. Week 00 :: AZ-900 The goal here is to work through necessary course-work so I can quiz for and obtain the Microsoft AZ-900 certification. I enrolled myself in the Microsoft Cloud Support Associate Professional Certificate offered by Coursera and, as I get closer to completing it, will keep this post up to date on my status... In lieu of just studying, I am jumping ahead to work on the project, which will be outlined below. Week 01 :: Cloud Resume (Front-End) 07/23/2026 Yesterday (and today) I worked on creating / securing my Azure account, setting up my environment for Azure development and building the front-end. The development environment is VS Code with the Azure Extensions, Azure CLI and Azure Functions Core Tools. The website is, in its current state, an exact replica of my PDF resume... made with Vue.js. I will be adding a separate page based solely around this project as I included Vue Router and already worked through layout components, a 404 page, etc.

It started with a billing alert. Estimated charges had crossed $250. Not scary money, but enough to make me look. And what actually caught my attention wasn't the number, it was the alert itself. I'd clearly set this up at some point, and the threshold felt stale. So I went looking for where the alert lived. It came from a BillingAlerts CloudFormation stack I created back in 2014 and completely forgot about. So a thing I forgot about was warning me about all the other things I'd forgotten about. I opened my stack list and that's when I saw it wasn't alone. It was sitting in a lineup of stacks, and I didn't recognise half of them. Years of leftovers, just sitting there. The stuff you forget about doesn't break anything. It doesn't page you at 2am. It just sits there, quietly billing, until you glance at the invoice and can't remember what half of it is for. Forgotten, still-running resources are one of the biggest sources of wasted cloud spend, by some estimates around a quarter of the average cloud budget . I came to update one alert and I found a mess. To be clear, these stacks weren't really costing me much. Stopped instances, a few half-deleted leftovers. If they'd been the $252, the alert would've tripped every month. But that's the point. You can't tell what's actually costing you until the clutter is gone. So the alert could wait. I wanted these stale stacks gone first. Normally this is a chore. Open the console, find each stack, click delete, wait, refresh, check if it worked, OR write out CLI commands. It's not hard, just tedious. The kind of task I keep putting off. And that's exactly how this started. ClickOps through the console. I'd just finished deleting an old Directory Service directory over in the Mumbai region by hand, clicking through the screens and waiting out the spinner, when it hit me. Barely ten minutes of manual clicking, and I still had a pile of stacks to go. I didn't have to do any of this myself. Why was I still clicking? I opened Kiro ,