awsdocs/amazon-vpc-user-guide

The open source version of the Amazon VPC docs. You can submit feedback and requests for changes by submitting issues in this repo or by making proposed changes and submitting a pull request.

amazon-vpc-user-guide's Issues

missing hyperlinks in VPC_Internet_Gateway.html

Sometimes the HTML file has nothing where the source Markdown file has hyperlinks. I do not see how this could be fixed in Markdown.

1. 
2. 
3. 
4. 
5. 
6. 
7. 

S3 Gateway policy doesn't support PrincipalAccount condition variable

I wanted to scope down access for S3 Gateway using the PrincipalAccount condition variable as part of using it in combination of ECR interface endpoints to have ECS Fargate tasks pull images through the ECR endpoints. After a few days spinning my wheels over it, reached out to AWS support and after they replicated my environment they figured out that S3 Gateway doesn't support the PrincipalAccount condition variable.

I believe that this should go under limitations of the S3 Gateway endpoint part of the documentation. Is this the right place for something like this?

This also means that this section is wrong:

Example: Restrict access to users in a specific account

You can create a policy that restricts access to a specific account.

{
  "Sid": "AllowCallersFromAccount111122223333",
  "Effect": "Allow",
  "Principal": "*",
  "Action": "*",
  "Resource": "*",
  "Condition": {
    "StringEquals": {
      "aws:PrincipalAccount": "111122223333"
    }
  }
}

Unable to reference/use prefix list in security group

I created a security group and a prefix list, when I am trying to add that prefix list to an inbound rule in my security group I get this error:

The maximum number of rules per security group has been reached.

I do not have any other rules in the security group and neither in any other group.
I made prefix list with one entry and also tried without any entry but still getting same error.

Small glitch on Gateway VPC endpoints diagram

Hello,

It seems to be a small issue on the network diagram on the Gateway VPC endpoints documentation. In the diagram, Subnet 1 is displayed with a lock as it was a private subnet. But, the routing table associated with it allows traffic through an internet gateway, making it public.

Gateway VPC endpoints: https://github.com/awsdocs/amazon-vpc-user-guide/blob/master/doc_source/vpce-gateway.md
The diagram URL is: http://docs.aws.amazon.com/vpc/latest/userguide/images/vpc-endpoint-s3-diagram.png

Regards,
Ezequiel

Small glitch in VPC Share example diagram

Hi,

The diagram (https://docs.aws.amazon.com/images/vpc/latest/userguide/images/vpc-share-internet-gateway-example_updated.png) found in the "Example of sharing public subnets and private subnets" (https://docs.aws.amazon.com/vpc/latest/userguide/example-vpc-share.html) page in the Amazon Virtual Private Cloud userguide shows a Private subnet connected directly to the Internet gateway and a Public subnet connected to the Internet gateway via a NAT gateway. This is in contradiction to the definition of the Private and Public subnet found in a later section of the userguide (https://docs.aws.amazon.com/vpc/latest/userguide/configure-subnets.html).

Subnet types
Depending on how you configure your VPC, subnets are considered public, private, or VPN-only:

Public subnet: The subnet traffic is routed to the public internet through an internet gateway or an egress-only internet gateway. 

Private subnet: The subnet traffic can't reach the public internet through an internet gateway or egress-only internet gateway. 
Access to the public internet requires a NAT device.

I think the diagram should be more like the one attached

VPC_Scenario3.md: DHCP options include Amazon and custom DNS servers

Near the bottom of the implementation section of the Scenario 3 VPC example there's a section on DNS:

In scenario 3, you need a DNS server that enables your public subnet to communicate with servers on the Internet, and you need another DNS server that enables your VPN-only subnet to communicate with servers in your network.

Your VPC automatically has a set of DHCP options with domain-name-servers=AmazonProvidedDNS. This is a DNS server that Amazon provides to enable any public subnets in your VPC to communicate with the Internet over an Internet gateway. You must provide your own DNS server and add it to the list of DNS servers your VPC uses. Sets of DHCP options aren't modifiable, so you must create a set of DHCP options that includes both your DNS server and the Amazon DNS server, and update the VPC to use the new set of DHCP options.

Is this correct? The multiple name server addresses in the domain-name-servers option correspond to the nameserver entries that are added to /etc/resolv.conf in an EC2 instance in the VPC. According to the Linux resolv.conf man page the nameserver entries are tried in order, with the next name server queried after the current one times out:

The algorithm used is to try a name server, and if the query times out, try the next, until out of name servers, then repeat trying all the name servers until a maximum number of retries are made.

So my understanding is that multiple nameserver entries should be used for redundancy rather than to specify different authoritative name servers.

By specifying a custom name server which holds private DNS entries for servers in the corporate network as well as the standard Amazon DNS, you could get unexpected behaviour.

For example, if the corporate network contains name servers which are authoritative for acme.com and a DNS lookup is made for a private database running on db.acme.com, the Amazon name server is likely to respond indicating that the subdomain doesn't exist, whereas the custom name server would have responded with the private IP of the database, had it been asked. Because the Amazon name server didn't time out, the custom name server was never queried.

We can almost get the behaviour we want by switching the order of the name servers, but now in the case that the custom name server fails, the Amazon resolver won't have the answer either.

This could be OK for some use cases, as it allows a service to resolve internal host names as long as the custom name server is available; if it isn't, internal lookups fail but public lookups can still succeed using Amazon DNS. However, if you also need to look up records from private hosted zones in Route 53 you'd have the opposite problem to before - a query to the custom name server would return no results when a query to Amazon may have returned successfully.

Additionally, if a host can't reach the custom name server, DNS queries will be delayed by as long as the DNS resolution timeout (1 second when I tried dig on an Amazon Linux EC2 instance). This is reasonable if the name server is unavailable, but if the instance is running in a subnet which isn't allowed access to the VPN then these lookups will always fail, so DNS will always be laggy.

This is the scenario I'm trying to find a solution for - I want to be able to run some services in a private subnet which has access to services in the corporate network and therefore needs to resolve DNS via the VPN, and other services to run in a public (or at least, "less private") subnet which doesn't have access to the VPN, and can use the Amazon DNS server instead. Currently I need to ensure that everything in the VPC can route to our name servers running in the corporate network and all DNS queries need to traverse that network, even though for many services they never need to resolve internal host names.

I'm no expert on DNS so there's a good chance I've got some terminology wrong and may well be completely misunderstanding something; if so I'd greatly appreciate it being pointed out so I can improve on how we're resolving DNS. However, I think there is some kind of inconsistency at least, as the documentation for scenario 3 seems to be the only place the idea of combining a custom name server and the Amazon name server is mentioned, all other documentation I could find around the domain-name-servers DHCP option refer to "IP addresses of up to four domain name servers, or AmazonProvidedDNS".

If the documentation is indeed wrong to suggest using custom name servers with the Amazon name servers, can you suggest a solution I could use to achieve what I'm after, please? It looks as though the Route 53 Resolver could be what I need, but I was hoping there'd be something simpler and cheaper.

AWS SQS Endpoint?

A list of VPC Endpoints is available as part of this guide. However, I am can't see SQS in list of Endpoints or in the list of Gateways. Is there a way to expose AWS SQS to a VPC without going through the internet?

Root Principal for (Interface) Endpoints.

It's not explicitly clear - but what is the evaluation for root for interface endpoints? The line below only specifies gateway endpoints.

For gateway endpoints, if you specify the principal in the format "AWS":"AWS-account-ID" or "AWS":"arn:aws:iam::AWS-account-ID:root", access is granted to the AWS account root user only, and not all IAM users and roles for the account.

What is this error?

Hi, can anyone help me with this error? What caused that error? And how I can solve it?

VPC Secondary CIDR Blocks Rules require small corrections

Secondary CIDRs in the VPC cannot:

1. have the same range as that of primary CIDR block.
2. have the larger range (more IP Addresses) as that of primary CIDR block.

If the primary CIDR is 10.0.0.0/24, secondary cannot be 10.0.0.0/25 as that will be an overlap.
It can be 10.0.1.0/24 or similar.

Publish flow logs to Amazon S3, Section Amazon S3 bucket permissions for flow logs = Contains Inaccurate Information

Note that in the file "Publish flow logs to Amazon S3" the section "Amazon S3 bucket permissions for flow logs" contains a snippet that looks as follows:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AWSLogDeliveryWrite",
            "Effect": "Allow",
            "Principal": {
                "Service": "delivery.logs.amazonaws.com"
            },
            "Action": "s3:PutObject",
            "Resource": "my-s3-arn",
            "Condition": {
                "StringEquals": {
                    "aws:SourceAccount": account_id,
                    "s3:x-amz-acl": "bucket-owner-full-control"
                },
                "ArnLike": {
                    "aws:SourceArn": "arn:aws:logs:region:account_id:*"
                }
            }
        },
        {
            "Sid": "AWSLogDeliveryAclCheck",
            "Effect": "Allow",
            "Principal": {
                "Service": "delivery.logs.amazonaws.com"
            },
            "Action": [
                "s3:GetBucketAcl",
                "s3:ListBucket"
            ],
            "Resource": "arn:aws:s3:::bucket_name",
            "Condition": {
                "StringEquals": {
                    "aws:SourceAccount": account_id
                },
                "ArnLike": {
                    "aws:SourceArn": "arn:aws:logs:region:account_id:*"
                }
            }
        }
    ]
}

This does not mirror the bucket policy created by AWS, which includes a policy section for the AWSLogDeliveryWrite Sid that has resource names ending in my-s3-arn/*.

This is important because the s3:PutObject might operate differently depending on if the action was applied to a bucket resource (i.e. my-s3-arn) or content within a bucket (i.e. my-s3-arn/*).

VPC Gateway Endpoint Definition Unreadable

https://github.com/awsdocs/amazon-vpc-user-guide/blob/0d06781fcb6f25d7a53b1ea9366dc36482d5b212/doc_source/vpc-endpoints.md

L21 - The latest commit garbled the first sentence that defined the VPC Gateway Endpoint.

flow logs comment

IMO, it is unfortunate that the flow log record format can't be changed midstream. If something like the W3C extended log format was supported, the software that generates the flow logs could indicate a format change by inserting a comment record with the change (such as #Fields:). Any software that processes the logs could check for the presence of the format change record, and react accordingly. This provides flexibility for both log record generators and processors.

I can see that there could be concern about overhead (e.g. having to check each record for a format change record). Hopefully, this would be offset by judicious generation of log data. For example, if most log records for a given flow are not applicable ('-'), perhaps it is best not to log that field at all, and indicate so in the first format log record.

Totally wrong architecture

wrong architect,
consumer vpc2 is consumer not a service provider,
ELB just sprays request but reversely transmit data back to client

Interface Endpoints that Support Endpoint Policies (API Gateway)

https://docs.aws.amazon.com/vpc/latest/userguide/vpc-endpoints-access.html

For interface endpoints, only the following examples are listed: CodeBuild, CodeCommit, SNS, SQS.

Now, API Gateway is supported - should that be listed here as well?

https://aws.amazon.com/blogs/compute/introducing-amazon-api-gateway-private-endpoints/

Does a single S3 VPC flow log file always contain logs for the same interface-id (ENI)?

Hi
I am not able to find an answer to my question:
Does a single S3 VPC flow logs file always contain logs for the same interface-id (ENI)?
Would appreciate your information on this.

wrong ipv6 route table in vpc-migrate-ipv6.md

The figure below After you've completed the steps, your VPC will have the following configuration. show a wrong route table for private subnet.

In its following step:
Step 2: Update your route tables -> To update your route table for a private subnet -> 5. Choose Add route. For Destination,
The Targe for ::/0 is a egress-only internet gateway.

But the above figure illustrates a NAT gateway. Should be a egress-only-internet-gateway.

Add Route Table example with tgw-

On page:
https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Route_Tables.html#route-tables-priority
we have several examples with igw-, pcx- etc. but no example with Transit Gateway using tgw- especially what's the route priority if we have route with say vgw- and tgw-

Services Affected by S3 VPC Endpoint Should Include EMR

https://docs.aws.amazon.com/vpc/latest/userguide/vpc-endpoints-s3.html

The table in this section should include EMR based on these details:
https://docs.aws.amazon.com/emr/latest/ManagementGuide/private-subnet-iampolicy.html

There were also previously two other buckets listed for EMR that are not on the current version of the page, unsure if existing clusters may still need access to those for writing support logs.

"arn:aws:s3:::aws157-logs-prod-/"
"arn:aws:s3:::aws157-logs-prod/*"

vpce-interface.md: Update limitations regarding peered VPC connections and instance types?

When I first read this:

Interface endpoints can be accessed through intra-region VPC peering connections from Nitro instances. Interface endpoints can be accessed through inter-region VPC peering connections from any type of instance

... I thought it sounded more likely that the reverse would be true: that intra-region would be supported by all instance types, and inter-region would only be supported by Nitro instances.

I became curious and tested this with an intra-region VPC peering connection (us-east-2 <-> us-east-2) and an inter-region VPC peering connection (us-west-1 <-> us-east-2) and found that I could use an interface endpoint over both types of connections from both types of instances (non-Nitro and Nitro). Maybe that behavior is not supported with every combination of regions. If it is, then the doc should be updated.

Private DNS

In this page - https://docs.aws.amazon.com/vpc/latest/userguide/endpoint-service.html under Endpoint Service Limitations is explicitly mentioned:

"Service consumers must use the endpoint-specific DNS hostnames to access the endpoint service. Private DNS is not supported. For more information, see Accessing a Service Through an Interface Endpoint."

However when I go to Accessing a Service Through an Interface Endpoint (https://docs.aws.amazon.com/vpc/latest/userguide/vpce-interface.html#access-service-though-endpoint) I can see the following:

"If you have enabled private DNS for the endpoint (a private hosted zone), the default DNS hostname for the AWS service for the Region; for example, ec2.us-east-1.amazonaws.com."

---

In other words - we CAN or we CANNOT use private DNS for VPC service endpoint?

Thank you in advance

nat-gateway-scenarios.md

The NAT Gateway scenarios page doesn't describe an High availability architecture where an NAT Gateway is recommended in each availability zone to improve the applications availability and reduce the inter-az network charges.

VPC-NAT states IPv6 traffic is not supported, VPC-NAT Gateway says it is

https://github.com/awsdocs/amazon-vpc-user-guide/blob/master/doc_source/vpc-nat.md?plain=1#L10
https://github.com/awsdocs/amazon-vpc-user-guide/blob/master/doc_source/vpc-nat-gateway.md?plain=1#L36

I presume the latter is true, and it is supported now, but wasn't historically?