What Does a Cloud Developer Do?

A cloud developer designs, builds, deploys, and operates software on platforms such as AWS, Microsoft Azure, and Google Cloud. The role combines application development with cloud services, security, CI/CD, observability, and infrastructure decisions.

The difficult part is rarely getting an application online. It is making sure that the application behaves correctly when an API times out, traffic spikes, a message arrives twice, permissions are wrong, or a deployment fails.

For a CTO, that production judgement matters more than knowing a long list of cloud products.

A cloud developer turns product requirements into software that can run reliably in a cloud environment.

The balance varies by company. A startup developer may own code, infrastructure, deployment, and monitoring. Larger organisations often split those responsibilities between application developers, cloud engineers, DevOps engineers, platform teams, security specialists, and SREs.

Design cloud application architecture

Cloud developers map application requirements to technical components.

Consider a FinTech platform that processes transactions. The product might need an API, authentication, PostgreSQL, background jobs, object storage, an audit trail, notifications, and third-party integrations.

The application could run on virtual machines or managed containers. Some workflows could use serverless functions. Background jobs could use queues. The database could be self-managed or provided as a managed service.

The right architecture depends on traffic, recovery requirements, data sensitivity, team size, operating cost, and frequency of change.

Cloud-native architecture should mean using cloud capabilities where they solve a real problem, not adding as many services as possible.

A five-person SaaS team may operate more effectively with one modular application and a managed PostgreSQL database than with 25 microservices and a Kubernetes cluster.

Every service boundary creates another deployment, network connection, permission model, log stream, and possible failure. Senior developers know when that complexity is justified.

Build application code and cloud integrations

Cloud development still requires strong programming skills.

Common languages include Python, TypeScript and JavaScript, Java, C#, and Go. Developers connect application code to databases, storage, identity systems, queues, serverless runtimes, AI APIs, and other managed services.

A developer does not need to memorise every AWS, Azure, or GCP product.

The more valuable skill is understanding the engineering pattern behind the service.

Design for partial failure

Distributed cloud applications rarely fail as one unit.

One operation can succeed while the next fails.

Imagine an InsurTech platform charging a $500 premium. The payment provider accepts the transaction, but the network connection drops before the application receives confirmation.

The client retries.

If the application treats the retry as a new payment, the customer can be charged twice.

A developer can prevent that with idempotency. An idempotent operation can be repeated without creating another business outcome. The request carries a unique identifier, and repeated attempts return the original result instead of executing the operation again.

The same issue appears in asynchronous systems.

Queues can deliver the same message more than once. A process that creates invoices, transfers funds, updates balances, or changes policies must therefore be safe when duplicates occur.

Retries also need limits. Repeatedly calling an unhealthy API can increase pressure on the dependency.

Better implementations use timeouts, bounded retries, backoff, and a defined final failure path.

Move slow work out of user requests

Cloud developers decide which operations must happen immediately and which can run in the background.

Suppose an insurance application needs to:

1. process payment;
2. activate a policy;
3. generate policy documents;
4. send an email;
5. update analytics;
6. notify a CRM.

The customer probably does not need to wait for all six steps.

Payment and policy state may belong in the synchronous request. Document generation, analytics, CRM updates, and some notifications can often run through asynchronous workers.

That reduces coupling and represents failure more accurately. A policy can be active while an email remains pending instead of treating an email-provider outage as a failed purchase.

The technical decision changes the customer experience.

Automate builds and deployments

Cloud developers work with DevOps teams to make releases repeatable.

A CI/CD pipeline can build code, run tests, scan dependencies, create an artefact, deploy it, validate the result, and support rollback.

Code & Pepper's AWS DevOps guide explains how CI/CD, infrastructure as code, observability, and security checks fit into an AWS delivery process.

Automation also creates evidence of what changed. Teams can see which commit produced a release, which tests ran, which artefact reached production, and how it was deployed.

For FinTech, HealthTech, and InsurTech teams, that traceability can support security reviews and audit processes.

Define infrastructure as code

Infrastructure as code, or IaC, describes cloud resources in version-controlled files.

Common tools include Terraform, Pulumi, AWS CDK, and CloudFormation.

IaC makes infrastructure changes reviewable and environments easier to reproduce. It also reduces dependence on configuration that exists only inside a cloud console.

Code & Pepper applied this approach while improving the infrastructure behind GaiaLens, an ESG analytics platform for institutional investors.

The GaiaLens infrastructure case study describes a Google Cloud Platform setup using Terraform and automated deployment. The work also addressed database access that had previously been exposed to the public internet.

A network rule can matter as much as application code.

Build security into cloud applications

Cloud providers do not take responsibility for every part of application security.

Customer responsibilities vary according to the services selected and can include data, applications, guest operating systems, firewall configuration, encryption choices, and IAM permissions.

For developers, security becomes concrete work:

• assign least-privilege permissions;
• separate user and service identities;
• keep secrets out of source code;
• encrypt sensitive data;
• restrict network access;
• validate authentication and authorisation;
• log security-relevant events;
• update vulnerable dependencies.

Least privilege deserves particular attention.

Giving an application broad administrative permissions may solve an IAM problem quickly. It also increases the impact of a compromised workload.

For regulated products, access control, auditability, data handling, and change history should be architecture requirements from the start.

Make production observable

Cloud applications need telemetry that shows both technical health and customer impact.

Logs describe events. Metrics show behaviour over time. Traces follow requests across components.

Together, they can reveal which requests are failing, which dependency is slow, whether a release introduced an error, or whether a queue is building up.

The stronger approach connects technical monitoring with product outcomes.

CPU usage may look normal while payments fail.

A payments platform should know its authorisation success rate. A HealthTech scheduling product should track completed bookings. An API company should monitor latency and errors on important endpoints.

Infrastructure can be healthy while the product is broken.

Treat cloud cost as an architecture concern

Developers influence cloud spend through technical decisions.

Compute size, database type, storage tier, data transfer, retention rules, region choice, scaling behaviour, and AI workloads all change the bill.

A serverless application can be efficient for intermittent workloads. A predictable high-volume service may have different economics.

Code & Pepper's cloud cost optimisation guide covers rightsizing, storage, scaling, networking, and FinOps controls across AWS, Azure, and GCP.

For a CTO, one useful architecture question is:

What happens to this cloud bill when usage grows by 10x?

A senior developer should know which costs scale with requests, compute time, storage, network traffic, database load, or model inference.

Cloud developers focus mainly on applications, while cloud engineers focus more on infrastructure and DevOps engineers focus on software delivery and operations.

The roles still overlap in real teams.

The boundaries are often less clear in startups. One senior engineer may write TypeScript, provision AWS resources, configure CI/CD, set alerts, and investigate incidents.

That model becomes harder as teams grow.

When several teams keep rebuilding pipelines, deployment scripts, environment creation, and monitoring, platform engineering can turn repeated work into shared services.

Code & Pepper's platform engineering vs DevOps guide explains when that shift starts to make sense.

Strong cloud developers combine software engineering depth with enough infrastructure knowledge to make sound production decisions.

The core skills fall into six areas.

Programming

At least one production language should be strong.

Python, TypeScript, Java, C#, and Go are common choices. What matters is the ability to design maintainable application code, tests, APIs, and integrations.

Cloud platform knowledge

Depth in AWS, Azure, or GCP is usually more useful than shallow knowledge of all three.

The transferable concepts include compute, storage, databases, networking, identity, queues, functions, containers, logging, and scaling.

Distributed systems

Developers should understand timeouts, retries, idempotency, eventual consistency, caching, concurrency, rate limits, message delivery, and failure isolation.

These concepts remain relevant regardless of provider.

Security

A developer should understand IAM, secrets, encryption, access boundaries, logging, and network restrictions.

Delivery and testing

Git, automated tests, CI/CD, containerisation, and deployment strategies are part of everyday cloud development.

Production debugging

A developer should be able to move from a customer symptom to logs, metrics, traces, recent deployments, dependency behaviour, and the affected code path.

That skill is difficult to measure with certifications alone.

The best platform depends on the company's existing systems, product requirements, data, and engineering skills.

AWS offers a broad service ecosystem. Azure often fits organisations already invested in Microsoft technologies. Google Cloud is widely used for cloud-native applications, data platforms, containers, and AI workloads.

The service names matter less than the architecture decisions behind them.

Code & Pepper has delivered products using all three major providers across FinTech, HealthTech, InsurTech, SaaS, and data-intensive applications.

For Aspen, an investment analytics platform, Code & Pepper delivered end-to-end product work and cloud architecture using AWS, Node.js, React, and TypeScript.

For Nimbla, an invoice insurance platform, the team included full-stack, front-end, DevOps, and cloud specialists. The stack included Google Cloud Platform, Node.js, React, and TypeScript.

For US InsurTech company CoverTree, the team used AWS serverless architecture while working on security, reliability, scaling, integrations, and operating cost.

The provider changed. The engineering questions did not.

A production cloud system needs an explicit plan for what happens when one dependency stops working.

Consider a lending platform processing a credit application.

The application records the request. It then needs bank data, identity information, a fraud check, and a risk score before producing a decision.

One external risk API starts taking 15 seconds to respond.

A weak implementation waits. When the request finally times out, the user sees an error and submits the form again.

Now the platform may have two applications for the same person.

A better design gives the request a unique idempotency key. The application creates one credit request and records its state as pending.

A background worker calls the slow provider with a defined timeout. Failed requests use bounded retries with backoff. Persistent failures move to a dead-letter queue or another controlled recovery path.

The user sees an accurate status rather than a false failure.

Monitoring tracks:

• applications created;
• applications completed;
• duplicate submissions;
• provider timeout rate;
• queue depth;
• processing latency;
• failed messages.

This is the difference between deploying software in the cloud and engineering it for production.

Cloud development costs depend on location, seniority, employment model, and scope of responsibility.

For US hiring, researched reports say that an average annual salary of $128,365 as of September 7, 2026, equivalent to about $61.71 per hour. Most salaries currently fall between $112,500 and $154,000.

Other sources provide a broader benchmark. The median annual wage for software developers was $135,980 in May 2025. In finance and insurance, the median was $135,460.

These figures are useful for budgeting, but salary or hourly rate should not be the only comparison.

The more useful question is what scope an engineer can own. Architecture choices affect infrastructure spend, security exposure, reliability, and the engineering time required to maintain the product.

Cloud development can range from a sprint-sized change to a multi-month migration programme.

For migration work, it is better to check all dependencies before setting a timeline.

Individual migration waves often take 6 to 10 weeks, depending on application complexity, data movement, downtime limits, security requirements, integrations, and rollback planning.

A credible estimate follows dependency discovery, not the other way around.

Bring in specialist cloud expertise when cloud architecture becomes a delivery, security, reliability, or cost constraint.

Typical signals include manual deployments, scaling problems, rising cloud spend, unclear IAM ownership, poor observability, repeated infrastructure work, or a migration that needs dedicated technical ownership.

The engagement model should follow the problem. A backend engineer with strong cloud skills may cover an ongoing application need. A bounded infrastructure change may suit external specialists. Continuous ownership across several product teams may justify dedicated cloud, DevOps, or platform capability.

When evaluating an engineer or delivery partner, skip cloud-service trivia and ask about production decisions:

• What happened when a dependency timed out?
• How did you prevent duplicate operations?
• How were workload permissions limited?
• Could another engineer reproduce the infrastructure?
• How did rollback work?
• Which metrics showed customer impact?
• What happened to cost as usage increased?
• What would you simplify if you rebuilt the system?

Strong answers connect architecture to failure, security, cost, and product behaviour.

Code & Pepper provides DevOps and cloud engineers for FinTech and HealthTech across AWS, Azure, GCP, infrastructure as code, CI/CD, observability, and IAM. For broader infrastructure changes, its cloud migration and cost optimisation services cover assessment, migration, scaling, rightsizing, and post-migration optimisation.

If unstable releases, unclear permissions, production bottlenecks, rising cloud costs, or a planned infrastructure change is slowing your product, talk to Code & Pepper about the engineering expertise needed to fix that specific constraint.

What does a cloud developer bring to a software project? Here are quick answers about cloud development, AWS, Azure, GCP, DevOps, Kubernetes, salaries, and cloud migration.

What does a cloud developer do?

A cloud developer builds and operates applications on platforms such as AWS, Azure, and Google Cloud. Typical responsibilities include application code, APIs, managed services, security, deployment, monitoring, scaling, and production debugging.

Is a cloud developer a software developer?

Yes. It is a software engineering specialisation that adds cloud services, distributed systems, security, deployment, observability, and infrastructure knowledge.

What is the difference between a cloud developer and a cloud engineer?

A cloud developer focuses more on application code and its use of cloud services. A cloud engineer usually spends more time on infrastructure, networking, IAM, compute, storage, and migration. The responsibilities often overlap.

Does a cloud developer need DevOps skills?

Yes. Developers working with cloud applications should understand CI/CD, automated testing, deployment, containers, observability, rollback, and infrastructure as code, even when a dedicated DevOps team owns the shared platform.

Which programming languages do cloud developers use?

Common choices include Python, TypeScript and JavaScript, Java, C#, and Go. The right language depends on the product, existing stack, team skills, cloud services, and performance requirements.

Does a cloud developer need Kubernetes?

No. Kubernetes solves specific container orchestration problems, but it adds operational work. Managed containers, serverless functions, PaaS products, or virtual machines may suit simpler workloads better.

Should a cloud developer know AWS, Azure, and GCP?

Not necessarily. Deep knowledge of one provider plus a strong understanding of transferable cloud concepts is often more valuable than shallow knowledge of all three.

How much does a cloud developer earn in the US?

Cloud developer salaries vary by seniority, location, and responsibilities. In the US, the average annual salary is around $128,365, or about $61.71 per hour, with most salaries ranging from $112,500 to $154,000.

How long does a cloud migration take?

There is no fixed timeline for a cloud migration. Individual migration waves often take 6 to 10 weeks, depending on application complexity, data movement, downtime limits, security requirements, integrations, and rollback planning.