· A NAT instance is an EC2 Instance – they are in the community AMIs and are on their way out.
· A NAT instance will get a public IP.
· You must disable the source/destination checks in a NAT instance - *IMPORTANT
· To allow hosts in the subnet to go to the internet, you would add a route through the NAT instance.
Therefore, for NAT Instances:
· Disable the source/destination check
· 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!!!!!! (I remember this on the quiz).
· You can create HA using autoscaling groups, multiple subnets in different AZs, and a script to automate failover.
· They are behind a subnet or security group.
· They are redundance inside the AZ
· They are preferred by the enterprise
· They start at 5Gbps and scale to 45 Gbps.
· No need to patch them like a NAT instance.
· They are not associate with a security group.
· Update the route table for your NAT Gateway.
· Have a NAT Gateway in each availability zone.
· By default, a new network ACL denies everything.
· You have to create both inbound and outbound rules.
· Ephermeral ports – automatically assigned to connect (temporary) are usually assigned by the server. However add to the ACL. Ex. TCP 6, Port Range 10-24-65535 Dest. 0.0.0.0/0 Action – Allow
· Rules are evaluated from the top in chronological order – place a deny before and allow.
· Network ACLs can have multiple subnets
· Changes happen immediately
· Network ACLS act BEFORE a security group!!!!!!!!!!!!
· Your VPC automatically comes with a default network ACL, and by default it allows all outbound and inbound traffic.
· You can create custom network ACL that 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.
· You can block IP addresses using network ACLS, but not with security groups.
· You can associate a network ACL with multiple subnets; however, a subnet can bet associate with only one network ACL at a time. When you associate a network ACL with a subnet, the previous association is removed.
· You can associate a network ACL with multiple subnets, but a subnet can bet associated with only one.
· Network ACLs contain a numbered list of rules that is evaluated in order starting with the lowest numbered rule.
· Network ACLs have separate inbound and outbound rules, and each rule can either allow or deny traffic.
· Network ACLS are STATELESS!!!!!!!! – responses to allowed inbound traffic are subject to the rules for outbound traffic (and vice versa).
· 2 public subnets are required to create a load balancer.
· VPC flow logs log at the:
· Interface
· Subnet
· VPC
· Flow logs are sent to cloudwatch and stored in S3 buckets.
· You must create a log group (destination log group)
· Create or select an IAM role when creating flow logs
· You can’t enable flow logs that are peered with your VPC unless the peer VPC is in your account.
· You can tag flow logs
· You can’t change the configure of a flow log.
· Not all IP traffic is monitored.
· Traffic generated by instances when they contact the Amazon DNS server is not logged.
· If you use your own DNS server, then all traffic to that DNS Server is logged.
· Windows license activations are not logged.
· DHCP is not logged.
· 169.254.169.254 for instance metadata is not logged.
· Traffic to the reserved IP address for the default VPC router is not logged.
· Bastion Hosts used to securely administer EC2 instances (using SSH or RDP). Bastions are also called “jump boxes” in some places.
· A NAT gateway or NAT instance is used to provide internet traffic to EC2 instances in private subnets.
· You cannot use a NAT gateway as a bastion host.
· Direct Connect is a dedicated network line from premises to AWS
· It directly connects your data center to AWS
· Useful for high throughput workloads (LOTS OF NETWORK TRAFFI)
· It is a stable, reliable, and secure connection.
1. Direct Connect – Console – create a virtual interface (public virtual interface).
2. Go to the VPC Console ---à VPN Connection
a. Create a Customer Gateway
b. Create a Virtual Private Gateway
c. Attach Virtual Private Gateway to a VPC
3. Go to VPN Connections
a. Create a VPN Connection
b. Select the Virtual Private Gateway and the Customer Gateway
c. Once the VPN is available, setup the VPN on premise.
· AWS Global Accelerator is a service that creates accelerators to improve availability and performance of your applications for local and global users.
· It uses a static IP address – you can bring your own IP also.
· Global Accelerator components:
· Static IPs (2)
· Accelerator – includes listeners. Listeners process inbound connections from clients for port and protocol (tcp and udp)
· A listener has a DNS address.
· The static Ips are associated with an Availability Zone or Network Zone. (???)
· Endpoint groups are associated with a region.
· Endpoints can be:
· Load balances
· EC2
· Elastic Load Balancers
· Elastic Ips
· AWS Global Accelerator is a service in which you create accelerators to improve the availability and performance of your applications for local and global users.
· You are assigned 2 IP addresses or you can bring your own.
· You can control traffic using traffic (dials????). This is done in the endpoint group.
· VPC endpoints are a way of connecting your VPC to supported AWS services without leaving the AWS network. No public IP addresses are required to communicate with resources in this service.
· 2 Types:
· Interface – ENI with private IP
· Gateway to:
· S3
· DynamoDB
· EC2
· When you use the VPC gateway, you may need to add the region to your statements (ie; aws s3 ls –region <values>)
· AWS private link shares applications across VPCs to open an application to other VPCS. You can either:
a. Open the VPC up to the Internet
· Security Considerations
· Everything in the public subnet is public.
· There is more to manage.
b. You can use VPC peering. You have to manage many different peering connections.
c. Operate your services in a VPC to another VPC using private link. This is the best option to expose a service VPC to lots of customer VPCs (10s, 100s, or 1000s).
a. It does not require VPC Peering, route tables, NAT, Internet Gateways, etc
d. It requires a network load balancer on the service VPC and an ENI on the customer VPC
· If you see a question about peering VPCs to 10s, 100s, or 1000s of VPCs think of AWS private link.
· It doesn’t require VPC peering – no route tables, NAT, Internet Gateways, etc
· Requires a Network Load Balancer on the service VPC and an ENI on the customer VPC.
· A way of simplifying your network architecture – everything can connect to the transit gateway
· Hub and Spoke Architecture
· Transitive Peering between 1000s of VPCs and on-premise data centers
· Works n a regional basis but you can have it across multiple regions
· You can share it across multiple AWS accounts using RAM resource access manager. (?)
· You can use route tables to limit how VPCs talk to one another
· Works with Direct Connect as well as VPN Connections
· Supports IP multicast (not supported by another AWS service)
· If there are any questions about simplifying your network topology, thing transit gateway.
· If you have multiple sites, each with it’s own VPN connection, you can use AWS VPN Cloud Hub to connect those sites together.
· Hub and Spoke Model
· Low Cost
· Operates over the public internet but traffic is encrypted.
· Requests going in are free
· AZ to AZ (private) - .01/Gbps
· AZ to AZ (Internet) – large costs
· Region to Region – costs even more
· To save money:
· Use Private IP addresses over public IP addresses to save on costs. This then utilizes the AWS backbone network.
· To cut costs:
· Same AZ grouping using private IP – cheaper but this is a single point of failure.
· Learn to build a VPC by memory
· Think of a VPC as a virtual datacenter in AWS
· A VPC consists of:
· Internet Gateways (IGW)
· Route tables
· Network ACLs
· Subnets
· Security Groups
· 1 subnet = 1 AZ.
· Security groups are stateful
· Network ACLs are stateless
· No transitive peering
· When you create a VPC, it is created with a default route table, Network ACLS, and security group.
· No subnets are created when you create a vpc
· Zone names in each account maybe different although they have the same name – they are randomized.
· Amazon reserves 5 Ips within your subnets (REMEMBER THIS!!!!!!!!!!!!!!)
· You can only have one (1) internet gateway per VPC
· Security groups cannot span VPCs
· When creating a NAT instance, disable source/destination check on the instance.
· NAT instances go 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, increate the instance size.
· You can create HA using autoscaling groups, multiple subnets, in different AZs, and a script to automate failover.
· They are behind a security group.
· A NAT GW is not behind a security group.
· It supports 5-45 Gbps
· Automatically has a public IP.