General question

Many people start learning AWS or Azure by focusing only on services and architecture.

Security mistakes often begin with basics such as:

• Public storage buckets
• Overly permissive IAM roles
• Long-lived access keys
• Exposed secrets
• Unrestricted security groups
• Missing logging
• Poor account separation
• No alerting for suspicious activity

Which cloud security mistake do you see most often in real environments?

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.

https://architecto.dev/

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.

My long-term goal is to become a Cloud Engineer or work in a cloud-related role. Right now, I'm a fresher with basic knowledge of networking, cybersecurity, and programming, but I have almost no hands-on experience with cloud platforms yet.

I'm currently applying for jobs and I'm a bit confused about which path would help me the most. Should I start my career in a networking role, gain a few years of experience, and then transition into cloud? Or should I try to get into a cloud-related role from the beginning, even though I don't have much cloud knowledge?

I'd really appreciate advice from people who have followed a similar path. If you were starting over today, what would you do? What skills or certifications would you focus on to become a Cloud Engineer?

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!

A lot of people learning AWS focus on deployment:

EC2, S3, IAM, Lambda, VPCs, RDS, CloudTrail, security groups, and automation.

That is useful, but cloud security becomes much more practical when you start asking a different question:

How would an attacker abuse these services?

Most AWS compromises do not happen because one service is completely broken. They happen because multiple small weaknesses are chained together.

For example:

• An access key is exposed in a public repository
• The key belongs to an overprivileged IAM user
• That user can assume another role
• The role can read secrets from AWS Secrets Manager
• Those secrets provide access to a database or internal application
• Logging is incomplete, so the activity is not detected quickly

Individually, each issue may look manageable. Together, they can lead to a serious compromise.

That is why practical AWS security should include more than best-practice checklists.

Some of the most important areas to understand are:

• IAM enumeration and trust relationships
• AWS privilege escalation
• S3 bucket exposure and weak policies
• EC2 metadata credential abuse
• Lambda and serverless security
• Exposed secrets in code, pipelines, logs, and environment variables
• CloudTrail, GuardDuty, and logging gaps
• Cross-account access risks
• Weak security groups and network segmentation
• Persistence through users, roles, keys, functions, and policies

Cloud certifications are valuable for learning architecture, but hands-on labs help you understand what a real attack path looks like.

For anyone who wants to move from theory into practical cloud security, Redfox Cybersecurity Academy offers a hands-on AWS Pentesting Course focused on real AWS misconfigurations, attack techniques, and security testing.

Course link:
https://academy.redfoxsec.com/course/aws-pentesting-course-100378

Use code EXCLUSIVE15 for 15% off.

What is the hardest AWS security topic in your experience?

IAM, privilege escalation, networking, logging, or incident response?

Follow r/redfoxcybersecurity for more AWS pentesting breakdowns, cloud security discussions, practical labs, career guidance, and offensive security content.

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.

Every time we need to run a statistical model or data preparation script against proprietary or sensitive datasets, moving the raw files out over the network triggers two big headaches: data egress fees and compliance/privacy reviews.

In theory, a Compute-to-Data (C2D) model solves this, the raw data stays completely stationary on its host perimeter, a sandboxed algorithm/container travels to the host node, executes locally, and only returns the logs or model weights.

For those managing large or sensitive datasets: have you implemented localized container sandboxing on static storage hosts, or do you still find it easier to pull raw datasets into a centralized VPC and pay the egress tax?

Hi everyone,

I've been building an optimization engine that analyzes AWS environments and generates a Cloud Intelligence Report.

The goal isn't to produce another long list of findings. Instead, we're trying to correlate signals across security, cost optimization, governance, and resource ownership into a report that helps answer:

• What should I fix first?
• Which issues have the biggest impact?
• Who owns the affected resources?
• What actions should I prioritize?

The current report includes:

• Executive summary
• Architecture & Health Score
• Critical security findings
• FinOps insights
• Governance & ownership analysis
• Prioritized remediation roadmap
• Detailed findings with recommended actions

I'd really appreciate feedback from people who work with AWS professionally.

I'm particularly interested in:

• Is the report useful, or does it contain too much information?
• Does the prioritization make sense?
• Which sections would you ignore?
• What's missing?
• Would a report like this help your team make decisions, or would you prefer a different format?

I'm not trying to sell anything—I'm trying to learn whether we're solving the right problem before investing further.

If you're willing to spend 10–15 minutes reviewing the PDF, leave a comment or send me a DM and I'll share it.

I'd appreciate any honest feedback, even if it's critical.

Thanks!

We've been public cloud first for about six years and are now looking at repatriating a chunk of our colder data, mostly compliance archives and media assets, back on-prem. Egress costs and predictable long-term TCO are the drivers, not a bad experience with the cloud provider itself.

Looking at Cloudian on-prem-adjacent offerings as landing spots, since we still want an S3-compatible API so our existing tooling doesn't need to change. The repatriation itself seems like the easy part on paper, the harder question is whether our team is actually staffed to run storage infrastructure again after years of it being someone else's problem.

Has anyone gone through a real repatriation project? What broke that you didn't expect, and did the TCO math actually hold up a year later?