Blog

The terraform import command allows you to import into HashiCorp Terraform resources that already existed previously in the provider we are working with, in this case AWS. However, it only allows you to import those records one by one, with one run of terraform import at a time. This, apart from being extremely tedious, in some situations becomes impractical. This is the case for the records of a Route53 DNS zone. The task can become unmanageable if we have multiple DNS zones, each one with tens or hundreds of records. In this article I offer you a bash script that will allow you to import in Terraform all the records of a Route53 DNS zone in a matter of seconds or a few minutes.

If you have an unencrypted AMI you can share it with another AWS account directly without doing anything special. But if the AMI is encrypted, things get complicated, as the destination account won't have the encryption key to decrypt its snapshots and you won't be able to share it. In this article I'll show you how to properly share an encrypted AMI between two AWS accounts using customer managed KMS keys, allowing you to securely share your EC2 instance images across different AWS accounts.

Last December Amazon announced its new EBS gp3 volumes, which offer better performance and a cost saving of 20% compared to those that have been used until now (gp2). Well, after successfully testing these new volumes with multiple clients, I can do nothing but recommend their use, because they are all advantages and in these 2 and a half months that have passed since the announcement I have not noticed any problems or side effects.

One of the biggest annoyances when working with AWS and your Internet connection has a dynamic IP is that when it changes, you immediately stop accessing to all servers and services protected by an EC2 security group whose rules only allow traffic to certain specific IP’s instead of allowing open connections to everyone (0.0.0.0.0/0).

Certainly the simplest thing to do is always allowing traffic on a given port to everyone, so that even if you have a dynamic IP on your Internet connection you will always be able to continue accessing even if it changes. But opening traffic on a port to everyone is not the right way to proceed from a security point of view, because then any attacker will be able to access that port without restrictions, and that is not what you want.

The following Linux procedure describes how to use at the same time 2 network interfaces connected to the same AWS subnet and, which is more important, how to make both communication works well internally (between hosts on the same subnet) and also externally (both interfaces visible from the Internet). This can be useful for example when you want the same EC2 instance to host a web server serving http or https requests and at the same time have a websockets server ws:// or wss:// listening on the same port 80 or 443 respectively. Although there are other ways to achieve this such as configuring Nginx to be able to discriminate web traffic (http) from websockets traffic (ws) and act as a proxy to redirect the corresponding requests to the websockets server, this other solution I propose seems simpler and to some extent more efficient because it is not necessary to redirect traffic, which will always introduce a small latency, and allows to keep both servers completely independent within the same host. The only drawback is that you will need to assign 2 Elastic IP addresses to the same EC2 instance instead of only 1, but at the same time this will give you more flexibility when establishing rules in the security groups or in the subnet NAT rules.

One of the few things I do not like about the AWS EC2 service is that all available images (AMIs) used to to launch new instances require a root volume of at least 8 or 10 GB in size and all of them also have a single partition where the root filesystem is mounted on.

In my post The importance of properly partitioning a disk in Linux I discussed why in my opinion this approach is not appropriate and now I will address in a practical way how to divide those volumes into multiple partitions keeping the 8-10 GB base size or making them even smaller to save costs in case you want to deploy smaller servers that do not need as much storage space.

Sentilo is an open source software designed by openTrends for the exchange and processing of information from thousands of sensors and actuators, acting as an interface between them and the various applications that want to collect and make use of the information they provide. Thus, it fits well within the Smart City architecture and has the city of Barcelona as the main promoter. But Sentilo is not only made by and for the cities, but also for any organization that wants to implement an IoT application that requires deploying a smaller number of sensors and actuators, such as inside buildings or in the open field.

One of the main needs of a small business or startup is to have a reliable mail system with its own domain that helps differentiate on the Internet. Although there are lots of hosting plans offering free email accounts and even you could set up your own mail server, you are probably already used to mail services like GMail and would like to continue using it to also manage mail from your own domain without having to come to paid solutions such as G Suite (formerly Google Apps), which though inexpensive for the services you get in return, they represent an additional cost that your incipient project might not afford.

When we completely fill up an ext4 filesystem mounted on a partition hosted in an EBS volume of Amazon Web Services and we can not do anything to free space because we do not want to lose any of the stored data, the only solution is to grow up the volume and extend the associated partition up to 100% of its capacity to obtain free space again.

We start in our example with a 50 GB volume full to 100%. We want to extend it to double the size, 100 GB: