As an aside I think there are much better places to ask career growth questions than this channel, let me know if you'd like some pointers

@paulm thank you so much for this response. making changes with less stress is a great requirement

I'm realizing from both your responses how much where I'm at now is similar to my couple years ago "which programming language should i learn" - i was torn between python and javascript but now i know both and more. so yeah i see how jobs exist using almost any part of AWS, just like jobs exist with many major programming languages. but one has to ask what do i want, whats interesting for me, but also see that starting somewhere will lead you other places and that's ok.

phase 1: single ec2 instance, with nginx and pm2 - both front end and back end on there. using an elastic ip and pointing my domain's DNS to that. phase 2: setting up s3/cloudfront for front end, uploading manually an npm run build artifact to s3. pointing that to my ec2. this is also where IAM came into play, and also ACM. previously I just used certbot. phase 3: dockerizing. so same set up but now backend ec2 is running a docker image that is pulled from ecr. i think what i had then was nginx takes requests to given port and sends them to the container. this set up doesn't really make sense on its own but is a key prerequisite for the next phase phase 4: ALB + autoscaling. This was probably the hardest part, just a lot of settings, a lot of CORS issues, my app has JWT there was some weird bugs I needed to figure out here that had been mitigated by using a single instance that were now breaking. So I deleted everything down from my ec2 except the docker container. Then I created an image from that. used that as the image for the ec2 target group. created an autoscaling group from the target group. End result, when there are multiple instances live, ALB round robin's the requests to them. I defaulted desired minimum to 1, max to 3 or 4. I had written a benchmark test that bursted the single ec2 instance. I was hoping that it would trigger new instances with ALB and ASG - but I underestimated how long spinning up takes and my test wasn't long enough. I did get to show that what failed on 1 instance worked on 3 instances manually scaled horizontally which was cool. by this stage the problem is the manual nature of what it would take to make a change, I'd have to essentially manually git pull, create docker container, then replace the ECR entry for backend. For frontend I'd have to run a new npm run build, and then manually upload that to S3. thus, phase 5: cicd. I used github actions to create process that does the following. Since it's a solo project I treat pushing to main or merging my own PR as an approval. On pr it just runs tests. On push, it runs backend tests and lints the frontend, if those pass it runs e2e, if those pass it deploys what has changed, backend, frontend or both. If deploy is successful, that becomes prod, once prod a few more tests are applied - if those fail, then it rolls back to the previous version which was just saved as an image. I definitely pair programmed this with claude, and sometimes it took the lions share - I felt time pressure to get to the end of phase 5 so I can move on to some other projects, but also because I thought learning everything in detail might make more sense once I had done one successful set up. I definitely questioned or suggested every design decision throughout the process and tried to learn everything I could. It's really cool to see the graph on gh actions.

i did it all ARM, with t4g.small for my ec2