Devops, sre at managebac

Previous Lambda integration model for VPCs

It helps to understand some basics about the way that networking with Lambda works. Today, all of the compute infrastructure for Lambda runs inside of VPCs owned by the service.

When you invoke a Lambda function from any invocation source and with any execution model (synchronous, asynchronous, or poll based), it occurs through the Lambda API. There is no direct network access to the execution environment where your functions run:

By default, when your Lambda function is not configured to connect to your own VPCs, the function can access anything available on the public internet such as other AWS services, HTTPS endpoints for APIs, or services and endpoints outside AWS. The function then has no way to connect to your private resources inside of your VPC.

When you configure your Lambda function to connect to your own VPC, it creates an elastic network interface in your VPC and then does a cross-account attachment. These network interfaces allow network access from your Lambda functions to your private resources. These Lambda functions continue to run inside of the Lambda service’s VPC and can now only access resources over the network through your VPC.

All invocations for functions continue to come from the Lambda service’s API and you still do not have direct network access to the execution environment. The attached network interface exists inside of your account and counts towards limits that exist in your account for that Region.

With this model, there are a number of challenges that you might face. The time taken to create and attach new network interfaces can cause longer cold-starts, increasing the time it takes to spin up a new execution environment before your code can be invoked.

As your function’s execution environment scales to handle an increase in requests, more network interfaces are created and attached to the Lambda infrastructure. The exact number of network interfaces created and attached is a factor of your function configuration and concurrency.

Every network interface created for your function is associated with and consumes an IP address in your VPC subnets. It counts towards your account level maximum limit of network interfaces.

As your function scales, you have to be mindful of several issues:

• Managing the IP address space in your subnets
• Reaching the account level network interface limit
• The potential to hit the API rate limit on creating new network interfaces

Associate an IPv6 CIDR block with your subnet

You can associate an IPv6 CIDR block with an existing subnet in your VPC. The
subnet must not have an existing IPv6 CIDR block associated with it.

To associate an IPv6 CIDR block with a subnet using the console

1. Open the Amazon VPC console at
   https://console.aws.amazon.com/vpc/.

2. In the navigation pane, choose Subnets.

3. Select your subnet, choose Subnet Actions,
   Edit IPv6 CIDRs.

4. Choose Add IPv6 CIDR. Specify the hexadecimal pair
   for the subnet (for example, ) and confirm the entry by
   choosing the tick icon.

5. Choose Close.

Alternatively, you can use a command line tool.

To associate an IPv6 CIDR block with a subnet using the command line

• associate-subnet-cidr-block (AWS CLI)

• Register-EC2SubnetCidrBlock (AWS Tools for Windows PowerShell)

Сеть

Добавляем в :

## Public subnet

resource "aws_subnet" "aws-subnet-public" {
  vpc_id            = "${aws_vpc.MyVPC.id}"
  cidr_block        = "${var.vpc_cidr_public}"
  availability_zone = "${var.aws_region}a"
  tags = {
    Name            = "Public subnet"
  }
}

## Private subnet

resource "aws_subnet" "aws-subnet-private" {
  vpc_id            = "${aws_vpc.MyVPC.id}"
  cidr_block        = "${var.vpc_cidr_private}"
  availability_zone = "${var.aws_region}b"
  tags = {
    Name            = "Private subnet"
  }
}

Тут переменных немного больше, но они практически все понятны. Опишу не самые очевидные вещи:

availability_zone — зона доступности от региона отличается наличием индекса (a, b и т.п.)

После этого можно применить изменения и посмотреть, что будет:

$ terraform apply -var-file=terraform.tfvars

Disassociate an IPv6 CIDR block from your VPC or subnet

If you no longer want IPv6 support in your VPC or subnet, but you want to continue
using your VPC or subnet for creating and communicating with IPv4 resources, you
can
disassociate the IPv6 CIDR block.

To disassociate an IPv6 CIDR block, you must first unassign any IPv6 addresses
that are assigned to any instances in your subnet. For more information, see .

To disassociate an IPv6 CIDR block from a subnet using the console

1. Open the Amazon VPC console at
   https://console.aws.amazon.com/vpc/.

2. In the navigation pane, choose Subnets.

3. Select your subnet, choose Actions, Edit IPv6
   CIDRs.

4. Remove the IPv6 CIDR block for the subnet by choosing the cross
   icon.

5. Choose Close.

To disassociate an IPv6 CIDR block from a VPC using the console

1. Open the Amazon VPC console at
   https://console.aws.amazon.com/vpc/.

2. In the navigation pane, choose Your VPCs.

3. Select your VPC, choose Actions, Edit
   CIDRs.

4. Remove the IPv6 CIDR block by choosing the cross icon.

5. Choose Close.

Note

Disassociating an IPv6 CIDR block does not automatically delete any security
group rules, network ACL rules, or route table routes that you’ve configured
for
IPv6 networking. You must manually modify or delete these rules or routes.

Alternatively, you can use a command line tool.

To disassociate an IPv6 CIDR block from a subnet using a command line
tool

• disassociate-subnet-cidr-block (AWS CLI)

• Unregister-EC2SubnetCidrBlock (AWS Tools for Windows PowerShell)

To disassociate an IPv6 CIDR block from a VPC using a command line tool

• disassociate-vpc-cidr-block (AWS CLI)

• Unregister-EC2VpcCidrBlock (AWS Tools for Windows PowerShell)

Configuring Subnets for a VPC

A VPC spans all of the availability zones in a region. You can additionally create one or more subnets in each
availability zone, to increase your fault tolerance within a region and control routing.

By default, the class will allocate a public and a private subnet for each availability zone and evenly
partition traffic amongst each of them. In the event that you do not wish to keep this default, you can override
the behavior using its constructor’s argument.

For example, this program replicates the default behavior but with an explicit specification:

The argument simply takes an array of subnet specifications. Each one can include this information:

• : A required type of subnet to create. There are three kinds available:

  • A subnet is one whose traffic is routed to an
    Internet Gateway (IGW).
  • A subnet is one that is configured to use a
    NAT Gateway (NAT) so that it can reach the internet,
    but which prevents the internet from initiating connections to it.
  • An subnet is one that cannot reach the internet either through an IGW or with NAT.

• : An optional name to use as part of the subnet name. If not provided, the type of the subnet will be
  used. As a result, this is required when making multiple subnets of the same type.

  

  

  

  

  

  

  

  

  

  

• : The number of leading bits in the VPC’s CIDR block to use to define the CIDR for this specific
  subnet. By providing masking bits, this ensures each subnet has a distinct block.

• : A map of name/value pairs to tag the resulting subnet resource with.

There is no restriction on the number of subnets in an availability zone. For example, it might be useful to
have multiple isolated subnets, one for DB instances, and another for Redis instances. To facilitate this sort
of arrangements, we can use the property mentioned above:

By default, the subnet CIDR ranges will be divided as evenly as possible within the VPC. If this isn’t desired,
a particular size for each zone can be requested by passing in an appropriate value between 16 and 28.
This value can be provided for specific subnets you know the number of instances you want IP addresses for. The
remaining IP addresses in the availability zone, if any, will be split over the subnets without a defined size.

Refer to VPCs and Subnets for complete
information about how VPCs and subnets relate in AWS and the configuration options available to you.

Примеры использования

Создавайте проекты быстрееСокращайте время, затраченное на имитационное моделирование Computational Fluid Dynamics (CFD). Масштабируйте задачи по имитационному моделированию, экспериментируя с настраиваемыми параметрами, и быстрее получайте более точные результаты.

Быстрее разрабатывайте лекарственные средстваУскоряйте структурную разработку лекарств благодаря мгновенному доступу к практически неограниченным вычислительным ресурсам. Увеличьте скорость, точность и масштаб виртуального скрининга, квантовой механики, молекулярной динамики и решений со структурой 3D.

Получайте аналитические выводы в геномикеСоздавайте и запускайте приложения для обработки прогнозируемых, ретроспективных данных или данных в реальном времени, чтобы быстрее получать аналитические выводы. Сокращайте время обработки данных с нескольких недель до часов, чтобы вести более подробные исследования таких болезней, как рак, муковисцидоз и болезнь Альцгеймера.

Getting the Default VPC

Often resources like clusters, API gateways, lambdas, and more, will request a VPC object or ID. This ensures
such resources inside of your VPC so network traffic are isolated from other VPCs in your account.

So where do you get such a VPC from? One way is that each AWS account has a default VPC per region. Using the default
VPC is often the easiest path when you’re just getting up and running or don’t yet understand your specific networking
requirements. Most resources will use this default VPC automatically if you leave it unspecified. In other cases,
you may be required to pass it explicitly, in which case you’ll need to get it programmatically.

To get the default VPC, just call the function:

This example reads the default VPC and exports some of its properties for easy consumption. will show:

In this case, the VPC is not created and managed by Pulumi. Instead reads from your AWS account
and returns the VPC metadata. This object can be introspected or passed anywhere an is expected.

Private, Public, and Elastic IP Addresses

Private IP addresses

IP addresses not reachable over the internet are defined as private. Private IPs enable communication between instances in the same network. When you launch a new instance, a private IP address is assigned, and an internal DNS hostname allocated to resolves to the private IP address of the instance. If you want to connect to this from the internet, it will not work. You would need a public IP address for that.

Public IP addresses

Public IP addresses are used for communication between other instances on the internet and yours. Each instance with a public IP address is assigned an external DNS hostname too. Public IP addresses linked to your instances are from Amazon’s list of public IPs. On stopping or terminating your instance, the public IP address gets released, and a new one is linked to the instance when it restarts. For retention of this public IP address even after stoppage or termination, an elastic IP address needs to be used.

Elastic IP Addresses

Elastic IP addresses are static or persistent public IPs that come with your account. If any of your software or instances fail, they can be remapped to another instance quickly with the elastic IP address. An elastic IP address remains in your account until you choose to release it. A charge is associated with an Elastic IP address if it is in your account, but not allocated to an instance.

As a part of our AWS VPC tutorial, let us learn about subnets.

Setting Up a New VPC

Although using the default VPC is easy, it’s often not suitable for production. By setting up a dedicated VPC,
we can isolate workloads from existing ones, and have more control over subnet configuration, routing, and
controlling ingress and egress security rules.

To set up a new VPC, allocate a new object. This class offers a number of options, ranging from
simple defaults that many will want to start with, to complete control over everything VPC has to offer.

The following code creates a new VPC using all default settings:

If we run , the VPC and its supporting resources will be provisioned:

If unspecified, this VPC will use the following defaults:

• An IPv4 CIDR block of .
• The first availability zones inside of your region.
• A public and private subnet per availability zone.
• Equally partitioned CIDR address spaces per subnet (per availability zone).
• A NAT Gateway and EIP per private subnet.
• A single Internet Gateway for all public subnets to use.

The following sections show how to explicitly manage any or all of these settings.

MACsec

Вопрос. Заменяет ли MACsec другие технологии шифрования, которыми я сейчас пользуюсь для своей сети?

MACsec не является заменой какой-либо определенной технологии шифрования. Для простоты и для укрепления безопасности вам следует продолжать пользоваться теми технологиями шифрования, которыми вы уже пользуетесь. Мы предоставляем MACsec как технологию шифрования, которую можно интегрировать в вашу сеть в дополнение к другой технологии шифрования, которой вы пользуетесь.

Вопрос. Какой тип подключений AWS Direct Connect поддерживает MACsec?

MACsec поддерживается выделенными подключениями Direct Connect 10 Гбит/с и 100 Гбит/с в выбранных точках присутствия. Для работы MACsec ваше выделенное подключение должно быть прозрачным для трафика уровня 2. Если вы пользуетесь услугами партнера по подключению «последней мили», убедитесь, что это подключение может поддерживать MACsec. MACsec не поддерживается на выделенных или любых размещенных подключениях скоростью 1 Гбит/с.

Вопрос. Требуется ли специальное оборудование для использования MACsec?

Да. Вам понадобится устройство с поддержкой MACsec на вашей стороне Ethernet-подключения к расположению Direct Connect. Чтобы проверить поддерживаемые операционные режимы и необходимые возможности MACsec, см. раздел Безопасность MAC нашего Руководства пользователя.

Вопрос. Нужно ли мне новое подключение AWS Direct Connect для использования MACsec с устройством, которое поддерживает MACsec?

Для MACsec требуется, чтобы ваше подключение заканчивалось на устройстве с поддержкой MACsec на стороне Direct Connect. Чтобы проверить, поддерживает ли ваше текущее подключение шифрование MACsec, воспользуйтесь Консолью управления AWS или с помощью API Direct Connect DescribeConnections. Если ваше текущее подключение MACsec не завершается на устройстве с поддержкой MACsec, то вы можете запросить новое подключение с поддержкой MACsec с помощью Консоли управления AWS или API CreateConnection.

Вопрос. Какие наборы шифров MACsec вы поддерживаете?

На данный момент мы поддерживаем набор шифров GCM-AES-XPN-256.

Вопрос. Почему вы поддерживаете только 256-разрядные ключи?

Мы поддерживаем только 256-разрядные ключи MACsec для обеспечения современной защиты данных на наивысшем уровне.

Вопрос. Требуется ли использовать расширенное нумерование пакетов (XPN)?

Да, мы требуем использования XPN. Высокоскоростные подключения, например выделенные подключения со скоростью 100 Гбит/с, могут быстро истощить исходное 100-разрядное пространство номеров MACsec, что приведет к необходимости ротации ключей шифрования каждые несколько минут для установки новой связи для подключения. Чтобы избежать такой ситуации, в изменении IEEE Std 802.1AEbw-2013 введена расширенная нумерация пакетов, в которой пространство номеров увеличено до 64 разрядов, что смягчает требования к ротации ключей.

Вопрос. Поддерживается ли использование идентификатора безопасного канала (SCI)?

Да. Мы требуем, чтобы SCI был включен. Эту настройку изменить невозможно.

Вопрос. Поддерживаете ли вы сдвиг тега IEEE 802.1Q (Dot1q/VLAN)/dot1q-in-clear?

Нет, мы не поддерживаем перенос тега VLAN за пределы зашифрованной полезной нагрузки.

Unshare a shared subnet

The owner can unshare a shared subnet with participants at any time. After the owner

unshares a shared subnet, the following rules apply:

• Existing participant resources continue to run in the unshared subnet.

• Participants can no longer create new resources in the unshared subnet.

• Participants can modify, describe, and delete their resources that are in the
  subnet.

• If participants still have resources in the unshared subnet, the owner cannot delete
  the shared subnet or the shared-subnet VPC. The owner can only delete the subnet or
  shared-subnet VPC after the participants delete all the resources in the unshared
  subnet.

To unshare a subnet using the console

1. Open the Amazon VPC console at
   https://console.aws.amazon.com/vpc/.

2. In the navigation pane, choose Subnets.

3. Select your subnet and choose Actions, Share
   subnet.

4. Choose Actions, Stop sharing.

To unshare a subnet using the AWS CLI

Use the disassociate-resource-share command.

Create a VPC

Follow the steps in this section to create a VPC using the Amazon VPC console.

To create a VPC using the console

1. Open the Amazon VPC console at
   https://console.aws.amazon.com/vpc/.

   

   

   

   

   

   

   

   

   

   

2. In the navigation pane, choose Your VPCs,
   Create VPC.

3. Specify the following VPC details as needed.

   • Name tag: Optionally provide a name for your
     VPC. Doing so creates a tag with a key of and the
     value that you specify.

   • IPv4 CIDR block: Specify an IPv4 CIDR block
     (or IP address range) for your VPC. Choose one of the following
     options:

     • IPAM-allocated IPv4 CIDR
       block: If there is an Amazon VPC IP Address
       Manager (IPAM) IPv4 address pool available in this Region,
       you can get a CIDR from an IPAM pool. If you select an IPAM
       pool, the size of the CIDR is limited by the allocation
       rules on the IPAM pool (allowed minimum, allowed maximum,
       and default). For more information about IPAM, see What is IPAM? in the Amazon VPC IPAM User Guide.

     • IPv4 CIDR manual input:
       Manually input an IPv4 CIDR. The CIDR block size must have a
       size between /16 and /28. We recommend that you specify a
       CIDR block from the private (non-publicly routable) IP
       address ranges as specified in RFC
       1918; for example, , or
       .

       Note

       You can specify a range of publicly routable IPv4
       addresses. However, we currently do not support direct
       access to the internet from publicly routable CIDR
       blocks in a VPC. Windows instances cannot boot correctly
       if launched into a VPC with ranges from
       to
       (Class D and Class E IP
       address ranges).

   • IPv6 CIDR block: Optionally associate an IPv6 CIDR block with your
     VPC. Choose one of the following options, and then choose
     Select CIDR:

     • IPAM-allocated IPv6 CIDR
       block: If there is an Amazon VPC IP Address
       Manager (IPAM) IPv6 address pool available in this Region,
       you can get a CIDR from an IPAM pool. If you select an IPAM
       pool, the size of the CIDR is limited by the allocation
       rules on the IPAM pool (allowed minimum, allowed maximum,
       and default). For more information about IPAM, see What is IPAM? in the Amazon VPC IPAM User Guide.

     • Amazon-provided IPv6 CIDR block: Requests an IPv6 CIDR block
       from Amazon’s pool of IPv6 addresses. For Network
       Border Group, select the group from which
       AWS advertises IP addresses. Amazon provides a fixed IPv6
       CIDR block size of /56. You cannot configure the size of the
       IPv6 CIDR that Amazon provides

     • IPv6 CIDR owned by me: (BYOIP) Allocates an IPv6 CIDR block from your
       IPv6 address pool. For Pool, choose the
       IPv6 address pool from which to allocate the IPv6 CIDR
       block.

   • Tenancy: Select a tenancy option. Dedicated
     tenancy ensures that your instances run on single-tenant hardware.
     For more information, see Dedicated
     instances in the
     Amazon EC2 User Guide for Linux Instances.

   • (Optional) Add or remove a tag.

     Choose Add tag and do the
     following:

     • For Key, enter the key name.

     • For Value, enter the key
       value.

     Choose Remove to the right of the tag’s Key and
     Value.

4. Choose Create.

Alternatively, you can use a command line tool.

To create a VPC using a command line tool

• create-vpc
  (AWS CLI)

• New-EC2Vpc
  (AWS Tools for Windows PowerShell)

To describe a VPC using a command line tool

• describe-vpcs
  (AWS CLI)

• Get-EC2Vpc
  (AWS Tools for Windows PowerShell)

For more information about IP addresses, see IP Addressing in your VPC.

After you’ve created a VPC, you can create subnets. For more information, see
.

Overview

Pulumi Crosswalk for AWS provides simple, out of the box VPC functionality that follows widely accepted best
practices. This ensures you can provision and evolve your VPCs across many environments productively and safely,
without needing to recreate the same VPC templates for every new project you tackle.

Using these capabilities, you can control the entire virtual network and restrict access to just those network
endpoints that require it. These network resources are essential to configuring many of the other Crosswalk AWS
components, including ECS and EKS clusters, API gateways, and various network load balancing options.

Each account has a default regional network and VPC to make it easy to get up and running. Most production
circumstances call for dedicated VPCs and network isolation. This includes multi-tenanted scenarios where VPCs can be
used for strong network isolation between endpoints and resources that are otherwise sharing an AWS account.

Структура неймспейсов в K8S кластере

На этой схеме указаны неймспейсы, которые используются в кластере, и ресурсы, которые находятся в этих неймспесах по умолчанию.

Используемые в кластере чарты, с указанием неймспейса и коротким описанием.

Namespace	service	Description
kube-system	core-DNS	DNS сервер, используемый в кластере
certmanager	cert-manager	Cервис для автоматизации управления и получения сертификатов TLS
certmanager	Ресурс, представляющий центр сертификации, который может генерировать подписанные сертификаты, выполняя запросы подписи.
ing	nginx-ingress	Ингресс контролер, который использует nginx в качестве реверс прокси.
ing	Объект сертификата, который используется для nginx-ingress.
dns	external-dns	Сервис для организации доступа к внешним DNS из кластера.
ci	Гитлаб раннер используемый для запуска агентов gitlab-ci.
sys	aws-node-termination-handler	Сервис для контроля корректного завершения работы EC2.
sys	autoscaler	Сервис, который автоматически регулирует размер k8s кластера в зависимости от требований.
sys	kubernetes-external-secrets	Сервис для работы с внешними хранилищами секретов, такими как secret-manager, ssm parameter store и тд.
sys	Reloader	Сервис, который следит за изменения внешних секретов и обновляет их в кластере.
monitoring	kube-prometheus-stack	Зонтичный чарт включает в себя группу сервисов, используемых для мониторинга работы кластера и визуализации данных.
monitoring	loki-stack	Зонтичный чарт включает в себя сервис сбора логов контейнеров и визуализации данных.
elk	Зонтичный чарт включает в себя группу сервисов, для сбора логов, метрик и визуализации этих данных.

Billing and metering for the owner and participants

In a shared VPC, each participant pays for their application resources including Amazon
EC2
instances, Amazon Relational Database Service databases, Amazon Redshift clusters,
and AWS Lambda functions. Participants also
pay for data transfer charges associated with inter-Availability Zone data transfer,
data
transfer over VPC peering connections, and data transfer through an AWS Direct Connect
gateway. VPC
owners pay hourly charges (where applicable), data processing and data transfer charges
across
NAT gateways, virtual private gateways, transit gateways, AWS PrivateLink, and VPC
endpoints.
Data transfer within the same Availability Zone (uniquely identified using the AZ-ID)
is free
irrespective of account ownership of the communicating resources.

Execution

The article is basically a continuation of my recent blog on VPC as over there we setup a VPC with a public and private subnet, attached a IGW to a public subnet route and successfully installed & accessed an apache url over the internet. But we haven’t access the private subnet instance !

So, in short below is what we have till now.

• Create a VPC , by default a route table/NACL were created with a VPC.
• Create 2 Subnets i.e. 1 Public and 1 Private under custom VPC. Assign CIDR block.
• Update “AutoAssignPublicIP” check for public subnet to Yes as same is set to No (by default) for all custom created subnets.
• Associate created subnet with Custom vpc.
• Associate route with VPC (create a separate private route for private subnet).
• Create and attach a IGW to VPC for Public Subnet.
• Create security groups.

So, assuming our setup is arranged as per above, we now move on a bit further to create an instance in a private zone and then follow some basic steps to access private instance via public instance but that is directly through the local machine.

Setting Up a New VPC the Hard Way

The component encapsulates a lot of details, including subnets, route tables, gateways, in addition to
the VPC resource itself. The package, on the other hand, out of which is built, provides all of these
raw resource so that you can code directly to the underlying AWS resource types, exposing every underlying capability.

For information about configuring each of these resources, refer to each type’s API documentation:

• Vpc
• Subnet
• InternetGateway
• NatGateway
• SecurityGroup

These resources can be independently allocated, just as with the class shown above. They will need to be
connected together manually, however, which can provide greater flexibility but at a greater implementation cost.

Note that the constituent parts, in the form of these raw resources, are available as properties on the
resulting class. For instance, will return the Internet Gateway object for a VPC.

Associate a secondary IPv4 CIDR block with your VPC

You can add another IPv4 CIDR block to your VPC. Ensure that you have read the applicable
.

After you’ve associated a CIDR block, the status goes to .
The CIDR block is ready to use when it’s in the
state.

The Amazon Virtual Private Cloud Console provides the status of the request at the
top of the
page.

To add a CIDR block to your VPC using the console

1. Open the Amazon VPC console at
   https://console.aws.amazon.com/vpc/.

2. In the navigation pane, choose Your VPCs.

3. Select the VPC, and then choose Actions, Edit
   CIDRs.

4. Choose Add new IPv4 CIDR. Enter the CIDR block;
   for example, . Choose Save.

5. Choose Close.

To add a CIDR block using a command line tool

• associate-vpc-cidr-block (AWS CLI)

• Register-EC2VpcCidrBlock (AWS Tools for Windows PowerShell)

After you’ve added the IPv4 CIDR blocks that you need, you can create subnets. For
more information, see .

Партнеры по программе AWS Partner Network Competency в сфере высокопроизводительных вычислений

Партнеры по программе AWS Partner Network Competency в сфере высокопроизводительных вычислений помогают клиентам ускорить внедрение цифровых инноваций в различных областях высокопроизводительных вычислений: высокопроизводительных решателей, вычислений с высокой пропускной способностью, управлению высокопроизводительными рабочими нагрузками и базовой технологии высокопроизводительных вычислений. Партнеры по программе AWS Partner Network Competency в сфере высокопроизводительных вычислений предоставляют гибкие и экономически эффективные технологические продукты для высокопроизводительных вычислений на AWS с поддержкой геномики, вычислительной химии, отработки сейсмических данных, компьютерного моделирования, а также развивающихся приложений, таких как глубокое обучение и автономные автомобили.

Create a subnet in your VPC

To add a new subnet to your VPC, you must specify an IPv4 CIDR block for the
subnet from the range of your VPC. You can specify the Availability Zone in which
you want the subnet to reside. You can have multiple subnets in the same
Availability Zone.

You can optionally specify an IPv6 CIDR block for your subnet if an IPv6 CIDR
block is associated with your VPC.

To create the subnet in a Local Zone, or a Wavelength Zone, you must enable the Zone.
For
information about how to enable Wavelength Zones, see in the Amazon EC2 User Guide for Linux Instances.

To add a subnet to your VPC using the console

1. Open the Amazon VPC console at
   https://console.aws.amazon.com/vpc/.

2. In the navigation pane, choose Subnets, Create
   subnet.

3. Specify the subnet details as necessary and choose Create.

   • Name tag: Optionally provide
     a name for your subnet. Doing so creates a tag with a key of
     and the value that you specify.

   • VPC: Choose the VPC for which
     you’re creating the subnet.

   • Availability Zone: Optionally choose a Zone in which your subnet
     will reside, or leave the default No Preference
     to let AWS choose an Availability Zone for you.

     For information about the Regions and Zones, see in the Amazon EC2 User Guide for Linux Instances.

   • IPv6-only: Specify if this subnet should be an IPv6-only subnet. This
     option is only available if the subnet is in a VPC with an IPv6 CIDR
     block assigned. If you choose this option, you will not define an
     IPv4 CIDR block range for the subnet. Any EC2 instances launched in
     this subnet will given an IPv6 address only, not an IPv4 address. To
     launch an EC2 instance into an IPv6-only subnet, you must use .

   • IPv4 CIDR block: Specify an IPv4 CIDR block for your
     subnet, for example, . For more information,
     see . If you chose IPv6-only, this option is unavailable.

   • IPv6 CIDR block: If you’ve associated an IPv6 CIDR
     block with your VPC, choose Custom IPv6 CIDR.
     Specify the hexadecimal pair value for the subnet, or leave the
     default value. If you chose IPv6-only, choose
     an IPv6 CIDR block.

4. (Optional) If required, repeat the steps above to create more subnets in
   your VPC.

Alternatively, you can use a command line tool.

To add a subnet using a command line tool

• create-subnet
  (AWS CLI)

• New-EC2Subnet
  (AWS Tools for Windows PowerShell)

After you create a subnet, you can do the following:

• Configure your routing. To make your subnet a public subnet, you must attach an internet
  gateway to your VPC. For more information, see . You can then create a custom route table, and add route to the internet
  gateway. For more information, see . For other routing options, see Route tables for your VPC.

• Modify the subnet settings to specify that all instances launched in
  that subnet receive a public IPv4 address, or an IPv6 address, or both.
  For more information, see .

• Modify the subnet settings to change resource-based name (RBN) settings. For more
  information, see .

• Create or modify your security groups as needed. For more information,
  see Security groups for your VPC.

• Create or modify your network ACLs as needed. For more information,
  see Network ACLs.

• Share the subnet with other accounts. For more information, see .