And it all started so wellPosted: March 25, 2017
Well – my first foray into AWS was going so well.. I’ve been using A Cloud Guru for my AWS Architect Associate training and following each of the labs and doing a bit of playing in the background myself. Since getting through the initial S3 and EC2 videos, I brought up a Bitnami WordPress instance to host this site and did the relevant Route53 transfer and what have you. I also moved our wedding website to an S3-Static Site bucket as post-wedding it didn’t need PHP or anything fancy to run.
All seemed well and good.
Then I decided that since I was now hosting ‘live’ sites from my AWS account, I didn’t really want to be meddling with labs and accidentally destroy something.. So I created a new account and went about building a little lab environment: New vPC, subnets for web services, subnets for bastion hosts, scaling groups.. the works! I thought I was doing so well until I tried connecting to the first bastion instance I’d created and got a dreaded SSH time-out!
Cut to the chase: If you don’t want to read the rest, just remember this: Don’t forget a default gateway in the routing table – it doesn’t add itself!
The idiot network engineer
“User error” – I thought. Obviously. So I walked through my configuration:
- ElasticIP associated.. check.
- Instance attached to Subnet.. duh, check.
- Subnet associated in routing table.. check.
- vPC associated with Internet Gateway.. check.
- Security group has sensible ruleset (SSH and HTTP/s inbound from 0.0.0.0/0).. check.
So I still couldn’t see what the issue was. Now, at this point, I hadn’t done any training on CloudWatch, but I noticed in the vPC configuration I could do something with Flow Logs. So a bit of playing around and following the on-screen “You’re trying to do something you’re not ready for yet“-type instructions, I got flow information for the vPC going into a log and I could drill down on a per-instance basis.
Now I could see what was going on.. Nothing wrong with the rules, my ping’s and SSH attempts clearly had ‘ACCEPT’ next to them, so the inbound path was fine.
Then it dawn on me… stuff is getting in, but how is it getting out – or more precisely – does it know HOW to get out? So back to look at the routing table I went, with the sudden realisation that there was no default route! Doh! And I’m supposed to be a network engineer!
So what’s the lesson here: An AWS Internet Gateway isn’t given the default route by default.. makes sense, you might want to use a vASA or something
What good came out of this.. I learnt how to use CloudWatch