What AWS skills does a forward deployed engineer need in 2026?

Forward deployed engineers need IAM, networking and account structure on day one. Engagements teach most of the rest. Learn GPU work in your own account.
Brooke Jamieson

Published Oct 29, 2026
Last modified Oct 29, 2026
Last updated: 29 October 2026
Whenever someone asked me how to learn MLOps, I gave them the same answer: go and work in consulting.
At the time I was in leadership at an AI and machine learning consultancy, doing a lot of MLOps (DevOps for machine learning), so I know how that sounds.
I meant it, though. In consulting you get dropped into someone else's account every few weeks and have to work out what they're doing and how it works. You don't choose the architecture, and you can't settle into the one stack you set up yourself and know by heart.
If someone has something easy to build, they probably don't need to pay a consultant. People pay specialists when they're in a mess they can't get out of themselves: the team isn't structured for it, the politics won't let it happen, or they're trying to modernise the old system while building something new on top of it.
A certification teaches you the standard practices, and these aren't standard problems. The mess is why they needed your help, and it's also what teaches you. After a few of them you're more resilient, and well rounded in a way that building the same system for years doesn't make you.
A forward deployed engineer (FDE) does the same thing under a different job title: you're sent to work inside a customer's systems, which someone else designed, and you're expected to ship something real in them. You're usually there because something is stopping their own team from shipping it. You can treat that as a job. I think it's more useful to treat it as a way to learn, a bit like a master's in shipping software, where every engagement is a new case study and someone pays you to work through it.
These days you don't arrive alone. Most of us bring a coding agent that works faster than we do and will call any AWS API we point it at, which makes each new account quicker to find your way around. What it doesn't know is what's safe to change in an account it has never seen, and if you let it do all the exploring, you don't learn the account yourself.
So for an FDE whose customers run on AWS, the useful questions are what you need to know on day one, what the engagements will teach you, and what you shouldn't be learning on a customer's bill.
What AWS knowledge does a forward deployed engineer need?
Why is IAM the most important AWS skill for an FDE?
Can I give my coding agent less AWS access than I have?
How do you debug networking in a customer's AWS account?
How do you find your way around an unfamiliar AWS environment?
Which AWS services should an FDE know well, and which can wait?
How do you secure an AI agent's access to a customer's AWS account?
﻿
What AWS knowledge does a forward deployed engineer need?An FDE needs a wide base of identity, networking and account-structure knowledge, a working map of the common application services, and permission to stay shallow on specialised services until an engagement needs them.
I draw it as a food pyramid, with one change to how you read it: the width of a layer is how often an FDE needs that knowledge across customer environments, and its height is how situational the knowledge gets.  IAM  sits at the bottom because almost every engagement touches it (not because it's easy, which it isn't), while something like  HyperPod  is up near the top, hard but rarely needed. So the bottom is what you need on day one, and the middle layers are what the engagements teach you. The top works differently, because rarely needed doesn't mean safe to learn on the job. That's where a mistake costs the most, like a GPU cluster left running over a weekend or a Kubernetes networking change that takes a customer's services offline. When an engagement needs something from up there, learn it in your own account before you touch theirs, or bring in someone who already knows it.
﻿
From the bottom up:
Table stakes: accounts, IAM,  STS ,  VPCs  and routing, Regions and Availability Zones, the  AWS CLI , logs,  secrets , enough infrastructure as code to read it
Application substrate: compute, databases, queues, storage, APIs and  DNS 
Production engineering: reliability, observability, deployment, security and cost
Enterprise integration:  AWS Organizations , cross-account access, hybrid networking, governance
Specialised: deep  EKS , GPU training, multi-Region active-active, regulated environments
AI isn't a layer. It runs through all five, which is why "I know  Bedrock " is a thin answer to "do you know AWS for AI?" I'll come back to that in the last section.
If you don't understand the bottom layer, you shouldn't be changing a customer's account on your own, and these days that includes the changes your agent makes for you.
﻿
Why is IAM the most important AWS skill for an FDE?IAM decides whether anything you or your agent tries will work, and in a customer's environment it's usually the first thing that stops you.
IAM works across a set of boundaries, so start there. A resource lives at Organization → organisational unit → account → Region → VPC → subnet, and each step is a different kind of boundary. Availability Zones cut across that chain rather than sitting in it: a VPC spans every AZ in its Region, and each subnet sits in exactly one. That's why "it's in the same AWS Organization" tells you almost nothing about whether two applications can talk to each other.
﻿
"I'm an admin in this account" doesn't tell you much either, because there are policies above you that can still say no.  Service control policies (SCPs)  cap what principals in an account can do,  resource control policies (RCPs)  cap what anyone can do to resources like  S3  buckets and  KMS keys , and a  permissions boundary  caps a single role or user. None of those three ever grants anything. They only take permissions away, so an identity policy or a resource policy still has to say yes.
﻿
Make sure you know the difference between a trust policy and a permission policy. The trust policy decides who's allowed to assume a role, and the permission policy decides what the role can do once someone has. Most cross-account confusion comes from fixing one when the problem is the other.
Then the rough shape of  how AWS decides :
Plain text
principal
  → assumes a role (the trust policy decides who can)
  → receives temporary credentials from STS
  → each request is checked against:
       identity-based policies
       resource-based policies
       permissions boundaries
       session policies (extra limits passed in when a session starts)
       SCPs and RCPs (only for accounts in an AWS Organization)
  → an explicit Deny anywhere wins
  → otherwise something has to Allow it
That covers a request inside one account, where a resource policy that names the principal can be enough on its own. When the caller and the resource are in different accounts,  both accounts have to allow the request .
An FDE should be able to look at an  AccessDeniedException  and build a debugging tree instead of asking for admin, like this one:
Who am I right now?   aws sts get-caller-identity  
Does the message say which policy type denied me? Many services now include "with an explicit deny in a service control policy" (or similar) in the error.
If there's an encoded authorisation message, decode it:   aws sts decode-authorization-message --encoded-message <message>  
Same account or cross-account? If it's cross-account, check both sides.
Find the denied call in  CloudTrail  and read what it recorded.
Step 1 now has a second half: which identity is your agent using? An agent that connects through the AWS MCP Server can be set up with several named profiles and send individual requests through different ones, which is handy when you're working in a customer's dev and prod accounts in the same afternoon. It also means you should be able to answer "which profile did that call go through?" before you approve the next one.
Can I give my coding agent less AWS access than I have?Yes, for calls that go through an AWS-managed MCP server, such as the one in the  Agent Toolkit for AWS . Those requests carry two IAM condition keys:  aws:ViaAWSMCPService  (true for any AWS-managed MCP server) and  aws:CalledViaAWSMCP  (the specific server, such as  aws-mcp.amazonaws.com ). A customer can write a policy that lets you delete objects when you work by hand but refuses the same delete when your agent asks through the MCP server:
JSON
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowS3ReadAndDelete",
      "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:ListBucket", "s3:DeleteObject"],
      "Resource": "*"
    },
    {
      "Sid": "DenyDeleteViaMCP",
      "Effect": "Deny",
      "Action": "s3:DeleteObject",
      "Resource": "*",
      "Condition": {
        "Bool": { "aws:ViaAWSMCPService": "true" }
      }
    }
  ]
}
(Adapted from the  AWS Security Blog post on IAM for managed MCP servers . In a real policy, scope  Resource  to specific buckets.)
The key is only present on requests that pass through a managed MCP server. If your agent opens a shell and runs  aws s3 rm  with the same credentials, the key isn't in the request, so the Deny doesn't match and the Allow lets the delete through.
﻿
So the condition key guards one path into the account, and your agent probably has others. If you want the guardrail to hold, make the MCP server the only route the agent has, or give the agent's shell a profile whose role can't delete anything in the first place.
﻿
How do you debug networking in a customer's AWS account?Walk the request one hop at a time and ask the same few questions at each hop.
Plain text
browser
  → DNS
  → CloudFront (maybe)
  → ALB or API Gateway
  → security group
  → ECS, EKS, Lambda or EC2
  → security group
  → database
At each hop, check that the name resolved and there's a route, that a security group lets the traffic in and something is listening on the other side, whether TLS or IAM is involved, and whether the response can get back the way it came.
That list is more useful in a customer environment than knowing the maximum number of rules in a security group. You'll need the vocabulary (CIDR ranges, public and private subnets, route tables, internet and NAT gateways,  security groups  versus network ACLs, VPC endpoints), but most of the debugging is walking the request.
﻿
How do you find your way around an unfamiliar AWS environment?Trace five paths through it, plus a sixth whenever an agent is involved. They turn the "work out what they're doing and how it works" part of consulting into a method, and the first two lean on the IAM and networking sections you've just read.
﻿
Your agent can run most of these faster than you, so let it, but do the walk with it: read each call it makes and what came back. Doing the traces is how you learn an account, and reading its summary at the end won't teach you much.
Say someone on the customer's team pastes an Amazon Resource Name (ARN, the unique ID AWS gives every resource) into Slack with one line underneath: "why can't prod invoke this?" Walking the request path rules out the network first. CloudTrail then shows an  AccessDenied  on the call, which sends you to the identity trace. There you find that prod's role is allowed to invoke the function by its identity policy but the account sits in an OU with an SCP that denies the action outside an approved Region. The function, the role and the network can all stay as they are, because nothing in the account is broken. What you need is a conversation with the platform team, with the CloudTrail event in hand. It's the kind of mess people bring in outside help for, where the fix belongs to a team they don't run.
﻿
﻿
Which AWS services should an FDE know well, and which can wait?Know the services in almost every customer's request path well enough to operate them. For the rest, learn the idea underneath so you recognise the service when it turns up.
Spend the extra time on queues and events, because that's where the agents you build for customers make expensive mistakes fast.  SQS  standard queues,  SNS  and  EventBridge  all deliver at least once, so the same message can arrive twice. ( SQS FIFO queues  are the exception: they don't add duplicates of their own, and they drop a resend that carries the same deduplication ID within five minutes.) Without an agent, a duplicate means a worker did the same job twice. When an agent is calling tools, it can mean the agent retried  CreateInvoice()  after a timeout and the customer's customer got two invoices. Retrying  GetWeather()  costs a few milliseconds and nobody notices. To protect against that, make the tool idempotent: it accepts a request ID and treats a repeat of that ID as a no-op. You have to design that into the tool, because AWS has no switch for it.
﻿
Compute is quicker to cover. Be able to operate and debug  Lambda ,  ECS  on  Fargate  and  EC2 , and to trace common problems on EKS. AWS treats these as different models for different workloads, so when you meet one, the useful question is why the team chose it.
For data, learn the models and access patterns (relational, key-value, cache, search, object, vector) before the product names, because the product list moves.  S3 Vectors  only reached general availability in December 2025. Keeping up with that is work you can hand to your agent. If it has the AWS skills from the Agent Toolkit loaded, ask it which vector stores  Bedrock Knowledge Bases  supports this month and it will check the current docs instead of guessing from its training data. It won't know that the customer's security team has approved  OpenSearch  and nothing else, and that matters more than whatever the skill recommends by default.
Production engineering is the gap between a demo and something you can hand over. You need enough Terraform,  CloudFormation  or  CDK  to read it and change it without breaking anything, which means understanding state, plan versus apply, drift and imports. Terraform turns up in a lot of customer estates because it works across clouds. AWS's guidance is to manage infrastructure as code and keep changes out of the console. Use the console to understand the environment and code to change it.
For observability, instrument new code with OpenTelemetry through  ADOT , AWS's distribution of it. You'll still find the  X-Ray SDK  in plenty of codebases and it still works, but it has only had security fixes since February 2026.
Cost matters more than it does in your own account, because the bill you're making decisions on belongs to someone else. The usual surprises are traffic between Availability Zones,  NAT gateway data processing  (charged per GB on top of the hourly rate), logs nobody reads and, on AI work, inference tokens.
If you've only built in your own account, you won't have met the enterprise layer. Expect separate accounts for security, logging and networking, plus production and non-production OUs. Treat that layout as part of the customer's security model, and ask before you work around any of it. Learn cross-account role assumption properly, because you'll be doing it from the first week.
Most of the enterprise networking you only need to recognise. When two VPCs both use 10.0.0.0/16, which happens a lot with a vendor and a customer,  PrivateLink  can still expose a service from one to the other, because it doesn't need the address ranges to differ. A  Transit Gateway  is the hub that connects many VPCs and the customer's own data centre. You won't be configuring their  Direct Connect , but you should notice when a route table change could cut them off from that data centre, and talk to their network team before you make it.
At the top of the pyramid, deep Kubernetes networking,  SageMaker AI  training,  GovCloud  and  Outposts  can wait until an engagement needs them.
Being "good at" a service has levels too:
Recognise: I know what it is and why it might be there
Trace: I can follow it through an architecture and debug common problems
Operate: I can change, configure and deploy it safely
Design: I can choose it and defend the choice against the alternatives
Aim for Design only on the few things you'll be deciding for the customer, and Operate on the services you'll change most weeks, since those are the changes you'll be signing off, both your own and your agent's.
﻿
﻿
How do you secure an AI agent's access to a customer's AWS account?Treat every agent as one more principal in everything above, whether it's the coding agent you work with or one you build for the customer. Give each its own identity with the least privilege it needs, authorise every tool call, and make sure you can reconstruct afterwards what it did and on whose behalf. An agent will use every permission its credentials give it, so the limits have to come from the credentials and the checks around each call, not from the agent's judgement.
The two kinds are easy to blur, and they aren't the same job. Building with an agent means using a coding agent in your editor or terminal to do your own work faster: it reads the account, writes the Terraform and runs the CLI, and it leaves when you do. Building an agent means shipping one for the customer, like a support agent that looks up orders and issues refunds through their APIs, and it stays running after you've gone.
﻿
Both act in the customer's account with real credentials, and both are covered by the sixth trace:
Plain text
Agent: user → agent → model → retrieval → tool → authorisation → side effect → evaluation → audit trail
AWS's  Agentic AI Lens  for the  Well-Architected Framework  is written for the agents you build, and says each one should have its own identity, separate from human identities, scoped to least privilege. It also says tool calls should be authorised against policy before they run, the originating user's context should travel with the request, and high-risk actions that change things should get human approval. None of that is new, which is why AI was never its own layer in the pyramid. Every one of those ideas is already at the bottom, and the CreateInvoice retry from the queues section is the same idempotency problem, with an agent making the call.
Either kind of agent differs from your other principals in one way that matters: it acts on what it reads. A retrieved document, a tool response or a message from another agent can contain text the model follows as an instruction, so treat all of it as untrusted input, the same way you'd treat a form field on a public website.
For the agents you build, a 200 from every service in the trace tells you the calls succeeded, not that the agent did the right thing. To know that, you need traces of its tool calls and retrieval results, plus evaluations: tests that score whether it completed the task against a set of known cases. Cost per API call says little when an agent can loop, so report cost per successful task to the customer.
Your coding agent is often the first agent in a customer's account, before anything you build for them. If it uses the AWS MCP Server, its activity is logged in CloudTrail and its requests carry the condition keys from earlier, so the customer's security team has a record of what it did and can write separate rules for its calls. You also pick which Regional MCP endpoint it connects to, so check that against the customer's data-residency rules. Then run the agent trace on your own tooling, before you run it on anything you build for them.
﻿
I'd still give the same advice I gave about MLOps. You get good at this by being handed other people's messes in infrastructure you didn't choose, again and again, and an FDE role does that for you every engagement.
Bringing an agent changes how fast you move through each account, which is useful as long as you're still the one learning from it. Let it run the traces with you and read what it finds. If it does all the exploring and you only approve what it suggests, the customer's problem gets fixed and you leave no better at this than when you arrived.
On your next engagement, before you or your agent change anything, find out why the customer's own team couldn't build this. The answer is usually the team structure, the politics or the old system they're modernising underneath, and none of that shows up in an API call. It will tell you more about what's safe to change than anything in the account.
﻿
﻿
About the Author:Brooke Jamieson is a Senior Developer Advocate at AWS, focused on AI agents and developer tools. A former fashion model turned mathematician turned AI Engineer, Brooke moved from Australia to New York City for this role. They make byte-sized tech content about AI and AWS, and you can find them on  LinkedIn  ,  Instagram  or  X .