Customer Snapshot
| Attribute | Details |
|---|---|
| Industry | Workforce and services marketplace platform |
| Company Size | Roughly 300 employees |
| Cloud Environment | AWS, several independent accounts; production and non-production under management |
| Databases | Amazon Aurora MySQL on RDS, about ten instances in two accounts and two VPCs |
| Existing Setup | Database JIT running on a single central ECS service, with VPC peering to reach the databases |
| Identity | AWS IAM Identity Center for access, short-lived IAM tokens for database login |
| Tooling Philosophy | Build in-house, keep the vendor footprint small, justify spend by maturity |
| Focus Area | Adding data-tier controls without adding a new data path or vendor |
The Situation: A Team That Counts Every Third Party
This customer’s engineering philosophy is clear and consistent. Build rather than buy when it’s cheaper to maintain. Keep accounts isolated by design so that a failure in one stays in that one. Add a new tool or vendor only when the workflow it supports has matured enough to justify the cost and the extra access complexity. When asked why they build certain capabilities in-house instead of using third-party services, the answer was the same: third-party services cost more and bring access-management overhead.
That philosophy shapes what they will accept in security tooling. A product that sends production query traffic to someone else’s cloud, requires a new network path into the database tier, or asks for broad administrative rights across accounts would not clear the bar.
They adopted Cloudanix Database JIT on those terms. Rather than installing something that sits outside their network, they stood up a single ECS service in their own AWS account to act as the connection proxy. Because their Aurora MySQL databases span two accounts and two VPCs, they chose a centralized deployment that uses the VPC peering already in place, rather than installing a proxy per VPC. Database logins use short-lived IAM tokens, so there is no stored database password for the proxy or for engineers.
The question became what comes next. They had solved who can get in. They still wanted control over what happens once inside, and they wanted it without breaking the principle that made JIT acceptable in the first place.
The Core Tension
The data-tier controls most teams reach for are the ones this team is least willing to accept. Traditional database activity monitoring products capture and analyze query traffic on the vendor’s infrastructure. That gives them visibility, and it also means production data leaves the customer’s cloud. For a team whose entire approach is minimizing external parties and keeping access paths short, that is not a trade they will make.
The choice looks binary: comprehensive monitoring that ships sensitive data to a third party, or keep sovereignty and accept limited visibility. The better question is whether the control layer can run where the data already lives, using infrastructure already trusted and already reviewed.
Where the Gaps Were
A New Data Path Would Mean a New Review
Every new component that sees query traffic needs a security review, a network review, and an access review. A vendor-hosted monitor would trigger all three and likely fail the first one.
Per-VPC Deployments Multiply the Surface
With databases across two VPCs, installing a separate monitoring agent or proxy in each would double the footprint and double the places that need patching, permissions, and watching. The team had already decided a single central proxy over peered networks was the better design.
Native Controls Stop at the Connection
Aurora roles can limit who connects. They cannot mask a column, reject a dangerous statement, or attribute a statement to a person when a role-based identity sits between them.
Spend Has to Be Justified by Value
For a team that questions tooling cost, an expensive stand-alone data-security platform has to prove itself. An approach that builds on infrastructure they already pay for and already operate has a very different cost profile.
How Cloudanix Addresses This Situation
DAM Runs on the Same Proxy Architecture You Already Deployed
Cloudanix Database Activity Monitoring is a secure query proxy deployed on the customer’s own ECS. For a team already running the Database JIT proxy service in their own account, DAM extends that architecture rather than introducing a parallel one. The same centralized deployment, the same peered network path to the Aurora instances, and the same IAM-token login model carry over. There is no separate agent on each database and no extra network route to approve.
Where the Data Goes, and Where It Does Not
Consider the path of a single query:
- An engineer with an approved JIT session connects using their normal MySQL client.
- The connection reaches the proxy running in the customer’s ECS cluster.
- The proxy evaluates the statement against policy, forwards allowed statements to Aurora over the existing peered path, and applies masking to the results.
- The audit record is written to storage in the customer’s own AWS account.
At no point does query text, result data, or an audit record travel to Cloudanix. The control plane (console, policies, approvals) is separate from the data plane, which stays entirely in the customer’s account. This is the property that makes DAM acceptable to a team with a strict stance on third parties, and it can be demonstrated live: the proxy, the network path, and the log store are all in resources the customer owns and can inspect.
What the Proxy Adds Beyond Access Control
- Guardrails before execution: Block
DELETE,DROP, andTRUNCATEper policy, require aWHEREclause, restrict tables and columns, and cap row counts. Statements are also checked for tautologies and injection patterns. - Role-based masking: Mask sensitive columns by who is asking, using strategies such as show last four, mask email or phone, hash, redact, or tokenize.
- Query-level audit: Every statement stored with the person, tables, row count, and outcome.
- Anomaly detection: Unusual query patterns flagged for review.
Policies are set by an administrator in the Cloudanix console, so the security team keeps the decision-making.
Works With Current Engineering Workflows
Engineers keep their existing database clients. One practical detail from this customer’s setup: because login uses short-lived IAM tokens, the MySQL client needs the cleartext authentication plugin enabled. It is a single client setting, and it’s documented so the first engineer to connect doesn’t have to rediscover it.
Right-Sized Cost
DAM is an add-on to the Database JIT access product, metered by user, and it runs on infrastructure the customer already operates. There is no separate data-security platform to deploy, no replica of production data to host, and no agent fleet. The cost conversation becomes about the incremental value of adding data controls to something already in production.
See Cloudanix DAM in Action
In this 2-minute interactive walkthrough, see how Cloudanix DAM inspects, masks, and records queries, with your data never leaving your cloud.
What a Security Review Will Want to Verify
Teams like this one test claims instead of taking them on trust. These are the checks to run during a proof of concept.
| Question | How to verify it |
|---|---|
| Does query data leave our account? | Inspect the proxy task’s outbound traffic and the audit store location; both sit in your account |
| Is there a new network path? | Review the security groups and routes; the proxy reaches the databases over the existing peering |
| Are database passwords stored anywhere? | Logins use short-lived IAM tokens issued per session |
| Can the policy be tested safely? | Apply it to the non-production account first and review blocked-query logs |
| What permissions does the proxy hold? | Review the task role; it needs token-based database login and log write access, not broad admin rights |
| Do I control retention and access to logs? | The log store is yours, with your own lifecycle and access policies |
Rolling It Out in a Multi-Account Setup
- Start in non-production. Enable DAM on the non-production account’s databases and set strict guardrails to see what breaks.
- Tune with the blocked-query log. Real developer behavior shows which rules need adjusting.
- Extend to production. Promote the tuned policy to production databases, reusing the same central proxy.
- Review on a cadence. Pair policy review with the monthly check-in or access review you already run.
Independent accounts that are deliberately kept light on tooling, such as experimentation accounts, can stay out of scope. DAM applies only to the databases you put behind the proxy.
What to Know Before You Start
- The proxy needs to be able to reach each database. In a multi-VPC layout, confirm the peering and security group rules allow the proxy’s network range before enabling DAM. A migration of databases into a single VPC simplifies this later.
- DAM currently supports PostgreSQL, MySQL, and MSSQL. The Aurora MySQL estate in this scenario is covered. A hosted document store in the same environment is not, and continues to rely on JIT access control alone for now.
- DAM is added on top of Database JIT, not instead of it. JIT is the foundation that provides the identity and short-lived credentials DAM relies on.
Platform Impact
| Dimension | Before | After (DAM on the existing proxy) |
|---|---|---|
| Control over statements | None once connected | Guardrails and masking at the proxy |
| New network paths | N/A | None; reuses the existing peered path |
| Where query data and logs live | N/A | Entirely in your AWS account |
| Added vendors with access to data | N/A | None |
| Extra agents per VPC | N/A | None; one central proxy |
| Engineer workflow | MySQL client with IAM token | Unchanged |
Key Outcomes
- ✅ Sovereignty by Design: Query text, results, and audit records never leave your cloud.
- ✅ No New Data Path: DAM extends the proxy and network path you already reviewed.
- ✅ One Central Deployment: No per-VPC agents to patch and watch.
- ✅ Prevention Plus Evidence: Guardrails, masking, and a query-level trail.
- ✅ Verifiable: Every claim can be checked in resources you own.
- ✅ Cost in Proportion: An add-on to existing JIT, not a separate platform.
Want Data Controls Without Adding a Third Party to Your Data Path?
If your team avoids vendors that touch production data, Cloudanix DAM is built for you. The control layer runs inside your own cloud, on infrastructure you already operate, and every claim is something you can verify yourself.
Book a Free Assessment to review the architecture against your own VPC and account layout in under 30 minutes.
