Partner

AWS Partner

Shakewell is an Amazon Web Services partner. We design, build, and operate production workloads on AWS for clients across Australia, the same platforms our own products run on.

Platform architecture

Green-field builds and re-platforms on AWS: load-balanced EC2, serverless (Lambda + API Gateway), containerised workloads, and static-plus-functions architectures picked to fit the workload, not the fashion.

Web application hosting

Production Laravel, WordPress, and Next.js platforms with zero-downtime deploys, environment parity from dev to prod, and monitoring that catches problems before your users do.

Email & messaging at scale

Transactional email through Amazon SES with proper domain authentication (SPF, DKIM, DMARC), plus queues and scheduled jobs on SQS and EventBridge.

Cost & reliability engineering

Right-sizing instances, swap and memory tuning, backup and disaster-recovery runbooks, and infrastructure documented so your team is never hostage to ours.

Migration to AWS

Moves from private cloud or on-premises hosting onto EC2 or ECS, RDS, S3 and load balancers. We plan the cutover, load test the new environment and validate the data before traffic moves, and we have run this for a member-owned organisations.

Client-owned accounts

Where you want it, the AWS account is yours, not ours. We build inside your account, hand over the infrastructure as Terraform code with documentation, and your team keeps the keys. If you later move on, nothing has to be rebuilt.

Serverless Laravel

Laravel on Vapor, which runs on Lambda, with CloudFront in front and no servers to manage, though runtimes and dependencies still need upgrades. It suits sites with spiky traffic, such as venues and events, and APIs behind a Next.js front end. We also handle the framework upgrades that keep these stacks supported.

Managed AWS

Ongoing operation for platforms that cannot afford drift: monitoring, patching, cost reviews, disaster-recovery tests, and a security baseline built on IAM, GuardDuty, WAF and KMS. Reviews of cost and risk are built into the arrangement so neither creeps up unnoticed.

In-region data and AI

Hosting in the Sydney region (ap-southeast-2) keeps stored data in Australia, which regulated and public-sector clients often need. AWS also runs a Melbourne region (ap-southeast-4), which an account has to opt in to. For AI features we use Amazon Bedrock, with Sydney as the home region and the inference routing confirmed against each client's data requirements.

Proof, not promises

Platforms we've shipped on AWS include streaming and e-commerce products, university-scale web applications, and enterprise content systems. See the case studies.

Much of our AWS work sits behind technical publications platforms. For an aviation technical-publications client we replaced a legacy Access database with a Laravel API and web app, and supplied Terraform so the client can deploy into its own AWS environments (the case study covers the Access migration and web app). The same client's content portals are covered by a managed AWS arrangement that includes monitoring, cost optimisation, disaster-recovery testing and periodic reviews. We have also scoped a migration of a Windchill-based publishing platform onto AWS with validated recovery and identical output as the acceptance tests.

For a member-owned banking association we moved a private-cloud environment to AWS, with load testing and data validation before cutover. Separate work covers replatforming its public site and upgrading its member portal (case study). On the Laravel side, a headless hospitality site has its Laravel API on Vapor, and we have proposed a Laravel 11 to 12 upgrade for a public-sector platform that already runs serverless, with performance to be measured against the current baseline.

AI work follows the same rule. For a hospitality group we are building search that understands plain-English queries, calling Claude on Amazon Bedrock from the Sydney region with a fallback to standard search if the AI layer is switched off. It is in build for early 2027, so we make no claims about results yet.

How an AWS engagement runs

Review what you run today: workloads, data, traffic shape, what keeps breaking, what it costs to keep up.
Propose an architecture sized to the workload, with the account model (yours or ours) agreed up front.
Build or migrate in stages, with infrastructure as code, load tests and a rollback plan for each cutover.
Hand over Terraform and runbooks, or keep operating the environment under a support arrangement. Either is fine.

Every environment is documented for the people who inherit it. Disaster-recovery steps are written down and tested, and cost reviews look at actual usage, not the original sizing.

Why we favour client-owned accounts

An agency-owned AWS account is convenient for the agency and awkward for you. Billing, access and data sit with a third party, and leaving means a migration before you can even start. Building in your account keeps billing visible, lets your security team apply its own policies, and means the Terraform we write is the same code your next engineer will read. Some clients prefer that we hold the account while we operate it. We set that up too, and document how to transfer it later.

Choosing between EC2, containers and serverless

Long-running publishing systems with licensed software usually belong on EC2 and RDS. Content-heavy marketing sites and APIs with uneven traffic often fit Lambda through Vapor, where capacity follows demand. Containers on ECS sit between the two. We pick per workload, and say so plainly when the cheaper option is the boring one.

Region details checked against the AWS Regions documentation and Amazon Bedrock endpoints, November 2026.