My path to AWS Certified Solutions Architect – Associate

Almost a week and a half ago, I sat for and passed my AWS Certified Solutions Architect – Associate  (AWS CSAA) exam. To be quite honest, I felt the biggest sense of relief, after walking out of the exam centre, not because I had passed, but because I had finally forced myself to sit this exam.

Since posting on LinkedIn about passing my AWS CSAA exam, I have received a lot of requests from people, asking for tips on how to prepare for this exam. In addition to replying to them, I thought best to also put up a blog post, to help others that might be preparing to sit for the same exam.

I have been a Microsoft person for years, so it was quite natural for me to transition to Microsoft Azure a few years back. Microsoft Azure, to put it simply, is awesome. It empowers its users to grow their IT much faster and beyond what their local datacenter’s can accomodate, with a simple, pay-as-you-use model. This model has helped so many businesses become successful, in such a short amount of time.

I start my New Year, each year, with a list of technologies that I had been introduced to, in the year that had just finished, but did not get a chance to properly get acquainted with. This list, then condenses into my list of todos for that year. Last year, AWS made it into my list and since then I have been spending time, finding out all about it.

Exams to me are not just a certification, but a chance to find more about a technology and to re-confirm my understanding of it. That is why I try my best to learn as much as possible about the technologies being tested in an exam. What better way to learn more about AWS then to do the AWS Certified Solutions Architect – Associate exam 😉

I got my training material from https://acloud.guru Ryan Kroonenburg teaches an awesome course to get one prepared to sit for the exam. The course is not too expensive either, well within the budget of anyone.

However, a note of caution. If you are very new to AWS and think that just doing the course will be enough to pass the exam, then there is some news for you. The whole basis for the AWS exams is to test you on your hands on experience and just cramming the information and proceeding to sit for the exam will be preparing yourself for a fail. I would highly recommend doing the labs that Ryan takes you through in the course. AWS provides a free tier, which covers almost all that you will need to train for the AWS CSAA exam. You can make use of this to get lots of hands on training. Also, read the whitepapers and faqs. These provide detailed information about the AWS services. ACloud.guru also has forums where you can ask questions and also answer questions others have posted.

To recap, my tips for passing the AWS CSAA exam

  • purchase the ACloud.guru course for AWS CSAA
  • go through the videos in the ACloud.guru course at least twice and do all the labs
  • answer all the section quizzes, the Mega Quizzes and Final exam questions and do them till you get at least 90% correct
  • read the AWS whitepapers and FAQs
  • participate in the ACloud.guru forums

You will soon realise that you are confident enough to sit the exam and that is when you book it and go sit for it.

I would highly recommend not waiting too long to sit for your exam (I have learnt from my mistake). I find that if I wait for more than a month to book my exam, I normally start forgetting all that I have learnt, and have to go over the material all over again. Everyone is different, so this might not be true for you. I would suggest aiming for 1 month of training, however in the 2nd week, book your exam for a date 2 weeks away. Doing this will firstly put you in panic mode, but then you will soon realise that you don’t have much time to study, and will start studying more intensely. By the last week, if you still think you are not fully prepared, you have 72 hours to reschedule the exam. If you are going to reschedule, then don’t reschedule to a date too far in the future.

I wish you all the best for the exam.

Re-execute the UserData script in an AWS Windows Instance

Bootstrapping is an awesome way of customising your instances in AWS (similar capability exists in Azure).

To enable bootstrapping, while configuring the launch instance, in Step 3: Configure Instance Details scroll down to the bottom and then expand Advanced Details.

You will notice a User data text box. This is where you can provide your bootstrap script. The script will be run when your instance is first launched.

AWS_BootstrapScript

I went ahead and entered my script in the text box and proceeded to complete my instance configuration. Once my instance was running, I initiated a Remote Desktop connection to it, to confirm that my script had run. Unfortunately, I couldn’t see any customisations (which meant my script didn’t run)

Thinking that the instance had not been able to access the user data, I opened up Internet Explorer and then browsed to the following url (this is an internal url that can be used to access the user-data)

http://169.254.169.254/latest/user-data/

I was able to successfully access the user-data, which meant that there were no issues with that.  However when checking the content, I noticed a typo! Aha, that was the reason why my customisations didn’t happen.

Unfortunately, according to AWS, user-data is only executed during launch (for those that would like to read, here is the official AWS documentation). To get the fixed bootstrap script to run, I would have to terminate my instance and launch a new one with the corrected script (I tried re-booting my windows instance after correcting my typo, however it didn’t run).

I wasn’t very happy on terminating my current instance and then launching a new one, since for those that might not be aware, AWS EC2 compute charges are rounded up to the next hour. Which means that if I terminated my current instance and launched a new one, I would be charged for 2 x 1hour sessions instead of just 1 x 1 hour!

So I set about trying to find another solution. And guess what, I did find it 🙂

Reading through the volumes of documentation on AWS, I found that when Windows Instances are provisioned, the service that does the customisations using user-data is called EC2Config. This service runs the initial startup tasks when the instance is first started and then disables them. HOWEVER, there is a way to re-enable the startup tasks later on 🙂 Here is the document that gives more information on EC2Config.

The Amazon Windows AMIs include a utility called EC2ConfigService Settings. This allows you to configure EC2Config to execute the user-data on next service startup. The utility can be found under All Programs (or you can search for it).

AWS_EC2ConfigSettings_AllApps

AWS_EC2ConfigSettings_Search

Once Open, under General you will see the following option

Enable UserData execution for next service start (automatically enabled at Sysprep) eg. or <powershell></powershell>

AWS_EC2ConfigSettings

Tick this option and then press OK. Then restart your Windows Instance.

After your Windows Instance restarts, EC2Config will execute the userData (bootstrap script) and then it will automatically remove the tick from the above option so that the userData is not executed on subsequent restarts (or service starts)

There you go. A simple way to re-run your bootstrap scripts on an AWS Windows Instance without having to terminate the current instance and launching a new one.

There are other options available in the EC2ConfigService Settings that you can explore as well 🙂

 

Usable IP Addresses in an Azure {and AWS} Subnet

Over the last week I got asked an interesting question.

“Why is it that you always give x.x.x.4 ip address to you first Azure virtual machine? Why don’t you start with x.x.x.1 ?”

This is a very interesting question, and needs to be kept in mind whenever transitioning from On-Premise to Azure. In Azure, there are a few IP addresses that are reserved for system use and cannot be allocated to virtual machines.

The first and last IP addresses of a subnet have always been unavailable for machine addressing because the first IP address is the network address and the last is the broadcast address for the subnet.

In addition to the above, the next 3 IP addresses from the beginning are used by Azure for internal use.

Always keep the above in mind when allocating IP addresses in Azure.

Below are some helpful links that can provide more information

https://azure.microsoft.com/en-us/documentation/articles/virtual-networks-faq/

https://www.petri.com/understanding-ip-addressing-microsoft-azure

I came across a similar article for AWS. AWS also removes 5 IP addresses from the pool, for internal use. However, this article was more informative in regards to why these IP addresses are unavailable. I have a suspicion that Azure has the same reasons, however I couldn’t find any article on it.

Here is the AWS article http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Subnets.html

and below is the section that describes why the IP addresses are unavailable in AWS

The first four IP addresses and the last IP address in each subnet CIDR block are not available for you to use, and cannot be assigned to an instance. For example, in a subnet with CIDR block 10.0.0.0/24, the following five IP addresses are reserved:

  • 10.0.0.0: Network address.
  • 10.0.0.1: Reserved by AWS for the VPC router.
  • 10.0.0.2: Reserved by AWS for mapping to the Amazon-provided DNS. (Note that the IP address of the DNS server is the base of the VPC network range plus two. For more information, see Amazon DNS Server.)
  • 10.0.0.3: Reserved by AWS for future use.
  • 10.0.0.255: Network broadcast address. We do not support broadcast in a VPC, therefore we reserve this address.