#GlueCon 2014 Notes: VPC Migration: Flying Blind on a Rocket Cycle – Matthew Boeckman, Craftsy
VPC Migration: Flying Blind on a Rocket Cycle – Matthew Boeckman, Craftsy “VPC is mature network topology for AWS” Network ACL’s allow for true edge blocking Instances can be members of multiple security groups and can be added/removed as desired post-launch (classic cannot do this) Site-to-Site VPN connectiviy enables extension of your network to AWS When you migrate, keep it simple and get there now rather than later when it is more complex (and keep it simple) What they hated about EC2-classic Can’t change security groups per-IP maintenance of SG’s across regions Must allow TCP 22 from 0.0.0.0 (the world) No edge to block traffic VPC overview NAT instance to route private traffic to public. They use m1-medium as it seems big enough Make sure you have a failover NAT instance to prevent SPOF (use script or manual if desired) Once-click config for your firewall if it is on the list in the AWS Docs Cross-region VPN is difficult and you will likely need a network engineer or a good understanding of networking Reserved instances purchased in EC2 classic do not automatically transfer, so don’t forget to transfer them (doesn’t cost anything) Difficulties in migrating to VPC Traditional networking typically allows you to enable debug ACLs and packet-sniffing – with VPC you don’t have these tools to troubleshoot This requires more patience as you only have netcat and tcpdump When troubleshooting traffic issues, “be the packet” – understand the packet as it becomes an inbound/outbound packet in one direction, outbound/inbound in the opposite direction VPC has new limits: http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Appendix_Limits.html These limits may require changes to your architecture ACLs are not stateful (unlike every other firewall on the market) so it doesn’t track the return traffic So, let your ACLs be permissive and ALLOW ALL and then DENY a specific IP address/range instead SNS has no legs in VPC. Systems subscribing to SNS topics from private subnets need an HTTP proxy in a public subnet for SNS to reach them Redshift/RDS works fine in VPC Route53 has no support for “views” in VPC – a public DNS name that is seen via dig publicly with the public IP and private IP on the private network Tips for migrating to VPC Lean on your AWS support or account teams Start with subnets and basic NAT, VPN Move to dev environment and wait a week to verify everything is working properly and no hidden gotchas/missing ACLs Move to preprod and do the same Then clone for prod Shutdown classic, promote instances, etc. – their total downtime was approx 40 min for a major network topology switchover Used OpenSWAN over OpenVPN only because the AWS docs recommended them
VPC Migration: Flying Blind on a Rocket Cycle – Matthew Boeckman, Craftsy
- “VPC is mature network topology for AWS”
- Network ACL’s allow for true edge blocking
- Instances can be members of multiple security groups and can be added/removed as desired post-launch (classic cannot do this)
- Site-to-Site VPN connectiviy enables extension of your network to AWS
- When you migrate, keep it simple and get there now rather than later when it is more complex (and keep it simple)
- What they hated about EC2-classic
- Can’t change security groups
- per-IP maintenance of SG’s across regions
- Must allow TCP 22 from 0.0.0.0 (the world)
- No edge to block traffic
- VPC overview
- NAT instance to route private traffic to public. They use m1-medium as it seems big enough
- Make sure you have a failover NAT instance to prevent SPOF (use script or manual if desired)
- Once-click config for your firewall if it is on the list in the AWS Docs
- Cross-region VPN is difficult and you will likely need a network engineer or a good understanding of networking
- Reserved instances purchased in EC2 classic do not automatically transfer, so don’t forget to transfer them (doesn’t cost anything)
- Difficulties in migrating to VPC
- Traditional networking typically allows you to enable debug ACLs and packet-sniffing – with VPC you don’t have these tools to troubleshoot
- This requires more patience as you only have netcat and tcpdump
- When troubleshooting traffic issues, “be the packet” – understand the packet as it becomes an inbound/outbound packet in one direction, outbound/inbound in the opposite direction
- VPC has new limits: http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Appendix_Limits.html
- These limits may require changes to your architecture
- ACLs are not stateful (unlike every other firewall on the market) so it doesn’t track the return traffic
- So, let your ACLs be permissive and ALLOW ALL and then DENY a specific IP address/range instead
- SNS has no legs in VPC. Systems subscribing to SNS topics from private subnets need an HTTP proxy in a public subnet for SNS to reach them
- Redshift/RDS works fine in VPC
- Route53 has no support for “views” in VPC – a public DNS name that is seen via dig publicly with the public IP and private IP on the private network
- Tips for migrating to VPC
- Lean on your AWS support or account teams
- Start with subnets and basic NAT, VPN
- Move to dev environment and wait a week to verify everything is working properly and no hidden gotchas/missing ACLs
- Move to preprod and do the same
- Then clone for prod
- Shutdown classic, promote instances, etc. – their total downtime was approx 40 min for a major network topology switchover
- Used OpenSWAN over OpenVPN only because the AWS docs recommended them