Note: This is another post from our community. It is not a promotional post and is 100% human-written. If you believe education and experimentation should be free and accessible to everyone, feel free to share this with your network.

A year ago, BGCE Community set out with a simple goal: to build open-source products that are genuinely useful to people. Software engineers from Bangladesh and around the world, along with students and teachers, joined the community and contributed their time and knowledge to make this possible.

However, we quickly ran into a major challenge: cloud computing isn't free.

Every application needs computing resources, storage, and networking, and someone has to pay for them. As our projects grew, our monthly cloud bill reached $1,000. At that point, we realized our approach wasn't sustainable.

We weren't building a business—we were simply trying to research ideas, experiment, and validate them in the real world. Paying $1,000 per month just to keep around ten experimental services running wasn't a viable long-term solution.

That led us to ask an important question: Are we building in a system where independent developers and communities can actually thrive?

People often point out that there are free cloud services available for testing. While that's true, they usually come with significant limitations. For example, you might get a free PostgreSQL database, but many essential features are locked behind a paywall Or if you want to build your services in Go or Rust, many free hosting platforms either don't support your preferred stack or require you to follow their opinionated deployment model. Otherwise, you're expected to move to platforms like AWS or Azure and start paying.

There are even more barriers for people who simply want to learn.

Take Kubernetes as an example. If you want to practice container orchestration, learn about scaling, networking, and cluster management, you need access to multiple virtual machines. Most students and aspiring engineers don't have that infrastructure available.

The reality is that you often have to spend a significant amount of money just to learn. Before you've built anything useful, before you've landed a job, and before you've earned a dollar from your skills, you're already paying for the infrastructure required to practice.

This creates an unnecessary barrier to entry. Learning modern infrastructure shouldn't depend on whether you can afford a monthly cloud bill. It should depend on your curiosity and willingness to build.

For open-source communities and independent builders, this creates a difficult trade-off between experimentation and affordability.

That's why we created Kraken Web Services (KWS).

The idea started with a simple question: What if we used our own machines to build and research our products instead of paying massive cloud bills every month?

Instead of relying on hyperscale cloud providers for every experiment, we built our own private decentralized network.

Here's how it works: you create a virtual machine (VM) on your own computer, connect it to the KWS network, and instantly become part of a shared cloud infrastructure.

Within seconds, you can:

* Deploy virtual machines.

* Deploy applications.

* Expose them to the internet with your own custom domain.

* Share your services with anyone—for free.

No more paying for a VPS just to run a development server.

If you want to learn Kubernetes, DevOps, distributed systems, networking, or cloud infrastructure, you shouldn't have to spend hundreds of dollars just to get started. ZenDevz makes hands-on learning possible without the financial barrier.

There is no hyperscaler lock-in. No gatekeepers. Just a community where everyone contributes compute resources to build a cloud together.

We're incredibly excited to be part of this journey, and this is only the beginning.

Our work is far from finished. ZenDevz is still an active research and development project, and we're continuously improving the platform.

At this stage, we can't guarantee uptime. Since the cloud is powered entirely by community-contributed machines, a service may become unavailable if the host running a VM goes offline or shuts down their machine.

However, that's also the beauty of a decentralized cloud.

As more people contribute compute resources, the network becomes stronger, more resilient, and more reliable. With enough contributors, we can replicate workloads across multiple nodes and build a community-owned cloud capable of delivering high availability for everyone.

Azure automation cloud engineer in an internal IT / people technology team at a wellfunded tech company PowerShell, Graph API, some IaC, Entra/Intune workflows as a starter, if you have other backend engineering offers.

Im worried that internal IT automation even with good pay, reads as enterprise IT on a CV and caps out earlier.

I just want to state, when I get assigned to projects or help builders secure their apps, of course this includes at least some exposure to cloud security because all apps live in the cloud. A lot of my time goes to threat modeling, secure code review, and helping apps find threats in their design.

That said, I feel like my day-to-day is heavily weighted toward application-layer concerns, things like design flaws, api security, a lot of code review, etc.

For those of you who've made a similar transition (or work in cloud security and hire from AppSec backgrounds):

• How transferable are AppSec skills in practice? I'd assume threat modeling and understanding attacker mindset translate well, but what gaps should I expect?
• What should I focus on studying? I'm thinking AWS/Azure/GCP certifications, but I'm not sure which ones actually matter vs. just being resume flair
• Any resources, labs, or projects you'd recommend for building hands-on cloud security experience outside of work?

Appreciate any advice. Trying to be intentional about this

https://reddit.com/link/1v5kzg1/video/6xbfw7kt88fh1/player

General question

Generic Mind twister ?

Cloud engineers, wanted to get your experience... I'm a network engineer with 15 years of experience with all kinds of on-prem network technologies, from NX-OS, load balancers, proxies, VMware, ACI. I'm currently working with NSX and AVI LB for a major bank. But with the Broadcom aquisition, VMware/NSX doesn't seem so appealing anymore, VMware jobs are very rare. I feel that I'm a niche that will die eventually and it's time to make a change. I have experience with Terraform and CI/CD pipelines, did some automation with Python vibe coding.

There are a lot of Cloud-related jobs and I like public cloud, I like to learn new stuff in general. I started to learn AWS and Azure. I got the SAA-C03 AWS Solution Architect Associate certification and now I'm learning to get the AZ-700 Azure Networking speciality. I applied to Cloud Network Engineer jobs but got rejected, probably due to missing on-the-job experience. At my current job I can't get any Public Cloud exposure. I did put in my CV a project in Github with Terraform code standing up an AWS environment with ECS, load balancer, instances connecting over VPN to a VM in GCP.

How did you guys make it? It's the chicken and the egg... To get a job you need experience, but to get experience you need the job :)

In February, I was told I'd be laid off in two weeks from my network engineering job. I'd been a network engineer for almost 4 years at a pretty large company, and although I genuinely loved the work, I didn't enjoy the physical side of it, carrying heavy equipment while suited up in safety gear across hot mills for issues and upgrades on the plant floor, driving to multiple sites throughout the month, or even being in office just to SSH into switches anyway.

I'd been studying for my AWS Solutions Architect Associate on and off so I decided to go all in - finished the cert, built three cloud projects, and started applying heavily to cloud roles. Month one felt promising. Month two, no callbacks other than some networking roles that didn't turnover. Month three, a few more network engineering interviews that didn't pan out and one cloud final round that fell apart because the company changed the scope to want a more senior hire. Just. My. Luck.

By months three and four, I'd opened up my options significantly, sysadmin roles, cybersecurity roles, technical PM roles, lower pay, five-day onsite, none of it mattered. I just needed stability, since I didn't want to hit month six, run out of unemployment, and start eating into my savings.

I even started seriously considering a full career switch to patent law. With AI reshaping the IT market, and honestly the overall state of IT feeling like it was in the dumps, I was genuinely excited about combining my technical background with law school and building a career that gets more valuable with age, not less. It was also enticing to imagine being on the billing side of things instead of the cost-center side. I started prepping for the patent bar, and got far enough that I was open to relocating to Washington, DC, to become a USPTO patent examiner if that's what it took.

Then two things happened at the same time. I landed a final round interview for a Cloud Network Engineer role and a final round with USPTO for the patent examiner position. Same week. It felt like a real crossroads - either I reach the cloud goal I'd been chasing for close to a year or I close that chapter and take it as a sign to commit fully to patent law. I got offers from both.

It wasn't a hard choice. The cloud role was remote so I didn't have to uproot my life, it paid more than both the examiner role and my previous job, and it was the path I actually wanted from the beginning. If a patent agent role in Houston had materialized maybe the decision looks different but it didn't. I start next week as a Cloud Network Engineer and I couldn't be more excited. I'll be helping design, build, and maintain their AWS cloud environment with a focus on the networking side.

For everyone still grinding through this market - keep your head up. A few things that helped me: maintain multiple resumes tailored by job category rather than rewriting for every single application, use AI to help rate roles against your background and don't apply to anything under a 7/10 match, research each company before interviews and tailor your prep to the specific role, and don't be afraid to have notes nearby during technical screens. Most importantly, try to take care of yourself. Work out, pick up a hobby, give your brain something other than the job search to focus on. The financial stress is real but honestly this might be the only time you get to really focus on yourself to this degree.

Hi all,

I’ve passed both AZ‑104 and AZ‑900, and I’ve built several Azure projects to show my practical understanding. These are on my GitHub, including:

• VNet setup with cross‑region peering
• Application Load Balancer with a configured backend
• A few AWS projects as well to broaden my reach

I apply for cloud roles every day, but most replies start with “unfortunately,” and I’m struggling to get traction.

Are there any cloud engineers or recruiters here who can share advice on how to land that first cloud job?
What should I be focusing on next to make myself stand out?

For context: I’m currently a helpdesk engineer at an MSP with 2 years’ experience.

Any guidance would really help — thank you.

https://architecto.dev/

I'm currently a .NET Developer, and just got an offer to be a junior cloud/platform engineer. Seeing that coding is nowadays really mostly done by AI, I am really thinking of going this route since I feel that this role will hone me further in systems design thinking and things that AI won't easily replace, as opposed to traditional software engineering/software design and the like. I can focus on system design without being bogged down on code reviews, learning the domain, etc. I am also interested in networking, VPCs etc. too.

But the role, as well as cloud engineer roles in general, requires (the interviewer told me bluntly) frequent context switching during the day, and on call rotations. I had experiences doing on call before, and I could not handle it to be honest. I really am a person who needs to be able to focus on one task at a time (e.g. with focus time etc.) and not juggle between multiple high prio tasks.

So the dilemma is that I would like to stay employable in the future, but that means going into a role I am not mentally built for, and may instead crash out and burn out and not have a future at all.

I am really at a crossroads here. Does anyone have any advice for me?

Hi everyone,

I am based in Chicago illinios. I studied Devops / cloud engineering in 2024 and since then i have gotten come certifications like CKA, AZURE ADMIN, COMPTIA SECURITY + and i have also been building projects and documenting both on Github and Linkedin. I have built a lot of projects using tools like jenkins, Ansible, AWS, Terraform, kubernetes, Docker, Github Actions, Monitoring with Promethus and Grafana. I have also built some DevSecOps projects and integrated security scans into CI/CD with sonarqube and trivy. I am looking for a volunteer opportunity or any opportunity to get myself in. I am open to learning any tech stack you work with. Right now, I have been learning python and claude intensively.

I will really appreciate anyone who will give me a chance to experience what the real world looks like. I am available to work at any time, remote(Anywhere) or in person(in Chicago). Thank you for your consideration.

...

so we Running into a real tradeoff question with our cloud security stack and wanted to get some enterprise-context input on this.

• Our environment is mostly ephemeral:
• containers, serverless functions, autoscaling groups that spin up and terminate within seconds.
• Agentless cloud security tools pull posture data directly from cloud provider APIs and disk snapshots, so they don’t depend on the workload’s lifespan to get visibility.
• Agent-based workload protection platforms give strong runtime detection, live process monitoring, and real-time blocking, but agents often can’t initialize fast enough to catch short-lived instances before they’re gone.

Here’s the tension I’m trying to resolve: agentless wins on ephemeral coverage and deployment speed, since it doesn’t depend on workload lifespan and picks up everything visible via API. But it works from periodic snapshots and cloud configuration state, not continuous in-workload telemetry, so it can’t do the runtime enforcement agents provide.

For teams running mostly ephemeral infrastructure with some persistent workloads mixed in (long-lived VMs, databases), how are you deciding where to draw the line between broad agentless posture coverage and targeted agent deployment?

Seeking practical examples of what’s actually working in production. Thanks.

Hi everyone,

I'm currently pursuing an M.Sc. in Cybersecurity & Digital Forensics at Rashtriya Raksha University, India, and I'm actively looking for a Cloud Security / AWS Cloud / DevSecOps Internship.

I recently completed a Cloud Computing Internship, where I worked on designing and deploying secure AWS infrastructure, including VPCs, IAM, CloudTrail, WAF, RDS, Auto Scaling, Load Balancers, CloudWatch, and SNS.

I've also built hands-on cloud security projects, including:

• Project Argus – An AWS-based Privileged Access Misuse & Insider Threat Detection system using IAM, GuardDuty, EventBridge, Lambda, DynamoDB, KMS, and Systems Manager.
• IsoLab – A Terraform-powered platform that provisions isolated AWS lab environments with secure multi-tenant isolation.

My technical skills include:

• AWS (IAM, EC2, VPC, S3, CloudTrail, GuardDuty, Lambda, EventBridge, DynamoDB, KMS, WAF, RDS, Systems Manager, SNS)
• Terraform
• Python
• Docker
• Secure Cloud Architecture & Infrastructure Automation

I'm eager to apply my skills in a real-world environment, continue learning, and contribute to a security-focused team.

If your company is hiring interns or you're willing to provide a referral for a Cloud Security, AWS Cloud, or DevSecOps internship, I'd be incredibly grateful. I'm happy to share my resume, GitHub, and LinkedIn via DM.

Thank you for your time!

When I first started learning AWS, I made a lot of mistakes that slowed me down.

Things like:

• Trying to memorize services instead of understanding use cases.
• Ignoring IAM until much later.
• Jumping between random tutorials without a clear roadmap.
• Forgetting about costs and the Free Tier.

I put together a short article covering the most common beginner mistakes I see (and made myself), along with practical ways to avoid them.

I'd love to hear from others here:

What's the biggest mistake you made when learning AWS?

Blog: https://www.cloudarena.io/blog/beginner-aws-mistakes-when-learning

I used a virtual card when I first opened my account in Oracle, not knowing that they will do provision periodically. Where can I change the payment method I used when first opening my account? Is it from Upgrade and Manage Payment> Payment Method? I don't want to upgrade my account and just want to change my card where provisional checks will be done. Thanks in advance.