3 ms·

I'm not sure what the AWS services not supporting IPv6 has to do with charging for public IPv4 usage. Private IPv4 is still free so can access services over end

I'm not sure what the AWS services not supporting IPv6 has to do with charging for public IPv4 usage. Private IPv4 is still free so can access services over endpoints. NAT gateways cost the same and can access services over public IPv4 network. AWS also added IPv6 NAT64 gateway so it should be possible to run IPv6-only internally and still access AWS services and the rest of the Internet.

supriyo-biswas 3y ago
This would be acceptable if this internal route was already configured for free. However, it appears VPC endpoints have their own pricing[1], at which point one must carefully consider whether paying up for the IPv4 address is the better option. [1] https://aws.amazon.com/privatelink/pricing/ https://aws.amazon.com/privatelink/pricing/
- GabeIsko 3y ago
  I'm curious, why can't you use an elastic IP?
  - supriyo-biswas 3y ago
    This entire thread is about the additional costs imposed on a publicly accessible IP[1]. Granted, there are other (but similarly expensive) workarounds such as NAT gateways[2] for outbound connectivity or the cheaper NAT instance method which AWS doesn't support any more, but there are alternatives[3]. However, for use cases requiring inbound connectivity such as setting up websites on EC2 instances, or using an ELB which need internet access, you need an IPv4 address and these charges definitely rack up. [1] https://aws.amazon.com/blogs/aws/new-aws-public-ipv4-address-charge-public-ip-insights/ https://aws.amazon.com/blogs/aws/new-aws-public-ipv4-address... [2] https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gat... [3] https://fck-nat.dev https://fck-nat.dev
    - GabeIsko 3y ago
      Ah, I think i had the connectivity backwards. I thought the complaint was about hosts connecting to these services, not inbound connections to hosts. Ultimately, they will probably want people to solve it with service endpoints, and give preferred pricing on that. But I kind of get why that is a bit wigged out. Because it locks more architecture into them as a vendor. I'm not really sure putting a public ip is a good solution to this, but it is kind of scary because suddenly we are deciding infrastructure decisions more based on how they are being priced. Needs regulation.
- inopinatus 3y ago
  Interestingly, S3 and DynamoDB access from privately addressed IPv4 VPCs is free, since it's implemented as routes not endpoints, and although rather constraining you can definitely build things with that. Case in point, I had some internal instances that very occasionally want to pull files from a partner's endpoint. Previous solution, NAT gateway. New solution, DynamoDB request table streamed to AWS Lambda and results in S3. Caveat programmer: only suitable if the task is not latency sensitive. DynamoDB/Lambda are not everyone's cup of tea, but it's nice to have options.
  - supriyo-biswas 3y ago
    > S3 and DynamoDB access from privately addressed IPv4 VPCs is free, since it's implemented as routes not endpoints TIL. Thanks!

supriyo-biswas 3y ago

This would be acceptable if this internal route was already configured for free. However, it appears VPC endpoints have their own pricing[1], at which point one must carefully consider whether paying up for the IPv4 address is the better option. [1] https://aws.amazon.com/privatelink/pricing/ https://aws.amazon.com/privatelink/pricing/

GabeIsko 3y ago
I'm curious, why can't you use an elastic IP?
- supriyo-biswas 3y ago
  This entire thread is about the additional costs imposed on a publicly accessible IP[1]. Granted, there are other (but similarly expensive) workarounds such as NAT gateways[2] for outbound connectivity or the cheaper NAT instance method which AWS doesn't support any more, but there are alternatives[3]. However, for use cases requiring inbound connectivity such as setting up websites on EC2 instances, or using an ELB which need internet access, you need an IPv4 address and these charges definitely rack up. [1] https://aws.amazon.com/blogs/aws/new-aws-public-ipv4-address-charge-public-ip-insights/ https://aws.amazon.com/blogs/aws/new-aws-public-ipv4-address... [2] https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gat... [3] https://fck-nat.dev https://fck-nat.dev
  - GabeIsko 3y ago
    Ah, I think i had the connectivity backwards. I thought the complaint was about hosts connecting to these services, not inbound connections to hosts. Ultimately, they will probably want people to solve it with service endpoints, and give preferred pricing on that. But I kind of get why that is a bit wigged out. Because it locks more architecture into them as a vendor. I'm not really sure putting a public ip is a good solution to this, but it is kind of scary because suddenly we are deciding infrastructure decisions more based on how they are being priced. Needs regulation.
inopinatus 3y ago
Interestingly, S3 and DynamoDB access from privately addressed IPv4 VPCs is free, since it's implemented as routes not endpoints, and although rather constraining you can definitely build things with that. Case in point, I had some internal instances that very occasionally want to pull files from a partner's endpoint. Previous solution, NAT gateway. New solution, DynamoDB request table streamed to AWS Lambda and results in S3. Caveat programmer: only suitable if the task is not latency sensitive. DynamoDB/Lambda are not everyone's cup of tea, but it's nice to have options.
- supriyo-biswas 3y ago
  > S3 and DynamoDB access from privately addressed IPv4 VPCs is free, since it's implemented as routes not endpoints TIL. Thanks!