AWS VPC best practices 2016 by bogdan Naydenov - presentation on 1st #AWSBulgraia user group meeting at - SkyScanner office #SkyScannerSofia

1. Amazon VPC
best practices 2016
Bogdan Naydenov
23 Feb 2016
#AWSBulgaria User Group

2. Who am I
Bogdan Naydenov
Senior IT Enterprise Architect - Telerik Platform Services team at Progress
Software
Mostly Operational background with more than 18 years of IT experience
MongoDB DBA
MongoDB Developer
MongoDB Advanced Deployment and Operations
https://www.linkedin.com/in/bnaydenov @BobbyNaydenov

3. ● Static private IP address
● Elastic Network Interfaces: possible to bind multiple Elastic Network Interfaces to a
single instance
● Internal Elastic Load Balancers
● Advanced Network Access Control
● DHCP options
● Predictable internal IP ranges
● Moving NICs and internal IPs between instances
● VPN connectivity
● Heightened security
Introduction to VPC

4. Practice 1:
Get your Amazon VPC combination right
● Public facing VPC
● Public and Private setup VPC
● Amazon VPC with Public and Private Subnets and Hardware VPN Access
● Amazon VPC with Private Subnets and Hardware VPN Access
● Software based VPN access

5. Public facing VPC Public and Private setup VPC

6. Amazon VPC with Public and Private Subnets
and Hardware VPN Access

7. Practice 2:
Always span your Amazon VPC across multiple
subnets in Multiple Availability zones inside a Region
● This helps is architecting high availability inside your Amazon VPC properly

8. Practice 3:
Choose your CIDR Blocks
● VPC IP range - /28 netmask (16 IP’s) and /16 netmask (65536 IP’s).
● !! VPC CIDR range can not be changed
● Choose Amazon VPC CIDR range which not overlaps or conflicts with the CIDR
blocks in your On premise/Data center

9. Practice 4:
Isolate according to your Use case
● Create separate Amazon VPC for Development , Staging and Production
environment - prefer this one
● Create one Amazon VPC with Separate Subnets/Security/Isolated for Production ,
Staging and development.

10. Practice 5:
Securing Amazon VPC
● Secure your Amazon VPC using Firewall virtual appliance, Web application firewall available from Amazon
Web Services Marketplace.
● You can configure Intrusion Prevention or Intrusion Detection virtual appliances and secure the protocols
and take preventive/corrective actions in your VPC
● Configure VM encryption tools which encrypts your root and additional EBS volumes. The Key can be
stored inside AWS (or) in your Data center outside Amazon Web Services depending on your compliance
needs.
● Enable the CloudTrail to audit in the VPC environments ACL policy's. Enable CloudTrail : Apply anti virus
for cleansing specific EC2 instances inside VPC.
● Configure Site to Site VPN for securely transferring information between Amazon VPC in different regions
or between Amazon VPC to your On premise Data center
● Enable VPC Flow Logs

11. Practice 6:
Understand Amazon VPC Limits
● VPC and Subnets:
● Gateways:
● Network ACLs:
● Route Tables:
● Security Groups:
● Check all limits here:
http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Appendix_Limits.html

12. Practice 7:
Use security groups and Network ACLs wisely
● use security groups over Network ACLs inside Amazon VPC wherever applicable for better control
● Security groups are applicable on EC2 instance level
● network ACL is applicable on Subnet level
● Security groups are used for Whitelist mostly
● To blacklist IPs, one can use Network ACLs

13. Practice 8:
Tier your Security Groups
● Create different security groups for different tiers of your infrastructure architecture inside your VPC.
If you have Web, App, DB, Cache tiers create different security group for each of them.
● Creating tier wise security groups will increase the infrastructure security inside Amazon VPC.
EC2 instances in each tier can talk only on application specified ports and not at all ports.
If you create Amazon VPC security groups for each and every tier/service separately it will be easier to
open a port to a particular service.
● Don't use same security group for multiple tiers of instances, this is a bad practice.
● Open ports for security group instead of IP ranges

14. Practice 9:
Standardize your Security Group Naming conventions
● Following a security group naming conventions inside Amazon VPC will improve operations/management
for large scale deployments inside VPC. It also avoids manual errors, leaks and saves cost and time
overall.
Good example: Simple ones like Prod_DMZ_Web_SG or Dev_MGMT_Utility_SG
Bad example: EUFA3LXWEBP001- EU Frankfurt AZ 3 Linux Web Server Production 001

15. Practice 10:
ELB on Amazon VPC
● When using Amazon ELB for Web Applications, put all other EC2 instances( Tiers like App,cache,DB etc)
in private subnets as much possible. Unless there is a specific requirement where instances need outside
world access and EIP attached, put all instances in private subnet only.
● Only ELBs should be provisioned in Public Subnet as secure practice in Amazon VPC environment.

16. Practice 11:
Control your outgoing traffic in Amazon VPC
● for better security, for the traffic going to internet gateway use software's like Squid or other proxy to restrict
the ports,URL,Domains etc... so that all traffic go through the proxy tier controlled and it also gets logged.
● Using these proxy/security systems we can also restrict the unwanted ports, by doing so, if there is any
security compromise to the application running inside Amazon VPC they can be detected by auditing the
restricted connections captured from the logs. This helps in corrective security measure.
● Enable VPC Flow Logs + CloudWatch

17. Practice 12:
NEW!! use NAT managed gateways
● Retire your NAT instances and use NAT managed gateway
● NAT managed gateways - introduced on Dec 17 2015
● The gateway has built-in redundancy for high availability.
● Each gateway that you create can handle up to 10 Gbps of bursty TCP, UDP, and ICMP traffic, and is
managed by Amazon.
● You control the public IP address by assigning an Elastic IP Address when you create the gateway.

18. Practice 13:
Use EIP when needed
● At times you may need to keep a part of your application services to be kept in Public subnet for external
communication. It is recommended practice to associate them with Amazon Elastic IP and whitelist these IP
address in the target services used by them

19. Practice 14:
Plan your VPN Connections between On-Premise DC to Amazon VPC
● AWS hardware VPN - You can create an IPsec, hardware VPN connection between your VPC and your
remote network
● AWS Direct Connect - AWS Direct Connect provides a dedicated private connection from a remote network
to your VPC.
● AWS VPN CloudHub - If you have more than one remote network (for example, multiple branch offices),
you can create multiple AWS hardware VPN connections via your VPC to enable communication between
these networks
● Software VPN - You can create a VPN connection to your remote network by using an Amazon EC2
instance in your VPC that's running a software VPN appliance.

20. AWS VPN CloudHub

21. Practice 15:
Network ACL best practices
● Allow and Deny Network ACL - Create Internet outbound allow and deny network ACL in your VPC.
Example:
First network ACL: Allow all the HTTP and HTTPS outbound traffic on public internet facing subnet.
Second network ACL: Deny all the HTTP/HTTPS traffic. Allow all the traffic to Squid proxy server or any virtual appliance.
● Restricting Network ACL :
Block all the inbound and outbound ports. Only allow application request ports. These are stateless traffic filters that apply to all traffic
inbound or outbound from a Subnet within VPC. AWS recommended Outbound rules

22. Practice 16:
Use Amazon VPC Peering
● Large Enterprises usually run Multiple Amazon VPC in single region and some of their applications are so
interconnected that they may need to access them privately + securely inside AWS. Example Active
Directory, Exchange, Common business services will be usually interconnected.
● Large Enterprise have different AWS accounts for different business units/teams/departments , at times
systems deployed by some business units in different AWS accounts need to be shared or need to
consume a shared resource privately. Example: CRM , HRMS ,File Sharing etc can be internal and shared.
In such scenarios VPC peering comes very useful.
● Customer can peer their VPC with their core suppliers to have tighter integrated access of their systems.
● Companies offering Infra/Application Managed Services on AWS can now safely peer into customer
Amazon VPC and provide monitoring and management of AWS resources.

23. Practice 16:
Use Amazon VPC Peering limits
● You cannot create a VPC peering connection between VPCs that have matching or overlapping CIDR
blocks.
● You cannot create a VPC peering connection between VPCs in different regions.
● You have a limit on the number active and pending VPC peering connections that you can have per VPC.
● VPC peering does not support transitive peering relationships; in a VPC peering connection, your VPC will
not have access to any other VPCs that the peer VPC may be paired with. This includes VPC peering
connections that are established entirely within your own AWS account.
● You cannot have more than one VPC peering connection between the same two VPCs at the same time.
● You cannot reference a security group from the peer VPC as a source or destination for ingress or egress
rules in your security group. Instead, reference CIDR blocks of the peer VPC as the source or destination of
your security group's ingress or egress rules.
● An instance's public DNS hostname will not resolve to its private IP address across peered VPCs.

24. Two VPCs Peered Together Two VPCs Peered Together Three VPCs Peered Together
One VPC Peered With Multiple
VPCs
Multiple VPCs Peered Together

25. Bonus TIPS:
DNS resolving between Amazon VPC and on-premises networks
● common approach used to address this need is to run DNS servers on Amazon EC2 across multiple
Availability Zones (AZs) and integrate them with private on-premises DNS domains. In many cases, though,
a managed private DNS service (accessible outside of a VPC) with less administrative overhead is
advantageous.
● Using AWS Directory Service Simple AD to forward DNS requests to Route 53
Resolving DNS requests for on-premises resources originating from AWS
http://amzn.to/1XJQ4Ht
● DNS Resolution Between On-Premises Networks and AWS Using AWS Directory Service and Microsoft
Active Directory
http://amzn.to/1X28AKS

26. Using AWS Directory Service Simple AD
to forward DNS requests to Route 53

27. Resolving DNS requests for on-premises
resources originating from AWS

28. DNS Resolution Between On-Premises Networks and
AWS Using AWS Directory Service and Microsoft Active Directory

29. Resolving DNS requests for on-premises
resources originating from AWS with Microsoft Active Directory

30. Thank you attending
#AWSBulgaria
Q&A