VPCs

VPCs 101
    - VPC (Virtual Private Cloud) 
    - think of it as Virtual Data Centre in the Cloud
    - let's you provision a logically isolated section of the AWS where you can launch resources
       in the virtual network you define
    - you have ocmplete control over your virtual environment including selection of IP ranges,
       creation of subnets and configuration of route tables and network gateways
    - 1 Subnet = 1 Availability Zone


VPC structure:
    - on the outside of VPC we have 2 gateways - Internet Gateway and Virtual Private Gateway
    - both of these connections go to a router
    - router then directs traffic to Route tables
    - then Route tables will direct traffic through Network ACLs (that's first line of defence), like firewall or security groups
    - Network ACLs are stateless (when Security Groups are statefull):
        . allow/deny rules can be added
        . you can block specific IP adresses
    - then we move to Security Groups which are statefull (futher line of defence)
    - and here we have 2 different subnets:
        . PUBLIC SN 
            - internet traffic is accessible for any EC2 instances here
        . PRIVATE SN
            - EC2 instance cannot connect to the internet on it's own
            - you can still connect to that EC2 instance, but that's only possible if you first ssh into instance 
               in public subnet, and from it ssh into private one
            - there are 3 ranges of IPs reserved for private subnets:
                . 10.0.0.0 - 10.255.255.255 (10/8 prefix)
                . 172.16.0.0 - 172.31.255.255 (172.16/12 prefix)
                . 192.168.0.0 - 192.168.255.255 (192.168/16 prefix)


What can we do with VPC:
    - launch instance into a subnet of your choosing
    - assign custom IP address ranges in each subnet
    - configure route tables between subnets
    - create internet gateway and attach it to our VPC
    - much better security control over your AWS resources
    - you can assign security groups to individual instances
    - subnet network access control lists (ACLS)


Default VPC vs Custom VPC
    - Default VPC is user-friendly, allowing you to immediately deploy instances
    - all subnets in Default VPC have a route out to the internet
    - each EC2 instance has both a public and private IP address


VPC Peering
    - allows you to connect one VPC with another via a direct network route using private IP addresses
    - instances behave as if they were on the same private network
    - you can peer VPC's with other AWS accounts as well as with other VPCs in the same account
    - peering is in a star configuration: ie 1 central VPC peers with 4 others.
        NO TRANSITIVE PEERING!!!
    - you can peer between regions


Build a Custom VPC lab
    - aws reservs 5 ips for Network Address, VPC router, broadcast etc.
    - when you create a VPC, some things are NOT created:
        . new subnets
        . internet gateways
    - but some ARE created:
        . route table
        . network ACL 
        . Security group

    1. create 2 subnets:
            . we want one of them to be publicly accessible, so:
                - we need EC2 instance to launch in it with public IP address (Actions -> 'Modify auto-sign IP settings)
    2. add Internet Gateways so we can connect to our VPC
            . when you create IG it is 'detached' (fix: Actions -> 'attach')
            . you cannot attach another IG to same VPC (1 IG per VPC)
    3. configure Route tables
            . if you click on 'Routes' there are 2 routes (so that our subnets can talk to each other over ipv4 and ipv6)
            . we always want to make main route table PRIVATE and have separate route table for public subnet
                - let's create a route table (public to the internet):
                    1. simply create
                    2. 'Edit routes' -> 'Add route'
                    3. destination: 0.0.0.0/0, target: GW
                - any subnet associated with this route table will become public
                    1. 'Subnet associations' -> 'Edit ...'
                    2. check your 'public' subnet
    4. create 2 EC2 instances (1 for public subnet, 1 for private):
            Public:
                . in 'network' use your VPC
                . 'subnet' - public subnet
                . auto-assign ips
                . create new security group:
                    - + http 0.0.0.0/0
            Private:
                . in 'network' use your VPC
                . 'subnet' - private subnet
                . auto-assign ips (Disable)
                . use existing security group:
                    - default one
                . add tag... 
    5. In order to connect to a private ec2 instance you need to create another security group:
        - private instance has not public ip, but has private one.
        - by default, you cannot ssh from your public ec2 instance into private,
            because they are both in different security groups
        1. On new security group
            - allow ICMP traffic (so we can do ping)
            - ssh
            - http
            - dbs
        2. Change security group of private instance to newly created
        3. then you need to store keypair in your public instance and ssh into private one
            !!!ATTENTION!!! Do not do that this way, as if your public instance got hacked, hacker that can ssh into your private instance
            - there are other ways of doing it right


Network Address Translation (NAT)
    - we want our instances in private subnet to still download software and install updates
    - we don't wanna make instance to be public
    - there are NAT instances and NAT Gateways
    - NAT instance is a single EC2 instance
    - NAT Gateway - highly available Gateway
    - In order to create NAT instance:
        1. EC2
        2. Community AMIs (in search query type "nat")
        3. select any (or first one)
        4. launch it in public subnet
        5. use webDMZ security group
        6. 'Actions' -> Change Source/Destination checks (Disable)
        7. Create a route in root tables for main table
        8. add rule 0.0.0.0/0 , as a target use NAT_instance
        - the problem with such architecture - we have 1 small NAT machine, it can be easily overhelmed
        - it's single point of failure (if you terminate that instance then you cannot download anything on private instances)
    - To create and use NAT Gateway:
        1. NAT Gateways section
        2. Choose public instance
        3. Go to Route tables, edit main route table
        4. add rule 0.0.0.0/0 , as a target use nat-gateway


Exam tips:
    - NAT Instances:
        . when creating a NAT instance, Disable Source/Destination Check on the Instance
        . NAT instances must be in a public subnet
        . there must be a route out of the private subnet to the NAT instance, in order for this to work
        . the amount of traffic that NAT instances can support depends on the instance size.
            If you are bottlenecking, increase the instance size
        . you can create high availability using Autoscaling Groups, multiple subnets in different AZs,
            and a script to automate failover
        . NAT instances are behind security groups

    - NAT gateways
        . Redundant inside the AZ
        . Preferred by the enterprise
        . starts at 5Gbps and scales currently to 45Gbps
        . no need to patch
        . not associated with security groups
        . automatically assigned a public ip address
        . remember to update route tables
        . no need to disable Source/Destination checks
        . if you have resources in multiple AZs and they share one NAT gateway, in the event that the NAT gateway's AZ is down,
            resources in the other AZ lose internet access. 
          To create AZ-independent architecture, create a NAT gateway in each AZ and configure your routing to ensure that resources
            use the NAT gateway in the same AZ


Access Control Lists (ACLs)
    - rule number for ipv4 is 100, and aws prefers to use 100+ incremental (next ipv4 -> 200)
    - same for ipv6 (101) -> 201
    - by default, new NACL has all inbound/outbound rules DENIED
    - If you wanna do deny rule, make sure it's 'higher' than ALLOW rule (rules are applied in chronological order)
    - network ACLS always do their work first, before security groups
        1. Create ACL
        2. 'Edit subnet associations' for public subnet
        3. 'Edit inbound rules', add 100 -- port 80 -- 0.0.0.0/0 (http)
                                 add 200 -- port 443 - 0.0.0.0/0 (https)
                                 add 300 -- port 22 -- 0.0.0.0/0 (ssh)
        4. 'Edit outbound rules' add 100 -- port 80 -- 0.0.0.0/0 (http)
                                 add 200 -- port 443 - 0.0.0.0/0 (https),
                                 add 300 -- ports 1024-65535 0.0.0.0/0 (ephemeral ports)
                Ephemeral ports - short-lived transport protocol ports for IP communications.
                Used for communication with clients on well-known ports
    Exam tips: 
        - VPC automatically comes with a default network ACL, and by default it allows
            all inbound and outbound traffic
        - You can create custom network ACLs. By default, each custom network ACL denies
            all inbound and outbound traffic until you add rules
        - 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
        - block ipaddresses using network ACLs not Security Groups
        - you can associate network ACL with multiple subnets; however, a subnet can be associated with only one network ACL 
            at a time. When you associate a network ACL with a subnet, the previous association is removed
        - network ACLs contain a numbered list of rules that is evaluated in order,
            starting with the lowest numbered rule
        - network ACLs have separated inbound and outbound rules, each can allow/deny traffic
        - network ACLs are stateless; responses to allowed inbound traffic are subject to the rules for outbound traffic (and vice versa)


Custom VPCs and ELBs
    - exam tip: if you provision ELB, you need at least TWO PUBLIC subnets


VPC Flow Logs
    - it's a feature that enables you to capture information about the IP traffic going to and from network interfaces
        in your VPC
    - 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
    - Flow logs can be created on 3 different levels:
        . VPC
        . Subnet
        . Network Interface Level
    Exam tips:
        - you cannot enable flow logs for VPCs that are peered with your VPC unless the peer VPC is in your account
        - you cannot tag a flow log
        - after you've created a flow log, you cannot change its configuration; for example, you can't associate
            a different IAM role with the flow log
        - Traffic won't be monitored if:
            . traffic generated by instances when they contact the Amazon DNS server. If you use your own DNS server, 
                then all traffic to that DNS server is logged
            . traffic generated by a Windows instance for Amazon Windows license activation
            . traffic for instance metadata
            . DHCP traffic
            . traffic to the reserved IP address for the default VPC router


Bastion Hosts
    - special purpose computers on a network specifically designed and configured to withstand attacks.
    - stands in public subnet
    - all the staff is removed from it except rdp/ssh to communicate with private ec2 instance
    - NAT Gateway is used to provide internet traffic to EC2 instances in a private subnet
    - Bastion is used to securely administer EC2 instances (Using SSH or RDP). Bastions are sometimes called Jump Boxes
    - you cannot use a NAT Gateway as a Bastion host


Direct Connect
    - AWS Direct Connect is a cloud service solution that makes it easy to establish a dedicated network connection from
        your premises to AWS. Using AWS Direct Connect, you can establish private connectivity between AWS and your datacenter,
        office, or colocation environment, which in many cases can reduce your network costs, increase bandwidth throughput,
        and provide a more consistent network experience than Internet-based connections
    - directly connects your data center to AWS
    - useful for high throughput workloads (ie lots of network traffic)
    - or if you need a stable and reliable secure connection
    - can be scenario based question 'VPN connection keeps dropping out because of the amount of throughput'


VPC Endpoins
    - enables you to privately connect your VPC to supported AWS services and VPC endpoint services 
        powered by PrivateLink without requiring an internet gateway, NAT device, VPN connection, or AWS Direct Connect connection
    - instances in your VPC do not require public IPs to communicate with resources in the service. Traffic between your VPC and
        the other service does not leave the Amazon network
    - endpoints are virtual devices
    - horizontally scaled, redundant and highly available VPC components that allow communication between instances in your VPC and
        services without imposing availability risks or bandwidth constraints on your network traffic
    - two types of VPC endpoints:
        . Interface endpoints
        . Gateway endpoints
    - Interface endpoint is an elastic network interface with a private IP address that serves as an entry point for traffic destined 
        to a supported service (a lot of services in list)
    - Gateway Endpoints support:
        . Amazon S3
        . DynamoDB
    - for endpoinsts we need endpoint to be in private subnet and role (s3 full access):
        1. Attach that role to instance in private subnet
        2. add vpc subnet to default subnet (edit associations)
        3. ssh into private one (through public one)
        4. echo "test" > test.txt (create some file)
        5. aws s3 cp text.txt s3://<some_bucket>
        6. remove root to NAT gateway (or remove NAT gateway)
        7. after this you will not be able to do aws s3 ls
        8. add endpoint for vpc, and main root table, policy - s3 full access
        9. and then you will be able to look for s3 ls with:
            `aws s3 ls --region us-east-2
    

Q: Having just created a new VPC and launching an instance into its Public Subnet, 
    you realise that you have forgotten to assign a Public IP to the instance during creation. 
    What is the simplest way to make your instance reachable from the outside world?
A: Create an Elastic IP address and associate it with your instance

Q: A subnet can span multiple Availability Zones
A: False

Q: Are you permitted to conduct your own vulnerability scans on your own VPC without alerting AWS first?
A: Yes

Q: Can customers do Penetration Testing in their own VPC ?
A: True

Q: You can accelerate your application by adding a second Internet Gateway to your VPC
A: You may have only one Internet Gateway per VPC.

Q: When peering VPCs, you may peer your VPC only with another VPC in your same AWS account.
A: You may peer a VPC to another VPC that's in your same account, or to any VPC in any other account

Q: Application Load Balancer must be deployed into at least two subnets
A: True

Q: Which of the following is a chief advantage of using VPC endpoints to connect your VPC to services such as S3?
A: In contrast to a NAT gateway, traffic between your VPC and the other service does not leave the Amazon network when using VPC endpoints

Q: Which of the following allows you to SSH or RDP into an EC2 instance located in a private subnet?
A: A Bastion host allows you to securely administer (via SSH or RDP) an EC2 instance located in a private subnet. 
    Don't confuse Bastions and NATs, which allow outside traffic to reach an instance in a private subnet

Q: How many internet gateways can I attach to my custom VPC
A: one

Q: You have five VPCs in a 'hub and spoke' configuration, with VPC 'A' in the center and individually paired with VPCs 'B', 'C', 'D', and 'E',
     which make up the 'spokes'. There are no other VPC connections. Which of the following VPCs can VPC 'B' communicate with directly?
A: As transitive peering is not allowed, VPC 'B' can communicate directly only with VPC 'A'.

Q: Which of the following is true?
A: Security Groups are stateful and Network Access Control Lists are stateless

Q: Which of the following offers the largest range of internal IP addresses?
A: Min number

Q: Security groups act like a firewall at the instance level, whereas _________ are an additional layer of security that act at the subnet level
A: Network ACLs

Q: In a default VPC, all Amazon EC2 instances are assigned 2 IP addresses at launch. What are they?
A: A Public IP address and Private IP address

Q: When I create a new security group, all outbound traffic is allowed by default
A: True

Q: By default, how many VPCs am I allowed in each AWS Region?
A: 5

Q: Select the incorrect statement.
A: In Amazon VPC, an instance does not retain its private IP (It actually retains)

Q: To save administration headaches, a consultant advises that you leave all security groups
    in web facing subnets open on port 22 to 0.0.0.0/0 CIDR.
    That way, you can connect wherever you are in the world. Is this a good security design?
A: 0.0.0.0/0 would allow ANYONE from ANYWHERE to connect to your instances. 
    This is generally a bad plan. The phrase 'Web facing subnets..' does not mean just web servers. 
    It would include any instances in that subnet some of which you may not strangers attacking. 
    You would only allow 0.0.0.0/0 on port 80 or 443 to to connect to your public facing Web Servers, 
    or preferably only to an ELB. Good security starts by limiting public access to only what the customer needs. 
    Please see the AWS Security white paper for complete details.