AWS Certified Solutions Architect Associate ELB & AutoScaling Study Sheet

AWS Elastic Load Balancer is the “card dealer” that evenly distributes “cards” [traffic ] across “card players” [ EC2 instances ] .

Works across EC2 instances in multiple Availability Zones

  • supports http, https, TCP and SSL traffic / listeners
  • uses Route 53 DNS CNAME only
  • supports internet facing and internal
  • supports SSL offload / SSL termination at ELB, relieving load from EC2 instances

Idle Connection Timeout and Keep Alive Options


ELB sets the Idle timeout at 60 seconds for both connections; and will timeout if data is still being transferred.  Increase this setting for longer operations, ( file uploads ), etc.

For https and http listeners, use Keep Alive  load balancer to re-use back-end connections, reducing CPU.

AWS Cloud Watch for ELB and EC2

Service for monitoring all AWS resources and application in near real time. Collect and track metrics, collect and monitor log files, set alarms and react to changes in AWS environment. [ SNS notifications, kick off auto scaling group ]

Basic Monitoring / Every 5 minutes  [ DEFAULT ]

Detailed Monitoring / every 1 minute ( more expensive ) 

Each account limited to 5000 alarms.

Metrics data retained two weeks by default.

CloudWatch Logs Agent available for automated way to send log data to CloudWatch Logs for EC2 if running AWS Linux or Ubuntu.

The AWS/EC2 namespace includes the following default instance metrics:

CPU Metrics, Disk Metrics, Network Metrics,.

Auto Scaling and Launch Configuration

A Launch Configuration is basically a template that AWS Auto Scaling will use to spin up new instances. Launch Configurations are composed of:

  • AMI
  • EC2 instance type
  • Security Group
  • Instance Key Pair

Auto-Scaling is basically provisioning servers on demand and releasing them when no longer needed – you spin up more servers when there is peak demand; e.g., black Friday, World Series ticket sales . .

Auto-Scaling Plans:

Maintain Current Instance Levels – health checks on current instances; and if one dies; another will replace it.

Manual Scaling – This is a bad name for this group; because the auto-scaling itself is still automatic, the metrics input is manual .. e.g., you tell a change in the min, max capacity [ metrics, think max CPU, etc.. ] of group and Autoscaling will spin up more instances when your metrics are seen.

Scheduled Scaling – For predictable behavior [ Black friday thru christmas ] all actions performed automatically as a function of data and time.

Dynamic Scaling – you define different parameters, using cloud watch logs, network bandwidth ,etc

Scaling Policy

A scaling policy is used by Auto scaling with Cloud Watch alarms to determine when your AS group should scale in or scale out. Each Cloud watch alarm watches  a single metric and sends a message when the metric breaches a threshold.

AWS Certified Architect Associate VPC Study Sheet


As a Network Engineer; it fascinates me what Amazon has done to virtualize the Network in its Virtual Private Cloud.   Here go the notes!

AWS VPC is a logically isolated section of the AWS Cloud, a virtual network in which you can launch your EC2 instances that can be private or public.

All AWS VPCs contain: subnets, route tables, DHCP option sets, Security Groups and ACLs.

Optional VPC elements are: Internet Gateways, Elastic IP. Elastic Network interfaces, EndPoints, Peering, NAT servers or Gateways, Virtual Private Gateway, Customer Gateways, and VPNs.

Largest Subnet in a VPC is /16  Smallest Subnet is /28.

One Subnet per one Availability Zone; and do not span Availability Zones 

VPC Route Tables:

VPC has a Router (Implicit).

VPC comes with a “Main” Route table which you can change; and you can also create separate routes tables within your VPC that are not associated with “Main”.  Each subnet you create has to be associated with one of the route tables.

VPC Internet Gateways [ IGW]:

An AWS VPC Internet Gateway is a Horizontally Scaled, redundant, highly VPC component that allows communication between your EC2 instances and the internet. [ Basically default route Target out points to the IGW ]

IGW’s must be attached to VPCs

Route table must have a route to send all non-VPC traffic out.

ACLs and Security Groups MUST be configured so the bad guys don’t get in .

Below image is from AWS:


AWS automatically creates and associates a DHCP Option Set for your VPC and sets two options: 1. DNS servers 2. Domain-Name. These are set to Amazon default DNS and Domain name for your region.  To assign your own Domain name; you can create a custom DHCP option set and configure the following:

  1. DNS servers
  2. Domain-Name
  3. NTP Servers
  4. NetBios Name servers
  5. NetBios Node type.

Elastic IP addresses [ EIP ]: 

These are AWS Public IP Addresses that you can allocate to your account from their larger pool; reachable from anywhere on the internet.

  • Create the EIP first for your VPC; and then assign it to an EC2
  • EIPs are specific to a region
  • One to one relationship between network interfaces and EIP
  • EIPs can be moved from one EC2 instance to a different EC2 instances.
  • EIPs remain with your account until you release them.
  • There are charges incurred fro EIPs allocated to your AWS account; when they are not in use.
  • charged when instance is stopped; charged when un-attached
  • Free only only one EIP per instance and instance is running.

Elastic Network Interfaces [ EIN ]:

This is a network interface available within a single VPC that can be attached to an instance; and are associated with a subnet when they are created

  • Can have one public and multiple private IPs
  • Can exist independently of Instance
  • Allow you to create a management Network, use Network and Security AMIs/Appliances create dual-homed solutions.

VPC EndPoints

VPC Endpoints allows you to create a private connection between your VPC and other AWS servers without going over the internet. Works with Route TAbles; where Endpoint for particular service can be a target.

VPC Peering

Allows for communication between two VPCs; e.g., communication from instances in one VPC to instances in another VPC.

  • you can create peering with your VPC and:
    • another VPC in your account
    • VPC in another AWS account
  • within a single region

Peering Rules:

  • no peering between VPC that have matching over overlapping CIDR blocks
  • cannot peer with VPC in different Regions
  • No transitive peering
  • No more than one peering connection between two VPCs

Security Groups (SG) in a VPC

A security Group is a stateful Firewall that controls inbound and outbound network traffic to individual EC2 instances and other AWS resources.  All EC2 instances must be launched into a Security Group. Only the Default Security Group  allows communications between all resources in that same Security Group . Instances in Security Groups you create cannot talk to each other by default.

  •  500 SGs per AWS VPC
  • 50 inbound, 50 outbound rules for each SG
  • 5 SG’s per network interface
  • applied selectively to individual instances
  • Can specify ALLOW rules / but no DENY [ whitelist ]
  • By default, no inbound traffic is allowed from anything not in SG
  • New SGs by Default have a permit all outbound.
  • Stateful
  • Evaluates ALL rules before deciding permit / deny

Network Access Lists (ACLs)

so you Cisco guys, this is pretty much the same. . .

Subnet Level, state-less, number set of rules, processed top down.  VPCs have a default ACL associated with every subnet that allows all traffic in and out. When you crate an ACL, its deny all until you create rules.

  • Supports allow Rules and Deny rules
  • State-less, return traffic MUST be called out
  • processed in order
  • Because at Subnet level, applied to all instances in that subnet

NAT Instances ( AMI ) on VPC

AMIs on AWS that have the amzn-ami-vpc-nat – use is taking traffic from private subnet in VPC and forwarding it to the IGW ( Internet Gateway ) .

You need a SG will appropriate Rules / in and out

Launched in a PUBLIC subnet in VPC

-Disable Source / Destination Check of NAT or it won’t work 

Subnet with PROV host will have NAT host as the destination in the route table: goes to > [NAT instance name]

NAT Gateway on VPC

Designed to operation like the NAT AMI, but easier to manage; ( no EC2 isntance to patch ); and highly avaialble within an AZ.

VPN, VPG and CGW in a VPC

A VPG ( Virtual Provate Gateway ) is the VPn concentrator on the AWS side of a VPN connection.

A CGW represents a physical device on the customer’s network; thier end of the tunnel.

The VPN handshake must be initiated on the customer’s side.

EC2 Virtualized Types

Hardware Virtual Machines  (HVM) vs. ParaVirtual Machines  (PV)

HVM AMIs – fully virtualized set of hardware and boot executes master boot record of block device of image; has support for special VM extensions ( GPU accelerator ).

PV-AMI – Use PV-GRUB boot loader; runs on hardware without explicit support for VM; but no special extensions; currently only C3 and M3 types can be used.

T2 instances must be launched into a VPC ( not supported in classic )

T2 must be on HVM AMI

Recommended use current generation instance types on HVM AMIs

AWS Workshop Automating Security in the Cloud in Denver: Day 1

When I found out AWS was going to be doing a two day Security class in my home town at the end of April, I took no chances and simply requested two days PTO so I could go to this event.

Day one CORE content was taught by Tim Sandage , Senior Security Partner Strategist, AWS. Tim knows his world very well and relayed the material in a clear and concise way, keeping the audience engaged at all times.

There were a slew of Cloud Security Vendors there as well, my favorite vendor presentation was by Aaron Newman, CEO Cloudcheckr. Aaron is a very passionate and dynamic speaker – and the Cloudcheckr Product is gives solid, Security centric view of your AWS assets.

Some of the ideas presented below carry over from standard on-prem Infrastructure Security, such as Principle of Least Privilege; and some are unique to Cloud – CloudFormation Templates.

Below are my notes, transposed here from furiously fast handwritten catch during the event. Please excuse any brevity; partial sentences, etc.

Tim Sandage Notes: DevOps is Rising. Shortage of individuals to maintain Security.  DevOps needs Security engrained into their process. Focus on Continious Risk Treatments (CRT). Need to bring Security Risk treatment into DevOps Lifecycle. Technology drives governance. Governance is shared between AWS and end customer. Security Automation is key to Successful Governance.  API is the common language through which Policy can be automated.

AWS is a SHARED Security model. Security by Design ( SbD ) is an AWS assurance approach that formalizes account design and automates control and auditing. Cloud Templates / Cloud formation is key.

Continuos monitoring is not enough, it does not catch bad guys; we need to create a workflow to help with tech governance.

Security is top priority at AWS. AWS has over 1800 accreditation/ certifications geared toward being a compliant provider for its customers.

When moving to the Cloud, consider the boundary extensions and how they can affect compliance. Before moving to the Cloud, first look at dependencies and traffic flows, to ensure you are not moving something into the Cloud that is not compliant.

[SHORT BREAK]  VENDOR PRESO Okta Did presentation on Securing Cloud. Tools for Cloud Compliance.

Back to Tim: Talked about a slide that showed Rationalizing Security Requirements / Standards; a framework for building internal polices based on Industry standards, Common Practices, Laws and Requirements. Talked on Share Responsibility Control Models. 1. Inherited Control, Hybrid Control, Shared Control and Customer Control.

Tim: Talked about Defining Data Protection; laid out Problem statements  1. Most orgs don’t have Data Classification scheme, 2 most orgs don’t have Authoritative Source for Data, most orgs don’t have Data LifeCycle Policy.

Topic change; Breaches: Breaches that involve actors obtaining Data from stolen laptop / or cell phone is because the world has moved to a mobile workforce and employer has not caught up with that; e.g., still storing data on employee devices and not in central location, protected by predefined automated policies. Nothing should be on local laptop or phone.

Make sure least privilege is always used – No human should ever have admin ( at least for very long); instead, user gets promoted to admin role; and then STS token expries and Role goes away.

Topic change Assets: Everything in AWS is an asset; instance IDs are unique , Security Group IDs are unique. Customers choose to track and decide how these assets are protected. ID’s by Amazon Resource Name; ( ARN )  Enable a Data Protection Architecture – a Methodology to lock down assets launched in AWS; using Cloud Formation templates with pre-defined polices. [ no EC2 launched in root, no S3 buckets with World read ]

CLOUD SECURITY TIP: CloudTrail needs to be enabled for all Regions; to mitigate against internal people spinning up instances in regions you don’t operate in; mitigate against external threats; expose any badness in your account.  Show Activity in a space in which you do not operate.

CLOUD SECURITY TIP: AWS root account – Delete Admin ROOT API Key. Never use root to do any task. No repudiation in logging  – Instead,  log in, create two admin accounts, turn on Cloud trail and MFA 

AWS Security Architecture Recipes using CIS Benchmarks – Tactical Control rules for hardening.  CIs Benchmarks have been “templatized” for CloudFormation  current on GITHUB  –

Use Tag in assets – mapping correlation for proof of documentation for which CIS template was used to meet compliance.

[ My thoughts on day one ] This is HUGE! Basically, AWS assets, EC2 instances, S3 buckets, RDS instances can all be deployed with these CIS based templates; ensuring that all assets have the same Security controls/permissions on them each time they are deployed; and then mapped back to an audit control with the naming in the TAG. Basically, hand the auditor a paper and say “bye bye now” This compliments custom, secure AMI ( Amazon Machine instances ) that are deployed from the original AMI that was built.

Great Security tips included and woven into each presentation. My notes did not capture all of this; but I did the best to get the main points – I have things in my notebook that may appear in later blogs – Also, Amazon does a fantastic job of documenting this

See you all tomorrow at Day2!


Why I am pursuing Amazon Certified Solutions Architect Certification

It’s time to switch up here a bit . . . While we Security Professionals have been shunning all things Cloud and jumping up and down, waving our hands, desperately warning our employers not to move data there; the world has gone on without us and Enterprises are aggressively moving data and services to the Cloud. This is driven largely by massive cost saves associated with Cloud Services in general. Software is eating the world. And Cloud is making that possible. Businesses are moving in that direction. The time has come (or it has been here a while), for InfoSec as a whole to embrace this practice of having data, services and workloads in the Cloud and do the best we can to secure the Confidentiality, Integrity and Availability of those services and data in the Cloud.

Of all companies in this space, Amazon is kicking serious ass in being the world leader in Cloud Platforms. Amazon AWS is the fastest growing multi-billion dollar Enterprise IT company in the World. 14 Billion to be exact. Many heavy hitters are putting dollars and infrastructure in the the Cloud. Amazon is putting tremendous resources in the cloud in their own right and have bet the farm on it; they are innovating at a furious pace as their own shopping services rely on their own AWS Cloud. AWS is experiencing 47% year over year growth!

All of my IT personas: Information Security, Network, Linux guy, Server guy, I believe that an understanding of Cloud / Securing Cloud / Writing Code for the Cloud is the best way I can serve others and provide for my Family in the many years to come. The Economics driving this push to Cloud, [ ultra-cheap compute power, no longer paying to build and maintain data centers, paying for services only when your customers use them are just a few of the drivers ]  simply cannot be ignored!  That is why  I am pursuing  the

Amazon Certified Architect first; followed by the AWS Security Specialization Exam then; the Professional Architect Exam. Presently, I am doing a ton of hands on labs after hours in the AWS Free tier; Enrolled in a great course by A Cloud Guru Learning. The course is taught by Ryan Kroonenberg and is SUPERB! I’m 70% through the first run.

I believe the Amazon Cert Program is solid and will compliment my background and skill set and increase my value to employers. So, yeah, I am excited!  I am learning at a pace and depth I never thought possible! I think that is because I truly enjoy the AWS platform; the multitude of services offered and how to interface and build with them!

disclaimer: I do not work for Amazon, nor I am paid by Amazon.

Stay Safe!


UPDATE:  At the AWS ‘Automating Security in the Cloud’ event I attended ( a few weeks after this posting ); during the audience polling; most event attendants were there because their employers are moving data and predictable workloads into AWS. Amazon and partners are making it easier to address regulatory compliance; FedRAMP, 800-53.  All this means is that the FRICTION is  that used to exist between getting on-prem data / workloads into the cloud is eroding. That’s not an accident.