Systems that grow,
and stay in hand
We design and build software on AWS, with accounts set up from the start, access kept to what each needs and everything defined in code, so you can see what runs, who changed it and what it costs.
Thanks, we’ll be in touch soon.
{{ heroStatus }}
You’re in good company
A few of the companies we’ve worked with.
When the account grows by hand
On AWS, everything runs inside an account, a space of its own for resources and the access to them. A resource, any single thing you run there, such as a server or a database, can be made from the console in minutes. That’s much of what makes it quick to start on.
Over time, resources made by hand, access granted widely to get something working and versions nearing the end of standard support add up. Each version, the release of a language, a cluster or a database engine that a system runs on, has its own dates, and some carry charges past them: a database or a cluster kept on an older version can move into extended support, which is charged.
How much of the work is yours depends on the AWS services you choose, as the shared responsibility model AWS publishes sets out.
So the real work sits around the code: the accounts, who can reach what, the code that defines every resource, and keeping each version in support. Where to begin depends on how the system grew.
What we build
Every change to what runs is made in code, reviewed by a person and deployed from CI, the same way each time.
New services
Services, the programs behind your product, along with functions, small pieces of code that run when they’re called, and background jobs, built on AWS with tests from the first commit.
Accounts, set up from the start
Accounts set up by environment and team, with guardrails set in one place through AWS Organizations and AWS Control Tower, and sign-in managed in one place too.
Access kept to what’s needed
Each person signing in as themselves, each service holding only the permissions, the actions it’s allowed, that it uses, and access nobody uses removed, as the security best practices for AWS Identity and Access Management advise.
Everything in code
What runs, defined in AWS CloudFormation or the AWS Cloud Development Kit, reviewed and deployed from CI, so the test and live accounts match.
Costs with an owner
Every resource tagged by team and product, the tags activated for cost allocation, budgets and alerts set, and the bill read with you.
Built to keep running
Systems that need it spread across Availability Zones, isolated locations within an AWS Region, with copies of their data restored in tests and alarms in Amazon CloudWatch where they help.
Within support
Versions kept within standard support, each moved forward on a branch and tested before its date.
Moves, in planned stages
Systems moved onto AWS a stage at a time, each step tested, with a way back.
AI where it helps
AI features built with Amazon Bedrock, which AWS describes as a platform for building generative AI applications and agents, and code drafted by AI assistants tested and reviewed like any other change.
- The same work, on any platform:Cloud, DevOps & Security
- The internal platforms your teams build on:Platform Engineering
- Data and machine learning:Data EngineeringData Platforms & MLOps
- A review of your security:Application Security
- AI features for your product:AI Services
- The clusters themselves, on Amazon EKS or your own machines:Engineering
- The code that sets it all up, planned before it runs:Infrastructure as code
- Developers in your own team:Developers for your team
Where their part ends and yours begins
AWS looks after the cloud itself: the buildings, the hardware and the network, and the software that runs its services. What you put in it, and how it’s set up, is yours. That’s the split AWS sets out in its shared responsibility model, in plain words.
How much is yours depends on how a system runs. On servers you run with Amazon EC2, the operating system and its patches are yours. In containers on AWS Fargate, AWS looks after the servers beneath them, and the image each container is built from stays yours.
As functions on AWS Lambda, AWS also keeps the language your code runs in patched, on its managed runtimes, until a runtime is deprecated. A function packaged as a container image keeps that part yours.
Whichever you choose, your code, your data, your settings and who can reach them stay yours. So we choose with you, system by system, and set up your part from the start.
The card below stacks one system’s parts from the ground up. The line shows where the part AWS looks after ends.
Drag the line, or use the two buttons or the arrow keys, to see who looks after each part in each way of running.
One system, from the ground up
- Who can reach what
- Your data
- Network rules and settings
- Your code and its libraries
- The language your code runs in
- Servers and their operating system
- Buildings, hardware and the network
Each way fits different systems, and we choose with you.
Running as:
{{ yoRun }}
Looked after for you:
- {{ r.t }}
Yours:
- {{ r.t }}
Always yours: your code, your data, your settings and who can reach them.
{{ yoSay }}
Inside support, one version at a time
AWS Lambda deprecates a runtime, the version of a language that functions run on, when a major part of it reaches the end of its community’s long-term support. From then on, AWS Lambda no longer updates it, and later it blocks new functions on it, then updates to existing ones.
Each version Amazon EKS runs has a period of standard support, then a period of extended support, charged at a higher rate. With extended support turned off, a cluster is upgraded automatically when standard support ends; with it on, a cluster still on that version becomes eligible for an automatic upgrade when extended support ends.
Each major engine version of Amazon RDS and Amazon Aurora reaches an end of standard support too. A database still on it can move into Amazon RDS Extended Support, charged from the day after that date, and once that period ends, its engine is upgraded automatically.
AWS also publishes which of its services are closing, with their dates and a way forward, on its product lifecycle page.
We keep each system’s versions on one list, set against those dates, and move them forward one at a time, each on a branch and tested, before standard support ends.
Start with the accounts and the access
The review covers the accounts and how they’re organized; sign-in: who has access, through what, and who can change everything; the roles and permissions each service holds, and the access nobody uses; AWS CloudTrail in every account, and where its records are kept; how much of what runs is defined in code, and how it’s deployed; tags, budgets and alerts, and the largest costs, which we go through with you; versions against their end of standard support, across AWS Lambda runtimes, Amazon EKS clusters, and Amazon RDS and Amazon Aurora engines; which systems run in more than one Availability Zone, and whether the copies kept of their data have been restored in tests; the network: what’s reachable from the internet, and what’s private; secrets, logs and alarms; CI and deploys; and where the pillars of the AWS Well-Architected Framework point.
The first step is one of these, each tried in a test account first: accounts separated by environment, with guardrails set in one place; one role narrowed to the permissions it uses; tags, budgets and alerts set; one system’s resources defined in code, matching what runs; or one version moved forward before its standard support ends.
What you receive is a written review and a proposal for that first step.
Questions worth asking
Is it the right cloud for our system?
That depends on the system and the team: what it runs, where its users are and what your team already knows. We look at that first, suggest what fits, and say so plainly when another way would suit it better.
Can you work in the accounts we already have?
Yes, with the access you give us, each of us signing in as ourselves. The accounts, and everything in them, stay yours.
Servers, containers or functions?
Each fits different systems. On Amazon EC2 you run the servers; on AWS Fargate, AWS looks after the servers beneath your containers; on AWS Lambda, your code runs as functions on runtimes AWS keeps patched while they’re supported. We choose with you, system by system.
How do you keep costs in view?
Every resource carries tags for its team and product, budgets and alerts are set for each, and we read the bill with you, so each cost has someone who knows why it’s there.
What happens when a version reaches the end of standard support?
It depends on the service. An AWS Lambda runtime stops getting updates once it’s deprecated, and later new functions on it, then updates to existing ones, are blocked. Amazon EKS and Amazon RDS can keep an older version running in extended support, which is charged. We move each one forward before its date.
Can you move our systems across?
Yes, in planned stages: each step tested, with a way back, and the old system kept running until the new one has taken over its work.
How do you keep it secure?
We set up your part of the shared responsibility model from the start: sign-in through one place, permissions kept to what each needs, a record of the changes made in every account, and networks kept private where they should be.
Can we add AI features?
Yes, with Amazon Bedrock, which AWS describes as a platform for building generative AI applications and agents, each feature given only the access it needs.
Can you take over our existing systems?
Yes. First we read your accounts: how they’re organized, who can reach what, how much is defined in code and how it’s deployed. Then we agree a first piece of work with you, owned by one person on our side and done alongside your developers.
What does it cost?
That depends on your systems and the first step you choose. Before any work starts, you get a written proposal with the scope, the price or rate, and how you pay.
Can AI assistants help with our code?
Yes. Whatever an assistant drafts, from application code to the code that defines your resources, is tested, and a person reviews it before it’s deployed.
Can we hire developers for our own team?
Yes. Within 48 hours of your request we introduce developers who build on AWS, each working in your time zone, and you meet them before you decide who joins.
Amazon Web Services, AWS and the names of AWS services are trademarks of Amazon.com, Inc. or its affiliates. Webair isn’t affiliated with, sponsored by or endorsed by AWS.
Let’s build it better
Tell us about your systems on AWS and how their accounts and access are set up, and we’ll suggest a first step in a short call.
Thanks, we’ll be in touch soon.
{{ ctaStatus }}