Building an AI Data Harness: Modernising AWS Infrastructure

An agent needs a reliable data source and an enforceable access boundary before it needs more tools.

If your team is planning AI agents for internal work, start with the systems those agents will reach. A convincing demonstration can hide unclear data ownership, stale records and credentials that allow more access than the task requires. This guide is for CTOs and platform leads in Singapore preparing an existing AWS estate for agent-assisted operations. It covers three connected decisions: whether to modernise a legacy database, where to run agent workloads, and how to enforce data permissions. You will leave with a practical assessment checklist and a way to scope a first workload without committing to a wholesale cloud migration.

Table of contents

• What is an AI data harness?
• What should you assess before changing the database?
• How can you migrate SQL Server to Aurora PostgreSQL safely?
• When does Aurora Serverless fit the workload?
• Which container platform should run your agents?
• What can Lake Formation actually protect?
• How should a gateway enforce the user's access?
• What does the assessment and implementation take?
• Which mistakes should you avoid?
• What belongs on the decision checklist?
• FAQ
• How can Zimozi help you scope the work?

What is an AI data harness?

An AI data harness is the surrounding system that gives an agent approved tools, data access, execution limits and an audit trail. The model is one component; the harness defines what it can do.

The term is used differently across teams. For this guide, it includes the runtime, tool gateway, identity handling and data controls that support a specific workflow. It should make failures visible and stop requests outside the approved scope.

Consider a fictional Singapore logistics company asking an agent to explain shipment delays. The agent needs current shipment events and documented status meanings. It does not need payroll records or the ability to change a customer's delivery address.

What should you assess before changing the database?

Map the required data and permissions first. A database migration is useful only if it solves an identified limitation.

Document who owns each source, how fresh it is, which fields contain sensitive information and how the application enforces access today. Include business rules hidden in stored procedures and reports. An unexplained status code remains unexplained after it moves to a new engine.

For the logistics example, define which event makes a shipment late, which time zone applies and how corrections are recorded. Decide whether the agent needs a read-only transactional query, a curated analytical table or both.

Write the access policy at this stage. Governance should influence the migration design, rather than arrive after agents have been connected to production data.

How can you migrate SQL Server to Aurora PostgreSQL safely?

Use an assessment, explicit conversion work and reconciliation before cutover. AWS Database Migration Service can support data movement, but it does not establish that the new application behaves correctly.

DMS Schema Conversion guidance for SQL Server and PostgreSQL describes conversion settings and differences between the engines. Review the assessment before estimating the work. Stored procedures, types, identity values, collation and date handling need particular attention.

A practical sequence is:

1. Inventory the application's database dependencies and establish a tested backup and recovery path.
2. Assess schema conversion and record objects that need manual changes.
3. Convert and test the schema, routines and application queries in an isolated environment.
4. Configure full load and change data capture for the supported source and target setup.
5. Reconcile data and business outcomes while monitoring replication latency.
6. Rehearse the cutover, rollback decision and agreed period for retaining the old system.

DMS SQL Server source documentation lists prerequisites and limitations, including those for secondary replicas. A secondary source does not imply zero impact on the primary; verify the supported configuration and measure the migration's effect.

Use DMS data validation where supported, alongside checks tailored to the business. Compare totals, representative records, null handling and key relationships. A matching row count does not prove that an invoice balance or shipment timestamp is correct.

Rename unclear fields through a planned application change, or expose documented views. Changing names during cutover without updating dependencies creates another failure path.

When does Aurora Serverless fit the workload?

Aurora Serverless v2 can suit variable database demand, but its capacity settings must reflect latency and connection requirements.

Aurora's auto-pause documentation explains the supported versions, minimum-capacity configuration and conditions that prevent pausing. Scaling to zero is not a universal property of every Serverless v2 deployment. Open connections and other features can affect whether an instance pauses, and resuming adds latency.

Test the first request after an idle period as well as sustained traffic. An internal overnight analysis may tolerate a resume delay; an interactive customer workflow may need available capacity throughout operating hours.

For retrieval workloads, evaluate embeddings alongside the operational model, but keep permission checks independent of similarity matching. A relevant search result is not automatically an authorised result.

Which container platform should run your agents?

Choose the simplest platform that meets the workload and isolation requirements. ECS and EKS can both be appropriate; an existing team's operating capability matters.

Fargate pricing varies with configuration and region. Compare the actual workload in the intended Singapore Region; do not apply a universal savings percentage. ARM support also differs by service and deployment mode.

Fargate Spot guidance describes interruption handling and capacity constraints. Use it for restartable work, with persisted progress and safe retries. Do not assume unavailable Spot capacity automatically becomes on-demand capacity.

Treat generated-code execution as untrusted. Use a dedicated task with a narrowly scoped role, controlled egress and an explicit lifetime. A container boundary needs configuration and monitoring; the prompt cannot enforce it.

What can Lake Formation actually protect?

Lake Formation provides permissions for supported data-lake resources and integrated query paths. It is not a general permission layer over every database connection.

Lake Formation data filters support row, column and cell restrictions for supported read operations. Verify the chosen engine, catalogue and grant type. A direct Aurora connection needs its own database and application access controls.

Use LF-Tags where they simplify classification and grants, then design fine-grained read permissions separately. Athena and Lake Formation guidance describes limitations, including interactions with tag-based access. Do not assume adding a region tag automatically creates a row filter.

Also review existing broad access. Hybrid access mode supports a deliberate migration between IAM and Lake Formation permissions. Revoke or retain legacy grants according to that design, rather than applying a blanket change that breaks existing consumers.

In the logistics example, test that a Singapore operations role can read its approved shipment rows and cannot retrieve another region's restricted records through a different query path.

How should a gateway enforce the user's access?

Authenticate the request, authorise the tool action and enforce the downstream data policy. These are separate checks.

Amazon Bedrock AgentCore Gateway can expose tools, while AgentCore Policy describes Cedar-based policy enforcement. Neither name establishes that an end user's identity is automatically carried into every Lake Formation query.

Design the adapter's identity mapping explicitly. Decide whether a tool assumes a scoped role or applies another validated authorisation mechanism. A shared task role identifies the workload, not every employee who asks it a question.

Keep tool parameters constrained. A shipment-status tool can accept an authorised shipment identifier instead of arbitrary SQL. The backend must still check access before querying or returning data.

Log the principal, tool, requested scope and outcome without recording secrets or unnecessary personal data. Test denied requests, expired credentials and attempts to call the backend outside the gateway. Where private connectivity is required, verify the actual supported network configuration rather than inferring it from a VPC diagram.

For related planning, read our Singapore AI agent guide and cloud migration cost guide.

What does the assessment and implementation take?

Start with one workload and estimate after inspecting its dependencies. Migration effort and operating cost depend on the estate, rather than the article's reference architecture.

Provide schema access, representative queries, the intended access policy, workload measurements and recovery requirements. Use approved credential stores and anonymised samples where appropriate.

The assessment should produce a conversion backlog, a permission model, reconciliation tests, a runtime decision and a monthly cost model in SGD. Include database capacity, storage, networking, logging, backups, query charges and operational ownership. Do not promise a fixed timeline before the conversion and integration gaps are understood.

For a Singapore business, document which Region and services hold each class of data, including logs and backups. A regional database does not by itself prove that the entire workflow meets your contractual or privacy requirements.

Which mistakes should you avoid?

• Connecting an agent before defining its required data and permitted actions.
• Treating a migrated schema as self-documenting.
• Assuming row counts establish business correctness.
• Expecting all Aurora Serverless deployments to pause to zero.
• Using Spot for work that cannot safely recover from interruption.
• Treating a shared runtime role as the requesting user's identity.
• Assuming a gateway or Lake Formation policy covers direct database access.
• Publishing savings or delivery dates before measuring the workload.

What belongs on the decision checklist?

• One initial workflow and its data owners are identified.
• Freshness, field meanings and source-of-truth rules are documented.
• Conversion gaps and business reconciliation tests are recorded.
• Cutover and recovery have clear decision points.
• Database idle and peak behaviour have been measured.
• Runtime architecture and interruption handling are verified.
• End-user identity mapping and downstream grants are explicit.
• Denied-access tests cover alternate query paths.
• Data location, logs, backups and ongoing ownership are documented.
• The cost model includes networking and operational work.

How can Zimozi help you scope the work?

Bring one agent workflow, its data sources and the access boundary you need. Book a scoped call with Zimozi to plan the assessment, migration decisions and verification needed before production.