Cloud engineer, fully remote, $122,000 a year, open to candidates anywhere. Full-time position within the DevOps and cloud infrastructure side of the business, focused on the systems everything else in the company quietly depends on.
Applications, internal tools, and customer-facing products all sit on top of infrastructure someone has to design and keep running, and that's the layer this role owns. When it's built well, nobody upstream thinks about it much. When something in that layer breaks, the effects show up everywhere at once.
Responsibilities
- Design, deploy, and maintain scalable cloud infrastructure
- Automate provisioning and deployment processes
- Monitor systems for performance, security, and cost efficiency
Security monitoring in a cloud environment catches problems that would be obvious in a traditional data center but can slip by unnoticed here. A security group rule opened too broadly during a quick fix, say, exposing a database port to the public internet instead of just the application servers that need it, can sit unnoticed for weeks if nobody's actively auditing configurations. Regular reviews of that kind of exposure are a routine, expected part of the role, not something reserved for after an incident.
Cost efficiency work runs alongside the technical side constantly. A cloud environment that's technically working fine can still be burning through budget on resources nobody's actively using anymore, and part of the job is noticing that pattern before finance does.
Deployment automation covers more ground than a first read of the responsibilities might suggest. It's not just scripting a launch process once and walking away. Environments drift over time as manual changes accumulate outside the automated pipeline, and part of the ongoing work is catching that drift before infrastructure-as-code stops reflecting what's actually running.
Background needed
The degree requirement here is a bachelor's degree, and computer science is the most common field, though a closely related technical degree would satisfy it as well. Candidates should have 30 months of hands-on experience managing cloud infrastructure and a relevant cloud certification. Familiarity with automation and containerization tools is expected when walking in.
- Cloud platforms: AWS, Azure, or GCP
- Infrastructure as code
- Linux
- Networking
- Containerization
- Scripting
A specific certification, like AWS Solutions Architect or Azure Administrator, tends to carry real weight in review, more than a general mention of cloud familiarity does. Hands-on experience with Terraform or Pulumi helps for the same reason that infrastructure-as-code shows up on the required list. Multi-cloud exposure, some background in disaster recovery planning, and familiarity with a security compliance framework like SOC 2 will all make an application stronger without being required.
Cost optimization tools specific to a given provider, such as AWS Cost Explorer, are worth mentioning on a resume as well. Many candidates can describe infrastructure they've built, but fewer can point to a specific instance where they identified and eliminated unnecessary spend, and that distinction matters to a hiring manager weighing this particular responsibility.
Compensation
The role pays $122,000 annually. Health insurance, paid time off, 401(k) matching, and certification support are all part of the standard package here, which matters in a field where staying current on cloud provider certifications is an ongoing cost. Some employers hiring at this level also offer a wellness stipend or a home office equipment allowance for remote staff, though these vary by company.
- Health insurance
- Paid time off
- 401(k) matching
- Certification support
What this kind of work actually feels like
Cloud infrastructure work is mostly invisible when it's going right, which can make the job feel underappreciated at times. Naukri Mitra hears this from cloud engineers fairly often: nobody notices a well-architected system until it breaks, and by then the conversation is about what went wrong rather than the months of solid work that came before it. That's a real part of the job, worth knowing going in rather than discovering later.
Networking knowledge tends to separate strong candidates from average ones more than people expect. VPC design, subnet planning, and understanding how traffic actually routes between services aren't glamorous skills, but a cloud engineer who's weak in this area ends up building infrastructure that works until it doesn't, usually at the worst possible moment.
Disaster recovery planning falls into a similar category. It's easy to skip when everything is running smoothly, and expensive to skip when it isn't. A cloud engineer who's actually walked through a recovery scenario, even a practice one, understands the gap between having a backup and having a tested plan to restore from it.
How this fits into a career
Cloud engineer remote salary tends to track fairly closely with certification depth and the number of production environments someone's actually managed, more than with years of experience alone. Someone learning to become a remote cloud engineer typically starts with a systems administration or DevOps background, picking up cloud-specific skills and certifications along the way rather than starting directly there. That path takes longer than a bootcamp certificate suggests, but it tends to produce engineers who understand infrastructure at a deeper level than the certification exam alone can assess.
Anyone considering this role should have real examples ready of infrastructure they've designed or maintained end-to-end, not just individual tickets closed on someone else's system. Being able to walk through why a particular cloud architecture decision was made, including the tradeoffs considered and rejected, matters more in an interview here than reciting a list of AWS services by name.
The 30-month experience bar reflects that expectation directly. It's meant to filter for someone who's already made a few of those architecture calls and lived with the consequences, good or bad, rather than someone who's only followed infrastructure that another engineer already designed.
