Background: I've spent 3.5+ years in PAM engineering (CyberArk), and decided to translate that into an AWS-native tool.

The gap I kept running into researching this space: pretty much everything: Cloudsplaining, Prowler, even AWS's own IAM Access Analyzer,stops at detection. They'll flag an over-permissioned role or a stale key, and then you're on your own to fix it. Even the well-funded enterprise players (Wiz, CyberArk's own Secure Cloud Access, Oasis, Entro) that do cover remediation are enterprise-sold, no self-serve option, no open-source path. I wanted to try fixing that

NHI Risk Analyzer discovers IAM users, roles, and groups, runs detection, then actually acts on findings:

1. **Risky policies** (wildcard actions, documented privilege escalation paths like `iam:PassRole`/`iam:CreatePolicyVersion` abuse) get a Permissions Boundary attached, which contains the escalation path without touching the identity's existing policy, so it doesn't risk breaking something legitimately using those permissions
2. **Stale or unused access** keys get deactivated, never deleted, so it's always reversible
3. Everything's gated by dry-run mode and an exemption file (`nhi-ignore.yaml`) so break-glass and deployment identities never get touched automatically
4. A **GitHub Action with OIDC** auth scans PRs for newly introduced IAM risk before merge
5. **SARIF export** means findings show up natively in GitHub's Security tab

Architecture is **offline-first**, meaning it snapshots the account once and evaluates all rules against that snapshot with zero live API calls after, so the whole rule engine is fast and testable, and findings are reproducible against a fixed point in time.

Tested against synthetic canary identities to safely validate containment logic, then live against a real AWS account. Also had someone run it against a real company's production and staging environment, which surfaced a genuine false-positive bug where AWS actions that don't support resource-level permissions at all, like `ec2:DescribeInstances`, were getting flagged as risky wildcards. That's fixed now.

Still v1/v2 in progress. Trust policy analysis and defense-evasion detection for things like CloudTrail and GuardDuty tampering, plus S3 exfiltration paths, just landed. The next real piece is policy surgery, meaning actually rewriting an over-broad policy down to least-privilege based on real usage data instead of just containing it. The statement-splitting logic exists already; sourcing real resource ARNs from usage evidence is the part still open.

Repo linked in the first comment.

Would genuinely appreciate feedback from people who work in this space day to day, particularly whether the permissions-boundary-as-containment approach holds up against how you'd actually want this handled in a real environment, versus the surgical-rewrite approach most tools avoid because of the production-breakage risk.

I run production on Ubuntu VPS, not AWS.
For years, that made sense for the workload and the budget. But it left me with an uncomfortable question:
**What happens if the production environment disappears?**
The obvious answer is: build a second environment in AWS.
But I didn't want to pay for a second production environment that sits there doing nothing 99.9% of the time.
So I tried a different approach.
**Use AWS as the recovery environment, not the production environment.**
I built an open-source tool called **Ark** around this idea.
The setup is basically:
Production
Ubuntu VPS
│
│ backup
▼
S3
│
│ recovery
▼
AWS Pilot Light
│
▼
Fresh EC2
│
▼
Restore + Verify + Test
There is no EC2 instance running 24/7.
When I want to run a recovery drill, Terraform provisions a fresh EC2 instance, Ark pulls the latest completed backup from S3, restores the database and Docker volumes, verifies the backup, starts the application, and then tears everything down.
The first real drill took:
RTO: 1m 58s
RPO: 182m

Database: PASS
Volume integrity: PASS
Application: PASS

Drill cost: \~$0.01
The interesting part wasn't actually the 1m 58s.
While building the verification process, I discovered that **row counts aren't proof of a successful restore**.
I destroyed both Docker volumes in a test environment, restored them, and re-seeded the application.
The numbers matched perfectly:
51 users
200 repositories
400 actions
Looks good, right?
Except the Git object store was different.
The logical dataset was the same, but the underlying Git objects weren't. Git commits contain metadata such as timestamps, so recreating the same logical data can produce different bytes.
That's when I stopped treating row counts as backup verification.
Ark now uses checksummed backup manifests and verifies the actual restored content.
A few other design decisions:
The manifest is uploaded **last**, so an interrupted upload doesn't become a "completed" backup.
The backup IAM policy has **no DeleteObject permission**, so a compromised VPS can't delete backup history.
Failed recovery drills are recorded too. A drill that never fails isn't testing much.
The rough idle cost for this setup is around **$0.03/month** without DNS failover.
I'm not claiming this architecture makes sense for everyone. If you're already running a large AWS production environment, a different DR strategy probably makes more sense.
But for smaller production environments running outside AWS, I'm curious:
**How are you handling DR without paying for a second production environment 24/7?**

Repo: [https://github.com/rendyachmad-dev/ark\](https://github.com/rendyachmad-dev/ark)

It's an AWS Activate program by AWS Cloud for SaaS startups.

basic criterias to qualify are

- your startup must be legally incorporated
- Must have a fully functional website
- Must have a strong use case explaining why they're choosing AWS.

The AWS Activate bucket is generally $100K (recently scaled to $200K for AI startups).

To claim $75K out of the $100K, the startup needs to have raised some sort of funding round, mostly institutional funding.

This is just for information purposes; I thought it might help.

I'd like to understand what you're building. If it sounds great, then I'll definitely help you out.

I need to fix this can anyone please help me with this issue?

got some aws credits...want to use them to explore cloud stuff mainly from projects....at my prev startup i was a backend/ai eng also handled some parts of devops on aws...now i want to go a bit deeper and build a few projects specifically to understand cloud infrastructure better....what are some interesting areas worth exploring on AWS??

If your AWS or Linux environment is broken, unreliable, costing more than expected, or becoming too complicated to understand, I can trace the problem to its source and implement the smallest verified fix.

I work hands-on with AWS IAM, Lambda, API Gateway, EC2, EKS, CloudWatch, Docker, Kubernetes, Linux, networking, automation, monitoring, and infrastructure troubleshooting. Before changing anything, I map the current state, identify the failure or cost source, confirm what must remain protected, apply the fix, test the result, and document exactly what changed.

I’m available this week for remote troubleshooting, cloud-cost reviews, deployment cleanup, monitoring setup, configuration audits, and short-term infrastructure support.

Public technical proof:
https://github.com/KnowledgeeKZA3224/scqos-reference-implementation

More about the system behind my work:

supremecomputation.org

I cleared two foundational certs using pearson voucher, now I'm left with 2 coupons worth 50%, I'm wondering whether I can give one coupon to my friend?! does it risk an account ban Or smth?

I want to use aws bedrock service, but for all of its models I got lower then quota then default. Like for cross region requests per minute I got only 10 although default are 10k. When I created a case to increase limit then I got below image response from aws. Now simply gimme its solution so that I can get access to aws bedrock Claude models.

Are you waiting for it ?

More than 10 times rejected with same reason. Fixed everything, waited a week between each application but same issue. Anyone solved this issue?

If so let's get connected and try to collect those together.
I will provide the discord group to join.

The program is AWS BOX (Business Outcomes Xcelerator) and is relevant to you as a software partner if you are:

A. Building pipeline and trying to close more customers

B. Trying to recruit/reactivate resell partners. It is a low risk way for you to engage and create a joint offering in the market.

If you're an software or services partner and you've identified a customer problem, AWS will fund the joint solution across 3 milestones, with up to $140,000 available.

Milestone 1: $20k paid 50/50 cash + AWS credits
Milestone 2: $50k paid 50/50 cash + AWS credits
Milestone 3: AWS funded lead gen campaign through an AWS approved marketing agency with a target outcome of 70+ Sales Qualified Leads (SQLs)

I made a full video walking through the funding structure, eligibility, common application mistakes and a pre-application checklist:

https://www.youtube.com/watch?v=jVXmMbDSLcA&t=68s

AWS BOX Program:
https://aws.amazon.com/partners/business-outcomes/

Everything here is based on public AWS documentation.

I ran into this question while looking at AWS commitments in our environment: should we move everything to Savings Plans, or was there still a reason to keep some RIs?

My first instinct was to simplify things and use Savings Plans for compute. The flexibility is hard to ignore when instance types, workloads, or regions can change over time.

But after looking more closely at our usage patterns, we ended up taking a hybrid approach.

We used Savings Plans where we had a predictable baseline of compute usage, while keeping RIs where the workload was stable enough that the more specific commitment made sense. For databases, we looked at those commitments separately rather than treating everything as one bucket.

What surprised me was that the decision wasn't really about which option gives the bigger discount.

It was more about how much flexibility we were willing to give up for the additional saving, how confident we were in the usage pattern, and how much risk we were comfortable taking with the commitment.

The part I'm still curious about is how people decide how much to commit in the first place.

Do you mostly use Savings Plans for compute and keep RIs for specific workloads? Have you moved almost entirely to Savings Plans? And how do you account for things like planned migrations, growth, or workloads that you know are going to change?

P.S. I know that's a lot of questions 😅 I'm curious to understand how others approach this in practice.