DEV Community: Dennis Groß (he/him)

Beginners Guide to AWS VPCs

Dennis Groß (he/him) — Sat, 24 Dec 2022 19:00:00 +0000

A Virtual Private Cloud is a dedicated network in your AWS account that you can use to deploy private AWS services like EC2. VPCs are isolated networks that are deployed into an AWS region and can use all availability zones of that region.

A VPC consists of

Subnets
Routing tables that are associated with subnets
NAT gateways
An internet gateway

Each AWS Region comes with a default VPC which has one public subnet which can be accessed from the internet and route requests out to the internet.

VPC Router

Every VPC has a VPC router that handles the routing between subnets, Internet Gateway, and NAT Gateway. The +1 address in each subnet is reserved for the router.

The router uses Route Tables that are defined on a per subnet type basis and concrete subnet instances in an availability zone use a Route Table Association to identify their rout table.

Network Address Translation (NAT)

NATs map local devices to a public IPv4 address. A request from the internet to a local network device (with a private IPv4) passes the NAT Gateway which then maps the private IPv4 of the device to a public IPv4 that the NAT maintains.

This can be done in three different modes

Static NAT
Dynamic NAT
PAT

Static NAT

Each device with its local, private IPv4 address gets mapped to one static public IPv4 address. So there is a 1:1 relationship between local device IPs and public NAT gateway IPs.

The AWS Internet Gateway operates in the Static NAT mode.

Dynamic NAT

The NAT gateway maintains a list of public IPv4 addresses. Each request from/to a local device gets mapped to one of the available public IPs. So there is no static public IP provided for each device, the IP changes on a per-request basis.

PAT

PAT stands for Port Address Translation and maps multiple local device IPs to the same public IP through ports. The NAT gateway associates a port on the public IP to a local device IP on a per-request basis.

This means that local devices are not directly reachable from the internet since they get associated with a different port for each request.

The AWS NAT Gateway operates in this mode.

VPC CIDR

The VPC CIDR defines the network range that the VPC spans. This range must be private and can be

/28 at minimum (16 IPs, 14 usable)
/16 at most (65536 IPs, 65534 usable)

A good range that you can use are 10.x.x.x/y CIDRs but try to avoid 10.0.x.x/y and 10.1.x.x/y since those are very popular ranges.

You should plan your VPC CIDRs beforehand and estimate how many regions in an account you want to use. Choose VPC CIDRs that do not overlap in the same organization and give yourself a buffer of 2-3 extra CIDR ranges in case your business use case grows.

E.g. calculation:

5 AWS accounts * (4 used regions + 2 Buffer) = 30 CIDR ranges

CIDR Sizes

Micro	/24	216 IPv4
Small	/21	2008 IPv4
Medium	/19	8152 IPv4
Large	/18	16344 IPv4
X-Large	/16	65456 IPv4

Subnetting

A subnet is a smaller network within the VPC and can vary in

How it can be accessed from outside of the internet
How it can access the internet

You divide a VPC into subnets by providing the subnet a sub-range of the VPC CIDR.

So it is important to choose an appropriate CIDR range for your VPC in the first place to house all of your subnets. A subnet should have enough IPs to house all of the AWS services that you need to deploy into your VPC while leaving a proper buffer.

It is also important to keep in mind that each subnet can only use count(subnet_cidrs) - 2 IPv4 of the subnet CIDR since

The first IPv4 …
The last IPv4 …

Three-Tier Application

The Three - Tier Application is a VPC best practice that breaks a VPC into three subnets

Web Tier - public subnet for frontend applications and public APIs
Computing Tier - private subnet for private backend services
Data Tier - private subnet for data services

Finding the correct Subnet Structure

The Three-Tier Application VPC structure is always a good starting point, but it makes sense to add a fourth spare subnet in case your business use case grows. It is quite difficult to resize VPCs once they are housing productive workloads so you should think ahead and be more generous with the number of subnets you provide.

Availability Zones

VPC subnets are deployed into availability zones, which means you need to provide a CIDR range for each subnet per availability zone. It is a good practice to go with 3 availability zones as a standard but keep a CIDR range for a potential 4th availability zone in reserve.

Internet Gateway

The Internet Gateway can provide static, public IPv4 addresses to resources deployed in a VPC subnet that route directly to the Internet Gateway (Static NAT). So resources within those subnets have a public IP address attached and can be accessed from the internet.

The Internet Gateway service runs in the AWS public zone and

Region resilient

NAT Gateway

The NAT Gateway uses the Port Address Translation (PAT) mode to temporarily map a VPC subnet resource (that routes to the NAT Gateway) to a port on the NAT Gateway public, static IPv4 address.

A NAT Gateway must be

deployed to a public subnet (a subnet that routes to an Internet Gateway)
have an elastic IPv4 address (EIP)

Resources behind NAT Gateways cannot be accessed from the internet but can send requests out to the internet.

Each HTTP request that goes to the internet needs to go through a public IPv4 address. A TCP/UDP request has a source and destination IP address as well as a source and destination port. In the case of HTTP, these outgoing requests have an ephemeral source port that can only be reached from the internet resource that you call for the HTTP response.

The NAT Gateway provides an ephemeral source port to the elastic IP address attached to it for each request coming from a device in the private subnet. So outgoing internet requests are possible because internet resources can respond in the same request to the epihermal source port on the elastic IP address.

Subsequent requests from outside the internet to the epihermal port are not successful because the ephemeral ports are assigned on a per-request basis.

Routing Tables

A routing table contains route entries and tells each CIDR whether

it needs to go through the next router, called “next hop”
can reach the requested resource in the network of this routing device

e.g.

10.0.0/16	Local
0.0.0.0/0	igw-12345678901234567

The table above tells the routing device that incoming requests that target an IPv4 within the 10.0.0/16 CIDR remain in the Local network.

The loopback address 0.0.0.0/0 is set to the Internet Gateway. That address basically matches all IPv4 addresses and routing tables use rules with the loopback address with the lowest priority. This makes sure that all requests that do not match any rule in the table get redirected to the Internet Gateway.

Routing tables prioritize rules with more specific CIDR ranges over less specific ones. A CIDR range is more specific if it targets a smaller IPv4 range, so when the network mask value is higher. 0 is the lowest network mask and matches all IPv4 addresses, so it has the lowest priority.

Route Associations

You typically have multiple subnets spread across availability zones in your region and it would be tedious if you have to define one routing table for each subnet. After all, a subnet needs a routing table to define how incoming/outgoing requests get routed.

You can define one or multiple routing tables in your VPC configuration and then create one route association per subnet which makes it unnecessary to define a separate routing table for each subnet.

You should create multiple routing tables if you have different types of subnets like

public subnets
private subnets
private, isolated subnets

Thus, you define a routing table for each subnet type instead of each individual subnet. you then associate the routing table with the corresponding subnet, e.g. a private subnet instance gets associated with the private subnet routing table.

Subnets

Subnets are smaller parts of the VPC network that underly specific routing rules, provided through the associated Routing Table.

Public Subnets

A public subnet has a direct route to an internet gateway which attaches a public IPv4 to each resource ENI deployed to the subnet.

An External Network Interface (ENI) represents a virtual network card and is a bridge between actual AWS resources such as an EC2 instance and your VPC subnets. Requests to an AWS resource actually get targeted to its ENI which proxies the request to the resource.

Resources should only be deployed to a public network if they purposely should be reachable from the internet. This is necessary e.g. necessary for frontend applications or public APIs. Private APIs or DBMS on the other side should never be deployed in a public network so they do not receive a public IPv4 address.

Private Subnets

Private subnets do not route directly to the Internet Gateway and thus do not receive a static public IPv4 address. A private subnet can communicate to the internet by routing through a NAT Gateway to the Internet Gateway.

The NAT Gateway binds a resource from the private subnet to a port on the public static IPv4 (PAT) so resources in the private subnets can receive responses from websites that they may call from inside the VPC.

Private Isolated Subnets

Private isolated subnets are private subnets that have no route to a NAT Gateway and thus cannot reach the internet, nor can be reached from the internet.

This type of subnet is used to house critical infrastructure like managed data services such as RDS which do not need to communicate to the internet. In fact, it is a security advantage that the resources in this subnet cannon communicate to the internet. Otherwise, an attacker could transfer data out of the VPC upon compromising the isolated subnet.

High Availability in VPCs

Subnet instances are deployed into availability zones.

It is a good practice to deploy subnets into at least three AZs if the system is productive or only one AZ for SDLC or staging. Each CIDR range of subnets deployed in the AZs must not overlap and there is a cost of transferring data cross-az.

This makes the multi-az setup costly for staging and SDLC accounts.

VPC Configuration Flags

tenancy - defines where resources in the VPC get deployed to

default - uses shared resources
dedicated - uses dedicated hardware resources (premium price)

enableDnsHostnames - gives service instances in your subnets hostnames

enableDnsSupport - enables DNS resolution for resources in your DNS (Route53)

AWS IAM roles in Terraform

Dennis Groß (he/him) — Fri, 23 Dec 2022 19:00:00 +0000

IAM roles can be created with the aws_iam_role resource identifier. Other resources such as EC2 instances can assume these roles.

Content

`aws_iam_role` Resource

resource "aws_iam_role" "instance_profile" {
  name = "web-server-instance-profile"
  path = "/"

  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Action = "sts:AssumeRole",
        Principal = {
          Service = "ec2.amazonaws.com"
        },
        Effect = "Allow",
        Sid    = ""
      },
    ]
  })
}

The example above contains an IAM role with a role policy that allows the AWS EC2 service to assume another role. the concept of assuming another role through a role is called “role chaining”.

The aws_iam_role has the following attributes (non-exhaustive listing)

name (optional) - the name of the role as it will appear in the IAM console
path (optional) - groups roles into a common namespace path (to keep a better overview of your roles)
assume_role_policy (required) - controls what or who can assume this role (principal). This policy is also known under the term “trust policy”
managed_policy_arns (optional) - list of AWS managed policies that you can attach to this role
inline_policy (optional) - provides you the possibility to write a policy that is directly attached to the role.
policy (required) - references a policy document resource that gets attached to the role

Trust Policies

Every IAM role must specify a trust policy (assume_role_policy) as mentioned in the last bullet section.

The trust policy defines who can assume a particular role through the AWS Secure Token Service (STS). The entity that can assume the role is called a principal.

Principals can be

IAM users
AWS resources (by ARN)
Other roles (→ “role chaining”)
Entire services (e.g. “ec2.amazonaws.com”

Inline Policies

An inline policy is a policy document that is directly attached to an IAM role and does only exist in the context of this role.

It is a best practice to define IAM policies as dedicated resources if they can be re-used in the context of e.g. other roles. But it is ok to define inline policies if you know that the policy only makes sense in the context of a specific role.

Managed Policies

AWS provides predefined policy documents for common use cases like using the Cloud Watch Agent in an EC2 instance.

resource "aws_iam_role_policy_attachment" "smm_policy_attachment" {
  role       = aws_iam_role.instance_profile.name
  policy_arn = "arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore"
}

The code above attaches the managed policy "arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore" to the AWS instance profile role of an EC2 instance. The policy provides basic permissions to the AWS Systems Manager which we need to use the AWS Session Manager to SSH into the EC2 instance.

Using managed policies can be beneficial since you are using best practices provided by AWS. Inn addition to that, managed policies remove maintenance overhead from you since you don’t have to maintain the policy.

On the other hand, managed policies take control away from you since you cannot fine-tune the permissions that they give.

EC2 Instance Profile

It is a good practice to handle the permissions of an EC2 instance through an IAM role that the instance assumes. This role is called the “instance profile role”.

The EC2 aws_instance resource has an iam_instance_profile attribute that can be used for this.

resource "aws_instance" "web_server" {
  ...
  iam_instance_profile = aws_iam_instance_profile.instance_profile.name
  depends_on = [
    aws_iam_role_policy_attachment.smm_policy_attachment,
    aws_iam_role_policy_attachment.cw_agent_policy_attachment
  ]
    ...
}

The attribute references an IAM role. In our case, it references a role called instance_profile that we create through the aws_iam_role resource identifier.

The EC2 instance and IAM role get married together through the aws_iam_instance_profile that the aws_instance resource references and which on the other hand references the IAM role.

resource "aws_iam_instance_profile" "instance_profile" {
  name = "web-server-instance-profile"
  role = aws_iam_role.instance_profile.name
}

resource "aws_iam_role" "instance_profile" {
  name = "web-server-instance-profile"
  path = "/"

  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Action = "sts:AssumeRole",
        Principal = {
          Service = "ec2.amazonaws.com"
        },
        Effect = "Allow",
        Sid    = ""
      },
    ]
  })
}

resource "aws_iam_policy" "cw_agent_policy" {
  name        = "cw-agent-policy"
  path        = "/"
  description = "policy to alow ec2 instance to push metrics and logs to CloudWatch"

  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Action = [
          "logs:CreateLogGroup",
          "logs:CreateLogStream",
          "logs:PutLogEvents",
          "logs:DescribeLogStreams"
        ],
        Effect = "Allow",
        Resource = [
          "*"
        ]
      }
    ]
  })
}

This only works if you specify a “trust policy” on the IAM role (assume_role_policy).

We used the “ec2.amazonaws.com” service as a trusted principal in this case, but you could be more restrictive by only allowing the web_server EC2 instance as a principal (by the instance ARN).

`jsonencode`

The jsonencode method takes a Terraform object annotation as an argument and converts it to a JSON string that we can use for policy attributes e.g. in the aws_iam_role resource.

It is a good practice to use jsonencode when you specify policies since it makes it possible to define a JSON String policy while having the usual Linter support for Terraform through your IDE.

Compute AWS VPC Subnet CIDRs in Terraform

Dennis Groß (he/him) — Thu, 22 Dec 2022 19:00:00 +0000

Subnetting is the process of dividing a larger network CIDR e.g. 10.0.0.0/16 into smaller subnets e.g. 10.0.1.0/24, 10.0.2.0/24.

A CIDR consists of two parts

the host part of the CIDR
the subnet mask part of the CIDR

The subnet mask is the /16 value behind the CIDR IP and determines how many bits of the IP are host part. The /16 is a short notation for the bit mask 255.255.0.0 which is another short notation for 11111111.11111111.00000000.00000000

Do a logical and with the CIDR IP to find the host part, in our case it is the first half of the IP which determines the stable part of the subnet range. The second half of the IP is a wildcard and refers to the dynamic part of our CIDR IP.

This means that our network defined through 10.0.0.0/16 spans the network 10.0.0.0 - 10.0.255.255 which is around ~65k IPs.

So the network mask determines the amount of IPs spanned over the network. A higher subnet mask refers to a smaller network size.

Subnetting in Terraform

Subnetting is the process of breaking a larger CIDR range down to a smaller subnet CIDRS. E.g. we have a network CIDR 10.0.0.0/16 and break it down to multiple subnets 10.0.0.0/24 , 10.0.1.0/24

This is often necessary for the context of e.g. VPCs in AWS or other cloud providers.

Terraform offers a function called cidrsubnet that makes it possible to calculate subnets based on the

base CIDR - network CIDR that we divide into subnets
netnum - Offset that we use for the subnet
newbits - base CIDR net mask + newbits determines new subnet mask for subnet

resource "aws_subnet" "subnet_computing" {
  vpc_id                  = aws_vpc.main.id
  map_public_ip_on_launch = false

  count      = local.azs_count
  cidr_block = cidrsubnet(var.cidr, var.cidr_offset, count.index + local.computing_offset)
  availability_zone = element(var.availability_zones, count.index)

  tags = {
    Name        = "${var.vpc_name}-subnet-computing-${count.index}"
    Environment = var.environment
  }
}

The example above uses the VPC cidr var.cidr e.g. 10.0.0.0/16 and adds the newbits netmask offset to it 16 + 8 = 24 which results in the new subnet bit mask /24

Finally, we add the netnum which is the current index count.index + the offset local.computing_offset that we already used to compute subnet CIDRs for other AWS VPC subnets.

The result is a subnet CIDR e.g. 10.0.12.0/24 that we use for the VPC subnet.

Using the Terraform cidrsubnet function makes it obsolete to define lists of subnet CIDRs ranges for each subnet that you want to create. You just have to define a base network CIDR range and an newbits value.

How to use Terraform variables

Dennis Groß (he/him) — Wed, 21 Dec 2022 19:00:00 +0000

Variables are used to remove hardcoded config values from your Terraform scripts and can be placed in the same file as the script that you are executing or in a dedicated [variables.tf](http://variables.tf) file (best practice).

You can provide default values to the variables and override them through the CLI or environment variables if you placed the [variables.tf](http://variables.tf) in the root module.

`variables.tf`

You can declare a variable with the variable block inside a *.tf script or in a dedicated [variables.tf](http://variables.tf) file.

variable "vpc_cidr" {
  type = string
  default = "172.31.0.0/16"
}

And then use the variable in another file within the same module.

resource "aws_vpc" "main" {
  cidr_block = var.vpc_cidr
  instance_tenancy = "default"
}

Calling the terraform plan command will use the default value of the vpc_cidr variable.

variables terraform plan

Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols:
  + create

Terraform will perform the following actions:

  # aws_vpc.main will be created
  + resource "aws_vpc" "main" {
      + arn                                  = (known after apply)
      + cidr_block                           = "172.31.0.0/16"
      + default_network_acl_id               = (known after apply)
      + default_route_table_id               = (known after apply)
      + default_security_group_id            = (known after apply)
      + dhcp_options_id                      = (known after apply)
      + enable_classiclink                   = (known after apply)
      + enable_classiclink_dns_support       = (known after apply)
      + enable_dns_hostnames                 = (known after apply)
      + enable_dns_support                   = true
      + enable_network_address_usage_metrics = (known after apply)
      + id                                   = (known after apply)
      + instance_tenancy                     = "default"
      + ipv6_association_id                  = (known after apply)
      + ipv6_cidr_block                      = (known after apply)
      + ipv6_cidr_block_network_border_group = (known after apply)
      + main_route_table_id                  = (known after apply)
      + owner_id                             = (known after apply)
      + tags_all                             = (known after apply)
    }

Plan: 1 to add, 0 to change, 0 to destroy.

Overriding defaults

The value of the variable var.vpc_cidr can be overwritten with the environment or through the CLI.

Override with environment variables

All environment variable overrides need to match the pattern TF_VAR_<var_name> to override a variable.

export TF_VAR_vpc_cidr="0.0.0.0/16"

terraform plan       

Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols:
  + create

Terraform will perform the following actions:

  # aws_vpc.main will be created
  + resource "aws_vpc" "main" {
      + arn                                  = (known after apply)
      + cidr_block                           = "0.0.0.0/16"
      + default_network_acl_id               = (known after apply)
      + default_route_table_id               = (known after apply)
      + default_security_group_id            = (known after apply)
      + dhcp_options_id                      = (known after apply)
      + enable_classiclink                   = (known after apply)
      + enable_classiclink_dns_support       = (known after apply)
      + enable_dns_hostnames                 = (known after apply)
      + enable_dns_support                   = true
      + enable_network_address_usage_metrics = (known after apply)
      + id                                   = (known after apply)
      + instance_tenancy                     = "default"
      + ipv6_association_id                  = (known after apply)
      + ipv6_cidr_block                      = (known after apply)
      + ipv6_cidr_block_network_border_group = (known after apply)
      + main_route_table_id                  = (known after apply)
      + owner_id                             = (known after apply)
      + tags_all                             = (known after apply)
    }

Plan: 1 to add, 0 to change, 0 to destroy.

Override with the CLI

Use the -var <var_name>="<value>" parameter to override a variable with the CLI.

terraform plan -var vpc_cidr="0.0.0.0/16"

Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols:
  + create

Terraform will perform the following actions:

  # aws_vpc.main will be created
  + resource "aws_vpc" "main" {
      + arn                                  = (known after apply)
      + cidr_block                           = "0.0.0.0/16"
      + default_network_acl_id               = (known after apply)
      + default_route_table_id               = (known after apply)
      + default_security_group_id            = (known after apply)
      + dhcp_options_id                      = (known after apply)
      + enable_classiclink                   = (known after apply)
      + enable_classiclink_dns_support       = (known after apply)
      + enable_dns_hostnames                 = (known after apply)
      + enable_dns_support                   = true
      + enable_network_address_usage_metrics = (known after apply)
      + id                                   = (known after apply)
      + instance_tenancy                     = "default"
      + ipv6_association_id                  = (known after apply)
      + ipv6_cidr_block                      = (known after apply)
      + ipv6_cidr_block_network_border_group = (known after apply)
      + main_route_table_id                  = (known after apply)
      + owner_id                             = (known after apply)
      + tags_all                             = (known after apply)
    }

Plan: 1 to add, 0 to change, 0 to destroy.

Use locals with Terraform

Dennis Groß (he/him) — Tue, 20 Dec 2022 19:00:00 +0000

Locals are like variables another tool to avoid hard coding values in terraform scripts and keep the code DRY.

The scope of locals is restricted to the current module and can yield

a hard value like a string, integer etc.
an expression

Locals cannot be passed through the CLI or environment and represent a more permanent, constant value or expression in your code.

Create Locals

Locals can be defined in the locals block and used in the same module.

locals {
  uuidv4 = "4c67baa1-f139-45c0-85d4-451e615ece9a"
  bucket_name = "my-fancy-bucket-${uuidv4}"
}

Use Locals With Ternary Operator

Locals can be used together with the Ternary operator to assign a conditional value to a local variable.

This can be e.g. useful if you want to differentiate the instance count of EC2 instances in a development vs. production environment.

locals {
  ec2_count = var.stage == "production" ? 3 : 1
}

resource "aws_instance" "my_instance" {
  ami           = "ami-005e54dee72cc1d00"
  instance_type = "t2.micro"

  count = local.ec2_count
}

Beginners Guide to EC2

Dennis Groß (he/him) — Tue, 20 Dec 2022 08:45:29 +0000

EC2 Instances

The Elastic Compute Cloud (EC2) provides virtual machines on demand. Most of the AWS services are built using the EC2 service in some capacity, which makes EC2 one of the essential services on AWS.

TL;DR

You can choose from different EC2 instance-type families, the families are specialized into a specific use case like…

general purpose-balanced - offers an average ratio between CPU, memory, and network resources, used for regular services and applications.
compute-optimized - focus on CPU resources, used for CPU-intensive operations such as machine learning algorithms.
memory-optimized - focus on memory, used for services that process a lot of data in memory.
accelerated computing - provides hardware accelerators, used for example in graphics processing or specific kinds of data processing.
storage-optimized - focus on high I/O and throughput on attached volumes, used for databases.

Instances in those families often come in different versions such as T2 and T3. The versions can change different aspects of the instance like…

whether CPU credits are used.
how costs are calculated.
what CPU architecture gets used.

In general, go with the latest version of an instance family, AWS tries to provide the best price/value ratio for the newer versions.

AWS introduced recently the new Graviton2 processors which you can already find in the newer instance families like T4g or M6g. These processors use an ARM architecture and provide the same CPU resources at a reduced cost [compared to the x86 counterparts]. Try to go with the new Graviton2 processors when you can but keep in mind that your application must support ARM.

Virtual Machines

You already read in the intro that EC2 instances are virtual machines, so let me give you a short recap of what virtual machines are. Skip ahead if you are already familiar with the concept of virtualization.

Virtual machines help you to abstract from concrete hardware like…

CPUs
Memory
Hard or Network Disks
Network Resources

The base concept behind virtual machines is to use a pool of hardware resources and to create a flexible number of machines with operating systems based on this resource pool. The hardware used by the machines is shared, but the user of the virtual machine would think that this is a fully functional computer.

Data centers use virtual machines to allocate their hardware resources more flexibly. A physical computer has a fixed set of CPU, memory, disk, and network resources, but a virtual machine on the other hand can be allocated an arbitrary amount of those system resources. The flexibility of the virtualization concept helps data centers to upsell their hardware resources to customers.

EC2 Instance Families

EC2 instances come with a preconfigured set of system resources. AWS categorizes instances by…

vCPU - essentially CPU threads, modern CPUs support hyper-threading so one physical CPU core [roughly] supports two different threads. You can say one vCPU equals half a physical CPU core.
Memory
Storage/Instance Storage - what Storage types can be attached to the EC2 instance, mostly EBS.
Bandwidth - max network throughput in Gbps that the EC2 instance supports.

apart from this, there are also a few metrics that apply only to specific EC2 instance families like…

EBS Bandwidth - max network throughput in Gbps to/from attached EBS volumes. A caveat, every EC2 instance has a fixed IOPS limit which can become a bottleneck if you attach multiple EBS volumes.
CPU Credits - let you perform above your instance vCPU computing capacity for a while until your CPU credits run out. You earn CPU credits when you don’t max out on your instance CPU capabilities. This applies not to all EC2 instances and we tend to call EC2 instances with CPU credits burstable instances.

EC2 instance families target different application use cases with the baseline being “general purpose”. Most of your applications should use general-purpose instances which offer a good balance between CPU, memory, and network bandwidth.

Here is an official listing of all instance families by AWS. I advise you to go with the latest iteration of the instance types which offer you in general a better performance/value proposition.

Instancy Types

An instance family like T3 offers different instance types like t3.nano or t3.medium. We saw already in the blog post that virtual machines consist of system resources that are derived from the hardware resource pool. We also saw why this is a flexible concept, but keep in mind that EC2 instances are virtual machines with a fixed set of system resources.

You can’t scale the system resources of a running virtual machine. You need to terminate an existing instance and start a new one to up or down-scale system resources.

AWS provides you with pre-configured EC2 instances and gives them an instance type label. The t3.nano instance type for example features…

2 vCPUs
0.5 GiB memory
CPU credits
Up to 5 Gbps network transfer

So think about what you want to do with your service or application on EC2. It is a good idea to restrict yourself to the smaller instance types like t3.nano, t3.micro, or t3.small if your application workload runs in a staging or development environment.

Productive EC2 instances can be larger like the t3.large instance and may incur significant costs. EC2 uses a pay-as-you-go model, so you pay per second of usage. You only pay for EC2 instances when they are in the running state, stop the instance and you only pay for attached disk volumes like EBS volumes or EFS.

Burstable Instances

Some instance types like the t3.* instances are burstable, which means that they operate with CPU credits. All EC2 instance types have a fixed amount of vCPUs attached which we call the baseline computation performance of the instance.

Now imagine you run a rather small application on your instance and you decided to go with the t3.small instance type. That instance type is sufficient for your use case but they are a couple of situations when you would need additional computation power…

During the booting procedure of the instance.
On occasional traffic spikes when a lot of people access your application.

AWS provides EC2 CPU credits exactly for such use cases. You can think of CPU credits like a savings account in your bank. Your EC2 instance starts with a full savings account filled with CPU credits. You can pay for additional computation resources with these CPU credits whenever your baseline computation power is not enough and you can do that until your CPU credits run out.

This process happens automatically, EC2 scales your computation performance automatically for the price of some CPU credits when your instance goes through some computation-intensive operations.

Your instance will save CPU credits into your instance “savings account” when your application is not performing above the baseline performance. There is a fixed rate at which you save CPU credits that depends on the instance family.

This is a really awesome mechanism and it demonstrates that AWS puts the customer needs in the center when they design/implement their services.

Instance Lifecycle

An EC2 instance can be in one of 7 different states…

rebooting - restarting the instance while reinitializing the instance.
pending - currently starting the instance.
shutting-down - instance termination in progress.
terminated - instance got removed.
stopping - preparing to be stopped or hibernated.
stopped - workloads on the instance are not
running - workloads are running on the instance.

From all of the states above you only pay for…

running
stopped - if your instance is in hibernation.

Some of you might be confused that instances can be terminated, stopped, or hibernated. You should…

stop instances if you don’t need to access your workloads on the instance but want to keep the EBS volumes attached [to the instance]. You will only be charged for the EBS volumes and not for the instance computing resources.
terminate instances if you want to remove the instance permanently, this will also delete all EBS volumes that specify the delete_on_termination flag.
hibernate instances if you want to stop the instance workloads but you have in-memory data stored on the instance that you don’t want to lose by stopping the instance. EC2 will take a snapshot of your instance memory before hibernation and restores the snapshot when you start the instance again.

I also want to make you familiar with a small technicality when it comes to starting/stopping instances. Stopping and then starting an instance is not the same as restarting an instance.

Stopping an instance followed by a start of the instance keeps the identical instance VM.
Restarting an instance may change the instance VM.

That’s a technical detail and for most of you, it won’t matter whether it is the same VM or not.

EC2 is a zonal service which means that instances are deployed into a specific availability zone. You have to keep in mind that the servers that host your EC2 instances are located in a data center of a specific availability zone. The same is true for EBS volumes. This is the reason why you can only attach EBS volumes to EC2 instances of the same availability zone.

Restarting the EC2 instance might result in another instance from the same availability zone. This is not a problem in 99% of the cases but it becomes an issue when you work with software licenses or communicate directly with the IPv4 addresses of your instance (use CNAMES wherever possible!).

Boot Volume

Every EC2 instance needs a boot volume to install the operating system. In most cases, this boot volume is an attached EBS volume that sets the delete_on_termination . The flag indicates if the EBS volumes get destroyed when you terminate the EC2 instance.

In general, we call EBS volumes that…

terminate with the EC2 instance ephemeral volumes.
do not terminate with the EC2 instance volumes persistent volumes.

I encourage you to use managed data services such as DocumentDB, DynamoDB, or RDS for persistent application data. But there are always exceptions to that equation and you might end up requiring a persistent volume for your application data. Make sure that your EBS volume is delete_on_termination=false if you want to use it for persistent data, and schedule backups for this volume.

Attaching EBS Volumes

EBS volumes other than the boot volume get attached as raw block storage to your EC2 instance so you need to…

format the block storage with a file system like ext4.
create a folder on your operating system that you use as a mount target.
mount the formatted volume to the folder.

You don’t have to ssh into new EC2 instances for this, you can automate the procedure with the EC2 User Data script.

EBS volumes can only be attached to a single EC2 instance (except for io2) and the instance must be from the same region and availability zone.

You still can transfer your EBS volume data to an EC2 instance in another region/availability zone…

Create a snapshot of the EBS volume.
Copy the snapshot to the other region/availability zone.
Create an EBS volume from the snapshot copy in that region/availability zone.
Attach the new EBS volume to the EC2 instance.

You need to take an unencrypted snapshot if you want to transfer the snapshot copy to another region. EBS uses the KMS service to encrypt EBS data at rest and KMS keys are a regional construct, so you can’t easily transfer encrypted data cross-region (at least you won’t be able to decrypt it).

A lot of people are frustrated about such details but this is a great effort by AWS to keep the data integrity of regions.

EFS

The Elastics File System (EFS) offers distributed network file systems that you can attach to EC2 (and other services) which is much easier to work with than EBS. As the name suggests, EFS comes with a network file system that is compliant with the NFS protocol installed so you don’t have to mount/format raw block storage.

But EFS has a premium price compared to EBS. The biggest selling point of EFS is that you can attach it to multiple EC2 instances even cross-az, so you should use those network file systems whenever you work with distributed data….

when you have multiple EC2 instances that need to access the same persistent data source.
when you use high-performance computing operations based on a shared data set.

User Data

Some of you might have worked already with configuration management tools like Ansible which in essence do the same thing as the EC2 User Data script.

You can pass in a set of shell instructions to the User Data script attribute of an EC2 instance. These instructions will be executed upon the initial boot phase of the EC2 instance, so only once. Restarting an instance won’t trigger the User Data script again, only terminating the instance and bootstrapping a new instance would trigger it again (or a reboot).

Use the User Data script to automate…

the installation of system dependencies.
installation and start of the software application or service that you run on your instance.
the formatting and mounting of EBS volumes.

I think you should always strive for full automation, so try to automate any installation, configuration or application start that you need to do in your EC2 instance through the User Data script.

AMIs and Golden AMIs

Amazon Machine Images (AMIs) contain the operating system and a set of pre-configurations that EC2 instances use as a baseline. Any additional configuration on top of the AMI will typically be met by the User Data script.

Amazon offers you a set of bare-bones Linux and windows AMIs that you can use, the most important are…

The hosting world relies mostly on Linux software and operating systems, so I go 99% of the time with the Amazon Linux 2 HVM AMI which is based on a Red Hat Enterprise Linux (RHEL).

Use Windows if you need to work with .NET or proprietary software from Microsoft.

The best thing about AMIs is that you can create your own AMIs. Here is the process for creating a new AMI.

Configure an EC2 instance using a base AMI e.g. Amazon Linux 2.
Start the instance.
Right-click on the instance, “create AMI”

Basically, you create a new AMI based on a running EC2 instance.

AMIs are a regional construct, which means that any AMI that you create from a running EC2 instance will be stored in the region in which the EC2 instance runs. You can copy your AMI to another region which will result in another AMI with another AMI ID.

This becomes very relevant when you use IaC tools like CloudFormation or Terraform.

I recommend you…

create a RegionMap in CloudFormation for your AMIs.
use the Data directive in Terraform to filter for a specific AMI in your region by name.

AMIs that contains everything you need to run your application is also called “Golden AMIs”. You should try to create golden AMIs for your EC2 application wherever possible, they reduce the CPU overhead that you incur in the bootstrapping process of your EC2 instances since you use a preconfigured snapshot of an EC2 instance.

There are a couple of ways to build EC2 AMIs automatically…

with the EC2 Image Builder service.
with the Hashicorp Packer tool.

I go with Packer here. It is easier to write a CI/CD process that creates new golden AMIs with Packer than the EC2 Image Builder but that is only my personal impression.

SSH into EC2 via Session Manager

Having SSH access to EC2 instances can be really useful to try out new configurations before you place them in the User Data script, or to debug an existing configuration.

You could SSH into an EC2 instance with the EC2 Keypair, but the instance must be deployed in a public subnet (a subnet with a direct route to an Internet Gateway) and you must open port 22 for ingress through a security group.

This poses a serious security risk for most EC2 instances, and you should always try to restrict access to instances as much as you can.

If not absolutely necessary, you should try to…

put EC2 instances in private subnets.
restrict access through security groups, especially port 22.

AWS provides a tool called Session Manager that lets you SSH into an EC2 instance through a Cloud Shell. You don’t need to open a port in the security groups for this or deploy the instance in a public subnet. You don’t even need to have access to a specific Keypair.

There are only two requirements for the Session Manager to work…

Install the SSM agent on your EC2 instance. I recommend you do this through the User Data Script.
Provide the EC2 instance with the managed policy "arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore" to communicate with the Systems Session Manager. You can attach this managed AWS policy to your EC2 instance profile role.

You can access the instance now from the AWS console, navigate to the EC2 service, find your instance, right-click, and click on “connect”. You will be redirected to a dialog window, the second tray says “AWS Session Manager”.

You will see a description of how you need to set up the Session Manager on your instance if your instance is not configured properly.

I install the SSM agent on all of my EC2 instances, and I use the Systems Manager exclusively for accessing my Instances via SSH. As a short recap, the System Manager…

Offers SSH access to instances that are deployed in private subnets.
Logs SSH instance access in Cloud Trail, with user ID.
Requires no SSH Keypair on the instance.
Makes it easy to define who can access the instance based on IAM policies rather than SSH Keypairs.

Launch Templates

In DevOps there is a simple equation:

Code + Configuration = Software Release

In an ideal world, you are able to create an immutable code and configuration version. So, you attach a specific code and configuration combination to a semantic version and make sure that this version corresponds always to the same config and code (immutability).

This is very important and ensures that software releases that you tested on a staging environment operate in the same way on a productive system.

This should apply to software running on EC2 instances too!

We can use golden AMIs to fix the software and dependencies running on the EC2 instance but you can still apply variable configuration for…

Instance type & Instance family
Allocated EBS volume
…

Launch Templates solve this issue and create a fixed software release for EC2 instances by assigning a version number to a template with an immutable set of configurations.

You can create a Launch Template from…

An existing EC2 instance - right-click on the instance in the EC2 console and click “Create Launch template”.
Create a new Launch Template from the EC2 instance console.

Summary

I think that was a lot of information to digest, but I always try to understand the technologies and their limitations that I am working with. But we are not done with EC2, there is still a lot you should know if you want to operate EC2 instances successfully and cost-efficient.

I’ll turn this post into a series and add more content.

But first, let’s have a short recap of the most important things we learned.

EC2 instances have different instance families and instance types. An instance family is always geared to a specific use case such as “general purpose” or “memory-optimized”, the instance type on the other hand just defines the scale of the computing resources.
There are 7 different lifecycle states of an EC2 instance. You pay only for running instances and partially for stopped instances in hibernation mode.
EC2 is a zonal service, instances are deployed into a specific availability zone and you can only attach EBS volumes of the same zone.
AMIs contain the operating system and initial configuration to start your EC2 instance. You can create Golden AMIs that contain your application and all dependencies that you need to run the application on EC2.
Launch Templates create an immutable software release on EC2 and consist of a fixed configuration and AMI.
You should use the Session Manager to SSH into instances.
Startup sequences or the installation of dependencies can be automated with the EC2 User Data script.
Some instance families are burstable, which means they offer CPU credits that you can use to temporarily boost your instance's computing performance.

How to configure Provider in Terraform

Dennis Groß (he/him) — Mon, 19 Dec 2022 19:00:00 +0000

Terraform is a multi-cloud viable IaC technology and breaks the functionality to communicate with specific cloud provider APIs (SaaS providers or other APIs) down to providers.

A provider is a logic module that you use to interact with a specific cloud provider like AWS.

Terraform providers can be categorized into community-driven providers and those providers maintained by the Hashicorp team directly.

Specifying a Provider

A provider must be specified in the root module of a Terraform project.

It is a best practice to define the provider in a [providers.tf](http://providers.tf) separate from the actual IaC scripts in the root module. This makes it easier to locate the provider configuration in a Terraform project.

But it is theoretically possible to place a provider configuration in one of the Terraform scripts of the root module.

It is a best practice to expose credentials and configuration values through variables in the provider configuration, so you don’t have to hard code any values or potentially commit them to Github.

AWS Provider

The AWS provider can be configured with a profile or direct technical user credentials through the AWS_SECRET_KEY and AWS_SECRET_ACCESS_KEY .

The provider requires basically two things

your region
credentials for your AWS account (technical IAM user)

Specify Credentials through AWS Profile

Providing the credentials through the ~/.aws/credentials file that stores one or multiple access and secret access keys for AWS profiles is a good practice. You may change the profile in the future or rotate the AWS credentials of the technical users which has an immediate effect on the provider.

This has also the added benefit that you don’t have any hard credential values in your code files.

The Terraform provider config will assume that your AWS credentials file is on path ~/.aws/credentials by default, but you can specify a custom path with shared_credentials_file .

terraform {
  required_providers {
    aws = {
      source = "hashicorp/aws"
      version = "4.41.0"
    }
  }
}

provider "aws" {
  region = "${var.region}"
  profile = "${var.profile}"
}

Specify Credentials directly

You can specify an AWS IAM user directly in the provider configuration through the access_key and secret_key parameters.

Do not hard-code any secrets into the provider config in this case and make sure you use environment variables and declare variables (without default value) for these credentials.

terraform {
  required_providers {
    aws = {
      source = "hashicorp/aws"
      version = "4.41.0"
    }
  }
}

provider "aws" {
  region = "${var.region}"
  access_key = "${var.access_key}"
  secret_key = "${var.secret_key}"
}

The variables in this case can be defined through

the CLI: -var access_key="..." -var secret_key=".."
environment variables: export TF_VAR_access_key="..."; export TF_VAR_secret_key="..."

AWS Best Practices: Three Tier VPC

Dennis Groß (he/him) — Sun, 18 Dec 2022 19:08:59 +0000

The Three Tier VPC is an AWS best practice provides strong network security principles.

TL;DR

Here is the Terraform source code for the VPC that we create in this post

aws-terraform-examples/modules/vpc at master · gdenn/aws-terraform-examples

A Three Tier VPC consists of three different subnet types

Web Subnet - public subnet, assigns public ipv4 addresses to resources in this subnet directly through the Internet Gateway
Computing Subnet - private subnet, cannot be reached from the outside since there is no direct route to the Internet Gateway. This subnet can reach resources from the internet through a Nat Gateway route to the Internet Gateway.
Data Subnet - private isolated subnet, resources in this subnet cannot be reached from the internet and the resources themselves cannot reach out to the internet.

In general use the

Web Subnet for public resources such as Application Load Balancers, frontend Applications, or Lambda functions that you want to make directly accessible from the internet.
Computing Subnet for backing services such as private APIs or frontend applications that you expose through an Application Load Balancer.
Data Subnet for data services and data processing or anything that does not must communicate with external resources on the internet.

Create the VPC

You can create a VPC with the Terraform aws_vpc resource.

resource "aws_vpc" "main" {
  cidr_block           = var.cidr
  instance_tenancy     = "default"
  enable_dns_support   = true
  enable_dns_hostnames = true

  tags = {
    Name        = var.vpc_name
    Environment = var.environment
  }
}

A few things are important here

instance_tenancy defines where VPC resources will be placed and should be set to "default". There is also the "dedicated" option which in the case of EC2 instances will use dedicated instances. Keep this on "default" unless you have a clear use case for "dedicated", otherwise this might cost you a small fortune.
enable_dns_hostnames determines whether your resources will receive CNAMEs from the AWS DNS service, leave this on by default. It makes sense to use CNAMEs instead of hardcoded IPs wherever possible.
enable_dns_support defines whether your VPC resources are supported by the AWS DNS, you should leave this on as well.

You can see that we are using a bunch of variables in this VPC resource. Here is a complete snippet of the [variables.tf](http://variables.tf) content.

variable "environment" {
  type        = string
  description = "environment type (staging/prod/sdlc)"
  default     = "production"
}

variable "cidr" {
  type        = string
  description = "vpc cidr"
  default     = "10.0.0.0/16"
}

variable "cidr_offset" {
  description = "offset that we pass to the cidrsubnet function to build subnets"
  default = 8
}

variable "profile" {
  type    = string
  description = "aws profile"
}

variable "log_group_name" {
  type    = string
  description = "vpc-flow-logs"
}

variable "region" {
  type    = string
  default = "eu-central-1"
}

variable "vpc_name" {
  type    = string
  description = "vpc name"
  default = "test"
}

variable "availability_zones" {
  type = list(string)
  description = "list of availability zones"
  default = ["eu-central-1a", "eu-central-1b", "eu-central-1c"]
}

Every VPC requires you to define a CIDR range which can be a /16 (largest) subnet or a /28 subnet (smallest). The size of your VPC highly depends on the number of resources you want to deploy into it.

Keep in mind that a couple of IPs in each VPC are reserved. Personally, I try to anticipate what I want to do with the VPC in the future. You might deploy some extra resources in 1-2 years, so choose a larger subnet than you need now.

Enable VPC Flow Logs

Flow logs contain top-level meta information of Layer 4 (IP Layer) packages that are transferred in the VPC, it is in general a good practice to enable them and drain them to a CloudWatch Log Group.

They can help you to…

analyze attack vectors when your network got compromised.
debug security group issues with resources.
are useful for intrusion detection.

Here is how you activate the VPC Flow Logs.

resource "aws_flow_log" "vpc_flow_logs" {
  iam_role_arn = aws_iam_role.flow_logs_role.arn
  log_destination = aws_cloudwatch_log_group.vpc_log_group.arn
  traffic_type = "ALL"
  vpc_id = aws_vpc.main.id

}

We need to create (or reuse an existing) Cloud Watch Log Group. I like to have one Log Group per application stack.

resource "aws_cloudwatch_log_group" "vpc_log_group" {
  name = var.log_group_name
}

And an IAM role that gives the VPC permission to push Flow Logs into the Cloud Watch Log Group.

resource "aws_iam_role" "flow_logs_role" {
  name = "flow-logs-role"

  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = {
      Effect = "Allow"
      Principal = {
        Service = "vpc-flow-logs.amazonaws.com"
      }
      Action = "sts:AssumeRole"
    }
  })
}

resource "aws_iam_role_policy" "create_log_group_policy" {
  name = "allow-log-group-policy"
  role = aws_iam_role.flow_logs_role.name

  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Action = [
          "logs:CreateLogGroup",
          "logs:CreateLogStream",
          "logs:PutLogEvents",
          "logs:DescribeLogStreams"
        ],
        Effect = "Allow",
        Resource = [
          "*"
        ]
      }
    ]
  })
}

Public Web Subnet

Resources in the Web Subnet receive static IPv4 addresses and require a direct route to the Internet Gateway.

resource "aws_internet_gateway" "main_igw" {
  vpc_id = aws_vpc.main.id

  tags = {
    Name = "${var.vpc_name}-igw"
  }
}

The Internet Gateway is hosted by AWS in the public zone and is a region resilient service. You don’t have to provide multiple instances of the Internet Gateway to ensure high availability, AWS ensures that there is a sufficient amount of Internet Gateways deployed in your region in case of a failure.

And that’s sufficient since VPCs are regional constructs which means your blast radius with a VPC is at most a region (if you use multiple availability zones for your subnets).

The next thing that we need is a Route Table that routes directly to the Internet Gateway that we provisioned.

resource "aws_route_table" "public_subnet" {
  vpc_id = aws_vpc.main.id

  route {
    cidr_block = "0.0.0.0/0"
    gateway_id = aws_internet_gateway.main_igw.id
  }
}

We also add a few locals before we start with the Web Subnet itself.

locals {
  azs_count = length(var.availability_zones)
  computing_offset = local.azs_count
  data_offset = local.azs_count * 2
}

Always keep your code DRY and use locals to

Avoid code redundancies
Assign complex expressions to local variables with proper names

We create the Web Subnet with the aws_subnet resource.

resource "aws_subnet" "subnet_web" {
  vpc_id                  = aws_vpc.main.id
  map_public_ip_on_launch = true

  count      = local.azs_count
  cidr_block = cidrsubnet(var.cidr, var.cidr_offset, count.index)
  availability_zone = element(var.availability_zones, count.index)

  tags = {
    Name        = "${var.vpc_name}-subnet-web"
    Environment = var.environment
  }
}

The Terraform count operator creates a subnet for each availability zone that we configured in the variables file. Provide a non-overlapping CIDR range for each subnet that you deploy into an availability zone.

The cidrsubnet function from Terraform computes our VPC CIDR for our subnets which makes it obsolete to pass additional subnet CIDR ranges through variables.

Computing Subnet

The next subnet is the Computing Subnet. The subnet is private, resources in the subnet receive no static IPv4 address and are not reachable from the internet. But the resources can communicate with servers that are on the internet.

The subnet is a great fit for internal APIs or resources that you expose through an Application Load Balancer.

resource "aws_subnet" "subnet_computing" {
  vpc_id                  = aws_vpc.main.id
  map_public_ip_on_launch = false

  count      = local.azs_count
  cidr_block = cidrsubnet(var.cidr, var.cidr_offset, count.index + local.computing_offset)
  availability_zone = element(var.availability_zones, count.index)

  tags = {
    Name        = "${var.vpc_name}-subnet-computing-${count.index}"
    Environment = var.environment
  }
}

Notice that we set the map_public_ip_on_launch to false, this option only makes sense if you route directly to an Internet Gateway which is not the case with the computing subnet.

The next thing that we need is a NAT Gateway.

resource "aws_eip" "nat_eip" {
  vpc = true
  depends_on = [aws_internet_gateway.main_igw]
  count = local.subnet_count
}

resource "aws_nat_gateway" "natgw" {
  count = local.subnet_count
  allocation_id = aws_eip.nat_eip[count.index].id
  subnet_id = aws_subnet.subnet_web[count.index].id
  depends_on = [aws_internet_gateway.main_igw]

  tags = {
    Name = "natgw-${count.index}"
    Environment = var.environment
  }
}

The Route Table of the Computing subnet routes requests from resources to the internet through the NAT Gateway and from there to the Internet Gateway.

The NAT Gateway requires a static public IPv4 address which we provide through an Elastic IP (eip). The NAT Gateway does a Port Address Translation (PAT), and resources that communicate to the internet use the NAT Gateway’s public IPv4 address. The NAT Gateway assigns each requesting resource from within the subnet a port.

Resources are not always reachable from the same port, that’s the reason why you can’t request them from the internet.

We need to create a Routing Table, a Route, and a Route Table Association for each subnet to finish the computing subnet.

resource "aws_route" "private_subnet" {
  count = local.subnet_count
  route_table_id = aws_route_table.private_subnet[count.index].id
  destination_cidr_block = "0.0.0.0/0"
  nat_gateway_id = aws_nat_gateway.natgw[count.index].id
}

resource "aws_route_table" "private_subnet" {
  count = local.subnet_count
  vpc_id = aws_vpc.main.id

  tags = {
    Name        = "${var.vpc_name}-private-subnet-route-table-${count.index}"
    Environment = var.environment
  }
}

resource "aws_route_table_association" "subnet_computing_route_table_association" {
  count          = local.azs_count
  subnet_id      = aws_subnet.subnet_computing[count.index].id
  route_table_id = aws_route_table.private_subnet[count.index].id
}

Data Subnet

The last subnet is the Data subnet. Resources in this subnet cannot communicate to the internet and are not reachable from within the internet.

That makes it a perfect fit for data services or services that perform data processing, or in general everything that doesn’t have to communicate to the internet.

Putting your data services into a private, isolated subnet is a security best practice. An attacker that compromises your data service cannot offload data to a malicious server from within the VPC subnet.

We start with the subnet resource again.

resource "aws_subnet" "subnet_data" {
  vpc_id                  = aws_vpc.main.id
  map_public_ip_on_launch = false

  count      = local.azs_count
  cidr_block = cidrsubnet(var.cidr, var.cidr_offset, count.index + local.data_offset)
  availability_zone = element(var.availability_zones, count.index)

  tags = {
    Name        = "${var.vpc_name}-subnet-data-${count.index}"
    Environment = var.environment
  }
}

This subnet does not need a route to the NAT Gateway or Internet Gateway but it is still necessary to provide a Route Table and Route Table Associations for each subnet.

resource "aws_route_table" "private_isolated_subnet" {
  vpc_id = aws_vpc.main.id

  tags = {
    Name        = "${var.vpc_name}-private-isolated-subnet-route-table"
    Environment = var.environment
  }
}

resource "aws_route_table_association" "subnet_data_route_table_association" {
  count          = local.azs_count
  subnet_id      = aws_subnet.subnet_data[count.index].id
  route_table_id = aws_route_table.private_isolated_subnet.id
}

Productive VPC Usage

There are a couple of things that you should do when you create a VPC for productive use

Make sure you have one NAT Gateway per availability zone. NAT Gateway instances will be deployed into your Web subnet, thus they are not a fully-managed solution like the Internet Gateway and you need to make sure that you have multiple instances of them (HA).
Enable VPC Flow Logs and drain them to Cloud Watch.
Use multiple availability zones (at least 3) for your VPC so resources in your VPC can be deployed into multiple zones.
Be a bit more generous with your VPC CIDR range, it is quite tedious to find out that you're VPC is not sufficiently sized. Moving productive resources is quite challenging and VPC peering is also not a walk in the park. So think ahead in regards to your VPC size

The VPC stack from this post has everything that you need for productive use, just make sure that you configure three availability zones in the variable.

Considerations for non-productive Use

There are also a few things that you should be aware of when you use this VPC architecture for non-productive use, mostly in regard to cost-efficiency.

Use at least two availability zones even for non-productive use. Resources like the Application Load Balancer require at least two availability zones to be deployed, regardless of whether it is for productive or non-productive use.
Deploy only one NAT Gateway and associate the NAT Gateway with all Computing subnet Route Tables. NAT Gateway cost you per second that they run and additionally for traffic that it transfers so it is a good idea to limit the amount of NAT Gateway for non-productive use.
Keep in mind that AWS charges you for cross-availability-zone transfer of network data (except for managed solutions). Try to keep your resources deployed in the same AZ so they don’t incur costs for cross-az communication.
Tag your VPC with the environment tag so operators are never in doubt if the VPC is used for productive or non-productive use (the best practice is still to separate via accounts).

Summary

Every AWS cloud engineer should be comfortable with the configuration of a VPC and should know the core components involved.

You will use VPCs for a large percentile of AWS services and misconfiguring it can cause you a lot of trouble in the long run, so take your time and try to understand all components that we used in this post.

Here is a short recap of the things that we learned in this post

Web Subnet - public subnet for public reachable resources such as load balancers or internet-facing APIs and frontend applications.
Computing Subnet - private subnet for resources that need to communicate to the internet but should not be reachable from the internet.
Data Subnet - private, isolated subnet for data services and data processing.
Internet Gateway - provides static, public IPv4 addresses to resources.
NAT Gateway - uses Port Address Translation, routes to the Internet Gateway, and makes sure that resources can communicate to the internet but are not reachable from the internet.

How to use templates in Terraform

Dennis Groß (he/him) — Sun, 18 Dec 2022 14:45:34 +0000

Terraform has a templatefile(path, vars) function that can be used to render the content of a file into a string with variable substitution.

Variable Substitution

The variable substitution has an interpolation syntax using ${..} . So you can reference variables that you passed into the second map argument of the templatefile function.

resource "aws_instance" "web_server" {
  ami           = data.aws_ami.amzn2.id
  instance_type = local.instance_type
  user_data     = templatefile("user-data.sh", {})
    ...
}

The code above renders a shell script as a string without substituting any template variables.

The recommended file format is *.tftpl but the function does not enforce it.

We can pass additional variables from the terraform script to the user data example above.

resource "aws_instance" "web_server" {
  ami           = data.aws_ami.amzn2.id
  instance_type = local.instance_type
  user_data     = templatefile("user-data.sh", { log_group = "test-server" })
    ...
}

#!/bin/bash
sudo chown $USER:$USER -R $cw_agent_config_folder
sudo mkdir -p $cw_agent_config_folder
sudo cat <<EOT >> $cw_agent_config_path
{
  "agent": {
    "metrics_collection_interval": $cw_agent_collection_interval,
    "run_as_user": "root"
  },
  "logs": {
    "logs_collected": {
      "files": {
        "collect_list": [
          {
            "file_path": "$http_access_logs",
            "log_group_name": "${log_group}",
            "log_stream_name": "{instance_id}-access-logs",
            "retention_in_days": $cw_agent_log_retention
          }
        ]
      }
    }
  },
  ...
}
EOT
sudo $cw_agent_ctl -a fetch-config -m ec2 -c file:$cw_agent_config_path -s

The example above shows how you can work both with shell variables and template variables at the same time since the syntax that you use to reference them differs.

For Loop - Lists

Templates can also be used to dry up repeating sections.

This snippet prints “hello world” in 4 different variations.

resource "aws_instance" "web_server" {
  ...
  user_data     = templatefile("hello-world.tfpl", { names = [ "world", "planet" ] })
    ...
}

#!/bin/bash
%{ for name in names }
echo "hello ${name}
%{ endfor ~}

The snippets above render the hello-world.tfpl into a string that contains to echo statements.

echo "hello world"
echo "hello planet"

It is important that we add a shebang into the shell script if we do not use the *.sh file ending (or comparable) but the *.tfpl file ending instead. The shebang instructs the script caller which binary must be invoked for the script execution.

For Loop - Maps

We can also loop through maps.

resource "aws_instance" "web_server" {
  ...
  user_data     = templatefile("hello-world.tfpl", { names = { "firstname": "Max", "lastname": "Fischer" })
    ...
}

#!/bin/bash
%{ for config_key, config_value in names }
echo "hello to ${config_key}: ${config_value}"
%{ endfor ~}

Results of this output

echo "hello to firstname Max"
echo "hello to lastname Fischer"

How to use count in Terraform

Dennis Groß (he/him) — Sun, 18 Dec 2022 14:44:30 +0000

The count meta argument is an alternative to for_each and applies a resource multiple times.

resource "aws_route" "private_subnet" {
  count = local.subnet_count
  route_table_id = aws_route_table.private_subnet.id
  destination_cidr_block = "0.0.0.0/0"
  nat_gateway_id = aws_nat_gateway.natgw[count.index].id
}

The snippet above uses the count meta arg to create multiple private subnets. You need to provide an integer value to the count argument and the resource will be applied according to the value that you choose.

You can combine the count with the length(..) function to get the amount of elements from a list and apply the same amount of resources.

resource "aws_route" "private_subnet" {
  count = length(var.availability_zones)
  route_table_id = aws_route_table.private_subnet.id
  destination_cidr_block = "0.0.0.0/0"
  nat_gateway_id = aws_nat_gateway.natgw[count.index].id
}

This also works with maps when you use the length(..) function on keys or values.

you can access the index value (1,2,…) through count.index which is useful for enumerating resource names or accessing elements with the element(...) function from an array (i.e. array ob CIDR ranges).

Use the count meta argument over for_each if you have a simple resource use case that does no rely on multiple values but only operates with an index value.

How to use Modules in Terraform

Dennis Groß (he/him) — Sun, 18 Dec 2022 14:34:41 +0000

A module makes a set of resources reusable by wrapping it into a package that we can use in the context of different Terraform projects.

In essence, a module is a folder with one or multiple *.tf files that describe resources. There must be at least one *.tf file in the module, the so-called root module.

Module Distribution

There are multiple ways to re-use Terraform from another system

You have the module code checked out nearby, and reference the module directly
The module is available in the Terraform Registry
The module is available in a private registry
- Github
- Bitbucket
- HTTP URLs
- S3 Bucket
- GCS buckets

Referencing Modules from the File System

Here is an example of how we reference the vpc module in a Terraform project relative to the current directory.

module "vpc" {
  source = "../vpc"
}

Using Registry Modules

Using a module from a Terraform registry is quite the same than referencing a module on the local file system.

module "vpc" {
    source = "terraform-aws-module"
    version = "3.14.0"
  # variable values can be passed here
}

This example refers to a module called terraform-aws-module . the biggest difference between local and registry modules is that registry modules are versioned, so you need to provide a version string.

Hosting Modules in Github

You can reference a module from a GitHub repository by URL. This is convenient since most Terraform modules need to be stored in a version control system anyways.

You can checkout GitHub modules in two ways

Through HTTPS
Through SSH

module "vpc" {
    source = "github.com/gdenn/my-vpc"
    # variables values go here
}

Example SSH

module "vpc" {
    source = "git@github.com:gdenn/my-vpc.git"
    # variables values go here
}

You can reference your GitHub credentials in multiple ways

~/.ssh/config set a Host entry and point to your IdentiyFile (SSH key)

Host USERNAME.github.com
    HostName github.com
    User git
    IdentityFile ~/.ssh/id_rsa

Pass the credentials to the source parameter

module "vpc" {
  source = "git::https://${git_username}:${git_password}@github.com/folder/terraform-azure-core-resource-group.git"
  ...
}

Passing Variables

Every module can have a variables file that stores configurable config parameters that the resource scripts might use.

Values for the variables can be passed in the module block.

module "vpc" {
  source = "../vpc"
  profile = var.profile
    region = "eu-central-1"
    ...
}

You can still pass variables through the environment or use the default values.

Provider Configuration

A module can inherit the provider config from the caller module (parent module). Although it is advisable to define a provider with a range of compliant versions.

terraform {
  required_version = ">= 0.13.1"

  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = ">= 4.0"
    }
  }
}

Terraform will try to use a pre-installed provider version (e.g. used by another module or the parent) if it fits the version constrained by this child module.

In many cases, this might prevent the installation of an unnecessary additional provider and ensures that the module uses a provider this is compatible.

10 Reasons Why You Should use Docker

Dennis Groß (he/him) — Sun, 18 Dec 2022 13:44:07 +0000

One of the most popular container technology providers Docker registers in February 2022 a record breaking 15+ million active users per month.

The success of Docker is a testament to the impact that container technologies have on the entire IT landscape.

But what causes more and more developers and organisations to move their applications and services into the container?

This blog post will explain the fundamental concepts of container technologies and show you 10 reasons that make container technologies attractive for you.

What is a Container?

Containers are small packages that contain software in a runnable software environment. You can use those packages to ship software to any computer or virtual machine (VM) that supports a container runtime like Docker.

The idea behind containers is the virtualisation of the operating system. Containers are processes that disguise themselves as operating systems. Container looks like an operating system for applications that run inside the container. But they are in reality processes that run on top of an existing operating system. They share system resources such as disk, memory and network with the host operating system.

Container Images

The container image is a file format that we use to specify to a container runtime how a container process should start. It contains a set of top-down instructions that the container runtime carries out when we start a container.

The file format to specify a container image in the Docker ecosystem is called a Dockerfile. We can create a Dockerfile with our code editor and turn it into a container image with the docker build command.

Here is an example Dockerfile from the NodeJS community

FROM node:16

# Create app directory
WORKDIR /usr/src/app

# Install app dependencies
# A wildcard is used to ensure both package.json 
# AND package-lock.json are copied
# where available (npm@5+)
COPY package*.json ./

RUN npm install
# If you are building your code for production
# RUN npm ci --only=production

# Bundle app source
COPY . .

EXPOSE 8080
CMD ["node", "server.js"]

You can see that the Dockerfile above carries out commands with the RUN directive much like you would do in the terminal of your UNIX system. But Dockerfiles offer also container specific declarations like COPY and EXPOSE which we use to inject data into a container process or for port-binding.

Every container image references a "base image". This is done through the FROM statement. The example above references the official NodeJS Docker image. Using the NodeJS Docker image as a base image ensures that we already have a linux container with NodeJS dependencies like npm and node pre-installed.

But we could have chosen any other Docker image from the official Docker Hub registry instead.

The concept of re-using existing Container Images by referencing base images is called image layering. Container images can consist of multiple layers. The example Dockerfile above is based on the NodeJS image layer which is based on the Ubuntu image layer.

Container Registries

Containers are made to simplify the deployment of software. But we need to ship container images to production systems in order to start container processes.

Container registries help us to distribute container images. A registry is a database for container images that we can consume through a Rest API or a client. One of the most popular container registries is the Docker Hub Registry. This is the place where many open source communities upload their official container images.

The Dockerfile example from the last section uses the official Docker Hub image for NodeJS. The docker command line interface (CLI) searches the Docker Hub container registry by default if the required container image cannot be found on the host system

Downloading a container image from a registry is called a "pull" or "pulling".

You can also host a container registry by yourself. Nexus and Artifactory are two common applications that provide container registries. Most cloud providers like Amazon Web Service, Microsoft Azure or Google Cloud Platform offer managed container registries for users.

How you can use another container registry with your Docker CLI is described here

Container Orchestration

Operating production systems with many container applications is difficult. Container Orchestrators like Kubernetes, Docker Swarm and Docker Compose exist to make the deployment and maintenance of containerized production systems easier.

Container orchestrators differ greatly in complexity and features. But Docker Compose is a good orchestrator to get started with Docker. It is primarly used for local development purposes or the deployment of production systems on a single virtual machine or computer.

Other orchestrators like Kubernetes are more complex to use but make it possible to deploy container applications on infrastructure with multiple virtual machines.

Open Container Initiative

The Open Container Initiative (OCI) provides a standard for the most important components of container technologies. Part of these standards are for example the container image format and the container runtime API.

Container Runtimes like containerd, CRI-O, Docker and Mirantis implement this OCI container runtime standard. That is important because container orchestrators like Kubernetes make the Container Runtime configurable. You use any container runtime that respects the OCI standard in your Kubernetes cluster.

Reasons to Use Container Technologies

We understand now the fundamental concepts of container technologies and can start to learn more about their use cases and benefits.

Here are the 10 reasons why you should use container technologies.

1. Resource Efficiency

Container help us to utilise more of our system resources in our computers, servers and virtual machines.

Organisations can deploy multiple services or applications on a machine through containers while maintaining a degree of isolation between them. That makes it possible to run more software on the same machine which improves resource utilisation and reduces hosting costs.

A smaller resource overhead compared to dedicated virtual machines makes the container a cheaper deployment target for software. Container do not provide system resources on their own but reuse existing system resources of the host machine instead.

A host machine can be anything that provides an operating system like a virtual machine or computer. Virtual machines are an interesting platform to host container processes since they find wide application in cloud computing and software hosting in general.

Virtualization of system resources in form of virtual machines is time intensive and costly. Automated infrastructures require on average several minutes to bootstrap a virtual machine, while containers are up and running in seconds.

The speed and resource efficiency of containers make them both a space, resource and time efficient deployment option and help us to maximise the resource usage of virtual machines.

2. Isolation

Software products have been deployed on virtual machines for a long time. Linux operating systems offer service managers like systemd to orchestrate several service processes on the same virtual machine. But that can be quite challenging because of the lack of isolation between processes.

Processes running on the same Linux operating system share system wide dependencies, disk space, network and CPU resources. It is difficult to ensure that services running in different Linux processes do not interfere with each other.

Container processes on the other side offer a higher degree of isolation in comparison. A container process gets started with the Unix clone system call in contrast to the exec system call used for most other Unix processes.

The clone system call spawns a UNIX process like the exec or fork system call. But clone has some important capabilities:

clone can place child processes into different UNIX namespaces.
clone can place child processes into a different virtual address space.
clone can change the file descriptor table of the child process.
...

We won't go into details of how a Unix operating system works in this blog post. But the capabilities offered by the clone system call used by container processes improves the isolation of containers compared to "regular" UNIX processes.

Container processes provide a virtualised operating system that reuses existing system resources of the host. The virtualised operating system prevents the leakage of system wide dependencies like dynamic link libraries into software processes that run inside a container.

For example, installing a NodeJS NPM package in one container process running a NodeJS app does not affect other container processes. The same might not be true for two NodeJS processes running on the same Linux machine. There is the possibility that both apps use the same NodeJS interpreter which might lead to incompatabilities.

3. Automated Setup

Container images provide a declarative syntax that you can use to describe a container. Container Runtimes use container images to start container processes on a host operating system.

The starting procedure that the Container Runtime carries out is automated and reproducible. Instructing the Container Runtime to start a container process using the same image a hundred times, leads a hundred times to the same result.

That is an important quality of Container Technologies. It makes software deployments more predictable and bugs in software systems more relatable. Software Developers can reproduce bugs that appear in production systems easier if the underlying application runs in a container. Developers can use the container image to run an application in the same runtime environment on their local machine for trouble shooting.

4. Reusability

The container image ecosystem works like an onion. Container images consist of multiple layers that are entwined into each other like an onion.

Reusing rather than rewriting container images makes it easier to specify a container. A NodeJS developer can use the official NodeJS Docker Hub image to containerise his application. There is no need to specify installation routines for a NodeJS interpreter or the NPM package manager. This step is already covered by the NodeJS base container image.

Compare this approach with the typical installation workflow on virtual machines. A vanilla virtual machine comes with an operating system only. DevOps have to intercept the virtual machine through SSH to install software dependencies and parts of the software runtime by hand.

Additional software like Chef or Ansible can automate this process but administrators have to configure and maintain automation workflows.

5. Flexibility

A Docker Container can be deployed to any operating system with a Docker Engine installed. Docker supports a wide range of operating systems from Windows, MacOS to most Linux distributions.

Being able to deploy a container across many operating systems offers flexibility. It makes us more independent from conditions that we meet on our infrastructure. Virtual machines on Amazon Web Services might differ greatly from virtual machines on Microsoft Azure. So your software applications might require different dependencies depending on the infrastructure that you deploy them on.

Container technologies ship their own software runtime and circumvent discrepancies between infrastructures. That makes it easier to deploy them on different infrastructures.

6. Reproducibility

The premise of containers is that software running inside them behaves the same, regardless on which host system we deploy them. The extended isolation of container processes compared to "regular" UNIX processes ensures that this premise holds true.

Knowing that your containerised application behaves the same on any host system makes it easier to reproduce and debug problems that happen in productive systems. Software developers can run containerised application on their local machine and debug a problem that the customer reported at the production environment.

7. Interoperability

Container technologies simplify the collaboration between developers and operators. Operators can provide the container image while software developers focus on programming the software application specified in the container image.

Changes in the software application rarely require changes of the container image. This makes it easier to isolate the developer and operator role in a software company.

Container images function as a contract between developer and operator. This contract specifies how software can be deployed on the production system through a container runtime.

Compare this with "regular" software processes running on a developer machine or a virtual machine. Complex software processes require different data services and software dependencies. Developers and operators have to install these runtime dependencies on local development machines and virtual machines alike. This results in a confusing installation procedure that can lead to misunderstandings.

8. Composability

Composing software services and applications across multiple virtual machines can be challenging. Platform providers tend to install applications and services on dedicated virtual machines to limit potential side effects.

Additional software like Chef or Ansible get used to automate this process but require configuration and maintenance of qualified personnel.

The implementation of large micro service architectures with multiple applications and services that communicate with each other are common these days.

Container orchestrators like Kubernetes can help to schedule and deploy containerised micro services across multiple virtual machines.

9. Scalability

Containers are fast, it takes a few seconds to start a container on a host system. They are so fast that Kubernetes kills failing container services and starts a new service rather than fixing the old instance.

Deployment speed is an important metric in software hosting. It reduces the downtime of services during updates and makes it easier to scale out.

Creating a new virtual machine on an automated infrastructure (IaaS) like AWS on the other hand takes minutes. Requesting a larger VM on the same infrastructure to satisfy the growing resource demand of an application costs you another couple of minutes.

This makes it much more difficult to scale out applications or services that run as processes on a virtual machines instead of containers.

10. Less Permissive

It can be challenging to deploy applications on virtual machines if you don't have sufficient permissions to install third party applications and dependencies.

Many Linux users install software and dependencies through a package manager like aptitude with superuser permissions. This can be done with the sudo command that runs a terminal command with superuser priviliges.

But giving every developer and operator superuser priviliges is dangerous. Many organizations restrict superuser priviliges on productive virtual machines for this reason.

Container processes do not need to be executed with superuser priviliges. They ship their own virtual operating system and developers specify required dependencies through the container image.

Summary

Container technologies revolutionised how we as a community operate and deploy software.

This blog post taught us the fundamental concepts of container technologies along with their advantages.

But containers are not a magic pill. They have limitations like any other technology. One of the weaknesses of container technologies is at the same time its biggest strength. The lack of virtualised system resources in containers make them slim and fast but they compromise the isolation of containers in comparison to virtual machines.

A container does not virtualise network, storage or server resources. It reuses existing system resources of the host system along with other containers and processes. Container runtimes cannot limit the bandwidth of IO operations for a container process. This problem is also known as the IOPS problem.

Placing two large containerised databases on the same virtual machine might lead to resource contingencies. One database could occupy the complete bandwidth for data IO operations of the host system, effectively leaving the other database dry.

And those are the 10 reasons why you should use container technologies.

I recommend you have a look at the excellent documentation of Docker if you want to get started with container technologies now.

DEV Community: Dennis Groß (he/him)

Beginners Guide to AWS VPCs

VPC Router

Network Address Translation (NAT)

Static NAT

Dynamic NAT

PAT

VPC CIDR

CIDR Sizes

Subnetting

Three-Tier Application

Finding the correct Subnet Structure

Availability Zones

Internet Gateway

NAT Gateway

Routing Tables

Route Associations

Subnets

Public Subnets

Private Subnets

Private Isolated Subnets

High Availability in VPCs

VPC Configuration Flags

AWS IAM roles in Terraform

aws_iam_role Resource

Trust Policies

Inline Policies

Managed Policies

EC2 Instance Profile

jsonencode

Compute AWS VPC Subnet CIDRs in Terraform

Subnetting in Terraform

How to use Terraform variables

variables.tf

Overriding defaults

Override with environment variables

Override with the CLI

Use locals with Terraform

Create Locals

Use Locals With Ternary Operator

Beginners Guide to EC2

EC2 Instances

TL;DR

Virtual Machines

EC2 Instance Families

Instancy Types

Burstable Instances

Instance Lifecycle

Boot Volume

Attaching EBS Volumes

EFS

User Data

AMIs and Golden AMIs

SSH into EC2 via Session Manager

Launch Templates

Summary

How to configure Provider in Terraform

Specifying a Provider

AWS Provider

Specify Credentials through AWS Profile

Specify Credentials directly

AWS Best Practices: Three Tier VPC

TL;DR

Create the VPC

Enable VPC Flow Logs

Public Web Subnet

Computing Subnet

Data Subnet

Productive VPC Usage

Considerations for non-productive Use

Summary

How to use templates in Terraform

Variable Substitution

For Loop - Lists

For Loop - Maps

How to use count in Terraform

How to use Modules in Terraform

Module Distribution

Referencing Modules from the File System

Using Registry Modules

`aws_iam_role` Resource

`jsonencode`

`variables.tf`