What Should I Expect When Starting as an AWS Infrastructure Engineer?

The CLI is a daily driver for many infrastructure engineers, but that doesn’t mean memorizing every command or flag. Most people remember a small set of frequently used commands—things like checking the current AWS identity—and look up everything else. Terraform is a good fit for persistent infrastructure changes, while the console is useful for exploration, troubleshooting, and walking through something with a colleague. The CLI or SDK is usually best for repeatable operational work and automation.

Documentation is a much bigger part of the job than it may seem. Experienced engineers still read service documentation, examples, API references, and sometimes first-party code. Familiarity reduces the time needed, but new services, edge cases, and unfamiliar features still require research. AWS documentation quality varies, so understanding the underlying service capabilities and your actual requirements matters more than finding one supposedly perfect snippet. For especially complex designs, AWS Support or a solutions architect can also be useful.

My workflow is mostly Terraform or Python, written and tested from a terminal. I use the AWS CLI selectively rather than for every operation. Documentation time also depends on the system’s maturity: established platforms may only need occasional research, while learning a new service can take considerably longer. As for CodePipeline, some teams use it everywhere because it is their standard, but others avoid it and use a different build or deployment system. The best choice is usually the one your team can operate and troubleshoot reliably.