A gentle introduction to automated reasoning

Meet Amazon Science’s newest research area.

This week, Amazon Science added automated reasoning to its list of research areas. We made this change because of the impact that automated reasoning is having here at Amazon. For example, Amazon Web Services’ customers now have direct access to automated-reasoning-based features such as IAM Access Analyzer, S3 Block Public Access, or VPC Reachability Analyzer. We also see Amazon development teams integrating automated-reasoning tools into their development processes, raising the bar on the security, durability, availability, and quality of our products.

The goal of this article is to provide a gentle introduction to automated reasoning for the industry professional who knows nothing about the area but is curious to learn more. All you will need to make sense of this article is to be able to read a few small C and Python code fragments. I will refer to a few specialist concepts along the way, but only with the goal of introducing them in an informal manner. I close with links to some of our favorite publicly available tools, videos, books, and articles for those looking to go more in-depth.

Let’s start with a simple example. Consider the following C function:

bool f(unsigned int x, unsigned int y) {
   return (x+y == y+x);
}

Take a few moments to answer the question “Could f ever return false?” This is not a trick question: I’ve purposefully used a simple example to make a point.

To check the answer with exhaustive testing, we could try executing the following doubly nested test loop, which calls f on all possible pairs of values of the type unsigned int:

#include<stdio.h>
#include<stdbool.h>
#include<limits.h>

bool f(unsigned int x, unsigned int y) {
   return (x+y == y+x);
}

void main() {
   for (unsigned int x=0;1;x++) {
      for (unsigned int y=0;1;y++) {
         if (!f(x,y)) printf("Error!\n");
         if (y==UINT_MAX) break;
      }
      if (x==UINT_MAX) break;
   }
}

Unfortunately, even on modern hardware, this doubly nested loop will run for a very long time. I compiled it and ran it on a 2.6 GHz Intel processor for over 48 hours before giving up.

Why does testing take so long? Because UINT_MAX is typically 4,294,967,295, there are 18,446,744,065,119,617,025 separate f calls to consider. On my 2.6 GHz machine, the compiled test loop called f approximately 430 million times a second. But to test all 18 quintillion cases at this performance, we would need over 1,360 years.

When we show the above code to industry professionals, they almost immediately work out that f can't return false as long as the underlying compiler/interpreter and hardware are correct. How do they do that? They reason about it. They remember from their school days that x + y can be rewritten as y + x and conclude that f always returns true.

Re:Invent 2021 keynote address by Peter DeSantis, senior vice president for utility computing at Amazon Web Services
Skip to 15:49 for a discussion of Amazon Web Services' work on automated reasoning.

An automated reasoning tool does this work for us: it attempts to answer questions about a program (or a logic formula) by using known techniques from mathematics. In this case, the tool would use algebra to deduce that x + y == y + x can be replaced with the simple expression true.

Automated-reasoning tools can be incredibly fast, even when the domains are infinite (e.g., unbounded mathematical integers rather than finite C ints). Unfortunately, the tools may answer “Don’t know” in some instances. We'll see a famous example of that below.

The science of automated reasoning is essentially focused on driving the frequency of these “Don’t know” answers down as far as possible: the less often the tools report "Don't know" (or time out while trying), the more useful they are.

Today’s tools are able to give answers for programs and queries where yesterday’s tools could not. Tomorrow’s tools will be even more powerful. We are seeing rapid progress in this field, which is why at Amazon, we are increasingly getting so much value from it. In fact, we see automated reasoning forming its own Amazon-style virtuous cycle, where more input problems to our tools drive improvements to the tools, which encourages more use of the tools.

A slightly more complex example. Now that we know the rough outlines of what automated reasoning is, the next small example gives a slightly more realistic taste of the sort of complexity that the tools are managing for us.

void g(int x, int y) {
   if (y > 0)
      while (x > y)
         x = x - y;
}

Or, alternatively, consider a similar Python program over unbounded integers:

def g(x, y):
   assert isinstance(x, int) and isinstance(y, int)
   if y > 0:
      while x > y:
         x = x - y

Try to answer this question: “Does g always eventually return control back to its caller?”

When we show this program to industry professionals, they usually figure out the right answer quickly. A few, especially those who are aware of results in theoretical computer science, sometimes mistakenly think that we can't answer this question, with the rationale “This is an example of the halting problem, which has been proved insoluble”. In fact, we can reason about the halting behavior for specific programs, including this one. We’ll talk more about that later.

Here’s the reasoning that most industry professionals use when looking at this problem:

  1. In the case where y is not positive, execution jumps to the end of the function g. That’s the easy case.
  2. If, in every iteration of the loop, the value of the variable x decreases, then eventually, the loop condition x > y will fail, and the end of g will be reached.
  3. The value of x always decreases only if y is always positive, because only then does the update to x (i.e., x = x - y) decrease x. But y’s positivity is established by the conditional expression, so x always decreases.

The experienced programmer will usually worry about underflow in the x = x - y command of the C program but will then notice that x > y before the update to x and thus cannot underflow.

If you carried out the three steps above yourself, you now have a very intuitive view of the type of thinking an automated-reasoning tool is performing on our behalf when reasoning about a computer program. There are many nitty-gritty details that the tools have to face (e.g., heaps, stacks, strings, pointer arithmetic, recursion, concurrency, callbacks, etc.), but there’s also decades of research papers on techniques for handling these and other topics, along with various practical tools that put these ideas to work.

Policy-code.gif
Automated reasoning can be applied to both policies (top) and code (bottom). In both cases, an essential step is reasoning about what's always true.

The main takeaway is that automated-reasoning tools are usually working through the three steps above on our behalf: Item 1 is reasoning about the program’s control structure. Item 2 is reasoning about what is eventually true within the program. Item 3 is reasoning about what is always true in the program.

Note that configuration artifacts such as AWS resource policies, VPC network descriptions, or even makefiles can be thought of as code. This viewpoint allows us to use the same techniques we use to reason about C or Python code to answer questions about the interpretation of configurations. It’s this insight that gives us tools like IAM Access Analyzer or VPC Reachability Analyzer.

An end to testing?

As we saw above when looking at f and g, automated reasoning can be dramatically faster than exhaustive testing. With tools available today, we can show properties of f or g in milliseconds, rather than waiting lifetimes with exhaustive testing.

Can we throw away our testing tools now and just move to automated reasoning? Not quite. Yes, we can dramatically reduce our dependency on testing, but we will not be completely eliminating it any time soon, if ever. Consider our first example:

bool f(unsigned int x, unsigned int y) {
   return (x + y == y + x);
}

Recall the worry that a buggy compiler or microprocessor could in fact cause an executable program constructed from this source code to return false. We might also need to worry about the language runtime. For example, the C math library or the Python garbage collector might have bugs that cause a program to misbehave.

What’s interesting about testing, and something we often forget, is that it’s doing much more than just telling us about the C or Python source code. It’s also testing the compiler, the runtime, the interpreter, the microprocessor, etc. A test failure could be rooted in any of those tools in the stack.

Automated reasoning, in contrast, is usually applied to just one layer of that stack — the source code itself, or sometimes the compiler or the microprocessor. What we find so valuable about reasoning is it allows us to clearly define both what we do know and what we do not know about the layer under inspection.

Furthermore, the models of the surrounding environment (e.g., the compiler or the procedure calling our procedure) used by the automated-reasoning tool make our assumptions very precise. Separating the layers of the computational stack helps make better use of our time, energy, and money and the capabilities of the tools today and tomorrow.

Unfortunately, we will almost always need to make assumptions about something when using automated reasoning — for example, the principles of physics that govern our silicon chips. Thus, testing will never be fully replaced. We will want to perform end-to-end testing to try and validate our assumptions as best we can.

An impossible program

I previously mentioned that automated-reasoning tools sometimes return “Don’t know” rather than “yes” or “no”. They also sometimes run forever (or time out), thus never returning an answer. Let’s look at the famous "halting problem" program, in which we know tools cannot return “yes” or “no”.

Imagine that we have an automated-reasoning API, called terminates, that returns “yes” if a C function always terminates or “no” when the function could execute forever. As an example, we could build such an API using the tool described here (shameless self-promotion of author’s previous work). To get the idea of what a termination tool can do for us, consider two basic C functions, g (from above),

void g(int x, int y) {
   if (y > 0)
      while (x > y)
         x = x - y;
}

and g2:

void g2(int x, int y) {
   while (x > y)
      x = x - y;
}

For the reasons we have already discussed, the function g always returns control back to its caller, so terminates(g) should return true. Meanwhile, terminates(g2) should return false because, for example, g2(5, 0) will never terminate.

Now comes the difficult function. Consider h:

void h() {
   if terminates(h) while(1){}
}

Notice that it's recursive. What’s the right answer for terminates(h)? The answer cannot be "yes". It also cannot be "no". Why?

Imagine that terminates(h) were to return "yes". If you read the code of h, you’ll see that in this case, the function does not terminate because of the conditional statement in the code of h that will execute the infinite loop while(1){}. Thus, in this case, the terminates(h) answer would be wrong, because h is defined recursively, calling terminates on itself.

Similarly, if terminates(h) were to return "no", then h would in fact terminate and return control to its caller, because the if case of the conditional statement is not met, and there is no else branch. Again, the answer would be wrong. This is why the “Don’t know” answer is actually unavoidable in this case.

The program h is a variation of examples given in Turing’s famous 1936 paper on decidability and Gödel’s incompleteness theorems from 1931. These papers tell us that problems like the halting problem cannot be “solved”, if by“solved” we mean that the solution procedure itself always terminates and answers either “yes” or “no” but never “Don’t know”. But that is not the definition of “solved” that many of us have in mind. For many of us, a tool that sometimes times out or occasionally returns “Don’t know” but, when it gives an answer, always gives the right answer is good enough.

This problem is analogous to airline travel: we know it’s not 100% safe, because crashes have happened in the past, and we are sure that they will happen in the future. But when you land safely, you know it worked that time. The goal of the airline industry is to reduce failure as much as possible, even though it’s in principle unavoidable.

To put that in the context of automated reasoning: for some programs, like h, we can never improve the tool enough to replace the "Don't know" answer. But there are many other cases where today's tools answer "Don't know", but future tools may be able to answer "yes" or "no". The modern scientific challenge for automated-reasoning subject-matter experts is to get the practical tools to return “yes” or “no” as often as possible. As an example of current work, check out CMU professor and Amazon Scholar Marijn Heule and his quest to solve the Collatz termination problem.

Another thing to keep in mind is that automated-reasoning tools are regularly trying to solve “intractable” problems, e.g., problems in the NP complexity class. Here, the same thinking applies that we saw in the case of the halting problem: automated-reasoning tools have powerful heuristics that often work around the intractability problem for specific cases, but those heuristics can (and sometimes do) fail, resulting in “Don’t know” answers or impractically long execution time. The science is to improve the heuristics to minimize that problem.

Nomenclature

A host of names are used in the scientific literature to describe interrelated topics, of which automated reasoning is just one. Here’s a quick glossary:

  • A logic is a formal and mechanical system for defining what is true and untrue. Examples: propositional logic or first-order logic.
  • A theorem is a true statement in logic. Example: the four-color theorem.
  • A proof is a valid argument in logic of a theorem. Example: Gonthier's proof of the four-color theorem. 
  • A mechanical theorem prover is a semi-automated-reasoning tool that checks a machine-readable expression of a proof often written down by a human. These tools often require human guidance. Example: HOL-light, from Amazon researcher John Harrison. 
  • Formal verification is the use of theorem proving when applied to models of computer systems to prove desired properties of the systems. Example: the CompCert verified C compiler. 
  • Formal methods is the broadest term, meaning simply the use of logic to reason formally about models of systems. 
  • Automated reasoning focuses on the automation of formal methods. 
  • A semi-automated-reasoning tool is one that requires hints from the user but still finds valid proofs in logic. 

As you can see, we have a choice of monikers when working in this space. At Amazon, we’ve chosen to use automated reasoning, as we think it best captures our ambition for automation and scale. In practice, some of our internal teams use both automated and semi-automated reasoning tools, because the scientists we've hired can often get semi-automated reasoning tools to succeed where the heuristics in fully automated reasoning might fail. For our externally facing customer features, we currently use only fully automated approaches.

Next steps

In this essay, I’ve introduced the idea of automated reasoning, with the smallest of toy programs. I haven’t described how to handle realistic programs, with heap or concurrency. In fact, there are a wide variety of automated-reasoning tools and techniques, solving problems in all kinds of different domains, some of them quite narrow. To describe them all and the many branches and sub-disciplines of the field (e.g. “SMT solving”, “higher-order logic theorem proving”, “separation logic”) would take thousands of blogs posts and books.

Automated reasoning goes back to the early inventors of computers. And logic itself (which automated reasoning attempts to solve) is thousands of years old. In order to keep this post brief, I’ll stop here and suggest further reading. Note that it’s very easy to get lost in the weeds reading depth-first into this area, and you could emerge more confused than when you started. I encourage you to use a bounded depth-first search approach, looking sequentially at a wide variety of tools and techniques in only some detail and then moving on, rather than learning only one aspect deeply.

Suggested books:

International conferences/workshops:

Tool competitions:

Some tools:

Interviews of Amazon staff about their use of automated reasoning:

AWS Lectures aimed at customers and industry:

AWS talks aimed at the automated-reasoning science community:

AWS blog posts and informational videos:

Some course notes by Amazon Scholars who are also university professors:

A fun deep track:

Some algorithms found in the automated theorem provers we use today date as far back as 1959, when Hao Wang used automated reasoning to prove the theorems from Principia Mathematica.

Research areas

Related content

US, NY, New York
Twitch is looking for an Applied Scientist to lead computer vision and video manipulation work within Amazon Publisher Monetization (APM). You will apply large language models (LLMs), vision-language models (VLMs), and traditional computer vision techniques to build products that directly improve how millions of Twitch creators produce content and how viewers engage with it. This is a high-visibility project backed by senior leadership, and you will have the autonomy to evaluate both first-party and third-party solutions to deliver the highest quality results quickly. If you thrive in a fast-paced, startup-like environment where your scientific decisions shape the product roadmap, we want to hear from you. Key job responsibilities Design and deploy computer vision and video manipulation models using LLMs, VLMs, and traditional techniques, taking solutions from research prototype to production. Partner with senior Product and Twitch leadership to translate customer needs into well-defined scientific problems and deliver end-to-end solutions. Evaluate and integrate generative AI capabilities across Amazon Bedrock and third-party platforms, selecting the approach that maximizes product quality. Drive the team's scientific agenda by proposing new initiatives, authoring technical documents, and contributing to external publications. Mentor fellow scientists and engineers through code reviews, design guidance, and technical assessments that raise the overall quality bar. A day in the life You will split your time roughly evenly between independent research and collaborative sessions. Mornings often start with focused solo work — benchmarking a new VLM, writing model code, or analyzing experiment results. Midday you join working sessions with Product and Twitch leadership to align on requirements or review progress. Afternoons shift between pairing with engineers on production integration and mentoring teammates on evaluation methodology. Weekly science reviews and bi-weekly roadmap syncs keep the team aligned without over-scheduling your calendar. About the team The APM science team supports all of Amazon's Publisher Monetization efforts, building the models and systems behind Twitch's creator tools and ad experiences. The team includes applied scientists, software engineers, and product managers who collaborate daily to move ideas from whiteboard to production. We operate with a startup mentality — moving fast, wearing multiple hats, and iterating closely with Twitch and Product partners. We are accelerating investment in computer vision and generative AI, and this role will be central to that expansion.
US, WA, Bellevue
Are you curious about turning complex data into actionable insights that shape how millions of customers experience Amazon? Do you enjoy building analytical models, testing hypotheses, and seeing your work drive real business decisions? We are looking for a Data Scientist to join our team at Amazon. In this role, you will apply statistical techniques, machine learning, and data analysis to solve well-defined business problems and deliver measurable improvements. You will work with large-scale datasets from multiple sources, build and validate models, and create metrics that quantify impact. This is an opportunity for a self-starter who is comfortable with ambiguity in data, thrives on collaboration with science and engineering partners, and is eager to grow their craft in a fast-paced environment. Key job responsibilities - Use statistical methods, machine learning algorithms, and data analysis techniques to translate well-defined business problems into data science solutions that improve processes and systems. - Gather, clean, and integrate large datasets from multiple sources to build and validate models, ensuring data integrity and adherence to best practices throughout the pipeline. - Design and deliver metrics, visualizations, and reports that compare results against benchmarks and original project goals, enabling clear and informed decision-making for stakeholders. - Collaborate with business, science, and engineering teams to understand customer needs, identify opportunities, and develop scalable analytical solutions using tools such as Python, R, or SQL. - Evaluate opportunities to integrate generative artificial intelligence tools into workflows, refining outputs and applying responsible practices to augment productivity and solution quality. About the team Our team is focused on using data science to help Amazon make smarter, faster decisions that benefit customers. We build analytical models and machine learning solutions that operate at scale, and we value rigorous methodology paired with clear communication. You will join a collaborative group of scientists and engineers who are passionate about learning from one another and pushing the boundaries of what data can do. If you are excited about growing your career in an inclusive, supportive environment where your contributions have tangible impact, we would love to hear from you.
TW, TPE, Hsinchu City
Are you passionate about robotics and research? Do you want to solve real customer problems through innovative technology? Do you enjoy working on scalable research and projects in a collaborative team environment? Do you want to see your science solutions directly impact millions of customers worldwide? At Amazon, we hire the best minds in technology to innovate and build on behalf of our customers. Customer obsession is part of our company DNA, which has made us one of the world's most beloved brands. We’re looking for current PhD or Master students with a passion for robotic research and applications to join us as Robotics Applied Scientist II Intern/Co-ops in 2027 to shape the future of robotics and automation at an unprecedented scale across. For these positions, our Robotics teams at Amazon are looking for students with a specialization in one or more of the research areas in robotics such as: robotics, robotics manipulation (e.g., robot arm, grasping, dexterous manipulation, end of arm tools/end effector), autonomous mobile robots, mobile manipulation, movement, autonomous navigation, locomotion, motion/path planning, controls, perception, sensing, robot learning, artificial intelligence, machine learning, computer vision, large language models, human-robot interaction, robotics simulation, optimization, and more! We're looking for curious minds who think big and want to define tomorrow's technology. At Amazon, you'll grow into the high-impact engineer you know you can be, supported by a culture of learning and mentorship. Every day brings exciting new challenges and opportunities for personal growth. By applying to this role, you will be considered for Robotics Applied Scientist II Intern/Co-op (2027) opportunities across various Robotics teams at Amazon with different robotics research focus, with internship positions available for multiple locations, durations (3 to 6+ months), and year-round start dates (winter, spring, summer, fall). Amazon intern and co-op roles follow the same internship structure. "Intern/Internship" wording refers to both interns and co-ops. Amazon internships across all seasons are full-time positions during vacation, and interns should expect to work in office, Monday-Friday, up to 40 hours per week typically between 9am-6pm. Specific team norms around working hours will be communicated by your manager. Interns should not have other employment during the Amazon work-day. Applicants should have a minimum of one quarter/semester/trimester remaining in their studies after their internship concludes. The robotics internship join dates, length, location, and prospective team will be finalized at the time of any applicable job offers. In your application, you will be able to provide your preference of research interests, start dates, internship duration, and location. While your preference will be taken into consideration, we cannot guarantee that we can meet your selection based on several factors including but not limited to the internship availability and business needs of this role.
US, WA, Seattle
Amazon Prime Air is seeking an Applied Scientist Manager to lead the team developing our next-generation drone navigation system. You will lead a team of 8–12 Applied Scientists, Research Scientists and Software Development Engineers who invent, model, develop, test, and deploy the state estimation algorithms. Your team will own the full algorithm lifecycle: early prototypes and modeling, simulation and hardware-in-the-loop testing, then flight test and deployment across a rapidly growing delivery network. You will also manage the feedback loop that brings real-world operational data back into the team to inform next generation of algorithm improvements. Because our navigation software is safety-critical, you will work closely with the Controls, Perception, Safety, Simulation and Flight Test teams to deliver robust, fully verified algorithms. This role combines deep technical leadership with people leadership. You will hire and develop science-focused engineers, run a fast-paced agile development team and help shape the technical roadmap for autonomous navigation at Prime Air. Key job responsibilities - Lead a team of 8–12 Applied Scientists, Research Scientists and Software Development Engineers developing novel navigation and state estimation algorithms, including Kalman filtering (EKF/UKF, error-state), tightly and loosely coupled GNSS/INS integration, multi-sensor fusion and observability analysis, integrity monitoring (RAIM, fault detection and exclusion), and visual navigation (VIO/VSLAM). - Drive day-to-day execution across the full development lifecycle: prototyping, modeling, simulation testing, hardware-in-the-loop testing, flight test and deployment to the production fleet. - Lead the team in a scrum-style agile process: set sprint priorities, manage dependencies and deliver against program milestones. - Build mechanisms that capture operational learnings from our delivery network, such as flight data, anomalies and performance trends, and feed them into the requirements and design of each new generation of algorithms. - Set technical direction and raise the bar on scientific rigor. - Partner with Flight controls, Perception, Hardware, Safety, Simulation and Flight Operations teams to define interfaces, requirements and verification evidence. - Hire, mentor and develop Applied Scientists, Research Scientists and SDEs, building a diverse, high-performing team with a strong safety culture. - Communicate technical strategy, trade-offs, risks and results clearly in writing and in reviews with senior leadership.
US, WA, Redmond
Amazon LEO is an initiative to increase global broadband access through a constellation of 3,236 satellites in low Earth orbit (LEO). Its mission is to bring fast, affordable broadband to unserved and underserved communities around the world. Amazon Leo will help close the digital divide by delivering fast, affordable broadband to a wide range of customers, including consumers, businesses, government agencies, and other organizations operating in places without reliable connectivity. About this role We're looking for a Data Scientist to turn data from our satellite fleet into engineering decisions. Every satellite in orbit sends back a steady stream of telemetry. Every unit was also tested heavily on the ground before launch, and the ground segment watches the satellite every day while it operates. Your job is to connect these sources. You'll find out which in-orbit behaviors trace back to what we measured in the factory, which events repeat across the fleet, and which patterns point to weaknesses in the hardware design. Your findings will directly shape how we design, build, test, and operate the next generation of satellites. A typical problem starts small: a handful of satellites show a drifting temperature, an occasional link dropout, or a counter that creeps up faster than expected. You'll work out whether it's a real effect or noise, whether it's spreading, and what the affected units have in common. They might share a manufacturing lot, a configuration, an orbital environment, or a signature in their factory test history. From there you'll form a hypothesis about the physical cause and argue it in front of hardware, firmware, and reliability engineers who will push back hard. You'll also have to say plainly when the data rules your own idea out. Telemetry alone rarely settles the question, so your first stop is the ground test data we already have. Every unit in orbit has a detailed record from manufacturing and environmental testing, and the fleet as a whole is backed by an even larger population of units still on the ground. You'll dig through that history for the same behavior: did the affected units show early signs on the ground, did they sit near a test limit, does the effect appear across many units under certain conditions? Often the answer is already in data no one has looked at in this light. When it isn't, you'll design the ground experiments that can provide it. That means deciding which units to test and under what conditions, how many runs you need before the result means anything, and what outcome would confirm or refute the theory. You'll work with the engineers who run those tests, analyze the results, and close the question with a clear answer and a recommended action. Beyond individual investigations, you'll build the fleet-level view: baselines for healthy behavior, early warning indicators that catch emerging issues before they cause outages, and reliability estimates that tell us how the population is aging. You'll decide which recurring analyses should become automated monitoring and work with software engineers to make that happen. You'll be the person the team turns to when someone asks "is this normal?" about the fleet. The ideal candidate is curious about how hardware fails and comfortable with messy data from many sources. They can turn "we're seeing something odd on a few satellites" into a rigorous analysis and a clear recommendation. What you'll bring: - Master's degree or above in a quantitative field such as statistics, mathematics, data science, physics, electrical or aerospace engineering, or computer science, or PhD - 3/5+ years of hands-on experience in an applied or industry setting using Python and SQL to analyze large datasets such as time series, telemetry, sensor, or test data - Experience applying statistical methods (hypothesis testing, regression, time-series analysis, anomaly detection) to noisy, incomplete real-world data - Experience building visualizations and dashboards that communicate findings to engineers and decision makers - Experience framing and solving loosely defined problems, from the first question to a recommendation people act on - Ability to work with hardware and software engineers and turn their questions into analyses you can actually run Nice to have: - Experience analyzing telemetry from satellites, spacecraft, aircraft, vehicles, or other fleets of deployed hardware - Experience with reliability and failure analysis methods such as survival analysis, Weibull modeling, failure-mode analysis, and root-cause investigation - Familiarity with electronics or RF hardware, manufacturing test, environmental stress screening (thermal cycling, burn-in, HASS/HALT), or yield analysis - Experience with pattern-discovery techniques such as clustering, change-point detection, and unsupervised anomaly detection - Experience with large-scale data tools (Spark, Athena/Presto, Redshift) and AWS - Experience with visualization tools such as QuickSight, Tableau, Grafana, or Plotly/Dash - Experience working with software engineers on data pipelines: data requirements, schema design, data quality checks, and automating recurring analyses - Experience using AI-assisted tools to speed up analysis and automate repetitive work - A track record of changing engineering design or test decisions with data Export Control Requirement Due to applicable export control laws and regulations, candidates must be a U.S. citizen or national, U.S. permanent resident (i.e., current Green Card holder), or lawfully admitted into the U.S. as a refugee or granted asylum. Key job responsibilities As a Data Scientist, you will… - Analyze in-orbit telemetry to measure the health and performance of satellite subsystems, and detect anomalies and slow degradation early - Correlate in-orbit behavior with pre-launch data, including manufacturing, production test, and environmental test results, to find which ground measurements predict on-orbit performance. Feed those insights back into test limits and screening strategy - Correlate in-orbit data with what the ground segment sees (gateways, customer terminals) and with failure analysis of lab and returned units - Connect events across the fleet by build lot, component, configuration, firmware version, orbit, and operating conditions, so we can tell systemic issues apart from one-off events - Find patterns that point to hardware design weaknesses, measure their impact on the fleet, and present the evidence to hardware engineering teams with clear recommendations - Build visualizations and dashboards that support decisions in fleet health reviews, anomaly investigations, and design reviews - Work with software engineers to improve the data pipeline: define data requirements, improve data quality, link ground and in-orbit datasets, and automate recurring analyses - Own ambiguous investigations end to end, from forming the hypothesis to reporting the outcome to senior engineering leaders About the team Phased Array Antenna System Validation is the team that decides whether a satellite's phased array antennas (PAAs) are ready to fly. These are the electronically steered transmit and receive panels that form the link between the satellite and the ground. We're part of Amazon Leo, Amazon's low Earth orbit satellite constellation, and we own the test strategy, the automation, and the data pipeline that every PAA goes through on its way to orbit. That path runs from early component-level screening through full-panel functional testing and extended environmental stress testing across temperature, vacuum, and vibration. Our responsibility doesn't end at launch. We also own the analysis of telemetry from PAAs in orbit, and we use what the constellation tells us to improve how we test on the ground. We are a hardware-facing software and test team, and we sit where several disciplines meet. Our test automation directs firmware provisioning, self-tests, and environmental profiles on test stations at manufacturing sites. Over a single run it exercises thousands of measurement points: high-speed serial links, clocking, digital beamformer firmware, RF chains, power, and thermal behavior. Every result is tied to a specific serial-numbered part. That builds a detailed, part-level history of how each panel and component behaved under stress, from the factory floor to launch. A large part of our work is investigation. When something fails, we work out whether the cause is the hardware, the firmware, the test equipment, or our own automation, and we decide what should happen next. Over time we have built a growing catalog of failure signatures and their root causes, internal tools for analyzing long-duration tests, and AI-assisted agents that help turn raw logs into conclusions. We care about evidence over assumption. A label on a result isn't the result itself, and a search that finds nothing doesn't prove the problem has no history. Theories get tested against the data before they're accepted. We support multiple hardware generations at once, so the architecture, the questions, and the tooling keep changing. You'll work closely with antenna hardware, firmware, manufacturing, and reliability engineers who are glad to dig into a hard problem with you. Because we own both ends, from the first ground test to behavior in orbit, the loop is closed within the team. What we learn from the constellation goes straight back into our screens, thresholds, and test sequences, so that the next panel we validate is more likely to keep working in orbit.
CA, BC, Vancouver
Do you want to build science solutions that shape how millions of customers experience AWS products? Do you want to influence AWS investment in Cloud and AI technology, and see your recommendations inform AWS leadership decisions and drive the growth of the AWS business? Do you want to push the boundaries of data science (e.g., statistical modeling, causal inference, econometrics, product growth analytics, and forecasting models) and help democratize how AWS senior leaders access analytics insights using an agentic analytics system? The AWS Analytics Engineering team is at the forefront of leveraging AI/ML technology and infrastructure to redefine how AWS product leaders and teams interact with and derive insights from their product and customer data. Our vision is to use data science methods to enable AWS product teams and business leaders to drive product and revenue growth and create personalized, optimized, and simplified product experiences to delight our customers. We are looking for a customer-focused Senior Data Scientist to develop and deliver science solutions for AWS services. In this role, you will build ML-driven product analytics for AWS Compute (EC2), GenAI & Agents, Database & Analytics, and Storage (S3). You will partner with product managers, business leaders, and senior stakeholders to translate complex business problems into scientific solutions that influence AWS's top line and bottom line. You will analyze product growth insights, understand product growth drivers, and identify business risks that need to be surfaced to leadership. As a Senior Data Scientist, you will analyze business trends and customer insights hands-on, own analyses end to end from problem definition through recommendation, and help raise the bar for scientific rigor on the team. You will mentor junior data scientists through code and methodology reviews and share best practices across the team. You will operate effectively in ambiguous environments, use sound business judgment, show high ownership and a deep understanding of the AWS business, and apply new data science methods at AWS scale. Key job responsibilities Set the technical direction for ML-driven product analytics across AWS Compute (EC2), GenAI & Agents, Database & Analytics, and Storage (S3) Deliver at scale ML-Driven, proactive product analytics for ALL AWS services - initiating and driving GM/VP level conversations Define, own and deliver Knowledge organization best practices for agentic data analytics across AWS Services Build agentic knowledge coverage mechanisms to ensure any service GM/VP/Finance/PM leaders in AWS are able to derive accurate and well covered agentic insights Drive the delivery of cross-service AWS insights, and influence GMs and VPs on product and process changes based on insights delivered. Partner with other science organizations like AWS Central Econ and science (ACES) and IDEAS Science & Economics to drive AWS wide agentic analytics boundaries across organizations and governance mechanisms Work across the AAE Science, Engineering, Core data engineering and service analytics organization to scale science and analytics to all AWS services
US, NY, New York
We are seeking an Applied Scientist to develop and optimize Visual Inertial Odometry (VIO) and sensor fusion systems for our intelligent robots. In this role, you will design, implement, and deploy state estimation and tracking algorithms that enable robots to understand their position and motion in real time, even in challenging and dynamic environments. You will own the full pipeline from algorithm development through embedded deployment, ensuring that perception systems run efficiently on resource-constrained robotic hardware. You will also leverage modern machine learning approaches to push the boundaries of classical perception methods, combining learned representations with geometric techniques to achieve robust, real-time performance. This is a deeply hands-on role. You will work directly with sensors, hardware, and real-world data, while prototyping, testing, and iterating in physical environments. The ideal candidate has strong foundations in VIO and sensor fusion, practical experience optimizing algorithms for embedded platforms, and familiarity with how modern deep learning is transforming perception. Key job responsibilities - Design and implement Visual Inertial Odometry algorithms for robust real-time state estimation on robotic platforms like Sprout - Develop multi-sensor fusion pipelines integrating cameras, IMUs, and other sensing modalities for accurate pose tracking - Optimize perception and tracking algorithms for deployment on embedded hardware (e.g., ARM, GPU-accelerated edge devices) under strict latency and power constraints - Apply modern ML-based perception techniques (learned features, depth estimation, neural odometry) to complement and improve classical geometric approaches - Build and maintain calibration, evaluation, and benchmarking infrastructure for perception systems - Collaborate with hardware, controls, and navigation teams to integrate perception outputs into the robot’s autonomy stack - Lead technical projects from research prototyping through production deployment
IN, KA, Bengaluru
We are looking for a talented Research Scientist to join our team. In this role, you will design, develop, and deploy machine learning and computer vision models that solve real-world problems at scale in the Amazon grocery domain. You will work closely with engineering, product, and business teams to turn complex technical challenges into production-ready solutions, and own the model development lifecycle from experimentation through deployment. You will bring scientific rigor to every stage — from data analysis and model design to evaluation and iteration. This is a high-impact role where your models will directly improve the shopping experience for millions of customers in Amazon grocery stores. Key job responsibilities Design, train, and evaluate computer vision and machine learning models for complex grocery-domain problems including product identification, shelf perception, and in-store scene understanding — iterating rapidly from prototype to production-quality solutions Conduct rigorous exploratory data analysis to characterize domain-specific challenges (image variability, catalog gaps, label noise) and translate findings into actionable modeling decisions Design and execute offline and online evaluation frameworks — defining metrics that capture both model performance and downstream business impact, and diagnosing failure modes to prioritize improvements Build and improve data pipelines and annotation workflows that feed model training, including active learning strategies to maximize label efficiency Communicate technical results, trade-offs, and recommendations clearly to engineering, product, and business stakeholders — connecting model behavior to customer experience outcomes Stay current with state-of-the-art research in computer vision, multimodal learning, and representation learning — evaluating and adapting promising techniques to team-specific problems Contribute to a culture of scientific rigor through reproducible experimentation, thorough documentation, peer code and design reviews, and raising the quality bar for the team A day in the life As a Research Scientist on the GRAISE team, you'll spend your days analyzing model performance from overnight experiments, and prototyping new approaches using multimodal learning with store video and sensor data. You'll present findings to product and business stakeholders, translating technical results into actionable recommendations. Throughout the day, you'll balance rigorous scientific thinking with practical engineering constraints, knowing your work directly improves the shopping experience for millions of customers in Amazon grocery stores. About the team The GRAISE team (Grocery, Retail & In-Store Experience) within World Wide Grocery Store Tech (WWGST) builds foundational AI and machine learning systems that power Amazon's in-store grocery technologies. We develop domain-specific models that solve uniquely complex challenges in grocery — from smart shopping carts and inventory intelligence to personalization and store operations. Our mission is to create technology which makes grocery shopping more convenient, economical, personalized, and enjoyable for customers while empowering retailers with operational efficiency.
US, NY, New York
The Ads Measurement Science team in the Measurement, Ad Tech, and Data Science (MADS) team of Amazon Ads serves a centralized role developing solutions for a multitude of performance measurement products. We create solutions which measure the comprehensive impact of advertiser's ad spend, including sales impacts both online and offline and across timescales, and provide actionable insights that enable our advertisers to optimize their media portfolios. We also own the science solutions for AI tools that unlock new insights and automate high-effort customer workflows, such as custom query and report generation based on natural language user requests. We leverage a host of scientific technologies to accomplish this mission, including Generative AI, classical ML, Causal Inference, Natural Language Processing, and Computer Vision. As an Applied Scientist on the team, you will lead measurement solutions end-to-end from inception to production. You will propose, design, analyze, and productionize models to provide novel measurement insights to our customers. Key job responsibilities Leverage deep expertise in one or more scientific disciplines to invent solutions to ambiguous ads measurement problems Disambiguate problems to propose clear evaluation frameworks and success criteria Work autonomously and write high quality technical documents Implement a significant portion of critical-path code, and partner with engineers to directly carry solutions into production Partner closely with other scientists to deliver large, multi-faceted technical projects Share and publish works with the broader scientific community through meetings and conferences Communicate clearly to both technical and non-technical audiences Contribute new ideas that shape the direction of the team's work Mentor more junior scientists and participate in the hiring process About the team We are a team of scientists across Applied, Research, Data Science and Economist disciplines. You will work with colleagues with deep expertise in ML, NLP, CV, Gen AI, and Causal Inference with a diverse range of backgrounds. We partner closely with top-notch engineers, product managers, sales leaders, and other scientists with expertise in the ads industry and on building scalable modeling and software solutions.
US, CA, Sunnyvale
Robots are about to step out of the movies and into our homes. If you're excited about this robotics revolution, come join Amazon's Fauna Robotics. As an Applied Scientist in this org, you'll push the state-of-the-art techniques in Robotics. You'll drive technical excellence in areas such as perception, manipulation, sim2real transfer, reinforcement learning and multi-task learning, designing novel algorithms that bridge the gap between research and real-world deployment. In this role, you will integrate hands-on technical expertise with scientific leadership, ensuring your team delivers robust solutions for dynamic real-world environments. While staying updated with the latest advancements in robotics research, you will leverage your experience and expertise to guide the team towards the most promising direction. Collaborating with a talented group of software engineers and scientists, you will bring your ideas to fruition. Deploying robots in home environments requires you to anticipate challenges not encountered in structured settings like warehouses. Additionally, consumer-grade sensors and actuators necessitate working around their limitations, requiring out-of-the-box innovative ideas. As such, you are someone who truly enjoys thinking about problems using first principles at a holistic and systems level to address the aforementioned challenges. Key job responsibilities - Lead technical initiatives in areas such as robotics foundation models, reinforcement learning and manipulation - - Design experiments to identify the limitations of current state-of-the-art models and developing new models or techniques that can surpass these models - Design and implement novel deep learning architectures that push the boundaries of what robots can understand and accomplish - Mentor fellow scientists while maintaining strong individual technical contributions - Collaborate with engineering teams to optimize and scale models for real-world applications - Influence technical decisions and implementation strategies within your area of focus - Experienced in communicating complex technical work to a non-technical audience - The ability to work with minimal guidance, be proactive and to handle ambiguity and the challenge of quickly evolving goals About the team Fauna Robotics, an Amazon company, is building capable, safe, and genuinely delightful robots for everyday life. Our goal is simple: make robots people actually want to live and interact with in everyday human spaces. We believe that future won’t arrive until building for robotics becomes far more accessible. Today, too much effort is spent reinventing the fundamentals. We’re changing that by developing tightly integrated hardware and software systems that make it faster, safer, and more intuitive to create real-world robotic products. Our work spans the full stack: mechanical design, control systems, dynamic modeling, and intelligent software. The focus is not just functionality, but experience. We’re building robots that feel responsive, expressive, and genuinely useful. At Fauna, you’ll work at the frontier of this space, helping define how robots move, manipulate, and interact with people in natural environments. It’s an opportunity to solve hard problems across hardware and software with a team focused on making robotics accessible and joyful to build. If you care about making robotics real for everyone and building systems that are as delightful as they are capable, we’re interested in hearing from you.