AWS Environment Setup

There's no `AWS Lambda` without `AWS`. That means we'll need a few AWS resources created and configured on the AWS side of things to develop and effectively.

AWS Environment Setup#

There's no AWS Lambda without AWS. That means we'll need a few AWS resources created and configured on the AWS side of things to develop and effectively.

Those resources include:

  • Access to an AWS Account

  • An IAM User on that AWS Account which has rights to interact with AWS Lambda, and related services. The rights that come with Administrator Access or Power User Access cover most everything we will touch.

  • API Access Key credentials for our IAM User. This key will be saved on our local development machine and used to deploy our Lambda's programatically.

Additionally, even if you have all of the above ready - we recommend reading the Securing Your AWS Account section to learn how to keep your AWS Account secured.

Spending 15 minutes now will save you hours later if you ever need regain access after a compromise!

Every AWS Account is a potential target. A common misconception about AWS is the belief that it is not necessary to secure your account when it’s only being used for testing or minor projects. Many attackers don’t want to steal your data - they want to steal your AWS compute resources. An attacker will often use compromised accounts to spin up expensive instances for crypto mining or botnet attacks. Sometimes they use unusual AWS regions and dedicated instances so those instances don’t appear visible in a user’s usual dashboard. Some users don’t realize they have been attacked until they receive an expensive bill! Alternatively, AWS may reach out and temporarily disable a compromised account if they detect it is being used for malicious purposes. This can be a serious headache that can affect uptime for anyone running legitimate production services.

A note on Free-Tier usage and costs in AWS#

Every exercise in this course will comply with AWS free-tier offerings. If we are using an account that is still free-tier eligible, there should be no billed charged for completing any exercises as defined in the book. Some projects could potentially incur cost past free-tier with heavy usage (ie, deploying the dicebot project into a popular channel where it gets invoked frequently). However - simply deploying and testing these applications will not incur cost if free-tier is active. Steps for removing the deployed project from AWS will also be included. It is recommended to always cleanup work after completion. We can always re-deploy projects later.

Additional Recommended Reading on this topic Guidance for Avoiding Unexpected Charges.

Common AWS Scenarios#

We recognize that exposure to AWS might vary wildly among our readers. You can use the links below to jump to whichever section of the course is most relevant to your needs.

Account Provisioning#

For Developers new to AWS (Standard Signup)#

For everyone else, we will need to register a standard AWS Account in our own name, or in our business’ name on the AWS Signup Page. Be aware - creating an AWS Account requires a valid credit card, even if we only intend to use free-tier services and/or promotional credits.

WARNING - Automated Fraud Prevention AWS Fraud detection may enforce a hold-period of up to 24-hours when registering an account associated with a high-fraud risk locale!

For Members of Organizations that already use AWS (AWS Organizations)#

If your workplace or organization already uses AWS - you may be able to request access to an existing account or ask your AWS Account Admin to provision you a new one through the AWS Organizations service.

For Students (AWS Educate)#

If you are a student with a valid .edu email address, you can register for a special AWS account that includes promotional credit and other training resources through the AWS Educate Program.

Securing an AWS Account#

Security changes only take a few minutes to make, but they will significantly improve the risk posture of an AWS account. Don’t put this step off for later,- do it on first login to any new AWS account.

For readers who did not create their own AWS account, and instead were provided access to a user within a shared account - you can log in with that user and skip down to Enable MFA on IAM User

Configure CloudTrail#

Note for Accounts created by AWS Organization Many AWS Organizations-created accounts already have CloudTrail configured by default If CloudTrail is already enabled by organization policy, skip this step.

CloudTrail is a service which keeps records for the last 90 days worth of management API events in AWS. This includes information about which user logged in, where they logged in from, and any changes they made to account users and permissions. These events are incredibly useful when you need to monitor an account that is shared by multiple users, and have value for auditing purposes even when you don’t plan to share an AWS account.

If you are the owner of your AWS account, it’s highly recommended that you create a custom CloudTrail configuration that spans all regions and logs management events to a S3 bucket for long-term storage. Creating an S3 bucket along with this Trail will allow you to save events longer than the default length of 90 days, but can incur some cost if your account is very active and generates large volumes of data for storage. If you are not running productions services or staying in free-tier is important, you can choose not to configure a S3 bucket. The first management trail you configure in any AWS account is free, so you will only see charges if you create multiple management trails, create data trails (Trails which log in-depth information for AWS Resources beyond basic management resources - very useful for troubleshooting at times), or if you configure a S3 bucket with your trail. You can read more details on pricing and decide if long-term storage is right for you.

Create a Management Trail#

Navigate to the AWS CloudTrail console by typing CloudTrail into the home page of the AWS web console.

AWS Web Console Main Dashboard screenshot

Create the CloudTrail config by clicking the 1Create trail1 button from the CloudTrail management page.

AWS Web Console Cloudtrail screenshot

The next page will look like this:

AWS Web console Cloudtrail Create screenshot

Configure the trail settings as shown below:

Trail Name : Name the trail something obvious, like ManagementTrail.

Apply Trail to all regions : Should be Yes.

Read/write events : Use the default of All so you don’t lose any potentially data.

Storage Location

  • Create a new S3 Bucket

  • Yes if we decided to store events beyond 90 days in S3 (which may incur small charges beyond free-tier if the account is highly utilized). If selecting No, skip the setting below for S3 Bucket

  • S3 bucket

  • the name for a new bucket. S3 buckets names must always be globally unique - meaning unique across every AWS account, so try a name formatted like cloudtrail-mgmt-myname.

Click the blue button below to finish creating the trail. The trail will now appear in the CloudTrail Dashboard.

AWS Web console Cloudtrail Created screenshot

Billing Alerts#

Billing Alerts are useful to manage your costs, but they also have security benefits since cost-overrun alerts can warn us of a potential account compromise situation.

Contact AWS Support in case of cost concerns

If you ever do find yourself experiencing an unusual cost over-run, contact AWS Support immediately for assistance. If your account was compromised - they can help you lock it down and usually reverse any charges generated by an attacker. Even if your account wasn’t compromised, AWS Support will often refund unexpected costs when they happen due to misunderstanding or accidental misconfiguration - so ask!

Enable Billing Alerts#

While still signed in as the root user, go to the AWS Billing Dashboard

On the left side, select Billing Preferences

AWS Web console - billing dashboard screenshot

The screen below should appear with options for enabling alerts.

AWS Web console - billing preferences screenshot

If you are planning to use free-tier, ensure the box for Receive Free Tier Usage Alerts is checked. You may add an email address into the field shown if you need alerts for free-tier usage alerts to be sent to an email address other than the account default email.

If you would like to receive alerts that are tailored to a specific cost threshold (ie, alert if estimate exceeds $10), then select the Receive Billing Alerts box. From there, click through on the Manage Billing Alerts Link to go to the CloudWatch page for Billing alerts. See the AWS Documentation for complete information about configuring CloudWatch Billing Alarms

Set a password policy for the account#

The default password policy that comes configured with new accounts is comically weak. It’s important to update this policy before you add any new users.

To update the default password policy: Go to IAM > Account Settings from the AWS Dashboard.

AWS Web console -IAM dashboard screenshot

Click the grey button that says Set password policy to bring up the policy configuration screen.

AWS Web console -IAM password policy screenshot

The password policy can vary depending on organizational security policy, but aim to be as strong or stronger than the policy shown here:

AWS Web console -IAM password policy screenshot
  • Update the character length under “Enforce minimum password length” to AT LEAST 12

  • Require at least one uppercase letter

  • Require at least one lowercase letter

  • Require at least one number

  • Require at least one non-alphanumeric character

  • Enable password expiration of at least 90 days

  • Allow users to change their own password

Save the changes.

Deactivate Regions not in use (optional)#

AWS supports many different regions to allow you to deploy to endpoints closest to your users. In practice though, many AWS customers only ever use one or two regions.

When an AWS account is compromised, attackers often choose to utilize lesser-used regions in hopes that their changes to resource usage will go unnoticed. But more commonly - it’s just easy to forget about resources that were created in rarely-used regions you don’t normally use and end up paying for them longer than you intended.

From the IAM > Account Settings page, we can deactivate regions that we do not plan to us. This ensures that any authentication credentials created for our account cannot be used for those de-activated regions.

In the example below, the deactivate option has been clicked on every region except us-east-1 and us-west-2.

AWS Web console -IAM account regions screenshot

Why isn't it possible to deactivate US East (us-east-1)?

The us-east-1 region was the first region created by AWS, and as such, it is a bit of a snowflake. Many services that are not specific to any particular region (“global” services such as IAM and Billing), are actually running from us-east-1.

Create an IAM Admin User#

If you were given an account access by an account administrator you probably already have an IAM user configured. If that is the case, please contact your administrator to verify if your permissions are sufficient for AWS Lambda development, and ask them for API credential keys if you do not already have them.

For those of us who created our own account, we will need to configure a named user with AdministratorAcess or PowerUserAccess permissions. This user will be used for all future AWS work. This step is strictly required - it's never a good idea to use the AWS account root user (the email address associated with account setup) for any development work.

Steps:

Create the new user by navigating to the AWS Dashboard for IAM > Users

AWS Web console -IAM Users screenshot

Create a new user by clicking the blue Add User button

AWS Web console -Add IAM User screenshot

We will be directed to a screen with user configuration options as shown below:

AWS Web console -Add IAM User screenshot

Name : The username should be something memorable that doesn't already exist in the current account. AWS will show a warning if an invalid user name is given

AWS Account Access Type : Programmatic access : Ensure this option is selected. This option ensures that API credential keys are created for the new user. Those keys are required to deploy Lambdas with the aws-sam-cli, as we will soon in the Configure SAM CLI step.

: AWS Managed Console access : Ensure this option is selected. This allows the new user to login into the AWS Web console as that user. After initial account setup has been completed, it's advised to always login with this user and NOT the email address used to setup the account

Password : Custom password : Ensure selected We are planning to use this user immediately, so we can safely select this option and set a password now. : Require password reset : Ensure unselected Uncheck this box. We don't want to reset the password at next login. This setting should only be used when creating an account that will be given to someone else. : Autogenerated passwords : Ensure unselected Uncheck this box. This option is also intended for use when creating an account that will be given to somebody else.

Click the blue Next: Permissions button on the right side of the page to continue.

AWS Web console -Add IAM User permissions screenshot

From this permissions screen, select the right-most box with the text Attach existing policies directly.

After selecting that box, a list with a search box should appear below. To create an Admin User, type “Admin” into the search box and then select only the AdminstratorAccess option.

AWS Web console -Add IAM User power user screenshot

AdminstratorAccess is powerful

AdministratorAccess gives a user power over almost every resource in an AWS account. Billing control is the one notable exception here. Never share the password or keys for this account with others. Always make a separate account for each user, and provide minimum necessary access permissions depending on each user's role. AWS Identity and Access Management (IAM) can be a complex topic in its own right, so don’t hesitate to consult AWS Docs on IAM

Click the blue button for Next: Tags

Tags are optional key-value pairs that are available on many different AWS resources. These tags are not required, but may be helpful for managing users. In the example we added a tag with the key email for a user’s email address.

Tagging in AWS

Tags are case-sensitive, and input is not validated by AWS when the tag is saved. They are mainly used for categorizing resources. Check that a tag value is correct. Whenever a shared AWS Account is used, it's recommended to agree on a set of "Tag Standards" that are used consistently.

Click the blue button for Next: Review

Check the review page to ensure there were no typos or mis-clicks, and then click the blue Create User button

We will then see the screen with the information about our user.

Click the button that says Download .csv and save the contents somewhere secure. We will not have the opportunity to download these again later. However, if we do lose that file, we can follow the process in the Configuring SAM and AWS CLI step to generate a new set of credentials.

Guard the Access Key CSV file!

If the the contents from the AccessKey file downloaded here are ever accidentally shared or committed to a public repo - those credentials must be disabled immediately. Deleting the file from the public repo after a leak is not enough Attackers have scrapers that target Github and other repo services specifically looking for AWS Credentials - so even if it's there for a second - the creds will need to be disabled. Creds can be disabled the IAM User's security credential page, which is shown in the IAM Creds step below.

Enable MFA on IAM User#

Multi-factor Authentication (MFA) absolutely should be enabled for any user with login access to the AWS web console. AWS does not support sending MFA codes directly over SMS, so most users will want to use a Virtual MFA to secure their AWS account. Hardware MFA devices can also be configured if necessary.

To use virtual MFA device, we will need to install a software application that supports the TOTP protocol on a device we have physical access to - typically a phone. Widely used Virtual MFA applications include Authy, Duo Mobile Google Authenticator and many others. If you already have a particular virtual MFA application installed on your phone, you will most likely be able to use the same one for AWS.

Have a MFA Backup Plan!

If the device that is used for virtual MFA is lost or destroyed - the MFA codes that were on it may be lost with it! Fortunately, most Virtual MFA applications have tooling to restore lost MFA access using either a password encrypted cloud backup, or a series of passcodes that can be stored away from the device. Test these processes early to avoid surprises later.

If you do happen to get locked out of MFA for AWS - you can always contact AWS Support for assistance getting back in. Be prepared, re-gaining access can be a time-consuming process that might require photo ID and/or private billing information to complete.

The example below will use Google Authenticator on Android.

From the AWS Web console, navigate to the IAM console and click Users on the left

AWS Web console IAM Dashboard

Select the user that was just created during the Create IAM Admin User step from the list of users to the right.

AWS Web console IAM Users

Click the Security Credentials Tab

AWS Web console IAM User Security Credentials

To the right of Assigned MFA Device, click the blue link for Manage

A screen like this will appear. If using a virtual MFA, ensure the box for Virtual MFA device is selected and click Continue

AWS Web console Manage MFA

On the next page, we will click the Show QR code button, and open the virtual MFA application on our mobile device.

AWS Web console Virtual MFA

This user account is now ready to be added to the Virtual MFA Application. This process may vary slightly by application.

For Google Authenticator this means: 1. Open the application, and click the red + button at the bottom right side of the screen 2. Click Scan barcode 3. Point the QR code to the QR code shown on the AWS console page in the browser 4. From the browser - enter the first 6 digit number that appears in the box for MFA code 1 5. Wait for that number to change to a different number (takes about 30 seconds) 6. From the browser - Enter the new 6 digit number in the box for MFA code 2 above 7. From the browser - click Assign MFA 8. From Google Authenticator, click the blue ADD ACCOUNT link to save the newly configured account.

After adding the MFA device, the text next to Assigned MFA device on the IAM User credentials tab will no longer say Not Assigned.

AWS Web console User Security Credentials Configured MFA

Enable Root Account MFA#

This step is only for users who are the admins of their own AWS Account. Ignore this if you provided credentials from a shared account

The process to enable Root Account MFA is very similar to the process for setting up a user’s MFA. It is possible to use the exact same virtual MFA app used in the previous step for root configuration configuration.

Click the link here to access the Activate MFA for root credentials.

Alternatively, this page can be navigated to from the AWS web console via the steps below:

  • To enable Root MFA, go to the IAM dashboard.

  • Find the table underneath the header Security Status.

  • Click on the row that says Enable MFA on your root account

  • click Manage MFA

AWS Web console Root MFA

A pop-up screen warning about the use of root security credentials may appear. Click continue.

AWS Web console Root MFA popup

After that box is dismissed, click the blue box for Activate MFA.

After clicking Activate MFA, follow the same procedure from Enable MFA on IAM User section above.

Disable Any Root User Access Keys#

This step is only for users who are the admins of their own AWS Account. Ignore this if you provided credentials from a shared account

From the same screen as the Activate MFA setting

Click the row for “Access Keys”.

AWS Web console Root Access Keys

If there are any access keys which exist for the root account, disable them immediately.

That table should look completely empty, as shown below.

AWS Web console No Root Access Keys

Final notes on security#

If this AWS account is intended to be shared with other user - there are a few other configuration changes that we strongly recommend implementing before granting any additional access. The configuration of these settings is beyond the scope of this particular course, but they are critical for ensuring a sane and secured multi-user environment.

A complete list of security best practices is available at the AWS docs

No discussions yet