Baixar para ler offline
Carregado porAmazon Web Services LATAM
Criando e conectando seu datacenter virtual
O documento fornece uma introdução aos conceitos e funcionalidades da AWS VPC, incluindo: 1) Uma visão geral da AWS e o que é uma VPC; 2) Os passos para criar uma VPC e subnets, incluindo escolher ranges de IPs e configurar segurança; 3) Opções para conectividade, como Internet Gateways, VPNs e Direct Connect.
Mais conteúdo relacionado
Semelhante a Criando e conectando seu datacenter virtual
Criando e conectando seu datacenter virtual
- 1. © 2015, AmazonWeb Services, Inc. or its Affiliates. All rights reserved. Cláudio Freire Júnior, Solutions Architect Fortaleza, 23 de Agosto de 2016 Criando e Conectando Seu Datacenter Virtual
- 2. O que éesperado nessa sessão? • Overview sobre AWS; • Conceitos de VPC; • Setup básico de VPC; • Conectividade com ambiente on-premises; • Monitoramento do tráfego VPC;
- 3. O que éa AWS? AWS provê uma plataforma de infraestrutura na nuvem altamente confiável, escalável e de baixo custo que possibilita grandes ganhos para mais de 1 milhão de empresas em 190 países ao redor do mundo. Benefícios • Baixo custo • Elasticidade e Agilidade • Plataforma aberta e flexível • Segurança • Alcance global
- 4. 10o Aniversário Lançada em14 de Março, 2006
- 5.
- 6. E então, oque é VPC? • VPC – Virtual Private Cloud; • Isolamento lógico de rede; • Permite a segregação de redes (Público e Privada); • Serviço de escopo de região; • Permite a escolha do seu proprio range de Ips; • Provê conexão com infraestrutura on-premises;
- 7.
- 8.
- 9. Criando VPC: Passoa Passo Escolher o range de IPs Configurar subnets nas Availability Zones Criar rota para Internet (Utilizando Internet Gateway ou NAT) Autorizar tráfego de/para VPC
- 10. Escolher o rangede IPs
- 11. Notação CIDR CIDR rangeexample: 172.31.0.0/16 ~ Máscara: 255.255.0.0 172.31.0.0-172.31.255.255
- 12. Escolher os rangespara sua VPC 172.31.0.0/16 Recomendado: RFC1918 Recomendado: /16 (64K endereços)
- 13.
- 14. Configurar ranges deIP address para sua subnet 172.31.0.0/16 Availability Zone Availability Zone Availability Zone VPC subnet VPC subnet VPC subnet 172.31.0.0/24 172.31.1.0/24 172.31.2.0/24 sa-east-1a sa-east-1b sa-east-1c
- 15. Demo Criação de VPCe subnets
- 16. Criar rotas paraInternet
- 17. Tabela de Rotasna sua VPC • Possuem regras por onde os pacotes trafegarão; • Na VPC sempre possui tabela de rotas padrão; • … e você pode designar tabelas de rotas diferentes para subnets diferentes.
- 18. Tráfego destinado para VPCficam na VPC. Rotas Internas dentro da VPC
- 19. Internet Gateway (Utilizadopara subnet Públicas) Componente para envio de pacote, se o destino for Internet.
- 20. Tudo que nãotem destino para VPC, é enviado para Internet. Internet Gateway (Utilizado para subnet Públicas)
- 21. Acesso à Internetvia NAT Gateway VPC subnet VPC subnet 0.0.0.0/0 0.0.0.0/0 Public IP NAT Gateway
- 22.
- 23. Network ACLs =Regras stateless firewall Permitir todo o tráfego de entrada Aplicado no nível de subnet
- 24. Security Groups segueo fluxo da sua aplicação “MyWebServers” Security Group “MyBackends” Security Group Permitir acesso somente “MyWebServers”
- 25. Security Groups =stateful firewall Porta 80 aberta para o mundo
- 26. Security Groups =stateful firewall Porta do App Server aberta somente para frota de Web
- 27. Demo Criação de Internet Gatewaye Security Groups
- 28.
- 29. Além da conectividadecom Internet Roteamento no nivel de Subnet Conectando com a sua rede corporativa Conectando a outras VPCs
- 30. Roteamento no nívelde subnets
- 31. Diferentes tabelas derotas para diferentes subnets VPC subnet VPC subnet Possui rota para Internet Não possui rota para Internet
- 32. Conectando à outrasVPC: VPC Peering
- 33. Serviços compartilhados: UtilizandoVPC peering Serviços comuns/core • Autenticação/Diretório; • Monitoramento; • Logging; • Administração remota; • Scanning
- 34. Conectando sua rede: VirtualPrivate Network & Direct Connect
- 35. Conectando sua redecom VPN/Direct Conenct VPN Direct Connect
- 36. AWS VPN • Rotasestáticas ou dinâmicas (BGP); • Conexões iniciadas pelo Customer Gateway (definição do appliance do cliente); • IPSec Security Associations em modo de túnel; • Sempre é disponibilizado 2 Ips para conexão (HA); • Conectividade feita pela Internet; • Baixo custo de serviço;
- 37. VPN: O quevocê precisa saber? Customer Gateway Virtual Gateway Dois tuneis IPSec 192.168.0.0/16 172.31.0.0/16 192.168/16 Seu device de rede
- 38. Rotas para oVirtual Private Gateway Trafego para rede 192.168.0.0/16 irá pelo túnel
- 39. • Conexão dedicadae privada com a AWS; • Cobrança reduzida de data-out (data-in continua gratuito); • Performance consistente; • Pelo menos 1 ponto de conexão por região; • Opção para conexões redundantes; • Múltiplas contas AWS podem compartilhar a conexão; • Portas de conexões de 50M a 10G; • 50-500M feita com parceiro; • 1G e 10G direto com a AWS; AWS Direct Connect
- 40. AWS Direct Connect- Locais AWS Region AWS Direct Connect (Locais) Asia Pacific (Singapore) Equinix SG2 Asia Pacific (Sydney) Equinix SY3 Asia Pacific (Sydney) Global Switch Asia Pacific (Tokyo) Equinix OS1 Asia Pacific (Tokyo) Equinix TY2 China (Beijing) Sinnet JiuXianqiao IDC China (Beijing) CIDS Jiachuang IDC EU (Frankfurt) Equinix FR5 EU (Frankfurt) Interxion Frankfurt EU (Ireland) Eircom Clonshaugh EU (Ireland) TelecityGroup, London Docklands' South America (São Paulo) Terremark NAP do Brasil South America (São Paulo) Tivit US East (Virginia) CoreSite NY1 & NY2 US East (Virginia) Equinix DC1 - DC6 & DC10 US West (Northern California) CoreSite One Wilshire & 900 North Alameda, CA US West (Northern California) Equinix SV1 & SV5 US West (Oregon) Equinix SE2 & SE3 US West (Oregon) Switch SUPERNAP, Las Vegas
- 41. VPN vs DirectConnect •Ambos permitem conexão segura entre sua rede e VPC; • VPN é um par de túnel IPSec que trafegará pela Internet; • DirectConnect é conexão dedicada e latência controlada; • Para workloads de alta disponibilidade: Utilizar ambos (failover);
- 42. VPC Flow Logs:Analise seu tráfego Visibilidade da aplicabilidade do Security Group; Fazer troubleshooting de conectividade de rede; Possibilidade de analizar tráfego.
- 43. AWS VPC Endpoints:S3 sem Internet Gateway
- 44.
- 45. Recapitulando • VPC; • SubnetsPúblicas vs Subnets Privadas; • Tabelas de Rota; • VPC VPN vs Direct Connect; • Endpoints na rede privada.
- 46.
Notas do Editor
- #6 We also make it easy to expand globally to reach new customers without large capital investments in foreign markets 13 regions and 35 availability zones (August/2016) The unique design of AWS’ infrastructure ensures you can design for high availability Each region has at least two AZs, which exist on wholly separate power grids, flood plains, etc An AZ is a collection of multiple data centers to provide redundancy within the zone
- #8 … and that is exactly what VPC is. A Virtual Private Cloud is the network for your EC2 instances in the cloud. You get a lot of the control you would get over a non-virtual network that you manage by hand in your own data center. ‘V’ is for ‘virtual’, meaning that --unlike in your data center, where you had to have deep networking expertise in order to have full control over your network -- in a Virtual Private Cloud it’s easy and flexible. And the ‘P’ is for private, meaning that this network is yours; you control: CLICK The range of IP addresses and -- if you want -- even individual IP addresses in your network CLICK You can organize your network into subnetworks, with different routing rules applied to each (even if you are not a routing expert) CLICK You get to decide what kinds of connectivity you get. For example, you can choose to have all, part, or none of your VPC accessible to and from the Internet.
- #9 Let’s get started. We’re going to set up the simplest VPC possible, which is a VPC with Internet access. For many of you, a VPC like the one we’re about to set up will completely meet your networking needs in EC2 and may be everything you need to know about connectivity in EC2.
- #10 In brief, what we’re going to do is… Decide what IP addresses to use in our network Decide how we divide our network into subnetworks Make our VPC reachable from the Internet And make sure that the traffic we want reaching our instances -- and only the traffic we want reaching our instances -- reaches our instances.
- #13 Talking points: We recommend an RFC1918 range because this is what most people expect to see for IP addresses in a private network, which is what you have. We also recommend a /16 address range. It gives you plenty of space for eventual expansion. Unlike almost everything else in your VPC, this choice is fixed for your VPC. And since there are numerous ways to connect your VPC to other networks -- we’ll talk about that later -- you want to avoid conflicting with those ranges.
- #15 Talking points. Define Availability Zones and explain that this is your tool for building highly available services on EC2. We recommend creating one subnet in each Availability Zone; this will allow you to launch EC2 instances in any of the Availability Zones. We also recommend, unless you have a reason to do otherwise, that you choose a /24 block for each subnet. This gives you space for 251 IP addresses in your subnet. (It’s not 256: In each subnet, we reserve the low four and one high address in the range.) You can always add or delete subnets later. Further, we recommend starting with exactly one of these subnets in each AZ: It gives you plenty of room in your VPC for new subnets, as you need them.
- #16 Demo 1
- #17 Talking point: Everything interesting that happens with a VPC happens with a route. In this case, packets need to know how to get between your EC2 instances and the Internet.
- #18 É algo dificil na TI tradicional, mas é bem simples na AWS;
- #19 Tráfego que acontece dentro da VPC, fica dentro da VPC; Talking point: A brand-new route table contains just this single route. You’ll see that it talks about the address range of your VPC, and it says that those packets should be routed ‘local’ to the VPC. Traffic destined anywhere else goes nowhere. And sometimes this is what you want! But this is not what we want here: We want to be able to get to the Internet.
- #20 Talking points: Those of you who think about availability might be wondering whether this Internet Gateway is a single point of failure. It isn’t. It’s an abstraction for routing to the Internet that is backed by something highly available.
- #22 NAT Gateway foi anunciado em Setembro ultimo; NAT Gateway ficará em sua VPC pública; Serviço gerenciado; Let’s talk about this public/private subnet setup. Click The subnet on the right has a route to the Internet and is “public”; the subnet on the left doesn’t. But in some cases, your private-subnet EC2 instances have a need for outbound access to the Internet. Maybe they need to be able to reach a yum repo to update software. Those EC2 instances don’t have public IP addresses, though, so you will need their traffic NATted (spell it out: Network Address Translation) to a public IP address that you have. Click This is a new feature of VPC: As of December, you can now use a NAT Gateway. You can create a NAT Gateway in our console or our API. Click. That thing is a NAT Gateway Click. You’ll need to specify a public IP address -- an Elastic IP address. All your NATted traffic will appear, in the Internet, to be coming from this address. Click. And like everything else that has to do with VPC connectivity, you route your Internet-bound traffic to it. The rest is done for you. Like the Internet Gateway, it’s not a single point of failure. It’s something AWS manages for you in a highly-available way.
- #23 We now can route traffic to the Internet. But that doesn’t mean you want to exchange traffic with just anywhere. VPC gives you two tools to do this job that -- in a traditional data center -- you’d do by managing firewalls.
- #24 Talking points: We’ll start with Network ACLs, because it’s the simpler tool. You can configure NACL rules for both inbound and outbound traffic. NACLs are *not* connection-aware. Meaning that if you’re DENYing traffic to/from somewhere, it doesn’t matter if it’s a part of an established connection, it doesn’t reach your instance. These are a pretty blunt tool. I’ll say that these are used by customers less often than Security Groups, which is your other tool…
- #25 Da um exemplo de Webserver ”virados para internet”… Servidor de aplicação usando porta 2345; Talking points: Security Groups are a more flexible tool than NACLs. A Security Group is what it sounds like -- a group. The members of the group are EC2 instances, which will often share a common purpose. For example, in this picture…
- #26 Security Groups allow you to attach rules to this group of EC2 instances. They’re closed by default, meaning that unless I allow the traffic, the traffic won’t be let through. Security Groups let you reference CIDR blocks, like MyWebServers, which want to receive traffic from everywhere.
- #27 They can also reference other Security Groups, like MyBackends. That’s convenient because you don’t need to stay on top of the elastic, changing membership of the MyWebServers Security Group. Another thing to note about Security Groups is that they are connection-aware. While we have Security Groups for both inbound and outbound traffic, if you allow a particular connection to be established outbound, the reply traffic will be authorized. For example, if your egress SG rules allow the MyBackends to initiate connections to, say, a yum repo, the reply traffic does not need to be explicitly authorized in the ingress SG rules.
- #28 Demo 2
- #29 Segue: We’ve talked about what goes on in an Internet-connected VPC. Let’s talk about some other connectivity options for your VPC.
- #32 Voltando para o mesmo caso que mostramos anteriormente (Webserver/APP Server); Segregação semelhante a que possui em TI tradicional; Alguma necessidade específica para que serviços dentro de VPC privada (não ficarão expostas); Backend possui dados sensíveis, não pode expor para internet; Talking points: In some cases, your network requirements will call for parts of your VPC to be completely disconnected from the Internet. A common reason for this might be compliance / auditing requirements, that require you to demonstrate that your resources are not routable from the Internet. It’s also something that customers sometimes choose for a belt-and-suspenders approach to security. In our documentation, the subnet with a route to the Internet is called a ‘public subnet,’ and the subnet without such a route is called a ‘private subnet.’ In point of fact, though, there is nothing inherently public about that ‘public subnet’; it is absolutely possible -- and in fact simpler -- to use Internet-connected VPCs with well-designed Security Groups. It’s plenty secure, and many customers choose this simpler option.
- #34 No overlap; Comunicação privada; Security group Talking points: Mention that VPC Peering is your tool if you are trying to establish private connectivity across different accounts. You might have different accounts to make billing straightforward in your organization.
- #35 Talking point: A VPC peering doesn’t happen until both sides of the peering have approved it.
- #39 Talking point: Go back to the point that all connectivity in VPC is done through routes in the route table. In this case, the gateway you’re routing to is the peering connection (pcx). You are saying that any traffic that looks like it’s destined for the remote peered VPC should get routed to the peering.
- #40 Segue: We just talked about getting between VPCs, either in your own account or across accounts. Now let’s talk about ways to securely and privately connect your VPC to your own network, for example your own data center. You might be doing this as part of migrating to the cloud, or as part of a hybrid deployment.
- #41 The two technologies for doing this are Virtual Private Network and DirectConnect. I’ll describe each of these, and then when you might choose each.
- #42 Next, lets consider the requirements to establish a VPN between your customer gateway and the Virtual Private Gateway at AWS. Firstly, connections must be initiated by the customer gateway. This may mean you need to generate some ‘interesting’ traffic such that your device brings the connection up. We utilise a Pre-Shared Key for the IKE Security association and we then require your hardware to support IPSec SA’s in Tunnel mode. In terms of encryption, we currently support AES 128-bit encryption and use of the SHA-1 hashing function. DH Group 2 is used for Perfect Forward Secrecy and we support Dead Peer Detection. Finally, it’s important that your customer gateway supports the option to Fragment IP Packets before encryption – even if the Don’t Fragment (DF) header is set.
- #43 VPN IPSec, documentado para um série de vendors; Static routes ou BGP; Here’s your data center, and here’s your VPC. Click. In your data center, you will need your own networking device, for example a router. There’s a list of Customer Gateway devices we have tested from several vendors in our documentation, with specific instructions for setting up each. Click On the VPC side, you’ll create a Virtual Gateway, or VGW. It has the word ‘gateway’ in it because, like the other gateways, it’s something you can route packets to in your route table. The VGW is our end of the VPN connection. Click. And, following the instructions for your Customer Gateway, we get two redundant encrypted IPSec tunnels established. These terminate in different Availability Zones on our side. We strongly recommend that you configure both tunnels.
- #44 This gateway is like any other gateway in your VPC: You route data-center-bound traffic to it.
- #45 Each AWS Region is associate with at least 1 Direct Connect Location. These locations are large co-lo facilties like Equinix or Coresite with large concentrations of customers. We extend private fiber from our AWS region to the Direct Connect locations associated to the same region. We set up a patch panel in a Meet Me Room and allow what it says on the box – Direct Connections into the Region If you already have a footprint in these locations, its an easy cross connect into Direct Connect. If not, you can work with one of our Telco Partners to establish last mile connectivity. (or your OWN telco) US-EAST-1, US-WEST-1, and EU-WEST-1 all have 2 DX locations Network data out from DX SEA is 0.02 per GB vs 0.12 per GB for US West Internet out (for first 10 TB) Recommend redundant fiber connection – or at least a VPN connection as a backup. DX will always be a preferred route by the VGW as long as its up.
- #47 Talking point: More data to transfer, use Direct Connect.
- #48 Segue: Especially if you’re coming from a traditional networking environment, you know that operating DNS servers in your network is no small task. Fortunately, VPC does this for you.
- #49 Pode utilizar seu proprio DNS dentro da AWS; Your VPC has two DNS settings on it. You will probably want to say yes to both. Click. DNS Resolution means that Amazon does the DNS for you. You have the option of doing your own DNS in your VPC. The vast majority of customers choose to have Amazon provide the DNS. Click. DNS Hostnames means that EC2 will assign DNS names to every EC2 instance in your VPC. Typically, you want this. Let’s take a look at these hostnames do; they have some useful properties.
- #50 Your EC2 instance gets two DNS names. Click. One is internal, which means that it resolves to the private IP address of your instance. Click. The other is an external DNS name. This resolves to…
- #51 … The right answer, from wherever you try to resolve it. Here I’m trying to resolve this hostname from anywhere -- outside my VPC, even outside EC2. I get a public IP address, like I should. That’s the right way for me to reach this instance from where I am.
- #52 But when I resolve this from an EC2 instance inside my VPC, notice how I get a private IP address. This is exactly the right answer: Within my VPC, I should be using my VPC’s IP addresses -- i.e. private IP addresses -- to get around. Moreover, using addresses inside my VPC ensures that the Security Groups that I’ve set up take effect correctly.
- #53 Beyond that, VPC gives you the power to really take control over DNS resolution in your VPC… without operating a single DNS resolver.
- #54 Let’s set up a Private Hosted Zone for my VPC. I’m in the Route53 console right now. You’ll notice that I’m creating this zone on demohostedzone.org. I don’t even own this domain name. I don’t have to. Now that I’ve done this and associated it with my VPC, I get to decide how names in demohostedzone.org resolve.
- #55 I’ll create some records. In my VPC, I’m saying that example.demohostedzone.org resolves to 172.31.0.99.
- #56 … And let’s hop onto an EC2 instance in my VPC. Resolving example.demohostedzone.org gives me the answer I said it should: 172.31.0.99
- #57 Lançado mais ou menos há 1 ano; Consegue ver os pacotes que estão sendo bloqueados; Talking point: VPC not only gives you flexible but precise control over the management of your network, it also gives you a level of visibility into what is actually going on in there. Without managing any infrastructure, you can turn on VPC Flow Logs and get aggregated packet and byte counts into any EC2 instances that you want.
- #58 Another new feature of VPC from last year is VPC Endpoints for S3. S3 is a critical part of many applications in AWS; it’s often where your data lives. A VPC Endpoint is a secure gateway to S3 that allows you to specify Identity and Access Management policy both at the VPC end -- what your VPC can do in S3 -- and at the S3 bucket -- you can, for example, specify that only this VPC can interact with this bucket. And you can turn this on without changing any of your code or workflows with VPC.
- #59 Segue: Especially if you’re coming from a traditional networking environment, you know that operating DNS servers in your network is no small task. Fortunately, VPC does this for you.