Egress-only internet gateway basics

IPv6 addresses are globally unique, and are therefore public by default. If user want your instance to be able to access the internet, but you want to prevent resources on the internet from initiating communication with your instance, you can use an egress-only internet gateway.

VPC End point and Interfaces

To access AWS resources in Private subnet, one can Create VPC End point Gateway or Interfaces. for S3 and Dynamo DB we need to create VPC gateway for rest its Interfaces

AWS Direct Connect

AWS Direct connect is to establish connection with internal network with AWS services.

Connection and Virtual Interfaces are key components of AWS direct Connect.

Network requirements

To use AWS Direct Connect in an AWS Direct Connect location, your network must meet one of the following conditions:

• Your network is colocated with an existing AWS Direct Connect location.
• You are working with an AWS Direct Connect partner who is a member of the AWS Partner Network (APN)
• You are working with an independent service provider to connect to AWS Direct Connect.

In addition, your network must meet the following conditions:

• Your network must use single-mode fiber with a 1000BASE-LX (1310 nm) transceiver for 1 gigabit Ethernet or a 10GBASE-LR (1310 nm) transceiver for 10 gigabit Ethernet.
• Auto-negotiation for the port must be disabled. Port speed and full-duplex mode must be configured manually.
• 802.1Q VLAN encapsulation must be supported across the entire connection, including intermediate devices.
• Your device must support Border Gateway Protocol (BGP) and BGP MD5 authentication.
• (Optional) You can configure Bidirectional Forwarding Detection (BFD) on your network. Asynchronous BFD is automatically enabled for AWS Direct Connect virtual interfaces, but does not take effect until you configure it on your router.

VPC flow logs vs ELB logs

the syntax of ELB logs are

timestamp elb client:port backend:port request_processing_time backend_processing_time response_processing_time elb_status_code backend_status_code received_bytes sent_bytes "request" "user_agent" ssl_cipher ssl_protocol

The following is an example log entry for an HTTP listener (port 80 to port 80):

2015-05-13T23:39:43.945958Z my-loadbalancer 192.168.131.39:2817 10.0.0.1:80 0.000073 0.001048 0.000057 200 200 0 29 "GET http://www.example.com:80/ HTTP/1.1" "curl/7.38.0" - -

By default, the log line format for a VPC flow log record is a space-separated string that has the following set of fields in the following order.

<version> <account-id> <interface-id> <srcaddr> <dstaddr> <srcport> <dstport> <protocol> <packets> <bytes> <start> <end> <action> <log-status>

Example of VPC flow log SH traffic (destination port 22, TCP protocol) to network interface eni-1235b8ca123456789 in account 123456789010 was allowed.

Protocol filed is replaced by number like 6 or something else. refer http://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml to understand what this number represents. 6-TCP, 1-ICMP,17-UDP, 4 and 6 represents IP4 and IP6 encapsulation respectively.

2 123456789010 eni-1235b8ca123456789 172.31.16.139 172.31.16.21 20641 22 6 20 4249 1418530010 1418530070 ACCEPT OK

so from the above data, it is evident that ELB logs and VPC flow logs has different fields. VPC flow logs applicable to entire VPC where as ELB logs are only to specific ELB. Based on the use case, one should opt for VPC or ELB logs

set up a VPN connection to allow communication between the instances from your AWS VPC to your on-premises data center

Setting up a VPN connection to AWS requires you to have both Virtual Private Gateway and Customer Gateway available. To enable instances in your VPC to reach your customer gateway, you must configure your route table to include the routes used by your VPN connection and point them to your virtual private gateway. You can enable route propagation for your route table to automatically propagate those routes to the table for you.

when you create a virtual private gateway, it is only optional that you specify a private Autonomous System Number (ASN) for the Amazon side of the gateway. The ASN must be different from the BGP ASN specified for the customer gateway.

Main Route table vs custom route table

A route table contains a set of rules, called routes, that are used to determine where network traffic from your subnet or gateway is directed.

When you create a VPC, it automatically has a main route table. The main route table controls the routing for all subnets that are not explicitly associated with any other route table. On the Route Tables page in the Amazon VPC console, you can view the main route table for a VPC by looking for Yes in the Main column.

By default, a custom route table is empty and you add routes as needed. When you use the VPC wizard in the console to create a VPC with an internet gateway, the wizard creates a custom route table and adds a route to the internet gateway. One way to protect your VPC is to leave the main route table in its original default state. Then, explicitly associate each new subnet that you create with one of the custom route tables you’ve created. This ensures that you explicitly control how each subnet routes traffic.

NATSG security group

Define the NATSG security group as described in the following table to enable your NAT instance to receive Internet-bound traffic from instances in a private subnet, as well as SSH traffic from your network. The NAT instance can also send traffic to the Internet, which enables the instances in the private subnet to get software update

source	Protocol	Port Range	Comments
10.0.1.0/24	TCP	80	Allow inbound HTTP traffic from servers in the private subnet
10.0.1.0/24	TCP	443	Allow inbound HTTPS traffic from servers in the private subnet
Public IP address range of your home network	TCP	22	Allow inbound SSH access to the NAT instance from your home network (over the Internet gateway)

Destination	protocol	Port Range	Comments
0.0.0.0/0	TCP	80	Allow outbound HTTP access to the Internet
0.0.0.0/0	TCP	443	Allow outbound HTTPS access to the Internet

AWS Direct Connect Public and Private virtual interfaces

Refer https://aws.amazon.com/premiumsupport/knowledge-center/public-private-interface-dx/

Ephemeral ports

The example network ACL in the preceding section uses an ephemeral port range of 32768-65535. However, you might want to use a different range for your network ACLs depending on the type of client that you’re using or with which you’re communicating.

The client that initiates the request chooses the ephemeral port range. The range varies depending on the client’s operating system.

• Many Linux kernels (including the Amazon Linux kernel) use ports 32768-61000.
• Requests originating from Elastic Load Balancing use ports 1024-65535.
• Windows operating systems through Windows Server 2003 use ports 1025-5000.
• Windows Server 2008 and later versions use ports 49152-65535.
• A NAT gateway uses ports 1024-65535.
• AWS Lambda functions use ports 1024-65535.

For example, if a request comes into a web server in your VPC from a Windows XP client on the internet, your network ACL must have an outbound rule to enable traffic destined for ports 1025-5000.

If an instance in your VPC is the client initiating a request, your network ACL must have an inbound rule to enable traffic destined for the ephemeral ports specific to the type of instance (Amazon Linux, Windows Server 2008, and so on).

In practice, to cover the different types of clients that might initiate traffic to public-facing instances in your VPC, you can open ephemeral ports 1024-65535. However, you can also add rules to the ACL to deny traffic on any malicious ports within that range. Ensure that you place the deny rules earlier in the table than the allow rules that open the wide range of ephemeral ports.