2017 Recap

The year has come to a close, below is a recap of the 2017 goals I've completed for 2017:

• Completed the CCDP exam: This was a big one for me as my CCNP was set to expire this year. The difficulty studying for this certification was at the same level as the CCNP but for different reasons. While the CCNP requires hours of labs and deep diving into CLI configuration, the design exams are on the opposite end of the spectrum. It requires hours of tedious reading of the most obscure white papers and videos. What got me through this exam by far had to be the note taking and Anki flash cards I practiced every day.

• Implemented Wireless Solution from Scratch: I've always been listed as the SME for our wireless solution for the few companies I worked for by happen stance. I never had the opportunity to build out a wireless controller from scratch, survey and deploy AP's, and configure the wireless network. I had my chance a few months ago with Aruba and it was a good experience. If nothing else it gives me the confidence to deploy wireless on a larger scale which is the plan for next year.

• Created useful Python scripts: If you look to the right menu, you'll see my meager attempts here. While these tools are far from optimized they help get my job done when needed. After finishing up the AWS Solutions Architect cert, I plan on digging deeper in Python scripting.

• Finally began Amazon Web Services learning: For the past year I felt like I was falling behind current technology trends. There's only so much OSPF and Spanning-Tree you can learn and provide value to a business. If you look at the latest IT business trends, the shift from on-premise to cloud is a huge thing. I honestly do not know of a decent sized business that's not at least looking at cloud infrastructure. To get a head of the curve, I've jumped head first into Amazon's cloud services.

•  No better way to do this than by studying for a certification to help track your learning progress. I expect to have the AWS Solutions Architect Certification completed in early 2018. I'm currently studying the following book (which is awesome), click the image if you want a copy:

• Committed more time to blogging: This wasn't on my initial list of 2017 goals honestly. But earlier this month, I realized that I've neglected a very useful tool that's helpful not only for my certification studying, but also for my career. It's been a good December getting all of my thoughts and notes on digital paper. I plan on keeping this momentum going throughout 2018.

Well that's it, not too long of a list. I have even more goals for 2018, don't worry I'll be sharing them in the near future. Let me know what your 2017 were and if you completed your all of your goals below!

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