How can I utilize user data to automatically run a script with every restart of my Amazon EC2 Linux instance?

Last updated: 2021-02-10

I want to utilize user data to run a script every time my Amazon Elastic Compute Cloud (Amazon EC2) instance is restarted. How can I do that?

Short description

By default, user data scripts and cloud-init directives run only during the first boot cycle when an EC2 instance is launched. However, you can configure your user data script and cloud-init directives with a mime multi-part file. A mime multi-part file allows your script to override how frequently user data is run in the cloud-init package. Then, the file runs the user script. For more information on mime multi-part files, see Mime Multi Part Archive on the cloud-init website.

Resolution

Warning: Before starting this procedure, review the following:

• Stopping and starting the instance erases any data on instance store volumes. Be sure that you back up any data on the instance store volume that you want to keep. For more information, see Determine the root device type of your AMI.
• Stopping and restarting the instance changes the public IP address of your instance. It’s a best practice to use an Elastic IP address instead of a public IP address when routing external traffic to your instance.

1. Make sure that the latest version of cloud-init is installed and functioning properly on your EC2 instance.

2. For security reasons, create an IAM policy to restrict the users who are allowed to add or remove user data through the ModifyInstanceAttribute API.

5. Choose Actions, choose Instance Settings, and then choose Edit User Data.

6. Copy your user script into the Edit user data box, and then choose Save.

The following example is a shell script that writes «Hello World» to a testfile.txt file in a /tmp directory.

By default, cloud-init allows only one content type in user data at a time. However, this example shows both text/cloud-config and text/x-shellscript content-types in a mime-multi part file.

The text/cloud-config content type overrides how frequently user data is run in the cloud-init package by setting the SCRIPTS-USER parameter to ALWAYS.

The text/x-shellscript content type provides the actual user script to be run by the cloud-init cloud_final_modules module. In this example, there is only one line to be run, which is /bin/echo «Hello World.» >> /tmp/testfile.txt.

Note: Replace the line /bin/echo «Hello World.» >> /tmp/testfile.txt with the shell script that you want to run during the instance boot.

7. Start your EC2 instance again, and validate that your script runs correctly.

AWS EC2 userdata on Windows

As I have been previously doing more work on the other cloud, namely Amazon Web Services (AWS), I have found a few things that are worth mentioning and in this article here I will start with EC2 instances and their deployment / provisioning on AWS.

Often you will find yourself in the situation where you will need to run code post deployment of your AWS marketplace or pre-baked custom Amazon machine image (AMI) that you weren’t able to run while creating the AMI or wasn’t included into the marketplace AMI. Examples for this could be:

• joining a Microsoft Active Directory Domain
• installing (or registering) agents, like Anti Virus or monitoring agents
• preparing the instance for other Configuration Management tools like Ansible, Puppet or Chef

Depending on what sort of image (AMI) you are deploying you actually have two options:

• you own the image:
  • create a Scheduled Task while baking the image
  • user_data
• you don’t own the image:
  • bake a new image from the marketplace image
  • user_data

AWS userdata

AWS gives you, as the provisioner of instances, the capability of injecting code into the launch process of an EC2 instance, no matter if you go straight to EC2 or use for example CloudFormation to deploy your infrastructure.

UserData is code that is executed on instances upon instance launch. On Windows that code can come in two flavours, script and powershell .

Your userdata code is configured / set before you launch your instances and if you are using the AWS Console to launch them then above picture will show you where to input the code. UserData is a block of code with a maximum size of 16kb, after it has been encoded to Base64. This means don’t put a 1000 lines of PowerShell code in here.

A very basic test showed me that around 200 lines of PowerShell encoded into Base64 equal around 16kb.

For example setting your machines up for Ansible with this PowerShell script would still work via userdata: https://github.com/ansible/ansible/blob/devel/examples/scripts/ConfigureRemotingForAnsible.ps1

However, you don’t normally use the AWS Console to spin up machines, right? Just as you wouldn’t use the Azure portal to deploy instances, you would use a CLI, a tool like Ansible or in AWS’s case CloudFormation to help you with this task.

UserData on Windows can call two different shells, well, the two that exist on Windows (except for Bash, for now?).

script will convert your code into a .bat file and call cmd.exe . powershell will convert your conde into a .ps1 file and call powershell.exe .

userdata on Windows from CloudFormation

CloudFormation uses json format to describe your environment / infrastructure. If you are familiar with Microsoft Azure then this will be similar to an Azure Resource Manager (ARM) template. Part of this CloudFormation template would be the UserData block as you can see below.

This example json is used to configure the local proxy on an instance leveraging the script call. This is done because here we are calling both PowerShell cmdlets and “legacy” executables like netsh . When both script and powershell are used in a userdata block then the batch script always gets executed first, no matter in what order the blocks are put in the userdata field. My recommendation is to only use script or powershell , not both. The Ref calls are used to gather input parameters to the CloudFormation script.

userdata with aws cli

If you are going straight to the aws cli to provision your instances then using the userdata script is just as easy.

user_data.txt would consist of the cleartext code that you want run upon instance launch encapsulated in the

userdata with AWS PowerShell module

Are you running your provisioning scripts on Windows and do you have access to the AWS PowerShell module? If yes, then New-EC2Instance has two parameters that will help you pass in your userdata into a new instance.

New-EC2Instance -ImageId ami-fbc42a3 -MinCount 1 -MaxCount 1 -InstanceType c4.large -KeyName david-dev -SecurityGroup sg-dev -userdatafile user_data.txt

If you didn’t know, the AWS PowerShell module is available on most AMIs out of the box. If not, and you are on WMF5 or have PackageManagement installed on your machine, then run the following command to install it from the command line:

Execution context

Depending on what you need to do you need to be aware of the execution context of your userdata script. If you are launching an AMI for the first time that has the “auto-generate Administrator password” flag set in the EC2Config then the script will execute in the context of the localhost\\Administrator accoun. If this is not the case then the context of the EC2Config service will be used, by default that is the SYSTEM account.

Troubleshooting

The resulting script will be copied to the instance to the following path: C:\\Program Files\\Amazon\\Ec2ConfigService\\Scripts\\UserScript.ps1. Here you will be able to see the resulting script and check if your parameters were passed into your userdata script correctly for example.

Start playing around with this, I will post some more info on this in the future.

Instance metadata and user data

Instance metadata is data about your instance that you can use to configure or manage the running instance. Instance metadata is divided into categories, for example, host name, events, and security groups.

You can also use instance metadata to access user data that you specified when launching your instance. For example, you can specify parameters for configuring your instance, or include a simple script. You can build generic AMIs and use user data to modify the configuration files supplied at launch time. For example, if you run web servers for various small businesses, they can all use the same generic AMI and retrieve their content from the Amazon S3 bucket that you specify in the user data at launch. To add a new customer at any time, create a bucket for the customer, add their content, and launch your AMI with the unique bucket name provided to your code in the user data. If you launch more than one instance at the same time, the user data is available to all instances in that reservation. Each instance that is part of the same reservation has a unique ami-launch-index number, allowing you to write code that controls what to do. For example, the first host might elect itself as the original node in a cluster. For a detailed AMI launch example, see Example: AMI launch index value.

EC2 instances can also include dynamic data, such as an instance identity document that is generated when the instance is launched. For more information, see Dynamic data categories.

Although you can only access instance metadata and user data from within the instance itself, the data is not protected by authentication or cryptographic methods. Anyone who has direct access to the instance, and potentially any software running on the instance, can view its metadata. Therefore, you should not store sensitive data, such as passwords or long-lived encryption keys, as user data.

Amazon ec2 user-data, how does it work?

We are starting instances, and accessing the user-data we place. But does anybody understand the internals of this operation (from Amazon’s side)? When we pass in the user-data, at what point is that data transmitted to the VM (is this a Xen feature) and where is it stored?

I first thought, it was set as the USER_DATA env var, but we can also pass it as a file. Where is that file stored? Is it generic to all instances or varies depending on AMI?

This is not a problem per se, just wanted to know how Amazon does this.

5 Answers 5

The user-data is available to the instance with a simple HTTP request at this URL:

Amazon EC2 does not put this user-data on the instance directly, though many AMIs have code that instructs the instance to download and process the user-data automatically.

An easy example for everyone’s understanding: If you want to create the file /tmp/testfile.txt when the machine gets started, you can simply add these two lines on the User data field.

Remember to put the #!/bin/bash at the top before your commands.

When you run the instance (Linux AMI), you can see the User data field content at /var/lib/cloud/instance/user-data.txt

Sorry to post to such an old question, but this seems like the best place to put this additional piece of information.

Most all the AWS documents describe User Data as a property in which to put instance lifecycle startup scripting, that is, the stuff you want to run only when the instance first launches.

This is usually the case, but there has been at least one other person besides myself wanting to perform different scripting on restart, say to fix a broken key or something. And guess what. you can do that using User Data.

Here is the code and the link to the AWS document.

I can find no documentation on this formatting of User Data that allows this to happen. I’ve tried it out and it works. I have tried to see if it runs on every startup, and it does.

So, if you think you need to do this, I recommend that you backup. Make sure you have a copy of the original User Data, and use the code provided modified to suite, and remove the code upon the next time you stop the instance (to avoid multiple runs of the script).

Configure a Windows instance using the EC2Config service

The latest launch service for all supported Windows Server versions is EC2Launch v2, which replaces both EC2Config and EC2Launch.

Windows AMIs for Windows Server 2012 R2 and earlier include an optional service, the EC2Config service ( EC2Config.exe ). EC2Config starts when the instance boots and performs tasks during startup and each time you stop or start the instance. EC2Config can also perform tasks on demand. Some of these tasks are automatically enabled, while others must be enabled manually. Although optional, this service provides access to advanced features that aren’t otherwise available. This service runs in the LocalSystem account.

EC2Launch replaced EC2Config on Windows AMIs for Windows Server 2016 and later. For more information, see Configure a Windows instance using EC2Launch. The latest launch service for all supported Windows Server versions is EC2Launch v2, which replaces both EC2Config and EC2Launch.

EC2Config uses settings files to control its operation. You can update these settings files using either a graphical tool or by directly editing XML files. The service binaries and additional files are contained in the %ProgramFiles%\Amazon\EC2ConfigService directory.

Contents

EC2Config tasks

EC2Config runs initial startup tasks when the instance is first started and then disables them. To run these tasks again, you must explicitly enable them prior to shutting down the instance, or by running Sysprep manually. These tasks are as follows:

Set a random, encrypted password for the administrator account.

Generate and install the host certificate used for Remote Desktop Connection.

Dynamically extend the operating system partition to include any unpartitioned space.

Execute the specified user data (and Cloud-Init, if it’s installed). For more information about specifying user data, see Work with instance user data.

EC2Config performs the following tasks every time the instance starts:

Change the host name to match the private IP address in Hex notation (this task is disabled by default and must be enabled in order to run at instance start).

Configure the key management server (AWS KMS), check for Windows activation status, and activate Windows as necessary.

Mount all Amazon EBS volumes and instance store volumes, and map volume names to drive letters.

Write event log entries to the console to help with troubleshooting (this task is disabled by default and must be enabled in order to run at instance start).

Write to the console that Windows is ready.

Add a custom route to the primary network adapter to enable the following IP addresses when multiple NICs are attached: 169.254.169.250, 169.254.169.251, and 169.254.169.254. These addresses are used by Windows Activation and when you access instance metadata.

EC2Config performs the following task every time a user logs in:

Display wallpaper information to the desktop background.

While the instance is running, you can request that EC2Config perform the following task on demand:

Run Sysprep and shut down the instance so that you can create an AMI from it. For more information, see Create a standardized Amazon Machine Image (AMI) using Sysprep .

Stop, restart, delete, or uninstall EC2Config

You can manage the EC2Config service just as you would any other service.

To apply updated settings to your instance, you can stop and restart the service. If you’re manually installing EC2Config, you must stop the service first.

To stop the EC2Config service

Launch and connect to your Windows instance.

On the Start menu, point to Administrative Tools, and then click Services.

In the list of services, right-click EC2Config, and select Stop.

To restart the EC2Config service

Launch and connect to your Windows instance.

On the Start menu, point to Administrative Tools, and then click Services.

In the list of services, right-click EC2Config, and select Restart.

If you don’t need to update the configuration settings, create your own AMI, or use AWS Systems Manager, you can delete and uninstall the service. Deleting a service removes its registry subkey. Uninstalling a service removes the files, the registry subkey, and any shortcuts to the service.

To delete the EC2Config service

Start a command prompt window.

Run the following command:

To uninstall EC2Config

Launch and connect to your Windows instance.

On the Start menu, click Control Panel.

Double-click Programs and Features.

On the list of programs, select EC2ConfigService, and click Uninstall .

EC2Config and AWS Systems Manager

The EC2Config service processes Systems Manager requests on instances created from AMIs for versions of Windows Server prior to Windows Server 2016 that were published before November 2016.

Instances created from AMIs for versions of Windows Server prior to Windows Server 2016 that were published after November 2016 include the EC2Config service and SSM Agent. EC2Config performs all of the tasks described earlier, and SSM Agent processes requests for Systems Manager capabilities like Run Command and State Manager.

You can use Run Command to upgrade your existing instances to use to the latest version of the EC2Config service and SSM Agent. For more information, see Update SSM Agent by using Run Command in the AWS Systems Manager User Guide.

EC2Config and Sysprep

The EC2Config service runs Sysprep, a Microsoft tool that enables you to create a customized Windows AMI that can be reused. When EC2Config calls Sysprep, it uses the files in %ProgramFiles%\Amazon\EC2ConfigService\Settings to determine which operations to perform. You can edit these files indirectly using the Ec2 Service Properties dialog box, or directly using an XML editor or a text editor. However, there are some advanced settings that aren’t available in the Ec2 Service Properties dialog box, so you must edit those entries directly.

If you create an AMI from an instance after updating its settings, the new settings are applied to any instance that’s launched from the new AMI. For information about creating an AMI, see Create a custom Windows AMI.

EC2 service properties

The following procedure describes how to use the Ec2 Service Properties dialog box to enable or disable settings.

To change settings using the Ec2 Service Properties dialog box

Launch and connect to your Windows instance.

From the Start menu, click All Programs, and then click EC2ConfigService Settings.

On the General tab of the Ec2 Service Properties dialog box, you can enable or disable the following settings.

If this setting is enabled (it is disabled by default), the host name is compared to the current internal IP address at each boot; if the host name and internal IP address do not match, the host name is reset to contain the internal IP address and then the system reboots to pick up the new host name. To set your own host name, or to prevent your existing host name from being modified, do not enable this setting.

User data execution enables you to specify scripts in the instance metadata. By default, these scripts are run during the initial launch. You can also configure them to run the next time you reboot or start the instance, or every time you reboot or start the instance.

If you have a large script, we recommend that you use user data to download the script, and then run it.

For more information, see User data execution.

Use this setting to display event log entries on the console during boot for easy monitoring and debugging.

Click Settings to specify filters for the log entries sent to the console. The default filter sends the three most recent error entries from the system event log to the console.

Use this setting to display system information on the desktop background. The following is an example of the information displayed on the desktop background.

The information displayed on the desktop background is controlled by the settings file EC2ConfigService\Settings\WallpaperSettings.xml .

Use this setting to allow EC2 to signal the operating system to perform hibernation.

Click the Storage tab. You can enable or disable the following settings.

This setting dynamically extends Disk 0/Volume 0 to include any unpartitioned space. This can be useful when the instance is booted from a root device volume that has a custom size.

This setting formats and mounts all volumes attached to the instance during start.

Drive Letter Mapping

The system maps the volumes attached to an instance to drive letters. For Amazon EBS volumes, the default is to assign drive letters going from D: to Z:. For instance store volumes, the default depends on the driver. AWS PV drivers and Citrix PV drivers assign instance store volumes drive letters going from Z: to A:. Red Hat drivers assign instance store volumes drive letters going from D: to Z:.

To choose the drive letters for your volumes, click Mappings. In the DriveLetterSetting dialog box, specify the Volume Name and Drive Letter values for each volume, click Apply, and then click OK. We recommend that you select drive letters that avoid conflicts with drive letters that are likely to be in use, such as drive letters in the middle of the alphabet.

After you specify a drive letter mapping and attach a volume with same label as one of the volume names that you specified, EC2Config automatically assigns your specified drive letter to that volume. However, the drive letter mapping fails if the drive letter is already in use. Note that EC2Config doesn’t change the drive letters of volumes that were already mounted when you specified the drive letter mapping.

To save your settings and continue working on them later, click OK to close the Ec2 Service Properties dialog box. If you have finished customizing your instance and want to create an AMI from that instance, see Create a standardized Amazon Machine Image (AMI) using Sysprep .

EC2Config settings files

The settings files control the operation of the EC2Config service. These files are located in the C:\Program Files\Amazon\Ec2ConfigService\Settings directory:

ActivationSettings.xml —Controls product activation using a key management server (KMS).

AWS.EC2.Windows.CloudWatch.json —Controls which performance counters to send to CloudWatch and which logs to send to CloudWatch Logs.

BundleConfig.xml —Controls how EC2Config prepares an instance store-backed instance for AMI creation.

Config.xml —Controls the primary settings.

DriveLetterConfig.xml —Controls drive letter mappings.

EventLogConfig.xml —Controls the event log information that’s displayed on the console while the instance is booting.

WallpaperSettings.xml —Controls the information that’s displayed on the desktop background.

This file contains settings that control product activation. When Windows boots, the EC2Config service checks whether Windows is already activated. If Windows is not already activated, it attempts to activate Windows by searching for the specified KMS server.

SetAutodiscover —Indicates whether to detect a KMS automatically.

TargetKMSServer —Stores the private IP address of a KMS. The KMS must be in the same Region as your instance.

DiscoverFromZone —Discovers the KMS server from the specified DNS zone.

ReadFromUserData —Gets the KMS server from UserData.

LegacySearchZones —Discovers the KMS server from the specified DNS zone.

DoActivate —Attempts activation using the specified settings in the section. This value can be true or false .

LogResultToConsole —Displays the result to the console.

This file contains settings that control how EC2Config prepares an instance for AMI creation.

AutoSysprep —Indicates whether to use Sysprep automatically. Change the value to Yes to use Sysprep.

SetRDPCertificate —Sets a self-signed certificate to the Remote Desktop server. This enables you to securely RDP into the instances. Change the value to Yes if the new instances should have the certificate.

This setting is not used with Windows Server 2008 or Windows Server 2012 instances because they can generate their own certificates.

SetPasswordAfterSysprep —Sets a random password on a newly launched instance, encrypts it with the user launch key, and outputs the encrypted password to the console. Change the value of this setting to No if the new instances should not be set to a random encrypted password.

Ec2SetPassword —Generates a random encrypted password each time you launch an instance. This feature is disabled by default after the first launch so that reboots of this instance don’t change a password set by the user. Change this setting to Enabled to continue to generate passwords each time you launch an instance.

This setting is important if you are planning to create an AMI from your instance.

Ec2SetComputerName —Sets the host name of the instance to a unique name based on the IP address of the instance and reboots the instance. To set your own host name, or prevent your existing host name from being modified, you must disable this setting.

Ec2InitializeDrives —Initializes and formats all volumes during startup. This feature is enabled by default.

Ec2EventLog —Displays event log entries in the console. By default, the three most recent error entries from the system event log are displayed. To specify the event log entries to display, edit the EventLogConfig.xml file located in the EC2ConfigService\Settings directory. For information about the settings in this file, see Eventlog Key in the MSDN Library.

Ec2ConfigureRDP —Sets up a self-signed certificate on the instance, so users can securely access the instance using Remote Desktop. This feature is disabled on Windows Server 2008 and Windows Server 2012 instances because they can generate their own certificates.

Ec2OutputRDPCert —Displays the Remote Desktop certificate information to the console so that the user can verify it against the thumbprint.

Ec2SetDriveLetter —Sets the drive letters of the mounted volumes based on user-defined settings. By default, when an Amazon EBS volume is attached to an instance, it can be mounted using the drive letter on the instance. To specify your drive letter mappings, edit the DriveLetterConfig.xml file located in the EC2ConfigService\Settings directory.

Ec2WindowsActivate —The plug-in handles Windows activation. It checks to see if Windows is activated. If not, it updates the KMS client settings, and then activates Windows.

To modify the KMS settings, edit the ActivationSettings.xml file located in the EC2ConfigService\Settings directory.

Ec2DynamicBootVolumeSize —Extends Disk 0/Volume 0 to include any unpartitioned space.

Ec2HandleUserData —Creates and runs scripts created by the user on the first launch of an instance after Sysprep is run. Commands wrapped in script tags are saved to a batch file, and commands wrapped in PowerShell tags are saved to a .ps1 file (corresponds to the User Data check box on the Ec2 Service Properties dialog box).

Ec2ElasticGpuSetup —Installs the Elastic GPU software package if the instance is associated with an elastic GPU.

Ec2FeatureLogging —Sends Windows feature installation and corresponding service status to the console. Supported only for the Microsoft Hyper-V feature and corresponding vmms service.

ManageShutdown —Ensures that instances launched from instance store-backed AMIs do not terminate while running Sysprep.

SetDnsSuffixList —Sets the DNS suffix of the network adapter for Amazon EC2. This allows DNS resolution of servers running in Amazon EC2 without providing the fully qualified domain name.

WaitForMetaDataAvailable —Ensures that the EC2Config service will wait for metadata to be accessible and the network available before continuing with the boot. This check ensures that EC2Config can obtain information from metadata for activation and other plug-ins.

ShouldAddRoutes —Adds a custom route to the primary network adapter to enable the following IP addresses when multiple NICs are attached: 169.254.169.250, 169.254.169.251, and 169.254.169.254. These addresses are used by Windows Activation and when you access instance metadata.

RemoveCredentialsfromSyspreponStartup —Removes the administrator password from Sysprep.xml the next time the service starts. To ensure that this password persists, edit this setting.

This file contains settings that control drive letter mappings. By default, a volume can be mapped to any available drive letter. You can mount a volume to a particular drive letter as follows.

VolumeName —The volume label. For example, My Volume . To specify a mapping for an instance storage volume, use the label Temporary Storage X , where X is a number from 0 to 25.

DriveLetter —The drive letter. For example, M: . The mapping fails if the drive letter is already in use.

This file contains settings that control the event log information that’s displayed on the console while the instance is booting. By default, we display the three most recent error entries from the System event log.

Category —The event log key to monitor.

ErrorType —The event type (for example, Error , Warning , Information .)

NumEntries —The number of events stored for this category.

LastMessageTime —To prevent the same message from being pushed repeatedly, the service updates this value every time it pushes a message.

AppName —The event source or application that logged the event.

This file contains settings that control the information that’s displayed on the desktop background. The following information is displayed by default.

Hostname —Displays the computer name.

Instance ID —Displays the ID of the instance.

Public IP Address —Displays the public IP address of the instance.

Private IP Address —Displays the private IP address of the instance.

Availability Zone —Displays the Availability Zone in which the instance is running.

Instance Size —Displays the type of instance.

Architecture —Displays the setting of the PROCESSOR_ARCHITECTURE environment variable.

You can remove any of the information that’s displayed by default by deleting its entry. You can add additional instance metadata to display as follows.

You can add additional System environment variables to display as follows.

This file contains settings that control how EC2Config initializes drives.

By default, EC2Config initialize drives that were not brought online with the operating system. You can customize the plugin as follows.

Use a settings group to specify how you want to initialize drives:

Enables the TRIM command when formatting drives. After a drive has been formatted and initialized, the system restores TRIM configuration.

Starting with EC2Config version 3.18, the TRIM command is disabled during the disk format operation by default. This improves formatting times. Use this setting to enable TRIM during the disk format operation for EC2Config version 3.18 and later.

Disables the TRIM command when formatting drives and improves formatting times in Windows. After a drive has been formatted and initialized, the system restores TRIM configuration.

Disables formatting for new drives. Use this setting to initialize drives manually.

Configure proxy settings for the EC2Config service

You can configure the EC2Config service to communicate through a proxy using one of the following methods: the AWS SDK for .NET, the system.net element, or Microsoft Group Policy and Internet Explorer. Using the AWS SDK for .NET is the preferred method because you can specify a user name and password.

Methods

Configure proxy settings using the AWS SDK for .NET (Preferred)

You can configure proxy settings for the EC2Config service by specifying the proxy element in the Ec2Config.exe.config file. For more information, see Configuration Files Reference for AWS SDK for .NET.

To specify the proxy element in Ec2Config.exe.config

Edit the Ec2Config.exe.config file on an instance where you want the EC2Config service to communicate through a proxy. By default, the file is located in the following directory: %ProgramFiles%\Amazon\Ec2ConfigService .

Add the following aws element to the configSections . Do not add this to any existing sectionGroups .

For EC2Config versions 3.17 or earlier

For EC2Config versions 3.18 or later

Add the following aws element to the Ec2Config.exe.config file.

Save your changes.

Configure proxy settings using the system.net element

You can specify proxy settings in a system.net element in the Ec2Config.exe.config file. For more information, see defaultProxy Element (Network Settings) on MSDN.

To specify the system.net element in Ec2Config.exe.config

Edit the Ec2Config.exe.config file on an instance where you want the EC2Config service to communicate through a proxy. By default, the file is located in the following directory: %ProgramFiles%\Amazon\Ec2ConfigService .

Add a defaultProxy entry to system.net . For more information, see defaultProxy Element (Network Settings) on MSDN.

For example, the following configuration routes all traffic to use the proxy that is currently configured for Internet Explorer, with the exception of the metadata and licensing traffic, which will bypass the proxy.

Save your changes.

Configure proxy settings using Microsoft Group Policy and Microsoft Internet Explorer

The EC2Config service runs under the Local System user account. You can specify instance-wide proxy settings for this account in Internet Explorer after you change Group Policy settings on the instance.

To configure proxy settings using Group Policy and Internet Explorer

On an instance where you want the EC2Config service to communicate through a proxy, open a Command prompt as an Administrator, type gpedit.msc , and press Enter.

In the Local Group Policy Editor, under Local Computer Policy, choose Computer Configuration, Administrative Templates, Windows Components, Internet Explorer.

In the right-pane, choose Make proxy settings per-machine (rather than per-user) and then choose Edit policy setting.

Choose Enabled, and then choose Apply.

Open Internet Explorer, and then choose the Tools button.

Choose Internet Option, and then choose the Connections tab.

Choose LAN settings.

Under Proxy server, choose the Use a proxy server for your LAN option.

Specify address and port information and then choose OK.