Hire AWS Developers: Who Gets Into Your Account, and on What Terms

Updated November 2026 · Written and maintained by the Progression Agency strategy team

The worst AWS hire is the one whose personal access key is still the only way into your account after they leave. AWS secures the hardware and facilities, but under its shared responsibility model everything you build and configure inside the account is yours to protect. When you hire AWS developers, you hand part of that job to someone else, so the sign in method, the permissions and the budget alarms come before the first line of code. Progression’s team is based in New York and supplies AWS developers to US businesses on those terms, remotely or on site.

An account only the last contractor could open

A hypothetical company let its developer set up everything with one long-lived access key, and the root login lived on the developer’s personal phone. The contract ended. Now nobody can change a DNS record.

The company never made a bad decision on any one day. The hiring decision simply included an access decision that nobody made, and the key became the account’s only door.

Why is a personal key such a problem?

It belongs to a person, not to the business. When that person leaves, the access either stays open to someone who should not have it or disappears with them.

Hire AWS developers by the work in your account

The brief to write is the list of things already running in the account, not a job title. Each kind of work touches different services and needs different permissions, and the table lays them side by side.

The plain advice: write the hire brief from the services already running in the account, and give the developer permissions for those and nothing else. For a move onto AWS, see cloud migration services.

Hire AWS Lambda developers for event driven code

Lambda work is small functions that run when something happens, such as an upload or a request. The developer needs rights to deploy and update those functions, and the review is how each function is limited to the data it uses.

Hire an AWS solutions architect before the build

When the shape of the system is undecided, a short design phase comes first. An AWS solutions architect draws the services, the data flow and the permissions, and the developers then build to that drawing.

• Name each AWS service the work will touch.
• Name the data it reads and the data it writes.
• Decide who approves a change to production.
• Write down what the developer must never touch.

What security in the cloud leaves with you

AWS describes security and compliance as a shared responsibility between AWS and the customer. AWS is responsible for security of the cloud: the hardware, software, networking and facilities that run its services. The customer is responsible for security in the cloud.

That customer share depends on the services chosen. For Amazon EC2, the customer manages the guest operating system, including updates and security patches, the installed software and the firewall settings AWS provides for each instance. For abstracted services such as Amazon S3 and DynamoDB, customers manage their data, including encryption options, classify their assets and use IAM tools to apply permissions.

The plain advice: the contract names which part of security in the cloud the developer owns, and the business keeps the root user and the billing.

Does hiring a developer move the responsibility?

No. You can hand the work to a developer, but the responsibility for what is configured in your account stays with your business. The contract decides who does the work.

Sign in, permissions and keys from day one

AWS’s IAM guidance reads as a checklist, and the terms of a hire can follow it line by line. The developer works within these seven rules from the first day.

1. Human users sign in through federation with an identity provider and receive temporary credentials.
2. Workloads use IAM roles and temporary credentials, not stored keys.
3. Multi-factor authentication is required.
4. Where a long-term key cannot be avoided, it is updated when needed.
5. The root user’s credentials are protected and kept by the business.
6. Permissions start narrow and are widened only when a task needs it.
7. IAM Access Analyzer checks policies and any public or cross-account access.

Unused users, roles, permissions, policies and credentials are reviewed and removed regularly. The plain advice: the developer never receives the root login or a long-lived personal key. See AWS’s IAM best practices for the full list.

• Give the developer a role, not a user with a password.
• Scope the role to the services in the work table.
• Turn on multi-factor authentication before the first sign in.
• Calendar a review of every permission the developer holds.

What is least privilege in practice?

A permission set that starts with almost nothing and grows only when a named task needs more. It is slower on day one and much safer on day ninety.

Budget alarms before the first deploy

AWS Budgets can track costs and usage, alert on actual and forecasted spend and apply an action, such as a custom IAM policy, when a threshold is reached. A budget is the control that watches the bill while the developer works.

There is a catch. Because of a delay between when a resource is used and when that use is billed, costs can exceed the notification threshold before the alert arrives. A budget limits the surprise; it does not remove it.

The plain advice: set a monthly cost budget and a forecast alert before any developer gets write access, and agree who acts on an alert. See AWS’s page on managing costs with Budgets for the options.

Who acts when an alert arrives?

A named person on your side and one on the developer’s side, written into the engagement. An alert nobody owns is noise.

Hire cloud developers or an AWS consultant?

A cloud developer builds and ships. A consultant reviews and recommends. Many projects need a short consultant phase first, then developers, and some need only one. If you hire cloud developers before the design is settled, you pay for rework.

If you are weighing whether to hire an AWS consultant, the question is whether you already know what to build. For the choice of platform, see AWS vs Azure vs Google Cloud.

When is a cloud developer enough?

When the system is small, the design is clear and someone on your side can review the infrastructure changes.

Engagement models and contract terms

Three models cover most work: a project with a fixed scope, dedicated AWS developers by the month, and a review retainer beside your own team. A project suits a clear deliverable, and the monthly model suits ongoing work with a changing backlog.

• A project with a fixed scope and a defined end.
• Dedicated AWS developers by the month for ongoing work.
• A review retainer where your developers build and ours check.

Whatever the model, three terms are written in. The AWS account stays owned by the business, the infrastructure as code lives in the business’s repository, and documentation is a deliverable. For general dedicated hiring across other stacks, see hire dedicated developers.

Who owns the code?

The business. It sits in your repository from the first commit, so ending the engagement never means asking for the code back.

What AWS developers cost to hire

Pricing depends on scope, is subject to change and is set in the written proposal. AWS usage is billed by AWS to the business and is never part of the developer’s fee.

• Ask what the fee covers and what AWS bills separately.
• Ask how a fixed scope handles a change in requirements.
• Ask what the monthly model includes when the backlog is quiet.
• Ask for the access and budget terms in the proposal itself.

A paid first task that shows how they work

Before a larger engagement, give the developer a small paid task in a sandbox account. The result shows how they handle access, naming and cost, which an interview does not.

A good task is writing infrastructure as code for one storage bucket with least privilege access and a budget alert. When you hire AWS experts, the work they hand back tells you more than their description of it.

• Does the code run from a role, not a personal key?
• Is the permission set narrow and explained?
• Is the budget alert in the code?
• Can someone else on the team read and run it?

How big should the first task be?

A day or two of work. Anything larger stops being a test.

Ending access cleanly

The last day of an engagement is a security event. Federated access is revoked, any key the developer could see is rotated, IAM Access Analyzer findings are reviewed, and the infrastructure as code is compared with what is actually running.

• Revoke the developer’s federated access first.
• Rotate every key the developer could see.
• Read the Access Analyzer findings and close what they show.
• Confirm the code in the repository matches the running account.
• Take the runbook and store it where the business controls it.

What is a runbook?

The written steps for operating what was built: how to deploy, how to roll back, who to call and where each credential lives.

What to put in the hire brief

The brief that attracts the right developer is specific about the account. A paragraph of general cloud language draws general replies.

• The AWS services already running, listed by name.
• The workloads, whether functions, containers or data jobs.
• The data involved and how sensitive it is.
• The engagement model and how long the work should last.
• The sign in method and budget terms the developer must accept.

A brief that includes the access terms filters out developers who expect a shared password. The same brief can also be handed to a second firm for comparison, which is fair to both.

Should the brief name a budget?

It should name the monthly cost budget for the AWS account, as distinct from the developer’s fee.

Working beside your in-house team

Many engagements place a developer next to people already on staff. The developer can take a backlog, review infrastructure changes or cover a gap while a role is filled.

For pipelines and production operations, see DevOps services.

Do outside developers get production access?

Only if the engagement needs it, and then through a role scoped to what the task requires.

Frequently asked questions