DEV Community: Carlos Loredo

AWS VPC - Cheat Sheet

Carlos Loredo — Thu, 08 Jul 2021 02:50:14 +0000

Virtual Private Cloud

VPC --> A virtual private network that can be compared with having your own data center inside AWS. An isolated section where you can launch resources with complete control of the virtual network environment.

Key Concepts:

Subnet: A range of IPs inside your VPC (public and private).
Route table: A set of rules called "routes" that define where the network traffic goes.
Internet Gateway: A gateway attached to your VPC that enables communication of your resource to the Internet.
VPC endpoint: Privately connect your VPC to other AWS services, powered by a Private Link.
CIDR block: A route aggregation methodology, classless, based on the mask.
NAT Gateway: Gateway to enable Internet access to resources in Private Subnets, but preventing "the Internet" to initialize connections to them.

What we can do with a VPC?

Launch instances in a Subnet of our choose.
Assign custom Subnets IP addresses.
Configure route tables.
Create an Internet Gateway (IGW) and attach to your VPC.
Much better security control over resources.
Instance Security Groups.
Access control lists.

*you can only have one IGW attached to a VPC

Subnets:

VPC span in all the AZs in the region where they were created, you can put one or more Subnets in each AZ. Each Subnet must reside in one AZ.

Private Subnet: A Subnet that has no route to IGW. Instances don't have public IPv4 addresses.
Public Subnet: A Subnet that has a route to IGW in the routing table. An instance in a Public Subnet must have an IPv4 address to connect to the Internet.
VPN-only Subnet: A Subnet that doesn't have a connection to the Internet, but has attached a virtual private gateway for a site-to-site VPN connection.
Route tables: A set of rules called routes that define where the network traffic goes. You can specify the Route Table for a Subnet, if you don't, it will be associated with the default route table.

*Amazon always reserve 5 IP addresses within your Subnets.

Connection:

Internet gateway: (IGW) allows communication through the Internet using the AWS network edge. IGW must be attached to the VPC and there must be a route defined in the Route Table.

Site-to-site connection: Consists of two tunnels (VPNs) between Private Virtual Gateway or a Transit Gateway and a Customer Gateway.

Transit Gateway: This is a virtual link to connect your VPCs and On-premises networks. You can connect VPCs, SD-WAN network appliances, AWS Direct Connect Gateway, peering connections to another Transit Gateway, VPN connection.
MTU:1500 bytes for VPC and 8500 MTU between the other services.

Private Link: Connect your VPC to other AWS-supported services, also services hosted by other AWS accounts, and AWS Marketplace services. Everything without going through the Internet. To use Private Link you must create a VPC Endpoint.

VPC Endpoint: Enables you to connect to your VPC other AWS services powered by Private Link, without going to the Internet. No IGW, NATGW, VPN, or Direct Connect required.
Types of endpoints:

Gateway Endpoint: An endpoint for S3 and DynamoDB. You must attach a policy to allow access to all or some services. Then it works as a target in the Route table of the Subnet that you want to grant access to those services.
Interface Endpoint: An Elastic Network Interface (ENI) with an IP address of your Subnet. Works as an entry point to supported AWS service traffic.
Gateway Load Balancer endpoint: A ENI with an IP in the range of your Subnet. Acts as an entry point to intercept traffic (layer 3), works in combination with Elastic Load Balancer.

VPC Peering: Connects two VPCs, enabling to route traffic between them privately. You can connect VPCs in your own account or with other accounts. VPCs can be in other regions (inter-region VPC peering).

Communication between non-overlapping CIDR block only.
No edge-to-edge routing (You can't reach, Direct connect, Internet connections, VPC endpoints, etc.).

NAT instance: An EC2 instances that works as a NAT gateway.

When creating a NAT instance, disable Source/destination check.
NAT instance must be in a Public Subnet.
There must be a route in the Private Subnet to the NAT instance.
The amount of traffic depends on the Ec2 instance size used.
You can create High Availability using Autoscaling groups, multiple subnets in different AZs and a script automatic fail over for the NAT instance.
Must be behind a security group.

NAT gateway --> A complete gateway that woks for many instances.

Redundancy inside Availability Zone.
Start at 5Gbps and scales up to 48Gbps.
No need patch or updates.
Automatic IP addresses.
Not associated with Security Groups.

Networking & Security

Security Groups: Works at the instance level and control inbound and outbound traffic. Only allow rules (not deny rules), you can filter traffic based on protocols and ports number. There are inbound and outbound rules. Security groups are stateful. Responses to allowed inbound traffic are allowed to flow out, regardless of outbound rules.

Default Security Group names start with "sg- "
Security groups can be used in the VPC where were created.
You can change rules in default Security Groups but, you can't delete them.

Network Access Control List (NACL): Control traffic at the Subnet level. Each Subnet must be associated with 1 NACL, but an NACL can be associated with multiple subnets. The rules are evaluated in order starting with the lower number. NACL is stateless, it means that is not implicit that responses to inbound traffic will be allowed and vice-versa.

NACL vs SG:

When you create a new NACL it deny everything, the one created by default allows everything.
The usage of ephemeral ports on NACL is because we need open ports for the sessions with different clients.
In NACL the inbound/outbound rules are applied in chronological order.
We can have multiple Subnets associations on NACLs
You can block IP addresses in NACLs, not in Security Groups
NACL are stateless, SG are stateful.

Flow logs: Capture traffic logs going in/out your interfaces inside VPC. You can create flow logs for VPC, Subnets, or Networks Interfaces. Help you control the rules behavior of Security Groups and Network Access Control Lists. Flow logs can be published on CloudWatch logs and S3.

Traffic Mirroring: Copy traffic from an Elastic Network Interface (ENI) of an EC2 instance to a monitoring appliance.

DNS: Instances in VPCs are provided with Private and Public DNS names for IPv4 addresses.

Other important stuff:

Direct Connect: A service that bypasses the Internet using a direct connection between your On-premises network and AWS services or VPC.

Global Accelerator: Improve the performance of applications creating acceleration. An accelerator directs traffic to optimal endpoints over AWS global network.

By default it provides two static IP addresses that you associate with your accelerator, alternatively you can bring your own.
Global Accelerator assigns each accelerator a default DNS that point to static IP addresses.
Network zone service. The static IP addresses for the accelerator from a unique Subnet (similar to AZs) --> 2 IP addresses
Listener processes inbound connection to accelerator based on port and protocol (TCP & UPD protocols)
Endpoints groups are associated with AWS regions, you can adjust the % of traffic (setting the traffic dial).
Endpoints (EC2 instances, load balancers, IP addresses) can be configured with different weights.

Saas: La metodología de 12 factores explicada

Carlos Loredo — Mon, 21 Jun 2021 00:13:26 +0000

La metodología de doce-factores es una metodología para crear aplicaciones de software como servicio (Saas). Consta de algunas "mejores prácticas" diseñadas para permitir que las aplicaciones web se creen con portabilidad y resiliencia.

Para comprender esta metodología podemos dividir los doce factores en 3 componentes clave:

A continuación, veremos las mejores prácticas que se debe seguir en cada factor para que nuestra aplicación cumpla con esta metodología.

Factores de código:

Factor 1 - Código base:

Se debe hacer seguimiento a los cambios en el código desden un sistema de control de versiones (VCS) como Github, BitBucket, etc.
Relación uno a uno entre el código base y la aplicación.
Puede haber múltiples implementaciones de la aplicación.
Pueden haber diferentes versiones del código base en cada implementación.

Factor 5: Compila, publica y ejecuta:

Build (Compilación): transforma un código base en una unidad ejecutable llamada build.
Release (Lanzamiento): Combina el build con la configuración para que esté listo para ejecutarse.
Ejecución: ejecuta la aplicación.

Factor 10 - Paridad Dev/Prod:

Minimiza las diferencias entre los entornos de implementación y producción.
Los servicios de back-end deben ser los mismos en todos los entornos (dev/prod).

Factores de implementación:

Factor 2 - Dependencias:

Ten en cuenta que una aplicación solo es confiable como su dependencia menos confiable.
Asegúrate de que el código declare explícitamente cualquier dependencia.

Factor 3 - Configuración:

La configuración contiene todo lo que varía entre las implementaciones, como las credenciales y las ubicaciones de los servicios de respaldo.
Las configuraciones deben mantenerse separadas del código
Almacena la configuración en variables de entorno.

Factor 4 - Servicios de back-end:

Las aplicaciones no deben distinguir entre servicios de back-end locales y de terceros.
Se debe acceder a todos los servicios mediante URLs y credenciales para que puedan intercambiarse sin cambiar el código.

Factor 6 - Procesos:

"Stateless" y no comparten nada.
Los servicios de respaldo almacenan datos persistentes ya que la memoria y los sistemas de archivos no se comparten entre los procesos.
Los datos se almacenan de forma centralizada.

Factor 7 - Enlace a través de puertos:

Exportación de servicios designando un puerto. HTTP y otros servicios se exportan de esta manera.
Para vincular un puerto normalmente debe declarar una biblioteca de servidor web.
Las aplicaciones pueden ser servicios que sean llamadas por otras aplicaciones a través de la URL y el puerto.

Factor 9 - Desechabilidad:

Las aplicaciones deben tener un tiempo de inicio de proceso mínimo y un cierre o terminación de la applicación eficiente.
Implementar código y configurar cambios rápidamente.
Escale aplicaciones fácilmente.

Factor 11 - Registros (logs):

Las aplicaciones no deben preocuparse por almacenar registros (logs).
Las aplicaciones deben tener registros de tendencias en forma de un flujo de eventos escrito en stdout.
El entorno de ejecución captura el flujo de todas las aplicaciones, agrega los registros y enruta los registros a su destino.

Factores operativos:

Factor 8 - Simultaneidad:

Se pueden utilizar procesos concurrentes para escalar la aplicación.
Los procesos sin estado se pueden activar sin crear dependencias en otros procesos.

Factor 12 - Procesos de administración:

Habilite procesos únicos de administración de aplicaciones, como la migración de bases de datos.
Ejecutar contra una versión con la misma configuración del código base.
Están incluidos en el código de la aplicación.

Fuentes:

El sitio web de la Metodología de los Doce Factores: 12factor

SaaS: The Twelve-Factor app methodology explained

Carlos Loredo — Sun, 20 Jun 2021 23:45:40 +0000

The Twelve-Factor App methodology is a methodology for building software-as-a-service applications. These best practices are designed to enable applications to be built with portability and resilience when deployed to the web.

To understand this methodology we can divide the twelve factors into 3 key components:

Next, we'll see the best practices that you should follow for every factor to comply with what this methodology says.

Code Factors:

Factor 1 - CodeBase:

Code must be tracked in a version control system (VCS) like Github, BitBucket, etc.
One-to-One relationship between the CodeBase and the application.
There can be multiple deploys of the application.
Different versions of the CodeBase can be in each deployment.

Factor 5 - Build, release and run:

Build: Transform a CodeBase into an executable unit called build.
Release: Combine build with configuration so that it's ready to run.
Run: Runs the application.

Factor 10 - Dev/Prod parity:

Minimize differences between deployment and production environments.
Back-end services should be the same across environments (dev/prod)

Deploy Factors:

Factor 2 - Dependencies:

Be aware that an app is only reliable as its least reliable dependency.
Be sure that code explicitly declares any dependency.

Factor 3 - Config:

Config contains everything that varies between deploys such as credentials and backing services locations.
Configs must be kept separate from the code
Store config in environment variables.

Factor 4 - Backing services:

Applications should not distinguish between local and third-party back-end services.
All services should be accessed by URL and credentials so that can be swapped without changing the code.

Factor 6 - Processes:

Stateless and share nothing.
Backing services store persistent data since memory and filesystems are not shared across processes.
Data is centrally stored.

Factor 7 - Port binding:

Export services by port binding. HTTP and other services are exported in this way.
To bind a port usually you must declare a web server library.
Applications can be backing services for other applications.

Factor 9 - Disposability:

Applications should have minimal process start-time and graceful termination.
Quickly deploy code and configure changes.
Easily scale applications.

Factor 11 - Logs:

Applications should not concern themselves with storing logs.
Applications should trend logs as event stream written to stdout.
Execution environment captures the stream for all apps aggregates the logs and routes logs to their destination.

Operate Factors:

Factor 8 - Concurrency:

Concurrent processes can be used to scale the application.
Stateless processes can be spun up without creating dependencies on other processes.

Factor 12 - Admin processes:

Enable one-off application management processes such as database migration.
Run against a release using the same CodeBase configuration.
Are included in the application code.

Sources:

The Twelve-Factors Methodology website: 12factor

AWS IAM users, groups and roles explained in an airport

Carlos Loredo — Fri, 11 Jun 2021 23:54:31 +0000

First, what is this IAM thing about?

Imagine a really big airport, like Hartsfield–Jackson Airport in Atlanta (U.S) or Beijing International Airport (China) with hundreds of airline offices, a lot of flights arriving and leaving, employees doing their different jobs, and many people going around. Even if we don't know exactly how everything works in an airport, we can be sure that it works.

Well, to understand Identity access management (IAM) we can think of Amazon Web Services (AWS) as a big Airport with hundreds of services (airlines), traffic between services (flights), and many users with different roles taking advantage of cloud services (people).

What I'm trying with this example, is to explain how IAM users, groups, and roles work, because I see many new developers struggling with these concepts. If you read this I hope that clarifies everything for you. Let me know in a comment how it was, and how it can improve.
OK, let's do this!

I think that we've all been to the airport at least one time, right? Well, I don't know if you noticed but in airports, there is a complex access control system to keep individuals out of restricted areas and maintain the facilities secure, it is composed of a lot of people with different roles, scanners, cameras, and many other devices and equipment. All of them are there to maintain the security of the airport (infrastructure, airlines, and passengers)

Ok, we can say that Identity Access Management is the same, is the service that provides access control in AWS, so it controls all the access to AWS resources. Is important to say that IAM is not the only service that provides security, but is the most important. And is also composed of different elements, features, and tools.

The root user:

In an airport, airlines rent offices to operate and offer flights to their customers. There are big international airlines and also small airlines with local operations. (Just like the users of AWS) When an airline company wants to operate in the airport they sign a contract (terms of use) to use the airport services. Let's say that the contract is signed by the regional manager who represents the airline in that airport, We could say that he gets the office keys that allow him to access anywhere.

When you create an AWS account, you accept some terms and conditions for the service, and immediately you have access to all the services. This account is called the root account and with this account, you have all the permissions to create resources, assign new users and manage all your infrastructure and applications in AWS services.

Let's continue, the manager shouldn't do everything, right? he or she can't run an airline office by itself, there have to be a lot of people that work for the company. What he can do is hire more staff. There can be sales agents, operations agents, baggage handlers, flight dispatchers, administrative support staff, among others. In the end, the manager will only sit at his desk eating donuts like a boss. (I don't know if that's the case of a true manager but for this example it is).

When you first create an AWS account, you begin with a single sign-in identity that has complete access to all the services and resources in the account. This identity is called the AWS account root user. You can sign in as the root user using the email address and password that you used to create the account.

AWS strongly recommends that you do not use the root user for your everyday tasks, even the administrative ones. Instead, create IAM users and assign them different permissions to perform different tasks. Then securely lock away the root user credentials and use them to perform only a few account and service management tasks. Let that account rest eating donuts.

IAM Users:

Airports are divided into landside and airside zones. The landside is subject to fewer special laws and is part of the public realm, while access to the airside zone is tightly controlled. The airside area includes all parts of the airport around the aircraft and the parts of the buildings that are restricted to staff.

Let's suppose that the manager hired some people to perform different jobs and gave them credentials and different permissions to access different areas. For example, the sales agents are at the counter in contact with clients but will never enter the airside area; the baggage handlers on the other hand are allowed to enter the airside area to carry the luggage to the aircraft.

Well, in AWS is almost the same. An IAM user is an entity that you create in AWS to represent the person or application that uses it to interact with AWS. A user in AWS consists of a name and credentials that can access AWS in different ways depending on what services and resources it is allowed to use.

A brand new IAM user created using the AWS CLI or AWS API has no credentials of any kind. You must create the type of credentials for an IAM user based on the needs of your user.

IAM Groups:

Do you know RFID cards? These are the cards that are used to grant access to restricted areas to the cardholder. So you can program which doors will open with that card.
In this case, the manager decided to give the employees RFID cards of different colors depending on the access permissions that they need. For example, there is a group of ten people in charge of the maintenance of aircraft. All of them, who received the orange card, can access the same restricted areas in the airside zone.

Let's suppose that an employee is promoted to a new job. What happens then? Well, it's simple, he will be part of another group, so he will return his card and receive a new one.

An IAM user group is a collection of IAM users. User groups let you specify permissions for multiple users, which can make it easier to manage the permissions for those users. For example, you could have a user group called "Devs" and give that user group the types of permissions that developers typically need. Any user in that user group automatically has the permissions that are assigned to the user group. If a new user joins your organization and needs developer privileges, you can assign the appropriate permissions by adding the user to that user group. Similarly, if a person changes jobs in your organization, instead of editing that user's permissions, you can remove him or her from the old user groups and add him or her to the appropriate new user groups.

IAM Roles:

Imagine that every three months a third-party auditory team must enter the office and check how all operations are being carried out. The manager is not going to generate RFID cards for them, because they may not be the same people who visit the office every time, and because they are not part of the company.

To resolve this, the manager decides to create predefined cards with all the permissions that they will need in their auditors' role. So these people get these cards only for the period that they remain in the offices, later when they have done with their job, they have to return the cards and they lose all the access that had granted.

An IAM role is an IAM identity that you can create in your account that has specific permissions. An IAM role is similar to an IAM user. However, instead of being uniquely associated with one person, a role is intended to be assumable by anyone who needs it. Also, a role does not have standard long-term credentials such as a password or access keys associated with it. Instead, when you assume a role, it provides you with temporary security credentials for your role session.

You can use roles to delegate access to users, applications, or services that don't normally have access to your AWS resources. For example, you might want to grant users in your AWS account access to resources they don't usually have, or grant users in one AWS account access to resources in another account. Or you might want to allow a mobile app to use AWS resources, but not want to embed AWS keys within the app (where they can be difficult to rotate and where users can potentially extract them). Sometimes you want to give AWS access to users who already have identities defined outside of AWS, such as in your corporate directory. Or, you might want to grant access to your account to third parties so that they can perform an audit on your resources.