Hire AWS Developers in India
Nobody struggles to hire AWS developers in India because there are too few of them. They struggle because AWS is so large that almost every candidate can honestly claim a dozen services, and only a fraction of them can architect one. That gap is what this page is about, and how to find it in an hour.
The Breadth Trap: Why Every AWS CV Looks Excellent
Ninety per cent of bad AWS hires are the same mistake, and it is not a lack of diligence. It is that AWS makes shallow experience look like deep experience on paper.
One vendor makes a long list look like a career
A CV arrives naming S3, EC2, Lambda, API Gateway, RDS, DynamoDB, SQS, SNS, ECS, EKS, CloudFront, Route 53, CloudWatch, Step Functions, Kinesis, Glue and Athena. Seventeen services. Read that same list as seventeen separate products from seventeen separate companies and your instinct would be suspicion. Because they all carry the same logo, it reads instead like a coherent skill set with a name on it, and the name is AWS.
The suspicion was right the first time. Knowing a service properly means running it well past the point where documentation stops helping: sizing it wrong, watching it throttle, working out what its headline metric is really counting, and arriving at a view on where it is a poor fit. Reaching that point takes months per service, not weeks. What the seventeen item list normally records is one application, built once, that happened to touch all of them, with the depth of a getting started guide behind every entry.
The console is what makes it possible
This is the part people miss. On AWS you can genuinely stand up almost anything without understanding it, because the console fills in every decision you did not know you were making. Create a VPC through the wizard and you get subnets, route tables, an internet gateway and a NAT gateway without ever choosing a CIDR block or knowing what a route table is for. Create a Lambda function and it silently creates an execution role with a policy attached. Create an RDS instance and it picks a subnet group, a parameter group and a backup window on your behalf.
Every one of those defaults is a decision that someone will have to defend later, usually during an incident or during a bill review. An engineer who has only ever built through the console has never made those decisions, has no vocabulary for them, and will not recognise them as decisions when they cause a problem. Ask a candidate what CIDR they chose for their last VPC and why. The honest ones say they inherited it. The tell is the ones who have never thought about it at all.
What the breadth actually costs you
A broad shallow hire is not useless. They will build things, and the things will work in staging. The cost turns up in three places, always slightly later than the point at which you could have avoided it.
Cost is the first, because AWS charges for the shape of your architecture and a shallow design has an expensive shape. Security is the second, because the easy path through IAM is a permissive one and it stays invisible until somebody audits it or exploits it. The third is the one that hurts most: reversibility. Some AWS decisions can be changed on a Tuesday afternoon and some of them cannot be changed at all without rebuilding the account. A person who cannot tell those two categories apart will eventually put you on the wrong side of one.
How to screen past it without becoming an interrogator
Stop asking what they have used. Ask instead which service they ran for more than a year and what they hated about it, because sustained exposure always leaves a specific grievance behind. Ask what they turned off or migrated away from, since deliberate removal is a much stronger signal than adoption. Ask them to describe the request path through their last production system, hop by hop, from browser to database, and listen for whether the network appears in the answer at all.
Still unsure whether cloud is even the binding constraint here? Start one level up. Our overview of how to hire developers in India compares the engagement shapes before you commit yourself to a single named skill.
What Does an AWS Engineer Actually Do in a Week?
Job adverts say design and build scalable cloud solutions. Here is the week that phrase is hiding.
Writing the permission that should have existed
A service needs to read one prefix in one bucket and write to one queue. The version that appears in the first pull request grants far more than that, because it was copied from something that worked. Turning it into a policy that grants exactly what is needed, and proving it still works afterwards, is a recurring Tuesday.
Tracing a request that vanishes
Something returns a 504 roughly one time in forty. The load balancer logs it, the application never sees it, and the metric graphs look untroubled because a one in forty failure disappears into an average. This is the work that separates people who read dashboards from people who read logs.
Reading the bill like a diff
Not the total, which tells you nothing. The line items grouped by usage type, compared against last week rather than last month, looking for the day something changed shape. A competent engineer does this on a schedule instead of after somebody in finance sends an alarmed email.
Refusing a service, politely
A developer wants a new managed service for a problem that a queue and a cron job already solve. Saying no to a service that genuinely would work, on the grounds that it adds an operational surface nobody has agreed to own, is a senior behaviour and one you want to see in an interview.
Upgrades that nobody asked for
An RDS major version reaching end of standard support. A Lambda runtime being deprecated. An EKS version falling out of the supported window. None of these are features, all of them are dated, and all of them become emergencies if the person holding the calendar leaves.
Making the change reviewable
Turning a change somebody made in the console during last week's incident into code, so the next rebuild produces the same thing. This is unglamorous, constant, and the single best predictor of whether your infrastructure is recoverable.
Notice how little of that list is building something new. On a young account the balance tips the other way and the role really is construction. On an account that is three years old, most weeks are custody. Be honest with yourself about which one you are hiring for, because the people who enjoy each are not the same people, and a builder put on custody work leaves within the year.
IAM Is Where Tutorial Experience Stops
If you only have time to test one area properly, test this one. Nothing else discriminates as cleanly between somebody who has built on AWS and somebody who has operated on it.
Roles rather than users, and why the distinction is the whole test
An IAM user is a permanent identity with permanent credentials attached. A role is a set of permissions that something temporarily becomes, receiving short lived credentials from the security token service each time. Almost everything running inside AWS should be using a role: an EC2 instance through its instance profile, a Lambda function through its execution role, an ECS task through its task role, a Kubernetes pod on EKS through a service account mapped to a role by an OIDC provider.
So the diagnostic question is simple. Ask a candidate where the credentials come from for code running on an EC2 instance. If the answer involves putting an access key in an environment variable or a config file, you have learned something important in under a minute. If they describe the instance metadata service handing out temporary credentials that rotate on their own, and mention that the second version of that service requires a token and exists precisely because the first one was trivially readable through a server side request forgery, you are talking to someone who has been near a real incident.
Assume role, and the trust policy nobody reads
Every role carries two policies and candidates routinely only know one. The permissions policy says what the role may do. The trust policy says who is allowed to become it. Cross account access, third party integrations, CI pipelines authenticating without stored secrets: all of it lives in the trust policy, and it is where the interesting mistakes are.
Push on the third party case specifically. When you give an external vendor a role in your account, the trust policy should name their account as principal and require an external ID condition. Without that condition, another customer of the same vendor can potentially get the vendor to act against your account, which is the confused deputy problem and the reason the external ID exists at all. A candidate who can explain why that condition is there, rather than merely that it is there, has read past the copy and paste snippet.
The other one worth asking about is CI. Long lived AWS keys sitting in a build system are one of the most common ways credentials leak, and the modern answer is an OIDC trust relationship where your CI provider presents a signed token and assumes a role directly. Ask how they would scope that trust so that only one repository and one branch can assume it, and see whether they reach for a condition on the subject claim or wave vaguely at the principal.
Least privilege as it actually happens
Least privilege described in a book is a design activity. In practice it is iterative, and anyone who claims otherwise is describing a project they have not finished. The workable method is to start a new service with a deliberately generous policy in a non production account, run it under real load, then read CloudTrail to find out which API calls it genuinely made, and narrow the policy to that set. IAM Access Analyzer will generate a candidate policy from that activity, which gives you a starting draft rather than a finished answer.
Then comes the part people skip. Narrowing needs to happen again six months later, because services accumulate permissions during incidents and nobody removes them afterwards. Ask a candidate how they would find over granted roles in an account they just inherited. Good answers reach for last accessed information on services and actions, which tells you what a role has never once used, and treat that as the removal list.
Why a wildcard policy is a red flag rather than a shortcut
A policy granting every action on every resource is not a temporary convenience. It is a decision to stop having an opinion about blast radius, and it does not get revisited because nothing ever fails to remind you. When you see one in a code review, the useful question is not why the wildcard is there. It is which specific call the author could not get working, because there is almost always exactly one, and finding it turns a wildcard into three lines.
Two permissions deserve special attention and rarely get it. The ability to pass a role to a service lets a caller hand a more privileged role to something they control, which is a well understood escalation path, and it should be constrained to the specific roles the caller is meant to be able to pass. The ability to modify IAM itself is worse: any identity that can attach policies can grant itself everything else, so a policy allowing broad IAM write access is administrator access wearing a modest name. A candidate who spots either of those in a policy you show them is worth a second conversation.
The permission systems layered on top
IAM is not the only thing that decides whether a call succeeds, and the interaction is where real accounts get confusing. Service control policies at the organisation level set a ceiling that no policy inside the account can exceed, which is how you stop anybody in any account creating resources in a region you do not use. Permission boundaries do something similar for an individual identity. Resource policies attach to the resource instead of the caller: a bucket policy, a queue policy, a KMS key policy.
The KMS case is the one to test. A user can hold an IAM policy granting decrypt on everything and still be refused, because the key policy on that particular key does not name them. This trips up capable people, and an engineer who has hit it will tell you about it without prompting. Somewhere in the same conversation you want to hear that an explicit deny always wins over any allow, no matter where it comes from, because that single rule explains most of the access problems you will ever debug.
The Connectivity Diagram Decides More Than the Compute Choice
Teams argue for weeks about containers versus functions and settle the network in an afternoon. That is backwards. The compute choice can be revisited. Several of the network choices cannot.
The address range you pick on day one is the one you keep
A VPC gets a CIDR block, and that block quietly determines who you can ever connect to. Pick a range that overlaps with your office network and the day you want a site to site tunnel you will be renumbering something. Pick one that overlaps with a company you later acquire and peering between the two is simply not possible, because routing cannot decide which side an address belongs to. Pick a small one to be tidy and you will run out of addresses in a subnet at the worst moment, which on EKS happens quickly because every pod takes an address from the subnet under the default networking plugin.
None of that is reversible in any comfortable sense. You can add secondary ranges, you can rebuild, you can put a translation layer in the middle and regret it. What you cannot do is change your mind cheaply. So this is worth ten minutes of any senior interview: ask what range they used last time, what else was on the other end of a tunnel, and whether they left room. The answer tells you whether they have ever had to connect two networks that were designed independently.
A public subnet is a route table, not a checkbox
There is no property on a subnet that makes it public. A subnet is public because its route table sends unmatched traffic to an internet gateway, and private because it does not. Say that out loud to a candidate and watch whether it lands as obvious or as new information, because a surprising number of people who have deployed to AWS for years have never had to know it.
It matters because most confusing connectivity failures are route table failures wearing a disguise. A resource that cannot reach the internet, a subnet that was meant to be isolated but is not, a new availability zone whose subnet was associated with the wrong table and therefore behaves differently from its two siblings for reasons nobody can see in the console at a glance. When something works in one zone and not another, the route table association is the first place to look and the last place people look.
NAT gateways, and the bill that grows without anybody deciding
Private resources that need outbound internet access go through a NAT gateway, and a NAT gateway bills in two ways at once: a charge for every hour it exists, plus a charge for every gigabyte that passes through it, and that processing charge sits on top of ordinary data transfer costs rather than replacing them. Check current pricing before you plan around it, since the numbers move, but the shape matters more than the numbers.
The shape produces two classic mistakes. One is a single NAT gateway shared across three availability zones, which saves the hourly charge and buys you a cross zone data charge on everything plus a single zone failure that takes out egress for the whole VPC. The other is far more expensive and far more common: traffic to S3 or DynamoDB routed out through the NAT gateway, byte by byte, when a gateway VPC endpoint would have kept it inside the AWS network entirely. A team can pay for that mistake for a year without noticing, because the line item on the bill says NAT rather than S3.
Interface endpoints, the PrivateLink kind, work differently. They put a network interface in your subnet for a given service, they bill by the hour per zone plus data, and they are worth it once your traffic to that service is heavy enough or once your security position requires that nothing traverses the public internet. Judgement about when to use which is exactly the kind of thing a shallow candidate has no view on.
Security groups and NACLs are not two ways of doing the same thing
A security group is stateful and allow only. Permit inbound traffic and the reply is permitted automatically, and there is no way to express a deny. A network ACL is stateless and evaluated in numbered order with both allows and denies, which means return traffic needs its own explicit rule, and because that return traffic arrives on a high numbered ephemeral port, the rule has to cover a range that looks alarming to anyone seeing it for the first time.
Ask a candidate why an outbound connection that worked with security groups alone broke after somebody tightened the network ACL. If they get to ephemeral ports without help, they have debugged this in production. It is a small question with a very high signal to noise ratio.
While you are there, ask how they would allow a web tier to reach a database tier. The weaker answer gives the database security group a CIDR range. The better one references the web tier security group as the source, so the permission follows the instances rather than the addresses and stays correct when the addresses change, which they do constantly under any kind of autoscaling.
Load balancers, and the question about the client address
An application load balancer terminates HTTP, routes by host and path, and forwards the original client address in a header rather than in the packet, because as far as the target is concerned the connection came from the load balancer. A network load balancer works at the connection level, can preserve the source address, and is what you reach for when you need static addresses or a protocol that is not HTTP.
The reason this appears in a hiring page rather than a manual is that it produces a specific and very common bug. Rate limiting or geo blocking implemented against the connection source will happily block everyone or nobody, because every connection appears to come from the load balancer. Ask what they would check first if a rate limiter started rejecting all traffic after a migration behind a new load balancer, and see whether the forwarded header appears in the answer.
EC2, ECS, EKS, Fargate and Lambda: Where Each One Is Wrong
Anybody can list what each of these is. The useful interview question is the inverse: name a situation where this is the wrong choice. Only people who have lived with the consequences can answer it.
Lambda, and the ceiling nobody plans for
Wrong when the work runs long, because functions have a hard maximum duration and a job that grows past it fails rather than slowing down. Wrong when traffic is high and perfectly steady, since the per invocation model stops being cheap somewhere and a container that is always warm wins. Wrong when the thing on the other side is a traditional relational database, because a thousand concurrent functions means a thousand attempts at a connection and Postgres will refuse most of them. That last one is why RDS Proxy exists, and a candidate who reaches for it unprompted has hit the wall themselves.
Fargate, and paying for convenience
Wrong when you need a GPU, a specific instance family, or anything privileged, because you do not get the host. Wrong at high density, since you are billed for the resources you request per task rather than for a machine you fill up, and a hundred small tasks on Fargate can cost noticeably more than the same hundred packed onto instances you manage. Right, and genuinely right, when your team is small and the thing you are short of is operational attention rather than money.
EKS, and the surface it commits you to
Wrong when you have four services and one engineer. The control plane charge is the least of it. What you are signing up for is a version upgrade cadence measured in months rather than years, add ons that must stay compatible with each other, a networking plugin that consumes real VPC addresses, and a body of Kubernetes knowledge that has to exist somewhere in the building permanently. Right when you already have that knowledge, or when you need the ecosystem badly enough to fund it. If that is the direction you are heading, the hire Kubernetes developers in India page goes into what that role has to cover.
ECS, and the case for the boring option
Wrong when you genuinely need the Kubernetes ecosystem, or when portability between clouds is a real requirement rather than a slide. It is right far more often than its reputation suggests. Task roles map to IAM without an identity bridge, the scheduler is simple enough to reason about, and there is no upgrade treadmill. Many teams running EKS would have been happier here and chose otherwise for reasons that were about hiring rather than architecture.
Plain EC2, and the orchestrator you did not mean to write
Wrong the moment you find yourself writing user data scripts that pull an artefact, restart a service, and register with a load balancer, with a cron job checking whether it worked. That is an orchestrator, you are now maintaining it, and it has no tests. Right for workloads that genuinely want a machine: something licensed per host, something with an unusual kernel requirement, something stateful that was never designed to be scheduled.
Spot capacity, and where it stops being free money
Wrong for anything holding state that cannot be rebuilt, and wrong for anything that cannot act on a short interruption warning before the capacity is taken back. Right for batch, for CI runners, for stateless web tiers with enough spread across instance types. The question to ask is what their interruption handler actually did, because most people who claim spot experience have enabled it and never written one.
One more worth raising in an interview: moving workloads to Graviton, which is the AWS arm64 processor family. The performance per unit of cost is usually favourable, and the migration is genuinely mundane for anything running on an interpreted or JVM stack. What makes it interesting as a question is the second order effects, since your container images now need to be multi architecture, your CI has to build for both, and any dependency with a compiled native extension needs checking. A candidate who has actually done this describes the CI work first. A candidate who has read about it describes the price difference first.
Data: RDS, Aurora, and the DynamoDB Decision People Get Wrong
Compute choices are reversible in a quarter. Data choices are reversible in a year, if you are lucky and somebody wrote the migration down.
RDS or Aurora, and what you are paying the difference for
RDS runs a conventional database engine on an instance with attached storage, and it behaves the way that database behaves everywhere else. Aurora keeps the engine interface but replaces the storage layer with a distributed one shared across availability zones, which changes the operational characteristics rather than the query language. Replicas come up faster because they attach to the same storage instead of copying it. Failover is quicker. Storage grows without you managing it.
What people miss is that the billing model is different too, not just larger. Aurora has historically charged for input and output operations against that storage layer in its standard configuration, with an alternative configuration that folds those into a higher instance price instead. Which of the two is cheaper depends entirely on how input and output heavy your workload is, and the pricing details change often enough that anybody quoting you firm numbers from memory should be checked against current documentation. The point for hiring is narrower: a candidate who thinks Aurora is simply the better version of RDS has never received a surprising invoice for it.
Where DynamoDB gets chosen wrongly
DynamoDB is excellent and it is chosen for the wrong reasons more often than any other AWS data service. The wrong reason is nearly always that it scales, offered by a team whose workload will comfortably fit on a modest relational instance for the next five years and whose actual constraint is that their access patterns are still changing every fortnight.
That is the trade DynamoDB asks you to make. You commit to knowing your queries before you design your keys, because the key design is the query plan and there is no optimiser waiting to rescue you later. A new access pattern means a new index or a new table, not a new WHERE clause. For a team that knows exactly what it is building, that constraint delivers latency that is genuinely flat under load. For a team still discovering the product, it is a tax paid weekly.
The diagnostic in an existing system is scans. If production code is scanning a DynamoDB table, the key design does not match the questions being asked of it, and no amount of provisioned capacity fixes that. Ask a candidate what they would do about a scan they found in a hot path and listen for whether they talk about adding a global secondary index with the right partition key, or whether they talk about raising throughput.
The DynamoDB details that only show up in production
Partition keys with poor distribution create hot partitions, and while the service does adapt to uneven traffic to a degree, a single genuinely hot key will still throttle. Anybody who has run a system with a tenant identifier as the partition key knows this, because one large tenant is all it takes.
Global secondary indexes have their own capacity, separate from the base table, and this catches people badly. If an index cannot keep up with writes, the pressure travels backwards and your writes to the base table start failing, which is a failure mode that makes no sense until you know the mechanism. Ask about it. It is a precise question with a precise answer and no way to bluff it.
The read replica misunderstanding
Read replicas are reached for whenever a database is under strain, and roughly half the time the strain is on writes, in which case replicas add cost and change nothing. They also come with replication lag, which means an application reading its own recent write from a replica will sometimes not find it, and that bug appears at random and is miserable to reproduce. Then there are connection limits, which scale with instance size and are frequently the real ceiling rather than CPU.
The question that separates seniority here is simple. Ask what they would measure before adding a replica. You want to hear a split between read and write load, a look at what the slow queries actually are, and an acknowledgement that a missing index has been the answer more often than an extra instance.
On AWS, Cost Is an Engineering Discipline
This is the section that makes AWS hiring different from hiring for any other infrastructure role. Your architecture is your invoice. Nobody in finance can fix a bill that was decided in a network diagram.
The bill nobody reads
Most organisations look at one number every month and react to it emotionally. That number is useless, because it hides the only thing that matters, which is which usage type changed and on which day. Grouping by service tells you a little. Grouping by usage type tells you the mechanism, because usage types are named after what actually happened: bytes moved between availability zones, bytes processed by a NAT gateway, storage held per byte hour, requests of a particular class.
Underneath that sits the cost and usage report, which is the full record at hourly granularity. It is the tool for the question that matters during an investigation: not what did we spend last month, but at what hour did this line start, and what did we deploy that hour. Ask a candidate how they would find the exact hour a cost increase began. If the answer stops at the graphical cost explorer, they have never had to do it under pressure.
Where the money actually leaks
Waste on AWS is boring and repetitive, which is why it survives. Volumes detached from terminated instances continue to bill. Snapshots accumulate for years because nothing expires them. Load balancers stay up in front of environments that were decommissioned. Elastic IP addresses that are not attached to anything are charged specifically because they are not attached. Provisioned throughput left on after a load test never gets turned down.
Two are worth calling out because they are close to invisible. Incomplete multipart uploads sit in S3 as storage you are paying for and cannot see in an ordinary object listing, and they only go away if a lifecycle rule removes them. And log retention: log groups are created without an expiry unless somebody sets one, so a service that has been chatty for three years is holding three years of logs nobody will ever read. Both of those are single configuration changes and both of them are found only by looking.
The expensive decisions are architectural
The leaks above are worth finding and they are not where the money is. The money is in traffic that crosses an availability zone because a service and its database ended up in different ones, in data leaving the region when a cache in front of it would have served it, in log ingestion set to debug level and forgotten, in high cardinality custom metrics where somebody put a request identifier in a dimension, and in traffic to S3 taking the paid route out through a NAT gateway rather than the free one through a gateway endpoint.
Every one of those was decided by an engineer, usually without realising a cost decision was being made. That is the whole argument for cost being an engineering discipline rather than a reporting function. The person who can reduce your bill is the person who designs the traffic path, and they need to be told that this is part of their job, because most engineers have never been shown the invoice their work produces.
Commitments are a commercial instrument, not a fix
Savings plans and reserved capacity reduce the rate you pay in exchange for committing to a term. They are useful and they are also the most common way a team locks in its own waste, because committing to a year of an instance size you have not yet right sized means paying a discounted price for something you did not need.
The order is right sizing first, then commitment, and it is worth asking a candidate which comes first just to hear whether they have an opinion. While you are on the subject, ask what guard rails they would put in place so the next surprise is caught in days rather than at the end of the month. Budgets with alerts, anomaly detection on services rather than only on the total, and a tagging policy enforced at creation time rather than audited afterwards. The tagging point is the one people underrate: an account where a third of the spend is untagged cannot answer the question of which team or product caused an increase, and no tool fixes that retrospectively.
Infrastructure as Code, and What Terraform on a CV Hides
Everybody writes Terraform on a CV now. The interesting questions are not about the language, they are about state, blast radius and what happens on the day someone changes something in the console.
State is the part that goes wrong
Terraform keeps a record of what it believes exists, and every serious problem you will have with it is a disagreement between that record and reality. So the first question is where the state lives and what stops two people applying at once. A remote backend in S3 with locking is the ordinary answer, historically implemented with a DynamoDB table for the lock, though the backend has gained other locking options since and it is worth checking the current provider documentation rather than repeating what was true two years ago.
The better question is how the state is divided. A single state file describing an entire account means every apply touches everything, one careless change can propose destroying a database, and a corrupted file is a very bad afternoon. Splitting by lifecycle instead, so that networking, data and application layers each have their own state and the ones that rarely change sit apart from the ones that change hourly, is what someone who has been burned does. Ask a candidate how they would organise it and whether they have ever had to recover a state file. The recovery story is the one worth listening to.
CloudFormation, CDK and the inheritance nobody mentions
CDK is popular because it lets people write infrastructure in a language they already know, and the part that gets skipped in the pitch is that it compiles down to CloudFormation and inherits everything CloudFormation does. That includes stacks that get stuck in a failed rollback state and need manual intervention, and property changes that quietly replace a resource rather than updating it, which is fine for a security group and catastrophic for a database.
None of that makes CDK the wrong choice. Type checking and real abstractions are genuinely valuable, and staying inside one vendor's tooling has its own advantages. But a candidate who describes CDK purely as a nicer way to write infrastructure, with no mention of what happens underneath, has not yet had a stack fail on them. Our infrastructure as code services in India page covers how we approach this when the job is bringing an existing account under version control rather than starting clean.
The console access question
Every organisation has to decide what happens when production and the code disagree. The strict position is that production write access through the console does not exist, and everything goes through a pipeline. The pragmatic position is that during an incident somebody will need to act faster than a pull request allows, so you build a break glass path that is logged loudly and reviewed afterwards.
Both positions are defensible. What is not defensible is having no position, which is what most accounts have, and which produces infrastructure code that has been slowly diverging from reality for two years until nobody trusts a plan output any more. Ask a candidate what their last team's rule was, and how it was enforced rather than merely stated. Enforcement is the interesting half of the answer.
Can They Answer Why It Was Slow at 14:20 Yesterday?
That single question tests observability better than any list of tools, because answering it requires the instrumentation to have already existed. You cannot go back and add it.
What CloudWatch gives you for free, and what it does not
The metrics AWS collects for an EC2 instance are collected from outside the instance, which means they cover CPU, network and disk activity at the hypervisor level and stop there. Memory usage is not among them. Neither is disk space consumed inside the filesystem. Both require an agent running on the instance and reporting them as custom metrics, and the number of production estates that have been running for years without memory metrics because nobody realised is remarkable.
Ask a candidate directly whether memory shows up by default. It is a small question and it is a reliable one, because anybody who has had to diagnose an out of memory condition on AWS knows the answer with feeling.
Logs that can be queried rather than read
Structured logging is the difference between an investigation that takes ten minutes and one that takes a day. If your application emits JSON with a request identifier, a route and a duration on every line, then CloudWatch Logs Insights can answer questions about distributions. If it emits sentences, you are reduced to grep and guessing.
The same reasoning applies to load balancer access logs, which are off until somebody turns them on, and which land in S3 where Athena can query them directly. That combination answers the 14:20 question for the HTTP layer without any application changes at all, and it is the first thing to enable on an account that has none of this. Cheap, retrospective, and routinely absent.
Traces, and being honest about what they cost to adopt
Distributed tracing, whether through X-Ray or an OpenTelemetry setup, is the only thing that answers where the time went in a request that crossed six services. It is also work: instrumentation in every service, context propagated across every boundary including queues, and sampling decisions that trade completeness against cost.
A candidate who recommends tracing for a three service system without acknowledging that cost is selling you something. A candidate who says start with structured logs and a request identifier threaded through everything, then add tracing when the number of hops makes it necessary, has actually made this decision before.
CloudTrail is the record you need after the fact
Everything above is about performance. CloudTrail answers a different question, which is who did what, and it becomes urgent precisely when nobody has time to configure it. Management events, the API calls that change your infrastructure, are recorded by default and retained for a limited window in the console view unless a trail is configured to keep them properly.
Data events are different and they are the ones that matter in an exposure. Object level activity in S3 is not recorded unless you switch it on, so if a bucket was public for three weeks and you have no data events, you cannot tell anybody which objects were read. You can only tell them which objects were exposed, which is a much worse conversation to have with a customer. That distinction is worth testing, because the people who know it are usually the people who have been through an incident review.
How Do You Screen an AWS Engineer in One Hour?
Describe something broken and make them debug it out loud. Give them less information than they need on purpose, because what you are measuring is how they narrow the possibilities, not whether they reach the answer you had in mind.
A Lambda function that times out, but only in production
The weak answer raises the timeout. The next weakest blames cold starts, which is worth probing, because a cold start adds latency measured in fractions of a second and a timeout is usually seconds or tens of seconds away from that.
What you want is somebody who asks what is different about production before proposing anything. The frequent answer is that the production function is attached to a VPC and staging is not, so a call to an AWS API has no route out, no NAT and no interface endpoint, and instead of failing it hangs until the function is killed. Same shape with a security group that has no egress rule. Then the data explanations: a query that scans a table that is a hundred times larger in production, or connection exhaustion when concurrency rises and every invocation wants its own database connection.
The detail that marks out real experience is the observation that a timeout producing no error in the log is almost always a network path that never returns, and the fix for the diagnosis is to set the SDK socket and connection timeouts lower than the function timeout so that you get a real error with a stack trace instead of a silent kill. Anyone who volunteers that has debugged this at least twice.
An ECS task that will not start
First listen for where they look. Service events and stopped task reasons tell different stories, and someone who has run ECS goes to the stopped reason on the task rather than the service event list, because that is where the useful sentence usually is.
Then the causes. The execution role cannot authenticate to the registry or has no permission to pull. The task is in a private subnet with no route to the registry, which is the NAT and endpoint question again in a new costume. The image exists but was built for a different processor architecture. The secret referenced in the task definition points at a parameter the execution role cannot read. The container starts, fails its health check, gets killed, and the loop repeats fast enough that you never see a running task.
The single best signal in this whole exercise is whether they distinguish the execution role from the task role without being asked. The execution role is what the ECS agent uses to pull the image and write logs before your code exists. The task role is what your code uses once it is running. Confusing them produces a container that cannot start and a permission error that points at the wrong place, and everyone who has run ECS in production has lost an hour to it.
An RDS instance at 100 per cent CPU immediately after a deploy
The weak answer scales the instance. It even works, temporarily, which is what makes it seductive. The strong answer treats the deploy as the prime suspect and asks what shipped.
Listen for the mechanics: Performance Insights or the equivalent statistics extension to find the queries consuming the most total time rather than the most calls, a look at whether the load is CPU or waiting on storage, and a check on whether a new query is missing an index or an ORM change has turned one query into several hundred. Migrations deserve a mention too, since a large table change can leave statistics stale enough that the planner picks a sequential scan over an index that exists and is perfectly good.
The sentence you are hoping to hear is that scaling up buys time to find the cause and is not itself the cause. Follow up by asking what they would do if the deploy could not be rolled back, and see whether they reach for a targeted index created concurrently rather than a maintenance window nobody agreed to.
An S3 bucket that is public and should not be
This one tests composure as much as knowledge. There are several independent ways a bucket becomes readable: the bucket policy with a wildcard principal, access control lists on the bucket, access control lists on individual objects, and a distribution or presigned URL arrangement that was more generous than intended. A candidate who names more than one of those has thought about it before today.
The order of operations is what you are really assessing. Stop the exposure first, using the public access block settings at the bucket and at the account level, because account level is the one that cannot be undone by somebody else's policy. Then establish what was actually reachable and for how long. Then the hard question, which is whether anything sensitive was in there and needs rotating, and whether object level logging was enabled, because if it was not, you cannot say what was read and that is what you will have to tell people.
Finish by asking how they would stop it happening again. A one off policy change is not an answer. A control at the organisation level that prevents the setting from being changed in any account is.
A bill that doubled with no change in traffic
This is the question that most cleanly separates people who have owned an AWS account from people who have worked inside one. The instinct you want is to find the hour, not the month.
Good answers go to the cost and usage report at hourly granularity, group by usage type rather than by service, and compare day against day to find the step change. Then the usage type name gives away the mechanism. Regional data transfer means something started talking across availability zones, which normally means a deployment landed a service in a different zone from its database. NAT gateway bytes means traffic that used to take a free path is now taking a paid one. Storage byte hours climbing steadily means something is writing and nothing is deleting.
The common causes are dull and worth naming: a log level left at debug after an investigation, a retry loop hammering a downstream service and multiplying request charges, a lifecycle rule removed during a migration, a metric with an unbounded dimension, a pipeline reprocessing history. What matters in the answer is the sequence. Find the hour, name the usage type, correlate to a change, then fix. Anyone who begins by proposing reserved instances has misunderstood the question entirely.
What you are listening for across all five
Not correctness. Structure. Do they ask what changed before they theorise? Do they separate what they know from what they are assuming, out loud, without being prompted? Do they say at what point they would stop investigating and roll back? Are they willing to say they have never met this particular failure, and then name the first three places they would go and look?
Somebody who delivers five polished answers with no rough edges anywhere has generally read about these failures rather than sat through them. Operational memory is lumpy. People are vivid about the two that cost them a weekend and hazy about the rest, and that unevenness is a better signal than fluency.
Seniority, and What Each Level Can Safely Be Handed
Titles travel badly between companies. What follows is what each level can be trusted with on an AWS account specifically, which is a more useful thing to match against your brief.
Early career
Builds inside boundaries somebody else set. Can add a service to an existing pattern, write the Terraform for it by following the module next to it, and read the logs when it misbehaves. Should be working in a sandbox account with a spending limit, and every change to anything shared should go through review. Genuinely useful, and cheap to be wrong about, provided the account already has shape.
Mid level
Owns a service end to end within an established account: its permissions, its network placement, its alarms, its data store, its cost. Can debug across boundaries and will find the answer to most of the five scenarios above given time. Should not be the person choosing your VPC address range or your multi account structure, because those mistakes outlast the person who makes them.
Senior
Can be handed the account. Designs the network, sets the identity model, decides the compute and data choices and defends them, and treats the bill as something they own rather than something that arrives. Says no to services. Most teams need exactly this and write a job description for the tier below it, asking for four years of experience against a list of responsibilities that only a senior can carry.
Staff and above
Works above the account. Multi account structure under Organizations, the guard rails that stop other teams doing damage, the shared services that everyone consumes, and the standards that make twelve teams produce something recognisably similar. Needed when the problem is that your organisation has too many accounts and no agreement, not when you need somebody to build a platform.
One caution about years. AWS experience compounds unevenly, and five years spent inside one well governed account can teach less than two years spent building three accounts from nothing and getting two of them wrong. Ask what they built from scratch and what they inherited, because the two produce different engineers, and which one you want depends entirely on which situation you are in.
Four Patterns That Bring Teams to Us
These are recurring shapes rather than named engagements. If one of them describes your situation closely, the useful part is what it implies about who to hire.
The bill that outgrew the company
Growth arrived, the invoice grew faster than usage, and the engineer who built the account left eighteen months ago. Nobody knows what half the resources are for and nobody is willing to delete anything in case it matters. The reflex is to hire someone to cut costs. The better first move is a short investigation, because the answer is usually two or three architectural decisions rather than a hundred small wastes, and knowing which it is changes whether you need a project or a person.
Serverless that grew past the point of comprehension
Everything is a Lambda function. There are a hundred and forty of them, they are wired together through queues and events, no developer can run the system on their laptop, and tracing a single user action through it requires opening six log groups and correlating by timestamp. Nothing here is technically wrong. It is an architecture that traded local comprehensibility for operational simplicity and then never paid for the observability that trade requires. The hire needs to be someone who will consolidate rather than someone who will add.
The migration that stopped halfway
Part of the estate moved, part did not, and the two halves now talk over a tunnel that was meant to be temporary. Every performance problem is a mystery because the request crosses the boundary twice. The person who understood the plan has moved on and the remaining team is reluctant to touch either side. This one needs someone comfortable with both worlds and, more importantly, someone willing to say plainly that the halfway state is the problem and finishing is cheaper than living with it.
One person who knows everything
The account works. One engineer built it, understands it, and cannot take a holiday without something waiting for them. The documentation is a handful of pages that were accurate in a previous year. The risk here is not technical, it is that the entire recovery plan for your infrastructure is a person, and people leave. The right hire is a second pair of hands who starts by writing down what the first one knows, which is a specific temperament and worth screening for directly.
Timezones, Credentials and the Written Trail
Do the clock maths first, because it decides more about whether this works than anything on the CV.
The overlap, calculated rather than asserted
The offset is five and a half hours ahead of UTC, and India does not move its clocks in either direction, so the conversion behaves identically in every month of the year. Take a normal Indian workday of 09:30 to 18:30. Convert it and you land on 04:00 to 13:00 UTC, unchanged whether the month is January or July.
Lay that over a nine to five day in each buying market. British teams see the Indian day as 04:00 to 13:00 through the winter, which leaves four working hours together, from the moment they arrive until the Indian evening. Through British Summer Time the window widens to five. In Sydney the Indian day appears as 14:00 to 23:00, so roughly three hours are shared and every one of them falls after lunch, and two once Australian clocks move forward. Auckland is left with about an hour, right as its own day is closing.
North America is the row that matters and the row most proposals gloss. Eastern Standard Time renders the Indian day as 23:00 the previous night through 08:00, which finishes an hour before anyone in New York has arrived. Under Eastern Daylight Time it finishes at 09:00, the precise minute your day opens, which nobody should count as collaboration. California is further adrift still. Any supplier claiming a meaningful window here has either quietly moved somebody's hours or is counting the boundary minute.
Covering the United States therefore means an Indian day that begins after lunch and finishes late at night, permanently, for a person with a family and a commute. It holds up when it is negotiated during hiring and reflected in what the role pays. It falls apart when it is sprung on somebody in their second month, and the way it falls apart is resignation rather than complaint.
Why thin overlap costs this role less than most
Now the encouraging half, and it applies to infrastructure specifically rather than to offshore work generally. Enormous parts of the AWS job need nobody else awake. Pulling apart a cost and usage report. Drafting a migration runbook. Writing a Terraform module. Reviewing forty policy documents. Working backwards from a spike to whatever deployment caused it. All of that wants a precise question at the start and a written conclusion at the end, and neither of those is a meeting.
Contrast that with a role whose day is mostly answering colleagues, where a four hour window is genuinely limiting. There is some of that here, mainly access requests, but proportionally much less. The consequence for you is practical rather than philosophical: put the effort into writing the brief properly and the offset barely registers. Expect to resolve ambiguity in a call and it will grate every week.
The one place the offset pays you back
Disruptive maintenance. Database engine upgrades, failover drills, certificate rotations, DNS cutovers, anything you would rather not attempt while customers are awake. In London or Chicago those jobs land on somebody's Saturday. Viewed from India, a window that reads as late evening in New York is a mid morning slot: your engineer is rested, sitting at a desk, with a colleague two seats away to argue with before touching production, instead of alone in a dark kitchen at two in the morning.
That advantage is real and it is one of the few genuinely honest arguments for this arrangement in infrastructure work. It is also not the same as continuous cover. Doing one window well says nothing about the other three, and covering every hour means paying more people to be awake, which is a decision you make on purpose and put in a budget. Wanting it is entirely reasonable. Being told the geography provides it for nothing is not.
Credentials: what never leaves your side of the fence
On AWS this has a precise answer. Root stays with you, guarded by a hardware key that a named person in your organisation physically holds, and so does the Organizations management account and the payment relationship. Your engineer receives a named identity through IAM Identity Center, with a permission set that reaches only the accounts the work touches. Not an IAM user. Not a long lived key pasted into a chat window.
Six things belong in writing with us before a start date, and none of them are exotic: which accounts are in scope and by what route they are reached, whether raised permissions are standing or requested per piece of work, where the audit trail is delivered and which person reads it, any requirement you have about devices or source addresses, what happens when something breaks outside the agreed window, and the exact revocation checklist for the final day. Settling all six in an hour up front spares you a much worse conversation during an incident.
The written trail between two working days
With four hours of contact or fewer, the note somebody leaves behind is the working relationship. A useful one records what moved, what stalled, who is blocking whom, and the thing the writer would be nervous about if they were the one arriving cold tomorrow. Without it you get the identical fault investigated twice, on two continents, by two engineers who never exchanged a sentence, and that is a worse outcome than not having a distributed team in the first place. Fix the format in the opening week, put it somewhere both sides read without being asked, and treat a missing note as a bug to be raised rather than a quirk to be tolerated.
What If the Person Is Not Right?
Nobody signs anything without asking this, and it deserves two answers rather than one: what we do about it, and what you should have built so that it barely registers.
What happens on our end
A replacement reaches you within 48 hours. You also pick from a shortlist rather than being handed one name and invited to approve it, which matters more than the phrase suggests. Most poor matches are not about ability at all. They are about temperament against the shape of the work, and somebody outstanding at standing up a fresh account can be thoroughly unhappy babysitting a six year old one. Given two or three conversations instead of one, that mismatch is usually visible before anybody starts.
What happens on yours, which counts for more
A change of engineer turns into an outage for exactly one reason: the account lived in a single skull. Three habits prevent it, and they are worth adopting whoever you hire and whatever happens.
Begin read only. The opening week is exploration, ending in a written account of what is actually deployed, what caused a raised eyebrow, and which parts look hazardous. You go through that document together before a single write permission is issued. It stays valuable for years, and it doubles as the fastest honest verdict you will get on the appointment itself.
Refuse any environment whose rebuild depends on a person. When you ask how this gets recreated and the answer is a name, that is the defect. It gets closed by moving configuration into a repository, not by commissioning more documentation that nobody updates.
Define the exit at the beginning. Where runbooks are kept, what the documentation bar is, and which conditions have to be satisfied before an engagement can close cleanly. The specific notice and handover arrangements themselves live in the agreement we sign with you before work begins, not in a sentence on a marketing page.
The questions that always arrive alongside it
Ownership: what gets built belongs to you, and the assignment, the confidentiality position and the handling of any personal data are all recorded before the first commit lands. Where a regulation is in play, GDPR being the common one for European buyers, take that to your own lawyers instead of accepting an engineering supplier's reading of it. Our part is putting the terms down clearly at the outset so nothing rests on assumption.
Judging quality remotely: stop relying on status updates and make the work itself inspectable. Infrastructure arrives as a pull request with a plan attached and gets read by someone of yours before it applies. Production changes through the console are either blocked outright or logged noisily. The audit trail lands where your team can query it. Once every change carries an author, an approver and a stated expectation, the distance stops being the thing keeping you awake.
Language and communication: a pleasant introductory chat proves nothing, since every candidate clears that bar. Hand them a scenario with consequences attached and ask them to brief a non technical colleague on it. Ask for the written change record on a risky release, then read it as the person who has to approve the release. Precision on the page beats fluency in conversation here, because with a short overlap the document is the relationship.
Costs you have not budgeted: ramp up and supervision, both underestimated. An undocumented AWS account is slow to absorb, since the knowledge is scattered across policy documents, route tables, exceptions granted years ago and the reasoning nobody wrote down, and your existing engineers will lose hours explaining it. Someone of yours also has to answer questions and own the relationship. Count those hours honestly rather than assuming the arrangement steers itself.
Do You Actually Need a Hire, or a Project?
This page has spent several thousand words arguing for putting somebody in the seat, so here is the counterweight. One test decides it: does the work run out?
Some of it does. Laying out an account hierarchy, standing up guard rails, dragging an existing estate into version control, executing a migration, tracking down why the invoice jumped. Each of those has a last day. Recruit a permanent engineer for eleven weeks of work and at the end you own an engineer, a finished piece of work and nothing obvious to point them at next, which usually resolves itself as boredom followed by a resignation. What has no last day is custody: the upgrade calendar, the steady drip of permission requests, the cost review nobody volunteers for, the question that arrives from a team you have never met. That is what a standing role is for.
Embedded engineer
Sits on your board, joins your ceremonies, submits to your change process and is reviewed by your engineers. Fits when the work never stops and the account rewards somebody who builds up context month after month instead of dropping in, delivering and departing.
Project with a last day
A hierarchy to lay out, a network to redraw, a migration to finish, an estate to bring under code. Named outcome, agreed acceptance, and a handover to whoever inherits it. Our cloud architecture services in India page covers work of that shape.
Senior time on retainer
Some hours each week of experienced attention: reading a design before anybody builds it, checking whether the permission model has quietly drifted, going through the cost report, and being reachable when something unrecognisable turns up. Fits teams with good engineers and nobody carrying AWS scar tissue.
Doing the project before opening the vacancy tends to beat the other order, because afterwards your advert can point at a real account with real conventions rather than describing an aspiration. And if the thing that genuinely hurts is that shipping is slow, manual and nerve wracking rather than anything about AWS itself, the hire DevOps developers in India page explains where that role diverges from this one. Adverts blur the two relentlessly, and picking the wrong half of the pair costs you a quarter.
What Happens After You Send Us a Brief
Because engineers are already on the bench, no recruitment cycle has to begin when your brief lands. That is what makes 48-hour developer matching a description of the process rather than a slogan, and why a start 7 days out is a date you can plan against. These four steps occupy the space between.
Tell us about the account, not the vacancy
How many AWS accounts there are, whether Organizations is in play, what runs where, where the data sits, what the monthly invoice does, and which part of it currently stings. Twenty minutes of that moves the shortlist further than any other input, because this role changes character completely depending on how much structure already exists.
Fix the schedule and the access boundary early
Which hours are shared, whether out of hours maintenance is part of the job, which accounts are reachable, and who signs off what. Nailing this before any name is put forward means every candidate has been measured against a schedule and a scope they have knowingly agreed to.
Interview them yourself, on broken systems
Use the five failures from the screening section, or better, bring something that genuinely went wrong in your own account last quarter and watch them work it through live. You verify depth. Take nobody else's assessment as a substitute for your own, including ours.
Read only first, write access second
The opening week produces a written map of the account: what exists, what is surprising, what is risky. Write permissions arrive after you have discussed that document, not before it. One week spent this way tells you more about the appointment than a month of daily calls.
Frequently Asked Questions About Hiring AWS Developers in India
What does an AWS developer do that a backend developer cannot?
A backend developer owns what happens inside the process. An AWS engineer owns everything around it: which subnet it runs in, what identity it assumes, how traffic reaches it, where the data lives, what happens when the availability zone it sits in goes away, and what all of that costs per month. The overlap is real, but the failure modes are different and so is the debugging.
How do I tell a real AWS engineer from someone who has used twelve services once?
Ask for the one service they operated for longer than a year, then ask what went wrong with it. Real operating experience produces a specific complaint and a workaround. Ask which AWS service they would refuse to use again. Ask them to draw the path a request takes from a browser to the database and name every hop on the way. Console familiarity collapses under that question.
Does an AWS certification tell me anything useful?
It tells you what vocabulary the candidate arrives with, which is worth something and is not the same thing as capability. The associate level exams cover a syllabus wide enough to touch services the person has never run in anger. Read the certificate as a reading list the person has worked through, then use the interview itself to make them take a broken system apart in front of you. Exam codes get retired and replaced, so check the current ones if you intend to require any.
How much overlap do we get with an AWS engineer working from India?
An Indian workday of 09:30 to 18:30 lands on 04:00 to 13:00 UTC, identically in January and July, because the country holds a fixed offset of five and a half hours. Against that, London retains four working hours in winter and five in summer, Sydney two or three at the tail of its afternoon, and both American coasts retain nothing whatsoever. Covering North America therefore requires shifting the Indian day on purpose and saying so during hiring.
What happens if the engineer we pick turns out to be wrong for the role?
You get a replacement within 48 hours, and you shortlist from a pool rather than being handed a single name to accept or refuse. The engineering side of the answer matters just as much. Keep the first week read only, insist that the account is described in a repository instead of in one person's head, and a change of engineer becomes an inconvenience rather than an outage.
Should an external engineer have access to our root account and billing?
No. Root credentials, the Organizations management account and the payment relationship stay with you, protected by a hardware key somebody in your building physically holds. What the engineer gets instead is a named identity issued through IAM Identity Center, carrying a permission set that reaches only the accounts the work touches, never a standing access key. Deliver CloudTrail into an account outside their reach, and write down the offboarding sequence before day one.
Our bill doubled and nobody knows why. Is that a hire or a project?
Usually a project first. Finding the cause is a few days of work with the cost and usage report at hourly granularity, and the answer is normally one architectural decision rather than a hundred small wastes. Hiring makes sense once you know whether the fix is a fortnight of changes or a permanent owner for something that will drift again the moment nobody is watching.
AWS engineer, DevOps engineer or platform engineer: which do we actually need?
If the pain is the cloud account itself, the network, identity, the data services and the bill, you want the AWS specialist described on this page. If the pain is that releases are slow, manual and frightening, that is a delivery problem and the DevOps role fits it better. Platform engineering is the third case, where the job is building something your own developers consume rather than operating the infrastructure directly.