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!