I was struggling with this, too, but I found an answer over here https://stackoverflow.com/a/17162973/1750869 that helped resolve this issue for me. Reposting answer below.
You don't have to open permissions to everyone. Use the below Bucket policies on source and destination for copying from a bucket in one account to another using an IAM user
Bucket to Copy from – SourceBucket
Bucket to Copy to – DestinationBucket
Source AWS Account ID - XXXX–XXXX-XXXX
Source IAM User - src–iam-user
The below policy means – the IAM user - XXXX–XXXX-XXXX:src–iam-user has s3:ListBucket and s3:GetObject privileges on SourceBucket/* and s3:ListBucket and s3:PutObject privileges on DestinationBucket/*
On the SourceBucket the policy should be like:
{
"Id": "Policy1357935677554",
"Statement": [
{
"Sid": "Stmt1357935647218",
"Action": [
"s3:ListBucket"
],
"Effect": "Allow",
"Resource": "arn:aws:s3:::SourceBucket",
"Principal": {"AWS": "arn:aws:iam::XXXXXXXXXXXX:user/src–iam-user"}
},
{
"Sid": "Stmt1357935676138",
"Action": ["s3:GetObject"],
"Effect": "Allow",
"Resource": "arn:aws:s3::: SourceBucket/*",
"Principal": {"AWS": "arn:aws:iam::XXXXXXXXXXXX:user/src–iam-user"}
}
]
}
On the DestinationBucket the policy should be:
{
"Id": "Policy1357935677554",
"Statement": [
{
"Sid": "Stmt1357935647218",
"Action": [
"s3:ListBucket"
],
"Effect": "Allow",
"Resource": "arn:aws:s3::: DestinationBucket",
"Principal": {"AWS": "arn:aws:iam::XXXXXXXXXXXX:user/src–iam-user"}
},
{
"Sid": "Stmt1357935676138",
"Action": ["s3:PutObject"],
"Effect": "Allow",
"Resource": "arn:aws:s3::: DestinationBucket/*",
"Principal": {"AWS": "arn:aws:iam::XXXXXXXXXXXX:user/src–iam-user"}
}
]
}
command to be run is s3cmd cp s3://SourceBucket/File1 s3://DestinationBucket/File1
here's what finally worked for me, using the AWS CLI. I'm aware there are other dependencies besides subnets, but this is a start:
jcomeau@aspire:~$ aws ec2 describe-subnets
{
"Subnets": [
{
"VpcId": "vpc-9a5c2bfe",
"CidrBlock": "10.0.0.0/25",
"MapPublicIpOnLaunch": false,
"DefaultForAz": false,
"State": "available",
"AvailabilityZone": "us-east-1c",
"SubnetId": "subnet-10923666",
"AvailableIpAddressCount": 123
}
]
}
jcomeau@aspire:~$ aws ec2 delete-subnet --subnet-id=subnet-10923666
jcomeau@aspire:~$ aws ec2 delete-vpc --vpc-id=vpc-9a5c2bfe
jcomeau@aspire:~$
OK, so that didn't work on all of mine. here's another one:
jcomeau@aspire:~$ aws ec2 describe-internet-gateways
{
"InternetGateways": [
{
"Tags": [],
"InternetGatewayId": "igw-37e81153",
"Attachments": [
{
"State": "available",
"VpcId": "vpc-e2087c86"
}
]
}
]
}
jcomeau@aspire:~$ aws ec2 detach-internet-gateway --internet-gateway-id=igw-37e81153 --vpc-id=vpc-e2087c86
jcomeau@aspire:~$ aws ec2 delete-internet-gateway --internet-gateway-id=igw-37e81153
jcomeau@aspire:~$ aws ec2 delete-vpc --vpc-id=vpc-e2087c86
jcomeau@aspire:~$
Best Answer
Being "private" (as opposed to "public") is not a literal configuration attribute of a subnet.
It's derived from the subnet's associated route table... although it's not a literal configuration attribute of the route table, either.
Official definition:
This means directly to the Internet Gateway, not via a NAT Gateway, NAT Instance, Virtual Private Gateway, or other gateway-type device.
As typically deployed, a public subnet is a subnet whose associated route table has a default route that points to the Internet Gateway object... though it could also be a subnet with a route table that had only specific destinations routing directly to the Internet Gateway, and that would still essentially be a public subnet.
Because the configuration does have some flexibility, there's not a strict delineation. For practical purposes, any subnets that are associated with route tables with routes pointing to the Internet Gateway could typically be assumed to be "public" subnets, and the rest would be "private," so the discovery process would amount to traversing the hierarchy starting from the other direction, from the VPC → Route Tables (those with IGW routes = public) → associated Subnets for those route tables.