AWS Consulting Australia | Cloud Architecture for AI | ComplxAI
AWS consulting

AWS consulting for AI systems and software

ComplxAI provides AWS consulting in Australia for organisations that need a cloud platform they can run a business on. We design the account structure, the serverless or container architecture, the data layer and the security model, then build it in your own AWS account as infrastructure as code, with Bedrock and pgvector part of the same design.

  • Documentation and handover included
  • Senior engineers design and build the platform
  • Scope and price agreed in writing per stage
Who this is for

When the AWS account has outgrown the way it was set up

Few AWS accounts were designed. Each release added what it needed, and now the console holds resources nobody can name and an invoice nobody can explain. That is where a deliberate platform design pays for itself.

We work with founders, CTOs and engineering leads who want a deliberate platform under their product. For questions wider than one provider, see cloud engineering; for the model layer on top, production AI engineering.

A good fit if…

  • Your product runs on AWS and the person who set it up has left
  • An AI workload is heading to production and the platform needs to be right first
  • The AWS bill is a line item nobody owns
  • Australian data residency is written into your contracts
Problems we solve

Three ways an AWS platform asks for help

They surface as an outage, a stalled launch or a blocked deal. Underneath each is a decision that was never made.

An account built by hand

Resources created in the console, security groups widened until something worked, no record of why anything exists. We inventory it, describe the target state in code and migrate in steps.

An AI prototype with nowhere to run

The demo calls a model from a laptop. Production needs queues, retries, a vector store, encryption and a straight answer on data residency. We build what the prototype is missing.

Security findings blocking a deal

A questionnaire asks about encryption, access control and audit logging, and nobody is sure of the answer. We rebuild the boundaries: least-privilege IAM, encryption at rest with keys you control, private subnets and an audit trail you can show.

Capabilities

What our AWS consultants design and build

The AWS Well-Architected Framework is the lens for every review and design, applied to your workload rather than recited.

Architecture and review

A Well-Architected review of an existing workload, or a target architecture for a new one. Each decision is recorded with the option rejected and why, so the next engineer inherits judgement rather than mystery.

Serverless development

Lambda behind API Gateway, Step Functions for multi-step work, EventBridge and SQS to decouple producers from consumers, DynamoDB for known access patterns. Idempotent handlers and dead-letter queues from the first commit.

Containers on ECS and Fargate

For long-lived processes, custom runtimes or steady throughput: task definitions, service auto-scaling, load balancing, blue/green deploys and images scanned in the pipeline.

Data layer

S3, RDS Postgres with pgvector so relational and vector data share one engine, a managed vector database where retrieval outgrows Postgres. Multi-AZ, point-in-time recovery and a rehearsed restore, not assumed.

AWS for AI workloads

Bedrock for managed model access served from the region you choose, a containerised endpoint on ECS or Fargate where a custom model from our machine learning consulting needs hosting, plus prompt versioning, response caching, token telemetry and a person in the loop before any action with consequences.

Identity, network and security

IAM roles scoped to what each service needs, Cognito for user and machine identity, rotated encryption keys, private subnets and VPC endpoints that keep traffic off the public internet, secrets in a manager rather than a file.

Infrastructure as code and CI/CD

Every resource described in CDK or Terraform and reviewed as a pull request. Pipelines build, test, scan and promote changes through development, staging and production accounts under one organisation, with rollback as a normal operation.

Observability

Structured JSON logs with request identifiers, CloudWatch alarms tied to what users feel, distributed traces across Lambda, queues and databases, dashboards an on-call engineer can read at 2am.

Cost optimisation

Right-sizing compute and databases, on-demand or provisioned capacity per workload, caching at CloudFront and API Gateway, log retention, and budget alerts that reach a person before the invoice does.

Reference architecture

A serverless AI platform on AWS, layer by layer

The shape we start from for an AI-enabled product. Boxes change with the workload; the layers do not.

  • Edge and identityentry points
    CloudFrontAPI GatewayRequest validationCognito user poolsMachine-to-machine tokensRate limits
  • Computerequest handling and workflows
    LambdaStep FunctionsECS/Fargate servicesEventBridge rulesSQS with dead-letter queuesScheduled jobsIdempotency store
  • AI servicesinference in region
    Bedrock in the region you needCustom model endpoints on FargateModel routerPrompt registryResponse cacheToken and cost telemetryApproval steps
  • Datastorage and retrieval
    S3 with lifecycle rulesRDS Postgres + pgvectorDynamoDBManaged vector databaseEncryption at restPoint-in-time recovery
  • Operationsseeing what is happening
    CloudWatch metrics and alarmsDistributed tracingStructured logsBudgets and cost alertsRunbooks
  • Foundationsaccounts, access, delivery
    Multi-account structureDev, staging and prod accountsLeast-privilege IAMVPC and private endpointsSecrets ManagerCDK or TerraformCI/CD pipelines

The layers above the data tier are where AI engineering happens: retrieval, routing, evaluation and tracing of model calls. The application around the model is custom AI development. This page is the platform underneath: built once, in code, understood by your team.

Delivery

How an AWS consulting engagement runs

The commercial frame is the five-stage model described in how we work; within one Implementation block, platform work runs in this order.

  1. ReviewRead-only access to the account, the code and the bill. Findings written up against the Well-Architected pillars.
  2. Target designAccount structure, compute model, data layer, security boundaries and migration path, with reasons recorded.
  3. FoundationsOrganisation, environments, IAM, networking, secrets and the pipeline, all in CDK or Terraform.
  4. Build or migrateServices, data stores and integrations land in vertical slices, each one deployable and observable.
  5. Harden and tuneLoad and failure testing, security review, alarms and budgets wired to people, cost right-sized on real traffic.
  6. Hand overDocumentation, runbooks and a walkthrough for your team. Ongoing support if you want it, independence if you do not.
Example engagements

What the work looks like in practice

01

Greenfield AI platform

A new product with a model at its core. We stand up the accounts, the serverless request path, Bedrock in the region you need, RDS Postgres with pgvector and the pipeline, so your team starts on a platform, not a blank account.

02

Productionise a proof of concept

A prototype now carries an uptime expectation. We move it onto queues and Step Functions, add identity, encryption and an audit log, alarm the calls that matter and make it reproducible from code.

03

Cost review of an existing account

A pass over compute, storage, data transfer, logging and provisioned capacity, scoped and priced before it starts. You get a ranked list of changes with the expected effect of each, and we implement the ones you approve.

04

Migrate a monolith to containers or serverless

The application keeps serving customers while we separate it: background jobs first, then bounded services onto Fargate or Lambda, then the database, behind a routing layer we can reverse.

05

Secure multi-tenant SaaS foundation

Tenant isolation in the data layer, per-tenant keys where contracts demand them, Cognito with organisation-aware roles and usage metering built in. The base our custom SaaS platforms sit on.

Choosing compute

Lambda, Fargate or instances: how we decide

Each option is right for something; the mistake is choosing one for the whole platform.

ConsiderationLambda and Step FunctionsECS on FargateEC2 instances
Best suited toSpiky or event-driven work, APIs, workflows with waits and approvalsLong-lived services, steady throughput, custom runtimes, websocketsSoftware tied to a specific host or licence; GPU work
ScalingPer invocation, with deliberate concurrency limitsService auto-scaling on CPU, memory or queue depthAuto Scaling groups; capacity planned ahead
Cost modelPer request and duration; near zero when idlePer running task; predictable for steady loadPer instance, busy or not; reservations lower the rate
Operational loadNo servers, no patching, no capacity to manageImages to maintain, no hosts to patchOperating system, patching and capacity are yours
Where we use itDefault for new work and AI orchestrationServices that outgrow Lambda limits or need persistent connectionsRarely, and only with a written reason in the design
Why ComplxAI

AWS consultants who also write the software on top

Platform and product, one team

The person responsible for engineering, infrastructure and security designs the AWS platform, and the same team ships the custom software on it, so queues, databases and keys are chosen with the product in view.

Independent advice

We carry no vendor quota. When a managed service is wrong for the job, or a workload belongs on another cloud, we say so.

Yours from the first paid stage

Infrastructure code, pipelines and documentation live in your repositories and your account. No mandatory retainers; take it in-house whenever you choose.

Systems we have shipped

The same team shipped DisabilityAssessments' secure patient-data storage and invoice processing, Modedu's custom SaaS platform and Luxpip's web, mobile and B2B API. See the case studies.

Questions

Questions we get about AWS work

Anything not covered here can be raised on the intro call, at no charge.

Book a free intro call
Do we have to use AWS?

No. AWS is the platform this page covers and the one our reference designs assume, but the recommendation follows the workload. If you are committed to another cloud, or part of the system is better served elsewhere, we say so.

Can our data stay in Australia?

Yes. The platform is deployed in the region you need; for Australian data residency that is the AWS Sydney region, where storage, databases, queues, compute and vector search all run. Bedrock serves only some of its models from Sydney, so the design names the model behind each feature and where it runs; where residency rules a model out, we agree an alternative before build.

How do you control AWS cost?

Visibility first: tagging, cost allocation per environment and feature, and budgets that alert a person. Then design: serverless for spiky load, provisioned capacity only where steady traffic justifies it, caching, and retention policies on logs and objects.

Do you hand over the infrastructure?

There is little to hand over because it was never ours: from the first paid stage everything is built under your organisation, in repositories you control. You finish with documentation, runbooks and a walkthrough, then keep us on or run it in-house. No mandatory retainers either way.

What does an engagement look like?

The five stages apply: the intro call and pre-discovery are free, then Discovery, Strategy and 12-week Implementation blocks. A review is the opening step of a block; a migration or greenfield platform runs across one or more of them. Pricing for each stage is put in writing before it starts, and you can leave at any boundary.

Start with a conversation

Bring the account, the bill or the diagram

Thirty minutes with an engineer who will read your architecture rather than pitch one. Nothing is charged until a stage is scoped and quoted.