标签：#aws

Throughout my career, transitioning between CTO roles and, more recently, focusing purely on distributed systems architecture and high-performance engineering, I've seen many architectural patterns rise and fall. But few have caused as much silent damage to company bottom lines as the premature adoption of microservices. Over the last decade, the industry bought into the idea that, in order to scale, you needed to split your system into dozens (or hundreds) of independent services. The practical result I find in most companies? The creation of the dreaded "Distributed Monolith." The Anatomy of Waste: Networks vs. Memory The hard truth we need to face with maturity is that microservices primarily solve problems of organizational scale (Conway's Law), not necessarily performance. If your engineering team isn't the size of Netflix or Uber, prematurely fragmenting your codebase is shooting yourself in the foot. Technically, what happens when we break down a monolith without the proper domain boundaries? We trade extremely fast and cheap local function calls (resolved in the processor's L1/L2 Cache) for slow and expensive network calls (TCP/IP). We start spending an absurd amount of computational time on constant JSON serialization and deserialization, and the AWS bill explodes with internal traffic costs (egress/ingress) between Availability Zones (AZs). You haven't scaled your application; you've merely added network latency and infrastructure complexity. The Return of the Modular Monolith True seniority in software engineering isn't about mastering the most complex architecture of the moment, but having the wisdom to know when not to use it. That's why the Modular Monolith has consolidated itself as the initial gold standard for new projects and restructurings. In a well-designed Modular Monolith (and languages with strong type systems and strict scope control, like Rust, shine absurdly well here), you maintain the logical separation of domains. Modules are independen

Amazon’s latest India investment comes as global tech companies race to expand AI infrastructure in the country.

Modern cloud deployments involve many tools with different lifecycles, creating a heavy burden on engineers. The Kubernetes ecosystem offers a unified Control Plane approach. Sharing best practices through tech talks and inner-source collaboration can create an engaged community and drive adoption. By Ben Linders

And by viral I mean from $0 to $31. Umami told me Clew Directive got 14 visits last month. AWS told me I owed $31 for it. That works out to $2.21 a visitor, which would make it the most expensive free learning-path tool in California. Spoiler alert: 14 visitors, $31, and not a single one of them was the reason. Something was off. Here is how Amazon Q, Claude, and a few hours of reading my own code untangled it. The app turned out to be innocent. What Clew Directive is, quickly A free, stateless tool that builds you a personalized AI learning-path PDF. You take a 60-second Vibe Check, four questions about your goals and how you learn, and it maps you to free, verified resources and hands you a briefing. No accounts, no database, no paywall, nothing stored about you. It runs on Amazon Nova, which is why it costs close to nothing to operate, which is also why a $31 bill made no sense. The name is the Theseus kind of clew. A ball of thread to find your way out of the maze. Less hype, more direction. Live at clewdirective.com . The number that didn't add up Twelve visitors, 14 visits, 93% bounce, average session about a minute. Referrers from Bing, Google, Yahoo, GitHub. Visitors from the US, India, Netherlands, Egypt, Ethiopia, Singapore. Mostly crawlers stopping by to say hello. A few curious humans and a parade of bots is not a $31 month. So either every visit was doing something enormous, or the bill was never about visits at all. The dashboard lied, politely. An Amazon Q Story My cost tracker said Clew Directive was running on Claude Sonnet. Sonnet is the expensive one. Case closed, right? I opened the repo. Clew Directive does not run Sonnet. The Navigator agent runs Amazon Nova 2 Lite. Scout and Curator run Nova Micro. The IAM policy is scoped to Nova ARNs only, so a Sonnet call from these functions would come back AccessDenied. The app physically cannot bill Sonnet. The math agreed. A full learning-path generation on Nova costs about two-tenths of a cent. Fourtee

Live demo: https://safestate.vercel.app , code: https://github.com/usv240/safestate A product recall today is basically a notice. It lives on a webpage, or a PDF, or an email that somebody is supposed to read. Say the problem out loud and it gets uncomfortable fast. A recalled crib can be listed and sold to another family, and nobody in that sale ever sees the recall. Reselling recalled goods is actually illegal, and recalled infant products have killed kids. I spent this hackathon building something to close that gap. I called it SafeState, and the idea is small: make the recall do something. When a second-hand item is listed or sold, the marketplace checks SafeState first, and recalled units get blocked right at checkout. It is precise down to the serial number, so safe units still sell. It runs on the stack this hackathon is about. A Next.js front end on Vercel, with Amazon Aurora DSQL behind it. Why DSQL is the whole point here The promise SafeState has to keep is this: the moment a recall lands in any region, no marketplace anywhere should ever read that product as "safe" again. That is a strong consistency problem, not a nice-to-have. If there is any window where a recalled product still looks safe, that is exactly when it gets sold. An eventually consistent store or a nightly sync leaves that window open. DSQL's active-active, multi-region setup with strong consistency is what closes it. I set up a real peered cluster across us-east-1 and us-east-2, with us-west-2 as the witness. Write a recall through one region's endpoint and you can read it back from the other region right away. There is a page in the app that lets you run that yourself. The one trick that makes it work DSQL runs on snapshot isolation (PostgreSQL REPEATABLE READ) with optimistic concurrency. It catches write-write conflicts at commit time. Snapshot isolation will not protect you from write skew, so I had to design around that. To guarantee that a recall and a sale of the same product actua

What just happened On June 22, 2026, AWS quietly launched Lambda MicroVMs. Not a Lambda feature update. A new compute primitive sitting between Lambda Functions (stateless, 15-min max) and EC2 (full VM, you manage everything). Each MicroVM is an isolated Firecracker VM with its own HTTPS endpoint, running your code from a pre-built snapshot. Stateful. Up to 8 hours. Suspend when idle, resume on demand. I tested it the same week. Here's what I found. The test setup A minimal Python HTTP server packaged as a Dockerfile: from http.server import HTTPServer , BaseHTTPRequestHandler import json , time , os class Handler ( BaseHTTPRequestHandler ): start_time = time . time () request_count = 0 def do_GET ( self ): Handler . request_count += 1 body = json . dumps ({ " message " : " Hello from Lambda MicroVM! " , " uptime_seconds " : round ( time . time () - Handler . start_time , 2 ), " requests_served " : Handler . request_count , " pid " : os . getpid () }) self . send_response ( 200 ) self . send_header ( " Content-Type " , " application/json " ) self . end_headers () self . wfile . write ( body . encode ()) HTTPServer (( " 0.0.0.0 " , 8080 ), Handler ). serve_forever () The Dockerfile: FROM public.ecr.aws/lambda/microvms:al2023-minimal RUN dnf install -y python3 && dnf clean all WORKDIR /app COPY app.py . EXPOSE 8080 CMD ["python3", "app.py"] How it works Three steps: Zip code + Dockerfile → upload to S3 create-microvm-image builds the container, starts the app, takes a Firecracker snapshot of memory and disk run-microvm launches from that snapshot Every launch resumes from the pre-initialized state. No cold boot. Your app is already running the moment the MicroVM starts. aws lambda-microvms create-microvm-image \ --name hello-microvm-test \ --code-artifact "uri=s3://my-bucket/artifact.zip" \ --base-image-arn arn:aws:lambda:us-east-1:aws:microvm-image:al2023-1 \ --build-role-arn arn:aws:iam::123456789:role/MicroVMBuildRole Image build took about 3 minutes. Once done: aw

Table of Contents The Moment That Changed Everything What It Actually Is The Setup Nobody Believes Is This Simple Focused Sessions — One Agent, One Mission Sub-Agents With Specific Skill Sets Building MCPs for Your Own Stack What We've Actually Achieved How It Became a Force Multiplier for Incident Response From OpenCode to FRIDAY — The Agent That Investigates Incidents Autonomously From FRIDAY to JARVIS — Thinking About Write-Path Autonomy Deleting 130,000 Accounts Without Writing Code Learning the Entire Product in Conversations Why This Is Different From ChatGPT The Uncomfortable Truth What's Next The Moment That Changed Everything It was 11pm on a Tuesday. A cache migration in our production environment had just caused thousands of authentication failures for two of our largest enterprise customers. Our VP of Product wanted answers. Our support team was fielding escalations. And our engineers were alt-tabbing between AWS console, Datadog, GitHub, Azure DevOps, and PagerDuty trying to piece together what happened. Three weeks later, when we needed to attempt the same change again, an engineer typed this into a terminal: "Review the ADO change ticket, compare the MOP against the actual ElastiCache configuration in prod region, check the K8s config repo for how Redis env vars are wired on the Green cluster, and tell me if this approach avoids the token validation failure that caused the previous customer impact." Fourteen seconds later , the system had pulled the work item, queried AWS ElastiCache across four regions, read the Kubernetes configuration from GitHub, cross-referenced the deployment patches, and delivered a precise technical assessment including a risk it identified that the team hadn't documented: in-flight tokens during the 30–60 second Global Accelerator propagation window. That system is OpenCode — an AI-powered CLI assistant connected to our entire operational stack through the MC(Model Context Protocol). And it has fundamentally changed how a 20-

devtools #infrastructureascode #cdk #aws Index TL;DR Major Features Bedrock AgentCore — From Alpha to Stable Fn::GetStackOutput & Weak Cross-Stack References Validations Framework Performance Improvements CloudWatch PromQL Alarms CLI Improvements New L2 Constructs Service Enhancements Community Highlights Community Content & Resources How Can You Be Involved Hey CDK community! Here's an update covering everything that shipped in April and May 2026. TL;DR Bedrock AgentCore graduated to stable — production-ready AI agent infrastructure with semver guarantees. Cross-region references got a major upgrade with native Fn::GetStackOutput support and weak cross-stack references. The new Validations framework replaces policyValidationBeta1 with a richer plugin system. And file fingerprinting is ~33% faster with persistent asset caching. These features are available in aws-cdk-lib v2.247.0 through v2.257.0 and aws-cdk CLI v2.1116.0 through v2.1125.0. Full changelogs on GitHub Releases ( Library | CLI ). Major Features Bedrock AgentCore — From Alpha to Stable The @aws-cdk/aws-bedrock-agentcore-alpha module has graduated to aws-cdk-lib/aws-bedrockagentcore — stable APIs, semver guarantees, production-ready. If you've been building AI agents with Bedrock but held off on CDK because of the alpha label, it's time to upgrade. ( #37876 ) AgentCore provides the core infrastructure for building AI agents: runtimes, gateways, identity management, observability, and online evaluation. The Policy submodule remains in alpha as it continues to evolve rapidly. ┌─────────────────────────────────────────────────────┐ │ Bedrock AgentCore (Stable) │ ├─────────────────────────────────────────────────────┤ │ │ │ ┌──────────┐ ┌──────────┐ ┌──────────────────┐ │ │ │ Runtime │ │ Gateway │ │ Identity │ │ │ │ (L2) │ │ (L2) │ │ (L2) │ │ │ └────┬─────┘ └────┬─────┘ └────────┬─────────┘ │ │ │ │ │ │ │ ▼ ▼ ▼ │ │ ┌──────────┐ ┌──────────┐ ┌──────────────────┐ │ │ │Observa- │ │Online │ │ Policy Engine │ │ │

Jump Tables, TLV Footers, and the Real Cost of Reading What You Don't Need You're paying for bytes you never read. A data engineer on a busy pipeline touches dozens of Parquet files a day: schema discovery, predicate pushdown, column pruning, metadata scrapes for a data catalog sync. In each case, the application needs maybe 200 KB of context from a file that is 4 GB on disk. Without a seekable archive format and a jump table to find the right frame, your HTTP client fetches the whole thing, and your cloud egress invoice reflects every unnecessary gigabyte. This post quantifies the problem, then walks through how HuskHoard uses seekable Zstd frames, a per-volume jump table, and TLV-encoded footer metadata to make partial egress a first-class citizen across multi-volume archives — disk, cloud, and LTO tape alike. The Problem, In Dollars S3 standard egress runs $0.09/GB. GCS is $0.08/GB. Even Cloudflare R2, which is free for egress from R2 to the internet , still costs you in latency and API call count when you cannot bound the range of bytes you need. Here is a representative read pattern for a cold analytics archive: Operation Bytes Needed Bytes Fetched (naïve) Ratio Schema discovery ~50 KB (Parquet footer) 1–8 GB (full file) ~1:16,000 Single column scan ~200 MB (one column chunk) 4 GB (full row group) 1:20 Data catalog sync (1M files) ~50 GB (footers only) ~4 PB (full files) 1:80,000 Selective restore (1 row group) ~128 MB 4 GB 1:32 On 100 TB of cold Parquet data with $0.09/GB egress: Full read for schema sync : 100 TB × $0.09 = $9,216 Partial read (footers only, avg 100 KB/file, 1M files) : ~100 GB × $0.09 = $9.00 Savings per catalog sync: $9,207 — 99.9% reduction Even a conservative column-scan scenario (pulling 15% of each file's bytes) cuts a $9,216 monthly read bill to $1,382 . The ceiling on savings is determined entirely by how precisely you can address the bytes you actually need. That precision is what frames and jump tables buy you. Zstd Frames: What They

Last year I was asked to investigate a startup's AWS bill. It had jumped from roughly $200/month to over $3,000 in a few weeks. Nobody knew why. After digging through logs, metrics, and database traffic, I found the culprit: a polling loop with no backoff strategy. The code looked harmless: async function processQueue () { const jobs = await getJobs () for ( const job of jobs ) { await processFile ( job ) } processQueue () } processQueue () At first glance, this seems reasonable. Process all available jobs, then check again. The problem appears when the queue is empty. When getJobs() returned no work, the loop immediately queried the database again. And again. And again. There was no delay, no backoff, and no event-driven trigger. As a result, the service continuously hammered the database looking for work that didn't exist. Each iteration generated: A database query Network traffic CPU usage Logging overhead Additional infrastructure load Individually, each operation was cheap. Executed hundreds of thousands of times per day, they became expensive. The fix was simple: async function processQueue () { while ( true ) { const jobs = await getJobs () for ( const job of jobs ) { await processFile ( job ) } await new Promise ( resolve => setTimeout ( resolve , 5000 )) } } Even better would have been replacing polling entirely with an event-driven design using a message queue. What this incident taught me: 1. Empty queues are production workloads. Many engineers optimize for peak traffic and forget about idle traffic. Systems often spend more time idle than busy. 2. Polling needs backoff. If you're polling, always define what happens when no work is found. 3. Cost bugs rarely look like bugs. Nothing crashed. No exceptions were thrown. The system was technically working exactly as written. It was just doing useless work 24/7. 4. Always monitor cost alongside performance. CPU, latency, and error rates looked normal. The AWS bill was the first real alert. One question I ask

AWS released Blocks in public preview, an open-source TypeScript framework where each Block bundles application code, local mocks, and AWS infrastructure. Designed for AI agents to write correct backends from the start, it runs locally without an AWS account and deploys the same code to Lambda, DynamoDB, Aurora, and Bedrock with zero changes. By Steef-Jan Wiggers

Building a Spring Boot application is only half the journey. At some point, every backend project reaches the next question: Where should this application actually run? If you are deploying on AWS, two common options are: Amazon EC2 Amazon ECS Both can run the same Dockerized Spring Boot application. But they are not the same kind of deployment model. EC2 gives you a server. ECS gives you container orchestration. Choosing between them is less about which one is “better” and more about which one fits the stage of your application. Starting with EC2 EC2 is the most direct way to run a Spring Boot application on AWS. You create a virtual machine, install what you need, and run your application. For a Dockerized Spring Boot app, the flow often looks like this: GitHub Actions ↓ SSH into EC2 ↓ Pull latest code or image ↓ Build / run Docker container ↓ Spring Boot app runs on EC2 The mental model is simple: One server One Docker container One Spring Boot application That simplicity is useful. Especially when you are launching an MVP, a freelancer project, an internal tool, or your first production version. Why EC2 Works Well for Many Spring Boot Apps EC2 is not outdated just because newer deployment platforms exist. For many applications, EC2 is enough. It works well when: traffic is predictable the application is small or medium-sized you want full control over the server you want simple debugging through SSH you do not need multiple replicas yet you want to keep infrastructure easy to understand A common setup might be: Spring Boot Dockerfile Docker Compose GitHub Actions EC2 That setup can be production-ready for many early-stage apps. It gives you: a real deployment target repeatable Docker builds automated deployment through GitHub Actions simple logs direct server access For a solo developer or small team, that matters. You can understand the entire deployment flow without needing a full container orchestration platform. The Tradeoff With EC2 The tradeoff is that you

AWS made Graviton5-powered EC2 M9g and M9gd instances generally available with 192 ARM cores, formally verified VM isolation via the Nitro Isolation Engine, and DDR5-8800 memory. ClickHouse reported 36% better performance with zero code changes. Meta committed tens of millions of cores. On-demand pricing is 9% above Graviton4, translating to roughly 15% better price-performance. By Steef-Jan Wiggers

Doing the work and being able to explain the work are two different skills. I've had the first one for 8 years. I'm building the second one now. I'm a Cloud Platform Engineer. AWS, Kubernetes, Terraform, Linux. Regulated environments, healthcare, production systems. Real experience. Almost zero public documentation of it. That's the gap I'm closing, starting from Day 1. The platform is KodeKloud. Each session gives you tasks across multiple tools. I'm posting the Linux and AWS tasks here. Here's what I built and what actually matters about each one. Task 1 (Linux): Create a User with a Non-Interactive Shell The task was to create a system user that can own processes but cannot log in interactively. This is what you do for service accounts. bash ssh user@hostname sudo su - useradd username -s /sbin/nologin cat /etc/passwd | grep username The /sbin/nologin shell is the important part. The user exists in the system, can own files and run processes, but cannot open a shell session. You verify by checking /etc/passwd because the last field in each line is the assigned shell. I've been doing this in production environments for years. I still verify every time. Not because I'm unsure. Because in a regulated environment, you don't assume, you confirm. Task 2 (AWS): Create an EC2 Key Pair via CLI aws ec2 create-key-pair \ --key-name my-key-pair \ --key-type rsa \ --key-format pem \ --query "KeyMaterial" \ --output text > my-key-pair.pem aws ec2 describe-key-pairs --key-names my-key-pair The private key is returned exactly once at creation. AWS does not store it. If you lose it, you generate a new one and replace it everywhere it was used. I've seen this cause real problems in production environments where the key wasn't backed up properly. Always run chmod 400 my-key-pair.pem after saving it. SSH will refuse to use a key file with open permissions. It won't tell you that's the reason straight away. What Day 1 Taught Me That 8 Years Didn't Nothing here was technically new to

You add a sixth Lambda trigger to your OrderEvents table, deploy it, and within 20 minutes your SLA dashboard goes red. Latency on order writes jumps from 4ms to 40ms. The function itself is fine. The table is fine. The problem is that five other Lambdas are already hitting the same partition key on every write, and you just made it six. DynamoDB's internal partition throttling doesn't care that each function looks clean in isolation. This is an N+1 trigger problem, and your AI coding assistant cannot catch it. Not because it lacks intelligence, but because the fact that five Lambdas already target that table lives in your AWS account and your full codebase — not in the file your assistant has open. Infrawise · npm Why the LLM Can't See the Pattern When you ask Claude to write a new order processing Lambda, it reads the file you have open and generates code that looks correct — because in the context of that one file, it is correct. It doesn't know about ProcessRefundsLambda , NotifyFulfillmentLambda , SyncInventoryLambda , UpdateAnalyticsLambda , and AuditTrailLambda , all of which you wrote in previous sprints and which all write to the Orders table. This is a category of failure that model quality doesn't fix. A better model produces a more fluent explanation for why your latency spiked. The fact that five functions converge on the same table is a lookup, not a prediction. The source of truth is a combination of your code (which functions exist) and your infrastructure (what they access). Infrawise draws that boundary explicitly. It extracts the answer from your code using AST parsing and from your infrastructure using API calls, then hands that graph to the model as structured context — it never generates the answer. How Infrawise Traces Trigger Chains to the Same Table When Infrawise scans your repository, it uses ts-morph to walk every CallExpression in every source file. It's not searching for the string "DynamoDB" — it matches call structure against a known

Introduction In the previous articles, we explored AWS networking concepts like: VPC Subnets Internet Gateway Security Groups Route 53 Now, let's move to one of the most popular AWS services: Amazon S3 (Simple Storage Service) Amazon S3 is one of the easiest AWS services to learn and one of the most widely used services in real-world applications. Almost every application stores some kind of data: Images Videos Documents Log files Backups Static websites Amazon S3 helps us store and retrieve these files securely from anywhere in the world. In this article, we will understand: What Amazon S3 is Buckets and Objects Benefits of S3 Storage Classes Versioning Basic security concepts Static website hosting overview Why Do We Need Storage? Imagine you are running an online photo-sharing application. Users upload: Profile pictures Photos Videos Where should these files be stored? Keeping them directly inside application servers is not a good idea because: Storage is limited. Scaling becomes difficult. Replacing servers may cause data loss. This is where Amazon S3 helps. What is Amazon S3? Amazon S3 stands for: Simple Storage Service It is a cloud-based object storage service provided by AWS. S3 allows us to: Store data Retrieve data Manage data from anywhere using the internet. Amazon S3 is designed to be: Highly available Durable Scalable Secure Cost-effective Real-World Example Think of Amazon S3 as a digital warehouse. Suppose you own an e-commerce company. Inside your warehouse, you store: Product images Invoices Customer documents Videos Similarly, Amazon S3 stores digital files safely in the cloud. Buckets and Objects Amazon S3 stores data using two concepts: Bucket A bucket is a container used to store files. Think of a bucket like a folder. Examples: company-documents customer-images application-logs Bucket names must be globally unique. Object Anything stored inside a bucket is called an Object . Examples: invoice.pdf profile.jpg backup.zip video.mp4 Objects can co

AWS recently introduced Amazon Cognito multi-region replication, which automatically replicates user identities and user pool configurations from a primary region to a secondary one. This enables applications to continue authenticating users from a replica region during outages, without requiring custom replication and failover mechanisms. By Renato Losio

Google Open Knowledge Format: Why Enterprise Agents Need a Knowledge Layer, Not Just More Tools Most enterprise AI conversations still start in the wrong place. They start with the model. Which model should we use? Which framework should we adopt? Which vendor has the best agent platform? Which tools should we connect next? These are fair questions. But in real enterprise architecture, they are not the hardest questions. The harder question is this: Can our AI systems actually understand how our business works? That is why Google Cloud’s article on Open Knowledge Format caught my attention. The article talks about a simple but important idea: representing knowledge in a way that humans can read and machines can use. In OKF, that means markdown for the content and structured metadata for context. At first glance, that may sound too simple. But that simplicity is the point. Enterprises do not need another place where knowledge goes to die. We already have enough portals, catalogs, wikis, dashboards, folders, and internal tools. What we need is a practical way to package knowledge so it can be reviewed, versioned, governed, searched, and reused by both people and AI agents. That is where this idea becomes very relevant for agentic AI. The Real Enterprise AI Problem Most organizations already have the knowledge their AI agents need. They have it in databases, dashboards, tickets, architecture notes, runbooks, Confluence pages, data catalogs, code comments, incident reports, old project documents, and the heads of experienced employees. The issue is not that knowledge does not exist. The issue is that it is fragmented. Some of it is outdated. Some of it is duplicated. Some of it is tribal. Some of it is locked inside tools. Some of it is written for humans but not structured enough for AI systems to use reliably. This becomes a serious problem when we move from AI assistants to AI agents. An assistant can give a helpful answer. An agent does more. It plans, selects tools

AWS just launched AWS Blocks, an open-source TypeScript framework that gives you backend capabilities...

Certifications help when they match a role and are backed by proof — not as a scoreboard. The problem Beginners are told certifications are the key to IT, so they buy the most popular one, pass it, and are surprised when interviews still go badly. A certificate proves you can pass an exam; it does not, on its own, prove you can do the job. Why this matters now Certifications remain useful signals, and official providers like CompTIA, Microsoft, AWS, Cisco and Google keep their exam objectives public and current. But as AI makes it easier to grind practice questions, employers lean harder on whether you can actually apply the knowledge. The value of a certificate is increasingly in what you can demonstrate alongside it. There is also a cost reality. Exams, courses and retakes add up in money and time, and career changers usually have limited amounts of both. Spending three months and a chunk of savings on a certificate that no target role actually asks for is one of the most common and most avoidable mistakes in an IT transition — which is exactly why the order you choose them in matters. The practical framework Use certifications as targeted evidence, not as a scoreboard. Three rules: Match objectives to a job. Open the certification's published objectives next to a real job description. Overlap means it is relevant; no overlap means it is a hobby. Prove the same skills in practice. For each major objective, build one small artefact that shows you can do it, not just recall it. Stop at enough. One well-chosen, well-demonstrated certification beats three unrelated ones. Sequence them to roles, not to availability. Which one first? Let the target role decide, not the brand with the loudest marketing. As a rough guide: a vendor-neutral foundation (such as CompTIA A+ for general IT support, or Network+/Security+ as you specialise) suits broad support roles; a cloud-fundamentals exam (Microsoft Azure or AWS) suits cloud-leaning roles; Cisco-flavoured paths suit networkin