AWS Certified Developer – Associate – Passed! with 98% score!!

So I decided to take some time out of my crazy work schedule to get my next AWS certification. I had recently started to write some more Lambda functions and further develop my python skills.

As for the preparation I went through the videos and just focused on the DynamoDB, S3, SWF and SQS as these were the areas that this exam were more focused on. The AWS fundamentals were a breeze (having gone over them a few times before in the AWS SysOps and Architect exams). I was able to get through the video content in about 2 weeks of lunch breaks and just smashed the practice exams every night for a week.

The exam itself I was able to complete it in 20 minutes flat and scored 98%! Only one question I got wrong (which I think was a a result of me rushing to fast through it). I feel that of the three associate AWS certifications this was the easiest but I still was able to learn a few things. Which is what its all about anyway.


Did I mention I got 98% 🙂 Very pleased with that result!


Useful AWS powershell profile prompt

With having a number of AWS accounts to manage you might find yourself lost as to what account and or credentials you are currently using.

The below function when added to you profile.ps1 will modify your powershell prompt with the current shell AWS credentials and region you are using and add a bit of color to it to help you see it.

So when executing AWS commands you “shouldn’t” get lost as to what account you’re in.


It will also remove it if you open up a normal PowerShell window and don’t have any AWS Credentials loaded in the session.


function prompt 

 $prompt = ""
 $prompt1 = ""
 $prompt2 = "PS "
 if ($StoredAWSCredentials -ne $null)
    $prompt1 += "$StoredAWSCredentials"
 if ($StoredAWSRegion -ne $null) 
    $prompt1 += "@"
    $prompt1 += "$StoredAWSRegion"
    $prompt1 += " "
 $prompt += $pwd.ProviderPath
 $prompt += ">"

 Write-Host $prompt2 -nonewline -foregroundcolor Green
 Write-Host $prompt1 -nonewline -foregroundcolor Yellow
 Write-Host $prompt -nonewline -foregroundcolor Green
 Write-Output " "



AWS Certified SysOps Administrator – Associate – Passed!

Having sat the AWS Certified Solutions Architect a year ago I decided in January to go for my AWS SysOps certification. After spending the past year writing Lambda functions, using EC2 considerably more, writing IAM policies and developing some powershell automation around federating IAM and automated managed policy deployments. I felt that the SysOps would be the next ideal AWS Certification under my belt.

The preparation was quite easy the second time around as a majority of the content I was familiar with. I just signed up to for 1 month and was able to smash though the course in 2 weeks.

If you have passed your AWS Solutions Architect Exam I recommend having a go at the SysOps.

Using an AWS Storage Gateway – Keep in mind a couple of things

Just though I’d share a quick note about my experience using AWS Storage Gateway.

After troubleshooting multiple issues on a Windows 2012 R2 file server with Storage Gateway ISCSI presented volumes there were some learning both myself and some AWS contacts had.

So if your using or looking at deploying an AWS Storage Gateway (in “Gateway-Cached” mode) for cheap storage in S3 its a great idea and works well, just be mindful of a few things before implementing it. One of the common use cases posted by Amazon is as a corporate File Sharing (AWS Storage Gateway Overview). After troubleshooting a Windows 2012 R2 Fileserver with

  1. Make sure you configure your AV policy only to perform real time virus scan. (Managing Volumes for Gateway-Cached Volumes) Note: The article states “we don’t recommend using virus scanning software that scans the entire cached volume. Such a scan, whether on-demand or scheduled, will cause all data stored in Amazon S3 to be downloaded locally for scanning, which results in high bandwidth usage.
  2. Customize the Windows ISCSI timeout to 600 seconds (this makes Windows ISCSI connector more tolerant to network disruptions. (How to can be found here: Customizing Your Windows iSCSI Settings and Customizing Your Linux iSCSI Settings)
  3. Windows Volume Shadow Copy (VSS) is not supported. VSS will work initially but once your data your snapshoting via VSS gets to double the cache size you will start to see VSS failing and or not work at all. This was an interesting point as even a number of AWS professionals had expected that this should work. (an AWS case was logged confirming that it wasn’t supported)
  4. Windows data de-dupe can work but requires a chunk of the servers resources to work. You might be able to get some significant drive space savings enabling it but as the Storage Gateway is S3 backed your paying peanuts for it anyway so unless you have a decent business case I would leave this off.
  5. Be aware what happens to the Storage Gateway when it is restarted and how it behaves and the drive status (Understanding Volume Status)
  6. Patching/Updates to Storage Gateway. Updates generally don’t cause any outages its more of a service degradation. This is due to how the ISCSI caches requests while the update is in progress or the Gateway is rebooting (another reason why you should increase the ISCSI timeout) see Managing Gateway Updates Using the AWS Storage Gateway Console
  7. Sizing of the cache and upload buffer. Start with what you believe is the minimum volume sizes, reson being is that when you add volumes to the cache or upload buffer you cant (at this time remove them). So if you have over provisioned you would need to rebuild the Storage Gateway and migrate data in order to shrink the volumes which is just a messy process.
  8. Limits to be aware of (AWS Storage Gateway Limits)
  9. And finally monitoring. Keep a close eye on the gateway metrics as performance degradation can be in different areas. Once to be aware of is the cache hit ratio of the volumes. You want to see around 80% ideally as this seems to be the sweet spot. If your seeing a low value this means that data is having to be downloaded to cache from S3 so you might need to add more space to your cache. (cache usage should also be hovering at 99.9%) so read and understans the metrics to make decisions about possible bottlenecks. See Monitoring Your Gateway

Hope these tips help you out!






AWS Certified Solutions Architect – Associate – Passed!

As Amazon Web Services (AWS) is the largest public cloud on earth and that there some AWS work coming through the business I though it would be an idea time to start learning about AWS. My first serious interest in AWS first started about 12 months ago while reviewing my development plan at work. It was one of a few development goals but what set to be the last goal I needed to achieve for this cycle. So 6 months ago I had started to watch the videos from AWS and do the free labs they offer so I could start to get to know what AWS was all about. After attending the AWS Summit 2014 in Melbourne, AWS had given out $50 AWS credit vouchers. I was thinking sweet I can start spinning up servers and start playing around.

As there was more and more talk about AWS I then decided at the start of Jan I would dive into the accreditation for Solutions Architect. The one unfortunate issue I had was that there was no one in the business I was aware of I could ask about it.

So for the past few weeks I have been busily studying for the AWS Certified Solutions Architect – Associate exam. As the certification has only been around since 2013 I found that there wasn’t a lot of content online (due to NDA for exam questions and there its a lot of people that have this). I though I would share my experience and what I did to pass the exam.

1. Sign up for an AWS account!

2. Get Familiar with the console and watch the intro videos and do the Labs AWS supply. here

3. If you haven’t got anyone to ask (as I didn’t) you need some explanations for some of the concepts. Sign up to a course online There are a couple that offer the course and will give you 70% of what you need to know and at a fraction of the cost. (Attending live training session costs upwards of $2500 while online your looking at around $50-$200)

4. Read the white papers available from AWS. I read:

  • Overview of Amazon Web Services
  • Overview of Security Processes
  • AWS Risk and Compliance
  • AWS Security Best Practices
  • Storage Options in the AWS Cloud
  • How AWS Pricing Works
  • Building Fault-Tolerant Applications on AWS
  • Architecting for the AWS Cloud: Best Practices

They can all be downloaded from here: AWS White Papers 

5. Practice Exam. I spent the $20 for the AWS practice exam to get a feel for the questions. Wile I got 80% (only had 20 questions) this is only n indication of some of the questions you will face. I searched the internet and found a couple of good resources (and some not so useful) to try my hand at.

If you want to expand your knowledge in other areas to help you (if your not to familiar with databases ect.) I found another resource but be warned some of the answer’s are incorrect/outdated so I suggest you do your own research for your own answers so you understand the concept. I found little to none of these questions on the exam but was worth review to better understand other technologies.


So after going through the questions my last suggestion is to research the answered on your own via the AWS console and the AWS documentation. I read through a number of documents just to sometimes find one answer.


You don’t need to be expert in any one OS, but you will defiantly need to know how to access Windows Linux systems and manage EC2 Instances from the command line. Also knowledge of the basic principles of virtualization is very useful. A good understanding of networking concepts and IP addressing. You should be very comfortable with configuring and working with AWS Virtual Private Clouds (VPC). Understanding how using network route tables, access control lists, firewalls, NAT, HTTP, DNS, IP are all needed.

You must understand how AWS access control lists, security groups, and IAM work. Also how other services leverage this in-order to allow/deny access to AWS CLI/API.

You need to be familiar with loose coupling and stateless systems, web servers, caching, application servers, and load balancers, along with message queuing and RESTful Web Services, XML, and JSON. An understanding on how to interact with AWS SDK, AWS API, Command Line Interface and the software development lifecycle are also assumed.


AWS Puppet Labs workshop Melbourne

I was able to attend a Puppet Labs workshop at AWS offices in Melbourne on Monday. New to the Puppet tool I had found quickly that Puppet uses a declarative method of describing a state rather then using procedural code. Something new to me (as well as a lot of other AWS things I have recently been discovering)

There was a real mix of experienced people attending the puppet Lab workshop from those that had used it for some time to the noobs (like myself) who were windows based IT guys.

We were run through the basic setup of a master node and then some of the post configuration to start looking into how puppet starts to take control of files, packages, instillation, services and other configurations. Again the idea of letting go of control and letting the tools do the work for you is a repeated theme that a lot of  engineers (and users) need to adopt if IT want to become efficient. (Cattle not Pets).

Next step for me is to think of things Id like to have under puppet control in a windows lab environment…. Might need to do some more research and come back to that one now that I think of it.

I think most attendees got something out of that day. At the very least working with AWS sniping up servers, becoming more familiar with the interface is always good to practice.


I was there!.. AWS Summit 2014 Melbourne


So the Amazon Web Services (AWS) Summit 2014 has come and gone in Melbourne. It was a full house at the keynote with some breakout sessions having  standing room only.

Being new to AWS  I went to the 101 sessions and found that a majority of the info was aimed more at sales but some of the technical aspects did peak my interest such as moving Microsoft Windows Server workloads and Windows Server applications to AWS and understanding a bit more about licencing with AWS. oh and PS.. Windows Server 2003 will be end-of-life by July 2015.

What were some of the things did I took away from the AWS Summit:

  • Chaos monkey, chaos gorilla and chaos Kong stands out as tools used to deliberately break your AWS (service/servers/region) in order make sure your design is truly fault tolerant by deliberately introducing failures and building automated response to these failures to ensure that you never lose a service/s. (this was my favorite)
  • Think of servers as cattle not pets. Need to move away from the idea when a server has an issue, blow it away and redeploy a fresh one. Less likely spending time trouble shooting less likely engaging vendor support for critical issues.
  • Build teams to a max size that 2 pizzas can feed. Closer collaboration between team members will enhance productivity.
  • What does DevOpsmean? Breaking down barriers. I’m not a developer I come from the Operations side and now building solutions to solve business problems and also have to support them… Does that make me a DevOp…

And the $50 AWS credit will be handy playing with (i mean testing) AWS services. 🙂