AWS Certification Journey: Solutions Architect Associate

This time last year, I was counting down the last few days until I was to sit my first AWS certification exam, the Solutions Architect Associate. Starting in October of 2018 I’d decided that this would be the course I’d take next and began working toward skilling myself up in all things AWS. There is a lot of conceptual overlap between virtualization and Cloud, so personal experience combined with about three months of study led to my passing and achieving the cert.

I thought I’d share the things I used on the off chance anybody else finds it useful. What I find most useful is to identify more than one resource to get a different perspective on the objectives and, with the case of the book, it was also nice to be able to study offline. With the SA Associate certification, I used a combination of the exam blueprint, a textbook, multiple online classes, and (most importantly) hands-on experience. All told, it was a personal investment of only about $350, including the exam fee and any overages that may have exceeded the free tier.

The guidance from the two online courses was excellent and also provided a good deal of hands-on experience.

After you identify the resources you intend to use to study, the next thing you should do is pick a date for the exam and actually schedule it. The commitment of placing actual money is a great motivator. Scheduling will give you a deadline to work towards, not only making the goal real but providing a sense of urgency.


Book Recommendation: Terraform Up & Running

Quick book recommendation: Pick up Terraform: Up & Running when you get a chance. Great tool to add to your Cloud toolbelt for automating provisioning and adding on Infrastructure as Code.

I will post a more in-depth “review” when I’m done, but now half-way through and I’m already definitely finding it useful.


The “Right” Way to Access Private EC2 Instances

Accessing private EC2 instances from a public jump host presents a potential security issue. Every instance must be accessed using a private access key, but storing this key on the jump host is a bad (actually, very bad) idea. If stolen, this could allow any of your systems configured with the key to be compromised.

Try using ‘ssh-agent’ from your local system to store and use your private keys. This will allow your jump host to forward along or proxy the authentication without having to upload or share the key.

# Step 1 is to actually start 'ssh-agent'
# This outputs the commands to set the necessary environment variables
# and will display the PID of the agent.  
# Example:
$ ssh-agent
SSH_AUTH_SOCK=/tmp/ssh-wlp2yfs0IEW8/agent.16882; export SSH_AUTH_SOCK;
echo Agent pid 16883;

# Step 2 is to store your private key using 'ssh-add'
# ssh-add privateKeyName.pem
# Example:
$ ssh-add kpSuperSecret.pem
Identity added: kpSuperSecret.pem (kpSuperSecret.pem)

Once the access key is stored locally, you can simply connect to your jump host with SSH as normal. From there, accessing the private hosts just requires you to add the “-A” flag:

$ ssh -A

# And then, on into the private instances:
$ ssh ec2-user@ip-someInternalIP.ec2.internal