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#
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
IAM Useron that AWS Account which has rights to interact with AWS Lambda, and related services. The rights that come with
Power User Accesscover 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.
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
Note for Accounts created by
AWS OrganizationMany 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.
Create the CloudTrail config by clicking the 1Create trail1 button from the CloudTrail management page.
The next page will look like this:
Configure the trail settings as shown below:
: Name the trail something obvious, like
Apply Trail to all regions
: Should be
: Use the default of
All so you don’t lose any potentially data.
Create a new S3 Bucket
Yesif 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
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
Click the blue button below to finish creating the trail. The trail will now appear in the CloudTrail Dashboard.
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
The screen below should appear with options for enabling alerts.
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:
Account Settings from the AWS Dashboard.
Click the grey button that says
Set password policy to bring up the policy configuration screen.
The password policy can vary depending on organizational security policy, but aim to be as strong or stronger than the policy shown here:
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.
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
Why isn't it possible to deactivate US East (us-east-1)?
us-east-1region 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
Billing), are actually running from
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
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.
Create the new user by navigating to the AWS Dashboard for
Create a new user by clicking the blue
Add User button
We will be directed to a screen with user configuration options as shown below:
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.
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
AdministratorAccessgives 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
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
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
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
Select the user that was just created during the Create IAM Admin User step from the list of users to the right.
Security Credentials Tab
To the right of
Assigned MFA Device, click the blue link for
A screen like this will appear. If using a virtual MFA, ensure the box for
Virtual MFA device is selected and click
On the next page, we will click the
Show QR code button, and open the virtual MFA application on our mobile device.
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
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
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
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
Click on the row that says
Enable MFA on your root account
A pop-up screen warning about the use of root security credentials may appear. Click
After that box is dismissed, click the blue box for
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”.
If there are any access keys which exist for the root account, disable them immediately.
That table should look completely empty, as shown below.
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