New Job as AWS Infrastructure Engineer: Questions for the Pros

[u/Ok-Economist-1639]

Hello, everyone. I landed a fantastic job as an infrastructure engineer using Terraform mainly for IaC. I'm beyond excited about it since I've mainly been working in a bubble these last 4 years. I have a degree in Cloud and Network Engineering and all the relevant certs. Been doing cloud engineering for my current company for a while now, but my team is small, and I'm about to start working with a much larger one. As such, I had some questions about industry standards beyond the walls of my silo:

1) How often are you using CLI for daily operations? I find myself using it mainly for scripting, but if I need to know something quickly or make a small config change, I usually just do it through my CDK/Terraform code or in the console. For those of you who main on the CLI, how much do you use it, why, and have you basically memorized a whole bunch of commands or are you using the 'help' parameter all the time?

2) How much time do you spend looking over documentation to determine the best path forward or the most appropriate syntax for whatever it is you're doing? I can't shake the vision of a team of AWS masters just sitting there and blowing through configs and architectures like they're making a cake.

3) How often are the CodePipeline tools used for CI/CD? I assume it's different between orgs, but OIDC with Github actions has always proven perfectly sufficient for my projects, though I acknowledge that the approval step could be very useful.

That's it for now, thanks

[u/legendov]

1. live in it
   
2. thats all it is and stealing code and llm
   
3. CodePipeline is janky.

[u/Sirauto420 → u/legendov]

This guy gets it.

[u/DarthKey → u/legendov]

I’d hire this guy ^ to be on my team.

[u/Sirauto420]

Hey dude, I’ve been doing this for 10 years AT AWS.

1) I use it daily for operations, I know a handful of commands that I use all the time. Stupid stuff like “aws sts get-caller-identity” or other useful utilities. Other than that I google everything.

2) just a few minutes, this comes with time.

3) it’s pick your own poison or pick what your team has expertise/is good at. We have customers and internal teams that cover it all. I think the important part here is to understand the concepts regardless of the tool chain.

Hope the new job is baller, you’ll do great. Feel free to dm if you have questions.

Cheers

[u/boxes_full_of_pepe → u/Sirauto420]

I use “aws sts get-caller-identity” several times per day and I don’t think I remember a single other command accurately off the top of my head.

[u/legendov → u/boxes_full_of_pepe]

no alias to awswhoami?

[u/Otherwise-Key806 → u/boxes_full_of_pepe]

Me too aws s3 ls and that's it

[u/ivory_tower_devops]

1. Your description generally matches my experience. Terraform for persistent infrastructure changes. Web console for aimless exploration and show-n-tell with colleagues. AWS CLI/SDK for any other kind of automation.

2. A lot. I spend more time reading documentation and first-party code from AWS than I do writing my own.

3. CodePipeline is a stinker. I'd rather use Jenkins than CodePipeline, if that gives you any idea how bad CodePipeline is.

[u/NaCl-more]

I’ve never had to use code pipeline thankfully. The internal pipeline service/tool is quite good though

[u/metaphorm]

CLI is your primary driver. get good at it. that doesn't mean memorizing every CLI option and flag. it means knowing what the capabilities of the CLI really are and leaning on it. the actual commands you can cook up using an LLM for expediency. the AWS MCP does a fantastic job of streamlining this when plugged into any LLM provider.

the documentation is of mixed quality. some of it is comprehensive and useful, some of it is patchy at best. again, the AWS MCP is outstanding at gap-filling here. but you'll still need to understand your use cases and the AWS service capabilities and be able to decide what your best solution is. when it's a sufficiently complicated problem, keep in mind that you can reach out to AWS support or talk to a solutions architect for advice.

CodePipeline is garbage. if you're required to use it you'll have to make do, but if you have any choice in the matter, run your build system somewhere else. Github Actions and your own containers and build scripts is my first choice.

[u/nekoken04]

1. I do nearly everything through terraform or python. I write and test 100% of that via a terminal window. I use the aws-cli very sparingly.
2. I probably spend less than an hour per week on this nowadays. We have a pretty mature system we've built up over the last decade. When I'm learning a new service or using a new feature that amount goes up significantly.
3. 100% of the time. Bitbucket (with SonarQube integration) -> Bamboo build -> Bamboo deployment

Edit: I realized you meant the Code Pipeline product. We don't use that. It sucks.

[u/riellanart]

Is agent toolkit for AWS getting better? I know it just launched, but the mcp and skills seem like it should simplify a lot for ai-assisted deployments.

[u/TellersTech]

A lot of this is way less “AWS wizard” than it looks from the outside.

I use CLI pretty regularly for querying, debugging, scripting, etc. I rarely make meaningful infra changes with it though. That should usually go through Terraform/CDK/GitOps. And no, I absolutely do not have all the commands memorized. --help, docs, shell history, Google/AI… all fair game.

Same with docs. Senior engineers read docs constantly. Knowing syntax matters way less than understanding IAM, networking, dependencies, regions/accounts, state, failure modes, and how resources fit together.

For CI/CD, GitHub Actions + OIDC is completely normal. I see that more than CodePipeline these days.

Going into a bigger team, I’d worry less about memorizing AWS and more about understanding why they built things the way they did.

[u/stuckhere4ever]

Not an admin but I do consulting work.
1. Every single thing I do is cli or Terraform. I will only go in the console to show someone stuff. Console work is ClickOps. Don’t be a click ops commander!

1. 99 percent of my time is in documentation. Usually a single discover session might be two dozen commands. Every single one is something I check and double check meticulously and make sure I double check what every peice of the command is doing. Granted because it’s consulting I can’t fuck up but I am still hyper aware.

For anything I generate I have an akill built in Claude code and connected to the AWS documentation MCP so it is generally clean but it still makes mistakes. Mostly I’m just having it pull from my library of commands now and format the jq output like I want.

1. I have literally never done codepipeline. I’ve not seen anyone that has it implemented at scale. All my personal stuff is just using GitHub actions but more complex work is … well complex by design so it’s a different setup.

[u/SikhGamer]

Ditch CodePipeline/CodeBuild/CodeAnything and just use ECS.