How to apply using Terraform to launch multiple EC2 Resource with different configs (VPC not maintained by TF)
You can use a remote backend as a data source. That is working well for us thus far but this project is not very mature and we will likely refactor a time or ten.

data "terraform_remote_state" "network" {
  backend = "s3"
  config {
    // some variables related to config would likely go here
  }
}


then for the teams not managing the network to consume that data you could create an instance like (special attention to the subnet_id here):

resource "aws_instance" "oracle_ec2" {
  ami           = "${lookup(var.ami, var.region)}"
  instance_type = "${var.instance_type}"
  key_name      = "${var.key_name}"
  subnet_id     = "${data.terraform_remote_state.network.subnet_id}"
}


The network team should be able to manage the networking infrastructure and you should be able to consume those values based on current state. 

Terraform Remote State Data Source


  2) If new instances launch as t2.large(Instance type passed as variable) while old ones run on t2.micro


If you change the instance type from t2.micro to t2.large then yes the t2.micro instances will be destroyed and replaced with the t2.large. The name of the game is immutability outside of meta data changes like altering tags. Look into lifecycle hooks to alleviate some of this pain

lifecycle {
  create_before_destroy = true
}



  will it recreate old instances too if I just increase the count


No, current instances would not be destroyed. Terraform will check the state to see how many instances you currently have. If more instances are necessary, terraform will know how many instances to create and create the instances necessary


  Also, is there a way to automate this process i.e. append something like a template for new EC2 instance to existing .tf file.


Not sure what exactly you mean by this one. What I will say is that having the data coupled to the instance itself makes instance immutability and using terraform more difficult. A (untested and unproven) thought and potential solution in my head is to:

//create an ebs volume
resource "aws_ebs_volume" "oracle-data" {
  ...
}

//attach that volume to the instance
resource "aws_volume_attachment" "oracle-data-attachment" {
  ...
}


with some bash involved for an init script that creates and mounts the new volume to be used in conjunction with the aws_volume_attachment resource. That could potentially create a new instance preserving the EBS volume then reattaching it to the new instance.