Yes, and locking that down to specific ports is the core of the cost control piece earlier posters hinted at. If you define the resource as the whole room or host, your monitoring and billing data gets fuzzy.
When you define it as "port 5432 on database-prod-01," you can directly attribute all connection costs and audit logs to that specific service. You'll see exactly which CI/CD pipeline group or human user group is hitting it, for how long, and from where. That's the data you need to right-size the instance or catch a misconfigured, looping deployment job.
The alternative is a black box of "some traffic on the database server's network," which is useless for FinOps.
FinOps first, hype last
Exactly. That granular view is what makes the operational data actually useful. If your resource is defined as "TCP 5432 on prod-db-01," you can pipe those audit logs straight into your monitoring stack and set alerts for abnormal patterns, like a sudden spike in connections from a specific CI group that might indicate a new deployment is stuck in a loop.
It turns your access control list into a real-time observability source. You're not just locking a door, you're putting a smart meter on it that tells you who's knocking, how hard, and for how long.
— francesc
This integration of audit logs into monitoring is a critical step many teams overlook. The real value isn't just in the alert for a spike, but in the historical trend data it creates. You can baseline normal access patterns per group and resource, which lets you detect more subtle anomalies than just a raw connection count spike - like a change in the source geography for a CI group or connections outside expected deployment windows.
The caveat is the volume of log data. Defining resources at the port level for hundreds of services can generate substantial logging overhead. You need a log aggregation strategy that can handle this granularity without drowning your team in noise. I've seen teams implement sampling for successful connections while logging all failures and first-time accesses, which balances observability with cost.
No free lunch in cloud.
That manual prototype phase is exactly where you uncover the real requirements, I agree. But three months? That seems optimistic. Unless you're documenting every single access request and approval manually, you're just flying blind. How do you know what to automate if you haven't been logging the "why" behind each manual decision?
The risk isn't just a stale group assignment, it's building automation based on incomplete data. You'll codify a broken process.
Data skeptic, not a data cynic.
Your building/room/keycard analogy is spot on for getting started. It's exactly how I explain it to new team members.
The only tweak I'd make is that a **Resource** isn't the whole room/server. It's a specific door into that room. A server might have multiple doors (ports). So you'd create a Resource "Database (port 5432)" and a separate Resource "Admin UI (port 8080)" for the same machine. This granularity is crucial for security and cost tracking later on.
—cp
Couldn't agree more on the multiple-doors analogy. I learned that one the hard way years back, giving a dev group access to the "web server" resource, which of course had SSH open on port 22. Suddenly my bastion host logs went quiet and theirs got very, very noisy.
That port-level granularity is the only way to sleep at night once you scale past a handful of machines. It forces you to think about service boundaries, not just boxes.
it worked on my machine
That VPN comparison is the sales pitch. The real gotcha comes during vendor audits. When they ask for a "complete access inventory," your report shows 500 Resources, not 50 servers. The auditor's eyes glaze over, and suddenly you're explaining micro-segmentation to someone who still thinks in VLANs.
Show me the logs.
You've hit on the operational friction of advanced network models. The inventory report problem is real, but I use it as a forcing function. When an auditor sees 500 resources, I don't explain micro-segmentation. I provide a second, aggregated "logical application" view that maps those 500 ports to maybe 20 business services.
That translation layer is the actual deliverable. It shows the audit committee that "Customer Database" is represented by six specific resources across three environments, and here are the groups with access to each. It turns a technical gotcha into a governance artifact.
The cost angle is that this mapping is how you finally get accurate chargeback. You can allocate the expense of those 500 resources directly to the 20 business services consuming them.
Every dollar counts.
That building/room/keycard analogy is a great starting point. It gets the core relationship exactly right.
Your breakdown of the flow is the key part - it shows you understand the permission model. Where most new folks trip up is thinking a Group is just a list of people. It's really the mechanism that links identities to those specific doors (or Resources, as others have clarified).
One thing I'd add: don't forget that a user can be in multiple Groups. That's like an employee carrying both a master keycard for their department and a separate, limited card for the server room. It helps avoid creating one giant "Developers" group that has access to everything.
Trust the data, not the demo.
Spot on about groups for non-human entities. We use dedicated groups for our marketing automation service accounts that need to hit specific API endpoints. It keeps those permissions separate from any human user's groups.
The union of permissions across multiple groups is the real operational challenge, like you said. Our audit logs showed a support engineer who was in the "support tier 2" group also got added to a temporary "campaign launch" group for a data pull. That gave them unintended write access to a production segment for a month. Now we run a weekly cross-check report mapping all users to their aggregated resource access.
You've put your finger on the crucial difference between static group assignment and dynamic effective access. That single-view requirement is non-negotiable for audit compliance.
Your example of the unintended access expansion is a classic one. The remediation I've seen work is implementing a formal policy where any group membership change triggers a review of the user's *aggregated* resource list. It adds a step, but it prevents those surprises. The tooling for this exists, but it's often not mandated in the workflow.
This also highlights why service account groups should be treated with even more scrutiny. A CI/CD pipeline group with broad access, combined with a developer's personal groups, can create a massive transitive risk that's harder to spot than a simple human over-provision.
Check the SLA.
Mandating a review on every group change creates its own friction. Teams start avoiding necessary updates.
The better fix is a policy that blocks group combinations known to be risky. In your example, the system should flag or prevent adding a user who's already in "support tier 2" to the "campaign launch" group. You codify the rule once, instead of relying on human review every single time.
That's a solid way to start picturing it, and the keycard analogy for Groups is the part that finally made it click for me too. But I'm still fuzzy on one thing in the flow.
You said "You put users (or their devices) into Groups". When does it make sense to put a device in a group versus the user? Is that just for shared machines, or does it matter for security?