AWS Certified Solutions Architect - Progress Report and Notes

At this time, I've finished the second part of my study plan for the AWS Certified Solutions Architect Associate exam. As you may remember, I wanted to knock out CBT Nugget videos before digging into SafariBooks to read the AWS Certified Solutions Architect official study guide.

Now it's time to collect my notes from CBT and move on to the reading portion. Below are some high level notes I've taken:

AWS Infrastructure:

• Uses regions with availability zones, zones are redundant
• Edge Locations are cached Content Delivery Networks (CDNs)

Foundation Services:

• Compute: EC2, LAMDA, Auto-Scaling (Regions)
• Networking: Load-balancing, Route53, VPC (Availability Zones)
• Storage: S3, Block Storage, Glacer, EFS (Edge Locations)

Platform Services:

• Databases: DynamoDB, RDS, Redshift
• Analytics: Kinesis, EMR, Data Pipeline
• Deployment: Elastic Beanstalk, CodeDeploy
• Mobile: Cognito, SNS

Storage Options:

• Instance Store Backed: Physical storage connects directly to instance. Ephemeral so it is not in a permanent location.
• EBS Backed (recommended): Persistent storage using EBS.

Simple Storage Service (S3):

• Account uses bucketes (max 100 buckets)
• Objects are files within buckets (virtually limitless storage)
• Can host static web pages with S3
• Buckets are globally unique names created in a region
• Cannot nest buckets, they can only be Top-level containers
• Objects can be up to 5TB in size
• Bucket+Object+Version maps to unique URL
• Access control can be done at bucket or object level
• Not meant as primary storage for services (i.e. Instances)
• Region specific & supports REST & SOAP
• Server side encryption of data at rest
• Three access controls: IAM, Bucket, and ACLs. You can combine all three methods.

S3 Storage Classes:

• Standard: most expensive
• Infrequent Access
• Glacier: least expensive
• Reduced Redundancy

Elastic Block Store (EBS):

• Storage sizes between 1GB - 16TB (1TB for magnetic)
• Can take snapshots into S3 at anytime
• Use for DB's, Applications, & root volumes
• Backups are incremental
• Good for ephemeral temporary storage, is shared between instances
• Similar to a SAN

VPC:

• Security groups police traffic at instance level
• Network ACLs police traffic at subnet level
• Route tables are similar to VRF's
• Default VPC use subnet 172.31.0.0/16 and IPv6 disabled
• Use NAT Gateway or NAT instance for private to public routing

Identitiy and Access Management (IAM):

• Policies are not cumulative, entities give up old permissions when assuming a role
• Three types of policies (Managed, Custom, & Inline)

Non-Relational DB:

• Top-level organized into 'Tables'
• Tables contain 'Items'
• Items contain 'Attributes'

Auto-Scaling:

• Involves Elastic LB, Cloudwatch (provides info to AS), & Auto Scaling (manages group)
• Auto-Scaling invludes the following:

1.  Launch Config: Config of EC2 instances to be scaled
2. Auto-Scaling group: Defines how much to scale and un-scale
3. Scaling life cycle: Defines when to scale out or in, along with hooking events

Elastic Load Balancing (ELB):

• Can load balance across availability zones
• Cross zone load balancing: Allows you to distribute traffic evenly across all zones
• Can be internet facing or internal only

Cloudwatch:

• Has metrics for most AWS products and services
• Can push metrics via REST or CLI
• Can use SNS or Auto-Scaling

CloudFormation:

• Method to create or manage a collection of resources
• Built with JSON or CloudFormer
• Infrastructure as code
• Uses the components called "Resources" and "Parameters"
• GIT is recommended for version control
• Stack will rollback if there's a problem with its config
• Resources are deleted when the stack is deleted
• "WaitCondition" is used to ensure no 'order of operations' issues

How to Trick your VPC into Acting Like a Service Provider

So how do you solve the issue of routing traffic through a remote VPC to reach another remote network?

Picture the following example, you have your VPC and you have a business partner with their own VPC. You successfully have a VPC peering configured, bidirectional communication, and life is good:

Now what if behind their VPC they had an on-premise network not hosted with AWS that you need to reach as well? Simple right, just have your VPC traffic route to their VPC, and have their VPC route your traffic to their on-premise network via a few static routes:

This is where you'll run into an issue, by default Amazon does not allow traffic not originated from within a VPC to be routed out of its own network. Essentially you're not allowed to use a VPC as transit network (i.e. routing traffic through a BGP AS). Which is understandable as the last thing Amazon need is customers causing routing loops within their cloud environment. To get around this issue, you'll want to use what's called a Transit VPC.

This VPC functions as a hub for both VPC's and outside networks to route traffic to and from each other. Two Cisco ISR's (1000v) function as the back bone for this VPC. These two virtual routers are used for VPN termination, routing, and high availability. From what I understand these Cisco routers have most of the traditional Cisco IOS XE feature set. So maybe you can get creative with using DMVPN, FlexVPN, etc. for additionally dynamic capabilities.

Like anything Cisco though, you do have to pay a premium for this service. However it appears that this is not only the best choice but probably the easiest to implement.

Have you ran into crazy routing scenarios you've had to get around in a cloud or hybrid environment? Would love to hear your war stories and solutions in the comments below:

AWS Shared Responsibility

While AWS is great for quickly provisioning servers and networks without worrying about the back end hardware, there are a few caveats to be aware of. A big one is who's responsible for what in Amazon's Cloud environment? Not really meant to be loaded question, it's important to understand that Amazon can not be held liable for your everything in your custom cloud architecture.

Below are some items you are responsible for within their infrastructure:

• Network access to and from your AWS instances
• Logging
• Patching
• Backups
• Virus Protection of instances

Amazon is responsible for items such as:

• Physical security
• Physical servers, storage, and networking components
• Disk destruction
• Security audites
• DDOS protection (Free Kindle AWS White Paper Below) 

Neither list above is comprehensive but does give you an idea on what you the customer will need to protect on your own. Even something such as login access to your instances is your responsibility. If you happen to loose your private key to an instance, there's not much Amazon can do for you as an example (easy to resolve that problem I know). For the most part if it's anything that's physical or layer 2, you can probably bet that Amazon handles that portion of the cloud.

Hopes this helps, anything else I should add to the list above? Let me know in the comment section below!

Initial Strides with Amazon Web Services (AWS)

I've finished my work provided LMS video series last week and now I'm powering through CBT Nuggets at a fairly fast clip. I estimate that within two weeks I'll be complete with the Nuggets training as well. What's great about learning Cloud is how quick you can ramp up a lab environment as mentioned in my last post. It's really supercharging the time it usually takes to pick up a new technical skill.


To be honest, I'm most excited about the Udemy course as I hear it's very hands on and closely relates to the exam itself. That's also the main reason that I'm saving that piece for last. But using books on Safari always allows me to deep dive into the technology at hand which is why it's included in my study plan.

This is all perfect timing as I'm getting thrown into a few interesting AWS projects. One is how to get around some of the AWS networking limitations. We're needing to communicate between potentially dozens if not hundreds of VPC's due to our engineering testing. How do we accomplish this at scale? How do we limit the time for deployment? How can we make it simple to implement along with using our own proprietary instances? There's a lot of questions to be solved for and this isn't including business aspect of things such as cost (of course) and personnel resource requirements.

VPC Example:

I would love to hear other opinions on rather you think the "Cloud" is hear to stay? If you think so, what are you doing to prepare for it? Talk to you all soon

Beginning AWS Studies

As our company begins to swiftly move services to the cloud, specifically AWS I'm now in a great position to pick up this technology. This will require a paradigm shift on my part, not just on learning the tech but also how I learn and study this info as well.

Before with traditional networking, you could pick up a book or 3, setup a small scale lab if necessary, and be on your way. Since Cloud technology moves so quickly, reading books that are only 2 years old can be out of date already! Not only that but there's so much to cloud services you need a very good grasp on what tools are available to you. The best way is to of course setup your own account with the cloud service and play around with everything available. This is a nice change as in the past with labs, it took dozens of hours planning, purchasing, and setting up hardware before you could even begin labbing.

My AWS study plans will focus on the AWS Certified Solutions Architect - Associate cert. This seems to be the initial starting point everyone recommends. I'm not sure how deep I need to go yet with this material but it's for sure a mile wide the material that I need to learn. Once this cert is completed, I'm most likely going to take a look at the AWS Certified Advanced Networking specialty exam as it makes the most sense to me. For the first exam I plan on using the current studying plan in this order:

• Internal company LMS (Learning Management System) web learning for the AWS course: This will provide me with a very high level overview, I'll begin basic labs as well
• CBTNuggets AWS Associate videos: I'll begin taking notes at this point before moving on. Still debating on older 2013 videos that they have, may be very outdated at this point.
• Safari Books - AWS Certified Solutions Architect Official Study Guide: Associate Exam: This will perform as my deep dive (hopefully) into the AWS material. I will continue note taking along as implementing flashcards using Anki at this point
• Udemy (CloudGuru) course: I'll then prep for the exam itself by going through this course if affordable and available to finish up any lingering topics. I'll also deep dive into labs during this time.

Looking into the future...Cloud

For the past year our family have experienced a lot of new things, challenges, and overall growth. We have a new addition and now we're a family of three! You really do learn to survive on less hours of sleep, very rarely do I sleep for my than 6 hours a day now, less for my wife unfortunately.  Even with that considered we wouldn't have it any other way.

I'm still at it here and there with Python scripting but my big focus for the last year was completing the Cisco Certified Design Professional (CCDP). This exam was absolutely tough and I barely squeaked by but I made it through. Even though I'm not playing much with Cisco at the moment, the concepts hold true for many other vendors as well. The most difficult topics were new tech that I just don't get to play with along with security. Be sure you understand Cisco ACI at a high level and Cisco security IDS best practice designs at a low level.

Next up for me is most likely Sec+ but I've also been taking a hard look at cloud infrastrucure. Our enterprise is heavily focused on moving as much as we can to cloud or at the very least, a hybrid infrastructure. Not much as landed in our Networking team's laps but it's coming down the line fast. Most likely I'll dive into AWS to get a good sense on what it's all about. Because I'll be honest physically racking less equipment is not anything I'll ever complain about!

Stay tuned for further updates and don't forget to check out my Github to the right -->

2016 Recap

A lot has happened this year, including a employer change, new family addition, and new certifications. The employer I work for now has a huge Juniper presense which allowed me to grow my CLI skills with a different vendor besides just Cisco. In order to take full advantage of this change, I went ahead and knocked out a few of Juniper's lower level certifications. I took and passed both the JNCIA and JNCIS-ENT this past summer to help vet my new learned skillset.

Book I used for the JNCIA and JNCIS-ENT Exam:

Along with Juniper we're also rolling out our own NGFW's that rivals many competitors such as Palo Alto. Not only have I had an opportunity to get more hands on experience with our firewalls, I have the chance to administer Juniper SRX's and Palo Alto's which has been very challenging but engaging.

In my past roles I never had much of a chance to deal with network load balancers which always bugged me. While I played around with Cisco ACE's (now extinct) I didn't find them very intuitive with a weird learning curve. This year I've had the chance to deploy and implement virtual F5's using their LTM and GSLB modules. I only touched the GSLB (DNS Load Balancing) very lightly but I did get some great experience with LTM (De-facto Server Load Balancing).

To end the year off, our first little one arrived, which meant that I didn't want to dig to deep into the certification world right now. Instead I'm now diving into Python so that I can script some of the repeatable stuff I do on a daily, weekly, or monthly basis. I'm very noobish but with a help of a fellow colleague, we're starting to make some useful stuff.

Check out my github link to the right ---> I'll be keeping this updated as time goes on and my skill level increases. Hope everyone has a happy holidays, I'm excited for what the next year will bring!