DEV Community: Durrell Gemuh

EKS vs ECS vs Fargate: Choosing AWS Container Compute

Durrell Gemuh — Tue, 01 Sep 2026 23:53:23 +0000

"Should we use EKS?" is one of the most over-answered-with-yes questions in AWS. Kubernetes is
powerful, but it's not free, in money or operational effort. Here's how I actually decide between
ECS, EKS, and Fargate.

First, separate two questions

These are different choices people conflate:

Orchestrator: ECS or EKS (Kubernetes)?
Compute mode: EC2 (you manage nodes) or Fargate (serverless, AWS manages nodes)?

You pick one from each. "Fargate" isn't an alternative to EKS, you can run EKS on Fargate or
ECS on Fargate.

ECS: the pragmatic default

Amazon ECS is AWS's own orchestrator. It's simpler, deeply integrated, and has no control-plane
cost.

Choose ECS when:

You want to run containers without learning Kubernetes.
Your team is small and values low operational overhead.
You're all-in on AWS and don't need portability.

Trade-off: less ecosystem (no Helm, no Operators, fewer third-party tools) and it's AWS-only.

EKS: when you need Kubernetes specifically

Amazon EKS is managed Kubernetes. You get the entire K8s ecosystem, Helm, ArgoCD, Operators,
service meshes, and portability across clouds.

Choose EKS when:

You already have Kubernetes expertise or need its ecosystem (GitOps, Operators, mesh).
You want workload portability across clouds/on-prem.
You're running enough services that the platform investment pays off.

Trade-off: real operational weight (upgrades, add-ons, RBAC, networking) and a control-plane
cost. Don't adopt EKS for three services, that's over-engineering.

EC2 vs Fargate (the compute mode)

Fargate (serverless): no nodes to patch, scale, or capacity-plan. Pay per task's CPU/memory. Best for variable, bursty, or low-ops workloads. Slightly higher per-unit cost; cold-ish starts.
EC2: you manage the nodes, but get cheaper steady-state cost, GPUs, DaemonSets, and full control. Best for high, steady load or special requirements.

A common sweet spot: Fargate for spiky/low-volume services, EC2 node groups for the steady base.

A decision shortcut

Need the Kubernetes ecosystem or multi-cloud portability?
  ├─ Yes → EKS
  │        ├─ Small/variable workloads → EKS on Fargate
  │        └─ Steady/large or special (GPU, DaemonSets) → EKS on EC2
  └─ No  → ECS
           ├─ Low ops / variable → ECS on Fargate
           └─ Cost-sensitive steady load → ECS on EC2

Cost reality

Control plane: ECS is free; EKS charges per cluster-hour.
Compute: EC2 is cheaper per unit at steady load; Fargate wins when things are idle/bursty (no paying for empty nodes).
Hidden cost: EKS's biggest cost is often engineering time, not the invoice. Factor it in.

The honest recommendation

Most teams under ~20 services, AWS-only: start with ECS on Fargate. It's boring, cheap to operate, and ships fast.
Teams that need K8s' ecosystem or run at real scale: EKS, with Fargate for variable workloads and EC2 for the steady base.
Don't pick EKS because it's on your CV. Pick it because you need what it offers. (My Enterprise Kubernetes case study is where EKS did earn its place, 50+ services, GitOps, mesh.)

The best architecture is the simplest one that meets the requirement. Often that's ECS, and that's
a feature, not a compromise.

How to Become an AWS Community Builder: Complete Guide for 2027 Applications

Durrell Gemuh — Sun, 23 Aug 2026 12:31:52 +0000

The AWS Community Builders program opens applications once a year, typically in early January, and closes within about two weeks. That's a narrow window. If you're serious about the 2027 cycle, you have roughly four months from now to build the contribution track record that gets you selected.

I wrote my personal story about getting into the program from Cameroon. This post is different. It's a practical, no-fluff guide covering how the program works, what the application actually asks, what reviewers evaluate (based on patterns from people who've been accepted and rejected), and how to prepare starting today.

What the AWS Community Builders Program Actually Is

AWS Community Builders is a global program that recognizes people who share AWS knowledge publicly. Not AWS employees. Not necessarily experts. Engineers, students, content creators, and community organizers who consistently write, build, speak, or contribute to open source around AWS services.

The key word is consistently. This is not a certification you study for. It's recognition of a public track record of helping others learn and build on AWS.

The program sits below the AWS Heroes program in AWS's community ladder. Heroes are veterans with years of visible impact. Community Builders is the accessible entry point, and for most engineers reading this, the realistic first target.

It's free to apply. Membership runs in yearly cycles with renewal based on continued activity.

The Categories (Pick One That Matches Your Work)

When you apply, you select a technology category. For 2026 the categories were:

AI Engineering: Building generative AI applications with Amazon Bedrock, prompt engineering, RAG, fine-tuning, agents
Cloud Operations: Observability and configuration (CloudWatch, Systems Manager, Config, Service Catalog)
Containers: ECS, EKS, Fargate, App Runner
Data: Databases and analytics (DynamoDB, RDS, S3, OpenSearch, Redshift, Athena)
Dev Tools: CI/CD, CDK, build pipelines, Application Composer
Front-End Web and Mobile: API Gateway, Amplify, AppSync
Machine Learning: SageMaker, training and deploying models at scale
Networking and Content Delivery: CloudFront, Route 53, WAF, VPC
Security: Cognito, IAM, GuardDuty, Secrets Manager
Serverless: Lambda, Step Functions, EventBridge, SQS, SNS

Pick the category where your existing contributions already live, not the one that sounds impressive. If your last six blog posts are about CloudWatch and SSM, apply for Cloud Operations. Reviewers look at your submitted content, and a mismatch between category and contributions is an easy reason to pass on an application.

I'm in Cloud Operations, which aligns with my infrastructure, observability, and cost-optimization work.

What AWS Is Actually Evaluating

Through my time in the program and observing who gets accepted, rejected, and eventually succeeds on reapplication, there are clear patterns. AWS is not selecting experts. They're selecting patterns of behavior:

Patterns of continuous learning
Patterns of sharing knowledge publicly
Patterns of consistency over time
Patterns of helping others in the community

1. Consistency Over Brilliance

One viral post won't do it. Eight decent posts over a year will. The program is literally named for community building, which is a repeated act.

The AWS team evaluates your current behavior and momentum, not what you did years ago. They want to see contributions from within the last 12 months. Many applications fail because candidates start contributing too late or only after discovering the program exists.

If you think "this is too simple" or "this already exists on the internet," you're thinking about it wrong. Every person explains concepts differently. Your perspective, shaped by your real experience, matters more than originality.

2. Public and Verifiable

Everything you claim needs a URL. Blog with dates. YouTube channel with upload history. GitHub with commit graphs. Meetup talks with event pages. If your work is invisible, it can't count.

3. Original Voice

AWS wants to hear you, not polished LLM output. Content that feels synthetic or overly generic doesn't build trust. You can use tools to assist, but if your voice disappears, the signal is lost.

If your content sounds like documentation, rewrite it. If it sounds like marketing, rewrite it. If it doesn't sound like you, rewrite it.

4. Genuine Community Engagement

Creating content in isolation isn't enough. Show that you engage with others:

Answering questions on re:Post, Stack Overflow, dev.to
Responding to comments on your posts
Helping people in forums and discussions
Attending or organizing meetups
Contributing to open-source projects

The Application: Step by Step

Timeline

Applications typically open in the first week of January and close within about two weeks (for 2026 it closed around January 21). Results come in early March. That's why preparation now matters.

Step 1: Join the Waitlist

Go to https://builder.aws.com/community/community-builders and join the waitlist with a free AWS Builder ID. Do this now. The application form is emailed to the waitlist, and if you're not on it, you find out about the window from other people's LinkedIn posts after it closes.

Step 2: Choose Your Category

Select the one that matches your existing body of work. Don't choose a category you plan to explore. Choose where you've already been active.

Step 3: Prepare Your Three Public Links

This is the most important part of the application. You submit 2-3 pieces of public content that demonstrate your contributions. These should be:

Technically solid (accurate, helpful, showing real understanding)
Published at least 3-4 months ago (not something rushed the week before applying)
Aligned with your chosen category
Publicly accessible (no paywalls, no private repos)

Strong examples:

In-depth technical blog posts or tutorials with code examples
Video walkthroughs or conference/meetup talk recordings
Open-source projects or meaningful contributions
Documentation of events you organized (with photos, recordings, testimonials)

Weak examples:

A post saying "I passed my certification" with no educational content
Company blog posts not under your name
Content behind a paywall
Links to your LinkedIn profile without specific content

Step 4: Write Your Story (About 1000 Characters)

A short written answer on why you want to be part of the community. Write it yourself. Reviewers read hundreds of these, and generated text has a recognizable pattern. Your specific journey, in your own words, beats polished generic text every time.

AWS wants to understand:

Why you're passionate about AWS and cloud
How you're already helping others
Your vision for continued contribution
What makes your perspective unique

Step 5: Complete Everything

Don't skip any questions, especially about communication preferences. If you don't opt in to emails, AWS can't notify you about your application status even if you're accepted.

What to Contribute (Starting Now)

If you're reading this in mid-2026, you have roughly 4-5 months before applications open. That's 8-10 biweekly blog posts. Enough. More than enough.

Content Ideas That Work

Start with your daily work and learning:

Configured an AWS service for the first time? Write about what confused you, what failed, and how you fixed it
Followed an official guide? Explain it again in simpler words with screenshots or diagrams
Built a proof of concept? Document the architecture, key decisions, and lessons learned
Hit a production issue? Write the troubleshooting story (sanitized)
Compared two AWS services? Share your decision framework

Common mistakes, misunderstood services, cost surprises, security misconfigurations, and deployment failures make excellent topics. Even basic content creates impact when it reduces confusion for someone else.

Beyond Blog Posts

Short video walkthroughs on YouTube or LinkedIn
Answering questions on re:Post, Stack Overflow, or community forums (explain why a solution works, not just what works)
Open-source repos with sample code, IaC templates, or demo projects
Organizing or speaking at meetups (local AWS user groups, virtual events)
Contributing to AWS documentation or open-source AWS tools

The Publishing Cadence That Works

Aim for biweekly at minimum. That gives you 8+ pieces before January. The sweet spot seems to be:

Pick one platform and commit to it (blog, dev.to, YouTube, wherever)
Publish every two weeks, not perfectly, just consistently
Make sure everything is publicly searchable (not behind auth or paywalls)
Cross-post to LinkedIn to build visibility

Common Mistakes That Kill Applications

Starting too late. Discovering the contribution requirement while filling out the application. Start now.
Focusing only on certifications. Certs are valuable, but "I passed the SAA" doesn't teach anyone anything. Focus on educational content.
Using AI-generated content without your voice. Reviewers can tell. Use tools to assist, but the perspective and experience must be yours.
Inconsistent naming. Use the same name across your Builder ID, application, and content. Inconsistency makes verification harder.
Applying for the wrong category. Your links should match your category. If they don't, that's an easy pass.
Content behind paywalls or private. AWS can't see it if it's not public.
Only broadcasting, never engaging. Create content AND participate in discussions. One-way communication isn't community building.

What Happens After Selection

Getting the welcome email feels like the finish line. It's the starting line. The first 30 days set the tone for your program year.

Claim Benefits Immediately

$500-$1000 in AWS credits: Redeem in your billing console the day you get access. Credits have expiry dates.
Certification voucher: 100% coverage for one AWS exam (Foundational, Associate, or Professional/Specialty).
Learning subscriptions: Access to exclusive platforms and content.

Engage in the Slack

The private Slack workspace has channels per category, boost channels where builders amplify each other's content, and announcement channels where challenges and opportunities appear. Lurking gets you nothing. Introduce yourself and keep showing up.

Keep Contributing

Renewal is not automatic. The program reviews activity every cycle. Getting in and going silent is the standard way people fall out after one year. The builders who stay treat selection as the beginning of a publishing habit, not a badge to collect.

Watch for Challenges

AWS runs periodic content challenges for builders. Winners get visibility with the AWS teams in your category, and prizes. These are worth participating in.

If You Get Rejected

This is normal. Many successful Community Builders were rejected on their first attempt and selected the next year. The pattern is consistent across the community.

Rejection is feedback, even when it's silent:

Your contributions may have started too recently
Your content may not have been deep enough
Your links may not have matched your chosen category
You may simply need more visible community engagement

The application costs nothing but the form. The real application is the 12 months of public content before it. Use a rejection as fuel to contribute more, then reapply.

My Honest Take on the Program's Value

What it does well:

The credits and voucher have direct, countable value (around $800+ combined if you use both)
The Slack access is a real network you cannot buy: direct lines to AWS service teams, collaboration with builders worldwide
The external recognition opens doors, especially for engineers building international careers from regions without a big local AWS presence
It creates a forcing function to keep contributing publicly, which compounds over time

What it won't do:

It won't make you write. There's no content quota enforced month to month.
It won't hand you clients or a salary bump directly.
It won't substitute for deep technical skills.

The program amplifies whatever habits you already have. If your habit is building in public, it multiplies you. If your habit is silence, you'll be silent with a badge.

Your Timeline from Here

If you're reading this in August 2026 and targeting the January 2027 application:

When	What to Do
Now	Join the waitlist at builder.aws.com
Aug-Sep	Publish 2-3 solid AWS posts in your target category
Oct-Nov	Continue publishing biweekly, engage in communities, answer questions
Dec	Prepare your 3 strongest links, draft your story, review everything
Jan 2027	Submit application within the window (it's only open ~2 weeks)
Mar 2027	Results arrive

Start now. The best time to have started was six months ago. The second best time is today.

AWS Cost Optimization: 15 Strategies That Work

Durrell Gemuh — Sun, 16 Aug 2026 12:17:28 +0000

Cloud costs can spiral out of control faster than most engineering teams realize. I've helped multiple organizations reduce their AWS bills by 40-70% through systematic cost optimization. These aren't theoretical savings, these are real numbers from production environments.

This post covers the most effective strategies I've implemented, with specific examples and implementation steps.

Understanding AWS Cost Drivers

Before optimizing, you need visibility. The biggest cost drivers in most AWS environments:

EC2 Instances (35-50% of total spend)
EBS Storage (15-25%)
Data Transfer (10-20%)
RDS Databases (10-15%)
Lambda & Serverless (5-10%)

Strategy 1: Right-Size Your EC2 Instances

Impact: 20-40% savings
Implementation Time: 2-4 weeks

The Process

Enable CloudWatch Detailed Monitoring on all instances
Use AWS Compute Optimizer for recommendations
Analyze usage patterns over 2-week periods
Implement changes during maintenance windows

Real Example

A client had 20 m5.large instances running at 15% CPU average. We resized to m5a.medium, saving $8,400/month while maintaining performance.

Tools

AWS Compute Optimizer
CloudWatch metrics
EC2 Instance Selector (CLI tool)

Strategy 2: Implement Auto Scaling

Impact: 30-50% savings on variable workloads
Implementation Time: 1-2 weeks

When It Works

Web applications with variable traffic
Batch processing workloads
Development environments

Implementation

# CloudFormation template snippet
AutoScalingGroup:
  MinSize: '1'
  MaxSize: '10'
  DesiredCapacity: '3'
  MetricsCollection:
    - Granularity: '1Minute'

Real Result

A client's API service scaled from 3 to 12 instances during peak hours, then back down. Monthly savings: $15,000.

Strategy 3: Use Spot Instances for Non-Critical Workloads

Impact: 60-80% savings vs on-demand
Implementation Time: 1 week

Suitable Workloads

CI/CD pipelines
Batch processing
Development environments
Non-production workloads

Implementation Considerations

Use Spot Instance Advisor for interruption rates
Implement proper fallback to on-demand
Test interruption handling

Real Example

A client's ML training pipeline moved to spot instances, reducing costs from $50,000/month to $12,000/month.

Strategy 4: Optimize EBS Storage

Impact: 15-30% savings
Implementation Time: 2-3 weeks

Key Tactics

Use gp3 instead of gp2 (20% cheaper, better performance)
Implement EBS snapshots lifecycle policies
Use instance store for temporary data
Right-size EBS volumes

Real Savings

Client migrated 200 gp2 volumes to gp3: $3,200/month savings.

Strategy 5: Database Optimization

Impact: 25-40% savings
Implementation Time: 3-6 weeks

RDS Optimization Steps

Right-size instances based on CPU/memory usage
Use reserved instances for predictable workloads
Implement read replicas for read-heavy workloads
Optimize storage (gp3, proper IOPS allocation)

Real Example

A client's PostgreSQL database was over-provisioned. We:

Reduced instance size from r5.xlarge to r5.large
Added read replica for reporting queries
Monthly savings: $4,500

Strategy 6: Implement Savings Plans

Impact: 20-40% savings on compute
Implementation Time: 1-2 weeks

Types of Savings Plans

Compute Savings Plans: Most flexible, 1-3 year commitment
EC2 Instance Savings Plans: Instance-family specific
SageMaker Savings Plans: For ML workloads

Real Result

Client committed to 1-year Compute Savings Plan covering 70% of usage: $25,000/month savings.

Strategy 7: Optimize Data Transfer Costs

Impact: 10-25% savings
Implementation Time: 2-4 weeks

Cost Reduction Tactics

Use CloudFront for content delivery
Compress data before transfer
Use VPC endpoints instead of NAT gateways
Optimize cross-region transfers

Real Example

Client implemented CloudFront for static assets: $8,000/month data transfer savings.

Strategy 8: Lambda Cost Optimization

Impact: 20-50% savings
Implementation Time: 1-2 weeks

Optimization Strategies

Right-size memory allocation (affects CPU proportionally)
Optimize function duration through code improvements
Use provisioned concurrency for latency-sensitive functions
Implement proper error handling to avoid retries

Real Example

A client's Lambda functions were over-allocated. Optimization reduced costs from $12,000/month to $4,800/month.

Strategy 9: Implement Resource Tagging Strategy

Impact: Improved governance, enables cost allocation
Implementation Time: 2-4 weeks

Tagging Strategy

Environment: prod, staging, dev
Team: engineering, marketing, data
Project: specific project names
Cost-Center: department codes

Implementation

Use AWS Config Rules to enforce tagging compliance.

Strategy 10: Monitor and Alert on Cost Anomalies

Impact: Prevents cost overruns
Implementation Time: 1 week

AWS Cost Anomaly Detection

Set up automated alerts
Configure alerts by service, account, or tag
Integrate with Slack/PagerDuty

Strategy 11: Clean Up Unused Resources

Impact: 5-15% savings
Implementation Time: 1-2 weeks

Common Unused Resources

EBS volumes not attached to instances
Elastic IPs not associated
NAT gateways in unused subnets
Unused load balancers

Automation

Use AWS Config and Lambda for automated cleanup.

Strategy 12: Optimize Container Orchestration

Impact: 20-35% savings
Implementation Time: 2-4 weeks

EKS Optimization

Use Fargate for variable workloads
Implement cluster autoscaling
Use spot instances for worker nodes
Optimize pod resource requests/limits

Strategy 13: Implement Backup and Disaster Recovery Optimization

Impact: 15-25% savings
Implementation Time: 2-3 weeks

Strategies

Use cross-region replication strategically
Implement backup lifecycle policies
Use cheaper storage classes for older backups
Test and clean up unused AMIs and snapshots

Strategy 14: Use AWS Organizations for Consolidated Billing

Impact: Volume discounts, better negotiation leverage
Implementation Time: 1-2 weeks

Benefits

Combined usage for better pricing tiers
Centralized cost management
Easier resource sharing

Strategy 15: Implement FinOps Culture

Impact: 30-50% long-term savings
Implementation Time: Ongoing

Key Practices

Cost awareness training for engineering teams
Regular cost reviews and optimization sessions
Cost budgets and alerts
Infrastructure as Code for cost predictability

Tools and Services for Cost Optimization

AWS Native Tools

Cost Explorer
Budgets
Cost and Usage Reports
Trusted Advisor

Third-Party Tools

CloudHealth
Cloudability
CloudCheckr
Spot.io

Implementation Roadmap

Phase 1 (Quick Wins - 1-2 weeks)

Enable detailed monitoring
Set up cost alerts
Clean up obvious unused resources
Implement basic auto scaling

Phase 2 (Medium Impact - 2-4 weeks)

Right-size instances and storage
Implement Savings Plans
Optimize databases
Set up proper tagging

Phase 3 (Advanced Optimization - 1-3 months)

Implement advanced auto scaling
Use spot instances strategically
Optimize data transfer
Implement FinOps processes

Measuring Success

Track these metrics:

Cost per user/transaction
Cost optimization percentage
Reserved instance utilization
Resource utilization rates

Common Pitfalls to Avoid

Optimizing too early: Focus on business value first
Over-optimization: Don't sacrifice reliability for cost
Ignoring operational overhead: Complex optimizations need maintenance
Not monitoring after changes: Always validate that optimizations work

Final Thoughts

AWS cost optimization is an ongoing process, not a one-time project. The strategies above have consistently delivered 40-70% savings for my clients, but the key is systematic implementation and continuous monitoring.

Start with visibility, implement quick wins first, then tackle more complex optimizations. Remember: efficient infrastructure enables faster feature delivery and better user experience.

AWS IAM Least Privilege Without Losing Your Mind

Durrell Gemuh — Sun, 16 Aug 2026 11:36:43 +0000

Least privilege is the IAM principle everyone agrees with and few actually implement, because doing
it by hand is tedious and "Action": "*" always works. Here's a practical approach that gets you
most of the way without turning into a full-time job.

Why it matters

An over-permissive role is a standing risk: if the credentials leak or a service is compromised, the
blast radius is everything that role can touch. Least privilege shrinks that blast radius to "only
what this thing actually needs."

1. Start from deny, add what's used

Don't start from a broad policy and try to trim it, start from nothing and add what the workload
actually calls. The trick is knowing what it calls:

CloudTrail + IAM Access Analyzer can generate a policy from observed activity. Run the workload with a broad policy in a non-prod account, let it exercise its paths, then generate a scoped policy from what it actually used.
For new workloads, add permissions iteratively as AccessDenied errors appear, annoying for a day, correct forever.

2. Scope resources, not just actions

s3:GetObject on "Resource": "*" means every object in every bucket. Scope it:

{
  "Effect": "Allow",
  "Action": ["s3:GetObject"],
  "Resource": "arn:aws:s3:::my-app-bucket/*"
}

Most managed policies are convenient but broad. Prefer customer-managed policies scoped to your
actual ARNs.

3. Use conditions to tighten further

Conditions are the underused superpower:

"Condition": {
  "StringEquals": { "aws:RequestedRegion": "us-east-1" },
  "Bool": { "aws:SecureTransport": "true" }
}

Restrict by region, source VPC, MFA presence, tag, or time. A policy that only works from your VPC
over TLS is far safer than one that works from anywhere.

4. Prefer roles over long-lived keys

Workloads on AWS: use IAM roles (instance profiles, IRSA for EKS, task roles for ECS), no stored keys.
CI/CD and external systems: use OIDC federation so there are no long-lived AKIA… keys to leak.
Humans: use IAM Identity Center (SSO) with short-lived sessions, not IAM users.

5. Guardrails above the role: SCPs

Even a perfect role can't protect you from a thousand imperfect ones. Service Control Policies at
the AWS Organizations level set hard ceilings e.g. "deny disabling CloudTrail," "deny outside
approved regions", that no account or role can exceed. (My
aws-multi-account-organization repo
shows this pattern.)

6. Find and fix what's already over-permissioned

IAM Access Analyzer flags resources shared externally and unused access.
Last accessed data (in the IAM console) shows permissions a role hasn't used in months, strong candidates to remove.
Alert on new iam:* and *:* policies in CI with tfsec/checkov.

The wildcard traps to avoid

"Action": "*" on "Resource": "*", admin in disguise.
iam:PassRole with "Resource": "*", lets a principal hand any role to a service (privilege escalation).
NotAction policies, easy to reason about wrong; prefer explicit Action allow-lists.

A workable routine

New workload → start denied, generate a policy from observed use.
Scope every statement to specific ARNs.
Add region/transport/tag conditions where they fit.
No long-lived keys, roles and OIDC only.
SCPs as the org-wide ceiling.
Quarterly: prune unused permissions via Access Analyzer + last-accessed.

Least privilege isn't a one-time project; it's a habit backed by the right tools. Done this way, it's maintainable, not the soul-crushing exercise it's reputed to be.

The Reality of Working as a DevOps Engineer in Cameroon

Durrell Gemuh — Fri, 14 Aug 2026 22:04:43 +0000

Most "how to become a DevOps engineer" posts are written from places where electricity and internet
are background assumptions. Mine isn't. I build and operate cloud infrastructure for teams across
six countries, from Buea, Cameroon. It works, and it's a genuinely good career. But it's not the
frictionless picture the highlight reels show.

Here's the honest version: what's hard, what I do about it, and why it's still worth it.

The power situation

Electricity is the first real constraint. Load shedding and unplanned outages are part of life in
Buea and much of Cameroon. When you're mid-deploy or on an incident call, the lights going out isn't
an inconvenience, it's a work-stopping event.

What actually helps:

A laptop, not a desktop. Sounds obvious, but a desktop tower ties your work to mains power. A laptop gives you hours of buffer.
A UPS and/or a power bank/inverter sized for your router too: a charged laptop is useless if the internet box is dead.
A backup power plan for long outages: a small generator, a solar setup, or knowing which café or co-working spot has power.
Designing work to be resumable. I lean heavily on Git, infrastructure-as-code, and CI so that if I drop offline mid-task, nothing is lost and a pipeline can finish what I started.

DevOps is actually well-suited to this: the heavy lifting runs in the cloud, not on my machine.

Internet: the real bottleneck

Connectivity has improved a lot, but it's still the thing most likely to bite you. Bandwidth is
variable, latency to US/EU regions is high, and a fibre cut can mean a bad day. For work that
involves pushing container images, pulling large dependencies, or screen-sharing during incidents,
that matters.

How I work around it:

A primary connection plus a mobile-data backup (different carrier). When one drops, I tether.
Do heavy lifting in the cloud. I run builds, image pushes, and big terraform applys from CI or a cloud VM/bastion close to the target region, not over my home link. My laptop just drives it.
Cache aggressively. Local Docker layer caching, package mirrors, and terraform plan review before apply cut the amount I transfer.
Async-first communication. I don't rely on a perfect video call to get work done; clear written updates survive a flaky connection.

The mindset shift: treat your local connection as unreliable by design, and architect around it.

Timezones: a hidden advantage, with discipline

Cameroon is on WAT (UTC+1). Working with US teams means they're 6-9 hours behind; with parts of Asia
I'm behind. That overlap gap is real, but it's also a feature if you're deliberate.

The early morning is golden. Before the US wakes up, I get deep, uninterrupted work done: the best focus hours of my day.
Overlap windows are for humans, async is for everything else. I protect the few overlap hours for the conversations that genuinely need to be live, and push status, reviews, and decisions to writing.
On-call across timezones needs honesty. If a team needs 3am-my-time coverage, that has to be an explicit, compensated agreement, not an silent expectation. I've learned to negotiate this up front.

Being in a different timezone has won me work: I can cover hours the rest of the team can't.

Payments and the business side

This is the part nobody warns you about. Getting paid from abroad is harder than the work itself
some months:

Not every international platform supports Cameroon cleanly; some payment processors and payout options just aren't available.
I've had to get creative with a mix of services to receive funds reliably, and factor in fees and exchange rates.
Invoicing, contracts, and proving legitimacy as a solo engineer from Cameroon takes extra effort, a professional website, a real GitHub, and references do a lot of the trust-building that a recognisable local employer would otherwise provide.

None of it is a blocker. It's friction you plan for.

Visibility: you have to be undeniable

When you're not in a hub city and don't have a FAANG logo on your CV, the burden of proof is higher.
A hiring manager scrolling past you needs an immediate reason to stop. For me that's been:

Public, runnable projects that show I operate real systems.
Writing (like this) that shows how I think.
Community work: AWS Community Builder, and running Talent Forge to train other engineers here.

You can't control the bias; you can make yourself impossible to dismiss.

Why it's still absolutely worth it

For all of the above, I wouldn't trade it. I do interesting, well-paid, global-standard engineering
without leaving home. I get to build the local DevOps community I wish I'd had. And the constraints
made me a better engineer, when your power and internet can vanish, you build systems that are
resilient, automated, and observable by default. That's literally the job.

If you're an engineer in Cameroon, or anywhere with these same constraints, wondering whether a
remote DevOps career is realistic: it is. Plan for the friction, make your work undeniable, and ship.

*I'm a DevOps & Cloud Engineer based in Buea, Cameroon, working with teams worldwide and open to new opportunities.

Building LogSentry: A Serverless AWS Pipeline That Detects Secrets Leaked into Application Logs in Real-Time

Durrell Gemuh — Mon, 08 Jun 2026 02:02:20 +0000

A serverless AWS pipeline that auto-monitors every CloudWatch log group, scans for leaked credentials in real-time, sends rate-limited alerts, and ships with a triage dashboard — zero config after deploy.

Every production system I've operated has had the same recurring incident: a developer accidentally logs a password, an API key ends up in CloudWatch, a database connection string appears in a debug statement that was never removed.

The consequences are serious. A leaked AWS key in logs can be scraped by attackers in minutes. A database URL with credentials gives direct access. A Stripe key means money.

I built LogSentry to catch these leaks the moment they happen — before they become breaches. And critically, it requires zero configuration after the initial deploy. New services are monitored automatically.

The Problem

In a typical microservices environment running 20+ services, each generating thousands of log lines per minute, manual review is impossible. Teams discover leaked secrets in one of three ways:

A security audit (weeks or months later)
An incident (the secret was already exploited)
A colleague happens to notice during debugging

We need detection that's real-time, automated, comprehensive, and low-noise.

Architecture

Services → CloudWatch → [Auto-Subscribe] → Kinesis → Lambda Scanner → DynamoDB + SNS

The full flow:

Services generate logs → CloudWatch Log Groups
Auto-subscribe (EventBridge + 5-min scheduled scan) adds subscription filters to every log group — zero manual setup
Kinesis Data Stream buffers log events (backpressure, replay, scaling)
Lambda Scanner processes events: 12 regex patterns + Shannon entropy analysis
DynamoDB stores deduplicated findings (with TTL auto-expiry at 90 days)
SNS sends rate-limited alerts to Slack/email/PagerDuty
CloudWatch custom metrics track detection rates per severity
SQS Dead Letter Queue preserves failed events for 14 days

Zero-Config Auto-Subscribe

The key differentiator is automatic monitoring. Instead of manually attaching subscription filters to each log group, LogSentry handles it:

Trigger	Latency	How
New log group created	Instant	EventBridge rule (requires CloudTrail)
Scheduled fallback	≤ 5 minutes	Lambda scans for unsubscribed groups
First deploy	Immediate	Terraform local-exec subscribes existing groups

Excluded prefixes (configurable): /aws/lambda/logsentry, /aws/cloudtrail, /aws/rds — to avoid scanning its own logs or known-noisy sources.

After terraform apply, every existing and future log group is monitored. Deploy a new service tomorrow — it's covered automatically.

The Detection Engine

The scanner applies 12 patterns covering the most common secret types:

Pattern	What It Catches	Severity
AWS Access Key	`AKIA` + 16 chars	Critical
Password in logs	`password=`, `pwd:` with value	Critical
Database URL	`postgres://user:pass@host`	Critical
Private Key	`-----BEGIN RSA PRIVATE KEY-----`	Critical
Stripe Key	`sk_live_`, `pk_live_` prefixes	Critical
GitHub Token	`ghp_`, `gho_`, `ghs_` prefixes	Critical
JWT Token	`eyJ` base64 pattern	High
Bearer Token	`Bearer` + 20+ chars	High
Slack Token	`xoxb-`, `xoxp-` patterns	High
Generic API Key	`api_key=`, `api_secret=`	High
Generic Secret	`secret=`, `token=`	Medium

Reducing False Positives with Entropy

Raw regex matching produces too much noise. The string password=loading matches the pattern but isn't a credential.

LogSentry uses Shannon entropy analysis as a secondary filter. Real secrets have high randomness (entropy > 3.5 bits/char). Dictionary words and common values have low entropy and get filtered.

def calculate_entropy(data: str) -> float:
    if not data:
        return 0.0
    entropy = 0.0
    for x in set(data):
        p_x = data.count(x) / len(data)
        entropy -= p_x * math.log2(p_x)
    return entropy

This noticeably cuts false positives on generic patterns like secret= and token=, where the value is what tells a real credential apart from a placeholder.

Rate-Limited Alerting

A burst of 1,000 identical leaked secrets shouldn't generate 1,000 alerts. LogSentry handles this at two levels:

Deduplication — DynamoDB conditional writes (attribute_not_exists(finding_id)). Same secret = same finding ID = one alert.
Rate limiting — Maximum 10 alerts per Lambda invocation (configurable). Prevents notification storms during mass-logging incidents.

When a new finding is detected:

🚨 LogSentry Alert — CRITICAL

Pattern: AWS Access Key ID detected
Service: /app/payment-service
Value: AKIA************MPLE
Time: 2026-06-08T14:23:01Z
Environment: production

The Dashboard

I built a Flask dashboard that works in two modes:

Demo mode (python app.py) — uses sample data, no AWS credentials needed. Perfect for showcasing to a team.
Live mode (LOGSENTRY_MODE=live python app.py) — reads directly from DynamoDB.

Dashboard features:

Stats overview — total findings, broken down by severity and status
Findings list — filter by severity, status, service, pattern
Live scanner — paste any log line and instantly see what patterns match
Resolve workflow — one-click to mark findings as remediated
Service breakdown — which services are leaking the most

The live scanner is particularly useful for developers: paste a log line from your app and verify it doesn't contain detectable secrets before deploying.

Auto-Expiring Findings

Resolved findings don't need to live forever. DynamoDB TTL automatically deletes resolved items after 90 days (configurable). This keeps the table clean and costs low without manual maintenance.

Infrastructure as Code

Everything is provisioned with a single terraform apply:

Kinesis Data Stream (1 shard dev, 2 shards prod)
Scanner Lambda (zip deploy, no Docker needed)
Auto-subscribe Lambda + EventBridge rules + scheduled trigger
DynamoDB table (GSI on severity, TTL, point-in-time recovery)
SNS topic with email subscription
SQS Dead Letter Queue
CloudWatch alarms (error rate, critical findings)
IAM roles (least-privilege, scoped per function)
Subscription filters on all existing log groups

No manual steps. No clicking in the console.

CI/CD Pipeline

Push-to-deploy via GitHub Actions (with GitLab CI equivalent):

Push → pytest (20 tests) → Trivy scan → Zip + deploy Lambda

The Terraform infrastructure has its own pipeline:

Push → terraform fmt → validate → tfsec → plan → apply (manual gate for prod)

Lambda is deployed as a zip file — no Docker build step, no ECR, no image management. Keeps CI fast (under 2 minutes).

Testing

20 unit tests covering detection of each pattern type, false positive rejection, multiple findings in one line, entropy calculation, secret masking, deduplication logic, and finding structure validation.

All tests run in under a second with zero AWS dependencies — the scanner logic is pure Python with lazy-loaded boto3.

Key Takeaways

Zero-config monitoring is the goal — if you require manual steps per service, coverage will always have gaps
Deduplication + rate limiting are essential — without them, alert fatigue kills the system
Entropy filtering works — Shannon entropy is a simple, effective way to cut false positives on generic patterns
Serverless fits perfectly — bursty workload, scales with log volume, near-zero cost at quiet times
A dashboard makes it real — having a live scanner and resolve workflow turns this from a notification tool into a security platform

The full source is on GitHub: github.com/durrello/logsentry

Security built into the platform, not bolted on after an incident. If your services are generating logs without automated secret detection, you're relying on luck.

Build a Portable Development Playground with Vagrant and VirtualBox

Durrell Gemuh — Mon, 01 Jun 2026 17:33:21 +0000

Stop saying "it works on my machine." Start shipping consistent environments.

Introduction

Every developer has been there: you clone a repo, follow the README, and two hours later you're deep in dependency hell — wrong Python version, missing system library, or some obscure config that only works on macOS Ventura and above.

Vagrant paired with VirtualBox solves this elegantly. You define your environment as code, and anyone on your team — Windows, macOS, or Linux — spins up an identical VM in minutes.

In this guide, you'll go from zero to a fully reproducible development playground, complete with provisioning, shared folders, and port forwarding.

Prerequisites

Before we start, make sure you have:

A machine with at least 8 GB RAM (4 GB for the VM + your host OS)
VirtualBox installed → virtualbox.org/wiki/Downloads
Vagrant installed → developer.hashicorp.com/vagrant/downloads

Verify your installs:

vagrant --version
# Vagrant 2.4.x

VBoxManage --version
# 7.x.x

Step 1 — Initialize Your Project

Create a new directory for your playground and initialize Vagrant inside it:

mkdir my-dev-playground && cd my-dev-playground
vagrant init ubuntu/jammy64

This generates a Vagrantfile in your current directory. The ubuntu/jammy64 box is Ubuntu 22.04 LTS — a solid, well-maintained base image pulled from the Vagrant Cloud.

Step 2 — Configure the Vagrantfile

Open the generated Vagrantfile and replace its contents with this well-commented configuration:

Vagrant.configure("2") do |config|

  # ── Base Box ────────────────────────────────────────────────────
  config.vm.box = "ubuntu/jammy64"
  config.vm.box_check_update = false

  # ── Networking ──────────────────────────────────────────────────
  # Access your VM's web server at http://localhost:8080 on the host
  config.vm.network "forwarded_port", guest: 80,   host: 8080
  config.vm.network "forwarded_port", guest: 3000, host: 3000  # Node/React
  config.vm.network "forwarded_port", guest: 5432, host: 5432  # PostgreSQL
  config.vm.network "forwarded_port", guest: 6379, host: 6379  # Redis

  # Private network — access VM directly at this IP from the host
  config.vm.network "private_network", ip: "192.168.56.10"

  # ── Shared Folders ──────────────────────────────────────────────
  # Your project folder syncs automatically into the VM
  config.vm.synced_folder ".", "/vagrant", type: "virtualbox"

  # ── Provider Settings (VirtualBox) ──────────────────────────────
  config.vm.provider "virtualbox" do |vb|
    vb.name   = "dev-playground"
    vb.memory = "2048"   # 2 GB RAM — adjust as needed
    vb.cpus   = 2
    # Faster DNS resolution inside the VM
    vb.customize ["modifyvm", :id, "--natdnshostresolver1", "on"]
  end

  # ── Provisioning ────────────────────────────────────────────────
  # This shell script runs ONCE when you first `vagrant up`
  config.vm.provision "shell", inline: <<-SHELL
    echo "==> Updating package lists..."
    apt-get update -qq

    echo "==> Installing core tools..."
    apt-get install -y -qq \
      git curl wget unzip build-essential \
      software-properties-common apt-transport-https

    echo "==> Installing Node.js 20.x..."
    curl -fsSL https://deb.nodesource.com/setup_20.x | bash -
    apt-get install -y nodejs

    echo "==> Installing Python 3 + pip..."
    apt-get install -y python3 python3-pip python3-venv

    echo "==> Installing Docker..."
    curl -fsSL https://get.docker.com | sh
    usermod -aG docker vagrant

    echo "==> Installing PostgreSQL..."
    apt-get install -y postgresql postgresql-contrib
    sudo -u postgres psql -c "ALTER USER postgres PASSWORD 'postgres';"
    sudo -u postgres psql -c "CREATE DATABASE devdb;" 2>/dev/null || true

    echo "==> Installing Redis..."
    apt-get install -y redis-server
    sed -i 's/^bind 127.0.0.1/bind 0.0.0.0/' /etc/redis/redis.conf
    systemctl restart redis-server

    echo "==> All done! Your playground is ready."
  SHELL

end

💡 Tip: The <<-SHELL block is a Bash heredoc — any valid shell script goes here. You can also point to an external script file with config.vm.provision "shell", path: "provision.sh" to keep things tidy.

Step 3 — Boot the VM

vagrant up

The first run will:

Download the ubuntu/jammy64 base box (~500 MB, cached locally for future use)
Create and configure a VirtualBox VM
Run the provisioning script

Subsequent vagrant up calls take only 5–10 seconds since the box is already downloaded and provisioned.

Step 4 — Connect to Your VM

vagrant ssh

You're now inside the VM. Your project folder is mounted at /vagrant:

cd /vagrant
ls        # same files as your host machine!

Everything you install globally inside the VM is isolated from your host OS. Clean and reproducible.

Step 5 — Verify Your Stack

Once SSH'd in, quickly verify the tools are running:

# Node.js
node --version && npm --version

# Python
python3 --version && pip3 --version

# Docker
docker --version
docker run hello-world

# PostgreSQL
psql -U postgres -h localhost -c "\l"

# Redis
redis-cli ping    # should return PONG

From your host machine, you can connect to services using the forwarded ports:

# PostgreSQL from host (use any GUI like TablePlus, DBeaver)
psql -h localhost -p 5432 -U postgres -d devdb

# Redis from host
redis-cli -h localhost -p 6379 ping

Step 6 — Everyday Workflow

Command	What it does
`vagrant up`	Start the VM
`vagrant ssh`	SSH into the VM
`vagrant halt`	Gracefully shut down the VM
`vagrant reload`	Restart the VM (picks up Vagrantfile changes)
`vagrant provision`	Re-run the provisioning script
`vagrant destroy`	Delete the VM entirely (Vagrantfile stays)
`vagrant snapshot save <name>`	Save a snapshot of the current VM state

Reprovisioning: If you update the Vagrantfile provisioning script, run vagrant reload --provision to apply changes without destroying the VM.

Step 7 — Share Your Environment with the Team

The beauty of this setup: commit your Vagrantfile (and any provision.sh scripts) to your repository. Anyone with Vagrant + VirtualBox installed runs:

git clone https://github.com/yourorg/your-repo.git
cd your-repo
vagrant up

...and they have an identical environment to yours. No more "works on my machine."

A minimal .gitignore for Vagrant projects:

.vagrant/
*.log

Bonus: Multi-Machine Setup

Vagrant can spin up multiple VMs in a single Vagrantfile — perfect for simulating a microservices or client/server architecture:

Vagrant.configure("2") do |config|

  config.vm.define "web" do |web|
    web.vm.box = "ubuntu/jammy64"
    web.vm.network "private_network", ip: "192.168.56.11"
    web.vm.provision "shell", inline: "apt-get update && apt-get install -y nginx"
  end

  config.vm.define "db" do |db|
    db.vm.box = "ubuntu/jammy64"
    db.vm.network "private_network", ip: "192.168.56.12"
    db.vm.provision "shell", inline: "apt-get update && apt-get install -y postgresql"
  end

end

Start all machines with vagrant up, or target one with vagrant up web.

Troubleshooting

VirtualBox kernel module error on Linux:

sudo /sbin/vboxconfig

Slow synced folder performance on macOS:
Consider switching to NFS: config.vm.synced_folder ".", "/vagrant", type: "nfs"

Port already in use:
Change the host: port number in the forwarded_port config, or stop the conflicting service on your host.

"Box not found" error:
Search available boxes at app.vagrantup.com/boxes/search.

Wrapping Up

You now have a fully portable, version-controlled development playground that:

Runs identically on any OS
Installs your entire stack automatically on first boot
Forwards ports so host tools work seamlessly
Syncs your code files in real time
Can be destroyed and recreated in minutes

Once you're comfortable with this setup, consider exploring Ansible provisioning for more complex stacks, or Docker-in-Vagrant for a hybrid container + VM workflow.

Happy hacking! 🚀

Found this useful? Drop a ❤️ and share it with a teammate who's still fighting environment issues. Questions or improvements? Leave a comment below!

Deploy Your Portfolio Website: GitHub Pages + Cloudflare Custom Domain

Durrell Gemuh — Mon, 11 May 2026 23:46:58 +0000

Talent Forge Program · Project 1 | Beginner → Intermediate
The exact project that proves you can ship. Tie it to you, your resume, and your brand, all in one afternoon.

Why This Project Matters

Before you can list "built production infrastructure" on your CV, you need somewhere to list it from. Your portfolio website is not a vanity project, it is proof of work. It demonstrates:

You can version-control a codebase on GitHub
You understand Cloudflare Pages, a real edge deployment platform used at scale in production
You can configure DNS, custom domains, and SSL, skills that appear in every infrastructure job posting
You have a working CI/CD pipeline: every git push to main triggers an automatic global deployment

For my talk at AWS Student Community Day on Learning DevOps the Right Way: Building in Public and Gaining Real Experience, this is what I pointed students to. Not because it is the flashiest, but because it is the one you can finish in a weekend, deploy publicly, and put at the top of your CV immediately.

This is the complete implementation guide for Talent Forge Program 1, the portfolio website project. I am walking you through exactly how I built and deployed durrellgemuh.com.

What You Will Build

Your HTML/CSS/JS Site
        │
        ▼
   GitHub Repository
        │
        │  git push triggers
        ▼
   Cloudflare Pages (build + deploy)
        ├── Global CDN (300+ edge locations)
        ├── Automatic HTTPS (free SSL)
        ├── DDoS protection
        └── Custom domain
        │
        ▼
   yourdomain.com — live on the internet

Stack:

HTML, CSS, JavaScript — static site, no backend, no server
GitHub — source control and the CI/CD trigger
Cloudflare Pages — hosting, CDN, SSL, and deployment pipeline (all free)
A custom domain from any registrar (Namecheap, Porkbun, Google Domains, etc.)

Why Cloudflare Pages?
Cloudflare Pages gives you a globally distributed CDN out of the box, automatic HTTPS with zero configuration, instant cache invalidation on every deploy, DDoS protection at the edge, and detailed analytics — all on the free tier. It is what production-minded engineers actually reach for when they need fast, reliable, zero-maintenance static hosting.

Cost: ~$10–15/year for the domain. Everything else is completely free.

Time to complete: 2–4 hours for the first deployment. Under 30 minutes for every update after that.

Prerequisites

[ ] A GitHub account — github.com
[ ] A Cloudflare account — cloudflare.com (free plan)
[ ] A registered custom domain — around $10–12/year from any registrar
[ ] Git installed locally — git-scm.com
[ ] VS Code or any code editor

Part 1: Build Your Static Portfolio Site

Step 1.1 — Create Your Project Structure

mkdir my-portfolio
cd my-portfolio

# Create the folder structure
mkdir css js img fonts

# Create your main files
touch index.html css/style.css js/main.js

Your directory tree:

my-portfolio/
├── index.html          ← entry point (Cloudflare Pages serves this)
├── css/
│   └── style.css
├── js/
│   └── main.js
├── img/
│   └── (your photos and project screenshots)
└── fonts/
    └── (any custom font files)

💡 This is exactly the structure used at github.com/durrello/personal-website css, js, img, fonts, and multiple HTML pages. Fork it if you want a head start on the design.

Step 1.2 — Write Your index.html

A minimal but complete portfolio template you can build on:

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8" />
  <meta name="viewport" content="width=device-width, initial-scale=1.0" />
  <meta name="description" content="Your Name — DevOps & Cloud Engineer" />
  <title>Your Name | DevOps Engineer</title>
  <link rel="stylesheet" href="css/style.css" />
</head>
<body>

  <!-- NAVIGATION -->
  <nav>
    <div class="nav-brand">Your Name</div>
    <ul class="nav-links">
      <li><a href="#about">About</a></li>
      <li><a href="#projects">Projects</a></li>
      <li><a href="#blog">Blog</a></li>
      <li><a href="#contact">Contact</a></li>
    </ul>
  </nav>

  <!-- HERO SECTION -->
  <section id="hero">
    <h1>Your Name</h1>
    <h2>DevOps & Cloud Engineer</h2>
    <p>
      Building scalable infrastructure on AWS and GCP.
      Kubernetes · Terraform · CI/CD · GitOps
    </p>
    <div class="hero-cta">
      <a href="#projects" class="btn-primary">View Projects</a>
      <a href="resume.pdf" class="btn-secondary">Download Resume</a>
    </div>
  </section>

  <!-- ABOUT SECTION -->
  <section id="about">
    <h2>About Me</h2>
    <p>
      Write 3–5 sentences. Who you are, what you work on, what you care about.
      Mention your current learning focus or the Talent Forge program.
    </p>
  </section>

  <!-- PROJECTS SECTION -->
  <section id="projects">
    <h2>Projects</h2>
    <div class="project-grid">
      <div class="project-card">
        <h3>Project Title</h3>
        <p>Short description of what it does and the technologies used.</p>
        <div class="project-tags">
          <span>AWS</span>
          <span>Terraform</span>
          <span>Cloudflare Pages</span>
        </div>
        <div class="project-links">
          <a href="https://github.com/yourrepo">GitHub →</a>
          <a href="https://dev.to/yourarticle">Blog Post →</a>
        </div>
      </div>
    </div>
  </section>

  <!-- BLOG SECTION -->
  <section id="blog">
    <h2>Writing</h2>
    <p>
      Links to your dev.to posts, LinkedIn articles, or any public writing.
      This section is proof that you build in public.
    </p>
  </section>

  <!-- CONTACT SECTION -->
  <section id="contact">
    <h2>Get in Touch</h2>
    <p>Email: you@email.com</p>
    <p>LinkedIn: linkedin.com/in/yourhandle</p>
    <p>GitHub: github.com/yourhandle</p>
  </section>

  <script src="js/main.js"></script>
</body>
</html>

Step 1.3 — Add Basic Styling

/* css/style.css */

* {
  margin: 0;
  padding: 0;
  box-sizing: border-box;
}

body {
  font-family: 'Segoe UI', Tahoma, Geneva, Verdana, sans-serif;
  background: #0b0b0f;
  color: #e8e8f0;
  line-height: 1.6;
}

nav {
  display: flex;
  justify-content: space-between;
  align-items: center;
  padding: 1rem 5%;
  background: rgba(11, 11, 15, 0.95);
  position: sticky;
  top: 0;
  z-index: 100;
  border-bottom: 1px solid #1e1e2e;
}

.nav-brand {
  font-size: 1.25rem;
  font-weight: 700;
  color: #f6821f; /* Cloudflare orange */
}

.nav-links {
  list-style: none;
  display: flex;
  gap: 2rem;
}

.nav-links a {
  color: #e8e8f0;
  text-decoration: none;
  font-size: 0.9rem;
  transition: color 0.2s;
}

.nav-links a:hover { color: #f6821f; }

#hero {
  padding: 8rem 5% 6rem;
  max-width: 800px;
}

#hero h1 {
  font-size: 3.5rem;
  font-weight: 800;
  margin-bottom: 0.5rem;
}

#hero h2 {
  font-size: 1.5rem;
  color: #00d4ff;
  font-weight: 400;
  margin-bottom: 1.5rem;
}

#hero p {
  font-size: 1.1rem;
  color: #9090a8;
  margin-bottom: 2rem;
  max-width: 600px;
}

.hero-cta { display: flex; gap: 1rem; flex-wrap: wrap; }

.btn-primary {
  background: #f6821f;
  color: #0b0b0f;
  padding: 0.75rem 2rem;
  border-radius: 4px;
  text-decoration: none;
  font-weight: 700;
  transition: opacity 0.2s;
}

.btn-primary:hover { opacity: 0.85; }

.btn-secondary {
  border: 1px solid #f6821f;
  color: #f6821f;
  padding: 0.75rem 2rem;
  border-radius: 4px;
  text-decoration: none;
  font-weight: 600;
}

section {
  padding: 5rem 5%;
  max-width: 1200px;
  margin: 0 auto;
}

section h2 {
  font-size: 2rem;
  font-weight: 800;
  margin-bottom: 2rem;
  border-left: 4px solid #f6821f;
  padding-left: 1rem;
}

.project-grid {
  display: grid;
  grid-template-columns: repeat(auto-fill, minmax(320px, 1fr));
  gap: 1.5rem;
}

.project-card {
  background: #1a1a28;
  border: 1px solid #1e1e2e;
  border-radius: 8px;
  padding: 1.5rem;
  transition: border-color 0.2s;
}

.project-card:hover { border-color: #f6821f; }

.project-card h3 { font-size: 1.1rem; margin-bottom: 0.75rem; }

.project-tags {
  display: flex;
  flex-wrap: wrap;
  gap: 0.5rem;
  margin: 1rem 0;
}

.project-tags span {
  background: rgba(246, 130, 31, 0.1);
  border: 1px solid rgba(246, 130, 31, 0.3);
  color: #f6821f;
  padding: 0.2rem 0.6rem;
  border-radius: 3px;
  font-size: 0.8rem;
}

.project-links { display: flex; gap: 1rem; margin-top: 1rem; }
.project-links a { color: #f6821f; text-decoration: none; font-size: 0.9rem; }

Step 1.4 — Test Locally

# Python local server (usually pre-installed)
python3 -m http.server 8000

# Visit: http://localhost:8000

Make sure everything renders correctly before pushing.

Part 2: Push to GitHub

Step 2.1 — Initialise Git

cd my-portfolio
git init
git add .
git commit -m "feat: initial portfolio site"

Step 2.2 — Create the GitHub Repository

Go to github.com/new
Repository name: my-portfolio
Visibility: Public
Do NOT initialise with a README — you already have files
Click Create repository

Step 2.3 — Push

git remote add origin https://github.com/YOUR_USERNAME/my-portfolio.git
git branch -M main
git push -u origin main

Confirm:

git log --oneline
# Should show: feat: initial portfolio site

Part 3: Connect GitHub to Cloudflare Pages

This is where the CI/CD magic happens. Cloudflare Pages connects directly to your GitHub repository and automatically deploys on every push to main. No pipeline YAML to write — Cloudflare handles the deployment infrastructure for you.

Step 3.1 — Create a New Cloudflare Pages Project

Log in to cloudflare.com
In the left sidebar, go to Workers & Pages
Click Create → Pages tab → Connect to Git

Step 3.2 — Authorise GitHub

Click Connect GitHub
Cloudflare opens a GitHub OAuth window
Choose Only select repositories and select your my-portfolio repo
Click Install & Authorize

💡 You are granting Cloudflare read access to your repository so it can pull your code on each push. This is the same pattern used in every modern CI/CD integration — Cloudflare, Vercel, and Netlify all work this way.

Step 3.3 — Configure the Build Settings

After authorising, you will see the build configuration screen. For a pure static HTML/CSS/JS site:

Setting	Value
Production branch	`main`
Framework preset	`None`
Build command	(leave empty)
Build output directory	(leave empty)
Root directory	(leave empty)

Why no build command? Your site is plain HTML/CSS/JS — there is nothing to compile. Cloudflare Pages deploys the files exactly as they are in your repo. If you later add a framework (React, Next.js, Hugo), you would set the build command and output directory at that point.

Click Save and Deploy.

Step 3.4 — Watch the First Deployment

Cloudflare Pages will:

Pull your code from GitHub
Run the build (instant for static files)
Deploy to the global edge network
Give you a URL like: https://my-portfolio-abc.pages.dev

The first deployment takes 30–60 seconds. Visit the .pages.dev URL to confirm your site is live.

From this point on, every git push to main automatically triggers a new deployment. You now have a fully managed CI/CD pipeline — no servers, no agents, no maintenance.

Part 4: Add Your Domain to Cloudflare

Step 4.1 — Add Your Domain to Cloudflare DNS

If your domain is not already managed by Cloudflare:

In the Cloudflare dashboard, click Add a Site
Enter your domain: yourdomain.com
Select the Free plan → Continue
Cloudflare scans existing DNS records — review and keep any you need
Click Continue to activation

Cloudflare will give you two nameservers, for example:

aria.ns.cloudflare.com
jay.ns.cloudflare.com

Step 4.2 — Update Nameservers at Your Registrar

Go to wherever you bought the domain:

Find Nameservers or DNS Settings
Replace the existing nameservers with Cloudflare's two nameservers
Save

⚠️ Nameserver propagation takes 15 minutes to 48 hours — usually under an hour. Cloudflare sends an email when your domain is activated.

Step 4.3 — Verify Propagation

# Check your domain's nameservers
dig NS yourdomain.com +short

# Expected output (Cloudflare nameservers):
# aria.ns.cloudflare.com.
# jay.ns.cloudflare.com.

Or use whatsmydns.net — search for your domain with NS record type.

Part 5: Connect Your Custom Domain to Cloudflare Pages

Step 5.1 — Add the Custom Domain

Go to Workers & Pages → your Pages project
Click the Custom domains tab
Click Set up a custom domain
Enter: yourdomain.com
Click Continue

Cloudflare will check if your domain is managed in your account. Since you added it in Part 4, it will be found automatically.

Step 5.2 — Cloudflare Creates the DNS Record Automatically

This is one of the best parts of using Cloudflare Pages with a Cloudflare-managed domain: Cloudflare automatically creates the CNAME record pointing your domain to your Pages project. You do not touch DNS manually.

Cloudflare creates:

CNAME  yourdomain.com  →  my-portfolio-abc.pages.dev  (Proxied ✅)

Click Activate domain to confirm.

Step 5.3 — Add www Redirect (Recommended)

To make www.yourdomain.com also work:

Go to Custom domains → Set up a custom domain again
Enter: www.yourdomain.com
Cloudflare adds a second CNAME automatically

To redirect www to apex permanently:

Go to Rules → Redirect Rules
Create a rule: if Hostname equals www.yourdomain.com → redirect to https://yourdomain.com (301 permanent)

Part 6: Configure SSL and Security

Cloudflare Pages handles SSL automatically — your site gets HTTPS the moment the custom domain is activated. No certificate purchasing, no Let's Encrypt commands, no renewal reminders. Cloudflare renews it automatically, forever.

Tighten these settings to production standard:

Step 6.1 — SSL/TLS Mode

Go to your domain in Cloudflare → SSL/TLS → Overview
Set encryption mode to Full (strict)

Cloudflare Pages serves over HTTPS natively, so Full (strict) works without any issue and is the most secure mode available.

Step 6.2 — Force HTTPS

SSL/TLS → Edge Certificates
Always Use HTTPS → ON
Automatic HTTPS Rewrites → ON

Any visitor hitting http://yourdomain.com is now redirected to https:// at Cloudflare's edge — before a request even touches your site.

Step 6.3 — HSTS (Advanced — Optional)

For maximum security, enable HTTP Strict Transport Security:

SSL/TLS → Edge Certificates → HTTP Strict Transport Security (HSTS)
Enable HSTS → set Max Age to 6 months
Check Include subdomains if you have subdomains

⚠️ HSTS tells browsers to never connect over HTTP for the specified period. Only enable this when HTTPS is fully confirmed and working.

Part 7: Performance Settings

These take under five minutes and have real-world impact:

Speed → Optimization:

Setting	Value
Auto Minify — HTML	ON
Auto Minify — CSS	ON
Auto Minify — JavaScript	ON
Brotli compression	ON
Early Hints	ON

Caching → Configuration:

Setting	Value
Caching Level	Standard
Browser Cache TTL	4 hours

Security → Settings:

Setting	Value
Security Level	Medium
Bot Fight Mode	ON
Email Address Obfuscation	ON

💡 Bot Fight Mode silently challenges known bad bots at the edge. It is free, requires zero maintenance, and you should enable it on every site you run.

Part 8: Verify the Full Setup

# 1. Site loads over HTTPS with Cloudflare headers
curl -I https://yourdomain.com

# Expected:
# HTTP/2 200
# server: cloudflare
# content-type: text/html; charset=utf-8
# cf-ray: <id>-<datacenter>

# 2. HTTP redirects to HTTPS
curl -I http://yourdomain.com

# Expected:
# HTTP/1.1 301 Moved Permanently
# location: https://yourdomain.com/

# 3. www redirects to apex
curl -I https://www.yourdomain.com

# Expected: 301 to https://yourdomain.com

# 4. SSL certificate is valid
openssl s_client -connect yourdomain.com:443 -brief 2>/dev/null | grep -E "Verification|subject"

# 5. Check which Cloudflare PoP is serving you
curl -s -o /dev/null -w "Status: %{http_code} — CF-Ray: %header{cf-ray}\n" https://yourdomain.com

In the Cloudflare dashboard you now have:

Analytics → real-time requests, bandwidth, unique visitors, cache hit ratio
Security → threats blocked, bot traffic, firewall events
Pages → Deployments → full deployment history, build logs, preview URLs for every branch

Part 9: Your Ongoing Deployment Workflow

Every future update follows this pattern:

# 1. Make your change locally
vim index.html        # add a new project, update bio, etc.

# 2. Commit with a meaningful message
git add .
git commit -m "feat: add HashiCorp Vault HA project card"

# 3. Push to GitHub
git push

# 4. Cloudflare Pages detects the push and deploys automatically
# Monitor at: dash.cloudflare.com → Workers & Pages → your project → Deployments

Deployment completes in under 30 seconds. The new version is live globally across 300+ Cloudflare edge locations simultaneously.

This is exactly how production static sites are deployed at scale. You just built the same pipeline engineering teams use at startups and enterprises. Write it on your CV.

Part 10: What Content to Put On It

Now that infrastructure is running, populate it with real content in this priority order:

Projects Section

For each project:

One-sentence description of the problem it solves
Technologies used — be specific: "Cloudflare Pages" not just "CDN"
Link to the GitHub repository
Link to your dev.to write-up if you published one

Troubleshooting

Site shows a Cloudflare error instead of your portfolio

Confirm the custom domain is activated: Workers & Pages → Custom domains → green checkmark
Check DNS has propagated: dig yourdomain.com CNAME
Wait 5–10 minutes and hard refresh

Build fails in Cloudflare Pages

Go to Deployments tab → click the failed deployment → View build log
For a static site with no build command, the most common cause is a misconfigured output directory
Ensure Build output directory is empty (not dist or build — those are for frameworks)

Custom domain not activating

Confirm nameservers are on Cloudflare: dig NS yourdomain.com
Check your domain shows Active status under Websites in Cloudflare
The domain must be active in Cloudflare before Pages custom domain recognition works

Mixed content warnings

All src= and href= attributes must use https:// or protocol-relative //
Cloudflare's Automatic HTTPS Rewrites handles most of these automatically

Changes not appearing after push

Check the Deployments tab — did the build succeed?
Hard refresh: Ctrl + Shift + R (Windows/Linux) / Cmd + Shift + R (Mac)
Go to Caching → Purge Everything in Cloudflare if the old version persists

Architecture Summary

You (developer)
      │
      │  git push origin main
      ▼
GitHub Repository (source of truth)
      │
      │  Cloudflare Pages webhook detects push
      ▼
Cloudflare Pages Build Pipeline
  ├── Pulls latest code from GitHub
  ├── Runs build (instant for static HTML/CSS/JS)
  └── Deploys to Cloudflare edge network
      │
      ▼
Cloudflare Edge (300+ PoPs globally)
  ├── Serves yourdomain.com
  ├── SSL/TLS — Full (strict)
  ├── CDN caching
  ├── Always-HTTPS redirect
  ├── DDoS protection (always-on)
  ├── Bot Fight Mode
  └── Brotli compression
      │
      ▼
End User — fast, secure, globally distributed ✅

What This Proves on Your CV

Personal Portfolio Website — Deployed static site via Cloudflare Pages with GitHub CI/CD integration. Configured custom domain, Full (strict) SSL, HSTS, DDoS protection, bot filtering, Brotli compression, and edge caching. Site globally distributed across 300+ Cloudflare PoPs with automated deployments triggered on every commit to main.

That is seven production skills in a project that costs $10/year to run.

Next Steps

Add Cloudflare Web Analytics — Analytics → Web Analytics → add your site. Free, privacy-respecting, no cookie banner needed
Add a contact form — Formspree or Web3Forms work without any backend
Write your first blog post and link it from the writing section — closes the loop on building in public
Add a Projects page — every Talent Forge project you complete gets a card here
Project 2: Containerise a real application with Docker and deploy via a full CI/CD pipeline

Resources

Cloudflare Pages Documentation
Cloudflare Pages — Git Integration
Cloudflare Pages — Custom Domains
Cloudflare SSL/TLS Docs
Reference Implementation: github.com/durrello/personal-website
Live Example: durrellgemuh.com

About the Talent Forge Program

This article is the official solution guide for Project 1 of the Talent Forge mentorship program — a free, structured DevOps curriculum run through NextGen Playground.

The program takes you from zero to a portfolio that gets you hired — through real projects, real infrastructure, and real documentation you can point employers at.

Join the program: discord.com/invite/fWUEh5x9PD
Enrol: forms.gle/XuD5a6nxi67xf7fY7

The GitLab variant (GitLab Pages + custom domain) is the companion article.

GKE Gateway API: Full Setup & Troubleshooting Runbook

Durrell Gemuh — Mon, 27 Apr 2026 11:04:59 +0000

I recently went through the full process of setting up GKE Gateway API on a production-grade cluster — Fleet registration, controller enablement, Helm deployment, and a handful of painful debugging sessions. This is the cleaned-up runbook so you don't have to learn these lessons the hard way.

Cluster Context

Field	Value
Project	`my-gcp-project`
Cluster	`my-gke-cluster`
Region	`us-east1`
Namespace	`my-namespace`

Traffic flow:
Client → Cloud Load Balancer → GKE Gateway (L7) → HTTPRoute → Kubernetes Service → Pod

1. Prerequisites & Initial Setup

Set project & cluster context

gcloud config set project my-gcp-project

gcloud container clusters get-credentials my-gke-cluster \
  --region us-east1

Enable required GCP APIs

gcloud services enable container.googleapis.com
gcloud services enable gkehub.googleapis.com
gcloud services enable serviceusage.googleapis.com
gcloud services enable multiclusteringress.googleapis.com
gcloud services enable multiclusterservicediscovery.googleapis.com

IAM permissions

Grant your service account the roles needed for Fleet and Ingress management:

SA=serviceAccount:my-service-account@my-gcp-project.iam.gserviceaccount.com
PROJECT=my-gcp-project

gcloud projects add-iam-policy-binding $PROJECT \
  --member="$SA" --role="roles/container.admin"

gcloud projects add-iam-policy-binding $PROJECT \
  --member="$SA" --role="roles/gkehub.admin"

gcloud projects add-iam-policy-binding $PROJECT \
  --member="$SA" --role="roles/serviceusage.serviceUsageAdmin"

2. Fleet Registration & Gateway Enablement

Enable Workload Identity

The Workload Identity pool must match your service project, not the host project.

gcloud container clusters update my-gke-cluster \
  --region us-east1 \
  --workload-pool=my-service-project.svc.id.goog

Register the cluster to Fleet

gcloud container fleet memberships register my-gke-cluster \
  --gke-cluster=us-east1/my-gke-cluster \
  --enable-workload-identity

# Verify
gcloud container fleet memberships list

Enable Fleet Ingress (Gateway controller)

gcloud container fleet ingress enable

# Verify — expected: state: ACTIVE, membershipStates: OK
gcloud container fleet ingress describe

Enable Gateway API at cluster level

This is a separate step from Fleet Ingress. Without it, kubectl get gatewayclass
returns nothing and the controller will never attach.

gcloud container clusters update my-gke-cluster \
  --region us-east1 \
  --enable-gateway-api

Enable a release channel

The GKE-managed Gateway controller requires a release channel to attach to the cluster:

gcloud container clusters update my-gke-cluster \
  --region us-east1 \
  --release-channel regular

Install Gateway API CRDs

kubectl apply -f https://github.com/kubernetes-sigs/gateway-api/releases/latest/download/standard-install.yaml

# Verify
kubectl get crds | grep gateway

Verify GatewayClasses

After the controller attaches, these should appear:

kubectl get gatewayclass

# NAME                                  CONTROLLER
# gke-l7-rilb                           networking.gke.io/gateway
# gke-l7-global-external-managed        networking.gke.io/gateway
# gke-l7-gxlb                           networking.gke.io/gateway
# gke-l7-regional-external-managed      networking.gke.io/gateway

3. Helm Chart Deployment

helm upgrade --install my-gateway-chart ./gateway \
  -n my-namespace --create-namespace

Validate

kubectl get gateway    -n my-namespace
kubectl get httproute  -n my-namespace
kubectl get svc        -n my-namespace
kubectl describe gateway -n my-namespace

4. Issues & Fixes

This is where things got interesting.

Issue 1 — GatewayClass missing

Symptom: kubectl get gatewayclass returns no resources.

Root cause: Fleet Ingress and Gateway API at cluster level are two separate
enablement steps. You need both.

Fix: Run --enable-gateway-api on the cluster (step 2 above).

Issue 2 — Gateway stuck "Waiting for controller"

Symptom: ArgoCD shows Gateway as Progressing indefinitely.

Root cause: No release channel was set. The managed controller won't attach
without one.

Fix: Set the release channel, then delete the Gateway resource and let ArgoCD
re-sync:

kubectl delete gateway my-https-gateway -n my-namespace
# ArgoCD will recreate it against the now-attached controller

Issue 3 — CertificateMap region mismatch

Error:

CertificateMap "my-cert-map-cert-map" must not be configured in a region other than global

Two things went wrong here simultaneously.

Problem A — Helm double-suffix bug

The Helm template was concatenating a suffix onto a value that already had it:

# values.yaml
certMap: my-cert-map

# template (broken)
networking.gke.io/certmap: {{ .Values.gateway.certMap }}-cert-map
# renders as: my-cert-map-cert-map ❌

# template (correct)
networking.gke.io/certmap: {{ .Values.gateway.certMap }}
# renders as: my-cert-map ✔

Problem B — Wrong GatewayClass

gke-l7-rilb is regional internal. CertificateMaps are global-only — they are
incompatible:

# WRONG
gatewayClassName: gke-l7-rilb            # regional internal, no certMap

# CORRECT
gatewayClassName: gke-l7-global-external-managed  # global, certMap supported

🚨 Rule to remember: CertificateMaps are GLOBAL ONLY. Never pair them
with a regional GatewayClass.

Issue 4 — HTTPRoute BackendNotFound

Error:

BackendNotFound: services my-namespace/<name> not found

Root cause: The backendRefs in the HTTPRoute used Helm value names, not the
actual Kubernetes Service names.

# WRONG — these were Helm value names, not Service names
backendRefs:
  - name: frontend-service   # ❌
  - name: search-service     # ❌

# CORRECT — exact Kubernetes Service names
backendRefs:
  - name: frontend           # ✔
  - name: search             # ✔
  - name: dashboard          # ✔
  - name: analytics-web      # ✔

5. Validation & Testing

Get the Gateway IP

kubectl get gateway -n my-namespace
# Look at the ADDRESS column

Why a bare curl returns 404

curl -v http://<GATEWAY-IP>
# 404 fault filter abort

This is expected. The Gateway matched the request but no HTTPRoute matched
the Host header. It's not an error — it confirms the Gateway is working.

Test with the correct Host header

curl -H "Host: myapp.dev.example.io" http://<GATEWAY-IP>
# Should return your app's HTML

DNS

Create an A record:

myapp.dev.example.io  →  <GATEWAY-IP>

HTTPS

curl -vk https://myapp.dev.example.io

Local pod test

kubectl port-forward svc/analytics-web 8080:3000 -n my-namespace
curl http://localhost:8080

6. ArgoCD Cleanup

Orphaned HTTPRoutes from previous deploys will cause ArgoCD to show Degraded
even when the app is healthy. Clean them up:

kubectl delete httproute old-frontend-route  -n my-namespace
kubectl delete httproute old-search-route    -n my-namespace

Or enable pruning in your ArgoCD Application:

syncPolicy:
  syncOptions:
    - PruneLast=true

7. Quick Debug Reference

# Gateway status
kubectl describe gateway   -n my-namespace
kubectl get gateway -n my-namespace -w

# HTTPRoutes
kubectl describe httproute -n my-namespace

# Controller (no pods = managed mode, that's normal)
kubectl get pods -A | grep -i gateway
kubectl get gatewayclass
kubectl get crd | grep gateway

# Cluster config
gcloud container clusters describe my-gke-cluster --region us-east1

# Events
kubectl get events -n my-namespace --sort-by=.lastTimestamp

8. Final State

Component	Status
GatewayClass	✅ Accepted
Gateway	✅ Programmed
HTTPRoute	✅ Healthy
Services	✅ Resolved
Load Balancer	✅ Active
Pods	✅ Running
ArgoCD	✅ Synced

9. Key Lessons

Fleet Ingress ≠ Gateway controller ready. You need --enable-gateway-api separately on the cluster.
No release channel = no controller attachment. Add the cluster to regular or stable.
CertificateMaps are global only. Never use them with gke-l7-rilb or any regional GatewayClass.
Helm string concatenation silently breaks GCP resource names. Always helm template and inspect the rendered output before applying.
HTTPRoute backendRefs need exact Service names. Your Helm value names and your Kubernetes Service names are not the same thing.
404 fault filter abort = hostname mismatch, not a broken Gateway. Check your Host header.
No gateway pods in GKE managed mode is normal. The controller is cloud-managed.
Dataplane V2 can't be enabled on an existing cluster. You'd need to recreate it — and it's not required for Gateway API anyway.

10. Improvements Worth Making

Wildcard hostname — Reduces per-service HTTPRoute config significantly:

spec:
  hostnames:
    - "*.dev.example.io"

CI validation — Add a pre-deploy check that verifies every backendRef name exists as a live Service in the target namespace. This eliminates the BackendNotFound class of errors before they hit the cluster.

Helm schema guards — Use values.schema.json to validate that your certMap value doesn't already end with the suffix your template appends. Catches double-suffix bugs at helm lint time.

Unified naming — Make your Helm release name, Kubernetes Service name, and HTTPRoute backendRef all derive from the same value. One source of truth, zero drift.

Hope this saves someone a few hours. The GKE docs cover each of these pieces individually but the interactions between them — especially Fleet Ingress vs cluster-level Gateway API enablement, and the CertificateMap GatewayClass constraint — aren't obvious until you hit them.

Getting Started with Amazon CloudWatch

Durrell Gemuh — Sun, 12 Apr 2026 01:56:26 +0000

Monitoring is one of the most overlooked parts of building systems.

Until something breaks.

Then suddenly, it becomes the most important thing in your entire stack.

If you're working in AWS, one tool sits at the center of this:

Amazon CloudWatch

This post breaks down what CloudWatch actually does, how teams use it in real environments, and how you can get started without overcomplicating things.

Why CloudWatch Matters

In real-world systems, you need to answer three critical questions:

What is happening right now?
What happened earlier?
When should I react?

CloudWatch helps you answer all three.

Without monitoring, you're operating blind.

Core Components of CloudWatch

You don’t need to learn everything at once. Focus on these four:

Metrics: What’s Happening?

Metrics are numerical data points collected over time.

Examples:

CPU utilization (EC2)
Memory usage
Request count
Error rates

You use metrics to understand system behavior.

Logs: What Happened?

Logs give you detailed insight into events inside your system.

Examples:

Application logs
System logs
Container logs

Logs are what you check when something goes wrong.

Alarms: When to React

Alarms trigger actions based on metrics.

Examples:

CPU > 80%
Error rate spike
Instance down

Alarms help you move from reactive → proactive.

Dashboards: One View

Dashboards combine metrics and visualizations into one place.

They help teams:

Monitor systems in real-time
Share visibility across teams
Track key performance indicators

Real-World Use Case

Let’s say you deploy an application on AWS.

Here’s how CloudWatch fits in:

EC2 sends CPU and network metrics
Your app sends logs to CloudWatch Logs
You create alarms for:
- high CPU
- failed requests
You build a dashboard to visualize everything

Now you have:

visibility
alerts
debugging capability

That’s production-ready thinking.

Common Mistakes

Most beginners:

Try to configure everything at once
Ignore logs
Create too many alarms
Don’t test alerting

Keep it simple.

How to Get Started (Practical)

Start with this:

Enable default metrics for EC2 or your service
Send application logs to CloudWatch Logs
Create 1–2 alarms (CPU, errors)
Build a simple dashboard

That’s enough to begin.

You can scale later.

Pro Tip

Monitoring is not something you “add later.”

It’s part of the system design.

Final Thought

CloudWatch is not just a tool.

It’s how you understand your system.

And if you don’t understand your system — you can’t operate it.

What does it really cost to become a DevOps engineer? Getting started in DevOps without spending a dime

Durrell Gemuh — Sun, 05 Apr 2026 09:25:51 +0000

Let's be real, when most people Google "how to become a DevOps engineer," they land on listicles selling $500 Udemy courses, $300/year certification prep, and cloud subscriptions that bill you before you've written your first pipeline.

Here's the truth: you don't need to spend anything to get started. Zero.

What is DevOps, really?

DevOps is a culture, a set of practices, and a toolchain that bridges software development and IT operations. It's about shipping faster, breaking less, and recovering quickly when things go wrong. Learnable for free.

OS and virtualization

Ubuntu / Debian The go-to Linux distro for learning. Free, well-documented, massive community.
VirtualBox Run Linux VMs on any machine. Free and cross-platform.
WSL2 Run a full Linux environment inside Windows. No VM overhead needed.
Multipass Instantly spin up Ubuntu VMs on Mac, Windows, or Linux. Free CLI tool.

Version control and collaboration

Git The foundation. Learn it before anything else. Free and open source.
GitHub / GitLab (free tier) Host repos, run CI/CD pipelines, and build your public portfolio.
Gitea Self-hosted GitHub alternative. Great for practicing on-premise Git workflows.

Containers and orchestration

Docker (community edition) Build, ship, and run containers. Free for personal use.
Podman — A daemonless Docker alternative. Free and increasingly enterprise-standard.
Minikube / kind / k3s — Run Kubernetes locally. No cloud bill needed.
Play with Docker / Play with Kubernetes — Browser-based sandboxes. Zero install, zero cost.

CI/CD pipelines

GitHub Actions Free for public repos. The best starting point for CI/CD.
GitLab CI/CD 400 free CI minutes per month. Built-in, no plugin setup.
Jenkins Open source, self-hosted. Still widely used in enterprise.
Tekton Kubernetes-native CI/CD. Open source and cloud-agnostic.

Infrastructure as code

Terraform / OpenTofu — Define cloud infra as code. OpenTofu is the open source fork — free forever.
Ansible — Agentless automation for config management and deployments. Open source.
Pulumi (free tier) — IaC using real programming languages (Python, TypeScript, Go).

Monitoring and observability

Prometheus Open source metrics collection and alerting. The industry standard.
Grafana (open source) Build dashboards. Completely free self-hosted.
Loki Like Prometheus, but for logs. Free and open source.
Netdata Real-time system monitoring with zero config.
OpenTelemetry Open standard for traces, metrics, and logs. Vendor-neutral and free.

Cloud free tiers

AWS Free Tier 12 months of EC2, S3, Lambda, and more at no cost.
Google Cloud Free Tier $300 credit for 90 days plus an always-free e2-micro VM.
Azure for Students $100 credit, no credit card required.
Oracle Cloud Free Tier Two free AMD VMs forever. The most generous always-free compute.
Fly.io / Render / Railway Deploy real apps for free. Great for portfolio projects.

Scripting and languages

Bash Ships with every Linux system. Learn this first.
Python Used everywhere in DevOps for automation and tooling. Free.
Go (Golang) Docker, Kubernetes, and Terraform are written in Go. Free to learn and use.

Free learning platforms

roadmap.sh/devops The community-maintained DevOps roadmap. Start here for direction.
KodeKloud (free tier) Hands-on browser labs for Docker, Kubernetes, and Ansible.
Linux Foundation / edX LFS101 and several Kubernetes intro courses are free.
FreeCodeCamp Free courses and YouTube content on Linux and cloud fundamentals.
90DaysOfDevOps (GitHub) A 90-day structured learning journey. Completely free on GitHub.
AWS Skill Builder / Google Cloud Skills Boost Official free learning paths from AWS and Google.

Build something. Anything.

Deploy a personal blog with Docker and GitHub Actions. Set up a Prometheus and Grafana monitoring stack for a side project. Automate something annoying. Put it on GitHub. That portfolio gets you hired — not the course completion certificate.

The barrier to DevOps is time and consistency, not money.

What questions do you have about getting started? Drop them in the comments, happy to help.

AWS Service Spotlight: AWS Systems Manager (SSM)

Durrell Gemuh — Thu, 26 Mar 2026 13:32:40 +0000

Welcome to my AWS Service Spotlight series, where I break down AWS services, how they work, when to use them, and how they fit into real-world DevOps systems.

This week we're talking about AWS Systems Manager (SSM) one of those services that quietly does a ton of heavy lifting in production environments, yet doesn't always get the spotlight it deserves.

What is AWS Systems Manager?

Simply put, SSM is AWS's operations hub for managing your infrastructure at scale. Think of it as a remote control for your EC2 instances — and a whole lot more.

More technically: SSM is a collection of tools that lets you automate operational tasks, run commands across fleets of instances, manage configuration, patch systems, and access instances securely — all without needing a bastion host or open SSH/RDP ports.

Why Use It?

The Problem It Solves

Managing dozens or hundreds of servers manually is a nightmare. You'd need to SSH into each one, run scripts, hope nothing breaks, and repeat. SSM eliminates that entirely.

Use it when you need to:

Run commands across many instances simultaneously
Install software or agents on a fleet without manual access
Access instances that have no public IP or open ports
Automate patching and compliance checks
Store and retrieve secrets and config values securely

Who should care:

DevOps and platform engineers managing cloud infrastructure
Security teams who want auditability and zero open ports
Anyone deploying software to EC2 at scale

How I Used It This Week

This week I had a real, practical challenge: deploy the Datadog monitoring agent across a mixed fleet of Linux and Windows EC2 instances — in a way that any AWS account could run, without hardcoding credentials or writing instance-specific scripts.

Here's what I did:

I created two public SSM Command documents — one for Linux, one for Windows — and published them from a central AWS account with public permissions, so they're callable by ARN from literally any AWS account in the world.

Each document accepts just two parameters at runtime:

DDApiKey — the Datadog API key
DDSite — the Datadog intake region (defaults to datadoghq.com)

For Linux, the document runs the official Datadog shell installer via curl. For Windows, it uses msiexec with the Datadog MSI package — and getting the PowerShell quoting right (outer single quotes, inner escaped double quotes) was the key to making it work reliably through SSM.

The result: a one-click, parameterized, cross-OS monitoring deployment that any team can run against their fleet in minutes — no SSH, no RDP, no manual steps.

Step-by-Step: How I Built and Published the SSM Documents

Here's exactly how I did it — entirely through the AWS Console, no CLI required.

Step 1: Create the Linux Document

Go to AWS Console → Systems Manager → Documents
Click "Create document" → "Command or Session"
Fill in the details:
- Name: InstallDatadogAgent-Linux
- Document type: Command document
- Content format: JSON
Paste the following content:

{
  "schemaVersion": "2.2",
  "description": "Installs the Datadog Agent (v7) on Linux.",
  "parameters": {
    "DDApiKey": {
      "type": "String",
      "description": "(Required) Your Datadog API Key"
    },
    "DDSite": {
      "type": "String",
      "description": "Datadog intake site.",
      "default": "datadoghq.com",
      "allowedValues": [
        "datadoghq.com",
        "datadoghq.eu",
        "us3.datadoghq.com",
        "us5.datadoghq.com",
        "ap1.datadoghq.com"
      ]
    }
  },
  "mainSteps": [
    {
      "action": "aws:runShellScript",
      "name": "InstallDatadogLinux",
      "inputs": {
        "runCommand": [
          "DD_API_KEY={{ DDApiKey }} DD_SITE={{ DDSite }} DD_AGENT_MAJOR_VERSION=7 bash -c \"$(curl -L https://install.datadoghq.com/scripts/install_script_agent7.sh)\""
        ]
      }
    }
  ]
}

Click "Create document"

Step 2: Create the Windows Document

Back in Documents → Create document → Command or Session
Fill in the details:
- Name: InstallDatadogAgent-Windows
- Document type: Command document
- Content format: JSON
Paste the following content:

{
  "schemaVersion": "2.2",
  "description": "Installs the Datadog Agent (v7) on Windows.",
  "parameters": {
    "DDApiKey": {
      "type": "String",
      "description": "(Required) Your Datadog API Key"
    },
    "DDSite": {
      "type": "String",
      "description": "Datadog intake site.",
      "default": "datadoghq.com",
      "allowedValues": [
        "datadoghq.com",
        "datadoghq.eu",
        "us3.datadoghq.com",
        "us5.datadoghq.com",
        "ap1.datadoghq.com"
      ]
    }
  },
  "mainSteps": [
    {
      "action": "aws:runPowerShellScript",
      "name": "InstallDatadogWindows",
      "inputs": {
        "runCommand": [
          "$p = Start-Process -Wait -PassThru msiexec -ArgumentList '/qn /i \"https://windows-agent.datadoghq.com/datadog-agent-7-latest.amd64.msi\" /log C:\\Windows\\SystemTemp\\install-datadog.log APIKEY=\"{{ DDApiKey }}\" SITE=\"{{ DDSite }}\"'",
          "if ($p.ExitCode -ne 0) {",
          "  Write-Host \"msiexec failed with exit code $($p.ExitCode). Check C:\\Windows\\SystemTemp\\install-datadog.log\" -ForegroundColor Red",
          "  exit $p.ExitCode",
          "}"
        ]
      }
    }
  ]
}

Click "Create document"

Step 3: Make Both Documents Public

This is the step that makes the documents usable from any AWS account in the world.

For each document:

Go to Documents → Owned by me
Click the document name
Go to the "Permissions" tab
Select Public acknowledge and save.

That's it. The document is now publicly accessible via its ARN.

Step 4: Copy the Document ARN

On each document's detail page, copy the ARN. It looks like:

arn:aws:ssm:us-east-1:123456789012:document/InstallDatadogAgent-Linux
arn:aws:ssm:us-east-1:123456789012:document/InstallDatadogAgent-Windows

Anyone in any AWS account can now reference these ARNs directly in Run Command — no need to copy or recreate the documents.

Step 5: Run the Documents

From any AWS account:

Go to Systems Manager → Run Command
Click "Run command"
In the search box → select "Document name prefix" → paste the full ARN
Fill in parameters:
- DDApiKey → your Datadog API key
- DDSite → datadoghq.com (or your region)
Under Targets → choose instances by tag or select manually
Click "Run"

A Note on Document Content

The two documents are intentionally kept minimal and focused:

No hardcoded values — API key and site are always passed at runtime
Separate documents per OS — avoids the SSM precondition quirk that causes false failures on mixed fleets
No environment or tag parameters — kept lean so anyone can run it without knowing your internal tagging conventions
Linux uses the official Datadog shell installer — the same script you'd run manually
Windows uses the official MSI installer via PowerShell's Start-Process — the quoting pattern (outer single quotes, inner escaped double quotes) is critical for SSM to pass the arguments correctly to msiexec

IAM Requirement

Before SSM can communicate with an instance, the instance needs an IAM Role attached with this single policy:

AmazonSSMManagedInstanceCore

To set it up:

IAM → Roles → Create role → EC2
Attach AmazonSSMManagedInstanceCore
Name it EC2-SSM-Role → Create
EC2 → Select instance → Actions → Security → Modify IAM role → attach the role

No reboot needed. SSM will recognize the instance within about a minute.

Other Real-World Use Cases

DevOps Pipelines
Trigger SSM Run Command from a CI/CD pipeline to deploy application updates across an auto-scaling group after a build completes.

Kubernetes (EKS)
Use SSM Session Manager to access EKS worker nodes securely without exposing SSH. Great for debugging node-level issues.

Security & Compliance
Use SSM Patch Manager to automatically patch OS vulnerabilities on a schedule and audit compliance across your fleet.

Secrets & Config Management
Store database passwords, API keys, and feature flags in SSM Parameter Store. Pull them securely at runtime in Lambda, ECS, or EC2 — no hardcoded secrets.

Incident Response
Use Run Command to instantly restart services, collect logs, or run diagnostics across an entire fleet during an incident — in seconds, not hours.

Hybrid & On-Prem
SSM works with on-premises servers too via Hybrid Activations. Manage your data center the same way you manage your cloud.

Key Features

Run Command — execute scripts across any number of instances simultaneously
Session Manager — browser-based terminal, no SSH keys or open ports needed
Parameter Store — secure storage for config values and secrets
Patch Manager — automated OS patching with compliance reporting
State Manager — enforce desired configuration state continuously
Distributor — package and deploy software agents at scale
Documents — reusable, versionable, shareable automation scripts
Public Documents — shareable across any AWS account via ARN

How It Works (High-Level)

Every EC2 instance runs an SSM Agent (pre-installed on most modern AMIs). This agent maintains a persistent, outbound-only connection to the SSM service endpoints over HTTPS.

When you trigger a Run Command or Session:

You (Console/API)
      ↓
AWS SSM Service
      ↓
SSM Agent on Instance (outbound HTTPS — no inbound ports needed)
      ↓
Executes command, streams output back

The instance needs:

SSM Agent installed and running
IAM Role with AmazonSSMManagedInstanceCore policy attached
Outbound HTTPS (port 443) to SSM endpoints

No VPN, no bastion, no open security group rules.

Integration with Other AWS Services

Service	How SSM Works With It
EC2	Core target — manage instances directly via agent
IAM	Role-based access controls who can run what documents
S3	Stream command output to S3 for long-running jobs
CloudWatch	Send SSM logs and metrics to CloudWatch for alerting
EKS	Access worker nodes securely via Session Manager
Lambda	Pull config/secrets from Parameter Store at function runtime
EventBridge	Trigger SSM automations on schedule or in response to events

Alternatives

AWS Alternatives:

AWS OpsWorks — configuration management using Chef/Puppet, heavier setup
AWS Config — focused on compliance auditing, not execution
EC2 User Data — runs scripts at launch only, not on-demand

Non-AWS Alternatives:

Ansible — powerful but requires network access and more setup
Chef / Puppet — enterprise config management, complex overhead
Terraform — infrastructure provisioning, not runtime operations

SSM wins when you're already in AWS and want zero additional infrastructure to manage.

When NOT to Use It

You need complex configuration management with dependency resolution — Ansible or Chef handles that better
Your instances are not on AWS and you don't want Hybrid Activations overhead
You need real-time streaming logs — CloudWatch or a dedicated log agent is better suited
You're managing containers directly — native ECS/EKS tooling is more appropriate
Your team is already deeply invested in Ansible — adding SSM creates duplication without enough gain

Final Thoughts

SSM is one of those services you don't fully appreciate until you've managed infrastructure without it. Once it clicks — the secure access, the fleet-wide automation, the public reusable documents — it becomes a default part of how you think about AWS operations.

This week's use case was a great reminder that SSM isn't just for patching or basic scripts. With a little thought, you can build reusable, cross-account, cross-OS automation that scales to any team or environment.

If your EC2 instances don't have SSM set up yet, that's the first thing I'd fix.

Let's Connect

If this helped you think differently about AWS operations, drop a comment or share it with someone managing EC2 fleets.

I'm also building NextGen Playground — a platform helping engineers gain real-world DevOps experience through hands-on projects, mentorship, and practical learning.

If you're trying to level up your cloud and DevOps skills with real projects, not just tutorials — check it out and let's build together.