AWS Cloud Engineering
Salesforce rarely lives alone. The integrations, data pipelines and residency APIs around it run on AWS, Data 360 reaches into it through Zero Copy, and all of it has a bill, a blast radius and a 3 a.m. failure mode. We run the AWS side as an engineering practice: reviews against every pillar of the Well-Architected Framework, cost work you can stop after any wave, and estates built so a small team can run them.
Where We Have Done It
-
Cost Optimisation for a B2B SaaS Data Platform
About 40% lower AWS spend across four optimisation waves, each with a performance guardrail agreed before changes were made, so savings never came at the cost of latency or reliability.
-
Well-Architected Reviews and Resilience Remediation
Reviews of a UK telecommunications provider's AWS estate against the Well-Architected Framework, with every finding turned into a remediation backlog that had owners and estimates, and the resilience work delivered against that backlog afterwards.
-
DevOps Toolchain on EKS for a 20,000-Person Engineering Organisation
Jira, Confluence, GitLab, Nexus and SonarQube consolidated as tenants on one highly available EKS platform with single sign-on; upgrades without maintenance weekends and a run cost roughly a third lower.
Developer platforms and Kubernetes, on EKS or on your own hardware, have their own page: Platform Engineering.
Six Pillars, One Practice
The Well-Architected Framework is the checklist AWS itself uses. We have worked every pillar of it, on estates we built and on estates we inherited. Cost is the one that gets us the first call. It is rarely the one that matters most.
Operational Excellence
Everything as infrastructure code, so an environment can be rebuilt from the repository. Changes go through pipelines, not consoles. Runbooks for the things that go wrong, post-incident reviews for the things that did, and alerts that a person can act on at 3 a.m.
Security
A multi-account structure with IAM Identity Center and least-privilege roles, private networking by default, KMS encryption at rest, secrets out of code, GuardDuty and Security Hub switched on and actually read. For regulated data, residency controls designed in, as we did for the in-country residency service behind a Salesforce programme.
Reliability
Recovery objectives agreed with the business before any architecture is drawn, then multi-AZ where it earns its keep, backups that are restored on a schedule to prove they work, and failure tests run on purpose. Resilience remediation is where most inherited estates need the most work.
Performance Efficiency
Right-sizing with evidence, Graviton where the workload allows, caching in front of what is expensive, the right storage and database tier for each access pattern, and load tests that give every change a before-and-after number.
Cost Optimisation
Start by showing where the money goes, with tagging and showback so each team sees its own bill. Then waves: right-size, tier storage, schedule non-production, and only then buy Savings Plans against a footprint that is no longer moving. Each wave has a performance guardrail agreed in advance and a stop point.
Sustainability
Mostly the same moves as cost, measured differently: fewer and fuller instances, non-production switched off outside hours, data kept at the tier its access pattern deserves, and regions chosen with the carbon footprint report in the conversation. The report goes in the quarterly review next to the bill.
Four Ways In, Depending on Where You Are
An estate nobody has reviewed, a bill that keeps growing, a new platform to stand up, or a running one that only one person understands.
Review
A Well-Architected review of your estate, on the AWS tool, against all six pillars. It ends with a list of fixes, each with an owner, an estimate and a reason. You can hand that list to any team, including your own, or we deliver it.
Optimise
Cost work in waves. Before each wave we agree the performance number that must not move; after it we measure both the saving and the guardrail. You can stop after any wave, so you are never committed beyond the saving you can already see.
Build
A landing zone for a new estate, or a new platform inside an existing one: account structure, identity, networking, pipelines, observability, GPU capacity for self-hosted models, and the services around your Salesforce org, all as code and documented as we go.
Run
The platform your integrations and data services sit on, kept patched, upgraded and observable, with runbooks and knowledge transfer so your own team can take it over whenever you decide to. Developer platforms and Kubernetes are covered on their own page.
Where It Meets Salesforce
Most of our AWS work is sold to the same clients as our Salesforce work, and that is not a coincidence. The integration layer between Salesforce and the rest of the business runs on AWS: event buses, Lambda functions and containers that keep ERP, billing and data warehouses in step with the org. Data 360 reaches into Redshift and S3 through Zero Copy, which only works well if the warehouse side is modelled and secured for it. Data residency programmes keep regulated fields in an in-country service that Salesforce calls at read time, and that service has to be as available as the org it serves.
One team owning both halves means the architecture gets designed once, the decisions log covers both, and nobody is explaining a Salesforce timeout to an AWS team that has never seen the org.
AWS Cloud Engineering: Questions We Are Asked
Do you only do AWS cost optimisation?
No. Cost is the pillar that gets us the first call, so it is the one the case study is about. The practice covers all six pillars of the Well-Architected Framework: operational excellence, security, reliability, performance efficiency, cost optimisation and sustainability. Reviews run against every pillar, and the fixes that come out of them are usually about reliability and security before they are about the bill.
What does a Well-Architected review produce?
A list of fixes, each with an owner, an estimate and a reason. Not a score to file away. The review runs on the AWS Well-Architected Tool against all six pillars, so the findings are in the format AWS and your account team already recognise. The team has run these reviews for a UK telecommunications provider and delivered the resilience remediation against that backlog afterwards.
Can you review an AWS estate you did not build?
Yes, and most of the ones we review are inherited. The first step is discovery with read-only access: account structure, identity, networking, what is running, what it costs and what has no owner. The review is written against what is actually there, with the fixes ordered by risk, so a team that has just taken the estate over knows what to do first.
How do you cut an AWS bill without slowing anything down?
In waves. Before each wave we agree the performance number that must not move, make the changes, then measure both the saving and the guardrail before the next wave starts. You can stop after any wave, so you are never committed beyond the saving you can already see.
How much can we expect to save on AWS?
It depends on the estate, so the first thing we do is show you where the money goes. On a US B2B SaaS data platform, spend fell by about 40% across four waves with every performance guardrail held. Commitments such as Savings Plans come last, once the footprint has stopped moving, so you never buy a discount on capacity you are about to remove.
Can you set up AWS from scratch for us?
Yes. A landing zone: a multi-account structure, IAM Identity Center for people and roles for workloads, private networking, logging and guardrails switched on from the first account, all defined as code so the next account looks like the last one. It is designed with the six pillars in mind from the start, which is cheaper than reviewing it into shape later.
Why would a Salesforce partner run AWS?
Salesforce rarely lives alone. The integrations, data pipelines and residency APIs around it run on AWS, Data 360 reaches into it through Zero Copy, and all of it has a bill. We run that side for the same clients, so one team owns both halves of the architecture.
Do you do Kubernetes and platform engineering?
Yes, and it has its own practice page. Self-service for developers, paved CI/CD/CT pipelines, delivery metrics and the Kubernetes platform underneath, on Amazon EKS or your own hardware. Our engineers have built this for a 20,000-person engineering community and run a 57-node on-premises cluster with automated, no-downtime upgrades.
Included in Every Engagement, at No Extra Cost
The things most firms charge for, or quietly leave out. You get them as standard, and your team keeps all of it.
A Named Architect for the Whole Engagement
The person who designs your solution stays on it to the end and joins every review. No hand-off to a rotating bench.
A Decisions Log and Architecture Diagrams
Every choice written down with the reason, so six months later nobody has to guess why the org looks the way it does.
Working Demos Every Week
You see running software each week and steer while it is cheap to change. No status decks.
Everything in Version Control
Metadata, pipelines, packaging and tests from the first sprint. Your org can be rebuilt, audited and handed to anyone.
Documentation, Runbooks and Knowledge Transfer
Your admins can explain the design, not just operate it. We are not building a dependency on us.
Thirty Days of Post-Go-Live Support
After go-live the team stays available for a month to fix, tune and answer questions, inside the original price.
Ready to Talk to an Architect?
A 30-minute call with the architect who would own your work. You leave with a written view of the next step and a rough sizing, whether or not you go ahead with us.
Book an Architecture Discovery Callor email contact@crystallotus.co