Lambda

  1. Global service of AWS
  2. Max run duration 5 min
  3. Following Triggers are supported
    1. API Gateway
    2. AWS IOT
    3. Alexa (Skills and smart home)
    4. Cloud Front
    5. Cloud Watch (Events and logs)
    6. Code Commit
    7. Cognito
    8. DynamoDB
    9. Kinesis
    10. S3
    11. SNS
  4. Scales OUT automatically
  5. AWS X-Ray used to debug Lambda

Elastic File System (EFS)

  1. EFS is block based storage.
  2. AWS Elastic File System storage capacity is elastic (grows /shrinks as needed) unlike EBS
  3. NFS V4 protocol
  4. 30 cents/GB month
  5. Multi AZ’s
  6. Thousands of concurrent connections are supported
  7. Read after write consistancy
  8. Create a EFS
    1. Provide AZ’s subnets, ips (optional)
    2. the mount name and instructions to mount (Linux only. Windows is not supported currently as of 2018)
  9. Permissions at folder/file level possible by IAM. Amazon EFS allows you to tightly control access to your file systems through POSIX permissions. Use Amazon VPC to manage network access.
  10. EBS can be mounted to single EC2 instance where as EFS can be mounted by multiple EC2 instances
  11. You can also mount Amazon EFS file systems on your on-premises datacenter servers via the NFSv4 protocol when connected to your Amazon VPC with AWS Direct Connect.
  12. Encrypt your data at rest and in transit for a comprehensive solution securing both stored data and data in flight.

Auto Scaling Groups and Launch Configurations

  1. What is auto scaling group?
    1. Auto scaling groups along with Launch Configurations enable you to create a logical group of EC2 instances that are always available.
    2. ASGs optionally work with ELBs but ELB is not needed for ASG to work.
  2. What is Launch Configuration or Launch Template?
    1. ASG uses launch template, or a launch configuration (not recommended, offers fewer features), as a configuration template for its EC2 instances
    2. Is a recipe to create an EC2 instance. Steps involved are exactly same as creating an EC2 except at the end you will create the recipe as opposed to launching the actual instance.
    3. Launch templates have versions. Launch configs do not.
  3. Create Launch Configuration
    1. Choose AMI
    2. Choose Instance Type
    3. Name the launch config
    4. Choose spot instances or not
    5. Choose if you need detailed monitoring on cloud watch
    6. Choose IAM roles if any
    7. Input the User data (bootstrapping code) if any
    8. Any ip address related parameters
    9. Add storage details
    10. Security Group details (default or your own)
    11. Input your key pair name
    12. Click save the launch configuration
  4. Create Auto Scaling Group. (This will launch the EC2 instances)
    1. Name of the auto scaling group
    2. Choose VPC
    3. Choose Group size (starting number of instances)
    4. Choose subnets (one or more. Its a multi select. Better to choose two or more AZs). The instances from above step will be distributed evenly among the chosen AZs
    5. Choose Launch Configuration
    6. Choose optional Load Balancer
    7. Choose which health check to use (ELB or EC2)
    8. Input health check grace period (300 sec default). This is the amount of time the ASG waits before it checks the health of a newly started instance. If you have major bootstrapping script, increase this parameter.
    9. Scaling Policies
      1. Scaling policies enable you to either keep the group size constant at th initial size or
      2. Scale between min and max instances (min and max are not equal to initial size)
      3. Increase Group Size Rule
        1. Execute policy when (Points to an Alarm. Alarm has following)
          1. Name of the alarm
          2. Whenever: Average/Min/Max of CPU/RAM >/</>=/<=   XXXX percent.
          3. At least: N number of consecutive periods of T sec/min
          4. Optional SNS notification
        2. Take the action:
          1. Add/Substract
          2. N instances
          3. Warm up time (300 sec)
      4. Similarly Create Decrease Group Size Rule
      5. Provide optional email to be sent when launching/termination/fail to launch/fail to terminate instances
    10. Finally click to “Create ASG”. This will immediately launch the EC2 instances as per the rules of the ASG
    11. Remember: Security Group is input for the launch configuration whereas VPC/subnets/AZs are parameters of the auto scaling group.
    12. The default termination policy is designed to help ensure that your network architecture spans Availability Zones evenly.
      1.  Auto Scaling determines whether there are instances in multiple Availability Zones. If so, it selects the Availability Zone with the most instances and at least one instance that is not protected from scale in.
      2. If there is more than one Availability Zone with this number of instances, Auto Scaling selects the Availability Zone with the instances that use the oldest launch configuration.
    13. If you suspend AddToLoadBalancer, Auto Scaling launches the instances but does not add them to the load balancer or target group. If you resume the AddToLoadBalancer process, Auto Scaling resumes adding instances to the load balancer or target group when they are launched. However, Auto Scaling does not add the instances that were launched while this process was suspended. You must register those instances manually.
    14. Auto Scaling periodically performs health checks on the instances in your Auto Scaling group and identifies any instances that are unhealthy. You can configure Auto Scaling to determine the health status of an instance using Amazon EC2 status checks, Elastic Load Balancing health checks, or custom health checks
    15. The thumb rule is, if any instance reported unhealthy either by Auto scaling health check or any ELB instance check (In case of multiple ELB), Auto scaling will consider worst case scenario and always mark instance unhealthy and remove it.

CloudFront CDN

  1. Cloud Front is AWS content delivery network service
  2. Amazon Cloud Front can provide Content Delivery Network (CDN) functionality for many types of origins including
    1. Amazon Elastic Compute Cloud (Amazon EC2) instances
    2. AWS Elastic Load Balancing (ELB)
    3. Amazon Simple Storage Service (Amazon S3)
    4. Route53
    5. on-premises applications and sites.
  3. When you create a web distribution, Cloud Front assigns a domain name to the distribution, such as d6736837jhsdga.cloudfront.net. You can use this domain name in the URLs for your content, for example: http://d6736837jhsdga.cloudfront.net/logo.jpg. Alternatively, you might prefer to use your own domain name in URLs, for example: http://cdn.example.com/logo.jpg. If you want to use your own domain name, use Amazon Route 53 to create an alias record that points to your Cloud Front distribution.
  4. Edge locations are where your data (S3/EC2/ELB/Route53) cached, with low latency.
  5. Edge locations are different from regions and availability zones
  6. Distribution: A name given to the CDN containing a collection of edge locations
  7. Can do READ/WRITE (GET, OPTIONS, POST, PUT, PATCH)
  8. Content is temporarily cached on CF edge locations
    1. TTL is number of seconds before the cache expires (at which time new copy is fetched from origin)
    2. Invalidation: You can clear cache before TTL forcibly, but costs extra.
  9. S3-accelerated uses edge locations to read/write to S3 buckets
  10. Amazon Cloud Front can serve private content by using
    1. Signed URLs
    2. Signed cookies
    3. Amazon Simple Storage Service (Amazon S3) Origin Access Identifiers.
    4. Restrict content based on geolocation (whitelist and blacklist)
  11. To ensure that your users access your objects using only Cloud Front URLs, regardless of whether the URLs are signed, perform the following tasks:
    1. Create an origin access identity, which is a special Cloud Front user, and associate the origin access identity with your distribution.
    2. Change the permissions on your S3 bucket or on the objects so only the origin access identity has read permission (or read and download permission).
    3. When your end users access your Amazon S3 objects through Cloud Front, the Cloud Front origin access identity gets the objects on behalf of your end users.
    4. If your users request objects directly by using Amazon S3 URLs, they’re denied access. The origin access identity has permission to access objects in your Amazon S3 bucket, but users don’t.
  12. Distribution types
    1. Web Distribution
    2.  RTMP (media streaming / flash) Distribution – for Adobe flash files only

Storage Gateway

  1. All gateways are Virtual appliance (VM image) that can be downloaded and installed on a hypervisor (VM ware VSXi or MS Hyper-V) locally in your data center.
  2. Three types of storage gateways (acronym FTV File Volume Tape) are available to choose from:
    1. File Gateway (NFS Network File System mounts) stores flat files in S3 such as images, PDF/doc/xls files etc.
      1. Amazon S3 and Amazon Glacier cloud storage.
      2. File gateway offers an NFS mount for S3 with local caching.
      3. It can be used for on-premises applications, and for Amazon EC2-resident applications that need low-cost file storage.
      4. No storage on premises (Only cache)
      5. No limit on size
    2. Volume Gateway (iSCSI) provides virtual hard disks. Can be used as a block storage to install OS or databases such as MySQL/SQL Server etc.
      1. Stored Volumes: All data is stored on premises and snapshots are backed up on S3 . Volume size: 1 GB to 16 TB
      2. Cached Volumes: S3 is used as primary storage. Only most recently used data is cached on premises. Volume size: 1 GB to 32 TB
    3. Tape Gateway uses VTL (Virtual Tape Library) protocol to backup virtual tape archives on S3 Glacier.

DNS and Route 53

  1. Route 53 zone record contains a special record type called ALIAS which can be used to redirect a domain name to a load balancer or S3 bucket url.
  2. CNAME records are used for sub domains
  3. Both load balancers and S3 buckets have no ip only a DNS name
  4. Every hosted zone contains minimum two records NS and SOA (start of authority)
  5. Route 53 is global (no region)
  6. Traffic is distributed based on Routing Policies
  7. Simple one to one
    1. Simple Routing Policy: One single A record pointing to ip or alias pointing to ELB/S3/Cloud Front
  8. Resilient pillar based policies
    1. Failover policy: Need two record sets of type Failover. Choose Active in one and Passive in the other.  If Active site fails, traffic is diverted to Passive Site. You need to create a Health Check in Route 53.
  9. Performance pillar based policies: #7 and #8 use a single end point at any given time. But below three use multiple endpoints and distribute across them for performance
    1. Weighted routing policy: Distributes the traffic across 2 or more endpoints based on the weights. You create N records with weights (number between 1 and 256) and point to N different endpoints. Aggregates all the weights and applies ratios.
    2. Latency routing policy: Distributes the traffic across 2 or more endpoints based on the latency. Create two record sets of type Latency and provide region 1 and region 2 and it will choose target based on lowest latency
    3. Geo-location Routing Policy: Distributes the traffic across 2 or more endpoints based on the client’s geographic location.

Elastic Container Service (ECS)

  1. Amazon Elastic Container Service (Amazon ECS) is a highly scalable, fast, container management service that makes it easy to run, stop, and manage Docker containers on a cluster.
  2. Launch types:
    1. You can host your cluster on a serverless infrastructure that is managed by Amazon ECS by launching your services or tasks using the Fargate launch type.
    2. For more control you can host your tasks on a cluster of Amazon Elastic Compute Cloud (Amazon EC2) instances that you manage by using the EC2 launch type.
  3. Container images
    1. Container Images are stored in and pulled from container registries (ECR), which may exist within or outside of your AWS infrastructure
    2. Amazon ECR is a managed AWS Docker registry service that is secure, scalable, and reliable.
    3. ECR supports private Docker repositories with resource-based permissions using IAM so that specific users or EC2 instances can access repositories and images.
    4. Developers can use the Docker CLI to push, pull, and manage images.
  4. ECS Task Definition
    1. Task definition (application blueprint) is a text file, in JSON format, that describes one or more containers, up to a maximum of ten, that form your application.
    2. Task definitions specify various parameters for your application. Examples of task definition parameters are which containers to use, which launch type to use, which ports should be opened for your application, and what data volumes should be used with the containers in the task.
  5. task is the instantiation of a task definition within a cluster. After you have created a task definition for your application within Amazon ECS, you can specify the number of tasks that will run on your cluster.
  6. The Amazon ECS task scheduler is responsible for placing tasks within your cluster.
  7. Clusters
    1. When you run tasks using Amazon ECS, you place them on a cluster, which is a logical grouping of resources.
    2. If you use the Fargate launch type with tasks within your cluster, Amazon ECS manages your cluster resources.
    3. If you use the EC2 launch type, then your clusters will be a group of container instances you manage.
  8. The container agent
    1. runs on each infrastructure resource within an Amazon ECS cluster.
    2. It sends information about the resource’s current running tasks and resource utilization to ECS
    3. starts and stops tasks whenever it receives a request from Amazon ECS.
  9. Security
    1. In Amazon ECS, IAM can be used to control access at the container instance level using IAM roles, and at the task level using IAM roles for ECS tasks.
    2. With IAM roles for ECS tasks, you can specify an IAM role that can be used by the containers in a task.
    3. Applications must sign their AWS API requests with AWS credentials, and this feature provides a strategy for managing credentials for your applications to use, similar to the way EC2 instance profiles provide credentials to EC2 instances.
    4. Instead of creating and distributing your AWS credentials to the containers or using the EC2 instance’s role, you can associate an IAM role with an ECS task definition or RunTask API operation.
  10. ECS and Auto Scaling
    1. You can use Auto Scaling with a Fargate task within a service to scale in response to a number of metrics
    2. You can use Auto Scaling with a EC2 task to scale the container instances within your cluster.
  11. You can use Elastic Load Balancing to create an endpoint that balances traffic across services in a cluster.
  12. AWS Fargate is a technology that you can use with Amazon ECS to run containers without having to manage servers or clusters of EC2 instances. With AWS Fargate, you no longer have to provision, configure, and scale clusters of virtual machines to run containers. This removes the need to choose server types, decide when to scale your clusters, or optimize cluster packing.
  13. You can define clusters, task definitions, and services as entities in an AWS CloudFormation script.
  14. Docker provides several diagnostic tools that help you troubleshoot problems with your containers and tasks.
    1. You can access the Docker command line utilities by connecting to a container instance using SSH.
    2. The exit codes that Docker containers report can also provide some diagnostic information (for example, exit code 137 means that the container received a SIGKILL signal).
  15. Port mappings allow containers to access ports on the host container instance to send or receive traffic. Port mappings are specified as part of the container definition.
  16. Few important points about ECS
    1. Task Def. specifies how much CPU or RAM for the containers
    2. ECS Cluster is a logical grouping of container instances that you can place your tasks on
    3. Clusters can contain multiple different instance types
    4. Clusters are Region specific
    5. ECS agent (comes pre installed on Amazon Linux AMI) is a piece of software that runs on Linux (windows is not supported) lets you connect your EC2 instance connect with a container in a cluster
    6. Security groups act at the instance level (not at container or task level)
    7. You can schedule ECS in two ways
      1. Service scheduler
      2. customer scheduler

Virtual Private Clouds (VPC)

  1. virtual private cloud (VPC) is a virtual network dedicated to your AWS account. It is logically isolated from other virtual networks in the AWS Cloud. You can launch your AWS resources, such as Amazon EC2 instances, into your VPC. You can configure your VPC by modifying its IP address range, create subnets, and configure route tables, network gateways, and security settings.
  2. Can span multiple AZ, but can’t span multiple regions.
  3.  Every region has one default VPC for your account.
  4. VPC contains default route table and default ACL which will be associated with every new subnet by default
  5. VPC has to be assigned a CIDR (Range of private ips). Custom VPC can have a CIDR with a maximum /16 which is 2^16= 6536 addressable ips to a minimum /28 which is 2^4=16 addressable ips.
  6. When you create Custom VPC it creates default security group, default network ACL and default route table, it doesn’t create default Subnet though.
  7. Subnets are logical groups of private ip addresses that are represented by a CIDR which is subset of VPC CIDR
    1. You can assign a custom route table for your newly created subnets
    2. EC2 instances are launched into a subnet
    3. VPC can have upto 200 subnets and you can request AWS support to increase this limit
    4. One Subnet resides in one AZ. Unlike security groups, NACLs, Route Tables and VPCs which span across multiple AZs within the region.
    5. A subnet CIDR can have smallest range of /28 which is 2^4-5=11 ip addresses. Remember that every subnet, five ips (the first 4 ips and the last 1 ip) are reserved by AWS allowing the remaining ips to be assignable to resources.
  8. Network ACL: A network access control list (ACL) is an optional layer of security for your VPC that acts as a virtual firewall for controlling traffic in and out of one or more subnets. You might set up network ACLs with rules similar to your security groups in order to add an additional layer of security to your VPC.  Read more about NACLs
  9. Three types of subnets are possible
    1. If the assigned route table points to internet gateway (one igw per VPC) for 0.0.0.0/0 then your subnet is a public subnet
    2. If RT Points to NAT for 0.0.0.0/0  then its a private subnet
    3. If the RT points to VPG for 0.0.0.0/0 then its is a VPN only subnet
  10. DHCP Option set
    1. VPC points to a default DHCP optionset
    2. Using this you can assign names to private ips
    3. Only one DHCP option set can be active at any given point for a VPC
    4. DHCP Option Sets can’t edited after creation
    5. DHCP options sets are associated with your AWS account so that you can use them across all of your virtual private clouds (VPC).
  11. Rout Tables:
    1. Rout table has OUT bound records telling where outbound traffic (remember easily as rOUT table) is going from a subnet. (No mention of inbound traffic…only outbound traffic)
    2. Route contains DT records with Destination (ip range CIDR) and Target
    3. Rout table has associated subnets
      1. explicitly associated (newly created non-default RTs of a VPC need to be explicitly associated with a Subnet)
      2. non-explicitly associated (all SNs by deafult point to VPC’s default RT)
    4. A route table guides all network packets originating from your resources in your subnet, which way they need to go to get to their destination. Route tables are like intersections on a road, having multiple sign boards telling which direction (target eg: igwXXXXX) to choose to reach a destination.
    5. route table contains a set of rules, called routes, that are used to determine where outbound network traffic is directed.
    6. (local to connect to resources hosted within the subnet, internet gateway to connect to internet, NAT Instance/NAT Gateway to one way connect to internet for downloading patches/packages, VPC Peering Connection to connect to another VPC, VPC endpoint to connect to S3 using the private network, ClassicLink to connect classic EC2s, Egress-Only Internet Gateway for downloading patches, Virtual Private Gateway to connect to on-premise data center etc.)Rout table routes
    7. Each subnet in your VPC must be associated with one (and only one) route table; the table controls the routing for the subnet. A subnet can only be associated with one route table at a time, but you can associate multiple subnets with the same route table.
    8. When you create a VPC, a default route table (Main Routable) is created where the default Routes are VPC CIDR Local <— all subnets inside VPC will be able to talk to each other
    9. Don’t touch Main route table, instead create another route table for route out to internet (0.0.0.0/0 IGW)
    10. Last thing you associate this new route table to one of the subnet which will make it public. (you can enable auto assign public IP for the public subnet)
  12. Internet Gateways, NAT instances/gateways and Bastion hosts enable your resources in your VPC communicate with outside internet world.
  13. VPC flow logs
    1. Helps you to capture information about the IP traffic going to and from network interfaces in your VPC.
    2. Flow log data is stored using Amazon CloudWatch Logs. After you’ve created a flow log, you can view and retrieve its data in Amazon CloudWatch Logs.
    3. Flow logs can help you with a number of tasks; for example, to troubleshoot why specific traffic is not reaching an instance, which in turn helps you diagnose overly restrictive security group rules. You can also use flow logs as a security tool to monitor the traffic that is reaching your instance.
    4. There is no additional charge for using flow logs; however, standard CloudWatch Logs charges apply.
    5. They can be created at three levels: VPC or subnet or eni
    6. Traffic to the following can’t be monitored
      1. Reserved ips used by AWS (router, broadcast etc)
      2. DNS/DHCP/MS License/169.254.169.254 metadata requests
  14. VPC endpoints
    1. Used to connect EC2 instances in your VPC with AWS services such as S3 (only S3 is supported as of now) without going thru internet using NAT gateways
    2. Your private ip address is used in the communication thru end point. Public ip addresses are not used.
    3. Two types VPC end points
      1. ENI endpoint
        1. works at the EC2 instance level
      2. Gateway endpoint
        1. works at the route table level for the entire subnet (one or more subnets that are associated with the route table)
    4. You can specify a policy at the endpoint to allow/deny traffic
  15. When you launch a EC2 in a VPC
    1. In private subnet: You get private ip and no public ip and these private ips persist thru start/stop and reboots
    2. In a public subnet: You get a private ip and a public ip.  private ips persist thru start/stop and reboots and public ips do not persist.
    3. However you can assign a public elastic ip which will persist
  16. VPC Peering
    1. Lets you connect VPCs in the same region across multiple accounts using private ips
    2. Must have non conflicting CIDRs
    3. No gateway/VPN/hardware required
    4. Not transitive A<->B  B<->C does not mean A is peered to C
    5. No edge to edge routing thru a gateway or private connection (Eg. if VPC 1 has a NAT, VPC2 resources can’t use that NAT even though VPC1 and VPC2 are peered)
  17. Direct connect
    1. Dedicated connection from your local data center to AWS VPC over private ips and private network (NOT using internet)
    2. Connections go to DX facility and then to AWS
    3. Dedicated line is provided by your ISP
  18. VPN
    1. Connection from your local data center to AWS VPC using private ips and over public network (internet)
    2. Hardware or software based VPNs are possible
    3. Virtual Private Gateway (VPG) is VPN concentrator on AWS side
    4. Customer Gateway (CGW) is hardware or software solution that resides in the client data center and communicates with VPG
    5. VPNs use two IP-Sec tunnels between CGW and VPG for high availability
  19. Expanding VPC
    1. You can expand your existing VPC by adding four (4) secondary IPv4 IP ranges (CIDRs) to your VPC.
    2. You can shrink your VPC by deleting the secondary CIDR blocks you have added to your VPC.
    3. You cannot however change the size of the IPv6 address range of your VPC.
  20. Can I use Elastic Network Interfaces as a way to host multiple websites requiring separate IP addresses on a single instance?  Yes, however, this is not a use case best suited for multiple interfaces. Instead, assign additional private IP addresses to the instance and then associate EIPs to the private IPs as needed.
  21. VPC Flow logs
    1. VPC Flow Logs enables you to capture information about the IP traffic going to and from network interfaces in your VPC.
    2. Flow log data is stored using Amazon CloudWatch Logs. After you’ve created a flow log, you can view and retrieve its data in Amazon CloudWatch Logs.
    3. Flow logs can help you troubleshoot why specific traffic is not reaching an instance, which in turn helps you diagnose overly restrictive security group rules.
    4. You can also use flow logs as a security tool to monitor the traffic that is reaching your instance.
    5. There is no additional charge for using flow logs; Just CloudWatch Logs charges.
  22. Can’t delete VPC if you have active running instance or resources such as ELB are running
  23. configure a backup VPN connection for failover with my AWS Direct Connect connection. To configure the hardware VPN as a backup for your Direct Connect connection:
    1. Be sure that you use the same virtual private gateway for both Direct Connect and the VPN connection to the VPC.
    2. If you are configuring a Border Gateway Protocol (BGP) VPN, advertise the same prefix for Direct Connect and the VPN.
    3. If you are configuring a static VPN, add the same static prefixes to the VPN connection that you are announcing with the Direct Connect virtual interface.
    4. If you are advertising the same routes toward the AWS VPC, the Direct Connect path is always be preferred, regardless of AS path prepending.
  24. AWS Transit Gateway connects VPCs and on-premises networks through a central hub. This simplifies your network and puts an end to complex peering relationships. It acts as a cloud router – each new connection is only made once.
    1. Below first image represents the network architecture before TG
    2. Second image represents the network architecture after TG

Network Access Control Lists (NACL)

  1. network access control list (NACL) is a layer of security for your VPC that acts as a virtual  firewall for controlling traffic in and out of one or more subnets.
  2. You set up network ACLs with rules similar to your security groups in order to add an additional layer of security to your VPC.
  3. NACL operates on subnets whereas Security Groups work at EC2 level
  4. SGs have only ALLOW rules at EC2 level but NACLs have both ALOW/DENY rules at subnet level.
    1. So you can DENY (block) ip addresses using NACLs at subnet level.
    2. This is not possible thru SGs since SGs only ALLOW at EC2 level.
    3. So if you want to BLOCK IP address then do it in the NACL, not possible with security groups.
  5. NACL rules (IOADC)
    1. rule is either Inbound or Outbound
    2. rule can specify ALLOW or DENY
    3. inbound rule has source CIDR outbound rule has destination CIDR
    4. Only a CIDR will be specified in the source or destination field of an NACL, unlike in a Security Group where sources and destinations can be a CIDR/SG/PrefixList.
  6. When you create a VPC a default NACL is created
    1. Default NACL allows all inbound and outbound traffic.
    2. All subnets created are assigned this default NACL.
  7. We can create new custom NACLs and change the association from default to custom NACL at subnet level.
    1. By default a custom NACL DENYs all inbound and outbound traffic.
  8. Each subnet in your VPC must be associated with a network ACL. If you don’t explicitly associate a subnet with a network ACL, the subnet is automatically associated with the default network ACL.
  9. A subnet can have only one NACL associated at any given time unlike Security Groups, where multiple SGs can be assigned to an EC2 instance.
  10. One NACL can be associated with multiple subnets. For example the default NACL is assigned whenever a new subnet is created.
  11. Rules are evaluated starting with the lowest numbered rule. As soon as a rule matches traffic, it’s applied regardless of any higher-numbered rule that may contradict it. The highest number that you can use for a rule is 32766.
  12. NACLs rules are applied first before applying security group rules.
  13. NACLs are stateless
    1. Example: If you allow HTTP inbound in a NACL, this does not automatically ALLOW HTTP outbound. You need to explicitly ALLOW HTTP outbound as well.
    2. This is different from the security groups, which are stateful. In a SG, Once you allow HTTP inbound (request), the request’s corresponding outbound HTTP (response) is automatically allowed even if there is no such rule created.
  14. Use ephemeral (temporary) ports on outbound rules only

Network Address Translation (NAT) Instances, NAT Gateways, Egress only Internet Gateways and Bastion Hosts

  1. How to enable private subnet based EC2 instances access internet for downloading software and patches
    1. NAT Instances:
      1. Launch NAT instance from NAT AMI in public subnet
      2. You need to disable source/destination check
      3. Add a new route in the private subnet’s route table to send all traffic with destination 0.0.0.0/0 to the NAT instance (target)
      4. Unlike internet gateway, NAT instance provides is one way access (Request and response) to internet meaning one can’t initiate connection over internet into private subnet
    2. NAT Gateway (IPv4)
      1. ipv4, highly available and redundant (unlike NAT inst.)
      2. NO need to disable source/destination check
      3. needs an elastic ip
      4. Add a new route in the private subnet’s route table to send all traffic with destination 0.0.0.0/0 to the NAT gateway (target)
    3. Egress only internet gateway (IPv6)
      1. An egress-only internet gateway is for use with IPv6 traffic only. To enable outbound-only internet communication over IPv4, use a NAT gateway instead.
      2. An egress-only internet gateway is a horizontally scaled, redundant, and highly available VPC component that allows outbound communication over IPv6 from instances in your VPC to the internet, and prevents the internet from initiating an IPv6 connection with your instances.
  2. How to access your EC2 instances residing in a private subnet
    1. using SSH/RDP over internet using Bastion hosts
      1. Bastion hosts allow you to access EC2’s in private subnet thru SSH/RDP
      2. Bastion hosts live in public subnets
      3. ALLOW bastion host’s security group to SSH/RDP to your private subnet by modifying private subnet’s security group
      4. Use Putty agent forwarding to ssh to Bastian and further SSH to private subnet EC2
    2. Using AWS Systems Manager: SM is a Management Tool that enables you gain operational insights and take action on AWS resources safely and at scale. Using the run command, one of the automation features of Systems Manager, you can simplify management tasks by eliminating the need to use bastion hosts, SSH, or remote PowerShell.
        1. If you have a running EC2, you can find what role it is using and attach a AWS policy called “AmazonEC2RoleforSSM” to the role. Remember you can attach multiple policies to a single role.
        2. If you are launching a new EC2, you can create a new role for it use it after attaching “AmazonEC2RoleforSSM” policy

Copyright 2005-2016 KnowledgeHills. Privacy Policy. Contact .