A single idle database instance can run for months without anyone noticing, quietly adding thousands of dollars to a company's cloud bill before someone finally asks why costs crept up again.
Finding that waste, and building the automation that keeps it from creeping back, is what this engineering role is built around. You design, build, and test tooling that tracks and reduces cloud spend across the infrastructure your team owns, working closely with engineering, finance, and platform teams so cost decisions do not break reliability in the process. Every piece you ship gets code-reviewed, tested, and documented, because a cost-optimization script that quietly breaks a production alert is worse than no automation at all.
Most engineering teams treat cost as an afterthought until a bill spikes, and then everyone scrambles for a week before going back to ignoring it. This role exists to break that cycle: build the dashboards, alerts, and automated policies that make cost visibility a normal part of how the engineering org works, not a quarterly fire drill.
Expect real variety here. One week might be spent building a rightsizing recommendation into an internal dashboard, the next debugging why a cost alert fired for the wrong resource group entirely. You will work with cross-functional teams constantly, since a cost decision that looks obvious in isolation, like shutting down an idle staging environment, can have consequences a product team needs to weigh in on first.
A strong start in this role usually means shipping at least one meaningful cost-saving change within the first month or two, something small enough to ship quickly but real enough to show up in the numbers. From there, most engineers move on to bigger automation projects that prevent waste proactively instead of just catching it after the fact.
A bachelor's degree in computer science, software engineering, or a related field is expected, along with two years of hands-on engineering experience, ideally with some direct exposure to cloud infrastructure and cost management. A portfolio of real projects, whether from a job, an open-source contribution, or a serious side project, tells the hiring team more about your ability than a list of courses does.
Extra weight goes to candidates with hands-on experience in a major cloud provider's cost or billing tooling, familiarity with infrastructure-as-code, or a track record of driving a measurable cost reduction on a previous team.
The role pays $143,000 a year, full-time, with health coverage, paid time off, retirement plan matching, and a remote-work or home-office stipend included. Remoteroles fills this position for teams that run fully distributed engineering organizations, so async communication is the default, not an accommodation.
Work happens through Git-based code review, a shared ticketing system, and a handful of scheduled syncs each week for planning and cross-team alignment. Some overlap with your core team's working hours is expected for those syncs, but focused engineering work is yours to schedule. You will typically report to an engineering or platform lead who cares more about the trend in the cost graph than about hours logged.
If you like solving a problem that has a clear, measurable outcome, this role delivers that constantly: spend goes down, or it does not, and you can see the number move. It suits engineers who get restless doing pure feature work and want a mandate that touches infrastructure, tooling, and cross-team influence all at once.
The typical toolkit includes a cloud provider's cost-management console, an internal dashboard or third-party FinOps tool, Git for version control, and a CI pipeline for testing changes before they reach production. None of it is unusual for a modern engineering team, though tying it together well is where the real work lives. Documentation matters more here than in a lot of engineering roles, since a cost policy nobody understands gets ignored or worked around within a month.
A concrete example: a team spins up a large test environment for a two-week experiment and forgets to tear it down, and it quietly runs for four months before someone notices the charge. Preventing that kind of thing through automation, not manual policing, is the actual goal of this role. Cost conversations can also get political fast, since shutting down an environment sometimes means telling another team their project is not worth what it is costing, and handling that diplomatically, backed by real data, matters as much as the engineering itself.
Engineers who do this work well for a year or two often move toward a broader platform or FinOps leadership role, since the skill set, understanding both engineering tradeoffs and cost accountability, is genuinely scarce. Some also move laterally into site reliability or infrastructure roles that value the same instincts.
Reliability work and cost work overlap more than people expect. A resource that looks wasteful in isolation sometimes exists for a legitimate failover reason, and telling the difference takes more than a quick glance at a dashboard; it takes understanding how the system is actually used in practice. Engineers who get good at that distinction earn real trust quickly, since nobody wants an automation that saves money by accident breaking something critical overnight. It is also common to inherit legacy infrastructure with no clear owner, and part of the job is simply figuring out who to ask before making a change.
To apply, send a resume along with a link to relevant code or a project that shows your engineering approach. The interview process includes a technical conversation and a practical discussion of a cost or infrastructure scenario, and most candidates hear a decision within two to three weeks.