March 2025: Inter-region VPC peering now supports jumbo frames (up to 8500 bytes MTU) and full instance bandwidth.
April 2025: VPC Peering billing simplified with dedicated usage type for better cost visibility.
November 2025: VPC Encryption Controls launched to audit and enforce encryption on VPC peering traffic.
A VPC peering connection is a networking connection between two VPCs that enables routing of traffic between them using private IPv4 addresses or IPv6 addresses.
VPC peering connection
can be established between your own VPCs, or with a VPC in another AWS account in the same or different region.
is a one-to-one relationship between two VPCs.
supports intra and inter-region peering connections.
With VPC peering,
Instances in either VPC can communicate with each other as if they are within the same network
AWS uses the existing infrastructure of a VPC to create a 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
All inter-region traffic is encrypted with no single point of failure, or bandwidth bottleneck. Traffic always stays on the global AWS backbone, and never traverses the public internet, which reduces threats, such as common exploits, and DDoS attacks.
EC2 instances can use full instance bandwidth for inter-region VPC peering traffic (previously limited to 50% for instances with 32+ vCPUs, or 5 Gbps for smaller instances).
VPC peering pricing
There is no charge to create a VPC peering connection.
All data transfer over a VPC peering connection that stays within an Availability Zone (AZ) is free, even if it’s between different accounts.
Charges apply for data transfer over VPC peering connections that cross Availability Zones and Regions.
Since April 2025, VPC Peering billing uses a dedicated usage type (Region-Name-VpcPeering-In/Out-Bytes) for easier cost tracking in Cost Explorer and Cost and Usage Reports.
VPC Peering Connectivity
To create a VPC peering connection, the owner of the requester VPC sends a request to the owner of the accepted VPC.
Accepter VPC can be owned by the same account or a different AWS account.
Once the Accepter VPC accepts the peering connection request, the peering connection is activated.
Route tables on both the VPCs should be manually updated to allow traffic
Security groups on the instances should allow traffic to and from the peered VPCs.
VPC Peering Limitations & Rules
Does not support Overlapping or matching IPv4 or IPv6 CIDR blocks.
Does not support transitive peering relationships i.e. the VPC does not have access to any other VPCs that the peer VPC may be peered with even if established entirely within your own AWS account
Does not support Edge to Edge Routing Through a Gateway or Private Connection
In a VPC peering connection, the VPC does not have access to any other connection that the peer VPC may have and vice versa. Connections that the peer VPC can include
Only one peering connection can be established between the same two VPCs at the same time.
Jumbo frames (MTU up to 8500 bytes) are supported for peering connections both within the same region and across regions.
A placement group can span peered VPCs that are in the same region; however, you do not get full-bisection bandwidth between instances in peered VPCs
Inter-region VPC peering connections
Updated March 2025: The Maximum Transmission Unit (MTU) across an inter-region peering connection is now 8500 bytes (jumbo frames supported). Previously limited to 1500 bytes.
Security group rule that references a peer VPC security group cannot be created for cross-region peering.
EC2 instances can use full instance bandwidth for inter-region peering (no longer limited to 50% or 5 Gbps).
Any tags created for the peering connection are only applied in the account or region in which they were created
Unicast reverse path forwarding in peering connections is not supported
Instance’s Public DNS can be resolved to its private IP address across peered VPCs when DNS resolution is enabled for the VPC peering connection.
⚠️ DEPRECATED FEATURE
EC2-Classic and ClassicLink were retired on August 15, 2023.
The original content mentioned ClassicLink connections to EC2-Classic instances. This feature is no longer available.
Migration: All resources must be migrated to VPC. EC2-Classic is no longer supported.
VPC Peering Encryption
All inter-region VPC peering traffic is encrypted with AES-256 before leaving AWS data centers.
Intra-region traffic between Nitro-based EC2 instances is also encrypted transparently.
VPC Encryption Controls (November 2025):
Provides ability to monitor, audit, and enforce encryption in transit within and across VPCs.
Automatically applies hardware-based AES-256 encryption on traffic between VPC resources including Fargate, NLB, and ALB.
Helps demonstrate compliance with encryption standards (HIPAA, PCI DSS).
Can identify VPC resources unintentionally allowing plaintext traffic.
Generates audit logs for compliance and reporting.
VPC Peering Troubleshooting
Verify that the VPC peering connection is in the Active state.
Be sure to update the route tables for the peering connection. Verify that the correct routes exist for connections to the IP address range of the peered VPCs through the appropriate gateway.
Verify that an ALLOW rule exists in the network access control (NACL) table for the required traffic.
Verify that the security group rules allow network traffic between the peered VPCs.
Verify using VPC flow logs that the required traffic isn’t rejected at the source or destination. This rejection might occur due to the permissions associated with security groups or network ACLs.
Be sure that no firewall rules block network traffic between the peered VPCs. Use network utilities such as traceroute (Linux) or tracert (Windows) to check rules for firewalls such as iptables (Linux) or Windows Firewall (Windows).
For DNS resolution issues, ensure that DNS resolution is enabled for the VPC peering connection to resolve public DNS hostnames to private IP addresses.
VPC Peering Architecture
VPC Peering can be applied to create shared services or perform authentication with an on-premises instance
This would help create a single point of contact, as well limiting the VPN connections to a single account or VPC
VPC Peering vs Transit Gateway vs PrivateLink vs VPC Lattice
When to Use Each Solution
VPC Peering
Best for: Simple, direct connections between a small number of VPCs (typically less than 10)
Advantages: No additional cost for the connection itself, low latency, simple setup, full instance bandwidth inter-region
Limitations: Does not support transitive routing, becomes complex at scale (mesh topology), limited to 125 peering connections per VPC
Best for: Service-to-service connectivity, exposing services to multiple consumers, SaaS applications
Advantages: Unidirectional access, no VPC CIDR overlap issues, enhanced security, supports cross-account and cross-region access
Limitations: Requires Network Load Balancer or Gateway Load Balancer, additional cost, one-way communication by default
Amazon VPC Lattice
Best for: Application-layer service-to-service networking across VPCs and accounts
Advantages: No NLB required (unlike PrivateLink), built-in service discovery, IAM-based authorization, cross-VPC/cross-account without CIDR coordination, TLS termination at data plane
Limitations: Application-layer (L7) only, newer service with evolving feature set
Note: AWS App Mesh is being discontinued (EOL September 30, 2026); VPC Lattice is the recommended migration path
AWS Certification Exam Practice Questions
Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
AWS services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
AWS exam questions are not updated to keep up the pace with AWS updates, so even if the underlying feature has changed the question might not be updated
Open to further feedback, discussion and correction.
You currently have 2 development environments hosted in 2 different VPCs in an AWS account in the same region. There is now a need for resources from one VPC to access another. How can this be accomplished?
Establish a Direct Connect connection.
Establish a VPN connection.
Establish VPC Peering.
Establish Subnet Peering.
A company has an AWS account that contains three VPCs (Dev, Test, and Prod) in the same region. Test is peered to both Prod and Dev. All VPCs have non-overlapping CIDR blocks. The company wants to push minor code releases from Dev to Prod to speed up the time to market. Which of the following options helps the company accomplish this?
Create a new peering connection Between Prod and Dev along with appropriate routes.
Create a new entry to Prod in the Dev route table using the peering connection as the target.
Attach a second gateway to Dev. Add a new entry in the Prod route table identifying the gateway as the target.
The VPCs have non-overlapping CIDR blocks in the same account. The route tables contain local routes for all VPCs.
A company has 2 AWS accounts that have individual VPCs. The VPCs are in different AWS regions and need to communicate with each other. The VPCs have non-overlapping CIDR blocks. Which of the following would be a cost-effective connectivity option?
Use VPN connections
Use VPC peering between the 2 VPC’s
Use AWS Direct Connect
Use a NAT gateway
A company needs to connect 15 VPCs across multiple AWS accounts and regions with centralized routing and management. Which solution is most appropriate?
Create VPC peering connections between all VPCs
Use AWS Transit Gateway with a hub-and-spoke architecture
Use AWS PrivateLink for all connections
Use multiple VPN connections
A SaaS provider wants to expose their application running in their VPC to multiple customer VPCs without requiring VPC peering or overlapping CIDR concerns. Which solution should they use?
VPC Peering with each customer VPC
AWS Transit Gateway
AWS PrivateLink with VPC endpoint service
Internet Gateway with security groups
A company needs to transfer large amounts of data between VPCs in different AWS regions with maximum throughput. Which statement about inter-region VPC peering is correct? (Updated 2025)
Inter-region VPC peering is limited to 1500 bytes MTU and 5 Gbps bandwidth
Inter-region VPC peering does not support encryption
Inter-region VPC peering supports jumbo frames (8500 bytes MTU) and full EC2 instance bandwidth
Inter-region VPC peering requires a Transit Gateway attachment
A company wants to audit and enforce encryption on all traffic flowing through their VPC peering connections to meet PCI DSS compliance. Which AWS feature should they use?
Virtual Private Cloud – VPC provides networking functionality for the cloud-based resources and services that is global, scalable, and flexible.
VPC Networks
VPC network is a virtual version of a physical network
A VPC network is a global resource that consists of a list of regional virtual subnets in data centers, all connected by a global wide area network.
VPC networks are logically isolated from each other in Google Cloud.
VPC networks
provides connectivity for the VMs and products built on it like GKE
offers built-in Internal TCP/UDP Load Balancing and proxy systems for Internal HTTP(S) Load Balancing.
connects to on-premises networks using Cloud VPN tunnels and Cloud Interconnect attachments.
distributes traffic from GCP external load balancers to backends
Specifications
VPC networks are global resources, including the associated routes and firewall rules, and are not associated with any particular region or zone.
Subnets are regional resources and each subnet defines a range of IP addresses
Network firewall rules control the Traffic to and from instances. Rules are implemented on the VMs themselves, so traffic can only be controlled and logged as it leaves or arrives at a VM.
Resources within a VPC network can communicate with one another by using internal IPv4 addresses, subject to applicable network firewall rules.
Private access options for services allow instances with internal IP addresses can communicate with Google APIs and services.
Network administration can be secured by using IAM roles.
An organization can use Shared VPC to keep a VPC network in a common host project. Authorized IAM members from other projects in the same organization can create resources that use Shared VPC network subnets.
VPC Network Peering allows VPC networks to be connected with other VPC networks in different projects or organizations.
VPC networks can be securely connected in hybrid environments by using Cloud VPN or Cloud Interconnect.
VPC networks only support IPv4 unicast traffic. They do not support broadcast, multicast, or IPv6 traffic within the network; VMs in the VPC network can only send to IPv4 destinations and only receive traffic from IPv4 sources.
VPC Subnets
VPC networks do not have any IP address ranges associated with them.
Each VPC network consists of one or more useful IP range partitions called subnets and IP ranges are defined for the subnets.
Subnets are regional resources and each subnet is associated with a region.
A network must have at least one subnet before it can be used.
More than one subnet per region can be created
VPC Network supports the following subnet creation mode
Auto mode VPC networks
create subnets in each region automatically
adds new subnets automatically, if a new region becomes available
can be switched to custom mode VPC networks
Custom mode VPC networks
start with no subnets, giving full control over subnet creation.
are more flexible and are better suited for production
cannot be switched to auto mode VPC networks
Subnet must have a defined primary IP address range, and any resources created within are assigned an IP address from the defined range.
Subnets can be assigned a secondary IP address range, which is only used by alias IP ranges. This is useful if you have multiple services running on a VM and want to assign each service a different IP address.
Primary IP range of an existing subnet can be expanded by modifying its subnet mask, setting the prefix length to a smaller number.
VPC Routes
Routes define paths for packets leaving instances (egress traffic), either inside the network or outside of Google Cloud
A route consists of
a single destination prefix in CIDR format (0.0.0.0/0) and
a single next hop (for e.g Internet Gateway)
When an instance in a VPC network sends a packet, GCP delivers the packet to the route’s next hop if the packet’s destination address is within the route’s destination range.
Routes are defined at the VPC network level but implemented at each VM instance level.
Each VM instance has a controller that is kept informed of all applicable routes from the network’s routing table. Each packet leaving a VM is delivered to the appropriate next hop of an applicable route based on a routing order. When a route is added or deleted, the set of changes is propagated to the VM controllers by using an eventually consistent design.
Routes are divided into two categories: system-generated and custom.
system-generated routes
default – send traffic from eligible instances to the internet and can be removed or replaced
subnet routes – route traffic among its subnets and updated automatically by Google Cloud
are applied at the VPC level to all the instances
custom routes
are either static routes created manually or dynamic routes maintained automatically by one or more of the Cloud Routers
can be applied to all the instances or specific instance using network tag
Google Cloud provides several private access options which allow VM instances with internal IP addresses to reach certain APIs and services
Private Google Access
allows VMs to connect to the set of external IP addresses used by Google APIs and services by enabling Private Google Access on the subnet used by the VM’s network interface.
allows access to the external IP addresses used by App Engine, including third-party App Engine-based services.
configured on a subnet by subnet basis
provides following routing options
use default route with its next-hop being the default internet gateway, and it provides a path to the default domains, private.googleapis.com, and restricted.googleapis.com.
use custom static routes, each having a more specific destination, and each using the default internet gateway next hop.
Use this option to connect to Google APIs and services without giving the Google Cloud resources external IP addresses.
Private services access
is a private connection between the VPC network and a network owned by Google or a third party i.e. service producers
enables VM instances in the VPC network and the accessed services to communicate exclusively by using internal IP addresses.
VM instances don’t need Internet access or external IP addresses to reach services that are available through private services access.
Use this option to connect to specific Google and third-party services without assigning external IP addresses to the Google Cloud and Google or third-party resources.
VPC Flow Logs records a sample of network flows sent from and received by VM instances, including instances used as GKE nodes.
Flow Logs can be used for network monitoring, forensics, real-time security analysis, and expense optimization.
Flow logs are enabled on the VPC subnet level.
Flow logs only record TCP and UDP connections.
With GCP Shared VPC, all Flow logs are in the host project.
Cloud Logging can be used to view the flow logs and it can be exported to any destination that Cloud Logging export supports.
Flow logs are aggregated by the connection from Compute Engine VMs and exported in real-time.
Flow logs can be analyzed using real-time streaming APIs by subscribing to Pub/Sub.
Flow logs are collected for each VM connection at specific intervals (sampling period). All packets collected for a given interval for a given connection are aggregated for a period of time (aggregation interval) into a single flow log entry
GCP Certification Exam Practice Questions
Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
GCP services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
GCP exam questions are not updated to keep up the pace with GCP updates, so even if the underlying feature has changed the question might not be updated
Open to further feedback, discussion and correction.
Your VMs are running in a subnet that has a subnet mask of 255.255.255.240. The current subnet has no more free IP addresses and you require an additional 10 IP addresses for new VMs. The existing and new VMs should all be able to reach each other without additional routes. What should you do?
Use gcloud to expand the IP range of the current subnet.
Delete the subnet, and recreate it using a wider range of IP addresses.
Create a new project. Use Shared VPC to share the current network with the new project.
Create a new subnet with the same starting IP but a wider range to overwrite the current subnet
An IT company has a set of compute engine instances hosted in a VPC. They are not exposed to the internet. These instances now need to install an important security patch. How can the security patch be installed on the instances?
Upload to Cloud Storage and enable VPC peering
Upload to Cloud Storage and whitelist instance IP address
Upload to Cloud Storage and enable Private Google Access
Upload to Cloud Source Repository and enable VPC peering
Your security team wants to be able to audit network traffic inside of your network. What’s the best way to ensure they have access to the data they need?
Google Cloud VPC Network Peering allows internal IP address or private connectivity across two VPC networks regardless of whether they belong to the same project or the same organization.
VPC Network Peering enables VPC networks connection, so that workloads in different VPC networks can communicate internally.
VPC Network Peering provides internal IPv4 and IPv6 connectivity between pairs of VPC networks.
Traffic stays within Google’s network and doesn’t traverse public internet.
Peering supports connectivity between networks having any combination of IPv4-only, dual-stack, and IPv6-only subnets.
VPC Network Peering provides following advantages over using external IP addresses or VPNs to connect networks, including:
Network Latency – connectivity uses only internal addresses and provides lower latency than connectivity that uses external addresses
Network Security – service owners do not need to have their services exposed to the public Internet and deal with its associated risks.
Network Cost – Google Cloud charges egress bandwidth or outbound traffic for networks using external IPs to communicate even if the traffic is within the same zone. However, for peered networks as they use internal IPs to communicate and save on those egress costs.
VPC Network Peering is useful in these environments:
SaaS (Software-as-a-Service) ecosystems in Google Cloud, which can be made available privately across different VPC networks within and across organizations.
Organizations that have several network administrative domains that need to communicate using internal IP addresses.
VPC Peering Properties
VPC Network Peering works with Compute Engine, GKE, and App Engine flexible environment.
VPC Network Peering supports routes-based GKE clusters when configured to exchange static routes.
Peered VPC networks remain administratively separate. Routes, firewalls, VPNs, and other traffic management tools are administered and applied separately in each of the VPC networks.
Each side of a peering association is set up independently. Peering will be active only when the configuration from both sides matches. Either side can choose to delete the peering association at any time (in independent mode).
VPC peers always exchange subnet routes that don’t use privately used public IP addresses. Networks must explicitly export privately used public IP subnet routes for other networks to use them and must explicitly import privately used public IP subnet routes to receive them from other networks.
Subnet and static routes are global. Dynamic routes can be regional or global, depending on the VPC network’s dynamic routing mode.
A VPC network can peer with multiple VPC networks (default quota of 25 peerings per network).
IAM permissions for creating and deleting VPC Network Peering are included as part of the Compute Network Admin role (roles/compute.networkAdmin).
Peering traffic (traffic flowing between peered networks) has the same latency, throughput, and availability as private traffic in the same network.
Billing policy for peering traffic is the same as the billing policy for private traffic in the same network.
An organization policy administrator can use an organization policy to constrain which VPC networks can peer with VPC networks in the organization. Peering connections to particular VPC networks or to VPC networks in a particular folder or organization can be denied.
VPC Peering Connection Modes
VPC Network Peering supports two connection modes that determine how a peering connection is administered:
Independent Mode (default) – Either network can update or delete the peering connection at any time unilaterally.
Consensus Mode – Requires agreement from both networks to update or delete the peering connection. Prevents accidental, unilateral changes to network behavior.
When creating a peering connection, both peering configurations must specify the same connection mode.
An existing connection can be changed from independent to consensus mode (both sides must update), but changing from consensus to independent is NOT supported.
Consensus mode is recommended for critical services where accidental deletion of the peering connection would cause a service outage.
In consensus mode:
Update requests require complementary changes from both sides (e.g., if one side exports custom routes, the peer must import them).
Deletion requires both sides to submit a deletion request.
Pending update or deletion requests do not cause downtime—the connection remains active.
IPv6 Support in VPC Peering
VPC Network Peering provides internal IPv4 and IPv6 connectivity between pairs of VPC networks.
Peering supports connectivity between networks having any combination of IPv4-only, dual-stack, and IPv6-only subnets.
To exchange IPv6 routes (both internal and external IPv6 subnet ranges), the peering stack type must be set to IPV4_IPV6 using the --stack-type=IPV4_IPV6 flag.
IPv6 static and dynamic routes exchange also requires --stack-type=IPV4_IPV6 in addition to the --export-custom-routes / --import-custom-routes flags.
VPC Network Peering also provides certain external IPv6 connectivity to destination external IPv6 address ranges of dual-stack/IPv6-only VM instances, external protocol forwarding rules, and external passthrough Network Load Balancer forwarding rules.
IPv6 subnet routes are unique by definition — no two VPC networks can use the same internal or external IPv6 subnet ranges.
IPv6 functionality is available only in Premium Tier.
Route Exchange Options
When a VPC network shares local routes with a peered VPC network, it exports the routes. The peered VPC network can then import the routes.
Subnet routes (using private IPv4 ranges) are always exchanged and cannot be disabled.
Subnet routes using privately used public IPv4 addresses – exported by default, not imported by default. Controlled via --export-subnet-routes-with-public-ip and --import-subnet-routes-with-public-ip flags.
IPv6 subnet routes (internal and external) – not exchanged by default. Enabled by setting --stack-type=IPV4_IPV6.
Static and dynamic IPv4 routes – not exchanged by default. Controlled via --export-custom-routes and --import-custom-routes flags.
IPv6 static/dynamic routes – require both --export-custom-routes / --import-custom-routes AND --stack-type=IPV4_IPV6.
Static routes with network tags or using the default internet gateway as next hop can NEVER be exported or imported.
Policy-based routes are NOT supported for exchange via VPC Network Peering.
Route exchange options can be updated before peering is established or while peering is active.
VPC Peering Restrictions
A subnet CIDR range in one peered VPC network cannot overlap with a static route in another peered network. This rule covers both subnet routes and static routes.
A dynamic route can overlap with a subnet route in a peer network. For dynamic routes, the destination ranges that overlap with a subnet route from the peer network are silently dropped. Google Cloud uses the subnet route.
Only VPC networks are supported for VPC Network Peering. Peering is NOT supported for legacy networks.
Two auto mode VPC networks cannot be peered because each auto mode VPC uses subnet IP ranges that fit within 10.128.0.0/9. A custom mode VPC can be peered with an auto mode VPC as long as the custom mode VPC doesn’t have subnets within 10.128.0.0/9.
Subnet route exchange can’t be disabled or subnet routes that can be exchanged cannot be selected. After peering is established, all resources within subnet IP addresses are accessible across directly peered networks.
VPC Network Peering doesn’t provide granular route controls to filter out which subnet CIDR ranges are reachable across peered networks. It needs to be done using firewall rules.
Transitive peering is NOT supported. For transitive connectivity, use Network Connectivity Center with VPC spokes.
Network tags or service accounts from one peered network in the other peered network CANNOT be used in VPC firewall rules.
However, secure Tags (different from network tags) used in network firewall policies CAN identify sources in peered VPC networks connected to the VPC network to which the Tag is scoped.
Compute Engine internal DNS names created in a network are NOT accessible to peered networks. Use Cloud DNS peering zones or authorize the managed private zone to all peered VPC networks instead.
By default, VPC Network Peering with GKE is supported when used with IP aliases (VPC-native clusters). If you don’t use IP aliases (routes-based clusters), custom routes can be exported so that GKE containers are reachable from peered networks.
Peering Group and Quotas
VPC peering quotas depend on a concept called a peering group.
Each VPC network has its own peering group consisting of itself and all other VPC networks connected to it using VPC Network Peering.
Quotas such as internal forwarding rules, subnet ranges, and instances are evaluated across the entire peering group, not per individual network.
Default quota for VPC peerings within a single VPC is 25 (can be increased via quota request).
Google Cloud allows only one peering operation at a time across peered networks.
Network Connectivity Center (NCC) vs VPC Peering
Network Connectivity Center (NCC) is an alternative to VPC Network Peering for connecting multiple VPC networks, providing a hub-and-spoke model.
Transitivity: NCC provides full bandwidth and transitivity between workload VPCs (VPC spokes). VPC Peering does NOT provide transitivity.
Scale: NCC supports up to 250 VPC spokes per hub. VPC Peering is limited to 25 peerings per VPC by default.
When to use VPC Peering: Simple point-to-point connectivity between two VPCs without transitive requirements.
When to use NCC: Hub-and-spoke topologies, transitive routing across multiple VPCs, enterprise-scale connectivity, or when centralizing network management.
A VPC that is a VPC spoke in NCC can still use VPC Network Peering, provided the peered VPC network isn’t a VPC spoke itself.
NCC VPC spokes support IPv4 and IPv6 subnet route connectivity and IPv4 dynamic route connectivity using hybrid spokes.
Internal Load Balancer Support
Clients in a local VPC network can access internal load balancers in a peer VPC network.
Supported internal load balancers:
Internal passthrough Network Load Balancers
Internal proxy Network Load Balancers
Internal Application Load Balancers
Peered networks can exchange static routes that use internal passthrough Network Load Balancers as next hops.
DNS Support in Peered Networks
Resources in a peered VPC network cannot use Compute Engine internal DNS names created by a local VPC network.
To make DNS names available to resources in a peered VPC network, use one of the following:
Cloud DNS peering zones – Recommended approach for cross-network DNS resolution.
Authorize the managed private zone to all peered VPC networks.
GCP Certification Exam Practice Questions
Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
GCP services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
GCP exam questions are not updated to keep up the pace with GCP updates, so even if the underlying feature has changed the question might not be updated
Open to further feedback, discussion and correction.
Your company is working with a partner to provide a solution for a customer. Both your company and the partner organization are using GCP. There are applications in the partner’s network that need access to some resources in your company’s VPC. There is no CIDR overlap between the VPCs. Which two solutions can you implement to achieve the desired results without compromising security?
VPC peering
Shared VPC
Dedicated Interconnect
Cloud NAT
Your organization is deploying a single project for 3 separate departments. Two of these departments require network connectivity between each other, but the third department should remain in isolation. Your design should create separate network administrative domains between these departments. You want to minimize operational overhead. How should you design the topology?
Create a Shared VPC Host Project and the respective Service Projects for each of the 3 separate departments.
Create 3 separate VPCs, and use Cloud VPN to establish connectivity between the two appropriate VPCs.
Create 3 separate VPCs, and use VPC peering to establish connectivity between the two appropriate VPCs.
Create a single project, and deploy specific firewall rules. Use network tags to isolate access between the departments.
Your organization has 15 VPC networks that all need to communicate with each other. You need full-mesh transitive connectivity with centralized management. What should you use?
VPC Network Peering between all 15 networks
Network Connectivity Center with VPC spokes
Cloud VPN tunnels between all networks
Shared VPC with service projects
You have two VPC networks peered together. A critical production service runs across the peering connection. You want to prevent accidental deletion of the peering connection by either network administrator. What should you configure?
IAM deny policies on the peering resource
Organization policy constraints
Consensus mode for the peering connection
Read-only access for both network administrators
You have peered two VPC networks and need to enable IPv6 communication between resources in both networks. What must you configure on the peering connection?
Enable the --export-custom-routes flag
Create IPv6 firewall rules only
Set the peering stack type to IPV4_IPV6
Enable Private Google Access for IPv6
You want to use network firewall policy rules to identify traffic sources from peered VPC networks. Which identifier can be used to match sources across peered networks?
is a horizontally scaled, redundant, and highly available component that allows communication between instances in your VPC and the internet.
imposes no availability risks or bandwidth constraints on your network traffic.
serves two purposes: to provide a target in the VPC route tables for internet-routable traffic and to perform NAT for instances that have not been assigned public IPv4 addresses.
enables instances in a private subnet to connect to the internet or other AWS services, but prevents the Internet from initiating connections with the instances.
Public NAT gateway allows instances in private subnets to connect to the internet through the NAT gateway’s Elastic IP address.
Private NAT gateway allows instances in private subnets to connect to other VPCs or the on-premises network using its private IP address for source NAT.
Regional NAT Gateway (New – Nov 2025) – automatically expands across Availability Zones based on workload presence. Unlike standard (zonal) NAT gateways which operate in a single AZ, regional NAT gateways follow workloads to provide automatic high availability without requiring a public subnet to host the gateway.
Egress Only Internet Gateway
NAT devices are not supported for IPv6 traffic, use an Egress-only Internet gateway instead
Egress-only Internet gateway is a horizontally scaled, redundant, and highly available VPC component
Egress-only Internet gateway allows outbound communication over IPv6 from instances in the VPC to the Internet and prevents the Internet from initiating an IPv6 connection with your instances.
VPC endpoint provides a private connection from VPC to supported AWS services and VPC endpoint services powered by PrivateLink without requiring an internet gateway, NAT device, VPN connection, or AWS Direct Connect connection.
Instances in the VPC do not require public IP addresses to communicate with resources in the service. Traffic between the VPC and the other service does not leave the Amazon network.
VPC Endpoints are virtual devices and are horizontally scaled, redundant, and highly available VPC components that allow communication between instances in the VPC and services without imposing availability risks or bandwidth constraints on the network traffic.
VPC Endpoints are of three types
Interface Endpoints – is an elastic network interface with a private IP address that serves as an entry point for traffic destined to supported services.
Gateway Endpoints – is a gateway that is a target for a specified route in your route table, used for traffic destined to a supported AWS service. Currently only Amazon S3 and DynamoDB.
Resource Endpoints (New – Dec 2024) – enables private access to a specific resource (e.g., RDS database, IP address, or domain name) in another VPC or on-premises environment shared via AWS RAM, without requiring an NLB.
Cross-Region PrivateLink (Nov 2025) – Interface VPC endpoints now support cross-region connectivity, breaking the previous limitation that endpoints were regional-only. This enables connecting to VPC endpoint services hosted in other AWS Regions within the same partition.
provides private connectivity between VPCs, AWS services, and your on-premises networks without exposing your traffic to the public internet.
helps privately expose a service/application residing in one VPC (service provider) to other VPCs (consumer) within an AWS Region in a way that only consumer VPCs initiate connections to the service provider VPC.
With ALB as a target of NLB, ALB’s advanced routing capabilities can be combined with AWS PrivateLink.
VPC Resource Gateway (Dec 2024) – allows sharing any VPC resource (RDS databases, domain names, IP addresses) via AWS RAM. Consumers access these resources privately using VPC endpoints without needing an NLB, simplifying hybrid networking.
Cross-Region Connectivity (Nov 2025) – PrivateLink now supports native cross-region access for both AWS services and customer endpoint services, enabling global private connectivity from a single Region deployment.
enables networking connection between two VPCs to route traffic between them using private IPv4 addresses or IPv6 addresses
connections can be created between your own VPCs, or with a VPC in another AWS account.
enables full bidirectional connectivity between the VPCs
supports inter-region VPC peering connection
Inter-region peering now supports jumbo frames (up to 8500 bytes MTU) and full instance bandwidth (Mar 2025)
uses existing underlying AWS infrastructure
does not have a single point of failure for communication or a bandwidth bottleneck.
VPC Peering connections have limitations
cannot be used with Overlapping CIDR blocks
does not provide Transitive peering
does not support Edge to Edge routing through Gateway or private connection
is best used when resources in one VPC must communicate with resources in another VPC, the environment of both VPCs is controlled and secured, and the number of VPCs to be connected is less than 10
supports a limit of 125 active peering connections per VPC
Simplified Billing (Apr 2025) – AWS simplified VPC Peering billing; no changes to data transfer pricing but billing structure is streamlined.
VPN CloudHub
AWS VPN CloudHub allows you to securely communicate from one site to another using AWS Managed VPN or Direct Connect
AWS VPN CloudHub operates on a simple hub-and-spoke model that can be used with or without a VPC
AWS VPN CloudHub can be used if you have multiple branch offices and existing internet connections and would like to implement a convenient, potentially low cost hub-and-spoke model for primary or backup connectivity between these remote offices.
AWS VPN CloudHub leverages VPC virtual private gateway with multiple gateways, each using unique BGP autonomous system numbers (ASNs).
⚠️ Note: Transit VPC is a legacy architecture pattern. AWS recommends using AWS Transit Gateway or AWS Cloud WAN for new deployments, which provide managed, highly available hub-and-spoke connectivity without the operational overhead of managing EC2-based virtual appliances.
A transit VPC is a common strategy for connecting multiple, geographically disperse VPCs and remote networks in order to create a global network transit center.
A transit VPC simplifies network management and minimizes the number of connections required to connect multiple VPCs and remote networks
Transit VPC can be used to support important use cases
Private Networking – You can build a private network that spans two or more AWS Regions.
Shared Connectivity – Multiple VPCs can share connections to data centers, partner networks, and other clouds.
Cross-Account AWS Usage – The VPCs and the AWS resources within them can reside in multiple AWS accounts.
Transit VPC design helps implement more complex routing rules, such as network address translation between overlapping network ranges, or to add additional network-level packet filtering or inspection.
Transit VPC
supports Transitive routing using the overlay VPN network — allowing for a simpler hub and spoke design.
supports network address translation between overlapping network ranges.
supports vendor functionality around advanced security (layer 7 firewall/IPS/IDS) using third-party software on EC2
leverages instance-based routing that increases costs while lowering availability and limiting the bandwidth.
Customers are responsible for managing the HA and redundancy of EC2 instances running the third-party vendor virtual appliance
is a highly available and scalable service to consolidate the AWS VPC routing configuration for a region with a hub-and-spoke architecture.
is a Regional resource and can connect thousands of VPCs within the same AWS Region.
TGWs across different regions can peer with each other to enable VPC communications within the same or different regions.
provides simpler VPC-to-VPC communication management over VPC Peering with a large number of VPCs.
enables you to attach VPCs (across accounts) and VPN connections in the same Region and route traffic between them.
support dynamic and static routing between attached VPCs and VPN connections
removes the need for using full mesh VPC Peering and Transit VPC
Transit Gateway Flow Logs – enables capturing detailed telemetry (source/destination IPs, ports, protocol, traffic counters, timestamps) for all network flows traversing the Transit Gateway. Logs can be published to CloudWatch Logs, S3, or Firehose.
Flexible Cost Allocation (Nov 2025) – provides granular control over how Transit Gateway data processing costs are allocated across AWS accounts within AWS Organizations.
AWS Cloud WAN
is a managed wide area networking (WAN) service that helps build, manage, and monitor a unified global network connecting cloud and on-premises resources.
provides a central dashboard and network policies to create a global network spanning multiple locations, removing the need to configure and manage different networks using different technologies.
uses a policy-based automation system to define network segments, attach VPCs, VPN connections, and SD-WAN products.
simplifies global network management compared to manually managing Transit Gateways across regions.
key features include:
Central Dashboard – manage branch offices, data centers, VPN connections, SD-WAN, VPCs, and Transit Gateways from one place.
Network Policies – define how traffic is routed between segments with policy-based controls.
Service Insertion (2024) – streamlines integrating security and inspection services (e.g., Network Firewall) into global networks.
Routing Policy (Nov 2025) – enables route filtering, summarization, and BGP path manipulation for fine-grained traffic control at scale.
Security Group Referencing & Enhanced DNS (Jun 2025) – simplifies security group management and DNS resolution across Cloud WAN segments.
can be used as a migration path from Transit Gateway for organizations needing global, multi-Region network management.
available in AWS GovCloud (US) Regions as of Jun 2026.
VPC provides the option of creating an IPsec VPN connection between remote customer networks and their VPC over the internet
AWS managed VPN endpoint includes automated multi–data center redundancy & failover built into the AWS side of the VPN connection
AWS managed VPN consists of two parts
Virtual Private Gateway (VPG) on AWS side
Customer Gateway (CGW) on the on-premises data center
AWS Site-to-Site VPN only provides Site-to-Site VPN connectivity. It does not provide Point-to-Site VPC connectivity (use AWS Client VPN for that).
Virtual Private Gateway are Highly Available as it represents two distinct VPN endpoints, physically located in separate data centers to increase the availability of the VPN connection.
High Availability on the on-premises data center must be handled by creating additional Customer Gateway.
AWS Site-to-Site VPN connections are low cost, quick to setup and start with compared to Direct Connect. However, they are not reliable as they traverse through Internet.
5 Gbps Bandwidth Tunnels (Nov 2025) – supports VPN connections with up to 5 Gbps bandwidth per tunnel, a 4x improvement from the previous 1.25 Gbps limit. Beneficial for bandwidth-intensive hybrid applications, big data migrations, and disaster recovery. Bandwidth can be modified on existing connections without changing on-premises configuration (May 2026).
IPv6 Support for Outer Tunnel IPs (Jul 2025) – supports IPv6 addresses on outer tunnel IPs, enabling full IPv6-only VPN connectivity (IPv6-in-IPv6) and mixed (IPv4-in-IPv6) configurations without IPv6>IPv4>IPv6 translation.
VPN Concentrator (Nov 2025) – a new feature that simplifies multi-site connectivity for distributed enterprises with 25+ remote sites needing low bandwidth (under 100 Mbps each). Connects multiple remote sites through a single VPN attachment to Transit Gateway with 5 Gbps aggregate bandwidth.
AWS Client VPN
is a fully managed, scalable VPN service that provides an endpoint for users to establish a secure remote access (Point-to-Site) connection to the AWS network.
uses OpenVPN-based VPN client software for secure connectivity.
handles Point-to-Site VPN connectivity that AWS Site-to-Site VPN does not provide (e.g., remote worker/mobile access).
supports authentication via Active Directory, SAML-based federated authentication, and mutual certificate authentication.
IPv6 Connectivity (Aug 2025) – now supports full IPv6 connectivity for Client VPN endpoints, allowing connections to IPv6 resources in VPCs and from clients on IPv6 networks.
Software VPN
VPC offers the flexibility to fully manage both sides of the VPC connectivity by creating a VPN connection between your remote network and a software VPN appliance running in your VPC network.
Software VPNs help manage both ends of the VPN connection either for compliance purposes or for leveraging gateway devices that are not currently supported by Amazon VPC’s VPN solution.
Software VPNs allows you to handle Point-to-Site connectivity (though AWS Client VPN is now the recommended managed alternative).
Software VPNs, with the above design, introduces a single point of failure and needs to be handled.
AWS Direct Connect helps establish a dedicated private connection between an on-premises network and AWS.
Direct Connect can reduce network costs, increase bandwidth throughput, and provide a more consistent network experience than internet-based or VPN connections
Direct Connect uses industry-standard VLANs to access EC2 instances running within a VPC using private IP addresses
Direct Connect lets you establish
Dedicated Connection: A 1G, 10G, or 100G physical Ethernet connection associated with a single customer through AWS.
Hosted Connection: A physical Ethernet connection that an AWS Direct Connect Partner provisions on behalf of a customer. Speeds range from 50 Mbps to 10 Gbps.
Direct Connect provides the following Virtual Interfaces
Private virtual interface – to access a VPC using private IP addresses.
Public virtual interface – to access all AWS public services using public IP addresses.
Transit virtual interface – to access one or more transit gateways associated with Direct Connect gateways.
Direct Connect connections are not redundant as each connection consists of a single dedicated connection between ports on your router and an Amazon router
Direct Connect High Availability can be configured using
Multiple Direct Connect connections
Back-up IPSec VPN connection
SiteLink – enables sending data between AWS Direct Connect locations to create private network connections between offices and data centers in a global network, bypassing AWS Regions. Data travels over the shortest path between locations using the AWS global network backbone.
VIF Rate Limiters (Jun 2026) – supports Virtual Interface Rate Limiters on dedicated connections to prevent network congestion caused by unexpected traffic spikes on a VIF, protecting other VIFs on the same connection.
LAGs
Direct Connect link aggregation group (LAG) is a logical interface that uses the Link Aggregation Control Protocol (LACP) to aggregate multiple connections at a single AWS Direct Connect endpoint, allowing you to treat them as a single, managed connection.
LAGs need the following
All connections in the LAG must use the same bandwidth.
A maximum of four connections in a LAG. Each connection in the LAG counts toward the overall connection limit for the Region.
All connections in the LAG must terminate at the same AWS Direct Connect endpoint.
offers a Free Tier – fully managed 500 Mbps interconnect to another CSP at no charge on the AWS side (May 2026).
eliminates complex multicloud networking setups that previously required physical Direct Connect connections and manual peering arrangements.
Amazon VPC Lattice
is an application networking service that consistently connects, monitors, and secures communications between services and resources across VPCs and accounts.
automatically manages network connectivity and application layer routing between services across different VPCs and AWS accounts.
abstracts IP address dependencies, allowing applications to communicate securely without direct network routing.
supports HTTP, HTTPS, gRPC, TLS, and TCP protocols.
key features include:
Service Networks – logical grouping of services with shared access and observability policies.
Service Network VPC Endpoints – allows VPCs to connect to service networks via VPC endpoints.
VPC Resources Support (re:Invent 2024) – enables connectivity to TCP resources such as databases, domain names, and IP addresses across VPCs and accounts.
Auth Policies – fine-grained access control using IAM-based policies at the service network and service level.
can replace complex Transit Gateway and PrivateLink configurations for service-to-service communication within a Region.
does not natively support cross-Region service access; requires a proxy solution for external Region connectivity.
Amazon VPC Route Server
is a new managed service (GA Apr 2025) that enables dynamic routing within Amazon VPC using Border Gateway Protocol (BGP).
allows deploying endpoints in a VPC and peering them with virtual appliances to advertise routes using BGP.
filters received routes using standard BGP attributes and propagates selected routes to specified VPC route tables.
dynamically updates VPC and internet gateway route tables with preferred IPv4 or IPv6 routes for routing fault tolerance.
eliminates the need for complex scripting or Lambda-based failover mechanisms for virtual appliance routing.
key use cases:
Automatic active/standby failover for inspection appliances
Dynamic routing between cloud applications and on-premises systems via virtual appliances
Integration with Transit Gateway for centralized inspection architectures
Logging Enhancements (Jun 2025) – provides real-time monitoring of BGP and BFD session states, historical peer-to-peer session data, with delivery via CloudWatch, S3, Data Firehose, or AWS CLI.
AWS VPC – Virtual Private Cloud is a virtual network dedicated to the AWS account. It is logically isolated from other virtual networks in the AWS cloud.
VPC allows the users complete control over their virtual networking environment, including the selection of their own IP address range, creation of subnets, and configuration of route tables and network gateways.
VPC allows you to use both IPv4 and IPv6 in your VPC for secure and easy access to resources and applications.
VPC is a regional service and it spans all of the AZs in the Region. Availability zones (AZ) are multiple, isolated locations within each Region.
VPC Sizing
VPC needs a set of IP addresses in the form of a Classless Inter-Domain Routing (CIDR) block for e.g, 10.0.0.0/16, which allows 2^16 (65536) IP address to be available
Allowed CIDR block size is between
/28 netmask (minimum with 2^4 – 16 available IP address) and
/16 netmask (maximum with 2^16 – 65536 IP address)
CIDR block from private (non-publicly routable) IP address can be assigned
10.0.0.0 – 10.255.255.255 (10/8 prefix)
172.16.0.0 – 172.31.255.255 (172.16/12 prefix)
192.168.0.0 – 192.168.255.255 (192.168/16 prefix)
It’s possible to specify a range of publicly routable IP addresses; however, direct access to the Internet is not currently supported from publicly routable CIDR blocks in a VPC
CIDR block once assigned to the VPC cannot be modified.NOTE – You can now resize VPC. Read AWS blog post.
Each VPC is separate from any other VPC created with the same CIDR block even if it resides within the same AWS account
Connection between your VPC and corporate or home network can be established, however, the CIDR blocks should be not be overlapping for e.g. VPC with CIDR 10.0.0.0/16 can communicate with 10.1.0.0/16 corporate network but the connections would be dropped if it tries to connect to 10.0.37.0/16 corporate network cause of overlapping IP addresses.
VPC allows you to set tenancy options for the Instances launched in it. By default, the tenancy option is shared. If the dedicated option is selected, all the instances within it are launched on dedicated hardware overriding the individual instance tenancy setting.
Deletion of the VPC is possible only after terminating all instances within the VPC and deleting all the components with the VPC e.g. subnets, security groups, network ACLs, route tables, Internet gateways, VPC peering connections, and DHCP options
VPC Peering provides a networking connection between two VPCs (same or different account and region) that enables routing of traffic between them using private IPv4 addresses or IPv6 addresses.
NAT Gateway enables instances in a private subnet to connect to the Internet but prevents the Internet from initiating connections with the instances.
VPC endpoints enable the creation of a private connection between VPC to supported AWS services and VPC endpoint services powered by PrivateLink using its private IP address.
Subnets
Subnet spans a single Availability Zone, distinct locations engineered to be isolated from failures in other AZs, and cannot span across AZs
Subnet can be configured with an Internet gateway to enable communication over the Internet, or virtual private gateway (VPN) connection to enable communication with your corporate network
Subnet can be Public or Private and it depends on whether it has Internet connectivity i.e. is able to route traffic to the Internet through the IGW
Instances within the Public Subnet should be assigned a Public IP or Elastic IP address to be able to communicate with the Internet
For Subnets not connected to the Internet, but has traffic routed through Virtual Private Gateway only is termed as VPN-only subnet
Subnets can be configured to Enable assignment of the Public IP address to all the Instances launched within the Subnet by default, which can be overridden during the creation of the Instance
Subnet Sizing
CIDR block assigned to the Subnet can be the same as the VPC CIDR, in this case you can launch only one subnet within your VPC
CIDR block assigned to the Subnet can be a subset of the VPC CIDR, which allows you to launch multiple subnets within the VPC
CIDR block assigned to the subnet should not be overlapping
CIDR block size allowed is between
/28 netmask (minimum with 2^4 – 16 available IP address) and
/16 netmask (maximum with 2^16 – 65536 IP address)
AWS reserves 5 IPs address (first 4 and last 1 IP address) in each Subnet which are not available for use and cannot be assigned to an instance. for e.g. for a Subnet with a CIDR block 10.0.0.0/24 the following five IPs are reserved
10.0.0.0: Network address
10.0.0.1: Reserved by AWS for the VPC router
10.0.0.2: Reserved by AWS for mapping to Amazon-provided DNS
10.0.0.3: Reserved by AWS for future use
10.0.0.255: Network broadcast address. AWS does not support broadcast in a VPC, therefore the address is reserved.
Subnet Routing
Each Subnet is associated with a route table that controls the traffic.
Subnet Security
Subnet security can be configured using Security groups and NACLs
Security groups work at the instance level, and NACLs work at the subnet level
VPC & Subnet Sizing
VPC supports IPv4 and IPv6 addressing and has different CIDR block size limits for each
IPv6 CIDR block can be optionally associated with the VPC
VPC IPv4 CIDR block cannot be modified once created i.e. cannot increase or decrease the size of an existing CIDR block.
However, secondary CIDR blocks can be associated with the VPC to extend the VPC
Limitations
allowed block size is between a /28 netmask and /16 netmask.
CIDR block must not overlap with any existing CIDR block that’s associated with the VPC.
CIDR block must not be the same or larger than the CIDR range of a route in any of the VPC route tables for e.g. for a CIDR block 10.0.0.0/24, can only associate smaller CIDR blocks like 10.0.0.0/25
IP Addresses
Instances launched in the VPC can have Private, Public, and Elastic IP addresses assigned to them and are properties of ENI (Network Interfaces)
Private IP Addresses
Private IP addresses are not reachable over the Internet, and can be used for communication only between the instances within the VPC
All instances are assigned a private IP address, within the IP address range of the subnet, to the default network interface
Primary IP address is associated with the network interface for its lifetime, even when the instance is stopped and restarted and is released only when the instance is terminated
Additional Private IP addresses, known as secondary private IP address, can be assigned to the instances and these can be reassigned from one network interface to another
Public IP address
Public IP addresses are reachable over the Internet, and can be used for communication between instances and the Internet, or with other AWS services that have public endpoints
Public IP address assignment to the Instance depends if the Public IP Addressing is enabled for the Subnet.
Public IP address can also be assigned to the Instance by enabling the Public IP addressing during the creation of the instance, which overrides the subnet’s public IP addressing attribute
Public IP address is assigned from AWS pool of IP addresses and it is not associated with the AWS account and hence is released when the instance is stopped and restarted or terminated.
Elastic IP address
Elastic IP addresses are static, persistent public IP addresses that can be associated and disassociated with the instance, as required
Elastic IP address is allocated to the VPC and owned by the account unless released.
A Network Interface can be assigned either a Public IP or an Elastic IP. If you assign an instance, that already has a Public IP, an Elastic IP, the public IP is released
Elastic IP addresses can be moved from one instance to another, which can be within the same or different VPC within the same account
Elastic IPs are charged for non-usage i.e. if it is not associated or associated with a stopped instance or an unattached Network Interface
Elastic Network Interface (ENI)
Each Instance is attached to a default elastic network interface (Primary Network Interface eth0) and cannot be detached from the instance
ENI can include the following attributes
Primary private IP address
One or more secondary private IP addresses
One Elastic IP address per private IP address
One public IP address, which can be auto-assigned to the network interface for eth0 when you launch an instance, but only when you create a network interface for eth0 instead of using an existing ENI
One or more security groups
A MAC address
A source/destination check flag
A description
ENI’s attributes follow the ENI as it is attached or detached from an instance and reattached to another instance. When an ENI is moved from one instance to another, network traffic is redirected to the new instance.
Multiple ENIs can be attached to an instance and is useful for use cases:
Create a management network.
Use network and security appliances in your VPC.
Create dual-homed instances with workloads/roles on distinct subnets.
Create a low-budget, high-availability solution.
Route Tables
Route table defines rules, termed as routes, which determine where network traffic from the subnet would be routed
Each VPC has an implicit router to route network traffic
Each VPC has a Main Route table and can have multiple custom route tables created
Each Subnet within a VPC must be associated with a single route table at a time, while a route table can have multiple subnets associated with it
Subnet, if not explicitly associated to a route table, is implicitly associated with the main route table
Every route table contains a local route that enables communication within a VPC which cannot be modified or deleted
Route priority is decided by matching the most specific route in the route table that matches the traffic
Route tables need to be updated to define routes for Internet gateways, Virtual Private gateways, VPC Peering, VPC Endpoints, NAT Devices, etc.
VPC Route Server
Amazon VPC Route Server enables dynamic routing within a VPC using Border Gateway Protocol (BGP), simplifying routing between virtual appliances and cloud workloads.
VPC Route Server was announced GA in April 2025 and expanded to additional regions in January 2026.
Key Capabilities
Deploy Route Server endpoints in VPC and peer with virtual appliances using BGP
Dynamically updates VPC and internet gateway route tables with preferred IPv4 or IPv6 routes
Achieves routing fault tolerance for workloads running in subnets
Automatically reroutes traffic within a VPC for active/standby failover without static routes or manual intervention
Standard BGP attributes used for route filtering and selection
Use Cases
Network appliance high availability (automatic failover via BGP)
Centralized inspection with Transit Gateway for active/standby architectures
Third-party firewall and SD-WAN appliance integration
VPC Route Server eliminates the need for complex scripting or third-party solutions to handle dynamic routing and failover scenarios within a VPC.
Internet Gateways – IGW
An Internet gateway is a horizontally scaled, redundant, and highly available VPC component that allows communication between instances in the VPC and the Internet.
IGW imposes no availability risks or bandwidth constraints on the network traffic.
An Internet gateway serves two purposes:
To provide a target in the VPC route tables for Internet-routable traffic,
To perform network address translation (NAT) for instances that have been NOT been assigned public IP addresses.
Enabling Internet access to an Instance requires
Attaching Internet gateway to the VPC
Subnet should have route tables associated with the route pointing to the Internet gateway
Instances should have a Public IP or Elastic IP address assigned
Security groups and NACLs associated with the Instance should allow relevant traffic
NAT device enables instances in a private subnet to connect to the Internet or other AWS services, but prevents the Internet from initiating connections with the instances.
NAT devices do not support IPv6 traffic, use an egress-only Internet gateway instead.
Egress-only Internet gateway works as a NAT gateway, but for IPv6 traffic
Egress-only Internet gateway is a horizontally scaled, redundant, and highly available VPC component that allows outbound communication over IPv6 from instances in the VPC to the Internet, and prevents the Internet from initiating an IPv6 connection with the instances.
An egress-only Internet gateway is for use with IPv6 traffic only. To enable outbound-only Internet communication over IPv4, use a NAT gateway instead.
Shared VPCs
VPC sharing allows multiple AWS accounts to create their application resources, such as EC2 instances, RDS databases, Redshift clusters, and AWS Lambda functions, into shared, centrally-managed VPCs.
In this model, the account that owns the VPC (owner) shares one or more subnets with other accounts (participants) that belong to the same organization from AWS Organizations.
After a subnet is shared, the participants can view, create, modify, and delete their application resources in the subnets shared with them. Participants cannot view, modify, or delete resources that belong to other participants or the VPC owner.
VPC endpoint enables the creation of a private connection between VPC to supported AWS services and VPC endpoint services powered by PrivateLink using its private IP address
Traffic between VPC and AWS service does not leave the Amazon network
Endpoints are virtual devices, that are horizontally scaled, redundant, and highly available VPC components that allow communication between instances in the VPC and AWS services without imposing availability risks or bandwidth constraints on your network traffic.
Endpoints currently do not support cross-region requests, ensure that the endpoint is created in the same region as the S3 bucket
AWS currently supports the following types of Endpoints
A VPC peering connection is a networking connection between two VPCs that enables the routing of traffic between them using private IPv4 addresses or IPv6 addresses.
VPC peering connection is a one-to-one relationship between two VPCs and can be established between your own VPCs, or with a VPC in another AWS account in the same or different region.
VPC peering helps instances in either VPC can communicate with each other as if they are within the same network using AWS’s existing infrastructure of a VPC to create a peering connection; it is neither a gateway nor a VPN connection and does not rely on a separate piece of physical hardware.
VPC peering does not have any separate charges. However, there are data transfer charges.
VPC Flow Logs help capture information about the IP traffic going to and from network interfaces in the VPC and can help in monitoring the traffic or troubleshooting any connectivity issues.
Flow log can be created for the entire VPC, subnets, or each network interface. If enabled, for the entire VPC or subnet all the network interfaces within that resource are monitored.
Flow log can be configured to capture the type of traffic (accepted traffic, rejected traffic, or all traffic).
Flow logs do not capture real-time log streams for network interfaces.
Flow log data is collected outside of the path of the network traffic, and therefore does not affect network throughput or latency.
Flow logs can be created for network interfaces that are created by other AWS services; for e.g., ELB, RDS, ElastiCache, Redshift, and WorkSpaces.
Flow logs do not capture the following traffic
Traffic generated by instances when they contact the Amazon DNS server.
Traffic generated by a Windows instance for Amazon Windows license activation.
Traffic to and from 169.254.169.254 for instance metadata
Traffic to and from 169.254.169.123 for the Amazon Time Sync Service.
DHCP traffic.
Mirrored traffic.
Traffic to the reserved IP address for the default VPC router.
Traffic between an endpoint network interface and a Network Load Balancer network interface.
Troubleshooting traffic flow
If ACCEPT followed by REJECT, inbound was accepted by Security Groups and ACLs. However, rejected by NACLs outbound
If REJECT, inbound was either rejected by Security Groups OR NACLs.
VPC Block Public Access (BPA)
Amazon VPC Block Public Access (BPA) is a simple, declarative control that authoritatively blocks incoming (ingress) and outgoing (egress) VPC traffic through AWS-provided internet paths (launched November 2024).
VPC BPA supersedes any existing VPC settings (route tables, security groups, NACLs) to drop all traffic that would otherwise be exposed to the internet through Internet Gateways (IGW) or Egress-Only Internet Gateways (EIGW).
Key Features
Single declarative control to block internet access to/from VPCs and subnets
Can be set to bidirectional block (blocks all ingress and egress) or ingress-only block
Prevents accidental public exposure regardless of routing and security configuration
Supports subnet-level exclusions for DMZ architectures
Centralized enforcement across an AWS Organization
Deployment
Can be deployed across AWS Organizations using AWS CloudFormation or CLI
Supports IPv4 and IPv6 traffic blocking
Available in all commercial AWS regions and AWS China Regions (May 2025)
BPA is useful for accounts that should have no internet access (data processing, backend services) while allowing exceptions for specific subnets that require internet connectivity.
VPC Encryption Controls
VPC Encryption Controls is a security and compliance feature that provides centralized control to monitor and enforce encryption in transit for all traffic flows within and across VPCs in a region (GA 2025, paid feature from March 1, 2026).
VPC Encryption Controls uses both application-layer encryption and built-in encryption in transit capability of AWS Nitro System hardware to ensure encryption enforcement.
Operational Modes
Monitor mode – Audit the encryption status of traffic flows and identify resources allowing cleartext traffic
Enforce mode – Prevents creation or use of resources that allow unencrypted traffic; all traffic must be encrypted at hardware layer (Nitro) or application layer (TLS/SSL)
Key Capabilities
Centralized encryption policy enforcement across VPCs
Generates audit logs for compliance and reporting
Identifies resources that allow plaintext traffic
Works with Transit Gateway for inter-VPC encryption
Available in AWS GovCloud (US) Regions as of March 2026
Pricing
Fixed hourly rate for every non-empty VPC (with network interfaces) that has Encryption Controls enabled in either monitor or enforce mode
VPC Encryption Controls helps security teams demonstrate encryption compliance without relying on individual application teams to implement TLS correctly.
AWS VPC IP Address Manager (IPAM)
Amazon VPC IP Address Manager (IPAM) is a fully managed service that simplifies IP address management across AWS environments.
IPAM provides centralized visibility and control over IP address allocations across multiple AWS Regions and accounts within an AWS Organization.
Key benefits of IPAM:
Eliminates manual IP address tracking via spreadsheets or disparate systems
Automated IP address allocation and tracking
Prevents IP address conflicts and overlaps
Provides holistic view of IP address utilization
Supports both IPv4 and IPv6 address management
IPAM Features
Hierarchical pool structure for organizing IP address space
Automated CIDR allocation for VPCs and subnets
Cross-region and cross-account IP address visibility
Integration with AWS Organizations for centralized management
Compliance monitoring and reporting
IP address history and audit trails
IPAM Advanced Tier (launched 2025)
Infoblox infrastructure integration for hybrid cloud IP management
Manage AWS IP addresses through existing Infoblox workflows
Available for private scopes
Enhanced enterprise-grade capabilities
IPAM Integrations
Application Load Balancer (ALB) integration for predictable IP address blocks (March 2025)
IPAM Policies support for RDS and Application Load Balancers (January 2026)
Amazon CloudFront BYOIP for IPv6 through VPC IPAM integration (March 2026)
VPC CIDR allocation automation
AWS Resource Access Manager (RAM) for sharing IP pools
CloudWatch for monitoring and alerting
IPAM Pool Allocation Tags (May 2026)
Supports tags on IPAM pool allocations for organizing, governing, and controlling access to individual IP address allocations
Uses same tagging workflows as other AWS resources
Enables fine-grained access control via IAM policies based on allocation tags
IPAM helps network administrators organize, assign, monitor, and audit IP addresses at scale, reducing management burden and eliminating manual errors.
IPAM is available across all AWS commercial regions, including Asia Pacific (Taipei) as of June 2025.
Amazon VPC Lattice
Amazon VPC Lattice is an application networking service that simplifies service-to-service communication across VPCs and AWS accounts.
VPC Lattice operates at Layer 4 (TCP) and Layer 7 (HTTP/HTTPS) to provide intelligent application-layer routing.
VPC Lattice eliminates the need for complex networking configurations, Transit Gateways, or sidecar-based service meshes.
Key Capabilities
Service-to-service connectivity across VPCs and accounts without IP address management
Built-in service discovery and routing
Application-layer authentication and authorization
Centralized observability and monitoring
Zero-trust security model with fine-grained access controls
Service Networks
Logical container for grouping related services
Provides consistent security policies across services
Can be shared across AWS accounts using AWS Resource Access Manager (RAM)
Enables cross-account connectivity at scale
VPC can have only one service network association
VPC Lattice vs Traditional Networking
Simpler than Transit Gateway for service-to-service communication
No need for VPC Peering connections between every VPC pair
Application-aware routing based on headers, paths, and methods
Automatic service discovery without DNS management
Built-in security without managing security groups across VPCs
Migration from AWS App Mesh
AWS App Mesh is being discontinued effective September 30, 2026
VPC Lattice is the recommended replacement for App Mesh workloads
VPC Lattice provides similar service mesh capabilities without sidecar proxies
Simplified architecture with centralized management
VPC Lattice integrates with Amazon ECS, EKS, EC2, Lambda, and other compute services.
Resource Configurations (Enhanced 2025-2026)
Defines private endpoints (IP address or DNS name) within a VPC for cross-account access
Supports custom domain names for resource configurations (November 2025)
Supports private domain-name targets for secure cross-account access to privately-hosted resources (May 2026)
Attached to resource gateways and shared via AWS RAM
Use cases include microservices architectures, multi-account applications, and hybrid cloud connectivity.
AWS Network Firewall
AWS Network Firewall is a fully managed network security service that protects VPCs from network threats.
Network Firewall provides enterprise-grade perimeter defense with deep packet inspection and intrusion prevention.
Key Features
Stateful and stateless firewall rules
Deep packet inspection (DPI) for Layer 7 traffic analysis
Intrusion detection and prevention system (IDS/IPS)
Domain name filtering and URL filtering
Protocol detection and blocking
Geographic IP filtering
Flexible Rules Engine
Supports thousands of custom firewall rules
Rules based on domain, port, protocol, IP addresses, and pattern matching
Suricata-compatible IPS rules for threat detection
AWS Managed Threat Signatures for known threats
Active threat defense against command-and-control channels and malicious URLs
Traffic Filtering Capabilities
Inbound and outbound web filtering for HTTP/HTTPS traffic
Server Name Indication (SNI) filtering for encrypted traffic
Application protocol detection and enforcement
Malware and botnet protection
DDoS attack mitigation
Deployment and Scalability
Deployed at VPC subnet boundaries
Automatically scales based on traffic load
High availability with 99.99% SLA
Multi-AZ deployment for redundancy
No capacity planning required
Logging and Monitoring
Detailed flow logs for all inspected traffic
Alert logs for detected threats
Integration with CloudWatch, S3, and Kinesis Data Firehose
Real-time visibility into network traffic patterns
Compliance reporting and audit trails
Network Firewall integrates with AWS Firewall Manager for centralized policy management across multiple accounts and VPCs.
Default Stateful Action Update (June 2026)
New default stateful action for firewall policies changed to “Application drop established (server-directed only)” replacing “Application drop established (bidirectional)”
Improves connection reliability for legitimate traffic
Applies to all newly created firewall policies
Common use cases include perimeter security, egress filtering, threat prevention, and compliance enforcement.
AWS Certification Exam Practice Questions
Questions are collected from Internet and the answers are marked as per my knowledge and understanding (which might differ with yours).
AWS services are updated everyday and both the answers and questions might be outdated soon, so research accordingly.
AWS exam questions are not updated to keep up the pace with AWS updates, so even if the underlying feature has changed the question might not be updated
Open to further feedback, discussion and correction.
You have a business-to-business web application running in a VPC consisting of an Elastic Load Balancer (ELB), web servers, application servers and a database. Your web application should only accept traffic from predefined customer IP addresses. Which two options meet this security requirement? Choose 2 answers
Configure web server VPC security groups to allow traffic from your customers’ IPs (Web server is behind the ELB and customer IPs will never reach web servers)
Configure your web servers to filter traffic based on the ELB’s “X-forwarded-for” header (get the customer IPs and create a custom filter to restrict access. Refer link)
Configure ELB security groups to allow traffic from your customers’ IPs and deny all outbound traffic (ELB will see the customer IPs so can restrict access, deny all is basically have no rules in outbound traffic, implicit, and its stateful so would work)
Configure a VPC NACL to allow web traffic from your customers’ IPs and deny all outbound traffic (NACL is stateless, deny all will not work)
A user has created a VPC with public and private subnets using the VPC Wizard. The VPC has CIDR 20.0.0.0/16. The private subnet uses CIDR 20.0.0.0/24. Which of the below mentioned entries are required in the main route table to allow the instances in VPC to communicate with each other?
Destination : 20.0.0.0/24 and Target : VPC
Destination : 20.0.0.0/16 and Target : ALL
Destination : 20.0.0.0/0 and Target : ALL
Destination : 20.0.0.0/16 and Target : Local
A user has created a VPC with two subnets: one public and one private. The user is planning to run the patch update for the instances in the private subnet. How can the instances in the private subnet connect to the internet?
Use the internet gateway with a private IP
Allow outbound traffic in the security group for port 80 to allow internet updates
The private subnet can never connect to the internet
Use NAT with an elastic IP
A user has launched an EC2 instance and installed a website with the Apache webserver. The webserver is running but the user is not able to access the website from the Internet. What can be the possible reason for this failure?
The security group of the instance is not configured properly.
The instance is not configured with the proper key-pairs.
The Apache website cannot be accessed from the Internet.
Instance is not configured with an elastic IP.
A user has created a VPC with public and private subnets using the VPC wizard. Which of the below mentioned statements is true in this scenario?
AWS VPC will automatically create a NAT instance with the micro size
VPC bounds the main route table with a private subnet and a custom route table with a public subnet
User has to manually create a NAT instance
VPC bounds the main route table with a public subnet and a custom route table with a private subnet
A user has created a VPC with public and private subnets. The VPC has CIDR 20.0.0.0/16. The private subnet uses CIDR 20.0.1.0/24 and the public subnet uses CIDR 20.0.0.0/24. The user is planning to host a web server in the public subnet (port 80) and a DB server in the private subnet (port 3306). The user is configuring a security group of the NAT instance. Which of the below mentioned entries is not required for the NAT security group?
For Inbound allow Source: 20.0.1.0/24 on port 80
For Outbound allow Destination: 0.0.0.0/0 on port 80
For Inbound allow Source: 20.0.0.0/24 on port 80
For Outbound allow Destination: 0.0.0.0/0 on port 443
A user has created a VPC with CIDR 20.0.0.0/24. The user has used all the IPs of CIDR and wants to increase the size of the VPC. The user has two subnets: public (20.0.0.0/25) and private (20.0.0.128/25). How can the user change the size of the VPC?
The user can delete all the instances of the subnet. Change the size of the subnets to 20.0.0.0/32 and 20.0.1.0/32, respectively. Then the user can increase the size of the VPC using CLI
It is not possible to change the size of the VPC once it has been created (NOTE – You can now increase the VPC size. Read Post)
User can add a subnet with a higher range so that it will automatically increase the size of the VPC
User can delete the subnets first and then modify the size of the VPC
A user has created a VPC with the public and private subnets using the VPC wizard. The VPC has CIDR 20.0.0.0/16. The public subnet uses CIDR 20.0.1.0/24. The user is planning to host a web server in the public subnet (port 80) and a DB server in the private subnet (port 3306). The user is configuring a security group for the public subnet (WebSecGrp) and the private subnet (DBSecGrp). Which of the below mentioned entries is required in the web server security group (WebSecGrp)?
Configure Destination as DB Security group ID (DbSecGrp) for port 3306 Outbound
Configure port 80 for Destination 0.0.0.0/0 Outbound
Configure port 3306 for source 20.0.0.0/24 InBound
Configure port 80 InBound for source 20.0.0.0/16
A user has created a VPC with CIDR 20.0.0.0/16. The user has created one subnet with CIDR 20.0.0.0/16 by mistake. The user is trying to create another subnet of CIDR 20.0.0.1/24. How can the user create the second subnet?
There is no need to update the subnet as VPC automatically adjusts the CIDR of the first subnet based on the second subnet’s CIDR
The user can modify the first subnet CIDR from the console
It is not possible to create a second subnet as one subnet with the same CIDR as the VPC has been created
The user can modify the first subnet CIDR with AWS CLI
A user has setup a VPC with CIDR 20.0.0.0/16. The VPC has a private subnet (20.0.1.0/24) and a public subnet (20.0.0.0/24). The user’s data centre has CIDR of 20.0.54.0/24 and 20.1.0.0/24. If the private subnet wants to communicate with the data centre, what will happen?
It will allow traffic communication on both the CIDRs of the data centre
It will not allow traffic with data centre on CIDR 20.1.0.0/24 but allows traffic communication on 20.0.54.0/24
It will not allow traffic communication on any of the data centre CIDRs
It will allow traffic with data centre on CIDR 20.1.0.0/24 but does not allow on 20.0.54.0/24 (as the CIDR block would be overlapping)
A user has created a VPC with public and private subnets using the VPC wizard. The VPC has CIDR 20.0.0.0/16. The private subnet uses CIDR 20.0.0.0/24 . The NAT instance ID is i-a12345. Which of the below mentioned entries are required in the main route table attached with the private subnet to allow instances to connect with the internet?
Destination: 0.0.0.0/0 and Target: i-a12345
Destination: 20.0.0.0/0 and Target: 80
Destination: 20.0.0.0/0 and Target: i-a12345
Destination: 20.0.0.0/24 and Target: i-a12345
A user has created a VPC with CIDR 20.0.0.0/16 using the wizard. The user has created a public subnet CIDR (20.0.0.0/24) and VPN only subnets CIDR (20.0.1.0/24) along with the VPN gateway (vgw-12345) to connect to the user’s data centre. The user’s data centre has CIDR 172.28.0.0/12. The user has also setup a NAT instance (i-123456) to allow traffic to the internet from the VPN subnet. Which of the below mentioned options is not a valid entry for the main route table in this scenario?
Destination: 20.0.1.0/24 and Target: i-12345
Destination: 0.0.0.0/0 and Target: i-12345
Destination: 172.28.0.0/12 and Target: vgw-12345
Destination: 20.0.0.0/16 and Target: local
A user has created a VPC with CIDR 20.0.0.0/16. The user has created one subnet with CIDR 20.0.0.0/16 in this VPC. The user is trying to create another subnet with the same VPC for CIDR 20.0.0.1/24. What will happen in this scenario?
The VPC will modify the first subnet CIDR automatically to allow the second subnet IP range
It is not possible to create a subnet with the same CIDR as VPC
The second subnet will be created
It will throw a CIDR overlaps error
A user has created a VPC with CIDR 20.0.0.0/16 using the wizard. The user has created both Public and VPN-Only subnets along with hardware VPN access to connect to the user’s data centre. The user has not yet launched any instance as well as modified or deleted any setup. He wants to delete this VPC from the console. Will the console allow the user to delete the VPC?
Yes, the console will delete all the setups and also delete the virtual private gateway
No, the console will ask the user to manually detach the virtual private gateway first and then allow deleting the VPC
Yes, the console will delete all the setups and detach the virtual private gateway
No, since the NAT instance is running
A user has created a VPC with the public and private subnets using the VPC wizard. The VPC has CIDR 20.0.0.0/16. The public subnet uses CIDR 20.0.1.0/24. The user is planning to host a web server in the public subnet (port 80) and a DB server in the private subnet (port 3306). The user is configuring a security group for the public subnet (WebSecGrp) and the private subnet (DBSecGrp). Which of the below mentioned entries is required in the private subnet database security group (DBSecGrp)?
Allow Inbound on port 3306 for Source Web Server Security Group (WebSecGrp)
Allow Inbound on port 3306 from source 20.0.0.0/16
Allow Outbound on port 3306 for Destination Web Server Security Group (WebSecGrp.
Allow Outbound on port 80 for Destination NAT Instance IP
A user has created a VPC with a subnet and a security group. The user has launched an instance in that subnet and attached a public IP. The user is still unable to connect to the instance. The internet gateway has also been created. What can be the reason for the error?
The internet gateway is not configured with the route table
The private IP is not present
The outbound traffic on the security group is disabled
The internet gateway is not configured with the security group
A user has created a subnet in VPC and launched an EC2 instance within it. The user has not selected the option to assign the IP address while launching the instance. Which of the below mentioned statements is true with respect to the Instance requiring access to the Internet?
The instance will always have a public DNS attached to the instance by default
The user can directly attach an elastic IP to the instance
The instance will never launch if the public IP is not assigned
The user would need to create an internet gateway and then attach an elastic IP to the instance to connect from internet
A user has created a VPC with public and private subnets using the VPC wizard. Which of the below mentioned statements is not true in this scenario?
VPC will create a routing instance and attach it with a public subnet
VPC will create two subnets
VPC will create one internet gateway and attach it to VPC
VPC will launch one NAT instance with an elastic IP
A user has created a VPC with the public subnet. The user has created a security group for that VPC. Which of the below mentioned statements is true when a security group is created?
It can connect to the AWS services, such as S3 and RDS by default
It will have all the inbound traffic by default
It will have all the outbound traffic by default
It will by default allow traffic to the internet gateway
A user has created a VPC with CIDR 20.0.0.0/16 using VPC Wizard. The user has created a public CIDR (20.0.0.0/24) and a VPN only subnet CIDR (20.0.1.0/24) along with the hardware VPN access to connect to the user’s data centre. Which of the below mentioned components is not present when the VPC is setup with the wizard?
Main route table attached with a VPN only subnet
A NAT instance configured to allow the VPN subnet instances to connect with the internet
Custom route table attached with a public subnet
An internet gateway for a public subnet
A user has created a VPC with public and private subnets using the VPC wizard. The user has not launched any instance manually and is trying to delete the VPC. What will happen in this scenario?
It will not allow to delete the VPC as it has subnets with route tables
It will not allow to delete the VPC since it has a running route instance
It will terminate the VPC along with all the instances launched by the wizard
It will not allow to delete the VPC since it has a running NAT instance
A user has created a public subnet with VPC and launched an EC2 instance within it. The user is trying to delete the subnet. What will happen in this scenario?
It will delete the subnet and make the EC2 instance as a part of the default subnet
It will not allow the user to delete the subnet until the instances are terminated
It will delete the subnet as well as terminate the instances
Subnet can never be deleted independently, but the user has to delete the VPC first
A user has created a VPC with CIDR 20.0.0.0/24. The user has created a public subnet with CIDR 20.0.0.0/25 and a private subnet with CIDR 20.0.0.128/25. The user has launched one instance each in the private and public subnets. Which of the below mentioned options cannot be the correct IP address (private IP) assigned to an instance in the public or private subnet?
20.0.0.255
20.0.0.132
20.0.0.122
20.0.0.55
A user has created a VPC with CIDR 20.0.0.0/16. The user has created public and VPN only subnets along with hardware VPN access to connect to the user’s datacenter. The user wants to make so that all traffic coming to the public subnet follows the organization’s proxy policy. How can the user make this happen?
Setting up a NAT with the proxy protocol and configure that the public subnet receives traffic from NAT
Setting up a proxy policy in the internet gateway connected with the public subnet
It is not possible to setup the proxy policy for a public subnet
Setting the route table and security group of the public subnet which receives traffic from a virtual private gateway
A user has created a VPC with CIDR 20.0.0.0/16 using the wizard. The user has created a public subnet CIDR (20.0.0.0/24) and VPN only subnets CIDR (20.0.1.0/24) along with the VPN gateway (vgw-12345) to connect to the user’s data centre. Which of the below mentioned options is a valid entry for the main route table in this scenario?
Destination: 20.0.0.0/24 and Target: vgw-12345
Destination: 20.0.0.0/16 and Target: ALL
Destination: 20.0.1.0/16 and Target: vgw-12345
Destination: 0.0.0.0/0 and Target: vgw-12345
Which two components provide connectivity with external networks? When attached to an Amazon VPC which two components provide connectivity with external networks? Choose 2 answers
Elastic IPs (EIP) (Does not provide connectivity, public IP address will do as well)
NAT Gateway (NAT) (Not Attached to VPC and still needs IGW)
Internet Gateway (IGW)
Virtual Private Gateway (VGW)
You are attempting to connect to an instance in Amazon VPC without success You have already verified that the VPC has an Internet Gateway (IGW) the instance has an associated Elastic IP (EIP) and correct security group rules are in place. Which VPC component should you evaluate next?
The configuration of a NAT instance
The configuration of the Routing Table
The configuration of the internet Gateway (IGW)
The configuration of SRC/DST checking
If you want to launch Amazon Elastic Compute Cloud (EC2) Instances and assign each Instance a predetermined private IP address you should:
Assign a group or sequential Elastic IP address to the instances
Launch the instances in a Placement Group
Launch the instances in the Amazon virtual Private Cloud (VPC)
Use standard EC2 instances since each instance gets a private Domain Name Service (DNS) already
Launch the Instance from a private Amazon Machine image (AMI)
A user has recently started using EC2. The user launched one EC2 instance in the default subnet in EC2-VPC Which of the below mentioned options is not attached or available with the EC2 instance when it is launched?
Public IP address
Internet gateway
Elastic IP
Private IP address
A user has created a VPC with CIDR 20.0.0.0/24. The user has created a public subnet with CIDR 20.0.0.0/25. The user is trying to create the private subnet with CIDR 20.0.0.128/25. Which of the below mentioned statements is true in this scenario?
It will not allow the user to create the private subnet due to a CIDR overlap
It will allow the user to create a private subnet with CIDR as 20.0.0.128/25
This statement is wrong as AWS does not allow CIDR 20.0.0.0/25
It will not allow the user to create a private subnet due to a wrong CIDR range
A user has created a VPC with CIDR 20.0.0.0/16 with only a private subnet and VPN connection using the VPC wizard. The user wants to connect to the instance in a private subnet over SSH. How should the user define the security rule for SSH?
Allow Inbound traffic on port 22 from the user’s network
The user has to create an instance in EC2 Classic with an elastic IP and configure the security group of a private subnet to allow SSH from that elastic IP
The user can connect to a instance in a private subnet using the NAT instance
Allow Inbound traffic on port 80 and 22 to allow the user to connect to a private subnet over the Internet
A company wants to implement their website in a virtual private cloud (VPC). The web tier will use an Auto Scaling group across multiple Availability Zones (AZs). The database will use Multi-AZ RDS MySQL and should not be publicly accessible. What is the minimum number of subnets that need to be configured in the VPC?
1
2
3
4 (2 public subnets for web instances in multiple AZs and 2 private subnets for RDS Multi-AZ)
Which of the following are characteristics of Amazon VPC subnets? Choose 2 answers
Each subnet maps to a single Availability Zone
A CIDR block mask of /25 is the smallest range supported
Instances in a private subnet can communicate with the Internet only if they have an Elastic IP.
By default, all subnets can route between each other, whether they are private or public
Each subnet spans at least 2 Availability zones to provide a high-availability environment
You need to design a VPC for a web-application consisting of an Elastic Load Balancer (ELB). a fleet of web/application servers, and an RDS database The entire Infrastructure must be distributed over 2 availability zones. Which VPC configuration works while assuring the database is not available from the Internet?
One public subnet for ELB one public subnet for the web-servers, and one private subnet for the database
One public subnet for ELB two private subnets for the web-servers, two private subnets for RDS
Two public subnets for ELB two private subnets for the web-servers and two private subnets for RDS
Two public subnets for ELB two public subnets for the web-servers, and two public subnets for RDS
You have deployed a three-tier web application in a VPC with a CIDR block of 10.0.0.0/28. You initially deploy two web servers, two application servers, two database servers and one NAT instance tor a total of seven EC2 instances. The web, application and database servers are deployed across two availability zones (AZs). You also deploy an ELB in front of the two web servers, and use Route53 for DNS Web traffic gradually increases in the first few days following the deployment, so you attempt to double the number of instances in each tier of the application to handle the new load unfortunately some of these new instances fail to launch. Which of the following could the root caused? (Choose 2 answers) [PROFESSIONAL]
The Internet Gateway (IGW) of your VPC has scaled-up adding more instances to handle the traffic spike, reducing the number of available private IP addresses for new instance launches.
AWS reserves one IP address in each subnet’s CIDR block for Route53 so you do not have enough addresses left to launch all of the new EC2 instances.
AWS reserves the first and the last private IP address in each subnet’s CIDR block so you do not have enough addresses left to launch all of the new EC2 instances.
The ELB has scaled-up. Adding more instances to handle the traffic reducing the number of available private IP addresses for new instance launches
AWS reserves the first four and the last IP address in each subnet’s CIDR block so you do not have enough addresses left to launch all of the new EC2 instances.
A user wants to access RDS from an EC2 instance using IP addresses. Both RDS and EC2 are in the same region, but different AZs. Which of the below mentioned options help configure that the instance is accessed faster?
Configure the Private IP of the Instance in RDS security group (Recommended as the data is transferred within the the Amazon network and not through internet – Refer link)
Security group of EC2 allowed in the RDS security group
Configuring the elastic IP of the instance in RDS security group
Configure the Public IP of the instance in RDS security group
In regards to VPC, select the correct statement:
You can associate multiple subnets with the same Route Table.
You can associate multiple subnets with the same Route Table, but you can’t associate a subnet with only one Route Table.
You can’t associate multiple subnets with the same Route Table.
None of these.
You need to design a VPC for a web-application consisting of an ELB a fleet of web application servers, and an RDS DB. The entire infrastructure must be distributed over 2 AZ. Which VPC configuration works while assuring the DB is not available from the Internet?
One Public Subnet for ELB, one Public Subnet for the web-servers, and one private subnet for the DB
One Public Subnet for ELB, two Private Subnets for the web-servers, and two private subnets for the RDS
Two Public Subnets for ELB, two private Subnet for the web-servers, and two private subnet for the RDS
Two Public Subnets for ELB, two Public Subnet for the web-servers, and two public subnets for the RDS
You have an Amazon VPC with one private subnet and one public subnet with a Network Address Translator (NAT) server. You are creating a group of Amazon Elastic Cloud Compute (EC2) instances that configure themselves at startup via downloading a bootstrapping script from Amazon Simple Storage Service (S3) that deploys an application via GIT. Which setup provides the highest level of security?
Amazon EC2 instances in private subnet, no EIPs, route outgoing traffic via the NAT
Amazon EC2 instances in public subnet, no EIPs, route outgoing traffic via the Internet Gateway (IGW)
Amazon EC2 instances in private subnet, assign EIPs, route outgoing traffic via the Internet Gateway (IGW)
Amazon EC2 instances in public subnet, assign EIPs, route outgoing traffic via the NAT
You have launched an Amazon Elastic Compute Cloud (EC2) instance into a public subnet with a primary private IP address assigned, an internet gateway is attached to the VPC, and the public route table is configured to send all Internet-based traffic to the Internet gateway. The instance security group is set to allow all outbound traffic but cannot access the Internet. Why is the Internet unreachable from this instance?
The instance does not have a public IP address
The Internet gateway security group must allow all outbound traffic.
The instance security group must allow all inbound traffic.
The instance “Source/Destination check” property must be enabled.
You have an environment that consists of a public subnet using Amazon VPC and 3 instances that are running in this subnet. These three instances can successfully communicate with other hosts on the Internet. You launch a fourth instance in the same subnet, using the same AMI and security group configuration you used for the others, but find that this instance cannot be accessed from the internet. What should you do to enable Internet access?
Deploy a NAT instance into the public subnet.
Assign an Elastic IP address to the fourth instance
Configure a publically routable IP Address in the host OS of the fourth instance.
Modify the routing table for the public subnet.
You have a load balancer configured for VPC, and all back-end Amazon EC2 instances are in service. However, your web browser times out when connecting to the load balancer’s DNS name. Which options are probable causes of this behavior? Choose 2 answers
The load balancer was not configured to use a public subnet with an Internet gateway configured
The Amazon EC2 instances do not have a dynamically allocated private IP address
The security groups or network ACLs are not property configured for web traffic.
The load balancer is not configured in a private subnet with a NAT instance.
The VPC does not have a VGW configured.
When will you incur costs with an Elastic IP address (EIP)?
When an EIP is allocated.
When it is allocated and associated with a running instance.
When it is allocated and associated with a stopped instance.
Costs are incurred regardless of whether the EIP is associated with a running instance.
A company currently has a VPC with EC2 Instances. A new instance being launched, which will host an application that works on IPv6. You need to ensure that this instance can initiate outgoing traffic to the Internet. At the same time, you need to ensure that no incoming connection can be initiated from the Internet on to the instance. Which of the following would you add to the VPC for this requirement?
A NAT Instance
A NAT Gateway
An Internet Gateway
An egress-only Internet gateway
A company is deploying a multi-account AWS environment and needs centralized IP address management across all accounts and regions. Which AWS service should they use?
AWS Config
AWS Systems Manager
Amazon VPC IP Address Manager (IPAM)
AWS Resource Access Manager
An organization wants to enable service-to-service communication across multiple VPCs and AWS accounts without managing complex networking configurations or Transit Gateways. Which service provides this capability?
AWS PrivateLink
VPC Peering
Amazon VPC Lattice
AWS Direct Connect
A security team needs to implement deep packet inspection and intrusion prevention for all traffic entering and leaving their VPC. Which AWS service should they deploy?
AWS WAF
AWS Shield
AWS Network Firewall
Security Groups
Your company is currently using AWS App Mesh for service mesh capabilities. What is the recommended migration path given AWS’s service roadmap?
Migrate to AWS Cloud Map
Migrate to Amazon VPC Lattice (App Mesh EOL September 30, 2026)
Continue using App Mesh indefinitely
Migrate to Elastic Load Balancing
Which of the following features are provided by Amazon VPC Lattice? Choose 3 answers
Built-in service discovery
VPN connectivity
Cross-account service connectivity
Direct Connect integration
Application-layer authentication
A network administrator needs to prevent IP address conflicts across 50 AWS accounts in their organization. They want automated CIDR allocation for new VPCs. Which service feature addresses this requirement?
VPC Flow Logs
AWS VPC IPAM with automated allocation
AWS Config Rules
VPC CIDR block associations
AWS Network Firewall supports which of the following capabilities? Choose 3 answers
Deep packet inspection (DPI)
DDoS protection at Layer 3/4 (use AWS Shield)
Intrusion detection and prevention (IDS/IPS)
Web application firewall rules (use AWS WAF)
Domain name and URL filtering
Your organization needs to integrate AWS IP address management with existing Infoblox infrastructure. Which IPAM tier is required?
IPAM Basic Tier
IPAM Advanced Tier
IPAM Standard Tier
IPAM Enterprise Tier
A company wants to route HTTP traffic between microservices based on request headers and paths across multiple VPCs. Which service provides this capability?
Application Load Balancer
AWS Transit Gateway
Amazon VPC Lattice (Layer 7 routing)
VPC Peering
Which AWS service provides a 99.99% SLA for managed network security with automatic scaling?
Security Groups
Network ACLs
AWS Network Firewall
AWS WAF
A company needs to implement dynamic routing between their network virtual appliances and VPC route tables using BGP, with automatic failover when an appliance becomes unavailable. Which service should they use?
AWS Transit Gateway
Amazon VPC Route Server
AWS Direct Connect
VPC Peering
An organization wants to ensure no resources in specific VPCs can access or be accessed from the Internet, regardless of security group or route table configurations. Which feature provides this declarative control?
Network ACLs with deny rules
Security Group restrictions
VPC Block Public Access (BPA)
AWS WAF IP restrictions
A security team needs to centrally monitor and enforce that all network traffic within their VPCs is encrypted in transit, with audit logs for compliance. Which feature should they enable?
AWS CloudTrail
VPC Flow Logs
VPC Encryption Controls
AWS Config Rules
Which of the following statements about VPC Encryption Controls are correct? Choose 2 answers
It uses Nitro System hardware encryption and application-layer encryption (TLS/SSL)
It encrypts data at rest in EBS volumes
It provides monitor mode to audit encryption status and enforce mode to prevent unencrypted traffic
It requires VPN connections for all traffic
A company needs to tag individual IP address allocations within their IPAM pools to control access via IAM policies. Which IPAM feature supports this?