How to pick AWS CIDR within the CIDR ranges of VPC?












3














When i try to add a new subnet with CIDR, i got this message



172.22.128.0/24 CIDR is not within the CIDR ranges of VPC



My current VPC is 172.22.130.0/28



Any help ?









share



























    3














    When i try to add a new subnet with CIDR, i got this message



    172.22.128.0/24 CIDR is not within the CIDR ranges of VPC



    My current VPC is 172.22.130.0/28



    Any help ?









    share

























      3












      3








      3







      When i try to add a new subnet with CIDR, i got this message



      172.22.128.0/24 CIDR is not within the CIDR ranges of VPC



      My current VPC is 172.22.130.0/28



      Any help ?









      share













      When i try to add a new subnet with CIDR, i got this message



      172.22.128.0/24 CIDR is not within the CIDR ranges of VPC



      My current VPC is 172.22.130.0/28



      Any help ?







      amazon-web-services subnet amazon-vpc





      share












      share










      share



      share










      asked 5 hours ago









      omar jallohomar jalloh

      162




      162






















          2 Answers
          2






          active

          oldest

          votes


















          2














          The best start is to refer to VPC and Subnet Basics which explains the VPC addressing and sizing reqirements.



          Not sure if you are familiar with CIDR addressing? Essentially the bigger the number after / the less hosts and subnets you can fit inside such network.



          For example:





          • Your VPC CIDR is 172.22.130.0/28 where /28 means that out of the 32 bits in the IP address the first 28 bits are the network address (that part has to be the same for all resources in your VPC) and only the remaining 4 bits (= 32 - 28) can be used to address your instances.



            That gives you at most 24 = 16 IP addresses in your subnet. With 5 IPs reserved by AWS you can only use 11 IP addresses.




          • Also because the minimum subnet size is /28 you can really create only one subnet in your /28 VPC and it has to have the same CIDR range, i.e. 172.22.130.0/28.



            That effectively prevents you from placing your instances in multiple availability zones because subnets can not span across AZs.




          Much better practice is to allocate rather large CIDR blocks for your VPC. At least /24 but even larger if you can. Where larger means /22 or /20 or even /16. That will give you an opportunity to create subnets in multiple availability zones and create both private and public (DMZ) subnets.



          In your case you can allocate 172.22.128.0/24 to the VPC and then create 4 subnets inside the VPC:




          • Public A = 172.22.128.0/26 (in Availability zone a, e.g. ap-southeast-2a)

          • Public B = 172.22.128.64/26 (in AZ b, e.g. ap-southeast-2b)

          • Private A = 172.22.128.128/26 (in AZ a again)

          • Private B = 172.22.128.192/26 (in AZ b again)


          That will give you around 60 IP addresses in each subnet and you can have some hosts in Private subnets and some in Public, you can balance load across availability zones, etc.



          If you want to go one step higher and allocate 172.22.128.0/22 to your VPC the addressing then would be like this:




          • VPC CIDR = 172.22.128.0/22

          • Public A = 172.22.128.0/24

          • Public B = 172.22.129.0/24

          • Private A = 172.22.130.0/24

          • Private B = 172.22.131.0/24


          For the difference between Public and Private subnets refer to this answer: NAT gateway for ec2 instances



          Hope that helps :)






          share|improve this answer





























            0














            The subnet you're trying to add is




            1. not within your VPC's IP range


            2. bigger than your VPC's IP range


            As such, you can't add it.



            Side note: I didn't know AWS would even let you make a /28 VPC. You'll only have fourteen usable IPs in there.






            share|improve this answer





















            • Ok, any ideas what subnet range I can use?
              – omar jalloh
              5 hours ago






            • 2




              @omarjalloh You should delete the VPC and start over. A /28 is way too small for virtually any use case on AWS.
              – ceejayoz
              5 hours ago










            • You can use /16 to /28 in AWS. A /28 is appropriate for a up to about 9 servers, which is a valid use case for some rare needs. Consider a single server that never needs to scale, has no ELB, etc, and your IP address range has to integrate with a large corporate range without NAT.
              – Tim
              4 hours ago











            Your Answer








            StackExchange.ready(function() {
            var channelOptions = {
            tags: "".split(" "),
            id: "2"
            };
            initTagRenderer("".split(" "), "".split(" "), channelOptions);

            StackExchange.using("externalEditor", function() {
            // Have to fire editor after snippets, if snippets enabled
            if (StackExchange.settings.snippets.snippetsEnabled) {
            StackExchange.using("snippets", function() {
            createEditor();
            });
            }
            else {
            createEditor();
            }
            });

            function createEditor() {
            StackExchange.prepareEditor({
            heartbeatType: 'answer',
            autoActivateHeartbeat: false,
            convertImagesToLinks: true,
            noModals: true,
            showLowRepImageUploadWarning: true,
            reputationToPostImages: 10,
            bindNavPrevention: true,
            postfix: "",
            imageUploader: {
            brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
            contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
            allowUrls: true
            },
            onDemand: true,
            discardSelector: ".discard-answer"
            ,immediatelyShowMarkdownHelp:true
            });


            }
            });














            draft saved

            draft discarded


















            StackExchange.ready(
            function () {
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fserverfault.com%2fquestions%2f947971%2fhow-to-pick-aws-cidr-within-the-cidr-ranges-of-vpc%23new-answer', 'question_page');
            }
            );

            Post as a guest















            Required, but never shown

























            2 Answers
            2






            active

            oldest

            votes








            2 Answers
            2






            active

            oldest

            votes









            active

            oldest

            votes






            active

            oldest

            votes









            2














            The best start is to refer to VPC and Subnet Basics which explains the VPC addressing and sizing reqirements.



            Not sure if you are familiar with CIDR addressing? Essentially the bigger the number after / the less hosts and subnets you can fit inside such network.



            For example:





            • Your VPC CIDR is 172.22.130.0/28 where /28 means that out of the 32 bits in the IP address the first 28 bits are the network address (that part has to be the same for all resources in your VPC) and only the remaining 4 bits (= 32 - 28) can be used to address your instances.



              That gives you at most 24 = 16 IP addresses in your subnet. With 5 IPs reserved by AWS you can only use 11 IP addresses.




            • Also because the minimum subnet size is /28 you can really create only one subnet in your /28 VPC and it has to have the same CIDR range, i.e. 172.22.130.0/28.



              That effectively prevents you from placing your instances in multiple availability zones because subnets can not span across AZs.




            Much better practice is to allocate rather large CIDR blocks for your VPC. At least /24 but even larger if you can. Where larger means /22 or /20 or even /16. That will give you an opportunity to create subnets in multiple availability zones and create both private and public (DMZ) subnets.



            In your case you can allocate 172.22.128.0/24 to the VPC and then create 4 subnets inside the VPC:




            • Public A = 172.22.128.0/26 (in Availability zone a, e.g. ap-southeast-2a)

            • Public B = 172.22.128.64/26 (in AZ b, e.g. ap-southeast-2b)

            • Private A = 172.22.128.128/26 (in AZ a again)

            • Private B = 172.22.128.192/26 (in AZ b again)


            That will give you around 60 IP addresses in each subnet and you can have some hosts in Private subnets and some in Public, you can balance load across availability zones, etc.



            If you want to go one step higher and allocate 172.22.128.0/22 to your VPC the addressing then would be like this:




            • VPC CIDR = 172.22.128.0/22

            • Public A = 172.22.128.0/24

            • Public B = 172.22.129.0/24

            • Private A = 172.22.130.0/24

            • Private B = 172.22.131.0/24


            For the difference between Public and Private subnets refer to this answer: NAT gateway for ec2 instances



            Hope that helps :)






            share|improve this answer


























              2














              The best start is to refer to VPC and Subnet Basics which explains the VPC addressing and sizing reqirements.



              Not sure if you are familiar with CIDR addressing? Essentially the bigger the number after / the less hosts and subnets you can fit inside such network.



              For example:





              • Your VPC CIDR is 172.22.130.0/28 where /28 means that out of the 32 bits in the IP address the first 28 bits are the network address (that part has to be the same for all resources in your VPC) and only the remaining 4 bits (= 32 - 28) can be used to address your instances.



                That gives you at most 24 = 16 IP addresses in your subnet. With 5 IPs reserved by AWS you can only use 11 IP addresses.




              • Also because the minimum subnet size is /28 you can really create only one subnet in your /28 VPC and it has to have the same CIDR range, i.e. 172.22.130.0/28.



                That effectively prevents you from placing your instances in multiple availability zones because subnets can not span across AZs.




              Much better practice is to allocate rather large CIDR blocks for your VPC. At least /24 but even larger if you can. Where larger means /22 or /20 or even /16. That will give you an opportunity to create subnets in multiple availability zones and create both private and public (DMZ) subnets.



              In your case you can allocate 172.22.128.0/24 to the VPC and then create 4 subnets inside the VPC:




              • Public A = 172.22.128.0/26 (in Availability zone a, e.g. ap-southeast-2a)

              • Public B = 172.22.128.64/26 (in AZ b, e.g. ap-southeast-2b)

              • Private A = 172.22.128.128/26 (in AZ a again)

              • Private B = 172.22.128.192/26 (in AZ b again)


              That will give you around 60 IP addresses in each subnet and you can have some hosts in Private subnets and some in Public, you can balance load across availability zones, etc.



              If you want to go one step higher and allocate 172.22.128.0/22 to your VPC the addressing then would be like this:




              • VPC CIDR = 172.22.128.0/22

              • Public A = 172.22.128.0/24

              • Public B = 172.22.129.0/24

              • Private A = 172.22.130.0/24

              • Private B = 172.22.131.0/24


              For the difference between Public and Private subnets refer to this answer: NAT gateway for ec2 instances



              Hope that helps :)






              share|improve this answer
























                2












                2








                2






                The best start is to refer to VPC and Subnet Basics which explains the VPC addressing and sizing reqirements.



                Not sure if you are familiar with CIDR addressing? Essentially the bigger the number after / the less hosts and subnets you can fit inside such network.



                For example:





                • Your VPC CIDR is 172.22.130.0/28 where /28 means that out of the 32 bits in the IP address the first 28 bits are the network address (that part has to be the same for all resources in your VPC) and only the remaining 4 bits (= 32 - 28) can be used to address your instances.



                  That gives you at most 24 = 16 IP addresses in your subnet. With 5 IPs reserved by AWS you can only use 11 IP addresses.




                • Also because the minimum subnet size is /28 you can really create only one subnet in your /28 VPC and it has to have the same CIDR range, i.e. 172.22.130.0/28.



                  That effectively prevents you from placing your instances in multiple availability zones because subnets can not span across AZs.




                Much better practice is to allocate rather large CIDR blocks for your VPC. At least /24 but even larger if you can. Where larger means /22 or /20 or even /16. That will give you an opportunity to create subnets in multiple availability zones and create both private and public (DMZ) subnets.



                In your case you can allocate 172.22.128.0/24 to the VPC and then create 4 subnets inside the VPC:




                • Public A = 172.22.128.0/26 (in Availability zone a, e.g. ap-southeast-2a)

                • Public B = 172.22.128.64/26 (in AZ b, e.g. ap-southeast-2b)

                • Private A = 172.22.128.128/26 (in AZ a again)

                • Private B = 172.22.128.192/26 (in AZ b again)


                That will give you around 60 IP addresses in each subnet and you can have some hosts in Private subnets and some in Public, you can balance load across availability zones, etc.



                If you want to go one step higher and allocate 172.22.128.0/22 to your VPC the addressing then would be like this:




                • VPC CIDR = 172.22.128.0/22

                • Public A = 172.22.128.0/24

                • Public B = 172.22.129.0/24

                • Private A = 172.22.130.0/24

                • Private B = 172.22.131.0/24


                For the difference between Public and Private subnets refer to this answer: NAT gateway for ec2 instances



                Hope that helps :)






                share|improve this answer












                The best start is to refer to VPC and Subnet Basics which explains the VPC addressing and sizing reqirements.



                Not sure if you are familiar with CIDR addressing? Essentially the bigger the number after / the less hosts and subnets you can fit inside such network.



                For example:





                • Your VPC CIDR is 172.22.130.0/28 where /28 means that out of the 32 bits in the IP address the first 28 bits are the network address (that part has to be the same for all resources in your VPC) and only the remaining 4 bits (= 32 - 28) can be used to address your instances.



                  That gives you at most 24 = 16 IP addresses in your subnet. With 5 IPs reserved by AWS you can only use 11 IP addresses.




                • Also because the minimum subnet size is /28 you can really create only one subnet in your /28 VPC and it has to have the same CIDR range, i.e. 172.22.130.0/28.



                  That effectively prevents you from placing your instances in multiple availability zones because subnets can not span across AZs.




                Much better practice is to allocate rather large CIDR blocks for your VPC. At least /24 but even larger if you can. Where larger means /22 or /20 or even /16. That will give you an opportunity to create subnets in multiple availability zones and create both private and public (DMZ) subnets.



                In your case you can allocate 172.22.128.0/24 to the VPC and then create 4 subnets inside the VPC:




                • Public A = 172.22.128.0/26 (in Availability zone a, e.g. ap-southeast-2a)

                • Public B = 172.22.128.64/26 (in AZ b, e.g. ap-southeast-2b)

                • Private A = 172.22.128.128/26 (in AZ a again)

                • Private B = 172.22.128.192/26 (in AZ b again)


                That will give you around 60 IP addresses in each subnet and you can have some hosts in Private subnets and some in Public, you can balance load across availability zones, etc.



                If you want to go one step higher and allocate 172.22.128.0/22 to your VPC the addressing then would be like this:




                • VPC CIDR = 172.22.128.0/22

                • Public A = 172.22.128.0/24

                • Public B = 172.22.129.0/24

                • Private A = 172.22.130.0/24

                • Private B = 172.22.131.0/24


                For the difference between Public and Private subnets refer to this answer: NAT gateway for ec2 instances



                Hope that helps :)







                share|improve this answer












                share|improve this answer



                share|improve this answer










                answered 1 hour ago









                MLuMLu

                6,33711638




                6,33711638

























                    0














                    The subnet you're trying to add is




                    1. not within your VPC's IP range


                    2. bigger than your VPC's IP range


                    As such, you can't add it.



                    Side note: I didn't know AWS would even let you make a /28 VPC. You'll only have fourteen usable IPs in there.






                    share|improve this answer





















                    • Ok, any ideas what subnet range I can use?
                      – omar jalloh
                      5 hours ago






                    • 2




                      @omarjalloh You should delete the VPC and start over. A /28 is way too small for virtually any use case on AWS.
                      – ceejayoz
                      5 hours ago










                    • You can use /16 to /28 in AWS. A /28 is appropriate for a up to about 9 servers, which is a valid use case for some rare needs. Consider a single server that never needs to scale, has no ELB, etc, and your IP address range has to integrate with a large corporate range without NAT.
                      – Tim
                      4 hours ago
















                    0














                    The subnet you're trying to add is




                    1. not within your VPC's IP range


                    2. bigger than your VPC's IP range


                    As such, you can't add it.



                    Side note: I didn't know AWS would even let you make a /28 VPC. You'll only have fourteen usable IPs in there.






                    share|improve this answer





















                    • Ok, any ideas what subnet range I can use?
                      – omar jalloh
                      5 hours ago






                    • 2




                      @omarjalloh You should delete the VPC and start over. A /28 is way too small for virtually any use case on AWS.
                      – ceejayoz
                      5 hours ago










                    • You can use /16 to /28 in AWS. A /28 is appropriate for a up to about 9 servers, which is a valid use case for some rare needs. Consider a single server that never needs to scale, has no ELB, etc, and your IP address range has to integrate with a large corporate range without NAT.
                      – Tim
                      4 hours ago














                    0












                    0








                    0






                    The subnet you're trying to add is




                    1. not within your VPC's IP range


                    2. bigger than your VPC's IP range


                    As such, you can't add it.



                    Side note: I didn't know AWS would even let you make a /28 VPC. You'll only have fourteen usable IPs in there.






                    share|improve this answer












                    The subnet you're trying to add is




                    1. not within your VPC's IP range


                    2. bigger than your VPC's IP range


                    As such, you can't add it.



                    Side note: I didn't know AWS would even let you make a /28 VPC. You'll only have fourteen usable IPs in there.







                    share|improve this answer












                    share|improve this answer



                    share|improve this answer










                    answered 5 hours ago









                    ceejayozceejayoz

                    26.5k66389




                    26.5k66389












                    • Ok, any ideas what subnet range I can use?
                      – omar jalloh
                      5 hours ago






                    • 2




                      @omarjalloh You should delete the VPC and start over. A /28 is way too small for virtually any use case on AWS.
                      – ceejayoz
                      5 hours ago










                    • You can use /16 to /28 in AWS. A /28 is appropriate for a up to about 9 servers, which is a valid use case for some rare needs. Consider a single server that never needs to scale, has no ELB, etc, and your IP address range has to integrate with a large corporate range without NAT.
                      – Tim
                      4 hours ago


















                    • Ok, any ideas what subnet range I can use?
                      – omar jalloh
                      5 hours ago






                    • 2




                      @omarjalloh You should delete the VPC and start over. A /28 is way too small for virtually any use case on AWS.
                      – ceejayoz
                      5 hours ago










                    • You can use /16 to /28 in AWS. A /28 is appropriate for a up to about 9 servers, which is a valid use case for some rare needs. Consider a single server that never needs to scale, has no ELB, etc, and your IP address range has to integrate with a large corporate range without NAT.
                      – Tim
                      4 hours ago
















                    Ok, any ideas what subnet range I can use?
                    – omar jalloh
                    5 hours ago




                    Ok, any ideas what subnet range I can use?
                    – omar jalloh
                    5 hours ago




                    2




                    2




                    @omarjalloh You should delete the VPC and start over. A /28 is way too small for virtually any use case on AWS.
                    – ceejayoz
                    5 hours ago




                    @omarjalloh You should delete the VPC and start over. A /28 is way too small for virtually any use case on AWS.
                    – ceejayoz
                    5 hours ago












                    You can use /16 to /28 in AWS. A /28 is appropriate for a up to about 9 servers, which is a valid use case for some rare needs. Consider a single server that never needs to scale, has no ELB, etc, and your IP address range has to integrate with a large corporate range without NAT.
                    – Tim
                    4 hours ago




                    You can use /16 to /28 in AWS. A /28 is appropriate for a up to about 9 servers, which is a valid use case for some rare needs. Consider a single server that never needs to scale, has no ELB, etc, and your IP address range has to integrate with a large corporate range without NAT.
                    – Tim
                    4 hours ago


















                    draft saved

                    draft discarded




















































                    Thanks for contributing an answer to Server Fault!


                    • Please be sure to answer the question. Provide details and share your research!

                    But avoid



                    • Asking for help, clarification, or responding to other answers.

                    • Making statements based on opinion; back them up with references or personal experience.


                    To learn more, see our tips on writing great answers.





                    Some of your past answers have not been well-received, and you're in danger of being blocked from answering.


                    Please pay close attention to the following guidance:


                    • Please be sure to answer the question. Provide details and share your research!

                    But avoid



                    • Asking for help, clarification, or responding to other answers.

                    • Making statements based on opinion; back them up with references or personal experience.


                    To learn more, see our tips on writing great answers.




                    draft saved


                    draft discarded














                    StackExchange.ready(
                    function () {
                    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fserverfault.com%2fquestions%2f947971%2fhow-to-pick-aws-cidr-within-the-cidr-ranges-of-vpc%23new-answer', 'question_page');
                    }
                    );

                    Post as a guest















                    Required, but never shown





















































                    Required, but never shown














                    Required, but never shown












                    Required, but never shown







                    Required, but never shown

































                    Required, but never shown














                    Required, but never shown












                    Required, but never shown







                    Required, but never shown







                    Popular posts from this blog

                    CARDNET

                    Boot-repair Failure: Unable to locate package grub-common:i386

                    濃尾地震