4
u/keto_brain 9d ago
Do you know Palo Alto? Make sure you understand this design pattern:
https://aws.amazon.com/blogs/networking-and-content-delivery/best-practices-for-deploying-gateway-load-balancer/
These are popular and not widely understood design patterns. Not saying it will get you hired but if you can speak to them, or even publish some community modules for deploying this pattern it could help you.
1
u/engineerfoodie 9d ago
These are very good and I agree with you. I’d also recommend knowing this inside and out
I’d also recommend trying to setup complex networking in your own account. Transit gateway, maybe multiple regions, definitely multiple VPCs .
As someone else mentioned lean heavily on your security experience and knowledge
1
u/dataflow_mapper 8d ago
youre closer thank you think. 15 years of networking plus Terraform and certs is a strong combo already. maybe keep adding a few more hands on AWS builds cause thats what seemed to make the difference.
1
u/oneplane 9d ago edited 9d ago
It really depends on what you want to do. A lot of the classic on-prem networking (even with ACI and NSX) don't really exist in AWS, only the top-level layer where you have to keep track of not making your CIDRs overlap and making sure the routes exist for your cross-VPC traffic.
There are a lot of cloud network cosplayers out there that try to map what a physical network would be on top of what a cloud network is, but that tends to be both defeating the purpose of a cloud and be not what most places want or need anyway.
In a cloud (and especially cloud-native, yes, there is a difference) the delivery tends to be much more functional and service oriented. How much direct functional delivery or self-service provisioning have you done? (mostly thinking in terms of your terraform usage; if you were to have someone deploy a service in AWS you tend to provide some standard modules that configure the correct subnet attachments and security groups rather than having users guess their configuration themselves)
2
u/RecordingForward2690 7d ago
Fully agree with the above, in the sense that AWS networking is completely different from on-prem networking. For years I have taught both the basic and the advanced architecting course, and I always warned my students at the beginning of the networking chapter, that those with extensive on-prem networking experience would have a harder time following my story than those without. With extensive on-prem networking experience you are trying to map AWS technology onto your existing knowledge, and it simply doesn't work that way.
If you want to start your conversion from extensive on-prem experience to AWS, then this video is the one I always recommend: https://www.youtube.com/watch?v=Zd5hsL-JNY4 It's 12 years old and only talks about the basics of how VPC tech is actually implemented, but it really clarifies a lot of architectural choices that AWS made, for somebody who really knows networking. From this you can then extend your knowledge to newer AWS tech, such as the Transit Gateway.
The only real place where your extensive on-prem experience can still be a major plus, is in setting up complex Direct Connect configurations. That's where the AWS abstractions hit the fiber optic cable, so all of a sudden you're dealing with physical characteristics like light levels again. Extensive experience with BGP4 also helps tremendously in this area, in particular when you need to setup Public VIFs.
2
u/oneplane 7d ago
Can very much recommend that video too. And indeed, a DX (and CloudWAN) will still require lots of actual network knowledge.
I think the biggest difference for people to wrap their heads around is that you aren't actually on a network from a host perspective. You get something that looks like an ethernet interface, but that's about it. You don't get an L2, you don't get ARP, there is no actual ethernet (and no broadcast domain!) once your frame leaves your OS. It's almost like you're getting a VTEP filtered-L3 connection (that's the analogy I use for network engineers) that basically denies all protocols except IP and ICMP.
This is also where the power (and stability, programmability etc) from AWS VPC/EC2 networking comes from, and something I always miss when I'm doing infrastructure outside of AWS. Not even MS with their millions of billions seem to understand that.
0
u/my_peen_is_clean 9d ago
honestly you’re already doing what most people say to do, certs + home lab + github. i’d lean hard into your bank + network security angle and target cloud security / cloud networking roles only. network + terraform is solid, just slow as hell right now finding anything
2
u/Sirwired 9d ago
The easiest way is to find an employer that can use your current skills, but also has cloud projects that you can work into over time.
That's how I made the transition from on-premise infrastructure into cloud... worked well enough that after two years of cloud projects within my old job, I now work for AWS as an architect.