Built for the Load
You Actually Have.
Cloud infrastructure fails in two directions. Provision too much and you pay every month for capacity nobody uses. Provision too little and it falls over on your busiest day. Both are architecture decisions, and both show up on the bill or in the outage report. We design for the load you actually have, show you the tradeoff in plain terms, and leave you with something your own team can operate.
You Pay for What You Reserve
The most common finding on an existing AWS account is not a broken architecture. It is capacity sized for a peak that happens rarely, running at full price the rest of the time.
The gap is billed every hour
Capacity is set for the busiest moment and stays there. The shaded distance between what is provisioned and what is used is real money, charged continuously whether or not anything is happening.
You pay near what you use
The same workload, sized to follow it. Headroom stays deliberate rather than permanent, which is where the saving comes from without giving up the ability to absorb a spike.
- Provisioned and billed but not used
- Capacity following actual demand
Cheaper is not automatically better
Under-provisioning is a failure too, and an outage during your busiest hour costs more than the capacity would have. Some workloads genuinely need reserved capacity, and committing to it is often the cheaper answer. We will show you both numbers and the risk attached to each rather than optimising for a smaller bill on its own.
The Parts of an AWS Estate
Whether you are arriving on AWS or already running there, the work covers the same set of concerns.
Compute and serverless
Lambda, containers, and instances, sized and structured so the shape of the workload matches the shape of the bill.
Storage
S3 and block storage with lifecycle rules and appropriate tiers, so data that is never read stops being charged as if it were.
Networking and access
VPCs, routing, certificates, and the identity and permission boundaries that decide what can reach what.
Databases
Managed database services chosen for the access pattern you actually have, with backups and restores that have been tested.
Deployment pipelines
Repeatable deployments with a way back, so releasing is routine rather than an event that needs a calendar invite.
Monitoring and alerts
Knowing something broke before a customer tells you, and having enough signal to find out why.
Where the Bill Actually Comes From
Cloud spend is rarely one big line. It is a handful of ordinary decisions that each looked reasonable in isolation and compound month after month.
Sizing
Capacity chosen for a peak that happens twice a year, paid for continuously the rest of the time.
What stays on
Environments left running outside working hours, and test resources nobody remembered to remove.
Storage tiers
Data kept at instant-access pricing years after anyone last read it, with no lifecycle rule to move it down.
Traffic and egress
Data moving between regions, zones, or out to the internet, which is easy to architect into a design without noticing.
Your AWS account is billed to you directly by AWS. We do not resell it, we do not mark it up, and we do not control what AWS charges. What we can do is make the architecture that drives those charges a deliberate decision rather than an accident, and show you what each choice costs before it is built.
Yours, Not Ours
Cloud work should never leave you dependent on the people who built it. Everything is set up so you stay in control and could hand the estate to someone else tomorrow.
Your account
The infrastructure runs in an AWS account you own, with the root credentials and multi-factor authentication in your hands.
No lock-in
Built with standard AWS services in your own account, not on a private platform of ours, so any capable team can run it.
Written down
What was built, why, and how to run it is documented, so another engineer can pick it up without us.
Access handed back
At handoff our access is returned or removed as agreed, and nothing stays in place that only we understand.
From Estate to Handover
Review what exists
For an existing account: what is running, what it costs, and what is actually load-bearing. For a new build: the workload, the traffic pattern, and the constraints.
Design and price it
An architecture with the tradeoffs stated, including the expected running cost of each option, agreed in writing before anything is provisioned.
Build it repeatably
Infrastructure defined as code where practical, so the environment can be rebuilt rather than remembered, plus deployment and rollback paths.
Hand over the keys
Account access stays yours throughout. You get documentation, runbooks, and the ability to operate it without us.
What Is and Is Not Included
A cloud engagement covers the design and build we agreed on. These boundaries come from our Terms of Service and apply to every technology engagement.
Included in a scoped engagement
- Review of the existing estate or the proposed workload
- Architecture design with stated tradeoffs and expected running cost
- Building and configuring the agreed infrastructure
- Deployment pipelines with a documented rollback path
- Monitoring and alerting on the agreed signals
- Documentation, runbooks, and credential turnover
Not assumed unless agreed in writing
- Migrating existing data or workloads unless separately scoped
- Ongoing operations, on-call, or incident response after handoff
- Managed IT, cybersecurity monitoring, or formal security audits
- Any guaranteed uptime, cost reduction, or performance figure
- AWS charges themselves, which AWS bills to you directly
- Legal, tax, accounting, privacy-law, or regulatory advice
You own the AWS account and the commercial relationship with AWS throughout, and you keep it after we finish. We work inside the access you grant and expect you to revoke anything we no longer need at the end of the engagement.
How Cloud Work Is Priced
Work is priced by scope, not by the hour. You get a written scope with a fixed price before anything starts, and larger builds are split into milestones. The ranges below show where engagements typically start. The important distinction on this service: our fee and your AWS bill are two separate things.
See Starting Prices
| Engagement | When it fits | Investment |
|---|---|---|
| Fit Check | You know the work hurts, but not yet what to build, or whether to build anything: 30 minutes to find out. | Free |
| Quick Win Automation | One tightly bounded problem with a clear finish line. | From $1,500 |
| Core Automation or Integration Build | Workflows and system connections the business runs on, priced in a written scope. | From $5,000 |
| Operations Automation Partnership | After a build: monitoring, maintenance, vendor and API changes, and small improvements. | From $750 / month |
| AWS charges | All infrastructure usage, billed by AWS directly to your own account. | Paid by you to AWS |
We do not resell AWS capacity or take a margin on your infrastructure spend, which means we have no incentive to leave anything oversized. Any estimate of running cost we give is an estimate based on the expected workload, not a quote or a cap: actual charges depend on your real usage and on AWS pricing, both of which are outside our control.
Hosting, domains, licenses, subscriptions, and processing fees stay in accounts you own and are billed to you directly by each vendor whenever practical. Where we must place an approved charge on your behalf, that amount is collected before we incur it.
After the Build
Every build ends with documentation and a handoff, so your team can run it. If you would rather not, a monthly partnership covers monitoring, vendor and API changes, and small improvements under its own written agreement.
See Partnership LevelsYou own and remain responsible for your AWS account, its billing relationship, its payment method, and its account-level security, including root credentials and multi-factor authentication. AWS charges are incurred by you directly and are not part of our fees. Any cost estimate we provide is an informed estimate for planning, not a quote, a guarantee, or a cap. Cloud platform pricing, service availability, regional behaviour, and quotas are set by AWS and may change without notice, and outages or policy changes on their side are outside our control.
You agree to review deliverables promptly. Unless we agree to a different acceptance method in writing, work is deemed accepted on the earliest of: your written approval; your use of the delivered work in production or public release; or five (5) business days after delivery without a written, reasonably specific objection tied to the agreed scope.
T&C Group Holdings, LLC is not a law firm and does not provide legal advice. Technology services are provided for implementation, support, troubleshooting, and general business-use guidance only. We are an independent provider and are not affiliated with, endorsed by, or certified by Amazon Web Services; AWS and related marks are the trademarks of their respective owners and are used here only to describe the platform we work with. We do not guarantee uptime, cost reduction, performance, security outcomes, compatibility with every third-party service, or any particular business or technical result. Ongoing operations, monitoring, and incident response are outside a standard engagement unless separately accepted in writing. This page is a summary for convenience; our Terms of Service govern.
Full terms: Terms of Service
Moving to AWS, or Paying Too Much on It?
Tell us what you are running, or what you are planning to run. We will review it, show you what the architecture is costing and why, and come back with a scope and a number.