Networking & Content Delivery | Amazon Virtual Private Cloud (VPC) Flashcards

Question

How do I connect a VPC to my corporate datacenter? Connectivity Amazon Virtual Private Cloud (VPC) | Networking & Content Delivery

Answer 1

Establishing a hardware VPN connection between your existing network and Amazon VPC allows you to interact with Amazon EC2 instances within a VPC as if they were within your existing network. AWS does not perform network address translation (NAT) on Amazon EC2 instances within a VPC accessed via a hardware VPN connection.

Answer 2

Yes, you will need to enable NAT-T and open UDP port 4500 on your NAT device.

Answer 3

You will use the public IP address of your NAT device.

Answer 4

You will need to disable NAT-T on your device. If you don’t plan on using NAT-T and it is not disabled on your device, we will attempt to establish a tunnel over UDP port 4500. If that port is not open the tunnel will not establish.

Answer 5

You will use the public IP address of your NAT device for the CGW for each of your connections. You will also need to make sure UDP port 4500 is open.

Answer 6

The AWS VPN service is a route-based solution, so when using a route-based configuration you will not run into SA limitations. If, however, you are using a policy-based solution you will need to limit to a single SA, as the service is a route-based solution.

Answer 7

You can use any IPv4 address range, including RFC 1918 or publicly routable IP ranges, for the primary CIDR block. For the secondary CIDR blocks, certain restrictions apply. Publicly routable IP blocks are only reachable via the Virtual Private Gateway and cannot be accessed over the Internet through the Internet gateway. AWS does not advertise customer-owned IP address blocks to the Internet. You can allocate an Amazon-provided IPv6 CIDR block to a VPC by calling the relevant API or via the AWS Management Console.

Answer 8

You assign a single Classless Internet Domain Routing (CIDR) IP address range as the primary CIDR block when you create a VPC and can add up to four (4) secondary CIDR blocks after creation of the VPC. Subnets within a VPC are addressed from these CIDR ranges by you. Please note that while you can create multiple VPCs with overlapping IP address ranges, doing so will prohibit you from connecting these VPCs to a common home network via the hardware VPN connection. For this reason we recommend using non-overlapping IP address ranges. You can allocate an Amazon-provided IPv6 CIDR block to your VPC.

Answer 9

Default VPCs are assigned a CIDR range of 172.31.0.0/16. Default subnets within a default VPC are assigned /20 netblocks within the VPC CIDR range.

Answer 10

Yes, you can route traffic via the hardware VPN connection and advertise the address range from your home network.

Answer 11

Currently, Amazon VPC supports five (5) IP address ranges, one (1) primary and four (4) secondary for IPv4. Each of these ranges can be between /28 (in CIDR notation) and /16 in size. The IP address ranges of your VPC should not overlap with the IP address ranges of your existing network. For IPv6, the VPC is a fixed size of /56 (in CIDR notation). A VPC can have both IPv4 and IPv6 CIDR blocks associated to it.

Answer 12

Yes. You can expand your existing VPC by adding four (4) secondary IPv4 IP ranges (CIDRs) to your VPC. You can shrink your VPC by deleting the secondary CIDR blocks you have added to your VPC. You cannot however change the size of the IPv6 address range of your VPC.

Answer 13

Currently you can create 200 subnets per VPC. If you would like to create more, please submit a case at the support center.

Answer 14

The minimum size of a subnet is a /28 (or 14 IP addresses.) for IPv4. Subnets cannot be larger than the VPC in which they are created. For IPv6, the subnet size is fixed to be a /64. Only one IPv6 CIDR block can be allocated to a subnet.

Answer 15

No. Amazon reserves the first four (4) IP addresses and the last one (1) IP address of every subnet for IP networking purposes.

Answer 16

When you launch an Amazon EC2 instance within a VPC, you may optionally specify the primary private IP address for the instance. If you do not specify the primary private IP address, AWS automatically addresses it from the IP address range you assign to that subnet. You can assign secondary private IP addresses when you launch an instance, when you create an Elastic Network Interface, or any time after the instance has been launched or the interface has been created.

Answer 17

Primary private IP addresses are retained for the instance's or interface's lifetime. Secondary private IP addresses can be assigned, unassigned, or moved between interfaces or instances at any time.

Answer 18

No. An IP address assigned to a running instance can only be used again by another instance once that original running instance is in a "terminated" state.

Answer 19

No. You can specify the IP address of one instance at a time when launching the instance.

Answer 20

You can assign any IP address to your instance as long as it is: Part of the associated subnet's IP address range Not reserved by Amazon for IP networking purposes Not currently assigned to another interface

Answer 21

Yes. You can assign one or more secondary private IP addresses to an Elastic Network Interface or an EC2 instance in Amazon VPC. The number of secondary private IP addresses you can assign depends on the instance type. See EC2 User Guide for more information on the number of secondary private IP addresses that can be assigned per instance type.

Answer 22

Yes, however, the EIP addresses will only be reachable from the Internet (not over the VPN connection). Each EIP address must be associated with a unique private IP address on the instance. EIP addresses should only be used on instances in subnets configured to route their traffic directly to the Internet gateway. EIPs cannot be used on instances in subnets configured to use a NAT gateway or a NAT instance to access the Internet. This is applicable only for IPv4. Amazon VPCs do not support EIPs for IPv6 at this time.

Answer 23

An Amazon VPC router enables Amazon EC2 instances within subnets to communicate with Amazon EC2 instances in other subnets within the same VPC. The VPC router also enables subnets, Internet gateways, and virtual private gateways to communicate with each other. Network usage data is not available from the router; however, you can obtain network usage statistics from your instances using Amazon CloudWatch.

Answer 24

Yes. You can create route rules to specify which subnets are routed to the Internet gateway, the virtual private gateway, or other instances.

Answer 25

Yes. You may create a default route for each subnet. The default route can direct traffic to egress the VPC via the Internet gateway, the virtual private gateway, or the NAT gateway.

Answer 26

Amazon EC2 security groups can be used to help secure instances within an Amazon VPC. Security groups in a VPC enable you to specify both inbound and outbound network traffic that is allowed to or from each Amazon EC2 instance. Traffic which is not explicitly allowed to or from an instance is automatically denied. In addition to security groups, network traffic entering and exiting each subnet can be allowed or denied via network Access Control Lists (ACLs).

Answer 27

Security groups in a VPC specify which traffic is allowed to or from an Amazon EC2 instance. Network ACLs operate at the subnet level and evaluate traffic entering and exiting a subnet. Network ACLs can be used to set both Allow and Deny rules. Network ACLs do not filter traffic between instances in the same subnet. In addition, network ACLs perform stateless filtering while security groups perform stateful filtering.

Answer 28

Stateful filtering tracks the origin of a request and can automatically allow the reply to the request to be returned to the originating computer. For example, a stateful filter that allows inbound traffic to TCP port 80 on a webserver will allow the return traffic, usually on a high numbered port (e.g., destination TCP port 63, 912) to pass through the stateful filter between the client and the webserver. The filtering device maintains a state table that tracks the origin and destination port numbers and IP addresses. Only one rule is required on the filtering device: Allow traffic inbound to the web server on TCP port 80. Stateless filtering, on the other hand, only examines the source or destination IP address and the destination port, ignoring whether the traffic is a new request or a reply to a request. In the above example, two rules would need to be implemented on the filtering device: one rule to allow traffic inbound to the web server on TCP port 80, and another rule to allow outbound traffic from the webserver (TCP port range 49, 152 through 65, 535).

Answer 29

Yes. If an Internet gateway has been configured, Amazon VPC traffic bound for Amazon EC2 instances not within a VPC traverses the Internet gateway and then enters the public AWS network to reach the EC2 instance. If an Internet gateway has not been configured, or if the instance is in a subnet configured to route through the virtual private gateway, the traffic traverses the VPN connection, egresses from your datacenter, and then re-enters the public AWS network.

Answer 30

Yes. Instances in one region can communicate with each other using Inter-Region VPC Peering, public IP addresses, NAT gateway, NAT instances, VPN Connections or Direct Connect connections.

Answer 31

Yes. There are multiple options for your resources within a VPC to communicate with Amazon S3. You can use VPC Endpoint for S3, which makes sure all traffic remains within Amazon's network and enables you to apply additional access policies to your Amazon S3 traffic. You can use an Internet gateway to enable Internet access from your VPC and instances in the VPC can communicate with Amazon S3. You can also make all traffic to Amazon S3 traverse the Direct Connect or VPN connection, egress from your datacenter, and then re-enter the public AWS network.

Answer 32

Ping (ICMP Echo Request and Echo Reply) requests to the router in your VPC is not supported. Ping between Amazon EC2 instances within VPC is supported as long as your operating system's firewalls, VPC security groups, and network ACLs permit such traffic.

Answer 33

Yes. You can use the Amazon VPC Flow Logs feature to monitor the network traffic in your VPC.

Answer 34

Amazon VPC is currently available in multiple Availability Zones in all Amazon EC2 regions.

Answer 35

No. A subnet must reside within a single Availability Zone.

Answer 36

When you launch an Amazon EC2 instance, you must specify the subnet in which to launch the instance. The instance will be launched in the Availability Zone associated with the specified subnet.

Answer 37

When you create a subnet you must specify the Availability Zone in which to place the subnet. When using the VPC Wizard, you can select the subnet's Availability Zone in the wizard confirmation screen. When using the API or the CLI you can specify the Availability Zone for the subnet as you create the subnet. If you don’t specify an Availability Zone, the default "No Preference" option will be selected and the subnet will be created in an available Availability Zone in the region.

Answer 38

If the instances reside in subnets in different Availability Zones, you will be charged $0.01 per GB for data transfer.

Answer 39

Yes. DescribeInstances() will return all running Amazon EC2 instances. You can differentiate EC2-Classic instances from EC2-VPC instances by an entry in the subnet field. If there is a subnet ID listed, the instance is within a VPC.

Answer 40

Yes. DescribeVolumes() will return all your EBS volumes.

Answer 41

You can run any number of Amazon EC2 instances within a VPC, so long as your VPC is appropriately sized to have an IP address assigned to each instance. You are initially limited to launching 20 Amazon EC2 instances at any one time and a maximum VPC size of /16 (65,536 IPs). If you would like to increase these limits, please complete the following form.

Answer 42

You can use AMIs in Amazon VPC that are registered within the same region as your VPC. For example, you can use AMIs registered in us-east-1 with a VPC in us-east-1. More information is available in the Amazon EC2 Region and Availability Zone FAQ.

Answer 43

Yes, you may use Amazon EBS snapshots if they are located in the same region as your VPC. More details are available in the Amazon EC2 Region and Availability Zone FAQ.

Answer 44

Yes, however, an instance launched in a VPC using an Amazon EBS-backed AMI maintains the same IP address when stopped and restarted. This is in contrast to similar instances launched outside a VPC, which get a new IP address. The IP addresses for any stopped instances in a subnet are considered unavailable.

Answer 45

Yes. You can reserve an instance in Amazon VPC when you purchase Reserved Instances. When computing your bill, AWS does not distinguish whether your instance runs in Amazon VPC or standard Amazon EC2. AWS automatically optimizes which instances are charged at the lower Reserved Instance rate to ensure you always pay the lowest amount. However, your instance reservation will be specific to Amazon VPC. Please see the Reserved Instances page for further details.

Answer 46

Yes. Cluster instances are supported in Amazon VPC, however, not all instance types are available in all regions and Availability Zones.

Answer 47

A default VPC is a logically isolated virtual network in the AWS cloud that is automatically created for your AWS account the first time you provision Amazon EC2 resources. When you launch an instance without specifying a subnet-ID, your instance will be launched in your default VPC.

Answer 48

When you launch resources in a default VPC, you can benefit from the advanced networking functionalities of Amazon VPC (EC2-VPC) with the ease of use of Amazon EC2 (EC2-Classic). You can enjoy features such as changing security group membership on the fly, security group egress filtering, multiple IP addresses, and multiple network interfaces without having to explicitly create a VPC and launch instances in the VPC.

Answer 49

If your AWS account was created after March 18, 2013 your account may be able to launch resources in a default VPC. See this Forum Announcement to determine which regions have been enabled for the default VPC feature set. Also, accounts created prior to the listed dates may utilize default VPCs in any default VPC enabled region in which you’ve not previously launched EC2 instances or provisioned Amazon Elastic Load Balancing, Amazon RDS, Amazon ElastiCache, or Amazon Redshift resources.

Answer 50

The Amazon EC2 console indicates which platforms you can launch instances in for the selected region, and whether you have a default VPC in that region. Verify that the region you'll use is selected in the navigation bar. On the Amazon EC2 console dashboard, look for "Supported Platforms" under "Account Attributes". If there are two values, EC2-Classic and EC2-VPC, you can launch instances into either platform. If there is one value, EC2-VPC, you can launch instances only into EC2-VPC. Your default VPC ID will be listed under "Account Attributes" if your account is configured to use a default VPC. You can also use the EC2 DescribeAccountAttributes API or CLI to describe your supported platforms.

Answer 51

No. You can use the AWS Management Console, AWS EC2 CLI, or the Amazon EC2 API to launch and manage EC2 instances and other AWS resources in a default VPC. AWS will automatically create a default VPC for you and will create a default subnet in each Availability Zone in the AWS region. Your default VPC will be connected to an Internet gateway and your instances will automatically receive public IP addresses, just like EC2-Classic.

Answer 52

See Differences between EC2-Classic and EC2-VPC in the EC2 User Guide.

Answer 53

No. Default VPCs are attached to the Internet and all instances launched in default subnets in the default VPC automatically receive public IP addresses. You can add a VPN connection to your default VPC if you choose.

Answer 54

Yes. To launch an instance into nondefault VPCs you must specify a subnet-ID during instance launch.

Answer 55

Yes. To launch into nondefault subnets, you can target your launches using the console or the --subnet option from the CLI, API, or SDK.

Answer 56

You can have one default VPC in each AWS region where your Supported Platforms attribute is set to "EC2-VPC".

Answer 57

The default VPC CIDR is 172.31.0.0/16. Default subnets use /20 CIDRs within the default VPC CIDR.

Answer 58

One default subnet is created for each Availability Zone in your default VPC.

Answer 59

Not at this time.

Answer 60

Not at this time.

Answer 61

Yes, you can delete a default VPC. Once deleted, you can create a new default VPC directly from the VPC Console or by using the CLI. This will create a new default VPC in the region. This does not restore the previous VPC that was deleted.

Answer 62

Yes, you can delete a default subnet. Once deleted, you can create a new default subnet in the availability zone by using the CLI or SDK. This will create a new default subnet in the availability zone specified. This does not restore the previous subnet that was deleted.

Answer 63

The simplest way to get a default VPC is to create a new account in a region that is enabled for default VPCs, or use an existing account in a region you've never been to before, as long as the Supported Platforms attribute for that account in that region is set to "EC2-VPC".

Answer 64

Yes, however, we can only enable an existing account for a default VPC if you have no EC2-Classic resources for that account in that region. Additionally, you must terminate all non-VPC provisioned Elastic Load Balancers, Amazon RDS, Amazon ElastiCache, and Amazon Redshift resources in that region. After your account has been configured for a default VPC, all future resource launches, including instances launched via Auto Scaling, will be placed in your default VPC. To request your existing account be setup with a default VPC, contact AWS Support. We will review your request and your existing AWS services and EC2-Classic presence to determine if you are eligible for a default VPC.

Answer 65

If your AWS account has a default VPC, any IAM accounts associated with your AWS account use the same default VPC as your AWS account.

Answer 66

The total number of network interfaces that can be attached to an EC2 instance depends on the instance type. See the EC2 User Guide for more information on the number of allowed network interfaces per instance type.

Answer 67

Network interfaces can only be attached to instances residing in the same Availability Zone.

Answer 68

Network interfaces can only be attached to instances in the same VPC as the interface.

Answer 69

Yes, however, this is not a use case best suited for multiple interfaces. Instead, assign additional private IP addresses to the instance and then associate EIPs to the private IPs as needed.

Answer 70

No. You can attach and detach secondary interfaces (eth1-ethn) on an EC2 instance, but you can’t detach the eth0 interface.

Answer 71

Yes. Peering connections can be created with VPCs in different regions. Inter-Region VPC Peering is currently supported in AWS US East (Virginia), US East (Ohio), US West (Oregon) and EU (Ireland) regions.

Answer 72

Yes, assuming the owner of the other VPC accepts your peering connection request.

Answer 73

No. Peered VPCs must have non-overlapping IP ranges.

Answer 74

There is no charge for creating VPC peering connections, however, data transfer across peering connections is charged. See the Data Transfer section of the EC2 Pricing page for data transfer rates.

Answer 75

No. "Edge to Edge routing" isn’t supported in Amazon VPC. Refer to the VPC Peering Guide for additional information.

Answer 76

No. VPC peering connections do not require an Internet Gateway.

Answer 77

No. Traffic between instances in peered VPCs remains private and isolated – similar to how traffic between two instances in the same VPC is private and isolated.

Answer 78

No. Either side of the peering connection can terminate the peering connection at any time. Terminating a peering connection means traffic won’t flow between the two VPCs.

Answer 79

No. Transitive peering relationships are not supported.

Answer 80

AWS uses the existing infrastructure of a VPC to create a VPC peering connection; it is neither a gateway nor a VPN connection, and does not rely on a separate piece of physical hardware. There is no single point of failure for communication or a bandwidth bottleneck. Inter-Region VPC Peering operates on the same horizontally scaled, redundant, and highly available technology that powers VPC today. Inter-Region VPC Peering traffic goes over the AWS backbone that has in-built redundancy and dynamic bandwidth allocation. There is no single point of failure for communication. If an Inter-Region peering connection does go down, the traffic will not be routed over the internet.

Answer 81

Bandwidth between instances in peered VPCs is no different than bandwidth between instances in the same VPC. Note: A placement group can span peered VPCs; however, you will not get full-bisection bandwidth between instances in peered VPCs. Read more about Placement Groups.

Answer 82

Traffic is encrypted using modern AEAD (Authenticated Encryption with Associated Data) algorithms. Key agreement and key management is handled by AWS.

Answer 83

By default, a query for a public hostname of an instance in a peered VPC in a different region will resolve to a public IP address. Route 53 private DNS can be used to resolve to a private IP address with Inter-Region VPC Peering.

Answer 84

No. Security groups cannot be referenced across an Inter-Region VPC Peering connection.

Answer 85

No. Inter-Region VPC Peering does not support IPv6.

Answer 86

No. Inter-Region VPC Peering cannot be used with EC2-ClassicLink.

Answer 87

Network Load Balancers, AWS PrivateLink and Elastic File System cannot be used over Inter-Region VPC Peering.

Answer 88

Amazon Virtual Private Cloud (VPC) ClassicLink allows EC2 instances in the EC2-Classic platform to communicate with instances in a VPC using private IP addresses. To use ClassicLink, enable it for a VPC in your account, and associate a Security Group from that VPC with an instance in EC2-Classic. All the rules of your VPC Security Group will apply to communications between instances in EC2-Classic and instances in the VPC.

Answer 89

There is no additional charge for using ClassicLink; however, existing cross Availability Zone data transfer charges will apply. For more information, consult the EC2 pricing page.

Answer 90

In order to use ClassicLink, you first need to enable at least one VPC in your account for ClassicLink. Then you associate a Security Group from the VPC with the desired EC2-Classic instance. The EC2-Classic instance is now linked to the VPC and is a member of the selected Security Group in the VPC. Your EC2-Classic instance cannot be linked to more than one VPC at the same time.

Answer 91

The EC2-Classic instance does not become a member of the VPC. It becomes a member of the VPC Security Group that was associated with the instance. All the rules and references to the VPC Security Group apply to communication between instances in EC2-Classic instance and resources within the VPC.

Answer 92

No. The EC2 public DNS hostname will not resolve to the private IP address of the EC2-VPC instance when queried from an EC2-Classic instance, and vice-versa.

Answer 93

Yes. ClassicLink cannot be enabled for a VPC that has a Classless Inter-Domain Routing (CIDR) that is within the 10.0.0.0/8 range, with the exception of 10.0.0.0/16 and 10.1.0.0/16. In addition, ClassicLink cannot be enabled for any VPC that has a route table entry pointing to the 10.0.0.0/8 CIDR space to a target other than "local".

Answer 94

Traffic from an EC2-Classic instance can only be routed to private IP addresses within the VPC. They will not be routed to any destinations outside the VPC, including Internet gateway, virtual private gateway, or peered VPC destinations.

Answer 95

ClassicLink does not change the access control defined for an EC2-Classic instance through its existing Security Groups from the EC2-Classic platform.

Answer 96

The ClassicLink connection will not persist through stop/start cycles of the EC2-Classic instance. The EC2-Classic instance will need to be linked back to a VPC after it is stopped and started. However, the ClassicLink connection will persist through instance reboot cycles.

Answer 97

There is no new private IP address assigned to the EC2-Classic instance. When you enable ClassicLink on an EC2-Classic instance, the instance retains and uses its existing private IP address to communication with resources in a VPC.

Answer 98

ClassicLink does not allow EC2-Classic Security Group rules to reference VPC Security Groups, or vice versa.

Answer 99

For any new VGWs, configurable Private Autonomous System Number(ASN) allows customers to set the ASN on the Amazon side of the BGP session for VPNs and AWS Direct Connect private VIFs .

Answer 100

There is no additional charge for this feature.

Answer 101

You can configure/assign an ASN to be advertised as the Amazon side ASN during creation of the new Virtual Private Gateway (VGW). You can create a VGW using the VPC console or a EC2/CreateVpnGateway API call.

Answer 102

Amazon assigned the following ASNs: EU West (Dublin) 9059; Asia Pacific (Singapore) 17493 and Asia Pacific (Tokyo) 10124. All other regions were assigned an ASN of 7224; these ASNs are referred as "legacy public ASN" of the region.

Answer 103

You can assign any private ASN to the Amazon side. You can assign the "legacy public ASN" of the region until June 30th 2018, you cannot assign any other public ASN. After June 30th 2018, Amazon will provide an ASN of 64512.

Answer 104

Amazon is not validating ownership of the ASNs, therefore, we’re limiting the Amazon-side ASN to private ASNs. We want to protect customers from BGP spoofing.

Answer 105

You can choose any private ASN. Ranges for 16-bit private ASNs include 64512 to 65534. You can also provide 32-bit ASNs between 4200000000 and 4294967294. Amazon will provide a default ASN for the VGW if you don’t choose one. Until June 30th 2018, Amazon will continue to provide the "legacy public ASN" of the region. After June 30th 2018, Amazon will provide an ASN of 64512.

Answer 106

We will ask you to re-enter a private ASN once you attempt to create the VGW, unless it is the "legacy public ASN" of the region.

Answer 107

Amazon will provide an ASN for the VGW if you don’t choose one. Until June 30th 2018, Amazon will continue to provide the "legacy public ASN" of the region. After June 30th 2018, Amazon will provide an ASN of 64512.

Answer 108

You can view the Amazon side ASN in the VGW page of VPC console and in the response of EC2/DescribeVpnGateways API.

Answer 109

Yes, you can configure the Amazon side of the BGP session with a private ASN and your side with a public ASN.

Answer 110

You will need to create a new VGW with desired ASN, and create a new VIF with the newly created VGW. Your device configuration also needs to change appropriately.

Answer 111

You will need to create a new VGW with the desired ASN, and recreate your VPN connections between your Customer Gateways and the newly created VGW.

Answer 112

Amazon will assign 64512 to the Amazon side ASN for the new VGW.

Answer 113

You can configure/assign an ASN to be advertised as the Amazon side ASN during creation of the new Virtual Private Gateway (VGW). You can create VGW using console or EC2/CreateVpnGateway API call. As noted earlier, we will allow the use of the "legacy public ASN" for your newly created VGW.

Answer 114

Amazon will assign 7224 to the Amazon side ASN for the new VIF/VPN connection. The Amazon side ASN for your new private VIF/VPN connection is inherited from your existing VGW and defaults to that ASN.

Answer 115

No, you can assign/configure separate Amazon side ASN for each VGW, not each VIF. Amazon side ASN for VIF is inherited from the Amazon side ASN of the attached VGW.

Answer 116

No, you can assign/configure separate Amazon side ASN for each VGW, not each VPN connection. Amazon side ASN for VPN connection is inherited from the Amazon side ASN of the VGW.

Answer 117

When creating a VGW in the VPC console, uncheck the box asking if you want an auto-generated Amazon BGP ASN and provide your own private ASN for the Amazon half of the BGP session. Once VGW is configured with Amazon side ASN, the private VIFs or VPN connections created using the VGW will use your Amazon side ASN.

Answer 118

You will not have to make any changes.

Answer 119

We will support 32-bit ASNs from 4200000000 to 4294967294.

Answer 120

No, you cannot modify the Amazon side ASN after creation. You can delete the VGW and recreate a new VGW with the desired ASN.

Answer 121

No. You can do this with the same API as before (EC2/CreateVpnGateway). We just added a new parameter (amazonSideAsn) to this API.

Answer 122

No. You can view the Amazon side ASN with the same EC2/DescribeVpnGateways API. We just added a new parameter (amazonSideAsn) to this API.

Answer 123

AWS PrivateLink enables customers to access services hosted on AWS in a highly available and scalable manner, while keeping all the network traffic within the AWS network. Service users can use this to privately access services powered by PrivateLink from their Amazon Virtual Private Cloud (VPC) or their on-premises, without using public IPs, and without requiring the traffic to traverse across the Internet. Service owners can register their Network Load Balancers to PrivateLink services and provide the services to other AWS customers.

Answer 124

As a service user, you will need to create interface type VPC endpoints for services that are powered by PrivateLink. These service endpoints will appear as Elastic Network Interfaces (ENIs) with private IPs in your VPCs. Once these endpoints are created, any traffic destined to these IPs will get privately routed to the corresponding AWS services. As a service owner, you can onboard your service to AWS PrivateLink by establishing a Network Load Balancer (NLB) to front your service and create a PrivateLink service to register with the NLB. Your customers will be able to establish endpoints within their VPC to connect to your service after you whitelisted their accounts and IAM roles.

Answer 125

The following AWS services support this feature: Amazon Elastic Compute Cloud (EC2), Elastic Load Balancing (ELB), Kinesis Streams, Service Catalog and EC2 Systems Manager. Many SaaS solutions support this feature as well. Please visit AWS Marketplace for more SaaS products powered by AWS PrivateLink.

Answer 126

Yes. The application in your on-premises can connect to the service endpoints in Amazon VPC over AWS Direct Connect. The service endpoints will automatically direct the traffic to AWS services powered by AWS PrivateLink.

Answer 127

Yes. You can use the AWS Management Console to manage Amazon VPC objects such as VPCs, subnets, route tables, Internet gateways, and IPSec VPN connections. Additionally, you can use a simple wizard to create a VPC.

Answer 128

You can have: Five Amazon VPCs per AWS account per region Two hundred subnets per Amazon VPC Five Amazon VPC Elastic IP addresses per AWS account per region One Internet gateway per VPC Five virtual private gateways per AWS account per region Fifty customer gateways per AWS account per region Ten IPsec VPN Connections per virtual private gateway See the VPC User Guide for more information on VPC limits.

Answer 129

Not currently.

Answer 130

Yes. Click here for more information on AWS Support.

Networking & Content Delivery | Amazon Virtual Private Cloud (VPC) Flashcards

(161 cards)