Automate AWS account creation(2)
Tags: aws, devops, architecture, automation
Published: 2023-09-10 02:07:43

Hello! All Developers!

Following the First Post [Automate AWS account creation(1)](https://dev.to/aws-builders/automate-aws-account-creation1-3h78), I would like to cover the implementation method in the second article related to infrastructure automation.

I will explain it largely by dividing it into resources created with Terraform and implemented with Serverless Framework.

The architecture covered in Part 1 uses the Serverless Framework as a framework to conveniently implement AWS Lambda functions.

**Remind**

![AWS Architecture](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/6ngzuk9ykzrl6nc53wfw.png)

I hope those who read this will understand it completely :)

## 1. Implementation using Terraform

- AWS IAM User and Role

{% embed https://gist.github.com/YoungJinJung/98876b94886ba278a5979f9994db2aad %}
The organization I belong to uses IAM in a way that creates user accounts and maps them to groups. However, I can provide code examples specifically for creating user accounts as follows:

> The 'name' section corresponds to the user account.

> We use the 'mail' format so that Lambda can extract the user account and use it directly as an email address.

> If you prefer to use a simple name like 'test,' you can include the email domain in Lambda.

> The 'tags' field is not mandatory and is optional.

{% embed https://gist.github.com/YoungJinJung/d93bef1385059b6ff34b1cab6da95a5b %}

The IAM Role used in Lambda is configured as shown above. It has been set up to allow Lambda and EventBridge to assume this IAM Role.

The next part pertains to the policy associated with the role. When events occur, it logs them, and it grants permissions for the API used in the Lambda execution process through policies.

- AWS SNS Topic and Subscription

{% embed https://gist.github.com/YoungJinJung/93f75e895aebc8e1f50677e67aadb73d %}

The SNS Topic is configured with two main policies:
> Lines 6 - 13 define a policy that allows publishing events to the SNS Topic when events are triggered from EventBridge.

> Lines 14 - 35 define a policy that enables certain SNS functionalities when the SourceOwner is a specific Account-ID.

{% embed https://gist.github.com/YoungJinJung/2209cadca121b517df540563bef836d0 %}

So, when a specific event occurs in EventBridge and targets the SNS Topic, the first policy allows the event to be published. 

Additionally, for SNS Subscriptions associated with a specific Account ID, they can subscribe to the SNS Topic identified by its ARN and trigger the associated Lambda function.

- AWS SES

{% embed https://gist.github.com/YoungJinJung/4b354332564d2e66575317371b2269ed %}

To use the domain as mentioned above, you need to create a Domain Identity in SES. After creating the Domain Identity with the respective domain, when you go to the AWS Console, you will receive 3 address values for authentication.

Once you register these addresses in the route table of the domain you intend to use (or in AWS Route53), it will be authenticated.

However, registering these addresses alone does not mean that the domain is ready for use.

This domain exists in a sandbox environment.

The sandbox environment has the following constraints:
> You can send a maximum of 200 messages within 24 hours.
> You can send a maximum of 1 message per second.
> You can only send messages from authenticated email addresses in SES.

To use this domain in a real production environment, you must create a Request-production-access and submit it to AWS Support.

The official documentation states that Request-production-access may take up to 24 hours to complete (see Reference below).

Therefore, the process of Request-production-access must be completed before you can finish creating resources using Terraform.

Next, we will explain Lambda and EventBridge using the Serverless Framework.

## 2. Implementation using Terraform

- serverless.yml

{% embed https://gist.github.com/YoungJinJung/63e4bd8d3f1a76ab6846544fb61a3a0a %}

**The serverless.yml** file can be broadly divided into three sections: provider, function, and resource.

**The provider section** represents the environment configuration for Lambda. It specifies details such as the region where the deployment will occur, the amount of memory to be used, and the IAM role to be used.

**The function section** is where the actual Lambda execution behavior is defined when triggered. Among the key names, the handler part maps to the actual binary or function name that will be executed. This part varies slightly depending on the programming language used. For JavaScript or Python, it specifies the function name in the executing file, while for Go, it specifies the binary.

**The resource section** represents the resources configured within the Serverless Framework, primarily specifying resources used by the functions. The provided example determines whether an event notification will be sent to an SNS topic when the CreateUser API is called via EventBridge.

- main.go

{% embed https://gist.github.com/YoungJinJung/719680af7102a854a6a8c60258e7e6d7 %}

When Lambda is triggered, the `Handler` function in the source code is invoked, which can be divided into four main parts:

1. **Parsing the incoming information from the Event (Lines 46 - 49)**:
   In this step, information like the user's account name is extracted from the Event.

2. **Generating a Password using the `go-password` library (Lines 31 - 36)**:
   This library is used to generate a password based on parameters such as the desired length, the number of special characters, and the number of digits.

3. **Creating a login profile with the parsed user account name and generated Password (Lines 58 - 68)**:
   In this part, the Terraform-created user account is enabled, and a password is specified. Additionally, there's an option to determine whether the user should be prompted to reset their password upon initial login, which is passed as a parameter when making the API call.

4. **Sending account information created to an email address using the SES API (Lines 70 - 99)**:
   In this step, if the user account wasn't created in the form of an email address, you need to concatenate the domain and user account to the `ToAddress` in Line 79. Then, by specifying the desired Title and Content, the SES API is called to send an email.

This automation process demonstrates how AWS IAM creates a user, sets their password, activates the account, and sends the account details to a specified email or user account.