A VPC consists of one or more subnets that are located in one or more Availability Zones. Each subnet is associated with a route table that determines how traffic is routed within the VPC and to the Internet. A VPC can also have one or more security groups that control access to your resources. By default, all resources within a VPC can communicate with each other, but you can control this with network ACLs (access control lists) and security groups.

Subnets can either be public or private. For a subnet to be public it will need an internet gateway attached to it with routes in a route table to be able to traverse to the internet. A subnet is deemed to be private when the resources inside of it have no access to the internet. When deciding where to deploy your resources within a VPC, you should consider the following factors:

• Security: Place resources that require more security, such as databases or application servers, in private subnets that are not directly accessible from the Internet.
• Scalability: Place resources that need to scale horizontally, such as web servers or application load balancers, in public subnets that can access the Internet and scale out as needed.
• Latency: Place resources that need low latency communication, such as databases or other backend services, in the same Availability Zone or nearby subnets.
• Regulatory compliance: Place resources that need to comply with specific regulations, such as medical records or financial data, in private subnets with additional security measures.

The diagram shown below is an example architecture of a VPC:

Those are the basics of understanding your VPC and where to put resources within it.

Check out this article that covers application migration to AWS!